This patch brings in ipq806x source files from the vendor's u-boot
tree as it was published in the 'cs_banana' release.
The following files are being copied:
arch/arm/cpu/armv7/ipq/clock.c => src/soc/qualcomm/ipq806x/clock.c
arch/arm/cpu/armv7/ipq/gpio.c => src/soc/qualcomm/ipq806x/gpio.c
arch/arm/cpu/armv7/ipq/timer.c => src/soc/qualcomm/ipq806x/timer.c
arch/arm/include/asm/arch-ipq806x/clock.h => src/soc/qualcomm/ipq806x/clock.h
arch/arm/include/asm/arch-ipq806x/gpio.h => src/soc/qualcomm/ipq806x/gpio.h
arch/arm/include/asm/arch-ipq806x/gsbi.h => src/soc/qualcomm/ipq806x/gsbi.h
arch/arm/include/asm/arch-ipq806x/iomap.h => src/soc/qualcomm/ipq806x/iomap.h
arch/arm/include/asm/arch-ipq806x/timer.h src/soc/qualcomm/ipq806x/timer.h
arch/arm/include/asm/arch-ipq806x/uart.h => src/soc/qualcomm/ipq806x/uart.h
board/qcom/ipq806x_cdp/ipq806x_cdp.c => src/mainboard/google/storm/cdp.c
board/qcom/ipq806x_cdp/ipq806x_cdp.h => src/soc/qualcomm/ipq8064/cdp.h
drivers/serial/ipq806x_uart.c => src/console/ipq806x_console.c
Note that local timer.c gets overwritten with the original version. To
prevent a build breakage some shortly to be reverted modifications had
to be made to src/soc/qualcomm/ipq806x/Makefile.inc and
src/soc/qualcomm/ipq806x/cbfs.c.
BRANCH=none
BUG=chrome-os-partner:27784
TEST='emerge-storm coreboot' still succeeds
Change-Id: I3f50bfbec2e18a3b5d2c640cff353a26f88c98c1
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193722
Reviewed-by: David Hendricks <dhendrix@chromium.org>
A per target config template is required to allow the build system to
produce images. Add a template for storm.
BRANCH=none
BUG=chrome-os-partner:27784
TEST=manual
$ USE=fwserial emerge-storm coreboot
$ grep '^C.*CONSOLE' /build/storm/firmware/coreboot.config
CONFIG_DEFAULT_CONSOLE_LOGLEVEL=8
CONFIG_MAXIMUM_CONSOLE_LOGLEVEL=8
CONFIG_CONSOLE_SERIAL=y
CONFIG_CONSOLE_SERIAL_115200=y
CONFIG_MAXIMUM_CONSOLE_LOGLEVEL_8=y
CONFIG_DEFAULT_CONSOLE_LOGLEVEL_8=y
Change-Id: I9840c1c986788cf36d346d838ff59fe9015ddb07
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193724
Reviewed-by: David Hendricks <dhendrix@chromium.org>
BUG=chrome-os-partner:27094
BRANCH=None
CQ-DEPEND=CL:191031
CQ-DEPEND=CL:191622
TEST=Built and vbooted through depthcharge on nyan.
Change-Id: Idba8f28ed96fb37bb38ab5c05942bdd5bc2efcd3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/191535
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The cbmem console had been explicitly disabled in the bootblock because of
the complexity of handing off the console from the bootblock to the ROM stage.
The fixed cbmem location means no handoff is really necessary, so these can
be re-enabled.
Also include some other shared console drivers if they and bootblock console
have been enabled.
BUG=None
TEST=Built and booted on nyan and saw bootblock console output in cbmem. Built
for falco.
BRANCH=None
Change-Id: Iffe2747d6d526b58fabb0195f8744ae420f2e19d
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/193168
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The new API is in use in depthcharge and is based around the "i2c_transfer"
function instead of i2c_read and i2c_write. The new function takes an array of
i2c_seg structures which represent each portion of the transfer after a start
bit and before the stop bit. If there's more than one segment, they're
seperated by repeated starts.
Some wrapper functions have also been added which make certain common
operations easy. These include reading or writing a byte from a register or
reading or writing a blob of raw data. The i2c device drivers generally use
these wrappers but can call the i2c_transfer function directly if the need
something different.
The tegra i2c driver was very similar to the one in depthcharge and was simple
to convert. The Exynos 5250 and 5420 drivers were ported from depthcharge and
replace the ones in coreboot. The Exynos 5420 driver was ported from the high
speed portion of the one in coreboot and was straightforward to port back. The
low speed portion and the Exynos 5250 drivers had been transplanted from U-Boot
and were replaced with the depthcharge implementation.
BUG=None
TEST=Built and booted on nyan with and without EFS. Built and booted on, pit
and daisy.
BRANCH=None
Change-Id: I1e98c3fa2560be25444ab3d0394bb214b9d56e93
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/193561
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Jimmy Zhang <jimmzhang@nvidia.com>
Tested-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
In E-EDID(EDID v1.3), Monitor Name (0xfc) and Monitor Range Limits (0xfd) are
always required. However, some panels do not really have these fields. As a
workaround (and since we don't really use these fields), we only print warning
messages for that case.
BUG=chrome-os-partner:27413
TEST=emerge-nyan coreboot chromeos-bootimage
Successfully decoded Nyan panels.
BRANCH=none
Change-Id: I81b1db7d7f6c6f9320a862608dec4c7be298d7db
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193742
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
We want the coreboot build produce an image which can be run on the
target, even if the remaining parts of the bootprom (recovery path,
read-write stages, gbb, etc.) are not available yet.
This is achieved by including the Qualcomm SBLs blob in the bootblock.
CQ-DEPEND=CL:193518
BRANCH=None
BUG=chrome-os-partner:27784
TEST=manual
. run the following commands inside chroot to confirm expected image
layout (no actual code is executed on the target yet):
$ emerge-storm coreboot
$ \od -Ax -t x1 -v /build/storm/firmware/coreboot.rom 2>/dev/null | head -1
000000 d1 dc 4b 84 34 10 d7 73 15 00 00 00 ff ff ff ff
$ \od -Ax -t x1 -v /build/storm/firmware/coreboot.rom | grep 220000
220000 05 00 00 00 03 00 00 00 00 00 00 00 00 00 01 2a
Change-Id: I10e8b81c7bd90e4550a027573ad3a26c38c3808a
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193540
Ipq8064 SBLs initialize the hardware to prepare it to run an arbitrary
user provided bootloader. The only bootloader requirements imposed by
the SBLs are that it is concatenated with the SBL chunks in the
bootprm AND it uses MBN encapsulation (mostly to specify the size and
load address).
This patch adds configuration options to specify the location of the
SBL blobs and to require MBN encapsulation of the bootblock.
BRANCH=none
BUG=chrome-os-partner:27784
TEST=manual
- the below demonstrates added encapsulation, no code run attempts
have been made yet:
$ FEATURES=noclean emerge-storm coreboot
$ cd /build/storm/tmp/portage/sys-boot/coreboot-9999/work/coreboot-9999
$ \od -t x4 build/cbfs/fallback/bootblock.bin | head -3
0000000 00000005 00000003 00000000 2a010000
0000020 00000be0 00000be0 2a010be0 00000000
0000040 2a010be0 00000000 e32bf0df e59f0030
Change-Id: Iae30ad08059e2b35c434ac25a410ac2017752957
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193511
If it's not supported on a particular board, either the build will fail or
checks within the cbmem console itself should detect the problem. There
shouldn't be random memory corruption any more.
BUG=None
TEST=Built with CONSOLE_CBMEM enabled on nyan and saw that it was actually
enabled.
BRANCH=None
Change-Id: Id6c8c7675daafe07aa4878cfcf13faefe576e520
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/193167
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The current CBMEM console implementation can work in two different ways, one
that requires CAR migration which doesn't make sense on ARM and will break the
build, and a second which assumes 0x600 is a valid memory address which can be
used to keep track of the current location of the console. Neither of those
work on ARM.
To get around that problem, this change adds yet another flavor of behavior
to the cbmem console driver where it assumes the console is in a fixed place
before RAM is initialized (bootblock and ROM stage) and in CBMEM afterwards
(RAM stage). More specifically, the location of the console is always fixed
in a particular stage, attempts to set it are ignored, it's only initialized
in the earliest stage it's enabled, and cbmem reinitialization and migration
is ignored in RAM stage.
We really need to rework all the twisted paths through this code and reduce
it to one implementation that makes sense and works in all the situations it
needs to without all the extra complexity.
BUG=None
TEST=Built and booted on nyan with other changes that enable the console.
Ran cbmem -c and verified that output was preserved. Did the same on falco.
BRANCH=None
Change-Id: I05e75448be8572e2736d4d0e04997e536fb69396
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/193166
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
This symbol is set using a config variable which can be set to something
appropriate by the SOC. If it isn't, the symbol is set to 0 which should be
caught by checks in the cbmem console itself.
BUG=None
TEST=Built for nyan with a cbmem buffer location set. Built for peach_pit
without a location set.
BRANCH=None
Change-Id: I92cd65bb6767a67637faf1dd3cdbe03e433724a9
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/193165
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
With following settings
1.Coreboot 25Mhz
2.Maxim codec configured with MCLK=25Mhz
2.I2C 400Khz fixed
4.Including Enable/Disable SHDN bit when LRCLK starts/Stops
5.Removed PLL toggle workaround routine.
audio playing is smooth before/after S3, no noise when recording so change
MCLK from 19.2 back to 25Mhz.
BUG=chrome-os-partner:26948
BRANCH=firmware-rambi-5216
TEST=test audio play and record on Rambi, works fine.
Change-Id: I5602feb39721344feab837ff4a3a18309a47a6a6
Signed-off-by: Kein Yuan <kein.yuan@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/193881
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
On non-x86 systems, the location of the preram CBMEM console may not be in a
predictable place relative to other things in the linker script. That makes it
difficult to work with as its own section because the linker will complain if
you try to move backwards as it lays out memory. If the console header is
treated as an actual blob of memory which has to be put in the image, we'd
have to predict where to put it so that it isn't before something with a lower
address or after something with a higher address. Symbols, on the other hand,
can be defined arbitrarily.
BUG=None
TEST=Built and booted on link and falco. Spot checked that the CBMEM console
was the same as the output on the serial port.
BRANCH=None
Change-Id: I3257b981eee0c15bb997a9f2c55a03494c6ec6f0
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/193164
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Set the appropriate config options and make the appropriate calls
to perform vboot verification. The flashmap offset as well as the TPM
information needs to be properly set. Lastly, call into
vboot_verify_firmware() to perform the vboot verification when it is
enabled.
BUG=chrome-os-partner:27094
BRANCH=None
TEST=Built vboot verification on nyan.
Change-Id: I6113badd6143008ceb2b80f0ec0832e1addd03d7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/190928
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
I don't even know why these were off (at least the XHCI one)... well,
now they aren't. As far as coreboot is concerned, Snow is just a test
platform anyway, and these are useful to have.
BUG=None
TEST=It works.
Change-Id: Ibef65e8be6cf752276ffc87df6dda04869dd97cd
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193733
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
We've recently fixed a problem where an external hard drive would choke
due to one too many CLEAR_FEATURE(HALT) commands in the XHCI stack with
"libpayload: usb: xhci: Fix STALL endpoint handling". Clearing stall
conditions from within the transfer function is wrong in general... this
is really something that is host controller agnostic and should be left
to the higher-level driver to decide. The mass storage driver (the only
one that should really encounter stalls right now) already contains the
proper amount of clear_stall() calls... any more than that is redundant
and as we found out potentially dangerous.
This patch removes automatic clear stalls from UHCI and OHCI drivers as
well to make things consistent between host controllers.
BUG=chromium:192866
TEST=None. I could borrow the original hard drive from Shawn and compile
a Snow to only use the OHCI driver to reproduce/verify this, but alas, I
am lazy (and it's really not that important).
Change-Id: Ie1e4d4d2d70fa4abf8b4dabd33b10d6d4012048a
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193732
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
This patch combines a few minor fixes and refactoring to the various
host controller and root hub drivers to ensure they all do the right
thing on a call to usb_exit(). It puts a usb_detach_device(0) call
into detach_controller() so that the HCD doesn't need to remember to
tear down the root hub itself, and makes sure all root hubs properly
detach the subtree of devices connected to their ports first (as
generic_hub and by extension XHCI had already been doing).
It also fixes up some missing free() calls and replaces most 'ptr =
malloc(); if (!ptr) fatal()' idioms with the new x(z)alloc().
BUG=chromium:343415
TEST=Tested EHCI on Big and OHCI, EHCI, and XHCI on Snow. Could not test
UHCI (unless anyone volunteers to port coreboot to a ZGB? ;) ), but the
changes are really tame.
Change-Id: I6eca51ff2685d0946fe4267ad7d3ec48ad7fc510
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193731
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
This patch enables the OHCI driver to use DMA memory, which is necessary
for ARM systems where DMA devices are not cache coherent. I really only
need this to test some later OHCI changes, but it was easy enough...
copied almost verbatim from ehci.c.
BUG=chromium:343415
TEST=Works on Snow.
Change-Id: Ia717eef28340bd6182a6782e83bfdd0693cf0db1
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193730
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
- The hotplug register doesn't work in the way we describe. Just leave
it at default.
- The backlight registers will be configured by the OS driver.
BUG=chrome-os-partner:27304
TEST=Manual on Rambi. Boot system in both dev and normal mode, verify
that display comes up. Also verify that display functions after warm
reboot and suspend / resume.
BRANCH=rambi+squawks
Change-Id: I5559c131f41c4a14e64e5cec66e18d3a4a46092c
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193830
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Modify the utility to become a Linux executable. While at it, fix the
program name reported by error messages.
BRANCH=None
BUG=chrome-os-partner:27784
TEST=manual
$ ./util/ipqheader/ipqheader.py
ipqheader.py: incorrect number of arguments
Usage: ipqheader.py <base-addr> <input-file> <output-file>
Change-Id: I25061d43fdea72655a696deb9e494e9c7382f670
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193495
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
This is an as is copy of the tool provided by the vendor. It adds a
header which tells the early stage loader where to load the next phase
blob for execution. It is going to be used to encapsulate the
bootblock.
Usage of this tool is as follows:
ipqheader.py <base-addr> <input-file> <output-file>
BRANCH=None
BUG=chrome-os-partner:27784
TEST=none yet
Change-Id: I448c006719f4f3dd5a6716ff2e47f7fc275c805e
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193494
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
RAM module for RAMCODE 0010 (K4B4G1646Q) does not work with
hynix-2GB-204MHz configuration. We need to replace it by
hynix-2GB-792MHz. Also updated hynix-2GB-792MHz configuration
from Nyan board folder. This commit is only for bring up stage.
Once finish dram stress test, will update it again.
BRANCH=none
BUG=chrome-os-partner:27682
TEST=emerge-nyan_blaze coreboot builds OK; flash to blaze board and
boot to kernel successfully
Change-Id: Idfc503c944ac6120c92a4cf329f3fbe63b2c2a1c
Signed-off-by: Neil Chen <neilc@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/193737
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
There are some unexpected symbol at the end of each line in the
generated .inc file when the config file is DOS format (CR+LF).
Modify cfg2inc to support DOS format cfg file.
BUG=chrome-os-partner:27614
TEST=sudo cfg2inc.sh XXX.cfg # make a expected inc file
BRANCH=nyan
Signed-off-by: Neil Chen <neilc@nvidia.com>
Change-Id: I68b0f4b3805fcb5a6b633653c95afbafcb880a93
Reviewed-on: https://chromium-review.googlesource.com/192697
Tested-by: Neil Chen <neilc@nvidia.com>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Neil Chen <neilc@nvidia.com>
EDID v1.4 has changed some fields (0xfc - Monitor Name, 0xfd - Monitor Range
Limits) to optional so we need to list the requirements explicitly instead of
sharing v1.3 requirements.
BUG=chrome-os-partner:25933
TEST=emerge-nyan coreboot chromeos-bootimage
Successfully decoded Nyan panels.
BRANCH=none
Change-Id: I5c7ca06893bd20e178bc35164c4ca639c881e00b
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193013
The detail block may contain timing descriptor, or other fields like monitor
descriptor, so we should return 1 in detailed_block function when a valid
structure is found, otherwise for any EDID containing monitor descriptor we will
see following error messages:
EDID block does not conform at all!
Detailed blocks filled with garbage
BRANCH=none
BUG=chrome-os-partner:25933
TEST=emerge-nyan coreboot chromeos-bootimage;
Manually executed on a Nayn and not seeing error message like
"Detailed blocks filled with garbage".
Also tried EDID from following devices: Link, Peppy. Display panel
initialization is still functional.
Change-Id: Ib4e91d648741e5b54a558d53a1152273c7341427
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193002
The ASCII Data String in EDID Monitor Descriptor (3.10.3) is "Stored as ASCII,
code page #437" and may contain special characters like '-'. The isalnum check
should be removed.
Also, the "Monitor Name" (0xfc) does not need to always end with 0Ah, so the
name_descriptor_terminated should be replaced by has_valid_string_termination.
BRANCH=none
BUG=chrome-os-partner:25933
TEST=emerge-nyan coreboot chromeos-bootimage;
Sucessfully decoded Monitor Descriptor with dash symbol (-) on Nyan.
Also tried EDID from following devices: Link, Peppy. Display panel
initialization is still functional.
Change-Id: I12a670237e12577fc971c0fbd9b2a61c82040ad3
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193001
When parsing "extensions", we should skip the first EDID (main) block and start
from offset 128 (EDID may have only main block, so an EDID without any
extension is fine) because the header format for main block and extensions are
different.
Without this we will see "Unknown extension block" on all EDIDs, and seeing a
error (1) return value for EDIDs without extension.
Also, after the first "unknown" error is fixed, we can now collect all return
values from parse_extension, and give error when any of the extensions are wrong
(not just last one).
BRANCH=none
BUG=chrome-os-partner:25933
TEST=emerge-nyan coreboot chromeos-bootimage
Manually boot on Nyan and no "Unknown extension block" anymore.
Also tried EDID from following devices: Link, Peppy. Display panel
initialization is still functional.
Change-Id: I0ee029ac8ec6800687cd7749e23989399e721109
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193011
To set the 8 different BCT as hynix-2GB-204 first. Once the
corresponding BCT release from AE, change it.
BRANCH=none
BUG=None
TEST=emerge-nyan_blaze coreboot builds OK
Signed-off-by: Neil Chen <neilc@nvidia.com>
Change-Id: Ia42a4a5b85c561421ab8ae9aaf21c46a3c0a3513
Reviewed-on: https://chromium-review.googlesource.com/191682
Tested-by: Neil Chen <neilc@nvidia.com>
Reviewed-by: Artiste Hsu <chhsu@nvidia.com>
Reviewed-by: Katie Roberts-Hoffman <katierh@chromium.org>
Commit-Queue: Neil Chen <neilc@nvidia.com>
The EC doesn't seem to be able to handle its bus running at 4 MHz or higher.
To avoid it not being able to keep up, we reduce the frequency of that bus on
all nyan derivatives to 3 MHz. Because PLLP can't be divided that low, we
switch the clock source to CLKM.
BUG=chrome-os-partner:22849
TEST=Built and booted on nyan.
BRANCH=None
Change-Id: I8f31b41098d64634427b4686f5333012f643fada
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/193349
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Consolidate the register setting clrsetbits_le32 call to simplify the macros.
Add a check for bits of the divisor being dropped. The clock source registers
will throw away bits that aren't supported, so we can check for divisor
overflow by checking for dropped bits.
BUG=None
TEST=Purposefully tried to set a clock to a rate which overflows its divisor.
Verified that the check triggered. Booted on nyan. Verified the TPM i2c bus
frequency was still correct.
BRANCH=None
Change-Id: I3b1b6ba57f6b7729f303d15a16b685a48751d41f
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/193348
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
To ensure that the command1 write which sets the "go" bit completes before
other reads to the device. Otherwise, there's a race condition where those
register values might still have their values from the last transfer. With
different SPI clock frequencies, that could lead to spi_delay being told there
were negative bytes still to send. Its expected delay would wrap to a negative
value, that was passed to udelay, and the system would sit there for 4 seconds
not doing anything.
BUG=None
TEST=Built and booted on nyan. Set the SPI bus frequency to a value which was
causing the 4+ second delay and verified that it no longer happened.
BRANCH=None
Change-Id: I8b4090efc69f34d0413e3f63c59c1825dd151cec
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/193347
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
This fixes two problems with the clock configuration on tegra124. First, the
macro which set up the i2c clocks tried to account for the fact that the i2c
divisor's lsb represents 1.0 where it normally represents 0.5 by multiplying
the target frequency by 2. That doesn't work, unfortunately, because the
divisor is actually n + 1, and what n + 1 means depends on where the one's
place is in the divisor.
Also, when calculating the divisor, the standard C division operator uses
truncation to deal any remainder which tends to make the divisor smaller. That
has the effect of making the output frequency higher than what was requested.
Since it's usually safer to undershoot a frequency than overshoot it, this
change makes those divisions round up instead.
Finally, the hand tuned temporary UART clock configuration was adjusted so
that it still ends up with the same divisor. Without that, very early output
from the bootblock is garbled, specifically the coreboot welcome banner,
build timestamp, etc.
BUG=chrome-os-partner:27220
TEST=Built and booted on nyan. Used a logic analyzer to verify that the TPM
i2c bus ran at 400KHz instead of 660KHz, and that the divisor was the expected
value. Measured boot time with and without EFS and verified that there was no
change. Spot checked the output for errors and verified that none of the
bootblock output was garbled.
BRANCH=None
Change-Id: I7e948c361ed4bf58c608627d32f2e3424faea1fb
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/193362
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
To read EDID, we need to access I2C via DP AUX channel.
BRANCH=none
BUG=chrome-os-partner:25933
TEST=emerge-nyan coreboot chromeos-bootimage
Change-Id: I2666b5d46843485b79265a537f19bd8eab5e1a26
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/188858
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Turns out that when you clear 28 bits starting with bit 3, you leave bit
31 standing. Ooops...
This shouldn't really matter since that bit is reserved/SBZ in CLIDR
anyway, but it's still nice to fix it. This whole thing should really be
an AND for clarity anyway in my opinion.
Bug found in upstream NetBSD (who would've thought...).
BUG=None
TEST=Still boots.
Change-Id: Ic826e82d58fd1ce984971afea3dfa9296f746d9f
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193300
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Some lines in decode_edid have incorrect indent levels.
BUG=none
TEST=emerge-nyan coreboot
BRANCH=none
Change-Id: Icc9cb57ff8dd2e2056599b3dc733fe5ac4e41c16
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193010
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Provide the option to embed MRC as an ELF file and not just
binary blob. This allows for MRC to be relocated.
BUG=chrome-os-partner:27654
BRANCH=rambi
TEST=Built and booted rambi.
Change-Id: I2e177c155a3074e4e1d450b1a73b7299aebd5286
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/192893
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This patch adds the 10ms TRSTRCY delay between a reset and the following
Set Address command that is required by the USB 2.0 specification to the
EHCI root hub driver. The generic_hub driver that's used for XHCI and
external hubs already included this delay. This is such a glaring
violation of the spec that I'm really amazed how many USB 2.0 devices
we tested before seemed perfectly fine with responding to a Set Address
within 2 microframes of the reset...
It also increases the port reset hold delay by one millisecond to avoid
an ugly race condition on Tegra SoCs: they decided to time the 50ms
themselves instead of relying on the CPU to do it (fair enough), and to
automatically transition Port Reset to 0 and Port Enable to 1 after that
(bad idea). If the CPU's read-modify-write to clear Port Reset races
exactly with the host controller setting Port Enable, we may end up
clearing the bit again and going into the companion controller handoff
path later on. The added millisecond shouldn't cause any problems for
other host controllers and is not a big deal compared to other delays in
this code path.
BUG=chrome-os-partner:26749
TEST=Run several dozen reboot loops with The USB Stick of Death (TM) (a
blue Patriot XT 13fe:5200 with bcdDevice = 1.00), make sure it always
gets detected correctly.
Change-Id: Idd3329ae6d7e5e1c07a84a5475549b3459836b31
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/189872
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Jim Lin <jilin@nvidia.com>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
If EFS is enabled and vboot didn't tell us it's going to use the display, we
can skip initializing it and save some boot time.
BUG=chrome-os-partner:27094
TEST=Built and booted on nyan without EFS in recovery mode and normal mode.
Built and booted on nyan with EFS in recovery mode and normal mode. Verified
that in normal mode with EFS the display initialization was skipped and boot
time was essentially the same as when display initialization was simply
commented out.
BRANCH=None
Change-Id: I1e2842b57a38061f40514407c8fab1e38b75be80
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/192544
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Though vboot could be built for arm platforms the resulting
code was not being included in the cbfs. Now conditionally
include the vboot rmdoule like x86.
BUG=chrome-os-partner:27094
BRANCH=None
TEST=Built nyan with vboot. Confirmed being added to cbfs.
Change-Id: I677d0bf16dc488cf2d5b75dd1a65cf123d3ad9d2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/190927
In order to build rmodules for armv7 boards, the default
compiler options need to be set so the assembler sources
can correclty compile. For now assume rmodules for arm
devices use the ramstage compiler options.
BUG=chrome-os-partner:27094
BRANCH=None
TEST=Built vboot as rmodule for nyan.
Change-Id: I8d12a2a57944b187cbdff2f22176de5b4de87a54
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/190926
The non-x86 systems need the monotonic timer interface.
Add tegra124's timer implementation so vboot can link.
BUG=chrome-os-partner:27094
BRANCH=None
TEST=Built nyan with vboot verfication.
Change-Id: I75b99b6e07eeab0324495f97472f14a36883161e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/190925
Depending on the platform the underlying regions vboot requires
may not be accessible through a memory-mapped interface. Allow
for non-memory-mapped regions by providing a region request
abstraction. There is then only a few touch points in the code to
provide compile-time decision making no how to obtain a region.
For the vblocks a temporary area is allocated from cbmem. They
are then read from the SPI into the temporarily buffer.
BUG=chrome-os-partner:27094
BRANCH=None
TEST=Built and booted a rambi with vboot verification.
Change-Id: I828a7c36387a8eb573c5a0dd020fe9abad03d902
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/190924
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
- Remove the call to clear_stall in xhci_reset_endpoint because we will
call clear_stall from the mass-storage driver.
- Remove the xhci_reset_endpoint call from xhci_bulk on STALL since we
will reset on the next transfer anyway.
- Remove the clear_halt parameter from xhci_bulk since it's now unused.
BUG=chrome-os-partner:26687
TEST=Manual on Rambi w/ USB_DEBUG enabled in libpayload. Boot with SanDisk
Extreme USB 3.0 drive in USB 3.0 port, verify that after STALL is
encountered reset succeeds and device is initialized without extra
delay.
BRANCH=Rambi
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I852b87621861109e596ec24b78a8f036d796ff14
Reviewed-on: https://chromium-review.googlesource.com/192866
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Whenever spi_xfer is called and whenver it's implemented, the natural unit for
the amount of data being transfered is bytes. The API expected things to be
expressed in bits, however, which led to a lot of multiplying and dividing by
eight, and checkes to make sure things were multiples of eight. All of that
can now be removed.
BUG=None
TEST=Built and booted on link, falco, peach_pit and nyan and looked for SPI
errors in the firmware log. Built for rambi.
BRANCH=None
Change-Id: I02365bdb6960a35def7be7a0cd1aa0a2cc09392f
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/192049
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
They were only used internal to the SPI drivers and, according to the comment
next to their prototypes, were for when the SPI controller doesn't control the
chip select line directly and needs some help.
BUG=None
TEST=Built for link, falco, and rambi. Built and booted on peach_pit and nyan.
BRANCH=None
Change-Id: If4622819a4437490797d305786e2436e2e70c42b
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/192048
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
