steven james <[EMAIL PROTECTED]> writes: > Greetings, > > My experiance is that each chip has it's little quirks. Sometimes it's > undocumented, sometimes it's technically within JEDEC but weird, sometimes > both. > > It doesn't help that some documents assume if it's not in the docs, JEDEC > applies while in others, if it's not in the docs, it's not there at all. > > The good news is that the quirks are usually fairly minor. I do prefer a > userspace tool since that makes these things much easier to debug, and > some chips have features that don't map well to the MTD interfaces such > as block locking or top block swap.
Block locking maps well to the mtd interface. There is not currently a way to do the top block swap but that should be a minor addition. So far I prefer to achieve the same effect in software, so that has not been an issue. Generally I prefer the mtd driver for end users (not developers). 1) MTD has the cleanest infrastructure I have seen. 2) The test to see if everything is working properly is easy. 3) I can separate out policy from the code that actually talks to the chips. And I have not seen chips so buggy they are impossible to work with the mtd interface. My only problem with the mtd code is that it takes a while to flush through to being in the mainstream kernel. And if someone reminds me I will get my linuxbios flashing tools posted that use the mtd interface. Eric _______________________________________________ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
