#119: Winbond W39V040FBPZ is not written correctly by flashrom
Reporter: charles.herndon@… | Owner: somebody
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: flashrom | Version: v2
Keywords: W39V040FBPZ | Dependencies:
Patchstatus: there is no patch |
Flash device is detected as a Winbond W39V040B device. Flashrom attempts
to flash device, but verification fails. No actual writing to the chip
appears to be done. Tried changing write and erase in flashchips.c to:
jedec, winbond_fwhub and 49lfxxxc.
./flashrom -wv xxxx.bin
Calibrating delay loop... OK.
No coreboot table found.
Found chipset "Intel ICH7/ICH7R", enabling flash write... OK.
Found chip "Winbond W39V040B" (512 KB) at physical address 0xfff80000.
Flash image seems to be a legacy BIOS. Disabling checks.
Programming page: 0007 at address: 0x00070000
Verifying flash... FAILED! Expected=0xc7, Read=0x49
Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/119>
As title. Can someone enter this into the wiki?
same as P2B-F
ECC support: WIP - Not yet supported by the coreboot 440BX code, but
it's on our TODO list.
On-board IDE 3.5": Secondary IDE works. There are some problems with
On-board SCSI: WIP - Detected, but not properly enabled.
On-board ethernet: OK - Works only when not listed in the mainboard's
ISA add-on cards: OK - Tested with Sound Blaster AWE64 ISA. Detected,
initialized, ALSA driver loaded, no sound
PCI add-on cards: OK - Tested with a PCI NE2000 NIC in one slot
PCI-X add-on cards: N/A
PCIe add-on cards: N/A
Sensors/fan control: OK
Nonstandard LEDs: Untested - Message LED requires ACPI and OS support
Wake on ...: Untested
ACPI/reboot/suspend/poweroff: All untested; there is still not ACPI
support for this board.
Known working build:
r5238 introduced full SDRAM support. Most later builds should work.
Board has socketed ROM chip
Board not supported by flashrom (yet); works when forced as P2B-F with
coreboot. Not tested with vendor BIOS.
Chip is SST39SF020A. I flashed 3 times in a row. No problems.
-----BEGIN PGP SIGNED MESSAGE-----
I have started a port of AMD Mahogony board to Asrock 939A785GMH. It boots
kernel, IDE works, ethernet too. No VGA output need to check why the VGA BIOS
extracted from orig image hangs.
It has 1MB socketed SPI flash chip, serial header. There are some overclocking
GPIO options hopefully now just set to safe values, check sio_init for details.
Patch is quite big because the ACPI stuff is just copied.
Signed-off-by: Rudolf Marek <r.marek(a)assembler.cz>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
The attached patch adds code required for initializing the ACPI/power
management/SMBus subdevice of PIIX4.
This is required for properly placing the I/O ports for power
management functionalities, which in turn will be required for future
ACPI work. Speaking of which, I based these ports at 0xe400, after my
P2B-LS board. This support is far from complete, but one step at a
One other change I should propose (but is not in this patch) is that
the definition for SMBUS_IO_BASE be moved to i82371eb.h from
i82371eb_early_smbus.c. Makes more sense for a definition that may be
referenced from some other places.
I was thinking to ask if someone know where to set this I/O base
address, and turns out no initialization whatsoever was being done.
Signed-off-by: Keith Hui <buurin(a)gmail.com>
the patch make filo can compiling well without any parameters of make
Signed-off-by: Wang Qing Pei <wangqingpei(a)gmal.com>
Wang Qing Pei
remember it's time to apply for a Google Summer of Code stipend for this
year. The registration period started on March 28th and it's soon over
again, so better hurry up and hand in your proposals today!
See more information and proposal ideas here: http://www.coreboot.org/GSoC
Looking forward to a cool GSoC 2010!
On Wed, Mar 31, 2010 at 7:56 AM, Stefan Reinauer <stepan(a)coresystems.de>wrote:
> On 3/30/10 11:16 PM, Myles Watson wrote:
> On Tue, Mar 30, 2010 at 2:50 PM, Stefan Reinauer <stepan(a)coresystems.de>wrote:
>> On 3/30/10 10:47 PM, Myles Watson wrote:
>> > Sounds good. I'd forgotten that cbmem was used for suspend, and so I
>> > couldn't see a reason for all the PRE_RAM ifdefs. Thanks for the
>> > explanation.
>> This isn't that fancy, but it helps with readability for me.
> Signed-off-by: Myles Watson <mylesgw(a)gmail.com>
> Acked-by: Stefan Reinauer <stepan(a)coresystems.de> <stepan(a)coresystems.de>