BUG=None
TEST=emerge veyron_mighty and Boot the mighty board
BRANCH=None
Change-Id: I3fcdc837e8d7e62c145850f549662d8260aa1120
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/234714
Reviewed-by: Julius Werner <jwerner@chromium.org>
BUG=None
TEST=emerge veyron_jerry and Boot the jerry board
BRANCH=None
Change-Id: I6eb0900516bcd95159c472749c54d356448d2344
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/234713
Reviewed-by: Julius Werner <jwerner@chromium.org>
BUG=None
TEST=emerge veyron_pinky and Boot the pinky board
BRANCH=None
Change-Id: I06242ade0cabbba56b16b3832a1b4b09bec6f06b
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/234712
Reviewed-by: Julius Werner <jwerner@chromium.org>
we use the devicetree to pass the backlight control gpio before,
but if there have different board version, and use different
io to control backlight, it will hard to distinguish it. so we
move the backlight control to mainboard, and we can through board_id
to distinguish the backlight control.
BUG=None
TEST=emerge veyron_pinky and Boot the pinky board
BRANCH=None
Change-Id: I1ec8e04f4982c3a8c7e31d8dc2c75311b7199ffc
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/234711
Reviewed-by: Julius Werner <jwerner@chromium.org>
Display configuration is board specific. The change here is preparing
for supporting other than dsi interface.
BUG=chrome-os-partner:34336
BRANCH=none
TEST=build ryu and test dev/rec mode, also build rush ok
Change-Id: I494a04f7d6c0dbad2d472f4c2cd0aabfb23b8c97
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/234271
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
dc supporting functions can be used for other than dsi display
interfaces. This change is preparing for supporting sor display
interface.
BUG=chrome-os-partner:34336
BRANCH=none
TEST=build ryu and test dev/rec mode, also build rush ok
Change-Id: Id14cbd89457cb91c23526927a432f4eb7cc6291b
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/234270
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
- These should be 64bit values so when they try to return -1
it is interpreted properly by the kernel.
- The GPE value needs to be reset at the start so it does not
return stale data from a previous resume.
- If a GPE register is zero the value should only be updated
if it has not yet found a set bit.
BUG=chrome-os-partner:34532
BRANCH=samus,auron
TEST=build and boot on samus, suspend/resume with various
wake sources and ensure the reported _SWS values are correct
in every case.
Change-Id: Ic6897f20ad2f321f3566694c032b75a3db120556
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/235012
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Like Nyan, Veyron boards use a GPIO to reset the system so that we can
make the accompanying TPM reset secure and unforgeable. The normal
kernel reboot driver knows that, but the SoC-internal watchdog doesn't.
This patch implements a check for the global reset status register in
the early bootblock and triggers a hard_reset() when it matches "first
global watchdog reset" or "second global watchdog reset". Seems that
the difference between the two is is a choice controlled by
wdt_glb_srst_ctrl (unconfirmed), and we want this code to run in both
cases.
BRANCH=None
BUG=chrome-os-partner:33141
TEST=Run 'mem w 0xff800000 0x9' from the command line, watch how you end
up in recovery without this patch but can boot normally with it.
Change-Id: I2581bde84f0445c15896060544e9acb60de91c8c
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231734
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Define the signature for the FSP HOB list pointer and add it to the
table parser.
BRANCH=none
BUG=None
TEST=Use the following steps to reproduce:
1. Get the private FSP parts
2. Copy configs/config.samus.fsp to configs/config.samus
3. Build and run on Samus
4. Test successful if the code attempts to load the payload
Change-Id: I3e340289b0ba560147d9766583a82b783adb1605
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/234525
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Leroy P Leahy <leroy.p.leahy@intel.com>
Tested-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Call FspNotify to finish the platform initialization. Attempts to
load the payload.
BRANCH=none
BUG=None
TEST=Use the following steps to reproduce:
1. Get the private FSP parts
2. Copy configs/config.samus.fsp to configs/config.samus
3. If running on a non-samus board, in
src/mainboard/google/samus/Kconfig:
a. Comment out select EC_GOOGLE_CHROMEEC
b. Comment out select EC_SOFTWARE_SYNC
4. If running on a non-samus board, in
src/mainboard/google/samus/spd/spd.c comment out the check for
valid SPD data at the end of the file
5. Build and run on Samus
6. Test successful if the code attempts to load the payload
Change-Id: I007bd5481e532e14dca3f158b8eb1d8cb4dc3f47
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/232874
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Leroy P Leahy <leroy.p.leahy@intel.com>
Tested-by: Leroy P Leahy <leroy.p.leahy@intel.com>
With introduction of uber-sbl SRAM usage pattern is changing, this
introduces the new memory layout.
This patch overlays DDR initialization code with uber-sbl, as uber-sbl
goes out of scope as soon as bootblock starts.
A 4K block at offset 0x3f000 added in the comments, this is a shared
structure used by different QCA modules.
This suggested layout is not final, but will allow to move closer to
the production image.
BRANCH=storm
BUG=chrome-os-partner:34161
TEST=with other patches applied Storm boots all the way to rombase and
initializes DRAM.
Change-Id: I927f6ffc524fc8f0effd7b91d3f5d1e8d6be1530
Signed-off-by: Deepa Dinamani <deepad@codeaurora.org>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229023
16K of BSS scratchpad buffer is no pocket change for some platforms that
really need to count every kilobyte in their SRAM stages. This patch
makes sure we don't compile LZMA code into the romstage if we don't need
it because the ramstage is not compressed anyway.
BRANCH=None
BUG=None
TEST=Booted Pinky and Blaze. Confirmed that romstage memsz on Pinky is
way smaller than before.
Change-Id: Icf04971b8ddafa76052135cd0e44977d44d69486
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/234539
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add support to call FspSiliconInit
BRANCH=none
BUG=None
TEST=Use the following steps to reproduce:
1. Get the private FSP parts
2. Copy configs/config.samus.fsp to configs/config.samus
3. Build and run on Samus
4. After power on, POST code should be 0x35 if successful, hangs in
src/soc/intel/broadwell/romstage/romstage.c/romstage_after_car
Change-Id: I80363425df97bf1f1f9b9180f2fd4c625125d33e
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/232383
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Leroy P Leahy <leroy.p.leahy@intel.com>
Tested-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Add support to call FspTempRamExit
BRANCH=none
BUG=None
TEST=Use the following steps to reproduce:
1. Get the private FSP parts
2. Copy configs/config.samus.fsp to configs/config.samus
3. Build and run on Samus
4. After power on, POST code should be 0x35 if successful, hangs in
src/soc/intel/broadwell/romstage/romstage.c/romstage_after_car
Change-Id: I512bfa8c3add8a16d945c5983873ee0286ec40d1
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/232500
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Repartition the RAM initialization code to share the setup and caching
support. Display the parameters for the MemoryInit call. Initialize
memory using the FSP binary. Upon return display the HOBs and memory
configuration before hanging displaying POST code 0x35.
BRANCH=none
BUG=None
TEST=Use the following steps to reproduce:
1. Get the private FSP parts
2. Copy configs/config.samus.fsp to configs/config.samus
3. Build and run on Samus
4. After power on, POST code should be 0x35 if successful, hangs in
src/soc/intel/broadwell/romstage/romstage.c/romstage_common
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Change-Id: I02e1ea422644da1f6285812dd36045a70e0f4324
Reviewed-on: https://chromium-review.googlesource.com/231285
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
S25FL116K family use the first 3 bytes in response to a regacy identification
command (9f) while previously supported models use the last 4 bytes. This change
defines identify functions to allow both types to be handled correctly.
BUG=none
BRANCH=tot
TEST=verified romstage is loaded on cosmos development board.
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: Icdd2645e356652672c4482e7b805da1bc0f21e71
Reviewed-on: https://chromium-review.googlesource.com/234431
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The library timestamp module generates exactly the same error messages
in different situations, which does not help debugging.
Lets keep all messages different.
BRANCH=none
BUG=none
TEST=it still builds for storm
Change-Id: I0cbd4281f458de06e06fe58a02eafd1e96d7117d
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/234406
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
this is a preparation for porting these drivers to coreboot. the code will be modified by the following patches.
BUG=chrome-os-partner:33647
BRANCH=ToT
TEST=None
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: I9f3428ef02d2ba15ae63c99b10fe0605dd595313
Reviewed-on: https://chromium-review.googlesource.com/231461
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
During execution, src/soc/intel/broadwell/romstage/fsp_1_1.inc calls
src/soc/intel/fsp/fsp_util.c/find_fsp, added in change list 229573,
to locate the FSP binary in CBFS. Determine the TempRamInit entry point
and call TempRamInit. After returning, fsp_1_1.inc calls into
src/soc/intel/broadwell/romstage/romstage.c/romstage_main.
BRANCH=none
BUG=None
TEST=Use the following steps to reproduce:
1. Get the private FSP parts: internal 187295
2. Copy configs/config.samus.fsp to configs/config.samus
3. Build and run on Samus
4. After power on, POST code should be 0x35 if successful, hangs in
src/soc/intel/broadwell/romstage/romstage.c/romstage_main
Change-Id: Id7d17b7b46e73a7b6b4dae6ee859016dab6e6d6f
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/234140
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
this is required to do early firmware selection using vboot2. actual
implementation can be done later.
BUG=chrome-os-partner:33755
BRANCH=ToT
TEST=Booted storm.
Change-Id: Idd1a1de4991a19902ffe45f01be89d47f4413779
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229425
Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
this allows each board to decide what to do after firmware verification is
done. some board needs to return back to the previous stage and let the
previous stage kick off the verified stage.
this also makes it more visible what is going to happen in the verstage since
stage_exit now resides in main().
BUG=none
BRANCH=tot
TEST=booted cosmos dev board. booted blaze in normal and recovery mode.
built for all current boards.
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: I3cb466cedf2a9c2b0d48fc4b0f73f76d0714c0c7
Reviewed-on: https://chromium-review.googlesource.com/232517
The gpio access code has been moved to a separate file to match other
platforms. Accessor functions are added to read different switches
state. They will be read by verstage, when it is enabled, and by
ramstage, for passing the values to depthcharge.
It is unfortunate that the gpio values are not being cached and can
change by the time CBMEM table is filled, but we have to live with
that for now.
BUG=chrome-os-partner:33756,chrome-os-partner:34161
BRANCH=storm
TEST=none yet.
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: I940b54cd3cf046b94d57d59d370e634a70a8bbeb
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229426
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This device is not used in current builds and should be
disabled to help EMI.
BUG=chrome-os-partner:34117
BRANCH=samus
TEST=build and boot on samus
Change-Id: I62541e343dcaa3cd31c81b73d8c27a5efcf3ad60
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/234403
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
This code that stores the initial timestamp is not being used,
instead the timestamp is passed to romstage_main().
BUG=chrome-os-partner:28234
BRANCH=samus,auron
TEST=build and boot on samus
Change-Id: I0e0fa1ba74ab93d4454fdfa12208e712d2ae913c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/234402
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
When turning up the CPU frequency set it to turbo if that is
a possibility. Also only set the frequency on the boot CPU
since that is all we need it on, this will allow the 1-core
turbo ratio.
BUG=chrome-os-partner:28234
BRANCH=samus,auron
TEST=build and boot on samus
Change-Id: Ib5ad746767ee0a56bc7e59de679a9342f053c0e5
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/234401
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In order to avoid a 300ms timeout waiting for mbp_cleared flag
to be set there is a new flow for the ME10 1.5MB firwmare that
we can follow which will save significant boot time.
This requires sending new commands that do not generate an ACK
message, and ensuring an HMRFPO LOCK message is sent.
In addition now that the delay is removed clean up the ME path
to do the work in init() step and add a final() step that does
the disabling of the PCI device.
BUG=chrome-os-partner:30637,chrome-os-partner:34134
BRANCH=samus,auron
TEST=build and boot on samus, measure ~300ms speedup in boot time
Change-Id: I753087ecd65f6ebed9f812318a359f893e01da9f
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/234400
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Now that we have timestamps in pre-RAM stages, let's actually make use
of them. This patch adds several timestamps to both the bootblock and
especially the verstage to allow more fine-grained boot time tracking.
Some of the introduced timestamps can appear more than once per boot.
This doesn't seem to be a problem for both coreboot and the cbmem
utility, and the context makes it clear which operation was timestamped
at what point.
Also simplifies cbmem's timestamp printing routine a bit, fixing a
display bug when a timestamp had a section of exactly ",000," in it
(e.g. 1,000,185).
BRANCH=None
BUG=None
TEST=Booted Pinky, Blaze and Falco, confirmed that all timestamps show
up and contained sane values. Booted Storm (no timestamps here since it
doesn't support pre-RAM timestamps yet).
Change-Id: I5979bfa9445a9e0aba98ffdf8006c21096743456
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/234063
Reviewed-by: Aaron Durbin <adurbin@chromium.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_early_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_early_init(0) again from platform code.)
BRANCH=None
BUG=None
TEST=Booted Pinky, Blaze and Storm, compiled Daisy and Pit.
Change-Id: Iece1614b7442d4fa9ca981010e1c8497bdea308d
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/234062
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Some boards spread their timer implementation out in multiple files with
one function each for no discernable reason. Let's clean that up to make
things a little simpler to find.
BRANCH=None
BUG=None
TEST=Booted Pinky, compiled Daisy and Pit.
Change-Id: I43d29cd1b4a1d89cfd40f6cba5ca99ada3b00f82
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/234061
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The ramstage is loaded from romstage, so the LZMA scratchpad buffer used
to decompress it is part of the romstage BSS in SRAM. On RK3288, SRAM
cannot be cached which makes the decompression so slow that it's faster
to just load an uncompressed image from SPI. Disable ramstage
compression on this SoC to account for that.
Since Kconfig is weird and we cannot disable an option that is enabled
by default with 'select', we need to rearrange menu groups so that
'mainboard' and 'chipset' come before 'General setup', which allows the
subdirectory Kconfig files sourced by them to override the generic
defaults specified later.
BRANCH=None
BUG=None
TEST=Built for Pinky and Falco, confirmed that the former didn't have
COMPRESS_RAMSTAGE in its .config and the latter still did. Measured a
speed-up of about 35ms on Pinky. (For some weird reason, the
decompression of the payload also takes way longer than on other
platforms, although not as long as the ramstage. I have no explanation
for that and can't really think of a good way to figure it out... maybe
the Cortex-A12 is just terrible at some operation that LZMA uses a lot?)
Change-Id: I9f67f7537696ec09496483b16b59a8b73f4cb11b
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/234192
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch doubles the ACLK peripheral clock for the PD_BUS power domain
to 297MHz, which is the closest to the maximum of 300MHz we can reach by
dividing GPLL. This frequency directly translates into SRAM speed, so
maximizing it has a huge impact on boot speed (especially with the lack
of SRAM caching).
BUG=chrome-os-partner:32987
TEST=Booted Veyron_Pinky. Hacked timestamps into vboot and confirmed
that the (visibly) long signature verification times are nearly halved.
Change-Id: I3f19eaa3d97dcc6235d820c71eb5edf2ae87d647
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224524
Trybot-Ready: Doug Anderson <dianders@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This configures I2S1 and the codec MCLK muxes to pass the PCM
audio data to the RT5677 codec. Once depthcharge RT5677 codec
driver changes are in, audio 'beeps' should be heard on boot
(Ctrl-U / devmode/recmode).
BUG=chrome-os-partner:32582
BRANCH=none
TEST=Built and booted Ryu/A44.
Change-Id: Ib071bcb41fba8f6d628a386ed233ec84a54b0323
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/233945
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
With this change, audio 'beeps' are heard on boot if Ctrl-U is
pressed, or devmode/recmode is entered. I also tested via an
explicit call to VbExBeep in the kernel boot path. Note that
a couple of Rush CLs for depthcharge are needed for audio, too.
BUG=chrome-os-partner:32582
BRANCH=none
TEST=as above. Built and booted Rush/Norrin64.
Change-Id: Ia37f077569afd806ce6574c4c58813fd7aca1644
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/233671
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
add the samsung-4GB and hynix-4GB lpddr inf file,
and use ram_id 1000 correspond to samsung-4GB lpddr
use ram_id 1001 correspond to hynix-4GB lpddr
BUG=chrome-os-partner:33269
TEST=Boot veyron_speedy normal
BRANCH=None
Change-Id: I55b6968c642df8c1f579e518232ab5d278e7e12f
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/233859
Reviewed-by: Julius Werner <jwerner@chromium.org>
Data toggle should be running like 0, 1, 0, 1, ...
In the failed case (where a low-speed USB keyboard or km232 device
is installed), data toggle will be running as 0, 1, 0, 1, ..., 1, 1.
Therefore causing Halted or Transaction Error bit to be set in qTD
Status field.
BUG=None
BRANCH=None
TEST=Tested on nyan_kitty platform, firmware-kitty-5771.61.B branch.
Attached USB keyboard or km232 device to root-hub port (same side as
SD card slot).
Made sure no transaction error after doing interrupt transfer.
Change-Id: Ic2c0f95cff2ae6e314967b0b82231a962255f1a7
Signed-off-by: Jim Lin <jilin@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/233857
Reviewed-by: Julius Werner <jwerner@chromium.org>
After DDR PHY reset de-asserted, DLL automatically starts to
lock, and the lock time is maximum 5.12us. The output clock of
DLL supplies the clocks of DDR controller and PHY digital logic.
So before DLL lock, the clocks of DDR controller and PHY digital
logic are indeterminate. When programming DDR in the period of
DLL unlock, the programming maybe unstable because of the
indeterminate clocks. So we need wait for at least 5.12us after
de-asserting reset, then start to program DDR registers.
Add some redundancy, the waiting time hopes to achieve 10us.
BUG=chrome-os-partner:33148
TEST=I'm using the following command line test ok(15000 cycles).
"while sleep 4 && dut-control cold_reset:on sleep:.1 cold_reset:off;
do : ; done"
BRANCH=None
Change-Id: I55f8cb11ed3d7962567c5f40a31e6c8aed8fdcb0
Signed-off-by: DaiLunXue <dlx@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/232894
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Lunxue Dai <lunxue.dai@rock-chips.com>
Tested-by: Lunxue Dai <lunxue.dai@rock-chips.com>
Essentially a copy of veyron_jerry for now
BUG=chrome-os-partner:33269
TEST=emerge-veyron_speedy coreboot
BRANCH=None
Change-Id: Ife457db4fd67fe69bcd4082694b3372eccfb304b
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/233822
Reviewed-by: Julius Werner <jwerner@chromium.org>
Files necessary for the SOC bringup are added to the CBFS as raw
blobs.
Ipq8064 specific MBN header will allow to determine were the blobs
should be loaded and what start address should be used.
BRANCH=storm
BUG=chrome-os-partner:34161
TEST=build storm firmware and verify that the right components are added:
$ emerge-storm coreboot chromeos-bootimage
$ cbfstool /build/storm/firmware/image.bin print
image.bin: 8192 kB, bootblocksize 32488, romsize 2883584, offset 0x7f40
alignment: 64 bytes, architecture: arm
Name Offset Type Size
cdt.mbn 0x7f40 raw 376
ddr.mbn 0x8100 raw 25820
rpm.mbn 0xe640 raw 78512
tz.mbn 0x21940 raw 85360
fallback/verstage 0x36700 stage 39500
fallback/romstage 0x401c0 stage 15652
fallback/ramstage 0x43f40 stage 24328
config 0x49e80 raw 2701
fallback/payload 0x4a940 payload 65592
u-boot.dtb 0x5a9c0 (unknown) 2922
(empty) 0x5b580 null 2509336
$
Change-Id: Id642ae68ef07750624f85b31ad891752d8af99bf
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233672
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Used for audio on Rush/Ryu. I2S1/DAP2 provides the audio
'stream' for the dev/rec mode 'beeps'.
BUG=chrome-os-partner:32582
BRANCH=none
TEST=With follow-on CLs that make use of this support,
audio beeps (via VbExBeep) can be heard on Rush. Built
both Rush and Ryu OK.
Change-Id: Ia8c32303979f25300e22b5a14609d9d9d5ce3132
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/233670
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The only way to reliably reset an SD card in an unknown state is by
power-cycling. Since a kernel may crash and reboot at any point, SD
cards may be left in one of them fancy high-throughput modes that
depthcharge (or, in fact, a newly booting kernel without prior
knowledge) doesn't support, so we need to reset the card on every boot.
This patch adds support to turn off an RK808 regulator completely and
uses that to turn off SD card power rails in early romstage. The time
until configure_sdmmc() in ramstage turns them back on should be more
than enough to drain the power rail for an effective power-cycle.
BRANCH=None
BUG=chrome-os-partner:34289
TEST=Booted a Pinky from SD card, noticed that it works before and
after this patch.
Change-Id: I904b2d23ca35f765c000f9bee7637044f674eff9
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233713
Reviewed-by: Alexandru Stan <amstan@chromium.org>
Tested-by: Alexandru Stan <amstan@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
WPT-LP has 4 SATA ports. Current code assumes 6 SATA ports and as a result,
some reserved bits are written with 1. No specific issue has been observed
so far.
BUG=None
BRANCH=None
TEST=Verify SATA PCI configure space dump on Auron
Change-Id: I9c53ac86e2bf72901647bd2cfa48ac0ce31abea0
Signed-off-by: Wenkai Du <wenkai.du@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/233661
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit 7dd5bbd71 (cbmem: Unify random on-CBMEM-init tasks under common
CBMEM_INIT_HOOK() API) inadvertently broke ramstage timestamps since
timestamp_sync() was no longer called there. Oops.
This patch fixes the issue by extending the CBMEM_INIT_HOOK() mechanism
to the cbmem_initialize() call in ramstage. The macro is split into
explicit ROMSTAGE_/RAMSTAGE_ versions to make the behavior as clear as
possible and prevent surprises (although just using a single macro and
relying on the Makefiles to link an object into all appropriate stages
would also work).
This allows us to get rid of the explicit cbmemc_reinit() in ramstage
(which I somehow accounted for in the last patch without realizing that
timestamps work exactly the same way...), and replace the older and less
flexible cbmem_arch_init() mechanism.
Also added a size assertion for the pre-RAM CBMEM console to memlayout
that could prevent a very unlikely buffer overflow I just noticed.
BRANCH=None
BUG=None
TEST=Booted on Pinky and Falco, confirmed that ramstage timestamps once
again show up. Compile-tested for Rambi and Samus.
Change-Id: If907266c3f20dc3d599b5c968ea5b39fe5c00e9c
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233533
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
