David Brownell <[email protected]> writes:

> As they say, "A clean driver is a happy driver!"
>
>   - use io{read,write}{8,16,32}_rep() for faster i/o
>   - update/bugfix partition config handling
>   - update/bugfix ecc (1-bit) config handling
>   - separate dm355evm and dm6446evm specifics
>   - partial ALE/CLE parameterization
>
> This doesn't yet create a driver-specific platform data
> struct; adding and converting to that will be a flag day
> for later.  But it should make it easier to make such
> changes later.

Thanks, applied this 5-patch series.

> I suspect the dm355evm issue with reported bad blocks is
> related to the 4-bit ECC mode used by the firmware loaded
> on it.  It needs 10 bytes ECC data per 512 bytes data,
> but evidently the resulting 40 bytes per page exceeds
> what that version of Linux (and current ones??) allow
> in the OOB area.
>
> So ... the ECC data is instead stored inline, which
> means the first few bytes of OOB data on *good* blocks
> will be used for data, which will probably look just
> like a factory marker for a bad block.
>
> I think that'll be a mess to fix, if that's right.
> Ideally the existing bad block tables can be extracted
> and restored to a standard format.

IIRC, there was some discussion in TI about updating ubl/u-boot to fix
the bootloader-kernel mismatch.  Anyone in TI care to comment?

Kevin


_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Reply via email to