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:gerick...@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 > end > > Regards, > > Grant Erickson > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot