Re: bootloader & head.S weirdness (patch)

Re: bootloader & head.S weirdness (patch)

[Benjamin Herrenschmidt]

Ok, I posted the very first version of this bootloader. I'd appreciate
any comment, suggestion, etc... It's called "yaboot" and is on my test page

<http://calvaweb.calvacom.fr/bh40/test.html>

It's targeted for newworld machines only (machines with a working OF that
can load ELF binaries). It has a quik-like interface.

The config file must be named "yaboot.conf and located next to yaboot
itself, currently I put both on the first HFS volume of my disk, this
way, I can launch it with the simple OF command "boot hd:yaboot".

(Note that it's better to type boot hd:p,yaboot where "p" is the
partition number. If you don't do so, the bootloader will have to look at
all partitions it can read on device "hd" 
until it finds yaboot.conf since I didn't manage to find out the
partition number I was loaded from).

It supports loading files (both kernel and initrd) from any supported OF
disklabel/filesystem, and is had built-in ext2 support (only on Apple
partition maps for now). I'll add a built-in ISO (OF one doesn't seem to
work correctly) soon and also support for ext2 on PC disklabel partition
maps when I find some time>
Note also that currently, loading files from ext2 can be very slow, this
will be fixed in a future version. (The first time I tested, I thought it
was crashed, there is no spinning thing nor progress bar yet).

The kernel is loaded at 0x1000000 (16Mb). Currently, I've not been able
to boot successfully unless I apply the patch I posted earlier (that
disables the MMU after prom_init). I'll probably add an option for
specifying the load base on a per-kernel image basis. The bootloader
itself uses the range 0x200000->0x400000 (2Mb->4Mb) for now.

The syntax for a kernel image path (or initrd path) is a normal OF
syntax, for example:

hd:8,/boot/vmlinux

means the file "/boot/vmlinux" on partition 8 of device "hd". (hd is an
alias to the internal IDE disk of most macs). The parsing is a little bit
different than what quik used to do, so be careful.

I'll add a README and a sample config file with the next version.

Ultimately, this will allow bootable CDs for Macs (with the help of
miBoot for oldworld machines), and with a bit more GUI and the help of an
installer, we'll be, I hope, the primary bootloader for newworld Macs. I
plan to slowly abandon BootX support for those machines since it involves
too many hacks to work around various issues related to getting rid of
MacOS and problems with devices MacOS put in a non-reset state).


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bootloader & head.S weirdness (patch)

[Cort Dougan]

Have you tried the rs6000 quik on the g3's?  I've heard people have had
success with the modifications I made but haven't been able to get ahold of
a g3 for long-term tests.  I'd like to combine the two if we could.

} Ok, I posted the very first version of this bootloader. I'd appreciate
} any comment, suggestion, etc... It's called "yaboot" and is on my test page
} 
} <http://calvaweb.calvacom.fr/bh40/test.html>
} 
} It's targeted for newworld machines only (machines with a working OF that
} can load ELF binaries). It has a quik-like interface.

I think Yellowdog already has their cd bootable from macs.

} Ultimately, this will allow bootable CDs for Macs (with the help of
} miBoot for oldworld machines), and with a bit more GUI and the help of an
} installer, we'll be, I hope, the primary bootloader for newworld Macs. I
} plan to slowly abandon BootX support for those machines since it involves
} too many hacks to work around various issues related to getting rid of
} MacOS and problems with devices MacOS put in a non-reset state).

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bootloader & head.S weirdness (patch)

[Benjamin Herrenschmidt]

On Tue, Nov 23, 1999, Cort Dougan <cort@fsmlabs.com> wrote:

>Have you tried the rs6000 quik on the g3's?  I've heard people have had
>success with the modifications I made but haven't been able to get ahold of
>a g3 for long-term tests.  I'd like to combine the two if we could.

rs6000 quik is quik2.0 in ELF package ? I think I tried it but i failed
finding the boot device. I'll look at it again tomorrow.

When I tried to do what quik does in my bootloader (memmove'ing the
kernel to 0 before booting it), I ended up in a default catch. On the new
Macs, OF doesn't seem to map all the memory by default and won't let you
claim low-memory vectors so easily. I managed to map them without doing a
claim, but I had then problems instanciating RTAS from the kernel then.
Also, quik lacks support for the initrd. Since BootX doesn't work on the
new iMac DV (and I may not find a fix soon, it's a weird problem with
MacOS shutdown), there is need for an OF bootloader with initrd support
for installing on those machines.
(kernel with piggyback initrd may work too, but I heard of several people
who failed building them, so I added an option to load it from a separate
file).

