Automatic UBoot Installer

ramuk · **Posted:** Tue Nov 14, 2006 1:07 am

This may sound like an idiotic question, but is there any way to engineer u-boot so that it can be flashed WITH the firmware flasher?
is this technically even possible?

kuroguy · **Joined:** Tue Mar 21, 2006 9:11 pm **Posts:** 658

Not an idiotic question at all. IF this is possible, everybody with a LS should be using u-boot. It is head and antlers above the buffalo bootloader, and in combination with the 2.4.33 kernal and telnet/FTP enabled firmware and lb_worm's avr_evtd completely opens the LS and Kuro.

lb_worm · **Posted:** Tue Nov 14, 2006 11:30 am

We could make a change to the EM mode, which is used to extract the image to disk, so that it flashes the bootcode too AKA how the LS PRO does it. This would be a good change

mindbender · **Posted:** Tue Nov 14, 2006 1:40 pm

lb_worm wrote:

We could make a change to the EM mode, which is used to extract the image to disk, so that it flashes the bootcode too AKA how the LS PRO does it. This would be a good change

go on tell us your thoughts how this should work. i would try to implement on my LS1 and try to flash UBoot with it....

davy_gravy wrote:

OK, I'm up for it. It'd be on an HG .

which way do you wanna go? the UBoot way or with the stock bootloader?

kuroguy · **Joined:** Tue Mar 21, 2006 9:11 pm **Posts:** 658

Create a firmimg with the u-boot binary in the initrd as well as 2 special init files.

Use the firmware updater to flash the first firmimg and copy a second (final) firmimg to the harddisk.

This second firmimg would be 4MB and contain the final u-boot and the telnet/ftp enabled firmware with 2.4.33. The first init file in the first firmimg would automatically run on reboot and mount the harddisk and flash the permanent 4 MB firmware. Once that is complete, a second init file would erase the firmimg file from the harddisk and shutdown the box.

So, all that would be required of the user would be to run the firmware updater and restart the box after it completed. Then wait for it to shut down and simply restart your newly u-boot/telnet/ftp/2.4.33 enabled box.

Piece of cake. Unfortunately I do not have a LS1 to test it on. If someone (mindbender) wants to package this up I might be persuaded to flash a standard LS1 firmware to my Kuro and test it.

mindbender · **Posted:** Tue Nov 14, 2006 5:08 pm

idea sounds good.

flashing the first firmimg.bin to the flash is easy - we can just swap the firmimg.bin from the same directory as the firmware updater.

question is how we get the second firmimg.bin to the right position of the hdd. as you are thinking of using the firmware updater we need to find a simple way to transfer a file to the folder of our choice on the hdd.
maybe this is possible via ap_servd/ls_servd?

i mean.....the image.dat is also transfered to the box....

kuroguy wrote:

The first init file in the first firmimg would automatically run on reboot and mount the harddisk and flash the permanent 4 MB firmware.

this should be easy. the current enhanced firmimg.bins already have /usr/sbin/mount_disk inside which mounts /dev/hda1 & /dev/hda3.

Code:

#! /bin/sh 
 
  echo -n "Mounting system (/dev/hda1) + data partition (/dev/hda3)" 
  echo -n "of the internal HDD to /mnt/" 
 
  mkdir /mnt/hda1 
  mkdir /mnt/hda3 
 
  mount -t vfat,ext3,ext2 /dev/hda1 /mnt/hda1 
  mount -t vfat,ext3,ext2 /dev/hda3 /mnt/hda3 
 
exit 0 

we have to write a script that automatically starts the mounting and then flashes the UBoot binary.
i call it /etc/init.d/uboot_installer - it has to be linked to the beginning of the starting process...

Quote:

# !/bin/sh

# mount the hdd-partitions
/usr/sbin/mount_disk

# check if hdd really was successfully mounted
# if yes proceed, if no stop
>> TO BE DONE

