Tarl Neustaedter wrote:
In Sun's openboot, that's in go.fth (lives in obp/ach/sun4u/go.fth), and it does an execute-buffer on whatever's in load-base, followed by initializing the registers, trap-table and stack for the client interface. Specifically (I can include this because it has been open-sourced):
(lots cut)
With Stefan's hack in place, the Fcode finishes execution but it doesn't seem to load anything from the ramdisk. AFAICT at the moment the contents of /platform/sun4u/boot_archive is being loaded at 0x51000000, and a new node /ramdisk-root is being created with methods that seem to point into this memory space.
What I can't see at the moment is how the device switch takes place, i.e. when /ramdisk-root is used to load the kernel from the image. There are several checks for nested? in do-boot and friends which make me think that something in init-program should be calling do-boot again once the ramdisk switch has taken place...
ATB,
Mark.