When we first added ARM support to coreboot, it was clear that the
bootblock would need to do vastly different tasks than on x86, so we
moved its main logic under arch/. Now that we have several more
architectures, it turns out (as with so many things lately) that x86 is
really the odd one out, and all the others are trying to do pretty much
the same thing. This has already caused maintenance issues as the ARM32
bootblock developed and less-mature architectures were left behind with
old cruft.
This patch tries to address that problem by centralizing that logic
under lib/ for use by all architectures/SoCs that don't explicitly
opt-out (with the slightly adapted existing BOOTBLOCK_CUSTOM option).
This works great out of the box for ARM32 and ARM64. It could probably
be easily applied to MIPS and RISCV as well, but I don't have any of
those boards to test so I'll mark them as BOOTBLOCK_CUSTOM for now and
leave that for later cleanup.
BRANCH=None
BUG=None
TEST=Built Jerry and Falco, booted Oak.
Change-Id: Ibbf727ad93651e388aef20e76f03f5567f9860cb
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/12076
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
In order to have a proper runtime-modifyable page table API (e.g. to
remap DRAM after it was intialized), we need to remove any external
bookkeeping kept in global variables (which do not persist across
stages) from the MMU code. This patch implements this in a similar way
as it has recently been done for ARM32 (marking free table slots with a
special sentinel value in the first PTE that cannot occur as part of a
normal page table).
Since this requires the page table buffer to be known at compile-time,
we have to remove the option of passing it to mmu_init() at runtime
(which I already kinda deprecated before). The existing Tegra chipsets
that still used it are switched to instead define it in memlayout in a
minimally invasive change. This might not be the best way to design this
overall (I think we should probably just throw the tables into SRAM like
on all other platforms), but I don't have a Tegra system to test so I'd
rather keep this change low impact and leave the major redesign for
later.
Also inlined some single-use one-liner functions in mmu.c that I felt
confused things more than they cleared up, and fixed an (apparently
harmless?) issue with forgetting to mask out the XN page attribute bit
when casting a table descriptor to a pointer.
BRANCH=None
BUG=None
TEST=Compiled Ryu and Smaug. Booted Oak.
Change-Id: Iad71f97f5ec4b1fc981dbc8ff1dc88d96c8ee55a
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/12075
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Among its other restrictions (which are noted in a comment above the
function prototype and stay in place), our makeshift fine-grained page
table support for ARM32 has the undocumented feature that it relies on
a global bookkeeping variable, causing all sorts of fun surprises when
you try to use it from multiple stages during the same boot. This patch
redesigns the bookkeeping to stay completely inline in the (persistent)
TTB which should resolve the issue. (This had not been a problem on any
of our platforms for now... I just noticed this because I was trying to
solve the same issue on ARM64.)
BRANCH=None
BUG=None
TEST=Booted veyron_jerry. Mapped a second fine-grained memory range
from romstage, confirmed that it finds the next free spot and leaves the
bootblock table in place.
Change-Id: I325866828b4ff251142e1131ce78b571edcc9cf9
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/12074
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Upon bootup the hardware reads at minimum 256 * 16 bytes (4Kb, or 32KB) over
I2C on a system with all DIMM slots populated. If even one of those reads
has a single flipped bit in it (due to EMI, cross coupling with another trace,
or just poor margins on some cheap DIMM) the system will hang and require a
hard reset. In practice I've seen failure rates as high as 1 failed boot in
50 due to this issue, granted with cheap DIMMs, but even so retrying the read
resolves the corruption issue.
I2C is not designed for continuous data transmission with high reliability, and
there is no hardware error checking, therefore a single retry when transferring
this amount of data makes sense.
Change-Id: Ifab63eca2233c63a6a42ab8b7e742f8e47fb2a09
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11975
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
As announced in http://permalink.gmane.org/gmane.linux.bios/81918
I am removing all boards older than 10 years from the tree.
Change-Id: I36c2b0290f95f4c0f6bed6a7427fb3aab968d4da
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/12376
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins)
As announced in http://permalink.gmane.org/gmane.linux.bios/81918
I am removing all boards older than 10 years from the tree.
Change-Id: I866440595a0a38b65ce037dc9a1f7e4c02c6beb3
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/12385
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
As announced in http://permalink.gmane.org/gmane.linux.bios/81918
I am removing all boards older than 10 years from the tree.
Change-Id: I41d1f9eac2f4c37bec4d046a68f3f1cf95b51703
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/12384
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
As announced in http://permalink.gmane.org/gmane.linux.bios/81918
I am removing all boards older than 10 years from the tree.
Change-Id: Idd6011302d2164275fe01954ad3e4e13474ec7a9
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/12382
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
As announced in http://permalink.gmane.org/gmane.linux.bios/81918
I am removing all boards older than 10 years from the tree.
Change-Id: I915d5dd4a095b84023a19c9a0474634320207a08
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/12381
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
As announced in http://permalink.gmane.org/gmane.linux.bios/81918
I am removing all boards older than 10 years from the tree.
Change-Id: Icfdcc5d6043987e22ef9b4db84847d62c91bd305
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/12380
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
As announced in http://permalink.gmane.org/gmane.linux.bios/81918
I am removing all boards older than 10 years from the tree.
Change-Id: Ie44a3c46b82e77028921339c50ae4c176e38055c
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/12379
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Rev F's SPD address is different from other revision.
0 1
Channel A A0 A2
Channel B A4 AC
Change-Id: I620d1f9c295f9a0e30e3821ea36a05dd9f7d3495
Signed-off-by: WANG Siyuan <wangsiyuanbuaa@gmail.com>
Signed-off-by: WANG Siyuan <SiYuan.Wang@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/12342
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
As announced in http://permalink.gmane.org/gmane.linux.bios/81918
I am removing all boards older than 10 years from the tree.
Change-Id: I9099f90c073197cc95bb9630788016b7b8221922
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/12383
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
As announced in http://permalink.gmane.org/gmane.linux.bios/81918
I am removing all boards older than 10 years from the tree.
Change-Id: Ifd1dfa35ae13ec01d932250994086edebece924d
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/12377
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins)
As announced in http://permalink.gmane.org/gmane.linux.bios/81918
I am removing all boards older than 10 years from the tree.
Change-Id: Idfec80ce79c906717e679d6576dc94e71da994c9
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/12378
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins)
As announced in http://permalink.gmane.org/gmane.linux.bios/81918
I am removing all boards older than 10 years from the tree.
Change-Id: Ibf3849dcd7a1ef1d8bc5dfc864172a8254a64b6f
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/12375
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
As announced in http://permalink.gmane.org/gmane.linux.bios/81918
I am removing all boards older than 10 years from the tree.
Change-Id: I460208c18964857be73d9a4449ecfd872ccad98a
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/12374
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
As announced in http://permalink.gmane.org/gmane.linux.bios/81918
I am removing all boards older than 10 years from the tree.
Change-Id: I4a942150590fb69ff97279ff2b48b3be83abafa4
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/12372
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
As announced in http://permalink.gmane.org/gmane.linux.bios/81918
I am removing all boards older than 10 years from the tree.
Change-Id: I5b0fb633b7611e2a69aeb33cd31ca8fd4a83592c
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/12369
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
As announced in http://permalink.gmane.org/gmane.linux.bios/81918
I am removing all boards older than 10 years from the tree.
Change-Id: I180fd548e8f45fc94e5086159c0e3e9465c74598
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/12386
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
As announced in http://permalink.gmane.org/gmane.linux.bios/81918
I am removing all boards older than 10 years from the tree.
Change-Id: I1913ca75aa6f2a2c6b97d49faaabc16afd2799f5
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/12371
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
As announced in http://permalink.gmane.org/gmane.linux.bios/81918
I am removing all boards older than 10 years from the tree.
Change-Id: If0e0a7f69b77cf4bcab4c0dcb58a153485380069
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/12373
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins)
As announced in http://permalink.gmane.org/gmane.linux.bios/81918
I am removing all boards older than 10 years from the tree.
Change-Id: I8854c31f242c13b6f91901452f7eb7ce0ef0b255
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/12370
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
As announced in http://permalink.gmane.org/gmane.linux.bios/81918
I am removing all boards older than 10 years from the tree.
Change-Id: Ic71d8a9137f0bd2a0cc7571a43f9dddb50168d8d
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/12368
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins)
All boards using this SuperIO have been removed from the tree already.
Change-Id: I3c43a431d92d76b6ed3ec72b203d3e80925cadea
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/12247
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
NOTE: This commit switches CacheBase in CAR to use the DCACHE_RAM_BASE
Kconfig variable. There should be no functional difference between
the existing code and the new code, however hardware verfication is
encouraged on lesser used architectures such as AMD Geode.
Change-Id: Ia2e8f99be9df388e492a633c49df21ca1c57ba13
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11970
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The build was changed to remove usage of microcode .h files when
all of the .h files were converted to binary. This is still
needed for some builds when microcode binaries aren't in the
blobs tree.
Change-Id: Ia323c90efe8aa0b8799fc5cce6197509e466a105
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/12333
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
This is an update to the script in the blobs repo that converts
individual or multiple files into a microcode binary.
Change-Id: I66fb650bbfa334d1f07e8e3914ef6deb8e72bbb4
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/12332
Tested-by: build bot (Jenkins)
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
The obsolete and removed getpir utility remarked in its output that the
data is autogenerated. The tool was removed because it wasn't very
reliable, so there's no need to point that anymore.
Change-Id: I5d624931ba7872b1fefa8fa3c270ae7367e069fa
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/12354
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
'edid->hdmi_monitor_detected' would indicate whether the monitor
interface is HDMI or DVI.
BRANCH=none
BUG=chrome-os-partner:43789
TEST=Previously, my LG monitor couldn't show dev screen. But now I can see
dev screen have been posted normally.
Change-Id: Id71f051b2cd792712e52bee7a763db383c1962a8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 88101589a22d06f0bc25e0750b2862cf66b55391
Original-Change-Id: I157861d327926b834e1e8606b0b676f413491c70
Original-Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/309056
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/12346
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
HDMI driver need to know whether the monitor is DVI
or HDMI interface, so this commit just introduce a
new number 'hdmi_monitor_detected' to struct edid.
There were four bits to indicate the monitor interfaces,
it's better to take use of that. But those bits only
existed in EDID 1.4 version, but didn't persented in
the previous EDID version, so I decided to detect the
hdmi cea block.
BRANCH=none
BUG=chrome-os-partner:43789
TEST=When mickey connect with HDMI monitor, see 'hdmi_monitor_detected' is 'true'.
When mickey connect with DVI monitor, see 'hdmi_monitor_detected' is 'false'.
Change-Id: I1a4f1410e1cce1474ffae858db161a18578cac3a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 409f041805d9fdff2d49faa1a3a262cf4dc609c2
Original-Change-Id: Ife770898b0f2b4f58b8259711101a0cab4a5e4ac
Original-Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/309055
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/12345
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The on-board eMMC is designed as 2.0. If it is set as 3.0,
it can not be detected.
Change-Id: I9fd913f76535e65c1672924ebdeba3d35dea59cc
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11748
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
1. Bettong Rev A-E are DDR3, Bettong Rev F is DDR4.
2. DDR4 uses different memory configuration in AGESA.
Pass memory configuration parameters in agesawrapper_amdinitpost.
3. Tested on Rev C and Rev F.
Both of them can boot to Windows 8 and have the correct memory size.
Change-Id: Ia0d35ebf1b65c399abc3777ee6bdb107437a4345
Signed-off-by: WANG Siyuan <wangsiyuanbuaa@gmail.com>
Signed-off-by: WANG Siyuan <SiYuan.Wang@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11733
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Bettong uses 3 GPIO(5-7) pins to identify board.
The GPIO ports are mapped to MMIO space.
The GPIO value and board version are mapped as follow:
GPIO5 GPIO6 GPIO7 Version
0 0 0 A
0 0 1 B
......
1 1 1 H
Change-Id: I72df28043057d8c4ccc4a2e645011ca5379e9928
Signed-off-by: WANG Siyuan <wangsiyuanbuaa@gmail.com>
Signed-off-by: WANG Siyuan <SiYuan.Wang@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11732
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The RAM voltages can be set per socket, which contains two nodes.
Only reset the allowed voltages per socket before processing a new socket and
not after every node.
Change-Id: Ia0e47676c7a3eebd56a17ab6de0e9690bf8cf703
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: http://review.coreboot.org/12297
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Change-Id: I3fbb897feb68d899e5dec075a09d0dd605eca5ce
Signed-off-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
Reviewed-on: http://review.coreboot.org/12309
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The Ultra 40 M2 is a dual Socket F workstation with MCP55/IO55 chipset,
DME1737 superio and onboard Firewire. This board port is for family
0Fh (K8) processors.
Due to existing bugs, having memory on the second node will cause
raminit to fail.
Change-Id: I5b62ade908ffeb80e22f14edbe4c1ec04880bd30
Signed-off-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
Reviewed-on: http://review.coreboot.org/12304
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Change-Id: Ia275a697caa73168553b5d588d54df651e0539d7
Signed-off-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
Reviewed-on: http://review.coreboot.org/12303
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The Clang project has a powerful code rewrite engine in the form
of LibFormat. A auxiliary tool is provided called `clang-format'
that can take a coding style formalisation file and rewrite your
code to conform to this style. Further, a wrapper script called
`git-clang-format' is also provided that can hook pre-commits
potentially replacing our slow and poor coverage regexp scripts
on pre-commits.
Herein we provide essentially the Linux Style Guide formalism.
Change-Id: Ica2207fdb8a4702793fa73eba6293b7b36ea9050
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/8036
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Julius Werner