- 06 4月, 2017 7 次提交
-
-
由 Simon Glass 提交于
We have two chunks of code which depend on this CONFIG options. There is likely no need to keep them apart, so join them. Signed-off-by: NSimon Glass <sjg@chromium.org> Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Simon Glass 提交于
While x86 is the only user and this could in principle be moved to arch_cpu_init() there is some justification for this being a separate call. It provides a way to handle init which is not CPU-specific, but must happen before the CPU can be set up. Rename the function to be more generic. Signed-off-by: NSimon Glass <sjg@chromium.org> Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Simon Glass 提交于
This file is missing the usual header guard. Add it. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
There is no need to have this call in the generic init sequence and no other architecture has needed it in the time it has been there. Move it into sandbox's private code. Signed-off-by: NSimon Glass <sjg@chromium.org> Reviewed-by: NStefan Roese <sr@denx.de> Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Tom Rini 提交于
The OpenRISC architecture is currently unmaintained, remove. Cc: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi> Signed-off-by: NTom Rini <trini@konsulko.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Tom Rini 提交于
The SPARC architecture is currently unmaintained, remove. Cc: Francois Retief <fgretief@spaceteq.co.za> Signed-off-by: NTom Rini <trini@konsulko.com>
-
由 Tom Rini 提交于
The architecture is currently unmaintained, remove. Cc: Benjamin Matthews <mben12@gmail.com> Cc: Chong Huang <chuang@ucrobotics.com> Cc: Dimitar Penev <dpn@switchfin.org> Cc: Haitao Zhang <hzhang@ucrobotics.com> Cc: I-SYST Micromodule <support@i-syst.com> Cc: M.Hasewinkel (MHA) <info@ssv-embedded.de> Cc: Marek Vasut <marex@denx.de> Cc: Martin Strubel <strubel@section5.ch> Cc: Peter Meerwald <devel@bct-electronic.com> Cc: Sonic Zhang <sonic.adi@gmail.com> Cc: Valentin Yakovenkov <yakovenkov@niistt.ru> Cc: Wojtek Skulski <info@skutek.com> Cc: Wojtek Skulski <skulski@pas.rochester.edu> Signed-off-by: NTom Rini <trini@konsulko.com>
-
- 05 4月, 2017 33 次提交
-
-
由 Tom Rini 提交于
When this board was switched to using more DM drivers we didn't disable the legacy PCA953X driver. This in turn learn to a build time warning about implicit functions as i2c.h would not say anything about 'i2c_read' nor 'i2c_write'. But this was not a fatal error as none of the legacy driver would be linked in either. Fixes: e389033f ("imx: mx6sxsabreauto: enable more dm drivers") Reviewed-by: NStefano Babic <sbabic@denx.de> Signed-off-by: NTom Rini <trini@konsulko.com>
-
-
由 Vikas Manocha 提交于
This patch replaces SPL_PINCTRL_FULL with SPL_PINCNTRL. It is to avoid removal of pin control properties in case of SPL_PINCTRL. No impact in case of SPL_PINCTRL_FULL as it depends on SPL_PINCTRL. Signed-off-by: NVikas Manocha <vikas.manocha@st.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Stefan Roese 提交于
Add a test for the correct device removal. Currently two different ways for device removal are supported: - Normal device removal via the device_remove() API - Removal via selective device driver flags (DM_FLAG_ACTIVE_DMA) This new test "remove_active_dma" adds tests cases for those both ways of removal. This is done by adding a new test driver, which has this flag set. Signed-off-by: NStefan Roese <sr@denx.de> Cc: Simon Glass <sjg@chromium.org>
-
由 Stefan Roese 提交于
This patch adds a call to dm_remove_devices_flags() to announce_and_cleanup() so that drivers that have one of the removal flags set (e.g. DM_FLAG_ACTIVE_DMA_REMOVE) in their driver struct, may do some last-stage cleanup before the OS is started. Signed-off-by: NStefan Roese <sr@denx.de> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Stefan Roese 提交于
The new function dm_remove_devices_flags() is intented for driver specific last-stage cleanup operations before the OS is started. This patch adds this functionality and hooks it into the common device_remove() function. Drivers wanting to use this feature for some last-stage removal calls, need to add one of the DM_REMOVE_xx flags to their driver .flags. Signed-off-by: NStefan Roese <sr@denx.de> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Stefan Roese 提交于
This patch adds the flags parameter to device_remove() and changes all calls to this function to provide the default value of DM_REMOVE_NORMAL for "normal" device removal. This is in preparation for the driver specific pre-OS (e.g. DMA cancelling) remove support. Signed-off-by: NStefan Roese <sr@denx.de> Cc: Simon Glass <sjg@chromium.org> Acked-by: NSimon Glass <sjg@chromium.org>
-
由 Jernej Skrabec 提交于
MiQi is rk3288 based development board with 1 or 2 GB SDRAM, 16 GB eMMC, micro SD card interface, 4 USB 2.0 ports, HDMI, gigabit Ethernet and expansion ports. Signed-off-by: NJernej Skrabec <jernej.skrabec@siol.net> Reviewed-by: NKever Yang <kever.yang@rock-chips.com> Reviewed-by: NEddie Cai <eddie.cai.linux@gmail.com> Acked-by: NSimon Glass <sjg@chromium.org>
-
由 Jernej Skrabec 提交于
Sort rk3288 boards in alphabetical order. Signed-off-by: NJernej Skrabec <jernej.skrabec@siol.net> Reviewed-by: NKever Yang <kever.yang@rock-chips.com> Reviewed-by: NEddie Cai <eddie.cai.linux@gmail.com> Acked-by: NSimon Glass <sjg@chromium.org>
-
由 Philipp Tomsich 提交于
The (shared) rk3399.dtsi had defined the 'rockchip,vbus-gpio' properties for each USB 3.0 controller. As the GPIO usage will vary (e.g. one of those GPIOs shuts down one of the regulators on the RK3399-Q7) between boards, we move this from the shared dtsi into the device tree file for the EVB board which these GPIO definitions match. Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Acked-by: NSimon Glass <sjg@chromium.org>
-
由 Philipp Tomsich 提交于
This commit adds the baseline defconfig for the RK3399-Q7 (Puma) SoM (under the name 'puma-rk3399_defconfig') featuring the Rockchip RK3399 in a Qseven compatible module. This subsumes the following changes: * defconfig: rk3399: migrate CONFIG_SPL_LIBCOMMON_SUPPORT/CONFIG_SPL_LIBGENERIC_SUPPORT * defconfig: rk3399-puma: add CONFIG_MMC_DW_ROCKCHIP * defconfig: rk3399-puma: disable CONFIG_SPL_OF_PLATDATA * defconfig: rk3399-puma: don't USE_TINY_PRINTF * defconfig: rk3399-puma: set up CONFIG_SYS_BOARD for the RK3399-Q7 * defconfig: rk3399-puma: enable the multi-image loading via CONFIG_SPL_FIT * defconfig: rk3399-puma: SPL should be able to boot from MMC/SD card * defconfig: rk3399-puma: enable GMAC support * defconfig: rk3399-puma: enable support for SPI and Winbond SPI flash * defconfig: rk3399-puma: enable SPI as a boot-source in SPL * defconfig: rk3399-puma: disallow non-FIT images from being loaded * defconfig: rk3399-puma: rename to puma-rk3399 * rockchip: config: rk3399: update defconfigs and rk3399_common For the RK3399-Q7, we want a default boot-order of SPI -> MMC -> uSD. This both follows how the BootROM probes devices and is a sane default for customers in device-personalisation (e.g. it allows for quick and easy factory programming of unpersonalised devices using an SD card) and field usage (with customer devices expected to have their firmware either in SPI or MMC). However, when probing multiple interfaces (according to the result from the board_boot_order function), we need to ensure that only valid FIT images are considered and disable the fallback to assuming that a raw (binary-only) U-Boot image is loaded (to avoid hangs/crashes from jumping to random content loaded from devices that are probed, but don't contain valid image content). By disabling the SPL_RAW_IMAGE_SUPPORT and SPL_LEGACY_IMAGE_SUPPORT options, we ensure that raw images (indistinguishable from random data) are not considered for booting. Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Acked-by: NSimon Glass <sjg@chromium.org> Drop CONFIG_DEBUG_UART_BOARD_INIT: Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Philipp Tomsich 提交于
The RK3399-Q7 is a system-on-module featuring the Rockchip RK3399 in a Qseven-compatible form-factor. These changes add a device-tree describing the board and its interfaces for basic functionality (e.g. GbE, SPI, eMMC, SD-card). This includes the following changes from the original development: * dts: rk3399-puma: include DTS for RK3399-Q7 SoM in the Makefile * dts: rk3399-puma: add gmac for the RK3399-Q7 This change enables the Gigabit Ethernet support on the RK3399-Q7. * dts: rk3399-puma: use serial0 for stdout * dts: rk3399-puma: prepare the sdmmc node for SPL booting * dts: rk3399-puma: enable spi1 and spi5, add /spi1/spiflash The RK3399-Q7 (Puma) unsually (this is a build-time option for customised boards) has an on-module SPI-flash connected to SPI1. As of today, this is a Winbond W25Q32DW (32MBit) device. The SPI5 controller is routed to the Q7 edge connector and provides general-purpose SPI connectivity for customer base-boards. With some minor improvements on integration into our outbound tree - explicitly modelled the SPI flash as 'spiflash' under spi0 [dts: rk3399-puma: explicitly model spi-flash under spi1] - renamed the aliases to spi0 and spi1 to allow easier use of commands and legacy (SPL) infrastructure... i.e. the controllers will be 0 and 1 for 'sf probe', 'sspi', etc. [dts: rk3399-puma: rename aliases to number spi as 0 and 1 for commands] * dts: rk3399-puma: include SPI in the spl-boot-order property Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Acked-by: NSimon Glass <sjg@chromium.org>
-
由 Jakob Unterwurzacher 提交于
On the RK3399-Q7 we need to enable a number of configuration options (e.g. CONFIG_SPI_FLASH_WINBND) dependent on Kconfig seeing CONFIG_SPI and CONFIG_SPI_FLASH active. To allow for these being defined in Kconfig (e.g. via defconfig) and to avoid a warning on having the macro defined multiple times, we remove them from the common header file. Note that the rk3399-evb does not currently have the rk_spi.c driver active (i.e. CONFIG_ROCKCHIP_SPI), so there's no change to the evb-rk3399_defconfig as part of this change. X-AffectedPlatforms: RK3399-Q7 Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Tested-by: NJakob Unterwurzacher <jakob.unterwurzacher@theobroma-systems.com> Acked-by: NSimon Glass <sjg@chromium.org>
-
由 Philipp Tomsich 提交于
For the initial validation of the RK3399-Q7 (Puma), the DDR3 has been clocked at 666MHz (i.e. DDR3-1333) using the same (safe) settings as used in Rockchip's MiniLoader. Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Acked-by: NSimon Glass <sjg@chromium.org>
-
由 Philipp Tomsich 提交于
The RK3399 does not have any boot selection pins and the BootROM probes the boot interfaces using the following boot-order: 1. SPI 2. eMMC (sdhci in DTS) 3. SD card (sdmmc in DTS) 4. USB loader For ease of deployment, the SPL stage should mirror the boot order of the ROM and use the same probing order (assuming that valid images can be detected by SPL) unless instructed otherwise. The boot-order can then be configured via the 'u-boot,spl-boot-order' property in the chosen-node of the DTS. While this approach is easily extensible to other boards, it is only implemented for the RK3399 for now, as the large SRAM on the RK3399 makes this easy to fit the needed infrastructure into SPL and our production setup already runs with DM, OF_CONTROL and BLK in SPL. The new boot-order property is expected to be used in conjunction with FIT images (and all legacy image formats disabled via Kconfig). A boot-sequence with probing and fallthroughs from SPI via eMMC to SD card (i.e. &spiflash, &sdhci, &sdmmc) has been validated on the RK3399-Q7. Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Tested-by: NKlaus Goger <klaus.goger@theobroma-systems.com> Tested-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Acked-by: NSimon Glass <sjg@chromium.org>
-
由 Heiko Stübner 提交于
The Rock is a RK3188 based single board computer by Radxa. Currently it still relies on the proprietary DDR init and cannot use the generic SPL, but at least is able to boot a linux kernel and system up to a regular login prompt. Signed-off-by: NHeiko Stuebner <heiko@sntech.de> Reviewed-by: NSimon Glass <sjg@chromium.org> Tested-by: NKever Yang <kever.yang@rock-chips.com> Acked-by: NSimon Glass <sjg@chromium.org> Fix sort order in defconfig, enable CONFIG_SPL_TINY_MEMSET: Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Most of the time the optimised memset() is what we want. For extreme situations such as TPL it may be too large. For example on the 'rock' board, using a simple loop saves a useful 48 bytes. With gcc 4.9 and the rodata bug, this patch is enough to reduce the TPL image below the limit. Signed-off-by: NSimon Glass <sjg@chromium.org> Reviewed-by: NHeiko Stuebner <heiko@sntech.de>
-
由 Simon Glass 提交于
At present we sometimes see the following build error when building on a machine with multiple cores. +make[2]: *** No rule to make target 'dts/dt.dtb', needed by 'tpl/u-boot-tpl.dtb'. Stop. Add a dependency to correct this. Signed-off-by: NSimon Glass <sjg@chromium.org> Tested-by: NHeiko Stuebner <heiko@sntech.de>
-
由 Eddie Cai 提交于
firefly have a usb host. add dts node to provide power supply Signed-off-by: NEddie Cai <eddie.cai.linux@gmail.com> Acked-by: NSimon Glass <sjg@chromium.org>
-
由 Heiko Stübner 提交于
Commit 3a649407 ("arm: Migrate SYS_THUMB_BUILD to Kconfig, introduce SPL_SYS_THUMB_BUILD") moved the THUMB_BUILD symbols from the header to Kconfig symbols. With it still defined in the rk3188 header we end up with a duplicate symbol and compile errors, so fix that. Signed-off-by: NHeiko Stuebner <heiko@sntech.de> Acked-by: NSimon Glass <sjg@chromium.org>
-
由 Philipp Tomsich 提交于
The clock driver for the RK3399 mistakenly used (24 * 2^20) where it should have used (24 * 10^6) in a few calculations. This commits fixes this. Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Acked-by: NSimon Glass <sjg@chromium.org>
-
由 Philipp Tomsich 提交于
This change adds the gmac node (i.e. the GMAC Ethernet controller) as defined in the Linux DTS. Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Acked-by: NSimon Glass <sjg@chromium.org>
-
由 Philipp Tomsich 提交于
The GMAC in the RK3399 is very similar to the RK3288 variant (i.e. it is a Designware GMAC core and requires similar configuration as the RK3288 to switch it to RGMII and set up the TX/RX delays for Gigabit). The key difference is that the register offsets (within the GRF block) and bit-offsets (within those registers) used to hold the configuration differ between the various RK32/33 CPUs. This change refactors the gmac_rockchip.c driver to use a function table (selected via driver_data) to factor out these differences. Each function's implementation then matches the underlying processor. Some collateral changes are needed in the definitions describing the bits and offsets in the GRF are needed to prefix each set of symbolic constants with the SoC name to avoid name clashes... and in doing so, the shifts for masks and constants have been moved into the header files for readability (and to make it easier to stay below 80 chars). X-AffectedPlatforms: RK3399-Q7 Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Tested-by: NKlaus Goger <klaus.goger@theobroma-systems.com> Acked-by: NJoe Hershberger <joe.hershberger@ni.com> Acked-by: NSimon Glass <sjg@chromium.org> Fixed commit message typo s/factor our/factor out/: Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Philipp Tomsich 提交于
The Ethernet driver for the RK3288/3399 GMAC makes sure that the clock is ungated through a call to clk_set_rate(...). Even though nothing needs to be done on the RK3399 (the clock gates are open and the clock is external), we need to implement enough support to at least return success to enable driver probing. X-AffectedPlatforms: RK3399-Q7 Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Acked-by: NSimon Glass <sjg@chromium.org>
-
由 Philipp Tomsich 提交于
Due to differences in the code paths for SPL and non-SPL, some static constant structures remain unused in each build variant. This raises warnings with recent GCC versions (we currently use GCC-6.3). The warnings addressed in this commit (by matching #if conditions for the variable definition with their uses) are: * for the SPL build: drivers/clk/rockchip/clk_rk3399.c:53:29: warning: 'cpll_init_cfg' defined but not used [-Wunused-const-variable=] static const struct pll_div cpll_init_cfg = PLL_DIVISORS(CPLL_HZ, 1, 2, 2); ^~~~~~~~~~~~~ drivers/clk/rockchip/clk_rk3399.c:52:29: warning: 'gpll_init_cfg' defined but not used [-Wunused-const-variable=] static const struct pll_div gpll_init_cfg = PLL_DIVISORS(GPLL_HZ, 2, 2, 1); ^~~~~~~~~~~~~ * for the non-SPL build: drivers/clk/rockchip/clk_rk3399.c:54:29: warning: 'ppll_init_cfg' defined but not used [-Wunused-const-variable=] static const struct pll_div ppll_init_cfg = PLL_DIVISORS(PPLL_HZ, 2, 2, 1); ^~~~~~~~~~~~~ Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Acked-by: NSimon Glass <sjg@chromium.org>
-
由 Philipp Tomsich 提交于
To add GMAC (Gigabit Ethernet) support (limited to RGMII only at this point), we need support for additional pin-configuration. This commit adds the pinctrl support for GMAC in RGMII signalling mode: * adds a PERIPH_ID_GMAC and the mapping from IRQ number to PERIPH_ID * adds the required defines (in the GRF support) for configuring the GPIOC pins for RGMII * configures the RGMII pins (in GPIOC) when requested via pinctrl X-AffectedPlatforms: RK3399-Q7 Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Acked-by: NSimon Glass <sjg@chromium.org>
-
由 Philipp Tomsich 提交于
An earlier upstream change contained an unconditional debug message which would show up as a message similar to the following in the U-Boot startup (after the ATF and before the U-Boot banner): time 159f019, 0 This commit removes this message (instead of making if conditional on being a debug-build), as it doesn't pertain to any initialisation done in this file. Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Acked-by: NSimon Glass <sjg@chromium.org>
-
由 Philipp Tomsich 提交于
The BootROM of the RK3399 SoC does not initialise the cntfrq_el0 (which holds the value 0 (zero) on entry into the SPL. This causes the timebase for U-Boot not to advance (and will cause a hang where a timeout would be expected... e.g. if something goes wrong during MMC/SD card startup). This change defines COUNTER_FREQUENCY, which is used by the AArch64 init code in arch/arm/cpu/armv8/start.S to set up cntfrq_el0 (if necessary). Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Acked-by: NSimon Glass <sjg@chromium.org>
-
由 Jernej Skrabec 提交于
Designware HDMI controller and phy are used in other SoCs as well. Split out platform independent code. DW HDMI has 8 bit registers but they can be represented as 32 bit registers as well. Add support to select access mode. EDID reading code use reading by blocks which is not supported by other SoCs in general. Make it more general using byte by byte approach, which is also used in Linux driver. Finally, not all DW HDMI controllers are accompanied with DW HDMI phy. Support custom phys by making controller code independent from phy code. Signed-off-by: NJernej Skrabec <jernej.skrabec@siol.net> Tested-by: NNickey Yang <nickey.yang@rock-chips.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Heiko Stübner 提交于
The Cortex-A9 socs rk3066 and rk3188 share the IP but have their own compatible values, so add them to make the i2c on these platforms accessible. Signed-off-by: NHeiko Stuebner <heiko@sntech.de> Acked-by: NSimon Glass <sjg@chromium.org>
-
由 Heiko Stübner 提交于
The armclk starts in slow mode (24MHz) on the rk3188, which results in U-Boot startup taking a lot of time (U-Boot itself, but also the rc4 decoding done in the bootrom). With default pmic settings we can always reach a safe frequency of 600MHz which is also the frequency the proprietary loader left the armclk at, without needing access to the systems pmic. Signed-off-by: NHeiko Stuebner <heiko@sntech.de> Acked-by: NSimon Glass <sjg@chromium.org>
-
由 Heiko Stübner 提交于
The armclk starts in slow mode (24MHz) on the rk3188, which makes the whole startup take a lot of time. We therefore want to at least move to the safe 600MHz value we can use with default pmic settings. This is also the freqency the proprietary sdram-init leaves the cpu at. For boards that have pmic control later in u-boot, we also add the option to set the maximum frequency of 1.6GHz, if they so desire. Signed-off-by: NHeiko Stuebner <heiko@sntech.de> Acked-by: NSimon Glass <sjg@chromium.org>
-
由 Heiko Stübner 提交于
In the beginning, we did SPL -> TPL -> U-Boot, but after clarification of the real ordering swapped SPL and TPL. It seems some renames were forgotten and may confuse future readers, so also swap these to reflect the actual ordering. Signed-off-by: NHeiko Stuebner <heiko@sntech.de> Acked-by: NSimon Glass <sjg@chromium.org>
-