Motherboard Porting Guide: Difference between revisions

From coreboot
Jump to navigation Jump to search
No edit summary
No edit summary
 
(29 intermediate revisions by 4 users not shown)
Line 6: Line 6:
== HOWTO to find a way ==
== HOWTO to find a way ==


* find a model and manufacturer of your mobo
* find the model and manufacturer of your motherboard.
* download these tools:
* fetch '''Coreboot source code''': git clone http://review.coreboot.org/p/coreboot
  # git clone http://review.coreboot.org/p/coreboot
* fetch and built these tools (you'll need to have at least '''libpci''' and '''pciutils''' installed for some of these):
   # superiotool cd coreboot/util/superiotool ; make ; sudo make install )
   '''superiotool''': cd coreboot/util/superiotool; make; sudo make install
   # inteltool ( cd coreboot/util/inteltool ; make ; sudo make install )
   '''inteltool''':cd coreboot/util/inteltool; make; sudo make install
   # ectool ( cd coreboot/util/ectool ; make ; sudo make install )
   '''ectool''': cd coreboot/util/ectool; make; sudo make install
   # dmidecode ( cvs -z3 -d:pserver:anonymous@cvs.savannah.nongnu.org:/sources/dmidecode co dmidecode )
   '''dmidecode''': git clone https://git.savannah.nongnu.org/git/dmidecode.git
   # msrtool ( cd coreboot/util/msrtool ; ./configure ; make ; sudo make install )
   '''msrtool''': cd coreboot/util/msrtool; ./configure; make; sudo make install
   # nvramtool ( cd coreboot/util/nvramtool ; make ; sudo make install )
   '''nvramtool''': cd coreboot/util/nvramtool; make; sudo make install
   # flashrom ( svn co svn://coreboot.org/flashrom/trunk flashrom )
   '''flashrom''': git clone https://review.coreboot.org/flashrom.git
* make and install them (make; sudo make install) - you need at least libpci/pciutils
* check that your distro have these tools and install them:
* check that your distro have this tools and install them:
   # lspci
   # lspci
   # dmesg
   # dmesg
   # acpitool
   # acpitool
  # lspnp
   # lsusb
   # lsusb
* Do this commands:
  # acpidump
   # lspci -nnvvvxxxx > lscpi.log
* Loading this kernel module will be needed for one of the steps below:
  # lspnp -vv > lspnp.log
  # modprobe msr
   # lsusb -vvv > lsusb.log
* Perform these commands '''as root''':
   # superiotool -deV > superiotool.log
   lspci -nnvvvxxxx > lspci.log 2> lspci.err.log
   # inteltool -a > inteltool.log
   lsusb -vvv > lsusb.log 2> lsusb.err.log
   # ectool > ectool.log
   superiotool -deV > superiotool.log 2> superiotool.err.log
   # msrtool > msrtool.log
   inteltool -a > inteltool.log 2> inteltool.err.log
   # dmidecode > dmidecode.log
   ectool -i > ectool.log 2> ectool.err.log
   # biosdecode > biosdecode.log
   msrtool > msrtool.log 2> msrtool.err.log
   # nvramtool -x > nvramtool.log
   dmidecode > dmidecode.log 2> dmidecode.err.log
   # dmesg > dmesg.log
   biosdecode > biosdecode.log 2> biosdecode.err.log
   # flashrom -V -p internal:laptop=force_I_want_a_brick > flashrom_info.log
   nvramtool -x > nvramtool.log 2> nvramtool.err.log
   # flashrom -V -p internal:laptop=force_I_want_a_brick -r rom.bin > flashrom_read.log
   dmesg > dmesg.log 2> dmesg.err.log
* Save all logs in safe place, and also rom.bin file.  
  acpidump > acpidump.log 2> acpidump.err.log
* try to find information - what EC (if on laptop) or Super I/O chip (if any) is used in your mobo (may be some info in Service Manuals or Disassembly guides)
   for x in /sys/class/sound/card0/hw*; do cat "$x/init_pin_configs" > pin_"$(basename "$x")"; done
* try to find your Super I/O / EC chip datasheet
  for x in /proc/asound/card0/codec#*; do cat "$x" > "$(basename "$x")"; done
  cat /proc/cpuinfo > cpuinfo.log 2> cpuinfo.err.log
  cat /proc/ioports > ioports.log 2> ioports.err.log
  cat /sys/class/input/input*/id/bustype > input_bustypes.log
 
* And also these, which may not work on some vendor firmware:
  flashrom -V -p internal:laptop='''force_I_want_a_brick''' > flashrom_info.log 2> flashrom_info.err.log
   flashrom -V -p internal:laptop='''force_I_want_a_brick''' -r rom.bin > flashrom_read.log 2> flashrom_read.err.log
 
Here's the warning you get when running the above commands '''without''' the '''laptop=force_I_want_a_brick''' parameter on an unsupported laptop:
 
========================================================================
WARNING! You seem to be running flashrom on an unsupported laptop.
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 the manpage and https://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.
========================================================================
 
* Save all logs in a safe place, as well as the '''rom.bin''' file.
* Find what chip does your motherboard use. The name of the chip is present in '''flashrom_info.log''' but is not always exact as some chips have several packaging variants (e.g. SOIC-16, SOIC-8 and TSOP). Consult [http://flashrom.org/Technology this page] for more info on possible chip formats. If possible make a high-resolution (600dpi or higher) scan of the motherboard. Make a scan, not a photo, as cameras typically lack enough resolution to properly identify individual chips.
* try to find information about which EC (if on laptop) or Super I/O chip (if any) is used in your mther board (You may also find some info in Service Manuals or Disassembly Guides)
* try to find the datasheets for your Super I/O / EC chip
 
For laptop, additionally:
For laptop, additionally:
* if you see that ectool return some fake staff - like only 'FF' or '00' - so you have custom EC configuration, it's a hard work for support
* if you see that '''ectool''' returns some fake stuff, like only 'FF' or '00', then you have a custom EC configuration and it'll be a harder work for supporting it.
* if you see that ectool return looks like 'right' output - you have a big chances for support
* if you see that '''ectool''' return looks like 'right' output - you have a big chance for support
* you need to find from thease outputs Super I/O / EC chip name, or if not see this - disassembly your laptop
* you need to figure out the name of the Super I/O / EC chip based on the above log outputs. If you can't find it on the logs, then you'll have to disassemble your laptop to look at the actual chips.
 
=== Preparing recovery method ===
 
Inevitably when you develop coreboot there will be unbootable builds and so you'll need a way to unbrick your machine after installing a failed image. There are several ways to do so. Main ones are:
* In-system Programming. For more info consult [http://flashrom.org/ISP this page].
* Hotswap. Consult [http://flashrom.org/Technology this page].


=== Selecting Similar Board ===
In any case you have to locate the flash chip. Note the chipname from flashrom output. Teardown your system and find that chip. For how it usually looks like, consult [http://flashrom.org/Technology this page]. If you have a scanner, take a high-resolution scan of your motherboard since it may be useful later.


TODO.
=== Selecting a Similar Board ===


=== Modifying existing board ===
The most important criteria for finding a similar board is the chipset. Look at northbridge (device 0:0.0) and southbridge (LPC controller) in the lspci output. Use '''grep''' on the coreboot tree to find how those chipsets are named, and then grep for the chipset name (case-insensitive) to find a board which uses it. If there are several of them, try to match (in order of decreasing importance) the system type (desktop/laptop), Super I/O and manufacturer.


TODO.


=== Adding a new board ===
=== Adding a new board ===


This is a two step process. If you mainboard already exists, skip to next section.
This is a two step process. If your mainboard already exists in the coreboot source tree, skip to next section.


==== Adding a new vendor to tree ====
==== Adding a new vendor to the tree ====


Create a directory in src/mainboard with the same name as vendor name. Add to src/mainboard/Kconfig
Create a directory in '''src/mainboard''' with the same name as the vendor name. Add to '''src/mainboard/Kconfig''' a new vendor entry. The rest of this example uses "foo" vendor.
new vendor entry, the rest of this example uses "foo" vendor.


  config VENDOR_FOO
  config VENDOR_FOO
       bool "Foo"
       bool "Foo"


Add also a include for new Kconfig file which holds the vendor motherboards in the vendor directory
Add also an include for the new Kconfig file which holds the vendor motherboards in the vendor directory:


  source "src/mainboard/foo/Kconfig"
  source "src/mainboard/foo/Kconfig"


Create a src/mainboard/foo/Kconfig, copy from other vendor, and change the vendor name. Delete all mainboards.  
Create a '''src/mainboard/foo/Kconfig''' file, copying it from some other vendor, and then change the vendor name. Delete all mainboards.


==== Adding a new motherboard to tree ====
==== Adding a new motherboard to the tree ====


Asume that vendor name is foo and board type is bar. Add new configuration item in src/mainboard/foo/Kconfig
Assume in these examples that the vendor name is '''foo''' and the board type is '''bar'''. Add a new configuration item in '''src/mainboard/foo/Kconfig''':


  config BOARD_FOO_BAR
  config BOARD_FOO_BAR
         bool "BAR"
         bool "BAR"


Add include for board specific config:
Add include a board specific config:


  source "src/mainboard/foo/bar/Kconfig"
  source "src/mainboard/foo/bar/Kconfig"


==== Adjusting contents of new board directory ====
==== Adjusting the contents of the new board directory ====
 
Now copy the files of your similar board and start adjusting them. Your first stop is the '''Kconfig''' file.
 
* You need to change the conditional statement in the first line to match your board:
 
-if BOARD_VENDOR_'''BAR'''
+if BOARD_VENDOR_'''BAZ'''
 
* Change '''MAINBOARD_DIR''' and names.
* Change device options to match your config.
* Next stop is '''mainboard.c''' where you should adjust the GPIO config based on the '''inteltool''' dump performed above.
* Now you can build it, flash the resulting image and see what fails.
* Later adjust '''hda_verb.h''' to get sound working properly (use initial pin dumps for reference).
 
Look through the options and adjust.


Adjust Kconfig to fit the new vendor/model name and dont forget to change MAINBOARD_DIR and MAINBOARD_PART_NUMBER.
Adjust '''Kconfig''' to fit the new vendor/model name and don't forget to change '''MAINBOARD_DIR''' and '''MAINBOARD_PART_NUMBER'''.

Latest revision as of 16:11, 2 March 2020

Motherboard Porting Guide

Please note that this is WIP work.

HOWTO to find a way

  • find the model and manufacturer of your motherboard.
  • fetch Coreboot source code: git clone http://review.coreboot.org/p/coreboot
  • fetch and built these tools (you'll need to have at least libpci and pciutils installed for some of these):
 superiotool: cd coreboot/util/superiotool; make; sudo make install
 inteltool:cd coreboot/util/inteltool; make; sudo make install
 ectool: cd coreboot/util/ectool; make; sudo make install
 dmidecode: git clone https://git.savannah.nongnu.org/git/dmidecode.git
 msrtool: cd coreboot/util/msrtool; ./configure; make; sudo make install
 nvramtool: cd coreboot/util/nvramtool; make; sudo make install
 flashrom: git clone https://review.coreboot.org/flashrom.git
  • check that your distro have these tools and install them:
 # lspci
 # dmesg
 # acpitool
 # lsusb
 # acpidump
  • Loading this kernel module will be needed for one of the steps below:
 # modprobe msr
  • Perform these commands as root:
 lspci -nnvvvxxxx > lspci.log 2> lspci.err.log
 lsusb -vvv > lsusb.log 2> lsusb.err.log
 superiotool -deV > superiotool.log 2> superiotool.err.log
 inteltool -a > inteltool.log 2> inteltool.err.log
 ectool -i > ectool.log 2> ectool.err.log
 msrtool > msrtool.log 2> msrtool.err.log
 dmidecode > dmidecode.log 2> dmidecode.err.log
 biosdecode > biosdecode.log 2> biosdecode.err.log
 nvramtool -x > nvramtool.log 2> nvramtool.err.log
 dmesg > dmesg.log 2> dmesg.err.log
 acpidump > acpidump.log 2> acpidump.err.log
 for x in /sys/class/sound/card0/hw*; do cat "$x/init_pin_configs" > pin_"$(basename "$x")"; done
 for x in /proc/asound/card0/codec#*; do cat "$x" > "$(basename "$x")"; done
 cat /proc/cpuinfo > cpuinfo.log 2> cpuinfo.err.log
 cat /proc/ioports > ioports.log 2> ioports.err.log
 cat /sys/class/input/input*/id/bustype > input_bustypes.log
  • And also these, which may not work on some vendor firmware:
 flashrom -V -p internal:laptop=force_I_want_a_brick > flashrom_info.log 2> flashrom_info.err.log
 flashrom -V -p internal:laptop=force_I_want_a_brick -r rom.bin > flashrom_read.log 2> flashrom_read.err.log

Here's the warning you get when running the above commands without the laptop=force_I_want_a_brick parameter on an unsupported laptop:

========================================================================
WARNING! You seem to be running flashrom on an unsupported laptop.
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 the manpage and https://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.
========================================================================
  • Save all logs in a safe place, as well as the rom.bin file.
  • Find what chip does your motherboard use. The name of the chip is present in flashrom_info.log but is not always exact as some chips have several packaging variants (e.g. SOIC-16, SOIC-8 and TSOP). Consult this page for more info on possible chip formats. If possible make a high-resolution (600dpi or higher) scan of the motherboard. Make a scan, not a photo, as cameras typically lack enough resolution to properly identify individual chips.
  • try to find information about which EC (if on laptop) or Super I/O chip (if any) is used in your mther board (You may also find some info in Service Manuals or Disassembly Guides)
  • try to find the datasheets for your Super I/O / EC chip

For laptop, additionally:

  • if you see that ectool returns some fake stuff, like only 'FF' or '00', then you have a custom EC configuration and it'll be a harder work for supporting it.
  • if you see that ectool return looks like 'right' output - you have a big chance for support
  • you need to figure out the name of the Super I/O / EC chip based on the above log outputs. If you can't find it on the logs, then you'll have to disassemble your laptop to look at the actual chips.

Preparing recovery method

Inevitably when you develop coreboot there will be unbootable builds and so you'll need a way to unbrick your machine after installing a failed image. There are several ways to do so. Main ones are:

In any case you have to locate the flash chip. Note the chipname from flashrom output. Teardown your system and find that chip. For how it usually looks like, consult this page. If you have a scanner, take a high-resolution scan of your motherboard since it may be useful later.

Selecting a Similar Board

The most important criteria for finding a similar board is the chipset. Look at northbridge (device 0:0.0) and southbridge (LPC controller) in the lspci output. Use grep on the coreboot tree to find how those chipsets are named, and then grep for the chipset name (case-insensitive) to find a board which uses it. If there are several of them, try to match (in order of decreasing importance) the system type (desktop/laptop), Super I/O and manufacturer.


Adding a new board

This is a two step process. If your mainboard already exists in the coreboot source tree, skip to next section.

Adding a new vendor to the tree

Create a directory in src/mainboard with the same name as the vendor name. Add to src/mainboard/Kconfig a new vendor entry. The rest of this example uses "foo" vendor.

config VENDOR_FOO
      bool "Foo"

Add also an include for the new Kconfig file which holds the vendor motherboards in the vendor directory:

source "src/mainboard/foo/Kconfig"

Create a src/mainboard/foo/Kconfig file, copying it from some other vendor, and then change the vendor name. Delete all mainboards.

Adding a new motherboard to the tree

Assume in these examples that the vendor name is foo and the board type is bar. Add a new configuration item in src/mainboard/foo/Kconfig:

config BOARD_FOO_BAR
       bool "BAR"

Add include a board specific config:

source "src/mainboard/foo/bar/Kconfig"

Adjusting the contents of the new board directory

Now copy the files of your similar board and start adjusting them. Your first stop is the Kconfig file.

  • You need to change the conditional statement in the first line to match your board:
-if BOARD_VENDOR_BAR
+if BOARD_VENDOR_BAZ
  • Change MAINBOARD_DIR and names.
  • Change device options to match your config.
  • Next stop is mainboard.c where you should adjust the GPIO config based on the inteltool dump performed above.
  • Now you can build it, flash the resulting image and see what fails.
  • Later adjust hda_verb.h to get sound working properly (use initial pin dumps for reference).

Look through the options and adjust.

Adjust Kconfig to fit the new vendor/model name and don't forget to change MAINBOARD_DIR and MAINBOARD_PART_NUMBER.