[coreboot] flashrom: [PATCH] Fully working EON EN29F002NT

Mats Erik Andersson mats.andersson at gisladisker.se
Mon Sep 29 18:40:28 CEST 2008

Den 29 september skrev Uwe Hermann <uwe at hermann-uwe.de>:
> On Mon, Sep 22, 2008 at 03:24:25PM +0200, Mats Erik Andersson wrote:
> > Subsystem: coreboot-v2/util/flashrom/
> > Action: activating support for EN29F002(A)(N)[BT]
> > 
> > Fully tested for Probe/Read/Erase/Write on EN29F002NT.
> > Jedec subroutines 'probe_jedec()' and 'erase_chip_jedec()'
> > are still in use, but a tailored 'write_en29f002a()' is
> > needed due to a byte wise writing mechanism for this chip.
> > 
> > Signed-off by: Mats Erik Andersson <mats.andersson at gisladisker.se>
> Thanks, r3602.
> I tested this with an EN29F002NT and it does work better than the code
> we had before, but I'm seeing flashrom hang upon writes. Do you
> experience a similar behavior? Not sure what the problem is, flashrom
> is at 99% CPU load, but it can be killed with CTRL-C. Maybe it's just
> that my chip is dead or almost-dead (never worked so far)...

No, after implementing the correct byte wise writing algorithm,
I have not experienced any latch ups. I have produced some ten
images for a FIC mainboard and no problems at writing. Since I
use a uClibc-Busybox target system where flash writes are performed,
I can only say that the load figure using top says "0.17" at a
busy write to EN29F002NT, but the time to write 256kB is so short
that "top" might have difficulties to catch up.

Since this chip needs byte oriented writes and polling, a heavier
load than during block write ought to be expected. There is an
additional strobe using a value "0xF0" that I outcommented in the
code write_en26f002a() since it did not seem to matter. Do test
to see if that might awaken your memory chip.


Mats E Andersson

More information about the coreboot mailing list