This creates a config for the Lenovo T60 sound card based
on values taken from vendor bios
(in /sys/class/sound/hwC0D0/init_pin_configs on linux 3.16).
The sound card configuration on the vendor bios is the same
as the one on the Lenovo x60.
It improves the default behavior of the sound card:
- internal microphone is chosen by default
- when jack is inserted it is chosen instead of internal speaker
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/16529
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Change-Id: I44e3eaac437fe4ad97ff2b0eb32d36b33222c09b
Reviewed-on: https://chromium-review.googlesource.com/384969
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change adds armv7-r support for all stages.
armv7-r is an ARM processor based on the Cortex-R series.
Currently, there is support for armv7-a and armv7-m and
armv7-a files has been modfied to accommodate armv7-r by
adding ENV_ARMV7_A, ENV_ARMV7_R and ENV_ARMV7_M constants
to src/include/rules.h.
armv7-r exceptions support will added in a later time.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Hakim Giydan <hgiydan@marvell.com>
Reviewed-on: https://review.coreboot.org/15335
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Change-Id: If94415d07fd6bd96c43d087374f609a2211f1885
Reviewed-on: https://chromium-review.googlesource.com/384968
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add header files as is from FSP build output.
Move the FSP header files to new location as in apollolake.
Update all the FSP structure references now that they are
typedef'd.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/16517
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I148bff04c064cf853eccaaaf7a465d0079c46b07
Reviewed-on: https://chromium-review.googlesource.com/384967
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In the current implementation of postcar_frame_add_mtrr,
if provided size is bigger than the base address alignment,
the alignment is considered as size and covered by the MTRRs
ignoring the specified size.
In this case the callee has to make sure that the provided
size should be smaller or equal to the base address alignment
boundary.
To simplify this, utilize additonal MTRRs to cover the entire
size specified. We reuse the code from cpu/x86/mtrr/mtrr.c.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/16509
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Ie2e88b596f43692169c7d4440b18498a72fcba11
Reviewed-on: https://chromium-review.googlesource.com/384965
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Move the funtion to find most significant bit set(fms)
and function to find least significant bit set(fls) to a common
place. And remove the duplicates.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/16525
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Ia821038b622d93e7f719c18e5ee3e8112de66a53
Reviewed-on: https://chromium-review.googlesource.com/384964
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
postcar_loader.c has a useful library of funtions for
setting up stack and MTRRs. Make it available in romstage
irrespective of CONFIG_POSTCAR_STAGE for use in stack setup
after Dram init.
The final step of moving the used and max MTRRs on to stack
is moved to a new function, that can be used outside of
postcar phase.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/16331
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I322b12577d74268d03fe42a9744648763693cddd
Reviewed-on: https://chromium-review.googlesource.com/380061
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The serial IRQ configuration register is only 8 bit wide so switch the
PCI access from 16 bits to 8 bits.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/16534
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Change-Id: Ia9fbc02251e00b31440bf103e2afc2ff285b7f2e
Reviewed-on: https://chromium-review.googlesource.com/384961
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
There are shells where the result of a command substitution is subject
to word splitting (e.g. dash when assigning a value inside an export
statement).
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Idwer Vollering <vidwer@gmail.com>
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/15820
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Change-Id: I70a5bc124af7ee621da2bdb4777f3eaba8adafbb
Reviewed-on: https://chromium-review.googlesource.com/384960
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Although the goal was to hide the ME device by disabling
the PCI bridge, the original comment that this bridge was ME related
was a mistake, this bridge is for PEG not for ME.
We still need this PCI bridge "on" to enable pci express graphics
add-on cards.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Damien Zammit <damien@zamaudio.com>
Reviewed-on: https://review.coreboot.org/16496
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Change-Id: Ibf322136097d77a8e7c05dcb14f72da938187a0a
Reviewed-on: https://chromium-review.googlesource.com/383969
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Previously the ME PCI interface (HECI) was being reported as present in
the DMAR ACPI table even when ME firmware was missing or the PCI device
was hidden and HECI would be unresponsive.
Now we check via the PCI config space itself to verify if the HECI
is present or not.
Note that this test could fail if ME firmware is present but
HECI is disabled in devicetree, because it would not advertise that the HECI
exists even though there is a running ME. Perhaps this behaviour is desirable
because in this case you won't see the HECI in the lspci tree anyway.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Damien Zammit <damien@zamaudio.com>
Reviewed-on: https://review.coreboot.org/16330
Tested-by: build bot (Jenkins)
Reviewed-by: Swift Geek <swiftgeek@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Change-Id: Ib692d476d85236b4886ecf3d6e6814229f441de0
Reviewed-on: https://chromium-review.googlesource.com/383694
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch makes strtok_r:
- handle the end of the string
- handle string that contains only delimiters
- do not set ptr outside of str
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Jeremy Compostella <jeremy.compostella@gmail.com>
Reviewed-on: https://review.coreboot.org/16524
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Change-Id: I49925040d951dffb9c11425334674d8d498821f1
Reviewed-on: https://chromium-review.googlesource.com/383692
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
With a SPI clock above about 24MHz the APB cannot keep up when doing
individual byte transfers. Adjust the driver to use 16-bit reads when
it can, to remove this bottleneck.
Any transaction which involves writing bytes still uses 8-bit transfers,
to simplify the code. These are the transfers that are not time-critical
since they tend to be small. The case that really matters is reading from
SPI flash.
In general we can use 16-bit reads anytime we are transferring an even
number of bytes. If the code detects an odd number of bytes, it tries to
perform the operation in two steps: once in 16-bit mode with an even
number of bytes, and once in 8-bit mode for the final byte. This allow
us to use 16-bit reads even if asked to transfer (for example) 0xf423
bytes.
The limit on in_now and out_now is adjusted to 0xfffe to avoid an extra
transfer when transferring ~>=64KB.
CQ-DEPEND=CL:383232
BUG=chrome-os-partner:56556
BRANCH=none
TEST=boot on gru and see that things still work correctly. I tested (with
extra debugging) that the 16-bit case is being picked when it should be.
Change-Id: Idc5b7e5d82cdbdc1e8fe8b2d6da819edf2d5570c
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/381312
Commit-Ready: Julius Werner <jwerner@chromium.org>
Tested-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Several of the special function pins we're using in firmware have a
pre-assigned pull-up or pull-down on power-on reset. We don't want those
to interfere with any of the signaling we're trying to do on those pins,
so this patch disables them.
Also do some house-cleaning to group the bootblock code better, and
change the setup code for all SPI and I2C buses to first initialize the
controller and then mux the pins... I assume this might be a little
safer (in case the controller peripheral has some pins in a weird state
before it gets fully initialized, we don't want to mux it through too
early).
BRANCH=None
BUG=chrome-os-partner:52526
TEST=Booted Kevin.
Change-Id: I6bcf2b9a5dc686f2b6f82bd80fc9a1a245661c47
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/382532
Output GPIOs should never have a pull-up or pull-down resistor attached
since they're actively driven. Since some GPIOs get initialized with a
pull at power-on reset, we should explicitly overwrite that setting.
Most other platforms do this on gpio_output, but Rockchip hadn't yet.
Also, shuffle some code around to make things cleaner and allow for
easier code reuse.
BRANCH=None
BUG=chrome-os-partner:52526
TEST=Booted Kevin.
Change-Id: I044266d71ef8bd0518316ff72d829d1ca1e30f35
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/382531
Reviewed-by: Simon Glass <sjg@google.com>
Move the current devicetree.cb to be under variants/baseboard.
New variants can provide their own devicetree as needed.
BUG=chrome-os-partner:56677
BRANCH=None
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16510
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Change-Id: Ib109ca4be883884b318264500d14aa8d40e3072a
Reviewed-on: https://chromium-review.googlesource.com/382722
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The early TPM probe was done directly in tis.c ignoring the lower
layer that provides appropriate access to the chip. Move this into
a tpm_vendor_probe() function so it can use iic_tpm_read() with all
of the built-in delays and semantics instead of calling i2c_readb()
directly from the wrong layer.
This fixes early init failures that were seen with the cr50 i2c tpm
on the reef mainboard.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16527
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Change-Id: I9bb3b820d10f6e2ea24c57b90cf0edc813cdc7e0
Reviewed-on: https://chromium-review.googlesource.com/382721
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Enable the hexdump function in verstage as it can be useful there for
debugging I2C and TPM transactions.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16528
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Change-Id: If9dc4bcc30964e18ff5d8a98559f6306c0adec6f
Reviewed-on: https://chromium-review.googlesource.com/382720
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
For an unknown reason the printed address in the SPI debug messages is
modified before it is printed by subtracting the constant 0xf020 from
the passed in address.
What I suppose this debug code should do is to print the used register
address within the SPI controller while any parts of this address that
belongs to the SPI base address should be omitted. To fix that remove
the subtraction of 0xf020 and adjust the address mask to 0x3ff so that
only the offset to the registers inside the SPI controller will be
visible in the debug messages.
In addition switch to uint8_t and friends over u8 to sync up with used
types in this file.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/16500
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: York Yang <york.yang@intel.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Change-Id: I93ba7119873115c7abc80a214cc30363a6930b3b
Reviewed-on: https://chromium-review.googlesource.com/382719
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Hardcoding the microcode filenames into the makefiles is great when
the microcode is in the blobs directory. When the microcode isn't
posted to the blobs directory, we need some method of supplying the
microcode binary into the build. This can of course be done manually
after the build has completed, as can be done with everything that
we're including in the ROM image. Instead of making life hard for
everyone though, let's just add a way to specify where the microcode
rom comes from.
BUG=chrome-os-partner:53013
BRANCH=None
TEST=None
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://review.coreboot.org/16386
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Omar Pakker
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I7c5127234809e8515906efa56c04af6005eecf0b
Reviewed-on: https://chromium-review.googlesource.com/382718
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Similarly to 2b2f465fcb
"mb/gigabyte/ga-g41m-es2l: Fix ACPI IRQ settings for SATA"
SATA must function in "plain" mode because it does not work in
"combined" mode.
Tested on d945gclf
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/16319
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Change-Id: I2e051a632a1341c4932cf86855006ae517dbf064
Reviewed-on: https://chromium-review.googlesource.com/382716
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
we found some board not stable when sdram run 933Mhz, before we fix
it, we need to lower down the sdram frequency to 800MHz. In this patch
we modify the DQS delay from 0x280 to 0x260, extend the DQS window.
BRANCH=None
BUG=chrome-os-partner:56940
TEST=Booted Kevin.
Change-Id: I5eab6bbe96f0dae095c5353403292022e7a25421
Signed-off-by: Lin Huang <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/382724
Commit-Ready: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Increase the SPI bus speed to speed up boot time. The maximum supported
speed at 1.8V is 37.5MHz, and 33MHz is the next lowest convenient speed,
given the clock parents.
BUG=chrome-os-partner:56556
BRANCH=none
TEST=boot on gru and see that things still work correctly. Total time
spent on reading from SPI reduces from 185ms to 141ms.
Change-Id: I55a19f523817862e081d23469e94fd795456dd67
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/381313
Commit-Ready: Julius Werner <jwerner@chromium.org>
Tested-by: Simon Glass <sjg@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
At higher SPI bus speeds the SPI RX value is not available in time for
sampling at the normal time. Add a delay to ensure that we read the
correct data.
The value of 40ns is chosen arbitrarily. In my testing I can use a sample
delay of 1 even at 24MHz. But since it is not necessary, I have left that
case alone. It kicks in at 25MHz and up.
BUG=chrome-os-partner:56556
BRANCH=none
TEST=boot on gru and see no change at current speed
Change-Id: I65d66d752cbbbee4d02f475de23a52069a0e9782
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/381311
Commit-Ready: Julius Werner <jwerner@chromium.org>
Tested-by: Simon Glass <sjg@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Switch the BL31 (ARM Trusted Firmware) format to payload so that it can
have multiple independent segments. This also requires disabling the region
check since SRAM is currently faulted by that check.
This has been tested with Rockchip's pending change:
https://chromium-review.googlesource.com/#/c/368592/3
with the patch mentioned on the bug at #13.
BUG=chrome-os-partner:56314
BRANCH=none
TEST=boot on gru and see that BL31 loads and runs. Im not sure if it is
correct though:
CBFS: Locating 'fallback/payload'
CBFS: Found @ offset 1b440 size 15a75
Loading segment from ROM address 0x0000000000100000
code (compression=1)
New segment dstaddr 0x18104800 memsize 0x117fbe0 srcaddr 0x100038 filesize 0x15a3d
Loading segment from ROM address 0x000000000010001c
Entry Point 0x0000000018104800
Loading Segment: addr: 0x0000000018104800 memsz: 0x000000000117fbe0 filesz: 0x0000000000015a3d
lb: [0x0000000000300000, 0x0000000000320558)
Post relocation: addr: 0x0000000018104800 memsz: 0x000000000117fbe0 filesz: 0x0000000000015a3d
using LZMA
[ 0x18104800, 18137d90, 0x192843e0) <- 00100038
Clearing Segment: addr: 0x0000000018137d90 memsz: 0x000000000114c650
dest 0000000018104800, end 00000000192843e0, bouncebuffer ffffffffffffffff
Loaded segments
BS: BS_PAYLOAD_LOAD times (us): entry 0 run 125150 exit 1
Jumping to boot code at 0000000018104800(00000000f7eda000)
CPU0: stack: 00000000ff8ec000 - 00000000ff8f0000, lowest used address 00000000ff8ef3d0, stack used: 3120 bytes
CBFS: 'VBOOT' located CBFS at [402000:44cc00)
CBFS: Locating 'fallback/bl31'
CBFS: Found @ offset 10ec0 size 8d0c
Loading segment from ROM address 0x0000000000100000
code (compression=1)
New segment dstaddr 0x10000 memsize 0x40000 srcaddr 0x100054 filesize 0x8192
Loading segment from ROM address 0x000000000010001c
code (compression=1)
New segment dstaddr 0xff8d4000 memsize 0x1f50 srcaddr 0x1081e6 filesize 0xb26
Loading segment from ROM address 0x0000000000100038
Entry Point 0x0000000000010000
Loading Segment: addr: 0x0000000000010000 memsz: 0x0000000000040000 filesz: 0x0000000000008192
lb: [0x0000000000300000, 0x0000000000320558)
Post relocation: addr: 0x0000000000010000 memsz: 0x0000000000040000 filesz: 0x0000000000008192
using LZMA
[ 0x00010000, 00035708, 0x00050000) <- 00100054
Clearing Segment: addr: 0x0000000000035708 memsz: 0x000000000001a8f8
dest 0000000000010000, end 0000000000050000, bouncebuffer ffffffffffffffff
Loading Segment: addr: 0x00000000ff8d4000 memsz: 0x0000000000001f50 filesz: 0x0000000000000b26
lb: [0x0000000000300000, 0x0000000000320558)
Post relocation: addr: 0x00000000ff8d4000 memsz: 0x0000000000001f50 filesz: 0x0000000000000b26
using LZMA
[ 0xff8d4000, ff8d5f50, 0xff8d5f50) <- 001081e6
dest 00000000ff8d4000, end 00000000ff8d5f50, bouncebuffer ffffffffffffffff
Loaded segments
INFO: plat_rockchip_pmusram_prepare pmu: code d2bfe625,d2bfe625,80
INFO: plat_rockchip_pmusram_prepare pmu: code 0xff8d4000,0x50000,3364
INFO: plat_rockchip_pmusram_prepare: data 0xff8d4d28,0xff8d4d24,4648
NOTICE: BL31: v1.2(debug):
NOTICE: BL31: Built : Sun Sep 4 22:36:16 UTC 2016
INFO: GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3
INFO: plat_rockchip_pmu_init(1189): pd status 3e
INFO: BL31: Initializing runtime services
INFO: BL31: Preparing for EL3 exit to normal world
INFO: Entry point address = 0x18104800
INFO: SPSR = 0x8
.
Change-Id: I2d60e5762f8377e43835558f76a3928156acb26c
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/376849
Commit-Ready: Simon Glass <sjg@google.com>
Tested-by: Simon Glass <sjg@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Bring in this useful function from Linux 4.7.
BUG=chrome-os-partner:56556
BRANCH=none
TEST=build on gru
Change-Id: I37617e35b4784d6cdc51e6910aa91f566caf971d
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/382320
Reviewed-by: Julius Werner <jwerner@chromium.org>
Some of the asserts for valid clock divisor ranges were off by one. This
patch corrects them and writes them all in a consistent way.
BRANCH=None
BUG=None
TEST=Booted Kevin.
Change-Id: I429edb99e2d5ff2302d9750e6569b3d21f5686fa
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/381574
Reviewed-by: Simon Glass <sjg@chromium.org>
This patch fixes a typo in the clock initialization code that caused the
PERILP1_PCLK_HZ constant to be ignored and the clock to always run at
the same speed as its parent (PERILP1_HCLK_HZ). Since we've done all our
previous tests and validation with this bug, we should probably increase
the value of the constant (that had not actually been used) to the value
that we had been incorrectly using instead (which also makes effective
SPI read times faster).
BRANCH=None
BUG=chrome-os-partner:56556
TEST=Booted Kevin.
Change-Id: Icb5e079f53eb22b0dbf0ea4d1c2ff08688e3fa8e
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/381031
Reviewed-by: Simon Glass <sjg@chromium.org>
