Re: [PATCH v2 4/4] board: rockchip: Add Radxa ROCK 5 ITX
On Fri, 2 Aug 2024 at 23:00, Heiko Stuebner wrote:
>
> The Rock 5 ITX is board in ITX form factor using the RK358 SoC
type "is a board"
typo: "RK3588"
> It can be powered either by 12V, ATX power-supply or PoE.
>
> Notable peripherals are the 4 SATA ports, M.2 M-Key slot, M.2 E-key slot,
> 2*2.5Gb PCIe-connected Ethernet NICs.
>
> Display options are 2*HDMI, DP via USB-c, eDP + 2*DSI via PCB connectors.
>
> USB ports are 4*USB3 + 2*USB2 on the back panel and 2-port front-panel
> connector.
>
> Schematics for the board can be found on
> - https://dl.radxa.com/rock5/5itx/radxa_rock_5_itx_X1100_schematic.pdf
> - https://dl.radxa.com/rock5/5itx/v1110/radxa_rock_5itx_v1110_schematic.pdf
>
> The naming scheme with the dashes follows Dragan's comment on the mainline
> devicetree commit:
> "the name of this board deviates from the standard Radxa naming scheme,
> which is something like "ROCK " thus, "rock-5a" is
> fine, but it should be "rock-5-itx", simply because there's a space
> between "5" and "ITX" in "ROCK 5 ITX"
>
> Signed-off-by: Heiko Stuebner
> ---
> arch/arm/dts/rk3588-rock-5-itx-u-boot.dtsi | 22
> arch/arm/mach-rockchip/rk3588/Kconfig | 29 ++
> board/radxa/rock-5-itx-rk3588/Kconfig | 12 +++
> board/radxa/rock-5-itx-rk3588/MAINTAINERS | 8 ++
> configs/rock-5-itx-rk3588_defconfig| 111 +
> doc/board/rockchip/rockchip.rst| 1 +
> include/configs/rock-5-itx-rk3588.h| 15 +++
> 7 files changed, 198 insertions(+)
> create mode 100644 arch/arm/dts/rk3588-rock-5-itx-u-boot.dtsi
> create mode 100644 board/radxa/rock-5-itx-rk3588/Kconfig
> create mode 100644 board/radxa/rock-5-itx-rk3588/MAINTAINERS
> create mode 100644 configs/rock-5-itx-rk3588_defconfig
> create mode 100644 include/configs/rock-5-itx-rk3588.h
>
> diff --git a/arch/arm/dts/rk3588-rock-5-itx-u-boot.dtsi
> b/arch/arm/dts/rk3588-rock-5-itx-u-boot.dtsi
> new file mode 100644
> index 000..1e5c2674e49
> --- /dev/null
> +++ b/arch/arm/dts/rk3588-rock-5-itx-u-boot.dtsi
> @@ -0,0 +1,22 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2023 Collabora Ltd.
> + */
> +
> +#include "rk3588-u-boot.dtsi"
> +
> +&fspim2_pins {
> + bootph-pre-ram;
> + bootph-some-ram;
> +};
> +
> +&sfc {
> + flash@0 {
> + bootph-pre-ram;
> + bootph-some-ram;
> + };
> +};
> +
> +&vcc3v3_mkey {
> + regulator-always-on;
> +};
> diff --git a/arch/arm/mach-rockchip/rk3588/Kconfig
> b/arch/arm/mach-rockchip/rk3588/Kconfig
> index e751d64e1a1..0dcf2249fb4 100644
> --- a/arch/arm/mach-rockchip/rk3588/Kconfig
> +++ b/arch/arm/mach-rockchip/rk3588/Kconfig
> @@ -185,6 +185,34 @@ config TARGET_ROCK5B_RK3588
> USB PD over USB Type-C
> Size: 100mm x 72mm (Pico-ITX form factor)
>
> +config TARGET_ROCK_5_ITX_RK3588
> + bool "Radxa ROCK-5-ITX RK3588 board"
> + select BOARD_LATE_INIT
> + help
> + Radxa ROCK-5-ITX is a Rockchip RK3588 based SBC (Single Board
> + Computer) by Radxa in the ITX formfactor.
> +
> + There are variants depending on the DRAM size : from 4G up to 32G.
> +
> + Specification:
> +
> + Rockchip Rk3588 SoC
> + 4x ARM Cortex-A76, 4x ARM Cortex-A55
> + 4/8/16/24/32GB memory LPDDR5
> + Mali G610MC4 GPU
> + 2x MIPI CSI 2 multiple lanes connector
> + eMMC
> + uSD slot (up to 128GB)
> + M.2 M-key and M.2 E-key connector
> + 4x SATA
> + 2x USB 2.0 + 4x USB 3.0 Type-A, 2x USB 2.0 Panel, 1x USB 3.0 Type-C
> + 2x HDMI 2.1 output, 1x HDMI input
> + DP via Type-C
> + 2x DSI via PCB connector
> + 2x 2.5 Gbps Ethernet port
> + Front-panel connectors for audio and case-power, -leds
> + Powered by either 12V, ATX power-supply or PoE
> +
> config TARGET_SIGE7_RK3588
> bool "ArmSoM Sige7 RK3588 board"
> select BOARD_LATE_INIT
> @@ -319,6 +347,7 @@ source "board/pine64/quartzpro64-rk3588/Kconfig"
> source "board/turing/turing-rk1-rk3588/Kconfig"
> source "board/radxa/rock5a-rk3588s/Kconfig"
> source "board/radxa/rock5b-rk3588/Kconfig"
> +source "board/radxa/rock-5-itx-rk3588/Kconfig"
> source "board/rockchip/evb_rk3588/Kconfig"
> source "board/rockchip/toybrick_rk3588/Kconfig"
> source "board/theobroma-systems/jaguar_rk3588/Kconfig"
> diff --git a/board/radxa/rock-5-itx-rk3588/Kconfig
> b/board/radxa/rock-5-itx-rk3588/Kconfig
> new file mode 100644
> index 000..f7a7666d531
> --- /dev/null
> +++ b/board/radxa/rock-5-itx-rk3588/Kconfig
> @@ -0,0 +1,12 @@
> +if TARGET_ROCK_5_ITX_RK3588
> +
> +config SYS_BOARD
> + default "rock-5-itx-rk3588"
> +
> +config SYS_VENDOR
> + default "radxa"
> +
> +config SYS_CONFIG_NAME
> + default "rock-5-itx-rk3588"
> +
> +endif
> diff --git a/board/radxa/rock-5-itx-rk3588/MAINTAINERS
> b/board/radxa/rock-5-itx-rk3588/MAIN
Re: [PATCH v2 2/2] rockchip: spl-boot-order: show DT path for missing device
On Thu, 14 Mar 2024 at 12:58, Christopher Obbard wrote: > > When debugging the SPL boot order, the node ID of a device which hasn't > been found is printed but it can be quite hard to relate that to the > specific devicetree node. To aid debugging, print the node path instead of > the cryptic node ID. > > Original debug message: > > board_boot_order: could not map node @73c to a boot-device > > With this patch applied this becomes e.g: > >board_boot_order: could not map node /spi@ff1d/flash@0 to a boot-device > > Reviewed-by: Dragan Simic > Signed-off-by: Christopher Obbard Reviewed-by: Philipp Tomsich
Re: [PATCH 13/17] mmc: rockchip_sdhci: Add support for RK3588
On Mon, 3 Apr 2023 at 22:48, Jonas Karlman wrote:
>
> Add support for RK3588 to the sdhci driver. RK3588 has the inverter flag
> in TXCLK reg instead of RXCLK and also make use of a new CMDOUT reg.
> Add and use a quirks field to support such quirks.
>
> Signed-off-by: Jonas Karlman
> ---
> drivers/mmc/rockchip_sdhci.c | 62 ++--
> 1 file changed, 59 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/rockchip_sdhci.c b/drivers/mmc/rockchip_sdhci.c
> index 12a616d3dfb8..9178bc00b6b8 100644
> --- a/drivers/mmc/rockchip_sdhci.c
> +++ b/drivers/mmc/rockchip_sdhci.c
> @@ -56,6 +56,7 @@
> #define DWCMSHC_EMMC_DLL_RXCLK 0x804
> #define DWCMSHC_EMMC_DLL_TXCLK 0x808
> #define DWCMSHC_EMMC_DLL_STRBIN0x80c
> +#define DWCMSHC_EMMC_DLL_CMDOUT0x810
> #define DWCMSHC_EMMC_DLL_STATUS0 0x840
> #define DWCMSHC_EMMC_DLL_STATUS1 0x844
> #define DWCMSHC_EMMC_DLL_START BIT(0)
> @@ -70,18 +71,28 @@
> #define DLL_RXCLK_NO_INVERTER BIT(29)
> #define DLL_RXCLK_ORI_GATE BIT(31)
> #define DLL_TXCLK_TAPNUM_DEFAULT 0x10
> +#define DLL_TXCLK_TAPNUM_90_DEGREES0x9
> #define DLL_TXCLK_TAPNUM_FROM_SW BIT(24)
> +#define DLL_TXCLK_NO_INVERTER BIT(29)
> #define DLL_STRBIN_TAPNUM_DEFAULT 0x4
> #define DLL_STRBIN_TAPNUM_FROM_SW BIT(24)
> #define DLL_STRBIN_DELAY_NUM_SEL BIT(26)
> #define DLL_STRBIN_DELAY_NUM_OFFSET16
> #define DLL_STRBIN_DELAY_NUM_DEFAULT 0x10
> +#define DLL_CMDOUT_TAPNUM_90_DEGREES 0x8
> +#define DLL_CMDOUT_TAPNUM_FROM_SW BIT(24)
> +#define DLL_CMDOUT_SRC_CLK_NEG BIT(28)
> +#define DLL_CMDOUT_EN_SRC_CLK_NEG BIT(29)
> +#define DLL_CMDOUT_BOTH_CLK_EDGE BIT(30)
>
> #define DLL_LOCK_WO_TMOUT(x) \
> x) & DWCMSHC_EMMC_DLL_LOCKED) == DWCMSHC_EMMC_DLL_LOCKED) && \
> (((x) & DWCMSHC_EMMC_DLL_TIMEOUT) == 0))
> #define ROCKCHIP_MAX_CLKS 3
>
> +#define QUIRK_INVERTER_FLAG_IN_RXCLK BIT(0)
> +#define QUIRK_HAS_DLL_CMDOUT BIT(1)
> +
> struct rockchip_sdhc_plat {
> struct mmc_config cfg;
> struct mmc mmc;
> @@ -99,6 +110,7 @@ struct rockchip_sdhc {
> void *base;
> struct rockchip_emmc_phy *phy;
> struct clk emmc_clk;
> + u8 txclk_tapnum;
> };
>
> struct sdhci_data {
> @@ -144,6 +156,8 @@ struct sdhci_data {
> * Return: 0 if successful, -ve on error
> */
> int (*set_enhanced_strobe)(struct sdhci_host *host);
> +
> + u32 quirks;
As these are not really quirks (i.e., errata), it would be nicer to
add new function pointers to abstract away the difference in
behaviour.
> };
>
> static void rk3399_emmc_phy_power_on(struct rockchip_emmc_phy *phy, u32
> clock)
> @@ -294,6 +308,10 @@ static void rk3568_sdhci_set_clock(struct sdhci_host
> *host, u32 div)
>
> static int rk3568_sdhci_config_dll(struct sdhci_host *host, u32 clock, bool
> enable)
> {
> + struct rockchip_sdhc *priv = container_of(host, struct rockchip_sdhc,
> host);
> + struct sdhci_data *data = (struct sdhci_data
> *)dev_get_driver_data(priv->dev);
> + struct mmc *mmc = host->mmc;
> + u8 txclk_tapnum = DLL_TXCLK_TAPNUM_DEFAULT;
> int val, ret;
> u32 extra;
>
> @@ -318,12 +336,33 @@ static int rk3568_sdhci_config_dll(struct sdhci_host
> *host, u32 clock, bool enab
> if (ret)
> return ret;
>
> - extra = DWCMSHC_EMMC_DLL_DLYENA | DLL_RXCLK_NO_INVERTER;
> + extra = DWCMSHC_EMMC_DLL_DLYENA | DLL_RXCLK_ORI_GATE;
Adding DLL_RXCLK_ORI_GATE here is not documented in the commit message.
Was this missing before?
> + if (data->quirks & QUIRK_INVERTER_FLAG_IN_RXCLK)
> + extra |= DLL_RXCLK_NO_INVERTER;
> sdhci_writel(host, extra, DWCMSHC_EMMC_DLL_RXCLK);
This could be abstracted out as
if (data->enable_rxclk)
data->enable_rxclk();
or even as (a new function) rockchip_sdhci_enable_rxclk(host) ... and
then hiding the indirect function call in that function.
>
> + if (mmc->selected_mode == MMC_HS_200 ||
> + mmc->selected_mode == MMC_HS_400 ||
> + mmc->selected_mode == MMC_HS_400_ES)
> + txclk_tapnum = priv->txclk_tapnum;
> +
> + if ((data->quirks & QUIRK_HAS_DLL_CMDOUT) &&
> + (mmc->selected_mode == MMC_HS_400 ||
> +mmc->selected_mode == MMC_HS_400_ES)) {
> + txclk_tapnum = DLL_TXCLK_TAPNUM_90_DEGREES;
This overwrites txclk_tapnum (just set a few lines above). Is this
intentional or did you intend to OR this in?
> +
> + extra = DLL_CMDOUT_SRC_CLK_NEG |
> + DLL_CMDOUT_BOTH_CLK_EDGE |
> + DWCMSHC_EMMC_DLL_DLYENA |
> + DLL_CMDOUT_T
Re: [PATCH] rockchip: rk3328: Set VOP QoS to high priority
On Sat, 23 Jul 2022 at 13:29, Nicolas Frattaroli
wrote:
>
> The default priority for the quality of service for the video
> output results in unsightly glitches on the output whenever there
> is memory pressure on the system, which happens a lot.
>
> This sets the VOP QoS to high priority, which fixes this issue.
>
> Signed-off-by: Nicolas Frattaroli
> ---
> arch/arm/mach-rockchip/rk3328/rk3328.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/mach-rockchip/rk3328/rk3328.c
> b/arch/arm/mach-rockchip/rk3328/rk3328.c
> index de17b88682..2373586b14 100644
> --- a/arch/arm/mach-rockchip/rk3328/rk3328.c
> +++ b/arch/arm/mach-rockchip/rk3328/rk3328.c
> @@ -19,6 +19,8 @@ DECLARE_GLOBAL_DATA_PTR;
> #define GRF_BASE 0xFF10
> #define UART2_BASE 0xFF13
> #define FW_DDR_CON_REG 0xFF7C0040
> +#define QOS_VOP_OFFSET 0xFF760080
> +#define QOS_VOP_PRIORITY 0x8
>
> const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
> [BROM_BOOTSOURCE_EMMC] = "/mmc@ff52",
> @@ -54,6 +56,9 @@ int arch_cpu_init(void)
>
> /* Disable the ddr secure region setting to make it non-secure */
> rk_setreg(FW_DDR_CON_REG, 0x200);
> +#else
> + printf("Setting VOP QoS\n");
> + rk_setreg(QOS_VOP_OFFSET + QOS_VOP_PRIORITY, 0x2);
The change itself is easy enough to give a Reviewed-by on for (yes,
the address is correct, and 0x2 is a valid setting — please use a
symbolic constant for the 0x2, though), but...
Thinking about why you put this into '#else' had me question whether
this indeed belongs here...
This is part of the SoC init, as it sets up the arbitration in the
NOC: so at least whether arch_cpu_init is the right place to have it
is debatable (or if it should go into its own driver).
However, the overarching question is whether this should only be done
as part of the system configuration under the control of other drivers
(e.g., the Linux VOP driver) or under the control of the system
designer (i.e., based on device-tree or /proc entries in Linux).
Consider the case where someone is building a network/storage
appliance that uses VOP for console output: in such an application,
priority would be given to the peripherals critical to that
application instead of VOP.
So, I'd like to hear more discussion on whether this should be
unconditionally done in the bootloader before we move forward.
Thanks,
Philipp.
> #endif
> return 0;
> }
> --
> 2.37.1
>
Re: [PATCH 2/2] rockchip: mkimage: make RC4 key const
On Fri, 18 Nov 2022 at 17:13, John Keeping wrote: > > This is read-only data, so mark it as such. > > Signed-off-by: John Keeping Reviewed-by: Philipp Tomsich
Re: [PATCH 1/2] rc4: mark key as const
On Fri, 18 Nov 2022 at 17:13, John Keeping wrote: > > Key data is never written so the parameter can be const, which allows > putting fixed keys in .rodata. > > Signed-off-by: John Keeping Reviewed-by: Philipp Tomsich
Re: [RFC PATCH 4/8] rockchip: pad u-boot-rockchip.bin correctly
On Fri, 15 Jul 2022 at 17:37, Quentin Schulz wrote:
>
> From: Quentin Schulz
>
> On MMC storage media, the TPL/SPL needs to be flashed at offset 32KB.
> Instead of requesting the user to put the input the appropriate offsets,
> let's create u-boot-rockchip.bin with the padding already added.
NAK.
The storage layout provided by Rockchip leaves space for a
(protective) MBR and a primary GPT.
A bootloader update will overwrite the partition table if you create
the image as you suggest.
> Cc: Quentin Schulz
> Signed-off-by: Quentin Schulz
> ---
> arch/arm/dts/rockchip-u-boot.dtsi | 3 ++-
> doc/board/rockchip/rockchip.rst | 2 +-
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/dts/rockchip-u-boot.dtsi
> b/arch/arm/dts/rockchip-u-boot.dtsi
> index fc28ce5187..4cd243514e 100644
> --- a/arch/arm/dts/rockchip-u-boot.dtsi
> +++ b/arch/arm/dts/rockchip-u-boot.dtsi
> @@ -18,6 +18,7 @@
> pad-byte = <0xff>;
>
> mkimage {
> + offset = <(32 * 1024)>; /* 32KB */
> args = "-n", CONFIG_SYS_SOC, "-T", "rksd";
> #ifndef CONFIG_TPL
> u-boot-spl {
> @@ -38,7 +39,7 @@
> #else
> u-boot-img {
> #endif
> - offset = <((CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR -
> 64) * 512)>;
> + offset = <(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR *
> 512)>;
> };
> };
> };
> diff --git a/doc/board/rockchip/rockchip.rst b/doc/board/rockchip/rockchip.rst
> index 4ca7b00b1f..1995882244 100644
> --- a/doc/board/rockchip/rockchip.rst
> +++ b/doc/board/rockchip/rockchip.rst
> @@ -179,7 +179,7 @@ To write an image that boots from a SD card (assumed to
> be /dev/sda):
>
> .. code-block:: bash
>
> -sudo dd if=u-boot-rockchip.bin of=/dev/sda seek=64
> +sudo dd if=u-boot-rockchip.bin of=/dev/sda
> sync
>
> eMMC
> --
> 2.36.1
>
Re: [PATCH] rockchip: rk3308: fix same-as-spl boot order
On Thu, 14 Jul 2022 at 16:18, John Keeping wrote: > > Rockchip SoCs need the boot_devices array defined in order to map the > bootloader's value to a U-Boot device. Implement this for rk3308. > > Signed-off-by: John Keeping Reviewed-by: Philipp Tomsich
Re: [PATCH 2/2] rockchip: rk3399: fix incorrect ifdef check on SPL_GPIO
On Tue, 12 Jul 2022 at 17:38, Quentin Schulz wrote:
>
> From: Quentin Schulz
>
> The check to perform is on CONFIG_SPL_GPIO and not SPL_GPIO.
> Because this was never compiled in, it missed an include of cru.h that
> was not detected before. Let's include it too.
>
> Fixes: 07586ee4322a ("rockchip: rk3399: Support common spl_board_init")
> Cc: Quentin Schulz
> Signed-off-by: Quentin Schulz
> ---
> arch/arm/mach-rockchip/rk3399/rk3399.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c
> b/arch/arm/mach-rockchip/rk3399/rk3399.c
> index ad274b66ce..6d30b70565 100644
> --- a/arch/arm/mach-rockchip/rk3399/rk3399.c
> +++ b/arch/arm/mach-rockchip/rk3399/rk3399.c
> @@ -221,7 +221,9 @@ void spl_perform_fixups(struct spl_image_info *spl_image)
>"u-boot,spl-boot-device", boot_ofpath);
> }
>
> -#if defined(SPL_GPIO)
> +#if defined(CONFIG_SPL_GPIO)
#if IS_ENABLED(…)
> +
> +#include
> static void rk3399_force_power_on_reset(void)
> {
> ofnode node;
> @@ -253,7 +255,7 @@ void spl_board_init(void)
> {
> led_setup();
>
> -#if defined(SPL_GPIO)
> +#if defined(CONFIG_SPL_GPIO)
if (IS_ENABLED(…)) { }
> struct rockchip_cru *cru = rockchip_get_cru();
>
> /*
> --
> 2.36.1
>
Re: [PATCH 1/2] rockchip: rk3399: fix incorrect ifdef check on SPL_DM_REGULATOR
On Tue, 12 Jul 2022 at 17:38, Quentin Schulz wrote:
>
> From: Quentin Schulz
>
> The check to perform is on CONFIG_SPL_DM_REGULATOR and not
> SPL_DM_REGULATOR.
>
> Fixes: 07586ee4322a ("rockchip: rk3399: Support common spl_board_init")
> Cc: Quentin Schulz
> Signed-off-by: Quentin Schulz
> ---
> arch/arm/mach-rockchip/rk3399/rk3399.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c
> b/arch/arm/mach-rockchip/rk3399/rk3399.c
> index de11a3fa30..ad274b66ce 100644
> --- a/arch/arm/mach-rockchip/rk3399/rk3399.c
> +++ b/arch/arm/mach-rockchip/rk3399/rk3399.c
> @@ -275,7 +275,7 @@ void spl_board_init(void)
> rk3399_force_power_on_reset();
> #endif
>
> -#if defined(SPL_DM_REGULATOR)
> +#if defined(CONFIG_SPL_DM_REGULATOR)
This should use IS_ENABLED(...) or CONFIG_IS_ENABLED(...) and be a
regular if-block instead of an #ifdef.
> /*
> * Turning the eMMC and SPI back on (if disabled via the Qseven
> * BIOS_ENABLE) signal is done through a always-on regulator).
> --
> 2.36.1
>
Re: [PATCH V4 6/6] arm: set cntfrq_el0 if CONFIG_COUNTER_FREQUENCY is valid
On Wed, 13 Apr 2022 at 11:07, Peng Fan (OSS) wrote: > > From: Peng Fan > > Since COUNTER_FREQUENCY is obselete, so set cntfrq_el0 if > CONFIG_COUNTER_FREQUENCY is valid > > Signed-off-by: Peng Fan Reviewed-by: Philipp Tomsich
Re: [PATCH v1 06/11] rockchip: handle bootrom recovery mode in spl
On Tue, 22 Feb 2022 at 02:31, Peter Geis wrote:
>
> Fixup the bootrom recovery mode code to function in spl, so we can
> handle recovery mode in case u-boot loading is broken.
>
> Signed-off-by: Peter Geis
> ---
> arch/arm/mach-rockchip/Makefile| 6 +++---
> arch/arm/mach-rockchip/boot_mode.c | 4 +++-
> arch/arm/mach-rockchip/rk3568/rk3568.c | 23 +++
> 3 files changed, 29 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> index 00aef0ecee6a..53aff25ce8f6 100644
> --- a/arch/arm/mach-rockchip/Makefile
> +++ b/arch/arm/mach-rockchip/Makefile
> @@ -15,13 +15,13 @@ obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
>
> obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
>
> -ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TPL_BUILD),)
> -
> # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> # inside of boot_mode.c when CONFIG_BOOT_MODE_REG is 0. This way,
> # we can have the preprocessor correctly recognise both 0x0 and 0
> # meaning "turn it off".
> -obj-y += boot_mode.o
> +obj-$(CONFIG_ARCH_ROCKCHIP) += boot_mode.o
> +
> +ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TPL_BUILD),)
> obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> obj-$(CONFIG_MISC_INIT_R) += misc.o
> endif
> diff --git a/arch/arm/mach-rockchip/boot_mode.c
> b/arch/arm/mach-rockchip/boot_mode.c
> index 1a1a887fc2cd..43cb369465a2 100644
> --- a/arch/arm/mach-rockchip/boot_mode.c
> +++ b/arch/arm/mach-rockchip/boot_mode.c
> @@ -51,7 +51,7 @@ __weak int rockchip_dnl_key_pressed(void)
> ret = -ENODEV;
> uclass_foreach_dev(dev, uc) {
> if (!strncmp(dev->name, "saradc", 6)) {
> - ret = adc_channel_single_shot(dev->name, 1, &val);
> + ret = adc_channel_single_shot(dev->name, 0, &val);
This looks like an unrelated change (i.e., doesn't correlate with the
commit message). Should this go into a separate patch in the same
series?
> break;
> }
> }
> @@ -89,6 +89,7 @@ int setup_boot_mode(void)
> boot_mode = readl(reg);
> debug("%s: boot mode 0x%08x\n", __func__, boot_mode);
>
> +#if !defined(CONFIG_SPL_BUILD) && !defined(CONFIG_TPL_BUILD)
> /* Clear boot mode */
> writel(BOOT_NORMAL, reg);
>
> @@ -102,6 +103,7 @@ int setup_boot_mode(void)
> env_set("preboot", "setenv preboot; ums mmc 0");
> break;
> }
> +#endif
>
> return 0;
> }
> diff --git a/arch/arm/mach-rockchip/rk3568/rk3568.c
> b/arch/arm/mach-rockchip/rk3568/rk3568.c
> index 22eeb77d41fa..4e23feb9417f 100644
> --- a/arch/arm/mach-rockchip/rk3568/rk3568.c
> +++ b/arch/arm/mach-rockchip/rk3568/rk3568.c
> @@ -104,3 +104,26 @@ int arch_cpu_init(void)
> #endif
> return 0;
> }
> +
> +#ifdef CONFIG_SPL_BUILD
> +
> +void __weak led_setup(void)
> +{
> +}
> +
> +void spl_board_init(void)
> +{
> + led_setup();
> +
> +#if defined(SPL_DM_REGULATOR)
> + /*
> +* Turning the eMMC and SPI back on (if disabled via the Qseven
> +* BIOS_ENABLE) signal is done through a always-on regulator).
> +*/
> + if (regulators_enable_boot_on(false))
> + debug("%s: Cannot enable boot on regulator\n", __func__);
> +#endif
> +
> + setup_boot_mode();
> +}
> +#endif
> --
> 2.25.1
>
Re: No u-boot-rockchip pull request sent or merged for v2022.04
On Fri, 11 Mar 2022 at 19:15, Alper Nebi Yasak wrote: > > On 11/03/2022 18:43, Tom Rini wrote: > > On Fri, Mar 11, 2022 at 12:05:42AM +0300, Alper Nebi Yasak wrote: > >> I have a few Rockchip-related series [1] that I was expecting to land > >> for v2022.04 (including improvements for chromebook_bob, support for the > >> chromebook_kevin board, rk3399 eMMC fixes) but there hasn't been a > >> u-boot-rockchip pull request since the one for v2022.01 [2]. There's > >> also more pending patches from other people [3]. > >> > >> Kever seems unresponsive, last message to the mailing list was that pull > >> request in December 2021. I did send on-list mails as To: Kever whenever > >> Simon happened to poke me about chromebook_kevin not being merged, but > >> to no avail. > >> > >> What should be done here, any advice? > > > > I've been hoping for something to show up soon myself. To start with, > > are there any rockchip related regression fixes you're aware of? > > I haven't been paying enough attention to others' patches. For those of > mine, I think I can only call my RK3399 eMMC fix [1] a regression fix. > IIRC it has been broken since v2021.10 on some boards (but not all). For the regressions, I could try help moving them forward (i.e., build-test and reviewing) next week, but I don't have a test setup with any Rockchip boards available at the moment. Philipp. > > [1] rockchip: sdhci: Fix RK3399 eMMC PHY power cycling > https://patchwork.ozlabs.org/project/uboot/patch/20220128224240.4226-3-alpernebiya...@gmail.com/
Re: [PATCH v2] rockchip: puma/lion: update MAINTAINERS file
On Mon, 3 Jan 2022 at 13:04, wrote: > > From: Quentin Schulz > > Philipp does not work at Theobroma Systems anymore so let's swap > Philipp's address with mine. > > Cc: Philipp Tomsich > Cc: Quentin Schulz > Signed-off-by: Quentin Schulz Reviewed-by: Philipp Tomsich
Re: [PATCH 4/4] rk3399: Don't enable the debug UART if there is no driver
On Wed, 3 Nov 2021 at 14:16, Simon Glass wrote: > > Some boards do not enable SPL_SERIAL so cannot use the debug UART. Add > this condition to the code and drop use of the preprocessor while we are > here. > > Signed-off-by: Simon Glass Reviewed-by: Philipp Tomsich
Re: [PATCH v2 3/3] rockchip: rk3568: add arch_cpu_init()
On Mon, 25 Oct 2021 at 08:34, Nico Cheng wrote:
>
> We configured the drive strength and security of EMMC in
> arch_cpu_init().
>
> Signed-off-by: Nico Cheng
> ---
>
> Changes in v2:
> We use the rk_clrreg function instead of the writel to set eMMC sdmmc0 to
> secure.
> Modify comments to make them more explicit.
>
> arch/arm/mach-rockchip/rk3568/rk3568.c | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/arch/arm/mach-rockchip/rk3568/rk3568.c
> b/arch/arm/mach-rockchip/rk3568/rk3568.c
> index 973b4f9dcb..1a62052731 100644
> --- a/arch/arm/mach-rockchip/rk3568/rk3568.c
> +++ b/arch/arm/mach-rockchip/rk3568/rk3568.c
> @@ -13,6 +13,14 @@
>
> #define PMUGRF_BASE0xfdc2
> #define GRF_BASE 0xfdc6
> +#define GRF_GPIO1B_DS_20x218
> +#define GRF_GPIO1B_DS_30x21c
> +#define GRF_GPIO1C_DS_00x220
> +#define GRF_GPIO1C_DS_10x224
> +#define GRF_GPIO1C_DS_20x228
> +#define GRF_GPIO1C_DS_30x22c
> +#define SGRF_BASE 0xFDD18000
> +#define SGRF_SOC_CON4 0x10
>
> /* PMU_GRF_GPIO0D_IOMUX_L */
> enum {
> @@ -81,5 +89,16 @@ void board_debug_uart_init(void)
>
> int arch_cpu_init(void)
> {
> +#ifdef CONFIG_SPL_BUILD
> + /* Set the emmc sdmmc0 to secure */
> + rk_clrreg(SGRF_BASE + SGRF_SOC_CON4, (0x3 << 11 | 0x1 << 4));
Please introduce symbolic constants (or at least a C99 'const'
expressions with a suitable names) to clarify what bits[12:11]
and bit[4] control?
> + /* set the emmc driver strength to level 2 */
> + writel(0x3f3f0707, GRF_BASE + GRF_GPIO1B_DS_2);
> + writel(0x3f3f0707, GRF_BASE + GRF_GPIO1B_DS_3);
> + writel(0x3f3f0707, GRF_BASE + GRF_GPIO1C_DS_0);
> + writel(0x3f3f0707, GRF_BASE + GRF_GPIO1C_DS_1);
> + writel(0x3f3f0707, GRF_BASE + GRF_GPIO1C_DS_2);
> + writel(0x3f3f0707, GRF_BASE + GRF_GPIO1C_DS_3);
> +#endif
> return 0;
> }
> --
> 2.17.1
>
>
>
Re: [PATCH v2 2/3] arm: dts: rockchip: rk3568: Enable sdhci and sdmmc0 node
On Mon, 25 Oct 2021 at 08:34, Nico Cheng wrote: > > Enable sdhci and sdmmc0 node in rk3568-u-boot.dtsi > > Signed-off-by: Nico Cheng Reviewed-by: Philipp Tomsich
Re: [PATCH v2 1/3] rockchip: Kconfig: Enable SPL support for rk3568
On Mon, 25 Oct 2021 at 08:34, Nico Cheng wrote: > > Enable SPL support in Kconfig and add some related option in > rk3568_common.h > > Signed-off-by: Nico Cheng > Signed-off-by: Jason Zhu Acked-by: Philipp Tomsich
Re: [PATCH v1 3/3] rockchip: rk3568: add arch_cpu_init()
On Fri, 8 Oct 2021 at 04:01, Nico Cheng wrote:
>
> We configured the drive strength and security of EMMC in
> arch_cpu_init().
Could you point me to a public version of the TRM (and
ideally also of the datasheet), so I can review this series?
Thanks,
Philipp.
>
> Signed-off-by: Nico Cheng
> ---
>
> arch/arm/mach-rockchip/rk3568/rk3568.c | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/arch/arm/mach-rockchip/rk3568/rk3568.c
> b/arch/arm/mach-rockchip/rk3568/rk3568.c
> index 973b4f9dcb..3f9a435c3c 100644
> --- a/arch/arm/mach-rockchip/rk3568/rk3568.c
> +++ b/arch/arm/mach-rockchip/rk3568/rk3568.c
> @@ -13,6 +13,14 @@
>
> #define PMUGRF_BASE0xfdc2
> #define GRF_BASE 0xfdc6
> +#define GRF_GPIO1B_DS_20x218
> +#define GRF_GPIO1B_DS_30x21c
> +#define GRF_GPIO1C_DS_00x220
> +#define GRF_GPIO1C_DS_10x224
> +#define GRF_GPIO1C_DS_20x228
> +#define GRF_GPIO1C_DS_30x22c
> +#define SGRF_BASE 0xFDD18000
> +#define SGRF_SOC_CON4 0x10
>
> /* PMU_GRF_GPIO0D_IOMUX_L */
> enum {
> @@ -81,5 +89,16 @@ void board_debug_uart_init(void)
>
> int arch_cpu_init(void)
> {
> +#ifdef CONFIG_SPL_BUILD
> + /* Set the emmc sdmmc0 to secure */
> + writel(((0x3 << 11 | 0x1 << 4) << 16), SGRF_BASE + SGRF_SOC_CON4);
> + /* set the emmc ds to level 2 */
> + writel(0x3f3f0707, GRF_BASE + GRF_GPIO1B_DS_2);
> + writel(0x3f3f0707, GRF_BASE + GRF_GPIO1B_DS_3);
> + writel(0x3f3f0707, GRF_BASE + GRF_GPIO1C_DS_0);
> + writel(0x3f3f0707, GRF_BASE + GRF_GPIO1C_DS_1);
> + writel(0x3f3f0707, GRF_BASE + GRF_GPIO1C_DS_2);
> + writel(0x3f3f0707, GRF_BASE + GRF_GPIO1C_DS_3);
> +#endif
> return 0;
> }
> --
> 2.17.1
>
Re: [PATCH v7 6/6] rockchip: px30: Support configure SFC
On Thu, 5 Aug 2021 at 10:28, Jon Lin wrote: > > Make px30 SFC clock configurable > > Signed-off-by: Jon Lin Reviewed-by: Philipp Tomsich
Re: [PATCH v7 4/6] mtd: spi-nor-ids: Add XTX XT25F128B
On Thu, 5 Aug 2021 at 10:27, Jon Lin wrote: > > From: Chris Morgan > > Adds support for XT25F128B used on Odroid Go Advance. Unfortunately > this chip uses a continuation code which I cannot seem to parse, so > there are possibly going to be collisions with chips that use the same > manufacturer/ID. > > Signed-off-by: Chris Morgan > Signed-off-by: Jon Lin Reviewed-by: Philipp Tomsich
Re: [PATCH v7 1/6] spi: rockchip_sfc: add support for Rockchip SFC
On Thu, 5 Aug 2021 at 10:26, Jon Lin wrote: > > From: Chris Morgan > > This patch adds support for the Rockchip serial flash controller > found on the PX30 SoC. It should work for versions 3-5 of the SFC > IP, however I am only able to test it on v3. > > This is adapted from the WIP SPI-MEM driver for the SFC on mainline > Linux. Note that the main difference between this and earlier versions > of the driver is that this one does not support DMA. In testing > the performance difference (performing a dual mode read on a 128Mb > chip) is negligible. DMA, if used, must also be disabled in SPL > mode when using A-TF anyway. > > Signed-off-by: Chris Morgan > Signed-off-by: Jon Lin Reviewed-by: Philipp Tomsich
Re: [PATCH v3 2/3] mmc: rockchip_sdhci: Add support for RK3568
On Tue, 29 Jun 2021 at 10:24, Yifeng Zhao wrote: > > This patch adds support for the RK3568 platform to this driver. > > Signed-off-by: Yifeng Zhao I thought I had raised an objection to this patch previously, but did not see a discussion... So here we go again. In 2017, we decided to split the HDMI drivers such that there is a common core driver and a "mini-driver" wrapping it, so we don't pull in the extra code for every chip. See the original comment from Simon at https://patchwork.ozlabs.org/project/uboot/patch/1493394792-20743-4-git-send-email-philipp.toms...@theobroma-systems.com/#1648072 Given that we established that pattern already—and that there are practical benefits (e.g., in code-size), we should follow the same pattern for the SDHCI driver. Thank you, Philipp.
Re: [PATCH v3 3/3] rockchip: config: evb-rk3399: add hs400 and SDMA support
On Tue, 29 Jun 2021 at 10:25, Yifeng Zhao wrote: > > This enable hs400 and SDMA support for emmc on evb-rk3399. > > Signed-off-by: Yifeng Zhao Reviewed-by: Philipp Tomsich
Re: [PATCH] rk3399: Add basic support for helios64
On Thu, 22 Jul 2021 at 01:14, Dennis Gilmore wrote:
>
> From: Dennis Gilmore
>
> This is a stripped down version of the vendor U-Boot patch by Aditya
> Prayoga found in the armbian repository. This patch is enough to have
> the 1G ethernet port, the micro SD card, eMMC, PCIe and UART. It sets
> uart2 as the default outiput device. the defconfig file has been cleaned
> up a lot from the vendor version.
>
> The device tree file is from the for-next branch of linux-rockchip and
> targeted for 5.15 needed for SPI, stdout-path, and tsadc enablement
>
> Signed-off-by: Dennis Gilmore
> ---
> arch/arm/dts/Makefile | 1 +
> .../arm/dts/rk3399-kobol-helios64-u-boot.dtsi | 23 +
> arch/arm/dts/rk3399-kobol-helios64.dts| 534 ++
> arch/arm/mach-rockchip/rk3399/Kconfig | 17 +
> board/kobol/helios64-rk3399/Kconfig | 17 +
> board/kobol/helios64-rk3399/MAINTAINERS | 7 +
> board/kobol/helios64-rk3399/Makefile | 5 +
> board/kobol/helios64-rk3399/helios64.c| 262 +
> board/kobol/helios64-rk3399/sys_otp.c | 253 +
> board/kobol/helios64-rk3399/sys_otp.h | 15 +
> board/pine64/rockpro64_rk3399/Kconfig | 2 +
> configs/helios64-rk3399_defconfig | 114
> include/configs/helios64-rk3399.h | 56 ++
> 13 files changed, 1306 insertions(+)
> create mode 100644 arch/arm/dts/rk3399-kobol-helios64-u-boot.dtsi
> create mode 100644 arch/arm/dts/rk3399-kobol-helios64.dts
> create mode 100644 board/kobol/helios64-rk3399/Kconfig
> create mode 100644 board/kobol/helios64-rk3399/MAINTAINERS
> create mode 100644 board/kobol/helios64-rk3399/Makefile
> create mode 100644 board/kobol/helios64-rk3399/helios64.c
> create mode 100644 board/kobol/helios64-rk3399/sys_otp.c
> create mode 100644 board/kobol/helios64-rk3399/sys_otp.h
> create mode 100644 configs/helios64-rk3399_defconfig
> create mode 100644 include/configs/helios64-rk3399.h
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 9fb38682e6..2788d7dd7b 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -124,6 +124,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3399) += \
> rk3399-ficus.dtb \
> rk3399-firefly.dtb \
> rk3399-gru-bob.dtb \
> + rk3399-kobol-helios64.dtb \
> rk3399-khadas-edge.dtb \
> rk3399-khadas-edge-captain.dtb \
> rk3399-khadas-edge-v.dtb \
> diff --git a/arch/arm/dts/rk3399-kobol-helios64-u-boot.dtsi
> b/arch/arm/dts/rk3399-kobol-helios64-u-boot.dtsi
> new file mode 100644
> index 00..f534c14b13
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-kobol-helios64-u-boot.dtsi
> @@ -0,0 +1,23 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (c) 2020 Aditya Prayoga (adi...@kobol.io)
> + */
> +
> +#include "rk3399-u-boot.dtsi"
> +#include "rk3399-sdram-lpddr4-100.dtsi"
> +
> +/ {
> + chosen {
> + u-boot,spl-boot-order = "same-as-spl", &spiflash, &sdmmc,
> &sdhci;
> + };
> +
> + config {
> + u-boot,spl-payload-offset = <0x6>; /* @ 384KB */
> + };
> +};
> +
> +&spi1 {
> + spiflash: flash@0 {
> + u-boot,dm-pre-reloc;
> + };
> +};
> diff --git a/arch/arm/dts/rk3399-kobol-helios64.dts
> b/arch/arm/dts/rk3399-kobol-helios64.dts
> new file mode 100644
> index 00..63c7681843
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-kobol-helios64.dts
> @@ -0,0 +1,534 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2020 Aditya Prayoga
> + */
> +
> +/*
> + * The Kobol Helios64 is a board designed to operate as a NAS and optionally
> + * ships with an enclosing that can host five 2.5" hard disks.
> + *
> + * See https://wiki.kobol.io/helios64/intro/ for further details.
> + */
> +
> +/dts-v1/;
> +#include "rk3399.dtsi"
> +#include "rk3399-opp.dtsi"
> +
> +/ {
> + model = "Kobol Helios64";
> + compatible = "kobol,helios64", "rockchip,rk3399";
> +
> + aliases {
> + mmc0 = &sdmmc;
> + mmc1 = &sdhci;
> + spi1 = &spi1;
> + spi2 = &spi2;
> + spi5 = &spi5;
> + };
> +
> + avdd_0v9_s0: avdd-0v9-s0 {
> + compatible = "regulator-fixed";
> + regulator-name = "avdd_0v9_s0";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <90>;
> + regulator-max-microvolt = <90>;
> + vin-supply = <&vcc1v8_sys_s3>;
> + };
> +
> + avdd_1v8_s0: avdd-1v8-s0 {
> + compatible = "regulator-fixed";
> + regulator-name = "avdd_1v8_s0";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <180>;
> + vin-supply = <&vcc3v3_sys_s3>;
> + }
Re: [PATCH v2 0/3]
I had attempted to merge HDMI using this approach in 2017, but after some discussions with Simon, we used a 'mini-drivers' approach. I would like to see a similar approach taken here. See https://patchwork.ozlabs.org/project/uboot/patch/1493394792-20743-4-git-send-email-philipp.toms...@theobroma-systems.com/#1650260 for the original discussion between Simon and me. Thanks, Philipp. On Mon, 28 Jun 2021 at 11:20, Yifeng Zhao wrote: > RK3399 and RK3568 are use different sdhci controllers. > The drivers need to be updated to support these two platforms > and it's easy to support new platforms. > > > Changes in v2: > - Add mmc_of_parse to parse dts config. > - Used read_poll_timeout api to check dll lock status > - Add execute tuning api for hs200 tuning > - Used sdhci_set_clock api to set clock. > - Used read_poll_timeout api to check dll status. > > Yifeng Zhao (3): > mmc: rockchip_sdhci: add phy and clock config for rk3399 > mmc: rockchip_sdhci: Add support for RK3568 > rockchip: config: evb-rk3399: add hs200 and hs400 support > > configs/evb-rk3399_defconfig | 1 + > drivers/mmc/rockchip_sdhci.c | 427 --- > 2 files changed, 392 insertions(+), 36 deletions(-) > > -- > 2.17.1 > > > >
Re: [PATCH v2 3/3] rockchip: config: evb-rk3399: add hs200 and hs400 support
On Mon, 28 Jun 2021 at 11:20, Yifeng Zhao wrote: > > This enable hs200 and hs400 support for emmc on evb-rk3399. > > Signed-off-by: Yifeng Zhao Reviewed-by: Philipp Tomsich
Re: [PATCH 0/4] Use just one DTS file for all Espressobin variants
> On 02.12.2020, at 13:37, Andre Heider wrote: > > On 02/12/2020 11:35, Stefan Roese wrote: >> On 02.12.20 10:12, Pali Rohár wrote: >>> On Wednesday 02 December 2020 09:09:15 Stefan Roese wrote: On 02.12.20 01:33, Pali Rohár wrote: > On Wednesday 25 November 2020 19:20:06 Pali Rohár wrote: >> This patch series change Espressobin code to use in U-Boot just one DTS >> file for all Espressobin variants. Therefore DT compatible string >> globalscale,espressobin-emmc is not used anymore as it is not needed. >> >> It means that setup and compilation of U-Boot for Espressobin is less >> complicated and more simple. As there is no need to check for HW details >> and just one U-Boot binary would work for all Espressobin variants. >> >> First two patches just revert previous eMMC support and next two patches >> add support for eMMC in way that just one DTS file is used and fdtfile >> env variable is correctly set for any Espressobin variant. >> >> We have tested that fdtfile env variable is correctly set on Espressobin >> variants with eMMC, without eMMC, with DDR3 RAM and also with DDR4 RAM. >> Also that eMMC is working on Espressobin variant with eMMC. > > Stefan, could you please review this patch series? I like the approach in general to simplify things. One comment though: AFAICT, Linux uses multiple dts/dtsi files for espressobin. So your approach to move to one single file contradicts the (planned after comphy conversion) move to the Linux dts/dtsi files. >>> >>> After comphy conversion we can use e.g. Linux dtsi file and create one >>> main U-Boot dts file which would contain all nodes enabled and in U-Boot >>> code disable nodes which are not present/relevant. This patch series >>> allows to detect all variants v5, v7, with emmc, without emmc; so we can >>> reconstruct dts file at U-Boot runtime. In Linux we also simplified dts >>> files as much as possible, so all options are in common dtsi file and >>> only variant relevant changes (enable/disable nodes) are in dts files. >> I see. So let's please wait for Andre, if he has some comments on this. >> Thanks, >> Stefan > Andre, are you fine with these changes? I would like to get your > acknowledgment or review comment what needs to be changed or improved as > this patch series basically rework your code (which is first reverted > and them implemented in different way). Yes. Andre please also comment on this. > > This is a nice simplification. Pali had this idea before, and I hesitated > because of two questions I don't have the answer to: > - Can we just try to detect an emmc chip on an unpopulated board without any > drawbacks? All eMMC host controllers I know, will eventually return a timeout on the first command(s) to the eMMC. So the main drawback should be wasted runtime that will slow down the boot sequence. > - What about power consumption? Does this unnecessarily waste power on > non-emmc boards because something is still powered up? > > But if noone sees an issue with that I don't have any objections. > > I think this set could be simplified though. Instead of the first two > reverts, just remove the non-emmc dts and rename the emmc dts. That's less > churn and keeps the dtsi for future syncing with linux. > > Thanks, > Andre > Thanks, Stefan >> Pali Rohár (4): >> Revert "arm64: dts: armada-3720-espressobin: split common parts to >> .dtsi" >> Revert "arm64: dts: a3720: add support for espressobin with populated >> emmc" >> arm: mvebu: Espressobin: Add support for emmc into dts file >> arm: mvebu: Espressobin: Detect presence of emmc at runtime >> >>arch/arm/dts/Makefile | 1 - >>arch/arm/dts/armada-3720-espressobin-emmc.dts | 44 - >>arch/arm/dts/armada-3720-espressobin.dts | 186 +- >>arch/arm/dts/armada-3720-espressobin.dtsi | 167 >>board/Marvell/mvebu_armada-37xx/board.c | 6 +- >>doc/README.marvell| 7 +- >>6 files changed, 186 insertions(+), 225 deletions(-) >>delete mode 100644 arch/arm/dts/armada-3720-espressobin-emmc.dts >>delete mode 100644 arch/arm/dts/armada-3720-espressobin.dtsi >> >> -- >> 2.20.1 >> Viele Grüße, Stefan -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de >> Viele Grüße, >> Stefan
Re: [PATCH 3/3] patman: fix project-defaults not propagating into parsers
Simon,
On Wed, 25 Nov 2020 at 16:30, Simon Glass wrote:
> Here is a pointer to the docs I saw:
>
>
https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser.set_defaults
>
> "Parser-level defaults can be particularly useful when working with
> multiple parsers. See the add_subparsers() method for an example of
> this type."
I had looked at the same documentation and needed to carefully read the
example
to infer the original author's intended messaging...
The only mention of this in the subparser-docs was:
> One particularly effective way of handling sub-commands is to combine the
> use of the add_subparsers() method with calls to set_defaults() so that
> each subparser knows which Python function it should execute.
This example just demonstrated that two different subparsers could create a
different
default for the same argument name. I couldn't find any example of a
set_defaults()
on a higher-level parser propagating and the argparse-source doesn't seem
to try to
propagate defaults either.
I am starting to think that the correct fix for this would be more along
the lines of:
> diff --git a/tools/patman/settings.py b/tools/patman/settings.py
> index bb3f868..525c69e 100644
> --- a/tools/patman/settings.py
> +++ b/tools/patman/settings.py
> @@ -266,7 +266,11 @@ def _UpdateDefaults(main_parser, config):
> print("WARNING: Unknown setting %s" % name)
>
> # Set all the defaults (this propagates through all subparsers)
> -main_parser.set_defaults(**defaults)
> +for parser in parsers:
> +for name, val in defaults.items():
> +if parser.get_default(name) and val:
> +parser.set_defaults(name=val)
>
> def _ReadAliasFile(fname):
> """Read in the U-Boot git alias file if it exists.
>
than of what I sent out earlier.
An interesting aside: it looks as if the double-parsing of the args leads
to 'defaults'
being installed for all arguments that are passed in the first cycle (e.g.
count,
project and patchwork_url suddenly have the values loaded from the config
files
and parsed from the args populated with 'default' values).
Philipp.
Re: [PATCH 3/3] patman: fix project-defaults not propagating into parsers
Simon, On Wed, 25 Nov 2020 at 00:41, Simon Glass wrote: > According to the Python documentation and my testing, it should > propagate. Do you know what is going wrong here? If there is a > problem, we should update the comment. I don't see any code for propagating this in the argparse module: https://github.com/python/cpython/blob/85c84920f511d0d73a16daeaf715a022cd64/Lib/argparse.py#L1763 https://github.com/python/cpython/blob/85c84920f511d0d73a16daeaf715a022cd64/Lib/argparse.py#L1363 Philipp.
Re: [PATCH 3/3] patman: fix project-defaults not propagating into parsers
Simon,
On Wed, 25 Nov 2020 at 00:41, Simon Glass wrote:
>
> > Project defaults (e.g. for linux and gcc) do not propagate into the
> > subparsers. As both the processing of tags (e.g. in the defaults
> > for the linux project) and supressing the signoff (in the defaults
> > for the gcc project) are settings from subparsers, these would still
> > require an explicit commandline option mirroring the (ignored) default.
> >
> > This change ensures that defaults are updated in all parsers.
> >
> > Signed-off-by: Philipp Tomsich
> > ---
> >
> > tools/patman/settings.py | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/tools/patman/settings.py b/tools/patman/settings.py
> > index bb3f868..dc57b2f 100644
> > --- a/tools/patman/settings.py
> > +++ b/tools/patman/settings.py
> > @@ -266,7 +266,8 @@ def _UpdateDefaults(main_parser, config):
> > print("WARNING: Unknown setting %s" % name)
> >
> > # Set all the defaults (this propagates through all subparsers)
> > -main_parser.set_defaults(**defaults)
> > +for parser in parsers:
> > +parser.set_defaults(**defaults)
>
> According to the Python documentation and my testing, it should
> propagate. Do you know what is going wrong here? If there is a
> problem, we should update the comment.
I haven't dug down to find the root-cause, but I see the following behavior
both on Debian 10.6 and CentOS 7 when adding a print(args) in main.py
just before the __name__ == "__main__" check...
With this commit:
$ tools/patman/patman -p linux -c1 send -n
Namespace(add_maintainers=True, branch=None, cc_cmd=None,
check_patch=True, cmd='send', count=1, debug=False, dest_branch=None,
dry_run=True, end=0, force=False, full_help=False,
ignore_bad_tags=False, ignore_binary=False, ignore_errors=False,
in_reply_to=None, limit=None, patchfiles=['linux'],
patchwork_url='https://patchwork.ozlabs.org', process_tags=False,
project='linux', show_comments=False, smtp_server=None, start=0,
testname='linux', thread=False, verbose=False)
=> process_tags=False
Without this commit:
Namespace(add_maintainers=True, branch=None, cc_cmd=None,
check_patch=True, cmd='send', count=1, debug=False, dest_branch=None,
dry_run=True, end=0, force=False, full_help=False,
ignore_bad_tags=False, ignore_binary=False, ignore_errors=False,
in_reply_to=None, limit=None, patchfiles=[],
patchwork_url='https://patchwork.ozlabs.org', process_tags=True,
project='linux', show_comments=False, smtp_server=None, start=0,
testname='linux', thread=False, verbose=False)
=> process_tags=True
So in my testing, the problem reproduces reliably across distributions.
Regards,
Philipp
[PATCH 2/3] patman: Add project-default for 'gcc'
Add defaults for FSF/GNU projects, such as gcc, that provide sensible
settings for those projects.
Signed-off-by: Philipp Tomsich
---
tools/patman/settings.py | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/tools/patman/settings.py b/tools/patman/settings.py
index 8c10eab..bb3f868 100644
--- a/tools/patman/settings.py
+++ b/tools/patman/settings.py
@@ -23,7 +23,12 @@ _default_settings = {
"u-boot": {},
"linux": {
"process_tags": "False",
-}
+},
+"gcc": {
+"process_tags": "False",
+"add_signoff": "False",
+"check_patch": "False",
+},
}
class _ProjectConfigParser(ConfigParser.SafeConfigParser):
--
1.8.3.1
[PATCH 1/3] patman: Add --no-signoff to suppress adding signoffs
To enable use of patman with FSF/GNU projects, such as GCC or
Binutils, no Signed-off-by may be added. This adds a command
line flag '--no-signoff' to suppress adding signoffs in patman
when processing commits.
Signed-off-by: Philipp Tomsich
---
tools/patman/control.py | 6 +++---
tools/patman/gitutil.py | 6 --
tools/patman/main.py| 2 ++
3 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/tools/patman/control.py b/tools/patman/control.py
index 2330682..ee9717c 100644
--- a/tools/patman/control.py
+++ b/tools/patman/control.py
@@ -20,7 +20,7 @@ def setup():
"""Do required setup before doing anything"""
gitutil.Setup()
-def prepare_patches(col, branch, count, start, end, ignore_binary):
+def prepare_patches(col, branch, count, start, end, ignore_binary, signoff):
"""Figure out what patches to generate, then generate them
The patch files are written to the current directory, e.g. 0001_xxx.patch
@@ -56,7 +56,7 @@ def prepare_patches(col, branch, count, start, end,
ignore_binary):
to_do = count - end
series = patchstream.get_metadata(branch, start, to_do)
cover_fname, patch_files = gitutil.CreatePatches(
-branch, start, to_do, ignore_binary, series)
+branch, start, to_do, ignore_binary, series, signoff)
# Fix up the patch files to our liking, and insert the cover letter
patchstream.fix_patches(series, patch_files)
@@ -163,7 +163,7 @@ def send(args):
col = terminal.Color()
series, cover_fname, patch_files = prepare_patches(
col, args.branch, args.count, args.start, args.end,
-args.ignore_binary)
+args.ignore_binary, args.add_signoff)
ok = check_patches(series, patch_files, args.check_patch,
args.verbose)
diff --git a/tools/patman/gitutil.py b/tools/patman/gitutil.py
index 31fb3b2..5736d37 100644
--- a/tools/patman/gitutil.py
+++ b/tools/patman/gitutil.py
@@ -305,7 +305,7 @@ def PruneWorktrees(git_dir):
if result.return_code != 0:
raise OSError('git worktree prune: %s' % result.stderr)
-def CreatePatches(branch, start, count, ignore_binary, series):
+def CreatePatches(branch, start, count, ignore_binary, series, signoff = True):
"""Create a series of patches from the top of the current branch.
The patch files are written to the current directory using
@@ -323,7 +323,9 @@ def CreatePatches(branch, start, count, ignore_binary,
series):
"""
if series.get('version'):
version = '%s ' % series['version']
-cmd = ['git', 'format-patch', '-M', '--signoff']
+cmd = ['git', 'format-patch', '-M' ]
+if signoff:
+cmd.append('--signoff')
if ignore_binary:
cmd.append('--no-binary')
if series.get('cover'):
diff --git a/tools/patman/main.py b/tools/patman/main.py
index 342fd44..c4e4d80 100755
--- a/tools/patman/main.py
+++ b/tools/patman/main.py
@@ -81,6 +81,8 @@ send.add_argument('--no-check', action='store_false',
dest='check_patch',
help="Don't check for patch compliance")
send.add_argument('--no-tags', action='store_false', dest='process_tags',
default=True, help="Don't process subject tags as aliases")
+send.add_argument('--no-signoff', action='store_false', dest='add_signoff',
+ default=True, help="Don't add Signed-off-by to patches")
send.add_argument('--smtp-server', type=str,
help="Specify the SMTP server to 'git send-email'")
--
1.8.3.1
[PATCH 3/3] patman: fix project-defaults not propagating into parsers
Project defaults (e.g. for linux and gcc) do not propagate into the
subparsers. As both the processing of tags (e.g. in the defaults
for the linux project) and supressing the signoff (in the defaults
for the gcc project) are settings from subparsers, these would still
require an explicit commandline option mirroring the (ignored) default.
This change ensures that defaults are updated in all parsers.
Signed-off-by: Philipp Tomsich
---
tools/patman/settings.py | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/patman/settings.py b/tools/patman/settings.py
index bb3f868..dc57b2f 100644
--- a/tools/patman/settings.py
+++ b/tools/patman/settings.py
@@ -266,7 +266,8 @@ def _UpdateDefaults(main_parser, config):
print("WARNING: Unknown setting %s" % name)
# Set all the defaults (this propagates through all subparsers)
-main_parser.set_defaults(**defaults)
+for parser in parsers:
+parser.set_defaults(**defaults)
def _ReadAliasFile(fname):
"""Read in the U-Boot git alias file if it exists.
--
1.8.3.1
Re: [PATCH] ram: rockchip: px30: add a config-based ddr selection
> On 01.10.2020, at 20:40, Heiko Stuebner wrote: > > From: Heiko Stuebner > > The SRAM on the PX30 is not big enough to hold multiple DDR configs > so it needs to be selected during build. > > So far simply the DDR3 config was always selected and getting DDR4 > or LPDDR2/3 initialized would require a code modification. > > So add Kconfig options similar to RK3399 to allow selecting the DDR4 > and LPDDR2/3 options instead, while DDR3 stays the default as before. > > Signed-off-by: Heiko Stuebner Reviewed-by: Philipp Tomsich
Re: [PATCH] clk: rockchip: rk3399: implement getting wdt/alive clocks
> On 17.09.2020, at 11:42, Jack Mitchell wrote: > > In order to correctly calculate the designware watchdog > timeouts, the watchdog clock is required. Implement required > clocks to facilitate this. > > Signed-off-by: Jack Mitchell Reviewed-by: Philipp Tomsich
Re: [PATCH] pci: rockchip: Mark inline functions as static inline
> On 01.07.2020, at 17:47, Tom Rini wrote: > > Unless we mark the function as 'static inline' it may end up being > non-inlined by the compiled and result in duplicate functions. > > Cc: Jagan Teki > Cc: Kever Yang > Signed-off-by: Tom Rini Reviewed-by: Philipp Tomsich
Re: [PATCH 1/2] net: phy: mscc: make clock-output configurable on vsc85xx
> On 09.06.2020, at 15:37, Heiko Stuebner wrote: > > From: Heiko Stuebner > > The vsc8530/8531/8540/8541 phys have a configurable clock output that > can emit 25, 50 and 125 MHz rates, which in turn may be needed for > stable network connections. > > This follows a similar change introduced into the Linux kernel at > https://lore.kernel.org/netdev/20200609133140.1421109-2-he...@sntech.de > > Signed-off-by: Heiko Stuebner Reviewed-by: Philipp Tomsich
Re: [PATCH 2/2] net: phy: mscc: sync rx/tx delay settings with Linux on vsc85xx
> On 09.06.2020, at 15:37, Heiko Stuebner wrote: > > From: Heiko Stuebner > > The Linux kernel does set the clock delays to > - 0.2 ns (their default, and lowest, hardware value) if delays should > not be enabled > - 2.0 ns (which causes the data to be sampled at exactly half way between > clock transitions at 1000 Mbps) if delays should be enabled > depending on the interface mode > > See > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/phy/mscc/mscc_main.c#n523 > > So instead of using arbitrary delay values like now, mimic this behaviour. > > The behaviour is the same for all of vsc8530/8531/8540/8541 so move that > to a shared function while at it. > > Signed-off-by: Heiko Stuebner Reviewed-by: Philipp Tomsich
Re: [PATCH v3 7/8] rockchip: puma: drop special handling of usb host regulator
> On 05.06.2020, at 12:06, Heiko Stuebner wrote: > > From: Heiko Stuebner > > With the current usb stack in u-boot, all host ports on puma work > flawlessly without any additional special handling, so drop that > usb hub hacking from the puma board. > > Tested with mass-storage and usb-ethernet on both usb3 and usb2 ports. > > Signed-off-by: Heiko Stuebner > Reviewed-by: Kever Yang Reviewed-by: Philipp Tomsich
Re: [PATCH v3 2/8] arm64: dts: rk3399-puma: fix gpio levels for vcc5v0-host regulator
> On 05.06.2020, at 12:06, Heiko Stuebner wrote: > > From: Heiko Stuebner > > The regulator enable-gpio uses opposite values for the declaration > vs. the enable_active_low property, breaking the regulator enablement. > > Make the usbhost-supply work again by bringing them in sync again. > > This mimics the upstream Linux change found on: > http://lore.kernel.org/r/20200604091239.424318-1-he...@sntech.de > > Signed-off-by: Heiko Stuebner > Reviewed-by: Kever Yang Reviewed-by: Philipp Tomsich
Re: [PATCH v3 1/4] Makefile: Drop to handle rkspi image type
> On 04.06.2020, at 16:51, Jagan Teki wrote: > > On rockchip platforms, SPI boot image creation is not > straightforward like MMC boot image creation where former > requires to specify tpl, spl in multimage format in mkimage, > and later simply do a concatenate mkimaged-tpl with spl. > > On this note, let drop rkspi image type creation via kbuild > and let inform via rockchip.rst > > Signed-off-by: Jagan Teki > Reviewed-by: Kever Yang > --- > Changes for v3: > - none > > Makefile | 11 ++- > 1 file changed, 2 insertions(+), 9 deletions(-) > > diff --git a/Makefile b/Makefile > index 3851dd9fa0..db3b6b9991 100644 > --- a/Makefile > +++ b/Makefile > @@ -1438,22 +1438,15 @@ u-boot-with-spl.bin: $(SPL_IMAGE) $(SPL_PAYLOAD) FORCE > > ifeq ($(CONFIG_ARCH_ROCKCHIP),y) > > -# rockchip image type > -ifeq ($(CONFIG_SPL_SPI_LOAD),y) > -ROCKCHIP_IMG_TYPE := rkspi > -else > -ROCKCHIP_IMG_TYPE := rksd > -endif This should not be either-or, but rather allow the creation of both a SPI and SD/eMMC image for a platform, if so desired — e.g. the RK3399-Q7 supports both SPI and eMMC boot and it is a user-choice which location will be used for the bootloader. In other words: make this a “checkbox” option in Kconfig and output a rkspi, a rksd or both images depending on what is selected. Thanks, Philipp. > - > # TPL + SPL > ifeq ($(CONFIG_SPL)$(CONFIG_TPL),yy) > -MKIMAGEFLAGS_u-boot-tpl-rockchip.bin = -n $(CONFIG_SYS_SOC) -T > $(ROCKCHIP_IMG_TYPE) > +MKIMAGEFLAGS_u-boot-tpl-rockchip.bin = -n $(CONFIG_SYS_SOC) -T rksd > tpl/u-boot-tpl-rockchip.bin: tpl/u-boot-tpl.bin FORCE > $(call if_changed,mkimage) > idbloader.img: tpl/u-boot-tpl-rockchip.bin spl/u-boot-spl.bin FORCE > $(call if_changed,cat) > else > -MKIMAGEFLAGS_idbloader.img = -n $(CONFIG_SYS_SOC) -T $(ROCKCHIP_IMG_TYPE) > +MKIMAGEFLAGS_idbloader.img = -n $(CONFIG_SYS_SOC) -T rksd > idbloader.img: spl/u-boot-spl.bin FORCE > $(call if_changed,mkimage) > endif > -- > 2.25.1 >
Re: [PATCH v2 8/8] rockchip: puma: enable new usb config options
> On 04.06.2020, at 12:09, Heiko Stuebner wrote: > > From: Heiko Stuebner > > With recently added changes we get support for usb3 including handling > of the phys (type-c and inno-usb2), so enable the necessary config > options on puma. > > Signed-off-by: Heiko Stuebner Reviewed-by: Philipp Tomsich
Re: [PATCH 6/6] board: puma: remove separate fit generator
> On 03.06.2020, at 16:59, Heiko Stuebner wrote: > > From: Heiko Stuebner > > The introduction of the puma-specific generator was mainly a way > to split the pmu firmware from the ATF binary and not having to > distribute that 4GB (sparse) image that was created before moving > to the bl31.elf as base. > > Looking at the publically available repository for that separate > pmu firmware >https://git.theobroma-systems.com/rk3399-cortex-m0.git/ > there is also no activity for 3 years and apart from some build > customizations no other changes were done. > > And even then, if changes need to be made, this can very well also > happen in the atf context itself, so there is no real need to > diverge from the established build procedure and we can just go > back to using the main make_fit_atf.py script. > > Signed-off-by: Heiko Stuebner Reviewed-by: Philipp Tomsich
Re: [PATCH 1/6] arm64: dts: rk3399-puma: fix gpio levels for gmac reset pin
> On 03.06.2020, at 16:59, Heiko Stuebner wrote: > > From: Heiko Stuebner > > The gmac reset has opposite values for the gpio declaration > and the separate reset-active, bring this in line to make > u-boot also find the ethernet-phy. > > This mimics the upstream Linus commit found on > https://lore.kernel.org/r/20200603132836.362519-1-he...@sntech.de > > Signed-off-by: Heiko Stuebner Reviewed-by: Philipp Tomsich
Re: [PATCH 2/6] board: puma: fix indentation for -u-boot.dtsi
> On 03.06.2020, at 16:59, Heiko Stuebner wrote: > > From: Heiko Stuebner > > Tabs not spaces, so transform it to the common styling. > > Signed-off-by: Heiko Stuebner Reviewed-by: Philipp Tomsich
Re: [PATCH 4/6] board: puma: fix indentation of misc_init_r
> On 03.06.2020, at 16:59, Heiko Stuebner wrote:
>
> From: Heiko Stuebner
>
> The commit moving puma to the generic cpuid/macaddr helpers used 7 spaces
> as indentation, so correct that by moving to the required tabs.
>
> Fixes: fa177ff0208b ("board: puma: Use rockchip_* helpers to setup cpuid and
> macaddr")
> Signed-off-by: Heiko Stuebner
Reviewed-by: Philipp Tomsich
Re: [PATCH 5/6] board: puma: allow building with TPL as well
> On 03.06.2020, at 16:59, Heiko Stuebner wrote: > > From: Heiko Stuebner > > Right now puma-u-boot can fit everything into SPL but that may overflow > easily for example with more extensive debug options. > > By adding CONFIG_TPL and removing the CONFIG_SPL_TEXT_BASE it is easy > to enable a TPL build as well. Only obstacle is the usb-specific handling > for the puma regulator, so make this conditional on actual usb options > being enabled in SPL and U-Boot proper. > > Signed-off-by: Heiko Stuebner Reviewed-by: Philipp Tomsich
Re: [PATCH 3/6] board: puma: reorganize devicetrees to actually work and match upstream
> On 03.06.2020, at 16:59, Heiko Stuebner wrote:
>
> From: Heiko Stuebner
>
> So far the puma dts files only just included the main puma dtsi without
> handling the actual baseboard and rk3399-puma.dtsi was very much
> detached from the variant in the mainline Linux kernel.
>
> Recent changes resulted in a strange situation with nonworking puma boards.
>
> Commit ab800e5a6f28 ("arm: dts: rockchip: puma: move U-Boot specific bits to
> u-boot.dtsi")
> moved the sdram include from rk3399-puma-ddrX.dts to new files
> rk3399-puma-ddrx-u-boot.dtsi which were never included anywhere though.
>
> Commit 167efc2c7a46 ("arm64: dts: rk3399: Sync v5.7-rc1 from Linux")
> replaced the rk3399-puma.dtsi nearly completely, but in the kernel
> it definitly depends on a baseboard dts to actually enable peripherals
> like sd-slot, uarts, etc.
>
> So to untagle this and bring the whole thing more in line with mainline
> Linux, bring the rk3399-puma-haikou.dts over as well, drop the separate
> DDR-option devicetrees and instead replace them with a puma Kconfig option
> to select and include the needed DDR variant.
>
> Signed-off-by: Heiko Stuebner
Reviewed-by: Philipp Tomsich
Re: [PATCH v2 2/2] spl: add fixed memory node in target fdt also when loading ATF
> On 25.05.2020, at 19:57, Heiko Stuebner wrote: > > From: Heiko Stuebner > > In a loading chain SPL -> ATF (->OP-TEE) -> U-Boot, ATF and a subsequent > OP-TEE will re-use the same fdt as the U-Boot target and may need the > information about usable memory ranges. > > Especially OP-TEE needs this to initialize dynamic shared memory > (the only type U-Boot implements when talking to OP-TEE). > > So allow spl_fixup_fdt() to take a fdt_blob argument, falling back to > the existing CONFIG_SYS_SPL_ARGS_ADDR if needed and call it from the > ATF path as well. > > Signed-off-by: Heiko Stuebner > Reviewed-by: Kever Yang Reviewed-by: Philipp Tomsich
Re: [PATCH v5 4/8] lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop()
> On 22.05.2020, at 16:19, Heiko Stuebner wrote: > > From: Heiko Stuebner > > When calculating rrtmp/rr rsa_gen_key_prop() tries to make > (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and > (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] > with rlen being num_bits * 2 > > On a 4096bit key this comes down to to 257 uint32_t elements > in rr and 256 elements in rrtmp but with the current allocation > rr and rrtmp only have 129 uint32_t elements. > > On 2048bit keys this works by chance as the defined max_rsa_size=4096 > allocates a suitable number of elements, but with an actual 4096bit key > this results in other memory parts getting overwritten. > > so double the number of elements in rr and rrtmp so that it matches > the needed number and should increase nicely if max_rsa_size gets > increased in the future. > > Signed-off-by: Heiko Stuebner Reviewed-by: Philipp Tomsich
Re: [PATCH v4 5/8] lib: rsa: free local arrays after use in rsa_gen_key_prop()
> On 22.05.2020, at 16:13, Heiko Stuebner wrote: > > From: Heiko Stuebner > > n, rr and rrtmp are used for internal calculations, but in the end > the results are copied into separately allocated elements of the > actual key_prop, so the n, rr and rrtmp elements are not used anymore > when returning from the function and should of course be freed. > > Signed-off-by: Heiko Stuebner Reviewed-by: Philipp Tomsich
Re: [PATCH v4 6/8] lib: rsa: add documentation to padding_pss_verify to document limitations
> On 22.05.2020, at 16:13, Heiko Stuebner wrote: > > From: Heiko Stuebner > > padding_pss_verify only works with the default pss salt setting of -2 > (length to be automatically determined based on the PSS block structure) > not -1 (salt length set to the maximum permissible value), which makes > verifications of signatures with that saltlen fail. > > Until this gets implemented at least document this behaviour. > > Signed-off-by: Heiko Stuebner Reviewed-by: Philipp Tomsich
Re: [PATCH v4 2/8] lib: rsa: take spl/non-spl into account when building rsa_verify_with_pkey()
> On 22.05.2020, at 16:13, Heiko Stuebner wrote: > > From: Heiko Stuebner > > Right now in multiple places there are only checks for the full > CONFIG_RSA_VERIFY_WITH_PKEY option, not split into main,spl,tpl variants. > > This breaks when the rsa functions get enabled for SPL, for example to > verify u-boot proper from spl. > > So fix this by using the existing helpers to distinguis between > build-steps. > > Signed-off-by: Heiko Stuebner Reviewed-by: Philipp Tomsich
Re: [PATCH v4 3/8] lib: rsa: bring exp_len in line when generating a key_prop
> On 22.05.2020, at 16:13, Heiko Stuebner wrote: > > From: Heiko Stuebner > > The exponent field of struct key_prop gets allocated an uint64_t, > and the contents are positioned from the back, so an exponent of > "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" > > Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len > to the size returned from the parser, while on the other hand the > when getting the key from the devicetree exp_len always gets set to > sizeof(uint64_t). > > So bring that in line with the established code. > > Signed-off-by: Heiko Stuebner Reviewed-by: Philipp Tomsich
Re: [PATCH v3 1/4] lib: rsa: distinguish between tpl and spl for CONFIG_RSA_VERIFY
> On 18.05.2020, at 18:06, Heiko Stuebner wrote: > > From: Heiko Stuebner > > While the SPL may want to do signature checking this won't be > the case for TPL in all cases, as TPL is mostly used when the > amound of initial memory is not enough for a full SPL. nit: amound -> amount > So on a system where SPL uses DM but TPL does not we currently > end up with a TPL compile error of: > >lib/rsa/rsa-verify.c:48:25: error: dereferencing pointer to incomplete > type ‘struct checksum_algo’ > > To prevent that change the $(SPL_) to $(SPL_TPL_) to distinguish > between both. If someone really needs FIT signature checking in > TPL as well, a new TPL_RSA_VERIFY config symbol needs to be added. > > Signed-off-by: Heiko Stuebner > Reviewed-by: Philipp Tomsich > Reviewed-by: Kever Yang > --- > changes in v2: > - fix typo "distinguis(h)" > > I've split out the build fixes from the signature series. > It would be cool to get these applied already, as they do > fix actual issues to be seen when enabling signature support > in spl. > > > lib/rsa/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/lib/rsa/Makefile b/lib/rsa/Makefile > index 14ed3cb401..c61ebfd79e 100644 > --- a/lib/rsa/Makefile > +++ b/lib/rsa/Makefile > @@ -5,6 +5,6 @@ > # (C) Copyright 2000-2007 > # Wolfgang Denk, DENX Software Engineering, w...@denx.de. > > -obj-$(CONFIG_$(SPL_)RSA_VERIFY) += rsa-verify.o rsa-checksum.o > +obj-$(CONFIG_$(SPL_TPL_)RSA_VERIFY) += rsa-verify.o rsa-checksum.o > obj-$(CONFIG_RSA_VERIFY_WITH_PKEY) += rsa-keyprop.o > obj-$(CONFIG_RSA_SOFTWARE_EXP) += rsa-mod-exp.o > -- > 2.25.1 >
Re: [PATCH] rsa: fix alignment issue when getting public exponent
> On 03.05.2020, at 13:26, Heiko Stuebner wrote:
>
> From: Heiko Stuebner
>
> To fill the exponent field of the rsa_public_key struct, rsa_mod_exp_sw
> did a cast to uint64_t of the key_prop->public_exponent field.
> But that alignment is not guaranteed in all cases.
>
> This came to light when in my spl-fit-signature the key-name exceeded
> a certain length and with it the verification then started failing.
> (naming it "integrity" worked fine, "integrity-uboot" failed)
>
> key_prop.public_exponent itself is actually a void-pointer, fdt_getprop()
> also just returns such a void-pointer and inside the devicetree the 64bit
> exponent is represented as 2 32bit numbers, so assuming a 64bit alignment
> can lead to false reads.
>
> So just use the already existing rsa_convert_big_endian() to do the actual
> conversion from the dt's big-endian to the needed uint64 value.
>
> Fixes: fc2f4246b4b3 ("rsa: Split the rsa-verify to separate the modular
> exponentiation")
> Signed-off-by: Heiko Stuebner
Reviewed-by: Philipp Tomsich
Re: [PATCH 1/7] spl: fit: select SPL_HASH_SUPPORT for SPL_FIT_SIGNATURE
> On 18.04.2020, at 00:07, Heiko Stuebner wrote: > > From: Heiko Stuebner > > rsa-checsum needs support for hash functions or else will run into > compile errors like: > u-boot/lib/rsa/rsa-checksum.c:28: undefined reference to > `hash_progressive_lookup_algo' > > So similar to the main FIT_SIGNATURE entry selects HASH, > select SPL_HASH_SUPPORT for SPL_FIT_SIGNATURE. > > Cc: Heinrich Schuchardt > Signed-off-by: Heiko Stuebner Reviewed-by: Philipp Tomsich
Re: [PATCH 5/7] spl: fit: enable signing a generated u-boot.itb
> On 18.04.2020, at 00:07, Heiko Stuebner wrote: > > From: Heiko Stuebner > > With SPL_FIT_SIGNATURE enabled we will likely want a generated > u-boot.itb to be signed and the key stores so that the spl can > reach it. > > So add a SPL_FIT_SIGNATURE_KEY_DIR option and suitable hooks > into the Makefile to have mkimage sign the .itb and store the > used key into the spl dtb file. > > The added dependencies should make sure that the u-boot.itb > gets generated before the spl-binary gets build, so that there > is the necessary space for the key to get included. > > Signed-off-by: Heiko Stuebner Reviewed-by: Philipp Tomsich
Re: [PATCH 2/7] spl: fit: select SPL_CRYPTO_SUPPORT for SPL_FIT_SIGNATURE
> On 18.04.2020, at 00:07, Heiko Stuebner wrote: > > From: Heiko Stuebner > > Verifying FIT images obviously needs the rsa parts of crypto > support and while main uboot always compiles crypto support, > it's optional for SPL and we should thus select the necessary > option to not end up in compile errors like: > >u-boot/lib/rsa/rsa-verify.c:328: undefined reference to `rsa_mod_exp' > > So select SPL_CRYPTO_SUPPORT in SPL_FIT_SIGNATURE. > > Signed-off-by: Heiko Stuebner Reviewed-by: Philipp Tomsich
Re: [PATCH 3/7] lib: rsa: distinguish between tpl and spl for CONFIG_RSA_VERIFY
> On 18.04.2020, at 00:07, Heiko Stuebner wrote: > > From: Heiko Stuebner > > While the SPL may want to do signature checking this won't be > the case for TPL in all cases, as TPL is mostly used when the > amound of initial memory is not enough for a full SPL. > > So on a system where SPL uses DM but TPL does not we currently > end up with a TPL compile error of: > >lib/rsa/rsa-verify.c:48:25: error: dereferencing pointer to incomplete > type ‘struct checksum_algo’ > > To prevent that change the $(SPL_) to $(SPL_TPL_) to distinguis nit: distinguis -> distinguish > between both. If someone really needs FIT signature checking in > TPL as well, a new TPL_RSA_VERIFY config symbol needs to be added. > > Signed-off-by: Heiko Stuebner Reviewed-by: Philipp Tomsich
Re: [PATCH 6/7] spl: fit: add Kconfig option to specify key-hint for fit_generator
> On 18.04.2020, at 00:07, Heiko Stuebner wrote: > > From: Heiko Stuebner > > The u-boot.itb can be generated either from a static .its that can > simply include the needed signature nodes with key-hints or from a > fit-generator script referenced in CONFIG_SPL_FIT_GENERATOR. > > In the script-case it will need to know what key to include for the > key-hint and specified algorithm, so add an option for that key-name. > > Signed-off-by: Heiko Stuebner Reviewed-by: Philipp Tomsich
Re: [PATCH] rockchip: rk3399: enable spl-fifo-mode for sdmmc
> On 15.04.2020, at 05:25, Deepak Das wrote:
>
> adapting commit fa2047c47310 ("rockchip: rk3328: enable spl-fifo-mode
> for emmc and sdmmc") for rk3399.
> Since mmc to sram can't do dma, add patch to prevent aborts transferring
> TF-A parts.
>
> Signed-off-by: Deepak Das
> ---
> arch/arm/dts/rk3399-u-boot.dtsi | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi
> index 8b857ccfc7..3ad824450e 100644
> --- a/arch/arm/dts/rk3399-u-boot.dtsi
> +++ b/arch/arm/dts/rk3399-u-boot.dtsi
> @@ -84,6 +84,9 @@
>
> &sdmmc {
> u-boot,dm-pre-reloc;
> +
> + /* mmc to sram can't do dma, prevent aborts transferring TF-A parts */
> + u-boot,spl-fifo-mode;
Most transfers in SPL mode will occur to RAM (i.e. most of TF-A and the full
U-Boot),
so this is a heavy-handed solution for a problem affecting only some transfers.
Can’t this be solved using bounce buffers?
You will need to check if the target address cross the inaccessible memory
regions
and—if and only if—send these payloads through a bounce buffer...
> };
>
> &spi1 {
> --
> 2.17.1
>
Re: [PATCH 1/6] rockchip: efuse: Add support for rk3288 efuse
> On 20.02.2020, at 04:10, Finley Xiao wrote:
>
> This adds the necessary data for handling eFuse on the rk3288.
>
> Signed-off-by: Finley Xiao
Reviewed-by: Philipp Tomsich
Major rework required: see below.
> ---
> drivers/misc/rockchip-efuse.c | 76 ---
> 1 file changed, 72 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/misc/rockchip-efuse.c b/drivers/misc/rockchip-efuse.c
> index 2520c6a38e..f01d877e33 100644
> --- a/drivers/misc/rockchip-efuse.c
> +++ b/drivers/misc/rockchip-efuse.c
> @@ -15,6 +15,15 @@
> #include
> #include
>
> +#define RK3288_A_SHIFT 6
> +#define RK3288_A_MASK 0x3ff
> +#define RK3288_NFUSES 32
> +#define RK3288_BYTES_PER_FUSE 1
> +#define RK3288_PGENBBIT(3)
> +#define RK3288_LOAD BIT(2)
> +#define RK3288_STROBE BIT(1)
> +#define RK3288_CSB BIT(0)
> +
> #define RK3399_A_SHIFT 16
> #define RK3399_A_MASK 0x3ff
> #define RK3399_NFUSES 32
> @@ -27,6 +36,9 @@
> #define RK3399_STROBE BIT(1)
> #define RK3399_CSB BIT(0)
>
> +typedef int (*EFUSE_READ)(struct udevice *dev, int offset, void *buf,
> + int size);
> +
> struct rockchip_efuse_regs {
> u32 ctrl; /* 0x00 efuse control register */
> u32 dout; /* 0x04 efuse data out register */
> @@ -53,7 +65,7 @@ static int dump_efuses(cmd_tbl_t *cmdtp, int flag,
>*/
>
> struct udevice *dev;
> - u8 fuses[128];
> + u8 fuses[128] = {0};
> int ret;
>
> /* retrieve the device */
> @@ -77,12 +89,55 @@ static int dump_efuses(cmd_tbl_t *cmdtp, int flag,
> }
>
> U_BOOT_CMD(
> - rk3399_dump_efuses, 1, 1, dump_efuses,
> + rockchip_dump_efuses, 1, 1, dump_efuses,
> "Dump the content of the efuses",
> ""
> );
> #endif
>
> +static int rockchip_rk3288_efuse_read(struct udevice *dev, int offset,
> + void *buf, int size)
> +{
> + struct rockchip_efuse_platdata *plat = dev_get_platdata(dev);
> + struct rockchip_efuse_regs *efuse =
> + (struct rockchip_efuse_regs *)plat->base;
> + u8 *buffer = buf;
> + int max_size = RK3288_NFUSES * RK3288_BYTES_PER_FUSE;
> +
> + if (size > (max_size - offset))
> + size = max_size - offset;
> +
> + /* Switch to read mode */
> + writel(RK3288_LOAD | RK3288_PGENB, &efuse->ctrl);
> + udelay(1);
> +
> + while (size--) {
> + writel(readl(&efuse->ctrl) &
> + (~(RK3288_A_MASK << RK3288_A_SHIFT)),
> + &efuse->ctrl);
> + /* set addr */
> + writel(readl(&efuse->ctrl) |
> + ((offset++ & RK3288_A_MASK) << RK3288_A_SHIFT),
> + &efuse->ctrl);
> + udelay(1);
> + /* strobe low to high */
> + writel(readl(&efuse->ctrl) |
> + RK3288_STROBE, &efuse->ctrl);
> + ndelay(60);
> + /* read data */
> + *buffer++ = readl(&efuse->dout);
> + /* reset strobe to low */
> + writel(readl(&efuse->ctrl) &
> + (~RK3288_STROBE), &efuse->ctrl);
> + udelay(1);
> + }
> +
> + /* Switch to standby mode */
> + writel(RK3288_PGENB | RK3288_CSB, &efuse->ctrl);
> +
> + return 0;
> +}
> +
> static int rockchip_rk3399_efuse_read(struct udevice *dev, int offset,
> void *buf, int size)
> {
> @@ -130,7 +185,13 @@ static int rockchip_rk3399_efuse_read(struct udevice
> *dev, int offset,
> static int rockchip_efuse_read(struct udevice *dev, int offset,
> void *buf, int size)
> {
> - return rockchip_rk3399_efuse_read(dev, offset, buf, size);
> + EFUSE_READ efuse_read = NULL;
> +
> + efuse_read = (EFUSE_READ)dev_get_driver_data(dev);
> + if (!efuse_read)
> + return -EINVAL;
> +
> + return (*efuse_read)(dev, offset, buf, size);
> }
>
> static const struct misc_ops rockchip_efuse_ops = {
> @@ -146,7 +207,14 @@ static int rockchip_efuse_ofdata_to_platdata(struct
> udevice *dev)
> }
>
> static const struct udevice_id rockchip_efuse_ids[] = {
> - { .compatible = "rockchip,rk3399-efuse" },
> + {
> + .compatible = "rockchip,rk3288-efuse",
> + .data = (ul
Re: [PATCH 1/2] Revert "rockchip: spi: fix off-by-one in chunk size computation"
> On 11.12.2019, at 14:26, Jagan Teki wrote:
>
> The maximum transfer length (in a single transaction) for the Rockchip
> SPI controller is 64Kframes (i.e. 0x1 frames) of 8bit or 16bit
> frames and is encoded as (num_frames - 1) in CTRLR1.
>
> So the 0x1 is offset value for 64K but the actual size value would
> be 'minus 1' from 0x1.
NAK. Please see 2 code lines below your change to see that the “minus 1”
is applied there… so a todo of 0x1 will write 0x to regs->ctrlr1.
The problem must be somewhere else and this patch will only mask the
underlying issue.
>
> With the existing code of 0x1 transfer length leads to read
> failure when we try to read the flash with > 0x1 size like,
>
> 1. sf read failure when with > 0x1
>
> 2. Boot from SPI flash failed during spi_flash_read call in
> common/spl/spl_spi.c
>
> Observed and Tested in
> - Rockpro64 with Gigadevice flash
> - ROC-RK3399-PC with Winbond flash
>
> This reverts commit e647decdd93c7408741329432f26758fbec04c7a.
>
> Signed-off-by: Jagan Teki
> ---
> drivers/spi/rk_spi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/spi/rk_spi.c b/drivers/spi/rk_spi.c
> index c04535ac44..d9a310ce80 100644
> --- a/drivers/spi/rk_spi.c
> +++ b/drivers/spi/rk_spi.c
> @@ -451,7 +451,7 @@ static int rockchip_spi_xfer(struct udevice *dev,
> unsigned int bitlen,
>
> /* This is the original 8bit reader/writer code */
> while (len > 0) {
> - int todo = min(len, 0x1);
> + int todo = min(len, 0x);
>
> rkspi_enable_chip(regs, false);
> writel(todo - 1, ®s->ctrlr1);
> --
> 2.18.0.321.gffc6fa0e3
>
Re: [U-Boot] [PATCH 2/2] rockchip: px30: Add support for using UART3 as debug UART
Heiko, > On 28.11.2019, at 10:44, Heiko Stuebner > wrote: > > On 27.11.19 11:12, Paul Kocialkowski wrote: >> Some generic PX30 SoMs found in the wild use UART3 as their debug output >> instead of UART2 (used for MMC) and UART5. >> >> Make it possible to use UART3 as early debug output, with the associated >> clock and pinmux configuration. Two sets of output pins are supported (M0/M1) >> so a Kconfig option to select between the two is introduced like it's done >> for UART2. >> >> Future users should also note that the pinmux default in the dts is to use >> the M1 pins while the Kconfig option takes M0 as a default. >> >> Signed-off-by: Paul Kocialkowski > > Reviewed-by: Heiko Stuebner > > with one small question below > >> diff --git a/arch/arm/mach-rockchip/px30/Kconfig >> b/arch/arm/mach-rockchip/px30/Kconfig >> index 109a37be15ad..167517bbd63f 100644 >> --- a/arch/arm/mach-rockchip/px30/Kconfig >> +++ b/arch/arm/mach-rockchip/px30/Kconfig >> @@ -36,6 +36,15 @@ config DEBUG_UART2_CHANNEL >>For using the UART for early debugging the route to use needs >>to be declared (0 or 1). >> +config DEBUG_UART3_CHANNEL >> +int "Mux channel to use for debug UART3" >> +depends on DEBUG_UART_BOARD_INIT >> +default 0 >> +help >> + UART3 can use two different set of pins to route the output. >> + For using the UART for early debugging the route to use needs >> + to be declared (0 or 1). >> + >> source "board/rockchip/evb_px30/Kconfig" > > Would it make sense to rename DEBUG_UART3_CHANNEL to just > DEBUG_UART_CHANNEL and reuse it, so that we don't collect similar > options for each uart? Let me also check what we use on the Jaguar platform, as that will be our baseline platform for PX30 support for TSD boards... Thanks, Philipp. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] rockchip: px5: enable spl-fifo-mode for emmc for px5-evb
> On 26.11.2019, at 14:15, Andy Yan wrote: > > We need load some parts of ATF to sram, but rockchip > dwmmc controllers can't do dma to non-ddr addresses > space, so set the mmc controller into fifo mode in spl. > > Signed-off-by: Andy Yan Reviewed-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] rockchip: px30: enable spl-fifo-mode for both emmc and sdmmc on evb
> On 19.11.2019, at 12:04, Heiko Stuebner wrote: > > From: Heiko Stuebner > > As part of loading trustedfirmware, the SPL is required to place portions > of code into the socs sram but the mmc controllers can only do dma > transfers into the regular memory, not sram. > > The results of this are not directly visible in u-boot itself, but > manifest as security-relate cpu aborts during boot of for example Linux. > > There were a number of attempts to solve this elegantly but so far > discussion is still ongoing, so to make the board at least boot correctly > put both mmc controllers into fifo-mode, which also circumvents the > issue for now. > > Signed-off-by: Heiko Stuebner Reviewed-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] rockchip: dwmmc: add handling for u-boot, spl-fifo-mode
Sorry, I was confused and meant... > On 20.11.2019, at 12:09, Philipp Tomsich > wrote: > > > >> On 19.11.2019, at 12:04, Heiko Stuebner wrote: >> >> From: Heiko Stuebner >> >> Rockchips dwmmc controllers can't do dma to non-ddr addresses, >> like for example the soc-internal sram but during boot parts of >> TrustedFirmware need to be placed there from the read FIT image. >> >> So add handling for a u-boot,spl-fifo-mode to not put the mmc >> controllers into fifo mode for all time. >> >> The regular fifo-mode property still takes precedent and only >> if not set do we check for the spl-specific property. >> >> Suggested-by: Philipp Tomsich >> Signed-off-by: Heiko Stuebner > > Signed-off-by: Philipp Tomsich Reviewed-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] rockchip: dwmmc: add handling for u-boot, spl-fifo-mode
> On 19.11.2019, at 12:04, Heiko Stuebner wrote: > > From: Heiko Stuebner > > Rockchips dwmmc controllers can't do dma to non-ddr addresses, > like for example the soc-internal sram but during boot parts of > TrustedFirmware need to be placed there from the read FIT image. > > So add handling for a u-boot,spl-fifo-mode to not put the mmc > controllers into fifo mode for all time. > > The regular fifo-mode property still takes precedent and only > if not set do we check for the spl-specific property. > > Suggested-by: Philipp Tomsich > Signed-off-by: Heiko Stuebner Signed-off-by: Philipp Tomsich > --- > drivers/mmc/rockchip_dw_mmc.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/drivers/mmc/rockchip_dw_mmc.c b/drivers/mmc/rockchip_dw_mmc.c > index b2a1201631..a0e1be8794 100644 > --- a/drivers/mmc/rockchip_dw_mmc.c > +++ b/drivers/mmc/rockchip_dw_mmc.c > @@ -72,6 +72,11 @@ static int rockchip_dwmmc_ofdata_to_platdata(struct > udevice *dev) > return -EINVAL; > priv->fifo_mode = dev_read_bool(dev, "fifo-mode"); > > +#ifdef CONFIG_SPL_BUILD > + if (!priv->fifo_mode) > + priv->fifo_mode = dev_read_bool(dev, "u-boot,spl-fifo-mode"); > +#endif Nitpick: I would have used an “|=" instead of the "if(…)”. > + > /* >* 'clock-freq-min-max' is deprecated >* (see > https://github.com/torvalds/linux/commit/b023030f10573de738bbe8df63d43acab64c9f7b) > -- > 2.24.0 > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] rockchip: px30: enable fifo mode for both emmc and sdmmc on evb
Heiko,
> On 19.11.2019, at 11:03, Heiko Stuebner wrote:
>
> From: Heiko Stuebner
>
> As part of loading trustedfirmware, the SPL is required to place portions
> of code into the socs sram but the mmc controllers can only do dma
> transfers into the regular memory, not sram.
>
> The results of this are not directly visible in u-boot itself, but
> manifest as security-relate cpu aborts during boot of for example Linux.
>
> There were a number of attempts to solve this elegantly but so far
> discussion is still ongoing, so to make the board at least boot correctly
> put both mmc controllers into fifo-mode, which also circumvents the
> issue for now.
>
> Signed-off-by: Heiko Stuebner
> ---
> arch/arm/dts/px30-evb-u-boot.dtsi | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/dts/px30-evb-u-boot.dtsi
> b/arch/arm/dts/px30-evb-u-boot.dtsi
> index 3de9c7068e..27b8364e6c 100644
> --- a/arch/arm/dts/px30-evb-u-boot.dtsi
> +++ b/arch/arm/dts/px30-evb-u-boot.dtsi
> @@ -31,12 +31,15 @@
> &sdmmc {
> u-boot,dm-pre-reloc;
>
> - /* temporary till I find out why dma mode doesn't work */
> + /* mmc to sram can't do dma, prevent aborts transfering TF-A parts */
> fifo-mode;
Could you add a u-boot,spl-fifo-mode property to the driver?
Otherwise we force the controllers back to fifo-mode even for full U-Boot with
the associated performance impact.
Thanks,
Philipp.
> };
>
> &emmc {
> u-boot,dm-pre-reloc;
> +
> + /* mmc to sram can't do dma, prevent aborts transfering TF-A parts */
> + fifo-mode;
> };
>
> &grf {
> --
> 2.24.0
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v0] rockchip: adding the missing "/" in entries of boot_devices
> On 17.10.2019, at 09:22, d...@t-chip.com.cn wrote: > > From: Levin Du > > Without the prefix, "same-as-spl" in `u-boot,spl-boot-order` will not work > as expected. When board_boot_order() `spl-boot-order.c` meets > "same-as-spl", it gets the conf by looking the boot_devices table by boot > source, and parse the node by the conf with: > > node = fdt_path_offset(blob, conf); > > which will failed without the "/" indicating the path. > > Currently only entries of boot_devices in rk3399 have the "/" prefix. > Therefore add the missing ones in other boards. Good catch. One can thus tell what platform I originally tested this on ;-) > Signed-off-by: Levin Du Reviewed-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] rockchip: misc: read the correct number of bytes from the efuse
> On 25.09.2019, at 20:40, Heiko Stuebner wrote:
>
> Originally the cpuid var the value gets read into was defined as
>u8 cpuid[RK3399_CPUID_LEN];
> hence the sizeof(cpuid) would return the correct the correct number
> of array elements.
>
> With the move to a separate function cpuid becomes a pointer and
> sizeof(cpuid) hence returns the pointer size - 8 in the arm64 case.
>
> We do have the actual id length available as function param so use
> it for actual amount of bytes to read.
>
> Fixes: 04825384999f ("rockchip: rk3399: derive ethaddr from cpuid")
> Signed-off-by: Heiko Stuebner
Reviewed-by: Philipp Tomsich
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Should I create a new UCLASS for Bootstate or Add new Ops to UCLASS_BOOTCOUNT ??
Joel, > On 10.09.2019, at 01:07, Simon Glass wrote: > > Hi Joel, > > On Sat, 7 Sep 2019 at 18:34, Joel Peshkin wrote: >> >> >> Hi Simon, >> >> I need to create and upstream driver for a set of functions that manage >> volatile information that persist across reboots. These are simple >> registers that survive reboot but get cleared on power-cycle. The key >> operations we need to implement are ... >> >> boot_state_set_alternate_image_once() >>Called before rebooting (from uboot proper or from Linux)... sets flags >> to cause the next reboot to select an alternate image >> >> boot_state_getandclear_alternate_image() >>Called during boot (during SPL or TPL if using dual-uboot images as we >> do). Gets the status of the alternate_image flag and clears it. Could you elaborate how these are used? This sounds a lot like an A/B partition scheme, but I’d like to fully understand the use cases and what data is stored where before commenting in more detail. >> In our implementation, we have registers that always clear on power-cycle, >> but survive the soft reboot. Other implementations, where there is no such >> register, would still only use the alternate image once as long as the boot >> attempt reaches the getandclear_alternate_image() function, so drivers >> similar to those available in bootcount could easily handle the same >> function. >> >> Would you prefer that I create a new UCLASS or is it OK to extend the >> UCLASS_BOOTCOUNT operations and upstream the new operations, supported on a >> subset of the drivers that implement UCLASS_BOOTCOUNT ?? > > I think that adding new operations makes sense for now. > > I've added a few other people for thoughts. > > Regards, > Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/7] rockchip: ram: add full feature rk3328 DRAM driver
Kever, > On 02.08.2019, at 09:39, Matwey V. Kornilov wrote: > > From: Kever Yang > > This driver supports DDR3/LPDDR3/DDR4 SDRAM initialization. How is the unified driver for the Designware DRAM controller coming along? We’ve had that discussion over a year ago and it seems as if we’re still adding individual drivers for the closely related DRAM controllers… Thanks, Philipp. > Signed-off-by: YouMin Chen > Signed-off-by: Kever Yang > [cherry picked from commit > https://github.com/rockchip-linux/u-boot/commit/9fb0777ec3cc6a89af9d2e0969c3bfe58306a88d > with minor modifications] > Signed-off-by: Matwey V. Kornilov > --- > arch/arm/include/asm/arch-rockchip/sdram_rk3328.h | 441 + > drivers/ram/rockchip/sdram_rk3328.c | 1018 - > 2 files changed, 1456 insertions(+), 3 deletions(-) > create mode 100644 arch/arm/include/asm/arch-rockchip/sdram_rk3328.h > > diff --git a/arch/arm/include/asm/arch-rockchip/sdram_rk3328.h > b/arch/arm/include/asm/arch-rockchip/sdram_rk3328.h > new file mode 100644 > index 00..11411ead10 > --- /dev/null > +++ b/arch/arm/include/asm/arch-rockchip/sdram_rk3328.h > @@ -0,0 +1,441 @@ > +/* > + * Copyright (C) 2016-2017 Rockchip Electronics Co., Ltd > + * > + * SPDX-License-Identifier: GPL-2.0+ > + */ > + > +#ifndef _ASM_ARCH_SDRAM_RK3328_H > +#define _ASM_ARCH_SDRAM_RK3328_H > + > +#define SR_IDLE 93 > +#define PD_IDLE 13 > +#define SDRAM_ADDR 0x > +#define PATTERN (0x5aa5f00f) > + > +/* ddr pctl registers define */ > +#define DDR_PCTL2_MSTR 0x0 > +#define DDR_PCTL2_STAT 0x4 > +#define DDR_PCTL2_MSTR1 0x8 > +#define DDR_PCTL2_MRCTRL00x10 > +#define DDR_PCTL2_MRCTRL10x14 > +#define DDR_PCTL2_MRSTAT 0x18 > +#define DDR_PCTL2_MRCTRL20x1c > +#define DDR_PCTL2_DERATEEN 0x20 > +#define DDR_PCTL2_DERATEINT 0x24 > +#define DDR_PCTL2_PWRCTL 0x30 > +#define DDR_PCTL2_PWRTMG 0x34 > +#define DDR_PCTL2_HWLPCTL0x38 > +#define DDR_PCTL2_RFSHCTL0 0x50 > +#define DDR_PCTL2_RFSHCTL1 0x54 > +#define DDR_PCTL2_RFSHCTL2 0x58 > +#define DDR_PCTL2_RFSHCTL4 0x5c > +#define DDR_PCTL2_RFSHCTL3 0x60 > +#define DDR_PCTL2_RFSHTMG0x64 > +#define DDR_PCTL2_RFSHTMG1 0x68 > +#define DDR_PCTL2_RFSHCTL5 0x6c > +#define DDR_PCTL2_INIT0 0xd0 > +#define DDR_PCTL2_INIT1 0xd4 > +#define DDR_PCTL2_INIT2 0xd8 > +#define DDR_PCTL2_INIT3 0xdc > +#define DDR_PCTL2_INIT4 0xe0 > +#define DDR_PCTL2_INIT5 0xe4 > +#define DDR_PCTL2_INIT6 0xe8 > +#define DDR_PCTL2_INIT7 0xec > +#define DDR_PCTL2_DIMMCTL0xf0 > +#define DDR_PCTL2_RANKCTL0xf4 > +#define DDR_PCTL2_CHCTL 0xfc > +#define DDR_PCTL2_DRAMTMG0 0x100 > +#define DDR_PCTL2_DRAMTMG1 0x104 > +#define DDR_PCTL2_DRAMTMG2 0x108 > +#define DDR_PCTL2_DRAMTMG3 0x10c > +#define DDR_PCTL2_DRAMTMG4 0x110 > +#define DDR_PCTL2_DRAMTMG5 0x114 > +#define DDR_PCTL2_DRAMTMG6 0x118 > +#define DDR_PCTL2_DRAMTMG7 0x11c > +#define DDR_PCTL2_DRAMTMG8 0x120 > +#define DDR_PCTL2_DRAMTMG9 0x124 > +#define DDR_PCTL2_DRAMTMG10 0x128 > +#define DDR_PCTL2_DRAMTMG11 0x12c > +#define DDR_PCTL2_DRAMTMG12 0x130 > +#define DDR_PCTL2_DRAMTMG13 0x134 > +#define DDR_PCTL2_DRAMTMG14 0x138 > +#define DDR_PCTL2_DRAMTMG15 0x13c > +#define DDR_PCTL2_DRAMTMG16 0x140 > +#define DDR_PCTL2_ZQCTL0 0x180 > +#define DDR_PCTL2_ZQCTL1 0x184 > +#define DDR_PCTL2_ZQCTL2 0x188 > +#define DDR_PCTL2_ZQSTAT 0x18c > +#define DDR_PCTL2_DFITMG00x190 > +#define DDR_PCTL2_DFITMG10x194 > +#define DDR_PCTL2_DFILPCFG0 0x198 > +#define DDR_PCTL2_DFILPCFG1 0x19c > +#define DDR_PCTL2_DFIUPD00x1a0 > +#define DDR_PCTL2_DFIUPD10x1a4 > +#define DDR_PCTL2_DFIUPD20x1a8 > +#define DDR_PCTL2_DFIMISC0x1b0 > +#define DDR_PCTL2_DFITMG20x1b4 > +#define DDR_PCTL2_DFITMG30x1b8 > +#define DDR_PCTL2_DFISTAT0x1bc > +#define DDR_PCTL2_DBICTL 0x1c0 > +#define DDR_PCTL2_ADDRMAP0 0x200 > +#define DDR_PCTL2_ADDRMAP1 0x204 > +#define DDR_PCTL2_ADDRMAP2 0x208 > +#define DDR_PCTL2_ADDRMAP3 0x20c > +#define DDR_PCTL2_ADDRMAP4 0x210 > +#define DDR_PCTL2_ADDRMAP5 0x214 > +#define DDR_PCTL2_ADDRMAP6 0x218 > +#define DDR_PCTL2_ADDRMAP7 0x21c > +#define DDR_PCTL2_ADDRMAP8 0x220 >
Re: [U-Boot] [PATCH v3 3/3] board: puma: Use rockchip_* helpers to setup cpuid and macaddr【请注意，邮件由u-boot-boun...@lists.denx.de代发】 setup cpuid and macaddr
> On 25.07.2019, at 18:39, Rohan Garg wrote:
>
> Hey
> On Wednesday, 24 July 2019 14:26:44 CEST Kever Yang wrote:
>> Hi Rohan,
>>
>> On 2019/7/24 下午7:09, Rohan Garg wrote:
>>> We should use the shared helpers to setup the necessary parts
>>>
>>> Signed-off-by: Rohan Garg
>>> ---
>>>
>>> .../puma_rk3399/puma-rk3399.c | 108 +++---
>>> 1 file changed, 18 insertions(+), 90 deletions(-)
>>>
>>> diff --git a/board/theobroma-systems/puma_rk3399/puma-rk3399.c
>>> b/board/theobroma-systems/puma_rk3399/puma-rk3399.c index
>>> 251cd2d566..fb6c7c1f0a 100644
>>> --- a/board/theobroma-systems/puma_rk3399/puma-rk3399.c
>>> +++ b/board/theobroma-systems/puma_rk3399/puma-rk3399.c
>>> @@ -17,6 +17,7 @@
>>>
>>> #include
>>> #include
>>> #include
>>>
>>> +#include
>>>
>>> #include
>>> #include
>>> #include
>>>
>>> @@ -36,94 +37,6 @@ int board_init(void)
>>>
>>> return 0;
>>>
>>> }
>>>
>>> -static void setup_macaddr(void)
>>> -{
>>> -#if CONFIG_IS_ENABLED(CMD_NET)
>>> - int ret;
>>> - const char *cpuid = env_get("cpuid#");
>>> - u8 hash[SHA256_SUM_LEN];
>>> - int size = sizeof(hash);
>>> - u8 mac_addr[6];
>>> -
>>> - /* Only generate a MAC address, if none is set in the environment
> */
>>> - if (env_get("ethaddr"))
>>> - return;
>>> -
>>> - if (!cpuid) {
>>> - debug("%s: could not retrieve 'cpuid#'\n", __func__);
>>> - return;
>>> - }
>>> -
>>> - ret = hash_block("sha256", (void *)cpuid, strlen(cpuid), hash,
> &size);
>>> - if (ret) {
>>> - debug("%s: failed to calculate SHA256\n", __func__);
>>> - return;
>>> - }
>>> -
>>> - /* Copy 6 bytes of the hash to base the MAC address on */
>>> - memcpy(mac_addr, hash, 6);
>>> -
>>> - /* Make this a valid MAC address and set it */
>>> - mac_addr[0] &= 0xfe; /* clear multicast bit */
>>> - mac_addr[0] |= 0x02; /* set local assignment bit (IEEE802) */
>>> - eth_env_set_enetaddr("ethaddr", mac_addr);
>>> -#endif
>>> -}
>>> -
>>> -static void setup_serial(void)
>>> -{
>>> -#if CONFIG_IS_ENABLED(ROCKCHIP_EFUSE)
>>> - const u32 cpuid_offset = 0x7;
>>> - const u32 cpuid_length = 0x10;
>>> -
>>> - struct udevice *dev;
>>> - int ret, i;
>>> - u8 cpuid[cpuid_length];
>>> - u8 low[cpuid_length/2], high[cpuid_length/2];
>>> - char cpuid_str[cpuid_length * 2 + 1];
>>> - u64 serialno;
>>> - char serialno_str[17];
>>> -
>>> - /* retrieve the device */
>>> - ret = uclass_get_device_by_driver(UCLASS_MISC,
>>> -
> DM_GET_DRIVER(rockchip_efuse), &dev);
>>> - if (ret) {
>>> - debug("%s: could not find efuse device\n", __func__);
>>> - return;
>>> - }
>>> -
>>> - /* read the cpu_id range from the efuses */
>>> - ret = misc_read(dev, cpuid_offset, &cpuid, sizeof(cpuid));
>>> - if (ret) {
>>> - debug("%s: reading cpuid from the efuses failed\n",
>>> - __func__);
>>> - return;
>>> - }
>>> -
>>> - memset(cpuid_str, 0, sizeof(cpuid_str));
>>> - for (i = 0; i < 16; i++)
>>> - sprintf(&cpuid_str[i * 2], "%02x", cpuid[i]);
>>> -
>>> - debug("cpuid: %s\n", cpuid_str);
>>> -
>>> - /*
>>> -* Mix the cpuid bytes using the same rules as in
>>> -* ${linux}/drivers/soc/rockchip/rockchip-cpuinfo.c
>>> -*/
>>> - for (i = 0; i < 8; i++) {
>>> - low[i] = cpuid[1 + (i << 1)];
>>> - high[i] = cpuid[i << 1];
>>> - }
>>> -
>>> - serialno = crc32_no_comp(0, low, 8);
>>> - serialno |= (u64)crc32_no_comp(serialno, high, 8) << 32;
>>> - snprintf(serialno_str, sizeof(serialno_str), "%016llx", serialno);
>>> -
>>> - env_set("cpuid#", cpuid_str);
>>> - env_set("serial#", serialno_str);
>>> -#endif
>>> -}
>>> -
>>>
>>> static void setup_iodomain(void)
>>> {
>>>
>>> const u32 GRF_IO_VSEL_GPIO4CD_SHIFT = 3;
>>>
>>> @@ -213,8 +126,23 @@ static int setup_boottargets(void)
>>>
>>> int misc_init_r(void)
>>
>> After misc_init_r has add into rk3399_board, then this misc_init_r()
>> here will be multi-defined?
>>
>> In this case, maybe we need to remove the misc_init_r() from
>> rk3399_board.c first? :(
>>
>
> I'm a bit confused. I thought the idea was to hoist this code up into rk3399-
> board.c?
>
> On a separate note, perhaps setup_iodomain should move into a more generic
> helper for the rk3399 boards.
>
> I'm also not sure why setup_boottargets fiddles around with boot order, but
> perhaps we shouldn't be doing that? None of the other boards seem to do that
> (
> or at least none that I could find anyway ).
Please refer to the comment above setup_boottargets() in
board/theobroma-systems/puma_rk3399/puma-rk3399.c
for details on why the bootorder is modified for distroboot.
Please make sure that this is left in place, as it will otherwise break the
expected
and documented behaviour (i.e. how the “BIOS_DISABLE” signal is expected to
work) for the RK3399-Q7.
Thanks,
Ph
Re: [U-Boot] [PATCH 1/1] rockchip: video: rk3288_hdmi: Add missing call to dw_hdmi_enable()
> On 14.07.2019, at 12:40, Niklas Schulze wrote: > > The RK3288 HDMI driver's rk3288_hdmi_enable() currently lacks a call to > dw_hdmi_enable(). Thus, the HDMI output never gets enabled. > > Signed-off-by: Niklas Schulze > Cc: Philipp Tomsich Reviewed-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] board: puma: Use rockchip_* helpers to setup cpuid and macaddr
> On 11.07.2019, at 18:28, Rohan Garg wrote: > > Signed-off-by: Rohan Garg Your commit message is empty on this one. Please revise. Thanks, Philipp. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V2 41/51] spl: pass args to board_return_to_bootrom
> On 08.07.2019, at 03:40, Peng Fan wrote: > > Pass spl_image and bootdev to board_return_bootrom. > i.MX8MN needs the args to let ROM to load images > > Cc: Simon Glass > Cc: Philipp Tomsich > Cc: Kever Yang > Signed-off-by: Peng Fan Reviewed-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] rockchip: remove redundant pinctrl header including
> On 09.07.2019, at 15:55, Kever Yang wrote: > > No code is using this header file, remove it. You are not removing the header file, but are simply not including it. Thanks, Phil. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 00/92] ram: rk3399: Add LPDDR4 support
> On 12.06.2019, at 17:30, Jagan Teki wrote: > > On Tue, Jun 11, 2019 at 8:36 PM Philipp Tomsich > <mailto:philipp.toms...@theobroma-systems.com>> wrote: >> >> >> >>> On 11.06.2019, at 17:03, Jagan Teki wrote: >>> >>> On Tue, Jun 11, 2019 at 8:23 PM Philipp Tomsich >>> wrote: >>>> >>>> >>>> >>>>> On 11.06.2019, at 16:50, Jagan Teki wrote: >>>>> >>>>> Yes, it can be possible to break this series into multiple sub series >>>>> but idea here is to mark all the required changes to support LPDDR4 >>>>> in rk3399 in one set. if required we can break it from next versions. >>>>> >>>>> This is the initial set for supporting LPDDR4 with associated >>>>> features. >>>>> >>>>> Thanks to >>>>> - YouMin Chen >>>>> - Akash Gajjar >>>>> - Kever Yang >>>>> for supporting all the help on this work. >>>>> >>>>> On summary this series support >>>>> - Code warning and fixes >>>>> - rank detection, this would required to probe single channel >>>>> sdram configured in NanoPI-NEO4 >>>>> - LPDDR4 support, tested in Rockpro64 and Rock-PI-4 >>>>> >>>>> patch 0001 - 0033: fix code warnings, prints, new macros >>>>> >>>>> patch 0034 - 0051: rank detection, sdram debug code >>>>> >>>>> patch 0052: Use DDR3-1800 on NanoPI-NEO4 >>>>> >>>>> patch 0053 - 0089: lpddr4 support >>>>> >>>>> patch 0090: LPDDR4-100 timings >>>>> >>>>> patch 0091: Use LPDDR4-100 on Rockpro64 >>>>> >>>>> patch 0092: Use LPDDR4-100 on Rock-PI 4 >>>>> >>>>> Note: Puma rk3399 has SPL size overflow, better to enable TPL >>>>> for this board. >>>> >>>> We need to keep Puma on a SPL-only configuration for the time being. >>>> Please make sure that the LPDDR4 code is an optional feature that does not >>>> increase the DRAM-driver size for boards that don’t need/want it. >>> >>> We have few boards do have TPL-runnable, would be any technical issue >>> to switch puma to TPL? because we have lpddr4 code part of existing >>> driver itself and it require extra ifdef to consider which indeed look >>> awful from code point-of-view. >> >> Our secure boot process (i.e. signing tools) currently depends on this and >> the changeover won’t be quick… > > Not so quick, we have time till MW. isn't it possible? enabling secure > tools in both TPL and SPL or TPL-alone would be meaningful trail. what > do you think? We aren’t talking about a single MW here, given that summer is starting to eat up some of my resources… Thanks, Phil. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 00/92] ram: rk3399: Add LPDDR4 support
> On 11.06.2019, at 16:50, Jagan Teki wrote: > > Yes, it can be possible to break this series into multiple sub series > but idea here is to mark all the required changes to support LPDDR4 > in rk3399 in one set. if required we can break it from next versions. > > This is the initial set for supporting LPDDR4 with associated > features. > > Thanks to > - YouMin Chen > - Akash Gajjar > - Kever Yang > for supporting all the help on this work. > > On summary this series support > - Code warning and fixes > - rank detection, this would required to probe single channel > sdram configured in NanoPI-NEO4 > - LPDDR4 support, tested in Rockpro64 and Rock-PI-4 > > patch 0001 - 0033: fix code warnings, prints, new macros > > patch 0034 - 0051: rank detection, sdram debug code > > patch 0052: Use DDR3-1800 on NanoPI-NEO4 > > patch 0053 - 0089: lpddr4 support > > patch 0090: LPDDR4-100 timings > > patch 0091: Use LPDDR4-100 on Rockpro64 > > patch 0092: Use LPDDR4-100 on Rock-PI 4 > > Note: Puma rk3399 has SPL size overflow, better to enable TPL > for this board. We need to keep Puma on a SPL-only configuration for the time being. Please make sure that the LPDDR4 code is an optional feature that does not increase the DRAM-driver size for boards that don’t need/want it. Thanks, Philipp. > > Any inputs? > Jagan. > > Jagan Teki (92): > ram: rk3399: Fix code warnings > ram: rk3399: Add space between string with format specifier > ram: rk3399: Add proper spaces in data training > ram: rk3399: Handle data training return types > ram: rk3399: Order include files > ram: rk3399: Move macro after include files > ram: rk3399: Clear PI_175 interrupts in data training > ram: rk3399: Use rank mask in ca data training > ram: rk3399: Use rank mask in wdql data training > ram: rk3399: Add ddrtype enc macro > ram: rk3399: Add channel number encoder macro > ram: rk3399: Add row_3_4 enc macro > ram: rk3399: Add chipinfo macro > ram: rk3399: Add rank enc macro > ram: rk3399: Add column enc macro > ram: rk3399: Add bk enc macro > ram: rk3399: Add dbw enc macro > ram: rk3399: Add cs0_rw macro > ram: rk3399: Add cs1_rw macro > ram: rk3399: Add bw enc macro > ram: rk3399: Rename sys_reg with sys_reg2 > ram: rk3399: Update cs0_row to use sys_reg3 > ram: rk3399: Update cs1_row to use sys_reg3 > ram: rk3399: Add cs1_col enc macro > ram: rk3399: Add ddr version enc macro > ram: rk3399: Add ddrtimingC0 > ram: rk3399: Add DdrMode > ram: rk3399: Handle pctl_cfg return type > ram: rk3399: s/tsel_wr_select_n/tsel_wr_select_dq_n > ram: rk3399: s/tsel_wr_select_p/tsel_wr_select_dq_p > ram: rk3399: s/ca_tsel_wr_select_n/tsel_wr_select_ca_n > ram: rk3399: s/ca_tsel_wr_select_p/tsel_wr_select_ca_p > ram: rk3399: Order tsel variables > ram: rk3399: Add phy pctrl reset support > ram: rk3399: Move pwrup_srefresh_exit to dram_info > ram: rk3399: Add pctl start support > ram: rockchip: rk3399: Add cap_info structure > ram: rk3399: s/rk3399_base_params/sdram_base_params > ram: rk3399: Move common sdram structures in common header > arm: include: rockchip: Move dramtypes to common header > arm: include: rockchip: Add DDR4 enum > ram: rockchip: Add initial Kconfig > debug_uart: Add printdec > ram: rockchip: Add debug sdram driver > ram: rockchip: debug: Add sdram_print_ddr_info > ram: rockchip: debug: Get the cs capacity > ram: rk3399: debug: Add sdram_print_stride > ram: rk3399: Compute stride for 2 channels > ram: rk3399: Compute stride for 1 channel a > ram: rk3399: Add rank detection support > ram: rk3399: Enable sdram debug functions > rockchip: dts: rk3399: nanopi-neo4: Use DDR3-1866 dtsi > clk: rockchip: rk3399: Fix check patch warnings and checks > clk: rockchip: rk3399: Set 50MHz ddr clock > clk: rockchip: rk3399: Set 400MHz ddr clock > ram: rk3399: Add spaces in pctl_cfg > ram: rk3399: Configure phy IO in ds odt > ram: rk3399: Add lpddr4 rank mask for cs training > ram: rk3399: Add lpddr4 rank mask for wdql training > ram: rk3399: Move mode_sel assignment > ram: rk3399: Don't wait for PLL lock in lpddr4 > ram: rk3399: Avoid two channel ZQ Cal Start at the same time > ram: rk3399: Configure PHY_898, PHY_919 for lpddr4 > ram: rk3399: Configure BOOSTP_EN, BOOSTN_EN for lpddr4 > ram: rk3399: Configure SLEWP_EN, SLEWN_EN for lpddr4 > ram: rk3399: Configure PHY RX_CM_INPUT for lpddr4 > ram: rk3399: Map chipselect for lpddr4 > ram: rk3399: Configure tsel write ca for lpddr4 > ram: rk3399: Don't disable dfi dram clk for lpddr4, rank 1 > ram: rk3399: Add IO settings > ram: sdram: Configure lpddr4 tsel rd, wr based on IO settings > ram: rk3399: Add tsel control clock drive > ram: rk3399: Configure soc odt support > ram: rk3399: Get lpddr4 tsel_rd_en from io settings > ram: rk3399: Update lpddr4 vref based on io settings > ram: rk3399: Update lpddr4 mode_sel based on io settings > ram: rk3399: Update lpddr4 vref_mode_ac > ram: rk3399: Add LPPDR4 mr detection > arm: i
Re: [U-Boot] [PATCH 00/92] ram: rk3399: Add LPDDR4 support
> On 11.06.2019, at 17:03, Jagan Teki wrote: > > On Tue, Jun 11, 2019 at 8:23 PM Philipp Tomsich > wrote: >> >> >> >>> On 11.06.2019, at 16:50, Jagan Teki wrote: >>> >>> Yes, it can be possible to break this series into multiple sub series >>> but idea here is to mark all the required changes to support LPDDR4 >>> in rk3399 in one set. if required we can break it from next versions. >>> >>> This is the initial set for supporting LPDDR4 with associated >>> features. >>> >>> Thanks to >>> - YouMin Chen >>> - Akash Gajjar >>> - Kever Yang >>> for supporting all the help on this work. >>> >>> On summary this series support >>> - Code warning and fixes >>> - rank detection, this would required to probe single channel >>> sdram configured in NanoPI-NEO4 >>> - LPDDR4 support, tested in Rockpro64 and Rock-PI-4 >>> >>> patch 0001 - 0033: fix code warnings, prints, new macros >>> >>> patch 0034 - 0051: rank detection, sdram debug code >>> >>> patch 0052: Use DDR3-1800 on NanoPI-NEO4 >>> >>> patch 0053 - 0089: lpddr4 support >>> >>> patch 0090: LPDDR4-100 timings >>> >>> patch 0091: Use LPDDR4-100 on Rockpro64 >>> >>> patch 0092: Use LPDDR4-100 on Rock-PI 4 >>> >>> Note: Puma rk3399 has SPL size overflow, better to enable TPL >>> for this board. >> >> We need to keep Puma on a SPL-only configuration for the time being. >> Please make sure that the LPDDR4 code is an optional feature that does not >> increase the DRAM-driver size for boards that don’t need/want it. > > We have few boards do have TPL-runnable, would be any technical issue > to switch puma to TPL? because we have lpddr4 code part of existing > driver itself and it require extra ifdef to consider which indeed look > awful from code point-of-view. Our secure boot process (i.e. signing tools) currently depends on this and the changeover won’t be quick… Thanks, Philipp. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Bring tinker-rk3288 back into SPL size limit?
+Kever. > On 08.06.2019, at 20:05, Tom Rini wrote: > > Hey, > > With Heinrich's series to enforce a size limit on SPL and Simon > Goldschmidt's enhancements on top of that, we're now seeing that > tinker-rk3288 has an SPL that is too large to function. And it's now > also causing the build to fail. So, good that we're catching this at > least. Can you please look into what we need to do to get the image to > fit within the size constraints? Thanks! > > -- > Tom ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH v7 00/11] rockchip: Add new rk3399 boards
Jagan, > On 09.05.2019, at 14:36, Jagan Teki wrote: > > On Thu, May 9, 2019 at 6:01 PM Paul Kocialkowski > mailto:paul.kocialkow...@bootlin.com>> wrote: >> >> Hi, >> >> On Thu, 2019-05-09 at 16:15 +0530, Jagan Teki wrote: >>> Hi Paul, >>> >>> On Thu, May 9, 2019 at 12:38 PM Paul Kocialkowski >>> wrote: Hi, On Wed, 2019-05-08 at 11:11 +0530, Jagan Teki wrote: > (Sorry for the noice, I have missed to send two patches from v7) > > This is v7 resend patchset for New rk3399 boards support wrt previous > version[1] > > Unfortunately initial version of creating rk3399-u-boot.dtsi and > orangepi rk3399 changes are merged, so this is rework on top of > u-boot-rockchip/master. > > Overall this series add support below rk3399 boards > - NanoPI M4 > - NanoPC T4 > - NanoPI NEO4 > - Orangepi RK3399 > - Rock PI 4 > - Rockpro64 > > All the respective dts(i) files are synced from Linux 5.1-rc2 and few > dts(i) from linux-next. > > SoC u-boot specific dtsi rk3399-u-boot.dtsi changes are part of another > series [3]. > > Out of all above boards Rockpor64, Rock-PI and Nanopi NEO4 would support > booting via Rockchip miniloader as of now. Could you send these two boards in a separate series so that we avoid merging them for now (because SPL support is broken) and then re- iterate the series later with the DDR bringup? Or maybe find a way to disable SPL support, but in any case, it's not ok to merge a board with SPL enabled and broken. >>> >>> I have explained the details about this concern on v2 [1], thought you >>> would comeback on the same line instead here. >> >> Yes, you have already explained the issue, but I don't think it's >> enough a justification to merge broken SPL support. If it was only >> partial or limited, it would be fine, but here it's just broken. >> >>> Anyway, making SPL as an optional is not an idea to go with Mainline >>> as we make many decisions with regards to make SPL is mandatory. >> >> Yes I think making SPL mandatory is a good idea, so that's why I'm >> suggesting that we don't merge the boards until they have SPL support. >> >>> Since the DDR is show stopper here (and it would really need a good >>> amount of time, since it effect the other boards), I can go with TPL >>> enabled boot-chain where ddr bin, SPL and U-Boot proper can be part of >>> booting stages. This way we can avoid skipping SPL usage, and many >>> config changes to make SPL optional. >> >> Honestly I don't really see the point of merging these boards at all if >> they don't have SPL support. People who really want to use them with >> the rockchip blob can cherry-pick the patches from the list in the >> meantime. >> >> It also creates incentive for people to free the DDR init, since that >> becomes a condition to have the board upstream. >> >> What do you think? > > I don't know whether you get my point or not? these boards are not > merged yet. What I'm saying is we are going to support them with > TPL-enabled, that was SPL can make use of these boards which still a > valid boot-chain. moreover this way can avoid touching core files and > no specific change require while supporting ddr dtsi. On some boards, there will be no TPL and only a SPL stage that will initialise DRAM (as the move to having TPL on the RK3399 is optional). I agree with Paul that the DRAM init should be part of U-Boot whenever we add new boards and make an open DRAM init a prerequisite. Thanks, Philipp. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PULL, RESEND] Please pull u-boot-rockchip/tags/rockchip-for-2019.07
Tom, [resend due to me forgetting to CC the mailing-list] Here’s the first batch of changes for the Rockchip side of the repository. Took a bit longer as expected as there always was ‘one more issue’ to fix up during the merge… Clean bill-of-health in Travis-CI at https://travis-ci.org/ptomsich/u-boot-rockchip/builds/526773500 Thanks, Philipp. The following changes since commit a69120a0d7c8d4044cdaceea9eb03913ba4e49c7: Prepare v2019.07-rc1 (2019-04-29 21:54:04 -0400) are available in the git repository at: git://git.denx.de/u-boot-rockchip.git tags/rockchip-for-2019.07 for you to fetch changes up to dd320e122f78312b99cdbfb085a0ad167a396bb5: rockchip: rk3288: include header for back_to_bootrom (2019-05-01 09:40:59 +0200) Improvements and new features: - improved SPI driver for better read throughput - refactors initialisation of debug UART init - restructures header file paths - adds pinctrl improvements Adds Kever as a co-custodian. Jagan Teki (3): rockchip: dts: rk3399: Sync rk3399-opp from Linux rockchip: dts: rk3399: Create initial rk3399-u-boot.dtsi rockchip: rk3399: Add Orangepi RK3399 support Kever Yang (15): rockchip: arm: remove no use macro rockchip: add Kever Yang as co-custodian rockchip: arm: use 'arch-rockchip' for common header rockchip: use 'arch-rockchip' as header file path rockchip: correct ARCH_SOC name rockchip: enable DEBUG_UART_BOARD_INIT by default rockchip; kylin-rk3036: enabl DEBUG UART rockchip: rk3036: add board_debug_uart_init() rockchip: rk3188: add board_debug_uart_init() rockchip: rk322x: move board_debug_uart_init() to rk322x.c rockchip: rk3288: use grf structure to access soc_con2 rockchip: rk3288: add board_debug_uart_init() rockchip: rk3368: move board_debug_uart_init() to rk3368.c rockchip: rk3399: use grf structure to access reg rockchip: rk3399: add board_debug_uart_init() Philipp Tomsich (11): rockchip: rk3399-puma: support Gigadevice SPI-NOR flash rockchip: spi: add debug message for delay in CS toggle rockchip: spi: remove unused code and fields in priv rockchip: spi: fix off-by-one in chunk size computation rockchip: spi: consistently use false/true with rkspi_enable_chip rockchip: spi: only wait for completion, if transmitting rockchip: spi: add optimised receive-only implementation rockchip: spi: add driver-data and a 'rxonly_manages_fifo' flag rockchip: spi: make optimised receive-handler unaligned-safe rockchip: rk3399: include gpio.h rockchip: rk3288: include header for back_to_bootrom Urja Rannikko (2): pinctrl: exit pinconfig_post_bind if there are no subnodes rk3288-board: remove pinctrl call for debug uart MAINTAINERS | 1 + arch/arm/Kconfig | 1 + arch/arm/cpu/armv8/start.S| 4 + arch/arm/dts/Makefile | 1 + arch/arm/dts/rk3399-evb.dts | 1 - arch/arm/dts/rk3399-firefly.dts | 1 - arch/arm/dts/rk3399-opp.dtsi | 133 +++ arch/arm/dts/rk3399-orangepi-u-boot.dtsi | 7 + arch/arm/dts/rk3399-orangepi.dts | 771 +++ arch/arm/dts/rk3399-puma.dtsi | 1 - arch/arm/dts/rk3399-u-boot.dtsi | 8 ++ arch/arm/include/asm/arch-rockchip/ddr_rk3188.h | 2 +- arch/arm/include/asm/arch-rockchip/hardware.h | 2 - arch/arm/include/asm/gpio.h | 2 +- arch/arm/lib/vectors.S| 5 +- arch/arm/mach-rockchip/Kconfig| 6 +- arch/arm/mach-rockchip/boot_mode.c| 2 +- arch/arm/mach-rockchip/bootrom.c | 4 +- arch/arm/mach-rockchip/rk3036-board-spl.c | 26 +--- arch/arm/mach-rockchip/rk3036-board.c | 10 +- arch/arm/mach-rockchip/rk3036/Kconfig | 2 +- arch/arm/mach-rockchip/rk3036/Makefile| 1 + arch/arm/mach-rockchip/rk3036/clk_rk3036.c| 4 +- arch/arm/mach-rockchip/rk3036/rk3036.c| 38 ++ arch/arm/mach-rockchip/rk3036/sdram_rk3036.c | 12 +- arch/arm/mach-rockchip/rk3036/syscon_rk3036.c | 2 +- arch/arm/mach-rockchip/rk3128-board.c | 10 +- arch/arm/mach-rockchip/rk3128/Kconfig | 2 +- arch/arm/mach-rockchip/rk3128/clk_rk3128.c| 4 +- arch/arm/mach-rockchip/rk3128/syscon_rk3128.c | 2 +- arch/arm/mach-rockchip/rk3188-board-spl.c | 44 ++- arch/arm/mach-rockchip/rk3188-board.c | 10 +- arch/arm/mach-rockchip/rk3188/Kco
Re: [U-Boot] [PATCH 1/3] rockchip: arm: use 'arch-rockchip' for common header
> rockchip platform header file is in 'arch-rockchip' > instead of arch-$(SOC) for all SoCs. > > Signed-off-by: Kever Yang > Reviewed-by: Philipp Tomsich > --- > > arch/arm/cpu/armv8/start.S | 4 > arch/arm/include/asm/gpio.h | 2 +- > arch/arm/lib/vectors.S | 5 - > 3 files changed, 9 insertions(+), 2 deletions(-) > Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] rockchip: use 'arch-rockchip' as header file path
> Rockchip use 'arch-rockchip' instead of arch-$(SOC) as common > header file path, so that we can get the correct path directly. > > Signed-off-by: Kever Yang > Reviewed-by: Philipp Tomsich > --- > > .../include/asm/arch-rockchip/ddr_rk3188.h| 2 +- > arch/arm/mach-rockchip/Kconfig| 2 +- > arch/arm/mach-rockchip/boot_mode.c| 2 +- > arch/arm/mach-rockchip/bootrom.c | 4 ++-- > arch/arm/mach-rockchip/rk3036-board-spl.c | 12 +-- > arch/arm/mach-rockchip/rk3036-board.c | 10 +- > arch/arm/mach-rockchip/rk3036/clk_rk3036.c| 4 ++-- > arch/arm/mach-rockchip/rk3036/sdram_rk3036.c | 12 +-- > arch/arm/mach-rockchip/rk3036/syscon_rk3036.c | 2 +- > arch/arm/mach-rockchip/rk3128-board.c | 10 +- > arch/arm/mach-rockchip/rk3128/clk_rk3128.c| 4 ++-- > arch/arm/mach-rockchip/rk3128/syscon_rk3128.c | 2 +- > arch/arm/mach-rockchip/rk3188-board-spl.c | 16 +++ > arch/arm/mach-rockchip/rk3188-board.c | 10 +- > arch/arm/mach-rockchip/rk3188/clk_rk3188.c| 4 ++-- > arch/arm/mach-rockchip/rk3188/syscon_rk3188.c | 2 +- > arch/arm/mach-rockchip/rk322x-board-spl.c | 12 +-- > arch/arm/mach-rockchip/rk322x-board.c | 10 +- > arch/arm/mach-rockchip/rk322x/clk_rk322x.c| 4 ++-- > arch/arm/mach-rockchip/rk322x/syscon_rk322x.c | 2 +- > arch/arm/mach-rockchip/rk3288-board-spl.c | 20 +-- > arch/arm/mach-rockchip/rk3288-board-tpl.c | 14 ++--- > arch/arm/mach-rockchip/rk3288-board.c | 12 +-- > arch/arm/mach-rockchip/rk3288/clk_rk3288.c| 4 ++-- > arch/arm/mach-rockchip/rk3288/rk3288.c| 2 +- > arch/arm/mach-rockchip/rk3288/syscon_rk3288.c | 2 +- > arch/arm/mach-rockchip/rk3328/clk_rk3328.c| 4 ++-- > arch/arm/mach-rockchip/rk3328/rk3328.c| 2 +- > arch/arm/mach-rockchip/rk3328/syscon_rk3328.c | 2 +- > arch/arm/mach-rockchip/rk3368-board-spl.c | 10 +- > arch/arm/mach-rockchip/rk3368-board-tpl.c | 12 +-- > arch/arm/mach-rockchip/rk3368/clk_rk3368.c| 4 ++-- > arch/arm/mach-rockchip/rk3368/rk3368.c| 6 +++--- > arch/arm/mach-rockchip/rk3368/syscon_rk3368.c | 2 +- > arch/arm/mach-rockchip/rk3399-board-spl.c | 12 +-- > arch/arm/mach-rockchip/rk3399-board.c | 2 +- > arch/arm/mach-rockchip/rk3399/clk_rk3399.c| 4 ++-- > arch/arm/mach-rockchip/rk3399/rk3399.c| 2 +- > arch/arm/mach-rockchip/rk3399/syscon_rk3399.c | 2 +- > arch/arm/mach-rockchip/rk_timer.c | 2 +- > arch/arm/mach-rockchip/rv1108/clk_rv1108.c| 4 ++-- > arch/arm/mach-rockchip/rv1108/syscon_rv1108.c | 2 +- > arch/arm/mach-rockchip/sdram_common.c | 2 +- > board/elgin/elgin_rv1108/elgin_rv1108.c | 4 ++-- > board/rockchip/evb_rk3036/evb_rk3036.c| 4 ++-- > board/rockchip/evb_rk3229/evb_rk3229.c| 2 +- > board/rockchip/evb_rk3399/evb-rk3399.c| 2 +- > board/rockchip/evb_rv1108/evb_rv1108.c| 4 ++-- > board/rockchip/kylin_rk3036/kylin_rk3036.c| 4 ++-- > board/rockchip/sheep_rk3368/sheep_rk3368.c| 4 ++-- > .../lion_rk3368/lion_rk3368.c | 6 +++--- > .../puma_rk3399/puma-rk3399.c | 10 +- > board/vamrs/rock960_rk3399/rock960-rk3399.c | 2 +- > cmd/rockusb.c | 2 +- > drivers/clk/rockchip/clk_rk3036.c | 6 +++--- > drivers/clk/rockchip/clk_rk3128.c | 6 +++--- > drivers/clk/rockchip/clk_rk3188.c | 8 > drivers/clk/rockchip/clk_rk322x.c | 6 +++--- > drivers/clk/rockchip/clk_rk3288.c | 8 > drivers/clk/rockchip/clk_rk3328.c | 8 > drivers/clk/rockchip/clk_rk3368.c | 6 +++--- > drivers/clk/rockchip/clk_rk3399.c | 6 +++--- > drivers/clk/rockchip/clk_rv1108.c | 6 +++--- > drivers/gpio/rk_gpio.c| 3 ++- > drivers/i2c/rk_i2c.c | 6 +++--- > drivers/mmc/rockchip_dw_mmc.c | 4 ++-- > drivers/net/gmac_rockchip.c | 18 - > drivers/pwm/rk_pwm.c | 2 +- > drivers/ram/rockchip/dmc-rk3368.c | 12 +-- > drivers/ram/rockchip/sdram_rk3128.c | 6 +++--- > drivers/ram/rockchip/sdram_rk3188.c | 14 ++--- > drivers/ram/rockchip/sdram_rk322x.c | 16 +++ > drivers/ram/rockchip/sdram_rk3288.c | 14 ++--- > drivers/ram/rockchip/sdram_rk3328.c | 6 +++--- > d
Re: [U-Boot] [PATCH 3/3] rockchip: correct ARCH_SOC name
> The ARCH_SOC name default as 'rockchip' and we put all the > header file in 'arch/arm/include/asm/arch-rockchip/', but > the 'rockchip' is not the SOC name, let's correct it after > we update all the source file. > > Signed-off-by: Kever Yang > Reviewed-by: Philipp Tomsiich > --- > > arch/arm/mach-rockchip/rk3036/Kconfig | 2 +- > arch/arm/mach-rockchip/rk3128/Kconfig | 2 +- > arch/arm/mach-rockchip/rk3188/Kconfig | 2 +- > arch/arm/mach-rockchip/rk322x/Kconfig | 2 +- > arch/arm/mach-rockchip/rk3288/Kconfig | 2 +- > arch/arm/mach-rockchip/rk3328/Kconfig | 2 +- > arch/arm/mach-rockchip/rk3368/Kconfig | 2 +- > arch/arm/mach-rockchip/rk3399/Kconfig | 2 +- > arch/arm/mach-rockchip/rv1108/Kconfig | 2 +- > 9 files changed, 9 insertions(+), 9 deletions(-) > Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 09/10] rockchip: rk3399: use grf structure to access reg
> Prefer to use structure to access register if we could. > > Signed-off-by: Kever Yang > Reviewed-by: Philipp Tomsich > Tested-by: Andy Yan > --- > > arch/arm/mach-rockchip/rk3399/rk3399.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 07/10] rockchip: rk3288: add board_debug_uart_init()
> Use board_debug_uart_init() for UART iomux init instead of > do it in board_init_f, and move the function to soc file so > that we can find all the soc/board setting in soc file and > use a common board file for all rockchip SoCs later. > > Signed-off-by: Kever Yang > Reviewed-by: Philipp Tomsich > --- > > arch/arm/mach-rockchip/rk3288-board-spl.c | 12 ++-- > arch/arm/mach-rockchip/rk3288-board-tpl.c | 16 ++-- > arch/arm/mach-rockchip/rk3288/rk3288.c| 13 + > 3 files changed, 17 insertions(+), 24 deletions(-) > Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 03/10] rockchip: rk3036: add board_debug_uart_init()
> Use board_debug_uart_init() for UART iomux init instead of > do it in board_init_f, and move the function to soc file so > that we can find all the soc/board setting in soc file and > use a common board file. > > Signed-off-by: Kever Yang > Reviewed-by: Philipp Tomsich > --- > > arch/arm/mach-rockchip/rk3036-board-spl.c | 20 +--- > arch/arm/mach-rockchip/rk3036/Makefile| 1 + > arch/arm/mach-rockchip/rk3036/rk3036.c| 39 +++ > 3 files changed, 41 insertions(+), 19 deletions(-) > create mode 100644 arch/arm/mach-rockchip/rk3036/rk3036.c > Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 10/10] rockchip: rk3399: add board_debug_uart_init()
> Use board_debug_uart_init() for UART iomux init instead of > do it in board_init_f, and move the function to soc file so > that we can find all the soc/board setting in soc file and > use a common board file for all rockchip SoCs later. > > Signed-off-by: Kever Yang > Reviewed-by: Philipp Tomsich > --- > > arch/arm/mach-rockchip/rk3399-board-spl.c | 50 +-- > arch/arm/mach-rockchip/rk3399/rk3399.c| 50 +++ > 2 files changed, 51 insertions(+), 49 deletions(-) > Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 08/10] rockchip: rk3368: move board_debug_uart_init() to rk3368.c
> Move the function to soc file so > that we can find all the soc/board setting in soc file and > use a common board file later for all rockchip SoCs. > > Signed-off-by: Kever Yang > Reviewed-by: Philipp Tomsich > Tested-by: Andy Yan > --- > > arch/arm/mach-rockchip/rk3368-board-spl.c | 8 -- > arch/arm/mach-rockchip/rk3368-board-tpl.c | 33 +-- > arch/arm/mach-rockchip/rk3368/rk3368.c| 31 + > 3 files changed, 32 insertions(+), 40 deletions(-) > Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 06/10] rockchip: rk3288: use grf structure to access soc_con2
> Prefer to use structure to access register if we can. > > Signed-off-by: Kever Yang > Reviewed-by: Philipp Tomsich > --- > > arch/arm/mach-rockchip/rk3288/rk3288.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 05/10] rockchip: rk322x: move board_debug_uart_init() to rk322x.c
> Move the function to soc file so > that we can find all the soc/board setting in soc file and > use a common board file later for all rockchip SoCs. > > Signed-off-by: Kever Yang > Reviewed-by: Philipp Tomsich > --- > > arch/arm/mach-rockchip/rk322x-board-spl.c | 44 ++- > arch/arm/mach-rockchip/rk322x-board.c | 30 +--- > arch/arm/mach-rockchip/rk322x/Makefile| 2 +- > arch/arm/mach-rockchip/rk322x/rk322x.c| 44 +++ > 4 files changed, 48 insertions(+), 72 deletions(-) > create mode 100644 arch/arm/mach-rockchip/rk322x/rk322x.c > Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 04/10] rockchip: rk3188: add board_debug_uart_init()
> Use board_debug_uart_init() for UART iomux init instead of > do it in board_init_f, and move the function to soc file so > that we can find all the soc/board setting in soc file and > use a common board file. > > Signed-off-by: Kever Yang > Reviewed-by: Philipp Tomsich > --- > > arch/arm/mach-rockchip/rk3188-board-spl.c | 28 +- > arch/arm/mach-rockchip/rk3188/Makefile| 1 + > arch/arm/mach-rockchip/rk3188/rk3188.c| 36 +++ > 3 files changed, 38 insertions(+), 27 deletions(-) > create mode 100644 arch/arm/mach-rockchip/rk3188/rk3188.c > Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 02/10] rockchip; kylin-rk3036: enabl DEBUG UART
> Enable debug uart for kylin board in defconfig. > > Signed-off-by: Kever Yang > Reviewed-by: Philipp Tomsich > --- > > configs/kylin-rk3036_defconfig | 4 > 1 file changed, 4 insertions(+) > Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/10] rockchip: enable DEBUG_UART_BOARD_INIT by default
> All Rockchip SoCs use DEBUG_UART_BOARD_INIT to init per board > UART IOMUX, enable it by default. > > Signed-off-by: Kever Yang > Reviewed-by: Philipp Tomsich > --- > > arch/arm/Kconfig | 1 + > arch/arm/mach-rockchip/Kconfig | 4 > 2 files changed, 1 insertion(+), 4 deletions(-) > Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] rockchip: use 'arch-rockchip' as header file path
+-- > drivers/reset/reset-rockchip.c| 2 +- > drivers/serial/serial_rockchip.c | 2 +- > drivers/sound/rockchip_sound.c| 2 +- > drivers/spi/rk_spi.c | 4 ++-- > drivers/sysreset/sysreset_rockchip.c | 6 +++--- > drivers/timer/rockchip_timer.c| 2 +- > drivers/usb/gadget/f_rockusb.c| 2 +- > drivers/video/rockchip/rk3288_hdmi.c | 6 +++--- > drivers/video/rockchip/rk3288_mipi.c | 10 +- > drivers/video/rockchip/rk3288_vop.c | 6 +++--- > drivers/video/rockchip/rk3399_hdmi.c | 6 +++--- > drivers/video/rockchip/rk3399_mipi.c | 10 +- > drivers/video/rockchip/rk3399_vop.c | 2 +- > drivers/video/rockchip/rk_edp.c | 6 +++--- > drivers/video/rockchip/rk_hdmi.c | 5 ++--- > drivers/video/rockchip/rk_lvds.c | 6 +++--- > drivers/video/rockchip/rk_mipi.c | 9 - > drivers/video/rockchip/rk_vop.c | 7 +++ > drivers/video/rockchip/rk_vop.h | 2 +- > include/configs/rk3036_common.h | 2 +- > include/configs/rk3188_common.h | 2 +- > include/configs/rk322x_common.h | 2 +- > include/configs/rk3288_common.h | 2 +- > include/configs/rk3368_common.h | 2 +- > include/configs/rv1108_common.h | 2 +- > 100 files changed, 288 insertions(+), 290 deletions(-) > Reviewed-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
