diff options
Diffstat (limited to 'util/autoport/readme.md')
| -rw-r--r-- | util/autoport/readme.md | 457 |
1 files changed, 0 insertions, 457 deletions
diff --git a/util/autoport/readme.md b/util/autoport/readme.md deleted file mode 100644 index b546120f..00000000 --- a/util/autoport/readme.md +++ /dev/null @@ -1,457 +0,0 @@ -# Porting coreboot using autoport - -## Supported platforms - -### Chipset -For any Sandy Bridge or Ivy Bridge platform the generated result should -be bootable, possibly with minor fixes. - -### EC / SuperIO -EC support is likely to work on Intel-based thinkpads. Other laptops are -likely to miss EC support. SuperIO support on desktops is more likely to -work out of the box than any EC. - -## How to use autoport - -Enable as many devices as possible in the firmware setup of your system. -This is useful to detect as many devices as possible and make the port -more complete, as disabled devices cannot be detected. - -Boot into target machine under any Linux-based distribution and install -the following tools on it: -* `gcc` -* `golang` -* `lspci` -* `dmidecode` -* `acpidump` (part of `acpica` on some distros) - -Clone the coreboot tree and `cd` into it. For more detailed steps, refer -to Rookie Guide, Lesson 1. Afterwards, run these commands: - - cd util/ectool - make - cd ../inteltool - make - cd ../superiotool - make - cd ../autoport - go build - sudo ./autoport --input_log=logs --make_logs --coreboot_dir=../.. - - Note: in case you have problems getting gcc and golang on the target - machine, you can compile the utilities on another computer and copy - the binaries to the target machine. You will still need the other - listed programs on the target machine, but you may place them in the - same directory as autoport. - -Check for unknown detected PCI devices, e.g.: - - Unknown PCI device 8086:0085, assuming removable - -If autoport says `assuming removable`, you are fine. If it doesn't, -you may want to add the relevant PCI IDs to autoport. Run `lspci -nn` -and check which device this is using the PCI ID. Devices which are not -part of the chipset, such as GPUs or network cards, can be considered -removable, whereas devices inside the CPU or the PCH such as integrated -GPUs and bus controllers (SATA, USB, LPC, SMBus...) are non-removable. - -Your board has now been added to the tree. However, do not flash it -in its current state. It can brick your machine. Instead, keep this -new port and the logs from `util/autoport/logs` somewhere safe. The -following steps will back up your current firmware, which is always -recommended, since coreboot may not boot on the first try. - -Disassemble your computer and find the flash chip(s). Since there could be -more than one, this guide will refer to "flash chips" as one or more chips. -Refer to <https://flashrom.org/Technology> as a reference. The flash chip is -usually in a `SOIC-8` (2x4 pins, 200mil) or `SOIC-16` (2x8 pins) package. As -it can be seen on flashrom's wiki, the former package is like any other 8-pin -chip on the mainboard, but it is slightly larger. The latter package is much -easier to locate. Always make sure it is a flash chip by looking up what its -model, printed on it, refers to. - -There may be a smaller flash chip for the EC on some laptops, and other chips -such as network cards may use similar flash chips. These should be left as-is. -If in doubt, ask! - -Once located, use an external flasher to read the flash chips with `flashrom -r`. -Verify with `flashrom -v` several times that reading is consistent. If it is not, -troubleshoot your flashing setup. Save the results somewhere safe, preferably on -media that cannot be easily overwritten and on several devices. You may need this -later. The write process erases the flash chips first, and erased data on a flash -chip is lost for a very long time, usually forever! - -Compile coreboot for your ported mainboard with some console enabled. The most -common ones are EHCI debug, serial port and SPI flash console as a last resort. -If your system is a laptop and has a dedicated video card, you may need to add -a video BIOS (VBIOS) to coreboot to be able to see any video output. Desktop -video cards, as well as some MXM video cards, have this VBIOS on a flash chip -on the card's PCB, so this step is not necessary for them. - -Flash coreboot on the machine. On recent Intel chipsets, the flash space is split -in several regions. Only the one known as "BIOS region" should be flashed. If -there is only one flash chip present, this is best done by adding the `--ifd` -and `-i bios` parameters flashrom has (from v1.0 onwards) to specify what flash -descriptor region it should operate on. If the ME (Management Engine) region is -not readable, which is the case on most systems, use the `--noverify-all` -parameter as well. - -For systems with two flash chips, this is not so easy. It is probably better to -ask in coreboot or flashrom communication channels, such as via IRC or on the -mailing lists. - -Once flashed, try to boot. Anything is possible. If a log is generated, save it -and use it to address any issues. See the next section for useful information. -Find all the sections marked with `FIXME` and correct them. - -Send your work to review.coreboot.org. I mean it, your effort is very appreciated. -Refer to Rookie Guide, Lesson 2 for instructions on how to submit a patch. - -## Manual fixes -### SPD -In order to initialize the RAM memory, coreboot needs to know its timings, which vary between -modules. Socketed RAM has a small EEPROM chip, which is accessible via SMBus and contains the -timing data. This data is usually known as SPD. Unfortunately, the SMBus addresses may not -correlate with the RAM slots and cannot always be detected automatically. The address map is -encoded in function `mainboard_get_spd` in `romstage.c`. By default, autoport uses the most -common map `0x50, 0x51, 0x52, 0x53` on everything except for Lenovo systems, which are known -to use `0x50, 0x52, 0x51, 0x53`. To detect the correct memory map, the easiest way is to boot -on the vendor firmware with just one module in channel 0, slot 0, and check the SMBus address -the EEPROM has. Under Linux, you can use these commands to see what is on SMBus: - - $ sudo modprobe i2c-dev - $ sudo modprobe i2c-i801 - $ sudo i2cdetect -l - i2c-0 i2c i915 gmbus ssc I2C adapter - i2c-1 i2c i915 gmbus vga I2C adapter - i2c-2 i2c i915 gmbus panel I2C adapter - i2c-3 i2c i915 gmbus dpc I2C adapter - i2c-4 i2c i915 gmbus dpb I2C adapter - i2c-5 i2c i915 gmbus dpd I2C adapter - i2c-6 i2c DPDDC-B I2C adapter - i2c-7 i2c DPDDC-C I2C adapter - i2c-8 i2c DPDDC-D I2C adapter - i2c-9 smbus SMBus I801 adapter at 0400 SMBus adapter - - $ sudo i2cdetect 9 - WARNING! This program can confuse your I2C bus, cause data loss and worse! - I will probe file /dev/i2c-9. - I will probe address range 0x03-0x77. - Continue? [Y/n] y - 0 1 2 3 4 5 6 7 8 9 a b c d e f - 00: -- -- -- -- -- 08 -- -- -- -- -- -- -- - 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - 20: -- -- -- -- 24 -- -- -- -- -- -- -- -- -- -- -- - 30: 30 31 -- -- -- -- -- -- -- -- -- -- -- -- -- -- - 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - 50: 50 -- -- -- 54 55 56 57 -- -- -- -- 5c 5d 5e 5f - 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - 70: -- -- -- -- -- -- -- -- - -Make sure to replace the `9` on the last command with the bus number for SMBus on -your system. Here, there is a module at address `0x50`. Since only one module was -installed on the first slot of the first channel, we know the first position of -the SPD array must be `0x50`. After testing all the slots, your `mainboard_get_spd` -should look similar to this: - - void mainboard_get_spd(spd_raw_data *spd) { - read_spd(&spd[0], 0x50); - read_spd(&spd[1], 0x51); - read_spd(&spd[2], 0x52); - read_spd(&spd[3], 0x53); - } - -Note that there should be one line per memory slot on the mainboard. - -Note: slot labelling may be missing or unreliable. Use `inteltool` to see -which slots have modules in them. - -This procedure is ideal, if your RAM is socketed. If you have soldered RAM, -remove any socketed memory modules and check if any EEPROM appears on SMBus. -If this is the case, you can proceed as if the RAM was socketed. However, -you may have to guess some entries if there multiple EEPROMs appear. - -Most of the time, soldered RAM does not have an EEPROM. Instead, the SPD data is -inside the main flash chip where the firmware is. If this is the case, you need -to generate the SPD data to use with coreboot. Look at `inteltool.log`. There -should be something like this: - - /* SPD matching current mode: */ - /* CH0S0 */ - 00: 92 11 0b 03 04 00 00 09 03 52 01 08 0a 00 80 00 - 10: 6e 78 6e 32 6e 11 18 81 20 08 3c 3c 00 f0 00 00 - 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 65 00 - 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 6d 17 - 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - /* CH1S0 */ - 00: 92 11 0b 03 04 00 00 09 03 52 01 08 0a 00 80 00 - 10: 6e 78 6e 32 6e 11 18 81 20 08 3c 3c 00 f0 00 00 - 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 65 00 - 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 6d 17 - 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - -This is not a full-fledged SPD dump, as it only lists -the currently-used speed configuration, and lacks info -such as a serial number, vendor and model. Use `xxd` -to create a binary file with this SPD data: - - $ cat | xxd -r > spd.bin <<EOF - 00: 92 11 0b 03 04 00 00 09 03 52 01 08 0a 00 80 00 - 10: 6e 78 6e 32 6e 11 18 81 20 08 3c 3c 00 f0 00 00 - 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 65 00 - 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 6d 17 - 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - EOF (press Ctrl + D) - -Then, move the generated file into your mainboard's directory -and hook it up to the build system by adding the following -lines to `Makefile.mk`: - - cbfs-files-y += spd.bin - spd.bin-file := spd.bin - spd.bin-type := raw - -Now we need coreboot to use this SPD file. The following example -shows a hybrid configuration, in which one module is soldered and -the other one is socketed: - - void mainboard_get_spd(spd_raw_data *spd) - { - void *spd_file; - size_t spd_file_len = 0; - /* C0S0 is a soldered RAM with no real SPD. Use stored SPD. */ - spd_file = cbfs_boot_map_with_leak("spd.bin", CBFS_TYPE_RAW, - &spd_file_len); - if (spd_file && spd_file_len >= 128) - memcpy(&spd[0], spd_file, 128); - - /* C1S0 is a physical slot. */ - read_spd(&spd[2], 0x52); - } - -If several slots are soldered there are two ways to handle them: - -* If all use the same SPD data, use the same file for all the slots. Do - not forget to copy the data on all the array elements that need it. -* If they use different data, use several files. - -If memory initialization is not working, in particular write training (timB) -on DIMM's second rank fails, try enabling rank 1 mirroring, which can't be -detected by inteltool. It is described by SPD field "Address Mapping from Edge -Connector to DRAM", byte `63` (`0x3f`). Bit 0 describes Rank 1 Mapping, -0 = standard, 1 = mirrored; set it to 1. Bits 1-7 are reserved. - -### `board_info.txt` - -`board_info.txt` is a text file used in the board status page to list all -the supported boards and their specifications. Most of the information -cannot be detected by autoport. Common entries are: - -* `ROM package`, `ROM protocol` and `ROM socketed`: - These refer to the flash chips you found earlier. You can visit - <https://flashrom.org/Technology> for more information. - -* `Release year`: Use the power of Internet to find that information. -* `Category`: This describes the type of mainboard you have. - Valid categories are: - * `desktop`. Desktops and workstations. - * `server`. Servers. - * `laptop`. Laptops, notebooks and netbooks. - * `half`. Embedded / PC/104 / Half-size boards. - * `mini`. Mini-ITX / Micro-ITX / Nano-ITX - * `settop`. Set-top-boxes / Thin clients. - * `eval`. Development / Evaluation Boards. - * `sbc`. Single-Board computer. - * `emulation`: Virtual machines and emulators. May require especial care - as they often behave differently from real counterparts. - * `misc`. Anything not fitting the categories above. Not recommended. - -* `Flashrom support`: This means whether the internal programmer is usable. - If flashing coreboot internally works, this should be set to `y`. Else, - feel free to investigate why it is not working. - -### `USBDEBUG_HCD_INDEX` - -Which controller the most easily accessible USB debug port is. On Intel, -1 is for `00:1d.0` and 2 is for `00:1a.0` (yes, it's reversed). Refer to -<https://www.coreboot.org/EHCI_Debug_Port> for more info. - -If you are able to use EHCI debug without setting the HCD index manually, -this is correct. - -### `BOARD_ROMSIZE_KB_2048` - -This parameter refers to the total size of the flash chips coreboot will be in. -This value must be correct for S3 resume to work properly. This parameter also -defines the size of the generated coreboot image, but that is not a major issue -since tools like `dd` can be used to cut fragments of a coreboot image to flash -on smaller chips. - -This should be detected automatically, but it may not be detected properly in -some cases. If it was not detected, put the correct total size here to serve -as a sane default when configuring coreboot. - -### `DRAM_RESET_GATE_GPIO` - -When the computer is suspended to RAM (ACPI S3), the RAM reset signal must not -reach the RAM modules. Otherwise, the computer will not resume and any opened -programs will be lost. This is done by powering down a MOSFET, which disconnects -the reset signal from the RAM modules. Most manufacturers put this gate on GPIO -60 but Lenovo is known to put it on GPIO 10. If suspending and resuming works, -this value is correct. This can also be determined from the board's schematics. - -## GNVS - -`mainboard_fill_gnvs` sets values in GNVS, which then ACPI makes use of for -various power-related functions. Normally, there is no need to modify it -on laptops (desktops have no "lid"!) but it makes sense to proofread it. - -## `gfx.ndid` and `gfx.did` - -Those describe which video outputs are declared in ACPI tables. -Normally, there is no need to have these values, but if you miss some -non-standard video output, you can declare it there. Bit 31 is set to -indicate the presence of the output. Byte 1 is the type and byte 0 is -used for disambigution so that ID composed of byte 1 and 0 is unique. - -Types are: -* 1 = VGA -* 2 = TV -* 3 = DVI -* 4 = LCD - -## `c*_acpower` and `c*_battery` - -Which mwait states to match to which ACPI levels. Normally, there is no -need to modify anything unless your device has very special power saving -requirements. - -## `install_intel_vga_int15_handler` - -This is used with the Intel VGA BIOS, which is not the default option. -It is more error-prone than open-source graphics initialization, so do -not bother with this until your mainboard boots. This is a function -which takes four parameters: -1. Which type of LCD panel is connected. -2. Panel fit. -3. Boot display. -4. Display type. - -Refer to `src/drivers/intel/gma/int15.h` to see which values can be used. -For desktops, there is no LCD panel directly connected to the Intel GPU, -so the first parameter should be `GMA_INT15_ACTIVE_LFP_NONE`. On other -mainboards, it depends. - -## CMOS options - -Due to the poor state of CMOS support in coreboot, autoport does not -support it and this probably won't change until the format in the tree -improves. If you really care about CMOS options: - -* Create files `cmos.layout` and `cmos.default` -* Enable `HAVE_OPTION_TABLE` and `HAVE_CMOS_DEFAULT` in `Kconfig` - -## EC (lenovo) - -You need to set `has_keyboard_backlight` (backlit keyboard like X230), -`has_power_management_beeps` (optional beeps when e.g. plugging the cord -in) and `has_uwb` (third MiniPCIe slot) in accordance to functions available -on your machine - -In rare cases autoport is unable to detect GPE. You can detect it from -dmesg or ACPI tables. Look for line in dmesg like - - ACPI: EC: GPE = 0x11, I/O: command/status = 0x66, data = 0x62 - -This means that GPE is `0x11` in ACPI notation. This is the correct -value for `THINKPAD_EC_GPE`. To get the correct value for `GPE_EC_SCI` -you need to substract `0x10`, so value for it is `1`. - -The pin used to wake the machine from EC is guessed. If your machine doesn't -wake on lid open and pressing of Fn, change `GPE_EC_WAKE`. - -Keep `GPE_EC_WAKE` and `GPE_EC_SCI` in sync with `gpi*_routing`. -`gpi*_routing` matching `GPE_EC_WAKE` or `GPE_EC_SCI` is set to `2` -and all others are absent. - -If your dock has LPC wires or needs some special treatement you may -need to add codes to initialize the dock and support code to -DSDT. See the `init_dock()` for `x60`, `x200` or `x201`. - -## EC (generic laptop) - -Almost any laptop has an embedded controller. In a nutshell, it's a -small, low-powered computer designed to be used on laptops. Exact -functionality differs between machines. Its main functions include: - -* Control of power and rfkill to different component -* Keyboard (PS/2) interface implementation -* Battery, AC, LID and thermal information exporting -* Hotkey support - -autoport automatically attempts to restore the dumped config but it -may or may not work and may even lead to a hang or powerdown. If your -machine stops at `Replaying EC dump ...` try commenting EC replay out - -autoport tries to detect if machine has PS/2 interface and if so calls -`pc_keyboard_init` and exports relevant ACPI objects. If detection fails -you may have to add them yourself - -ACPI methods `_PTS` (prepare to sleep) and `_WAK` (wake) are executed -when transitioning to sleep or wake state respectively. You may need to -add power-related calls there to either shutdown some components or to -add a workaround to stop giving OS thermal info until next refresh. - -For exporting the battery/AC/LID/hotkey/thermal info you need to write -`acpi/ec.asl`. For an easy example look into `apple/macbook21` or -`packardbell/ms2290`. For information about needed methods consult -relevant ACPI specs. Tracing which EC events can be done using -[dynamic debug](https://wiki.ubuntu.com/Kernel/Reference/ACPITricksAndTips) - -EC GPE needs to be routed to SCI in order for OS in order to receive -EC events like "hotkey X pressed" or "AC plugged". autoport attempts -to detect GPE but in rare cases may fail. You can detect it from -dmesg or ACPI tables. Look for line in dmesg like - - ACPI: EC: GPE = 0x11, I/O: command/status = 0x66, data = 0x62 - -This means that GPE is `0x11` in ACPI notation. This is the correct -value for `_GPE`. - -Keep GPE in sync with `gpi*_routing`. -`gpi*_routing` matching `GPE - 0x10` is set to `2` -and all others are absent. If EC has separate wake pin -then this GPE needs to be routed as well |