Basically, my bootloader contains bits of quik, bits of poof, and a
simple abstract mecanism for ading file systems to it (currently, only
ext2 is built-in, iso will come soon and I'm thinking about UFS for
netbsd for example). Once it works, I plan to make it graphical with some
way to "detect" the possible boot devices (I already have an almost
working algorithm for that).

>I think Yellowdog already has their cd bootable from macs.

I discussed with them about this and they didn't manage to make this
work. The mini-ISO filesystem I'll add to yaboot comes from them. I'll do
more tests with CDs later, when we have a definitive solution to those
kenrel entry problems.

>} Ultimately, this will allow bootable CDs for Macs (with the help of
>} miBoot for oldworld machines), and with a bit more GUI and the help of an
>} installer, we'll be, I hope, the primary bootloader for newworld Macs. I
>} plan to slowly abandon BootX support for those machines since it involves
>} too many hacks to work around various issues related to getting rid of
>} MacOS and problems with devices MacOS put in a non-reset state).

Did you had a chance to test my new head.S/prom.c patch ? 


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

bootable CD's (Re: bootloader & head.S weirdness (patch))

[Hollis R Blanchard]

On Tue, 23 Nov 1999, Cort Dougan wrote:
> 
> } Ultimately, this will allow bootable CDs for Macs (with the help of
> } miBoot for oldworld machines), and with a bit more GUI and the help of an
> } installer, we'll be, I hope, the primary bootloader for newworld Macs. I
> } plan to slowly abandon BootX support for those machines since it involves
> } too many hacks to work around various issues related to getting rid of
> } MacOS and problems with devices MacOS put in a non-reset state).
> 
> I think Yellowdog already has their cd bootable from macs.

That's TurboLinux. And they use miBoot.

-Hollis


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bootable CD's (Re: bootloader & head.S weirdness (patch))

[Benjamin Herrenschmidt]

On Tue, Nov 23, 1999, Hollis R Blanchard <hollis+@andrew.cmu.edu> wrote:

>That's TurboLinux. And they use miBoot.

Yes, but miBoot is a BootX derivative and works only on old-world macs
(with MacOS ROM in real ROM). 


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bootable CD's (Re: bootloader & head.S weirdness (patch))

[Dan Burcaw]

Hollis,

> That's TurboLinux. And they use miBoot.

We have new world rom bootable cds in-house and have for some time.
Not using miBoot, but our own mods to quik. Note: there were issues with
the bootable cds we tried and that info has been passed to Ben in hopes
that the new bootloader solves them.

Dan

Terra Soft Solutions, Inc.
   Yellow Dog Linux
   "The Ultimate Companion for a Dedicated Server"
   http://www.yellowdoglinux.com/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

bootloader & head.S weirdness (patch)

[Benjamin Herrenschmidt]

I re-read myself and I think I was not very clear... So below is the
patch I made that makes my bootloader appear to work in all cases.

Basically, the idea is that instead of doing all sorts of weird things
with MMU potentially enabled, once we exit from prom_init, I just shut
the MMU down, clear bats (I beleive this version of clear_bats will work
on 601), and then only try to move things down to 0.
The only requirement for this code to work is that the place the kernel
is loaded be mapped 1:1 (which can be acheived by the bootloader).

My OF bootloader loads the kernel at 0x1000000 (16Mb), but I beleive I
can load it lower in memory.

I'm also trying to get initrd to work but I didn't fully understand the
pointer calculations on r3/r4 done in identify_machine. It looks like
loading the kernel at the above address and initrd 1Mb after the kernel
(so I leave some room for prom_init to expand klimit) doesn't work (the
ramdisk presence is not recognized). Should I pass a pointer in r3 which
is already relative to KERNELBASE ? (basically, should I pass
phys_initrd_address or phys_initrd_address+KERNELBASE ?) or should I just
remove those pointer calculations from setup.c and assume r3 contains the
real physical address of initrd ?

