Liu, Linas, list<br>Thanks a lot for the answers. It helped me to review the hardware configuration again.<br>The problem was the definition of the Flash size.<br>It turns out that the Xilinx generated header files define the size of the Flash. But the kernel also has a configuration option: Memory Technology Devices / Mapping Drivers for Chip Access / Physical Length of Chip Mapping
<br>My arch/ppc/platforms/xilinx_ocp/xparameters_ml300.h defines this as 4Mbyte, but the option in the kernel was set to 64 Mbyte (an extra 0 which I had not seen)<br>thanks again<br>Peter<br><br><br><br><br><div><span class="gmail_quote">
On 9/21/06, <b class="gmail_sendername">Liu Dave-r63238</b> <<a href="mailto:DaveLiu@freescale.com">DaveLiu@freescale.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<snip><br>> > Instruction machine check in kernel mode.<br>> > Oops: machine check, sig: 7<br>> > NIP: C00A2960 XER: 40000000 LR: C009CBD8 SP: C04D9D90 REGS:<br>> c04d9ce0 TRAP:<br>> > 0200 Not tainted
<br>> > MSR: 00009030 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11<br>><br>> Machine checks happen when some hunk of hardware is wired to<br>> the machine-check pin of the cpu chip, and that bit of<br>> hardware decides to raise the wire. I'd say the first step
<br>> is to figure ou what hardware is wired up this way, and what<br>> would make it unhappy enough to assert a machine check.<br>><br>> SRR1 has bits that state what caused he machine check. -- e.g<br>> partity error on data or address bus, "transfer error", or MC signal.
<br><br>The PPC405 has different registers for machine check. Unlike classic<br>powerpc.<br><br>-Dave<br></blockquote></div><br>