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>
In https://chromium-review.googlesource.com/181272 the payload->type has been
changed to big-endian (network ordering) but the cbfs_image is still parsing
type as host ordering, which caused printing cbfs image verbosely
(cbfstool imge print -v) would fail to find entry field and print numerous
garbage output.
Payload fields should be always parsed in big-endian (network ordering).
BUG=none
TEST=make; cbfstool image.bin print -v -v -v # see payloads correctly
Change-Id: If1ac355b8847fb54988069f694bd2f317ce49a1a
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200158
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Libpayload libc requires timer clock frequency to be at least 1MHz.
Ipq8064 code presently provides a single option of 32kHz. Pretend to
be running at 1 MHz without additional accuracy.
This is a hack which will be reverted as soon as the SOC is configured
to supply a faster running clock.
BUG=chrome-os-partner:27784, chrome-os-partner:28880
TEST=with other changes depthcharge boots to the CLI console
Change-Id: I80ec6652bc5693a549668cd6e824e9cf5c26b182
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201342
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The earlier compilation warning fix (7e4aa17) incorrectly assumed that
selfboot() is a function defined in the cbfs driver. This is a
commonly available function, it should not come from cbfs.h.
BUG=none
TEST=the following command succeeds:
$ for b in rambi storm nyan_big; do
cros_workon-$b start libpayload
emerge-$b libpayload || break
done
Change-Id: I3ef49d849168ad9dc24589cbd9ce7382052345bd
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201386
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>
This is still using the 32kHz timer coreboot uses. A finer granularity
timer implementation for 806x is in the works.
BUG=chrome-os-partner:27784,chrome-os-partner:28880
TEST=none yet.
Change-Id: Iae206749000d45040090df48199c8d86d76bbae5
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198021
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
As the USB driver for storm hardware is not yet available, do not
define it in llibpayload.
BUG=chrome-os-partner:27784
TEST=not much testing yet, just compilation/building
Change-Id: I6aea72cda33b61deb0a7dc69f8295f8c3f61406b
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200827
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>
The -z "${V}" sure must have meant to be -n "${V}", but come to think
of it, this check is not necessary, as the following check will
succeed if and only if V is set to 1.
BUG=none
TEST=verified that adding V=1 to the environment causes the lpgcc
debug statements to show up in the output.
Change-Id: I1eb43ef49aeb4f16aef4fbee3a1037e853f9b40f
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200501
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Make sure the build breaks in case of warnings.
BUG=none
TEST=run the following command with the previous patch removed and
then restored:
$ for b in rambi storm nyan_big; do
cros_workon-$b start libpayload
emerge-$b libpayload
done
all builds succeed with the restored patch and fail when a
compilation warning is thrown.
Change-Id: I9bdcd8938f59913e4ba86df5e4921b3f821ef920
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200110
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Seems that the 'if (cursor_enabled)' check in
video_console_fixup_cursor() that was removed in commit 1f880bca0 really
meant to check for 'if (console)'. Looks like the whole video console
driver is built extra robust to not fail no matter how screwed up the
console is, so let's add this missing check here as well. Also fixed up
a few other missing 'if (!console)' checks while I'm at it.
However, what payloads should really be doing is check the return value
of video_(console_)init() and not call the other video functions if that
failed. This also adapts video_console_init() to correctly pass through
the return value for that purpose (something that seems to have been
overlooked in the dd9e4e58 refactoring).
BUG=chrome-os-partner:28494
TEST=None. I don't know what Dave did to trigger this in the first
place, but it's pretty straight-forward.
Change-Id: I1b9f09d49dc70dacf20621b19e081c754d4814f7
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200688
Reviewed-by: David Hendricks <dhendrix@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>
When emerging libpayload a warning is generated about selfboot() being
defined without a prior prototype.
Addinf cbfs.h when CBFS use if compiled fixes the warning.
BUG=none
TEST=run the following
$ for b in rambi storm nyan_big; do
cros_workon-$b start libpayload
emerge-$b libpayload
done
verify that there is no compilation warnings thrown any more
Change-Id: Ic9cb5571f708bb006a0d477e451fd1f3b3eb833f
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200099
Reviewed-by: Hung-Te Lin <hungte@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>
The video console runs a video_console_fixup_cursor() function after
every printed character to make sure the cursor is still in the output
window and avoid overflows. For some crazy reason, this function does
not run when cursor_enabled is false... however, that variable is only
about cursor *visibility*, and it's imperative that we still do proper
bounds checking for our output even if the cursor itself doesn't get
displayed (otherwise we can end up overwriting malloc cookies that cause
a panic on the next free() and other fun things like that).
In fact, there seems to be no reason at all to even keep track of the
cursor visibility state in the generic video console framework (the
specific backends already do it, too), so let's remove that code
entirely. Also set the default cursor visibilty in the corebootfb
backend to 0 since that's consistent with what the other backends do.
BUG=None
TEST=Turn on video console on Big, generate enough output to make it
scroll, make sure it does not crash.
Change-Id: I1201a5bccb4711b6ecfc4cf47a8ace16331501b4
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196323
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
The calling convention of payload entry function is different by architecture.
For example, X86 takes no arguments and ARM needs first param to be a
cb_header_ptr*.
To help payloads load and execute other payloads easily and correctly, we should
provide the selfboot() function in libpayload, using same prototype as defined
in Coreboot environment.
BUG=none
TEST=emerge-nyan libpayload # pass
BRANCH=none
Change-Id: I8f1cb2c0df788794b2f6f7f5500a3910328a4f84
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199503
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
The libpayload build environment has been changed slightly and here are the
minimal changes to compile ubootcli under ebuild system:
- Allow overriding LIBPAYLOAD_DIR.
- Include only single libpayload.a.
- Revise build flags.
- Increase heap/stack size so video console init is fine.
- Remove abort() which may be defined in libpayload.
- Change weak link default function to non-inline (so it will be provided).
BUG=none
TEST=With a crafted ubootcli.ebuild:
emerge-nyan ubootcli # arm pass
emerge-rambi ubootcli # x86 pass
Change-Id: Icd3bd9f29a3682cd1a2c148a2a57ce44efe33664
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199476
Reviewed-by: Julius Werner <jwerner@chromium.org>
Some EABI conformant toolchains like GCC need additional functions like raise.
To prevent payloads adding arch-specific implementations everywhere, we should
provide the default version in libpayload.
BUG=none
TEST=emerge-nyan libpayload # pass
BRANCH=none
Change-Id: Id1e3c29590aa5881aefd944a7551949ce9a47b8f
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199686
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>
Dynamic cbmem support has been enabled on storm, but the proper
initialization at romstage is missing.
Proper DRAM base address definition is also necessary so that CBMEM is
placed in the correct address range (presently at the top of DRAM).
BUG=chrome-os-partner:27784
TEST=build boot coreboot on ap148, observe the following in the
console output:
Wrote coreboot table at: 5fffd000, 0xe8 bytes, checksum 44a5
coreboot table: 256 bytes.
CBMEM ROOT 0. 5ffff000 00001000
COREBOOT 1. 5fffd000 00002000
Change-Id: I74ccd252ddfdeaa0a5bcc929be72be174f310730
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199674
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Include the required modules in romstage and enable early console.
BUG=chrome-os-partner:27784
TEST=observe the romstage prompt in the console output:
coreboot-4.0 romstage Tue May 13 17:08:58 PDT 2014 starting...
Change-Id: Ie3853b9afc53246e6eb997f279ccd4dbb08f748b
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199673
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Eliminate duplicated printout and if needed, print only changed
information.
BUG=none
TEST=verified that the 'New segment dstaddr...' message is not
duplicated anymore
Change-Id: Ia13593394fccbb225f2bd9ab2b9228bac29d50fb
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199672
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This is just a convenience - when printing a pre-ram coreboot banner,
add the actual stage name to it.
BUG=none
TEST=manual
. with CONFIG_EARLY_CONSOLE enabled the banners look as follows (the
last one is for ramstage reads 'booting' instead of 'starting'):
coreboot-4.0 bootblock Tue May 13 14:13:37 PDT 2014 starting...
coreboot-4.0 romstage Tue May 13 14:13:37 PDT 2014 starting...
coreboot-4.0 Tue May 13 14:13:37 PDT 2014 booting...
Change-Id: I218c0d3bbfa4a9bdff5632855c520af8626d6495
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199671
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
