Fan is attached to port 2 instead of 3.
BUG=chrome-os-partner:23593
BRANCH=beltino
TEST=tested with 4-wire fan on beltino board
Change-Id: I9878063a24b0b908c74522580f776a4ce7d03d75
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174751
Reviewed-by: Stefan Reinauer <reinauer@google.com>
The AUX channel (panel communications link) is on i2c4.
Enable the clocks for it. Not knowing any better, since
no extant source or docs seem to indicate a best choice,
we leave it on CLK_M, which is also the power on
default.
BUG=None
TEST=Build and boot. Gets to depth charge. I've never see anything from depth charge so this is as far as I get.
BRANCH=None
Change-Id: I60882b9035ad901ddb3cf859a5e03558d918d989
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/174620
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
This field was being set with the clock_ll_source_divisor function, but that
doesn't use the right shift amount when setting the source, and the disp1
register doesn't have a divisor field. Also, because there's no divisor, we
need to use a PLL that's already at the right frequency. Since PLLC is at
600MHz and is the PLL used for disp1 in U-Boot (according to the comment),
lets use that instead of PLLD.
BUG=None
TEST=Built and booted into the kernel on nyan. Saw that it no longer tripped
over its shoe laces when an illegal source was used for disp1.
BRANCH=None
Change-Id: Ibeeb6483bfedcaac994d78a0773fab41d982ae9c
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/174701
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
These few changes will turn on the backlight. There is a redundant (at present)
power on of the panel vdd but we should leave it there, as we are not
sure whether to keep it in romstage or not.
Note in this mode (at Nvidia's recommendation) we don't run the PWM as a PWM,
just a GPIO. That keeps things simple.
The backlight, incidentally, is turning out to be a nice, visible, power LED.
BUG=None
TEST=Build, boot, backlight comes on.
BRANCH=None
Change-Id: I5def9a0255d82fdd240be7e9097de3889595db2d
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/174533
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
The code in that file was using the raw GPIO indices instead of using the GPIO
macro to generate a combined gpio_t index type. This technically works just
fine, but it's not how these functions are intended to be used.
BUG=None
TEST=Built and booted into depthcharge on nyan.
BRANCH=None
Change-Id: I6a886cc7b909b6622c67eeef93833f1a9cade835
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/174418
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The load_stage_from_cbfs() when CONFIG_RELOCATABLE_RAMSTAGE is
selected is incorrect in that it hard coded the wrong stage name.
Instead it should honor the name past in instead of using a
predetermined (and wrong!) name.
BUG=chrome-os-partner:22866
BRANCH=None
TEST=Built booted. Noted fallback path works.
Change-Id: I61654313d15167efe50d5e4ff24fb06eab16f389
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174391
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
A global microcode_ptr was added when doing the MP
development work. However, this is unnecessary as the
pattrs structure already contains the pointer. Use
that instead.
BUG=chrome-os-partner:22862
BRANCH=None
TEST=Built and booted. Microcode still being loaded correctly.
Change-Id: I0abba66fc7741699411d14bd3e1bb28cf1618028
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174552
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
This reverts commit a84f498129.
Change-Id: Ieb9f2ae8cccfbf3d8abd1cebff9c998bffadc42c
Reviewed-on: https://chromium-review.googlesource.com/174542
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Linux tegra124 kernel uses pmc.odmdata to figure out serial console type &
address, which was defined by BCT in U-Boot world.
For Coreboot, we should build that value by Kconfig values. But since we don't
have a complete support for BCT & ODMDATA values yet, let's follow the values
defined in bct/odmdata.cfg.
BUG=none
TEST=emerge-nyan chromeos-coreboot-nyan; boot # see linux kernel messages.
BRANCH=none
Change-Id: I95e8473df840cb9f55259670add9e99cebde4dee
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174486
The ramstage image is the third image in the partition (after ECRW hash
and depthcharge image).
TEST=Manual. Boot rambi, verify that ramstage image is correctly found:
"RW ramstage image at 0xffb1dc70, 0x0000f391 bytes"
BUG=None.
Change-Id: I628db3daf0b109106c51693960487a0c83b4e9f4
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174540
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The reference code blog is needed to bootstrap
certain pieces of hardware in bay trail. Provide
the ability to run reference code by loading
the reference code as an rmodule.
Note that support for vboot verification and S3
resume is omitted from this commit.
BUG=chrome-os-partner:22866
BRANCH=None
TEST=Built and booted with refcode loading.
Change-Id: I30334db441a57f4d87b4de6fca0a9a48e1c05c05
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174426
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
There are 3 places rmodule stages are loaded in the
existing code: cbfs and 2 in vboot_wrapper. Much of the
code is the same except for a few different cbmem entry
ids. Instead provide a common implementation in the
rmodule library itself.
A structure named rmod_stage_load is introduced to manage
the inputs and outputs from the new API.
BUG=chrome-os-partner:22866
BRANCH=None
TEST=Built and booted successfully.
Change-Id: I146055005557e04164e95de4aae8a2bde8713131
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174425
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
In order to identify the ram used in cbmem for
reference code blobs add common ids to be consumed
by downstream users.
BUG=chrome-os-partner:22866
BRANCH=None
TEST=Built and booted with ref code support. Noted reference
code entries in cbmem.
Change-Id: Iae3f0c2c1ffdb2eb0e82a52ee459d25db44c1904
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174424
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
In order to incorporate external blobs into
CBFS besides MRC have a notion of a reference code
blob. By selecting HAVE_REFCODE_BLOB and providing
the file name the refcode blob will be added to
cbfs as a stage file.
BUG=chrome-os-partner:22866
BRANCH=None
TEST=Using this option and other patches able to build,
boot, and run blob code.
Change-Id: I472604d77f4cb48f286b5a76b25d8b5bfb0c7780
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174423
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Enabling the monotonic timer allows for collecting
boot stage times as well as each device initialization
time.
BUG=chrome-os-partner:23166
BRANCH=None
TEST=Built and booted. Noted timings in console output.
Change-Id: I5fdc703ea21710fd26de352f367c6fc0c767ab6a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174422
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The PCU (platform controller unit) contains the
resources and IP blocks that used to reside in the
south bridge. Bay Trail has since renamed it south
cluster. There are quite a few fixed MMIO and I/O
resources. If these aren't added the resource allocator
will freely assign these addresses which causes conflicts
and other subtle bugs.
BUG=chrome-os-partner:23544
BUG=chrome-os-partner:23545
BRANCH=None
TEST=Built and booted through depthcharge. Verified
resource allocation not weird. And no more depthcharge
crashes.
Change-Id: I697fbda4538c03fded293bcb63a5823b1ed150ec
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174421
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This does a couple things:
- Fix typo in function name. This is not tegra2...
- Use #defines instead of numerical constants.
- Enable FLOW and set REQ_SEL.
BUG=none
BRANCH=none
TEST=built and booted on nyan
Change-Id: If35b75c13969ec1e898a4ff9d8cd3678508cb725
Reviewed-on: https://chromium-review.googlesource.com/174445
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
This exposes some #defines that are needed by the SPI driver so that
we can get rid of hard-coded constants.
BUG=none
BRANCH=none
TEST=compile tested
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I460028173af8ec8fe11fac47d21f954d23ed6fc4
Reviewed-on: https://chromium-review.googlesource.com/174444
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
To access MMC 3/4 in payloads, we need to first configure pinmux for their data
and command channel.
BUG=none
TEST=emerge-nyan chromeos-coreboot-nyan
BRANCH=none
Change-Id: I6e54afb0c38b34ba637bc97e1caac7f7fef505f6
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174011
Reviewed-by: Gabe Black <gabeblack@chromium.org>
The base clock is set to maximum speed supported by Tegra MMC controllers.
Actual SD clock speed will be configured by payloads.
BUG=none
TEST=emerge-nyan chromeos-coreboot-nyan
BRANCH=none
Change-Id: I4140cc0e680daab6692bb39327dc182eafac50e0
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173841
This patch intializes the PLLs P, C, D and U in addition to the already
existing PLLX. It completely revamps the oscillator-dependent divisor
table mechanism, using binary compatible bitfield structs in a
transparent union to make it both compact and compile-time range checked
while still being readable and easy to use in a generic init_pll()
function.
It also moves the clock.h file into <soc/...> include space because I'm
going to need that for USB code soon.
BUG=None
TEST=Make sure it still boots as well as before.
Change-Id: I5f06f97eb9e0a7359fef02469c63306f500aa423
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174380
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
This patch enables the UART first thing in the bootblock, without even
depending on a programmable clock source. This depends on being able to
divide CLK_M correctly, which may not be possible for all oscillator
frequencies, but it works for 12MHz.
BUG=None
TEST=Put a printk at the top of clock_init() and see it's output (also
put one after clock_config() and make sure that works as well).
Change-Id: Ided01a569fb3d141347992776970601042cb4402
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174339
Reviewed-by: Gabe Black <gabeblack@chromium.org>
- GPIO29 is no longer connected so we don't need the SMI workaround
on the entry to sleep states.
- Disable touchscreen wake source until the kernel driver is working
so it does not wake immediately.
- Update a few GPIOs and disable the codec for now as it is leaking
into the 1.8V DDR rail.
BUG=chrome-os-partner:23449
BRANCH=samus
TEST=emerge-samus chromeos-coreboot-samus
Change-Id: Ia67b17eb4a097627befd8f39aadc939da1bf3d40
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174122
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The LPDDR3 memory is x32 and dual rank with 14 row bits.
In addition the memory is actually elpida, even though
they are owned by micron it is confusing to label it as such.
And the ram strap options were inverted from what I expected
so the memory table needs to be updated.
BUG=chrome-os-partner:23449
BRANCH=samus
TEST=emerge-samus chromeos-coreboot-samus
Change-Id: Ia29a23e8140d884fb84f940806f041b40562aab9
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174121
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
There is only one bit for memory width reporting, either x16 or
other. With x32 memory this code is reporting it as x8 so instead
report "x8 or x32" in this condition.
BUG=chrome-os-partner:23449
BRANCH=samus
TEST=emerge-samus chromeos-coreboot-samus
Change-Id: I2a7c49bcb8de19084947b9dc42b93140641886fc
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174120
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This adds a stub for dcache_line_bytes() that returns a hard-coded
value for now. The actual value won't matter until we try to turn
on caching in the bootblock (if ever).
BUG=none
BRANCH=none
TEST=tested on nyan
Change-Id: I3876e8282698cc860ddd7b65e58246d8095958bd
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173976
Reviewed-by: Gabe Black <gabeblack@chromium.org>
This exposes the function that obtains cache line size so that it can
be used by drivers in DMA-related functions.
BUG=none
BRANCH=none
TEST=built and booted on nyan, nothing obvious broke
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I9b0ddc36aa39084f0d621af064487d1b2ef3d023
Reviewed-on: https://chromium-review.googlesource.com/174099
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
This exposes the function that obtains cache line size so that it can
be used by drivers in DMA-related functions.
BUG=none
BRANCH=none
TEST=tested on nyan
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I1664be98a91d2f776e27274b19838c1782371a81
Reviewed-on: https://chromium-review.googlesource.com/173975
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
These functions are intended to start and end a transaction on the bus and so
need to manage the CS line.
BUG=None
TEST=Used a Logic16 to watch the SPI bus as coreboot attempted to use it to
talk to the EC. With this change, CS was set (low) during the transaction when
before it wasn't.
BRANCH=None
Change-Id: I37992dc2e51dec878d565ebea1da586bdcac6400
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/173953
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The PLLX registers don't actually have those fields. I assume those are left
over from older SOCs, and since we don't support those we don't have to go
through the motions of setting them.
BUG=None
TEST=Built and booted into depthcharge on nyan.
BRANCH=None
Change-Id: I3696e57fc5629d6f15c09a50c91c4da1efeb217d
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/173779
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
This PLL feeds the CPUs, and, when using a 12 MHz external oscillator like on
nyan, was running the CPUs at 108 MHz. The new settings bring the frequency in
that case and the other oscillator frequencies up as close as they can be to
1.9 GHz without going over. I went for that frequency because it was in a
comment in the source, but the data sheet suggests that we could actually go
at 2.0 GHz.
The manual doesn't actually say what formula is used when applying the M/N
divider, but it appears to be:
(osc * n) / (m * (2 ^ p)) = output frequency.
It's interesting that the divider type is called M/N but the formula
effectively has N/M in it, but I suppose that works out if you're dividing
by it. Because we're going from a pretty low frequency to a pretty high
frequency, n is generally high and m and p are generally low. m and n are
limitted to 8 bits, so there aren't many combinations that can bring the
frequency up enough.
BUG=None
TEST=Built and booted into depthcharge on nyan. Saw that it ran much faster.
BRANCH=None
Change-Id: I5af9d33a1f9c4420235127a4e8276656fd67b170
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/173778
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Initialize SMM on all CPUs by relocating the SMM region
and setting SMRR on all the cores. Additionally SMI
is enabled in the south cluster.
BUG=chrome-os-partner:22862
BRANCH=None
TEST=Built and booted rambi. Tested with DEBUG_SMI and noted
power button turns off board while in firmware.
Change-Id: I92e3460572feeb67d4a3d4d26af5f0ecaf7d3dd5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173983
In order for the cpu code to start SMM relocation 2 new
functions are added to be shared:
- void smm_initiate_relocation_parallel()
- void smm_initiate_relocation()
The both initiate an SMI on the currently running cpu.
The 2 variants allow for parallel relocation or serialized
relocation.
BUG=chrome-os-partner:22862
BRANCH=None
TEST=Built and booted rambi using these functions.
Change-Id: I325777bac27e9a0efc3f54f7223c38310604c5a2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173982
The Bay Trail SMM save state revision is 0x0100.
Add support for this save state area using the
type named em64t100_smm_state_save_area_t.
BUG=chrome-os-partner:22862
BRANCH=None
TEST=Built and booted using this structure with forthcoming CLs.
Change-Id: Iddd9498ab9fffcd865dae062526bda2ffcdccbce
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173981
This will make USB keyboards connected to USB3 ports work
in libpayload on Beltino.
BUG=chrome-os-partner:23396
BRANCH=none
TEST=Use USB keyboard on Beltino in dev mode screen
Change-Id: I70b03d733bd9e4c8be5673b48bd2196effa8a5e7
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/173640
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
This script is used by 'make menuconfig', but being non executable it
fails to run, causing the make invocation failure.
Setting 'x' mode bits fixes the problem.
BRANCH=none
BUG=none
TEST=manual
. run the following commands in coreboot tree
$ cd payloads/libpayload/
$ cp configs/config.bayleybay .config
$ make menuconfig
This sequence now succeeds, it was failing before.
Change-Id: I925ca4ee056937b6c38ad34f5520fd621f9d9eb0
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173564
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
BUG=None
TEST=Builds
BRANCH=None
Change-Id: I105fa471c3996ea3ce8083aed7fc0e1c5c6c0db8
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/173955
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
taken from Stumpy
BUG=none
BRANCH=none
TEST=Boot ChromeOS
Change-Id: I1e216b854fe342b8c2101af5be421e56d6d1c67d
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/173641
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
This patch fixes the use of the recovery button on
Beltino devices. In order to have the recovery button
available as early as possible, the value is stored
in a SATA controller scratch register (similarly as
it has been done on other ChromeOS devices)
BUG=none
BRANCH=none
TEST=Use recovery button
Change-Id: I690cd1b9fe89afa9f58d9084e4473704a12f891d
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172276
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Bring up the APs using x86 MP infrastructure.
BUG=chrome-os-partner:22862
BRANCH=None
TEST=Built and booted rambi. Noted all cores are brought up.
Change-Id: I9231eff5494444e8eb17ecdc5a0af72a2e5208b5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173704
Provide a common entry point for bringing up the APs
in parallel. This work is based off of the Haswell one
which can be moved over to this in the future. The APs
are brought up and have the BSP's MTRRs duplicated in
their own MTRRs. Additionally, Microcode is loaded before
enabling caching. However, the current microcode loading
support assumes Intel's mechanism.
The infrastructure provides a notion of a flight plan
for the BSP and APs. This allows for flexibility in the
order of operations for a given architecture/chip without
providing any specific policy. Therefore, the chipset
caller can provide the order that is required.
BUG=chrome-os-partner:22862
BRANCH=None
TEST=Built and booted on rambi with baytrail specific patches.
Change-Id: I0539047a1b24c13ef278695737cdba3b9344c820
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173703
All USB ports need to be routed through XHCI, so
remove UHCI and EHCI stacks (will also reduce binary size
of depthcharge)
BUG=chrome-os-partner:23396
TEST=Boot into dev mode screen, use keyboard and see that it works.
BRANCH=none
Change-Id: I05c56657f16c459294c0e9ceff339fe7a8e03ca2
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/173579
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
There's some baked in assumptions internal to coreboot
that the BSP's cpu device exists in the device tree. Therefore
provide one in the device tree.
BUG=chrome-os-partner:22862
BRANCH=None
TEST=Compiled and booted with other changes.
Change-Id: I22ba10964760ee8efbc5bbd5d4ce65daf31b3839
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173702
The CPSR isn't set up in the bootblock like it normally would be since the
bootblock executes on the AVP and not the main CPUs like the remainder of the
firmware.
BUG=None
TEST=Built and booted into depthcharge on nyan.
BRANCH=None
Change-Id: I5b2fa460b6be6b212418de381e92de9b2fad70cb
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/173775
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
cpu.h uses standard int types but doesn't include stdint.h, getting by because
the including files apparently had included stdint.h before including cpu.h.
BUG=None
TEST=Built and booted into depthcharge on nyan.
BRANCH=None
Change-Id: Ibaf2e66c936184464cd31f4bb53abac7765ed473
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/173774
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
