On Wed, Jan 13, 2010 at 12:33:18PM +0100, Luc Verhaegen wrote:
On Wed, Jan 13, 2010 at 12:14:02PM +0100, Uwe Hermann wrote:
Hi,
On Sun, Jan 10, 2010 at 01:19:28PM +0100, Luc Verhaegen wrote:
From 357cbdbc7b3be6a6b685e73f723e6b5cf147bc19 Mon Sep 17 00:00:00 2001
From: Luc Verhaegen libv@skynet.be Date: Sat, 26 Dec 2009 20:45:35 +0100 Subject: [PATCH] Boards: Remove it8705_rom_write_enable.
Should be functionally the same as it8705f_write_enable_2e.
Yep, except for the "Configuration Select" (bit 7) in reg 0x22, but I think we need a way to handle that better anyway (which would be an additional patch), so:
Acked-by: Uwe Hermann uwe@hermann-uwe.de
As the default for this bit is 0 and the flashrom code set it to 1 we should probably trace back which board originally used this code. That one possibly did have two Super I/Os and needed to have one of them selected explicitly (?)
Uwe.
First of all, thanks for looking into this.
Secondly, this patch sadly depends on another patch which at least ties the max rom decode to boards directly instead of doing this through the board enable (which, amongst others, ruins our ability to sanitise board enables).
Thirdly, the original board enable was written by Peter as part of r256 (originally r3364) dated June 11th 2008:
flashrom: Board enable and autodetection for BioStar P4M80-M4. Thanks to Reinder for clean room reverse engineering and data sheet diving! This board is autodetected because there are some good BioStar subsystem IDs. Matching uses onboard VT6420 SATA RAID with subsystem BioStar 3206 and onboard UniChrome Pro IGP graphics with subsystem BioStar 1202. Signed-off-by: Peter Stuge <peter@stuge.se> Acked-by: Lyos Gemini Norezel <lyos.gemininorezel@gmail.com>CCed Peter so he can shed a bit more light on this, in as far as he still has a recollection of this, as it's been some 550 commits ago :)
Luc Verhaegen.
Status of this patch: the other patch is still pending.
Michael dug out the bios and found no such special handling. It can be assumed that people were just a bit too proactive when writing up the board enable with the datasheet by their side.
So: * Ack received. * question mark answered. * blocked on max_rom_decode patch. * will not cleanly apply when DMI hits, but that can be handled trivially.
Luc Verhaegen.