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>
linux_trampoline.c generation is broken with latest crossgcc-i386
toolchain. Fix the issue to enable the building.
../cbfstool/linux_trampoline.S: Assembler messages:
../cbfstool/linux_trampoline.S💯 Error: no instruction mnemonic
suffix given and no register operands; can't size
instruction
<builtin>: recipe for target '../cbfstool/linux_trampoline.o'
failed
TEST=Build and boot on intel/archercity CRB
cd util/cbfstool/
rm linux_trampoline.c
make linux_trampoline.c
Change-Id: I7faca296f946bb4e9fd510661357925e5dcf9a6b
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82704
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
<stdio.h> header is used for input/output operations (such as printf,
scanf, fopen, etc.). Although some input/output functions can manipulate
strings, they do not need to directly include <string.h> because they
are declared independently.
Change-Id: Ibe2a4ff6f68843a6d99cfdfe182cf2dd922802aa
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82665
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This adds some helper functions for FDT, since more and more mainboards
seem to need FDT nowadays. For example our QEMU boards need it in order
to know how much RAM is available. Also all RISC-V boards in our tree
need FDT.
This also adds some tests in order to test said functions.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I2fb1d93c5b3e1cb2f7d9584db52bbce3767b63d8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81081
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Debian sid is too unstable at this point, and frequently ends up having
issues that cause the coreboot-sdk docker image to fail to build. Using
stable also better reflects what users will typically be running.
Also remove the parameters to quiet the apt-get install command so that
if something does break, we can see what happened more easily.
Fixes bug 536
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I41b6464b024df89c114db2cdb9367c0526eb0297
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82411
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Yes, the DSDT revision is the OEM revision. But most certainly not that
of the board being ported. Because no one seems to care about the value
(newer boards inexplicably use lower values even though this represents
a date in 0xYYYYMMDD format), simply drop the incorrect comment. Should
save a bit of effort when reviewing mainboard ports: no longer will one
have to ask authors to drop the comment.
Change-Id: I9c425573e4fcb0f670a780e7821e815eadc8a2aa
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82401
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
If $BOARD is not all lowercase, then certain subfunctions of the
script will fail due to case-sensitive comparisons therein. To avoid
this, since all matched strings are fully lowercase, set $BOARD
to lowercase.
TEST: './crosfirmware.sh {akemi/Akemi/AKEMI}' all succeed.
Change-Id: I8ecb613a8d9384e2cccaff5183470e2e9956d0a2
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82232
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
This file is appended to Documentation/util.md by the util_readme.sh
script, and contains toctree entries for utilities with more in-depth
documentation than the description automatically pulled from the
description.md files throughout the util directory. As of commit
35599f9a66 (Docs: Replace Recommonmark with MyST Parser), the syntax
for creating a toctree has changed, so update this post_util.md
accordingly.
Change-Id: Ia7ae3c513781e53512763578fd97db7e2f75e65c
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82163
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
When installing the packages, apt-get returns an error about holding
broken packages. It occurs the diffutils depends on libcurl4t64
which breaks the libcurl4.
As a solution, remove the libcurl4 from the list, and let the package
manager resolve the dependencies.
TEST=Build coreboot-sdk
Change-Id: Iabc4f74619d4462317d8adb4068e50135d89d80e
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82066
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
This patch adds support for the new command-line option `-c` to
the ifdtool, which is able to check GPR0 (Global Protected Range)
status.
This patch also add helper function get_enabled_gprd() to get enabled
GPR0 settings. It used in enable_gpr0() and is_gpr0_protected().
Developers can use ifdtool with '-c' option to check whether GPR0 is
set to enabled or disabled in the binary file.
BUG=none
TEST=(1) > ifdtool -p mtl -E image-unlocked.bin -O image-lock.bin
...
Value at GPRD offset (64) is 0x83220004
--------- GPR0 Protected Range --------------
Start address = 0x00004000
End address = 0x00322fff
...
GPR0 protection is now enabled
(2) > ifdtool -p mtl -c image-unlocked.bin
GPR0 status: Disabled
Value at GPRD offset (64) is 0x00000000
--------- GPR0 Protected Range --------------
Start address = 0x00000000
End address = 0x00000fff
(3) > ifdtool -p mtl -c image-lock.bin
GPR0 status: Enabled
Value at GPRD offset (64) is 0x83220004
--------- GPR0 Protected Range --------------
Start address = 0x00004000
End address = 0x00322fff
Change-Id: I6b3af973be784200b965a68e5f6b7737cba03ed7
Signed-off-by: Tyler Wang <tyler.wang@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81928
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Reka Norman <rekanorman@chromium.org>
The command "wget" prints some hyperlink with "%", which will be
filtered in by previous regular expression. So we need to change to
match the string with exactly 3 digits and a percent symbol.
TEST:
echo 45% | grep -o "\<[0-9]\{1,3\}%"
45%
echo 1245% | grep -o "\<[0-9]\{1,3\}%"
<empty>
echo aa% | grep -o "\<[0-9]\{1,3\}%"
<empty>
Change-Id: I6ef9e7c87fd4ee6cc707346954d91e6e3af3b939
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66743
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
When the compiler is used as a linker frontend clang tries to match the
target string with what it supports internally. If it's not sufficiently
complete it will forward linking to GCC which is not desirable. This is
necessary when doing LTO with clang.
Change-Id: Ie9356a2bc0f5b77e934cc16482d6ccb1961195dc
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80730
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
A trailing "|" at the end of the regex added a zero length alternative
match, causing all files to match and be filtered out. This was causing
`make lint-stable` to ignore all missing license headers, preventing the
pre-commit git hook and Jenkins from detecting these. Also, a missing
"|" separator between cmos.default and .apcb would cause those files to
be unintentionally scanned.
Change-Id: I70cc3a5adf7edee059883cd3cbe02029776b02ef
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81422
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