--- paulus_stable/arch/ppc/kernel/head.S	Sat Oct 16 01:48:04 1999
+++ linux.ibook/arch/ppc/kernel/head.S	Mon Nov 22 12:36:50 1999
@@ -249,8 +249,12 @@
 	bl	prom_init
 	.globl	__secondary_start
 __secondary_start:
-/*
- * Use the first pair of BAT registers to map the 1st 16MB
+/* Switch MMU off, clear BATs and flush TLB */
+ 	bl	mmu_off
+	bl	clear_bats
+	bl	flush_tlbs
+
+/* Use the first pair of BAT registers to map the 1st 16MB
  * of RAM to KERNELBASE.  From this point on we can't safely
  * call OF any more.
  */
@@ -289,14 +293,6 @@
 	clrldi	r16,r16,63
 	mtsdr1	r16
 #else /* CONFIG_PPC64 */
-	/*
-	 * If the MMU is off clear the bats.  See clear_bat() -- Cort
-	 */
-	mfmsr	r20
-	andi.	r20,r20,MSR_DR
-	bne	100f
-	bl	clear_bats
-100:
 	/* 
 	 * allow secondary cpus to get at all of ram in early bootup
 	 * since their init_task may be up there -- Cort
@@ -1673,6 +1669,16 @@
 	blr
 #endif /* CONFIG_8xx */
 
+mmu_off:
+ 	mflr	r4
+	mfmsr	r3
+	ori	r3,r3,MSR_DR|MSR_IR
+	xori	r3,r3,MSR_DR|MSR_IR
+	mtspr	SRR0,r4
+	mtspr	SRR1,r3
+	sync
+	rfi
+
 /*
  * This code is jumped to from the startup code to copy
  * the kernel image to physical address 0.
@@ -1682,8 +1688,10 @@
 	addi	r9,r9,0x6f58		/* translate source addr */
 	cmpw	r31,r9			/* (we have to on chrp) */
 	beq	7f
+#if 0 // still needed ? breaks on me if I don't disable this
 	rlwinm	r4,r4,0,8,31		/* translate source address */
 	add	r4,r4,r3		/* to region mapped with BATs */
+#endif	
 7:	addis	r9,r26,klimit@ha	/* fetch klimit */
 	lwz	r25,klimit@l(r9)
 	addis	r25,r25,-KERNELBASE@h
@@ -2755,25 +2763,36 @@
  */
 clear_bats:
 	li	r20,0
-	
+	mfspr	r9,PVR
+	rlwinm	r9,r9,16,16,31		/* r9 = 1 for 601, 4 for 604 */
+	cmpwi	r9, 1
+	beq	1f
+
 	mtspr	DBAT0U,r20
-	mtspr	DBAT0L,r20
-	mtspr	IBAT0U,r20
-	mtspr	IBAT0L,r20
-	
+	mtspr	DBAT0L,r20	
 	mtspr	DBAT1U,r20
 	mtspr	DBAT1L,r20
+	mtspr	DBAT2U,r20
+	mtspr	DBAT2L,r20	
+	mtspr	DBAT3U,r20
+	mtspr	DBAT3L,r20
+1:	
+	mtspr	IBAT0U,r20
+	mtspr	IBAT0L,r20
 	mtspr	IBAT1U,r20
 	mtspr	IBAT1L,r20
-	
-	mtspr	DBAT2U,r20
-	mtspr	DBAT2L,r20
 	mtspr	IBAT2U,r20
 	mtspr	IBAT2L,r20
-	
-	mtspr	DBAT3U,r20
-	mtspr	DBAT3L,r20
 	mtspr	IBAT3U,r20
 	mtspr	IBAT3L,r20
 
 	blr
+
+flush_tlbs:
+	lis	r20, 0x1000
+1:	addic.	r20, r20, -0x1000
+	tlbie	r20
+	blt	1b
+	sync
+	blr
+
	

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bootloader & head.S weirdness (patch)

[Benjamin Herrenschmidt]

On Mon, Nov 22, 1999, Benjamin Herrenschmidt <bh40@calva.net> wrote:

