* CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
@ 2010-09-08 23:21 Ira W. Snyder
2010-09-09 1:02 ` Benjamin Herrenschmidt
0 siblings, 1 reply; 24+ messages in thread
From: Ira W. Snyder @ 2010-09-08 23:21 UTC (permalink / raw)
To: linuxppc-dev; +Cc: peterz, mingo
Hello everyone,
I'm running Linux on a Freescale MPC8349EA board (PowerPC 6xx processor). When
I enable the CONFIG_PROVE_LOCKING option, the kernel fails to boot. If I
toggle that option (and ONLY that option) off, the kernel boots normally.
The lockup happens very, very early during boot. Much too early to even have
console messages coming out on the serial port. Therefore, I've hooked up a
JTAG debugger and gained as much information as I can.
I would guess that something in lockdep_init() is breaking things, based on
the backtrace provided. It is called in machine_init(), which is part of the
backtrace. I think some part of lockdep is overwriting the flat device tree.
The __log_buf output supports this claim. I am booting the two kernels with
*exactly* the same device tree.
(gdb) target remote bdi2k:2001
Remote debugging using bdi2k:2001
0x0ffbf760 in ?? ()
(gdb) cont
Continuing.
Program received signal SIGTRAP, Trace/breakpoint trap.
0xc031e0ec in memblock_reserve (base=8355840, size=0) at /home/iws/devel/linux-2.6/mm/memblock.c:270
270 BUG_ON(0 == size);
(gdb) info stack
#0 0xc031e0ec in memblock_reserve (base=8355840, size=0) at /home/iws/devel/linux-2.6/mm/memblock.c:270
#1 0xc0315f04 in early_init_devtree (params=<value optimized out>) at /home/iws/devel/linux-2.6/arch/powerpc/kernel/prom.c:537
#2 0xc031691c in machine_init (dt_ptr=8355840) at /home/iws/devel/linux-2.6/arch/powerpc/kernel/setup_32.c:127
#3 0xc0003410 in start_here () at /home/iws/devel/linux-2.6/arch/powerpc/kernel/head_32.S:982
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) print __log_buf
$3 = "<3>[ 0.000000] Invalid tag 0 in flat device tree!\n<3>[ 0.000000] Invalid tag 0 in flat device tree!\n<3>[ 0.000000] Invalid tag 0 in flat device tree!\n", '\0' <repeats 130912 times>
I am happy to provide more information if it will help. I'm not especially
good at working the debugger. I can't get it to stop at machine_init() and let
me step through the code.
I tried this feature when it first became available on powerpc, and it
did not work then. At that time, I didn't have the resources to
investigate further. I don't think a git bisect will help in this case.
Thanks,
Ira
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
2010-09-08 23:21 CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?) Ira W. Snyder
@ 2010-09-09 1:02 ` Benjamin Herrenschmidt
2010-09-09 2:52 ` Ira W. Snyder
0 siblings, 1 reply; 24+ messages in thread
From: Benjamin Herrenschmidt @ 2010-09-09 1:02 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: peterz, mingo, linuxppc-dev
On Wed, 2010-09-08 at 16:21 -0700, Ira W. Snyder wrote:
>
>
> I am happy to provide more information if it will help. I'm not
> especially
> good at working the debugger. I can't get it to stop at machine_init()
> and let
> me step through the code.
>
> I tried this feature when it first became available on powerpc, and it
> did not work then. At that time, I didn't have the resources to
> investigate further. I don't think a git bisect will help in this
> case.
That's a concern... lockdep_init() is expected to only perform static
initializations...
Any chance you can stick a data breakpoint early on to catch when the
corruption happens ?
Cheers,
Ben.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
2010-09-09 1:02 ` Benjamin Herrenschmidt
@ 2010-09-09 2:52 ` Ira W. Snyder
2010-09-09 2:58 ` Benjamin Herrenschmidt
0 siblings, 1 reply; 24+ messages in thread
From: Ira W. Snyder @ 2010-09-09 2:52 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: peterz, mingo, linuxppc-dev
On Thu, Sep 09, 2010 at 11:02:36AM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2010-09-08 at 16:21 -0700, Ira W. Snyder wrote:
> >
> >
> > I am happy to provide more information if it will help. I'm not
> > especially
> > good at working the debugger. I can't get it to stop at machine_init()
> > and let
> > me step through the code.
> >
> > I tried this feature when it first became available on powerpc, and it
> > did not work then. At that time, I didn't have the resources to
> > investigate further. I don't think a git bisect will help in this
> > case.
>
> That's a concern... lockdep_init() is expected to only perform static
> initializations...
>
Yes, I looked over the function, and I don't understand where it goes
wrong.
> Any chance you can stick a data breakpoint early on to catch when the
> corruption happens ?
>
I will attempt to get the debugger to stop at start_kernel. I'm having
trouble driving the JTAG debugger (a BDI2000). I have used Denx's guide
[1] in the past, but the section on debugging the kernel itself is now
missing.
[1] http://www.denx.de/wiki/view/DULG/DebuggingLinuxKernel
I'll keep trying.
Thanks for the reply,
Ira
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
2010-09-09 2:52 ` Ira W. Snyder
@ 2010-09-09 2:58 ` Benjamin Herrenschmidt
2010-09-09 16:23 ` Ira W. Snyder
0 siblings, 1 reply; 24+ messages in thread
From: Benjamin Herrenschmidt @ 2010-09-09 2:58 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: peterz, mingo, linuxppc-dev
On Wed, 2010-09-08 at 19:52 -0700, Ira W. Snyder wrote:
>
> I will attempt to get the debugger to stop at start_kernel. I'm having
> trouble driving the JTAG debugger (a BDI2000). I have used Denx's
> guide
> [1] in the past, but the section on debugging the kernel itself is now
> missing.
>
> [1] http://www.denx.de/wiki/view/DULG/DebuggingLinuxKernel
>
> I'll keep trying.
start_kernel might be too late...
You can also hack thing :-) Like in the asm, before machine_init(),
stick something in the DABR and put a HW breakpoint with the BDI2000 on
the Data Access exception handler to "catch" when it faults.
Ben.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
2010-09-09 2:58 ` Benjamin Herrenschmidt
@ 2010-09-09 16:23 ` Ira W. Snyder
2010-09-09 18:44 ` Ira W. Snyder
2010-09-09 21:58 ` Benjamin Herrenschmidt
0 siblings, 2 replies; 24+ messages in thread
From: Ira W. Snyder @ 2010-09-09 16:23 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: peterz, mingo, linuxppc-dev
On Thu, Sep 09, 2010 at 12:58:16PM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2010-09-08 at 19:52 -0700, Ira W. Snyder wrote:
> >
> > I will attempt to get the debugger to stop at start_kernel. I'm having
> > trouble driving the JTAG debugger (a BDI2000). I have used Denx's
> > guide
> > [1] in the past, but the section on debugging the kernel itself is now
> > missing.
> >
> > [1] http://www.denx.de/wiki/view/DULG/DebuggingLinuxKernel
> >
> > I'll keep trying.
>
> start_kernel might be too late...
>
> You can also hack thing :-) Like in the asm, before machine_init(),
> stick something in the DABR and put a HW breakpoint with the BDI2000 on
> the Data Access exception handler to "catch" when it faults.
>
I have succeeded in getting the debugger to break early on during boot.
I have it set to break at start_here, in arch/powerpc/kernel/head_32.S.
My U-Boot bootloader indicates that the fdt is being loaded to address
0x7f8000, which translates to VA 0xc07f8000. See this output:
Booting using the fdt blob at 0x2269f1c
Uncompressing Kernel Image ... OK
Loading Ramdisk to 0fea0000, end 0ff76699 ... OK
Loading Device Tree to 007f8000, end 007ff78f ... OK
As soon an the debugger hit the start_here breakpoint, I ran the
following command. It should dump out the flat device tree to a file,
which I can then analyze:
(gdb) dump memory ~/fdt.bin 0xc07f8000 0xc07ff78f
On the good kernel (CONFIG_PROVE_LOCKING=n), I get a valid device tree
in fdt.bin. I see the stuff I would expect.
On the bad kernel (CONFIG_PROVE_LOCKING=y), I get all zeroes in fdt.bin.
So clearly something is overwriting the fdt.
However, note that this happens *before* lockdep_init() runs. Grepping
for CONFIG_PROVE_LOCKING in arch/powerpc and drivers/of shows nothing.
I'm not sure exactly how this is related to lockdep.
Some more suggestions for things to try would be great. For now, I'm
going to try getting the debugger to break near the end of U-Boot, to
see if the memory is overwritten there, and not in Linux.
Ira
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
2010-09-09 16:23 ` Ira W. Snyder
@ 2010-09-09 18:44 ` Ira W. Snyder
2010-09-09 19:10 ` Timur Tabi
2010-09-09 19:33 ` Ira W. Snyder
2010-09-09 21:58 ` Benjamin Herrenschmidt
1 sibling, 2 replies; 24+ messages in thread
From: Ira W. Snyder @ 2010-09-09 18:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt, peterz, mingo, linuxppc-dev
On Thu, Sep 09, 2010 at 09:23:07AM -0700, Ira W. Snyder wrote:
> On Thu, Sep 09, 2010 at 12:58:16PM +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2010-09-08 at 19:52 -0700, Ira W. Snyder wrote:
> > >
> > > I will attempt to get the debugger to stop at start_kernel. I'm having
> > > trouble driving the JTAG debugger (a BDI2000). I have used Denx's
> > > guide
> > > [1] in the past, but the section on debugging the kernel itself is now
> > > missing.
> > >
> > > [1] http://www.denx.de/wiki/view/DULG/DebuggingLinuxKernel
> > >
> > > I'll keep trying.
> >
> > start_kernel might be too late...
> >
> > You can also hack thing :-) Like in the asm, before machine_init(),
> > stick something in the DABR and put a HW breakpoint with the BDI2000 on
> > the Data Access exception handler to "catch" when it faults.
> >
>
> I have succeeded in getting the debugger to break early on during boot.
> I have it set to break at start_here, in arch/powerpc/kernel/head_32.S.
>
> My U-Boot bootloader indicates that the fdt is being loaded to address
> 0x7f8000, which translates to VA 0xc07f8000. See this output:
>
> Booting using the fdt blob at 0x2269f1c
> Uncompressing Kernel Image ... OK
> Loading Ramdisk to 0fea0000, end 0ff76699 ... OK
> Loading Device Tree to 007f8000, end 007ff78f ... OK
>
> As soon an the debugger hit the start_here breakpoint, I ran the
> following command. It should dump out the flat device tree to a file,
> which I can then analyze:
>
> (gdb) dump memory ~/fdt.bin 0xc07f8000 0xc07ff78f
>
> On the good kernel (CONFIG_PROVE_LOCKING=n), I get a valid device tree
> in fdt.bin. I see the stuff I would expect.
>
> On the bad kernel (CONFIG_PROVE_LOCKING=y), I get all zeroes in fdt.bin.
> So clearly something is overwriting the fdt.
>
> However, note that this happens *before* lockdep_init() runs. Grepping
> for CONFIG_PROVE_LOCKING in arch/powerpc and drivers/of shows nothing.
> I'm not sure exactly how this is related to lockdep.
>
> Some more suggestions for things to try would be great. For now, I'm
> going to try getting the debugger to break near the end of U-Boot, to
> see if the memory is overwritten there, and not in Linux.
>
Here is some more information. After tracing U-Boot's execution, I've
found that U-Boot is not the problem. The FDT is correct in-memory at
the point it jumps into the kernel. I literally halted it on the
instruction before the jmp and checked.
I've also found that setting a breakpoint at 0x0 stops right when the
Linux kernel starts, at symbol _start. AFAIK, the MMU is not yet
enabled, so I have to subtract 0xc0000000 from all addresses.
Single stepping through the initial assembly portion of kernel startup
shows that the FDT gets clobbered during the function early_init(). This
trace is reproduced below.
For whatever reason, even when single stepping, the debugger absolutely
refuses to enter the early_init function.
Misc Information:
1) 0xd00dfeed is an FDT magic number
2) 0x7f8000 is the physical address of the FDT in memory
(gdb) info break
Num Type Disp Enb Address What
2 hw breakpoint keep y 0x00000000 /home/iws/devel/linux-2.6/arch/powerpc/kernel/head_32.S:72
breakpoint already hit 3 times
(gdb) detach
Ending remote debugging.
(gdb) target remote bdi2k:2001
Remote debugging using bdi2k:2001
0x0ffbe760 in ?? ()
(gdb) continue
Continuing.
Breakpoint 2, _stext () at /home/iws/devel/linux-2.6/arch/powerpc/kernel/head_32.S:72
72 nop /* used by __secondary_hold on prep (mtx) and chrp smp */
Current language: auto; currently asm
(gdb) print /x *0x7f8000
$6 = 0xd00dfeed
(gdb) s
73 nop /* used by __secondary_hold on prep (mtx) and chrp smp */
(gdb) s
74 nop
(gdb) s
__start () at /home/iws/devel/linux-2.6/arch/powerpc/kernel/head_32.S:113
113 cmpwi 0,r5,0
(gdb) s
114 beq 1f
(gdb) s
142 1: mr r31,r3 /* save parameters */
(gdb) s
143 mr r30,r4
(gdb) s
144 li r24,0 /* cpu # */
(gdb) s
151 bl early_init
(gdb) print /x *0x7f8000
$7 = 0xd00dfeed
(gdb) s
__start () at /home/iws/devel/linux-2.6/arch/powerpc/kernel/head_32.S:156
156 bl mmu_off
(gdb) print /x *0x7f8000
$8 = 0x0
Ira
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
2010-09-09 18:44 ` Ira W. Snyder
@ 2010-09-09 19:10 ` Timur Tabi
2010-09-09 19:36 ` Ira W. Snyder
2010-09-09 19:33 ` Ira W. Snyder
1 sibling, 1 reply; 24+ messages in thread
From: Timur Tabi @ 2010-09-09 19:10 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: peterz, mingo, linuxppc-dev
On Thu, Sep 9, 2010 at 1:44 PM, Ira W. Snyder <iws@ovro.caltech.edu> wrote:
> Single stepping through the initial assembly portion of kernel startup
> shows that the FDT gets clobbered during the function early_init(). This
> trace is reproduced below.
Have you tried also enabling CONFIG_DEBUG_LOCK_ALLOC? These two
config options are related.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
2010-09-09 18:44 ` Ira W. Snyder
2010-09-09 19:10 ` Timur Tabi
@ 2010-09-09 19:33 ` Ira W. Snyder
1 sibling, 0 replies; 24+ messages in thread
From: Ira W. Snyder @ 2010-09-09 19:33 UTC (permalink / raw)
To: Benjamin Herrenschmidt, peterz, mingo, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 3532 bytes --]
On Thu, Sep 09, 2010 at 11:44:46AM -0700, Ira W. Snyder wrote:
[ snip a bunch of info: summary below ]
>
> I've also found that setting a breakpoint at 0x0 stops right when the
> Linux kernel starts, at symbol _start. AFAIK, the MMU is not yet
> enabled, so I have to subtract 0xc0000000 from all addresses.
>
> Single stepping through the initial assembly portion of kernel startup
> shows that the FDT gets clobbered during the function early_init(). This
> trace is reproduced below.
>
> For whatever reason, even when single stepping, the debugger absolutely
> refuses to enter the early_init function.
>
> Misc Information:
> 1) 0xd00dfeed is an FDT magic number
> 2) 0x7f8000 is the physical address of the FDT in memory
>
I have gotten the debugger to enter early_init(). I had to remove the
__init annotation on the function. I guess the debugger doesn't cope
with the extra sections that Linux uses.
(gdb) target remote bdi2k:2001
Remote debugging using bdi2k:2001
0xfc0034e8 in ?? ()
(gdb) info break
Num Type Disp Enb Address What
1 hw breakpoint keep y 0x00000000 /home/iws/devel/linux-2.6/arch/powerpc/kernel/head_32.S:72
breakpoint already hit 1 time
(gdb) continue
Continuing.
Breakpoint 1, _stext () at /home/iws/devel/linux-2.6/arch/powerpc/kernel/head_32.S:72
72 nop /* used by __secondary_hold on prep (mtx) and chrp smp */
Current language: auto; currently asm
(gdb) s
73 nop /* used by __secondary_hold on prep (mtx) and chrp smp */
(gdb) s
74 nop
(gdb) s
__start () at /home/iws/devel/linux-2.6/arch/powerpc/kernel/head_32.S:113
113 cmpwi 0,r5,0
(gdb) s
114 beq 1f
(gdb) s
142 1: mr r31,r3 /* save parameters */
(gdb) s
143 mr r30,r4
(gdb) s
144 li r24,0 /* cpu # */
(gdb) s
151 bl early_init
(gdb) s
early_init (dt_ptr=8355840) at /home/iws/devel/linux-2.6/arch/powerpc/kernel/setup_32.c:82
82 {
Current language: auto; currently c
(gdb) s
88 memset_io((void __iomem *)PTRRELOC(&__bss_start), 0,
(gdb) print /x *0x7f8000
$22 = 0xd00dfeed
(gdb) n
82 {
(gdb) n
88 memset_io((void __iomem *)PTRRELOC(&__bss_start), 0,
(gdb) print __bss_start
$23 = 0xc0369000 <Address 0xc0369000 out of bounds>
(gdb) print __bss_stop
$25 = 0xc08a0c48 <Address 0xc08a0c48 out of bounds>
(gdb) print /x *0x7f8000
$26 = 0xd00dfeed
(gdb) n
83 unsigned long offset = reloc_offset();
(gdb) print /x *0x7f8000
$27 = 0xd00dfeed
(gdb) n
88 memset_io((void __iomem *)PTRRELOC(&__bss_start), 0,
(gdb) print /x *0x7f8000
$28 = 0xd00dfeed
(gdb) n
55 DEF_PCI_AC_NORET(memset_io, (PCI_IO_ADDR a, int c, unsigned long n),
(gdb) print /x *0x7f8000
$29 = 0xd00dfeed
(gdb) n
95 spec = identify_cpu(offset, mfspr(SPRN_PVR));
(gdb) print /x *0x7f8000
$30 = 0x0
This shows that the memset_io() in early_init() is zeroing the FDT. It
appears that CONFIG_PROVE_LOCKING increases the BSS size significantly,
and that's what is causing the true error. It isn't a lockdep problem,
it is a "the BSS is too big" problem.
Unfortunately, I'm now at a loss on how to fix this. Why does the
bootloader put the FDT so close to the kernel? Is this a bootloader
problem? Is it a configuration problem on my part?
I'm booting with a FIT image. The source file is inlined below. By
U-Boot bootm command is trivial:
dhcp 2000000 carma.itb ; bootm 2000000
Thanks,
Ira
[-- Attachment #2: carma.its --]
[-- Type: text/plain, Size: 1148 bytes --]
/*
* U-boot uImage source file with CARMA kernel, ramdisk, and FDT blob
*
* Compile with:
* $ mkimage -f carma.its carma.itb
*/
/dts-v1/;
/ {
description = "CARMA kernel, ramdisk, and FDT blob";
#address-cells = <1>;
images {
kernel@1 {
description = "Linux 2.6.36rc3";
data = /incbin/("./vmlinux.bin.gz");
type = "kernel";
arch = "ppc";
os = "linux";
compression = "gzip";
load = <0x0>;
entry = <0x0>;
hash@1 {
algo = "md5";
};
hash@2 {
algo = "sha1";
};
};
ramdisk@1 {
description = "CARMA PPC Generic Ramdisk";
data = /incbin/("./initramfs-generic-ppc.cpio.gz");
type = "ramdisk";
arch = "ppc";
os = "linux";
compression = "gzip";
load = <0x0>;
hash@1 {
algo = "sha1";
};
};
fdt@1 {
description = "CARMA FDT";
data = /incbin/("./carma.dtb");
type = "flat_dt";
arch = "ppc";
compression = "none";
hash@1 {
algo = "crc32";
};
};
};
configurations {
default = "config@1";
config@1 {
description = "CARMA 2.6.36rc3 configuration";
kernel = "kernel@1";
ramdisk = "ramdisk@1";
fdt = "fdt@1";
};
};
};
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
2010-09-09 19:10 ` Timur Tabi
@ 2010-09-09 19:36 ` Ira W. Snyder
2010-09-09 19:40 ` Timur Tabi
2010-09-09 22:01 ` Benjamin Herrenschmidt
0 siblings, 2 replies; 24+ messages in thread
From: Ira W. Snyder @ 2010-09-09 19:36 UTC (permalink / raw)
To: Timur Tabi; +Cc: peterz, mingo, linuxppc-dev
On Thu, Sep 09, 2010 at 02:10:59PM -0500, Timur Tabi wrote:
> On Thu, Sep 9, 2010 at 1:44 PM, Ira W. Snyder <iws@ovro.caltech.edu> wrote:
>
> > Single stepping through the initial assembly portion of kernel startup
> > shows that the FDT gets clobbered during the function early_init(). This
> > trace is reproduced below.
>
> Have you tried also enabling CONFIG_DEBUG_LOCK_ALLOC? These two
> config options are related.
>
Yes, I have had it enabled the whole time.
As noted in another email, it appears that U-Boot puts the FDT in such a
place that Linux overwrites it with the BSS. The CONFIG_PROVE_LOCKING=y
option expands the BSS by a large amount, which causes the error. It
isn't directly lockdep related.
I don't know if this is a U-Boot problem or a Linux problem. I have no
idea how to fix the bug.
Thanks,
Ira
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
2010-09-09 19:36 ` Ira W. Snyder
@ 2010-09-09 19:40 ` Timur Tabi
2010-09-09 20:06 ` Ira W. Snyder
2010-09-09 22:01 ` Benjamin Herrenschmidt
1 sibling, 1 reply; 24+ messages in thread
From: Timur Tabi @ 2010-09-09 19:40 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: peterz, mingo, linuxppc-dev
Ira W. Snyder wrote:
> As noted in another email, it appears that U-Boot puts the FDT in such a
> place that Linux overwrites it with the BSS. The CONFIG_PROVE_LOCKING=y
> option expands the BSS by a large amount, which causes the error. It
> isn't directly lockdep related.
>
> I don't know if this is a U-Boot problem or a Linux problem. I have no
> idea how to fix the bug.
I wonder if this patch that I wrote for U-Boot will fix the problem:
http://lists.denx.de/pipermail/u-boot/2010-May/071822.html
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
2010-09-09 19:40 ` Timur Tabi
@ 2010-09-09 20:06 ` Ira W. Snyder
2010-09-09 20:13 ` Timur Tabi
0 siblings, 1 reply; 24+ messages in thread
From: Ira W. Snyder @ 2010-09-09 20:06 UTC (permalink / raw)
To: Timur Tabi; +Cc: peterz, mingo, linuxppc-dev
On Thu, Sep 09, 2010 at 02:40:50PM -0500, Timur Tabi wrote:
> Ira W. Snyder wrote:
> > As noted in another email, it appears that U-Boot puts the FDT in such a
> > place that Linux overwrites it with the BSS. The CONFIG_PROVE_LOCKING=y
> > option expands the BSS by a large amount, which causes the error. It
> > isn't directly lockdep related.
> >
> > I don't know if this is a U-Boot problem or a Linux problem. I have no
> > idea how to fix the bug.
>
> I wonder if this patch that I wrote for U-Boot will fix the problem:
>
> http://lists.denx.de/pipermail/u-boot/2010-May/071822.html
>
Nope, I tried it and it doesn't fix the problem. It relocates the FDT to
exactly the same address as before the patch.
I think the problem is that the U-Boot loader doesn't take into account
the Linux kernel's BSS size, and puts the FDT too close.
Here is the relevant U-Boot output after applying your patch. It was not
changed from the previous output.
Booting using the fdt blob at 0x226a278
Uncompressing Kernel Image ... OK
Loading Ramdisk to 0fe9f000, end 0ff75699 ... OK
Loading Device Tree to 007f8000, end 007ff78f ... OK
My ramdisk is right near the end of RAM. This board has 256MB of RAM.
0x0ff75699 / 1024 / 1024 == 255.4586
The FDT is just before the 8MB boundary:
0x007ff78f / 1024 / 1024 == 7.9979
My uncompressed vmlinux.bin.gz is ~3.5MB:
iws@rena ~/devel/correlator/fit-image $ zcat vmlinux.bin.gz > vmlinux.bin
iws@rena ~/devel/correlator/fit-image $ du -b vmlinux.bin
3573068 vmlinux.bin
As posted in my other email, Linux's BSS is ~5.2MB:
(gdb) print __bss_start
$23 = 0xc0369000 <Address 0xc0369000 out of bounds>
(gdb) print __bss_stop
$25 = 0xc08a0c48 <Address 0xc08a0c48 out of bounds>
(0xc08a0c48 - 0xc0369000) / 1024 / 1024 == 5.21784210205078125
Total (code + BSS): 3573068 + 5471304 == 9044372 (~8.62MB)
That easily overruns the location where U-Boot puts the FDT. Is this a
U-Boot bug, meaning I should post this information on the U-Boot
mailing list?
Thanks,
Ira
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
2010-09-09 20:06 ` Ira W. Snyder
@ 2010-09-09 20:13 ` Timur Tabi
2010-09-09 20:31 ` Ira W. Snyder
0 siblings, 1 reply; 24+ messages in thread
From: Timur Tabi @ 2010-09-09 20:13 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: peterz, mingo, linuxppc-dev
Ira W. Snyder wrote:
> That easily overruns the location where U-Boot puts the FDT. Is this a
> U-Boot bug, meaning I should post this information on the U-Boot
> mailing list?
Possibly.
I am under the impression that the memory in the boot block that contains
the FDT is marked as "reserved" in the device tree, so that the kernel
doesn't overwrite it. However, that obviously isn't helpful if we haven't
parsed the device tree yet.
What concerns me is this in U-Boot:
/*
* For booting Linux, the board info and command line data
* have to be in the first 16 MB of memory, since this is
* the maximum mapped by the Linux kernel during initialization.
*/
#define CONFIG_SYS_BOOTMAPSZ (16 << 20) /* Initial Memory map for Linux*/
If the 16MB mapping limit is true, then does this mean that the Linux's BSS
is larger than the memory that is mapped? If so, that means that Linux
can't even access all of its BSS at this point. Somehow, I doubt that.
Can you try increasing the size of CONFIG_SYS_BOOTMAPSZ? Combined with my
always-relocate-fdt, I think this will force the FDT to be placed higher in
memory.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
2010-09-09 20:13 ` Timur Tabi
@ 2010-09-09 20:31 ` Ira W. Snyder
2010-09-09 20:36 ` Timur Tabi
0 siblings, 1 reply; 24+ messages in thread
From: Ira W. Snyder @ 2010-09-09 20:31 UTC (permalink / raw)
To: Timur Tabi; +Cc: peterz, mingo, linuxppc-dev
On Thu, Sep 09, 2010 at 03:13:17PM -0500, Timur Tabi wrote:
> Ira W. Snyder wrote:
> > That easily overruns the location where U-Boot puts the FDT. Is this a
> > U-Boot bug, meaning I should post this information on the U-Boot
> > mailing list?
>
> Possibly.
>
> I am under the impression that the memory in the boot block that contains
> the FDT is marked as "reserved" in the device tree, so that the kernel
> doesn't overwrite it. However, that obviously isn't helpful if we haven't
> parsed the device tree yet.
>
> What concerns me is this in U-Boot:
>
> /*
> * For booting Linux, the board info and command line data
> * have to be in the first 16 MB of memory, since this is
> * the maximum mapped by the Linux kernel during initialization.
> */
> #define CONFIG_SYS_BOOTMAPSZ (16 << 20) /* Initial Memory map for Linux*/
>
> If the 16MB mapping limit is true, then does this mean that the Linux's BSS
> is larger than the memory that is mapped? If so, that means that Linux
> can't even access all of its BSS at this point. Somehow, I doubt that.
>
> Can you try increasing the size of CONFIG_SYS_BOOTMAPSZ? Combined with my
> always-relocate-fdt, I think this will force the FDT to be placed higher in
> memory.
>
That did it!
I'm using include/configs/MPC8349EMDS.h. On that board,
CONFIG_SYS_BOOTMAPSZ is 8MB. Boosting it to 16MB fixed the problem and
the kernel now boots.
I'll make a post to the U-Boot list asking if this should be boosted for
MPC8349EMDS (and others?). It is easy to build a kernel that overruns
this limit. Other than debugging options, my kernel is fairly minimal,
only a few drivers are built in.
I'm using your always-relocate-fdt patch. Your patch made no difference
to the FDT location. U-Boot with and without your patch both work fine,
as soon as I boosted CONFIG_SYS_BOOTMAPSZ to 16MB.
With your patch:
Booting using the fdt blob at 0x226a278
Uncompressing Kernel Image ... OK
Loading Ramdisk to 0fe9f000, end 0ff75699 ... OK
Loading Device Tree to 00ff8000, end 00fff78f ... OK
Without your patch:
Booting using the fdt blob at 0x226a278
Uncompressing Kernel Image ... OK
Loading Ramdisk to 0fe9f000, end 0ff75699 ... OK
Loading Device Tree to 00ff8000, end 00fff78f ... OK
Thanks,
Ira
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
2010-09-09 20:31 ` Ira W. Snyder
@ 2010-09-09 20:36 ` Timur Tabi
2010-09-09 20:55 ` Ira W. Snyder
0 siblings, 1 reply; 24+ messages in thread
From: Timur Tabi @ 2010-09-09 20:36 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: peterz, mingo, linuxppc-dev
Ira W. Snyder wrote:
> That did it!
Yea!
> I'm using include/configs/MPC8349EMDS.h. On that board,
> CONFIG_SYS_BOOTMAPSZ is 8MB. Boosting it to 16MB fixed the problem and
> the kernel now boots.
Ah, yes. I believe the reason that is the case is because some of those
boards were shipped with only 8MB of RAM.
> I'll make a post to the U-Boot list asking if this should be boosted for
> MPC8349EMDS (and others?). It is easy to build a kernel that overruns
> this limit. Other than debugging options, my kernel is fairly minimal,
> only a few drivers are built in.
I think we should first determine if the kernel boot map limit really is
16MB. If it's more than that, then we should consider making it match.
Assuming, of course, that the U-Boot code can handle a situation where
CONFIG_SYS_BOOTMAPSZ is larger than the actual amount of RAM.
> I'm using your always-relocate-fdt patch. Your patch made no difference
> to the FDT location. U-Boot with and without your patch bo
My patch only does something if the FDT is already located inside the boot
map. Since you were expanding the size of the boot map, there's a chance
that the FDT was located between 8MB and 16MB, and if so, my patch would
have made a difference.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
2010-09-09 20:36 ` Timur Tabi
@ 2010-09-09 20:55 ` Ira W. Snyder
2010-09-09 21:19 ` Timur Tabi
0 siblings, 1 reply; 24+ messages in thread
From: Ira W. Snyder @ 2010-09-09 20:55 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
On Thu, Sep 09, 2010 at 03:36:31PM -0500, Timur Tabi wrote:
> Ira W. Snyder wrote:
> > That did it!
>
> Yea!
>
> > I'm using include/configs/MPC8349EMDS.h. On that board,
> > CONFIG_SYS_BOOTMAPSZ is 8MB. Boosting it to 16MB fixed the problem and
> > the kernel now boots.
>
> Ah, yes. I believe the reason that is the case is because some of those
> boards were shipped with only 8MB of RAM.
>
> > I'll make a post to the U-Boot list asking if this should be boosted for
> > MPC8349EMDS (and others?). It is easy to build a kernel that overruns
> > this limit. Other than debugging options, my kernel is fairly minimal,
> > only a few drivers are built in.
>
> I think we should first determine if the kernel boot map limit really is
> 16MB. If it's more than that, then we should consider making it match.
> Assuming, of course, that the U-Boot code can handle a situation where
> CONFIG_SYS_BOOTMAPSZ is larger than the actual amount of RAM.
>
I have no idea how to determine this.
The code that caused the problem runs so early in boot that the MMU is
not running yet. Looking through the tiny bit of code, it appears that
it just uses whatever the bootloader set up for it. It hasn't gotten to
the initial_bats function yet.
The comment in initial_bats (arch/powerpc/kernel/head_32.S) says:
/*
* On 601, we use 3 BATs to map up to 24M of RAM at _PAGE_OFFSET
* (we keep one for debugging) and on others, we use one 256M BAT.
*/
I think the MPC8349EA would be a 603 CPU, meaning that we could increase
CONFIG_SYS_BOOTMAPSZ up to 256MB (if the board had that much RAM).
> > I'm using your always-relocate-fdt patch. Your patch made no difference
> > to the FDT location. U-Boot with and without your patch bo
>
> My patch only does something if the FDT is already located inside the boot
> map. Since you were expanding the size of the boot map, there's a chance
> that the FDT was located between 8MB and 16MB, and if so, my patch would
> have made a difference.
>
Yep, you're exactly correct. I tried loading my FIT image to a lower
address (0xa00000 == 10MB), both with and without your patch:
Without your patch (vanilla U-Boot):
Verifying Hash Integrity ... crc32+ OK
Booting using the fdt blob at 0xc6a278
Uncompressing Kernel Image ... OK
Loading Ramdisk to 0fe9f000, end 0ff75699 ... OK
With your patch:
Verifying Hash Integrity ... crc32+ OK
Booting using the fdt blob at 0xc42d6c
Uncompressing Kernel Image ... OK
Loading Ramdisk to 0fe9f000, end 0ff75699 ... OK
Loading Device Tree to 00ff8000, end 00fff84f ... OK
You'll see that your patch now relocated the FDT. It didn't cause any
problems. I'll post to the thread on the U-Boot ML.
[ dropped mingo and peterz from the CC list, they're not powerpc people ]
Thanks,
Ira
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
2010-09-09 20:55 ` Ira W. Snyder
@ 2010-09-09 21:19 ` Timur Tabi
0 siblings, 0 replies; 24+ messages in thread
From: Timur Tabi @ 2010-09-09 21:19 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: Kumar Gala, linuxppc-dev
Ira W. Snyder wrote:
> I have no idea how to determine this.
>
> The code that caused the problem runs so early in boot that the MMU is
> not running yet. Looking through the tiny bit of code, it appears that
> it just uses whatever the bootloader set up for it. It hasn't gotten to
> the initial_bats function yet.
I just spoke to Kumar, and he said that the 8MB is just historical. We ran
into the same exact problem that you ran into, except it was with a normal
kernel, so we changed 8MB to 16MB on our 85xx boards, but we never went back
and made the same change to 83xx boards.
So it should be safe to change CONFIG_SYS_BOOTMAPSZ from 8MB to 16MB on all
83xx systems. However, U-Boot does not verify that CONFIG_SYS_BOOTMAPSZ <=
the actual amount of RAM in the system, so we need to make sure that
CONFIG_SYS_BOOTMAPSZ isn't increased on any board that actually did ship
with only 8MB of RAM. My guess is that no such board exists, but I will get
confirmation.
However, this comment for CONFIG_SYS_BOOTMAPSZ still bothers me:
/*
* For booting Linux, the board info and command line data
* have to be in the first 8 MB of memory, since this is
* the maximum mapped by the Linux kernel during initialization.
*/
This same comment says 16MB on 85xx systems, so I don't think the statement
about "maximum mapped by the Linux kernel" is really true. Maybe someone
else can shed some light on this.
> I think the MPC8349EA would be a 603 CPU, meaning that we could increase
> CONFIG_SYS_BOOTMAPSZ up to 256MB (if the board had that much RAM).
Except that I'm still not sure what CONFIG_SYS_BOOTMAPSZ really means. I
was under the impression that CONFIG_MAX_MEM_MAPPED is the actual value of
the size of the mapping that U-Boot creates for the kernel. When the kernel
initializes the MMU for its own purposes, does it limit anything to 16MB? I
seriously doubt it.
> You'll see that your patch now relocated the FDT. It didn't cause any
> problems. I'll post to the thread on the U-Boot ML.
Yes, please. I need someone to confirm that he tested my patch.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
2010-09-09 16:23 ` Ira W. Snyder
2010-09-09 18:44 ` Ira W. Snyder
@ 2010-09-09 21:58 ` Benjamin Herrenschmidt
2010-09-09 22:11 ` Scott Wood
1 sibling, 1 reply; 24+ messages in thread
From: Benjamin Herrenschmidt @ 2010-09-09 21:58 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: peterz, mingo, linuxppc-dev
> I have succeeded in getting the debugger to break early on during boot.
> I have it set to break at start_here, in arch/powerpc/kernel/head_32.S.
>
> My U-Boot bootloader indicates that the fdt is being loaded to address
> 0x7f8000, which translates to VA 0xc07f8000. See this output:
>
> Booting using the fdt blob at 0x2269f1c
> Uncompressing Kernel Image ... OK
> Loading Ramdisk to 0fea0000, end 0ff76699 ... OK
> Loading Device Tree to 007f8000, end 007ff78f ... OK
>
> As soon an the debugger hit the start_here breakpoint, I ran the
> following command. It should dump out the flat device tree to a file,
> which I can then analyze:
>
> (gdb) dump memory ~/fdt.bin 0xc07f8000 0xc07ff78f
>
> On the good kernel (CONFIG_PROVE_LOCKING=n), I get a valid device tree
> in fdt.bin. I see the stuff I would expect.
>
> On the bad kernel (CONFIG_PROVE_LOCKING=y), I get all zeroes in fdt.bin.
> So clearly something is overwriting the fdt.
>
> However, note that this happens *before* lockdep_init() runs. Grepping
> for CONFIG_PROVE_LOCKING in arch/powerpc and drivers/of shows nothing.
> I'm not sure exactly how this is related to lockdep.
>
> Some more suggestions for things to try would be great. For now, I'm
> going to try getting the debugger to break near the end of U-Boot, to
> see if the memory is overwritten there, and not in Linux.
I suspect your uboot setup. The one thing lockdep does is massively
increase the amount of kernel bss. I suspect you are just overlapping DT
and bss and hence wiping out the DT when clearing the bss.
I would have expected uboot to warn (the kernel ELF header contains the
BSS size) but apparently that isn't the case.
Cheers,
Ben.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
2010-09-09 19:36 ` Ira W. Snyder
2010-09-09 19:40 ` Timur Tabi
@ 2010-09-09 22:01 ` Benjamin Herrenschmidt
1 sibling, 0 replies; 24+ messages in thread
From: Benjamin Herrenschmidt @ 2010-09-09 22:01 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: peterz, mingo, linuxppc-dev, Timur Tabi
On Thu, 2010-09-09 at 12:36 -0700, Ira W. Snyder wrote:
> On Thu, Sep 09, 2010 at 02:10:59PM -0500, Timur Tabi wrote:
> > On Thu, Sep 9, 2010 at 1:44 PM, Ira W. Snyder <iws@ovro.caltech.edu> wrote:
> >
> > > Single stepping through the initial assembly portion of kernel startup
> > > shows that the FDT gets clobbered during the function early_init(). This
> > > trace is reproduced below.
> >
> > Have you tried also enabling CONFIG_DEBUG_LOCK_ALLOC? These two
> > config options are related.
> >
>
> Yes, I have had it enabled the whole time.
>
> As noted in another email, it appears that U-Boot puts the FDT in such a
> place that Linux overwrites it with the BSS. The CONFIG_PROVE_LOCKING=y
> option expands the BSS by a large amount, which causes the error. It
> isn't directly lockdep related.
>
> I don't know if this is a U-Boot problem or a Linux problem. I have no
> idea how to fix the bug.
Definitely a u-boot problem. There must be a way to set where the fdt
goes somewhere.
Cheers,
Ben.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
2010-09-09 21:58 ` Benjamin Herrenschmidt
@ 2010-09-09 22:11 ` Scott Wood
2010-09-09 22:13 ` Benjamin Herrenschmidt
0 siblings, 1 reply; 24+ messages in thread
From: Scott Wood @ 2010-09-09 22:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: peterz, mingo, linuxppc-dev, Ira W. Snyder
On Fri, 10 Sep 2010 07:58:54 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> I would have expected uboot to warn (the kernel ELF header contains the
> BSS size) but apparently that isn't the case.
U-Boot doesn't use ELF files with Linux, so it has no idea where the
BSS is. uImage is just a wrapper around a flat binary.
-Scott
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
2010-09-09 22:11 ` Scott Wood
@ 2010-09-09 22:13 ` Benjamin Herrenschmidt
2010-09-09 22:16 ` Benjamin Herrenschmidt
2010-09-09 22:37 ` Scott Wood
0 siblings, 2 replies; 24+ messages in thread
From: Benjamin Herrenschmidt @ 2010-09-09 22:13 UTC (permalink / raw)
To: Scott Wood; +Cc: peterz, mingo, linuxppc-dev, Ira W. Snyder
On Thu, 2010-09-09 at 17:11 -0500, Scott Wood wrote:
> > I would have expected uboot to warn (the kernel ELF header contains
> the
> > BSS size) but apparently that isn't the case.
>
> U-Boot doesn't use ELF files with Linux, so it has no idea where the
> BSS is. uImage is just a wrapper around a flat binary.
Oh, right, I forgot about that... -1 for uboot there. Seriously, it's
time it grows the ability to load ELF or to at least stick an ELF in a
uImage... I've never understood the reasoning for that uImage wrapper
thingy. Definitely causes more problems than it solves in my experience.
Ben.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
2010-09-09 22:13 ` Benjamin Herrenschmidt
@ 2010-09-09 22:16 ` Benjamin Herrenschmidt
2010-09-09 22:37 ` Scott Wood
1 sibling, 0 replies; 24+ messages in thread
From: Benjamin Herrenschmidt @ 2010-09-09 22:16 UTC (permalink / raw)
To: Scott Wood; +Cc: peterz, mingo, linuxppc-dev, Ira W. Snyder
On Fri, 2010-09-10 at 08:13 +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2010-09-09 at 17:11 -0500, Scott Wood wrote:
> > > I would have expected uboot to warn (the kernel ELF header contains
> > the
> > > BSS size) but apparently that isn't the case.
> >
> > U-Boot doesn't use ELF files with Linux, so it has no idea where the
> > BSS is. uImage is just a wrapper around a flat binary.
>
> Oh, right, I forgot about that... -1 for uboot there. Seriously, it's
> time it grows the ability to load ELF or to at least stick an ELF in a
> uImage... I've never understood the reasoning for that uImage wrapper
> thingy. Definitely causes more problems than it solves in my experience.
Note that with ePAPR we know the top of mapped memory on entry, so
in theory, if the bootloader is fully ePAPR compliant we -could- detect
that case and move the FDT up to after the .dts before we clear the
bss... do we care enough tho ?
Even if we aren't totally ePAPR compliant, we could still try to move
it, if we hit the end of memory well... we won't do more damage than we
already did by by overwriting the dts in the first place.
Cheers,
Ben.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
2010-09-09 22:13 ` Benjamin Herrenschmidt
2010-09-09 22:16 ` Benjamin Herrenschmidt
@ 2010-09-09 22:37 ` Scott Wood
2010-09-09 22:49 ` Benjamin Herrenschmidt
2010-09-10 11:29 ` Wolfgang Denk
1 sibling, 2 replies; 24+ messages in thread
From: Scott Wood @ 2010-09-09 22:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: peterz, mingo, linuxppc-dev, Ira W. Snyder
On Fri, 10 Sep 2010 08:13:53 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Thu, 2010-09-09 at 17:11 -0500, Scott Wood wrote:
> > > I would have expected uboot to warn (the kernel ELF header contains
> > the
> > > BSS size) but apparently that isn't the case.
> >
> > U-Boot doesn't use ELF files with Linux, so it has no idea where the
> > BSS is. uImage is just a wrapper around a flat binary.
>
> Oh, right, I forgot about that... -1 for uboot there. Seriously, it's
> time it grows the ability to load ELF or to at least stick an ELF in a
> uImage...
It actually can load an ELF file, but it doesn't currently support
passing a device tree to it (only argc/argv text arguments, or some
vxworks stuff).
> I've never understood the reasoning for that uImage wrapper
> thingy. Definitely causes more problems than it solves in my experience.
Wolfgang was just defending it on the U-Boot list the past couple
days... seems like the main thing in its favor is the CRC, especially
as a final check before reflashing an image.
-Scott
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
2010-09-09 22:37 ` Scott Wood
@ 2010-09-09 22:49 ` Benjamin Herrenschmidt
2010-09-10 11:29 ` Wolfgang Denk
1 sibling, 0 replies; 24+ messages in thread
From: Benjamin Herrenschmidt @ 2010-09-09 22:49 UTC (permalink / raw)
To: Scott Wood; +Cc: peterz, mingo, linuxppc-dev, Ira W. Snyder
On Thu, 2010-09-09 at 17:37 -0500, Scott Wood wrote:
>
> Wolfgang was just defending it on the U-Boot list the past couple
> days... seems like the main thing in its favor is the CRC, especially
> as a final check before reflashing an image.
Right, then fwd my 2 cents:
Makes sense to have a wrapper like that for flashing, but
- It could/should contain an ELF
- u-boot should be capable to just load/boot the ELF, not everybody
uses flashable images (netboot anyone ? espectially when debugging) and
it's really a burden to do the wrapping all the time. In addition, we
just see how it can actually hurt due to losing information such as the
BSS size.
Cheers,
Ben.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
2010-09-09 22:37 ` Scott Wood
2010-09-09 22:49 ` Benjamin Herrenschmidt
@ 2010-09-10 11:29 ` Wolfgang Denk
1 sibling, 0 replies; 24+ messages in thread
From: Wolfgang Denk @ 2010-09-10 11:29 UTC (permalink / raw)
To: Scott Wood; +Cc: peterz, mingo, linuxppc-dev, Ira W. Snyder
Dear Scott Wood,
In message <20100909173735.503c4cc0@schlenkerla.am.freescale.net> you wrote:
>
> It actually can load an ELF file, but it doesn't currently support
> passing a device tree to it (only argc/argv text arguments, or some
> vxworks stuff).
I see no problems to extend U-Boot such that we support booting Linux
kernel images in form of ELF files. Ideally these should be wrapped
into FIT images to allow for easy combination of kernel and FDT into a
single file (useful for netboot).
> > I've never understood the reasoning for that uImage wrapper
> > thingy. Definitely causes more problems than it solves in my experience.
>
> Wolfgang was just defending it on the U-Boot list the past couple
> days... seems like the main thing in its favor is the CRC, especially
> as a final check before reflashing an image.
The additional file header serves a number of purposes; even if they
seem of little use to a developer they are really helpful in
production and maintenance/repair.
Assume you were to find out why a system (returned from a customer)
does not boot any more. Being able to identify the kernel image in
flash, with information about version (name string), image build time
and size is really, really helpful then. Of course it's also helpful
to be able to check if the image is OK or for example has been
(partially) overwritten.
The checksum protection is indeed a VERY useful thing.
If we hade similar checksum protection on the device tree we would
have been able to recognize the memory corruption that triggered this
thread MUCH easier.
Acutally this is my biggest critique on the FDT blob: that we cannot
detect corruptions like this.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
It is a good thing for an uneducated man to read books of quotations.
- Sir Winston Churchill _My Early Life_ ch. 9
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2010-09-10 11:29 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-09-08 23:21 CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?) Ira W. Snyder
2010-09-09 1:02 ` Benjamin Herrenschmidt
2010-09-09 2:52 ` Ira W. Snyder
2010-09-09 2:58 ` Benjamin Herrenschmidt
2010-09-09 16:23 ` Ira W. Snyder
2010-09-09 18:44 ` Ira W. Snyder
2010-09-09 19:10 ` Timur Tabi
2010-09-09 19:36 ` Ira W. Snyder
2010-09-09 19:40 ` Timur Tabi
2010-09-09 20:06 ` Ira W. Snyder
2010-09-09 20:13 ` Timur Tabi
2010-09-09 20:31 ` Ira W. Snyder
2010-09-09 20:36 ` Timur Tabi
2010-09-09 20:55 ` Ira W. Snyder
2010-09-09 21:19 ` Timur Tabi
2010-09-09 22:01 ` Benjamin Herrenschmidt
2010-09-09 19:33 ` Ira W. Snyder
2010-09-09 21:58 ` Benjamin Herrenschmidt
2010-09-09 22:11 ` Scott Wood
2010-09-09 22:13 ` Benjamin Herrenschmidt
2010-09-09 22:16 ` Benjamin Herrenschmidt
2010-09-09 22:37 ` Scott Wood
2010-09-09 22:49 ` Benjamin Herrenschmidt
2010-09-10 11:29 ` Wolfgang Denk
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).