[#3978] kernel traps into CPLB exception while build with bf536 selected on 2008R1 branch.

Submitted By: Sonic Zhang

Open Date

2008-03-21 04:44:26 Close Date

2008-07-20 23:15:23

Priority:

Medium Assignee:

Sonic Zhang

Status:

Closed Fixed In Release:

N/A

Found In Release:

N/A Release:

2008R1

Category:

N/A Board:

STAMP

Processor:

BF536 Silicon Revision:

Is this bug repeatable?:

Yes Resolution:

Fixed

Uboot version or rev.:

2008R1 Toolchain version or rev.:

2008R1

App binary format:

N/A

Summary: kernel traps into CPLB exception while build with bf536 selected on 2008R1 branch.

Details:

kernel traps into CPLB exception whiel build with bf536 selected on 2008R1 branch.

Follow-ups

--- 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

bug.

--- 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:

blackfin.uclinux.org/gf/project/uclinux-dist/forum/?action=ForumBrowse&_forum_action=MessageReply&message_id=52804

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

it did.

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

Sonic:

Can you attach a uImage and bugreport.tgz to replicate the problem?

Thanks

-Robin

--- 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.

-Robin

--- Sonic Zhang 2008-04-11 04:07:00

Finally, this bug is root caused to be wrong section definition in kernel link

script.

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

Good catch.

-Robin

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

script. If a section is not defined, it is not generated.

--- Sonic Zhang 2008-07-20 23:15:18

Fixed and closed.

Files

Changes

Commits

Dependencies

Duplicates

Associations