Stop running AVP at the end of romstage until event conditions are met (JTAG,
GIC_IRQ or LIC_IRQ).
BUG=chrome-os-partner:30831
BRANCH=None
TEST=Compiles successfully and boots till last known good checkpoint.
Change-Id: Ia221f08b27ac0c60a66d588e351677144cc6a322
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/209424
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
The ROMSTAGE_ELF variable is assigned based upon the architecture the
romstage is being built for. x86 uses a unique value but arm & arm64
both use the same value which MIPS will also share. Remove the
duplication of the assignment by special casing x86 only.
Change-Id: Id4307c30d91fde8dc48f89b2eb6f5b16b45e0c67
Suggested-by: Vadim Bendebury <vbendeb@google.com>
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-on: https://chromium-review.googlesource.com/208932
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Specify a CBFS architecture value for MIPS & allow cbfstool to make
use of it.
Change-Id: I604d61004596b65c9903d444e030241f712202bd
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-on: https://chromium-review.googlesource.com/207971
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This patch introduces support for building a MIPS cross compiler
targetting little endian machines by default.
Change-Id: I116f6f431cdf80f5f5f58d2743357a9f70a7347d
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-on: https://chromium-review.googlesource.com/207970
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Most things still needs to be filled in, but this will allow us to build boards which use this SOC.
BUG=chrome-os-partner:29778
TEST=emerge-veyron coreboot
Change-Id: If643d620c5fb8951faaf1ccde400a8e9ed7db3bc
Signed-off-by: jinkun.hong <jinkun.hong@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/205069
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
This code ports antirollback module and tpm library from platform/vboot_reference.
names are modified to conform to Coreboot's style.
The rollback_index module is split in a bottom half and top half. The top half
contains generic code which hides the underlying storage implementation
the bottom half implements the storage abstraction.
With this change, the bottom half is moved to coreboot, while the top half stays
in vboot_reference.
TEST=Built with USE=+/-vboot2 for Blaze. Built Samus, Link.
BUG=none
Branch=none
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: I77e3ae1a029e09d3cdefe8fd297a3b432bbb9e9e
Reviewed-on: https://chromium-review.googlesource.com/206065
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
The SPI controller operates on packets which can be variable
length up to 32-bit packets. It also has the ability to be
put in packed or unpacked mode w.r.t each packet. i.e. does
a single fifo register hold >= 1 packet. The current programming
uses 8-bit packets in unpacked mode which means 4 fifo slots
are used for a 32-bit DMA transfter. As the AHB can only operate
on a minimum of 32-bit bursts the triggers need to be programmed
correctly so that there is room for a full 32-bit DMA transaction.
Previously faster SPI clocks just made things magically work.
BUG=chrome-os-partner:30779
BRANCH=None
TEST=Built and booted through coreboot with 20MHz SPI clock.
Change-Id: I3f1cd4dddcea9514327b2363ed450a527db7e1fe
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208862
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
The Trust Zone carveout registers are only accessible using
a secure access mode. The AVP runs as non-secure all the time.
In EL3 the CPU is in secure mode, but when the MMU is enabled
the page tables dictate if accesses to certain regions are
secure or not. However, ramstage is currently being loaded
into non-secure memory and the page tables will live in
non-secure memory as well. Therefore, handle all these
cases by providing global state which mirrors the TZ
register.
BUG=chrome-os-partner:30782
BRANCH=None
TEST=Built and ran through ramstage with the MMU enabled
Resources are read and set accordingly.
Change-Id: Ib76b2641497a29ef2adb75934b2df55ecf0b3e78
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209061
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Looks like we got our first SoC that actually insists on using
word-sized accesses for its MMIO registers with the Rk3288. This patch
changes the GDB command handler for reading and writing memory to always
perform word-sized accesses. This isn't really perfect since the remote
GDB interface is just not really meant to interact with MMIO (e.g. you
shouldn't use this on something with read side effects), but for most
of our purposes it should be good enough.
BUG=chrome-os-partner:18390
TEST=Remote GDB works on Veyron even when writing MMIO registers.
Change-Id: I2ae52636593499f70701582811f1b692c1ea8fcc
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208554
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Add support for mmu initialization and enabling caches. mmu_operations provides
functions to add mmap_regions using memrange library and then calls mmu_init for
armv8.
BUG=chrome-os-partner:30688
BRANCH=None
TEST=Compiles rush successfully and boots until depthcharge load. Goes past
all the earlier alignment errors.
Change-Id: I57c2be80427fa77239093c79ece73e31fd319239
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/208762
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
1) Add check for zero size in memrange.
2) Add public memrange_init_empty function to allow initializing only the
memrange structure without filling in device resources
BUG=None
BRANCH=None
TEST=Compiles and runs succesfully for rush MMU memranges.
Change-Id: I8e4d864cbc9a770cd208f8a9f83f509dc7ace894
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/208957
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Add support for initializing and enabling mmu for armv8. Using 64KiB granule and
33 bits per VA, thus total VA address space is 6GiB. PA Range is 64GiB. Makes
use of memrange library to get a list of all the mmap regions from the SoC to
initialize XLAT table.
Currently, all calculations in mmu.h are based on the assumptions that max 33
bits are used in VA and granule size is 64KiB. Changes in these assumptions will
have to reflect in the dependent calculations as well.
BUG=chrome-os-partner:30688
BRANCH=None
TEST=Compiles rush successfully and boots until "payload not found". Goes past
all the earlier alignment errors.
Change-Id: Iac1df15f0b81dcf64484a56b94f51357bcd67cc2
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/208761
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
This must be committed at the same time as the corresponding
depthcharge change which updates the fmap.
BUG=chrome-os-partner:30079
BRANCH=none
TEST=Build samus firmware.
dump_fmap -h /build/samus/firmware/image.bin shows PD_MAIN_A and
PD_MAIN_B sections.
Boot samus. 'crossystem mainfw_act' -> A
As root, 'crossystem fwb_tries=1'
Reboot samus. 'crossystem mainfw_act' -> B
CQ-DEPEND=CL:208984,CL:*169850,CL:208989
Change-Id: Ibccec8b82ba22c61248a79023f42b92e4763403e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208899
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Due to some projects don't have the correct settings in devicetree.cb
so put this change in case those projects without are setting in devicetree.cb
BUG=chrome-os-partner:30690
BRANCH=none
TEST=emerge-rambi coreboot without problem
checked the USBPHY_COMPBG is configured properly
even there is no setting in devicetree
Change-Id: Iaf8155497c41f10c81d1faa7bb0e3452a7cedcc6
Signed-off-by: Kane Chen <kane.chen@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/209051
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Other default slams should be added later to the init table
once we know what the kernel touches. But for now, only VDD_CPU
is needed.
Also slipped in a minor name change in mainboard.c
BRANCH=none
BUG=none
TEST=none, no HW here for me to test on yet
Change-Id: Ifbe86192449ed0466085808a0a12a15a7b6a1795
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/208385
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
setbits_le32() is not really arch-specific... the arch-specific part of
accessing memory is wrapped by readl() and writel(), and the endianness
can be accounted for with the right macros. Generalize the definitions,
add a be32 version and move them to endian.h so that all platforms can
use them. Also include endian.h from libpayload.h so we won't update any
payload's old use of the macros (endianness is something useful enough
to always have avalable anyway, and shouldn't clash with other things).
This also fixes a bug where these macros would only be available if
libpayload-config.h had been independently included before.
Also fix a bug with readl() macros on all archs where they refused to
work on const pointers (which they should).
CQ-DEPEND=CL:208712
BUG=None
TEST=Stuff still compiles. Built and booted on Storm.
Change-Id: I01a7fbadbb5d740675657d95c1e969027562ba8c
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208713
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
With this memory resource, the payload loading code should be
able to create a bounce buffer and load the payload successfully.
Adapted from tegra124 soc.c
BUG=None
BRANCH=None
TEST=Built and booted to ramstage on rush.
Change-Id: I2e336ce93c1b0236104e63d3785f0e3d7d76bb01
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/208121
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
USBPHY_COMPBG needs to be configured by project
BUG=chrome-os-partner:30690
BRANCH=none
TEST=emerge-rambi coreboot without problem
checked the USBPHY_COMPBG is configured properly
CQ-DEPEND=CL:208557
Change-Id: I8f2714644e1ef5d790d7ef1f574ebb998abbdac6
Signed-off-by: Kane Chen <kane.chen@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/208731
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Once LPDDR3 init is supported in the ryu romstage, this can
be reverted. Note that this 528MHz BCT has been pre-qualed
by NVIDIA AE's, but will be updated as more tuning is done.
BUG=none
BRANCH=none
TEST=Builds, BCT is in binary, but I have no HW here to test on
Change-Id: I315a9a5d56290bb5f51863b15053d2171db7b1e4
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/208384
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
The CCSIDR_EL1 register has cache attribute information
for a given cache selection in CSSELR_EL1. However, the
cache isn't being selected before reading CCSIDR_EL1.
Instead use CTR_EL0 which better fits with the semantics
of dcache_line_bytes(). CTR_EL0 has the minimum data cache
line size of all caches in the system encoded in 19:16 encoded
as lg(line size in words).
BUG=None
TEST=Built.
Change-Id: I2cbf888a93031736e668918de928c3a99c26bedd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208720
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
USBPHY_COMPBG needs to be configured by project
BUG=chrome-os-partner:30690
BRANCH=none
TEST=emerge-rambi coreboot without problem
checked the USBPHY_COMPBG is configured properly
Change-Id: I05eee384d94cf5deeec14418bd78816df0b26a92
Signed-off-by: Kane Chen <kane.chen@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/208557
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
config.veyron was written by hand and had some minor mismatches (entries
in a different order than Config.in, negative entries for some options
that no longer exist, etc.). Most importantly, it was missing the
negative entry for CONFIG_LP_REMOTEGDB, which is required to make our
ebuilds build a correct image.dev.bin with GDB support.
Ran it through make oldconfig once so that everything is in the right
place again.
BUG=None
TEST=Remote GDB on Veyron works (woohoo!)
Change-Id: Ic5ebe25fe8ef1b63031569a178c5419ca7e31754
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208255
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This patch removes a chunk of romstage code from Tegra and all Nyan
boards that was supposed to enable some LCD power rails early, but never
really worked. The dev_find_slot() function can only find PCI devices,
which the CPU cluster is not. Since we're done with Nyan-RO and the
ramstage display code is fine as it is, there is no point in trying to
fix this... but we should remove it from ToT lest someone uses it as a
blueprint to add more dead code to future boards.
BRANCH=None
BUG=None
TEST=None
Change-Id: I6eee256873299429d4e3934fe7d454120390f34d
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207720
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Whatever this variable was intended for, it doesn't appear to have
any purpose now.
BUG=none
BRANCH=none
TEST=buildgcc -p armv7a-eabi still works
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I618c6c05c95face6c902e626a3574700bea12153
Reviewed-on: https://chromium-review.googlesource.com/208145
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The address map code was originally assuming all carveouts would
be packed together in the upper end of the physical memory
address space. However, the trust zone carveout is always in the
32-bit address space. Therefore, one needs to query memory ranges
by above and below 4GiB with the assumption of carveouts being
packed at the top of *each* resulting range.
BUG=chrome-os-partner:30572
BRANCH=None
TEST=Built and ran through coreboot on rush.
Change-Id: Iab134a049f3726f1ec41fc6626b1a6683d9f5362
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208101
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
The default CBFS size configuration setting is incorrect in case of
Qualcomm SOC targets, as the coreboot blob is much smaller than the
actual bootprom. Note that this size also must match the board fmap
defined in the appropriate depthcharge board directory.
BUG=chromium:394068
TEST=manual
. previously failing to boot coreboot image does not fail to load
depthcharge anymore.
Change-Id: I1b178970b1deee05705490542e4a0c57500379dd
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208146
Reviewed-by: David Hendricks <dhendrix@chromium.org>
When coreboot is being built, the terminal output is littered with the
following messages:
/bin/sh: -print-libgcc-file-name: command not found
/bin/sh: -print-libgcc-file-name: command not found
/bin/sh: -print-libgcc-file-name: command not found
/bin/sh: -print-libgcc-file-name: command not found
They do not prevent the build from succeeding, but are nevertheless
annoying. This patch makes sure that there is no attempt to determine
libgcc file name for nonexisting compilers.
BUG=none
TEST=The build for lumpy and storm still succeeds, but there is no
spurious error messages generated any more
Change-Id: Iac12e57edc8b605caf8d35287e78e2ad496b264e
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208190
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This is a minor tweak to make the console output cleaner
and more consistent with all the reporting of platform data.
BUG=chrome-os-partner:30586
BRANCH=None
TEST=build and boot on samus
Change-Id: Iea7b48f14795bd6061615a68ca25ff52f84abc5a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208213
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In order to ensure that we meet timing requirements for the SSD
power sequencing delay bringing the SSD out of reset until after
memory training.
BUG=chrome-os-partner:29914
BRANCH=None
TEST=build and boot on samus
Change-Id: I807e3d3698255287c3fe7219f44e8ec9a0985df1
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208155
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
- disable_self_refresh: parameter to disable memory self refresh
during training. This can be used to work around power issues
seen with lpddr3.
- disable_saved_data: parameter to disable the use of the cached
MRC data. This can be used to work around lpddr3 training replay
issues.
BUG=chrome-os-partner:29787,chrome-os-partner:29117
BRANCH=None
CQ-DEPEND=CL:*169275
TEST=build and boot on samus
Change-Id: I051bfbfa0d171ad9b2503cb9a30990b13b4c0cb2
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208153
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
- Turn on keyboard backlight early in boot (not resume) path
as a sign of life for the system
- Add ACPI device for keyboard backlight so the kernel can find
and make use of it
BUG=chrome-os-partner:30586
BRANCH=None
TEST=build and boot on samus
Change-Id: Iecaef0ec5c814774e19d7c4a14cb92dc236cfee3
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208152
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change will read the chipset power state data earlier in boot
and then store a pointer to the data in romstage params for use in
other phases of romstage.
BUG=chrome-os-partner:30586
BRANCH=None
TEST=build and boot on samus
Change-Id: I5fd193b56f34fa3cfe3ad2eb8b915737e6807af4
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208151
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Provide a default Trust Zone region size of 1MiB, and
correctly account for it in the AVP and the arm64 cores.
The different paths between the arm64 cores and the AVP
is because the AVP cannot access the Trust Zone region
registers. Therefore the AVP needs to account for the
Trust Zone region.
BUG=chrome-os-partner:30572
BRANCH=None
TEST=Built and ran. Noted Trust Zone region being accounted for.
Change-Id: Ie0f117ec7a5ff8519c39778d3cdf88c3eee57ea5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208062
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Some of the SoC's need an early hook to configure
certain registers. One example of this is on t132
where ramstage is the first thing being ran on the
arm64 core and it is the only entity that can configure
certain registers required for the rest of ramstage.
Therefore, provide the opportunity for the SoC to
implement such requirements.
BUG=chrome-os-partner:30572
BRANCH=None
TEST=Built and ran through coreboot.
Change-Id: Ib352f3788872f888581b398c9b394b7c4e54b02a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208061
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
In order to make sharing of the location of MTS microcode easier
provide a Kconfig option that is the path to the files.
BUG=chrome-os-partner:30569
BRANCH=None
TEST=Built rush coreboot.
Change-Id: I36775d0018fc8591d5e77c2943e28a51381713f5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207839
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
This is a clone of rush for the time being. All the incompatible
bits can be moved later.
BUG=chrome-os-partner:30569
BRANCH=None
TEST=Built coreboot for rush_ryu board
Change-Id: Iae56d016d0c328d83242b95f307fefaa8c68deec
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207838
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
The TrustZone carveout needs to be taken into account when
determining the memory layout. However, things are complicated
by the fact that TZ carveout registers are not accessible by
the AVP.
BUG=chrome-os-partner:30572
BRANCH=None
TEST=Built and booted to end of ramstage. Noted that denver cores
can read TZ registers while AVP doesn't bother.
Change-Id: I2d2d27e33a334bf639af52260b99d8363906c646
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207835
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Tom Warren <twarren@nvidia.com>
Since RES1 and RES0 bits are marked as SBOP(Should-Be-One-or-Preserved) and
SBZP(Should-Be-Zero-or-Preserved) respectively, resetting the SCTLR and SCR
registers should be done with proper bitmask.
BUG=None
BRANCH=None
TEST=Compiles successfully and verified that the RES bits are preserved across
register writes.
Change-Id: I5094ba7e51e8ea6f7d7612ba4d11b10dcbdb1607
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/207815
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
The carveout regions need to be taken into account when
calculating addressable memory because those regions aren't
accesible from the main cpu. The additional exposed functions
are to accommodate adding resources during ramstage resource
reading. The TZ (trust zone) region is empty for now until
more documentation is provided on determining its location.
BUG=None
TEST=Built and booted through attempting payload loading.
MTS carveout is taken into account programatically.
Change-Id: I3301b2a12680ad79047198ada41f32eb1b7fa68b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207585
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
With BOARD_VARIANT_AP148 configuration option enabled the image will
be built for 512MB DRAM instead of 1024MB and the
mainboard_part_number field in the lb_mainboard entry will be set to
"AP148" instead of "Storm".
BUG=chrome-os-partner:30440
TEST=manual
. built and booted both AP148 and proto0 all the way to reading the
kernel
. verified that the config file includes correct part number and
memory size
. verified proper machine IDs reportted when starting the kernel
Change-Id: Ie609544a460fc991e66e8b95e8d7a3ed5e845f7b
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207427
Reviewed-by: Trevor Bourget <tbourget@codeaurora.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
