Universal Flashing tool
Eric W. Biederman
ebiederman at lnxi.com
Fri Mar 14 12:40:00 CET 2003
steven james <pyro at linuxlabs.com> writes:
> My experiance is that each chip has it's little quirks. Sometimes it's
> undocumented, sometimes it's technically within JEDEC but weird, sometimes
> 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.
More information about the coreboot