Force 4-byte alignment for .bs_init section to ensure that no padding
data is added to init structures.
BUG=chromium:416651
BRANCH=none
TEST=build firmware with GCC 4.9 and test on Auron and Rambi.
Change-Id: I3f94cd419b5951fdc6e5749576c4df2cc44f8a24
Signed-off-by: Ryan Lin <ryan.lin@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/223116
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Kenji Chen <kenji.chen@intel.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The F0 stepping has the same CPUID as E0 stepping so report
it as either stepping to avoid confusion.
BUG=chrome-os-partner:32359
BRANCH=samus,auron
TEST=build and boot on samus
Change-Id: Ia4955f346ceb9be92e06ecea5b7a8fe2db84cabc
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223097
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Instead of having this in mosys just have coreboot report the
board version in SMBIOS tables.
BUG=chrome-os-partner:32359
BRANCH=samus
TEST=build and boot on samus, check /sys/class/dmi/id/product_version
Change-Id: Ib851d2e79ed721dcbc1c2f2eda6da50cac064cf3
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223096
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
If you try to boot a VBOOT2_VERIFY_FIRMWARE with less than 4K CBFS cache
right now, your system will try and fail to validate the FMAP signature
at (u8 *)0xFFFFFFFF and go into recovery mode. This patch avoids the
memcmp() to potentially invalid memory, and also adds an error message
to cbfs_simple_buffer_map() to make it explicit that we ran out of CBFS
cache space.
BUG=None
TEST=Booted on Veyron_Pinky with reduced CBFS cache, saw the message.
Change-Id: Ic5773b4e0b36dc621513f58fc9bd29c17afbf1b7
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222899
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
It's been a while since SBL blob size was reduced. As CBFS area by
definition includes the bootblock, storm configuration needs to be
updated to address the changes in layout.
Incidentally, it looks like CBFS_SIZE configuration setting is not
used on ARM platforms, this will have to be addressed separately.
BRANCH=storm
BUG=chromium:422501
TEST=storm firmware does not report the failure to find payload anymore
Change-Id: I37abf76a9d8884b3431633f57f64896c3a5fb135
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222898
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
When cbfs debug is enabled, compilation fails because one of the debug
messages is using an non-existing variable.
BRANCH=nonr
BUG=None
TEST=compiling with CONFIG_DEBUG_CBFS enabled does not fail anymore.
Change-Id: Ic83f5e96cdcb5275ec0b7fadbc901e254a1002ca
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222897
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In able to do earlyprintk spew on LP0 resume, the kernel needs to
know the board UART. ODMDATA (in bct/odmdata.cfg) contains this info,
and the kernel looks for it in PMC_SCRATCH20. Fetch the ODMDATA word
from the BCT copy stored in IRAM by the BootROM.
BUG=chrome-os-partner:32015
BRANCH=none
TEST=Built for Rush and Ryu OK. Dumped PMC_SCRATCH20 in TegraShell
on Rush and confirmed value is what's in odmdata.cfg.
Change-Id: I63f33558ee8b00bd6c1e313efcd531e1d5fc67eb
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/222402
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch does some general cleanup in the Rockchip clock code, and
adds some more assertions regarding the PLL VCO and output frequency
ranges. It changes all PLL divisors to use the lowest values that can
still hit the target frequency, since higher NR values lead to higher
jitter and higher NO values increase power draw.
Also change DDR3 frequency code to hardcode the optimal divisors for
certail frequencies. As a little hack we will interpret 666000000 to
actually mean 666666666.6P (and analogous for 533MHz), since that's what
you usually want for memory.
BUG=chrome-os-partner:32139
TEST=Boot on veyron_pinky rev2, check that dpll_is shown as 666666666 in
/sys/kernel/debug/clk/clk_summary.
Change-Id: I4f3c39641955a95c6dfbe9334035eb670b138bf0
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221801
This change re-writes the spi_xfer() function to support full-duplex
transfers.
Even though the code looks much different, the same basic algorithm
for setting up the transfer is used. The main difference is that
reads from rxdr and writes to txdr occur simultaneously and accounting
is more complicated, so I separated the higher-level accounting
portion from the low-level FIFO handling portion to simplify things.
BUG=chrome-os-partner:31850
BRANCH=none
TEST=Loaded content from SPI ROM fine, needs testing w/ EC
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I33d2f5179360baf94627c86b57d12f032897caf5
Reviewed-on: https://chromium-review.googlesource.com/218881
Reviewed-by: Julius Werner <jwerner@chromium.org>
This is important since mmu is disabled during the post_sysinfo_mmu_setup call
and calling printf can cause unaligned access.
BUG=None
BRANCH=None
TEST=Compiles successfully and boots to kernel prompt with console_init
Change-Id: Ie376e394d084edd6c999fc9edde79f15a0264e7b
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/222664
Reviewed-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Provide a function to obtain a new memrange with requested properties (type,
size, alignment, max_addr and other restrictions) from the set of available
memranges passed in coreboot table. One user of this function would be getting
memrange for dma, another one would be framebuffer.
BUG=chrome-os-partner:31634
BRANCH=None
TEST=Compiles successfully and boots to kernel prompt
Change-Id: I187d73a4d55d3c6f49afbe9852901672d25de8dc
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/222110
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Fix the typo of sate to state and add uKernel phase to just
output the current state byte.
BUG=chrome-os-partner:28234
BRANCH=samus,auron
TEST=build and boot on samus
Change-Id: I520a4cc75faffa5feeb6113ffd7b07a48c4e6f28
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222677
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The first 64 bytes of the framebuffer contain garbage after running
the option rom and after calling the VBE mode set with the flag to
clear the framebuffer.
Work around this issue by clearing the first 64 bytes in the framebuffer
in the broadwell graphics setup code after it executes the VBIOS.
BUG=chrome-os-partner:32771
BRANCH=samus,auron
TEST=build and boot on samus in dev mode, check for graphical corruption
Change-Id: I072bc913f7daea16e4861a7549e1b4ec85cde4cd
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222676
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This selects the correct custom vesa mode for Samus which is
added to the VBIOS for bitmaps to be scaled appropriately.
BUG=chrome-os-partner:32643
BRANCH=samus
TEST=build and boot on samus
Change-Id: Id2b3349340e85ab6f29374dff096c39ac0506fc6
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222675
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
BUG=chrome-os-partner:31424
TEST=Build a image and run on Samus proto boards to confirm if the
settings are applied correctly.
Signed-off-by: Kenji Chen <kenji.chen@intel.com>
Change-Id: I8138507506771148420a585fd12897a3bfe91916
Reviewed-on: https://chromium-review.googlesource.com/221387
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
CQ-DEPEND=CL:218766
BUG=none
BRANCH=none
TEST=built and booted on Pinky
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: Icbee95350949bd9bfa4490a8a4b6bbf09beb4170
Reviewed-on: https://chromium-review.googlesource.com/221019
Reviewed-by: Julius Werner <jwerner@chromium.org>
Enable L1 Sub-State when both root port and endpoint support it.
BUG=chrome-os-partner:31424
TEST=Build a image and run on Samus proto boards to check if the
settings are applied correctly. I just only have proto boars and
need someone having EVT boards to confirm the settings.
Signed-off-by: Kenji Chen <kenji.chen@intel.com>
Change-Id: Id1b5a52ff0b896f4531c4a6e68e70a2cea8c736a
Reviewed-on: https://chromium-review.googlesource.com/221436
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
according to schematic, GPIO29 needs to output high to enable M.2
socket power
BUG=none
BRANCH=none
TEST=build ok and see wifi device on M.2 socket working in OS
Change-Id: I7f122541a7bf3a5d7872f37a866ea3f1e52e8b47
Signed-off-by: Kane Chen <kane.chen@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/221927
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
this adds a flash vbnv driver for vboot to store non-volatile data in a flash
storage.
BUG=chrome-os-partner:32774
BRANCH=none
TEST=Built samus, veyron pinky, and cosmos
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: If5fc1b779722528134ad283fa030f150b3bab55f
Reviewed-on: https://chromium-review.googlesource.com/222258
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
There's no need to reserve the framebuffer within corebot. If the
payloads need a framebuffer they can allocate one themselves.
BUG=chrome-os-partner:31355
BRANCH=None
TEST=Built and booted on ryu.
Change-Id: I8d8b159e7fdd877e392193c5474a7518e9b3ad21
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221726
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
If a TD is comprised of one or more Normal TRBs and terminated with an
Event Data TRB, then the transition to the Idle state (and associated
Stream state save) could occur after all the data for the TD has been
moved (e.g. after Transfer Event TRBs have been executed), but before the
Event Data TRB is executed. Under these conditions, the execution of the
Event Data TRB is necessary to complete the TD, otherwise it does not
occur until the nexttime the Stream is scheduled. This could lead to the
lock up.
The Evaluate Next TRB(ENT) flag provides a means of forcing the execution
of a terminating Event Data TRB. Setting ENT flag in last Normal TRB makes
the xHC to evaluate the Even Data TRB.
BUG=chrome-os-partner:29375
TEST=Verified kernel boot-up on storm from previously failing USB stick.
USB stick model: Sandisk Ultra USB 3.0 Pen Drive 32 GB
Strontium Jet USB 3.0 Pen Drive(32 GB)
Change-Id: I4e123577ec5a5996d87d2fc52cb6cf5c571c9fae
Signed-off-by: Sourabh Banerjee <sbanerje@codeaurora.org>
Reviewed-on: https://chromium-review.googlesource.com/220123
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
1. keep functions and objects used entirely within mmu.c as static.
2. DMA region finding needs to terminate. Therefore, the next address
to be attempted needs to be less then the current end address.
3. Ensure mmu_ranges passed to mmu_init_ranges_from_sysinfo() has
0 entries marked as used.
BUG=chrome-os-partner:31634
BRANCH=None
TEST=Booted ryu with RAM hole above cbmem tables below 4GiB.
Change-Id: I5cb4e5009359cb04c4e1b5fe60845f80fbdff02c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221725
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
The default mapping size is 1MiB of ram. However, not
all systems allow 1MiB of memory to mapped depending on
the kernel's memory map. Therefore, be explicit about
the sizes to mmap().
The only path that wasn't cleaned up was the coverage path
as that needs to handle dynamic cbmem. The correct way to
fix that is to add a global like the timestamps that is set
while parsing cbtable.
BUG=chrome-os-partner:31355
BRANCH=None
TEST=Can cbmem -ltc on ryu.
Change-Id: I27b70ae8a8fba168d1c1829bbef0135c7b651eac
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221971
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
In some cases the cbmem console can be larger than the default
mapping size of 1MiB. Therefore, add the ability to do a mapping
that is larger than the default mapping using map_memory_size().
The console printing code will unconditionally map the console based
on the size it finds in the cbmem entry.
Change-Id: I016420576b9523ce81195160ae86ad16952b761c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5440
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: https://chromium-review.googlesource.com/221970
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
DDI-A should not need re-enabled in the resume path, just
the resume path when we did not execute VBIOS.
BUG=chrome-os-partner:28234
BRANCH=samus,auron
TEST=build and boot on samus, test suspend+resume
Change-Id: Iaf7d083c5c92c42b7a117e2d2c9546ada6bf5f76
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221988
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This is the latest available microcode.
BUG=chrome-os-partner:28234
BRANCH=samus,auron
TEST=build and boot on samus
Change-Id: I3fdc93d834a43c97cf6f404f0f465902781ad9e4
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221987
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
With introduction of GDB support the GDB_DEBUG make parameter sounds
misleading. Let's change it to SOURCE_DEBUG. It is still quite useful
when debugging with GDB, but can be used with any debugger.
BUG=None
TEST=built coreboot with SOURCE_DEBUG in the environment, observed it
compiled as expected
Change-Id: Ia6cfddfa1764fb070f4d35f374ed4f35e38d38fe
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221386
Reviewed-by: Julius Werner <jwerner@chromium.org>
This patch adds some simple constants to more easily write and do math
with frequencies, analogous to the existing KiB, MiB and GiB constants
for sizes. They are exemplary added to the Veyron_Pinky/Rk3288 code for
now and will hopefully be adopted by other parts of the codebase in the
future.
BUG=None
TEST=Compiled Veyron_Pinky.
Change-Id: I4a1927fd423eb96d3f76f7e44b451192038b02e0
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221800
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This reverts commit 36960019dc.
Change-Id: Ie347622774bd9343face4890da2f65e8b29f4fb7
Reviewed-on: https://chromium-review.googlesource.com/221944
Reviewed-by: Michael Spang <spang@chromium.org>
Commit-Queue: Michael Spang <spang@chromium.org>
Tested-by: Michael Spang <spang@chromium.org>
Set "CONFIG_LP_USB_EHCI_HOSTPC_ROOT_HUB_TT=y" for nyan-series
platforms to enable USB keyboard when it's connected to root hub.
BUG=chrome-os-partner:32355
TEST=Tested on nyan series platforms.
Press ESC+REFRESH+POWER keys on internal keyboard to power up.
Press Left Arrow or Right Arrow on USB keyboard to switch between
"English" and "Default Locale" in coreboot UI. Or unplug and plug
in device and try again.
Root hub <- low-speed USB keyboard
Root hub <- full-speed hub <- low-speed USB keyboard
Root hub <- high-speed hub <- low-speed USB keyboard
Change-Id: I0c47cdd7018133185b6ffe1a51c62932f1287b34
Signed-off-by: Jim Lin <jilin@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/221035
Reviewed-by: Julius Werner <jwerner@chromium.org>
Provide a weak implemenation of usb_setup_utmip function for those stages that
do not include usb.c.
BUG=chrome-os-partner:32684
BRANCH=None
TEST=Compiles successfully
Change-Id: Ib235cf039a17204ef7e06d545a3c86b75aff5b4c
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/221575
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
This function needs to be available in different LOGLEVELs.
BUG=chrome-os-partner:28234
BRANCH=samus
TEST=USE=quiet-cb emerge-samus coreboot
Change-Id: Ia8f0d05af24c9070c8c9241a3a7e137f845d1cab
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221540
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This is the specific codec setup platform data for samus.
BUG=chrome-os-partner:29649
BRANCH=samus
TEST=emerge-samus coreboot
Change-Id: I5e2a8fad58bb8a3d02ccece0b1f6fe52f56c94ea
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221539
Reviewed-by: Ben Zhang <benzh@chromium.org>
If secure monitor is used, rmodules support should be compiled in as well.
BUG=None
BRANCH=None
TEST=Compiles and boots to kernel prompt
Change-Id: Id1e33fd500d52cfa03a946bf7dd85e6a90f3360e
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/221574
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
A higher drive setting is used for fast link training, once the
link training succeeds, a known-good drive setting will be used
for the main stream transactions.
For full link training sequence, the sink devices may ask for a
preferred drive setting, thus this drive setting should be used
for the main stream transactions too.
BUG=chrome-os-partner:32129
TEST=all panels on blaze/big devices work fine.
Change-Id: Icc540650dc1329af07fd9ee4661eb7fad435fde4
Signed-off-by: Neil Chen <neilc@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/219544
Reviewed-by: Julius Werner <jwerner@chromium.org>
The original dp driver supports only fast link training and a
special drive setting is used for the link training sequence.
This might not be accepted by all panels. The better way is to
go through full link training sequence to negotiate for a best
drive setting.
With the change, dp driver will try fast link training first,
this is same as before. If it fails in fast link training, will
try full link training.
BUG=chrome-os-partner:32129
TEST=all panels on blaze/big devices work fine.
Change-Id: I6f3402c4c5993a156c965c7f52b011d336a2946f
Signed-off-by: Neil Chen <neilc@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/219543
Reviewed-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
rockchip_spi_slave has a fifo_size member which doesn't change.
This just replaces the struct member with a #define.
BUG=none
BRANCH=none
TEST=built and booted on Pinky
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I9ea5cdad49ee10c5f32304d0909c4a7e74a261f9
Reviewed-on: https://chromium-review.googlesource.com/220471
Reviewed-by: Julius Werner <jwerner@chromium.org>
