steven james pyro@linuxlabs.com 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