I've released a new version of APEX. This one properly loads the kernel and ramdisk from NOR flash and passes control to the kernel. In combination with the debian package, it will function as a second stage boot loader.
The .deb puts the loader in boot/apex.flash. The file needs to be swizzled before being written to flash. While I could add that, I'm not sure that that would be the best way to handle it. On the one hand, the nslu2 loader will always need to be swizzled. On the other hand, the swizzling can be done easily as the flash image is being prepared. The APEX environment resides at nor:0x7fc000+15k, near the end of the FIS partition table block. There is a README that explains the format used to write to the environment in NV storage. If all you are doing is writing new variables (not appending to an existing environment), I think we can write a simple script to automate composing the data. Heck, devio is probably all we need. I've verified that it boots the debian installer image and I've separately verified that RedBoot will execute APEX when it is written to the start of the partition where the kernel is currently stored. I haven't written a new flash image with the kernel and ramdisk moved and APEX in place. The loader presently copies the partition labeled 'kernel' to the place in SDRAM where the kernel goes, and the partition labeled 'ramdisk' to the place in SDRAM where the ramdisk goes. These names can be changed either in the source, or by writing a startup variable to the environment. It also assumes that these partitions have SERCOMM headers on them. I believe we don't need to include these headers if we don't want to as there shouldn't be a backward compatibility issue. Cheers. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
