Re: Please make K2 Linux bootable without PeeMON again

Re: Please make K2 Linux bootable without PeeMON again

[Michael Sokolov]

Tom Rini <trini@kernel.crashing.org> wrote:

> Right.  I think I confused you somewhere along the line.  I want the
> kernel to be told the bi_recs are <someplace>.  I just want to get what
> people think would be a good rule-of-thumb <someplace>.  I take it you
> belive 8mb and change is a good rule-of-thumb location, yes?

Yes.

Now the question is how to pass the pointer to bi_recs to the kernel. I propose
a physical address in R3, as this is the most obvious way and there is
precedent for it already (I even seem to recall that someone else other than me
is already doing this).

MS

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

Re: Please make K2 Linux bootable without PeeMON again

[Michael Sokolov]

Tom Rini <trini@kernel.crashing.org> wrote:

> Yes, but where is what I'm asking.

I don't understand this question.

> Right.  And what's a good place to put them?

I don't think there is one answer that will satisfy everyone. Each booter
should be able to put them where it wants and tell the kernel where that is.

Right now I put them in the memory belonging to my booter.

> Okay.  If I'm reading all of this your bi_recs end up in the middle of
> where you're run from, yes?

Yes, and that's the way I want it.

> This has the same problem that the wrapper
> does in that it's possible to overwrite these, if you're run in a bad
> spot.

What do you mean by "if you're run in a bad spot"? My code is statically linked
at 0x800000 and always runs there (this is all with translation disabled). I
assume 8 MB is more than enough for the kernel.

> No, I want to have the wrapper put the bi_recs there and suggest that
> other people who're doing bootloaders do likewise in 2.5, IF this makes
> sense as a good place to put them and they can't be overwriten by the
> kernel bss.

And why not instead give bootloader developers the freedom to put them
elsewhere if they want to?

> I've been thinking, and one of two things could happen, at least in the
> wrapper, we know mem size (Firmware, res data, magic).  Or assume
> there's at least XX megs of ram on the system (I _think_ 16mb is the
> 'normal' min, but of course we have lots of systems breaking that rule).
>
> What I'd like to see, and at least I think would be a good thing to
> figure out is a general 'safe' location to store these in.

Again, all this strikes me as unnecessary trouble. Just have the bootloader
tell the kernel where the bi_recs are! If you are concerned that your current
location for them could get overwritten by the kernel, just make your wrapper
do the same thing my booter does: store them at the wrapper's end symbol, not
the kernel's. Your wrapper runs at 0x800000 just like my booter, so I guess you
are not expecting the kernel image to exceed 8 MB, so I don't see the problem.

MS

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

Re: Please make K2 Linux bootable without PeeMON again

[Tom Rini]

On Tue, Nov 27, 2001 at 12:40:45PM -0800, Michael Sokolov wrote:
> Tom Rini <trini@kernel.crashing.org> wrote:
> > I've been thinking, and one of two things could happen, at least in the
> > wrapper, we know mem size (Firmware, res data, magic).  Or assume
> > there's at least XX megs of ram on the system (I _think_ 16mb is the
> > 'normal' min, but of course we have lots of systems breaking that rule).
> >
> > What I'd like to see, and at least I think would be a good thing to
> > figure out is a general 'safe' location to store these in.
>
> Again, all this strikes me as unnecessary trouble. Just have the bootloader
> tell the kernel where the bi_recs are!

Right.  I think I confused you somewhere along the line.  I want the
kernel to be told the bi_recs are <someplace>.  I just want to get what
people think would be a good rule-of-thumb <someplace>.  I take it you
belive 8mb and change is a good rule-of-thumb location, yes?

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

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

Re: Please make K2 Linux bootable without PeeMON again

[Michael Sokolov]

Tom Rini <trini@kernel.crashing.org> wrote:

> Maybe it's just me, but wouldn't you need to know the size to how much
> to shove into memory?

My booter doesn't shove the kernel into memory, if that's what you meant. It
expects the kernel to be there already prior to it being run. I.e., the user
first loads the kernel by whatever means s/he wants (that's why I call it
occult, I don't assume any particular mechanism, the user could use JTAG or
whatever to do it) and *then* runs my booter.

