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.
G'day, sjames
On 14 Mar 2003, Jeremy Jackson wrote:
On Thu, 2003-03-13 at 19:14, Spirit wrote:
an NULL function pointer. An small if statement fixes that, but the tool still can't detect the installed flash part properly. The part is JEDEC-compliant, but probe_jedec doesn't return correct id's for it,
I think a lot of these devices operate differently from what the manufacturer's datasheet says. Then there are different revisions, which may not be documented.
no matter if I run flash_on or not. So I still prefer uniflash. Someone here called it an old code... well, may be the code style isn't very good (after all it's pascal...), but the project itself is very fresh. The last update is something like January 2003.
Yes thanks for stating it that way. When I commented about Uniflash, I meant to say the coding style was old. But it works! It is mature code, and like devbios, it contains working code dealing with hardware quirks. I beat my head against the wall trying to get an Atmel AT29C040 to ID, using their datasheet. Then I looked at Uniflash and devbios, did what they did, and it worked, just nowhere near how the spec said.
It would be nice however to have both working, and modern code. Ron, can you elaborate more on the problems you have with MTD?
Jeremy
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios