Here's the chip_enable code for the ALI M1533 and the board_enable for the Asus P5A, an ALI M1541+M1533 socket 7 motherboard.
It's quite nasty: It does an SMBUS read/write to a yet unidentified device, i think it is the superio, but i'm not sure. The Asus P5A also seriously messes up pci-ids, there is nothing dependable there, so people who want to use flashrom on this board should use -m asus:p5a
but it works :)
This is a board i own myself and this has been tested successfully.
Luc Verhaegen.
On Tue, May 15, 2007 at 12:11:26PM +0200, Luc Verhaegen wrote:
The Asus P5A also seriously messes up pci-ids, there is nothing dependable there, so people who want to use flashrom on this board should use -m asus:p5a
Did anyone have any ideas for more reliable detection?
All I can come up with is to try to extract something meaningful from the current BIOS in RAM.. (not the flash chip)
//Peter
On Tue, May 15, 2007 at 12:34:12PM +0200, Peter Stuge wrote:
On Tue, May 15, 2007 at 12:11:26PM +0200, Luc Verhaegen wrote:
The Asus P5A also seriously messes up pci-ids, there is nothing dependable there, so people who want to use flashrom on this board should use -m asus:p5a
Did anyone have any ideas for more reliable detection?
All I can come up with is to try to extract something meaningful from the current BIOS in RAM.. (not the flash chip)
//Peter
Since nobody bothered to reply, i will now give you my take on this (in as far as this wasn't clear already :)).
DMI is probably what is needed here.
But i kind of am against elaborately depending on another thing which is: A) deprecated. http://www.dmtf.org/standards/dmi/
"Due to the rapid advancement of DMTF technologies, such as CIM, the DMTF defined an "End of Life" process for its Desktop Management Interface (DMI), which ended March 31, 2005"
B) just as easy to bugger up. I'm mostly worried about the same board having multiple names here, changed between bios revisions when developers notice a typo, or because there was yet another marketing u-turn.
We're just pushing the "unable to identify" boundary slightly further, as there will still be cases where dmidecode will be insufficient.
Also, when evaluating the current situation: * Agami aruma is linuxbios only, so name matched. * epia-M is matched properly on pci-ids. * asus A7V8X-MX is matched properly on pci-ids. * Iwill is a buggered up. * Asus P5A is buggered up too.
Now, the P5A is a socket 7 motherboard from 1999, it was hugely popular then, even though it only had half the L2 (L3 when using a K6-2/3) cache of other motherboards. The chance of people running into it again are very slim, i was already very amazed when a user popped up on irc talking about this device.
I think that asus people were little aware of pci-subsystem ids then. I'm not sure when they came into existence, but they weren't in the original pci spec.
So very few people will ever really bother about the P5A. I just added it because the hardware is running right here. It's also an ASUS_FLASH (first vector), which, i now found out first hand, is just as "trivial" as an AWDFLASH (second, full vector).
This only really leaves the Iwill board as the only board for which this is needed, and i don't think that this is enough of a reason to bump the complexity with dmi code _yet_.
On the other hand, if anyone writes up a suitable/cut down dmi decoder for linuxbios, one which: * runs only when the bios isn't linuxbios. * and runs after a failed pci subsystem id match as subsystem ids are a lot cheaper. * adds only a single string to the board enables struct * a single function which returns the board name only: we probably don't want to strcmp all dmi names in the table against all dmi devices known. That would be rather painful and it could lead to false positives. * adds only a single string to the board enables struct.
Then no-one should have much in the way of objections, i just don't want to go there myself (well, maybe if i'm really bored, but really really bored). It might not be too much work, but it isn't going to be as trivial as pci subsystem ids.
I'm not sure what the license of dmi decode is yet.
Also, we do want to make the entries of the board enables all sit on single, but very long lines. I know that this is sniffed at (uwe :p), but believe me, you do want this when more entries are in there. And when you add another string, entries would cover three lines and would be even harder to read.
(my) Conclusion: DMI is probably where we need to go if it is really necessary, but i'm not too keen on doing this myself as it is just more of the same "vendor buggering up" nonsense :)
Luc Verhaegen.
On Thu, May 17, 2007 at 03:21:44AM +0200, Luc Verhaegen wrote:
DMI is probably what is needed here.
Committed in r2677 (with minor cosmetic changes), thanks.
I don't see any better way to do this, so let's just commit for now (but maybe we find a better solution later, who knows).
However, I don't think we want to go down that DMI route.
Uwe.
* Uwe Hermann uwe@hermann-uwe.de [070520 18:19]:
However, I don't think we want to go down that DMI route.
Hm.. as an option, in case someone adds the code (not me),... why not.
It could be a single module, like the linuxbios table module in the tree now.
Does dmidecode provide a library or functions that make this stuff easier? Or do we have to import lots of code?
Stefan
Hi all, This patch fixes the support for Winbond W39V040FA. I've tested the patch and it successfully read and write the binary (with verification) to the flash chip. The previous code is able to read but cannot write into the chip because the block locking registers (BLR) are not set accordingly.
Regards, Darmawan Salihun
On Tue, Aug 21, 2007 at 04:32:28PM +0700, Darmawan Salihun wrote:
This patch fixes the support for Winbond W39V040FA.
Great!
Please add the chip as supported to all relevant documentation files and add your sign-off according to the development guidelines on the wiki, so we can commit.
Thanks!
//Peter
On Tue, Aug 21, 2007 at 04:32:28PM +0700, Darmawan Salihun wrote:
- w39v040fa.c: driver for Winbond W39V040FAx flash models.
- This program is free software; you can redistribute it and/or modify
- it under the terms of the GNU General Public License as published by
- the Free Software Foundation; either version 2 of the License, or
- (at your option) any later version.
- This program is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- GNU General Public License for more details.
- You should have received a copy of the GNU General Public License
- along with this program; if not, write to the Free Software
- Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
The FSF has not been at this address for a *very* long time. The current address is 51 Franklin St, 5th floor, Boston, MA 02110, USA.
Thanks, Ward.
Hi, All things set. See patch.
Regards,
Darmawan Salihun -------------------------------------------------------------------- -= Human knowledge belongs to the world =-
Hi, I forgot to include the my copyright for the added file previously. Fixed. See patch
Regards,
Darmawan Salihun -------------------------------------------------------------------- -= Human knowledge belongs to the world =-
Darmawan Salihun wrote:
Hi, I forgot to include the my copyright for the added file previously. Fixed. See patch
Regards,
Darmawan Salihun
-= Human knowledge belongs to the world =-
Is there a reason you use your own mmap instead of using the already mmapped area in flashrom.c:int map_flash_registers(struct flashchip *flash) ?
On Wed, Aug 22, 2007 at 12:24:38AM +0700, Darmawan Salihun wrote:
I forgot to include the my copyright for the added file previously. Fixed. See patch
Does this lock/unlock also apply to other Winbond chips? The rest of the code looks pretty much the same as for other chips, maybe it lock/unlock functions can be merged into one of the œxisting files?
Thanks, Uwe.
On 8/22/07, Stefan Reinauer stepan@coresystems.de wrote:
Is there a reason you use your own mmap instead of using the already mmapped area in flashrom.c:int map_flash_registers(struct flashchip *flash) ?
Yes, the BLRs are located in areas not covered by mmap in int map_flash_registers(struct flashchip *flash).
Anyway, there's a possibility that I misunderstood map_flash_registers() though. I'm going to recheck it tonight. Last time I check it, the BLRs areas are not covered.
Regards,
Darmawan Salihun -------------------------------------------------------------------- -= Human knowledge belongs to the world =-
On 8/22/07, Uwe Hermann uwe@hermann-uwe.de wrote:
On Wed, Aug 22, 2007 at 12:24:38AM +0700, Darmawan Salihun wrote:
I forgot to include the my copyright for the added file previously. Fixed. See patch
Does this lock/unlock also apply to other Winbond chips? The rest of the code looks pretty much the same as for other chips, maybe it lock/unlock functions can be merged into one of the œxisting files?
This chip is an Firmware Hub (FWH) chip. I don't see the code applies to
other Winbond chip that's not an FWH. As for merging the lock/unlock function, I will need to read other winbond chip to see if there's a possibility for that.
Regards,
Darmawan Salihun -------------------------------------------------------------------- -= Human knowledge belongs to the world =-
On 8/22/07, Stefan Reinauer stepan@coresystems.de wrote:
Darmawan Salihun wrote:
Hi, I forgot to include the my copyright for the added file previously. Fixed. See patch
Regards,
Darmawan Salihun
-= Human knowledge belongs to the world =-
Is there a reason you use your own mmap instead of using the already mmapped area in flashrom.c:int map_flash_registers(struct flashchip *flash) ?
Having analyzed map_flash_registers(), I'm sure I can use that function. I'm going to test it tonight. However, it seems to be the patch will stay as different file because among all of the flashchip support files, there's no one of them that can provide the register unprotect routine(s).
Regards,
Darmawan Salihun -------------------------------------------------------------------- -= Human knowledge belongs to the world =-
On Thu, Aug 23, 2007 at 01:28:04PM +0700, Darmawan Salihun wrote:
However, it seems to be the patch will stay as different file because among all of the flashchip support files, there's no one of them that can provide the register unprotect routine(s).
The idea is to keep code duplication to a minimum where possible, so if W39V are quite similar to another already-supported chip except for these registers it may be a good idea to just add the neccessary register stuff to that chip code instead. (But only called for W39V, of course.)
//Peter
On 8/23/07, Peter Stuge peter@stuge.se wrote:
On Thu, Aug 23, 2007 at 01:28:04PM +0700, Darmawan Salihun wrote:
However, it seems to be the patch will stay as different file because among all of the flashchip support files, there's no one of them that can provide the register unprotect routine(s).
The idea is to keep code duplication to a minimum where possible, so if W39V are quite similar to another already-supported chip except for these registers it may be a good idea to just add the neccessary register stuff to that chip code instead. (But only called for W39V, of course.)
Done.
During testing I found that W39V040FA doesn't seem supporting per-sector erase. As other SST Firmware Hub chips. Therefore, I add the code to give erase support for the chip. See patch.
Regards,
Darmawan Salihun -------------------------------------------------------------------- -= Human knowledge belongs to the world =-
On 8/24/07, Darmawan Salihun darmawan.salihun@gmail.com wrote:
On 8/23/07, Peter Stuge peter@stuge.se wrote:
On Thu, Aug 23, 2007 at 01:28:04PM +0700, Darmawan Salihun wrote:
However, it seems to be the patch will stay as different file because among all of the flashchip support files, there's no one of them that can provide the register unprotect routine(s).
The idea is to keep code duplication to a minimum where possible, so if W39V are quite similar to another already-supported chip except for these registers it may be a good idea to just add the neccessary register stuff to that chip code instead. (But only called for W39V, of course.)
Done.
During testing I found that W39V040FA doesn't seem supporting per-sector erase. As other SST Firmware Hub chips. Therefore, I add the code to give erase support for the chip. See patch.
I had the chance to test per-sector erase once more last night and I can confirm that it's _not_ working in my testbed (DFI 865PE Infinity motherboard -- ICH5-W39V040FA). Therefore, a whole chip erase is the only option as in the latest patch I sent.
Regards,
Darmawan Salihun -------------------------------------------------------------------- -= Human knowledge belongs to the world =-
-
Darmawan Salihun -
Luc Verhaegen -
Peter Stuge -
Peter Stuge -
Stefan Reinauer -
Uwe Hermann -
Ward Vandewege