>I'm also trying to get initrd to work but I didn't fully understand the
>pointer calculations on r3/r4 done in identify_machine. It looks like
>loading the kernel at the above address and initrd 1Mb after the kernel
>(so I leave some room for prom_init to expand klimit) doesn't work (the
>ramdisk presence is not recognized). Should I pass a pointer in r3 which
>is already relative to KERNELBASE ? (basically, should I pass
>phys_initrd_address or phys_initrd_address+KERNELBASE ?) or should I just
>remove those pointer calculations from setup.c and assume r3 contains the
>real physical address of initrd ?

Ok, I have initrd working by changing the stuffs in setup.c to always
take r3 and r4 into account when they are both non-null and not
0xdeadbeef. I also had to pass the initrd_base + 0xc0000000 to the kernel
for it to work.

However, it works only when I load the kernel at 0x1000000 (16Mb). If I
load the kernel at 8Mb, then it fails mounting the ramdisk. The initrd
image is loaded just after the kernel (I leave a gap of 1Mb between the
kernel and the ramdisk). Of course, I use the kernel memory size, not
file size for the calculations.

I also know why loading the kernel below (4 or 6Mb) didn't work: RTAS is
instanciated at the fixed address 0x600000 (6Mb), which did override the
kernel image.

So now, I have the bootloader loaded at 0x200000, it's malloc pool at
0x300000, the kernel at 0x1000000, the ramdisk 1Mb after the kernel end,
and it works (provided that I apply the head.S patch I posted earlier). I
beleive all newworld machines have at least 32Mb of RAM, so this should
be fine for now, but I would still prefer to be able to "pack" things a
little bit better (and have an RTAS address calculated from the kernel
image size) since this bootloader may be usegful to other CHRP machines
with less memory.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bootloader & head.S weirdness (patch)

[Cort Dougan]

I applied the patch (with some changes necessary to get it into
2.2.14pre7).  It breaks pmac netboot during the jump from
__secondary_stat() to clear_bats().  There must be some I mappings we need
to preserve in order to get to non-pc relative code.  It's worth noting
that OF loads us and gives us mappings for 0xc000000 since that's where
we're linked at.  BootX and Quik don't do that so that's probably why they
work.  Netboot is really useful so I'd prefer to not break it (definitely
not in 2.2).  Any ideas for workarounds?

Chrp and prep netboot works fine.  Boot via quik on chrp works, too.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bootloader & head.S weirdness (patch)

[Benjamin Herrenschmidt]

On Mon, Nov 22, 1999, Cort Dougan <cort@fsmlabs.com> wrote:

>I applied the patch (with some changes necessary to get it into
>2.2.14pre7).  It breaks pmac netboot during the jump from
>__secondary_stat() to clear_bats(). 

You mean netbooting the kernel image directly from OF without going thru
a bootloader ? Or are you talking about the xcoff piggyback bootstrap ?

>There must be some I mappings we need
>to preserve in order to get to non-pc relative code.  It's worth noting
>that OF loads us and gives us mappings for 0xc000000 since that's where
>we're linked at. 

I never managed to get OF load the kernel image directly. How did you
acheive this result (OF setting up such a mapping ?). In this specific
case, it's always possible to ask OF about our physical address and use
it for the return address of mmu_off. It should be returned by prom_init
in r3. This would be cleaner anyway. I'll look into fixing that but I'd
like to know how you did this netboot stuff so I can reproduce it here.
(Could you send me your bootptab ?)

>BootX and Quik don't do that so that's probably why they
>work.  Netboot is really useful so I'd prefer to not break it (definitely
>not in 2.2).  Any ideas for workarounds?

Yes, as I wrote before, OF can tell us the real physical address and we
can return it from prom_init so that mmu_off does the right thing.

>Chrp and prep netboot works fine.  Boot via quik on chrp works, too.

Great.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bootloader & head.S weirdness (patch)

[Benjamin Herrenschmidt]

On Mon, Nov 22, 1999, Cort Dougan <cort@fsmlabs.com> wrote:

>I applied the patch (with some changes necessary to get it into
>2.2.14pre7).  It breaks pmac netboot during the jump from
>__secondary_stat() to clear_bats().  There must be some I mappings we need
>to preserve in order to get to non-pc relative code.  It's worth noting
>that OF loads us and gives us mappings for 0xc000000 since that's where
>we're linked at.  BootX and Quik don't do that so that's probably why they
>work.  Netboot is really useful so I'd prefer to not break it (definitely
>not in 2.2).  Any ideas for workarounds?
>
>Chrp and prep netboot works fine.  Boot via quik on chrp works, too.