> Because it's only a slightly less magical location than the current one
> (in the wrapper, I don't know where yours puts it).

No, with my solution you don't need to know the kernel size, you just simply
point it at where you've put the bi_recs.

The point is, you broke what worked. I was able to run public Linux on my K2
prior to your change of 2001-11-19, I am not able to any more. You cannot break
code that people use. You must fix it. I have already offered one easy fix.

> Well, that's the fun part.  No one really like the current magic
> location, but no one's come up with a better one.

But why have any magic location at all? I have no problem with your zImage goo
putting bi_recs where it does (hell, I'll never use it anyway, so I don't care
what it does in general), just please don't make the kernel look in any fixed
location and let the booter tell it where it put them.

My booter, for example, doesn't use any magic locations. My booter is a plain
standalone C program built with the GNU toolchain, and I store the bi_recs in
my program's memory. You don't need to worry about what physical address it is,
as I set R3 to point to them when I start vmlinux.

You are welcome to look at my code:

cvs -d :pserver:anoncvs@ivan.Harhan.ORG:/fs3/IFCTF-cvs co ppc-linux-boot

> After reading the
> pmac/chrp stuff which shoves the initrd at the end of RAM (we _could_
> overwrite our initrds that we place right after the kernel, if we have a
> big kernel and low link addresss).  Not that i've tried it yet, it just
> poped out at me.

OK, so now you want to make the kernel look for stuff only at the end of RAM
and nowhere else, right? Then how is it going to know where the end of RAM is
if the memory size is one of the things communicated via bi_recs in the first
place? Isn't it easier to pass a pointer? Then you can make your wrapper/
whatever put them whereever, including the end of RAM if you want, and them
pass a pointer to the kernel.

MS

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

Re: Please make K2 Linux bootable without PeeMON again

[Tom Rini]

On Tue, Nov 27, 2001 at 10:46:17AM -0800, Michael Sokolov wrote:
>
> Tom Rini <trini@kernel.crashing.org> wrote:
>
> > Because it's only a slightly less magical location than the current one
> > (in the wrapper, I don't know where yours puts it).
>
> No, with my solution you don't need to know the kernel size, you just simply
> point it at where you've put the bi_recs.

Yes, but where is what I'm asking.

>
> The point is, you broke what worked. I was able to run public Linux on my K2
> prior to your change of 2001-11-19, I am not able to any more. You cannot break
> code that people use. You must fix it. I have already offered one easy fix.

Right.  And I don't want to just fix it, I want to make it better if
possible.

> > Well, that's the fun part.  No one really like the current magic
> > location, but no one's come up with a better one.
>
> But why have any magic location at all? I have no problem with your zImage goo
> putting bi_recs where it does (hell, I'll never use it anyway, so I don't care
> what it does in general), just please don't make the kernel look in any fixed
> location and let the booter tell it where it put them.

Right.  And what's a good place to put them?

> My booter, for example, doesn't use any magic locations. My booter is a plain
> standalone C program built with the GNU toolchain, and I store the bi_recs in
> my program's memory. You don't need to worry about what physical address it is,
> as I set R3 to point to them when I start vmlinux.

If it's not a constant, it's somehow 'magical', in the above contexts.

> You are welcome to look at my code:
>
> cvs -d :pserver:anoncvs@ivan.Harhan.ORG:/fs3/IFCTF-cvs co ppc-linux-boot

Okay.  If I'm reading all of this your bi_recs end up in the middle of
where you're run from, yes?  This has the same problem that the wrapper
does in that it's possible to overwrite these, if you're run in a bad
spot.  If I'm reading things right.

> > After reading the
> > pmac/chrp stuff which shoves the initrd at the end of RAM (we _could_
> > overwrite our initrds that we place right after the kernel, if we have a
> > big kernel and low link addresss).  Not that i've tried it yet, it just
> > poped out at me.
>
> OK, so now you want to make the kernel look for stuff only at the end of RAM
> and nowhere else, right?

No, I want to have the wrapper put the bi_recs there and suggest that
other people who're doing bootloaders do likewise in 2.5, IF this makes
sense as a good place to put them and they can't be overwriten by the
kernel bss.

> Then how is it going to know where the end of RAM is
> if the memory size is one of the things communicated via bi_recs in the first
> place?

I've been thinking, and one of two things could happen, at least in the
wrapper, we know mem size (Firmware, res data, magic).  Or assume
there's at least XX megs of ram on the system (I _think_ 16mb is the
'normal' min, but of course we have lots of systems breaking that rule).

What I'd like to see, and at least I think would be a good thing to
figure out is a general 'safe' location to store these in.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

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

Re: Please make K2 Linux bootable without PeeMON again

[Michael Sokolov]

Tom Rini <trini@kernel.crashing.org> wrote:

> Alright.  But what other magical bits do you need to shove in the
> registers?

None, I just have one register (R3, the first one) point to bi_recs.

> The wrappers do:
> rec = (struct bi_record *)_ALIGN((ulong)zimage_size +
> (1<<20)-1,(1<<20));
>
> Does the occult magic know the size?

The booter doesn't know the size. You see, right now the user first loads the
kernel using whatever means s/he wants, then runs my booter. The booter doesn't
currently know the kernel size. You want to give my users an extra hassle of
stuffing the kernel size in a register before starting my booter so the latter
can know it. Why? What's wrong with the other alternative (my yesterday's
patch) which would keep me happy, keep my users happy, and keep the rest of the
Linux/PPC community happy because it doesn't break anything and is completely
transparent?

