devkit8000: MMC/FAT booting problem with SPL
Hi List,
there seems to be a problem in devkit8000 in combination with mmc boot.
I have this error:
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.img
Error reading cluster
spl: error reading image u-boot.img, err - -1
### ERROR ### Please RESET the board ###
Some exploring i did some time ago showed that this error is deep in the FAT implementation. (a pity that i don't have my notes on this anymore)
I'am aware that there have been changes some time ago regarding FAT/SPL and malloc.
Is someone able to guess where the problem might be - to be true I didn't had a clue from the FAT code.
I will do some debugging later this day and post the results here.
Thanks!
Simon
Quoted 15 lines · Simon Schwarz
Hi List,
there seems to be a problem in devkit8000 in combination with mmc boot.
I have this error:
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.img
Error reading cluster
spl: error reading image u-boot.img, err - -1
### ERROR ### Please RESET the board ###Some exploring i did some time ago showed that this error is deep in the FAT implementation. (a pity that i don't have my notes on this anymore)
Quoted 7 lines
I'am aware that there have been changes some time ago regarding FAT/SPL and malloc.
Is someone able to guess where the problem might be - to be true I didn't had a clue from the FAT code.
I will do some debugging later this day and post the results here.
The datapoint I want to raise is that I can see this with my SPL series as well, but only on devkit8000. Beagleboard and omap3evm are fine booting from MMC with SPL. Which is odd, I know.
Signature · 1 line
Tom
Quoted 1 line · Tom Rini
On 11/29/2011 04:11 AM, Simon Schwarz wrote:
[SNIP]
Quoted 1 line
Quoted 1 line
I will do some debugging later this day and post the results here.
So here is the result of my first session:
- The problem seems to be in fat.c disk_read-function.
- it returns -1 because if (cur_dev->block_read) seems to be false if it tries to read the second cluster (it seems works with the first cluster!)
So the question now is how can cur_dev->block_read be reset in between...
Quoted 5 lines
The datapoint I want to raise is that I can see this with my SPL series as well, but only on devkit8000. Beagleboard and omap3evm are fine booting from MMC with SPL. Which is odd, I know.
Jap I know. This is a strange problem. ATM I am clueless...
Regards
Simon
Quoted 19 lines · Simon Schwarz
Quoted 18 lines
Hi List,
there seems to be a problem in devkit8000 in combination with mmc boot.
I have this error:
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.img
Error reading cluster
spl: error reading image u-boot.img, err - -1
### ERROR ### Please RESET the board ###Some exploring i did some time ago showed that this error is deep in the FAT implementation. (a pity that i don't have my notes on this anymore)
I'am aware that there have been changes some time ago regarding FAT/SPL and malloc.
Quoted 8 lines
Quoted 4 lines
Is someone able to guess where the problem might be - to be true I didn't had a clue from the FAT code.
I will do some debugging later this day and post the results here.
The datapoint I want to raise is that I can see this with my SPL series as well, but only on devkit8000. Beagleboard and omap3evm are fine booting from MMC with SPL. Which is odd, I know.
Stupid question -- isn't some stack corruption / memory corruption going on ?
M
On 11/29/2011 05:25 PM, Marek Vasut wrote:
[SNIP]
Quoted 4 lines
Stupid question -- isn't some stack corruption / memory corruption going on ?
M
Not stupid at all. I don't think it is a stack corruption but IMHO it seems that the .bss section is overwritten somehow.
The cur_dev pointer is 0x80000120 for the first sector and 0xe087c004 before the second one. So either it is changed somewhere or somehow the pointer is overwritten by accident.
Quoted 6 lines · Simon Schwarz
On 11/29/2011 05:25 PM, Marek Vasut wrote:
[SNIP]Quoted 4 lines
Stupid question -- isn't some stack corruption / memory corruption going on ?
Quoted 9 lines
Quoted 1 line
M
Not stupid at all. I don't think it is a stack corruption but IMHO it seems that the .bss section is overwritten somehow.
The
cur_devpointer is0x80000120for the first sector and0xe087c004before the second one. So either it is changed somewhere or somehow the pointer is overwritten by accident.
little status-report: The .bss-section is overwritten. Moving it into the middle of RAM fixes the problem - although this is not a solution it may help to find the root...
Regards