Ok. I gave a try at asking OF for the physical address. It seems to work
here on the iBook
but I couldn't do more tests today. I hope I didn't mess up the patch (my
real prom.c patch is much bigger, I extracted only what is interesting to
us now):


--- paulus_stable/arch/ppc/kernel/prom.c	Thu Sep  9 21:07:52 1999
+++ linux.ben/arch/ppc/kernel/prom.c	Tue Nov 23 13:21:56 1999
@@ -263,7 +263,7 @@
  * handling exceptions and the MMU hash table for us.
  */
 __init
-void
+unsigned long
 prom_init(int r3, int r4, prom_entry pp)
 {
 #ifdef CONFIG_SMP	
@@ -272,14 +272,18 @@
 	char type[16], *path;
 #endif	
 	unsigned long mem;
-	ihandle prom_rtas;
+	ihandle prom_rtas, prom_mmu;
 	unsigned long offset = reloc_offset();
 	int l;
 	char *p, *d;
+	unsigned long phys;
+	
+	/* Default */
+	phys = offset + KERNELBASE;
 	
 	/* check if we're apus, return if we are */
 	if ( r3 == 0x61707573 )
-		return;
+		return phys;
 
 	/* If we came here from BootX, clear the screen,
 	 * set up some pointers and return. */
@@ -375,12 +379,12 @@
 		prom_print(RELOC("booting...\n"));
 		flushscreen();
 #endif
-		return;
+		return phys;
 	}
 	
 	/* check if we're prep, return if we are */
 	if ( *(unsigned long *)(0) == 0xdeadc0de )
-		return;
+		return phys;
 
 	/* First get a handle for the stdout device */
 	RELOC(prom) = pp;
@@ -472,6 +476,29 @@
 			prom_print(RELOC(" done\n"));
 	}
 
+	if ((int) call_prom(RELOC("getprop"), 4, 1, RELOC(prom_chosen),
+			    RELOC("mmu"), &prom_mmu, sizeof(prom_mmu)) <= 0) {	
+		prom_print(RELOC(" no MMU found\n"));
+	} else {
+		int nargs;
+		struct prom_args prom_args;
+		nargs = 4;
+		prom_args.service = RELOC("call-method");
+		prom_args.nargs = nargs;
+		prom_args.nret = 4;
+		prom_args.args[0] = RELOC("translate");
+		prom_args.args[1] = prom_mmu;
+		prom_args.args[2] = (void *)(offset + KERNELBASE);
+		prom_args.args[3] = (void *)1;
+		RELOC(prom)(&prom_args);
+
+		/* We assume the phys. address size is 3 cells */
+		if (prom_args.args[nargs] != 0)
+			prom_print(RELOC(" (translate failed) "));
+		else
+			phys = (unsigned long)prom_args.args[nargs+3];
+	}
+
 #ifdef CONFIG_SMP
 	/*
 	 * With CHRP SMP we need to use the OF to start the other
@@ -548,6 +575,7 @@
 			prom_print(RELOC("...failed\n"));
 	}
 #endif	
+	return phys;
 }
 
--- paulus_stable/include/asm/prom.h	Thu Sep  9 05:26:50 1999
+++ linux.ben/include/asm/prom.h	Tue Nov 23 13:21:33 1999
@@ -63,7 +63,7 @@
 
 /* Prototypes */
 extern void abort(void);
-extern void prom_init(int, int, prom_entry);
+extern unsigned long prom_init(int, int, prom_entry);
 extern void prom_print(const char *msg);
 extern void relocate_nodes(void);
 extern void finish_device_tree(void);

--- paulus_stable/arch/ppc/kernel/head.S	Sat Oct 16 01:48:04 1999
+++ linux.ben/arch/ppc/kernel/head.S	Tue Nov 23 13:26:18 1999
@@ -249,8 +249,12 @@
 	bl	prom_init
 	.globl	__secondary_start
 __secondary_start:
-/*
- * Use the first pair of BAT registers to map the 1st 16MB
+/* Switch MMU off, clear BATs and flush TLB */
+ 	bl	mmu_off
+	bl	clear_bats
+	bl	flush_tlbs
+
+/* Use the first pair of BAT registers to map the 1st 16MB
  * of RAM to KERNELBASE.  From this point on we can't safely
  * call OF any more.
  */
