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.