Hi Jon, I came on board well after the hardware was closed and employed in the field. Unfortunately, the base NAND device is hardware locked and can not be written to in the field, period. On the other hand reads are relatively rare, for booting and UBOOT usage mainly. But you are right about the the read problem. We are simply not able to write to it.
So as I understand I am on my own regarding this issue. I'm just in absolute wonder how it is that I am the only one in this very large world who has this issue? Am I the first?? Hard to believe. Anyway, I will continue to work on it and hope to provide a patch to others who may want it. Regards Michael On Fri, Jan 21, 2011 at 8:31 AM, Jon Povey <[email protected]>wrote: > Hi. Let's keep the list CC'd in, might be useful for someone else reading > archives later. > > Also, inline quoting is prefered.. > > Michael Hallak-Stamler wrote: > > We are using the original 2.6.18 Montavista kernel with the > > SYNDROME calculation. Since we have many existing devices in > > the field and we want to perform a remote upgrade, we need to > > maintain the same format on the NAND devices in order > > preserve other important data on them, such as the UBOOT and UBL and > > other data. > > > > Our system uses a technique whereby one of two NAND devices > > are read locked. Hence, there is not way to reformat the > > device for a new technique. We are stuck with having to > > maintain the original SYNDROME calculation. > > Are you physically (electrically) unable to erase/write one of your NAND > devices? > You do know about read disturb, right?... > In short it means that to correctly manage a NAND device you have to > rewrite > blocks from time to time as bit errors appear randomly after reads from > time > to time. I have seen this brick devices in the field with naieve NAND > handling > firmware. > > I hope you can unlock your locked device.. > > > I don't understand why this was not maintained so that we > > have backward compatibility. Is there no solution or patch that you > > are aware of? > > > > I do see partial support for the SYNDROME calculation in the > > kernel but nothing that gives a complete solution. > > I don't know, sorry. > The original layout was simplistic and just plain wrong, didn't agree with > manufacturer's idea of OOB layout and factory marked bad blocks, so it was > "fixed". This caused headaches for people trying to upgrade, yes.. > > Although I don't know if the old layout ever was in the mainline kernel, if > not then who can really be blamed if MV/TI did it one way once and the > mainline does it the "right way", you are comparing apples and oranges to > some extent. > > Anyway, you have the source and can beat it into submission :) > > This is assuming of course that you are running into the problems I did > and not something completely different.. > > FYI I ended up rewriting chunks of flash in MTD RAW mode using software to > change OOB layout and calculate ECC so that when rebooted it would be > correct. > Had to write various utilities to do that - and don't have the rights to > the > sources, sorry. > > Related point, eMMC looks nice for the future, takes away all the ECC and > wear levelling hassle it seems.. > > > -- > Jon Povey > [email protected] > > 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 > > >
_______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
