2008-01-16 10:06:55 Enable the memory protection unit
Jason Holden (UNITED STATES)
Message: 49670 I am testing an SVN kernel on a BF537, and there is a new option, "Enable the memory protection unit". If I enable this option, I get kernel panics (first panic is in ifconfig, and it degrades from there). If I disable the memory protection option, I boot just fine. I was wondering if this was expected?
-Jason
QuoteReplyEditDelete
2008-01-16 10:56:12 Re: Enable the memory protection unit
Robin Getz (UNITED STATES)
Message: 49672 Jason:
It is experimental - but it should not panic.
Can you post your dump message?
-Robin
QuoteReplyEditDelete
2008-01-16 11:55:40 Re: Enable the memory protection unit
Jason Holden (UNITED STATES)
Message: 49675
This is a test run with a 128MB 0.3 BF537 board. Kernel was unmodified, compiled for 128MB 0.3 silicon. I've also tested kernels compiled as 0.2 64MB on this same board and get similiar errors in ifconfig. Compiled with a freshly built svn toolchain. Full log is attached.
<snip>
SMSC LAN83C185: Registered new driver
bfin_mac_mdio: probed
bfin_mac: attached PHY driver [SMSC LAN83C185] (mii_bus:phy_addr=0:01, irq=-1, mdc_clk=2500000Hz(mdc_div=19)@sclk=100MHz)
bfin_mac: Version 1.1, Blackfin BF53[67] BF527 on-chip Ethernet MAC driver
bfin-spi bfin-spi.0: Blackfin BF5xx on-chip SPI Contoller Driver, Version 1.0, regs_base@ffc00500, dma channel@7
rtc-bfin rtc-bfin: rtc core: registered rtc-bfin as rtc0
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
rtc-bfin rtc-bfin: setting the system clock to 1970-01-02 19:05:36 (155136)
IP-Config: Complete:
device=eth0, addr=129.86.197.26, mask=255.255.0.0, gw=129.86.197.1,
host=wolf212, domain=, nis-domain=(none),
bootserver=129.86.24.144, rootserver=129.86.24.144, rootpath=
dma_alloc_init: dma_page @ 0x07a05000 - 256 pages at 0x07f00000
Data access CPLB miss
- Used by the MMU to signal a CPLB miss on a data access.
Defered Exception context
CURRENT PROCESS:
COMM=ifconfig PID=92
TEXT = 0x00c10040-0x00c1a560 DATA = 0x00c1a564-0x00c1d1e4
BSS = 0x00c1d1e4-0x00c1d894 USER-STACK = 0x00c1ef74
return address: [0x00c1400a]; contents of:
0x00c13fe0: 9560 4a70 9720 2f69 b0e0 2f67 05ec e800
0x00c13ff0: 0003 e3ff fd81 3220 e14d 00c1 e10d cf78
0x00c14000: cc00 c000 956e 0000 600f [9125] e300 0cf2
0x00c14010: 5207 4f40 5830 9728 6008 e56e 0020 e300
SEQUENCER STATUS: Not tainted
SEQSTAT: 00000026 IPEND: 0030 SYSCFG: 0006
HWERRCAUSE: 0x0
EXCAUSE : 0x26
RETE: <0x00000000> /* Maybe null pointer? */
RETN: <0x07ae4000> /* unknown address */
RETX: <0x00c1400a> [ ifconfig + 0x3fca ]
RETS: <0x00c13ff6> [ ifconfig + 0x3fb6 ]
PC : <0x00c1400a> [ ifconfig + 0x3fca ]
DCPLB_FAULT_ADDR: <0x07ae3bd4> /* unknown address */
ICPLB_FAULT_ADDR: <0x0007f3ec> { _sprintf + 0x0 }
PROCESSOR STATE:
R0 : 00000000 R1 : 00c1ef88 R2 : 00c1ef78 R3 : 00c1a54e
R4 : 00c10740 R5 : 00000003 R6 : 00000120 R7 : 00000001
P0 : 00c1ef78 P1 : 00c1d848 P2 : 00c1d84c P3 : 00c1ef78
P4 : d818d818 P5 : 00c1cf78 FP : 00c1ef0c SP : 07ae3f24
LB0: 07b0bd67 LT0: 07b0bd66 LC0: 00000000
LB1: 07b41959 LT1: 07b41958 LC1: 00000000
B0 : 00000000 L0 : 00000000 M0 : 00000000 I0 : 07ac0430
B1 : 00000000 L1 : 00000000 M1 : 00000000 I1 : 07ac03fd
B2 : 00000000 L2 : 00000000 M2 : 00000000 I2 : 00000000
B3 : 00000000 L3 : 00000000 M3 : 00000000 I3 : 00000000
A0.w: 00000000 A0.x: 00000000 A1.w: 00000000 A1.x: 00000000
USP : 00c1ef00 ASTAT: 02003005
No trace since you do not have CONFIG_DEBUG_BFIN_NO_KERN_HWTRACE enabled
Stack from 07ae3f04:
ffffe000 ffa00750 00144568 00144568 00144564 00000003 07ac053c ffa01992
00c1400a 00000030 00000026 00000000 07ae4000 00c1400a 00c1400a 00c13ff6
00000000 02003005 07b41959 07b0bd67 07b41958 07b0bd66 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 07ac03fd 07ac0430 00c1ef00 00c1ef0c 00c1cf78 d818d818
</snip>
128mb_0dot3_mem_protect.txt
QuoteReplyEditDelete
2008-01-18 20:18:08 Re: Enable the memory protection unit
Jason Holden (UNITED STATES)
Message: 49824 Any chance u-boot changes in the past few months could be causing this? The uboot version on my board is a couple months old.
I'm going to compile the same rev of software on my home machine (ubuntu instead of RHE4) and run it on a stock bf537 board and see if I get the same issue.
-Jason
QuoteReplyEditDelete
2008-01-18 20:36:06 Re: Enable the memory protection unit
Mike Frysinger (UNITED STATES)
Message: 49825 while anything is possible, i doubt it ... cplbs get turned off before executing linux from u-boot and the kernel should do the right thing and initialize them as if they were completely empty/corrupt/whatever
QuoteReplyEditDelete
2008-01-20 15:33:24 Re: Enable the memory protection unit
Jason Holden (UNITED STATES)
Message: 49866 I still get panics even with a stock 537 0.2 board. I've attached my .configs. Its basically just the stock configuration. I'm wondering why you guys haven't seen this. I've compiling with completely unmodifed uclinux r5977, linux r4098, toolchain r2138.
-Jason
config
config
QuoteReplyEditDelete
2008-01-20 17:25:36 Re: Enable the memory protection unit
Mike Frysinger (UNITED STATES)
Message: 49868 the MPU option was just added and hasnt seen any testing, so i imagine it's going to be rough for a while
QuoteReplyEditDelete
2008-01-20 19:18:32 Re: Enable the memory protection unit
Robin Getz (UNITED STATES)
Message: 49869 Hmm - you should not run it on any part with Anomaly 05000263 - which would mean 0.2 537 will not work. We should figure out how to add that to Kconfig, or put an #error in the code...
Mike/Bernd - any thoughts?
-Robin
QuoteReplyEditDelete
2008-01-20 20:03:53 Re: Enable the memory protection unit
Mike Frysinger (UNITED STATES)
Message: 49871 adding to one of the MPU files should be easy:
#if ANOMALY_05000263
# error MPU will not work while Anomaly 05000263 applies
#endif
QuoteReplyEditDelete
2008-01-21 13:17:12 Re: Enable the memory protection unit
Jason Holden (UNITED STATES)
Message: 49891 I'm not sure that this is specific to Anomaly 05000263 because my original test was on a 537 rev 0.3, which doesn't suffer from that anomaly. (see the log attached earlier in this thread).
-Jason
QuoteReplyEditDelete