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.
Am Mittwoch, den 13.01.2010, 12:14 +0100 schrieb Uwe Hermann:
Yep, except for the "Configuration Select" (bit 7) in reg 0x22
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.
Subversion says: BioStar P4M80-M4
Regards, Michael Karcher
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.
Am Mittwoch, den 13.01.2010, 12:33 +0100 schrieb Luc Verhaegen:
flashrom: Board enable and autodetection for BioStar P4M80-M4.
I rechecked the current BIOS board enable. It doesn't poke that bit. It only sets 0x24, bit 2 and 0x24, bit 7.
Regards, Michael Karcher
On Wed, Jan 13, 2010 at 12:41:30PM +0100, Michael Karcher wrote:
Am Mittwoch, den 13.01.2010, 12:33 +0100 schrieb Luc Verhaegen:
flashrom: Board enable and autodetection for BioStar P4M80-M4.I rechecked the current BIOS board enable. It doesn't poke that bit. It only sets 0x24, bit 2 and 0x24, bit 7.
Regards, Michael Karcher
As i thought, and one of those bits, off the top of my head, is enabling the C through F segment, which we do not need.
So i guess that someone has just been a bit too proactive :)
Luc Verhaegen.
Hi,
On 13.01.2010 12:33, 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 :)
CCed Reinder (I hope his email address is still valid).
Regards, Carl-Daniel
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.
On Wed, Jan 20, 2010 at 03:00:33PM +0100, Luc Verhaegen wrote:
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.
r876.
Luc Verhaegen.
-
Carl-Daniel Hailfinger -
Luc Verhaegen -
Michael Karcher -
Uwe Hermann