Age | Commit message (Collapse) | Author |
|
Patch b2a62622b (linking: move romstage and bootblock to use program.ld)
unified the linker scripts between different stages. Unfortunately it
omitted several special cases from the old bootblock.ld script that are
required for non-x86 environments.
This patch expands program.ld to once again merge the .BSS into the
program image for bootblocks (ensuring correct initialization by the
external loader). It also revives the .id section (which adds a
human-readable blurb of information to the top of an image) and fixes a
problem with unintended automated section alignment.
BRANCH=None
BUG=None
TEST=Jerry and Oak boot again.
Change-Id: I54271b8b59a9c773d858d676cde0218cb7f20e74
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 6fddbc00963e363039634fa31a9b66254b6cf18f
Original-Change-Id: I4d748056f1ab29a8e730f861879982bdf4c33eab
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/299413
Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11660
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Previously there were 2 paths in linking ramstage. One was used for
RELOCATABLE_RAMSTAGE while the other was fixed location. Now that
rmodtool can handle multiple secitons for a single proram segment
there's no need for linking ramstage using lib/rmodule.ld. That
also means true rmodules don't have symbols required for ramstage
purposes so fix memlayout.h. Lastly add default rules for creating
rmod files from the known file names and locations.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi. Inspected ramstage.debug as well as rmodules
created during the build.
Change-Id: I98d249036c27cb4847512ab8bca5ea7b02ce04bd
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11524
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Add an LDFLAGS_common variable and use that for each stage
during linking within all the architectures. All the architectures
support gc-sections, and as such they should be linking in the
same way.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi and analyzed the relocatable ramstage.
Change-Id: I41fbded54055455889b297b9e8738db4dda0aad0
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11522
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Bring rmodule linking into the common linking method.
The __rmodule_entry symbol was removed while using
a more common _start symbol. The rmodtool will honor
the entry point found within the ELF header. Add
ENV_RMODULE so that one can distinguish the environment
when generating linker scripts for rmodules. Lastly,
directly use program.ld for the rmodule.ld linker script.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi and analyzed the relocatable ramstage,
sipi_vector, and smm rmodules.
Change-Id: Iaa499eb229d8171272add9ee6d27cff75e7534ac
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11517
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
There's no reason to have a separate verstage.ld now
that there is a unified stage linking strategy. Moreover
verstage support is throughout the code base as it is
so bring in those link script macros into the common
memlayout.h as that removes one more specific thing a
board/chipset needs to do in order to turn on verstage.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=None
Change-Id: I1195e06e06c1f81a758f68a026167689c19589dd
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11516
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
All the other architectures are using the memlayout
for linking romstage. Use that same method on x86
as well for consistency.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built a myriad of boards. Analyzed readelf output.
Change-Id: I016666c4b01410df112e588c2949e3fc64540c2e
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11510
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Instead of having separate <stage>.ld files in src/lib
one file can be used: program.ld. There's now only one
touch point for stage layout.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built a myriad of boards. Analyzed readelf output.
Change-Id: I4c3e3671d696caa2c7601065a85fab803e86f971
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11509
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Though coreboot started as x86 only, the current approach to x86
linking is out of the norm with respect to other architectures.
To start alleviating that the way ramstage is linked is partially
unified. A new file, program.ld, was added to provide a common way
to link stages by deferring to per-stage architectural overrides.
The previous ramstage.ld is no longer required.
Note that this change doesn't handle RELOCATABLE_RAMSTAGE
because that is handled by rmodule.ld. Future convergence
can be achieved, but for the time being that's being left out.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built a myriad of boards.
Change-Id: I5d689bfa7e0e9aff3a148178515ef241b5f70661
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11507
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
coreboot has no CREDITS file.
Change-Id: Iaa4686979ba1385b00ad1dbb6ea91e58f5014384
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/11514
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
In order to prepare for more unification of the linker
scripts prefix pci_drivers, epci_drivers, cpu_drivers, and
ecpu_drivers with an underscore.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built different boards includes ones w/ and w/o relocatable
ramstage.
Change-Id: I8918b38db3b754332e8d8506b424f3c6b3e06af8
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11506
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Some of the Chrome OS boards were directly calling vboot
called in some form after contorting around #ifdef preprocessor
macros. The reasoning is that Chrome OS doesn't always do display
initialization during startup. It's runtime dependent. While
this is a requirement that doesn't mean vboot functions should be
sprinkled around in the mainboard and chipset code. Instead provide
one function, display_init_required(), that provides the policy
for determining display initialization action. For Chrome OS
devices this function honors vboot_skip_display_init() and all
other configurations default to initializing display.
Change-Id: I403213e22c0e621e148773597a550addfbaf3f7e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11490
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Add the timestamp tick frequency within the timestamp table so
the cbmem utility doesn't try to figure it out on its own. Those
paths still exist for x86 systems which don't provide tsc_freq_mhz().
All other non-x86 systems use the monotonic timer which has a 1us
granularity or 1MHz.
One of the main reasons is that Linux is reporting
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq as the true
turbo frequency on turbo enables machines. This change also fixes
the p-state values honored in cpufreq for turbo machines in that
turbo p-pstates were reported as 100MHz greater than nominal.
BUG=chrome-os-partner:44669
BRANCH=firmware-strago-7287.B
TEST=Built and booted on glados. Confirmed table frequency honored.
Change-Id: I763fe2d9a7b01d0ef5556e5abff36032062f5801
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11470
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
BRANCH=None
BUG=chrome-os-partner:43789
TEST=Mickey board, 640x480@60Hz display normally
Change-Id: Iea298302fe1124edbef157d1d81c12610402e9c7
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: 0209422efe52c45cab3c0d787b27352f63578e76
Original-Change-Id: Idf4c8cd9f2da3c5daa589973d831a506ff549b8b
Original-Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/293994
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/11397
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This patch will let you to choose a favourite mode to
display, while not just taking the edid detail timing.
But not all modes are able to set, only modes that
are in established or standard timing, and we only
support a few common common resolutions for now.
BUG=chrome-os-partner:42946
BRANCH=firmware-veyron
TEST=tested dev mode on Mickey at 640x480@60Hz
Change-Id: I8a9dedfe08057d42d85b8ca129935a258cb26762
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: 090583f90ff720d88e5cfe69fcb2d541c716f0e6
Original-Change-Id: Iaa8c9a6fad106ee792f7cd1a0ac77e3dcbadf481
Original-Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/289671
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/11390
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This ensures the output buffer is initialized before exiting
decode_edid() so that if the return value is ignored in higher-level
logic (like when dealing with external displays) we don't leave
the struct filled with garbage.
BUG=chrome-os-partner:42946
BRANCH=firmware-veyron
TEST=none
Change-Id: I557e2495157458342db6d8b0b1ecb39f7267f61f
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: bb12dca133576543efa4d3bcc9aadf85d37c8b71
Original-Change-Id: I697436fffadc7dd3af239436061975165a97ec8c
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/293547
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/11389
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This replaces various timing mode parameters parameters with
an edid_mode struct within the edid struct.
BUG=none
BRANCH=firmware-veyron
TEST=built and booted on Mickey, saw display come up, also
compiled for link,falco,peppy,rambi,nyan_big,rush,smaug
[pg: extended to also cover peach_pit, daisy and lenovo/t530]
Change-Id: Icd0d67bfd3c422be087976261806b9525b2b9c7e
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: abcbf25c81b25fadf71cae106e01b3e36391f5e9
Original-Change-Id: I1bfba5b06a708d042286db56b37f67302f61fff6
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/289964
Original-Reviewed-by: Yakir Yang <ykk@rock-chips.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/11388
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
There are serveral members of the edid struct which are never used
outside of the EDID parsing code itself. This patch moves them to a
struct in edid.c. They might be useful some day but until then we can
just pretty print them and not pollute the more general API.
BUG=none
BRANCH=firmware-veyron
TEST=compiled for veyron_mickey, peppy, link, nyan_big, rush, smaug
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I660f28c850163e89fe1f59d6c5cfd6e63a56dda0
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: ee8ea314a0d8f5993508f560fc24ab17604049df
Original-Change-Id: I7fb8674619c0b780cc64f3ab786286225a3fe0e2
Original-Reviewed-on: https://chromium-review.googlesource.com/290333
Original-Reviewed-by: Yakir Yang <ykk@rock-chips.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/11387
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The stage_cache_add() function should not be manipulating
the struct prog argument in anyway. Therefore, mark it as
const.
BUG=chrome-os-partner:43636
BRANCH=None
TEST=Built, booted, suspended, and resumed on glados.
Original-Change-Id: I4509e478d3c98247b9d776f6534b949d9ba6282c
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/290721
Original-Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: Ibadc00a9e1cbbf12119def92d77a79077625fb85
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11192
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
This should probably be moved out of lib and to arch/x86,
since it does not even apply on x86-64, and ARM has its
own copy of libgcc.
Change-Id: I4fca1323927f8d37128472ed60d059f7a459fc71
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/11110
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
We've seen an increasing need to reduce stack sizes more and more for
space reasons, and it's always guesswork because no one has a good idea
how little is too litte. We now have boards with 3K and 2K stacks, and
old pieces of common code often allocate large temporary buffers that
would lead to very dangerous and hard to detect bugs when someone
eventually tries to use them on one of those.
This patch tries improve this situation at least a bit by declaring 2K
as the minimum stack size all of coreboot code should work with. It
checks all function frames with -Wstack-usage=1536 to make sure we don't
allocate more than 1.5K in a single buffer. This is of course not a
perfect test, but it should catch the most common situation of declaring
a single, large buffer in some close-to-leaf function (with the
assumption that 0.5K is hopefully enough for all the "normal" functions
above that).
Change one example where we were a bit overzealous and put a 1K buffer
into BSS back to stack allocation, since it actually conforms to this
new assumption and frees up another kilobyte of that highly sought-after
verstage space. Not touching x86 with any of this since it's lack of
__PRE_RAM__ BSS often requires it to allocate way more on the stack than
would usually be considered sane.
BRANCH=veyron
BUG=None
TEST=Compiled Cosmos, Daisy, Falco, Blaze, Pit, Storm, Urara and Pinky,
made sure they still build as well as before and don't show any stack
usage warnings.
Change-Id: Idc53d33bd8487bbef49d3ecd751914b0308006ec
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8e5931066575e256dfc2295c3dab7f0e1b65417f
Original-Change-Id: I30bd9c2c77e0e0623df89b9e5bb43ed29506be98
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/236978
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9729
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Assume that it's 64 byte.
Change-Id: I168facd92f64c2cf99c26c350c60317807a4aed4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10919
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Commit bd1499d3 fixed a bug to not re-initialize the timestamp
cache in ramstage for EARLY_CBMEM_INIT. However, EARLY_CBMEM_INIT
was not included. Therefore, add this condition. This will result
in base_time being initialized to the passed in timestamp
for !EARLY_CBMEM_INIT platforms.
Change-Id: Ia1d744b3cfd28163f3339f2364efe59f7dcb719b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10884
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
This allows finding the currently used CBFS (in case there are several), and
avoids the need to define flash size when building the payload.
Change-Id: I4b00159610077761c501507e136407e9ae08c73e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10867
Tested-by: build bot (Jenkins)
|
|
The fmap directory can be useful to pass to the payload. For that, we need to
be able to get it.
Change-Id: Ibe0be73bb4fe28afb16d4d215b979eb0be369645
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10866
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
vboot passes around the offset and size of the region to use in later stages.
To assign more meaning to this pair, provide a function that returns the
fmap area name if there's a precise match (and an error otherwise).
Change-Id: I5724b860271025c8cb8b390ecbd33352ea779660
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10865
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Kconfigs symbols of type bool are always defined, and can be tested with
the IS_ENABLED() macro.
symbol type except string.
Change-Id: Ic4ba79f519ee2a53d39c10859bbfa9c32015b19d
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10885
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
While running ramstage with the EARLY_CBMEM_INIT config the timestamp
cache was re-initialized and subsequently used. The result was that
the ramstage timestamps would be dropped from cbmem. The reason
is that the ramstage timestamps perpetually lived in ramstage BSS
never getting sync'd back into cbmem. The fix is to honor the
cache state in ramstage in the timestamp_init() path.
Also, make cache_state a fixed bit width to allow for different
architectures across the pre-ramstage stages.
TEST=Used qemu-armv7 as a test harness with debugging info.
Change-Id: Ibb276e513278e81cb741b1e1f6dbd1e8051cc907
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10880
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
In order to accommodate tracking timestamps in all the
__PRE_RAM__ stages (bootblock, verstage, romstage, etc)
of a platform one needs to provide a way to specify
a persistent region of SRAM or cache-as-ram to store
the timestamps until cbmem comes online. Provide that
infrastructure.
Based on original patches from chromium.org:
Original-Change-Id: I4d78653c0595523eeeb02115423e7fecceea5e1e
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/223348
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Original-Change-Id: Ie5ffda3112d626068bd1904afcc5a09bc4916d16
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/224024
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Change-Id: I8779526136e89ae61a6f177ce5c74a6530469ae1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10790
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
|
|
The LZMA functions are supposed to return the decompressed size, but
what they actually return is just an unaltered field from the LZMA
header that is *supposed* to contain the decompressed size. Apparently
some encoders just overshoot that for no good reason. This patch changes
the code such that the actual amount of decompressed bytes is returned.
BRANCH=smaug
BUG=None
TEST=Printed output bytes when decompressing kernels with LZMA in
depthcharge, noted that amounts now make sense.
Change-Id: Icdd8f782aa87841f770eff4c14a08973530c7446
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 24b2fa8c9a342ca4288dad1430c8965395f00263
Original-Change-Id: Ib4cf8673846aedd34656e594ce7b8ea875b56099
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/282742
Original-Reviewed-by: Stefan Reinauer <reinauer@google.com>
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10777
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Some ld versions (eg. the one used in the chromium build system) mis-handled
the redefined symbol in romstage.ld, so use the feature that exists for
precisely that purpose.
Change-Id: I184310ab20a02f6b3d569798448eac78b13e88a3
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10754
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: I752fcc3b8687e4f861c3977322ebb6439f14fac4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10708
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The 8250 MMIO uart driver calls udelay, and if that is the first
call then it will also call printk in init_timer() which can result
in a deadlock trying to acquire the console lock.
There are a few options to prevent this:
1) remove the printk in init_timer which removes a useful debug message
2) change the udelay() to cpu_relax() in uart8250mem.c
3- move the init_timer() call in ramstage main() to be called earlier
Since hardwaremain.c:main() already has an explicit call to init_timer()
on x86 it is an easy change to move this to happen before the console
is initialized.
BUG=chrome-os-partner:40857
BRANCH=none
TEST=boot on glados with serial output through ramstage
Change-Id: I8a8d8cccdd0b53de9de44600076bfad75e4f5514
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 744610f72628a944582925933b286f65bde630d9
Original-Change-Id: Ic1fdafaea5541c6d7b1bb6f15399c759f484aa74
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/275157
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10698
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
|
|
With an x86_64-elf toolchain, this code that is unused
outside of ramstage, is causing undefined references.
Help the compiler along a little bit by conditionally compiling
the code in ramstage only.
Change-Id: I75518149b53c24eda4b985b0fef856447e196dec
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10585
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Instead of having the chipset code make the approrpiate
calls at the appropriate places use the cbmem init hooks
to take the appropriate action. That way no chipset code
needs to be changed in order to support the external
stage cache.
Change-Id: If74e6155ae86646bde02b2e1b550ade92b8ba9bb
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10481
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
It can be helpful to certain users of the cbmem init hooks
to know if recovery was done or not. Therefore, add this
as a parameter to the hooks.
Change-Id: I049fc191059cfdb8095986d3dc4eee9e25cf5452
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10480
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Squashed and adjusted two changes from chromium.git. Covers
CBMEM init for ROMTAGE and RAMSTAGE.
cbmem: Unify random on-CBMEM-init tasks under common CBMEM_INIT_HOOK() API
There are several use cases for performing a certain task when CBMEM is
first set up (usually to migrate some data into it that was previously
kept in BSS/SRAM/hammerspace), and unfortunately we handle each of them
differently: timestamp migration is called explicitly from
cbmem_initialize(), certain x86-chipset-specific tasks use the
CAR_MIGRATION() macro to register a hook, and the CBMEM console is
migrated through a direct call from romstage (on non-x86 and SandyBridge
boards).
This patch decouples the CAR_MIGRATION() hook mechanism from
cache-as-RAM and rechristens it to CBMEM_INIT_HOOK(), which is a clearer
description of what it really does. All of the above use cases are
ported to this new, consistent model, allowing us to have one less line
of boilerplate in non-CAR romstages.
BRANCH=None
BUG=None
TEST=Built and booted on Nyan_Blaze and Falco with and without
CONFIG_CBMEM_CONSOLE. Confirmed that 'cbmem -c' shows the full log after
boot (and the resume log after S3 resume on Falco). Compiled for Parrot,
Stout and Lumpy.
Original-Change-Id: I1681b372664f5a1f15c3733cbd32b9b11f55f8ea
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232612
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
cbmem: Extend hooks to ramstage, fix timestamp synching
Commit 7dd5bbd71 (cbmem: Unify random on-CBMEM-init tasks under common
CBMEM_INIT_HOOK() API) inadvertently broke ramstage timestamps since
timestamp_sync() was no longer called there. Oops.
This patch fixes the issue by extending the CBMEM_INIT_HOOK() mechanism
to the cbmem_initialize() call in ramstage. The macro is split into
explicit ROMSTAGE_/RAMSTAGE_ versions to make the behavior as clear as
possible and prevent surprises (although just using a single macro and
relying on the Makefiles to link an object into all appropriate stages
would also work).
This allows us to get rid of the explicit cbmemc_reinit() in ramstage
(which I somehow accounted for in the last patch without realizing that
timestamps work exactly the same way...), and replace the older and less
flexible cbmem_arch_init() mechanism.
Also added a size assertion for the pre-RAM CBMEM console to memlayout
that could prevent a very unlikely buffer overflow I just noticed.
BRANCH=None
BUG=None
TEST=Booted on Pinky and Falco, confirmed that ramstage timestamps once
again show up. Compile-tested for Rambi and Samus.
Original-Change-Id: If907266c3f20dc3d599b5c968ea5b39fe5c00e9c
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233533
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I1be89bafacfe85cba63426e2d91f5d8d4caa1800
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/7878
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This patch adds a few bit counting functions that are commonly needed
for certain register calculations. We previously had a log2()
implementation already, but it was awkwardly split between some C code
that's only available in ramstage and an optimized x86-specific
implementation in pre-RAM that prevented other archs from pulling it
into earlier stages.
Using __builtin_clz() as the baseline allows GCC to inline optimized
assembly for most archs (including CLZ on ARM/ARM64 and BSR on x86), and
to perform constant-folding if possible. What was previously named log2f
on pre-RAM x86 is now ffs, since that's the standard name for that
operation and I honestly don't have the slightest idea how it could've
ever ended up being called log2f (which in POSIX is 'binary(2) LOGarithm
with Float result, whereas the Find First Set operation has no direct
correlation to logarithms that I know of). Make ffs result 0-based
instead of the POSIX standard's 1-based since that is consistent with
clz, log2 and the former log2f, and generally closer to what you want
for most applications (a value that can directly be used as a shift to
reach the found bit). Call it __ffs() instead of ffs() to avoid problems
when importing code, since that's what Linux uses for the 0-based
operation.
CQ-DEPEND=CL:273023
BRANCH=None
BUG=None
TEST=Built on Big, Falco, Jerry, Oak and Urara. Compared old and new
log2() and __ffs() results on Falco for a bunch of test values.
Change-Id: I599209b342059e17b3130621edb6b6bbeae26876
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3701a16ae944ecff9c54fa9a50d28015690fcb2f
Original-Change-Id: I60f7cf893792508188fa04d088401a8bca4b4af6
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/273008
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10394
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
As there can be more than one source of firmware assets this
patch generalizes the notion of locating a particular asset.
struct asset is added along with some helper functions for
working on assets as a first class citizen.
Change-Id: I2ce575d1e5259aed4c34c3dcfd438abe9db1d7b9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10264
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
One can remove the struct buffer_area and use the region_device
embedded in the struct prog to represent the in-memory loaded
program. Do this by introducing a addrspace_32bit mem_region_device
that can have region_device operations performed on it. The
addrspace_32bit name was chosen to make it explicit that 32-bits
of address space is supported at the max.
Change-Id: Ifffa0ef301141de940e54581b5a7b6cd81311ead
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10261
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
A new CBFS API is introduced to allow making CBFS access
easier for providing multiple CBFS sources. That is achieved
by decoupling the cbfs source from a CBFS file. A CBFS
source is described by a descriptor. It contains the necessary
properties for walking a CBFS to locate a file. The CBFS
file is then decoupled from the CBFS descriptor in that it's
no longer needed to access the contents of the file.
All of this is accomplished using the regions infrastructure
by repsenting CBFS sources and files as region_devices. Because
region_devices can be chained together forming subregions this
allows one to decouple a CBFS source from a file. This also allows
one to provide CBFS files that came from other sources for
payload and/or stage loading.
The program loading takes advantage of those very properties
by allowing multiple sources for locating a program. Because of
this we can reduce the overhead of loading programs because
it's all done in the common code paths. Only locating the
program is per source.
Change-Id: I339b84fce95f03d1dbb63a0f54a26be5eb07f7c8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9134
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: I8e694f37c8709efd702208aa005096ebf1f3abb5
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10356
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
|
|
Instead of being pointer based use the region infrastrucutre.
Additionally, this removes the need for arch-specific compilation
paths. The users of the new API can use the region APIs to memory
map or read the region provided by the new fmap API.
Change-Id: Ie36e9ff9cb554234ec394b921f029eeed6845aee
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9170
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
The boot_device is a region_device that represents the
device from which coreboot retrieves and boots its stages.
The existing cbfs implementations use the boot_device as
the intermediary for accessing the CBFS region. Also,
there's currently only support for a read-only view of
the boot_device. i.e. one cannot write to the boot_device
using this view. However, a writable boot_device could
be added in the future.
Change-Id: Ic0da796ab161b8025c90631be3423ba6473ad31c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10216
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Now that the users of cbmem_set_top() always provide a consistent
cbmem_top() value there's no need to have cbmem_set_top() around.
Therefore, delete it.
Change-Id: I0c96e2b8b829eddbeb1fdf755ed59c51ea689d1b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10314
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
On S3 resume, CBMEM_ID_CONSOLE from previous boot is found in ramstage,
even when romstage did not create it. So buffer did not get cleared
on S3 resume path.
Also do not allocate for preram_cbmem_console in CAR when there
are no means to back it up to ram.
Change-Id: I175cebbb938adf2a7414703fefffb8da796e9fa9
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/10301
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
With LATE_CBMEM_INIT, do not search for the initial collection from
CBMEM in ramstage. On S3 resume this would find the non-empty
collection from previous run of ramstage. Start with an empty table
instead.
Remove a spurious error message as the stamps get stashed and
will be copied to CBMEM later.
Change-Id: Ib94049531c0ac23af25407bd2ca7644ee0163d69
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/10300
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Implementation for cbmem_find() did not work for boards without
EARLY_CBMEM_INIT in romstage.
This is required for S3 resume to work on AGESA plaforms.
First broken with commit 0dff57d
cbmem: switch over to imd-based cbmem
Change-Id: I9c1a4f6839f5d90f825787baad2a3824a04b5bdc
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/10299
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
The __console attribute as well as linker binding
was dropped at some point. Kill of the dead code and
infrastructure.
Change-Id: I15e1fb4468fffe2e148ec9ac8539dfd958551807
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10279
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
As per discussion with lawyers[tm], it's not a good idea to
shorten the license header too much - not for legal reasons
but because there are tools that look for them, and giving
them a standard pattern simplifies things.
However, we got confirmation that we don't have to update
every file ever added to coreboot whenever the FSF gets a
new lease, but can drop the address instead.
util/kconfig is excluded because that's imported code that
we may want to synchronize every now and then.
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} +
$ find * -type f
-a \! -name \*.patch \
-a \! -name \*_shipped \
-a \! -name LICENSE_GPL \
-a \! -name LGPL.txt \
-a \! -name COPYING \
-a \! -name DISCLAIMER \
-exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} +
Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9233
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
|
|
Intermediate linking may distort linker behavior (in particular related to
weak symbols). The idea is that archives are closer to 'just a list of
object files', and ideally makes the linker more predictable.
Using --whole-archive, the linker doesn't optimize out object files just
because their symbols were already provided by weak versions. However it
shouldn't be used for libgcc, because that one has some unexpected side-effects.
Change-Id: Ie226c198a93bcdca2d82c02431c72108a1c6ea60
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10139
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
|