Re: SBS Palomar II/IV/V port

Re: SBS Palomar II/IV/V port

[Val Henson]

On Tue, Oct 09, 2001 at 02:25:03PM -0700, Michael Sokolov wrote:

> Some other bi_rec fixes may be needed (initrd ones are broken I think).

Indeed!  This is on my list of stuff to do - straighten out once and
for all how BI_INITRD works and then rewrite the Gemini boot process
to use it.  It seemed like we had two interpretations:

1. The BI_INITRD boot record contains the start address and the size
   of the initrd.

2. The BI_INITRD boot record contains the entire initrd itself (as a
   really large boot record).

I have no preference either way, I just want someone to tell me which
way we're going to do it. :)

-VAL

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

Re: SBS Palomar II/IV/V port

[Benjamin Herrenschmidt]

>Indeed!  This is on my list of stuff to do - straighten out once and
>for all how BI_INITRD works and then rewrite the Gemini boot process
>to use it.  It seemed like we had two interpretations:
>
>1. The BI_INITRD boot record contains the start address and the size
>   of the initrd.
>
>2. The BI_INITRD boot record contains the entire initrd itself (as a
>   really large boot record).
>
>I have no preference either way, I just want someone to tell me which
>way we're going to do it. :)

We can very easily support both ways. In the first case, we should
also clearly comment the fact that the pointer passed to the kernel
is physical.

I'll eventually push some code in the upcoming 1 or 2 days that
does the kernel-side of getting passed pointer-based birecs. I
will eventually throw in a couple of new birec definitions as
well.

Ben.


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

Re: SBS Palomar II/IV/V port

[Tom Rini]

On Wed, Oct 10, 2001 at 11:30:37PM +0200, Benjamin Herrenschmidt wrote:

> I'll eventually push some code in the upcoming 1 or 2 days that
> does the kernel-side of getting passed pointer-based birecs. I
> will eventually throw in a couple of new birec definitions as
> well.

Can we please not commit this just yet?  2.5 will open up soon
hopefully...  Maybe after 2.4.12 or so.  I think it would be a bad thing
to put this in the 2_4 trees (either of 'em) inititally.  Throwing
around patches tho would be good. :)

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

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

Re: SBS Palomar II/IV/V port

[Paul Mackerras]

Val Henson writes:

> 1. The BI_INITRD boot record contains the start address and the size
>    of the initrd.
>
> 2. The BI_INITRD boot record contains the entire initrd itself (as a
>    really large boot record).
>
> I have no preference either way, I just want someone to tell me which
> way we're going to do it. :)

I think 1 is preferable, if you have 1 you can actually do 2 as well
in fact (just have a large record with an address/size record at the
front with the address pointing into the record).

Paul.

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

Re: SBS Palomar II/IV/V port

[Tom Rini]

On Wed, Oct 10, 2001 at 12:24:15PM -0600, Val Henson wrote:
>
> On Tue, Oct 09, 2001 at 02:25:03PM -0700, Michael Sokolov wrote:
>
> > Some other bi_rec fixes may be needed (initrd ones are broken I think).
>
> Indeed!  This is on my list of stuff to do - straighten out once and
> for all how BI_INITRD works and then rewrite the Gemini boot process
> to use it.  It seemed like we had two interpretations:
>
> 1. The BI_INITRD boot record contains the start address and the size
>    of the initrd.
>
> 2. The BI_INITRD boot record contains the entire initrd itself (as a
>    really large boot record).

I thought we had agreed on 1 (and nothing uses it yet anyhow).  Tho my
memory could be hazy.

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

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

Re: SBS Palomar II/IV/V port

[Peter Bergner]

On Wed, Oct 10, 2001 at 06:06:22PM -0700, Tom Rini wrote:
: > 1. The BI_INITRD boot record contains the start address and the size
: >    of the initrd.
: >
: > 2. The BI_INITRD boot record contains the entire initrd itself (as a
: >    really large boot record).
:
: I thought we had agreed on 1 (and nothing uses it yet anyhow).  Tho my
: memory could be hazy.

This was my understanding as well of the earlier conversations,
so this is what I used to implement zImage.initrd for ppc64.
Hopefully everyone remembers this not only affects the ppc32
kernel, but also affects the ppc64 kernel as well.

