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

[Wolfgang Denk]

In message <877aabc404081700055ab573aa at mail.gmail.com> you wrote:
>
> 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.

What has serial_getc() to do with that? Are you just  mis-using  this
function for your purpooses? Why do you use such a dirty hack instead
of simply using one of the clean ways to do this (like implementing a
custom command and calling this preboot command.

> 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.

Why the he** are you talking about modifying to code  all  the  time?
There  is  NO  NEED to do that. U-Boot is extendable on command level
(which makes it much easier for you to test such things, btw.).

> (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.

This is no problem at all. There are even boards without any flash at
all (for example, the PN62 board has no flash, and the  U-Boot  image
gets loaded into RAM over PCI).

> > 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.

Did you try reading (like using the "md" command) the same area under
U-Boot? [If you  used  "preboot"  you'd  just  have  to  modify  this
environment variable for such debuging commands - you see what I mean
when warning against unnecessary hacking of the code.]

> However, jumping to this location (40004) from u-boot via function
> pointers results in the said trap. If I initialize the function

Jumping via function pointers? In the first message you said you were
using the "go"  command???  And  -  is  your  code  a  proper  U-Boot
extension  at  all (i. e. is it linked correctly), or ist it a U-Boot
standalone programm which can be called by "go"?

> 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.

I think you're just doing too many strange things at once. Break this
down into  single  tasks.  First  get  the  download  working  (in  a
separate, interactive command which allows for testing in the content
is  stored  correctly  in  RAM).  Then try to get the code running as
standalone program, i. e. start it manually usinbg  "go".  When  both
steps  are working, #define CONFIG_PREBOOT to call the prper download
and go commands.

> > > 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.

Then obviously there have been accesses to this location, right?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
"Where shall I begin, please your Majesty?" he asked. "Begin  at  the
beginning,"  the  King said, gravely, "and go on till you come to the
end: then stop."    - Alice's Adventures in Wonderland, Lewis Carroll