# start the UBoot flashing-script
/usr/sbin/flash_full_image

# maybe do some post-flashing checks before rebooting automatically and do not reboot if anything goes wrong
# so debugging + fixing it via telnet is possible
>> TO BE DONE

# automatically reboot
reboot

of course we need the /usr/sbin/flash_full_image script also:

Quote:

# !/bin/sh

# check which box this script is running on
>> can be used from other scripts

# check if a valid all-flash-file is available at the correct position on the hdd.
>> TO BE DONE

# flash the all-flash-file to the complete flash-device
>> TO BE DONE

exit 0;

any thoughts, suggestions or criticism?

or maybe some replacements for some "TO BE DONE"-blocks?

ramuk · **Posted:** Tue Nov 14, 2006 5:30 pm

mindbender wrote:

question is how we get the second firmimg.bin to the right position of the hdd. as you are thinking of using the firmware updater we need to find a simple way to transfer a file to the folder of our choice on the hdd.
maybe this is possible via ap_servd/ls_servd?

i mean.....the image.dat is also transfered to the box....

Why not just pack it into the image.dat/tmpimage.tgz? you could just pack it into a telnet enabled distribution or openlink.....
then the installation of either debian/gentoo/ or whatever have you after that could be scripted I would think (with a self updating script) from an SSH session/root prompt.

kuroguy · **Joined:** Tue Mar 21, 2006 9:11 pm **Posts:** 658

To make things easy lets call the part of the image.dat that goes into flash "firmware" and the part that goes on the hard disk "soft-firmware".

I was thinking that the 4 MB firmware contents could be deployed as part of a tmpimage.dat. It would just need to be tarred up as part of the stock tmpimage and then untarred in the root directory; Just like a regular soft-firmware update.

Checking for the presence of the 4MB flash image is as simple as mounting the disk partition and doing an "if exist...." If the file exists then copy it to flash at 0xffc00000 and erase the file from the hard disk so it doesn't get used again.

The simplicity of this system is that if the installer is run a second time it will not damage the box as all we are really doing is flashing the full firmware from a copy on disk and we do not actually erase the flash, so a missing firmware on disk just halts the process and drops us into EM mode.

As far as checking that the payload gets written properly, a checksum of the flash contents from 0xffc00000 thru 0xffefffff (the initrd and kernel) and 0xfff00000 thru 0xfff3fffff (the bootloader) and an if then statement should do the trick as we should know these checksums going into this. these correct checksums, checksum binary, and scripts for checking could be placed on the harddisk as part of the first stage soft-firmware update.

Regarding checking which box this is running on, doesn't the firmware updater do this check? if so, we could leave the part of making sure we are flashing to the correct box up to the firmware updater.

By the way, we should cut these last few posts and move them to a different thread with a more appropriate title as we have completely left the original subject of this thread.

mindbender · **Posted:** Tue Nov 14, 2006 6:01 pm

kuroguy wrote:

I was thinking that the 4 MB firmware contents could be deployed as part of a tmpimage.dat. It would just need to be tarred up as part of the stock tmpimage and then untarred in the root directory; Just like a regular soft-firmware update.

thats true!
i forgot that. good. then this is no problem.

kuroguy wrote:

Checking for the presence of the 4MB flash image is as simple as mounting the disk partition and doing an "if exist...." If the file exists then copy it to flash at 0xffc00000 and erase the file from the hard disk so it doesn't get used again.

i agree.

kuroguy wrote:

The simplicity of this system is that if the installer is run a second time it will not damage the box as all we are really doing is flashing the full firmware from a copy on disk and we do not actually erase the flash, so a missing firmware on disk just halts the process and drops us into EM mode.

good...we need to make it as save as possible.

kuroguy wrote:

As far as checking that the payload gets written properly, a checksum of the flash contents from 0xffc00000 thru 0xffefffff (the initrd and kernel) and 0xfff00000 thru 0xfff3fffff (the bootloader) and an if then statement should do the trick as we should know these checksums going into this. these correct checksums, checksum binary, and scripts for checking could be placed on the harddisk as part of the first stage soft-firmware update.

