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.

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.

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.

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

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.

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.

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.

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.

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.

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum