remove util/autoport

upstream has merged all of the changes that it contained,
so we don't need this anymore. we'll have the newer upstream
changes on the next general revision updates for coreboot,
within config/coreboot/

Signed-off-by: Leah Rowe <leah@libreboot.org>

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