Hello,
See below the output of the /flashrom -p internal -V on a National Instruments 8351 Rackmount Controller. It is a rebranded MSI MS-9218. After specifying the laptop:this_is_not_a_laptop option the flashrom is able to detect and read the flash fine:
Proceeding anyway because user forced us to. Found chipset "Intel ICH7/ICH7R". Enabling flash write... OK. Found SST flash chip "SST49LF008A" (1024 kB, FWH) at physical address 0xfff00000. Reading flash... done.
root@TS333:~/flashrom# ./flashrom -p internal -V flashrom v0.9.6.1-r1620 on Linux 2.6.32-41-generic-pae (i686) flashrom is free software, get the source code at http://www.flashrom.org
flashrom was built with libpci 3.0.0, GCC 4.4.3, little endian Command line (3 args): ./flashrom -p internal -V Initializing internal programmer No coreboot table found. DMI string system-manufacturer: "MSI" DMI string system-product-name: "GrantsDale CRB Board" DMI string system-version: "MSI CORPORATION" DMI string baseboard-manufacturer: "bbl" DMI string baseboard-product-name: "MS-9218" DMI string baseboard-version: "Revision A " DMI string chassis-type: "Other" DMI chassis-type is not specific enough. W836xx enter config mode worked or we were already in config mode. W836xx leave config mode had no effect. Active config mode, unknown reg 0x20 ID: e9. Please send the output of "flashrom -V" to flashrom@flashrom.org with W836xx: your board name: flashrom -V as the subject to help us finish support for your Super I/O. Thanks. ======================================================================== WARNING! You may be running flashrom on an unsupported laptop. We could not detect this for sure because your vendor has not setup the SMBIOS tables correctly. You can enforce execution by adding '-p internal:laptop=this_is_not_a_laptop' to the command line, but please read the following warning if you are not sure.
Laptops, notebooks and netbooks are difficult to support and we recommend to use the vendor flashing utility. The embedded controller (EC) in these machines often interacts badly with flashing. See http://www.flashrom.org/Laptops for details.
If flash is shared with the EC, erase is guaranteed to brick your laptop and write may brick your laptop. Read and probe may irritate your EC and cause fan failure, backlight failure and sudden poweroff. You have been warned. ======================================================================== Aborting. Error: Programmer initialization failed.
Please see below the output of the dmidecode:
SMBIOS 2.33 present. 33 structures occupying 1025 bytes. Table at 0x000DC010.
Handle 0x0000, DMI type 0, 20 bytes BIOS Information Vendor: MSI Version: P9218NI V1.36 Release Date: 10/26/2006 Address: 0xE4F80 Runtime Size: 110720 bytes ROM Size: 1024 kB Characteristics: ISA is supported PCI is supported PC Card (PCMCIA) is supported PNP is supported APM is supported BIOS is upgradeable BIOS shadowing is allowed ESCD support is available USB legacy is supported Smart battery is supported BIOS boot specification is supported
Handle 0x0001, DMI type 1, 25 bytes System Information Manufacturer: MSI Product Name: GrantsDale CRB Board Version: MSI CORPORATION Serial Number: 0123456789 UUID: Not Settable Wake-up Type: Power Switch
Handle 0x0002, DMI type 2, 8 bytes Base Board Information Manufacturer: bbl Product Name: MS-9218 Version: Revision A Serial Number: 400
Handle 0x0003, DMI type 3, 17 bytes Chassis Information Manufacturer: MSI Type: Other Lock: Not Present Version: N/A Serial Number: None Asset Tag: No Asset Tag Boot-up State: Safe Power Supply State: Safe Thermal State: Safe Security Status: None OEM Information: 0x00001234
Handle 0x0004, DMI type 4, 35 bytes Processor Information Socket Designation: LGA775/PRESCOTT Type: Central Processor Family: Pentium 4 Manufacturer: Intel Corporation ID: 44 0F 00 00 FF FB EB BF Signature: Type 0, Family 15, Model 4, Stepping 4 Flags: FPU (Floating-point unit on-chip) VME (Virtual mode extension) DE (Debugging extension) PSE (Page size extension) TSC (Time stamp counter) MSR (Model specific registers) PAE (Physical address extension) MCE (Machine check exception) CX8 (CMPXCHG8 instruction supported) APIC (On-chip APIC hardware supported) SEP (Fast system call) MTRR (Memory type range registers) PGE (Page global enable) MCA (Machine check architecture) CMOV (Conditional move instruction supported) PAT (Page attribute table) PSE-36 (36-bit page size extension) CLFSH (CLFLUSH instruction supported) DS (Debug store) ACPI (ACPI supported) MMX (MMX technology supported) FXSR (Fast floating-point save and restore) SSE (Streaming SIMD extensions) SSE2 (Streaming SIMD extensions 2) SS (Self-snoop) HTT (Hyper-threading technology) TM (Thermal monitor supported) PBE (Pending break enabled) Version: Intel(R) Pentium(R) D CPU 3.00GHz Voltage: 1.8 V External Clock: Unknown Max Speed: 3800 MHz Current Speed: 3000 MHz Status: Populated, Enabled Upgrade: ZIF Socket L1 Cache Handle: 0x0005 L2 Cache Handle: 0x0006 L3 Cache Handle: Not Provided Serial Number: <BAD INDEX> Asset Tag: <BAD INDEX> Part Number: <BAD INDEX>
Invalid entry length (0). DMI table is broken! Stop.
Our company is manufacturing a wide range of embedded x86 based PXI controllers. I have checked some, and most of them was worked with the flashrom after specifying the this_is_not_a_laptop switch. What kind of information do you need to get them officaly verified and supported?
Thank you for the flashrom, this is a great program!
Regards, Miklós Márton | Test Engineer / NIH Test Development | Tel: +36-30-521-1052 | NI Hungary Kft
NI Hungary Kft. H-4031 Debrecen Határ u 1/A. Telefon: +36 (52) 515 400 Cégjegyzékszám: 09-09-009315 Bejegyezte: Debreceni Törvényszék Cégbírósága
On Tue, 30 Oct 2012 19:22:15 +0100 "Miklos Marton" miklos.marton@ni.com wrote:
Hello Miklos and thanks for your report!
I presume you did not try to write to that board yet. Because you left out the laptop force switch on the second, verbose run, there is a lot of information missing, but i think it would be safe to try writing to it in general anyway (and if you need to e.g. update the firmware). It could be that there is a write protection though, but flashrom would show us that if you try erasing/writing and there is a write protection active.
Our company is manufacturing a wide range of embedded x86 based PXI controllers. I have checked some, and most of them was worked with the flashrom after specifying the this_is_not_a_laptop switch. What kind of information do you need to get them officaly verified and supported?
By testing do you mean that you have also tried writing or just probing/reading? On most flash chips flashrom can not tell if it is write protected or not, one has to try.
The general policy to add a board to our supported list is therefore a log that shows a legit write. Please note that this requires verbose output, because only then flashrom shows what it really does. Without that you would not see if flashrom skips the whole erase/write process because the flash chip content is equal to the image file.
The question is though if it makes sense to include PXI controllers that (please forgive me :) are not very common. But if you want to do the testing i can add them of course.
BTW the laptop force switch depends on the DMI chassis information. If your firmware engineers would use something else than "Other" (or one of the laptop/mobile values) you would not need to specify it.
Hello,
I presume you did not try to write to that board yet. Because you left out the laptop force switch on the second, verbose run, there is a lot of information missing, but i think it would be safe to try writing to it in general anyway (and if you need to e.g. update the firmware). It could be that there is a write protection though, but flashrom would show us that if you try erasing/writing and there is a write protection active.
Yes I have not tried to write, yet but I can do it without any problems, because I have Willem programmer, and have ability to de/resolder the flash. I will flash it and let you know the result and the outputs.
By testing do you mean that you have also tried writing or just probing/reading? On most flash chips flashrom can not tell if it is write protected or not, one has to try.
The general policy to add a board to our supported list is therefore a log that shows a legit write. Please note that this requires verbose output, because only then flashrom shows what it really does. Without that you would not see if flashrom skips the whole erase/write process because the flash chip content is equal to the image file.
The question is though if it makes sense to include PXI controllers that (please forgive me :) are not very common. But if you want to do the testing i can add them of course.
Personally I have tried to reflash one of our PIXe-8106 controllers, and it had been flashed fine, and the BIOS revision had been also updated. I have access to all of our products for trying out BIOS upgrade on it even if some would be unsuccessful, I can replace/reflash using external programmer.
Well I know that the PXI systems are not very common things.
Right now we are using different platforms for the Functional Verification Test in the manufacturing. Some older controllers are still flashed under MS-DOS, the newer ones under Windows. It would be great for us if we could have an uniform preferably Linux based platform for flashing the BIOS images during the manufacturing process.
If it is not a problem/a lot work for you I would like to test our product's flashrom compatibility and send you the logs one-by-one to get them officially supported.
Thank you for your help!
Regards, Miklós Márton | Test Engineer / NIH Test Development | Tel: +36-30-521-1052 | NI Hungary Kft
From: Stefan Tauner stefan.tauner@student.tuwien.ac.at To: "Miklos Marton" miklos.marton@ni.com Cc: flashrom@flashrom.org Date: 2012.10.31 11:57 Subject: Re: [flashrom] W836xx:NI 8351 (rebranded MSI MS-9218) flashrom -V
On Tue, 30 Oct 2012 19:22:15 +0100 "Miklos Marton" miklos.marton@ni.com wrote:
Hello Miklos and thanks for your report!
I presume you did not try to write to that board yet. Because you left out the laptop force switch on the second, verbose run, there is a lot of information missing, but i think it would be safe to try writing to it in general anyway (and if you need to e.g. update the firmware). It could be that there is a write protection though, but flashrom would show us that if you try erasing/writing and there is a write protection active.
Our company is manufacturing a wide range of embedded x86 based PXI controllers. I have checked some, and most of them was worked with the flashrom after specifying the this_is_not_a_laptop switch. What kind of information do you need to get them officaly verified and supported?
By testing do you mean that you have also tried writing or just probing/reading? On most flash chips flashrom can not tell if it is write protected or not, one has to try.
The general policy to add a board to our supported list is therefore a log that shows a legit write. Please note that this requires verbose output, because only then flashrom shows what it really does. Without that you would not see if flashrom skips the whole erase/write process because the flash chip content is equal to the image file.
The question is though if it makes sense to include PXI controllers that (please forgive me :) are not very common. But if you want to do the testing i can add them of course.
BTW the laptop force switch depends on the DMI chassis information. If your firmware engineers would use something else than "Other" (or one of the laptop/mobile values) you would not need to specify it.
On Wed, 31 Oct 2012 12:39:40 +0100 "Miklos Marton" miklos.marton@ni.com wrote:
It would be great for us if we could have an uniform preferably Linux based platform for flashing the BIOS images during the manufacturing process.
If it is not a problem/a lot work for you I would like to test our product's flashrom compatibility and send you the logs one-by-one to get them officially supported.
I think your customers and even less your own manufacturing staff would care much about our supported hardware list, if you tell them explicitly to use the vanilla (or your own) version of flashrom. :) But as i wrote before, if you think it is worth it, send the logs and i'll at them. It is always nice to get feedback from companies that use flashrom like this, thank you.
This patch shows what is needed to add a single board: http://patchwork.coreboot.org/patch/2846/ Namely a single line added to print.c.
I usually collect a number of such and similar patches and commit them together every few weeks-months, like this one: http://patchwork.coreboot.org/patch/3527/
The easiest procedure for me would be if you mail such a single line together with your log, or even a patch that combines many of them.
-
Miklos Marton -
Stefan Tauner