Grant,
Thanks for the reply.
I am certain that it is a hardware failure that is causing the machine check because I can use the exact same binary on another (identical) board and have it boot just fine. That tells me that all the EBC and SDRAM settings are correct; and that I am using the right addresses and chip selects for the data cache.
Currently I am leaning toward an SDRAM problem because I get about a 20 second pause when U-Boot tries to relocate to RAM.
Again, thanks for the reply.
Jonathan
-----Original Message----- From: Grant Erickson [mailto:gerickson@nuovations.com] Sent: Wednesday, April 29, 2009 5:38 PM To: Jonathan Haws Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] AMCC 405EX Trap
On 4/29/09 12:45 PM, Jonathan Haws wrote:
I am experiencing a machine check on a custom AMCC 405EX PPC board. Our
board
is based on the AMCC Kilauea evaluation board. We have a few of these
boards
that are up and running, but I am trying to track down a machine check
error
on a couple of them.
My question for you is this: when the registers are printed to the
console,
there is one called TRAP. I want to know how/where/when and with what
data
that gets populated. I have read through the AMCC manuals a couple of
times
trying to find it and have searched through the U-Boot code to no avail.
All
I know is that there is a data type "struct pt_regs*" that contains all
that
data, but nowhere can I find where it is populated.
Below is the console output. The line "!!!! PAUSE !!!!" was inserted by
me
after I copied the text from the console to remind me of the ~20 second
pause
that occurs at that point.
I am hoping that someone can point me to the bit definitions for
whatever
register is being displayed in TRAP. From there, I think I can trace
the
problem back to the specific piece of hardware and get it fixed.
Jonathan:
Typically machine checks such as this are latent and are more about something that happened earlier during bootstrap and initialization rather than something that happened at the time the machine check was actually realized. This is because up until that point, exceptions have not been enabled.
The first thing to check is your u-boot board configuration file. Are all EBC settings correct? Are all SDRAM settings correct? Are you using the right addresses and chip selects for data cache bootstrapping?
Beyond that, it might be useful to single step with your BDI/GDB (or other debugger) from start.S forward, watching key exception registers after every step.
To assist with such debugging, I defined the following macro in my .gdbinit file to dump relevant registers after every single step:
.gdbinit: define dumpexcregs monitor rd msr monitor rd esr monitor rd dead monitor rd srr0 monitor rd srr1 monitor rd srr2 monitor rd srr3 monitor rd mcsr monitor rd mcar monitor rd mcsrr0 monitor rd mcsrr1 monitor rd ebc_besr0 monitor rd ebc_besr1 monitor rd sdram_besr0 monitor rd sdram_besr0 monitor rd sdram_bearl monitor rd sdram_bearh endRegards,
Grant Erickson