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 00040000696e6720: 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 696e6720696e6720: 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 696e6720696e6720: 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 696e6720696e6720: 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 ff000400a0: 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.
Signature · 2 lines
Amit Shah http://amitshah.nav.to/
Quoted 6 lines · In message <[email protected]> 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' inmain_loopso 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?
Quoted 2 lines
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?]
Quoted 3 lines
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
Signature · 3 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de Remember that Beethoven wrote his first symphony in C ...
Quoted 8 lines · Wolfgang Denk
Quoted 6 lines · In message <[email protected]> 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' inmain_loopso that I can transfer a binary to the 40004 mem. location using a PCI interface via the host machine.
Quoted 4 lines
Ummm.. what _exactly_ are you doing? What has a "
serial_getcinmain_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.
Quoted 5 lines
Quoted 2 lines
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
0x00040004at 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.
Quoted 6 lines
Quoted 3 lines
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..
Quoted 4 lines
Best regards,
Wolfgang Denk
Amit.
Signature · 2 lines
Amit Shah http://amitshah.nav.to/
Quoted 5 lines · In message <[email protected]> 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()inmain_loopallows me to put a binary in SDRAM at location0x40004, '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.
Quoted 2 lines
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.).
Quoted 3 lines
(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).
Quoted 7 lines
Quoted 2 lines
What exactly is the contents of the memory at
0x00040004at 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
0x40004and 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.]
Quoted 2 lines
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"?
Quoted 4 lines
pointer to u-boot code in the RAM, (let's say,
main_loop), it works alright. ie, I keep going intomain_loopover 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.
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
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
Signature · 5 lines
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
Quoted 11 lines · Wolfgang Denk
Quoted 5 lines · In message <[email protected]> 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()inmain_loopallows me to put a binary in SDRAM at location0x40004, '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.
Quoted 6 lines
Quoted 2 lines
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..
Quoted 7 lines
Quoted 3 lines
(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.
Quoted 8 lines
Quoted 7 lines
Quoted 2 lines
What exactly is the contents of the memory at
0x00040004at 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
0x40004and put the binary into/dev/mvsdram0. This is the SDRAM0 BAR. I can read the contents back and verify, they are coherent.
Quoted 4 lines
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 :-)
Quoted 7 lines
Quoted 2 lines
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.
Quoted 5 lines
Quoted 4 lines
pointer to u-boot code in the RAM, (let's say,
main_loop), it works alright. ie, I keep going intomain_loopover and over again. So the binary I copied into RAM... either isn't copied (improbable) or the processor doesn't read its contents.
Quoted 7 lines
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_PREBOOTto 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.
Quoted 10 lines
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
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.
Signature · 2 lines
Amit Shah http://amitshah.nav.to/
Quoted 9 lines · In message <[email protected]> you wrote:
Quoted 5 lines
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.
Quoted 2 lines
Yes. I know all the right infrastructure is in place, thanks for the great modularity..
Then USE it.
Quoted 2 lines
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 :-)
Quoted 1 line
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
Signature · 4 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de I can type faster than I can move a mouse, so I find menu-driven drawing packages time consuming and frustrating. - W. R. Stevens
Quoted 5 lines · Wolfgang Denk
Quoted 1 line · In message <[email protected]> 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.
Signature · 2 lines
Amit Shah http://amitshah.nav.to/
Quoted 8 lines · Wolfgang Denk
Quoted 3 lines · In message <[email protected]> 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.
Signature · 2 lines
Amit Shah http://amitshah.nav.to/
Quoted 9 lines · In message <[email protected]> you wrote:
Quoted 4 lines
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
Signature · 4 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de Quote from the Boss... "I didn't say it was your fault. I said I was going to blame it on you."
Quoted 11 lines · Wolfgang Denk
Quoted 4 lines
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.
Quoted 11 lines
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 Quote from the Boss... "I didn't say it was your fault. I said I was going to blame it on you."
Signature · 2 lines
Amit Shah http://amitshah.nav.to/
Quoted 5 lines · In message <[email protected]> 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?
Quoted 1 line
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.
Quoted 4 lines
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
Signature · 4 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de I had a letter in the post today. It said 'Gas Bill'. It sounds a tempting offer...