@@ -289,14 +293,6 @@
 	clrldi	r16,r16,63
 	mtsdr1	r16
 #else /* CONFIG_PPC64 */
-	/*
-	 * If the MMU is off clear the bats.  See clear_bat() -- Cort
-	 */
-	mfmsr	r20
-	andi.	r20,r20,MSR_DR
-	bne	100f
-	bl	clear_bats
-100:
 	/* 
 	 * allow secondary cpus to get at all of ram in early bootup
 	 * since their init_task may be up there -- Cort
@@ -1673,6 +1669,19 @@
 	blr
 #endif /* CONFIG_8xx */
 
+mmu_off:
+ 	addi	r4, r3, __secondary_start - _start
+	mfmsr	r3
+	andi.	r0,r3,MSR_DR|MSR_IR		/* MMU enabled? */
+	beq	1f
+	ori	r3,r3,MSR_DR|MSR_IR
+	xori	r3,r3,MSR_DR|MSR_IR
+	mtspr	SRR0,r4
+	mtspr	SRR1,r3
+	sync
+	rfi
+1:	blr
+
 /*
  * This code is jumped to from the startup code to copy
  * the kernel image to physical address 0.
@@ -1682,8 +1691,10 @@
 	addi	r9,r9,0x6f58		/* translate source addr */
 	cmpw	r31,r9			/* (we have to on chrp) */
 	beq	7f
+#if 0 // still needed ? breaks on me if I don't disable this
 	rlwinm	r4,r4,0,8,31		/* translate source address */
 	add	r4,r4,r3		/* to region mapped with BATs */
+#endif	
 7:	addis	r9,r26,klimit@ha	/* fetch klimit */
 	lwz	r25,klimit@l(r9)
 	addis	r25,r25,-KERNELBASE@h
@@ -2755,25 +2766,36 @@
  */
 clear_bats:
 	li	r20,0
-	
+	mfspr	r9,PVR
+	rlwinm	r9,r9,16,16,31		/* r9 = 1 for 601, 4 for 604 */
+	cmpwi	r9, 1
+	beq	1f
+
 	mtspr	DBAT0U,r20
-	mtspr	DBAT0L,r20
-	mtspr	IBAT0U,r20
-	mtspr	IBAT0L,r20
-	
+	mtspr	DBAT0L,r20	
 	mtspr	DBAT1U,r20
 	mtspr	DBAT1L,r20
+	mtspr	DBAT2U,r20
+	mtspr	DBAT2L,r20	
+	mtspr	DBAT3U,r20
+	mtspr	DBAT3L,r20
+1:	
+	mtspr	IBAT0U,r20
+	mtspr	IBAT0L,r20
 	mtspr	IBAT1U,r20
 	mtspr	IBAT1L,r20
-	
-	mtspr	DBAT2U,r20
-	mtspr	DBAT2L,r20
 	mtspr	IBAT2U,r20
 	mtspr	IBAT2L,r20
-	
-	mtspr	DBAT3U,r20
-	mtspr	DBAT3L,r20
 	mtspr	IBAT3U,r20
 	mtspr	IBAT3L,r20
 
 	blr
+
+flush_tlbs:
+	lis	r20, 0x1000
+1:	addic.	r20, r20, -0x1000
+	tlbie	r20
+	blt	1b
+	sync
+	blr
+	
\ No newline at end of file


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bootloader & head.S weirdness (patch)

[Cort Dougan]

I'll check this patch with the latest 2.2 to see how it goes.  Would using
the bootinfo structure we talked about a few weeks ago help?  I'd like to
unify things a bit with it but I'm not sure how many problems it would
solve and how many it could cause.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bootloader & head.S weirdness (patch)

[Benjamin Herrenschmidt]

On Mon, Nov 22, 1999, Cort Dougan <cort@fsmlabs.com> wrote:

>I'll check this patch with the latest 2.2 to see how it goes.  Would using
>the bootinfo structure we talked about a few weeks ago help?  I'd like to
>unify things a bit with it but I'm not sure how many problems it would
>solve and how many it could cause.

I'd really like to see this happen. There is really an urgent need to
cleanup the mess with initrd and the way the command line is passed to
the kernel too and this would get rid of those.

