summaryrefslogtreecommitdiff
path: root/src/soc/rockchip/rk3288
AgeCommit message (Collapse)Author
2015-10-25rockchip/rk3288: Remove 1392MHz option for RK3288 APLLDavid Hendricks
It's no longer used. BUG=none BRANCH=none TEST=it compiles Change-Id: I3d9385e0e1f14977c1632f3a8dda771c684ce458 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 5381b6434996da10706dd358928f98703ac0892c Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Change-Id: Ib0cfaf1bb173a7150f7ff504b9f58a62eb82e781 Original-Reviewed-on: https://chromium-review.googlesource.com/302634 Reviewed-on: http://review.coreboot.org/12138 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2015-10-25rockchip/rk3288: Add 1416MHz as an option for RK3288 APLLDavid Hendricks
BUG=chrome-os-partner:42054 BRANCH=none TEST=tested with subsequent patch Change-Id: I92d67ff4b706c16677661ead1edd5c190ccc6d95 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: dced0fcbc35457d7326d590948ce5fe098a5e735 Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Change-Id: I7b29c647380046ac41a290b19fdfba186bcb2127 Original-Reviewed-on: https://chromium-review.googlesource.com/302632 Reviewed-on: http://review.coreboot.org/12136 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2015-10-25rockchip/rk3288: Add 600MHz as an option for RK3288 APLLDavid Hendricks
BUG=chrome-os-partner:41201 BRANCH=firmware-veyron TEST=tested with subsequent patch on mickey Signed-off-by: David Hendricks <dhendrix@chromium.org> Change-Id: I7081d92be128f522e1a33eee6f3de9dfbbf042ea Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: a390c927ad8ed035520c8a813db808715dc5e527 Original-Change-Id: I3ce0f7b2772c8c652b7f461749d01cc7b669b6cf Original-Reviewed-on: https://chromium-review.googlesource.com/300616 Original-Commit-Ready: David Hendricks <dhendrix@chromium.org> Original-Tested-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/12134 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2015-09-22linking: link bootblock.elf with .data and .bss sections againAaron Durbin
Currently coreboot expects the loader to clear the bss section for all stages. i.e. stages don't clear their own bss. On ARM SoCs the BootROM would be responsible for this. To do that one needs to include the bss section data (all zeros) in the bootblock.bin file. This was previously being attempted by keeping the .bss info in the .data section because objcopy happened zero out non-file allocated data section data. Instead go back to linking bootblock with the bss section but mark the bss section as loadable allocatable data. That way it will be included in the binary properly when objcopy -O binary is emplyed. Also do the same for the data section in the case of no non-zero object values are in the data section. Without this change the trick of including .bss in .data was not working when there wasn't a non-zero value object in the data section. BUG=None BRANCH=None TEST=Built emulation/qemu-armv7 and noted bootblock.bin contains the cleared bss. Change-Id: I94bd404c2c4a8b9332393e6224e98940a9cad4a2 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11680 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-09-09verstage: use common program.ld for linkingAaron Durbin
There's no reason to have a separate verstage.ld now that there is a unified stage linking strategy. Moreover verstage support is throughout the code base as it is so bring in those link script macros into the common memlayout.h as that removes one more specific thing a board/chipset needs to do in order to turn on verstage. BUG=chrome-os-partner:44827 BRANCH=None TEST=None Change-Id: I1195e06e06c1f81a758f68a026167689c19589dd Signed-off-by: Aaron Durbin <adubin@chromium.org> Reviewed-on: http://review.coreboot.org/11516 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-09-08rk3288: Allow board-specific APLL (CPU clock) settingsDavid Hendricks
This changes the API to rkclk_configure_cpu() such that we can pass in the desired APLL frequency in each veyron board's bootblock.c. Devices with a constrainted form facter (rialto and possibly mickey) will use this to run firmware at a slower speed to mitigate risk of thermal issues (due to the RK808, not the RK3288). BUG=chrome-os-partner:42054 BRANCH=none TEST=amstan says rialto is noticably cooler (and slower) Change-Id: I28b332e1d484bd009599944cd9f5cf633ea468dd Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: d10af5e18b4131a00f202272e405bd22eab4caeb Original-Change-Id: I960cb6ff512c058e72032aa2cbadedde97510631 Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/297190 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/11582 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-09-04bootmode: add display_init_required()Aaron Durbin
Some of the Chrome OS boards were directly calling vboot called in some form after contorting around #ifdef preprocessor macros. The reasoning is that Chrome OS doesn't always do display initialization during startup. It's runtime dependent. While this is a requirement that doesn't mean vboot functions should be sprinkled around in the mainboard and chipset code. Instead provide one function, display_init_required(), that provides the policy for determining display initialization action. For Chrome OS devices this function honors vboot_skip_display_init() and all other configurations default to initializing display. Change-Id: I403213e22c0e621e148773597a550addfbaf3f7e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11490 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2015-08-28rockchip: rk3288: multiple NPLL rate in pll_para_configYakir Yang
Due to HDMI need to set dclk_rate to 27Mhz, and we can't caclu a suitable config paramters for this rate, so we need to multiple rate unless the vco larger then VCO_MAX. When NPLL rate multiple to 54MHz, pll_para_config could caclu a right paramters, and I have verify the clock jitter is okay to HDMI output. Jitter Reports: Dclk Rate NPLL Rate nr/no/nf jitter Margin 27MHz 54MHz 2/10/45 449.0ps +51.0% BRANCH=None BUG=chrome-os-partner:42946 TEST=Mickey board, show right recovery picture on TV, and 480p clock jitter test passed Change-Id: Iaa0a6622e63d88918ed465900e630bdf16fde706 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Original-Commit-Id: 59f1552026889f61167cfeaec3def668ba709c10 Original-Signed-off-by: Yakir Yang <ykk@rock-chips.com> Original-Change-Id: Iab274b41f163d2d61332df13e5091f0b605cb65c Original-Reviewed-on: https://chromium-review.googlesource.com/288416 Original-Commit-Queue: David Hendricks <dhendrix@chromium.org> Original-Tested-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/290331 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/11393 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-08-28rk3288: Set HDMI display mode to 480pYakir Yang
If an HDMI display is detected (EDID can be read), set the display mode to 480p. If for some reason 480p is not supported then we'll fall back to the automatically detected display mode. BUG=chrome-os-partner:42946 BRANCH=firmware-veyron TEST=dev mode screen shows up on Mickey at 480p resolution Change-Id: I2c431eff6673392d3c09e1b66c66ba12ecc6eeb0 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Original-Commit-Id: 76203a683c4501f368c50fe24101f68746ddb7f0 Original-Change-Id: I90dea37daa2d78628230d7d47f7ef0e917cbd7bb Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/290554 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/11392 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-08-28rk3288: Ignore EDID errors for HDMIDavid Hendricks
Assume that HDMI implies usage of an external display, and that we want to try bringing up display if we can read an EDID. BUG=chrome-os-partner:42946 BRANCH=firmware-veyron TEST=none; need a display with corrupt EDID to test with Change-Id: I11cc61140d905d70798a7b46db7847f3a1b3c886 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Original-Commit-Id: ace7773623eac57f068ecd50baa9108ce028cf1b Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Change-Id: I9e22984a98b1a5f8cd9645b92dc9b87e8d968f01 Original-Reviewed-on: https://chromium-review.googlesource.com/293548 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/11391 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-08-28edid: Use edid_mode struct to reduce redundancyDavid Hendricks
This replaces various timing mode parameters parameters with an edid_mode struct within the edid struct. BUG=none BRANCH=firmware-veyron TEST=built and booted on Mickey, saw display come up, also compiled for link,falco,peppy,rambi,nyan_big,rush,smaug [pg: extended to also cover peach_pit, daisy and lenovo/t530] Change-Id: Icd0d67bfd3c422be087976261806b9525b2b9c7e Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Original-Commit-Id: abcbf25c81b25fadf71cae106e01b3e36391f5e9 Original-Change-Id: I1bfba5b06a708d042286db56b37f67302f61fff6 Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/289964 Original-Reviewed-by: Yakir Yang <ykk@rock-chips.com> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/11388 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-08-28rockchip: rk3288: fix phsync & pvsync bugYakir Yang
Struct edid defien pvsync & phsync as an character, like '+' or '-', so we need to check sync polarity by comparing with characters '+' and '-' instead of treating as boolean. BRANCH=None BUG=chrome-os-partner:42946 TEST=Mickey board, light monitor normally Change-Id: I92d233e19b6df8917fb8ff9a327ccb842c152d65 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Original-Commit-Id: 2d22d4b6e7108474f67200e0fb1e4894cd88db85 Original-Change-Id: I14c72aa8994227092a1059d2b25c1dd2249b9db1 Original-Signed-off-by: Yakir Yang <ykk@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/289963 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Commit-Queue: David Hendricks <dhendrix@chromium.org> Original-Tested-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/11380 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-08-21ChromeOS: Fix Kconfig dependenciesMartin Roth
Add CHROMEOS dependencies to selects for the following Kconfig symbols: CHROMEOS_RAMOOPS_DYNAMIC CHROMEOS_RAMOOPS_NON_ACPI CHROMEOS_VBNV_CMOS CHROMEOS_VBNV_EC CHROMEOS_VBNV_FLASH EC_SOFTWARE_SYNC LID_SWITCH RETURN_FROM_VERSTAGE SEPARATE_VERSTAGE VBOOT_DISABLE_DEV_ON_RECOVERY VBOOT_EC_SLOW_UPDATE VBOOT_OPROM_MATTERS VBOOT_STARTS_IN_BOOTBLOCK WIPEOUT_SUPPORTED This gets rid of these sorts of Kconfig errors: warning: BOARD_SPECIFIC_OPTIONS selects CHROMEOS_VBNV_EC which has unmet direct dependencies (MAINBOARD_HAS_CHROMEOS && CHROMEOS) Note: These two boards would never actually have CHROMEOS enabled: intel/emeraldlake2 has MAINBOARD_HAS_CHROMEOS commented out google/peach_pit doesn't have MAINBOARD_HAS_CHROMEOS Change-Id: I51b4ee326f082c6a656a813ee5772e9c34f5c343 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: http://review.coreboot.org/11272 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-07-09rk3288: Fix & vs && mix up in hdmi driverStefan Reinauer
Change-Id: I54650671adaef3bc129c662d6e972474c869afaa Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: http://review.coreboot.org/10859 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins)
2015-07-07rk3288: Use timestamp region for pre-cbmem timestampsFurquan Shaikh
BUG=None BRANCH=None TEST=Compiles successfully for veyron_pinky Original-Change-Id: I3862e9bf2c32085c921adae4c1dcdf88ff0f3ff3 Original-Signed-off-by: Furquan Shaikh <furquan@google.com> Original-Reviewed-on: https://chromium-review.googlesource.com/227243 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org> Original-Tested-by: Furquan Shaikh <furquan@chromium.org> (cherry picked from commit 0fabdbb05826160beb8ee8f89339b18a49e87ab8) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I4504d29a43084d4bd406626899b25903200fa6d7 Reviewed-on: http://review.coreboot.org/10740 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2015-07-06veyron*: Kill SKIP_DISPLAY_INIT_HACKDavid Hendricks
Now that we have functioning display code for all platforms, we can just get rid of this ugly hack used on non-Chromebook veyrons. BUG=none BRANCH=none TEST=built for Brain, Rialto, Mickey, Romy Change-Id: Ibe248c7cc74940811345c249d66992d74fe85fe5 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 9c627b087ba9fc07b4ec4a6d55d2e0203bdd4ff5 Original-Change-Id: I946eddb4e8ce1dbaa20212a2bb417e71a31b2ba3 Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/282049 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/10785 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2015-07-06rk3288: Add VOP_MODE_NONE for headless devicesDavid Hendricks
BUG=none BRANCH=none TEST=built w/ follow-up rialto patch Change-Id: I166c75673c199e8c6860f601db6759cdc3cb9c96 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: ba0e0b639f12654ec54216d4366c688baa5b3253 Original-Change-Id: Id21c87ace2f4d381a1e374e1d5fe15cf1cd96da0 Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/282047 Reviewed-on: http://review.coreboot.org/10779 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-07-06rk3288: Auto-detect display.David Hendricks
We currently select either HDMI or EDP (default). This patch allows us to use HDMI as a fallback for devices that may have a display connected on either interface. It also renames the enums to sound a little more sensible in other contexts (more on that in the follow-up patches). VOP_MODE_AUTO is added to the mode enum which will make it explicit that a board can support either. In AUTO_MODE we will try EDP first and then fallback to HDMI. Other modes can be set to force a certain behavior such as HDMI-only on Mickey where it doesn't make sense to try EDP. A follow-up patch will add logic for when we explicitly don't want to probe for any display (headless devices). BUG=none BRANCH=none TEST=On veyron_danger, connected EDP and HDMI displays and saw dev mode screen appear on EDP display. Unplugged EDP and then dev mode screen showed up on HDMI. Change-Id: I22b38031c4ab3d79fbb182f7a906da1197f35543 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 3f57ed3758c4e516d9fd226ad9499b102b81b423 Original-Change-Id: I352dcde16f7f3ebbf5796852b685685e541eb794 Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/281076 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/10775 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-07-06rockchip: rk3288: correct ddr 300MHz clock settinghuang lin
CRU request (24MHz * nf) / nr > 440MHz, but now ddr 300MHz setting can't meet this request, so modify it BRANCH=None BUG=None TEST=Set ddr frequency to 300MHz and boot from mickey Change-Id: I00324f5864f5ce8c1a3768268e402e0beca214c6 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 3d292b67245e714cb03ed35ee28c9b838d514da5 Original-Change-Id: I885704542293ed55e429a0b4b30135af7978990f Original-Signed-off-by: huang lin <hl@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/282445 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/10772 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-07-01rockchip/rk3288: Initialize CPU in bootblockPatrick Georgi
Some basic MMU setup is required to allow unaligned memory accesses that happen across our entire codebase. Change-Id: If5a84e19a7a3e47d6009fd073b1323dfb25e6a06 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Found-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/10753 Tested-by: build bot (Jenkins) Reviewed-by: Julius Werner <jwerner@chromium.org>
2015-06-26rockchip/rk3288: complete vboot configuration and move to SoCPatrick Georgi
Where vboot verification can start, and how the code flow looks like is more a property of the SoC (and its properties, like amount of SRAM) rather than the board. Change-Id: I610153ea4ceddc226d8cc3e17a515e41fc0479cf Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10662 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-06-23rockchip/rk3288: add support for hdmi displayYakir Yang
this is an brief hdmi driver which config with simple display parameter, const encoder input & output color format and 8bit color depth, and only 48KHz audio support. what's more to prevent TV have not show an right things before coreboot switch to kernel space, we have to add an terrible 2s delay to driver (2s come from test many times), cause we have to wait TV to respond (we got no flag to check whether it is ready). BUG=chrome-os-partner:40337 TEST=Booted Veyron Jerry and display normal BRANCH=None Change-Id: Icd33467e95de6219e1b614616f0112afc52097b6 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 7e5b699aff75a579116aae63d858c834b2f648e8 Original-Change-Id: Iedc87c011c5b62ce5f16a296dd9c3e0c2eaba59b Original-Signed-off-by: Yakir Yang <ykk@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/272565 Original-Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Original-Commit-Queue: Lin Huang <hl@rock-chips.com> Original-Tested-by: Lin Huang <hl@rock-chips.com> Reviewed-on: http://review.coreboot.org/10625 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-06-21Remove old HAVE_UART_MEMORY_MAPPED select statementsMartin Roth
The HAVE_UART_MEMORY_MAPPED symbol is no longer present, so these don't actually select anything. Change-Id: I6d0eb610e48a4506ac7449ac677ee67981d0ff0d Signed-off-by: Martin Roth <gaumless@gmail.com> Reviewed-on: http://review.coreboot.org/10608 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2015-06-10rockchip: rk3288: add HDMI related iomux configurationhuang lin
BUG=none BRANCH=none TEST=Boot from mickey board Change-Id: I6eadf52bddcf89011a112a8e5dee5e752556add9 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: e3c865f0bf8567c3183d7948a0f9e8361db70695 Original-Change-Id: I438527ee0870044f48b23a6842986e7cf166e191 Original-Signed-off-by: huang lin <hl@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/276290 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/10477 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
2015-06-08Remove empty lines at end of fileElyes HAOUAS
Used command line to remove empty lines at end of file: find . -type f -exec sed -i -e :a -e '/^\n*$/{$d;N;};/\n$/ba' {} \; Change-Id: I816ac9666b6dbb7c7e47843672f0d5cc499766a3 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: http://review.coreboot.org/10446 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-06-05lib: Unify log2() and related functionsJulius Werner
This patch adds a few bit counting functions that are commonly needed for certain register calculations. We previously had a log2() implementation already, but it was awkwardly split between some C code that's only available in ramstage and an optimized x86-specific implementation in pre-RAM that prevented other archs from pulling it into earlier stages. Using __builtin_clz() as the baseline allows GCC to inline optimized assembly for most archs (including CLZ on ARM/ARM64 and BSR on x86), and to perform constant-folding if possible. What was previously named log2f on pre-RAM x86 is now ffs, since that's the standard name for that operation and I honestly don't have the slightest idea how it could've ever ended up being called log2f (which in POSIX is 'binary(2) LOGarithm with Float result, whereas the Find First Set operation has no direct correlation to logarithms that I know of). Make ffs result 0-based instead of the POSIX standard's 1-based since that is consistent with clz, log2 and the former log2f, and generally closer to what you want for most applications (a value that can directly be used as a shift to reach the found bit). Call it __ffs() instead of ffs() to avoid problems when importing code, since that's what Linux uses for the 0-based operation. CQ-DEPEND=CL:273023 BRANCH=None BUG=None TEST=Built on Big, Falco, Jerry, Oak and Urara. Compared old and new log2() and __ffs() results on Falco for a bunch of test values. Change-Id: I599209b342059e17b3130621edb6b6bbeae26876 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 3701a16ae944ecff9c54fa9a50d28015690fcb2f Original-Change-Id: I60f7cf893792508188fa04d088401a8bca4b4af6 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/273008 Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10394 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-05-21Remove address from GPLv2 headersPatrick Georgi
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>
2015-05-19Remove Kconfig variable that has no effectPatrick Georgi
CPU_HAS_BOOTBLOCK_INIT is only declared once and selected elsewhere (with no overlap), and never read. Remove it. Change-Id: I3f294b0724a87876a7e2f274e6933fe10321a69d Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10253 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2015-05-15rk3288: remove unused structs and declarationsAaron Durbin
The struct rockchip_spi_media type is no longer used; nor is initialize_rockchip_spi_cbfs_media(). Remove them. Change-Id: I2c24be249e0cd89e2dd328e05cdd24a178fe37e8 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10214 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2015-04-30vboot: split class in library and stagePatrick Georgi
The build system includes a bunch of files into verstage that also exist in romstage - generic drivers etc. These create link time conflicts when trying to link both the verstage copy and romstage copy together in a combined configuration, so separate "stage" parts (that allow things to run) from "library" parts (that contain the vboot specifics). Change-Id: Ieed910fcd642693e5e89e55f3e6801887d94462f Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10041 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-04-29kbuild: automatically include SOCsStefan Reinauer
This change switches all SOC vendors and southbridges to be autoincluded by Makefile.inc, rather than having to be mentioned explicitly in soc/Makefile.inc or in soc/<vendor>/Makefile.inc. This means, vendor and SOC directories are now "drop in", e.g. be placed in the coreboot directory hierarchy without having to modify any higher level coreboot files. The long term plan is to enable out of tree components to be built with a given coreboot version (given that the API did not change). Change-Id: Iede26fe184b09c53cec23a545d04953701cbc41d Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: http://review.coreboot.org/9799 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-22rtc: add config flag to denote rtc API availabilityPatrick Georgi
RTC drivers now select RTC, so that code which depends on them can implement fallback behavior for systems that lack the hardware or driver. Change-Id: I0f5a15d643b0c45c511f1151a98e071b4155fb5a Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/9953 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-04-22rockchip/rk3288: Fix operator precedence error in LPDDR initJulius Werner
Upstream coreboot regularly runs Coverity over the code base. Turns out that's a good idea since it's really easy to screw yourself over with a missing parenthesis and some unfortunately deceptive line breaking. This patch fixes a bug in LPDDR3 initialization due to an incorrect operator precedence assumption ( ?: does not bind stronger than | ). In effect, instead of setting MR11[1:0] to 0b11 or 0b00 based on ODT, we're unconditionally setting MR0[1:0] to 0b11. Thankfully, MR0[1:0] seems to contain read-only bits so this might have not been a problem when ODT is off (which is currently true for all LPDDR boards). Also adding a redundant LPDDR_OP() around the 0 to make the intent clearer and changing 3 and 0 to 0x3 and 0x0 to make it more obvious that these are bit masks (right?). BRANCH=veyron BUG=None TEST=Running reboot loop on a Minnie, looks good so far... Change-Id: I06464aaa57e693b1973846a5771162244f7a1c57 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Found-by: Coverity Scan Original-Commit-Id: 5bd9eba39fb7b0f940fead963bbc1878b031b2cb Original-Change-Id: I701ce059472078b5de09a45dd31f54b65a51e641 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/264135 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-by: Jinkun Hong <jinkun.hong@rock-chips.com> Original-Tested-by: Jinkun Hong <jinkun.hong@rock-chips.com> Reviewed-on: http://review.coreboot.org/9911 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-22soc: select generic gpio lib on (almost) all non-x86 SOCsStefan Reinauer
BOARD_ID functionality is not what requires the GPIO lib, but it is the mainboard specific implementations that do. The option essentially says whether the SoC provides <soc/gpio.h> (with the interface required by the common GPIO code). Right now, x86 and Samsung's Exynos SOCs don't have support for this interface. So this should be selected by the SOC, not by BOARD_ID_SUPPORT. Signed-off-by: Stefan Reinauer <reinauer@chromium.org> BUG=none BRANCH=none TEST=emerge-storm coreboot still successfully compiled an image Change-Id: I0ce2bd7ce023f22791d31a6245833b61135504b3 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 0dd4dea521372194eedf11b077d95fd3b15ad9f7 Original-Change-Id: I3dea6c2fb42a23fcb9d384c3bbfa7fc8e217be2d Original-Reviewed-on: https://chromium-review.googlesource.com/262743 Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Original-Tested-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Queue: Stefan Reinauer <reinauer@chromium.org> Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9899 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-22rockchip/rk3288: Fix SPI clock divisor calculationJulius Werner
The code to calculate the RK3288 SPI controller's internal clock divisor is wrong: it assumes that the divisor register was an "n-1" divisor when it actually isn't (due to some misleading kernel code that was copied in here). This means that all SPI clocks are currently running lower than expected. This patch fixes the calculation and changes all callers such that the effective speeds stay the same. BRANCH=veyron BUG=chrome-os-partner:38352 TEST=Booted Jerry with and without the patch, dumping the divisor for flash and EC clocks. Made sure it stays the same. Change-Id: I2336e2b81c2384b5076175fcf32717a3ab2ba0c5 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 1fd5b990f937019a9bee7bd693c91d6e2fca1adb Original-Change-Id: I094d57a5933c8b849f5c66194e6cc2952ab68b90 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/262269 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9887 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-21arm(64): Manually clean up the mess left by write32() transitionJulius Werner
This patch is a manual cleanup of all the rubble left by coccinelle waltzing through our code base. It's generally not very good with line breaks and sometimes even eats comments, so this patch is my best attempt at putting it all back together. Also finally remove those hated writel()-style macros from the headers. BRANCH=none BUG=chromium:444723 TEST=None (depends on next patch) Change-Id: Id572f69c420c35577701feb154faa5aaf79cd13e Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 817402a80ab77083728b55aed74b3b4202ba7f1d Original-Change-Id: I3b0dcd6fe09fc4e3b83ee491625d6dced98e3047 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/254865 Reviewed-on: http://review.coreboot.org/9837 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-21arm(64): Globally replace writel(v, a) with write32(a, v)Julius Werner
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>
2015-04-21arm(64): Replace write32() and friends with writel()Julius Werner
This patch is a raw application of the following spatch to the directories src/arch/arm(64)?, src/mainboard/<arm(64)-board>, src/soc/<arm(64)-soc> and src/drivers/gic: @@ expression A, V; @@ - write32(V, A) + writel(V, A) @@ expression A, V; @@ - write16(V, A) + writew(V, A) @@ expression A, V; @@ - write8(V, A) + writeb(V, A) This replaces all uses of write{32,16,8}() with write{l,w,b}() which is currently equivalent and much more common. This is a preparatory step that will allow us to easier flip them all at once to the new write32(a,v) model. BRANCH=none BUG=chromium:451388 TEST=Compiled Cosmos, Daisy, Blaze, Pit, Ryu, Storm and Pinky. Change-Id: I16016cd77780e7cadbabe7d8aa7ab465b95b8f09 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 93f0ada19b429b4e30d67335b4e61d0f43597b24 Original-Change-Id: I1ac01c67efef4656607663253ed298ff4d0ef89d Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/254862 Reviewed-on: http://review.coreboot.org/9834 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-21rk3288: disable rk808 DCDC_UV_ACT_REG restart converter functionhuang lin
if DCDC_UV_ACT_REG setted, when the buck voltage drop to 85%, rk808 will reset this buck, but now when the current consumption large, rk808 may miscarriage of justice this status, so we must disable this function BUG=chrome-os-partner:34834 TEST=Boot from jerry, and do RUNIN test sucess BRANCH=None Change-Id: I08cef73b88d6c2722b389c632c7db29605f4545d Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 858c8abc11a824fc3d991a39a49710243f4b1473 Original-Change-Id: I46ebe332c576eebd3386b5042b146a8b57a5c194 Original-Signed-off-by: huang lin <hl@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/254496 Original-Commit-Queue: Julius Werner <jwerner@chromium.org> Original-Tested-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9831 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-21rockchip: configure lpddr odt properlyDerek Basehore
The wrong offsets were being used for the GRF_SOC_CON2 register. This also configures odt based on the value of odt in the sdram_params for lpddr systems. BUG=chrome-os-partner:37346 TEST=boot veyron_speedy and veyron_jerry BRANCH=None Change-Id: I13ec3d0df162fe73fabf8af40dd5472e15d6f6af Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 403ab13de17290dc3766bd6f1a03b6effbe58b41 Original-Change-Id: Ic0c18cc7ccf861ef8749e6c950fab9a2802e5f26 Original-Signed-off-by: Derek Basehore <dbasehore@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/255584 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9828 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-21rk3288: support single channel ddrjinkun.hong
When using single-channel ddr, DMC channel 1 need to reset dll, otherwise it will lead to pmdomain idle request fails. BUG=chrome-os-partner:35654 BRANCH=veyron TEST=boot rialto Change-Id: Id6b673187c688d238e9a391b3d98720c783e3af4 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 927e8426104f8869e139c3f60a04cd49bf726e61 Original-Change-Id: I8be1567040ddb5f2a2b0d06568e517d794ead87a Original-Signed-off-by: jinkun.hong <jinkun.hong@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/250060 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9819 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-20rk3288: Disable ramstage compression by defaultJulius Werner
The ramstage is loaded from romstage, so the LZMA scratchpad buffer used to decompress it is part of the romstage BSS in SRAM. On RK3288, SRAM cannot be cached which makes the decompression so slow that it's faster to just load an uncompressed image from SPI. Disable ramstage compression on this SoC to account for that. [pg: implementation avoids restructuring all of Kconfig] BRANCH=None BUG=None TEST=Built for Pinky and Falco, confirmed that the former didn't have COMPRESS_RAMSTAGE in its .config and the latter still did. Measured a speed-up of about 35ms on Pinky. (For some weird reason, the decompression of the payload also takes way longer than on other platforms, although not as long as the ramstage. I have no explanation for that and can't really think of a good way to figure it out... maybe the Cortex-A12 is just terrible at some operation that LZMA uses a lot?) Change-Id: I9f67f7537696ec09496483b16b59a8b73f4cb11b Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/234192 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/9792 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-17rk3288: Add software I2C supportJulius Werner
This patch adds the necessary platform glue to allow the use of software-driven I2C bit banging on the RK3288. This is just a debugging feature that can be used to reproduce certain I2C failure cases. Also fix Makefile verstage linking for the feature and add some new rk3288 IOMUX macros as needed. BRANCH=None BUG=None TEST=Added "CONFIG_SOFTWARE_I2C=y" to configs/config.veyron_jerry, wrapped Jerry's bootblock and verstage in software_i2c_attach/detach() calls, confirmed that both PMIC and TPM could be driven correctly with software I2C driver. Tried out different combinations of software_i2c_wedge_ack() and software_i2c_wedge_read() on the PMIC and observed transfer results with the hardware controller after reboot... the worst that would happen is that the first register read-modify-write (DCDC_ILMAX) would fail to read, but all later transfers would be fine. Since that register is written twice (due to current BUCK1 ramp implementation) and is not terribily important anyway, I think we don't need to worry about wedging problems. Change-Id: Iba801ee61d30fb1fd3aef8300612c67fa50c441b Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 24dfca9bab38a20c40ef0c2dd4c775b8d8f47487 Original-Change-Id: I96777300a57c85471bad20e23a455551e9970222 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/247890 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9757 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-17chromeos: Provide common watchdog reboot supportJulius Werner
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>
2015-04-17chromeos: Move memlayout.h/symbols.h into common directoryJulius Werner
Turns out there are uses for memlayout regions not specific to vboot2. Rather than add yet another set of headers for a single region, let's make the vboot2 one common for chromeos. BRANCH=veyron BUG=chrome-os-partner:35705 TEST=Booted Jerry, compiled Blaze, Cosmos, Ryu and Storm. Change-Id: I228e0ffce1ccc792e7f5f5be6facaaca2650d818 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: c6d7aab9f4e6d0cfa12aa0478288e54ec3096d9b Original-Change-Id: I1dd7d9c4b6ab24de695d42a38913b6d9b952d49b Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/242630 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9748 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-17uart: pass register width in the coreboot tableVadim Bendebury
Some SOCs (like pistachio, for instance) provide an 8250 compatible UART, which has the same register layout, but mapped to a bus of a different width. Instead of adding a new driver for these controllers, it is better to have coreboot report UART register width to libpayload, and have it adjust the offsets accordingly when accessing the UART. BRANCH=none BUG=chrome-os-partner:31438 TEST=with the rest of the patches integrated depthcharge console messages show up when running on the FPGA board Change-Id: I30b742146069450941164afb04641b967a214d6d Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 2c30845f269ec6ae1d53ddc5cda0b4320008fa42 Original-Change-Id: Ia0a37cd5f24a1ee4d0334f8a7e3da5df0069cec4 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/240027 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9738 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-17rk3288: detect sdram size at runtimehuang lin
we use Kconfig define sdram size before, but there may use different sdram size in the same overlay, so we must detect sdram size at runtime now. If we use 4G byte sdram, we can use[0x00000000:0xff000000], since the [0xff000000:0xffffffff] is the register space. BUG=chrome-os-partner:35521 TEST=Boot from mighty BRANCH=None Change-Id: I7a167c268483743c3eaed8b71c7ec545a688270c Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: ad4f27dd08c467888eee87e3d9c4ab3077751898 Original-Change-Id: Ib32aed50c9cae6db495ff3bab28266de91f3e73b Original-Signed-off-by: huang lin <hl@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/243139 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9734 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-17rk3288: Handle framebuffer through memlayout, not the resource systemJulius Werner
We've traditionally tucked the framebuffer at the end of memory (above CBMEM) on ARM and declared it reserved through coreboot's resource allocator. This causes depthcharge to mark this area as reserved in the kernel's device tree, which may be necessary to avoid display corruption on handoff but also wastes space that the OS could use instead. Since rk3288 boards now have proper display shutdown code in depthcharge, keeping the framebuffer memory reserved across the handoff (and thus throughout the lifetime of the system) should no longer be necessary. For now let's just switch the rk3288 implementation to define it through memlayout instead, which is not communicated through the coreboot tables and will get treated as normal memory by depthcharge. Note that this causes it to get wiped in developer/recovery mode, which should not be a problem because that is done in response to VbInit() (long before any images are drawn) and 0 is the default value for a corebootfb anyway (a black pixel). Eventually, we might want to think about adding more memory types to coreboot's resource system (e.g. "reserved until kernel handoff", or something specifically for the frame buffer) to model this situation better, and maybe merge it with memlayout somehow. CQ-DEPEND=CL:239470 BRANCH=veyron BUG=chrome-os-partner:34713 TEST=Booted Jerry, noticed that 'free' now displays 0x7f000 more bytes than before (curiously not 0x80000 bytes, I guess there's some alignment waste in the kernel somewhere). Made sure the memory map output from coreboot looks as expected, there's no visible display corruption in developer/recovery mode and the 'cbmem' utility still works. Change-Id: I12b7bfc1b7525f5a08cb7c64f0ff1b174df252d4 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 10afdba54dd5d680acec9cb3fe5b9234e33ca5a2 Original-Change-Id: I1950407d3b734e2845ef31bcef7bc59b96c2ea03 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/240819 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9732 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-17rk3288: Add a config variable hack to skip display initDavid Hendricks
The current display init code causes Brain to crash when trying to allocate resources. This just avoids doing display init if a config variable is set. Once code has been implemented to properly setup different types of displays we can get rid of this hack. BUG=none BRANCH=none TEST=built and booted (to depthcharge) on Brain, compiled for pinky with FEATURES=noclean and ensured config variable is 0 Change-Id: I9a7266c6bff5b7a6eb05b2b21fb65797bee392d6 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 804632ca67eaaf4174ca597d83b8923cb9abd1b7 Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Change-Id: I04c9e8181c58fa0608fd20776fa8c4798a023474 Original-Reviewed-on: https://chromium-review.googlesource.com/235922 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9720 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-17veyron: Activate Winbond SPI driverJulius Werner
This patch activates the chip driver for Winbond SPI flash (which, incidentally, looks 99.9% the same as the Gigadevice driver but still requires some extra 500+ bytes of object code... there's definitely room for improvement here). Shuffle around rk3288 memlayout to make a little more room in the bootblock. BRANCH=veyron BUG=chrome-os-partner:34176 TEST=Booted Pinky. Checked bootblock and verstage memsz of final binary and noticed that both only have less than 500 bytes left against their memlayout boundary. The next piece of code we add will cause some serious headaches... Change-Id: I97ea6ac334104e4219e310afc557c164b2ff19d9 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 8769e5a34ad3cd417132646fbb58ff51c29fb640 Original-Change-Id: Id2f1204c30aa28251cf85cb80d7ca44947388dba Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/236977 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9719 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-15rk3288: support edp HPD functionhuang lin
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>
2015-04-15rk3288: set the rk808 BUCK default inductor current to max valuehuang lin
Our use of the bucks may exceed their default maximum inductor current. Just set it to the highest possible value for every buck we configure to avoid problems... the kernel can later fine-tune the values further if needed. (Also some slight grammar updates while I'm in there.) BRANCH=veyron TEST=Build and Boot on Jerry BUG=None Change-Id: If8258cf4feefe191604365405bff1f20c8ab8746 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 065a163bb902b8c96d05bfef6ed4885aa20f31cc Original-Change-Id: I3801cabeb93d7bf7ecc02db0e69d4932c9394db9 Original-Signed-off-by: huang lin <hl@rock-chips.com> Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/242785 Original-Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-on: http://review.coreboot.org/9655 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-15rk3288: Fix failing LPDDR3 reboot testjinkun.hong
tMRD request 10nCK in LPDDR3, we set the DDR_PCTL_TMRD BIT0~BIT2 to generate this signal, but the max value we can set is 7, so the standard can not be met. So, now we send the Mode Register Set command manually, and hence we can add the delay manually. BUG=chrome-os-partner:34608 TEST=loop reboot BRANCH=veyron Change-Id: Id974ab935c2df6ea35dcdd240378ffc68de0204d Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: b60a4de6ff3ad3720c2c06ed7de03ed942360e6c Original-Change-Id: I0d29ea9cd82ef018e835ae53090a47d0299ef61d Original-Signed-off-by: jinkun.hong <jinkun.hong@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/242176 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9654 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-15rk3288: Fix failing DDR3 reboot testjinkun.hong
We want a reset signal to last 200us. The length of a reset signal is represented by BIT0~BIT16 in DDR_PUBL_PTR2. When DDR memory runs at 667MHz, the calculated value for the reset signal is 0x20850, which is bigger than the maximum value that can be described with 17 bits (0x1ffff). As a result, the memory controller only sees 0x850, which generates a 3.5us reset cycle instead, which violates the standard and negatively impacts memory stability. So instead, we now set it to the maximum value (0x1ffff) to prevent this overflow, resulting in a reset signal of 196us for 667MHz DDR memory. BUG=chrome-os-partner:34875 TEST=loop reboot BRANCH=veyron Change-Id: Ia01f8a0414b49fa3ecf4d543cfa1822e29ee4cc4 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 767a4a3cb8dff47cb15064d335b78ffa5815914d Original-Change-Id: I9b410e1605c87f12a5ca96ead12f8527ca4f417f Original-Signed-off-by: jinkun.hong <jinkun.hong@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/242175 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9653 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-15rk3288: send correct EDID buffer sizehuang lin
decode_edid() parses the whole EDID buffer, regardless of whether there is an extension buffer, so we pass the size of the EDID actually read to prevent EDID parser getting the wrong data. BUG=chrome-os-partner:35053 TEST=Boot from jerry BRANCH=veyron Change-Id: I5951b670f129cf4765a5199cb58ac6abff5478a6 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 4d508647efc0a9d48b2a4b23c12a54b63af2813e Original-Change-Id: I8cd8e09025520322461fe940b01e4af3995b5ecd Original-Signed-off-by: huang lin <hl@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/240643 Original-Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Reviewed-on: http://review.coreboot.org/9645 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-15rk808: Implement RTC driverDavid Hendricks
This adds RTC functions to the existing RK808 driver. BUG=chrome-os-partner:34436 BRANCH=none TEST=with eventlog patches applied to pinky, booted and saw eventlog entries generated with correct timestamps: localhost ~ # mosys -k eventlog list 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: I1df70a2ca94ff463ffea8d9f02d951d6c62e6b08 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: a304f7e6954f585f04feef54c4902dcb25a39fcc Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Change-Id: I3a240e342a54b2e7023da71708d0d70f5131f0b9 Original-Reviewed-on: https://chromium-review.googlesource.com/238525 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/9643 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-15veyron_*: Move PMIC_BUS to a Kconfig variableDavid Hendricks
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>
2015-04-15rk3288: Implement support for CRYPTO module and use it in vboot hashingJulius Werner
This patch implements support for the CRYPTO module in RK3288 and ties it into the new vboot vb2ex_hwcrypto API. We only implement SHA256 for now, since the engine doesn't support SHA512 and it's very unlikely that we'll ever use SHA1 for anything again. BRANCH=None BUG=chrome-os-partner:32987 TEST=Booted Pinky, confirmed that it uses the hardware crypto engine and that firmware body hashing time dropped to about 1.5ms (from over 70ms). Change-Id: I91d0860b42b93d690d2fa083324d343efe7da5f1 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: e60d42cbffd0748e13bfe1a281877460ecde936b Original-Change-Id: I92510082b311a48a56224a4fc44b1bbce39b17ac Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/236436 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: http://review.coreboot.org/9641 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-15veyron_*: Use common CBFS wrapperDavid Hendricks
This switches all the rk3288 platforms to use the common CBFS wrapper instead of implementing its own CBFS media driver. It also happens that veyron_* platforms use Gigadevice SPI flash (at least for now). As we use more SPI-related stuff, for example eventlog and vboot data in Brain's case, we will need to use more of the SPI API anyway. This prevents us from having to duplicate pieces of it for rk3288. BUG=none BRANCH=none TEST=built and booted on Pinky Change-Id: Ie462456814646fdc277485d9e2d8c901fd4936e7 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 2d6df2fe6d78bc8eee8689019b9aaf29c82b6b30 Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Change-Id: Id307bd5fb6cc8f79411d8c66e1370e80c58d017b Original-Reviewed-on: https://chromium-review.googlesource.com/235882 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9678 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2015-04-15veyron: Move backlight gpio control to mainboard.chuang lin
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>
2015-04-15veyron: Trigger hard reset (via GPIO) if last reboot was caused by watchdogJulius Werner
Like Nyan, Veyron boards use a GPIO to reset the system so that we can make the accompanying TPM reset secure and unforgeable. The normal kernel reboot driver knows that, but the SoC-internal watchdog doesn't. This patch implements a check for the global reset status register in the early bootblock and triggers a hard_reset() when it matches "first global watchdog reset" or "second global watchdog reset". Seems that the difference between the two is is a choice controlled by wdt_glb_srst_ctrl (unconfirmed), and we want this code to run in both cases. BRANCH=None BUG=chrome-os-partner:33141 TEST=Run 'mem w 0xff800000 0x9' from the command line, watch how you end up in recovery without this patch but can boot normally with it. Change-Id: Ice79648831e1e97d22325711da9e82bbf6bf3c75 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 5d7cb52b2c2dcb2fff0bf83fc168439dade4b1b7 Original-Change-Id: I2581bde84f0445c15896060544e9acb60de91c8c Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/231734 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9629 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-15veyron: Turn off SD card power in romstageJulius Werner
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>
2015-04-15rk3288: implement spi_crop_chunk()Patrick Georgi
This function was added in upstream but was missing in Chromium OS Change-Id: I35debf65153e5f280343eebfe91438ecf665ba22 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/9677 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-14rk3288: Fix memlayout to allow a little more bootblock spaceJulius Werner
Freeing up memory on rk3288 is like squeezing water out of a stone right now, but I still managed to get a few drops here and there. Let's hope this will be enough. BRANCH=None BUG=None TEST=Pinky builds and boots again. memsz is ~15K in bootblock and ~39K in verstage. Change-Id: Icf7ff3369bf367426a34f1490e0a041ae9bd6367 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 9a3737ab535cdef228a1607433860f881db04412 Original-Change-Id: I90d9eab5b5d3af7a2e4b836a9c7b735b7c1c48e6 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/235870 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9609 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-14rk3288: Add CBMEM console support and fix RETURN_FROM_VERSTAGEJulius Werner
Since we can now reduce our vboot2 work buffer by 4K, we can use all that hard-earned space for the CBMEM console instead (and 4K are unfortunately barely enough for all the stuff we dump with vboot2). Also add console_init() and exception_init() to the verstage for CONFIG_RETURN_FROM_VERSTAGE, which was overlooked before (our model requires those functions to be called again at the beginning of every stage... even though some consoles like UARTs might not need it, others like the CBMEM console do). In the !RETURN_FROM_VERSTAGE case, this is expected to be done by the platform-specific verstage entry wrapper, and already in place for the only implementation we have for now (tegra124). (Technically, there is still a bug in the case where EARLY_CONSOLE is set but BOOTBLOCK_CONSOLE isn't, since both verstage and romstage would run init_console_ptr() as if they were there first, so the romstage overwrites the verstage's output. I don't think it's worth fixing that now, since EARLY_CONSOLE && !BOOTBLOCK_CONSOLE is a pretty pointless use-case and I think we should probably just get rid of the CONFIG_BOOTBLOCK_CONSOLE option eventually.) BRANCH=None BUG=None TEST=Booted Pinky. Change-Id: I87914df3c72f0262eb89f337454009377a985497 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 85486928abf364c5d5d1cf69f7668005ddac023c Original-Change-Id: Id666cb7a194d32cfe688861ab17c5e908bc7760d Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/232614 Reviewed-on: http://review.coreboot.org/9607 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-14timer: Reestablish init_timer(), consolidate timer initialization callsJulius Werner
We have known for a while that the old x86 model of calling init_timer() in ramstage doesn't make sense on other archs (and is questionable in general), and finally removed it with CL:219719. However, now timer initialization is completely buried in the platform code, and it's hard to ensure it is done in time to set up timestamps. For three out of four non-x86 SoC vendors we have brought up for now, the timers need some kind of SoC-specific initialization. This patch reintroduces init_timer() as a weak function that can be overridden by platform code. The call in ramstage is restricted to x86 (and should probably eventually be removed from there as well), and other archs should call them at the earliest reasonable point in their bootblock. (Only changing arm for now since arm64 and mips bootblocks are still in very early state and should sync up to features in arm once their requirements are better understood.) This allows us to move timestamp_init() into arch code, so that we can rely on timestamps being available at a well-defined point and initialize our base value as early as possible. (Platforms who know that their timers start at zero can still safely call timestamp_init(0) again from platform code.) BRANCH=None BUG=None TEST=Booted Pinky, Blaze and Storm, compiled Daisy and Pit. Change-Id: I1b064ba3831c0c5b7965b1d88a6f4a590789c891 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: ffaebcd3785c4ce998ac1536e9fdd46ce3f52bfa Original-Change-Id: Iece1614b7442d4fa9ca981010e1c8497bdea308d Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/234062 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9606 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-14CBFS: Automate ROM image layout and remove hardcoded offsetsJulius Werner
Non-x86 boards currently need to hardcode the position of their CBFS master header in a Kconfig. This is very brittle because it is usually put in between the bootblock and the first CBFS entry, without any checks to guarantee that it won't overlap either of those. It is not fun to debug random failures that move and disappear with tiny alignment changes because someone decided to write "ORBC1112" over some part of your data section (in a way that is not visible in the symbolized .elf binaries, only in the final image). This patch seeks to prevent those issues and reduce the need for manual configuration by making the image layout a completely automated part of cbfstool. Since automated placement of the CBFS header means we can no longer hardcode its position into coreboot, this patch takes the existing x86 solution of placing a pointer to the header at the very end of the CBFS-managed section of the ROM and generalizes it to all architectures. This is now even possible with the read-only/read-write split in ChromeOS, since coreboot knows how large that section is from the CBFS_SIZE Kconfig (which is by default equal to ROM_SIZE, but can be changed on systems that place other data next to coreboot/CBFS in ROM). Also adds a feature to cbfstool that makes the -B (bootblock file name) argument on image creation optional, since we have recently found valid use cases for CBFS images that are not the first boot medium of the device (instead opened by an earlier bootloader that can already interpret CBFS) and therefore don't really need a bootblock. BRANCH=None BUG=None TEST=Built and booted on Veyron_Pinky, Nyan_Blaze and Falco. Change-Id: Ib715bb8db258e602991b34f994750a2d3e2d5adf Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: e9879c0fbd57f105254c54bacb3e592acdcad35c Original-Change-Id: Ifcc755326832755cfbccd6f0a12104cba28a20af Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/229975 Reviewed-on: http://review.coreboot.org/9620 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-13rk3288/exynos5250/exynos5420: Consolidate timer filesJulius Werner
Some boards spread their timer implementation out in multiple files with one function each for no discernable reason. Let's clean that up to make things a little simpler to find. BRANCH=None BUG=None TEST=Booted Pinky, compiled Daisy and Pit. Change-Id: I8b543d1a0d9af37bde5433b0c9271d687b2404b2 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 887765e1bd88d7aa49ad9a5e98b8831c10da6c10 Original-Change-Id: I43d29cd1b4a1d89cfd40f6cba5ca99ada3b00f82 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/234061 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9601 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-13rk3288: Increase PD_BUS_ACLK (SRAM clock) to improve boot speedJulius Werner
This patch doubles the ACLK peripheral clock for the PD_BUS power domain to 297MHz, which is the closest to the maximum of 300MHz we can reach by dividing GPLL. This frequency directly translates into SRAM speed, so maximizing it has a huge impact on boot speed (especially with the lack of SRAM caching). BUG=chrome-os-partner:32987 TEST=Booted Veyron_Pinky. Hacked timestamps into vboot and confirmed that the (visibly) long signature verification times are nearly halved. Change-Id: Iafa3044854a4058a7f885c775119d964a6295de4 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: c230585f4344d0eab4f8eeaa761869965f2da08a Original-Change-Id: I3f19eaa3d97dcc6235d820c71eb5edf2ae87d647 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/224524 Original-Trybot-Ready: Doug Anderson <dianders@chromium.org> Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9600 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-13rk3288: Move UART initialization to bootblock_mainboard_early_init()Julius Werner
This patch uses the new bootblock_mainboard_early_init() hook to run the UART pinmuxing on rk3288-based boards before initializing the console. This allows us to get rid of the hacky second console_init() call in bootblock_soc_init(). We can also simplify the pinmux selection a bit since we know that a given board always uses the same UART (still keep an assert around to be sure, though). BRANCH=None BUG=chrome-os-partner:32123 TEST=Booted on Pinky. Change-Id: I3da8b0e4bd609f33cedd934ce51cb20b1190024b Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: caabda8fc1ddb4805d86fd9a0d5d2f3cf738bfaf Original-Change-Id: Ia56c0599a15f966d087ca39181bfe23abd262e72 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/231942 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9604 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-13arm: Redesign mainboard and SoC hooks for bootblockJulius Werner
This patch makes some slight changes to the way bootblock_cpu_init() and bootblock_mainboard_init() are used on ARM. Experience has shown that nearly every board needs either one or both of these hooks, so having explicit Kconfigs for them has become unwieldy. Instead, this patch implements them as a weak symbol that can be overridden by mainboard/SoC code, as the more recent arm64_soc_init() is also doing. Since the whole concept of a single "CPU" on ARM systems has kinda died out, rename bootblock_cpu_init() to bootblock_soc_init(). (This had already been done on Storm/ipq806x, which is now adjusted to directly use the generic hook.) Also add a proper license header to bootblock_common.h that was somehow missing. Leaving non-ARM32 architectures out for now, since they are still using the really old and weird x86 model of directly including a file. These architectures should also eventually be aligned with the cleaner ARM32 model as they mature. [pg: this was already partly upstreamed. These are the remains. Further cleanup is necessary and on the short-term TODO, but beyond the scope of this commit] BRANCH=None BUG=chrome-os-partner:32123 TEST=Booted on Pinky. Compiled for Storm and confirmed in the disassembly that bootblock_soc_init() is still compiled in and called right before the (now no-op) bootblock_mainboard_init(). Change-Id: Idf655894c4fec8fce7d3348d3b3e43b1613b35db Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 257aaee9e3aeeffe50ed54de7342dd2bc9baae76 Original-Change-Id: I57013b99c3af455cc3d7e78f344888d27ffb8d79 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/231940 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9602 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-13rk3288: Increase the delay after DDR reset de-assert to 10us.Dailunxue
After DDR PHY reset de-asserted, DLL automatically starts to lock, and the lock time is maximum 5.12us. The output clock of DLL supplies the clocks of DDR controller and PHY digital logic. So before DLL lock, the clocks of DDR controller and PHY digital logic are indeterminate. When programming DDR in the period of DLL unlock, the programming maybe unstable because of the indeterminate clocks. So we need wait for at least 5.12us after de-asserting reset, then start to program DDR registers. 10us provide some safety margin. BUG=chrome-os-partner:33148 TEST=I'm using the following command line test ok(15000 cycles). "while sleep 4 && dut-control cold_reset:on sleep:.1 cold_reset:off; do : ; done" BRANCH=None Change-Id: Ie7d615f5a2264c615c4b4413d6b828cd3d78cd2b Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 54e1a439c0e29aaf4fc542ae756f7bb036ceaf3e Original-Change-Id: I55f8cb11ed3d7962567c5f40a31e6c8aed8fdcb0 Original-Signed-off-by: DaiLunXue <dlx@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/232894 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Commit-Queue: Lunxue Dai <lunxue.dai@rock-chips.com> Original-Tested-by: Lunxue Dai <lunxue.dai@rock-chips.com> Reviewed-on: http://review.coreboot.org/9578 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-10rk3288: reset edp after edp clock source selecthuang lin
edp must reset when device power up, otherwise the edp register maybe uncertain, now the edp source clock default select 27M, and in pinky and jerry board we use 24M as edp sourec clock, if we want to reset edp, we must after the clock source select 24M. BUG=chrome-os-partner:34023 TEST=Booted Veyron jerry and read edid normal BRANCH=None Change-Id: I4b03dbabe5d3d595d2d56efb0cd82f510f8d2e1b Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 2292da77cc2322b85c4b4f4f20e4ebcc4c4d060d Original-Change-Id: Ica031d2d52deb539c1a0a56968786d6952b3d0e8 Original-Signed-off-by: huang lin <hl@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/231336 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Reviewed-on: http://review.coreboot.org/9555 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-10rockchip: support displayhuang lin
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>
2015-04-10veyron: Change VCC10_LCD_PWREN_H to allowed maximum of 2.5VJulius Werner
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>
2015-04-10vboot: move vboot files to designated directoryDaisuke Nojiri
This moves vboot1 and vboot2 files to their designated directory. Common code stays in vendorcode/google/chromeos. BUG=none BRANCH=none TEST=built cosmos, veyron_pinky, rush_ryu, nyan_blaze, samus, parrot, lumpy, daisy_spring, and storm. Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Change-Id: Ia9fb41ba30930b79b222269acfade7ef44b23626 Original-Reviewed-on: https://chromium-review.googlesource.com/222874 Original-Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org> Original-Tested-by: Daisuke Nojiri <dnojiri@chromium.org> (cherry picked from commit cbfef9ad40776d890e2149b9db788fe0b387d210) Signed-off-by: Aaron Durbin <adurbin@chromium.org> Change-Id: Ia73696accfd93cc14ca83516fa77f87331faef51 Reviewed-on: http://review.coreboot.org/9433 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-10rk3288: Adjust CBFS header and ROM offsetsJulius Werner
Our CBFS header offset on rk3288 was very low and overlapped with the end of the bootblock on recent Pinky builds. This can create all kinds of fun effects like BSS variables suddenly being initialized to something else than zero, in an effect that jumps somewhere else for every slightest code size change. This patch moves the CBFS header offset up a bit and the CBFS ROM offset down (because there's really no point in leaving such a large gap). This resolves our immediate booting problems, and I'll also start on a patch to add further checks somewhere that catch these overlaps in the future. BRANCH=None BUG=None TEST=Created a Pinky image from the exact same commit version as the official 6443.0.0 build, with a KERNELREVISION string of the exact same length as the builder (which for some arcane reason is different than running emerge locally, shifting the whole bootblock around with it). Confirmed that I saw the same "Not enough room for another sub-pagetable!" hang, and that this patch fixes it. Change-Id: I9e59a282b3cd0af3b0d224d64c10b7c4d312ad02 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 1a142cd2c51c6f51a1597c21ad513feb151e0938 Original-Change-Id: I8be5b7b7e87021cc1b3a91d336e8d233546ee188 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/228326 Original-Reviewed-by: Gediminas Ramanauskas <gedis@chromium.org> Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9410 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-10rk3288: don't log LAST_TSHUT bithuang lin
Since the LAST_THSUT bit is uncertain value when it cold-reboot, we remove the printout about this status bit in coreboot. BUG=chrome-os-partner:33521 TEST=Boot on veyron_pinky rev2 Change-Id: I3b9791ffdffeff0721e3d86378db6255c5abc9ea Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 16464d3229ad1001952ef1b50fe3e606d1583462 Original-Change-Id: I258750797e32c28f86e73a01eede005e890a6906 Original-Signed-off-by: huang lin <hl@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/228391 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9409 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-10rk3288: slowly raise to max cpu voltage to prevent overshoothuang lin
slowly raise to max cpu voltage to prevent overshoot, and in our experience,when cpu run in 1.8GHz,the vdd_cpu must up to 1.4V BUG=chrome-os-partner:32716, chrome-os-partner:31896 TEST=Boot on veyron_pinky rev2,check the rk808 buck1 voltage 1400mv and measure the overshoot is 1440mv Change-Id: I759840bd8cf57a5589bf1862d04803f80f804164 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 567f616ff091883ed3275b407859c9399db981b2 Original-Change-Id: I9bb739b49ae4b4f7a60133fa38b0fe51b95c0d78 Original-Signed-off-by: huang lin <hl@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/226753 Original-Reviewed-by: Doug Anderson <dianders@chromium.org> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9408 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-10gpio: Extend common GPIO header, simplify function namesJulius Werner
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>
2015-04-09soc: Use DEVICE_NOOP macro formalism over static stub funcEdward O'Callaghan
Change-Id: Ice7e27230010ffc48948f952394e849533f94085 Signed-off-by: Edward O'Callaghan <edward.ocallaghan@koparo.com> Reviewed-on: http://review.coreboot.org/8989 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-08timer: Add generic udelay() implementationAaron Durbin
Add GENERIC_UDELAY Kconfig option so that a generic udelay() implementation is provided utilizing the monotonic timer. That way each board/chipset doesn't need to duplicate the same udelay(). Additionally, assume that GENERIC_UDELAY implies init_timer() is not required. BUG=None BRANCH=None TEST=Built nyan, ryu, and rambi. May need help testing. Change-Id: I7f511a2324b5aa5d1b2959f4519be85a6a7360e8 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 1a85fbcad778933d13eaef545135abe7e4de46ed Original-Change-Id: Idd26de19eefc91ee3b0ceddfb1bc2152e19fd8ab Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/219719 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org> Reviewed-on: http://review.coreboot.org/9334 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-08console: fix Kconfig usesPatrick Georgi
While upstreaming, some old (or downstream) names sneaked in. Change-Id: I148fd8f46bc88c38ce1f62efe5771555bd5dcc5c Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/9350 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-08rk3288: Change all SoC headers to <soc/headername.h> systemJulius Werner
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>
2015-04-08rk3288: support tsadchuang lin
check the cpu and gpu temperature in romstage, if over 120 degrees celsius,shut down the device. BUG=None Test=Boot on veyron_pinky rev2, write value 3421(125 celsius) to grf_tsadc_testbitl register, the device will be shut down Change-Id: I275d643ce8560444a9b42ee566d5fd63ebcda35e Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: e0c597489dc0637ffa66ee9db0c4f60757f8889f Original-Change-Id: If406d6a4f6201150f52ea7fc64cd50b45778d7aa Original-Signed-off-by: huang lin <hl@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/223259 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Commit-Queue: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9348 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-08rk3288: Add early SRAM mappingJulius Werner
Solving the DACR bug will mean that XN bits suddenly become enforced on non-LPAE systems, and we will no longer be able to execute out of a region mapped DCACHE_OFF. When we enable the MMU in romstage we are still executing out of SRAM, so we would instantly kill ourselves. Solve this issue by enabling the MMU earlier (in the bootblock) and mapping the SRAM regions as DCACHE_WRITETHROUGH. They should really be DCACHE_WRITEBACK, but it looks like there might be hardware limitations in the Cortex-A12 cache architecture that prevent us from doing so. Write-through mappings are equivalent to normal non-cacheable on the A12 anyway, and by using this attribute we don't need to introduce a new DCACHE_OFF_BUT_WITHOUT_XN_BIT type in our API. (Also, using normal non-cacheable might still have a slight speed advantage over strongly ordered since it should fetch whole cache lines at once if the processor finds enough accesses it can combine.) CQ-DEPEND=CL:223783 BUG=chrome-os-partner:32118 TEST=None (depends on follow-up CL) Change-Id: I1e5127421f82177ca11af892b1539538b379625e Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: e7b079f4b6a69449f3c7cc18ef0e1704f2006847 Original-Change-Id: I53e827d95acc2db909f1251de78d65e295eceaa7 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/223782 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9342 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-08rk3288: Fix some PLL divisors and improve clock codeJulius Werner
This patch does some general cleanup in the Rockchip clock code, and adds some more assertions regarding the PLL VCO and output frequency ranges. It changes all PLL divisors to use the lowest values that can still hit the target frequency, since higher NR values lead to higher jitter and higher NO values increase power draw. Also change DDR3 frequency code to hardcode the optimal divisors for certail frequencies. As a little hack we will interpret 666000000 to actually mean 666666666.6P (and analogous for 533MHz), since that's what you usually want for memory. BUG=chrome-os-partner:32139 TEST=Boot on veyron_pinky rev2, check that dpll_is shown as 666666666 in /sys/kernel/debug/clk/clk_summary. Change-Id: I57d7ef34500984184e010c0cc7d73789338834d4 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 7466ffc035b3f06ac280f412bc496059abf3239c Original-Change-Id: I4f3c39641955a95c6dfbe9334035eb670b138bf0 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/221801 Reviewed-on: http://review.coreboot.org/9339 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-08rk3288: Re-write spi_xfer() to support full duplexDavid Hendricks
This change re-writes the spi_xfer() function to support full-duplex transfers. Even though the code looks much different, the same basic algorithm for setting up the transfer is used. The main difference is that reads from rxdr and writes to txdr occur simultaneously and accounting is more complicated, so I separated the higher-level accounting portion from the low-level FIFO handling portion to simplify things. BUG=chrome-os-partner:31850 BRANCH=none TEST=Loaded content from SPI ROM fine, needs testing w/ EC Change-Id: Ic109a02daf52ba694b63a73fec1a72b3c5c0fd71 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 6a14f5ff8ed04d62e8de6ad2f468b763ffb8213c Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Change-Id: I33d2f5179360baf94627c86b57d12f032897caf5 Original-Reviewed-on: https://chromium-review.googlesource.com/218881 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9338 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-06New mechanism to define SRAM/memory map with automatic bounds checkingJulius Werner
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>
2015-04-06Add predefined __ROMSTAGE__ and __RAMSTAGE__ macrosJulius Werner
This patch adds the macros __ROMSTAGE__ and __RAMSTAGE__ which get predefined in their respective stages by make, so that we have one specific macro for every stage. It also renames __BOOT_BLOCK__ and __VER_STAGE__ to __BOOTBLOCK__ and __VERSTAGE__ for consistency. This change is intended to provide finer control and clearer communication of intent after we added a new (optional) stage that falls under __PRE_RAM__, and will hopefully provide some robustness for the future (we don't want to end up always checking for romstage with #if defined(__PRE_RAM__) && !defined(__BOOT_BLOCK__) && !defined(__VER_STAGE__) && !defined(__YET_ANOTHER_PRERAM_STAGE__)). The __PRE_RAM__ macro stays as it is since many features do in fact need to differentiate on whether RAM is available. (Some also depend on whether RAM is available at the end of a stage, in which case #if !defined(__PRE_RAM__) || defined(__ROMSTAGE__) should now be authoritative.) It's unfeasable to change all existing occurences of __PRE_RAM__ that would be better described with __ROMSTAGE__, so this patch only demonstratively changes a few obvious ones in core code. BUG=None TEST=None (tested together with dependent patch). Change-Id: I6a06d0f42c27a2feeb778a4acd35dd14bb53f744 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: a4ad042746c1d3a7a3bfda422d26e0d3b9f9ae42 Original-Change-Id: I6a1f25f7077328a8b5201a79b18fc4c2e22d0b06 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/219172 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9304 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2015-04-04rk3288: set cpu frequency up to 1.8GHzhuang lin
before the rkclk_init(), we must set rk808 buck1 voltage up to 1300mv BUG=chrome-os-partner:32716, chrome-os-partner:31896 TEST=Boot on veyron_pinky rev2,check the rk808 buck1 voltage 1300mv and check the cpu frequency up to 1.8GHz Original-Change-Id: I6a8c6e35bd7cc6017f2def72876a9170977f206e Original-Signed-off-by: huang lin <hl@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/222957 Original-Reviewed-by: Doug Anderson <dianders@chromium.org> (cherry picked from commit 2e7e7c265691250d4a1b3ff94fe70b0a05f23e16) Signed-off-by: Aaron Durbin <adurbin@chromium.org> Change-Id: Iff89d959456dd4d36f4293435caf7b4f7bdaf6fd Reviewed-on: http://review.coreboot.org/9260 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-04rk3288: guarantee i2c low period more than 1.3ushuang lin
change i2c clock low period and high period proportion to 7:3 guarantee the low period more than 1.3us BUG=None TEST=Boot on veyron_pinky rev2,check the i2c clock frequency Original-Change-Id: I235e9e3ff54ab3b9cabad36bab58a8409f7005a0 Original-Signed-off-by: huang lin <hl@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/223002 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> (cherry picked from commit 57a5d90d394086483e0dcdd6279678658d07d842) Signed-off-by: Aaron Durbin <adurbin@chromium.org> Change-Id: I6b0c9dfa540354f6463ed90c9f3f9503a4d5749e Reviewed-on: http://review.coreboot.org/9259 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-04veyron_pinky/rk3288: Use KHz, MHz and GHz constantsJulius Werner
Use the previously added frequency constants in patch titled 'stddef: Add KHz, MHz and GHz constants'. BUG=None TEST=Compiled Veyron_Pinky. Original-Change-Id: I4a1927fd423eb96d3f76f7e44b451192038b02e0 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/221800 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> (cherry picked from commit 41bb8026818b4381d4a6d43d2d433c207c3971bc) Signed-off-by: Aaron Durbin <adurbin@chromium.org> Change-Id: I37a610d57f1a3d44796bf80de5104c2b5b3f3dac Reviewed-on: http://review.coreboot.org/9254 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-04rk3288: Replace SPI fifo_size with constantDavid Hendricks
rockchip_spi_slave has a fifo_size member which doesn't change. This just replaces the struct member with a #define. BUG=none BRANCH=none TEST=built and booted on Pinky Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Change-Id: I9ea5cdad49ee10c5f32304d0909c4a7e74a261f9 Original-Reviewed-on: https://chromium-review.googlesource.com/220471 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> (cherry picked from commit f76cce3b38ac37f4df8abf6eebb8f7c7b29da095) Signed-off-by: Aaron Durbin <adurbin@chromium.org> Change-Id: I3ab4eecfcce98aff3f6c9bd8f6c4e589784c60be Reviewed-on: http://review.coreboot.org/9246 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-04rk3288: Pass SPI bus speed in as parameter to init functionDavid Hendricks
This re-factors rockchip_spi to remove speed_hz which will instead be passed in via rockchip_spi_init(), thus making it easier to support other boards which may have different slave devices attached. BUG=none BRANCH=none TEST=built and booted on Pinky Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Change-Id: I7baf0fa0a2660e3c975847fdec3eb92bcd0d6c10 Original-Reviewed-on: https://chromium-review.googlesource.com/220411 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> (cherry picked from commit de33d2ed6352fc4c8e81dc53451f164a8792daf2) Signed-off-by: Aaron Durbin <adurbin@chromium.org> Change-Id: Ie6473e47d50b7e633688185e8d8036980b833f1c Reviewed-on: http://review.coreboot.org/9245 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-02pinky: Move some init to mainboard bootblockDavid Hendricks
This patch moves init for I2C, SPI, ChromeOS GPIOs to the board-specific bootblock init function on Pinky, the idea being to isolate SoC code so that it's more readily adaptable for different boards. BUG=none BRANCH=none TEST=built and booted on Pinky Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Change-Id: I75516bbd332915c1f61249844e18415b4e23c520 Original-Reviewed-on: https://chromium-review.googlesource.com/220410 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> (cherry picked from commit 0a7dec2fe70679c3457b0bfc7138b4a90b6217c8) Signed-off-by: Aaron Durbin <adurbin@chromium.org> Change-Id: Ib2c2e00b11c294a8d5bdd07a2cd59503179f0a84 Reviewed-on: http://review.coreboot.org/9243 Reviewed-by: David Hendricks <dhendrix@chromium.org> Tested-by: build bot (Jenkins)
2015-04-02rk3288/pinky: Move uart address to mainboard KconfigDavid Hendricks
Since the UART which is used for the serial console may change from board-to-board, this moves CONSOLE_SERIAL_UART_ADDRESS from rk3288's Kconfig into Pinky's Kconfig. BUG=none BRANCH=none TEST=built and booted on pinky Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Change-Id: I29837a72d8cf205a144494a6c8ce350465118b34 Original-Reviewed-on: https://chromium-review.googlesource.com/221438 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> (cherry picked from commit 53bff629f2e9865656beabd81e6ce1eab7c728a9) Signed-off-by: Aaron Durbin <adurbin@chromium.org> Change-Id: I65835c07a49dc3a3518c6bb24a29bc6ae7dd46c9 Reviewed-on: http://review.coreboot.org/9242 Reviewed-by: David Hendricks <dhendrix@chromium.org> Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2015-04-02rk3288: remove duplicated #define `PERI_ACLK_DIV_SHIFT`Aaron Durbin
I'm not sure how the build didn't fail before. In either case remove the duplication. Change-Id: I764774f2b8a5839512af3f054b844a1a86efdb45 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9244 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins)
2015-04-02coreboot: rk3288: add new ddr config and support ddr3 freq up to 800mhzjinkun.hong
Add ddr3-samsung-2GB config and modify 533mhz linit. Support ddr3 freq up to 800mhz. Enable ODT at LPDDR3. BUG=None TEST=Boot Veyron Pinky Original-Change-Id: Ic02a381985796a00644c5c681b96f10ad1558936 Original-Signed-off-by: jinkun.hong <jinkun.hong@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/220113 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Tested-by: Lin Huang <hl@rock-chips.com> Original-Commit-Queue: Julius Werner <jwerner@chromium.org> Change-Id: I867753bc5d1eb301eb4975f5a945bfdba9b8f37d (cherry picked from commit e6689cbb0ec50317672c8ebe4e23555ca2f01005) Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9239 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-02rockchip: support pwm regulatorhuang lin
BUG=None TEST=Boot Veyron Pinky and test the VDD_LOG Original-Change-Id: Ie2eef918e04ba0e13879e915b0b0bef44aef550e Original-Signed-off-by: huang lin <hl@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/219753 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Commit-Queue: Julius Werner <jwerner@chromium.org> Change-Id: I444b47564d90b3480b351fdd8460e5b94e71927c (cherry picked from commit 4491d9c4037161fd8c4cc40856167bf73182fda6) Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9240 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins)