[U-Boot-Users] decoding 'program check exception trap'
Hi all,
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.
On timeout, u-boot tries to transfer control to the binary, but it seems there's some problem:
## Starting application at 0x00040004 ... NIP: 00040004 XER: 00000000 LR: 0FFE7824 REGS: 0ff9db70 TRAP: 0700 DAR: 3DFEFEF7 MSR: 00088030 EE: 1 PR: 0 FP: 0 ME: 0 IR/DR: 11
GPR262144: 0FFE7814 0FF9DC60 00000080 00000001 0FF9DE94 00000010 FFFFFFFE 00000004 GPR08: 00000041 00000000 FFFFFFFF F1009010 00000000 00040000 00040000 00040000 GPR262144: 00040000 00040000 15DB7FF4 F79EFBFF 7EBBBBEF 00000001 DFEFBF6F 00000001 GPR24: 80006200 0FF9DE90 00000000 00000001 00040000 0FF9DF98 10005058 00040000 696e6720: ff ff ff fe 3f ff ff df ff fe ff 696e6720 ff ff ff ff 0003fff0: ff df 7f ff f7 ff ed ff ff ff bf ff 77 ff f6 fd 00040000: 00 d0 696e6720 696e6720 696e6720 d0 00 d0 ff f5 696e6720 696e6720 bf 696e6720 696e6720 696e6720 696e6720: 696e6720 696e6720 696e6720 696e6720 eb df bf ff 696e6720 696e6720 696e6720 fd fa fe ff ff 00040020: f7 ff 77 df ff ef 7f ff 3f 9f ff 4f ff ff f9 df 00040030: ef fe ef fe ff ff ff ff bf f7 fb 696e6720 696e6720 696e6720 fe ff 00040040: ff ff 77 ff 7f 5f 696e6720 696e6720 fb 696e6720 696e6720 696e6720 696e6720 696e6720 696e6720 696e6720 696e6720: 696e6720 ff bf ef cf ef ff 7f fe fe ff ff 696e6720 696e6720 ff ff 00040060: f7 ff ff df f6 ff 7f ff 35 ff f5 ff b7 7f e7 ff 00040070: ff ff ef af df ff fe 696e6720 696e6720 696e6720 fe fa ef f7 fe 696e6720 696e6720: 696e6720 696e6720 696e6720 696e6720 696e6720 696e6720 696e6720 696e6720 696e6720 696e6720 696e6720 ff 7f e6 696e6720 696e6720
696e6720: 696e6720 696e6720 ab 696e6720 696e6720 696e6720 696e6720 696e6720 696e6720 696e6720 696e6720 696e6720 fe ff 6f ff 000400a0: ff ff ff ed 696e6720 696e6720 ff 7f d7 df fd ff ff 77 f5 bf 000400b0: fa bf ff ff ff bf ff 7d fe ff bb bb ff fe ef ff 000400c0: 696e6720 696e6720 ff ef d4 696e6720 df ff df f7 df ff eb 7f 69 bf 000400d0: fb ff ff ff fe ef fe ff eb ff fa ff f7 fb ae 63 Call backtrace: Program Check Exception
Since the 'call backtrace' has no pointers, I can't use the 'backtrace' script to decode stuff. Anyways, I think that won't help here, since I know what the control flow is.
Is SRR1 stored anywhere? That could help me why exception 0x700 is being caused.
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.
Any help appreciated.
Thanks, Amit.
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?
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?]
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?
Best regards,
Wolfgang Denk
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.
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.
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
On Tue, 17 Aug 2004 09:38:48 +0200, Wolfgang Denk wd@denx.de 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.
In message 877aabc404081701367e56aceb@mail.gmail.com you wrote:
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.
You're just adding complexity where it is not necessary. Keep things simple.
Yes. I know all the right infrastructure is in place, thanks for the great modularity..
Then USE it.
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 :-)
Fine :-)
Uh, actually, I tried both the approaches. Autoboot with 'go 0x40004'.
Remember that "go" expects a standalone application or something that will take over control completely.
Best regards,
Wolfgang Denk
On Tue, 17 Aug 2004 12:24:44 +0200, Wolfgang Denk wd@denx.de wrote:
In message 877aabc404081701367e56aceb@mail.gmail.com you wrote:
Uh, actually, I tried both the approaches. Autoboot with 'go 0x40004'.
Remember that "go" expects a standalone application or something that will take over control completely.
I'm trying out a simple app that just writes to SRAM and UART. I'm also trying it out with hello_world from examples/. That probably explains the location 40004 :-)
Amit.
On Tue, 17 Aug 2004 09:38:48 +0200, Wolfgang Denk wd@denx.de wrote:
In message 877aabc404081700055ab573aa@mail.gmail.com you wrote:
(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).
Hey WD, can you explain a bit on how you actually did this? The preboot command copies something from PCI. How / when do you write to the SDRAM over PCI? Did you do this through interrupts? Or was it something else?
Thanks, Amit.
In message 877aabc404081704266d856f38@mail.gmail.com you wrote:
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).
Hey WD, can you explain a bit on how you actually did this? The preboot command copies something from PCI. How / when do you write to the SDRAM over PCI? Did you do this through interrupts? Or was it something else?
In our case this was different. The system is a standard PCI card which sits in a PC. Some software on the PC will initialize the card, holding the processor in reset. It will then upload the U-Boot image into SDRAM, and then release the processor on the card which will boot U-Boot from the location in RAM, which then in turn will load and boot Linux.
Best regards,
Wolfgang Denk
On Tue, 17 Aug 2004 13:43:15 +0200, Wolfgang Denk wd@denx.de wrote:
Hey WD, can you explain a bit on how you actually did this? The preboot command copies something from PCI. How / when do you write to the SDRAM over PCI? Did you do this through interrupts? Or was it something else?
In our case this was different. The system is a standard PCI card which sits in a PC. Some software on the PC will initialize the card, holding the processor in reset. It will then upload the U-Boot image into SDRAM, and then release the processor on the card which will boot U-Boot from the location in RAM, which then in turn will load and boot Linux.
My situation is a bit similar as well. I too have a PCI card. However, we do have flash, so I use u-boot to initialize the SDRAM and UART on the board. After this is done, some binary (evenutally, a uImage) is to be loaded and run. How to synchroize these things? How to stop u-boot so that image from the PCI can be transferred? Better would be to interrupt the host, and the driver then signals some userspace program to transfer the image. After this, signal the MV64360 that the binary is loaded, so that u-boot can then continue and transfer execution to the binary / uImage.
Is this too murky?
Amti.
Best regards,
Wolfgang Denk
-- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de Quote from the Boss... "I didn't say it was your fault. I said I was going to blame it on you."
In message 877aabc4040817045975185242@mail.gmail.com you wrote:
My situation is a bit similar as well. I too have a PCI card. However, we do have flash, so I use u-boot to initialize the SDRAM and UART on the board. After this is done, some binary (evenutally, a uImage) is to be loaded and run. How to synchroize these things? How to stop
Implement a protocol. I have no ideahow your hardware is designed, but if you have some kind of shared memory you will probably also have thought about ways to synchronize access to it?
u-boot so that image from the PCI can be transferred? Better would be
Why stop U-Boot? Just run a command that puts it into "wait for download completed" state.
to interrupt the host, and the driver then signals some userspace program to transfer the image. After this, signal the MV64360 that the binary is loaded, so that u-boot can then continue and transfer execution to the binary / uImage.
This is a design issue. As far as U-Boot on the PCI card is concerned it should make no difference if the download is done by Linux driver or application code.
Best regards,
Wolfgang Denk
participants (2)
-
Amit Shah -
Wolfgang Denk