What if the UBI flasher can't skip all-FF pages?

[Jon Povey]

linux-mtd-bounces at lists.infradead.org wrote:
> Artem Bityutskiy <dedekind1 <at> gmail.com> writes:

>> The original reason for writing this article was that some flashes
>> have write non-0xFF ECC to the OOB area when programmed with all
>> 0xFFs. But this case is easily testable.
>
> Isn't that possible for all ECC algorithms?  If the page has
> a bit stuck at 0,
> and is programmed to all 0xFFs, the ECC cannot possibly be all 0xFFs.

If the page has a bit which won't erase, the block should be marked bad and retired, so correct ECC is not relevant.

An ECC algorithm that produced all-FF for all-FF input would be nice. I wonder if some controllers implement this. You could do it just by XORing with the binary-not of the underlying all-FF ECC signature. (This is just me thinking out loud about hardware I'd like to see, it doesn't help you).

> A long initial boot is not really a problem.  I was seriously
> considering this, but I realized that I could set up a platform
> specific workaround.  My bootloader can write UBIFS correctly, so all
> I need to do is reprogram every PEB in the UBI volume on the first
> boot before attempting to
> load Linux.

If that is a fresh mkfs.ubifs filesystem not many blocks will have a mix of all-FF and not-all-FF pages, you only need to rewrite those blocks.
all-FF blocks I think you can just erase completely and UBI will put headers back on later (someone else may like to comment..)

Bear in mind what happens if you lose power or get reset while doing this process. If you are planning to do it in the factory with a test after, shouldn't be a problem.

--
Jon Povey
jon.povey at racelogic.co.uk

Racelogic is a limited company registered in England. Registered number 2743719 .
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB .

The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network