Sometimes it's helpful to know the reset reason caused in the SoC.
Add reset reason detection for the RK3288 SoC.
This will set an environment variable which represents the reset reason.
Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
This converts the following to Kconfig:
CONFIG_SYS_I2C_BUS_MAX
Signed-off-by: Adam Ford <aford173@gmail.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
[trini: Fix AM43XX drop AM44XX]
Signed-off-by: Tom Rini <trini@konsulko.com>
For consistency with other platforms and in preparation of Kconfig
migration, let's change Several TI platforms that use I2C_BUS_MAX
to CONFIG_SYS_I2C_BUS_MAX
Signed-off-by: Adam Ford <aford173@gmail.com>
SUNXI_GMAC was still used to configure the code where as the
same has been renamed and moved to Kconfig in below commit
"sunxi: Move SUNXI_GMAC to Kconfig"
(sha1: 4d43d065db)
Signed-off-by: Dave Prue <dave@prue.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jagan Teki <jagan@openedev.com>
Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
Tested-by: Mark Kettenis <kettenis@openbsd.org>
[Tweek commit message, config_whitelist.txt, build-whitelist.sh]
Signed-off-by: Jagan Teki <jagan@openedev.com>
Almost all of the newer Allwinner SoCs have a new operating mode for the
eMMC clocks that needs to be enabled in both the clock and the MMC
controller.
Details about that mode are sparse, and the name itself (new mode vs old
mode) doesn't give much details, but it seems that the it changes the
sampling of the MMC clock. One side effect is also that it divides the
parent clock rate by 2.
Add support for it through a Kconfig option.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>
Since the gpr_init() function is common for boards using MX6S, MX6DL, MX6D,
MX6Q and MX6QP processors move it to the soc.c file.
Signed-off-by: Breno Lima <breno.lima@nxp.com>
Acked-by: Stefano Babic <sbabic@denx.de>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
kASLR support in kernel requires a random number to be passed via
chosen/kaslr-seed propert. sec_firmware generates this random seed
which can then be passed in the device tree node.
sec_firmware reserves JR3 for it's own usage. Node for JR3 is
removed from device-tree.
Signed-off-by: Ruchika Gupta <ruchika.gupta@nxp.com>
Add the reserved boot mode used in the bmode command for i.MX 6UL
and 6ULL as introduced in commit 3fd9579085 ("imx: mx6ull: fix USB
bmode for i.MX 6UL and 6ULL").
Also replace BMODE_UART with BMODE_RESERVED, which is more appropriate.
Commit 96aac843b6 ("imx: Use IMX6_BMODE_* macros instead of numericals")
added macros for boot modes, in the process the reserved boot mode got
named BMODE_UART. We use the reserved boot mode in the bmode command to
let the boot ROM enter serial downloader recovery mode. But this is only
a side effect, the actual boot mode is reserved...
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Some files for i.MX do not yet have the SPDX ID to reference the correct
license.
Signed-off-by: Stefano Babic <sbabic@denx.de>
Reviewed-by: Wolfgang Denk <wd@denx.de>
The description for eMMC/SDIO/SDMMC src is not correct,
update the CRU_CLKSEL11_CON value definition according to TRM.
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
A few years ago STM32F1 SoCs support has been added :
0144caf22c gpio: stm32: add stm32f1 support
2d18ef2364 ARMv7M: add STM32F1 support
But neither STM32F1 dedicated defconfig nor board was
associated to these commits.
Got confirmation from Tom Rini and Matt Porter to remove
all this code [1]
[1] http://u-boot.10912.n7.nabble.com/Remove-STM32F1-support-td301603.html
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
OMAP5432 did go into production with AVS class0 registers which were
mutually exclusive from AVS Class 1.5 registers.
Most OMAP5-uEVM boards use the pre-production Class1.5 which has
production efuse registers set to 0. However on production devices,
these are set to valid data.
scale_vcore logic is already smart enough to detect this and use the
"Nominal voltage" on devices that do not have efuse registers populated.
On a test production device populated as follows:
MPU OPP_NOM:
=> md.l 0x04A0021C4 1
4a0021c4: 03a003e9 ....
(0x3e9 = 1.01v) vs nom voltage of 1.06v
MPU OPP_HIGH:
=> md.l 0x04A0021C8 1
4a0021c8: 03400485 ..@.
MM OPP_NOM:
=> md.l 0x04A0021A4 1
4a0021a4: 038003d4 ....
(0x3d4 = 980mV) vs nom voltage of 1.025v
MM OPP_OD:
=> md.l 0x04A0021A8 1
4a0021a8: 03600403 ..`.
CORE OPP_NOM:
=> md.l 0x04A0021D8 1
4a0021d8: 000003cf ....
(0x3cf = 975mV) vs nom voltage of 1.040v
Since the efuse values are'nt currently used, we do not regress on
existing pre-production samples (they continue to use nominal voltage).
But on boards that do have production samples populated, we can leverage
the optimal voltages necessary for proper operation.
Tested on:
a) 720-2644-001 OMAP5UEVM with production sample.
b) 750-2628-222(A) UEVM5432G-02 with pre-production sample.
Data based on OMAP5432 Technical reference Manual SWPU282AF (May
2012-Revised Aug 2016)
NOTE: All collaterals on OMAP5432 silicon itself seems to have been
removed from ti.com, though EVM details are still available:
http://www.ti.com/tool/OMAP5432-EVM
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
It should be '<<' instead of '<' for _MASK definition, fix it.
Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
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 <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
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 <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
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: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
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 <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
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 <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
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: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
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: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
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: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Some devices (e.g. the RK3368) have only limited SRAM, but provide
support for loading the next boot stage after our SPL performs basic
setup (e.g. DRAM).
For target systems like these, we add a boot device BOOTROM that will
invoke a board-specific hook to return to the bootrom (if supported).
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Some new Allwinner SoCs' PRCM has a secure switch register, which
controls the access to some clock and power registers in PRCM block.
Add the definition of this register and its bits in the PRCM header
file.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Tested-by: Chen-Yu Tsai <wens@csie.org>
Reviewed-by: Jagan Teki <jagan@openedev.com>
move to Kconfig:
CONFIG_BCM_SF2_ETH
CONFIG_BCM_SF2_ETH_DEFAULT_PORT
CONFIG_BCM_SF2_ETH_GMAC
Also modified defconfigs of all platforms that use these configs.
Signed-off-by: Suji Velupillai <suji.velupillai@broadcom.com>
Tested-by: Suji Velupillai <suji.velupillai@broadcom.com>
Reviewed-by: JD Zheng <jiandong.zheng@broadcom.com>
Reviewed-by: Scott Branden <scott.branden@broadcom.com>
Signed-off-by: Steve Rae <steve.rae@raedomain.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Modify chip_id() routine such that to handle based on
the current el. Also make it available even if FPGA is
not enabled in system such it can be used always.
Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
This patch makes chip_id() as a global routine so that
it can be used in other places as required.
Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
This patch modifies the chip_id routine to get either idcode or
silicon version based on the argument received.
Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Remove incorrect code of writing to system timestamp
counter registers. This register writes does nothing
and can be removed.
Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
TCM on ZynqMP needs to be intialized in a sequence
and this patch provides a global routine to perform
this as per requirement.
Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
The duplicate definitions for IH_ARCH_ARM and IH_ARCH_ARM64 are removed.
The definitions in <image.h> are used.
According to this modification, the comparison between os arch and cpu
arch is done in C programming instead of ASM programming.
Signed-off-by: Alison Wang <alison.wang@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
Now that EHCD does not use CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS,
remove it in all boards' config files.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Tested-by: Stefan Roese <sr@denx.de>
Adjust this to take a device as a parameter instead of a node.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Tested-on: Beaver, Jetson-TK1
Tested-by: Stephen Warren <swarren@nvidia.com>
Adjust this code to support a live device tree. This should be implemented
as a PHY driver but that is left as an exercise for the maintainer.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Stephen Warren <swarren@nvidia.com>
The PMC can be modelled as a syscon peripheral. Add a driver for this
so that it can be accessed by drivers when needed. Enable it for tegra124
boards.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Tested-on: Beaver, Jetson-TK1
Tested-by: Stephen Warren <swarren@nvidia.com>
This removes the unused 'rate' field from both rk3399_pmuclk_priv and
rk3399_clk_priv. I didn't bother to check where this came from (i.e.
what the historical context of these was), but only verified that
these are indeed unused across all code-paths.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The rk3368_clk_priv has two unused fields: rate, has_bwadj. This
removes them as there's no need for either (i.e. has_bwadj is always
true for the RK3368, according to its TRM).
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
When building for a TPL/SPL setup (e.g. on the RK3368), we need the
TPL stage to have the extra space for for the 'Rockchip SPL name'
(i.e. 'RK33' word). Yet, the SPL will start execution at its first
word (i.e. the first word in the SPL binary needs to be a valid
instruction). To make things a bit more involved, CONFIG_SPL_BUILD
is defined both for the SPL and the TPL stage.
To avoid having to explicitly test for the first stage (TPL, if and
only if TPL and SPL are built, SPL otherwise), this commit modifies
the sequence to repeat the 'b reset' (instead of reserving 4 bytes
of undefined space) at the start of the boot0 hook: if overwritten
(and execution starts at the second word), the first instruction is
still a 'b reset'... if not overwritten, we start on a 'b reset' as
well.
This solution wouldn't even require the check whether we are in the
SPL/TPL build (i.e. CONFIG_SPL_BUILD), but we leave this check in for
documentation purposes.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
