On Wed, 2010-11-17 at 16:08 -0600, Scott Wood wrote:
On Wed, 17 Nov 2010 22:40:49 +0100 Wolfgang Denk wd@denx.de wrote:
Dear Steve Sakoman,
In message AANLkTimrfQ5+AWfdFy_fueTMH=x=xrkaZGNtK8fiSD48@mail.gmail.com you wrote:
readenv: offset = 240000 readenv: nand_read failure = -117 *** Warning - readenv() failed, using default environment
I then immediately tried to use the nand read command to read the same block, and it was successful!
Hm... any chance that - for example - your timers are not working correctly before relocation (maybe because they try to write to the not yet available data segment) ? This could cause timeouts or delays to be too short, so the NAND driver is misbehaving?
The NAND driver only works after relocation.
It looks like the problem is that -EUCLEAN is a non-fatal error (indicates a correctable ECC error). The code invoked by the "nand read" command succeeds if nand_read() returns either 0 or -EUCLEAN, but readenv() is missing this check.
Changing readenv to use nand_read_skip_bad eliminated the -117 (EUCLEAN) failures.
Now I am getting just the -74 (EBADMSG) errors for fw_setenv written environments.
It seems that fw_printenv can always read u-boot written environments, but 99.9% of the time I get a -74 (EBADMSG) error in u-boot for environments written by fw_setenv:
NAND read from offset 240000 failed -74 *** Warning - readenv() failed, using default environment
If I try to read the environment using the nand read tool I get the same error.
Using fw_printenv always seems to work -- whether u-boot or fw_setenv was the writer.
The code generating both errors is in the nand_do_read_ops function in nand_base.c:
if (mtd->ecc_stats.failed - stats.failed) return -EBADMSG;
return mtd->ecc_stats.corrected - stats.corrected ? -EUCLEAN : 0; }
I understand that the -EUCLEAN error indicates a correctable ECC error. What does the -EBADMSG error indicate?
This condition doesn't seem to bother the linux driver, but u-boot doesn't like it at all!
Steve