[U-Boot] [PATCH] fsl: board EEPROM has the CRC in the wrong location

[Timur Tabi]

Scott Wood wrote:

> Timur, I know you said you don't control the format, but could you ask
> for a version number bump so that going forward there's a way to
> unambiguously mark the contents as "good" (the spec wouldn't change, but
> there would be no known implementations of v2 with this bug)?

I'm not sure what you mean.  The specification for v1 has always said that
the CRC is at address 0xFC.  I just wrote the code wrong.  I was always
under the impression that I was writing the CRC at 0xFC, until York
pointed that out to me last year.  As far as the specification is
concerned, nothing has changed.

> If not, and Wolfgang still refuses to accept this, what about checking
> the old location on a CRC fail, and if the old CRC passes, don't
> automatically use it but print a message telling the user that they
> probably need to run the migration command?

I honestly don't see what's wrong with checking the CRC in the old
location, and using it if it's valid.  Like I said, we already
automagically update EEPROMs from version 0 to version 1.  The existing
code already checks a version number to determine where the CRC is:

/*
 * If we've read an NXID v0 EEPROM, then we need to set the CRC offset
 * to where it is in v0.
 */
if (e.version == 0)
	crc_offset = 0x72;

So here we're reading the 'version' field before we validate the data,
because we need to check the version to know where the CRC is.

-- 
Timur Tabi
Linux kernel developer at Freescale