For Sandy/Ivy Bridge boards, this results in northbridge devices ending
up north of (above) southbridge devices. Which is the convention pretty
much all boards in the tree uses.
Change-Id: I9dc2ff13182ff9d92141b1736796749cea49d23a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82406
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Running autoport as root has the annoying side effect of making all
generated files owned by root. Prevent this by using sudo to invoke
log-making programs (lspci, dmidecode, acpidump, inteltool, ectool,
superiotool). These programs either need to be run as root or allow
collecting more information if run as root (lspci).
In case there's a valid reason not to use sudo, provide a prompt to
let autoport run the programs directly, as it originally did. There
might be someone trying to run autoport from an OS that lacks sudo.
Change-Id: I4bf4ddf8dd2cb930e9b7303e2ea986d8c072aa7a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82404
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The original approach to call external programs was rather convoluted
and would fall back to running executables inside the current working
directory if running them from the location specified in the code did
not succeed, swallowing any errors from the first invocation.
Rewrite the system around the `LogMakingProgram` concept, a struct to
represent a program. Each program has a name, prefixes to try running
it from and the arguments to pass to it (if any). Plus, collect error
information from failed executions, but only show it when none of the
prefixes resulted in a successful invocation.
In addition, look for programs in PATH instead of CWD: it is unlikely
that all utils will be in the CWD, but utils can be in the PATH after
one installs them (`sudo make install`). For coreboot utils, look for
them in the utils folder first as the installed versions might not be
up-to-date.
Furthermore, print out the command about to be executed, as there are
some commands (e.g. `ectool` on boards without an EC) that can take a
very long time to complete.
Change-Id: I144bdf609e0aebd8f6ddebc0eb1216bedebfa313
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82403
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In order to detect more issues in our code, make GCC more picky by
enabling -Wextra. Disable a couple of warnings turned on by -Wextra
temporarily in order to keep everything compiling and working for now.
The warnings may be enabled step by step later.
Since xcompiles applies to coreboot and libpayload, add Wextra here
instead of the top-level Makefile.mk.
Change-Id: I60915cb66581dc2c9b6807335fd0e214b45e76d6
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83347
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Some chips (fintek [1,2]) have registers with specific selector-fields
that can affect the address space of the device (for example, switch the
register bank). At the same time, these registers contain fields that
should not change after they are configured in BIOS (for example, set
the port to 2E/2F or 4E/4F). In this case, the selector should take into
account the mask of the register fields and there is no convenient and
easy way to add this in the code in the utility. The selector-fields
should be set manually before the dump and this action is done several
times.
This patch adds an extra-selector mechanism that allows superiotool to
make a correct dump in automatic mode.
Just add a structure with an index, mask, and value for the selector
inside the superio_registers chip for the corresponding LDN to switch
the register bank:
{FINTEK_F81966_DID, "F81962/F81964/F81966/F81967", {
* * *
{NOLDN, "Global",
{0x28,0x2a,0x2b,0x2c,EOT},
{0x00,0x00,0x00,0x00,EOT},
{.idx = 0x27, .mask = 0xd, .val = 0x1} /* update extra selector */
},
{0x03, "LPT",
{0x30,0x60,0x61,0x70,0x74,0xf0,EOT},
{NANA,0x03,0x78,0x07,0x03,0xc2,EOT} /* without extra selector */
},
* * *
Tested with Fintek F81966 on Asrock IMB-1222:
- run superiotool on Ubuntu and dump the registers for the board with
the vendor's firmware;
- add the superio chip initialization code to the board configuration
in coreboot and build the project;
- boot Ubuntu on the board with coreboot and re-dump the registers;
- the register values from the board configuration code are the same
in both dumps.
Found Fintek F81962/F81964/F81966/F81967 (vid=0x3419, id=0x0215) at 0x2e
(Global) -- ESEL[27h] 0x00 (Port Select Register) --
idx 02 07 20 21 23 24 25 26 27 28 29 2a 2b 2c 2d
val 00 0b 15 02 19 34 5a 23 80 a0 f0 45 02 e3 2e
def NA 00 15 02 19 34 00 23 02 a0 00 00 02 0c 28
* * *
The changes do not affect the configuration of existing chips, which
was tested on the Asrock H110-STX motherboard with Nuvoton NCT5539D
(the dump before and after the changes are the same).
[1] CB:83004
[2] CB:83019
Change-Id: If56af9f977381e637245bdd26563f5ba7e6cbead
Signed-off-by: Maxim Polyakov <max.senia.poliak@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83196
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
It looks like some unused artifact: The PPC64 Makefile.mk doesn't
pick it up. Also, the only other architecture using this (x86) has
linker flags there, not compiler flags.
Change-Id: I734542db9ee5b62d9a39d303d4092cd83dfef54b
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83577
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Firmware files are packaged in various formats and very often some
Windows-only executable is used for unpacking files. These extractors
allow to deal with some of them without having to run the executables.
Change-Id: I1346807508a6baba801c4d5ed0a575b17e06c8d4
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83522
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nicholas Chin <nic.c3.14@gmail.com>
In order to support logging events for when we show early signs
of life to the user during CSE FW syncs add support for the
ELOG_TYPE_FW_LATE_SOL type.
BUG=b:305898363
TEST=verify event shows in eventlog CSE sync.
Change-Id: I862db946f6ff622ac83072e6bf27832732c0c318
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83462
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
This tool helps take off the burden of manually decoding default
configuration registers. Using decoded values can make code more
self-documenting compared to shrouding it with magic numbers.
This is also written as a module which allows easy integration with
other tools written in Go (e.g. autoport).
Change-Id: Ib4fb652e178517b2b7aceaac8be005c5b2d3b03e
Signed-off-by: Nicholas Sudsgaard <devel+coreboot@nsudsgaard.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80470
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
The value stored in `gen` is only ever `1` or `0`. Storing `1` causes
Clang to warn, since the only valid values for a 1-bit int are -1 and 0:
```
amdfwtool.c:1487:27: error: implicit truncation from 'int' to a one-bit
wide bit-field changes value from 1 to -1
[-Werror,-Wsingle-bit-bitfield-constant-conversion]
1487 | amd_romsig->efs_gen.gen = EFS_BEFORE_SECOND_GEN;
```
TEST=Rebuilt coreboot; no warning was emitted.
Change-Id: Ibd83be8302e8a717db7e7dc86a403b5648976586
Signed-off-by: George Burgess IV <gbiv@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83412
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Expose aliased PCI and PNP devices as `pci_/pnp_devfn_t` constants
in <static_devices.h>. They will be named `_sdev_<alias>` to have
a underscore prefix for consistency and to not collide with the
`struct device` objects (with `_dev_` prefix).
Change-Id: I2d1cfe12b1e7309f8235c84dd220bd090ebfe1b5
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82764
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The ioapic and ioapic_irq keywords are no longer valid tokens as of
commit e84b095d3a (util/sconfig: Remove unused ioapic and irq
keywords), and the associated driver had previously been removed in
commit ca5a793ec3 (drivers/generic/ioapic: Drop poor implementation).
Thus, drop them from autoport. Also, the IOAPICIRQs map that this code
relied on to generate ioapic_irq entries never seems to have been
populated by any code in any previous commit, so this appears to have
been dead code since autoport was created.
The lapic keyword was removed from sconfig in commit 15d5183e4a
(util/sconfig: Remove lapic devices from devicetree parsers) so remove
autoport handling for it as well.
Change-Id: Icf2582594b244cf5f726c722eb3a3c12573a2662
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83358
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Autoport determines the mainboard vendor and board names based on DMI
entries, which sometimes doesn't result in the most obvious name. In
addition, newcomers may not be familiar with coreboot's directory
structure and have no idea where to look. Print out the absolute patch
of the generated sources once autoport finishes so that it is easier to
locate the files.
Change-Id: I4ba00484ac57355d7539fa6e36e0e6df62719f8a
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83344
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Intel chipsets from ICH7 through Lynxpoint use the same GPIO register
format and thus mainboards using using these platforms have similar
gpio.c files. Factor out the code to generate gpio.c from bd82x6x.go so
that it other chipsets added to autoport can use it.
This was originally written by Iru Cai in his Haswell autoport patch in
CB:30890; I have simply split out the code to a separate commit as it is
a separate logical change.
TEST=Generated output is identical before and after this patch when run
against logs from a Dell Latitude E6430
Change-Id: If1f506f6ad10144bd6acc42505592426bb7193b7
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83286
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The generator inserts into the gpio.h an unnecessary blank line in
front of the list of macros in the table. Let's remove this from the
template to make the code cleaner. These changes have no effect on the
configuration of macros.
Change-Id: I1141ca630cb6d9a46be5bce2b434762ef8e6fdd0
Signed-off-by: Maxim Polyakov <max.senia.poliak@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83003
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The host bridge PCI device ID can be changed by the firmware. There
is no documentation about it, though. There's 'official' IDs, which
appear in spec updates and Windows drivers, and 'mysterious' IDs,
which Intel doesn't want OSes to know about and thus are not listed.
For the sake of completeness, add the PCI device IDs for Clarkdale.
Though coreboot only supports Arrandale, both of them are Ironlake.
It is possible that the Management Engine handles changing the PCI
device ID, which would not happen when using a broken ME firmware.
Change-Id: I85a48fcf0e0e62f42fe147a5d4e2d557b2143e5b
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60215
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Update autoport for:
1. Commit ee12634872 ("nb/sandybridge,sb/bd82x6x: Configure USB from
southbridge devicetree")
2. Commit 94625d2aae ("sb/intel/bd82x6x: Allow actual USBIRx values
for native USB config")
As a side effect of #2 above, no more (broken anyway) FIXME comment
will be written for usb_port_config.
Change-Id: I3b8f44d9de19a7446e2fbcbce1aab6ec6583ebe3
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82656
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Commit 45e4ab4a66 (mb/*: Update SPD mapping for sandybridge boards)
changed the way in which SPD addresses are set up for SNB/IVB boards,
but autoport was not updated to reflect these changes. Result is:
register "spd_addresses" = "{0x50, 0x51, 0x52, 0x53}" # FIXME: Put proper SPD map here"
The stray quote at the end is irritating, but is hard to get rid of
without substantial refactoring of autoport's guts. But, given that
this is a FIXME comment, anyone using autoport should just drop the
comment after verifying the SPD map, so it's not a big deal.
In addition, update the corresponding section of the README, which
was horrendously out-of-date.
Change-Id: I6ad38f53afc4fafb45be7f086723cc0782a965ed
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82405
Reviewed-by: Keith Hui <buurin@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Replace 3 unused values in the map with those found during a Ghidra
examination of MRC binary, and on hardwares running vendor firmware
(asus/p8z77-m and HP Z210 CMT Workstation).
The outgoing values were introduced in commit 216ad2170c
("sb/intel/bd82x6x: Add new USB currents") in anticipation for
Gigabyte GA-Z77-DS3H mainboard, but effort to land it was eventually
abandoned. Since commit xxxxxxxxxxxx, such values can be placed
directly in the port config, so there should be no hurdle should that
effort be resurrected.
Add a few #defines in pch.h to place some inline documentation
on MRC values, but more will be documented in the future when this
mapping is introduced MRC-side.
Finally, update autoport to match.
Change-Id: I195c7f627994e48f7a6e6698589504dc96248cff
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82754
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
We are going to expose ths tool to end users, and want to take
care that the presented information can be consumed by them.
The current code simply prints below warnings if we use release
binary available for end-user to download:
No firmware volume header present
No valid firmware volume was found
It will be concerning and not clear to end users, they might not
understant why it happens, what are the implications, and whether
it is something that they should worry about.
This commit tries to explain what actually happens here.
Change-Id: Iaa2678f5ae7c243811484c0567ced97ae0b3fc0a
Signed-off-by: Maciej Pijanowski <maciej.pijanowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82692
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
