This patch adds code to initialize the two DWC3 USB host controllers and
their associated PHYs to the IPQ806x SoC (closely imitating the existing
DWC3 implementation for Exynos5), and uses them to initialize USB on the
Storm mainboard.
BUG=chrome-os-partner:29375
TEST=Hack up netboot to get around missing SPI flash, load a file over
TFTP. Hack a storage read into the storage attach function, dump the
data and confirm that it looks right. Enable USB debugging and confirm
3.0 devices get enumerated at SuperSpeed (mostly).
Change-Id: Iaf7b96bef994081ca222b7de9d8e8c49751d3f1d
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202157
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
- Put SSD into reset on transition to S3/S5 to prevent leakage
- Fix GPIO number for wlan disable used in smihandler
- Enable generic hub driver in libpayload
- Fix comment in devicetree about S0ix
BUG=chrome-os-partner:28502
BRANCH=None
TEST=Build and boot on samus
Change-Id: Idce566d0f22622d36697be54ab51cacb576c5d6d
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203185
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
XHCI driver was not enabled in libpayload and some ports were
disabled that should be enabled.
The Chrome OS GPIOs also need to be reported as 0xFFFFFFFF to
properly indicate unused so crossystem does not attempt to
export GPIO number 255 in the kernel and trigger a warning.
BUG=chrome-os-partner:28234
TEST=Build and boot on wtm2
Change-Id: Ib5727ef6e618c959640b200757cfa13f95c7cb0f
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203184
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Does not compile yet because tegra132 support is not present in cbootimage
BUG=None
BRANCH=None
TEST=Does not compile (Waiting for tegra132 support in cbootimage)
Change-Id: I796f171031bacf17106878d4a554e8f1cbfe93f8
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/203145
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Changes might be required for .bct files as we get to know more.
Pulling in files from mainboard nyan for now
BUG=None
BRANCH=None
TEST=Compiles successfully for rush
Change-Id: Iaf81a384af0469c77940cf7309ba68018110b5eb
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/203144
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
CrOS devices with Chromeos EC need only use hostevent to communicate
recovery assertion to the BIOS. This CL removes wired GPIO from
determining recovery as it appears under certain conditions (cold
reset) the internal PU on the AP isn't strong enough and therefore the
value is sometimes seen as asserted.
BRANCH=none
BUG=chrome-os-partner:29333
TEST=compiles & BIOS no longer responds to rec_mode GPIO during boot.
Change-Id: Ib220cfa5f5bfe7193d555bfd32c0444b063d00f2
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202996
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Tom Warren <twarren@nvidia.com>
x86 systems run their romstage as execute-in-place from flash, which
prevents them from having writable data segments. In several code pieces
that get linked into both romstage and ramstage, this has been worked
around by using a local variable and having the 'static' storage class
guarded by #ifndef __PRE_RAM__.
However, x86 is the only architecture using execute-in-place (for now),
so it does not make sense to impose the restriction globally. Rather
than fixing the #ifdef at every occurrence, this should really be
wrapped in a way that makes it easier to modify in a single place. The
chromeos/cros_vpd.c file already had a nice approach for a wrapper
macro, but unfortunately restricted it to one file... this patch moves
it to stddef.h and employs it consistently throughout coreboot.
BRANCH=nyan
BUG=None
TEST=Measured boot time on Nyan_Big before and after, confirmed that it
gained 6ms from caching the FMAP in vboot_loader.c.
Change-Id: Ia53b94ab9c6a303b979db7ff20b79e14bc51f9f8
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203033
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
The recently introduced page table location value is wrong, it
overlaps with other areas of the code. This patch fixes the location,
a more robust scheme is needed for memory layout management.
BUG=none
TEST=manual
. occasional random failures disappear after this patch is applied
Change-Id: Idc9047d38712736c5e8197e933c373488b333649
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202641
Reviewed-by: Julius Werner <jwerner@chromium.org>
This is an interim change (before EFS is enabled), align ROM and RAM
stages so that they have enough room and do not step over each other.
BUG=chrome-os-partner:27784
TEST=manual
. booted coreboot successfully on ap148
Change-Id: I6e1710ac7ca494a69aea5ba3b117bfd882aded26
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202046
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Trevor Bourget <tbourget@codeaurora.org>
The driver as it was copied from u-boot provided a function to
transmit multiple characters in one invocation. This feature was not
ported to coreboot, there is no need to maintain the complexity when
only one character at a time is transmitted. It is also very desirable
to get rid of a 1024 byte array allocated on the stack.
The array was necessary to allow to convert multiple newline
characters in the transmit data flow into two character sequences
CRLF. Now just a single word is enough to keep one or two characters
to transmit.
BUG=chrome-os-partner:27784
TEST=verified that coreboot with the new code prints generates console
output.
Change-Id: I73869c5f4ca87210b34811b583386554bafff1e7
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201782
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Trevor Bourget <tbourget@codeaurora.org>
Both DDI ports may be used on this board so it needs to be
able to detect a device on either port.
BUG=chrome-os-partner:28234
TEST=None (needs hardware)
Change-Id: I5fc5ec3fe887fb51e7bdeae43c8297580e0ba6d6
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202358
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The ME debug info is not compiled in when the loglevel is
turned down to save the space of all the strings so the
contents in me_status.c should not be included either.
BUG=chrome-os-partner:28234
TEST=Build and boot with LOGLEVEL=BIOS_ERROR
Change-Id: Ibef46d0da038e13b0de0a29ab038ab6fce395730
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202357
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
- Enable the option to always load the VBIOS even when not executing
- If the option rom is not executed then DDI-A needs to be enabled
for the internal panel to work when the kernel comes up.
BUG=chrome-os-partner:28234
TEST=Build and boot with working OS graphics in normal mode.
Change-Id: I4ebfbf9d8714490dfd2dc2e634928c449719a2bf
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202356
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Define a base address for page table entries. Place it 64KB below the
bootblock loading address.
BUG=chrome-os-partner:28467
TEST=verified that the page tables are being populated at this
address. Also observed that the SPI driver takes 900 ns to
process a byte as opposed to 1.5 us in case caching is not
enabled.
Change-Id: I3d8bd3104c55389aa5768033642ebbf1fda0fec7
Signed-off-by: Deepa Dinamani <deepad@codeaurora.org>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200332
This change updates the cfg file for Hynix/Micron/Samsung 4GB,
792MHz DRAM based on the data generated by t124_emc_reg_tool.
BUG=none
BRANCH=blaze
TEST=emerged coreboot, booted successfully into kernel.
Change-Id: I7621e60d8dcc568e0bb400a6c96b7f8909a15aa6
Signed-off-by: Neil Chen <neilc@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/202059
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Tom Warren <twarren@nvidia.com>
- Update GPIO map
- Update SPD for new memory and 4-bit table decode
- Enable USB3 port 3 and 4 (shared with PCIe port 1)
- Enable PCIe port 3 and disable port 1
- Enable SerialIO ACPI mode for devices
- Disable S0ix for now to prevent use of C10
- Special handling for memory with broadwell CPU
BUG=chrome-os-partner:28234
TEST=Boot on P1.9
Change-Id: If6adcc2ea76f1af7613b715133483d7661e94dd8
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201083
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Put all the SPD related information in one place including
the onboard SPD sources and the board specific parsing.
BUG=chrome-os-partner:28234
TEST=Build and boot on samus
Change-Id: If5cd826ecc9cc856008b7c29aa3cfade5ae7f685
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201082
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
- The old pei_data structure from haswell was still present
- Add a function for romstage to read CPU family/model
- Add quick_ram_check after memory init
BUG=chrome-os-partner:28234
TEST=Build and boot on wtm2 with broadwell CPU
Change-Id: I48ae199351d383796b28197fc0368770cba80ec4
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201690
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Broadwell CPUs can have a region reserved just below TSEG for a
PCODE patch or TXT/BootGuard data. The DPR register reports the
TOP of this region with the size also reported in bits 8:4.
Compute and use the DPR base address as the top of memory for
coreboot.
BUG=chrome-os-partner:28234
TEST=Build and boot on wtm2+broadwell, check that the
usable memory is adjusted by 1MB:
- 3. 0000000000100000-000000007ce3efff: RAM
- 4. 000000007ce3f000-000000007cffffff: CONFIGURATION TABLES
- 5. 000000007d000000-000000007f9fffff: RESERVED
+ 3. 0000000000100000-000000007cd3efff: RAM
+ 4. 000000007cd3f000-000000007cefffff: CONFIGURATION TABLES
+ 5. 000000007cf00000-000000007f9fffff: RESERVED
Change-Id: Ia6ba25bc9992c3a3f859edd8d4a9c64aa42cfa98
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201081
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Broadwell devices have new _HID values, although the kernel
drivers do not seem to treat them differently right now.
ADSP was using an incorrect _HID for lynxpoint devices which
conflicted with the I2C controller.
The SerialIO ACPI devices need custom methods to put the
controller in D0 or D3 state. These need to use the PCIe
config space that is mirrored in BAR1.
Additionally the device should not be put into D3hot state
until after setup is complete, which also means that it needs
to use the BAR instead of PCIe config cycles.
BUG=chrome-os-partner:28234
TEST=boot with devices in ACPI mode and ensure the kernel
I2C driver can bring them out of D3 and initialize them properly.
Also ensure that the driver puts the controller in D3 state
when there is no activity on the bus.
Change-Id: I82a860fceb2a32d9975f93dedcaaf2a48e354d1c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201080
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This commit includes bayleybay board related settings for bring up baytrail crb
BUG=none
TEST=emerge-bayleybay coreboot chromeos-bootimage compile ok.
It can boot to dev chromium desktop without verify boot(due to no TPM built in bayleybay)
Change-Id: I659293d7a8fcdae40b60fd127e19b7284e75aa10
Signed-off-by: Kane Chen <kane.chen@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/201002
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Convert wtm2 board to use the broadwell soc chipset.
BUG=chrome-os-partner:28234
TEST=Build and boot on wtm2 with haswell and broadwell
CQ-DEPEND=CL:201067
CQ-DEPEND=CL:*164226
Change-Id: Ifb0db15cc23a3b66430b32b2ad3f8ab2fb03c4c3
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201070
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The VDDIO to GEN2 I2C SCL/SDA pins is 1.8V and the external
pull-up voltage is 3.3V (the external 3.3V > I/O 1.8V) thus
the pinmux E_OD bit of these two pins needs to be set to
ensure GEN2 I2C pads work fine on 3.3V.
BRANCH=nyan
BUG=none
TEST=observed voltage drop from 3.3V to 2.36V on gen2 i2c
on blaze w/o this change. the waveform looks good on both
scl/sda pins w/ this change.
Change-Id: I1b97f0c9c7580d1e532c3bdf7ac8690241ee7ee3
Signed-off-by: Ken Chang <kenc@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/200996
Reviewed-by: Julius Werner <jwerner@chromium.org>
GPIO init marcos are not enough to initialize different gpio attributes
BUG=none
TEST=emerge-rambi coreboot works well
Change-Id: I193fa7b3e22632cacb555e726e3dd3991f4f4faa
Signed-off-by: Kane Chen <kane.chen@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/200531
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
When doing DP attach, we need to make sure the register change to
take effect immediately, otherwise it may fail to catch the attach
timing.
BRANCH=None
BUG=chrome-os-partner:28128
TEST=Display works and system boots up on Nyan and Big
Change-Id: I569dc435a1aa4aac0d5ecd0655d2ad87a791246d
Signed-off-by: Vince Hsu <vinceh@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/200414
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
We initialized the dc before the plld's initialization. So some
of the dc init settings did not took effect. This patch moves
the clock_display() before the dc init call.
BRANCH=None
BUG=chrome-os-partner:28128
TEST=Display works and system boots up on Nyan and Big
Change-Id: If2c40e2526fdf7a6aa33a2684ba324bd0ec40e90
Signed-off-by: Vince Hsu <vinceh@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/200413
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
There is a hub in USB port2 downstream.
BUG=chrome-os-partner:28964
BRANCH=None
TEST=emerge-nyan_blaze coreboot depthcharge chromeos-bootimage and verify usb
port2 is workable
Change-Id: I0e698970729911f401f89594232f9d49e4da93cc
Signed-off-by: Neil Chen <neilc@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/200417
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Our tests with the I2C bit clear mechanism (recovering from "lost
arbitration" errors) show that the bit clear hardware does not work
correctly in some situations. When a wedged slave device tries to send
more than one 0-to-1-to-0 transition to the host (e.g. leftover bits
from an aborted read), the controller never transitions the BC_ENABLE
bit back to zero.
This patch adds a long timeout to the bit clear code that waits for
register transitions as a safeguard. This way, We will still eventually
exit the function (probably followed by a reboot). Our tests show that
this will recover from all conditions after at most a few reboots.
BRANCH=nyan
BUG=chrome-os-partner:28323
TEST=Ran wedge_ack and wedge_read tests with software_i2c patch, system
recovered as expected in all cases.
Change-Id: I6c37119130e1240e1ef3a5944582abbcd2e39ff0
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200265
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
This patch adds I2C emulation in software through raw toggling of the
SDA/SCL lines. Platforms need to provide bindings to toggle their
respective I2C busses for this to work (e.g. by pinmuxing them as GPIOs,
currently only enabled for Tegra).
This is mostly useful as a debugging feature, to drive unusual states on
a bus and closely monitor the device output without the need of a bus
analyzer. It provides a few functions to "wedge" an I2C bus by aborting
a transaction at certain points, which can be used to test if a system
can correctly recover from an ill-timed reboot. However, it can also
dynamically replace the existing I2C transfer functions and drive
some/all I2C transfers on the system, which might be useful if a driver
for the actual I2C controller hardware is not (yet) available.
Based on original code by Doug Anderson <dianders@chromium.org> and
Hung-ying Tyan <tyanh@chromium.org> for the ChromeOS embedded
controller project.
BRANCH=None
BUG=chrome-os-partner:28323
TEST=Spread tegra_software_i2c_init()/tegra_software_i2c_disable()
through the code and see that everything still works.
Change-Id: I9ee7ccbd1efb38206669a35d0c3318af16f8be63
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198791
Reviewed-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
The kernel will not track wakeup events for devices unless they have
a defined _PRW. There is no EC output of the lid signal coming to
a GPIO and instead it pulses PCH_WAKE#.
BUG=chrome-os-partner:27631
TEST=Manual on Rambi.
- Run lidclose + lidopen on EC console, verify that wakeup_count
increments.
- Run lidclose + lidopen in rapid succession, verify that suspend
request is aborted.
BRANCH=Rambi.
Change-Id: I8d4c58a7bb37d7e474ec094fe96e46e1bfd980de
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200289
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
BUG=none
BRANCH=nyan
TEST=built and booted on Big under various modes, verified that
expected boot mode showed up using "mosys eventlog list"
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I8d98487a2cb910874c8d741008ae59a6c89102e7
Reviewed-on: https://chromium-review.googlesource.com/199691
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The handling of LPDDR is a bit messy in Intel platforms. There
is no traditional SPD so instead one is created by hand from the
provided datasheets.
These have varying (and sometimes unexpected) geometry and it can
be important during bringup to know what configuration is being
passed to the memory training code.
This could in theory be put in a more generic location, but for now
this is the only board with LPDDR3 where I have found it valuable.
BUG=chrome-os-partner:28234
TEST=Build and boot on samus, look for SPD details on the console.
CQ-DEPEND=CL:199920
CQ-DEPEND=CL:199921
CQ-DEPEND=CL:199922
CQ-DEPEND=CL:199943
CQ-DEPEND=CL:*163751
Change-Id: Ibce0187ceb77d37552ffa1b4a5935061d7019259
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199923
Switch from the haswell cpu/northbridge/southbridge interface
to the soc/intel/broadwell interface.
- Use new headers where appropriate
- Remove code that is now done by the SOC generic code
- Update GPIO map to drop LP specific handling
- Update INT15 handlers, drop all but the boot display hook
BUG=chrome-os-partner:28234
TEST=Build and boot on samus
CQ-DEPEND=CL:199920
CQ-DEPEND=CL:199921
CQ-DEPEND=CL:199923
CQ-DEPEND=CL:199943
CQ-DEPEND=CL:*163751
Change-Id: I56f3543612e89e2cdb4256b1bcd4279f5546b918
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199922
This needs to be executed in both romstage and ramstage
for the different PEI binary stages.
It uses the broadwell interface now instead of haswell.
BUG=chrome-os-partner:28234
TEST=Build and boot on samus
CQ-DEPEND=CL:199920
CQ-DEPEND=CL:199922
CQ-DEPEND=CL:199923
CQ-DEPEND=CL:199943
CQ-DEPEND=CL:*163751
Change-Id: Ida05bd17b9e54f08ed0e2767361c9301a2e97709
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199921
The code to find the SPD data for the mainboard based on GPIOs
is moved from romstage.c into spd.c.
It relies on the updated pei_data structure from broadwell instead
of the haswell interface.
BUG=chrome-os-partner:28234
TEST=Build and boot on samus
CQ-DEPEND=CL:199921
CQ-DEPEND=CL:199922
CQ-DEPEND=CL:199923
CQ-DEPEND=CL:199943
CQ-DEPEND=CL:*163751
Change-Id: I5bd56f81884dae117b35a1ffa5fb6e804fd3cb9c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199920
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add support for enabling different coreboot stages (bootblock, romstage and
ramstage) to have arm64 architecture. Most of the files have been copied over
from arm/ or arm64-generic work.
BUG=None
BRANCH=None
TEST=Compiled successfully for rush board with bootblock being armv4 and
romstage and ramstage being armv8
Change-Id: Icd59bec55c963a471a50e30972a8092e4c9d2fb2
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/197397
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
ARM processors save the PC value in the Link Register when they handle
and exception, but they store it with an added offset (depending on the
exception type). In order to make crashes easier to read and correctly
support more complicated handlers in libpayload, this patch adjusts the
saved PC value on exception entry to correct for that offset.
(Note: The value that we now store is what ARM calls the "preferred
return address". For most exceptions this is the faulting instruction,
but for software interrupts (SWI) it is the instruction after that. This
is the way most programs like GDB expect the stored PC address to work,
so let's leave it at that.)
Numbers taken from the Architecture Reference Manual at the end of
section B1.8.3.
BRANCH=none
BUG=chrome-os-partner:18390
TEST=Provoked a data abort and an undefined instruction in both coreboot
and depthcharge, confirmed that the PC address was spot on.
Change-Id: Ia958a7edfcd4aa5e04c20148140a6148586935ba
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199844
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This adds a generic helper function for adding boot reason in the
ChromeOS case. If vboot is enabled, it will use information passed
in via the vboot handoff table in cbmem to determine mode and
reason in the case of recovery.
BUG=chromium:373467
BRANCH=nyan
TEST=built along with follow-up CL and booted on Big under various
modes, verified entry was added to eventlog with "mosys eventlog list"
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I50a7aa6d55eb46413fe9929e732d6eb18c758d4b
Reviewed-on: https://chromium-review.googlesource.com/199690
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Hook the soc/intel/broadwell directory into the configuration
and build system so it can be used by mainboards.
BUG=chrome-os-partner:28234
TEST=build and boot on wtm2
Change-Id: Ia48ac644a8cefb2cf9c64efaa1bd9737ddfb8b1f
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199893
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This provides a driver for the ADSP (aka SST -- smart sound tech)
that is built into the southbridge in haswell/broadwell.
This block shares pins with HDA so they cannot both be enabled at
the same time so if HDA is disabled the pins are routed to the
ADSP block.
The ADSP device needs to be put into ACPI mode so a new block of
BARs and enable status is added to the device_nvs structure.
The ACPI _HID is expected to be different for haswell and broadwell
so a new ACPI method is added to check if the PCH is WildcatPoint
and then used in the base ADSP ACPI device definition.
BUG=chrome-os-partner:28234
TEST=Build and boot on samus with ADSP device enabled and check
firmware log for HDA disabled message and that the HDA PCI device
is gone. With sio_acpi_mode=1 the ADSP PCI device is also gone
and is instead enumerated by ACPI.
Change-Id: I73d950725ce29d44a5da9aab00c7f784ba63f2d1
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199892
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add defines for PCI device+function for SA/PCH devices and
complete the list by adding entries for devices that were missing.
Then make use of these defines in pch.c and serialio.c.
BUG=chrome-os-partner:28234
TEST=Build and boot on wtm2
Change-Id: Id1b284cfab8a72acf040ea1ce1c38324abccc110
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199891
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The two UARTs built into the haswell/broadwell PCH can be used for
standard console output if configured properly. There is a magic bit
in the IOBP settings for the UART device that will put it into "byte
addressing mode" so it is compatible with standard 16550 UART drivers.
When in this mode the linux kernel driver will be unable to talk to
the device so it is indicated as disabled via the ACPI driver.
Note that this by itself is not enough to get working MMIO UART
in coreboot because the current code is heavily tied with the oxpcie
driver. I have a separate set of patches to disentangle the generic
MMIO UART code from the oxpcie driver but I want to get that series
in upstream first.
BUG=chrome-os-partner:28234
TEST=None
Change-Id: I9e689456aa5017784328d1be33ad072f79db1920
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199807
This function will enable the EHCI port 1 on haswell/broadwell
PCH to act as USB debug port. This is hardcoded to port 1.
The EHCI controller must be kept enabled if CONFIG_USBDEBUG
is enabled so this logic is added to the ehci ramstage driver.
BUG=chrome-os-partner:28234
TEST=enable CONFIG_USBDEBUG and build+boot with USB debug output.
Note that libpayload does not support usbdebug yet (I have separate
patches for that) so no payload output is visible.
Change-Id: I704a4786438173b2f3ee2c246636f5a24d8b428c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199412
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
CBMEM IDs are converted to symbolic names by both target and host
code. Keep the conversion table in one place to avoid getting out of
sync.
BUG=none
TEST=manual
. the new firmware still displays proper CBMEM table entry descriptions:
coreboot table: 276 bytes.
CBMEM ROOT 0. 5ffff000 00001000
COREBOOT 1. 5fffd000 00002000
. running make in util/cbmem still succeeds
Change-Id: I0bd9d288f9e6432b531cea2ae011a6935a228c7a
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199791
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The main benefit of adding this skeleton is the addition of the
correct memory map to CBMEM. Attempts to load depthcharge do not fail
because of unavailability of the bounce buffer.
BUG=chrome-os-partner:27784
TEST=boot updated firmware on AP148, observe
CPU: Qualcomm 8064
in the ramstage console output as well as not failing to load
depthcharge any more.
Change-Id: I56c1fa34ce3967852be6eaa0de6e823e64c3ede8
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199675
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
