Board Testing HOWTO: Difference between revisions
Hailfinger@flashrom.org/ (talk) ("Hailfinger@flashrom.org/: More testing info") |
("nico.h@gmx.de: Rename => Supported *H*ardware") |
||
(9 intermediate revisions by 5 users not shown) | |||
Line 1: | Line 1: | ||
This page gives you hints on how to test | This page gives you mainly hints on how to test flashprog support on mainboards. Testing for graphics / network / SATA cards and external programmer devices is similar but less dangerous. | ||
==Important information== | == Important information == | ||
* <div style="color: | * <div style="color:cb4b16">DO NOT ATTEMPT TO FOLLOW THESE INSTRUCTIONS UNLESS YOU KNOW WHAT YOU ARE DOING! THIS CAN RENDER YOUR MAINBOARD TOTALLY UNUSABLE! YOU HAVE BEEN WARNED!</div> | ||
* If you have a laptop/notebook/netbook, please do NOT try | * If you have a pre-2012 laptop/notebook/netbook, please do '''NOT''' try flashprog because interactions with the EC on these machines might crash your machine during flashing. Flashprog tries to detect if a machine is a laptop, but not all laptops follow the standard, so this is not 100% reliable. | ||
* To check whether | * To check whether flashprog knows about your chipset and ROM chip, run '''flashprog -p internal'''. | ||
* If it says "Found chipset CHIPSETNAME..." and "CHIPNAME found at..." that's a good first sign. | * If it says "Found chipset CHIPSETNAME..." and "CHIPNAME found at..." that's a good first sign. | ||
* To check if you can read the existing BIOS image from the chip, run ''' | * To check if you can read the existing BIOS image from the chip, run '''flashprog -p internal -r backup.bin'''. Make sure that '''backup.bin''' contains a useful BIOS image (some chipsets will return 0xff for large areas of flash without any error messages, but there might be actually large areas of 0xff in the original image as well). | ||
* Now the really important part, checking if ''writing'' an image on the chip works: | * Now the really important part, checking if ''writing'' an image on the chip works: | ||
** First make sure you have a backup chip containing the original BIOS. Also, you should have verified that it actually boots your system successfully. Put away that backup chip somewhere safe | ** First, if the board has a flash socket and you have spare chips, make sure you have a backup chip containing the original BIOS. Also, you should have verified that it actually boots your system successfully. Put away that backup chip somewhere safe and insert a chip which you can safely overwrite (e.g. an empty one you bought). | ||
** If that is not possible make sure you have some other way for complete recovery, e.g. an external programmer that can do [[ISP|in-circuit programming]] on the board in question. | |||
** If not, you might try to enable the "Enable BIOS Update" or "Write-protect BIOS" or similar options in your BIOS | ** Then write an image onto the chip, which is ''different'' from what's on the chip right now: '''flashprog -p internal -w new.bin'''. If the image is equal you will get a notice since r1680. If this works and flashprog reports "VERIFIED" your board is supported by flashprog. | ||
** If none of the above helps (but | ** If not, you might try to enable the "Enable BIOS Update" or "Write-protect BIOS" or similar options in your BIOS menu first, or set a jumper on your board (this is highly board-dependent). Also, you might have to use the flashprog '''--mainboard''' switch for some boards. | ||
** If none of the above helps (but flashprog still ''does'' detect your chipset and ROM chip), there's quite likely a board-specific initialization required in flashprog, which is non-trivial to add (e.g. toggling certain custom GPIO lines etc). In that case, contact us as we may be able to help. | |||
** If you can't risk a write on a given chip and if the chip is SPI, the following guidelines may help: | ** If you can't risk a write on a given chip and if the chip is SPI, the following guidelines may help: | ||
*** Try probing. | *** Try probing. | ||
*** For ICH/VIA SPI, lockdown can mean probe works, but write/erase doesn't. It can also mean that probe does not work, but write/read/erase (or any subset thereof) would work. For all other SPI chipsets, there is no such lockdown, so you can issue any erase/write/read command. | *** For ICH/VIA SPI, lockdown can mean probe works, but write/erase or even read doesn't. It can also mean that probe does not work, but write/read/erase (or any subset thereof) would work. For all other SPI chipsets, there is no such lockdown, so you can issue any erase/write/read command. | ||
*** However, some SPI chips have a WP# pin which causes the block protection bits to become readonly. Now if | *** However, some SPI chips have a WP# pin which causes the block protection bits to become readonly. Now if flashprog has a generic block protection checker for your chip, we're able to figure out if write/erase is possible. Basically, you can check if you need a board enable by setting all block protection bits, then unsetting them. If either of the operations fail, you need a board enable. If they succeed, erase and write are guaranteed to work. | ||
* Please tell us about your results by sending the output of | * Please tell us about your results by sending the output of '''flashprog -p internal -V''', '''lspci -nnvvxxx''', '''superiotool -deV''' and the exact board manufacturer and model name and all of your observations and test results to the flashprog [[Contact#Mailing_List|mailing list]]. | ||
and the exact manufacturer and model name and all of your observations and test results to the | |||
If flashprog finds your flash chip and everything works, we'd like to hear about it. If your flash chip is found, but not all operations work, we'd like to hear about it. If your flash chip or your chipset is not found, we'd like to hear about it as well, and we'll check/update the [[Supported Hardware#Supported_mainboards|list of boards supported by flashprog]] accordingly (whether it works or does not work on your board). | |||
and we'll check/update the [[ | |||
== Updating the wiki == | == Updating the wiki == | ||
We try to collect the status for every supported mainboard/card/device on [[Supported Hardware|our autogenerated list of supported hardware]]. | |||
If you test something we should know about please send a mail to the [[Contact#Mailing_List|mailing list]]. |
Latest revision as of 17:46, 3 December 2023
This page gives you mainly hints on how to test flashprog support on mainboards. Testing for graphics / network / SATA cards and external programmer devices is similar but less dangerous.
Important information
- DO NOT ATTEMPT TO FOLLOW THESE INSTRUCTIONS UNLESS YOU KNOW WHAT YOU ARE DOING! THIS CAN RENDER YOUR MAINBOARD TOTALLY UNUSABLE! YOU HAVE BEEN WARNED!
- If you have a pre-2012 laptop/notebook/netbook, please do NOT try flashprog because interactions with the EC on these machines might crash your machine during flashing. Flashprog tries to detect if a machine is a laptop, but not all laptops follow the standard, so this is not 100% reliable.
- To check whether flashprog knows about your chipset and ROM chip, run flashprog -p internal.
- If it says "Found chipset CHIPSETNAME..." and "CHIPNAME found at..." that's a good first sign.
- To check if you can read the existing BIOS image from the chip, run flashprog -p internal -r backup.bin. Make sure that backup.bin contains a useful BIOS image (some chipsets will return 0xff for large areas of flash without any error messages, but there might be actually large areas of 0xff in the original image as well).
- Now the really important part, checking if writing an image on the chip works:
- First, if the board has a flash socket and you have spare chips, make sure you have a backup chip containing the original BIOS. Also, you should have verified that it actually boots your system successfully. Put away that backup chip somewhere safe and insert a chip which you can safely overwrite (e.g. an empty one you bought).
- If that is not possible make sure you have some other way for complete recovery, e.g. an external programmer that can do in-circuit programming on the board in question.
- Then write an image onto the chip, which is different from what's on the chip right now: flashprog -p internal -w new.bin. If the image is equal you will get a notice since r1680. If this works and flashprog reports "VERIFIED" your board is supported by flashprog.
- If not, you might try to enable the "Enable BIOS Update" or "Write-protect BIOS" or similar options in your BIOS menu first, or set a jumper on your board (this is highly board-dependent). Also, you might have to use the flashprog --mainboard switch for some boards.
- If none of the above helps (but flashprog still does detect your chipset and ROM chip), there's quite likely a board-specific initialization required in flashprog, which is non-trivial to add (e.g. toggling certain custom GPIO lines etc). In that case, contact us as we may be able to help.
- If you can't risk a write on a given chip and if the chip is SPI, the following guidelines may help:
- Try probing.
- For ICH/VIA SPI, lockdown can mean probe works, but write/erase or even read doesn't. It can also mean that probe does not work, but write/read/erase (or any subset thereof) would work. For all other SPI chipsets, there is no such lockdown, so you can issue any erase/write/read command.
- However, some SPI chips have a WP# pin which causes the block protection bits to become readonly. Now if flashprog has a generic block protection checker for your chip, we're able to figure out if write/erase is possible. Basically, you can check if you need a board enable by setting all block protection bits, then unsetting them. If either of the operations fail, you need a board enable. If they succeed, erase and write are guaranteed to work.
- Please tell us about your results by sending the output of flashprog -p internal -V, lspci -nnvvxxx, superiotool -deV and the exact board manufacturer and model name and all of your observations and test results to the flashprog mailing list.
If flashprog finds your flash chip and everything works, we'd like to hear about it. If your flash chip is found, but not all operations work, we'd like to hear about it. If your flash chip or your chipset is not found, we'd like to hear about it as well, and we'll check/update the list of boards supported by flashprog accordingly (whether it works or does not work on your board).
Updating the wiki
We try to collect the status for every supported mainboard/card/device on our autogenerated list of supported hardware. If you test something we should know about please send a mail to the mailing list.