This replaces a hard-coded bus number of 0 with a Kconfig variable,
CONFIG_BOOT_MEDIA_SPI_BUS. This removes an assumption made for x86
where this value is always 0 and makes it easy to add support for
other platforms where the bus number for the backing SPI flash is
more arbitrary.
BUG=none
BRANCH=none
TEST=tested on Nyan (bus=4) and Link (bus=0)
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I1e878a1628af7f4ccc2f39a70b2190192767e536
Reviewed-on: https://chromium-review.googlesource.com/194854
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
PLLD, the clock for display, was previously hard-coded to 306MHz. To support
more different panels, we should calcualte PLLD by panel pixel clock
configuration.
Note existing pixel clock configurations for nyan* boards won't work (they used
to rely on hard-coded approximated values) so the device trees are also
modified.
BRANCH=none
BUG=chrome-os-partner:25933
TEST=emerge-nyan_big coreboot chromeos-bootimage
See panel correctly initialized and got DEV screen.
Change-Id: I8d592f0cc044e7c4e4803c45955642e791210ad3
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193565
BOOT_MEDIA_SPI_BUS is a Kconfig variable used on some ARM-based
platforms to set up CBFS media. It turns out it can also be helpful
for setting up the eventlog which is intended to reside on the same
SPI flash as CBFS. Setting it for x86 will allow us to remove an
assumption about which SPI bus is used for this flash device.
Long term this can go away as we come up with a better abstraction
for the eventlog's backing store. This is only intended to help us
get from here to there.
BUG=none
BRANCH=none
TEST=built and booted on Link
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I1d84dc28592fbece33a70167be59e83bca9cd7bc
Reviewed-on: https://chromium-review.googlesource.com/191202
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
This adds a missing dma_release() at the end of DMA transfers. It
probably doesn't matter since we don't do many DMA transfers, though
I wouldn't want to hit some corner case with EFS and eventlog.
BUG=none
BRANCH=none
TEST=tested on nyan
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I79b30455babe75a13aac827caac88bf7053ec9e4
Reviewed-on: https://chromium-review.googlesource.com/194479
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
It worked earlier since the APB and AHB bus widths occupy the same bits
in their respective registers.
BUG=none
BRANCH=none
TEST=tested on Nyan
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I9b18c648c60dcc4ad62ca1f514d253f8cccaeee7
Reviewed-on: https://chromium-review.googlesource.com/194478
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
GPIO_PU4/PH1 and _PU5/PH2 were set to use the same PWM1/2 SFIO.
Even though no problems were caused by this, correct it here
so we get a conflict-free pinmux map.
BUG=chrome-os-partner:27091
BRANCH=none
TEST=Built and booted on Nyan, ran TegraShell "pinmux check"
and saw no conflicts.
Change-Id: Ib16341aa0c92b9a078d7f3254d4151e9592f40b0
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/194582
Reviewed-by: David Hendricks <dhendrix@chromium.org>
href_to_sync and vref_to_sync are chip specific settings. Currently
they are set to 1/2 of hfront_porch and vfront_porch respectively.
However, to support EDID (CL192730), per David Ung, the safe
values for both are 1 (the same settings as in kernel).
BUG=none
BRANCH=none
TEST=built and booted on nyan.
Change-Id: Ifb8898e720a160ba044e2b526de2a4d17bc63672
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/193504
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
This change takes about 8K of space away from the cbfs cache and repurposes
it for the cbmem console buffer. This is a little more than twice the space
we currently need for the bootblock and ROM stage to give us some room to grow
and for extra debug output if needed.
BUG=None
TEST=Built and booted on nyan. Checked the cbmem output.
BRANCH=None
Change-Id: I6543bf5efddcf2377528a273f846b8090cd8be55
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/193169
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
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>
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>
- 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>
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>
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>
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>
