More walnut boottime "fun"

More walnut boottime "fun"

[Simon Winwood]

	Hi,

	Apart from NFS not working, it looks like the bootloader is
clobbering itself when the image is reasonably large (> 1M?).

	This happens when it relocates itself (the initrd or whatever
overwrites the relocation code).

	Has anyone fixed this, or should I keep going ;)

	Simon

p.s. this is only an issue where the dest address < the load address, as
on walnut and friends

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

Re: More walnut boottime "fun"

[Tom Rini]

On Tue, Nov 27, 2001 at 10:30:42AM +1100, Simon Winwood wrote:

> 	Apart from NFS not working, it looks like the bootloader is
> clobbering itself when the image is reasonably large (> 1M?).

There's certain dead-zones now.  Check out
arch/ppc/boot/common/relocate.S for the constraints.  Tomorrow I plan on
implementing a slightly smarter relocate that moves the text, jumps
there and then relocates data, which should bring us back to the same
size deadzones that the original code had.

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

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

Re: More walnut boottime "fun"

[Matt Porter]

On Mon, Nov 26, 2001 at 10:17:28PM -0700, Tom Rini wrote:
>
> On Tue, Nov 27, 2001 at 10:30:42AM +1100, Simon Winwood wrote:
>
> > 	Apart from NFS not working, it looks like the bootloader is
> > clobbering itself when the image is reasonably large (> 1M?).
>
> There's certain dead-zones now.  Check out

Deadzone. Singular.

> arch/ppc/boot/common/relocate.S for the constraints.  Tomorrow I plan on
> implementing a slightly smarter relocate that moves the text, jumps
> there and then relocates data, which should bring us back to the same
> size deadzones that the original code had.

I don't think you understand what happened.  The relocate.S code
changed simply in terms of direction of copy.  It used to copy
from low->high now it copies from high->low.  This eliminated one
constraint from the original code and does not add any additional
ones.  I simply documented the remaining constraint since nobody
bothered to do that in the past.

That said, the two stage relocator is "The Right Thing To Do(tm)".
It only needs to be two stage, though when the load point > -Ttext.

Why doesn't walnut simply call mktree with the option to load at
it's -Ttext to avoid the original problem?  That's why I added the
parameter to mktree and use it on the Spruce build...no need to
do an extra copy if we control the load point.

--
Matt Porter
MontaVista Software, Inc.
mporter@mvista.com

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

Re: More walnut boottime "fun"

[Tom Rini]

On Tue, Nov 27, 2001 at 05:07:54AM -0700, Matt Porter wrote:
>
> On Mon, Nov 26, 2001 at 10:17:28PM -0700, Tom Rini wrote:
> >
> > On Tue, Nov 27, 2001 at 10:30:42AM +1100, Simon Winwood wrote:
> >
> > > 	Apart from NFS not working, it looks like the bootloader is
> > > clobbering itself when the image is reasonably large (> 1M?).
> >
> > There's certain dead-zones now.  Check out
>
> Deadzone. Singular.
>
> > arch/ppc/boot/common/relocate.S for the constraints.  Tomorrow I plan on
> > implementing a slightly smarter relocate that moves the text, jumps
> > there and then relocates data, which should bring us back to the same
> > size deadzones that the original code had.
>
> I don't think you understand what happened.

After sleeping on it I was confusing myself with a different problem...

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

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

Re: More walnut boottime "fun"

[Simon Winwood]

[-- Attachment #1: Type: text/plain, Size: 1068 bytes --]

On Tue, Nov 27, 2001 at 05:07:54AM -0700, Matt Porter wrote:
> On Mon, Nov 26, 2001 at 10:17:28PM -0700, Tom Rini wrote:
> >
>

[...]

> That said, the two stage relocator is "The Right Thing To Do(tm)".
> It only needs to be two stage, though when the load point > -Ttext.

	I have fixed the relocate code so it does it in 2 stages ...
first it moves the relocate code, then it relocates the image, either
start first or end first, so it doesn't overwrite itself.

	The code is a bit verbose, but I guess size isn't really an issue
for the boot code.
>
> Why doesn't walnut simply call mktree with the option to load at
> it's -Ttext to avoid the original problem?  That's why I added the
> parameter to mktree and use it on the Spruce build...no need to
> do an extra copy if we control the load point.

	That would be too easy ;)  Besides, I had pretty much finished
