Age | Commit message (Collapse) | Author |
|
This patch removes a lot of code duplication between the virtually
identical Veyron Chromebook variants by merging the code into a single
directory and handling the different names solely within Kconfig. This
also allows us to easily add all the other Chromebook variants that have
only been kept in Google's firmware branch to avoid cluttering coreboot
too much, making it possible to build these boards with upstream
coreboot out of the box.
The only effective change this will have on the affected boards is
removing quirks for early board revisions (since revision numbers differ
between variants). Since all those quirks concerned early pre-MP
revisions, I doubt this will bother anyone (and the old code is still
available through the Google firmware branch if anyone needs it). It
will also expand a recent fix in Jerry that increased an LCD power-on
delay to make it compatible with another kind of panel to all boards,
which is probably not a bad idea anyway.
Leaving all non-Chromebook boards as they are for now since they often
contain more extensive differences.
BRANCH=None
BUG=None
TEST=Booted Jerry.
Change-Id: I4bd590429b9539a91f837459a804888904cd6f2d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 10049a59a34ef45ca1458c1549f708b5f83e2ef9
Original-Change-Id: I6a8c813e58fe60d83a0b783141ffed520e197b3c
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/296053
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11555
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
As per discussion with lawyers[tm], it's not a good idea to
shorten the license header too much - not for legal reasons
but because there are tools that look for them, and giving
them a standard pattern simplifies things.
However, we got confirmation that we don't have to update
every file ever added to coreboot whenever the FSF gets a
new lease, but can drop the address instead.
util/kconfig is excluded because that's imported code that
we may want to synchronize every now and then.
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} +
$ find * -type f
-a \! -name \*.patch \
-a \! -name \*_shipped \
-a \! -name LICENSE_GPL \
-a \! -name LGPL.txt \
-a \! -name COPYING \
-a \! -name DISCLAIMER \
-exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} +
Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9233
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
|
|
in depthcharge we will use "backlight" gpio which in lb_gpio table
to control backlight, we use lcd_bl before, but it will not meet
the backlight power sequence, so we change it to bl_en.
BUG=chrome-os-partner:37348
TEST=Boot from speedy, and backlight work well
BRANCH=None
Change-Id: I19e488c7d3f1fe5cb91f8a93fae6b848f58b36b7
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: cb594ce612e1cedeabced4531fbd954f3698da98
Original-Change-Id: Ib0dac7c48bce7d0b28ec287b32d8c5bad575893f
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/259900
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9864
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This patch is a raw application of the following spatch to src/:
@@
expression A, V;
@@
- writel(V, A)
+ write32(A, V)
@@
expression A, V;
@@
- writew(V, A)
+ write16(A, V)
@@
expression A, V;
@@
- writeb(V, A)
+ write8(A, V)
@@
expression A;
@@
- readl(A)
+ read32(A)
@@
expression A;
@@
- readb(A)
+ read8(A)
BRANCH=none
BUG=chromium:444723
TEST=None (depends on next patch)
Change-Id: I5dd96490c85ee2bcbc669f08bc6fff0ecc0f9e27
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 64f643da95d85954c4d4ea91c34a5c69b9b08eb6
Original-Change-Id: I366a2eb5b3a0df2279ebcce572fe814894791c42
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/254864
Reviewed-on: http://review.coreboot.org/9836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Many ChromeOS devices use a GPIO to reset the system, in order to
guarantee that the TPM cannot be reset without also resetting the CPU.
Often chipset/SoC hardware watchdogs trigger some kind of built-in
CPU reset, bypassing this GPIO and thus leaving the TPM locked. These
ChromeOS devices need to detect that condition in their bootblock and
trigger a second (proper) reboot.
This patch adds some code to generalize this previously
mainboard-specific functionality and uses it on Veyron boards. It also
provides some code to add the proper eventlog entry for a watchdog
reset. Since the second reboot has to happen before firmware
verification and the eventlog is usually only initialized afterwards, we
provide the functionality to place a tombstone in a memlayout-defined
location (which could be SRAM or some MMIO register that is preserved
across reboots).
[pg: Integrates
'mips: Temporarily work around build error caused by <arch/io.h> mismatch]
BRANCH=veyron
BUG=chrome-os-partner:35705
TEST=Run 'mem w 0xff800000 0x9' on a Jerry, watch how a "Hardware
watchdog reset" event appears in the eventlog after the reboot.
Change-Id: I0a33820b236c9328b2f9b20905b69cb934326f2a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: fffc484bb89f5129d62739dcb44d08d7f5b30b33
Original-Change-Id: I7ee1d02676e9159794d29e033d71c09fdf4620fd
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/242404
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Id: c919c72ddc9d2e1e18858c0bf49c0ce79f2bc506
Original-Change-Id: I509c842d3393bd810e89ebdf0dc745275c120c1d
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/242504
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9749
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
BUG=chrome-os-partner:34436
BRANCH=none
TEST=Built and booted on pinky w/ depthcharge fmap patch,
used mosys to verify that eventlog entries get populated:
entry="0" timestamp="2015-01-06 13:45:33" type="Log area cleared" bytes="4096"
entry="1" timestamp="2015-01-06 13:45:33" type="System boot" count="0"
entry="2" timestamp="2015-01-06 13:45:33" type="Chrome OS Developer Mode"
Change-Id: I74ba8b271328453c8b91f11e7858754a80806c31
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 197010f057f4835a30ed2e71f47ca51fc181afe4
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: I19cb884be5c3e00975599e96e0223e33d32e7c0d
Original-Reviewed-on: https://chromium-review.googlesource.com/238830
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Julius Werner <jwerner@chromium.org>
Original-Tested-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9644
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
we use the delay 200ms to meet the edp power timing request before,
it waste time, so we use the HPD function to detect the edp panel now.
In previous version, the hardware may not support the edp HPD function,
so in the code it will spend 200ms to detect hpd single, if it don't get
the hpd single, it will contiue the edp initialization process, to compatible
all of the hardware version.
BUG=chrome-os-partner:35623
TEST=Boot from Mighty, and display normal
BRANCH=None
Change-Id: I82c6a80e37fa42eef3521e6ebbf190d7e80fcece
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 7a5343eb9af12cae9a15284217762a91ae24bac6
Original-Change-Id: I21c0ef6ce4643e90a192d8b86659264895b5fda9
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/242792
Original-Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-on: http://review.coreboot.org/9659
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
backlight timing: LED_VCC->LED_PWM->LED_EN, we modify the
code to meet the timing.
BUG=chrome-os-partner:36201
TEST=Boot from jerry, and scope the backlight timing
BRANCH=None
Change-Id: I6bfa6af176400086e4af0112a63127c1152ca70e
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 52ac0b2944cea7dc860bfea12fe44851436bb7f7
Original-Change-Id: I6c53a822410ad706383c6d9fa2b5f0437775f710
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/244639
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9658
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
This patch adds a new "backlight" output GPIO to the coreboot table in
order to avoid redundantly defining that GPIO in the payload.
BRANCH=veyron
BUG=chrome-os-partner:34713
TEST=Tested together with corresponding depthcharge CL.
Change-Id: Ia997beb1a400136ad65d8f0217781c9782f6e8a5
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 04ce4c23573cf926aeef3d817d3ab00835f897c7
Original-Change-Id: I69b3c7ac6be4b9723b6a0dfecef5e1c4ea681aff
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/242400
Original-Tested-by: Lin Huang <hl@rock-chips.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9652
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
This moves PMIC_BUS from each mainboard's board.h file to a per-
mainboard Kconfig variable. To prevent humans from forgetting to
set a valid value, an invalid default is set in the rk3288 Kconfig
and checked in rk808.c so that compilation will fail if the mainboard
Kconfig does not override it.
Originally, PMIC_BUS was only used by mainboard code as an argument
to RK808 PMIC functions. To conform to the generic RTC API, however,
the RK808 code needs to have the bus number globally defined somewhere
since the rtc_get() and rtc_set() functions don't take any args.
Since CONFIG_PMIC_BUS is globally visible, we no longer need to pass
bus number to the PMIC functions.
BUG=chrome-os-partner:34436
BRANCH=none
TEST=built and booted on Pinky
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I73783878e507b2e7b1526dd2f81cfbdf8f1e2a55
Reviewed-on: https://chromium-review.googlesource.com/240203
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9642
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
Due to a missing i2c_init(), we were actually running our TPM with
default divisors at 660KHz. Oops.
While it's commendable that both the TPM and our controller seem to have
been running fine all this time at more than 1.5 times the maximum
frequency they support, we should probably still get that fixed.
Also sync Speedy back up to the other Veyron boards since it seems to
have missed a recent SDMMC patch.
BRANCH=None
BUG=None
TEST=Booted Pinky.
Change-Id: I255c66624b21bf48b12f950208ba2c401a75c4e4
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: f2bd7c8579cd90d2f800c777c1981557d81a9b49
Original-Change-Id: I43e6b5fe02aca605a5b243c5b876bd44b90b2bf9
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/236580
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9634
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
BUG=None
TEST=emerge veyron_pinky and boot the Pinky board
BRANCH=None
Change-Id: I75bc1b7681c9a3d7dc2868a2b260884538587dbd
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 66069927618924af02a4e17503fa49ae2c31fdfc
Original-Change-Id: I06242ade0cabbba56b16b3832a1b4b09bec6f06b
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/234712
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9631
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
We use the devicetree to pass the backlight control gpio before,
but if there have different board version, and it uses different
io to control backlight, it will hard to distinguish it. So, we
move the backlight control to mainboard, and use board_id
to distinguish the backlight control.
BUG=None
TEST=emerge veyron_pinky and Boot the pinky board
BRANCH=None
Change-Id: Ifa81eb2455296f4b4285b681208f4393f266fb34
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 2ff7f65134dcf97f97757750eab41dcf8c7765d3
Original-Change-Id: I1ec8e04f4982c3a8c7e31d8dc2c75311b7199ffc
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/234711
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9630
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
The only way to reliably reset an SD card in an unknown state is by
power-cycling. Since a kernel may crash and reboot at any point, SD
cards may be left in one of them fancy high-throughput modes that
depthcharge (or, in fact, a newly booting kernel without prior
knowledge) doesn't support, so we need to reset the card on every boot.
This patch adds support to turn off an RK808 regulator completely and
uses that to turn off SD card power rails in early romstage. The time
until configure_sdmmc() in ramstage turns them back on should be more
than enough to drain the power rail for an effective power-cycle.
BRANCH=None
BUG=chrome-os-partner:34289
TEST=Booted a Pinky from SD card, noticed that it works before and
after this patch.
Change-Id: Iaa5f7adaa59da69a964785c5e369ad73c6620224
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 95fba21907f1f3f686cb5a95b993736247db8f96
Original-Change-Id: I904b2d23ca35f765c000f9bee7637044f674eff9
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/233713
Original-Reviewed-by: Alexandru Stan <amstan@chromium.org>
Original-Tested-by: Alexandru Stan <amstan@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9626
Tested-by: build bot (Jenkins)
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
Implement VOP and eDP drivers, vop and edp clock configuration,
framebuffer allocation and display configuration logic.
The eDP driver reads panel EDID to determine panel dimensions
and the pixel clock used by the VOP.
The pixel clock is generating using the NPLL.
BUG=chrome-os-partner:31897
TEST=Booted Veyron Pinky and display normal
BRANCH=None
Change-Id: I01b5c347a3433a108806aec61aa3a875cab8c129
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e4f863b0b57f2f5293ea8015db86cf7f8acc5853
Original-Change-Id: I61214f55e96bc1dcda9b0f700e5db11e49e5e533
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/219050
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9553
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This patch adds support for Pinky rev3 (board ID 2) and Jerry rev2: the
power button GPIO changed polarity to low, the 5V_DRV pin for USB power
was moved to the AP again (welcome back!), and the EMMC_RST_L is now
finally on a port with the right IO voltage so we don't need any weird
pull-up tricks anymore. Since there are very few Jerry rev1s around,
we'll just move it over to the new code directly without introducing
board ID differences (also, because I have no idea how they stuffed it
this time... is this one actually called rev2?).
BRANCH=None
BUG=None
TEST=Still boots on my Pinky rev2, though that doesn't say much.
Change-Id: Id11044cedcaac5a4ae07e696893823925107a6db
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 55344a9518ff04edcef01bcd40817e9e4b613717
Original-Change-Id: Iddee360fbda357ecde4ae5fbb5c3a01fe0c22474
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/229010
Original-Reviewed-by: Lin Huang <hl@rock-chips.com>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9551
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
LDO7 (VCC10_LCD_PWREN_H) is essentially just a glorified GPIO that turns
the real VCC10 regulator on or off. We tried setting it to 3.3V since it
matches the VCC33_SYS voltage on the input of that regulator. However,
we didn't notice that the LDO only supports going up to 2.5V.
This patch changes the voltage to the allowed maximum, which should
still work fine as an enable line (and is the same value used by the
kernel). This removes an assertion error in the ramstage.
Also change the PMIC driver to assert maximum VSEL values based on the
LDO, because the lower-voltage ones support one more setting. (LDO3 is
actually listed to only go up to 0b1111 in the manual, and has a weird
jump from 0b1101 -> 2.2V (skipping over 0b1110) to 0b1111 -> 2.5V. I
don't know if that's a documentation error or what they were smoking
when they designed that, but we don't need to care for now.)
BRANCH=None
BUG=None
TEST=Booted on Pinky, no more ASSERTION FAILED.
Change-Id: I38bf99e38822fd0883fd4d0bd9a1b01143545a95
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 70f3149efbc3aa9a03ab3fd5be99d17d9c5e1c87
Original-Change-Id: I68a3bb882cf25d98aca8922ede2a17e1ef6524de
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/228292
Original-Commit-Queue: Lin Huang <hl@rock-chips.com>
Original-Tested-by: Lin Huang <hl@rock-chips.com>
Original-Reviewed-by: Jerry Parson <jwp@chromium.org>
Reviewed-on: http://review.coreboot.org/9547
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The eMMC enable pin is in a 3.3V IO domain. Unfortunately the eMMC
expects this pin to be 1.8V. The way we were driving this pin would
cause the eMMC to pull power through this pin and that was causing
current leaks.
In future revisions of hardware we should move this pin somewhere more
legit. However, in the current hardware we can get things working
pretty well by using a pullup to "drive" this pin. This will work in
conjunction with the external 100K pullup to give a somewhat
reasonable voltage. The eMMC will also not be able to pull much
current through this pin, so it can't leak too badly.
BRANCH=none
BUG=chrome-os-partner:33319
TEST=Boot a kernel that doesn't touch the mux/pulls and see no leak:
dut-control --port=${SERVO} vcc_flash_ma -t 5
Change-Id: Ibc25cd090d826c8215be24a0b5c11d97b5281700
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 26e7a9d7e067ed4dd859387ee63bf654ab9dc529
Original-Change-Id: Iadfc1477cd478773cc9d159e3fbc22b66b8f0f78
Original-Signed-off-by: Doug Anderson <dianders@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/226039
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9545
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
We've had gpiolib.h which defines a few common GPIO access functions for
a while, but it wasn't really complete. This patch adds the missing
gpio_output() function, and also renames the unwieldy
gpio_get_in_value() and gpio_set_out_value() to the much easier to
handle gpio_get() and gpio_set(). The header is renamed to the simpler
gpio.h while we're at it (there was never really anything "lib" about
it, and it was presumably just chosen due to the IPQ806x include/
conflict problem that is now resolved).
It also moves the definition of gpio_t into SoC-specific code, so that
different implementations are free to encode their platform-specific
GPIO parameters in those 4 bytes in the most convenient way (such as the
rk3288 with a bitfield struct). Every SoC intending to use this common
API should supply a <soc/gpio.h> that typedefs gpio_t to a type at most
4 bytes in length. Files accessing the API only need to include <gpio.h>
which may pull in additional things (like a gpio_t creation macro) from
<soc/gpio.h> on its own.
For now the API is still only used on non-x86 SoCs. Whether it makes
sense to expand it to x86 as well should be separately evaluated at a
later point (by someone who understands those systems better). Also,
Exynos retains its old, incompatible GPIO API even though it would be a
prime candidate, because it's currently just not worth the effort.
BUG=None
TEST=Compiled on Daisy, Peach_Pit, Nyan_Blaze, Rush_Ryu, Storm and
Veyron_Pinky.
Change-Id: Ieee77373c2bd13d07ece26fa7f8b08be324842fe
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9e04902ada56b929e3829f2c3b4aeb618682096e
Original-Change-Id: I6c1e7d1e154d9b02288aabedb397e21e1aadfa15
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/220975
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9400
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This patch is the start of a series to change all non-x86 SoC-specific
headers to be included as <soc/header.h> instead of the old
<soc/vendor/chip/header.h> or "header.h". It will add an include/soc/
directory under every src/soc/vendor/chip/ and append the .../include/
part of that to the global include path.
This matches the usage of <arch/header.h> for architecture-specific
headers and had already been done for some headers on Tegra. It has the
advantage that a source file which does not know the specific SoC used
(e.g. Tegra files common for multiple chips, or a global include file)
can still include SoC-specific headers and access macros/types defined
there. It also makes the includes for mainboard files more readable, and
reduces the chance to pull in a wrong header when copying mainboard
sources to use a different-related SoC (e.g. using a Tegra124 mainboard
as template for a Tegra132 one).
For easier maintainability, every SoC family is modified individually.
This patch starts out by changing Rk3288. Also alphabetized headers in
affected files since we touch them anyway.
BUG=None
TEST=Whole series: compared binary images for Daisy, Nyan_Blaze,
Rush_Ryu, Storm, Urara and Veyron_Pinky. Confirmed that they are
byte-for-byte identical except for timestamps, hashes, and __LINE__
macro replacements. Compile-tested individual patches.
Change-Id: I4d74a0c56be278e591a9cf43f93e9900e41f4319
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 4ad8b6d2e0280428aa9742f0f7b723c00857334a
Original-Change-Id: I415b8dbe735e572d4ae2cb1df62d66bcce386fff
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/222025
Reviewed-on: http://review.coreboot.org/9349
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This patch creates a new mechanism to define the static memory layout
(primarily in SRAM) for a given board, superseding the brittle mass of
Kconfigs that we were using before. The core part is a memlayout.ld file
in the mainboard directory (although boards are expected to just include
the SoC default in most cases), which is the primary linker script for
all stages (though not rmodules for now). It uses preprocessor macros
from <memlayout.h> to form a different valid linker script for all
stages while looking like a declarative, boilerplate-free map of memory
addresses to the programmer. Linker asserts will automatically guarantee
that the defined regions cannot overlap. Stages are defined with a
maximum size that will be enforced by the linker. The file serves to
both define and document the memory layout, so that the documentation
cannot go missing or out of date.
The mechanism is implemented for all boards in the ARM, ARM64 and MIPS
architectures, and should be extended onto all systems using SRAM in the
future. The CAR/XIP environment on x86 has very different requirements
and the layout is generally not as static, so it will stay like it is
and be unaffected by this patch (save for aligning some symbol names for
consistency and sharing the new common ramstage linker script include).
BUG=None
TEST=Booted normally and in recovery mode, checked suspend/resume and
the CBMEM console on Falco, Blaze (both normal and vboot2), Pinky and
Pit. Compiled Ryu, Storm and Urara, manually compared the disassemblies
with ToT and looked for red flags.
Change-Id: Ifd2276417f2036cbe9c056f17e42f051bcd20e81
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f1e2028e7ebceeb2d71ff366150a37564595e614
Original-Change-Id: I005506add4e8fcdb74db6d5e6cb2d4cb1bd3cda5
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/213370
Reviewed-on: http://review.coreboot.org/9283
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
BUG=None
TEST=Boot Veyron Pinky and measure i2c clock frequency
Original-Change-Id: I04d9fa75a05280885f083a828f78cf55811ca97d
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/219660
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Julius Werner <jwerner@chromium.org>
Change-Id: Ie7ac3f2d0d76a4d3347bd469bf7af3295cc454fd
(cherry picked from commit 4b9b3c2f8b7c6cd189cb8f239508431ee08ebc52)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9241
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
This patch adds support for the board changes in rev2 (board_id = 0001).
It also moves the existing mainboard.c code around a bit to group it by
component.
BUG=chrome-os-partner:32139
TEST=Booted on rev1. Confirmed SD card still works. Confirmed power
button was still as broken as before.
Original-Change-Id: Ifc4876687db64ca50e41d009d911446129d57b1b
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/220251
(cherry picked from commit 9428e0d1b784b27790b3b3dbbb18a769e51c6fd3)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I8d3479aa314f8c6f1591c1b69b0a3827234fc730
Reviewed-on: http://review.coreboot.org/9237
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
this change makes veyron pinky to select a rw romstage using vboot2.
BUG=None
TEST=Booted Veyron Pinky. Verified firmware selection in the log.
BRANCH=None
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
CQ-DEPEND=CL:219100
Original-Change-Id: Ia1cfdacde9f8b17b00e7772a02e0d266afedb82f
Original-Reviewed-on: https://chromium-review.googlesource.com/219103
Original-Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
(cherry picked from commit 69c1e4b9ee200645d38d28165389aa85ef9b36cd)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I7b4a2db8bcb95038dfb55bb7ceee66ac4a6c9475
Reviewed-on: http://review.coreboot.org/9234
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
The static gpio_t initializers are stylish, but they are still a little
too annoying to write and read in day-to-day use. Let's wrap that in a
macro to make it a little easier to handle.
BUG=None
TEST=None
Change-Id: If41b2b3fd3c3f94797d314ba5f3ffcb2a250a005
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 102a5c0a800f43d688d11d1d7bbc51e360341517
Original-Change-Id: I385ae5182776c8cbb20bbf3c79b986628040f1cf
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/220250
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9052
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The Rk808 PMIC is a part that will probably be used by most Rk3288
boards, so it makes sense to keep it as common code in the the SoC
directory. This patch puts LDO control functions into rk3288/rk808.c, so
that the mainboard only has to call a simple interface to set up the
specific LDOs it requires.
BUG=chrome-os-partner:30167
TEST=Booted both this and the old version with a stubbed-out
i2c_writeb(), ensured that the final values are the same.
Change-Id: I7efa60f8a357ce6be7490e64d2e0e3f72ad16f1c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 4df22cd78ee04fefc6f7fa0e5c3d903eb1794422
Original-Change-Id: Ic172f9c402e829995f049726d3cb6dbd637039d1
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/217598
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8871
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
|
|
We retroactively decided to use the variant name "pinky" for the Rk3288
board we're currently bringing up, and retcon the unadorned "veyron"
name to refer to the Rockchip evaluation board. Since we currently have
no interest to maintain coreboot support for that board in our tree,
let's rename everything to "veyron_pinky" and forget about "veyron".
CQ-DEPEND=CL:217592
BUG=chrome-os-partner:30167
TEST='emerge-veyron libpayload coreboot' fails but
'emerge-veyron_pinky libpayload coreboot' succeeds.
Change-Id: I88bf5cc2da7c2f969ea184b5f12affaa94045a06
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: aa8ec24b63d11798fec1993091b113a0c0938c7a
Original-Change-Id: I366391efc8e0a7c610584b50cea331a0164da6f3
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/217674
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/8869
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|