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

[Tom Rini]

On Fri, Jun 17, 2022 at 02:19:57PM -0500, Nishanth Menon wrote:
> 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 at 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.

OK, thanks for explaining.

Reviewed-by: Tom Rini <trini at konsulko.com>

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20220617/2b841441/attachment.sig>