Re: [PATCH 1/3] board: ti: common: Optimize boot when detecting consecutive bad records

[Nishanth Menon <nm@ti.com>]

On 14:50-20220617, Tom Rini wrote:
> On Fri, Jun 17, 2022 at 01:26:10PM -0500, Nishanth Menon wrote:
> 
> > The eeprom data area is much bigger than the data we intend to store,
> > however, with bad programming, we might end up reading bad records over
> > and over till we run out of eeprom space. instead just exit when 10
> > consecutive records are read.
> > 
> > Signed-off-by: Nishanth Menon <nm@ti.com>
> 
> Why not just stop at the first bad record?  Otherwise 10 seems like a

Because it could be just a couple of bad ones where the header.len
does'nt match up with record data. Some folks use a spreadsheet to
generate the records, some manually and some script it up - so,
attempting to get the best possible success chance while warning
invalid data to get people to fix things made sense.

> fine, small, arbitrary number.  If it's not arbitrary but number of
> total records, do we already enum the total number of records or
> something where we could say that we tried to read all possible records,
> everyone was bad, stop?

It is arbitrary small value - for all practical purposes, we have 6
types of records atm in u-boot, even looking ahead, we have'nt had
more than that I know of (I think display, camera and few other misc
types got added). The structure however, is by design flexible
with the END_LIST marker denoting the last record - and depending on
the eeprom size, you could theoretically have a large variation.

Considering this is attempting to recover from bad programming, the
chances are better when attempting a few more entries, but I dont
think going aggressive with a single record or conservative (as it is
right now) in scanning the entire eeprom is necessary. That leaves us
with some sort of practical number.

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D