Boot Process Analysed
since it looks as if I have damaged something on 2 machines (they still boot the new kernel from SD card when pressing Fn-Ctrl-Shift - but nothing else works), I tried to understand the boot process better. Unfortuantely, information is a little distributed. So I have tried to collect things in this e-mail.
With this information we may be able to write and install our own U- Boot, our own recovery menus etc.
0. NAND fash partitions
0x00000000-0x00100000 : "bootloader partition" -- ok, this is u-boot 0x00100000-0x00400000 : "kernel partition" -- ok, this is a kernel 0x00400000-0x00500000 : "mac partition" -- this holds the MAC address(es) 0x00500000-0x00a00000 : "mini rootfs partition" 0x00a00000-0x40000000 : "yaffs2 rootfs partition"
cat /proc/mtd will list all partitions (incl. one for the second 1G flash)
See here how these partitions are mapped to /dev/mtd# and /dev/mtdblock#
1. U-Boot (1.1.6)
U-Boot is stored in partition "bootloader partition" (/dev/mtd0)
The default boot args (and usually invisible console output) are described here: http://projects.kwaak.net/twiki/bin/view/Epc700/UbootStuff
Source code: http://download.goldelico.com/letux-400/files/PC701-LX-u-boot-1.1.6.tar.bz2
The U-Boot has some patches in common/main.c and common/cmd_bootm.c to detect several key combinations during boot. Depending on that, different actions are taken (normal boot, flash uimage, flash minifs etc.)
There appear to be different versions of U-Boot installed in factory since the recovery procedures and secret key combinations described are not exactly the same and don't exactly match the U-Boot sources.
And, older machines don't have tftp built in, but newer machines (1.1.6 U-Boot) appear as if they can load/boot/flash through tftp by additional key press combinations.
U-Boot can read flash images only from a SD card (not from USB memory keys).
Normal boot sequence boots a kernel from nandflash (i.e. the "kernel partition")
If that fails, the so called minifs is booted (by loading kernel & minifs to RAM and doing a bootm).
NOTE: if U-Boot itself is damaged, the device is bricked and probably needs reflashing through JTAG.
This appears a mini-linux system that operates as a second stage bootloader or at least as a maintainance tool. It lives in the /dev/ mtd3 partition.
It is not clear if it contains its own kernel or shares the kernel with the real system.
Download: http://www.trendtac.nl/documents/Recovery_EPC700.zip (this includes also a certain version of a recovery.img for 4.)
I guess (since I could neither find code in U-Boot nor the Kernel - and one can't overwrite a rootfs while it is being used) the function of this minifs is to show the penguin picture, and check for F3 to flash a root-filesystem. And, boot the final system if F3 is not pressed.
To get this minifs into flash through U-Boot, one has to press fn +leftshift+rightshift and have minifs.img (this is a .jffs2) on a FAT- SD card (does not work on my broken device - or the kernel in flash does not work any more).
We have started to write our own minifs: http://projects.goldelico.com/p/l400-rootfs/source/tree/master/config/root/recover http://projects.goldelico.com/p/l400-rootfs/source/tree/master/config/root/mkminifs
This is the real kernel (or is it shared with 2?).
It is stored in NAND flash in partition "kernel partition" (/dev/mtd1)
To flash a kernel, place a uImage (file search is not case sensitive) on the FAT-SD and press Fn+LeftShift+F1 and power on.
If the kernel is not shared with 2. it could also be written by the recovery procedure.
There appears to be a download of a kernel at http://www.elonex.com/support/products/ONEt/mbrrecovery.shtm
4. root filesystem
This can be flashed by placing a .tbz archive (with extension renamed to .img) on the root of a SD card or USB stick and press F3 during boot. This will open a recovery menu where one can choose where to load the rootfs from. The recovery menu is not provided by U.Boot but by the minifs.
Finally, there is a newer .rec format which appears to replace the .img format - but nothing specific is known (a yaffs raw image?). This is used for the recovery file of the Letux 400. Since U-Boot can't handle complex file formats I think it is responsibility of 2. to handle this.