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>
It encourages users from writing to the FSF without giving an address.
Linux also prefers to drop that and their checkpatch.pl (that we
imported) looks out for that.
This is the result of util/scripts/no-fsf-addresses.sh with no further
editing.
Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11888
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The src/lib/timestamp.c already has an implementation using
timer_monotonic_get() for timestamp_get(). Use that instead
of duplicating the logic.
BUG=chrome-os-partner:44669
BRANCH=None
TEST=None
Change-Id: If17be86143f217445bd64d67ceee4355fa482d39
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11468
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Used command line to remove empty lines at end of file:
find . -type f -exec sed -i -e :a -e '/^\n*$/{$d;N;};/\n$/ba' {} \;
Change-Id: I816ac9666b6dbb7c7e47843672f0d5cc499766a3
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: http://review.coreboot.org/10446
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
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>
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>
arch_program_segment_loaded ensures that the program segment loaded is
synced back from the cache to PoC. dcache_flush_all on arm64 does not
guarantee PoC in case of MP systems. Thus, it is important to track
and sync back all the required segments using
arch_program_segment_loaded. Use this function in rmodules as well
instead of cache_sync_instructions which guarantees sync upto PoC.
BUG=chrome-os-partner:37546
BRANCH=None
TEST=Boots into depthcharge on foster
Change-Id: I64c2dd5e40ea59fa31f300174ca0d0aebcf8041d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 35ba0b882b86ff2c29ac766e1d65f403c8346247
Original-Change-Id: I964aa09f0cafdaab170606cd4b8f2e027698aee7
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/260908
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/10173
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
The build system includes a bunch of files into verstage that
also exist in romstage - generic drivers etc.
These create link time conflicts when trying to link both the
verstage copy and romstage copy together in a combined configuration,
so separate "stage" parts (that allow things to run) from "library" parts
(that contain the vboot specifics).
Change-Id: Ieed910fcd642693e5e89e55f3e6801887d94462f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10041
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Without this, building with COLLECT_TIMESTAMPS fails.
Fixes a mistake during upstreaming in commit 0de8820.
Change-Id: Ie56bd38649a821f6b22a1e5dee5f50ef397035fe
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10002
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Some platforms may pass as a parameter the maskrom or vendor startup
code information when calling the bootblock.
Make sure the bootblock startup code saves this parameter for use by
coreboot. As we don't want to touch memory before caches are
initialized, save the passed in parameter in r10 for the duration of
cache initialization.
Added warning comments to help enforcing that cache initialization
code does not touch r10.
BRANCH=storm
BUG=chrome-os-partner:30623
TEST=with the rest of the patches applied see the QCA uber-sbl report
in the coreboot console output.
Change-Id: Ic6a09e8c3cf13ac4f2d12ee91c7ab41bc9aa95da
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e41584f769eb042604883275b0d0bdfbf5b0d358
Original-Change-Id: I517a79dc95040326f46f0b80ee4e74bdddde8bf4
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/255144
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Vadim Bendebury <vbendeb@gmail.com>
Reviewed-on: http://review.coreboot.org/9842
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This is necessary to make sure that bootblock uses the default CBFS
header (as it ought to) when multiple CBFS images support is enabled.
BRANCH=storm
BUG=chrome-os-partner:34161, chromium:445938
TEST=with the rest of the patches applied storm boots all the way inot
the Linux prompt
Change-Id: I5e029d95c5cb085794c7bf5f44513b2144661e38
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 75b2c2ef6c8287db7c3e5879cacfd5dcba4391ac
Original-Change-Id: I5c352921b4c9b6a3294f4658d174e0842d2ee365
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/237661
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9770
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
broadcom cygnus hangs if we clean caches by dcache_clean_invalidate_all
at bootblock entry point. this change makes startup code call
dcache_invalidate_all instead.
other boards theoretically should not be affected as long as maskrom
does not hand off execution to bootblock with dirty cache.
BUG=chrome-os-partner:36648,chrome-os-partner:36691
BRANCH=broadcom-firmware
TEST=boot cygnus b0 board, messages were printed on console:
coreboot-688aae9-dirty bootblock Mon Feb 9 13:21:02 PST 2015
starting...
Exception handlers installed.
Change-Id: I05777ca525c97bb3d7cbb5ea7e872a602dcd5a19
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 59de5328df9d0502a3b3f7c624d3e86e038de50e
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: I9b8850846b941e7e62712e90cc28ad14a68da393
Original-Reviewed-on: https://chromium-review.googlesource.com/251304
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9762
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We have known for a while that the old x86 model of calling init_timer()
in ramstage doesn't make sense on other archs (and is questionable in
general), and finally removed it with CL:219719. However, now timer
initialization is completely buried in the platform code, and it's hard
to ensure it is done in time to set up timestamps. For three out of four
non-x86 SoC vendors we have brought up for now, the timers need some
kind of SoC-specific initialization.
This patch reintroduces init_timer() as a weak function that can be
overridden by platform code. The call in ramstage is restricted to x86
(and should probably eventually be removed from there as well), and
other archs should call them at the earliest reasonable point in their
bootblock. (Only changing arm for now since arm64 and mips bootblocks
are still in very early state and should sync up to features in arm once
their requirements are better understood.) This allows us to move
timestamp_init() into arch code, so that we can rely on timestamps
being available at a well-defined point and initialize our base value as
early as possible. (Platforms who know that their timers start at zero
can still safely call timestamp_init(0) again from platform code.)
BRANCH=None
BUG=None
TEST=Booted Pinky, Blaze and Storm, compiled Daisy and Pit.
Change-Id: I1b064ba3831c0c5b7965b1d88a6f4a590789c891
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ffaebcd3785c4ce998ac1536e9fdd46ce3f52bfa
Original-Change-Id: Iece1614b7442d4fa9ca981010e1c8497bdea308d
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/234062
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9606
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
On most platforms, enabling the console and exception handlers are
amongst the very first things you want to do, as they help you see
what's going on and debug errors in other early init code. However, most
ARM boards require some small amount of board-specific initialization
(pinmuxing, maybe clocks) to get the UART running, which is why
bootblock_mainboard_init() (and with it almost all of the actual
bootblock code) always had to run before console initialization for now.
This patch introduces an explicit bootblock_mainboard_early_init() hook
for only that part of initialization that absolutely needs to run before
console output. The other two hooks for SoC and mainboard are moved
below console_init(). This model has already proven its worth before in
the tegra124 and tegra132 custom bootblocks.
BRANCH=None
BUG=chrome-os-partner:32123
TEST=Booted on Pinky. Compiled for Daisy, Storm and Ryu.
Change-Id: I510c58189faf0c08c740bcc3b5a654f81f892464
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f58e84a2fc1c9951e9c4c65cdec1dbeb6a20d597
Original-Change-Id: I4257b5a8807595140e8c973ca04e68ea8630bf9a
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/231941
Reviewed-on: http://review.coreboot.org/9603
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
When the i-cache is on and the d-cache is off, the L1 i-cache is still
fetching information through L2 cache.
Since L2 cache is never invalidated, it has stale information.
BRANCH=storm
BUG=none
TEST=Resolves the invalidate data fetch from i-cache while jumping from
bootblock to romstage.
Change-Id: Ibaca1219be2e40ce5bbbd1c124863d0ea71d0466
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: a13e20f9b242d8193dcb314a2bdc708c6bdfea51
Original-Change-Id: I252682d372bd505f525f075461b327e4bcf70a1a
Original-Signed-off-by: Deepa Dinamani <deepad@codeaurora.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/236422
Original-Reviewed-by: Trevor Bourget <tbourget@codeaurora.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/9587
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
this change sets the stack pointer to the value specified in
memlayout.ld before jumping to the bootblock.
BUG=none
BRANCH=ToT
TEST=Built cosmos and all other current boards.
Change-Id: Ic1b790f27bce431124ba70cc2d3d3607c537564b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d50fd02db8bf10147fd808f3030e6297b9ca0aad
Original-Change-Id: I4bb8cea7435d2a0e2c1ced050c3366d2e636cb8a
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/225420
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/9384
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
this adds an entry point jumping to main for the bootblock.
BUG=None
BRANCH=ToT
TEST=Built coreboot for cosmos
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: I1c9ea6ba63a1058e09613d969fe00308260037be
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 662d0083f25008b55b9bc5fbce9e30e6b80c2c65
Original-Change-Id: I74f2f5e3b3961ab54a7913e6b3a3ab0e6fd813a3
Original-Reviewed-on: https://chromium-review.googlesource.com/225205
Original-Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Original-Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/9382
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Paging code is tricky and figuring out what is wrong with it can be a
pain. This patch tries to ease the burden by giving a little more
information for prefetch and data aborts, dumping the Instruction Fault
Address Register (IFAR), Instruction Fault Status Register (IFSR) and
Auxiliary Instruction Fault Status Register (AIFSR) or the respective
Data registers. These contain additional information about the cause of
the abort (internal/external, write or read, fault subtype, etc.) and
the faulting address.
BUG=None
TEST=I have read through enough imprecise asynchronous external abort
reports with this patch that I learned the bit pattern by heart.
Change-Id: If1850c4a6df29b1195714ed0bdf025e51220e8ab
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: bf3b4924121825a5ceef7e5c14b7b307d01f8e9c
Original-Change-Id: I56a0557d4257f40b5b30c559c84eaf9b9f729099
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/223784
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9345
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Remember the XN bit? The one we had so much fun with on Nyan (LPAE)
because not setting it allows random instruction prefetches to device
memory that hang the system every few thousand boots? Thankfully, we had
always been setting it in the non-LPAE MMU code already...
"When the XN bit is 1, a Permission fault is generated if the processor
attempts to execute an instruction fetched from the corresponding memory
region. However, when using the Short-descriptor translation table
format, the fault is generated only if the access is to memory in the
Client domain, see Domains[...]" - ARM A.R.M. section B3.7.2
Oops. This patch changes our Domain Access Control Register (DACR) to
set domain 0 (the only one we are using) to Client. This means that
access permissions (AP[2:0] bits) become enforced, but they are already
set to full access (0b011). It also means that non-LPAE systems will not
be allowed to execute from DCACHE_OFF memory with enabled MMU anymore.
As far as I can see, Veyron_Pinky has been the only board that does
that.
BUG=chrome-os-partner:32118
TEST=Booted Veyron_Pinky with MMU in the bootblock, saw hangs that look
like spurious prefetches and confirmed that this patch fixes them.
Change-Id: I81c00743f938924a5dc8825389fe512a069b77db
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: cbc96db296a41ae700371a8515a1179c142f58e7
Original-Change-Id: I30676a5bfe12d516e5f910f51ee6854f6e5be557
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/223783
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9343
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch adds an mmu_config_range_kb() function, which can set memory
types at the 4KB level by chaining a fine-grained page table to an
existing superpage entry. It is only intended for special cases where
this level of precision is really necessary and therefore comes with a
few practical limitations (the area for each invocation must be confined
within a single superpage, and you are not allowed to remap the same
region with mmu_config_range() again later). Since the fine-grained page
tables need some space, boards intending to use this feature must define
a TTB_SUBTABLES() region in their memlayout.ld.
BUG=chrome-os-partner:32848
TEST=Booted both Veyron_Pinky (normal) and Nyan_Blaze (LPAE), ensured
that they still work. Checksummed the page tables with and without this
patch, confirmed that they end up equal. Hacked in some subtable test
entries, hexdumped all tables and manually confirmed that they look as
expected.
Change-Id: I8c3eb7c2eb9c82e2abc5f2c0dda91f5b2eee7023
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2f13e60cf5509b9a63fb7b8d84846daf889dc1b7
Original-Change-Id: Iedf7ca435ae337ead85115200d6987fb0d4828d7
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/223781
Reviewed-on: http://review.coreboot.org/9341
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch creates a new mechanism to define the static memory layout
(primarily in SRAM) for a given board, superseding the brittle mass of
Kconfigs that we were using before. The core part is a memlayout.ld file
in the mainboard directory (although boards are expected to just include
the SoC default in most cases), which is the primary linker script for
all stages (though not rmodules for now). It uses preprocessor macros
from <memlayout.h> to form a different valid linker script for all
stages while looking like a declarative, boilerplate-free map of memory
addresses to the programmer. Linker asserts will automatically guarantee
that the defined regions cannot overlap. Stages are defined with a
maximum size that will be enforced by the linker. The file serves to
both define and document the memory layout, so that the documentation
cannot go missing or out of date.
The mechanism is implemented for all boards in the ARM, ARM64 and MIPS
architectures, and should be extended onto all systems using SRAM in the
future. The CAR/XIP environment on x86 has very different requirements
and the layout is generally not as static, so it will stay like it is
and be unaffected by this patch (save for aligning some symbol names for
consistency and sharing the new common ramstage linker script include).
BUG=None
TEST=Booted normally and in recovery mode, checked suspend/resume and
the CBMEM console on Falco, Blaze (both normal and vboot2), Pinky and
Pit. Compiled Ryu, Storm and Urara, manually compared the disassemblies
with ToT and looked for red flags.
Change-Id: Ifd2276417f2036cbe9c056f17e42f051bcd20e81
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f1e2028e7ebceeb2d71ff366150a37564595e614
Original-Change-Id: I005506add4e8fcdb74db6d5e6cb2d4cb1bd3cda5
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/213370
Reviewed-on: http://review.coreboot.org/9283
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Instead of sprinkling the cbfs calls around (as well as getting
return values incorrect) use the common run_romstage() to perform
the necessary work to load and run romstage.
Change-Id: Id59f47febf5122cb3ee60f9741cfb58cb60ccab5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8711
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Currently, the rmodules inclusion for vboot is dependent on ramstage_arch.
This change adds dependency on romstage_arch, since vboot is associated with
romstage. Inclusion based on ramstage_arch is left as is in case someone needs
it in ramstage.
BUG=chrome-os-partner:30784
BRANCH=None
TEST=Compiles successfully for link, rush and nyan
Original-Change-Id: Ib62415671c26a4a18c7133d98e8c683414def32b
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/209568
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 00da67cc02c81d7a6160f7336b33bf53b00e1875)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I9df02134af4e396c7257a2db2e2c371cfd1a02bc
Reviewed-on: http://review.coreboot.org/8673
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Provide functionality to create dynamic classes based on program name and the
architecture for which the program needs to be compiled/linked. define_class
takes program_name and arch as its arguments and adds the program_name to
classes-y to create dynamic class and compiler toolset is created for the
specified arch. All the files for this program can then be added to
program_name-y += .. Ensure that define_class is called before any files are
added to the class. Check subdirs-y for order of directory inclusion.
One such example of dynamic class is rmodules. Multiple rmodules can be used
which need to be compiled for different architectures. With dynamic classes,
this is possible.
BUG=chrome-os-partner:30784
BRANCH=None
TEST=Compiles successfully for nyan, rush and link.
Original-Change-Id: I3e3aadbe723d432b9b3500c44bcff578c98f5643
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/209379
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 242bb90d7476c2ee47d60c50ee18785edeb1a295)
Some of this cherry-pick had already been committed here:
commit 133096b6dc
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I9f5868d704c4b3251ca6f54afa634588108a788c
Reviewed-on: http://review.coreboot.org/8672
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch has a basic structure of vboot2 integration. It supports only Nyans,
which have bootblock architecture and romstage architecture are
compatible from linker's perspective.
TEST=Built with VBOOT2_VERIFY_FIRMWARE on/off. Booted Nyan Blaze.
BUG=None
BRANCH=none
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: I4bbd4d0452604943b376bef20ea8a258820810aa
Original-Reviewed-on: https://chromium-review.googlesource.com/204522
Original-Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Original-Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
(cherry picked from commit a6bce0cbed34def60386f3d9aece59e739740c58)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I63ddfbf463c8a83120828ec8ab994f8146f90001
Reviewed-on: http://review.coreboot.org/8160
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
This reverts the revert commit 5780d6f387
and fixes the build issue that cuased it to be reverted.
Verstage will host vboot2 for firmware verification.
It's a stage in the sense that it has its own set of toolchains,
compiler flags,
and includes. This allows us to easily add object files as needed. But
it's directly linked to bootblock. This allows us to avoid code
duplication for stage loading and jumping (e.g. cbfs driver) for the
boards
where bootblock has to run in a different architecture (e.g. Tegra124).
To avoid name space conflict, verstage symbols are prefixed with
verstage_.
TEST=Built with VBOOT2_VERIFY_FIRMWARE on/off. Booted Nyan Blaze.
BUG=None
BRANCH=none
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: Iad57741157ec70426c676e46c5855e6797ac1dac
Original-Reviewed-on: https://chromium-review.googlesource.com/204376
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit 27940f891678dae975b68f2fc729ad7348192af3)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I2a83b87c29d98d97ae316091cf3ed7b024e21daf
Reviewed-on: http://review.coreboot.org/8224
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This reverts commit 320647abda, because it
introduced the following regression.
$ LANG=C make V=1
Warning: no suitable GCC for arm.
Warning: no suitable GCC for aarch64.
Warning: no suitable GCC for riscv.
/bin/sh: --: invalid option
Usage: /bin/sh [GNU long option] [option] ...
/bin/sh [GNU long option] [option] script-file ...
GNU long options:
--debug
--debugger
--dump-po-strings
--dump-strings
--help
--init-file
--login
--noediting
--noprofile
--norc
--posix
--rcfile
--restricted
--verbose
--version
Shell options:
-ilrsD or -c command or -O shopt_option (invocation only)
-abefhkmnptuvxBCHP or -o option
make: -print-libgcc-file-name: Command not found
It also introduced trailing whitespace.
Change-Id: I50ec00a38e24c854fa926357cd24f9286bf4f66f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/8223
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Verstage will host vboot2 for firmware verification.
It's a stage in the sense that it has its own set of toolchains, compiler flags,
and includes. This allows us to easily add object files as needed. But
it's directly linked to bootblock. This allows us to avoid code
duplication for stage loading and jumping (e.g. cbfs driver) for the boards
where bootblock has to run in a different architecture (e.g. Tegra124).
To avoid name space conflict, verstage symbols are prefixed with verstage_.
TEST=Built with VBOOT2_VERIFY_FIRMWARE on/off. Booted Nyan Blaze.
BUG=None
BRANCH=none
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: Iad57741157ec70426c676e46c5855e6797ac1dac
Original-Reviewed-on: https://chromium-review.googlesource.com/204376
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit 27940f891678dae975b68f2fc729ad7348192af3)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I42b2b3854a24ef6cda2316eb741ca379f41516e0
Reviewed-on: http://review.coreboot.org/8159
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Cherry-pick from chromium and adjusted for added boards
and changed directory layout for arch/arm.
Timestamp implementation for ARMv7
Abstract the use of rdtsc() and make the timestamps
uint64_t in the generic code.
The ARM implementation uses the monotonic timer.
Original-Signed-off-by: Stefan Reinauer <reinauer@google.com>
BRANCH=none
BUG=chrome-os-partner:18637
TEST=See cbmem print timestamps
Original-Change-Id: Id377ba570094c44e6895ae75f8d6578c8865ea62
Original-Reviewed-on: https://gerrit.chromium.org/gerrit/63793
(cherry-picked from commit cc1a75e059020a39146e25b9198b0d58aa03924c)
Change-Id: Ic51fb78ddd05ba81906d9c3b35043fa14fbbed75
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8020
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Add XN/PXN bits to prevent cpu from fetching speculative instructions
on noncacheable region.
BUG=chrome-os-partner:28568
BRANCH=nyan
TEST=Build and run reboot tests on nyan_big
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Change-Id: I0cd2ad5a47a467ef609d30d42cd300b5ca45b77b
Original-Reviewed-on: https://chromium-review.googlesource.com/203447
Original-Tested-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Commit-Queue: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit c3d585bdfcbe9330e5c6f51d1fcf45aec9f26755)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Icf552e2f1ba20255915b24b4f96a179a2e7d08fe
Reviewed-on: http://review.coreboot.org/8043
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
ARM processors save the PC value in the Link Register when they handle
and exception, but they store it with an added offset (depending on the
exception type). In order to make crashes easier to read and correctly
support more complicated handlers in libpayload, this patch adjusts the
saved PC value on exception entry to correct for that offset.
(Note: The value that we now store is what ARM calls the "preferred
return address". For most exceptions this is the faulting instruction,
but for software interrupts (SWI) it is the instruction after that. This
is the way most programs like GDB expect the stored PC address to work,
so let's leave it at that.)
Numbers taken from the Architecture Reference Manual at the end of
section B1.8.3.
BRANCH=none
BUG=chrome-os-partner:18390
TEST=Provoked a data abort and an undefined instruction in both coreboot
and depthcharge, confirmed that the PC address was spot on.
Original-Change-Id: Ia958a7edfcd4aa5e04c20148140a6148586935ba
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/199844
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Original-Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
(cherry picked from commit 4a914d36bb181d090f75b1414158846d40dc9bac)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ib63ca973d5f037a879b4d4d258a4983160b67dd6
Reviewed-on: http://review.coreboot.org/7992
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The following patches had to be squashed
to properly build all the different ARM boards.
ipq8064: storm: re-arrange bootblock initialization
The recent addition of the storm bootblock initialization broke
compilation of Exynos platforms. The SOC specific code needs to be
kept in the respective source files, not in the common CPU code.
As of now coreboot does not provide a separate SOC initialization API.
In general it makes sense to invoke SOC initialization from the board
initialization code, as the board knows what SOC it is running on.
Presently all what's need initialization on 8064 is the timer. This
patch adds the SOC initialization framework for 8064 and moves there
the related code.
BUG=chrome-os-partner:27784
TEST=manual
. nyan_big, peach_pit, and storm targets build fine now.
Original-Change-Id: Iae9a021f8cbf7d009770b02d798147a3e08420e8
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/197835
(cherry picked from commit 3ea7307b531b1a78c692e4f71a0d81b32108ebf0)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
arm: Redesign mainboard and SoC hooks for bootblock
This patch makes some slight changes to the way bootblock_cpu_init() and
bootblock_mainboard_init() are used on ARM. Experience has shown that
nearly every board needs either one or both of these hooks, so having
explicit Kconfigs for them has become unwieldy. Instead, this patch
implements them as a weak symbol that can be overridden by mainboard/SoC
code, as the more recent arm64_soc_init() is also doing.
Since the whole concept of a single "CPU" on ARM systems has kinda died
out, rename bootblock_cpu_init() to bootblock_soc_init(). (This had
already been done on Storm/ipq806x, which is now adjusted to directly
use the generic hook.) Also add a proper license header to
bootblock_common.h that was somehow missing.
Leaving non-ARM32 architectures out for now, since they are still using
the really old and weird x86 model of directly including a file. These
architectures should also eventually be aligned with the cleaner ARM32
model as they mature.
BRANCH=None
BUG=chrome-os-partner:32123
TEST=Booted on Pinky. Compiled for Storm and confirmed in the
disassembly that bootblock_soc_init() is still compiled in and called
right before the (now no-op) bootblock_mainboard_init().
Original-Change-Id: I57013b99c3af455cc3d7e78f344888d27ffb8d79
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/231940
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 257aaee9e3aeeffe50ed54de7342dd2bc9baae76)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Id055fe60a8caf63a9787138811dc69ac04dfba57
Reviewed-on: http://review.coreboot.org/7879
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
This change introduces LPAE for virtual address translation. To enable it, set
ARM_LPAE. Boot slows down about 4ms on Tegra124 with LPAE enabled.
TEST=Booted nyan with and without LPAE. Built nyan_big and daisy.
BUG=None
BRANCH=none
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@google.com>
Original-Change-Id: I74aa729b6fe6d243f57123dc792302359c661cad
Original-Reviewed-on: https://chromium-review.googlesource.com/187862
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Original-Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
(cherry picked from commit 6d8c8b2bbdc70555076081eb3bfaabde7b4a398f)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I8980375c14758af35f7d5ec5244be963e5462d8a
Reviewed-on: http://review.coreboot.org/7749
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Turns out that when you clear 28 bits starting with bit 3, you leave bit
31 standing. Ooops...
This shouldn't really matter since that bit is reserved/SBZ in CLIDR
anyway, but it's still nice to fix it. This whole thing should really be
an AND for clarity anyway in my opinion.
Bug found in upstream NetBSD (who would've thought...).
BUG=None
TEST=Still boots.
Change-Id: Ic826e82d58fd1ce984971afea3dfa9296f746d9f
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193300
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit d270c0ec18b74b272451c456cbf07e99d95896cb)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/7745
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
In order to build rmodules for armv7 boards, the default
compiler options need to be set so the assembler sources
can correclty compile. For now assume rmodules for arm
devices use the ramstage compiler options.
BUG=chrome-os-partner:27094
BRANCH=None
TEST=Built vboot as rmodule for nyan.
Original-Change-Id: I8d12a2a57944b187cbdff2f22176de5b4de87a54
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/190926
(cherry picked from commit cd091ae8ced30e6e2543f36bdb5c14518e7879c3)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I24706f7d72a53f71abd2770f0d12de8c6ed31f63
Reviewed-on: http://review.coreboot.org/7744
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
There were instances of unneeded arch/hlt.h includes,
various hlt() calls that weren't supposed to exit (but
might have) and various forms of endless loops around
hlt() calls.
All these are sorted out now: unnecessary includes are
dropped, hlt() is uniformly replaced with halt() (except
in assembly, obviously).
Change-Id: I3d38fed6e8d67a28fdeb17be803d8c4b62d383c5
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/7608
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This patch changes the ENTRY() macro in asm.h to create a new section
for every assembler function, thus providing dcache_clean/invalidate_all
and friends with the same --gc-sections goodness that our C functions
have. This requires a few minor changes of moving around data (to make
sure it ends up in the right section) and changing some libgcc functions
(which apparently need to have two names?), but nothing serious.
(You may note that some of our assembly functions have data, sometimes
even writable, within the same .text section. This has been this way
before and I'm not looking to change it for now, although it's not
totally clean. Since we don't enforce read-only sections through paging,
it doesn't really hurt.)
BUG=None
TEST=Nyan and Snow still boot. Confirm dcache_invalidate_all is not
output into any binary anymore since no one actually uses it.
Original-Change-Id: I247b29d6173ba516c8dff59126c93b66f7dc4b8d
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/183891
(cherry picked from commit 4a3f2e45e06cc8592d56c3577f41ff879f10e9cc)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ieaa4f2ea9d81c5b9e2b36a772ff9610bdf6446f9
Reviewed-on: http://review.coreboot.org/7451
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This patch changes several cache-related pieces to be cleaner, faster or
more correct. The largest point is removing the old
arm_invalidate_caches() function and surrounding bootblock code to
initialize SCTLR and replace it with an all-assembly function that takes
care of cache and SCTLR initialization to bring the system to a known
state. It runs without stack and before coreboot makes any write
accesses to be as compatible as possible with whatever state the system
was left in by preceeding code. This also finally fixes the dreaded
icache bug that wasted hundreds of milliseconds during boot.
Old-Change-Id: I7bb4995af8184f6383f8e3b1b870b0662bde8bd4
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183890
(cherry picked from commit 07a35925dc957919bf88dfc90515971a36e81b97)
nyan_big: apply cache-related changes from nyan
This applies the same changes from 07a3592 that were applied to nyan.
Old-Change-Id: Idcbe85436d7a2f65fcd751954012eb5f4bec0b6c
Reviewed-on: https://chromium-review.googlesource.com/184551
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 4af27f02614da41c611aee2c6d175b1b948428ea)
Squashed the followup patch for nyan_big into the original patch.
Change-Id: Id14aef7846355ea2da496e55da227b635aca409e
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
(cherry picked from commit 4cbf25f8eca3a12bbfec5b015953c0fc2b69c877)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/6993
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch switches every last part of Coreboot on ARM over to Thumb
mode: libpayload, the internal libgcc, and assorted assembly files. In
combination with the respective depthcharge patch, this will switch to
Thumb mode right after the entry point of the bootblock and not switch
back to ARM until the final assembly stub that jumps to the kernel.
The required changes to make this work include some new headers and
Makefile flags to handle assembly files (using the unified syntax and
the same helper macros as Linux), modifying our custom-written libgcc
code for 64-bit division to support Thumb (removing some stale old files
that were never really used for clarity), and flipping the general
CFLAGS to Thumb (some more cleanup there as well while I'm at it).
BUG=None
TEST=Snow and Nyan still boot.
Original-Change-Id: I80c04281e3adbf74f9f477486a96b9fafeb455b3
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/182212
Original-Reviewed-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 5f65c17cbfae165a95354146ae79e06c512c2c5a)
Conflicts:
payloads/libpayload/include/arm/arch/asm.h
src/arch/arm/Makefile.inc
src/arch/arm/armv7/Makefile.inc
*** There is an issue with what to do with ramstage-S-ccopts, and
*** will need to be covered in additional ARM cleanup patches.
Change-Id: I80c04281e3adbf74f9f477486a96b9fafeb455b3
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/6930
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The ccopts mechanism is needed for passing ARM assembler flags to GCC.
There are many gotchas in adding ASFLAGS. As things have moved
around, the revert doesn't remove cleanly, so this reverts and cleans
up the ccopts.
This reverts commit 25b56c3af5.
Change-Id: I44c025535258e6afb05a814123c10c24775a88e8
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/7352
Tested-by: build bot (Jenkins)
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch fixes the remaining few bugs in our shiny new cache iteration
by set/way/level algorithm to actually make it work: It makes it start
from cache level 0 (previously it would always start at LoC and be
"done" instantly), fixes up the two shifts that isolate the set bits at
the end (which didn't seem to account for the fact that the first shift
affects the second), and throws an S bit on that last shift so that it
actually affects the conditionals after it.
In addition, also moves the next_level block to the top so that we can
share (and thus eliminate) some code at initialization, and turns the
whole thing into a thrice-instantiated macro to create functions that
fit our existing interface.
Change-Id: I1338a589cbb37d74ea6e7a3d4f67ff827e24edbe
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183879
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 6d94f8330191c316fe093ddb5288329453da8a4b)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6932
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This patch pulls in NetBSD's full cache flushing algorithm for ARM, to
replace our old, slow and slightly overzealous C-only implementation.
It's a beautiful piece of code that manages to run on only caller-saved
registers (meaning it doesn't need to write to memory) in a very tight
loop, and it's BSD-licensed to boot (which we need for libpayload).
Unfortunately it's also not quite correct, but I can fix that. Pulling
the original in a separate commit to make it more obvious what changes
are mine.
Change-Id: I7a71c9e570866a6e25f756cb09ae2b6445048d83
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183878
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 4698467320613d7ddc39714f40aacbc990af9399)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6931
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
libgcc/macros.h contains some useful assembly macros that are common in
Linux kernel code and facilitate things such as unified ARM/THUMB
assembly. This patch moves it to a more general place where it can be
used by other code as well.
Change-Id: If68e8930aaafa706c54cf9a156fac826b31bb193
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182178
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
(cherry picked from commit a780670def94a969829811fa8cf257f12b88f085)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6917
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This patch adds stub implementations of exception_init() to all archs
so that it can be called from src/lib/hardwaremain.c. It also moves/adds
all other invocations of exception_init() (which needs to be rerun in
every stage) close to console_init(), in the hopes that it will be less
likely overlooked when creating future boards. Also added (an
ineffective) one to the armv4 bootblock implementations for consistency
and in case we want to implement it later.
Change-Id: Iecad10172d25f6c1fc54b0fec8165d7ef60e3414
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176764
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 2960623f4a59d841a13793ee906db8d1b1c16c5d)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6884
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
"Hey guys, I have this awesome idea! How about we put a huge array
filled with 0xa5 into the data segment of our uncompressed romstage
for no particular reason? Give our SPI driver something to do so it
doesn't get too bored, you know?"
Guess it pays off to just hexdump our image and sanity-check it top to
bottom every once in a while...
Also reduces the size because 8K is crazy just to print a bunch of
registers (256 bytes ought to be enough for anybody).
Old-Change-Id: Icec0a711a1b5140d2ebcd98338ec638a4b6262fa
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176762
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 61c360a1c3f445535c9ff383a389e643cfe4527c)
arm: Remove exception_test()
The exception_test() mechanism might have been useful when exceptions
were first implemented, but now that they are pretty stable it's really
not necessary anymore (especially not on every single boot in production
Chromebooks). It forces a simple unaligned access, and as we start
having exceptions in stages that might not have paging turned on yet,
it's better to remove that completely.
Also removed the duplicated implementations of SCTLR-stuff and switched
to the existing ones in cache.h.
Old-Change-Id: I85e66269f5e2f2dfd3e8aaaa18441493514b62f8
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/177101
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit d0706b848572fbea26e0e432ec5827503b9603c9)
Squashed 2 exception related commits.
Change-Id: Id2c115ee39a0732c375472afc0194436e2f5e069
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6885
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Julius Werner