BRANCH=none
BUG=chrome-os-partner:27413
TEST=build nyan and nyan_big. nyan display works fine.
nyan_big display still does't work until all related
patches are built in. (CL:194739)
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Change-Id: Ic5d977f695be127693f1ecc3ba52d478f524d20f
Reviewed-on: https://chromium-review.googlesource.com/194737
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
Correct SOR attaching sequence.
https://chromium-review.googlesource.com/190300
BRANCH=none
BUG=chrome-os-partner:27413
TEST=build nyan and nyan_big. nyan display works fine.
nyan_big display still doesn't work until all related
patches are built in. (CL:194737 and CL:194739)
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Change-Id: I8aaf65db90e5e45bd9097c9d38b231bd7d41d997
Reviewed-on: https://chromium-review.googlesource.com/194403
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
Some kconfig options have changed but the configs haven't been updated. When
make oldconfig is run from the ebuild through emake, that doesn't seem to
causea problem for whatever reason. When run manually, however, kconfig stops
to ask for each config it doesn't have a value for. This change updates the
configs to correct that issue.
BUG=None
TEST=Ran make oldconfig manually for all boards. Built and booted on big.
BRANCH=None
Change-Id: I138f8ad9239a3834d28dc492e0a90a94442b2af1
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/194908
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tegra124 family products may want to use many different display panels with
various timing settings. To support them, we should initialize display panel by
EDID instead of hard-coded values.
BUG=none
TEST=emerge-nyan coreboot chromeos-bootimage
BRANCH=none
Change-Id: Ib125a7f9cb1e6c8cf2d79e0baab525acfd1b7a6e
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/192730
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
According to DP version 1.2a, The MOT (Middle-of-Transaction) bit
must be set when the I2C transaction does not stop with the current
AUX transaction.
Thus the correct steps for an I2C read shall be:
1. I2C command write with MOT set to 1
2. I2C command read to the same address with MOT set to 0
BUG=chrome-os-partner:27679
TEST=EDID data read from LP140WH8 panel is correct while it's a
repeated pattern of the first 16 bytes without this CL
BRANCH=none
Change-Id: I0526beffb8852fbbe0eb5bb80e370261617a59b8
Signed-off-by: Ken Chang <kenc@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/194915
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Similar to the W25Q64DW, the W25Q32DW has basically the same
attributes as the earlier W25Q32 parts but with a different
value in the MSB of the ID.
BUG=none
BRANCH=none
TEST=tested on nyan, now SPI flash commands actually work.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I697768a443c98515d893f9cf8f8b4258ae0f159d
Reviewed-on: https://chromium-review.googlesource.com/191205
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
The old print simply said "Got idcode". This makes it actually
display what it got.
BUG=none
BRANCH=none
TEST=tested on nyan
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I8f1c8fde6e4ac00b12e74f925b7bcff83d1f69f3
Reviewed-on: https://chromium-review.googlesource.com/191204
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
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>
These drivers are needed right away and never really fit into depthcharge's
driver model anyway.
CQ-DEPEND=CL:194064
BUG=None
TEST=Built and booted nyan, link, and peach_pit and verified that timer values
in cbmem were reasonable. Built for nyan_big, nyan_blaze and daisy.
BRANCH=None
Change-Id: Ia7953cfece57524262a6c7d6537082af7a00f4d6
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/194058
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
These drivers need to be ready right away and never really fit into the
depthcharge driver model anyway.
CQ-DEPEND=CL:194063
BUG=None
TEST=Built and booted on nyan and peach_pit. Built for nyan_big, nyan_blaze,
and daisy.
BRANCH=None
Change-Id: I9570dee53c57d42ef4cd956f66a878ce39a2dc20
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/194057
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@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>
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>
