Re: [9fans] Replacing 9load

[jmk@plan9.bell-labs.com]

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 </usr/jmk/k/pc64/kpc64 -a arg -fg foo bar>
mod 0x116000 0x116082 </usr/jmk/tmp/plan9.ini>
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 <GNU GRUB 0.96>
pmem0: 0x0000000000116082 0x00000000fbed9f7e 0x00000000fbff0000
pmem1: 0x0000000100000000 0x0000000080000000 0x0000000180000000
cr3 = 0x108000
reset

--jim