the code when I got this email (would have finished it last night, except
that 'mtcr' and 'mtctr' are apparently both valid instructions ;(

	Simon

--
Simon Winwood
IBM T.J. Watson Research Center

[-- Attachment #2: patch-ppc-relocate --]
[-- Type: text/plain, Size: 3756 bytes --]

===== arch/ppc/boot/common/relocate.S 1.5 vs edited =====
--- 1.5/arch/ppc/boot/common/relocate.S	Mon Nov 19 19:17:42 2001
+++ edited/arch/ppc/boot/common/relocate.S	Tue Nov 27 14:49:50 2001
@@ -22,8 +22,10 @@
 #include <asm/cache.h>
 #include <asm/ppc_asm.h>

+#define GETSYM(reg, sym)	\
+	lis	reg, sym@h; ori	reg, reg, sym@l
+
 	.text
-
 	/* We get called from the early initialization code.
 	 * Register 3 has the address where we were loaded,
 	 * Register 4 contains any residual data passed from the
@@ -39,10 +41,9 @@
 	mr	r11, r4

 	/* compute the size of the whole image in words. */
-	lis	r4,start@h
-	ori	r4,r4,start@l
-	lis	r5,end@h
-	ori	r5,r5,end@l
+	GETSYM(r4,start)
+	GETSYM(r5,end)
+
 	addi	r5,r5,3		/* round up */
 	sub	r5,r5,r4	/* end - start */
 	srwi	r5,r5,2
@@ -55,33 +56,94 @@
 	cmp	cr0,r3,r4
 	beq	start_ldr	/* If 0, we don't need to relocate */

-	/*
-	 * No matter where we're loaded, move ourselves to -Ttext
-	 * address.  Always copy end->start to accomodate images
-	 * that cross the -Ttext boundary.
-	 *
-	 * Note: There are still many ways we can wipe ourselves out
-	 * while relocating.  If we are loaded > -Ttext and the
-	 * sizeof(zImage[.initrd]) > (load point - -Ttext) then we
-	 * will wipe ourselves out.  We need a two stage relocater
-	 * to handle this case. -MDP
+	/* Move this code somewhere safe.  This is max(load + size, end)
+	 * r8 == load address
 	 */
-	lis	r4,end@h	/* Load ending address */
-	ori	r4,r4,end@l
-	mr	r5,r7		/* Get the # of longwords again */
-	mtctr	r5		/* Setup for a loop */
-	slwi	r5,r5,2		/* Get size in bytes */
-	add	r3, r3, r5	/* Calculate end of loaded image */
-	li	r6,0
-00:	lwzu	r5,-4(r3)	/* Load and decrement */
-	stwu	r5,-4(r4)	/* Store and decrement */
-	xor	r6,r6,r5	/* Are we done? */
-	bdnz	00b
-	lis	r3,start_ldr@h
-	ori	r3,r3,start_ldr@l
+	GETSYM(r4, start)
+	GETSYM(r5, end)
+
+	sub	r6, r5, r4
+	add	r6, r8, r6	/* r6 == phys(load + size) */
+
+	cmpw	r5, r6
+	bgt	1f
+	b	2f
+1:
+	mr	r6, r5
+2:
+	/* dest is in r6 */
+	/* Ensure alignment --- this code is precautionary */
+	addi	r6, r6, 4
+	li	r5, 0x0003
+	andc	r6, r6, r5
+
+	/* Find physical address and size of do_relocate */
+	GETSYM(r5, do_relocate)
+	GETSYM(r4, do_relocate_end)
+	GETSYM(r3, start)
+
+	/* Size to copy */
+	sub	r4, r4, r5
+	srwi	r4, r4, 2
+
+	/* Src addr to copy (= do_relocate - start + where_loaded) */
+	sub	r3, r5, r3
+	add	r5, r8, r3
+
+	/* Save dest */
+	mr	r3, r6
+
+	/* Do the copy */
+	mtctr	r4
+3:	lwz	r4, 0(r5)
+	stw	r4, 0(r3)
+	addi	r3, r3, 4
+	addi	r5, r5, 4
+	bdnz	3b
+
+	/* This will return to the relocated do_relocate */
+	mtlr	r6
+	b	flush_instruction_cache
+
+do_relocate:
+	/* We have 2 cases --- start < load, or start > load
+	 * This determines whether we copy from the end, or the start.
+	 * Its easier to have 2 loops than to have paramaterised
+	 * loops.  Sigh.
+	 */
+	li	r6, 0		/* Clear checksum */
+	mtctr	r7		/* Setup for a loop */
+
+	GETSYM(r4, start)
+	mr	r3, r8		/* Get the load addr */
+
+	cmp	cr0, r4, r3	/* If we need to copy from the end, do so */
+	bgt	do_relocate_from_end
+
+do_relocate_from_start:
+1:	lwz	r5, 0(r3)	/* Load and decrement */
+	stw	r5, 0(r4)	/* Store and decrement */
+	addi	r3, r3, 4
+	addi	r4, r4, 4
+	xor	r6,r6,r5	/* Update checksum */
+	bdnz	1b		/* Are we done? */
+	b	do_relocate_out	/* Finished */
+
+do_relocate_from_end:
+	GETSYM(r3, end)
+	slwi	r4, r7, 2
+	add	r4, r8, r4	/* Get the physical end */
+1:	lwzu	r5, -4(r4)
+	stwu	r5, -4(r3)
+	xor	r6, r6, r5
+	bdnz	1b
+
+do_relocate_out:
+	GETSYM(r3,start_ldr)
 	mtlr	r3		/* Easiest way to do an absolute jump */
 	blr
-
+do_relocate_end:
+
 start_ldr:
 /* Some boards don't boot up with the I-cache enabled.  Do that
  * now because the decompress runs much faster that way.

Re: More walnut boottime "fun"

[Tom Rini]

On Wed, Nov 28, 2001 at 06:18:57AM +1100, Simon Winwood wrote:
> On Tue, Nov 27, 2001 at 05:07:54AM -0700, Matt Porter wrote:
> > On Mon, Nov 26, 2001 at 10:17:28PM -0700, Tom Rini wrote:
> > >
> >
>
> [...]
>
> > That said, the two stage relocator is "The Right Thing To Do(tm)".
> > It only needs to be two stage, though when the load point > -Ttext.
>
> 	I have fixed the relocate code so it does it in 2 stages ...
> first it moves the relocate code, then it relocates the image, either
> start first or end first, so it doesn't overwrite itself.

Yay.  I was just about to start on that now that I fixed the minor
things upsetting my rpx.  I'll go and test this around and commit it or
something similar today hopefully.

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

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

Re: More walnut boottime "fun"

[Phil]

I'am trying to boot the latest linuxppc_2_4_devel kernel version
(2.4.27-pre2).
I got it with the rsync access from Montavista.
I build the kernel for my Walnut board using HHL2.0 toolchain
(ppc-405-xxx) and i try to load it
with the original bootloader (from ibm)
Nothing appened after "Now booting the kernel".
It seems it's a known problem.
Thanks.
-Phil

Here is my boot console:
--------------------------------
ENET Speed is 10
Mbs...
HALF duplex
connection
Booting from [ENET] Ethernet
...
Sending bootp request
...


Loading file "pvillet/kernel/vmlinuz-target"
...
Sending tftp boot request
...
Transfer Complete
...
Loaded successfully
...
Entry point at 0x500000
...

loaded at:     00500000
0058388C
relocated to:  00400000
0048388C
board data at: 004807BC
004807FC
relocated to:  0048077C
004807BC
zimage at:     00405400
0047FF59
avail ram:     00484000
02000000

Linux/PPC load: root=/dev/nfs rw
ip=auto
Uncompressing
Linux...done.
Now booting the kernel

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

Re: More walnut boottime "fun"

[Tom Rini]

On Tue, Dec 04, 2001 at 02:46:46PM +0100, Phil wrote:

> I'am trying to boot the latest linuxppc_2_4_devel kernel version
> (2.4.27-pre2).

What date?  This isn't a problem anymore, at least on a few walnuts I've
gotten people to test.

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

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

Re: More walnut boottime "fun"

[Phil]

I resync the kernel sources today at 7:15 am GMT.
Any idea ?

-Phil.


Tom Rini a écrit :
>
> On Tue, Dec 04, 2001 at 02:46:46PM +0100, Phil wrote:
>
> > I'am trying to boot the latest linuxppc_2_4_devel kernel version
> > (2.4.27-pre2).
>
> What date?  This isn't a problem anymore, at least on a few walnuts I've
> gotten people to test.

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

Re: More walnut boottime "fun"

[Tom Rini]

On Tue, Dec 04, 2001 at 03:24:49PM +0100, Phil wrote:

> I resync the kernel sources today at 7:15 am GMT.
> Any idea ?

Have you run a 'make distclean' anytime recently?  If not, try that..
(and save your .config someplace).

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

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

Re: More walnut boottime "fun"

[Phil]

Tom Rini a écrit :
>
> On Tue, Dec 04, 2001 at 03:24:49PM +0100, Phil wrote:
>
> > I resync the kernel sources today at 7:15 am GMT.
> > Any idea ?
>
> Have you run a 'make distclean' anytime recently?  If not, try that..
> (and save your .config someplace).
>
> --
> Tom Rini (TR1265)
> http://gate.crashing.org/~trini/

Yes, i have. I also try to launch it with an empty command line
as described in a previous e-mail but without success.
Are the printed adresses by the bootloader correct :
Thanks.
-Phil


Entry point at 0x500000
...

loaded at:     00500000
0058388C
relocated to:  00400000
0048388C
board data at: 004807BC
004807FC
relocated to:  0048077C
004807BC
zimage at:     00405400
0047FF59
avail ram:     00484000
02000000

Linux/PPC load: root=/dev/nfs rw
ip=auto
Uncompressing
Linux...done.
Now booting the kernel

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

Re: More walnut boottime "fun"

[Tom Rini]

On Tue, Dec 04, 2001 at 05:46:31PM +0100, Phil wrote:
> Tom Rini a ?crit :
> >
> > On Tue, Dec 04, 2001 at 03:24:49PM +0100, Phil wrote:
> >
> > > I resync the kernel sources today at 7:15 am GMT.
> > > Any idea ?
> >
> > Have you run a 'make distclean' anytime recently?  If not, try that..
> > (and save your .config someplace).
>
> Yes, i have. I also try to launch it with an empty command line
> as described in a previous e-mail but without success.
> Are the printed adresses by the bootloader correct :
> Thanks.

Everything looks fine, can you look into this more?  And try changing
the -Ttext line in arch/ppc/boot/simple/Makefile from 0x00400000 to
0x00500000

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

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

Re: More walnut boottime "fun"

[Frank Rowand]

Phil wrote:
>
> I resync the kernel sources today at 7:15 am GMT.
> Any idea ?
>
> -Phil.
>
> Tom Rini a écrit :
> >
> > On Tue, Dec 04, 2001 at 02:46:46PM +0100, Phil wrote:
> >
> > > I'am trying to boot the latest linuxppc_2_4_devel kernel version
> > > (2.4.27-pre2).
> >
> > What date?  This isn't a problem anymore, at least on a few walnuts I've
> > gotten people to test.

Rev 1.731 of linuxppc_2_4_devel(mid-day California time yesterday) boots
fine on my walnut.

HHL2.0 toolchain and ibm OpenBios.

I used an almost default configuration (I was working on a KGDB
problem so I enabled KGDB):

   make walnut_config
   make menconfig
        select KGDB
        select CONFIG_MORE_COMPILE_OPTIONS
   make dep
   make zImage

(I needed to fix config.in to allow CONFIG_MORE_COMPILE_OPTIONS - see
the patch I posted yesterday.)

You shouldn't have to enable KGDB.


Do you have KGDB enabled by mistake?  If you do, it will sit at the
"Now booting the kernel" console message until KGDB connects to the
target.


-Frank
--
Frank Rowand <frank_rowand@mvista.com>
MontaVista Software, Inc

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

Re: More walnut boottime "fun"

[Armin Kuster]

Phil wrote:
>
> I resync the kernel sources today at 7:15 am GMT.
> Any idea ?
>
> -Phil.
>
> Tom Rini a écrit :
> >
> > On Tue, Dec 04, 2001 at 02:46:46PM +0100, Phil wrote:
> >
> > > I'am trying to boot the latest linuxppc_2_4_devel kernel version
> > > (2.4.27-pre2).
> >
> > What date?  This isn't a problem anymore, at least on a few walnuts I've
> > gotten people to test.
>


Change set 1.735 works.  Its prior to the kgdb patches

-- armin

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

Re: More walnut boottime "fun" and BDI2000

[Phil]

Frank Rowand a écrit :
>
> Phil wrote:
> >
> > I resync the kernel sources today at 7:15 am GMT.
> > Any idea ?
> >
> > Tom Rini a écrit :
> > >
> > > On Tue, Dec 04, 2001 at 02:46:46PM +0100, Phil wrote:
> > >
> > > > I'am trying to boot the latest linuxppc_2_4_devel kernel version
> > > > (2.4.27-pre2).
> > >
> > > What date?  This isn't a problem anymore, at least on a few walnuts I've
> > > gotten people to test.
>
> Rev 1.731 of linuxppc_2_4_devel(mid-day California time yesterday) boots
> fine on my walnut.
>
> HHL2.0 toolchain and ibm OpenBios.
>
> I used an almost default configuration (I was working on a KGDB
> problem so I enabled KGDB):
>
>    make walnut_config
>    make menconfig
>         select KGDB
>         select CONFIG_MORE_COMPILE_OPTIONS
>    make dep
>    make zImage
>
> (I needed to fix config.in to allow CONFIG_MORE_COMPILE_OPTIONS - see
> the patch I posted yesterday.)
>
> You shouldn't have to enable KGDB.
>
> Do you have KGDB enabled by mistake?  If you do, it will sit at the
> "Now booting the kernel" console message until KGDB connects to the
> target.


Thanks Frank
You're right. It works fine with
    make walnut_config
    make menconfig
    make dep
    make zImage
and the ibm openbios
but i want to use my BDi 2000  Abatron debugger to debug the kernel.
So, i select the following options :
         select CONFIG_BDI_SWITCH
         select CONFIG_MORE_COMPILE_OPTIONS
I download the kernel with the debugger(latest 1.07 firmware). It works
fine (i can put for
example a breakpoint in start_kernel or in do_init_bootmem, it stops at
the right address)
If i continue, nothing happened, the 405GP seems locked in the __udelay
routines.
Is it a debugger config file pb ?
Any idea ? Thanks

-Phil.

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