On Tue, Jan 10, 2006 at 10:51:58AM +0200, Cyril Plisko wrote: > Tom, > > thanks for summarizing the meeting. > > I have to say that my line was pretty bad and I was loosing > the conversation from time to time. The whole Xen part is > a surprise for me for example :) > Ok, here is my thoughts > > 1. I see a big value in having Solaris booted the very same way > across all the supported architectures. GRUB2 is a great promise > in this respect. OTOH, I am not sure how feasible it is for, let's say, > embedded system. So having a functional TFTP based fallback > mechanism is important too. > 2. As much as it tempting to just offload the task to OF I feel > somewhat uneasy with OF doing all the work - it means we are > nailing some dependencies on specific OF implementation and that > is not good if you consider different PowerPC systems out there. > Genesi is not the only PPC vendor [However by far most cooperative :)] > > So my options would be > 1. Fully fledged GRUB2 implementation if possible. > 2. TFTP if 1. is not possible.
Well, i am not sure if i am missing something, but i think the unix + boot_archive situation is not all that different from what i see in the linux world, where we have the kernel and a ramdisk, which contains a (minimal) root filesystem as well as a kernel modules. So, basically, the important thing is being able to load both the unix file and the boot_archive file into main memory, somehow pass the address of the boot_archive to the unix elf file, and then boot it. How you do this is largely unrelevant, it can be the OF loading both, passing the start and size of the ramdisk as argument to the unix file, and booting it, it can be grub2, even yaboot will probably work if we simply use the same convention as linux uses (r5 for the OBP/OF/prom pointer, r3/r4 for the start and size of the boot_archive ramdisk, this is even in the CHRP spec i believe, so it will work as is on pegasos, apple hardware, ibm hardware, whoever). I mean, grub2 is mostly there for the nice boot menu, and as a band-aid for those architectures whose BIOS is so underwhelmed they can't do it themselves, but it should not really be needed for more mature implementations like sparc's or powerpc's OPB/OF. Notice that this doesn't mean the same boot method will not work for all possible targets, altough i guess the way the boot_archive start/size is passed is processor specific anyway, since it is dependent on the register affectation startegy. On the pegasos machine, the firmware resides between 16MB and 24MB, if i am not wrong, so provided your kernel is not oversized, and compiled to link at 8MB for example, you could, at the of prompt : ok setenv load-base 0x02000000 ok load geth boot_archive ok setenv load-base 0x00800000 ok boot geth unix ba_start=0x02000000 ba_size=<your_size> And then have your unix kernel parse the command line arguments, which are passed in chosen/bootargs, and interpret those the ba_start and ba_size arguments to find back the boot_archive. Alternatively, you can use the registers, and write ba_start and ba_size to r3/r4 with some adequate forth magic, and then boot the unix kernel without arguments. You could even wrap the above in some nice little forth script you could then tftp boot, or put on some cd, or whatever, and furthermore if i am not wrong, you could mostly experiment and test the above method or a variant thereof on sparc/OBP. I think it is a failing of those of you being too much involved with the solaris/x86 port to put so much value into grub and what it can or not do, since really the functionality you really need from it is rather minimal, and nothing a good OBP/OF implementation cannot do. Friendly, Sven Luther
