| Age | Commit message (Collapse) | Author |
|---|
|
When <symbols.h> was first introduced, it only declared a handful of
regions and we didn't expect that too many architectures and platforms
would need to add their own later. However, our amount of platforms has
greatly expanded since, and with them the need for more special memory
regions. The amount of code duplication is starting to get unsightly,
and platforms keep defining their own <soc/symbols.h> files that need
this as well.
This patch adds another macro to cut down the definition boilerplate.
Unfortunately, macros cannot define other macros when they're called, so
referring to region sizes as _name_size doesn't work anymore. This patch
replaces the scheme with REGION_SIZE(name).
Not touching the regions in the x86-specific <arch/symbols.h> yet since
they don't follow the standard _region/_eregion naming scheme. They can
be converted later if desired.
Change-Id: I44727d77d1de75882c72a94f29bd7e2c27741dd8
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/31539
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
In order to have a proper runtime-modifyable page table API (e.g. to
remap DRAM after it was intialized), we need to remove any external
bookkeeping kept in global variables (which do not persist across
stages) from the MMU code. This patch implements this in a similar way
as it has recently been done for ARM32 (marking free table slots with a
special sentinel value in the first PTE that cannot occur as part of a
normal page table).
Since this requires the page table buffer to be known at compile-time,
we have to remove the option of passing it to mmu_init() at runtime
(which I already kinda deprecated before). The existing Tegra chipsets
that still used it are switched to instead define it in memlayout in a
minimally invasive change. This might not be the best way to design this
overall (I think we should probably just throw the tables into SRAM like
on all other platforms), but I don't have a Tegra system to test so I'd
rather keep this change low impact and leave the major redesign for
later.
Also inlined some single-use one-liner functions in mmu.c that I felt
confused things more than they cleared up, and fixed an (apparently
harmless?) issue with forgetting to mask out the XN page attribute bit
when casting a table descriptor to a pointer.
BRANCH=None
BUG=None
TEST=Compiled Ryu and Smaug. Booted Oak.
Change-Id: Iad71f97f5ec4b1fc981dbc8ff1dc88d96c8ee55a
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/12075
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
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>
|
|
BL31 makes an assumption that TZDRAM always starts at its base. This
was not true in our case since coreboot page tables were located
towards the start of TZDRAM. Instead move page tables to the end, thus
satisfying the assumption that BL31 base is the base of TZDRAM as
well.
BUG=chrome-os-partner:42989
BRANCH=None
TEST=Compiles successfully and boots to kernel prompt
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: aabed336da6e9aea426650c5ca5977ccfc83a21b
Original-Change-Id: Ic4d155525dbb4baab95c971f77848e47d5d54dba
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/291020
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-(cherry picked from commit a57127f1655ef311b82c41ce33ffc71db5f9db35)
Original-Reviewed-on: https://chromium-review.googlesource.com/290987
Change-Id: Ie7166fd0301b46eb32f44107f7f782c6d79a278c
Reviewed-on: http://review.coreboot.org/11383
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Address region from 0x0 to 0x00ffffff is used for IROM_LOVEC and
can not be accessed by Bootloader.
Issue found in CL: 283104 is captured by this patch.
BUG=None
BRANCH=None
TEST=Compiles successfully and reboot test does not crash in firmware
Here are memory mapping table before and after this CL for evt2 board:
Before:
Mapping address range [0000000000000000:0000000040000000) as cacheable | read-write | secure | device
Mapping address range [0000000040000000:0000000040040000) as cacheable | read-write | non-secure | normal
Mapping address range [0000000040040000:0000000080000000) as cacheable | read-write | secure | device
Mapping address range [0000000080000000:00000000feb00000) as cacheable | read-write | non-secure | normal
Mapping address range [00000000fec00000:0000000100000000) as cacheable | read-write | secure | normal
Mapping address range [0000000100000000:0000000140000000) as cacheable | read-write | non-secure | normal
After:
Mapping address range [0000000001000000:0000000040000000) as cacheable | read-write | secure | device
Mapping address range [0000000040000000:0000000040040000) as cacheable | read-write | non-secure | normal
Mapping address range [0000000040040000:0000000080000000) as cacheable | read-write | secure | device
Mapping address range [0000000080000000:00000000feb00000) as cacheable | read-write | non-secure | normal
Mapping address range [00000000fec00000:0000000100000000) as cacheable | read-write | secure | normal
Mapping address range [0000000100000000:0000000140000000) as cacheable | read-write | non-secure | normal
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Change-Id: I07d38a8994c37bf945a68fb95a156c13f435ded2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3eee44944c2c83cc3530bfac0d71b86d3265f5b2
Original-Change-Id: I2b827064807ed715625af627db1826c3a01121ec
Original-Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/285260
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11015
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
1. Make TTB_SIZE Kconfig option
2. Add Kconfig option for maximum secure component size
3. Add check in Makefile to ensure that Trustzone area is big enough
to hold TTB and secure components
4. Calculate TZDRAM_BASE depending upon TTB_SIZE and TZ_CARVEOUT_SIZE
BUG=chrome-os-partner:42319
BRANCH=None
Change-Id: I9ceb46ceedc931826657e5a0f6fc2b1886526bf8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a425d4978a467b157ea5d71e600242ebf427b5bb
Original-Change-Id: I152a38830773d85aafab49c92cef945b7c4eb62c
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/284074
Original-Reviewed-by: Varun Wadekar <vwadekar@nvidia.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/10878
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This includes Chrome OS downstream up to Change-Id: Ic89ed54c.
Change-Id: I81853434600390d643160fe57554495b2bfe60ab
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10633
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
