CB:36845 simplified how coreboot finds the RW CBFS after vboot has and
eliminated a layer of caching. Unfortunately, we missed the fact that
the former cached value didn't exactly match the FMAP section... it was
in fact truncated to the data actually used by vboot. That patch
unintentionally broke this truncation which leads to performance
regressions on certain CBFS accesses.
This patch makes use of a new API function added to vboot (CL:1965920)
which we can use to retrieve the real firmware body length as before.
(Also stop making all the vb2_context pointers const. vboot generally
never marks context pointers as const in its API functions, even when
the function doesn't modify the context. Therefore constifying it inside
coreboot just makes things weird because it prevents you from calling
random API functions for no reason. If we really want const context
pointers, that's a refactoring that would have to start inside vboot
first.)
This patch brings in upstream vboot commit 4b0408d2:
2019-12-12 Julius Werner 2lib: Move firmware body size reporting to
separate function
Change-Id: I167cd40cb435dbae7f09d6069c9f1ffc1d99fe13
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37680
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mathew King <mathewk@chromium.org>
On nocturne, the VBT specifies that the native panel resolution
(3000x2000) is to be used by FSP/GOP init, which makes payload
and grub menus extremely difficult to read. Change the default
POST resolution specified by the VBT to 1500x1000 instead
(200% scaling) which is much more legible.
Test: build/boot nocturne with GOP init and Tianocore payload,
observe menu text is actually readable.
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Change-Id: I767a2b8319c7673e3460acfad534140409bf1d57
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37621
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
For low frequency (e.g., 1600 or 2400 Mbps) we can do fast
calibration for TX and RX window. However, for high frequency
(e.g., 3200 or 3600 Mbps) a full calibration is needed.
BUG=b:80501386,b:142358843
BRANCH=kukui
TEST=Boots correctly on Kukui
Signed-off-by: Huayang Duan <huayang.duan@mediatek.com>
Change-Id: I00d563ece4cf91ef5e8e12b6cf7f777849375a24
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36921
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* Implement reading EDID over software I2C.
* Fall back to VGA if no monitor connected for BMC KVM
* Copy the linux kernel code and add a bunch of wrapper structs to make it
compile.
* Convert the EDID to a drm_display_mode, which is understood by the
driver.
* Properly select HAVE_LINEAR_FRAMEBUFFER and HAVE_VGA_TEXT_FRAMEBUFFER
Tested on Supermicro X11SSH-TF using FullHD VGA monitor.
Initializes the graphics in about 1 second, which is twice as fast as the
VGA Option ROM.
The framebuffer is advertised and working in tianocore.
Change-Id: I7803566b64158405efc04a39f80a0ec98b44e646
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35726
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add early SuperIO initialization in bootblock to enable early console.
Also, remove some southbridge-specific initialization that has been
moved to southbridge bootblock initialization in previous patch.
The board obtains few additional timestamps: start of bootblock, end
of bootblock, starting to load romstage and finished loading romstage.
TEST=boot apu2 and launch Debian with Linux kernel 4.14.50
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: If770eff467b9a71d21eeb0963b6c3ebe72a88ef3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36915
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Now that we have a CONFIG_NO_FMAP_CACHE to completely configure out the
pre-RAM FMAP cache code, there's no point in allowing the region to be
optional anymore. This patch makes the section required by the linker.
If a board doesn't want to provide it, it has to select NO_FMAP_CACHE.
Adding FMAP_CACHE regions to a couple more targets that I think can use
them but I don't know anything about... please yell if one of these is
a bad idea and I should mark them NO_FMAP_CACHE instead.
Change-Id: Ic7d47772ab3abfa7e3a66815c3739d0af071abc2
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37497
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
While Merlin Falcon binaries are not available, make it explicit that it's
compiling for Prairie Falcon (it was being surreptitious about it).
Board Padmelon accepts 3 different SOC, just changing some resistors
(soldered or not): Brown Falcon, Prairie Falcon and Merlin Falcon. Code for
Brown Falcon is not currently available.
BUG=None
TEST=Build with prairie falcon.
Change-Id: I1663e4403a32a7d626dd2fa06763f18f4230457e
Signed-off-by: Richard Spiegel <richard.spiegel@silverbackltd.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36824
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Make a new Kconfig symbol for using soc//stoneyridge. This code also
supports Prairie Falcon is backward-compatible with Carrizo and Merlin
Falcon.
Although Bettong uses Carrizo, it does not currently rely on stoneyridge
source, so it is unaffected by this change.
Change-Id: I786ca54b0444cbcf36dc428a193006797b01fc09
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37224
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com>
The stoneyridge code inferred that if Merlin Falcon was built but no
Merlin Falcon binaries were present, the intent must be Prairie Falcon.
The two falcons are Embedded variants, and Prairie Falcon falls within
Family 15h Models 70h-7Fh.
Add a Prairie Falcon symbol that can be used explicitely. Drop
HAVE_MERLINFALCON_BINARIES.
Change-Id: I0d3a1bc302760c18c8fe3d57c955e2bb3bd8153a
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37223
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com>
'struct acpi_gpio' and 'struct acpi_irq' require the inclusion
of acpi_device.h. The only reason this wasn't caught previously
is due to the header being included with another driver compiled
first on the one board using it (google/eve).
Change-Id: I987f0ec6f769e550f3421629e0ef0c579a3d12f9
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37539
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
According to the POSIX standard, %p is supposed to print a pointer "as
if by %#x", meaning the "0x" prefix should automatically be prepended.
All other implementations out there (glibc, Linux, even libpayload) do
this, so we should make coreboot match. This patch changes vtxprintf()
accordingly and removes any explicit instances of "0x%p" from existing
format strings.
How to handle zero padding is less clear: the official POSIX definition
above technically says there should be no automatic zero padding, but in
practice most other implementations seem to do it and I assume most
programmers would prefer it. The way chosen here is to always zero-pad
to 32 bits, even on a 64-bit system. The rationale for this is that even
on 64-bit systems, coreboot always avoids using any memory above 4GB for
itself, so in practice all pointers should fit in that range and padding
everything to 64 bits would just hurt readability. Padding it this way
also helps pointers that do exceed 4GB (e.g. prints from MMU config on
some arm64 systems) stand out better from the others.
Change-Id: I0171b52f7288abb40e3fc3c8b874aee14b9bdcd6
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37626
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: David Guckian
SDCARD_CD is defined in onboard.h but required in ASL only, move this
define to dsdt.asl.
Removed the onboard.h file from the ASL files that don use it.
BUG=N/A
TEST=build
Change-Id: I35b75e0ae2e2bc4ce143aaec6df6016774676095
Signed-off-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37610
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
