13 Aug, 2017

40 commits

  • With the hierarchical defaults set up, we remove these from the header
    files. To do so, I've run moveconfig on SPL_LDSCRIPT and this commits
    the changes.

    Signed-off-by: Philipp Tomsich
    Reviewed-by: Simon Glass

    Philipp Tomsich
     
  • With SPL_LDSCRIPT moved to Kconfig (and this being a 'string' config
    node), all the lingering definitions in header files will cause
    warnings/errors due to the redefinition of the configuration item.

    As we don't want to pollute the defconfig files (and values should
    usually be identical for entire architectures), the defaults are moved
    into Kconfig. Kconfig will always pick the first default that
    matches, so please keep these values at the end of each file (to allow
    any board-specific Kconfig, which will be included earlier) to
    override with an unconditional default setting.

    Signed-off-by: Philipp Tomsich
    Reviewed-by: Simon Glass

    Philipp Tomsich
     
  • With the changes to split SPL/TPL for the RK3368, I apparently missed
    some needed adjustments to the RK3188 Kconfig and rock_defconfig.

    This fixes build-issues for the rock board after applying the RK3368
    enablement (and SPL/TPL) set that resulted from TPL_SERIAL_SUPPORT,
    TPL_ROCKCHIP_BACK_TO_BROM and TPL_TINY_MEMSET being separate symbols
    now.

    Signed-off-by: Philipp Tomsich
    Reviewed-by: Simon Glass

    Philipp Tomsich
     
  • As the debug uart is marked as dm-pre-reloc, the pinctrl driver
    will handle the correct iomux setting.

    Signed-off-by: Andy Yan
    Acked-by: Philipp Tomsich
    Reviewed-by: Philipp Tomsich
    Reviewed-by: Simon Glass

    Andy Yan
     
  • The default 1kb pre-reloc malloc pool is not enough for dm
    core to enable the dm-pre-reloc device drivers.

    Signed-off-by: Andy Yan
    Acked-by: Philipp Tomsich
    Reviewed-by: Philipp Tomsich

    Andy Yan
     
  • Device drivers like debug serial, dmc should be enabled before
    relocation, so add u-boot.dtsi files to contain devices that
    should be marked as dm-pre-reloc.

    Signed-off-by: Andy Yan
    Reviewed-by: Philipp Tomsich
    Acked-by: Philipp Tomsich
    Reviewed-by: Simon Glass

    Andy Yan
     
  • When using DM timers w/ the timer0 block within the RK3368, we no
    longer depend on the ARMv8 generic timer counting. This allows us to
    drop the secure timer initialisation from the TPL and SPL stages.

    The secure timer will later be set up by ATF, which starts the ARMv8
    generic timer. Thus, there will be a dependency from Linux to the ATF
    through the ARMv8 generic timer... this seems reasonable, as Linux
    will require the ATF (and PSCI) to start up the secondary cores anyway
    (in other words: we don't add any new dependencies).

    Signed-off-by: Philipp Tomsich
    Reviewed-by: Simon Glass

    Philipp Tomsich
     
  • There is no reasonably robust way (this will be needed so early that
    diagnostics will be limited) to specify the base-address of the secure
    timer through the DTS for TPL and SPL. In order to allow us a cleaner
    way to structure our SPL and TPL stage, we now move to a DM timer
    driver.

    Signed-off-by: Philipp Tomsich
    Reviewed-by: Simon Glass

    Philipp Tomsich
     
  • To use it with the DM timer driver in SPL and TPL, timer0 needs to be
    marked as pre-reloc.

    Signed-off-by: Philipp Tomsich
    Reviewed-by: Simon Glass

    Philipp Tomsich
     
  • This adds a device-model driver for the timer block in the RK3368 (and
    similar devices that share the same timer block, such as the RK3288) for
    the down-counting (i.e. non-secure) timers.

    This allows us to configure U-Boot for the RK3368 in such a way that
    we can run with the secure timer inaccessible or uninitialised (note
    that the ARMv8 generic timer does not count, if the secure timer is
    not enabled).

    Signed-off-by: Philipp Tomsich
    Reviewed-by: Simon Glass

    Philipp Tomsich
     
  • To fully support DM timer in SPL and TPL, we need a few things cleaned
    up and normalised:
    - inclusion of the uclass and drivers should be an all-or-nothing
    decision for each stage and under control of $(SPL_TPL_)TIMER
    instead of having the two-level configuration with TIMER and
    $(SPL_TPL_)TIMER_SUPPORT
    - when $(SPL_TPL_)TIMER is enabled, the ARMv8 generic timer code can
    not be compiled in

    This normalises configuration to $(SPL_TPL_)TIMER and moves the config
    options to drivers/timer/Kconfig (and cleans up the collateral damage
    to some defconfigs that had SPL_TIMER_SUPPORT enabled).

    Signed-off-by: Philipp Tomsich
    Reviewed-by: Simon Glass

    Philipp Tomsich
     
  • The timer-uclass depends on full OF_CONTROL through its interrogation
    of /chosen and the code to determine the clock-frequency.

    For the OF_PLATDATA case, these code-paths are disabled and it becomes
    the timer driver's responsibility to correctly set the clock-frequency
    in the uclass priv-data.

    Signed-off-by: Philipp Tomsich
    Reviewed-by: Simon Glass

    Philipp Tomsich
     
  • Splitting the feature selection for SPL and TPL, caused a few build
    failures to mpx85xx boards. This fixes the fallout by adding the
    needed new option names to the respective defconfig files.

    Signed-off-byL Philipp Tomsich

    Philipp Tomsich
     
  • prefix the bl31 firmware needed to build uboot.itb so it can coexist in
    the build area with ATFs from other boards (i.e. lion_rk3368)

    Signed-off-by: Klaus Goger
    Signed-off-by: Philipp Tomsich
    Reviewed-by: Simon Glass

    Klaus Goger
     
  • The ITS file generated warnings due to @ designations in the naming
    which cause DTC to complain as follows:
    Warning (unit_address_vs_reg): Node /images/uboot@1 has a unit name, but no reg property
    Warning (unit_address_vs_reg): Node /images/atf@1 has a unit name, but no reg property
    Warning (unit_address_vs_reg): Node /images/pmu@1 has a unit name, but no reg property
    Warning (unit_address_vs_reg): Node /images/fdt@1 has a unit name, but no reg property
    Warning (unit_address_vs_reg): Node /configurations/conf@1 has a unit name, but no reg property

    This removes the @ part from the names, as we only have a single
    image for each payload aspect (and only a single configuration) anyway.

    Signed-off-by: Philipp Tomsich
    Reviewed-by: Simon Glass

    Philipp Tomsich
     
  • We can finally drop TPL_STACK, TPL_TEXT_BASE and TPL_MAX_SIZE off the
    whitelist (this time it's really happening!) and migrate the setting
    (only used on the RK3368-uQ7 so far) into Kconfig.

    Signed-off-by: Philipp Tomsich
    Reviewed-by: Simon Glass

    Philipp Tomsich
     
  • The RK3368 needs to have a different base-address and stack-pointer
    for its TPL stage. Now that we want to do this via Kconfig, we need
    to tick the appropriate 'TPL_NEEDS_...' boxes.

    Signed-off-by: Philipp Tomsich
    Reviewed-by: Simon Glass

    Philipp Tomsich
     
  • Now that TPL_STACK has been moved off the whitelist (ok, I'm lying:
    the 'moving off the whitelist' part comes in once moveconfig
    runs... which will be a few commits down the line) and added to
    Kconfig, we need to test CONFIG_TPL_NEEDS_SEPARATE_STACK to see
    whether the value from TPL_STACK should be used or whether we try to
    inherit whatever SPL uses.

    Signed-off-by: Philipp Tomsich
    Reviewed-by: Simon Glass

    Philipp Tomsich
     
  • Let's clean up behind ourselves and move the (newly defined)
    TPL_STACK, TPL_MAX_SIZE and TPL_TEXT_BASE into Kconfig. Given that
    0x0 might be considered to be valid values for TPL_TEXT_BASE and
    TPL_STACK, we need to introduce helper config options
    ("TPL_NEEDS_SEPARATE_...") to indicate that these symbols are used
    (and not inherited from their SPL variants) for any given
    target-platform.

    Signed-off-by: Philipp Tomsich
    Reviewed-by: Simon Glass

    Philipp Tomsich
     
  • Set TPL_LDSCRIPT in Kconfig, so we don't have to pollute our
    header file.

    Signed-off-by: Philipp Tomsich

    Philipp Tomsich
     
  • Now that we have split up SPL_LDSCRIPT into a SPL and TPL variant and
    have started to use the TPL-variant for the RK3368, it's time to clean
    up behind ourselves: move both variants into Kconfig and remove them
    from the whitelist.

    Signed-off-by: Philipp Tomsich
    Reviewed-by: Simon Glass

    Philipp Tomsich
     
  • The RK3368-uQ7 (codenamed 'Lion') is a micro-Qseven (40mm x 70mm,
    MXM-230 edge connector compatible with the Qseven specification)
    form-factor system-on-module based on the octo-core Rockchip RK3368.
    It is designed, supported and manufactured by Theobroma Systems.

    It provides the following features:
    - 8x Cortex-A53 (in 2 clusters of 4 cores each)
    - (on-module) up to 4GB of DDR3 memory
    - (on-module) SPI-NOR flash
    - (on-module) eMMC
    - Gigabit Ethernet (with an on-module KSZ9031 PHY)
    - USB
    - HDMI
    - MIPI-DSI/single-channel LVDS (muxed on the 'LVDS-A' pin-group)
    - various 'slow' interfaces (e.g. UART, SPI, I2C, I2S, ...)

    Signed-off-by: Philipp Tomsich
    Reviewed-by: Simon Glass

    Philipp Tomsich
     
  • For the RK3368, we can reuse the SPI driver (although we'll have to
    eventually investigate whether it can be merged with the
    designware_spi.c driver) also used for the RK3288 and RK3399.
    This adds the necessary compatible string to support the RK3368.

    Note that the assumption that GPLL will be clocked at 594MHz is not
    true for the RK3368, but this will not lead to incorrect functioning
    (just to a lower-than-expected SPI operating frequency): this has been
    documented in the driver, so it doesn't cause any headaches when
    someone next needs to touch the clock code of this driver.

    Signed-off-by: Philipp Tomsich
    Reviewed-by: Simon Glass

    Philipp Tomsich
     
  • With SPL and TPL support for the RK3368 in place, mark SPL and TPL as
    supported from Kconfig for the RK3368. As this is primarily tested on
    the RK3368-uQ7, we'll leave it to board's individual defconfig to
    enable.

    Also enable DEBUG_UART_BOARD_INIT for the RK3368, so we get output
    during the early boot-up, as we turn on TPL and SPL.

    Signed-off-by: Philipp Tomsich
    Reviewed-by: Simon Glass

    Philipp Tomsich
     
  • Adds SPL support for the RK3368 (assuming that our TPL stage has
    initialised DRAM and set up the memory firewall).

    Signed-off-by: Philipp Tomsich
    Reviewed-by: Simon Glass

    Philipp Tomsich
     
  • In order to reuse the support for the u-boot,spl-boot-order property
    from the rk3399, we split it into a reusable module that can be
    included by the SPL code for any of our boards.

    Signed-off-by: Philipp Tomsich
    Reviewed-by: Simon Glass

    Philipp Tomsich
     
  • This adds the TPL support for the RK3368, including the u-boot-tpl.lds.

    Signed-off-by: Philipp Tomsich
    Reviewed-by: Simon Glass

    Philipp Tomsich
     
  • To build TPL and SPL stages for the RK3368, we will also need to
    enable the SPL_FRAMEWORK.

    Signed-off-by: Philipp Tomsich
    Reviewed-by: Simon Glass

    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: Philipp Tomsich
    Reviewed-by: Simon Glass

    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: Philipp Tomsich
    Reviewed-by: Simon Glass

    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: Philipp Tomsich
    Reviewed-by: Simon Glass

    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: Philipp Tomsich
    Reviewed-by: Simon Glass
    Acked-by: Joe Hershberger

    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: Philipp Tomsich
    Reviewed-by: Simon Glass

    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: Philipp Tomsich
    Reviewed-by: Simon Glass

    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
    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: Philipp Tomsich
    Reviewed-by: Simon Glass

    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: Philipp Tomsich
    Reviewed-by: Simon Glass

    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: Philipp Tomsich
    Reviewed-by: Simon Glass

    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: Philipp Tomsich
    Reviewed-by: Simon Glass

    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: Philipp Tomsich
    Reviewed-by: Simon Glass

    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: Philipp Tomsich
    Reviewed-by: Simon Glass

    Philipp Tomsich