Board Testing HOWTO: Difference between revisions

From flashprog
Jump to navigation Jump to search
Hailfinger@flashrom.org/ (talk)
("Hailfinger@flashrom.org/: 10 revisions: Import coreboot.org/Board testing")
 
("nico.h@gmx.de: Rename => Supported *H*ardware")
 
(12 intermediate revisions by 6 users not shown)
Line 1: Line 1:
This page gives you hints on how to test the coreboot support for your mainboard and all components present on the board.
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.


We try to maintain one build tutorial / status page for every supported coreboot mainboard. The status table is always implemented using the [[Template:Status|status template]] in this wiki. A [[Template:Status#Usage_Example|usage example]] is available, but you can also look at existing status pages.
== Important information ==


For each item in the status table, this page describes how you can test the respective hardware part.
* <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 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'''.
== RAM ==
 
== CPU ==
 
== On-board hardware ==
 
=== IDE ===
 
==== IDE 3.5" ====
 
==== IDE 2.5" ====
 
==== IDE-to-CF ====
 
=== On-board USB ===
 
* Test at least one "full-speed" (USB 1.1) device (e.g. USB keyboard) and one "hi-speed" (USB 2.0) device (e.g. DVB-T adapter).
* Test both of the above devices on all available USB connectors. This includes the usual on-board connectors, but there may also be pin headers on the board where you can add further USB connectors.
 
== Add-on slots/cards ==
 
== Legacy / Super I/O ==
 
=== Parallel port ===
 
* Try loading the '''ppdev''' and '''parport_pc''' kernel modules: '''modprobe ppdev; modprobe parport_pc'''. Check if there were errors using <tt>dmesg</tt>.
* Try to actually use a parallel port device (e.g. a printer).
* If there are errors/problems, please post the '''[[Superiotool|superiotool -dV]]''' output on the [[Mailinglist|mailing list]] and ask the developers for help.
 
=== PC speaker ===
 
* Try to create a beep on the PC speaker. There are various ways to do that, e.g. you can use the Debian package '''beep''' ('''apt-get install beep''').
* If that doesn't work, check that you actually have a speaker correctly attached and also try '''modprobe pcspkr'''.
 
== Miscellaneous ==
 
=== Flashrom ===
 
* <div style="color:red">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>
* To check whether [[flashrom]] knows about your chipset and ROM chip, run '''flashrom'''.
* 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 '''flashrom -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.)
* 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).
** Try inserting a ROM chip which you can safely overwrite (e.g. an empty one you bought). Then write an image onto the chip, which is ''different'' from what's on the chip right now: '''flashrom -w new.bin'''. If this works and flashrom reports "VERIFIED" your board is supported by flashrom.
** 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 CMOS menu first, or set a jumper on your board (this is highly board-dependent). Also, you might have to use the flashrom <tt>--mainboard</tt> switch for some boards.
** 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 flashrom still ''does'' detect your chipset and ROM chip), there's quite likely a board-specific initialization required in flashrom, 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 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 flashrom had a generic block protection checker, we'd be 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.
*** 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 mailing flashrom@flashrom.org and we'll check/update the [[Flashrom#Supported_mainboards|list of boards supported by flashrom]] accordingly (whether it works or does not work on your board).
* 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]].
 
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).


== Updating the wiki ==


{{GPL}}
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.

Retrieved from "https://flashprog.org/wiki/index.php?title=Board_Testing_HOWTO&oldid=264"