[U-Boot-Users] problem when running the bootm command
Hi,
I am using the M5282EVB configuration. I have come across the following problem: I load a compressed linux image into address 400000 (I leave enough room for it to be decompressed at address 100000). I then run -> bootm 400000 This works fine (the image is decompressed at address 100000 and runs correctly).
Now I reset the board, download the compressed image again (using iminfo to very it's header is there and correct) and again I run -> bootm 400000
This time I get an exception (this happens consistently until I program U-Boot again into FLASH, at which time I can again use bootm successfully only once):
-> bootm 400000 ## Booting image at 00400000 ... Image Name: Image Type: M68K Linux Standalone Program (gzip compressed) Data Size: 1249874 Bytes = 1.2 MB Load Address: 00100000 Entry Point: 00100000 Verifying Checksum ... OK Uncompressing Standalone Application ...
*** Unexpected exception *** Vector Number: 3 Format: 04 Fault Status: 4
PC: 00fe5d48 SR: 00002704 SP: 00f9155c D0: 00000000 D1: 00000000 D2: 00000000 D3: 0000011a D4: 00000000 D5: 00000000 D6: 004000d8 D7: 00fa1f90 A0: 00000009 A1: 00fac8e0 A2: 00fa28e0 A3: 00f91afe A4: 00fa2928 A5: 00ff7600 A6: 00f91ad4
*** Please Reset Board! ***
The problem cannot e related to overwriting critical areas in RAM because I don't overwrite U-Boot's region or the region where I store the packaged image.
Did anyone come across this problem
Thanks,
Erez
Erez Koelewyn wrote:
Hi,
I am using the M5282EVB configuration. I have come across the following problem: I load a compressed linux image into address 400000 (I leave enough room for it to be decompressed at address 100000). I then run -> bootm 400000 This works fine (the image is decompressed at address 100000 and runs correctly).
Now I reset the board, download the compressed image again (using iminfo to very it's header is there and correct) and again I run -> bootm 400000
This time I get an exception (this happens consistently until I program U-Boot again into FLASH, at which time I can again use bootm successfully only once):
-> bootm 400000 ## Booting image at 00400000 ... Image Name: Image Type: M68K Linux Standalone Program (gzip compressed) Data Size: 1249874 Bytes = 1.2 MB Load Address: 00100000 Entry Point: 00100000 Verifying Checksum ... OK Uncompressing Standalone Application ...
*** Unexpected exception *** Vector Number: 3 Format: 04 Fault Status: 4
PC: 00fe5d48 SR: 00002704 SP: 00f9155c D0: 00000000 D1: 00000000 D2: 00000000 D3: 0000011a D4: 00000000 D5: 00000000 D6: 004000d8 D7: 00fa1f90 A0: 00000009 A1: 00fac8e0 A2: 00fa28e0 A3: 00f91afe A4: 00fa2928 A5: 00ff7600 A6: 00f91ad4
*** Please Reset Board! ***
The problem cannot e related to overwriting critical areas in RAM because I don't overwrite U-Boot's region or the region where I store the packaged image.
Did anyone come across this problem
Thanks, Erez
I'm clueless but that never stopped me from guessing. ;-)
It sounds like your linux image is scribbling in flash, messing up u-boot (but not fatally). Do you have a flash file system configured in your linux image? Any other reason your linux image would overwrite flash? If you dump the end portion of the *flash* u-boot image before and after the successful linux boot, does it show corruption?
If that isn't the problem the follow up question is: what is the unexpected exception vector number 3, what is the meaning of the PC (where the exception occurred), what does the stack tell you when you dump it?
Good luck, gvb
On 10/23/07, Jerry Van Baren gerald.vanbaren@ge.com wrote:
It sounds like your linux image is scribbling in flash, messing up u-boot (but not fatally). Do you have a flash file system configured in your linux image? Any other reason your linux image would overwrite flash? If you dump the end portion of the *flash* u-boot image before and after the successful linux boot, does it show corruption?
I never thoughtLinux might be corrupting FLASH memory for the following reasons:
1. When I load and run linux as a .bin file there is never any problem. Ah! yes, another good test would be to run load and run a linux .bin file (on a freshly programmed board) and after that try to inflate a packaged linux image. 2. Flash memory sectors where U-Boot resides are protected (read only). Could linux be removing the protection? I should check. 3. The problem occurs even when uncompressing from a RAM location to another RAM location, before linux has a chance to run. But obviously the corruption could still happen in the first run as you pointed out.
I will do as you suggest and compare the FLASH memory dump with my U-Boot image, it's a very good idea.
If that isn't the problem the follow up question is: what is the unexpected exception vector number 3, what is the meaning of the PC (where the exception occurred), what does the stack tell you when you dump it?
Yes, that's the hard part. I was hoping to aviod the hassle in case someone already encountered this problem and provided a patch (I couldn't find anything in previous postings though).
Thank you for your advice,
Erez
An update on this:
It seems to be related to saving the environment variables in FLASH. Only after I save the environment variables to FLASH does the problem happen. Something there is overwriting U-Boot's code. This is also why the first time after programming the board it works OK, since the U-Boot's code runs from RAM, only after restarting the board do we load the corrupted code.
I'm looking into it. Thank you for all your help
participants (2)
-
Erez Koelewyn -
Jerry Van Baren