Since CCLK_BURST_POLICY and SUPER_CCLK_DIVIDER are not accesible
from AVP, the first place that can change CPU clock is after CPU
has been brought up, ie, ramstage in this case.
CPU initial clock source is set to PLLP by MTS.
BUG=None
TEST=Norrin64 and A44
Change-Id: I525bb2fa2be0afba52837bc0178950541535fd22
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/209698
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.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
Change-Id: Ib62415671c26a4a18c7133d98e8c683414def32b
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/209568
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.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.
Change-Id: I3e3aadbe723d432b9b3500c44bcff578c98f5643
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/209379
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Implement the necesary logic for running vboot
verification on ramstage. The logic just handles
the fallback path of loading from cbfs.
BUG=chrome-os-partner:30784
BRANCH=None
TEST=Built for rush.
Change-Id: I7b4fa0438efbdb0af7420e1a8b87f4fa4a86c0ee
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209571
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
The vboot module previously assumed the CPU running the
verfication would also be the one executing the next
stage of execution. That isn't true for all platforms.
Therefore, provide the ability to load and return the
entry point by way of vboot_verify_firmware_get_entry().
vboot_verify_firmware() still does the same thing as
it previously did -- load and run from the current
execution context.
BUG=chrome-os-partner:30784
BRANCH=None
TEST=Built for nyan.
Change-Id: Id06c3d382edfe84adb170e7f52c12be58b88bab9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209592
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
The arm architectures have a stage_exit() function
which takes a void * pointer as an entry point. Provide
the same API for x86. This can make the booting paths
less architecture-specific.
BUG=chrome-os-partner:30784
TEST=built for nyan.
Change-Id: I4ecfbf32f38f2e3817381b63e1f97e92654c5f97
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5086
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: https://chromium-review.googlesource.com/209591
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
The serial driver hangs in cases when FIFO has more than single word to be
processed. Easiest way to reproduce is to paste a string of greater than 4
characters in cli.
Clearing the RXSTALE interrupt without draining all the characters from FIFO
leads to the issue as the driver is dependent on msm_boot_uart_dm_read
function to reinitialize for next transfer.
Logically the driver is organized in such a manner that next transfer never
gets initiated till rx_data_read < total_rx_data. Clearing the RXSTALE without
consideration of total number of characters (or words) unprocessed makes the
msm_boot_uart_dm_read to return on the first if conditional. Thus the driver is
stuck forever.
A quick fix is to avoid clearing the stale interrupt. Reset is handled whenever
a new transfer is initialized in msm_boot_uart_dm_init_rx_transfer.
BUG=chrome-os-partner:29542
TEST=manual
-Paste a string greater than 4 characters in cli.
Change-Id: I016afb01a77cd14764f0176f6bf144fb29796c2f
Signed-off-by: Yogesh Lal <ylal@codeaurora.org>
Reviewed-on: https://chromium-review.googlesource.com/209512
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
There is no point in duplicating boardid.h per board - they are all
the same. Let's keep a single instance in the common include directory
and let the linker report a problem if one tries using this function
on a board where it is not supported.
BUG=chrome-os-partner:30489
TEST=verified that coreboot builds fine for nyan_big and nyan_blaze.
Change-Id: Ifbe9c2287a1d828d4db74c637d1d02047ac4da25
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209699
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Get rid of Kconfig warning "warning: defaults for choice values not supported"
BUG=None
BRANCH=None
TEST=Compiles successfully and boots rush till last known good point
Change-Id: Ib2667eacdb4f4e4d2ac8005078c5c1f644d0325c
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/209556
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
vboot_handoff field includes information used by verified boot in
depthcharge, let's make sure it is available on storm.
BUG=chrome-os-partner:30705
TEST=tested along with accompanying depthcharge patches, observed
proper verified mode boot
Change-Id: I38f360cd5e336c74eee7ee054e67a4b5dc3d5d44
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208840
Reviewed-by: Stefan Reinauer <reinauer@google.com>
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>