There is one idea suggested to me by Gabriel Paubert which would be worth
considering:

Define some kind of bootx-like bootinfo structure (will all addresses
relative to the beginning of the structure) and move out of the kernel
_all_ those head.S hacks AND all the prom_init code (reading the OF tree,
initing the display, instanciating RTAS, ...).

All this would be done from a head-appended bootloader which would built
a device tree when OF is available, and then enter the kernel with a
unified entry point based on a structure, known mappings.

I don't know if it's worth doing that _now_ (it involves almost breaking
everything), but I like the idea of cleaning all this up.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bootloader & head.S weirdness (patch)

[Cort Dougan]

Check out include/asm/machdep.h for the minimal bootloader structure I have
there.  I have some early work with quik (for the rs6000, haven't tested on
pmac yet) to pass info via that structure.

} I'd really like to see this happen. There is really an urgent need to
} cleanup the mess with initrd and the way the command line is passed to
} the kernel too and this would get rid of those.
} 
} There is one idea suggested to me by Gabriel Paubert which would be worth
} considering:

That was the plan with the bootinfo in machdep.h in 2.3  Give it a look and
let me know how possible it would be modify bootx to use it.

} Define some kind of bootx-like bootinfo structure (will all addresses
} relative to the beginning of the structure) and move out of the kernel

Some of this is substantial work that we'd have to move into the
bootloader.  I'm not against it, but it'd be nice of all the bootloaders
did it the same way.

} _all_ those head.S hacks AND all the prom_init code (reading the OF tree,
} initing the display, instanciating RTAS, ...).
} 
} All this would be done from a head-appended bootloader which would built
} a device tree when OF is available, and then enter the kernel with a
} unified entry point based on a structure, known mappings.

It is 2.3, after all :)

} I don't know if it's worth doing that _now_ (it involves almost breaking
} everything), but I like the idea of cleaning all this up.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bootloader & head.S weirdness (patch)

[Geert Uytterhoeven]

On Tue, 23 Nov 1999, Cort Dougan wrote:
> That was the plan with the bootinfo in machdep.h in 2.3  Give it a look and
> let me know how possible it would be modify bootx to use it.
> 
> } Define some kind of bootx-like bootinfo structure (will all addresses
> } relative to the beginning of the structure) and move out of the kernel

Before you walk into the same traps as we did on the m68k many years ago
(zillions of kernel and bootloader versions that where incompatible with each
other), you may want to look at the bootinfo stuff in
include/asm-m68k/bootinfo.h.

The idea is to pass the bootinfo not as a fixed (inherently back/forewards
incompatible) struct, but as a concatenation of records. Each record contains
a tag ID, a size, and data:

struct bi_record {
    unsigned short tag;                 /* tag ID */
    unsigned short size;                /* size of record (in bytes) */
    unsigned long data[0];              /* data */
};

The parsing of the bootinfo is done in m68k_parse_bootinfo() in
arch/m68k/kernel/setup.c. If you add new fields in the booter, older kernels
still work fine because they just skip bi_records with unknown tag IDs.

Gr{oetje,eeting}s,

P.S. As a sidenote: we did our job that well that we never had to change the
     bootinfo on Amiga later anyway, see the `2.0' bootinfo version (`1.x' was
     pre-bi_record) as a testimony :-)
--
Geert Uytterhoeven -- Linux/{m68k~Amiga,PPC~CHRP} -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bootloader & head.S weirdness (patch)

[Cort Dougan]

Do you keep the list around after the initialization?  We do something
similar with the prep residual data but after we grab what we want we free
the RAM.  

} The idea is to pass the bootinfo not as a fixed (inherently back/forewards
} incompatible) struct, but as a concatenation of records. Each record contains
} a tag ID, a size, and data:
} 
} struct bi_record {
}     unsigned short tag;                 /* tag ID */
}     unsigned short size;                /* size of record (in bytes) */
}     unsigned long data[0];              /* data */
} };
} 
} The parsing of the bootinfo is done in m68k_parse_bootinfo() in
} arch/m68k/kernel/setup.c. If you add new fields in the booter, older kernels
} still work fine because they just skip bi_records with unknown tag IDs.
} 
} Gr{oetje,eeting}s,
} 
} P.S. As a sidenote: we did our job that well that we never had to change the
}      bootinfo on Amiga later anyway, see the `2.0' bootinfo version (`1.x' was
}      pre-bi_record) as a testimony :-)
} --
} Geert Uytterhoeven -- Linux/{m68k~Amiga,PPC~CHRP} -- geert@linux-m68k.org
} 
} In personal conversations with technical people, I call myself a hacker. But
} when I'm talking to journalists I just say "programmer" or something like that.
} 							    -- Linus Torvalds

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bootloader & head.S weirdness (patch)

