[U-Boot] AMCC 405EX Trap

[Jonathan Haws]

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 at nuovations.com]
> Sent: Wednesday, April 29, 2009 5:38 PM
> To: Jonathan Haws
> Cc: u-boot at 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
>