the flash contents from 0xfc00000 through 0xffefffff (initrd and kernel) is the firmimg.bin i suppose? we could simply use the firmimgtool inside the Ramdisk to verify the the checksum for the kernel + initrd. it can be used directly with an device and not only with a file....but of course we could do it completely independent from that by creating own checksums which also get included in the special UBoot-image.dat. we should run this scripts after flashing and before rebooting....thats the only way they make sense at all.

kuroguy wrote:

By the way, we should cut these last few posts and move them to a different thread with a more appropriate title as we have completely left the original subject of this thread.

done

kuroguy · **Joined:** Tue Mar 21, 2006 9:11 pm **Posts:** 658

mindbender wrote:

we should run this scripts after flashing and before rebooting....thats the only way they make sense at all.

Exactly. So we check the checksum of the firmimg.bin against the one in flash to verify a good flash and do the same for the bootloader, only since the bootloader only takes up 4 blocks we can't just calculate a checksum for the bootloader's mtd device as there will be other blocks (fff40000 to the end) that we don't bother to erase. Also, it would be a good idea to erase 0xfff60000 -0xfff6ffff as that is where the u-boot environment is stored and garbage there will cause problems with u-boot; not huge problems, in fact very easy to fix, but since we are already working with the flash, it makes sense to do the housekeeping as part of the installer.

By the way, reading the checksum from the firmimg header is not a good way to verify the firmimg as the header could be written correctly and the remainder of the firmimg could have an error, so calculating the checksum from the mtdblock would be the way to go.

mindbender · **Posted:** Tue Nov 14, 2006 7:22 pm

kuroguy wrote:

By the way, reading the checksum from the firmimg header is not a good way to verify the firmimg as the header could be written correctly and the remainder of the firmimg could have an error, so calculating the checksum from the mtdblock would be the way to go.

you are right.

i created a new wiki page which deals with this "UBoot Installer"....and we can develope the scripts on the talk-page of it.
http://buffalo.nas-central.org/index.php?title=UBoot-Installer

ramuk · **Posted:** Tue Nov 14, 2006 8:31 pm

I added the small bit to check whether disks were mounted, kept it very short, just exits.

I wonder how you would check if it's an HG/LS1 or LS2? all of our solutions so far seem to have tested something ON the disk, or used the kernel name.

edit: mindbender's method used /etc/linkstation_release is this written to the disk by the onboard flash? or by the firmware updater? (ie contained in tmpimage.tgz)

mindbender · **Posted:** Tue Nov 14, 2006 8:41 pm

ramuk wrote:

I wonder how you would check if it's an HG/LS1 or LS2?

by bundling the firmware updater with the right UBoot-Binary (inside the right firmimg.bin).

the firmware updater only works if it is the correct box....in fact it is only working if it gets the correct information of /etc/linkstation_release from either hddrootfs-mode or even EM-mode.

if the firmware updater finds the box it IS the correct model.

there will be an "UBoot-updater-package" for each supported model.
i think that is the easiest way.

ramuk · **Posted:** Tue Nov 14, 2006 8:47 pm

mindbender wrote:

by bundling the firmware updater with the right UBoot-Binary (inside the right firmimg.bin).

of course.... I understood that part

I ment INSIDE the script you put up, how to figure this out there?

Code:

# check which box this script is running on

mindbender · **Posted:** Tue Nov 14, 2006 8:52 pm

i define that the 4mb flash image is stored at /.

i call it full_image.bin. it will be bundled with an OpenLink for that box.

so we should check for /mnt/hda1/full_flash_image.bin

regarding the flash device we want to flash to it depends on the box we have. the LS1 uses /dev/flX, the HG /dev/mtdblockX.

Buffalo NAS-Central Forums

Automatic UBoot Installer

Who is online