| Age | Commit message (Collapse) | Author |
|---|
|
Data is intended to be a byte array, so it should be described by a type which
has a fixed size equal to an 8 bit byte. Also, the data passed to write
shouldn't be modified and can be const.
Change-Id: I6466303d962998f6c37c2d4006a39c2d79a235c1
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3721
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This was removed from ramstage a little while ago and should have been removed
from here as well.
Change-Id: I6a40ed4a98bedac39e5492e4b1aed3427ab4e08b
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3720
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This appears to be needed, though we have no way to test yet.
Change-Id: I39033581011e056258193f2cdff78814361a8d55
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3719
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
In resume path, if memory setup takes too long without setting PS_HOLD, EC watch
dog may power off or reboot the system. To prevent that, we should enable
PS_HOLD in same timing as cold boot - right before starting memory setup.
Change-Id: I5c294fa7ae015f8cff57b1fd81e5b80902647b15
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3718
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The functions which manipulated the tps65090 were removed a while ago because
it isn't accessible directly from the AP, it's on an I2C bus that has to be
accessed by the EC on our behalf. Now that that capability has been added, we
can rewrite the small portion of the the tps65090 we actually used but using
the EC passthrough commands.
Also, we should not be configuring the hardware display port hotplug detect
line since we're using it as a GPIO for other purposes. The GPIO we're using
instead defaults to being an input, but to be safe we should probably
explicitly configure it as one anyway.
Change-Id: I7f8a8a767e3cccb813513940a5feceea482982f5
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3717
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: I576d0dbf65693f40d7d1c20d3d5e7a75b8e14dc9
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/3752
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The ChromeOS EC for peach_pit is connected to SPI2 bus, not I2C.
Change-Id: Ifeb8a626aa4fc3d3a181a7bc016e3f91be948ae5
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3716
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The workaround of re-opening device in exynos_spi_read has been fixed by the new
correct open/close and xfer procedure. It's safe to be removed now.
Change-Id: I6b1bf717c916903999a137998a578b0a866829bd
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3715
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Switch spi_xfer and exynos_spi_read to use the new spi_rx_tx function.
Change-Id: I01ab43509df1319672bec30dd111f98001d655d0
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3714
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The SPI driver (exynos_spi_rx_tx) was implemented with only "read" ability and
only full-duplex mode. To communicate with devices like ChromeOS EC, we need
both output (tx) and half-duplex (searching frame header) features.
This commit adds a spi_rx_tx that can handle all cases we need.
Change-Id: I6aba3839eb0711d49c143dc0620245c0dfe782d8
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3713
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The original Exynos SPI open/close procedure was copied from U-Boot SPL with
some assumptions that only works in SPL stage. For example, it tries to always
work in 4-byte transmission mode with only RX data is swapped, and claims a
packet for initial address command (and with incorrect size).
This commit revises open/close and reset so only the required SPI registers are
configured.
Change-Id: Ieba1f03d80a8949c39a6658218831ded39853744
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3712
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Fill the SPI device parameters for spi_setup_slave on Exynos 5420.
Change-Id: I10b4b9e6cfe46d7bfa34e80e3727c7e7da99ba9d
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3711
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The SPI module in Exynos 5420 didn't follow Coreboot's SPI API standard
(spi-generic.h) and will be a problem when we want to share SPI drivers.
This commit replaces exynos_spi_* by spi_* functions.
Note, exynos_spi_read is kept and changed to a static function because its usage
is different from the standard API "spi_xfer".
Change-Id: I6de301bc6b46a09f87b0336c60247fedbe844ca3
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3710
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Remove unused header and constant definition in SPI module.
Change-Id: I339e603f48186e4a356e83518b0d0b4c907f11b8
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3709
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Add SPI0 and SPI2 to Exynos 5 SPI list, and correct structure names.
Also removed the un-enumerated devices (SPI_BASE, base_spi()).
Change-Id: Ica6d9a41f9619c8c61eab664d5e988dd4a428e09
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3708
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
For devices with ChromeOS EC on SPI bus, use the standard SPI driver interface
(see spi-generic.h) to exchange data.
Note: Only EC protocol v3 is supported for SPI bus.
Change-Id: Ia8dcdecd125a2bd7424d0c7560e046b6d6988a03
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3751
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Add the new Chrome EC protocol version 3 to Coreboot.
Note, protocol version 3 is not applied on any bus implementations yet.
LPC (x86) and I2C (arm/snow) are still using v2 protocol. The first one to use
v3 protocol will be SPI bus (arm/pit). LPC / I2C will be updated to v3 only
when they are ready to change.
Change-Id: I3006435295fb509c6351afbb97de0fcedcb1d8c4
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3750
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Since EC protocol v3, the packet format will be the same for all buses (inclding
I2C, SPI, and LPC). That will simplify the implementation in each individual bus
driver source file.
To prepare for that, we will move the protocol part into crosec_proto.c:
crosec_command_proto, with bus driver in callback "crosec_io".
Change-Id: I9ccd19a57a182899dd1ef1cd90598679c1546295
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3749
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The Embedded Controller (EC) for Pit is connected via SPI2, and needs to be
configured before we can talk to it.
Change-Id: I1f8e921b4616f15951f3e5fae1ecbf116de4ba90
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3707
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Some initialization / shutdown commands should be paired correctly in a SPI I/O
session. For example, setting CS should be enabled and disabled in each read;
and the bus width (byte or word) should be configured only when opening /
closing the SPI device.
Change-Id: Ie56b1c3a6df7d542f7ea8f1193ac435987f937ba
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3706
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: Ie347b32575c26133d52c275622d29d1cd4c6c0c7
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3623
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
Change-Id: I4feabc448945c4664d3114c0c8afdad48338230a
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3705
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The functions which checked the status of a transfer would return success if
the bus was no longer occupied, even if it's no longer occupied because the
transfer failed. This change modifies those functions to return three possible
values, 0 if the transfer isn't done, -1 if there was a fault, and 1 if the
transaction completed successfully.
Change-Id: Idcc5fdf73cab3c3ece0e96f14113a216db289e05
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3704
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The exynos manual suggests hooking the mmc ip blocks to the mpll. They had
been set to use a different pll. This changes them over and modifies the
divider so that the frequency stays the same.
Change-Id: I85103388d6cc2c63d1ca004654fc08fcc8929962
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3703
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: I2dc4caa370473dd86fee2b5cc8b1b9eb154b970e
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3702
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This allows us to set different speeds for each HSI2C bus.
Change-Id: I50cc257aad9ef50025d0837b0516940b956efc02
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3701
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This change adjusts some clock settings so that they match U-Boot. There are
three different changes.
1. Change the source for psgen from the oscillator clock to the pclk.
2. Change the pll feeding the SPI busses from epll to mpll, as suggested in
the manual.
3. Change the SPI prescaller.
Change-Id: Ib54a255bc14fc286629dac86db9b8cf8e75a610b
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3700
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The clock divider was being read from registers incorrectly which meant that
the periph rate was wrong.
Change-Id: I50efb62849ef29bdfb0efc56c49642d3edca094c
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3699
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Wait for UART FIFO to be ready.
(Credit to dhendrix for finding the bits to test with.)
Change-Id: Ib6733e422cbc1c61b942bd90d85f88a3f412d6ff
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3698
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Chrome EC protocol V3 has several new command structure and constants defined.
Simply cherry-picking changes from upstream.
Change-Id: I7cb61d3b632ff32743e4fa312e0cc691c1c4c663
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3748
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
... this is needed for libpayload to talk to USB devices.
(forward ported from https://gerrit.chromium.org/gerrit/#/c/55554)
Change-Id: I5a20864689efd0c0149775e6d85b658e0cc6715c
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3697
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
... this is needed for libpayload to talk to USB devices.
Change-Id: I7eb19003c9e96efb5fa7a3f97c7b15f3ef332687
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3696
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: I5cddffc2e524aae7a31a8f94f67e03a5b7e15c82
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3695
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Otherwise we have to worry about hand off between bootblock and
romstage. Too much complexity
Change-Id: I89bf8a229dba7e1330accadf9a732d831ebc4827
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3694
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Found during a perusal of u-boot changes. It looks important.
For more info: http://git.chromium.org/gitweb/?p=chromiumos/third_party/u-boot.git;a=commit;h=56eab63922d2b2380518238ae03e8d69e99af4fe
Change-Id: Ida2fe2a98be008a4bdfe594cf00d01a33b511b4f
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3693
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This is already called in ARMv7 bootblock_simple.c so we don't
want to do it twice
Change-Id: I80cb41035b8a77787e04f2ea58a1cd372cea97d8
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3692
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: I6b28bb95c7decbe3eed33b5b5a029bee48bbe403
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3691
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Currently, the exception handling code on ARM turns on alignment checks as an
easy way to generate an exception for testing purposes. It was leaving it on
which disabled unaligned accesses for other, unlreated code running later.
This change adjusts the code so the original value of the alignment bit is
restored after the test exception.
Change-Id: Id8d035a05175f9fb13de547ab4aa5496d681d30c
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3690
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The GPIOs used by vboot and setting up the display and backlight were still
the ones for snow. This change updates them so they're correct for pit.
Change-Id: I06ba773da3af249efec723bb90c2e9e8075a777a
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3689
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The MAX_CPUS option is only used on x86 currently, so there's no reason to
have it in the pit config.
Change-Id: I270bbfd3aff781d88304791b1d9735777643caab
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3688
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
That part isn't used on pit.
Change-Id: I48f3a10f7e6eb89b1e9630d2372b6865b4c12a7f
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3687
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
On pit, the tps65090 is connected to the EC and has to be accessed by proxy.
Until we have that implemented, this change removes calls to tps69050 which
will never succeed, and stops compiling in the driver.
Change-Id: I7218f85f9f26623bd13aaaf8ded0638b3b2f874a
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3686
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The members data structures in dmc.h are intended to have a particular size.
Rather than assume that particular types are the right size, we should use
types that are guaranteed to be the right size. Also, since the registers are
at particular offsets as well, the structures should be packed.
Change-Id: I9cc11d7451f92ba3eb85c6be88ecbc62c7a5652d
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3685
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The previous driver was a bit awkward and not entirely correct. This change
primarily replaces the read/write functions with simpler and more robust
(hopefully) version.
Change-Id: I55f0ad8faec2de520e27577bd6dad9c0118d8171
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3684
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
For all other CPUs, we unconditionally include the CPU Kconfig
files in the CPU directory, not in the vendor directory. Do the
same thing for the Exynos CPUs. This allows us to make CPU dependent
changes in the directory of that CPU alone.
Also, drop some unused Kconfig variables from the Exynos Kconfig
files.
Change-Id: I4e4c22a0693988834e619dd33d121bf994ed57e8
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3683
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The dmb should be executed before reading operations, and before/after writing
operations.
Change-Id: I572136a2f9a07eb2c38a112f5deeb2de0c0fd46c
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3682
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This updates the low-level I2C code to handle the new high-speed
HSI2C/USI inteface. It also outputs a bit more error information
when things go wrong. Also adds some more error prints. Timeouts
really need to be noted.
In hsi2c_wait_for_irq, order the delay so that we do an initial
sleep first to avoid an early-test that was kicking us out of the
test too soon. We got to the test before the hardware was ready
for us. Finally, test clearing the interrupt status register every time
we wait for it on the write. Works.
Change-Id: I69500eedad58ae0c6405164fbeee89b6a4c6ec6c
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3681
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This updates the setup_power() function to actually set up the PMIC
which is on this board (the MAX77802).
Change-Id: I9c6f21f183dacc0bca71277e681e670834412d78
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3680
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This adds register offsets and important values for the Maxim
MAX77802 PMIC.
Change-Id: I3724b82bcb235b6684d2b976876f628f1ffbed3f
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3747
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
We saw a problem on x86 last year in which setting direction, then value,
glitched the output and caused problems. Change this code to set the output,
then the direction.
Change-Id: I3e1e17ffe82ae270eea539530368a58c6cfe0ebe
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3679
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The 5420 clock code still had a data structure in it for the 5250 clock
registers which was used by some of the clock functions. That caused some
clocks to be configured incorrectly, specifically the i2c clock which was
running at about 80KHz instead of about 600KHz as configured by U-Boot.
Also, the registers and bit positions used to set up the SPI bus were not
consistent with U-Boot, and if the bus clock rate were set to 50MHz, a rate
which has historically worked on snow, loading would fail. With these fixes
the clock rate can be set to 50MHz and the device boots as much as is
expected. I haven't yet measured the actual frequency of the bus to verify
that it's now being calculated correctly.
Change-Id: Id53448fcb6d186bddb3f889c84ba267135dfbc00
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3678
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Tested and working. Gets us to ramstage.
Change-Id: Ib9ea4a6c912e8152246aaf4f1f084a4aa1626053
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3677
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This adds entries for I2C8-10 to giant switch statement in
clock_get_periph_rate(). It also eliminates the I2C peripheral's
usage of clk_bit_info since it's confusing and error-prone.
Change-Id: I30dfc4c9a03fbf16d08e44e074189fb9021edb6d
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3676
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The code has been there for quite a while but was never enabled.
Change-Id: I4ec3dcbb3c03805ac5c75872614e5d394df667cf
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3675
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: I5e0ec360597cd95cb6510fb32b04d8931e6a33db
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3674
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The pinmux code for the exynos5250 was all bundled into a single, large
function which contained a switch statement that would set up the pins for
different peripherals within the SOC. There was also a "flags" parameter, the
meaning of which, if any, depended on which peripheral was being set up.
There are several problems with that approach. First, the code is inefficient
in both time and space. The caller knows which peripheral it wants to set up,
but that information is encoded in a constant which has to be unpacked within
the function before any action can be taken. If there were a function per
peripheral, that information would be implicit. Also, the compiler and linker
are forced to include the entire function with all its cases even if most of
them are never called. If each peripheral was a function, the unused ones
could be garbage collected.
Second, it would be possible to try to set up a peripheral which that function
doesn't know about, so there has to be additional error checking/handling. If
each peripheral had a function, the fact that there was a function to call at
all would imply that the call would be understood.
Third, the flags parameter is fairly opaque, usually doesn't do anything, and
sometimes has to have multiple values embedded in it. By having separate
functions, you can have only the parameters you actually want, give them
names that make sense, and pass in values directly.
Fourth, having one giant function pretends to be a generic, portable API, but
in reality, the only way it's useful is to call it with constants which are
specific to a particular implementation of that API. It's highly unlikely that
a bit of code will need to set up a peripheral but have no idea what that
peripheral actually is.
Call sights for the prior pinmux API have been updated. Also, pinmux
initialization within the i2c driver was moved to be in the board setup code
where it really probably belongs. The function block that implements the I2C
controller may be shared between multiple SOCs (and in fact is), and those
SOCs may have different pinmuxes (which they do).
Other places this same sort of change can be made are the pinmux code for the
5420, and the clock configuration code for both the 5250 and the 5420.
Change-Id: Ie9133a895e0dd861cb06a6d5f995b8770b6dc8cf
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3673
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The memset and memcpy functions are assembled as ARM code, likely because
that's the default of the assembler. Without special annotation, the assembler
and linker don't know that those symbols are functions which need special
handling so that ARM/thumb issues are handled properly. This change adds that
annotation which gets those functions working in Coreboot which is compiled as
thumb. Libpayload and depthcharge are compiled as ARM so they don't *need* the
annotation since it just works out in ARM mode, but it's the safe thing to do
in case we change that in the future.
We should explicitly select ARM vs. thumb when assembling assembly files to be
consistent across builds and toolchains.
Change-Id: I814b137064cf46ae9e2744ff6c223b695dc1ef01
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3672
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
It might be that you want an early console in romstage before RAM is up, but
you can't or don't want to support the console all the way back in the
bootblock. By making the console in those two different environments
configurable seperately that becomes possible.
On the 5250 console output as early as the bootblock works, but on the 5420 it
only starts working in the ROM stage after clocks have been initialized.
Change-Id: I68ae3fcb4d828fa8a328a30001c23c81a4423bb8
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3671
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
There are hundreds of GPIOs on the Exynos5420. Don't
always print all of them per default.
Change-Id: I2152ab760e31a335dbcd9d6ad32cd1eaae4b89bc
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3670
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
remove some unused code
Change-Id: I41602fb391c1910c588a4f9dcc7c2edefe8ab5bc
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3669
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
If we clear the framebuffer and then flush it back to memory using cache
operations, the writes are going to be full cachelines at a time. If we
make it uncacheable first, the writes will be serialized writes of
whatever sized chunks memset uses, probably 4 bytes or less.
Change-Id: I960f87a370e97f9e91236ad796d931573bb3dbb8
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3668
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
At one time it seemed to be necessary to disable and then re-enable the
MMU when setting the framebuffer to be uncache-able due to bugs in the
MMU management code. Since those bugs have been fixed, this is no longer
necessary.
Change-Id: I7ce825cf5eaaa95119364d780cba0935752e4632
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/3667
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The code that allocated space for the framebuffer was adding space for a
vestigial color map which was never used. It was also passing around a
structure which was used to calculate a single value which was already
known when that structure was put together. Eliminate the extra space,
and pass the single value instead of the structure.
Change-Id: I29bc17488539dbe695908e47f0b80c07e102e17d
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/3666
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The code which figured out the rate of the input clock to a peripheral was
doing several things wrong. First, it was using the wrong values when
determing what the source of a clock was set to. Second, it was using the
wrong offset into that register to find the current source setting.
This change fixes the constants which select a clock source which get some
more things working, but doesn't attempt to fix the bit position table.
Change-Id: Id7482ee1c78cec274353bae3ce2dccb84705c66a
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3665
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Not all ARM systems need "BL1", and the layout of BL* and bootblock may be
different (ex, Exynos 5250 may use a new BL1 with variable length checksum
header).
To support that better, define the real base address (and ROM offset) of boot
block, and then we can post-processing ROM image file by filling data / checksum
and any other information.
Change-Id: I0e3105e52500b6b457371ad33a9aa546acf28928
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3664
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
On x86 there is a 16-byte alignment requirement for the
addresses containing the CPU microcode. The cbfs files
containing the microcode are used in memory-mapped fashion
when loading new mircocode. Therefore, the data payload's
address/offset of a cbfs file in flash dictates the resulting
alignment. Fix this by processing the CPU microcode cbfs
file separately as it uses $(CBFSTOOL) to find the proper
location within the provided rom image.
Change-Id: Ia200d62dbcf7ff1fa59598654718a0b7e178ca4c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3663
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The LPC-based ChromeOS EC uses several ioport regions to communicate with
the AP. In order for the new unified userspace access method to work, we
need them to be reserved by the BIOS.
Before /proc/ioports shows:
0800-0803
0804-08ff
We'd like just a single 256-byte region at 0x800, but ASL can't handle that.
So this will work:
0800-087f
0880-08ff
Change-Id: I3f8060bff32d3a49f1488b26830ae26b83dab79d
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: http://review.coreboot.org/3746
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
There are hundreds of GPIOs on the Exynos5250. Don't
always print all of them per default.
Change-Id: Ie349f2a4117883302b743027ed13cc9705b804f8
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3661
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The Chrome EC still does not tolerate SERIRQ in quiet mode
and so the keyboard does not work properly.
Change-Id: I9ab052187c9926ce0e2c86b86dfe987dd6564c1b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/3745
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Now that we are executing VbInit() in coreboot we can end up
in a situation where the recovery reason is consumed during
VbInit (end of romstage) and then the EC is rebooted to RO
during ramstage EC init, thereby losing the recovery reason.
Two possiblities are to remove the EC check+reboot from ramstage
and let it happen in depthcharge. This however means that the
system has to boot all the way into depthcharge and then reboot
the EC and the system again.
Instead if we do a check in romstage before VbInit() is called
then we can reboot the EC into RO early and avoid booting all
the way to depthcharge first.
This change adds a ramstage version the EC init function and
calls it from the shared romstage code immediately after the
PCH decode windows are setup.
Change-Id: I30d2a0c7131b8e4ec30c63eea36944ec111a8fba
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/3744
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
- Updated ec_commands.h is copied in directly from EC repo
- Removed "old" interface and update resources for "new" interface
- Updated temp sensor constants and added "not calibrated"
- Update mainboards to remove check for EC_SWITCH_KEYBOARD_RECOVERY
Change-Id: Ic93c1914f86b6f5bc224178270624ed92b5c1e15
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/3743
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This stuff is not used, so let's drop it.
Change-Id: I671a5e87855b4c59622cafacdefe466ab3d70143
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3660
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
With only 19 source files it doesn't make a whole lot of sense to
create sub directories in arch/armv7, especially since the files
were distributed somewhat randomly.
Change-Id: I029c7848e915edf1737e1c401c034837c95d179d
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3659
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The new code is stolen from U-Boot with little or no understanding of how it
works.
Change-Id: I3de7d25174072f6068d9d4fdaa308c0462296737
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3658
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This function had been declared in a public header file, but was marked
static when actually defined.
Change-Id: Ia551a5a12e7dbaf7bc00861e085695145ab7b91a
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3657
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
- Don't initialize console twice in the bootblock
- remove printk in memory init that would mess up the UART
- unconditionally run console_init() in romstage, as it is
also unconditionally run in the bootblock.
Change-Id: I983d011c6ca602445f447d17799c1b2a33e8bd1d
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3656
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
With LynxPoint-LP the SCI GPE is no longer a GPIO
that is offset by 16. Remove the Add and fix up
the link definition so it is still accurate.
Change-Id: I091141183a09345b5ffe28365583e48019f9f5e5
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/3742
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
If we clear the framebuffer and then flush it back to memory using cache
operations, the writes are going to be full cachelines at a time. If we make
it uncacheable first, the writes will be serialized writes of whatever sized
chunks memset uses, probably 4 bytes or less.
Change-Id: I1b81731cfed00ae091ba6357451ab186d16f559e
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3655
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
At one time it seemed to be necessary to disable and then re-enable the MMU
when setting the framebuffer to be uncache-able due to bugs in the MMU
management code. Since those bugs have been fixed, this is no longer
necessary.
Change-Id: I5f7b9bd14dc9929efe1834ec9a258d388b8c94e9
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3654
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
When modifying the page tables, use writel to ensure the writes happen, flush
the page tables themselves to ensure they're visible to the MMU if it doesn't
look at the caches, and invalidate the right TLB entries.
The first two changes are probably safer but may not be strictly necessary.
The third change is necessary because we were invalidating the TLB using i
which was in megabytes but using an instruction that expects an address in
bytes.
One symptom of this problem was that the framebuffer, which was supposed to be
marked uncacheable, was only being partially updated since some of the updates
were still in the cache. With this change the graphics show up correctly.
Change-Id: I5475df29690371459b0d37a304eebc62f81dd76b
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3653
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The code that allocated space for the framebuffer was adding space for a
vestigial color map which was never used. It was also passing around a
structure which was used to calculate a single value which was already known
when that structure was put together. Eliminate the extra space, and pass the
single value instead of the structure.
Change-Id: Ia6a41cefdf8b29fe7d68f9596a156eced6eb5df8
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3652
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Coreboot knows that, for the snow board, certain pins are to be connected to
bus controllers in the SOC and to the wires of a bus external to the SOC. It
can configure them as such and free its payload from having to know how to
set everything up.
Change-Id: I1bb127c810e9ee077afc4227a6f316eaa53d6498
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3650
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
|
|
Change-Id: Ib0d98e3ab5b2943c36f88765587e8963a4f49604
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/3754
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: I5e4d35572c43f07bec5ec0bcd75c717723228e2f
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/3757
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: I999987af9cb44906e3c3135c0351a0cd6eb210ff
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/3756
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: I53a40d114aa2da76398c5b97443d4096809dcf36
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/3730
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: I1fef27c4a16ee4358ace8014a8d6e9fa92c4f790
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/3728
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: Ifea10f0180c0c4b684030a168402a95fadf1a9db
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/3727
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The page tables need to be aligned to a 16KB boundary and are 16KB in size.
The CBMEM allocator only guarantees 512 byte alignment, so to make sure
things are where they're supposed to be, the code was allocating extra space
and then adjusting the pointer upwards. Unfortunately, it was adding the size
of the table to the pointer first, then aligning it. Since it allocated twice
the space of the table, this had the effect of moving past the first table
size region of bytes, and then aligning upwards, pushing the end of the table
out of the space allocated for it.
You can get away with this if you push things you don't care about off the
end, and it happened to be the case that we were allocating a color map we
weren't using at the start of the next part of cbmem.
Change-Id: I6b196fc573801b02f27f2e667acbf06163266651
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3651
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
These pins will be driven by the internal controller which shouldn't have pull
ups or downs in the pin fighting with them.
Change-Id: I579aed84ace45d8f5f1d3ca64c064d98de842b57
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3649
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: Iac6615240e94c74037afc801169c32d3ebc4ac03
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3648
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
- Guard console_init() with CONFIG_EARLY_CONSOLE in bootblock
- Don't initialize console twice in the bootblock
- remove printk in memory init that would mess up the UART
- unconditionally run console_init() in romstage, as it is
also unconditionally run in the bootblock.
Change-Id: I8f0d60877433162367074d0e55e01f935fd81f8e
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3647
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This change adds a pit mainboard which is mostly a copy of snow, except that
mentions of the 5250 were replaced with the 5420, and mentions of snow were
replaced with pit.
Change-Id: I8eb0ce379eb2fa353bb88d5656a0c5e2290afbf0
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3646
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Some of the settings which were defaulted to or automatically selected for the
exynos5420 which were inherited from the exynos5250 were not correct for this
SOC.
Change-Id: I11ffd8a6b80628405ac493fe2139f79c05d15d7e
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3645
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This change creates an exynos5420 directory with code that will eventually
implement support for the exynos5420 cpu from Samsung. Currently it's a copy
of the exynos5250 directory with the name changed. There are going to be some
problems where headers in src/cpu/samsung/exynos-common include headers in the
exynos5250 directory directly.
Change-Id: Ia8d7244310d32499238bbc171c0c668ec48178e1
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3644
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The Exynos GPIO code has three different APIs that, unfortunately,
were widely used throughout the code base. This patch is cleaning
up the mess.
Change-Id: I09ccc7819fb892dbace9693c786dacc62f3f8eac
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3643
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
When starting the Exynos5250 port, a lot of unneeded u-boot code
was imported. This is an attempt to get rid of a lot of unneeded
code before the port is used as a basis for further ARM ports.
There is a lot more that can be done, including cleaning up the
5250's Kconfig file.
Change-Id: I2d88676c436eea4b21bcb62f40018af9fabb3016
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3642
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: Ice28114e5f53f510d305cd85d095044e2f4bd7b2
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3740
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
|
|
The enumeration results are stored as five DWORDs in one 20 byte buffer.
Bytes 3, 7, 11 and 15 were used to set the lowest bit of each DWORD.
ACPI uses little endian, so 1, 4, 8 and 12 are the correct indices.
Change-Id: I793225cb1bb62fd148ecfa1e61e02f5d7be62cdb
Signed-off-by: Christoph Grenz <christophg+cb@grenz-bonn.de>
Reviewed-on: http://review.coreboot.org/3602
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
It turns out that the exynos5-common code previously imported from
u-boot is not common code at all but very specific to the 5250 and
not compatible with the 5450. Hence, unify the directories exynos5250
and exynos5-common. We will try to factor out common code while
progressing with the 5450 port.
Change-Id: Iab595e66fcd01eda8365c96fb8bef896f7602f03
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3641
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
