Update: the 'mtd3' chained-bootloader that I'm using is from http://www.plugapps.com/index.php5?title=PlugApps:Pogoplug_Setboot so I examined the kernel it ships with using 'mkimage -l' and it's Load Address is the same as Armedslack's, 00008000. This works because upon closer examination, the stock u-Boot loads the second bootloader at 0xc00000, right near the end of the 128MB of RAM, so there's plenty of room for a kernel, initrd, and decompressed ramfs back at the beginning. Unfortunately I still can't get it to boot so there's probably some other minor setting somewhere that needs tweaked.
>>> > (I extracted initrd to the >>> > MMC card and booted it as my system has to little RAM to use initrd >>> > directly). >> >> That's clever. If I can't figure out the Load Address stuff, this >> should be a good alternative. >> > As there's actually no > initrd, it seems to be important to compile all the drivers needed to > boot into kernel binary. In my situation it applied at least to the file > system and MMC interface drivers. Since I couldn't get my kernel+initrd combo to boot, I tried this. I compiled a kernel with SCSI, USB, ext2, NIC, and netconsole built-in along with netconsole kernel parameters and put it on the USB stick with the extracted contents of the Armedslack installer initrd. The USB stick activity light flashes for quite a long time, much longer than would be required to just load the kernel, but unfortunately I get nothing on the netconsole so I must have done something else wrong. I don't think it's getting past the second u-Boot because eventually the thing reboots which I don't think would happen after the Armedslack kernel starts executing. I now have a TTL-serial adapter on it's way so I can at least see on the console what's not happy. _______________________________________________ ARMedslack mailing list ARMedslack@lists.armedslack.org http://lists.armedslack.org/mailman/listinfo/armedslack