From mboxrd@z Thu Jan 1 00:00:00 1970 From: Amit Shah Date: Tue, 17 Aug 2004 14:06:32 +0530 Subject: [U-Boot-Users] decoding 'program check exception trap' In-Reply-To: <20040817073853.61876C109F@atlas.denx.de> References: <20040817073853.61876C109F@atlas.denx.de> Message-ID: <877aabc404081701367e56aceb@mail.gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Tue, 17 Aug 2004 09:38:48 +0200, Wolfgang Denk wrote: > In message <877aabc404081700055ab573aa@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/