Category:Opensource Firmware Updater
In computing, firmware is software that is embedded in a hardware device. It is often provided on flash ROMs or as a binary image file that can be uploaded onto existing hardware by a user. Firmware is defined as: The computer program in a Flash memory integrated circuit (a hardware part number or other configuration identifier is usually used to represent the software)
Updating the firmimg.bin in the flash is needed as a base to allow updating with the planned HddRootFS-Updater described below. We need a telnet + ftp-enabled Ramdisk (EM Mode) like the Kuroboxes have. mindbender already created some for the LS1/LS HG/LS HS. These new firmimg.bins will most likely be bundled with the future openlink / freelink releases when they are ready for that.
Status: currently we only have 22.214.171.124 working for UBoot-images. the current kernels cannot be bundled with the standard releases as it would break the ability to use the buffalo firmware updater because there is no check for "OKOK" in flash of the LS1/HG anymore. either we have to integrate this check again especially for the standard releases who do not want to use UBoot or we have to use the stock firmware which does not allow to much (NFS for example). mindbender plans to create a seperate 126.96.36.199 with included check for "OKOK" in flash.
This should be the future way of installing a new OS to the HDD of the LS.
this way of installing new firmwares will be a huge breaktrough as it is far easier and more failsave than the old way with the original firmware updater. if anything goes wrong it won`t be a problem to recover....no semi-bricked Linkstations anymore...
with the telnet + ftp enabled EM-Mode, upgrading to a new OS will work like this:
1) the user has to get into EM mode manually
either via UBoot (if he already uses it) or with the stock bootloader via avr_evtd (pressing longer than 20 seconds on the reset button).
wiki-instructions will cover that.
2) /dev/hda1 + /dev/hda3 need to be mounted
mount_disk (a short script) is already included in the current existing telnet + ftp enabled ramdisks..it mounts to /mnt/hda1 and /mnt/hda3
3) tmpimage.tgz needs to be transfered to /mnt/hda3 via ftp
4) everything on /mnt/hda1 needs to be wiped
only if there is a boot-folder it should be left there (for UBoot-users running a custom kernel from the hdd)
5) untar /mnt/hda3/tmpimage.tgz to /mnt/hda1
6) get out of EM mode.
manually via executing write_ok (on stock bootloader boxes) or with UBoot simply by rebooting to the HDD.
Status: waite from kurobox.com pointed out that he already has coded an automatic installer for the kuroboxes. it is python based...so it is also platform independent. mindbender tested the base python script and his Linkstation was found. as the current telnet + ftp-enabled flash-images have the same functionallity (except included fdisk + mount-script for /dev/hda1 + /dev/hda3) it will work on the Linkstations also. good stuff because it already is coded. there might be some minor changes needed (for example the linkstation firmimg.bins do not request for a password) but they can be done in the short run.
We should create an easy but failsave installer.
i mean...as linuxnotincluded already wrote this can be a bashscript...maybe like andre`s webinstaller. but there is one difference. flashing UBoot can get you in serious troubles if something fails....we have to make sure that we use checksums and some checks so there is no chance that a broken u-boot.bin (internet can be very unreliable!) or the wrong uboot-image (LS1 / HG !) are flashed to the flash.
the script should check for:
1) which kernel the box runs
(with 2.6 writing to the flash is currently not possible...so it should NOT be allowed with it)
2) which box it is
(stock kernel makes it partly easy; LS1 -> 2.4.17, HG 2.4.20..... LS2 -> 2.4.20 -> warning! stop!)
3) if the box is not running the stock kernel...
(188.8.131.52 for example) then there needs to be another check somehow....but i suppose there won`t be many out there...this is only possible if you use 184.108.40.206 via loader.o for some reason..2.6 is better
in my opinion it should ONLY allow installation from the (future) stock kernel! thats the only way to make sure that it will work.
any other thoughts are highly appreciated as this can cause complications....we have to be very careful as all guys who later use this installer have to TRUST us...if a box gets bricked then it is our fault.