> > No, it doesn't. The patch I posted yesterday doesn't and cannot break anything.
>
> Er, oh yeah, thanks.:w

So how about applying that patch then?

> Well, the register magic is being deprecated in 2.5, or that's the plan
> anyhow.

I've heard a different plan, namely having one (1) register, no "magic", point
to bi_recs. That's what I want.

> Why can't the occult load whatever the 2.5 bi_recs look like
> into memory someplace?

Where is that someplace? I don't see how you can come up with anything other
than something tied to aspects of the vmlinux ELF image, which I have already
shown to be not good.

MS

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

Re: Please make K2 Linux bootable without PeeMON again

[Tom Rini]

On Tue, Nov 27, 2001 at 08:34:51AM -0800, Michael Sokolov wrote:
>
> Tom Rini <trini@kernel.crashing.org> wrote:
>
> > Alright.  But what other magical bits do you need to shove in the
> > registers?
>
> None, I just have one register (R3, the first one) point to bi_recs.

Okay.

> > The wrappers do:
> > rec = (struct bi_record *)_ALIGN((ulong)zimage_size +
> > (1<<20)-1,(1<<20));
> >
> > Does the occult magic know the size?
>
> The booter doesn't know the size. You see, right now the user first loads the
> kernel using whatever means s/he wants, then runs my booter. The booter doesn't
> currently know the kernel size.

Maybe it's just me, but wouldn't you need to know the size to how much
to shove into memory?

> You want to give my users an extra hassle of
> stuffing the kernel size in a register before starting my booter so the latter
> can know it. Why? What's wrong with the other alternative (my yesterday's
> patch) which would keep me happy, keep my users happy, and keep the rest of the
> Linux/PPC community happy because it doesn't break anything and is completely
> transparent?

Because it's only a slightly less magical location than the current one
(in the wrapper, I don't know where yours puts it).

> > Well, the register magic is being deprecated in 2.5, or that's the plan
> > anyhow.
>
> I've heard a different plan, namely having one (1) register, no "magic", point
> to bi_recs. That's what I want.

Well, 'register magic' == 'cmd_line is rA, initrd is rB and rC'.  Sorry
for the confustion.

> > Why can't the occult load whatever the 2.5 bi_recs look like
> > into memory someplace?
>
> Where is that someplace? I don't see how you can come up with anything other
> than something tied to aspects of the vmlinux ELF image, which I have already
> shown to be not good.

Well, that's the fun part.  No one really like the current magic
location, but no one's come up with a better one.  After reading the
pmac/chrp stuff which shoves the initrd at the end of RAM (we _could_
overwrite our initrds that we place right after the kernel, if we have a
big kernel and low link addresss).  Not that i've tried it yet, it just
poped out at me.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

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

Re: Please make K2 Linux bootable without PeeMON again

[Michael Sokolov]

Tom Rini <trini@kernel.crashing.org> wrote:

> Er, why can't you find the magic location for the bi_recs and set that
> as well as the other registers you need to?

Because that location is tied to the kernel's symbols (__bss_start in this
case), and I have no way of knowing where that is. The kernel has already been
loaded into memory (by occult) by the time my booter runs, and my booter
doesn't have access to the original vmlinux ELF header or to System.map.

> > The patch below makes the K2 vmlinux expect a pointer to bi_recs in R3 like I
> > do on the Adirondack and makes the "simple" zImage goo pass a pointer to its
> > magic bi_recs in R3.
>
> And breaks all of the other ports which use 'simple' and expect bi_recs
> in the 'normal' place.

No, it doesn't. The patch I posted yesterday doesn't and cannot break anything.
The bi_recs are still being created in exactly the same place as before, I just
made the wrapper set R3 to point to that location before jumping to the kernel.
As R3 on entry to the kernel was previously undefined for "simple", this cannot
break anything. Why R3? Because there already is a precedent for it
(Adirondack).

> For now I'd much rather add back in the register
> checks.

You mean put arch/ppc/platforms/k2_setup.c back the way it was? That would work
for me. In that case you would also need to make
arch/ppc/boot/common/relocate.S put at least some meaningful values in R4 and
R6 (at least zeros) so that the kernel doesn't interpret garbage in those
registers as pointers to stuff.

