Age | Commit message (Collapse) | Author |
|
This is to support other gfx enable method such as Gfx Peim (AKA GOP)
for Intel soc.
BRANCH=none
BUG=chrome-os-partner:44559
TEST=Built and boot on kunimitsu/glados.
Change-Id: Ib8010ea6901ea906a8b4129807b94ace71ef1165
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ad26a99560009c487070cccf6ab132188b9e247d
Original-Change-Id: Id132718a8bcec5446cc4c0d9d636d26e8a99bb15
Original-Signed-off-by: robbie zhang <robbie.zhang@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/303801
Original-Commit-Ready: Robbie Zhang <robbie.zhang@intel.com>
Original-Tested-by: Robbie Zhang <robbie.zhang@intel.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12140
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: I9a59fcb7cf221ae590a047c520e7aff99e23ecf1
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11962
Tested-by: build bot (Jenkins)
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
This reverts commit e6606518243d9beda31693d40493b5f7a1a3e2e0.
After some discussion on IRC we decided to revert it as libpayload can
only read the copy that was removed (and other users like nvramtool can
only read the other copy). So we need both copies at this time.
Signed-off-by: Nico Huber <nico.h@gmx.de>
Change-Id: I6cf6b2a1523d771bb52f3d5720b1b16ed4b348db
Reviewed-on: http://review.coreboot.org/11696
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Commit dbeedbef (arch/x86/bootblock: Link in object files selected with
bootblock-y) breaks building of x86 boards with
`CONFIG_EARLY_CBMEM_INIT` *not* selected but CBMEM time stamp collection
enabled.
Aaron Durbin explained as below [1] and provided this patch to fix it.
> That change actually processes bootblock-objs where before it never did
> such a thing. I'm sure this isn’t the only issue lurking. bootblock on
> x86 implied romcc and thus all the bootblock-y += rules that other
> architectures use worked, but now all the implied assumptions are no
> longer true on x86.
>
> timestamp stuff on x86 !CONFIG_EARLY_CBMEM_INIT is the issue you're
> seeing. In order to compile timestamp.c for bootblock under these
> conditions will mean there needs to be some more Makefile guarding.
[1] http://review.coreboot.org/11864
Change-Id: I3441b9fcdbbc8bbe82b9f2075e60668a846ecf09
Fix-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/11875
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
|
|
To support x86 verstage one needs a working buffer for
vboot. That buffer resides in the cache-as-ram region
which persists across verstage and romstage. The current
assumption is that verstage brings cache-as-ram up
and romstage tears cache-as-ram down. The timestamp,
cbmem console, and the vboot work buffer are persistent
through in both romstage and verstage. The vboot
work buffer as well as the cbmem console are permanently
destroyed once cache-as-ram is torn down. The timestamp
region is migrated. When verstage is enabled the assumption
is that _start is the romstage entry point. It's currently
expected that the chipset provides the entry point to
romstage when verstage is employed. Also, the car_var_*()
APIs use direct access when in verstage since its expected
verstage does not tear down cache-as-ram. Lastly, supporting
files were added to verstage-y such that an x86 verstage
will build and link.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados using separate verstage.
Change-Id: I097aa0b92f3bb95275205a3fd8b21362c67b97aa
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11822
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
On x86 the early stages are currently execute-in-place which
means they live in the memory-mapped spi flash. However, when
loading romstage from verstage the romstage is
execute-in-place so it's unnecessary to write over a read-only
media -- not to mention writing to read-only memory is wrong
to begin with.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados. Noted reduction of 20ms when
loading romstage.
Change-Id: I7cd399302a3925a05fbce82600b4c50ea66a0fcb
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11823
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
The conditions in cbmem console for supporting verstage
were implicitly utilizing CONFIG_BOOTBLOCK_CONSOLE to handle
the cbmem console enablement. Fix it so verstage is a first
class citizen for deciding actions pertaining to cbmem console.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados using verstage. cbmem console
shows verstage output.
Change-Id: Iba79efd1c1d4056f1a105a5e10ffc95f3e69b597
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11820
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Based on the info by Felix Held.
Change-Id: Iab84dd8a0e3c942da20a6e21db5510e4ad16cadd
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/11857
Tested-by: build bot (Jenkins)
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
The macro is defined in `util/cbmem/cbmem.c` too, so do the same here,
so that searching for that macro name shows all the usages.
Change-Id: I52e9fa414fbbe2012bc6d00312db528efba3e564
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/11803
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
|
|
Now that cbfs is adding more metadata in the cbfs file
header one needs to access that metadata. Therefore,
add struct cbfsf which tracks the metadata and data
of the file separately. Note that stage and payload
metadata specific to itself is still contained within
the 'data' portion of a cbfs file. Update the cbfs
API to use struct cbfsf. Additionally, remove struct
cbfsd as there's nothing else associated with a cbfs
region aside from offset and size which tracked
by a region_device (thanks, CBFS_ALIGNMENT!).
BUG=None
BRANCH=None
TEST=Built and booted through end of ramstage on qemu armv7.
Built and booted glados using Chrome OS.
Change-Id: I05486c6cf6cfcafa5c64b36324833b2374f763c2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11679
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
This fixes building with CONFIG_COVERAGE=y
Change-Id: I5128ae0ef0d4f71e3ede7bcb3ee7ed7e265d1bb7
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11729
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
While the romstage code flow is not consistent across all
mainboards/chipsets there is only one way of running ramstage
from romstage -- run_ramstage(). Move the
timestamp_add_now(TS_END_ROMSTAGE) to be within run_ramstage().
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados. TS_END_ROMSTAGE still present in
timestamp table.
Change-Id: I4b584e274ce2107e83ca6425491fdc71a138e82c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11700
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Currently coreboot expects the loader to clear the bss section
for all stages. i.e. stages don't clear their own bss. On ARM
SoCs the BootROM would be responsible for this. To do that
one needs to include the bss section data (all zeros) in the
bootblock.bin file. This was previously being attempted by
keeping the .bss info in the .data section because objcopy
happened zero out non-file allocated data section data.
Instead go back to linking bootblock with the bss section
but mark the bss section as loadable allocatable data. That
way it will be included in the binary properly when objcopy
-O binary is emplyed. Also do the same for the data section
in the case of no non-zero object values are in the data
section.
Without this change the trick of including .bss in .data
was not working when there wasn't a non-zero value object
in the data section.
BUG=None
BRANCH=None
TEST=Built emulation/qemu-armv7 and noted bootblock.bin contains
the cleared bss.
Change-Id: I94bd404c2c4a8b9332393e6224e98940a9cad4a2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11680
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Instead of reaching into src/include and re-writing code
allow for cleaner code sharing within coreboot and its
utilities. The additional thing needed at this point is
for the utilities to provide a printk() declaration within
a <console/console.h> file. That way code which uses printk()
can than be mapped properly to verbosity of utility parameters.
Change-Id: I9e46a279569733336bc0a018aed96bc924c07cdd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11592
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
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>
|