Linux Oops, MPS8260ADS, ELDK, 2.4.24

Hi All, I have spend about a week so far at trying to to get past this kernel oops, any thoughts or recommendations would be appreciated.

Build details; building under Redhat 8, using ELDK 3.0, compiling for the MPC8260ADS card, using the linux source found on the ELDK sources disk

Crash details; I have added print statements, and the code appears to reun right up until the phy is enabled in fcc_enet.c. Note my prints are "marked" with "wil".

Thanks for your considerations, Wil

U-Boot 1.0.2 (Mar 31 2004 - clk 16500000 - cpu_clk 132000000, cpm_clk 132000000, bus_clk 66000000

CPU: MPC8260 (HiP3 Rev 01, Mask A.1 1K22A-XC) at 132 MHz Board: Motorola MPC8260ADS I2C: ready DRAM: 16 MB

U-Boot 1.0.2 (Mar 31 2004 - 13:02:08)

MPC8260 Reset Status: Check Stop, External Soft, External Hard

MPC8260 Clock Configuration - Bus-to-Core Mult 2x, VCO Div 2, 60x Bus Freq 50-150, Core Freq 100-300 - dfbrg 1, corecnf 0x04, busdf 3, cpmdf 1, plldf 0, pllmf 1 - vco_out 264000000, scc_clk 66000000, brg_clk 16500000 - cpu_clk 132000000, cpm_clk 132000000, bus_clk 66000000

CPU: MPC8260 (HiP3 Rev 01, Mask A.1 1K22A-XC) at 132 MHz Board: Motorola MPC8260ADS I2C: ready DRAM: 16 MB FLASH: ### Unknown flash ID 8989FF89 AAAAFFAA at address FF800000 ### 0 kB In: serial Out: serial Err: serial Net: FCC2 ETHERNET Hit any key to stop autoboot: 0 => tftpboot Using FCC2 ETHERNET device TFTP from server 192.168.0.7; our IP address is 192.168.0.9 Filename 'vmlinux'. Load address: 0x100000 Loading: ################################################################# ##################################################### done Bytes transferred = 603659 (9360b hex) => bootm ## Booting image at 00100000 ... Image Name: Linux-2.4.24-pre2 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 603595 Bytes = 589.4 kB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Memory BAT mapping: BAT2=16Mb, BAT3=0Mb, residual: 0Mb Linux version 2.4.24-pre2 ( snipped-for-privacy@localhost.localdomain) (gcc version 3.2.2

287.85 BogoMIPS Memory: 14736k available (1040k kernel code, 348k data, 56k init, 0k highmem) Dentry cache hash table entries: 2048 (order: 2, 16384 bytes) Inode cache hash table entries: 1024 (order: 1, 8192 bytes) Mount cache hash table entries: 512 (order: 0, 4096 bytes) Buffer cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 4096 (order: 2, 16384 bytes) POSIX conformance testing by UNIFIX Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket wil main.c do_basic_setup(): pre do_initcalls wil main.c do_initcalls(): pre (*call)() 0 0xC0141F28 wil main.c do_initcalls(): pre (*call)() 1 0xC0141F2C wil main.c do_initcalls(): pre (*call)() 2 0xC0141F30 wil main.c do_initcalls(): pre (*call)() 3 0xC0141F34 wil main.c do_initcalls(): pre (*call)() 4 0xC0141F38 Starting kswapd wil main.c do_initcalls(): pre (*call)() 5 0xC0141F3C wil main.c do_initcalls(): pre (*call)() 6 0xC0141F40 wil main.c do_initcalls(): pre (*call)() 7 0xC0141F44 wil main.c do_initcalls(): pre (*call)() 8 0xC0141F48 wil main.c do_initcalls(): pre (*call)() 9 0xC0141F4C wil main.c do_initcalls(): pre (*call)() 10 0xC0141F50 wil main.c do_initcalls(): pre (*call)() 11 0xC0141F54 wil main.c do_initcalls(): pre (*call)() 12 0xC0141F58 wil main.c do_initcalls(): pre (*call)() 13 0xC0141F5C wil main.c do_initcalls(): pre (*call)() 14 0xC0141F60 wil main.c do_initcalls(): pre (*call)() 15 0xC0141F64 wil main.c do_initcalls(): pre (*call)() 16 0xC0141F68 wil main.c do_initcalls(): pre (*call)() 17 0xC0141F6C CPM UART driver version 0.01 ttyS0 on SCC1 at 0x8000, BRG7 ttyS1 on SCC2 at 0x8100, BRG1 wil tty_init: pre pty_init pty: 256 Unix98 ptys configured by Wil wil tty_init: post pty_init wil mem.c chr_dev_init: post tty_init wil main.c do_initcalls(): pre (*call)() 18 0xC0141F70 wil main.c do_initcalls(): pre (*call)() 19 0xC0141F74 wil genhd.c device_init(): start wil genhd.c device_init(): pre net_dev_init() wil dev.c net_dev_init: pre wil dev.c net_dev_init: pre-rx queues wil dev.c net_dev_init: pre add devices wil dev.c net_dev_init: pre unhook dev wil dev.c net_dev_init: pre init network devices wil fcc_enet.c init_fcc_startup: pre wil fcc_enet.c init_fcc_startup: pre enable the PHY Machine check in kernel mode. Caused by (from SRR1=49030): Transfer error ack signal Oops: machine check, sig: 7 NIP: C013DCDC XER: 00000000 LR: C013DCC4 SP: C01ABED0 REGS: c01abe20 TRAP: 0200 Not tainted MSR: 00049030 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 TASK = c01aa000[1] 'swapper' Last syscall: 120 last math 00000000 last altivec 00000000 GPR00: C013DCC4 C01ABED0 C01AA000 C010FB84 00001032 00000001 F0000000 00000000 GPR08: C01F1060 3460C013 C012ABAF F8000004 0000000D FFFFFFFF 00FFF000 007FFF10 GPR16: 00000000 00000001 007FFF00 C00A1F14 C00A1E20 C00A1784 C00A15E0 C00A1E4C GPR24: C00A1E40 C00A1E50 00000000 C0110000 C012AC34 C012AC34 C01AD400 F0011320 Call backtrace: C013DCC4 C013D708 C013CAF0 C013CB2C C013E24C C013C3A8 C0134658 C01346AC C00039D0 C0008318 Kernel panic: Attempted to kill init! Rebooting in 180 secon
Reply to
Wil Moloughney
Loading thread data ...

Have you run that through ksymoops? That would turn the callstack into a symbolic callstack, which might be interesting. Also, the machine check code should be pretty informative; have you looked into what causes a "transfer error ack" signal? You might need to look at the powerpc hardward guide and your board's hardware guide a bit.

- Dan

Reply to
Dan Kegel

Did you really bother to read the error messages, and try to understand what they could mean?

Should be working fine, normally.

Stop here. Do not continue.

What's happening here?

Looks to me as if the third byte (0xFF) is bogus.

Didnt you ask yourself what that means?

...

And did you decode the stack backtrace?

What does this give?

I recommend (and I really man it!) to solve problems one at a time, i. e. if you run into a problem you must not continue until it was solved or at least until at least you understand EXACTLY why it's happening.

Go back to step 1. Why is the flash detection in U-Boot failing for you? Are you absolutely sure your hardware is working?

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88   Web: www.denx.de
 Click to see the full signature
Reply to
Wolfgang Denk

Yes, I followed the error messages, but some were new to me and I did (and maybe still do not) understand what they are attempting to tell me. If I had not attempted to understand the error messages, I would have posted earlier. Posting to a newsgroup is not my first method (nor preferred) of solving problems.

Do you know if anyone else has run this version on the MPC8260ADS card?

100-300

This error shows up rarely. And was not the focus of the problem I was attempting to solve. I agree with solve one problem at a time, and so I was focusing on the linux oops.

The call traceback takes me right to where my print statements left me, in the original posting it shows it ends at; wil fcc_enet.c init_fcc_startup: pre enable the PHY Which is just before the phy is enabled within the function init_fcc_startup() within the file fcc_enet.c. I suspect enabling the phy may result an interrupt, and the oops is a result of the interrupt. But this is only a suspicion at this time.

I agree, see comments above.

As I said above, I rarely see this message. With respect to my hardware not working, I cannot say yes with 100% certainty.

Reply to
Wil Moloughney

Rare errors are the worst...

We had a problem with ELDK U-Boot IBM Sycamore (405GPr) where we got

- Kernel Oops looking earlier in the trace we found

- malloc: unknown:0 assertion botched (bash) replacing bash with (/bin/sh -> busybox, replaced /bin/bash with /bin/sh in ELDK scripts - OK in most cases) and then we got

- Memory Error

All these was fixed when we switched from "New Mode" to "Legacy"... We had tried to create a Sycamore config file for U-Boot but the new features in 405GPr probably requires new code - not only correct config of old code... Your problem can be of the same type.

/RogerL

--
Roger Larsson
SkellefteƄ
 Click to see the full signature
Reply to
Roger Larsson

100-300

This error is probalibly caused by UBoot not issuing a 'reset command' to the Flash before trying to read back the ID codes - in other words it is making bad assumptions regarding the state of the Flash devices internal state machines.

It is clear that the Flash is providing instructions OK otherwise UBoot would not run at all. I think it can be safely ignored.

I would guess that it will not occur if the board is newly powered up and that it may occur directly after the devices have been programmed.

--
David J Edgar
Cedaryacht Limited
 Click to see the full signature
Reply to
David J Edgar

No. It seems obvious that the system uses 4 chips in 8 bit mode, and

3 of them read correct IDs, while one of them just reads 0xFF - this is a hardware problem.

I think it is a hardware problem and cannot be ignored.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88   Web: www.denx.de
 Click to see the full signature
Reply to
Wolfgang Denk

OK - I've checked the UBoot code. It does not issue a 'reset command' before reading the ID codes.

This is a requirement to ensure correct operation with these devices. You have to consider that each device has it's own access state machine and three out of the four are in the reset state and one is not.

Reply to
David J Edgar

not

If you send me a copy of your code in S-Record format together with your board setup I will test it for you on another ADS8260.

Dave.

--
David J Edgar
Cedaryacht Limited
 Click to see the full signature
Reply to
David J Edgar

Why should it? We reach this code coming out of hard reset. We were able to boot out of flash, so obvioulsy the state of the flash chips is known.

Only if the state is unknown. This is not the case here. We know exactly which previous steps happened. Ummmm... at least I think I know this pretty well.

Which, in this case, must be hardware problem: a few CPU cycles before the same memory must have been in read mode, or the system would have never been able to boot.

Actually, instead of a hardware problem it may be also a some marginal settings of the timings in the memory controler, etc. But the effect is the same.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88   Web: www.denx.de
 Click to see the full signature
Reply to
Wolfgang Denk

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.