- 13 8月, 2017 40 次提交
-
-
由 Philipp Tomsich 提交于
To build TPL and SPL stages for the RK3368, we will also need to enable the SPL_FRAMEWORK. Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Philipp Tomsich 提交于
For full SPL support, including DRAM initialisation, we need a few nodes from the DTS: this commit adds the DMC (DRAM controller) node, the service_msch (memory scheduler) node and marks GRF, PMUGRF and CRU as 'u-boot,dm-pre-reloc'. In addition to this, we also include the dt-binding for the DMC to allow DTS files including this DTSI to refer to the symbolic constants for the DDR3 bin and for the memory-schedule. Note that the DMC contains both the memory regions for the (Designware) protocol controller as well as the DDR PHY. Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Philipp Tomsich 提交于
This adds a DRAM controller driver for the RK3368 and places it in drivers/ram/rockchip (where the other DM-enabled DRAM controller drivers for rockchip devices should also be moved eventually). At this stage, only the following feature-set is supported: - DDR3 - 32-bit configuration (i.e. fully populated) - dual-rank (i.e. no auto-detection of ranks) - DDR3-1600K speed-bin This driver expects to run from a TPL stage that will later return to the RK3368 BROM. It communicates with later stages through the os_reg2 in the pmugrf (i.e. using the same mechanism as Rockchip's DDR init code). Unlike other DMC drivers for RK32xx and RK33xx parts, the required timings are calculated within the driver based on a target frequency and a DDR3 speed-bin (only the DDR3-1600K speed-bin is support at this time). The RK3368 also has the DDRC0_CON0 (DDR ch. 0, control-register 0) register for controlling the operation of its (single-channel) DRAM controller in the GRF block. This provides for selecting DDR3, mobile DDR modes, and control low-power operation. As part of this change, DDRC0_CON0 is also added to the GRF structure definition (at offset 0x600). Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Philipp Tomsich 提交于
Handling TPL and SPL in the Makefile for mach-rockchip was based on nested if checks and/or if-else-if paths. This can be simplified and made more readable by using $(SPL_TPL_) and by introducing intermediate variables for the aggregation of SPL and TPL features. Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Philipp Tomsich 提交于
The GMAC in the RK3368 once again is identical to the incarnation in the RK3288 and the RK3399, except for where some of the configuration and control registers are located in the GRF. This adds the RK3368-specific logic necessary to reuse this driver. Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: NSimon Glass <sjg@chromium.org> Acked-by: NJoe Hershberger <joe.hershberger@ni.com>
-
由 Philipp Tomsich 提交于
As SPI support may be useful in the boot-flow, this adds support for configuring the SPI controller's clocks in the RK3368 clock driver. Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Philipp Tomsich 提交于
With the clock support in rk3368_clk_set_rate() conditionalized on various feature definitions, 'priv' can remain unused (e.g. in the SPL build when only MMC is enabled). Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Philipp Tomsich 提交于
To enable the GMAC on the RK3368, we need to set up the clocking appropriately to generate a tx_clk for the MAC. This adds an implementation that implements the use of the <&ext_gmac> clock (i.e. an external 125MHz clock for RGMII provided by the PHY). This is the clock setup used by the boards currently supported by U-Boot (i.e. Geekbox, Sheep and RK3368-uQ7). This includes the change from commit - rockchip: clk: rk3368: define GMAC_MUX_SEL_EXTCLK Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Philipp Tomsich 提交于
As part of the DRAM initialisation process (running as part of the TPL stage) on the RK3368, we need to set up the DRAM PLL. This implements support for configuring the PLL to for 1200, 1332 or 1600 MHz (i.e. for DDR3-1200, DDR3-1333, DDR3-1600 operating modes). Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Philipp Tomsich 提交于
The original clock support for MMC/SD cards on the RK3368 suffered from a tendency to select a divider less-or-equal to the the one giving the requested clock-rate: this can lead to higher-than-expected (or rather: higher than supported) clock rates for the MMC/SD communiction. This change rewrites the MMC/SD clock generation to: * always generate a clock less-than-or-equal to the requested clock * support reparenting among the CPLL, GPLL and OSC24M parents to generate the highest clock that does not exceed the requested rate In addition to this, the Linux DTS uses HCLK_MMC/HCLK_SDMMC instead of SCLK_MMC/SCLK_SDMMC: to match this (and to ensure that clock setup always works), we adjust the driver appropriately. This includes the changes from: - rockchip: clk: rk3368: convert MMC_PLL_SEL_* definitions to shifted-value form Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Philipp Tomsich 提交于
On he RK3368, we need to temporarily disable security on the DMA engines during TPL and SPL to allow the MMC host to DMA into DRAM. To do so, we need to reset the two DMA engines, which in turn requires the DMA1_SRST_REQ and DMA2_SRST_REQ constants to refer to the appropriate bits in the CRU. As the ATF correctly initialises security (and only leaves EL3 after doing so), this can not pose a security issue. Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Philipp Tomsich 提交于
To implement a TPL stage (incl. its DRAM controller setup) for the RK3368, we'll want to configure the DPLL (DRAM PLL). This commit implements setting the DPLL (CLK_DDR) and provides PLL configuration details for the common DRAM operating speeds found on RK3368 boards. Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Philipp Tomsich 提交于
The RK3368 has a somewhat temperamental BootROM (which I learned the hard way) when it comes to reconfiguring the CPLL and GPLL (in fact, experiments show that changing the GPLL broke things for me, while changing the CPLL seems to be more benign). These should not be modified by the SPL stage, if we intend to return to the BootROM for chain booting the next stage. This commit changes the clock initialisation to not change CPLL/GPLL before returning to the BootROM (i.e. in TPL). As it's safe to change these settings if we no longer intend to return to U-Boot, we'll run the full PLL setup a little later (i.e. in SPL). Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Philipp Tomsich 提交于
With the RK3368's limited TPL size, we'll want to use OF_PLATFDATA for the SPL stage. This implements support for OF_PLATDATA in the clock driver for the RK3368. Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Philipp Tomsich 提交于
The RK3368 TRM recommends to configure the bandwith adjustment (CON2) for PLLs to NF/2. This implements this for all reconfigurations of PLLs and removes the 'has_bwadj' flag (as the RK3368 always has the bandwidth-adjustment feature according to its manual). Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Philipp Tomsich 提交于
To implement pinctrl support for the RK3368, we need to add the bit-definitions to configure the IOMUX and tie these into the pinctrl framework. This also adds the mapping from the IRQ# back onto the periheral id for the SPI devices. Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Philipp Tomsich 提交于
There is no real reason to keep the bit-definitions for the IOMUX in the grf header file (which defines the register layout of the GRF block): these should only be used by our pinctrl driver (with the possible exception of early debug-init code in TPL/SPL). This moves the relevant definitions from the grf_rk3368.h header into the pinctrl driver pinctrl_rk3368.c. Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Philipp Tomsich 提交于
The RK3368 has two SD/MMC controllers that can be used from U-Boot both during SPL and for booting an OS from the full bootloader stage. While both are configured to (mostly) sensible settings from the BROM, additional configuration for the MMC controller is needed to configure it to 8bit mode. This adds pinctrl support for the MMC controller. Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-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 mode: * adds a PERIPH_ID_GMAC and the mapping from IRQ number to PERIPH_ID * configures the RGMII pins Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Philipp Tomsich 提交于
We will to drop device security temporarily (until the ATF initialises it fully) from the TPL/SPL stage: this requires access to some registers in the SGRF. This adds the sgrf node to the rk3368.dtsi, so we can then bind a syscon device onto it and access its memory ranges. Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Philipp Tomsich 提交于
The RK3368 GRF header was still defines with a shifted-mask but with non-shifted function selectors for the IOMUX defines. As the RK3368 support is still fresh enough to allow a quick change, we do this now before having more code use this. Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
-
由 Philipp Tomsich 提交于
In TPL we will need to configure security in the SGRF of the RK3368. This change adds support for the SGRF as a syscon device, so we can retrieve its address range through the syscon API in TPL (and can avoid having to hard-code the address). Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Philipp Tomsich 提交于
The RK3368 has both a limited TPL size (just 0x7000 bytes) and the added challenge of booting in AArch64, which increases the code size for TPL (particularily when using the LP64 programming model). For this reason we expect the RK3368 to always use OF_PLATDATA for its TPL stage. This change adds support for the MSCH, PMUGRF and GRF register regions in syscon, which are necessary for initialising the RK3368's DRAM controller. Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Philipp Tomsich 提交于
For the RK3368, we use a multi-stage boot-process consisting of the following: 1. TPL: initalises DRAM, returns to boot-ROM (which then loads the next stage and transfers control to it) 2. SPL: a full-features SPL stage including OF_CONTROL and FIT image loading, which fetches the ATF, DTB and full U-Boot and then transfers control to the ATF (using the BL31 parameter block to indicate the location of BL33/U-Boot) 3. ATF: sets up the secure world and exits to BL33 (i.e. a full U-Boot) in the normal world 4. full U-Boot TPL/SPL and the full U-Boot are built from this tree and need to run from distinct text addresses and with distinct initial stack pointer addresses. This commit sets up the configuration to run: - TPL from the SRAM at 0xff8c0000 (note that the first 0x1000 are reserved for use by the boot-ROM and contain the SP when the TPL is entered) - SPL from DRAM at 0x0 - U-Boot from DRAM at 0x200000 Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Philipp Tomsich 提交于
The BootROM of the RK3368 Boot ROM does not initialise cntfrq_el0. 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 the counter-frequency is not correctly set up, the calculation of delays using the ARMv8 generic timer can not work correctly. Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Philipp Tomsich 提交于
On the RK3368 we use a TPL-stage similar to Rockchip's DDR init (i.e. it initialises DRAM, leaves some info for the next stage and returns to the BootROM). To allow compatibility with Rockchip's DDR init code, we use the same register os_reg2 in pmugrf for passing this info (i.e. DRAM size and configuration) between stages. This change adds the definitions for os_reg[0] through os_reg[3] to the pmugrf structure for the RK3368. Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Philipp Tomsich 提交于
This commit adds support for RK3368 SoC in mkimage. Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Philipp Tomsich 提交于
The RK3368 option in Kconfig referred to the RK3328 (copy-and-paste) and had a few typos and unnecessarily used UTF-8 characters. While fixing this, I also reformatted and further clarified the text (e.g. made the grouping into a a big and little cluster of 4 cores each explicit). Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Philipp Tomsich 提交于
The utility functions in sdram_common.c will be useful both for some SPL implementations (and if unused, the linked will discard these anyway) and for the full U-Boot stage. This changes selects sdram_common.o through the $(SPL_TPL_) macro to allow better control of its inclusion through the CONFIG_ROM, CONFIG_SPL_RAM or CONFIG_TPL_RAM options. Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Philipp Tomsich 提交于
To simplify drivers/Makefile a bit when using TPL/SPL, we consistently use the $(SPL_TPL_) macro to test for drivers that have separate configuration symbols for the full U-boot, SPL and TPL stages. Instead of explicitly repeating them in two separate if-guarded sections of the Makefile, we can now simply list these options once. Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: NSimon Glass <sjg@chromium.org> Reviewed-by: NTom Rini <trini@konsulko.com>
-
由 Philipp Tomsich 提交于
This adds the TPL_DRIVER_MISC_SUPPORT option to allow activation of DRIVER_MISC_SUPPORT for devices that need it in the TPL stage. Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: NSimon Glass <sjg@chromium.org> Reviewed-by: NTom Rini <trini@konsulko.com>
-
由 Philipp Tomsich 提交于
To allow for a finer-grained control of features for TPL and SPL builds all modules/boot-methods/etc. need to be consistently selected based on the $(SPL_TPL_) macros. This allows splitting the associated config-options in Kconfig: we don't split the Kconfig options here and now, as this should happen on an as-needed basis, whenever someone needs a feature/boot-method/etc. in their TPL. Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: NSimon Glass <sjg@chromium.org> Reviewed-by: NTom Rini <trini@konsulko.com>
-
由 Philipp Tomsich 提交于
This splits the compilation of code modules for TPL and SPL for OF_CONTROL (and related) features between TPL and SPL. The typical use-case of this is a TPL stage that uses OF_PLATDATA at TPL and provides full OF_CONTROL at SPL (e.g. on the RK3368). Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: NSimon Glass <sjg@chromium.org> Reviewed-by: NTom Rini <trini@konsulko.com>
-
由 Philipp Tomsich 提交于
As include/malloc.h already checks for SYS_MALLOC_SIMPLE using the CONFIG_IS_ENABLED macro, we need to move to having separate entries as we switch to fully separate configuration for SPL and TPL. Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: NSimon Glass <sjg@chromium.org> Reviewed-by: NTom Rini <trini@konsulko.com>
-
由 Philipp Tomsich 提交于
For the bringup of the RK3368, we need to support TPL and SPL running from different addresses... which requires both stages to use a distinct TEXT_BASE. This commit adds support for having a separate LDSCRIPT for TPL (which is expected to make use of the TPL_MAX_SIZE define) and for having a the option of defining TPL_TEXT_BASE and having the TPL stage linked against this address. Note that the handling of the TEXT_BASE is designed to not interfere with the previous assumption that SPL_TEXT_BASE should be used for TPL as well, unless TPL_TEXT_BASE is defined. For this reason, the test in Makefile.spl uses the following (seemingly redundant checks): 1. looks for $(SPL_TPL_)TEXT_BASE 2. looks for SPL_TEXT_BASE (even when building in TPL) Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Philipp Tomsich 提交于
To allow a TPL and SPL to run from different addresses/memories, we need to split setup of the TPL and SPL stacks. To do so, we introduce CONFIG_TPL_STACK (not listed in Kconfig) which can be used to override the initial stack pointer for TPL. To provide backward compatibility for existing boards, this is added as an optional configuration item and the normal search order (i.e. SPL_STACK, then SYS_STACK) apply if not defined. Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: NSimon Glass <sjg@chromium.org> Reviewed-by: NTom Rini <trini@konsulko.com>
-
由 Philipp Tomsich 提交于
TPL builds today don't need to call into firmware or set up the MMU (if this changes, it should be controlled through a config option whether to include this or not), but include the needed support code for this anyway. By moving these unused low-level functions into seperate function-sections, the linker can garbage-collect the unused sections. Note that (if DM support is enabled), there will be a call to the cache-flushing code from alloc_priv(...) in drivers/core/device.c. This then add 52 bytes of binary size (an increase from 20589 to 20641 bytes) compared to completely removing this code. Even for a feature-rich TPL (including DM support as for the RK3368), this equates to a size difference of significantly more than 10% in TPL binary size. Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Philipp Tomsich 提交于
Even though there's now a TPL_DM configuration option, the spl logic still checks for SPL_DM and thus does not pick up the proper config option. This introduces the use of CONFIG_IS_ENABLED(DM) in spl.c to always pick up the desired configuration option instead of having a hard-coded check for the SPL variant. Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: NSimon Glass <sjg@chromium.org> Reviewed-by: NTom Rini <trini@konsulko.com>
-
由 Philipp Tomsich 提交于
For the RK3368, we want to use OF_PLATDATA in TPL, but full OF_CONTROL in SPL: this requires the introduction of a new family of configuration options to decouple SPL_OF_CONTROL and SPL_OF_PLATDATA from TPL. Consequently, Makefile.spl needs to be adjusted to test for these configuration items through the $(SPL_TPL_) macro instead of hard-coding the SPL variant. Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: NSimon Glass <sjg@chromium.org> Reviewed-by: NTom Rini <trini@konsulko.com>
-
由 Philipp Tomsich 提交于
Introduce TPL_CLK to allow finer-grained selection of TPL features for feature-rich (i.e. DM-based) TPL stages. Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: NSimon Glass <sjg@chromium.org> Reviewed-by: NTom Rini <trini@konsulko.com>
-