From mboxrd@z Thu Jan 1 00:00:00 1970 From: Amit Shah Date: Tue, 17 Aug 2004 12:35:10 +0530 Subject: [U-Boot-Users] decoding 'program check exception trap' In-Reply-To: <20040816202124.D5055C109F@atlas.denx.de> References: <20040816202124.D5055C109F@atlas.denx.de> Message-ID: <877aabc404081700055ab573aa@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 Mon, 16 Aug 2004 22:21:19 +0200, Wolfgang Denk wrote: > In message 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/