Peter

--
Peter Bergner
SLIC Optimizing Translator Development / Linux PPC64 Kernel Development
IBM Rochester, MN
bergner@vnet.ibm.com


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

Re: SBS Palomar II/IV/V port

[Tom Rini]

On Wed, Oct 10, 2001 at 12:24:15PM -0600, Val Henson wrote:
>
> On Tue, Oct 09, 2001 at 02:25:03PM -0700, Michael Sokolov wrote:
>
> > Some other bi_rec fixes may be needed (initrd ones are broken I think).
>
> Indeed!  This is on my list of stuff to do - straighten out once and
> for all how BI_INITRD works and then rewrite the Gemini boot process
> to use it.  It seemed like we had two interpretations:
>
> 1. The BI_INITRD boot record contains the start address and the size
>    of the initrd.

Okay, does the following look right/work for everyone?  (With a similar
change to arch/ppc64/kernel/setup.c).

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

===== arch/ppc/kernel/setup.c 1.60 vs edited =====
--- 1.60/arch/ppc/kernel/setup.c	Thu Sep 27 09:01:14 2001
+++ edited/arch/ppc/kernel/setup.c	Thu Oct 11 16:15:45 2001
@@ -496,7 +496,7 @@
 #ifdef CONFIG_BLK_DEV_INITRD
 		case BI_INITRD:
 			initrd_start = data[0];
-			initrd_end = data[0] + rec->size;
+			initrd_end = data[0] + data[1];
 			break;
 #endif /* CONFIG_BLK_DEV_INITRD */
 #ifdef CONFIG_ALL_PPC

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

Re: SBS Palomar II/IV/V port

[Peter Bergner]

: Okay, does the following look right/work for everyone?  (With a similar
: change to arch/ppc64/kernel/setup.c).
:
: ===== arch/ppc/kernel/setup.c 1.60 vs edited =====
: --- 1.60/arch/ppc/kernel/setup.c	Thu Sep 27 09:01:14 2001
: +++ edited/arch/ppc/kernel/setup.c	Thu Oct 11 16:15:45 2001
: @@ -496,7 +496,7 @@
:  #ifdef CONFIG_BLK_DEV_INITRD
:  		case BI_INITRD:
:  			initrd_start = data[0];
: -			initrd_end = data[0] + rec->size;
: +			initrd_end = data[0] + data[1];
:  			break;
:  #endif /* CONFIG_BLK_DEV_INITRD */
:  #ifdef CONFIG_ALL_PPC

That's one of the changes I already have for PPC64, so looks good to me too.

Peter

--
Peter Bergner
SLIC Optimizing Translator Development / Linux PPC64 Kernel Development
IBM Rochester, MN
bergner@vnet.ibm.com


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

Re: SBS Palomar II/IV/V port

[Michael Sokolov]

Val Henson <val@nmt.edu> wrote:

> Indeed!  This is on my list of stuff to do - straighten out once and
> for all how BI_INITRD works and then rewrite the Gemini boot process
> to use it.  It seemed like we had two interpretations:
>
> 1. The BI_INITRD boot record contains the start address and the size
>    of the initrd.
>
> 2. The BI_INITRD boot record contains the entire initrd itself (as a
>    really large boot record).
>
> I have no preference either way, I just want someone to tell me which
> way we're going to do it. :)

I really need to be able to have the initrd image located anywhere, forcing it
to be part of the bi_recs list is unacceptable. But if someone really wants
option 2, maybe we can have two different bi_recs to suit everyone?

--
Michael Sokolov				5791 VAN ALLEN WAY
Software Engineer			CARLSBAD CA 92008-7321 USA
SBS Technologies, Inc.			Phone: +1-760-438-6900 x2347
Communications Products			    or  1-888-SBS-COMM x2347
					Fax:   +1-760-438-6985
					E-mail: msokolov@sbs.com
					     or msokolov@ivan.Harhan.ORG

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

Re: SBS Palomar II/IV/V port

[Michael Sokolov]

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

> Okay, does the following look right/work for everyone?
>
> [...]
>
> -			initrd_end = data[0] + rec->size;
> +			initrd_end = data[0] + data[1];

This should work for me.

MS

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