[Benjamin Herrenschmidt]

On Tue, Nov 23, 1999, Cort Dougan <cort@fsmlabs.com> wrote:

>Do you keep the list around after the initialization?  We do something
>similar with the prep residual data but after we grab what we want we free
>the RAM. 

As I just wrote to Cort, we already have something for that on PPC, it's
the device tree. Having a tagged data structure _and_ a device tree looks
to me like having twice the same things (humm .. almost).

If we remove all the prom_init stuff from the kernel, we can simplify
kernel entry by always entering the kernel with a known MMU state (let's
say OFF) and with one parameter: the offset from _start to the device
tree image.

Non-OF machines can easily build a very simple tree with the various
residual datas from the bootloader and Mac/CHRP machines can have the
kernel image appended to a bootloader that fills the device tree from OF
and adds whatever supplementary stuffs we need (initrd, cmd_line, ...) to
the tree in a given node.

There are two things not yet clear to me with this scheme:

 - We'll need to have RTAS instanciated at a fixed address choosen by the
bootloader. I don't think it's a problem if the bootloader puts it as
high as possible in memory, but it would have been better to have the
kernel have control on it. But we can live with this limitation

 - on SMP machines, the other CPUs must be started by OF code. That means
that the bootloader must also start them in an idle loop. I beleive the
code for the idle loop can be in the device tree too with all the infos
required by the kernel to take over.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bootloader & head.S weirdness (patch)

[Geert Uytterhoeven]

On Tue, 23 Nov 1999, Cort Dougan wrote:
> Do you keep the list around after the initialization?  We do something
> similar with the prep residual data but after we grab what we want we free
> the RAM.  
> 
> } The idea is to pass the bootinfo not as a fixed (inherently back/forewards
> } incompatible) struct, but as a concatenation of records. Each record contains
> } a tag ID, a size, and data:
> } 
> } struct bi_record {
> }     unsigned short tag;                 /* tag ID */
> }     unsigned short size;                /* size of record (in bytes) */
> }     unsigned long data[0];              /* data */
> } };

No we don't. The structure isn't that large, and the kernel is padded to a multiple
of the page size anyway (the structure is after the kernel in memory).

Gr{oetje,eeting}s,
P.S. How much Belgian Beer do I have to send you to convince you to put your
     comments _below_ the text you quote, like all other people do? ;-)
--
Geert Uytterhoeven -- Linux/{m68k~Amiga,PPC~CHRP} -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bootloader & head.S weirdness (patch)

[Cort Dougan]

} No we don't. The structure isn't that large, and the kernel is padded to a multiple
} of the page size anyway (the structure is after the kernel in memory).
} 
} Gr{oetje,eeting}s,
} P.S. How much Belgian Beer do I have to send you to convince you to put your
}      comments _below_ the text you quote, like all other people do? ;-)

If you send me Juliper (I think that was the one I had) just one will do :)

I'm putting some of those changes in for the m68k-style bootloader info
right now.  I'll have it in the main 2.3.x tree shortly.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bootloader & head.S weirdness (patch)

[Geert Uytterhoeven]

On Tue, 23 Nov 1999, Cort Dougan wrote:
> } No we don't. The structure isn't that large, and the kernel is padded to a multiple
> } of the page size anyway (the structure is after the kernel in memory).
> } 
> } Gr{oetje,eeting}s,
> } P.S. How much Belgian Beer do I have to send you to convince you to put your
> }      comments _below_ the text you quote, like all other people do? ;-)
> 
> If you send me Juliper (I think that was the one I had) just one will do :)

Jupiler (`Mannen weten waarom' / `Les hommes savent pourqoui' / `Real men know
why')...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven ----------------- Sony Suprastructure Center Europe (SUPC-E)
Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55
Phone +32-2-7248632 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/