From: Scott Wood <scottwood@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] fsl: board EEPROM has the CRC in the wrong location
Date: Fri, 13 Jul 2012 17:19:18 -0500 [thread overview]
Message-ID: <50009EE6.2080804@freescale.com> (raw)
In-Reply-To: <500098F6.8050702@freescale.com>
On 07/13/2012 04:53 PM, Timur Tabi wrote:
> 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.
I know the spec wouldn't change, except the version number. But as I
said above, there would be no known v2 implementations with the bug.
You would only check the bad CRC location if you see v1 data, because
there are known buggy v1 implementations.
>> 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.
Neither do I; I was just suggesting a compromise should Wolfgang
maintain his opposition.
-Scott
next prev parent reply other threads:[~2012-07-13 22:19 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-12 21:46 [U-Boot] [PATCH] fsl: board EEPROM has the CRC in the wrong location Timur Tabi
2012-07-12 22:03 ` sun york-R58495
2012-07-12 22:37 ` Scott Wood
2012-07-12 22:44 ` Timur Tabi
2012-07-12 22:46 ` sun york-R58495
2012-07-12 22:49 ` Scott Wood
2012-07-12 22:52 ` Timur Tabi
2012-07-13 4:32 ` Wolfgang Denk
2012-07-13 12:11 ` Tabi Timur-B04825
2012-07-13 21:26 ` Wolfgang Denk
2012-07-13 4:30 ` Wolfgang Denk
2012-07-13 4:38 ` sun york-R58495
2012-07-13 12:12 ` Tabi Timur-B04825
2012-07-13 21:22 ` York Sun
2012-07-13 12:10 ` Tabi Timur-B04825
2012-07-13 21:25 ` Wolfgang Denk
2012-07-13 21:29 ` Timur Tabi
2012-07-13 21:32 ` Wolfgang Denk
2012-07-13 21:39 ` Timur Tabi
2012-07-13 21:45 ` Scott Wood
2012-07-13 21:53 ` Timur Tabi
2012-07-13 22:19 ` Scott Wood [this message]
2012-07-13 22:22 ` Timur Tabi
2012-07-13 22:41 ` Scott Wood
2012-07-13 22:46 ` Timur Tabi
2012-07-13 22:54 ` Scott Wood
2012-07-13 23:01 ` Wolfgang Denk
2012-07-13 23:12 ` Scott Wood
[not found] ` <C5EFF1F960B6FC4C873CF9BD5FE250210791DCC8@039-SN2MPN1-013.039d.mgd.msft.net>
2012-07-15 12:52 ` Tabi Timur-B04825
2012-07-16 19:57 ` Wolfgang Denk
2012-07-16 22:32 ` Scott Wood
2012-07-13 22:59 ` Wolfgang Denk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50009EE6.2080804@freescale.com \
--to=scottwood@freescale.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox