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 184.108.40.206 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)
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: mindbender plans to create a java app which automates 2 - 5...he chose java because it is platformindependent. if someone knows a better way (language?) post your comments. help IS needed. maybe it is easier to automate all this with .NET and leave Linux/apple users with wiki instructions...installing manually works the same way as on the kuroboxes...it depends on the help mindbender gets.
How about a shell script and heredocs to perform steps 2-5? Java and .NET require more software installation and sound a bit heavy for what is needed. Python comes with as part of the devtools and I would choose that over shell, but that also requires the devtools to be installed. -hsum
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 ue 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...
(220.127.116.11 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 18.104.22.168 via loader.o for some reason..2.6 is better
in my opinion it should ONLY allow installation from the 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 that it is our fault.