[#3978] kernel traps into CPLB exception while build with bf536 selected on 2008R1 branch.
Submitted By: Sonic Zhang
2008-03-21 04:44:26 Close Date
Closed Fixed In Release:
Found In Release:
BF536 Silicon Revision:
Is this bug repeatable?:
Uboot version or rev.:
2008R1 Toolchain version or rev.:
App binary format:
Summary: kernel traps into CPLB exception while build with bf536 selected on 2008R1 branch.
kernel traps into CPLB exception whiel build with bf536 selected on 2008R1 branch.
--- Sonic Zhang 2008-03-24 23:11:45
Not a bug. A problem of L1 SRAM size difference on different chips. Move some
kernel code out of L1 SRAM solve this issue on bf536.
--- Mike Frysinger 2008-03-25 08:11:16
if there was L1 overflow, why didnt the kernel panic ? we have code
specifically in our init sequence to make sure overflows are caught ...
--- Sonic Zhang 2008-03-27 05:21:21
L1 code is loaded by uboot, how can init sequence catchs this overflow?
This kernel panic is cuased by CPLB violation. Because the CPLB entry for L1
bank B on bf536 doesn't exist.
--- Mike Frysinger 2008-03-27 08:24:32
L1 is not handled by U-Boot in anyway. the kernel does the relocation itself
and if any region is overflowed, it is supposed to call panic().
--- Sonic Zhang 2008-03-28 00:13:05
Yes, l1 code is copied to L1 sram at the very beginning of kernel start code.
But, no panic() is called when L1 region is overflowed, because panic() outputs
nothing at that time before UART is initialized. Current solution is to only
copy max L1 sram size of code and delay the exception. So, this is still not a
--- Mike Frysinger 2008-03-28 12:25:59
it is a bug because in this case, the panic was not triggered. why wasnt it
triggered ? things crashed when they got to userspace instead of panic-ing very
early. this is what we're investigating:
as for output, when we have earlyprintk enabled (like we do by default now),
you would see the output.
--- Sonic Zhang 2008-03-30 23:47:01
This is just a log of that discussion. There is no panic() in the L1 relocation
code in kernel, because you won't see any output in this case even with early
printk enabled. So, trigger pannic at that time is meaningless for debugging.
--- Sonic Zhang 2008-04-01 02:22:52
If no objection, I will close this bug.
--- Mike Frysinger 2008-04-01 14:33:24
i really dont understand your logic. if there was an overflow in L1, there
should have been a panic(). regardless of earlyprintk being enabled, the
booting process in the referred forum message would not have made it as far as
why did the crash occur for the user when building for a BF536 ? if the answer
is "L1 overflow", then why wasnt the early panic triggered ?
--- Robin Getz 2008-04-05 15:46:29
Can you attach a uImage and bugreport.tgz to replicate the problem?
--- Sonic Zhang 2008-04-10 03:54:26
Because the L1 overflow happens before the early printk is initialized. So, you
won't see anything even with panic.
--- Sonic Zhang 2008-04-10 03:56:01
By delaying the exception, user can know something is wrong with the L1 code.
--- Robin Getz 2008-04-10 08:18:25
L1 overflow and panic happens after earlyprintk is initialized - so it should
work with this.
--- Sonic Zhang 2008-04-11 04:07:00
Finally, this bug is root caused to be wrong section definition in kernel link
In bf536 with all data cache is enabled, there is no L1 data sram. Current link
script won't define section data_l1.cacheline_aligned in this case. But, if user
selects "put cacheline_aligned data into l1 sram" in kernel
menuconfig, this data section will be dropped and access to these data will
trigger data CPLB exception.
Do panic in l1 relocation code as well.
--- Robin Getz 2008-04-13 19:31:33
BTW - silently dropping sections doesn't sound like a good idea. Is that the
expected behavior from ld?
--- Sonic Zhang 2008-04-13 23:07:01
I think ld only output code sections according to the definition in the link
script. If a section is not defined, it is not generated.
--- Sonic Zhang 2008-04-13 23:07:12
I think ld only outputs code sections according to the definition in the link
--- Sonic Zhang 2008-07-20 23:15:18
Fixed and closed.
File Name File Type File Size Posted By
No Files Were Found