[U-Boot-Users] decoding 'program check exception trap'

[Amit Shah <shahamit@gmail.com>]

On Mon, 16 Aug 2004 22:21:19 +0200, Wolfgang Denk <wd@denx.de> wrote:
> In message <cfqlq9$1d9$1@sea.gmane.org> you wrote:
> >
> > I have u-boot working on a custom board based on the MV64360 with a PPC
> > 750GX processor. I've set the autoboot timeout to 3 secs, with the bootcmd
> > to 'go 0x40004'. I have a 'serial_getc' in main_loop so that I can transfer
> > a binary to the 40004 mem. location using a PCI interface via the host
> > machine.
> 
> Ummm.. what _exactly_ are you  doing?  What  has  a  "serial_getc  in
> main_loop"  to  do with a PCI transfer to memory? and why do you have
> to  do  such  modifications  at  all  when  all  can  be  done  using
> envrionment variables?

Okay, I have a PCI driver on the host machine that can dump stuff into
the SDRAM on the board. The serial_getc() in main_loop allows me to
put a binary in SDRAM at location 0x40004, 'cos around this time, the
SDRAM would've been initialized by u-boot.

An alternate would be to dump the binary on to flash and then within
main_loop, copy the binary from flash to RAM and then execute it.
(Problem is, I don't have Ethernet devices on the board.) Also, I just
have 2 MB of flash, so uImage + initrd + ... will take up more than 2
MB. So I have to do something like this.

> > On timeout, u-boot tries to transfer control to the binary, but it seems
> > there's some problem:
> 
> What exactly is the contents of the  memory  at  0x00040004  at  this
> time? [and how can you be sure about this?]

I dump the binary via PCI into the SDRAM on the board. On the host
side, I specify an offset of 0x40004 and put the binary into
/dev/mvsdram0. This is the SDRAM0 BAR. I can read the contents back
and verify, they are coherent.

However, jumping to this location (40004) from u-boot via function
pointers results in the said trap. If I initialize the function
pointer to u-boot code in the RAM, (let's say, main_loop), it works
alright. ie, I keep going into main_loop over and over again. So the
binary I copied into RAM... either isn't copied (improbable) or the
processor doesn't read its contents.

> > Also, can this be due to some caching? It should not, 'cos there shouldn't
> > have been any access to this location earlier for the data at that location
> > to be cached, but one possibility that I can think of right now.
> 
> If there was no access to this location  earlier,  then  how  do  you
> think this location could contain executable code?

Yes, because I transferred it through the PCI.

I hope things are a little clearer now..

> 
> Best regards,
> 
> Wolfgang Denk

Amit.

-- 
Amit Shah
http://amitshah.nav.to/