> For 2.5 we can agree on a less magical and more predictable
> location.  Would somewhere around the end of memory work for you?

But why won't you just let me put it where I want and tell the kernel where I
put it? I'll fork Linux if I have to, but I would prefer not to.

MS

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

Re: Please make K2 Linux bootable without PeeMON again

[Tom Rini]

On Tue, Nov 27, 2001 at 07:33:27AM -0800, Michael Sokolov wrote:
>
> Tom Rini <trini@kernel.crashing.org> wrote:
>
> > Er, why can't you find the magic location for the bi_recs and set that
> > as well as the other registers you need to?
>
> Because that location is tied to the kernel's symbols (__bss_start in this
> case), and I have no way of knowing where that is. The kernel has already been
> loaded into memory (by occult) by the time my booter runs, and my booter
> doesn't have access to the original vmlinux ELF header or to System.map.

Alright.  But what other magical bits do you need to shove in the
registers?  The wrappers do:
rec = (struct bi_record *)_ALIGN((ulong)zimage_size +
(1<<20)-1,(1<<20));

Does the occult magic know the size?

> > > The patch below makes the K2 vmlinux expect a pointer to bi_recs in R3 like I
> > > do on the Adirondack and makes the "simple" zImage goo pass a pointer to its
> > > magic bi_recs in R3.
> >
> > And breaks all of the other ports which use 'simple' and expect bi_recs
> > in the 'normal' place.
>
> No, it doesn't. The patch I posted yesterday doesn't and cannot break anything.

Er, oh yeah, thanks.:w


> > For 2.5 we can agree on a less magical and more predictable
> > location.  Would somewhere around the end of memory work for you?
>
> But why won't you just let me put it where I want and tell the kernel where I
> put it? I'll fork Linux if I have to, but I would prefer not to.

Well, the register magic is being deprecated in 2.5, or that's the plan
anyhow.  Why can't the occult load whatever the 2.5 bi_recs look like
into memory someplace?

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

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

Please make K2 Linux bootable without PeeMON again

[Michael Sokolov]

Hi there,

This change in linuxppc_2_4_devel:

ChangeSet@1.666, 2001-11-19 09:10:26-07:00, trini@bill-the-cat.bloom.county
  Remove register magic from platforms which use 'simple'.  A few
  new platforms forgot parse_bootinfo(find_bootinfo()) as well.

  arch/ppc/platforms/k2_setup.c
    1.17 01/11/19 09:10:26 trini@bill-the-cat.bloom.county +0 -15
    Remove cmd_line and initrd register magic.

is a problem for me. On the K2 I do not use zImage or the braindead PeeMON
firmware that it assumes, instead I load vmlinux directly by occult. I need to
continue to able to do this, and I need to keep the interface to vmlinux
register-based so that I can load vmlinux into memory by occult, put the right
values in the right registers, and jump to it. A pointer to bi_recs in a
register is fine, but looking for bi_recs in the magic location isn't. (The
kernel has already been loaded into memory by occult when I get to it, and
without the original ELF header or System.map I cannot determine where will it
look for bi_recs in find_bootinfo.)

The patch below makes the K2 vmlinux expect a pointer to bi_recs in R3 like I
do on the Adirondack and makes the "simple" zImage goo pass a pointer to its
magic bi_recs in R3.

Please either apply this patch or give me some other way to boot Linux on the
K2 without PeeMON. This is the public tree in the free world and it is not
acceptable to force people to use PeeMON, the most developer-hostile ROM
monitor produced by the sickest minds ever.

MS

(Speaking on my own personal behalf only, not on my employer's.)

diff --minimal -Nru a/arch/ppc/boot/common/misc-simple.c b/arch/ppc/boot/common/misc-simple.c
--- a/arch/ppc/boot/common/misc-simple.c	Mon Nov 26 12:33:10 2001
+++ b/arch/ppc/boot/common/misc-simple.c	Mon Nov 26 12:33:10 2001
@@ -57,9 +57,10 @@
 extern unsigned long serial_init(int chan, void *ignored);
 extern void setup_legacy(void);

-void
+struct bootinfo *
 decompress_kernel(unsigned long load_addr, int num_words, unsigned long cksum)
 {
+	struct bootinfo *birecs;

 	int timer = 0;
 	extern unsigned long start;
@@ -158,6 +159,7 @@

 		rec = (struct bi_record *)_ALIGN((unsigned long)(zimage_size) +
 				(1 << 20) - 1, (1 << 20));
+		birecs = rec;

 		rec->tag = BI_FIRST;
 		rec->size = sizeof(struct bi_record);
@@ -183,4 +185,5 @@
 		rec = (struct bi_record *)((unsigned long)rec + rec->size);
 	}
 	puts("Now booting the kernel\n");
+	return(birecs);
 }
