First of all, I have a very rough (and ugly!) patch that makes flashrom work on FreeBSD. I tried it for reading BIOS image and it worked.
I have an old system with MP2-BX-X, please see some description here: http://www.geocities.com/SiliconValley/3686/delta_mp2.html It is based on 440BX chipset.
Visually I was able to identify that BIOS flash chip is SST39SF020, but flashrom didn't initially recognize it. Some debugging showed that it has JEDEC ids 0x25 for vendor and 0xE5 for device. Very unusual. So I decided to let you know.
The data that flashrom read are very similar to the data in vendor provided bios .bin. There are differences in a chunk of about 12k size, I guess this is where bios stored some config data.
Hi Andriy,
On 14.05.2008 22:30, Andriy Gapon wrote:
First of all, I have a very rough (and ugly!) patch that makes flashrom work on FreeBSD. I tried it for reading BIOS image and it worked.
Can you mail the patch to the list? We want flashrom to be cross-platform and will try to merge the patch or at least a variant of it.
I have an old system with MP2-BX-X, please see some description here: http://www.geocities.com/SiliconValley/3686/delta_mp2.html It is based on 440BX chipset.
Visually I was able to identify that BIOS flash chip is SST39SF020, but flashrom didn't initially recognize it. Some debugging showed that it has JEDEC ids 0x25 for vendor and 0xE5 for device. Very unusual. So I decided to let you know.
The JEDEC vendor ID 0x25 can mean any of the following companies: - Tristar - Zarlink/Mitel - Chameleon systems - Kingmax Semiconductor - Phyworks - Power-One
None of the companies above are in the BIOS flash market AFAICS. Probably this is just a strange reading of real flash contents at ID offsets.
The data that flashrom read are very similar to the data in vendor provided bios .bin. There are differences in a chunk of about 12k size, I guess this is where bios stored some config data.
Can you hexdump the first 8 bytes of the bios.bin you read back from your chip?
Regards, Carl-Daniel
on 15/05/2008 05:32 Carl-Daniel Hailfinger said the following:
Hi Andriy,
On 14.05.2008 22:30, Andriy Gapon wrote:
First of all, I have a very rough (and ugly!) patch that makes flashrom work on FreeBSD. I tried it for reading BIOS image and it worked.
Can you mail the patch to the list? We want flashrom to be cross-platform and will try to merge the patch or at least a variant of it.
The diff is attached. But it is really very ugly and hackish. The most noisy change is that outb has different order of arguments on Linux and FreeBSD.
I have an old system with MP2-BX-X, please see some description here: http://www.geocities.com/SiliconValley/3686/delta_mp2.html It is based on 440BX chipset.
Visually I was able to identify that BIOS flash chip is SST39SF020, but flashrom didn't initially recognize it. Some debugging showed that it has JEDEC ids 0x25 for vendor and 0xE5 for device. Very unusual. So I decided to let you know.
The JEDEC vendor ID 0x25 can mean any of the following companies:
- Tristar
- Zarlink/Mitel
- Chameleon systems
- Kingmax Semiconductor
- Phyworks
- Power-One
None of the companies above are in the BIOS flash market AFAICS. Probably this is just a strange reading of real flash contents at ID offsets.
The data that flashrom read are very similar to the data in vendor provided bios .bin. There are differences in a chunk of about 12k size, I guess this is where bios stored some config data.
Can you hexdump the first 8 bytes of the bios.bin you read back from your chip?
Here it is (16 bytes): 00000000 25 e5 2d 6c 68 35 2d 52 16 00 00 9e 1f 00 00 02
It does include -lh5- signature. I was even able to split it into several chunks on that signature, decompress the chunks and even disassemble some pieces. Interestingly enough this BIOS contains original.tm1 file in addition to original.tmp and the former seems to be a trailer of the latter.
Hmm, I see that 25 e5 is present here. So it might mean that my ported code didn't properly enable flash chip communication?
Andriy Gapon wrote:
The diff is attached. But it is really very ugly and hackish. The most noisy change is that outb has different order of arguments on Linux and FreeBSD.
Oh this is part is really ugly, indeed but there is not much that can be done to make it really nice.
Why don't you use libpci from pciutils btw? It should work on FreeBSD ...
Hmm, I see that 25 e5 is present here. So it might mean that my ported code didn't properly enable flash chip communication?
What's the mainboard? Maybe the mainboard protects the chip with an additional GPIO line.
Stefan
on 15/05/2008 13:24 Stefan Reinauer said the following:
Andriy Gapon wrote:
The diff is attached. But it is really very ugly and hackish. The most noisy change is that outb has different order of arguments on Linux and FreeBSD.
Oh this is part is really ugly, indeed but there is not much that can be done to make it really nice.
Why don't you use libpci from pciutils btw? It should work on FreeBSD ...
Thank you for pointing me in this direction, I missed this one.
Hmm, I see that 25 e5 is present here. So it might mean that my ported code didn't properly enable flash chip communication?
What's the mainboard? Maybe the mainboard protects the chip with an additional GPIO line.
Really old one, MP2-BX-X (rev. D): http://www.geocities.com/SiliconValley/3686/delta_mp2.html
on 15/05/2008 13:24 Stefan Reinauer said the following:
What's the mainboard? Maybe the mainboard protects the chip with an additional GPIO line.
Yes, this turned out to be the case. I glimpsed "somewhere" that on this motherboard value in IO register 0x4037 has to be and-ed with 0xef to enable writing to BIOS area (i.e. bit 4 has to be cleared). In my particular configuration 0x4000 is power-management IO base of PIIX4. And PIIX4 spec says that registers 0x34-37 control GPO signals (general purpose outputs). So this would make it, what, GPO28.
I did that and: $ ./flashrom -r -v -f bios.3.dd Calibrating delay loop... OK. No coreboot table found. Found chipset "Intel PIIX4/4E/4M", enabling flash write... OK. SST39SF020A found at physical address 0xfffc0000. Flash part is SST39SF020A (256 KB). === This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE Please email a report to flashrom@coreboot.org if any of the above operations work correctly for you with this flash part. Please include the full output from the program, including chipset found. Thank you for your help! === Reading Flash...done Verifying flash... VERIFIED.
On 16.05.2008 10:27, Andriy Gapon wrote:
on 15/05/2008 13:24 Stefan Reinauer said the following:
What's the mainboard? Maybe the mainboard protects the chip with an additional GPIO line.
Yes, this turned out to be the case. I glimpsed "somewhere" that on this motherboard value in IO register 0x4037 has to be and-ed with 0xef to enable writing to BIOS area (i.e. bit 4 has to be cleared). In my particular configuration 0x4000 is power-management IO base of PIIX4. And PIIX4 spec says that registers 0x34-37 control GPO signals (general purpose outputs). So this would make it, what, GPO28.
I did that and: $ ./flashrom -r -v -f bios.3.dd Calibrating delay loop... OK. No coreboot table found. Found chipset "Intel PIIX4/4E/4M", enabling flash write... OK. SST39SF020A found at physical address 0xfffc0000. Flash part is SST39SF020A (256 KB). === This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE Please email a report to flashrom@coreboot.org if any of the above operations work correctly for you with this flash part. Please include the full output from the program, including chipset found. Thank you for your help! === Reading Flash...done Verifying flash... VERIFIED.
Very nice. Can you send a patch which adds a board enable routine for your board?
Regards, Carl-Daniel
Add support for Delta MP2-BX-X motherboard. http://www.geocities.com/SiliconValley/3686/delta_mp2.html
Signed-off-by: Andriy Gapon avg@icyb.net.ua
This board can not be uniquely identified by PCI devices, all of them are part of 440BX/PIIX4E chipset.
on 17/05/2008 12:58 Andriy Gapon said the following:
Add support for Delta MP2-BX-X motherboard. http://www.geocities.com/SiliconValley/3686/delta_mp2.html
Signed-off-by: Andriy Gapon avg@icyb.net.ua
This board can not be uniquely identified by PCI devices, all of them are part of 440BX/PIIX4E chipset.
By the way this chip (SST39SF020) and this motherboard can be marked as tested. Past weekend I used (patched) flashrom to read bios and then to write a slightly modified version (cpu microcode updated) and that worked without any issue. Thank you!
Add support for Delta MP2-BX-X motherboard. It requires lowering of of PIIX4 GPO#28 for write access. http://www.geocities.com/SiliconValley/3686/delta_mp2.html
Signed-off-by: Andriy Gapon avg@icyb.net.ua
This board can not be uniquely identified by PCI devices, all of them are part of 440BX/PIIX4E chipset.
P.S. I sent this patch to the list before, but decided to re-send it again. I successfully tested the attached patch with flashrom on FreeBSD for both reading and writing. Flash RAM chip is SST39SF020.
On Thu, May 29, 2008 at 11:58:10AM +0300, Andriy Gapon wrote:
This board can not be uniquely identified by PCI devices, all of them are part of 440BX/PIIX4E chipset.
"artecgroup", "dbe62", "Artec Group DBE62", board_artecgroup_dbe6x},
{0x8086, 0x27b8, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, "kontron", "986lcd-m", "Kontron 986LCD-M", board_kontron_986lcd_m},
- {0x8086, 0x7113, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
{0, 0, 0, 0, 0, 0, 0, 0, NULL, NULL} /* Keep this */"delta", "mp2-bx-x", "Delta MP2-BX-X", board_mp2_bx_x},
};
I see a lot of 0's in the pci-id list, same for the kontron board.
Surely at least one other set of main device ids can be put in there. Due to the lack of subsystem ids this will not give you unique identification, but this will provide an additional safeguard.
For the recent kontron board, though, nothing less than a full set seems acceptable. Unless kontron, as an embedded vendor, couldn't be bothered with card ids as usual.
Luc Verhaegen. SUSE/Novell X Driver Developer.
On 15.05.2008 10:49, Andriy Gapon wrote:
on 15/05/2008 05:32 Carl-Daniel Hailfinger said the following:
Hi Andriy,
On 14.05.2008 22:30, Andriy Gapon wrote:
First of all, I have a very rough (and ugly!) patch that makes flashrom work on FreeBSD. I tried it for reading BIOS image and it worked.
Can you mail the patch to the list? We want flashrom to be cross-platform and will try to merge the patch or at least a variant of it.
The diff is attached. But it is really very ugly and hackish. The most noisy change is that outb has different order of arguments on Linux and FreeBSD.
I think we can merge the outb -> lin_outb change, though I we may want to call it outb_wrapper or somesuch. Can you send that as a separate patch?
I have an old system with MP2-BX-X, please see some description here: http://www.geocities.com/SiliconValley/3686/delta_mp2.html It is based on 440BX chipset.
Visually I was able to identify that BIOS flash chip is SST39SF020, but flashrom didn't initially recognize it. Some debugging showed that it has JEDEC ids 0x25 for vendor and 0xE5 for device. Very unusual. So I decided to let you know.
The JEDEC vendor ID 0x25 can mean any of the following companies:
- Tristar
- Zarlink/Mitel
- Chameleon systems
- Kingmax Semiconductor
- Phyworks
- Power-One
None of the companies above are in the BIOS flash market AFAICS. Probably this is just a strange reading of real flash contents at ID offsets.
The data that flashrom read are very similar to the data in vendor provided bios .bin. There are differences in a chunk of about 12k size, I guess this is where bios stored some config data.
Can you hexdump the first 8 bytes of the bios.bin you read back from your chip?
Here it is (16 bytes): 00000000 25 e5 2d 6c 68 35 2d 52 16 00 00 9e 1f 00 00 02
It does include -lh5- signature. I was even able to split it into several chunks on that signature, decompress the chunks and even disassemble some pieces. Interestingly enough this BIOS contains original.tm1 file in addition to original.tmp and the former seems to be a trailer of the latter.
Hmm, I see that 25 e5 is present here. So it might mean that my ported code didn't properly enable flash chip communication?
Yes, indeed. For details, see Stefan's answer. Oh, and the SST39 series are not really the ideal chips to test flashrom with. I have one of those chips which seemed to be damaged beyond repair after flashing it.
Regards, Carl-Daniel
on 15/05/2008 15:36 Carl-Daniel Hailfinger said the following:
I think we can merge the outb -> lin_outb change, though I we may want to call it outb_wrapper or somesuch. Can you send that as a separate patch?
Maybe call it "OUTB"? Will get back a little bit later with the change.
[snip]
Yes, indeed. For details, see Stefan's answer. Oh, and the SST39 series are not really the ideal chips to test flashrom with. I have one of those chips which seemed to be damaged beyond repair after flashing it.
I once re-flashed it in the past with official bios update using awdflash.exe. BTW, simply dd-ing from /dev/mem at the proper offset returns quite different data, so it seems that flashrom does get closer to the real bios, maybe just not close enough. I know, I am bubbling.
on 15/05/2008 15:48 Andriy Gapon said the following:
on 15/05/2008 15:36 Carl-Daniel Hailfinger said the following:
I think we can merge the outb -> lin_outb change, though I we may want to call it outb_wrapper or somesuch. Can you send that as a separate patch?
Maybe call it "OUTB"? Will get back a little bit later with the change.
Here's a new FreeBSD porting patch. I put FreeBSD (re-)definitions into flash.h, so that they are visible in all .c files. outb is renamed to OUTB. Also, on FreeBSD for access to IO ports you have to have /dev/io open, this is added in flashrom.c. Changes in Makefile: /usr/local/include /usr/local/lib are needed in the paths for libpci. I also had to drop -Werror because compilation produced some warnings (in outb calls) that I couldn't fix: warning: comparison is always true due to limited range of data type
flashrom build obviously requires libpci (from devel/libpci port or package) and gmake.
On 16.05.2008 08:03, Andriy Gapon wrote:
on 15/05/2008 15:48 Andriy Gapon said the following:
on 15/05/2008 15:36 Carl-Daniel Hailfinger said the following:
I think we can merge the outb -> lin_outb change, though I we may want to call it outb_wrapper or somesuch. Can you send that as a separate patch?
Maybe call it "OUTB"? Will get back a little bit later with the change.
Here's a new FreeBSD porting patch. I put FreeBSD (re-)definitions into flash.h, so that they are visible in all .c files. outb is renamed to OUTB. Also, on FreeBSD for access to IO ports you have to have /dev/io open, this is added in flashrom.c. Changes in Makefile: /usr/local/include /usr/local/lib are needed in the paths for libpci. I also had to drop -Werror because compilation produced some warnings (in outb calls) that I couldn't fix: warning: comparison is always true due to limited range of data type
flashrom build obviously requires libpci (from devel/libpci port or package) and gmake.
Thanks for the patch! It looks quite nice and I think we can merge it, but you'll have to rework the Makefile changes. I suggest to rework the Makefile as a separate patch.
Please add a Signed-off-by statement to your patch, otherwise we can't commit. See http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure for details.
Regards, Carl-Daniel
on 17/05/2008 02:29 Carl-Daniel Hailfinger said the following:
On 16.05.2008 08:03, Andriy Gapon wrote:
on 15/05/2008 15:48 Andriy Gapon said the following:
on 15/05/2008 15:36 Carl-Daniel Hailfinger said the following:
I think we can merge the outb -> lin_outb change, though I we may want to call it outb_wrapper or somesuch. Can you send that as a separate patch?
Maybe call it "OUTB"? Will get back a little bit later with the change.
Here's a new FreeBSD porting patch. I put FreeBSD (re-)definitions into flash.h, so that they are visible in all .c files. outb is renamed to OUTB. Also, on FreeBSD for access to IO ports you have to have /dev/io open, this is added in flashrom.c. Changes in Makefile: /usr/local/include /usr/local/lib are needed in the paths for libpci. I also had to drop -Werror because compilation produced some warnings (in outb calls) that I couldn't fix: warning: comparison is always true due to limited range of data type
flashrom build obviously requires libpci (from devel/libpci port or package) and gmake.
Thanks for the patch! It looks quite nice and I think we can merge it, but you'll have to rework the Makefile changes. I suggest to rework the Makefile as a separate patch.
Please add a Signed-off-by statement to your patch, otherwise we can't commit. See http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure for details.
I've just done that. BTW, I've just also determined that the warning is because of the type used by flashrom for IO port number. It is uint16_t, and FreeBSD apparently supports uint32_t and has some checks for actual value. If I change type of variables/parameters used to store the port number to uint32_t the the warning goes away. Do you think it would be good to make this change in flashrom sources? Or is it better to write more elaborate wrappers that would use temporary variable of uint32_t type?