Hello,

I'm currently trying to get my PegII to boot with an initrd (from a flash memory IDE disk). Since I don't know how to get that to work with OF, I wanted to embed the initrd into the kernel which gets called with "root=/dev/ram0".

After having some problems (s. below) I even used mkinitrd to get a "100% working initrd". But the only difference comparing the error message with the one below was the size and the addresses of the initrd.

After displaying this message the kernel stops and the computer is rebooted after a while (180s?). When I compile a framebuffer into the kernel it shows the pinguin logo instead but no text.

So, I have several questions:

1. What's wrong here? (What more informations would you need?)
2. Is there some HOWTO-initrd-ON-PEGASOS-FOR-DUMMIES?
3. Could someone please point me to some document where I could learn a little bit more about the initial things done by OF and the kernel so that I could someday really understand where exactly why which part is loaded and unzipped to? I want to learn

Thank you very much
M

PS:

1. To load kernels above a certain size you need to set load-base to a higher value that it is currently.

In the firmware memory map basically there is the zero page, some free memory, openfirmware stack/heap space (for claim) and at 4MB or so there is the firmware image. After that is empty memory. This is so a system with less than 32MB of RAM can boot.

| 0 | free space (load-base is set to here) | stack | firmware | memory-above-6MB-or-so-is-free |

What happens with the standard load-base is that a kernel which decompresses larger than 4MB is loaded into high memory above the firmware, and decompresses over the top of the low portion of memory (0-4MB and higher) which effectively decompresses Linux over the top of the firmware. Since it's still in the CHRP boot process the firmware is still active.. you get the picture.

The fix is to set load-base so that it loads kernels and decompresses not into the space below the firmware (marked free space) but into the higher memory space. setenv load-base 0x1000000 sets it to the 32MB point which should work great.

That's a very simple, dumb, and probably quite wrong in detail explanation of it. Sven would have a better time documenting this than I would. And yes I do think we need to document this and have it available as a tutorial on our website. I will nag

--
Matt Sealey
Genesi, Manager, Developer Relations

After the "returning 0x00010000 from prom_init" the frame buffer is initialized and output is redirected by the kernel from open firmware calls to the kernel frame buffer. If it stops at this point it usually means you forgot to enable the kernel frame buffer console and/or compile the appropriate frame buffer driver into the kernel (not as a module).

Most likely the kernel does not stop but rather continues without outputting what it is doing, then failing further down the road causing it to go into the "Rebooting in 180s" failure mode.

Hi you two,

sorry for beeing quite so long. Diploma thesis... :-/

Thank you very much for explaining the memory structure. Very helpful!

The framebuffer wasn't the problem. Everything is sooo easy when it works... I think I will post a very small HOWTO within the next weeks if anybody wants to build their first initrd for Pegasos and also forgets such stupid things like /dev/console on the ramdisk itself *bang-head-on-table*...

M