Cyril Plisko wrote: >On 1/10/06, Sven Luther <sl at bplan-gmbh.de> wrote: > > > >>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 >> >> >> >> > >Sven, Martin, > >I want to address your concerns wrt OBP/OF. First of all I didn't call >to kill OBP/OF - that would be crazy thing to do. The value of the firmware >of that class is hard to overestimate. >What I was trying to emphasize is that besides single task of booting kernel >GRUB does a lot of things. They may be not so visible at the first glance, >however they are important. For example boot menu. As much as it looks >simple and minor it is of huge importance for > >1. Having an *easy* accessible alternative boot_archive (FailSafe mode) >2. Having many boot environments created with Live Upgrade. > >You may argue that these things are solvable (and they indeed are) by >some other means. But do not forget that if the entire interface to the boot >magic is by editing the single file (menu.lst/grub.cnf) then all the supported >platform (SPARC, x86, PPC. etc) became significantly easy to develop >[this things] on and QA and support, etc. >That is just an example of how the choice of boot mechanism can affect >other distant projects in Solaris. > >Now as for our current plan - the method you've just described gets us >to the boot attempt nearly instantly, which is magnificent. Frankly speaking >I wasn't aware until yesterday that you can load two files via tftp. >(It appears quite obvious to me now - but it takes someone to tell you >that first to realize it :) ) > >And I think I didn't emphasized in my previous mail that I was thinking >on the long term options. Right now we have practically one choice - >to do dual file load. > >Wait a sec - it just appeared to me that we are essentially talking about >virtually same thing - the only difference is whether external "bells and >whistles" (GRUB2) are used or not. > >... I just looked again at your mail and it seems like I am just repeating >after you. So why does it feels like arguing ??? ;) No. No arguing here. > >I think we'll just go with your method for now, get it booting and then >when we'll be sitting under the palm and drinking beer (one day I hope!) >we'll continue this topic. > >How is that for a plan ? > >P.S. Plenty of palms here and pretty hot too in a couple of months. > >-- >Regards, > Cyril > >
Cool... So I think the task focus and the real effort move onto multiboot or in reality the PPC variant of it and the boot process of the kernel, everything up until the VM/HAT init (Guy is working on that). Can we get a higher level assesment of the scope of that effort or specifically what attributes our new multiboot will need. For example what BOP calls are made from it, if any? Removal of the x86 BIOS call. I know Jan will get back to us with some other boot details but what else do we need to get answers on with this. Thanks
