From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <3fe35a493427068423f3a486de5d1bc4@plan9.bell-labs.com> Date: Mon, 5 Dec 2005 15:11:50 -0500 From: jmk@plan9.bell-labs.com To: 9fans@cse.psu.edu Subject: Re: [9fans] Replacing 9load In-Reply-To: <3e1162e60512051142i58a2fddeu3bcbfa23ac63d5ff@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: b8284312-ead0-11e9-9d60-3106f5b1d025 On Mon Dec 5 14:42:57 EST 2005, leimy2k@gmail.com wrote: > > My comments about grub still stand. It's great for booting > > Linux kernels, which it was designed for, and it is okay for > > chainloading to get to Plan 9. I still think Smart Boot Manager > > is far and away the best PC multi-OS booter out there. It looks > > at the partitions and says "here is what I found: pick one." > > No manual config. In grub you have to boot to Linux to tell it > > about a new Plan 9 partition. Grub is really a Linux loader > > disguised as a multiboot loader. In that situation it works great. > > Beyond that it's just a pain. > > Actually, it was meant for GNU Hurd as it loads microkernels and > modules containing drivers and other bits of a "system" into separate > address spaces. > > GRUB2 works on PPC platforms as well now for the same effect. [the > solution for L4 based systems was to build a monolithic "piggybacked" > image to achieve the multiboot effect] > 9load has been used on PPC platforms too. > I agree chainloader is a bit of a pain in the ass. Grub has > filesystem modules and ways to do things like set VESA modes before > you boot an OS [used with House for example... written in Haskell > using the GHC runtime as OS services, yes ethernet drivers written in > Haskell.] > When I tried using the 'set vesa mode' fields in the multiboot header it didn't work and I couldn't find anything in the source that did it. Maybe I didn't look hard enough (GNU GRUB version 0.96). > grub is also capable of adding netboot capabilities to old PCs that > didn't have the BIOS for it. I used to boot an old P2 with a grub > floppy to netboot OSes on it because it had no hard disk. > GRUB failed miserbly here too. The machine I was using had an Intel 82557 and GRUB didn't recognise the PCI device number. I added it. GRUB still wedges probing the network device more often than not. > Grub has a lot of value to me as a result for some of these projects. > I've not seen another loader come along that can provide me with that > level of configuration [besides perhaps OpenFirmware on my mac.... > even that needs Grub2 to do multiboot stuff though] > I am sure GRUB is useful to some people, but not to me (see below). Also, the Multiboot specification can't describe the conventional Plan 9 boot format, you either have to boot an ELF-format kernel or hack GRUB to do special things if it recognises the Plan 9 binary (just like it has to do for all the other O/S binaries). > > > > > > Finally, do not believe even for a moment that Plan 9 thinks > > that all the world's a 386. We have always had a couple other > > architectures running, and running well. That's still true today. > > On the other hand, if you're writing a pc kernel, you're going > > to have to do some pc-specific things. > > I just wish BIOS would die a quick painful death and we can move on to > something else. OpenFirmware would have been my preference but EFI > appears to be the way for PCs. > > > > > Russ > > > > ----- End forwarded message ----- > > > > If I can find the irc logs I'll post them for context, but I don't think > > any of us said anything very useful. > > > > uriel > > Some of you will have seen this already, but here is a note I sent to some interested parties early this year when I was initially booting the AMD64: if you are booting a 386 kernel then grub can do that already. add the -H5 flag to your load line in the kernel mkfile and make sure your l.s has the 'multiboot' label in it. you don't currently get any plan9.ini or config stuff, but that's easy to add (i have some of it in the amd64 test code). i currently use grub to boot the amd64 test code over the network. grub is on a floppy. i boot a small 386 bootstrap programme (kpc32) which loads at 0x100020 using 'kernel'). i then load the amd64 kernel at 0x110000 using 'kernel', but it has an entry point of 0x100020, so the 'boot' command starts executing the 386 bootstrap code which sets up page tables and long mode then jumps to 0x110000. i used grub because i thought it would save me time, but grub is just 9load's evil twin, it has all the same problems as 9load, e.g. quirky syntax, flakey drivers ported in and hacked from other systems, odd configuration files and so on. it regularly hangs while probing the etherdevice. here's booting plan9 code with grub: Found Intel EtherExpressPro100 at 0xbc00, ROM address 0x0000 Probing...[Intel EtherExpressPro100]Ethernet addr: 00:E0:81:2A:3C:A6 Address: 135.104.9.32 Netmask: 255.255.255.0 Server: 135.104.9.7 Gateway: 135.104.9.1 Address: 135.104.9.32 Netmask: 255.255.255.0 Server: 135.104.9.2 Gateway: 135.104.9.1 GNU GRUB version 0.96 (639K lower / 4127680K upper memory) [ Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists the possible completions of a device/filename. ] grub> root (nd) Filesystem type is tftp, using whole disk grub> kernel /usr/jmk/k/pc32/kpc32 [Multiboot-elf, <0x100020:0x378b:0x0>, <0x104000:0x21c:0x234>, shtab=0x10500 0, entry=0x100020] grub> kernel /usr/jmk/k/pc64/kpc64 -a arg -fg foo bar [Multiboot-elf, <0x110000:0x3774:0x0>, <0x114000:0x570:0x1520>, shtab=0x1160 00, entry=0x100020] grub> module /usr/jmk/tmp/plan9.ini [Multiboot-module @ 0x116000, 0x82 bytes] grub> boot Hello Squidboy 32 Hello Squidboy 64 1800MHz &ax = ffffffff8010fff0, ax = 0x2badb002, bx = 0x36c40 magic 0x2badb002 pmbi 0x36c40 flags 0x7ef cmdline mod 0x116000 0x116082 Memory 0x0000000000000000 0x000000000009FC00 (654336) reserved 0x000000000009FC00 0x00000000000A0000 (1024) reserved 0x00000000000E0000 0x0000000000100000 (131072) Memory 0x0000000000116082 0x00000000FBFF0000 (4226654078) ACPI Reclaim Memory 0x00000000FBFF0000 0x00000000FBFFF000 (61440) ACPI Non-Volatile-Sleeping Memory 0x00000000FBFFF000 0x00000000FC000000 (4096) reserved 0x00000000FF7C0000 0x0000000100000000 (8650752) space 0x00000000FC000000 0x00000000FF7C0000 (4277665792) Memory 0x0000000100000000 0x0000000180000000 (2147483648) bootloadername pmem0: 0x0000000000116082 0x00000000fbed9f7e 0x00000000fbff0000 pmem1: 0x0000000100000000 0x0000000080000000 0x0000000180000000 cr3 = 0x108000 reset --jim