diff --minimal -Nru a/arch/ppc/platforms/k2.h b/arch/ppc/platforms/k2.h
--- a/arch/ppc/platforms/k2.h	Mon Nov 26 12:33:10 2001
+++ b/arch/ppc/platforms/k2.h	Mon Nov 26 12:33:10 2001
@@ -1,5 +1,5 @@
 /*
- * arch/ppc/kernel/k2.h
+ * arch/ppc/platforms/k2.h
  *
  * Definitions for SBS K2 board support
  *
@@ -13,8 +13,8 @@
  * option) any later version.
  */

-#ifndef __PPC_KERNEL_K2_H
-#define __PPC_KERNEL_K2_H
+#ifndef __PPC_PLATFORMS_K2_H
+#define __PPC_PLATFORMS_K2_H

 /*
  * SBS K2 definitions
@@ -81,4 +81,4 @@

 #define K2_SYS_SLOT_MASK	0x08

-#endif /* __PPC_KERNEL_K2_H */
+#endif /* __PPC_PLATFORMS_K2_H */
diff --minimal -Nru a/arch/ppc/platforms/k2_pci.c b/arch/ppc/platforms/k2_pci.c
--- a/arch/ppc/platforms/k2_pci.c	Mon Nov 26 12:33:10 2001
+++ b/arch/ppc/platforms/k2_pci.c	Mon Nov 26 12:33:10 2001
@@ -1,5 +1,5 @@
 /*
- * arch/ppc/kernel/k2_pci.c
+ * arch/ppc/platforms/k2_pci.c
  *
  * PCI support for SBS K2
  *
diff --minimal -Nru a/arch/ppc/platforms/k2_setup.c b/arch/ppc/platforms/k2_setup.c
--- a/arch/ppc/platforms/k2_setup.c	Mon Nov 26 12:33:10 2001
+++ b/arch/ppc/platforms/k2_setup.c	Mon Nov 26 12:33:10 2001
@@ -1,5 +1,5 @@
 /*
- * arch/ppc/kernel/k2_setup.c
+ * arch/ppc/platforms/k2_setup.c
  *
  * Board setup routines for SBS K2
  *
@@ -346,7 +346,7 @@
 void __init platform_init(unsigned long r3, unsigned long r4,
 		unsigned long r5, unsigned long r6, unsigned long r7)
 {
-	parse_bootinfo(find_bootinfo());
+	parse_bootinfo((struct bootinfo *) (r3 + KERNELBASE));

 	isa_io_base = K2_ISA_IO_BASE;
 	isa_mem_base = K2_ISA_MEM_BASE;

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

Re: Please make K2 Linux bootable without PeeMON again

[Tom Rini]

On Mon, Nov 26, 2001 at 01:01:49PM -0800, Michael Sokolov wrote:

> ChangeSet@1.666, 2001-11-19 09:10:26-07:00, trini@bill-the-cat.bloom.county
>   Remove register magic from platforms which use 'simple'.  A few
>   new platforms forgot parse_bootinfo(find_bootinfo()) as well.
>
>   arch/ppc/platforms/k2_setup.c
>     1.17 01/11/19 09:10:26 trini@bill-the-cat.bloom.county +0 -15
>     Remove cmd_line and initrd register magic.
>
> is a problem for me. On the K2 I do not use zImage or the braindead PeeMON
> firmware that it assumes, instead I load vmlinux directly by occult. I need to
> continue to able to do this, and I need to keep the interface to vmlinux
> register-based so that I can load vmlinux into memory by occult, put the right
> values in the right registers, and jump to it. A pointer to bi_recs in a
> register is fine, but looking for bi_recs in the magic location isn't. (The
> kernel has already been loaded into memory by occult when I get to it, and
> without the original ELF header or System.map I cannot determine where will it
> look for bi_recs in find_bootinfo.)

Er, why can't you find the magic location for the bi_recs and set that
as well as the other registers you need to?

> The patch below makes the K2 vmlinux expect a pointer to bi_recs in R3 like I
> do on the Adirondack and makes the "simple" zImage goo pass a pointer to its
> magic bi_recs in R3.

And breaks all of the other ports which use 'simple' and expect bi_recs
in the 'normal' place.  For now I'd much rather add back in the register
checks.  For 2.5 we can agree on a less magical and more predictable
location.  Would somewhere around the end of memory work for you?

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

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