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

[Amit Shah]

On Tue, 17 Aug 2004 09:38:48 +0200, Wolfgang Denk <wd at denx.de> wrote:
> 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.

Yeah, I'm just mis-using it. I basically just want to know why writing
something through PCI won't show up properly. I'll convert this into
some commands if there really is need for me to do it.

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

Yes. I know all the right infrastructure is in place, thanks for the
great modularity..

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

Hmm, just had a cursory look over it. I guess implementing things
'loadpci' way will help. Thanks for pointing this out; I'll try this
approach now.

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

Yes, I get your point. Actually, thanks for being so bullish about it,
I'll now just clean up the code and put in some commands there :-)

> > 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"?

Uh, actually, I tried both the approaches. Autoboot with 'go 0x40004'.
Also, just before it autoboots, do this with function pointers. I did
this 'cos in some strange conditions, u-boot just hung during the
autoboot timeout. It's not happening now, though. I could see the
Marvell sending interrupts via PCI to the host. May be that wasn't
working well. Argh, one more hack.

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

Yes. that's what I'll do now. First is to get the PCI transfer working
right. Thanks a lot.

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

yeah. But since the processor wasn't involved in the transfer through
the PCI, I'm wondering if something's amiss. I just can't explain it
with this theory as well. This is just something that I was wondering
about since I couldn't think of anything else.

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