[ARMedslack] A few questions on kirkwood initrd

[Tyler T]

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.