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] 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 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 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] 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] 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/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: [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 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 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 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: [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 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 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 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 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 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: [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: [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 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] 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 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 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] 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 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 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: [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 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 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 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 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 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: [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
>
[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
[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 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
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
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 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 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: [U-Boot] [Status] [U-boot] [PATCH v4 0/7] Add ethernet support for phyCORE-RK3288
I had asked for these to be split out as a separate series and rebased. Might have been v3 that I replied to, though… Thanks, Philipp. > On 23.11.2018, at 14:13, Janine Hagemann wrote: > > Hello, > > I just want to ask what happened to some of my patches from august 2018. > > https://patchwork.ozlabs.org/patch/962733/ > https://patchwork.ozlabs.org/patch/962736/ > https://patchwork.ozlabs.org/patch/962742/ > https://patchwork.ozlabs.org/patch/962735/ > > Should I send them again? > > > Kind regards > > Janine Hagemann > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers: regulator: regulator-uclass: disallow disable of always-on
> On 22.11.2018, at 22:12, Richard Röjfors wrote: > > It does not make sense to allow disable of a regulator that > is defined always on. > > I found this because the new mmc code that tests if the mmc > power can be switched off. That results in the rk3288 > firefly board to die since the regulator, which is always-on, > is shared with more than just mmc. > > Signed-off-by: Richard Röjfors Reviewed-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] lib: merge CRC16-CCITT into u-boot/crc.h
This merges the CRC16-CCITT headers into u-boot/crc.h to prepare for
rolling CRC16 into the hash infrastructure. Given that CRC8, CRC32
and CRC32-C already have their prototypes in a single header file, it
seems a good idea to also include CRC16-CCITT in the same.
Signed-off-by: Philipp Tomsich
---
board/8dtech/eco5pk/eco5pk.c | 2 +-
board/armadeus/apf27/apf27.c | 2 +-
board/sunxi/board.c | 2 +-
common/xyzModem.c| 2 +-
drivers/mmc/mmc_spi.c| 2 +-
drivers/net/phy/aquantia.c | 2 +-
include/crc.h| 43 ---
include/u-boot/crc.h | 3 +++
lib/crc16.c | 2 +-
9 files changed, 10 insertions(+), 50 deletions(-)
delete mode 100644 include/crc.h
diff --git a/board/8dtech/eco5pk/eco5pk.c b/board/8dtech/eco5pk/eco5pk.c
index e05928f..dcbd483 100644
--- a/board/8dtech/eco5pk/eco5pk.c
+++ b/board/8dtech/eco5pk/eco5pk.c
@@ -16,7 +16,7 @@
#include
#include
#include
-#include
+#include
#include
#include "eco5pk.h"
diff --git a/board/armadeus/apf27/apf27.c b/board/armadeus/apf27/apf27.c
index 0f0c8a4..bf2586d 100644
--- a/board/armadeus/apf27/apf27.c
+++ b/board/armadeus/apf27/apf27.c
@@ -16,8 +16,8 @@
#include
#include
#include
+#include
#include "apf27.h"
-#include "crc.h"
#include "fpga.h"
DECLARE_GLOBAL_DATA_PTR;
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 64ccbc7..a2254fd 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -28,7 +28,7 @@
#endif
#include
#include
-#include
+#include
#include
#include
#include
diff --git a/common/xyzModem.c b/common/xyzModem.c
index 830fca8..e5c65b4 100644
--- a/common/xyzModem.c
+++ b/common/xyzModem.c
@@ -24,7 +24,7 @@
#include
#include
#include
-#include
+#include
/* Assumption - run xyzModem protocol over the console port */
diff --git a/drivers/mmc/mmc_spi.c b/drivers/mmc/mmc_spi.c
index a9d95fb..4f57990 100644
--- a/drivers/mmc/mmc_spi.c
+++ b/drivers/mmc/mmc_spi.c
@@ -10,7 +10,7 @@
#include
#include
#include
-#include
+#include
#include
#include
diff --git a/drivers/net/phy/aquantia.c b/drivers/net/phy/aquantia.c
index 37749e0..a0abb23 100644
--- a/drivers/net/phy/aquantia.c
+++ b/drivers/net/phy/aquantia.c
@@ -8,7 +8,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
diff --git a/include/crc.h b/include/crc.h
deleted file mode 100644
index 2a00af5..000
--- a/include/crc.h
+++ /dev/null
@@ -1,43 +0,0 @@
-/* SPDX-License-Identifier: eCos-2.0 */
-/*
- *==
- *
- * crc.h
- *
- * Interface for the CRC algorithms.
- *
- *==
- *==
- *#DESCRIPTIONBEGIN
- *
- * Author(s):Andrew Lunn
- * Contributors: Andrew Lunn
- * Date: 2002-08-06
- * Purpose:
- * Description:
- *
- * This code is part of eCos (tm).
- *
- *DESCRIPTIONEND
- *
- *==
- */
-
-#ifndef _SERVICES_CRC_CRC_H_
-#define _SERVICES_CRC_CRC_H_
-
-#include
-
-#ifndef __externC
-# ifdef __cplusplus
-# define __externC extern "C"
-# else
-# define __externC extern
-# endif
-#endif
-
-/* 16 bit CRC with polynomial x^16+x^12+x^5+1 (CRC-CCITT) */
-
-uint16_t crc16_ccitt(uint16_t crc_start, unsigned char *s, int len);
-
-#endif /* _SERVICES_CRC_CRC_H_ */
diff --git a/include/u-boot/crc.h b/include/u-boot/crc.h
index e98cb46..111b22c 100644
--- a/include/u-boot/crc.h
+++ b/include/u-boot/crc.h
@@ -11,6 +11,9 @@
/* lib/crc8.c */
unsigned int crc8(unsigned int crc_start, const unsigned char *vptr, int len);
+/* lib/crc16.c - 16 bit CRC with polynomial x^16+x^12+x^5+1 (CRC-CCITT) */
+uint16_t crc16_ccitt(uint16_t crc_start, const unsigned char *s, int len);
+
/* lib/crc32.c */
uint32_t crc32 (uint32_t, const unsigned char *, uint);
uint32_t crc32_wd (uint32_t, const unsigned char *, uint, uint);
diff --git a/lib/crc16.c b/lib/crc16.c
index 763ae33..25bdfd8 100644
--- a/lib/crc16.c
+++ b/lib/crc16.c
@@ -22,7 +22,7 @@
*==
*/
-#include "crc.h"
+#include
/* Table of CRC constants - implements x^16+x^12+x^5+1 */
static const uint16_t crc16_tab[] = {
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] Roll CRC16-CCITT into the hash infrastructure
The CRC16-CCITT checksum function is useful for space-constrained
applications (such as obtaining a checksum across a 2KBit or 4KBit
EEPROM) in boot applications. It has not been accessible from boot
scripts until now (due to not having a dedicated command and not being
supported by the hash infrstructure) limiting its applicability
outside of custom commands.
This adds the CRC16-CCITT (poly 0x1021, init 0x0) algorithm to the
list of available hashes and adds a new crc16_ccitt_wd_buf() to make
this possible.
Signed-off-by: Philipp Tomsich
---
common/hash.c| 36
include/u-boot/crc.h | 11 +++
lib/crc16.c | 23 +--
tools/Makefile | 1 +
4 files changed, 65 insertions(+), 6 deletions(-)
diff --git a/common/hash.c b/common/hash.c
index ef14651..413a5bf 100644
--- a/common/hash.c
+++ b/common/hash.c
@@ -85,6 +85,33 @@ static int hash_finish_sha256(struct hash_algo *algo, void
*ctx, void
}
#endif
+static int hash_init_crc16_ccitt(struct hash_algo *algo, void **ctxp)
+{
+ uint16_t *ctx = malloc(sizeof(uint16_t));
+ *ctx = 0;
+ *ctxp = ctx;
+ return 0;
+}
+
+static int hash_update_crc16_ccitt(struct hash_algo *algo, void *ctx,
+ const void *buf, unsigned int size,
+ int is_last)
+{
+ *((uint16_t *)ctx) = crc16_ccitt(*((uint16_t *)ctx), buf, size);
+ return 0;
+}
+
+static int hash_finish_crc16_ccitt(struct hash_algo *algo, void *ctx,
+ void *dest_buf, int size)
+{
+ if (size < algo->digest_size)
+ return -1;
+
+ *((uint16_t *)dest_buf) = *((uint16_t *)ctx);
+ free(ctx);
+ return 0;
+}
+
static int hash_init_crc32(struct hash_algo *algo, void **ctxp)
{
uint32_t *ctx = malloc(sizeof(uint32_t));
@@ -160,6 +187,15 @@ static struct hash_algo hash_algo[] = {
},
#endif
{
+ .name = "crc16-ccitt",
+ .digest_size= 2,
+ .chunk_size = CHUNKSZ,
+ .hash_func_ws = crc16_ccitt_wd_buf,
+ .hash_init = hash_init_crc16_ccitt,
+ .hash_update= hash_update_crc16_ccitt,
+ .hash_finish= hash_finish_crc16_ccitt,
+ },
+ {
.name = "crc32",
.digest_size= 4,
.chunk_size = CHUNKSZ_CRC32,
diff --git a/include/u-boot/crc.h b/include/u-boot/crc.h
index 111b22c..788ef29 100644
--- a/include/u-boot/crc.h
+++ b/include/u-boot/crc.h
@@ -13,6 +13,17 @@ unsigned int crc8(unsigned int crc_start, const unsigned
char *vptr, int len);
/* lib/crc16.c - 16 bit CRC with polynomial x^16+x^12+x^5+1 (CRC-CCITT) */
uint16_t crc16_ccitt(uint16_t crc_start, const unsigned char *s, int len);
+/**
+ * crc16_ccitt_wd_buf - Perform CRC16-CCIT on an input buffer and return the
+ * 16-bit result (network byte-order) in an output buffer
+ *
+ * @in:input buffer
+ * @len: input buffer length
+ * @out: output buffer (at least 2 bytes)
+ * @chunk_sz: ignored
+ */
+void crc16_ccitt_wd_buf(const uint8_t *in, uint len,
+ uint8_t *out, uint chunk_sz);
/* lib/crc32.c */
uint32_t crc32 (uint32_t, const unsigned char *, uint);
diff --git a/lib/crc16.c b/lib/crc16.c
index 25bdfd8..f46ba72 100644
--- a/lib/crc16.c
+++ b/lib/crc16.c
@@ -22,6 +22,11 @@
*==
*/
+#ifdef USE_HOSTCC
+#include
+#else
+#include
+#endif
#include
/* Table of CRC constants - implements x^16+x^12+x^5+1 */
@@ -60,14 +65,20 @@ static const uint16_t crc16_tab[] = {
0x6e17, 0x7e36, 0x4e55, 0x5e74, 0x2e93, 0x3eb2, 0x0ed1, 0x1ef0,
};
-uint16_t crc16_ccitt(uint16_t crc_start, unsigned char *buf, int len)
+uint16_t crc16_ccitt(uint16_t cksum, const unsigned char *buf, int len)
{
- int i;
- uint16_t cksum;
-
- cksum = crc_start;
- for (i = 0; i < len; i++)
+ for (int i = 0; i < len; i++)
cksum = crc16_tab[((cksum>>8) ^ *buf++) & 0xff] ^ (cksum << 8);
return cksum;
}
+
+void crc16_ccitt_wd_buf(const uint8_t *in, uint len,
+ uint8_t *out, uint chunk_sz)
+{
+ uint16_t crc;
+
+ crc = crc16_ccitt(0, in, len);
+ crc = htons(crc);
+ memcpy(out, &crc, sizeof(crc));
+}
diff --git a/tools/Makefile b/tools/Makefile
index 3c0521f..a338705 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -106,6 +106,7 @@ dumpimage-mkimage-objs := aisimage.o \
stm32image.o \
$(ROCKCHIP_OBS) \
socfpgaimage.o \
+ lib/crc16.o \
lib/sha1.o \
lib/sha256.o \
common/hash.o \
--
2.1.
[U-Boot] [PATCH] dm: rtc: Fix function name in comment
The documentation comment for dm_rtc_set was referring to dm_rtc_put
instead. Fix it.
Signed-off-by: Philipp Tomsich
---
include/rtc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/rtc.h b/include/rtc.h
index 0d964d5..2c3a574 100644
--- a/include/rtc.h
+++ b/include/rtc.h
@@ -86,7 +86,7 @@ struct rtc_ops {
int dm_rtc_get(struct udevice *dev, struct rtc_time *time);
/**
- * dm_rtc_put() - Write a time to an RTC
+ * dm_rtc_set() - Write a time to an RTC
*
* @dev: Device to read from
* @time: Time to write into the RTC
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] dm: (re)sort uclass ids alphabetically
The comment in uclass-id.h states that
"U-Boot uclasses start here - in alphabetical order"
but the subsequent list is not sorted alphabetically.
This reestablishes order.
Signed-off-by: Philipp Tomsich
---
include/dm/uclass-id.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
index c91dca1..aad5d26 100644
--- a/include/dm/uclass-id.h
+++ b/include/dm/uclass-id.h
@@ -29,6 +29,7 @@ enum uclass_id {
/* U-Boot uclasses start here - in alphabetical order */
UCLASS_ADC, /* Analog-to-digital converter */
UCLASS_AHCI,/* SATA disk controller */
+ UCLASS_AXI, /* AXI bus */
UCLASS_BLK, /* Block device */
UCLASS_BOARD, /* Device information from hardware */
UCLASS_CLK, /* Clock source, e.g. used by peripherals */
@@ -38,15 +39,14 @@ enum uclass_id {
UCLASS_DMA, /* Direct Memory Access */
UCLASS_EFI, /* EFI managed devices */
UCLASS_ETH, /* Ethernet device */
+ UCLASS_FIRMWARE,/* Firmware */
UCLASS_FS_FIRMWARE_LOADER, /* Generic loader */
UCLASS_GPIO,/* Bank of general-purpose I/O pins */
- UCLASS_FIRMWARE,/* Firmware */
UCLASS_I2C, /* I2C bus */
UCLASS_I2C_EEPROM, /* I2C EEPROM device */
UCLASS_I2C_GENERIC, /* Generic I2C device */
UCLASS_I2C_MUX, /* I2C multiplexer */
UCLASS_IDE, /* IDE device */
- UCLASS_AXI, /* AXI bus */
UCLASS_IRQ, /* Interrupt controller */
UCLASS_KEYBOARD,/* Keyboard input device */
UCLASS_LED, /* Light-emitting diode (LED) */
@@ -68,8 +68,8 @@ enum uclass_id {
UCLASS_PINCONFIG, /* Pin configuration node device */
UCLASS_PINCTRL, /* Pinctrl (pin muxing/configuration) device */
UCLASS_PMIC,/* PMIC I/O device */
- UCLASS_PWM, /* Pulse-width modulator */
UCLASS_POWER_DOMAIN,/* (SoC) Power domains */
+ UCLASS_PWM, /* Pulse-width modulator */
UCLASS_PWRSEQ, /* Power sequence device */
UCLASS_RAM, /* RAM controller */
UCLASS_REGULATOR, /* Regulator device */
@@ -80,9 +80,9 @@ enum uclass_id {
UCLASS_SERIAL, /* Serial UART */
UCLASS_SMEM,/* Shared memory interface */
UCLASS_SPI, /* SPI bus */
- UCLASS_SPMI,/* System Power Management Interface bus */
UCLASS_SPI_FLASH, /* SPI flash */
UCLASS_SPI_GENERIC, /* Generic SPI flash target */
+ UCLASS_SPMI,/* System Power Management Interface bus */
UCLASS_SYSCON, /* System configuration device */
UCLASS_SYSRESET,/* System reset device */
UCLASS_TEE, /* Trusted Execution Environment device */
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] clk: Allow clock defaults to be set during re-reloc state for SPL only
In commit e5e06b65ad65 ("clk: Allow clock defaults to be set also
during re-reloc state") the earlier guard against setting clock
defaults in pre-reloc state was removed. While it is easy to filter
'assigned-clocks' properties for SPL using CONFIG_OF_SPL_REMOVE_PROPS,
no such mechanism exists for the pre-reloc stage of the full U-Boot.
With the default defconfig for the RK3399-Q7 (which filter the
'assigned-clocks' property for the DTS used by SPL anyway), this
caused a pause during startup of the full U-Boot stage that lasted for
almost 10s (due to the CPU not having been clocked up yet).
This reintroduces the guard from commit f4fcba5c5baa ("clk: Allow
clock defaults to be set also during re-reloc state") and extends it
to only apply outside of a TPL/SPL build: i.e. clk_set_defaults will
now run in pre-reloc state for SPL, but only after reloc for the full
U-Boot.
References: commit f4fcba5c5baa ("clk: implement clk_set_defaults()")
References: commit e5e06b65ad65 ("clk: Allow clock defaults to be set
also during re-reloc state")
Signed-off-by: Philipp Tomsich
---
drivers/clk/clk-uclass.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
index 04b369a..6d7a514 100644
--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -243,6 +243,10 @@ int clk_set_defaults(struct udevice *dev)
{
int ret;
+ /* If this not in SPL and pre-reloc state, don't take any action. */
+ if (!(IS_ENABLED(CONFIG_SPL_BUILD) || (gd->flags & GD_FLG_RELOC)))
+ return 0;
+
debug("%s(%s)\n", __func__, dev_read_name(dev));
ret = clk_set_default_parents(dev);
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/5] rv1108: Enable eMMC support
> On 27.11.2018, at 02:56, Andy Yan wrote: > > Hi: > > On 2018/11/27 上午12:18, Otavio Salvador wrote: >> On Tue, Nov 20, 2018 at 4:56 PM Otavio Salvador >> wrote: >>> This adds the pinctrl handles to enable the use of eMMC on custom >>> boards (as minievk) and makes it easier for later addition. >>> >>> Signed-off-by: Otavio Salvador >> Andy, did you review it? Is there someone which would be more >> appropriate for me to send the patches? > > > Thte whole series will to through Dr. Philipp Tomsich And I’ve been reading the reviews as you sent them out. Thanks for helping out on reviewing these… as I don’t have the RV1108 documentation I rely on others to provide feedback. Cheers, Philipp. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] rtc: rv3029: add to Kconfig
The MicroCrystal RV3029 driver didn't have a Kconfig entry and was not used anywhere. Add it to Kconfig to make it selectable. Signed-off-by: Philipp Tomsich Tested-by: Klaus Goger --- drivers/rtc/Kconfig | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig index bcc01b1..6038b43 100644 --- a/drivers/rtc/Kconfig +++ b/drivers/rtc/Kconfig @@ -60,6 +60,16 @@ config RTC_ISL1208 This driver supports reading and writing the RTC/calendar and detects total power failures. +config RTC_RV3029 + bool "Enable RV3029 driver" + depends on DM_RTC + help + The MicroCrystal RV3029 is a I2C Real Time Clock (RTC) with 8-byte + battery-backed SRAM. + + This driver supports reading and writing the RTC/calendar and the + battery-baced SRAM section. + config RTC_RX8010SJ bool "Enable RX8010SJ driver" depends on DM_RTC -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] rtc: rv3029: update to support DM and sync with Linux 4.17
The "Flamingo" carrier-board for the RK3399-Q7 has a RV3029 populated and the application will use the off-module RV3029 RTC including the battery backed SRAM. To support this use case, this commit includes the following changes: * updates the rv3029 driver to use DM * implements the read8/write8 operations This syncs the implementation with the Linux code (based on 4.17), porting the trickle-charger support from there (with improvements to avoid unnecessary EEPROM updates) and adheres to the Linux DTS binding. Signed-off-by: Philipp Tomsich Tested-by: Klaus Goger --- drivers/rtc/rv3029.c | 580 +-- scripts/config_whitelist.txt | 1 - 2 files changed, 443 insertions(+), 138 deletions(-) diff --git a/drivers/rtc/rv3029.c b/drivers/rtc/rv3029.c index dd4d060..38acb9c 100644 --- a/drivers/rtc/rv3029.c +++ b/drivers/rtc/rv3029.c @@ -1,189 +1,495 @@ // SPDX-License-Identifier: GPL-2.0+ /* - * (C) Copyright 2010 - * Heiko Schocher, DENX Software Engineering, h...@denx.de + * (C) Copyright 2018 Theobroma Systems Design und Consulting GmbH + * + * Based on a the Linux rtc-rv3029c2.c driver written by: + * Gregory Hermant + * Michael Buesch */ + #include #include +#include #include #include -#define RTC_RV3029_CTRL1 0x00 -#define RTC_RV3029_CTRL1_EERE (1 << 3) - -#define RTC_RV3029_CTRL_STATUS 0x03 -#define RTC_RV3029_CTRLS_EEBUSY(1 << 7) +#define RTC_RV3029_PAGE_LEN 7 -#define RTC_RV3029_CTRL_RESET 0x04 -#define RTC_RV3029_CTRL_SYS_R (1 << 4) +/* control section */ +#define RV3029_ONOFF_CTRL 0x00 +#define RV3029_ONOFF_CTRL_WE BIT(0) +#define RV3029_ONOFF_CTRL_TE BIT(1) +#define RV3029_ONOFF_CTRL_TAR BIT(2) +#define RV3029_ONOFF_CTRL_EERE BIT(3) +#define RV3029_ONOFF_CTRL_SRON BIT(4) +#define RV3029_ONOFF_CTRL_TD0 BIT(5) +#define RV3029_ONOFF_CTRL_TD1 BIT(6) +#define RV3029_ONOFF_CTRL_CLKINT BIT(7) +#define RV3029_IRQ_CTRL0x01 +#define RV3029_IRQ_CTRL_AIEBIT(0) +#define RV3029_IRQ_CTRL_TIEBIT(1) +#define RV3029_IRQ_CTRL_V1IE BIT(2) +#define RV3029_IRQ_CTRL_V2IE BIT(3) +#define RV3029_IRQ_CTRL_SRIE BIT(4) +#define RV3029_IRQ_FLAGS 0x02 +#define RV3029_IRQ_FLAGS_AFBIT(0) +#define RV3029_IRQ_FLAGS_TFBIT(1) +#define RV3029_IRQ_FLAGS_V1IF BIT(2) +#define RV3029_IRQ_FLAGS_V2IF BIT(3) +#define RV3029_IRQ_FLAGS_SRF BIT(4) +#define RV3029_STATUS 0x03 +#define RV3029_STATUS_VLOW1BIT(2) +#define RV3029_STATUS_VLOW2BIT(3) +#define RV3029_STATUS_SR BIT(4) +#define RV3029_STATUS_PON BIT(5) +#define RV3029_STATUS_EEBUSY BIT(7) +#define RV3029_RST_CTRL0x04 +#define RV3029_RST_CTRL_SYSR BIT(4) +#define RV3029_CONTROL_SECTION_LEN 0x05 -#define RTC_RV3029_CLOCK_PAGE 0x08 -#define RTC_RV3029_PAGE_LEN7 +/* watch section */ +#define RV3029_W_SEC 0x08 +#define RV3029_W_MINUTES 0x09 +#define RV3029_W_HOURS 0x0A +#define RV3029_REG_HR_12_24BIT(6) /* 24h/12h mode */ +#define RV3029_REG_HR_PM BIT(5) /* PM/AM bit in 12h mode */ +#define RV3029_W_DATE 0x0B +#define RV3029_W_DAYS 0x0C +#define RV3029_W_MONTHS0x0D +#define RV3029_W_YEARS 0x0E -#define RV3029C2_W_SECONDS 0x00 -#define RV3029C2_W_MINUTES 0x01 -#define RV3029C2_W_HOURS 0x02 -#define RV3029C2_W_DATE0x03 -#define RV3029C2_W_DAYS0x04 -#define RV3029C2_W_MONTHS 0x05 -#define RV3029C2_W_YEARS 0x06 +/* eeprom control section */ +#define RV3029_CONTROL_E2P_EECTRL 0x30 +#define RV3029_TRICKLE_1K BIT(4) /* 1.5K resistance */ +#define RV3029_TRICKLE_5K BIT(5) /* 5K resistance */ +#define RV3029_TRICKLE_20K BIT(6) /* 20K resistance */ +#define RV3029_TRICKLE_80K BIT(7) /* 80K resistance */ +#define RV3029_TRICKLE_MASK(RV3029_TRICKLE_1K |\ +RV3029_TRICKLE_5K |\ +RV3029_TRICKLE_20K |\ +RV3029_TRICKLE_80K) +#define RV3029_TRICKLE_SHIFT 4 -#define RV3029C2_REG_HR_12_24 (1 << 6) /* 24h/12h mode */ -#define RV3029C2_REG_HR_PM (1 << 5) /* PM/AM bit in 12h mode */ -#define RTC_RV3029_EEPROM_CTRL 0x30 -#define RTC_RV3029_TRICKLE_1K (1 << 4) -#define RTC_RV3029_TRICKLE_5K (1 << 5) -#define RTC_RV3029_TRICKLE_20K (1 << 6) -#define RTC_RV3029_TRICKLE_80K (1 << 7) - -int rtc_get( struct rtc_time *tmp ) +static int rv3029_rtc_get(struct udevice *dev, struct
[U-Boot] [PATCH v2 0/2] Update RV3029 driver to DM and add DM-backed bootcount support
On one of our application-specific carrier boards, a MicroCrystal RV3029 acts as an off-module battery-backed RTC for the RK3399-Q7. The RV3029 is intended both to provide RTC services (to Linux) and to store the bootcount in its battery-backed SRAM section. To support this use-case, this series adds the following: * replaces the existing RV3029 driver by a DM-based one (note that the existing driver appears unused and didn't even have a Kconfig entry) that closely mirrors its incarnation in Linux 4.17 * adds a bootcount-method interfacing back into DM devices (implementing support for the RTC uclass as of now). Changes in v2: - changed to provide a UCLASS-based implementation, as requested by SJG in his earlier review - split off the RV3029 driver into a separate series Philipp Tomsich (2): bootcount: add uclass for bootcount bootcount: add a DM RTC backing store for bootcount doc/device-tree-bindings/chosen.txt | 30 drivers/bootcount/Kconfig| 28 +++ drivers/bootcount/Makefile | 3 ++ drivers/bootcount/bootcount-uclass.c | 93 drivers/bootcount/rtc.c | 89 ++ include/bootcount.h | 48 +++ include/dm/uclass-id.h | 1 + 7 files changed, 292 insertions(+) create mode 100644 drivers/bootcount/bootcount-uclass.c create mode 100644 drivers/bootcount/rtc.c -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] bootcount: add uclass for bootcount
The original bootcount methods do not provide an interface to DM and
rely on a static configuration for I2C devices (e.g. bus, chip-addr,
etc. are configured through defines statically). On a modern system
that exposes multiple devices in a DTS-configurable way, this is less
than optimal and a interface to DM-based devices will be desirable.
This adds a simple driver that is DM-aware and configurable via DTS.
If ambiguous (i.e. multiple bootcount-devices are present) the
/chosen/u-boot,bootcount-device property can be used to select one
bootcount device.
Initially, this provides support for the following DM devices:
* RTC devices
Signed-off-by: Philipp Tomsich
Tested-by: Klaus Goger
---
Changes in v2:
- changed to provide a UCLASS-based implementation, as requested by
SJG in his earlier review
- split off the RV3029 driver into a separate series
doc/device-tree-bindings/chosen.txt | 30
drivers/bootcount/Kconfig| 8
drivers/bootcount/Makefile | 2 +
drivers/bootcount/bootcount-uclass.c | 93
include/bootcount.h | 48 +++
include/dm/uclass-id.h | 1 +
6 files changed, 182 insertions(+)
create mode 100644 drivers/bootcount/bootcount-uclass.c
diff --git a/doc/device-tree-bindings/chosen.txt
b/doc/device-tree-bindings/chosen.txt
index 86c533a..395c950 100644
--- a/doc/device-tree-bindings/chosen.txt
+++ b/doc/device-tree-bindings/chosen.txt
@@ -42,6 +42,36 @@ Example
};
};
+u-boot,bootcount-device property
+
+
+In a DM-based system, the bootcount may be stored in a device known to
+the DM framework (e.g. in a battery-backed SRAM area within a RTC
+device) managed by a device conforming to UCLASS_BOOTCOUNT. If
+multiple such devices are present in a system concurrently, then the
+u-boot,bootcount-device property can select the preferred target.
+
+Example
+---
+/ {
+ chosen {
+ u-boot,bootcount-device = &bootcount-rv3029;
+ };
+
+ bootcount-rv3029: bootcount@0 {
+ compatible = "u-boot,bootcount-rtc";
+ rtc = &rv3029;
+ offset = <0x38>;
+ };
+
+ i2c2 {
+ rv3029: rtc@56 {
+ compatible = "mc,rv3029";
+ reg = <0x56>;
+ };
+ };
+};
+
u-boot,spl-boot-order property
--
diff --git a/drivers/bootcount/Kconfig b/drivers/bootcount/Kconfig
index 6703363..46571eb 100644
--- a/drivers/bootcount/Kconfig
+++ b/drivers/bootcount/Kconfig
@@ -70,6 +70,14 @@ config BOOTCOUNT_AT91
bool "Boot counter for Atmel AT91SAM9XE"
depends on AT91SAM9XE
+config DM_BOOTCOUNT
+bool "Boot counter in a device-model device"
+ help
+ Enables reading/writing the bootcount in a device-model based
+ backing store. If an entry in /chosen/u-boot,bootcount-device
+ exists, this will be the preferred bootcount device; otherwise
+ the first available bootcount device will be used.
+
endchoice
config BOOTCOUNT_BOOTLIMIT
diff --git a/drivers/bootcount/Makefile b/drivers/bootcount/Makefile
index 68bc006..81980b3 100644
--- a/drivers/bootcount/Makefile
+++ b/drivers/bootcount/Makefile
@@ -7,3 +7,5 @@ obj-$(CONFIG_BOOTCOUNT_RAM) += bootcount_ram.o
obj-$(CONFIG_BOOTCOUNT_ENV)+= bootcount_env.o
obj-$(CONFIG_BOOTCOUNT_I2C)+= bootcount_i2c.o
obj-$(CONFIG_BOOTCOUNT_EXT)+= bootcount_ext.o
+
+obj-$(CONFIG_DM_BOOTCOUNT) += bootcount-uclass.o
diff --git a/drivers/bootcount/bootcount-uclass.c
b/drivers/bootcount/bootcount-uclass.c
new file mode 100644
index 000..0689db7
--- /dev/null
+++ b/drivers/bootcount/bootcount-uclass.c
@@ -0,0 +1,93 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2018 Theobroma Systems Design und Consulting GmbH
+ */
+
+#include
+#include
+#include
+#include
+
+int dm_bootcount_get(struct udevice *dev, u32 *bootcount)
+{
+ struct bootcount_ops *ops = bootcount_get_ops(dev);
+
+ assert(ops);
+ if (!ops->get)
+ return -ENOSYS;
+ return ops->get(dev, bootcount);
+}
+
+int dm_bootcount_set(struct udevice *dev, const u32 bootcount)
+{
+ struct bootcount_ops *ops = bootcount_get_ops(dev);
+
+ assert(ops);
+ if (!ops->set)
+ return -ENOSYS;
+ return ops->set(dev, bootcount);
+}
+
+/* Now implement the generic default functions */
+void bootcount_store(ulong val)
+{
+ struct udevice *dev = NULL;
+ ofnode node;
+ const char *propname = "u-boot,bootcount-device";
+ int ret = -ENODEV;
+
+ /*
+* If there's a preferred bootcount device selected by the user (by
+* setting '/chosen/u-boot,bootcount-device' in the DTS), try to use
+
[U-Boot] [PATCH v2 2/2] bootcount: add a DM RTC backing store for bootcount
This implements a driver using a RTC-based backing store for the DM
bootcount implementation. The node configuring this feature will be
compatible with 'u-boot,bootcount-rtc' and the underlying RTC device
shall be reference through the property 'rtc'. An offset into the RTC
device's register space can be provided through the 'offset' property.
Tested on a RK3399-Q7 on a Flamingo carrier board using the SRAM area
of the carrier board's RV3029 RTC.
Signed-off-by: Philipp Tomsich
---
Changes in v2: None
drivers/bootcount/Kconfig | 20 +++
drivers/bootcount/Makefile | 1 +
drivers/bootcount/rtc.c| 89 ++
3 files changed, 110 insertions(+)
create mode 100644 drivers/bootcount/rtc.c
diff --git a/drivers/bootcount/Kconfig b/drivers/bootcount/Kconfig
index 46571eb..b7c29f2 100644
--- a/drivers/bootcount/Kconfig
+++ b/drivers/bootcount/Kconfig
@@ -80,6 +80,26 @@ config DM_BOOTCOUNT
endchoice
+if DM_BOOTCOUNT
+
+menu "Backing stores for device-model backed bootcount"
+config DM_BOOTCOUNT_RTC
+ bool "Support RTC devices as a backing store for bootcount"
+ depends on DM_RTC
+ help
+ Enabled reading/writing the bootcount in a DM RTC device.
+ The wrapper device is to be specified with the compatible string
+ 'u-boot,bootcount-rtc' and the 'rtc'-property (a phandle pointing
+ to the underlying RTC device) and an optional 'offset' property
+ are supported.
+
+ Accesses to the backing store are performed using the write16
+ and read16 ops of DM RTC devices.
+
+endmenu
+
+endif
+
config BOOTCOUNT_BOOTLIMIT
int "Maximum number of reboot cycles allowed"
default 0
diff --git a/drivers/bootcount/Makefile b/drivers/bootcount/Makefile
index 81980b3..f9841d8 100644
--- a/drivers/bootcount/Makefile
+++ b/drivers/bootcount/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_BOOTCOUNT_I2C) += bootcount_i2c.o
obj-$(CONFIG_BOOTCOUNT_EXT)+= bootcount_ext.o
obj-$(CONFIG_DM_BOOTCOUNT) += bootcount-uclass.o
+obj-$(CONFIG_DM_BOOTCOUNT_RTC) += rtc.o
diff --git a/drivers/bootcount/rtc.c b/drivers/bootcount/rtc.c
new file mode 100644
index 000..db89fa3
--- /dev/null
+++ b/drivers/bootcount/rtc.c
@@ -0,0 +1,89 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2018 Theobroma Systems Design und Consulting GmbH
+ */
+
+#include
+#include
+#include
+#include
+
+static const u8 bootcount_magic = 0xbc;
+
+struct bootcount_rtc_priv {
+ struct udevice *rtc;
+ u32 offset;
+};
+
+static int bootcount_rtc_set(struct udevice *dev, const u32 a)
+{
+ struct bootcount_rtc_priv *priv = dev_get_priv(dev);
+ const u16 val = bootcount_magic << 8 | (a & 0xff);
+
+ if (rtc_write16(priv->rtc, priv->offset, val) < 0) {
+ debug("%s: rtc_write16 failed\n", __func__);
+ return -EIO;
+ }
+
+ return 0;
+}
+
+static int bootcount_rtc_get(struct udevice *dev, u32 *a)
+{
+ struct bootcount_rtc_priv *priv = dev_get_priv(dev);
+ u16 val;
+
+ if (rtc_read16(priv->rtc, priv->offset, &val) < 0) {
+ debug("%s: rtc_write16 failed\n", __func__);
+ return -EIO;
+ }
+
+ if (val >> 8 == bootcount_magic) {
+ *a = val & 0xff;
+ return 0;
+ }
+
+ debug("%s: bootcount magic does not match on %04x\n", __func__, val);
+ return -EIO;
+}
+
+static int bootcount_rtc_probe(struct udevice *dev)
+{
+ struct ofnode_phandle_args phandle_args;
+ struct bootcount_rtc_priv *priv = dev_get_priv(dev);
+ struct udevice *rtc;
+
+ if (dev_read_phandle_with_args(dev, "rtc", NULL, 0, 0, &phandle_args)) {
+ debug("%s: rtc backing device not specified\n", dev->name);
+ return -ENOENT;
+ }
+
+ if (uclass_get_device_by_ofnode(UCLASS_RTC, phandle_args.node, &rtc)) {
+ debug("%s: could not get backing device\n", dev->name);
+ return -ENODEV;
+ }
+
+ priv->rtc = rtc;
+ priv->offset = dev_read_u32_default(dev, "offset", 0);
+
+ return 0;
+}
+
+static const struct bootcount_ops bootcount_rtc_ops = {
+ .get = bootcount_rtc_get,
+ .set = bootcount_rtc_set,
+};
+
+static const struct udevice_id bootcount_rtc_ids[] = {
+ { .compatible = "u-boot,bootcount-rtc" },
+ { }
+};
+
+U_BOOT_DRIVER(bootcount_rtc) = {
+ .name = "bootcount-rtc",
+ .id = UCLASS_BOOTCOUNT,
+ .priv_auto_alloc_size = sizeof(struct bootcount_rtc_priv),
+ .probe = bootcount_rtc_probe,
+ .of_match = bootcount_rtc_ids,
+ .ops= &bootcount_rtc_ops,
+};
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESENT PATCH 1/2] rockchip: rk3128: use ROCKCHIP_BOOT_MODE_REG to update reboot flag
Kever,
> On 28.11.2018, at 03:04, Kever Yang wrote:
>
> Use ROCKCHIP_BOOT_MODE_REG instead of grf structure so that
> we can re-use the source code later.
>
> Signed-off-by: Kever Yang
NAK, as there are still pending changes.
See below for the reminder, in case this got lost.
> ---
>
> arch/arm/mach-rockchip/Kconfig| 1 +
> arch/arm/mach-rockchip/rk3128-board.c | 5 +
> 2 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
> index 145d96b1f0..94a03e2a38 100644
> --- a/arch/arm/mach-rockchip/Kconfig
> +++ b/arch/arm/mach-rockchip/Kconfig
> @@ -179,6 +179,7 @@ config TPL_ROCKCHIP_BACK_TO_BROM
> config ROCKCHIP_BOOT_MODE_REG
> hex "Rockchip boot mode flag register address"
> default 0x200081c8 if ROCKCHIP_RK3036
> + default 0x100a0038 if ROCKCHIP_RK3128
> default 0x20004040 if ROCKCHIP_RK3188
> default 0x110005c8 if ROCKCHIP_RK322X
> default 0xff730094 if ROCKCHIP_RK3288
As previously discussed: these should all go into header files, as they are not
user-configurable.
This affects multiple patch series (as I requested the same for the STIMER
address).
Please also refer to the discussion on the topic of "rockchip: add STIMER_BASE
for Rockchip SoCs”
where we discussed that asm/arch-rockchip would be preferable over
include/config as a header
file directory.
Thanks,
Philipp.
> diff --git a/arch/arm/mach-rockchip/rk3128-board.c
> b/arch/arm/mach-rockchip/rk3128-board.c
> index 7fd667a0b8..f64ccc51a0 100644
> --- a/arch/arm/mach-rockchip/rk3128-board.c
> +++ b/arch/arm/mach-rockchip/rk3128-board.c
> @@ -114,12 +114,9 @@ int board_usb_cleanup(int index, enum usb_init_type init)
> #if CONFIG_IS_ENABLED(FASTBOOT)
> int fastboot_set_reboot_flag(void)
> {
> - struct rk3128_grf *grf;
> -
> printf("Setting reboot to fastboot flag ...\n");
> - grf = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
> /* Set boot mode to fastboot */
> - writel(BOOT_FASTBOOT, &grf->os_reg[0]);
> + writel(BOOT_FASTBOOT, CONFIG_ROCKCHIP_BOOT_MODE_REG);
>
> return 0;
> }
> --
> 2.18.0
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESENT PATCH v3] rockchip: update emmc/sd index for distro boot order
Kever, > On 28.11.2018, at 03:06, Kever Yang wrote: > > According to the emmc/sdcard index in dts alias, emmc is always 0 and > sdcard index is 1, let's update to using correct mmc number for distro > boot order in common header. > > SD card suppost to have higher priority so that people can boot into > the firmware in SD card, this is very convenient for developer try with > distro img from SUSE, Fedora and etc. Developer only need to 'dd' the > Distro image(which id download from OS vendor release) into SD card without > any modify and then we can boot it up directly. You never addressed the review comment from Klaus (from the review in May): > Also prioritising SD card over eMMC does not make any sense to me. At least on > RK3399 and RK3368 the default ROM boot order is first eMMC then SD card. So > starting U-Boot from eMMC and then loading the Kernel from SD-card doesn’t > sound > right for me. This will change default behaviour and may break things for users in the field. Before we can move forward, we really need to establish a consensus on this and how users will be affected. While this doesn’t matter much for our boards, as we have logic to rewrite the default boot during boot-up anyway, I expect a lot of trouble for mainline users with their own boards... > Signed-off-by: Kever Yang > --- > > Changes in v3: > - update the commit message > Series-changes: 2 > - update the commit message > > include/configs/rockchip-common.h | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/include/configs/rockchip-common.h > b/include/configs/rockchip-common.h > index 68e1105a4b..8a72613e52 100644 > --- a/include/configs/rockchip-common.h > +++ b/include/configs/rockchip-common.h > @@ -11,11 +11,11 @@ > > #ifndef CONFIG_SPL_BUILD > > -/* First try to boot from SD (index 0), then eMMC (index 1) */ > +/* First try to boot from SD (index 1), then eMMC (index 0) */ > #if CONFIG_IS_ENABLED(CMD_MMC) > #define BOOT_TARGET_MMC(func) \ > - func(MMC, mmc, 0) \ > - func(MMC, mmc, 1) > + func(MMC, mmc, 1) \ > + func(MMC, mmc, 0) > #else > #define BOOT_TARGET_MMC(func) > #endif > -- > 2.18.0 > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] rockchip: rk3188: use board_debug_uart_init() for UART io init
> On 28.11.2018, at 06:01, Kever Yang wrote:
>
> Sync with other rockchip SoCs, use board_debug_uart_init() to
> init default UART iomux.
>
> Signed-off-by: Kever Yang
Is this different from commit d32f40ce262c584e25a0838840c8d4106aadc276 which
is has already been applied to uboot-rockchip/master at the start of the merge
window?
If so, please rebase to accomodate for the overlap...
Thanks,
Philipp.
> ---
>
> arch/arm/mach-rockchip/Kconfig| 1 +
> arch/arm/mach-rockchip/rk3188-board-spl.c | 29 +--
> 2 files changed, 23 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
> index 94a03e2a38..a007162b21 100644
> --- a/arch/arm/mach-rockchip/Kconfig
> +++ b/arch/arm/mach-rockchip/Kconfig
> @@ -35,6 +35,7 @@ config ROCKCHIP_RK3188
> select SPL_RAM
> select SPL_DRIVERS_MISC_SUPPORT
> select SPL_ROCKCHIP_EARLYRETURN_TO_BROM
> + select DEBUG_UART_BOARD_INIT
> select BOARD_LATE_INIT
> select ROCKCHIP_BROM_HELPER
> help
> diff --git a/arch/arm/mach-rockchip/rk3188-board-spl.c
> b/arch/arm/mach-rockchip/rk3188-board-spl.c
> index 98ca971b88..a7f59ad856 100644
> --- a/arch/arm/mach-rockchip/rk3188-board-spl.c
> +++ b/arch/arm/mach-rockchip/rk3188-board-spl.c
> @@ -16,6 +16,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -92,23 +93,37 @@ static int setup_arm_clock(void)
> return ret;
> }
>
> -void board_init_f(ulong dummy)
> +void board_debug_uart_init(void)
> {
> - struct udevice *pinctrl, *dev;
> - int ret;
> -
> - /* Example code showing how to enable the debug UART on RK3188 */
> -#ifdef EARLY_UART
> -#include
> /* Enable early UART on the RK3188 */
> #define GRF_BASE 0x20008000
> struct rk3188_grf * const grf = (void *)GRF_BASE;
> + enum {
> + GPIO1B1_SHIFT = 2,
> + GPIO1B1_MASK= 3,
> + GPIO1B1_GPIO= 0,
> + GPIO1B1_UART2_SOUT,
> +
> + GPIO1B0_SHIFT = 0,
> + GPIO1B0_MASK= 3,
> + GPIO1B0_GPIO= 0,
> + GPIO1B0_UART2_SIN,
> + };
>
> rk_clrsetreg(&grf->gpio1b_iomux,
>GPIO1B1_MASK << GPIO1B1_SHIFT |
>GPIO1B0_MASK << GPIO1B0_SHIFT,
>GPIO1B1_UART2_SOUT << GPIO1B1_SHIFT |
>GPIO1B0_UART2_SIN << GPIO1B0_SHIFT);
> +}
> +
> +void board_init_f(ulong dummy)
> +{
> + struct udevice *pinctrl, *dev;
> + int ret;
> +
> +#define EARLY_UART
> +#ifdef EARLY_UART
> /*
>* Debug UART can be used from here if required:
>*
> --
> 2.18.0
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] EXT: [PATCH v2 0/2] Update RV3029 driver to DM and add DM-backed bootcount support
> On 28.11.2018, at 07:29, Ray, Ian (GE Healthcare) wrote: > > > >> On 28 Nov 2018, at 0.00, Philipp Tomsich >> wrote: >> >> >> On one of our application-specific carrier boards, a MicroCrystal >> RV3029 acts as an off-module battery-backed RTC for the RK3399-Q7. >> The RV3029 is intended both to provide RTC services (to Linux) and >> to store the bootcount in its battery-backed SRAM section. >> >> To support this use-case, this series adds the following: >> * replaces the existing RV3029 driver by a DM-based one (note that the >> existing driver appears unused and didn't even have a Kconfig entry) >> that closely mirrors its incarnation in Linux 4.17 > > While true in v1, drivers/rtc/rv3029.c is not modified in this patchset. Good point. The cover letter needs updating (or I need to avoid last-minute decisions to split a series…). The RV3029 changes have been split off into the following series: https://patchwork.ozlabs.org/project/uboot/list/?series=78378 I’ll wait for comments and repost with an updated coverletter after those, if necessary. >> * adds a bootcount-method interfacing back into DM devices (implementing >> support for the RTC uclass as of now). >> >> >> Changes in v2: >> - changed to provide a UCLASS-based implementation, as requested by >> SJG in his earlier review >> - split off the RV3029 driver into a separate series >> >> Philipp Tomsich (2): >> bootcount: add uclass for bootcount >> bootcount: add a DM RTC backing store for bootcount >> > > Reviewed-by: Ian Ray > > >> doc/device-tree-bindings/chosen.txt | 30 >> drivers/bootcount/Kconfig| 28 +++ >> drivers/bootcount/Makefile | 3 ++ >> drivers/bootcount/bootcount-uclass.c | 93 >> >> drivers/bootcount/rtc.c | 89 ++ >> include/bootcount.h | 48 +++ >> include/dm/uclass-id.h | 1 + >> 7 files changed, 292 insertions(+) >> create mode 100644 drivers/bootcount/bootcount-uclass.c >> create mode 100644 drivers/bootcount/rtc.c >> >> -- >> 2.1.4 >> > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESENT PATCH 1/2] rockchip: rk3128: use ROCKCHIP_BOOT_MODE_REG to update reboot flag
Kever,
> On 29.11.2018, at 02:10, Kever Yang wrote:
>
> On 11/28/2018 05:07 PM, Philipp Tomsich wrote:
>> Kever,
>>
>>> On 28.11.2018, at 03:04, Kever Yang >> <mailto:kever.y...@rock-chips.com>> wrote:
>>>
>>> Use ROCKCHIP_BOOT_MODE_REG instead of grf structure so that
>>> we can re-use the source code later.
>>>
>>> Signed-off-by: Kever Yang >> <mailto:kever.y...@rock-chips.com>>
>> NAK, as there are still pending changes.
> Yes, I got that, and I send out my comments on your comments with no
> more response.
>> See below for the reminder, in case this got lost.
>>
>>> ---
>>>
>>> arch/arm/mach-rockchip/Kconfig| 1 +
>>> arch/arm/mach-rockchip/rk3128-board.c | 5 +
>>> 2 files changed, 2 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
>>> index 145d96b1f0..94a03e2a38 100644
>>> --- a/arch/arm/mach-rockchip/Kconfig
>>> +++ b/arch/arm/mach-rockchip/Kconfig
>>> @@ -179,6 +179,7 @@ config TPL_ROCKCHIP_BACK_TO_BROM
>>> config ROCKCHIP_BOOT_MODE_REG
>>> hex "Rockchip boot mode flag register address"
>>> default 0x200081c8 if ROCKCHIP_RK3036
>>> + default 0x100a0038 if ROCKCHIP_RK3128
>>> default 0x20004040 if ROCKCHIP_RK3188
>>> default 0x110005c8 if ROCKCHIP_RK322X
>>> default 0xff730094 if ROCKCHIP_RK3288
>> As previously discussed: these should all go into header files, as they are
>> not user-configurable.
>> This affects multiple patch series (as I requested the same for the STIMER
>> address).
> I believe you mention about this: http://patchwork.ozlabs.org/patch/891462/
> <http://patchwork.ozlabs.org/patch/891462/>
> Now the model in u-boot rockchip channel is:
> - People send out patches to mailing list;
> - The patch get an ACK patch and review patch may request for change in
> 1 week~4 months;
As I had earlier explained that the ACK means that the patch has gone into
my review queue and that I started processing it. I did change my process
since then, as this ACK had apparently been misleading to people … now the
first sign that I started processing the patch usually is a review comment.
I don’t feel that skipping the ACK is an improvement, but it seems to be less
misleading to users.
> - According to the maintainer's comment, people reply for why the patch
> like this,
>and maybe the patch do not need to change just like what the
> maintainer want.
When I state that changes are requested, this is usually for a good reason
(e.g. maintainability). So unless the comment actually serves to address
the technical concern, there is no reason to reply (as the only reply would
be a “I stand by my earlier comment.” which isn’t really helpful.
Thanks,
Philipp.
> - BUT, there will never be more reply/comments.
> - Then, people have to resend the patches they think it may be
> reasonable, and maintainer
>then complain people doesn't address his comment.
>
> For this patch, I think:
> - This is not an first patch for this operation, this just make rk3128
> work like other SoCs, it's not a new feature;
Allowing the first patches to go in was a mistake in retrospect. Back then,
I did not consider that this model would suddenly be extended beyond the
initial few use cases.
> - This kind of default value setting is all over the U-Boot project, I'm
> not say it's correct,
> but it's a good solution and convenient for us to use the same object
> with different value in different SoCs,
> It's much better to separate them into more then 10 header files or
> lots of "#ifdef CONFIG_ROCKCHIIP_RK3128"
> in one header files.
>
> I hope I can get reply for this mail this time.
>
> Hi Simon,
> Could you help to comment on this?
>
> Thanks,
> - Kever
>>
>> Please also refer to the discussion on the topic of "rockchip: add
>> STIMER_BASE for Rockchip SoCs”
>> where we discussed that asm/arch-rockchip would be preferable over
>> include/config as a header
>> file directory.
>>
>> Thanks,
>> Philipp.
>>
>>> diff --git a/arch/arm/mach-rockchip/rk3128-board.c
>>> b/arch/arm/mach-rockchip/rk3128-board.c
>>> index 7fd667a0b8..f64ccc51a0 100644
>>> --- a/arch/arm/mach-rockchip/rk3128-board.c
>>> +++ b/arch/arm/mach-rockchip/rk3128-board.c
>>> @@ -114,12 +114,9 @@ int board_usb_cleanup(int index, enum usb_init_type
>>> init)
>>> #if CONFIG_IS_ENABLED(FASTBOOT)
>>> int fastboot_set_reboot_flag(void)
>>> {
>>> - struct rk3128_grf *grf;
>>> -
>>> printf("Setting reboot to fastboot flag ...\n");
>>> - grf = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
>>> /* Set boot mode to fastboot */
>>> - writel(BOOT_FASTBOOT, &grf->os_reg[0]);
>>> + writel(BOOT_FASTBOOT, CONFIG_ROCKCHIP_BOOT_MODE_REG);
>>>
>>> return 0;
>>> }
>>> --
>>> 2.18.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESENT PATCH 1/2] rockchip: rk3128: use ROCKCHIP_BOOT_MODE_REG to update reboot flag
Simon, > On 29.11.2018, at 19:43, Simon Glass wrote: > > Hi Kever, > > On Wed, 28 Nov 2018 at 18:10, Kever Yang <mailto:kever.y...@rock-chips.com>> wrote: >> >> Hi Philipp, >> >> >> On 11/28/2018 05:07 PM, Philipp Tomsich wrote: >>> Kever, >>> >>>> On 28.11.2018, at 03:04, Kever Yang wrote: >>>> >>>> Use ROCKCHIP_BOOT_MODE_REG instead of grf structure so that >>>> we can re-use the source code later. >>>> >>>> Signed-off-by: Kever Yang >>> NAK, as there are still pending changes. >> Yes, I got that, and I send out my comments on your comments with no >> more response. >>> See below for the reminder, in case this got lost. >>> >>>> --- >>>> >>>> arch/arm/mach-rockchip/Kconfig| 1 + >>>> arch/arm/mach-rockchip/rk3128-board.c | 5 + >>>> 2 files changed, 2 insertions(+), 4 deletions(-) >>>> >>>> diff --git a/arch/arm/mach-rockchip/Kconfig >>>> b/arch/arm/mach-rockchip/Kconfig >>>> index 145d96b1f0..94a03e2a38 100644 >>>> --- a/arch/arm/mach-rockchip/Kconfig >>>> +++ b/arch/arm/mach-rockchip/Kconfig >>>> @@ -179,6 +179,7 @@ config TPL_ROCKCHIP_BACK_TO_BROM >>>> config ROCKCHIP_BOOT_MODE_REG >>>> hex "Rockchip boot mode flag register address" >>>> default 0x200081c8 if ROCKCHIP_RK3036 >>>> +default 0x100a0038 if ROCKCHIP_RK3128 >>>> default 0x20004040 if ROCKCHIP_RK3188 >>>> default 0x110005c8 if ROCKCHIP_RK322X >>>> default 0xff730094 if ROCKCHIP_RK3288 >>> As previously discussed: these should all go into header files, as they are >>> not user-configurable. >>> This affects multiple patch series (as I requested the same for the STIMER >>> address). >> I believe you mention about this: http://patchwork.ozlabs.org/patch/891462/ >> Now the model in u-boot rockchip channel is: >> - People send out patches to mailing list; >> - The patch get an ACK patch and review patch may request for change in >> 1 week~4 months; >> - According to the maintainer's comment, people reply for why the patch >> like this, >> and maybe the patch do not need to change just like what the >> maintainer want. >> - BUT, there will never be more reply/comments. >> - Then, people have to resend the patches they think it may be >> reasonable, and maintainer >> then complain people doesn't address his comment. >> >> For this patch, I think: >> - This is not an first patch for this operation, this just make rk3128 >> work like other SoCs, it's not a new feature; >> - This kind of default value setting is all over the U-Boot project, I'm >> not say it's correct, >> but it's a good solution and convenient for us to use the same object >> with different value in different SoCs, >> It's much better to separate them into more then 10 header files or >> lots of "#ifdef CONFIG_ROCKCHIIP_RK3128" >> in one header files. >> >> I hope I can get reply for this mail this time. >> >> Hi Simon, >>Could you help to comment on this? > > What happens if the user changes the value? > > Can this go in the device tree? > > It seems like this should be in a driver, to me. We have a SYSCON > driver for GRF. Should we add an ioctl-type interface to it? This affects a number of settings by now, including the addresses for the debug UARTs, secure timer base addresses and the boot-mode register. What we’d really need would be a “read/write named-register” operation (which could either be an ioctl or a new read/write operation that takes a selector that can then internally be mapped onto an actual address). However, this would require a custom syscon for each chip (or at least a per-chip driver-data), which also doesn’t sound like a desirable design. Thanks, Philipp. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESENT PATCH v3] rockchip: update emmc/sd index for distro boot order
+Vagrant Let’s also hear the opinion of the Debian project on this... > On 29.11.2018, at 10:54, Wadim Egorov wrote: > > Hi, > > Am 29.11.18 um 02:48 schrieb Kever Yang: >> >> On 11/28/2018 05:15 PM, Philipp Tomsich wrote: >>> Kever, >>> >>>> On 28.11.2018, at 03:06, Kever Yang wrote: >>>> >>>> According to the emmc/sdcard index in dts alias, emmc is always 0 and >>>> sdcard index is 1, let's update to using correct mmc number for distro >>>> boot order in common header. >>>> >>>> SD card suppost to have higher priority so that people can boot into >>>> the firmware in SD card, this is very convenient for developer try with >>>> distro img from SUSE, Fedora and etc. Developer only need to 'dd' the >>>> Distro image(which id download from OS vendor release) into SD card without >>>> any modify and then we can boot it up directly. >>> You never addressed the review comment from Klaus (from the review in May): >> I do address the review comment and that's why this patch has been V3 >> but not a RESEND for V1. The source code does not change, while the commit >> message has update to make it more clear why this patch is needed. >> >> I'm sorry to Klaus for not sure if I have reply to him directly, but I >> do this >> because I always not get response after I send out my comments in this >> channel, >> then I thought send a new patch with necessary update may be more fast to >> make patch merged. >> >>>> Also prioritising SD card over eMMC does not make any sense to me. At >>>> least on >>>> RK3399 and RK3368 the default ROM boot order is first eMMC then SD card. >>>> So >>>> starting U-Boot from eMMC and then loading the Kernel from SD-card doesn’t >>>> sound >>>> right for me. > > +1 for keeping the ROM boot order also for u-boot. > > >>> This will change default behaviour and may break things for users in the >>> field. >>> Before we can move forward, we really need to establish a consensus on this >>> and how users will be affected. >>> >>> While this doesn’t matter much for our boards, as we have logic to rewrite >>> the >>> default boot during boot-up anyway, I expect a lot of trouble for mainline >>> users >>> with their own boards... >> First we have to understand what we want and what we should do, I think the >> origin comment "First try to boot from SD (index 0), then eMMC (index 1)" is >> what we want, but the index is wrong, so we have to correct it, and my first >> commit message is about "index fix". >> And I do explain in latest commit message about why we need boot SD first, >> but I'm not sure if you have read it. >> >> Rockchip private loaders always make SD as higher priority then eMMC, >> because >> we may need use SD to update the firmware for eMMC or just a temporary test >> only image to check if the PCB is good or not. >> I think most of SBC developers prefer to use SD card instead of eMMC, >> because >> write a SD is easier then update eMMC firmware with vendor tools, and we can >> use SD card just like we try a Ubuntu in a Udisk without install it in >> hard disk for PC, >> just like I write in the commit message. > > If that is the case, then the SBC developers can override > BOOT_TARGET_DEVICES to their needs in the specific board include file. > > >> >> If we keep eMMC as higher priority, then people have no chance to use >> firmware >> in SD card if there already have firmware in eMMC. > > AFAIK most of the rockchip boards provide a jumper to somehow cut the > eMMC clock and bypass the fixed ROM boot order. > > Regards, > Wadim > >> >> Then let's check if this "break things for users in the field ", this >> patch only affect the >> case both eMMC and SD have available firmware(boot.img), right? >> I think people only write firmware to SD when they want to boot from it, >> or else >> people would never do it, the SD will be a normal external storage if >> they want to use >> the firmware in eMMC. I don't think there will be "a lot of trouble for >> mainline users ". >> >> With this patch, people can use firmware in SD card if they want; >> Without this patch, people never able to use firmware in SD card if eMMC >> firmware exist >> (even if it's broken). >> >> >
Re: [U-Boot] [RESENT PATCH v3] rockchip: update emmc/sd index for distro boot order
Kever, > On 29.11.2018, at 02:48, Kever Yang wrote: > > On 11/28/2018 05:15 PM, Philipp Tomsich wrote: >> Kever, >> >>> On 28.11.2018, at 03:06, Kever Yang wrote: >>> >>> According to the emmc/sdcard index in dts alias, emmc is always 0 and >>> sdcard index is 1, let's update to using correct mmc number for distro >>> boot order in common header. >>> >>> SD card suppost to have higher priority so that people can boot into >>> the firmware in SD card, this is very convenient for developer try with >>> distro img from SUSE, Fedora and etc. Developer only need to 'dd' the >>> Distro image(which id download from OS vendor release) into SD card without >>> any modify and then we can boot it up directly. >> You never addressed the review comment from Klaus (from the review in May): > I do address the review comment and that's why this patch has been V3 > but not a RESEND for V1. The source code does not change, while the commit > message has update to make it more clear why this patch is needed. > > I'm sorry to Klaus for not sure if I have reply to him directly, but I > do this > because I always not get response after I send out my comments in this > channel, > then I thought send a new patch with necessary update may be more fast to > make patch merged. > >> >>> Also prioritising SD card over eMMC does not make any sense to me. At least >>> on >>> RK3399 and RK3368 the default ROM boot order is first eMMC then SD card. So >>> starting U-Boot from eMMC and then loading the Kernel from SD-card doesn’t >>> sound >>> right for me. >> This will change default behaviour and may break things for users in the >> field. >> Before we can move forward, we really need to establish a consensus on this >> and how users will be affected. >> >> While this doesn’t matter much for our boards, as we have logic to rewrite >> the >> default boot during boot-up anyway, I expect a lot of trouble for mainline >> users >> with their own boards... > First we have to understand what we want and what we should do, I think the > origin comment "First try to boot from SD (index 0), then eMMC (index 1)" is > what we want, but the index is wrong, so we have to correct it, and my first > commit message is about "index fix”. Your patch clearly changes both the comment _and_ the boot order. So we need to find a consensus on the boot order as part of this discussion. > And I do explain in latest commit message about why we need boot SD first, > but I'm not sure if you have read it. I have read the message, but just because there is one use-case for this we shouldn't change the boot order for everyone. That said, I didn’t find the rationale from the commit message very compelling: (1) if there isn’t any firmware in the MMC, then the SD card will be booted anyway; (2) if there is firmware in the MMC, then U-Boot can be instructed to continue booting from SD (i.e. the user breaks onto the commandline and overrides the boottarget for distroboot) (3) if the firmware in the MMC is broken, then a USB-recovery can be attempted. Furthermore, if we always boot from SD, there’s issues for people that have another fixed storage connected to the SD controller (e.g. a second eMMC) or if a user inserts a SD card that inadvertently has a loadable image. > Rockchip private loaders always make SD as higher priority then eMMC, > because > we may need use SD to update the firmware for eMMC or just a temporary test > only image to check if the PCB is good or not. > I think most of SBC developers prefer to use SD card instead of eMMC, > because > write a SD is easier then update eMMC firmware with vendor tools, and we can > use SD card just like we try a Ubuntu in a Udisk without install it in > hard disk for PC, > just like I write in the commit message. There’s some interesting information here, as I had not been aware that your bootloader prioritised SD cards over eMMC. This may be an issue for most industrial embedded applications, as these frequently don’t want surprising changes to the boot order … however, I’d expect that most of these have the boot-order fixed in their board-files anyway. You might be surprised to hear that our RK3399 module has the eMMC on the SDHCI controller and the SD/SDIO on the DWMMC. As I said: my team doesn’t really have any skin in the game, as we have a 'u-boot,spl-boot-order’ to select where and how SPL searches for its FIT images… and we have a board-specific setup_boottargets() function to perform appropriate reordering of the boottargets before distroboot. > If we keep eMMC as higher priority, then people have no cha
Re: [U-Boot] [RESENT PATCH v3] rockchip: update emmc/sd index for distro boot order
>> With this patch, people can use firmware in SD card if they want; >> Without this patch, people never able to use firmware in SD card if eMMC >> firmware exist (even if it's broken). > > Most boards I know have the ability to bypass the internal eMMC. One last thing: I know a number of projects developing devices using our modules that have a SD card slot for data exchange (e.g. config data, log files, data acquisition and export) but that don’t want endusers to boot the device from the SD card (possibly using unauthorized firmware). For factory use, there’s a signal on the mainboard to disable (until turned back on by software) the on-module eMMC and (if available) SPI to allow booting from the external SD card. For field use, this signal is unaccessible and can not be asserted… Hope this provides one example to how different use cases can play out... Thanks, Philipp. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] rockchip: rk3188: use board_debug_uart_init() for UART io init
> On 29.11.2018, at 03:07, Kever Yang wrote: > > Sync with other rockchip SoCs, use board_debug_uart_init() to > init default UART iomux. > > Signed-off-by: Kever Yang Reviewed-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCHv3 1/4] dm: MIGRATION: Add migration plan for DM_MMC
> On 30.11.2018, at 09:10, Simon Goldschmidt > wrote: > > On Fri, Nov 30, 2018 at 12:21 AM Tom Rini <mailto:tr...@konsulko.com>> wrote: >> >> Given that at this point the MMC subsystem itself has been migrated >> along with a number of subsystem drivers, formalize a deadline for >> migration. >> >> Reviewed-by: Simon Glass mailto:s...@chromium.org>> >> Cc: Jaehoon Chung mailto:jh80.ch...@samsung.com>> >> Signed-off-by: Tom Rini mailto:tr...@konsulko.com>> > > Reviewed-by: Simon Goldschmidt <mailto:simon.k.r.goldschm...@gmail.com>> 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/5] clk_rv1108: Sync with vendor tree
Otavio, > On 30.11.2018, at 11:37, Otavio Salvador > wrote: > > Hello Vicent, > > On Fri, Nov 30, 2018 at 7:58 AM Otavio Salvador > wrote: >> On Fri, Nov 30, 2018 at 1:39 AM vicent@rock-chips.com >> wrote: >>> >>> Hi Otavio Salvador： >>> Fixed a problem of rv1108 emmc clock configuration. >>> I am afraid that the code between us is not synchronized, so I also >>> send the modified files to you. >> >> The patch you quote below does not match with the files you attached >> it seems. Would you mind send me the patch? > > I succeed in applying it here. I will run it on a few boards before > sending the new patch revision. Thanks again for your support on this. I’ll wait for v3 before doing anything further with the series then. I had this queued for a PR this weekend (as the end of the merge-window is getting close), but can pick this also next week (I really need to get this in quickly after rc1 or it will slip to the next merge-window). Thanks, Philipp. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/5] clk_rv1108: Sync with vendor tree
> On 30.11.2018, at 12:24, Otavio Salvador > wrote: > > On Fri, Nov 30, 2018 at 9:18 AM Philipp Tomsich > wrote: >>> On 30.11.2018, at 11:37, Otavio Salvador >>> wrote: >>> On Fri, Nov 30, 2018 at 7:58 AM Otavio Salvador >>> wrote: >>>> On Fri, Nov 30, 2018 at 1:39 AM vicent@rock-chips.com >>>> wrote: >>>>> >>>>> Hi Otavio Salvador： >>>>> Fixed a problem of rv1108 emmc clock configuration. >>>>> I am afraid that the code between us is not synchronized, so I also >>>>> send the modified files to you. >>>> >>>> The patch you quote below does not match with the files you attached >>>> it seems. Would you mind send me the patch? >>> >>> I succeed in applying it here. I will run it on a few boards before >>> sending the new patch revision. Thanks again for your support on this. >> >> I’ll wait for v3 before doing anything further with the series then. >> I had this queued for a PR this weekend (as the end of the merge-window is >> getting >> close), but can pick this also next week (I really need to get this in >> quickly after rc1 >> or it will slip to the next merge-window). > > Sure, I will be sending this and also our customer board (on top of > this) later today or tomorrow. I’ll try to hold off with my PR until then, so Tom can pick all changes in a single go. Thanks, Philipp. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/6] Kconfig: Migrate BOUNCE_BUFFER
The bounce buffer is used by a few drivers (most of the MMC drivers) to overcome limitations in their respective DMA implementation. This moves the configuration to Kconfig and makes it user-selectable (even though it will be a required feature to make those drivers work): the expected usage is for drivers depending on this to 'select' it unconditionally from their respective Kconfig. Signed-off-by: Philipp Tomsich --- common/Kconfig | 8 scripts/config_whitelist.txt | 1 - 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/common/Kconfig b/common/Kconfig index 57bd16d..f45e066 100644 --- a/common/Kconfig +++ b/common/Kconfig @@ -645,6 +645,14 @@ config DISPLAY_BOARDINFO_LATE the relocation phase. The board function checkboard() is called to do this. +config BOUNCE_BUFFER + bool "Include bounce buffer API" + help + Some peripherals support DMA from a subset of physically + addressable memory only. To support such peripherals, the + bounce buffer API uses a temporary buffer: it copies data + to/from DMA regions while managing cache operations. + menu "Start-up hooks" config ARCH_EARLY_INIT_R diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt index b3f525f..2151d65 100644 --- a/scripts/config_whitelist.txt +++ b/scripts/config_whitelist.txt @@ -169,7 +169,6 @@ CONFIG_BOOT_OS_NET CONFIG_BOOT_PARAMS_ADDR CONFIG_BOOT_RETRY_MIN CONFIG_BOOT_RETRY_TIME -CONFIG_BOUNCE_BUFFER CONFIG_BPTR_VIRT_ADDR CONFIG_BS_ADDR_DEVICE CONFIG_BS_ADDR_RAM -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/6] mmc: dw_mmc: depend on BOUNCE_BUFFER
The driver for the dw_mmc depends on the bounce buffer utility functions. Unconditionally select BOUNCE_BUFFER, when DW_MMC is enabled. Includes the migration (moveconfig with manual postprocessing of config-headers to drop unused comments) for the boards using DW_MMC. Signed-off-by: Philipp Tomsich --- drivers/mmc/Kconfig | 1 + include/configs/emsdp.h | 3 --- include/configs/exynos-common.h | 3 --- include/configs/hikey.h | 3 --- include/configs/hsdk.h | 5 - include/configs/iot_devkit.h| 3 --- include/configs/poplar.h| 3 --- include/configs/rk3036_common.h | 2 -- include/configs/rk3128_common.h | 3 --- include/configs/rk3188_common.h | 3 --- include/configs/rk322x_common.h | 3 --- include/configs/rk3288_common.h | 3 --- include/configs/rk3328_common.h | 3 --- include/configs/rk3368_common.h | 2 -- include/configs/rk3399_common.h | 1 - 15 files changed, 1 insertion(+), 40 deletions(-) diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig index fbd1396..65d43a5 100644 --- a/drivers/mmc/Kconfig +++ b/drivers/mmc/Kconfig @@ -178,6 +178,7 @@ config MMC_DAVINCI config MMC_DW bool "Synopsys DesignWare Memory Card Interface" + select BOUNCE_BUFFER help This selects support for the Synopsys DesignWare Mobile Storage IP block, this provides host support for SD and MMC interfaces, in both diff --git a/include/configs/emsdp.h b/include/configs/emsdp.h index 385d59e..23c71f4 100644 --- a/include/configs/emsdp.h +++ b/include/configs/emsdp.h @@ -18,9 +18,6 @@ #define CONFIG_SYS_MALLOC_LEN SZ_64K #define CONFIG_SYS_LOAD_ADDR CONFIG_SYS_SDRAM_BASE -/* Required by DW MMC driver */ -#define CONFIG_BOUNCE_BUFFER - /* * Environment */ diff --git a/include/configs/exynos-common.h b/include/configs/exynos-common.h index f3f194f..752acc5 100644 --- a/include/configs/exynos-common.h +++ b/include/configs/exynos-common.h @@ -34,9 +34,6 @@ /* select serial console configuration */ -/* SD/MMC configuration */ -#define CONFIG_BOUNCE_BUFFER - /* PWM */ #define CONFIG_PWM diff --git a/include/configs/hikey.h b/include/configs/hikey.h index 1376d61..6d9e6eb 100644 --- a/include/configs/hikey.h +++ b/include/configs/hikey.h @@ -53,9 +53,6 @@ #define CONFIG_HIKEY_GPIO -/* SD/MMC configuration */ -#define CONFIG_BOUNCE_BUFFER - /* Command line configuration */ /* BOOTP options */ diff --git a/include/configs/hsdk.h b/include/configs/hsdk.h index cdf4fdd..2ec2fd1 100644 --- a/include/configs/hsdk.h +++ b/include/configs/hsdk.h @@ -116,11 +116,6 @@ setenv core_iccm_3 0x6; setenv core_dccm_3 0x6;\0" #define CONFIG_BOOTFILE"uImage" #define CONFIG_LOADADDRCONFIG_SYS_LOAD_ADDR -/* - * Misc utility configuration - */ -#define CONFIG_BOUNCE_BUFFER - /* Cli configuration */ #define CONFIG_SYS_CBSIZE SZ_2K diff --git a/include/configs/iot_devkit.h b/include/configs/iot_devkit.h index 4ffe114..cd1309d 100644 --- a/include/configs/iot_devkit.h +++ b/include/configs/iot_devkit.h @@ -71,9 +71,6 @@ CONFIG_SYS_MALLOC_LEN - \ CONFIG_ENV_SIZE -/* Required by DW MMC driver */ -#define CONFIG_BOUNCE_BUFFER - /* * Environment */ diff --git a/include/configs/poplar.h b/include/configs/poplar.h index 0a12600..a7a77ec 100644 --- a/include/configs/poplar.h +++ b/include/configs/poplar.h @@ -26,9 +26,6 @@ /* USB configuration */ #define CONFIG_USB_MAX_CONTROLLER_COUNT2 -/* SD/MMC */ -#define CONFIG_BOUNCE_BUFFER - /* * Initial environment variables */ diff --git a/include/configs/rk3036_common.h b/include/configs/rk3036_common.h index d4e5406..1a6aeb7 100644 --- a/include/configs/rk3036_common.h +++ b/include/configs/rk3036_common.h @@ -25,8 +25,6 @@ #define CONFIG_ROCKCHIP_CHIP_TAG "RK30" /* MMC/SD IP block */ -#define CONFIG_BOUNCE_BUFFER - #define CONFIG_SYS_SDRAM_BASE 0x6000 #define SDRAM_BANK_SIZE(512UL << 20UL) #define SDRAM_MAX_SIZE (CONFIG_NR_DRAM_BANKS * SDRAM_BANK_SIZE) diff --git a/include/configs/rk3128_common.h b/include/configs/rk3128_common.h index 3e9e642..f4f64ed 100644 --- a/include/configs/rk3128_common.h +++ b/include/configs/rk3128_common.h @@ -23,9 +23,6 @@ #define CONFIG_SYS_BOOTM_LEN (64 << 20) /* 64M */ -/* MMC/SD IP block */ -#define CONFIG_BOUNCE_BUFFER - /* RAW SD card / eMMC locations. */ #define CONFIG_SYS_SPI_U_BOOT_OFFS (128 << 10) diff --git a/include/configs/rk3188_common.h b/include/configs/rk3188_common.h index d1837d5..612d643 100644 --- a/include/configs/rk3188_common.h +++ b/include
[U-Boot] [PATCH 3/6] mmc: mxsmmc: select BOUNCE_BUFFER unconditionally
The driver for the mxsmmc depends on the bounce buffer utility functions. Unconditionally select BOUNCE_BUFFER, when this driver is enabled. Includes the migration (moveconfig with manual postprocessing of config-headers to drop unused comments) for the boards using mxsmmc. Signed-off-by: Philipp Tomsich --- drivers/mmc/Kconfig | 1 + include/configs/mx6_common.h | 1 - include/configs/mx7_common.h | 1 - include/configs/mx7ulp_evk.h | 1 - include/configs/mxs.h| 5 - 5 files changed, 1 insertion(+), 8 deletions(-) diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig index 65d43a5..e16dd6a 100644 --- a/drivers/mmc/Kconfig +++ b/drivers/mmc/Kconfig @@ -240,6 +240,7 @@ config MMC_MXC config MMC_MXS bool "Freescale MXS Multimedia Card Interface support" depends on MX23 || MX28 || MX6 || MX7 + select BOUNCE_BUFFER select APBH_DMA select APBH_DMA_BURST if ARCH_MX6 || ARCH_MX7 select APBH_DMA_BURST8 if ARCH_MX6 || ARCH_MX7 diff --git a/include/configs/mx6_common.h b/include/configs/mx6_common.h index 1b2961f..cdc8833 100644 --- a/include/configs/mx6_common.h +++ b/include/configs/mx6_common.h @@ -55,7 +55,6 @@ #define CONFIG_SYS_MAXARGS 32 /* MMC */ -#define CONFIG_BOUNCE_BUFFER #define CONFIG_FSL_USDHC /* Fuses */ diff --git a/include/configs/mx7_common.h b/include/configs/mx7_common.h index b0b7e1e..a895c93 100644 --- a/include/configs/mx7_common.h +++ b/include/configs/mx7_common.h @@ -40,7 +40,6 @@ #define CONFIG_MXC_UART /* MMC */ -#define CONFIG_BOUNCE_BUFFER #define CONFIG_FSL_USDHC /* Fuses */ diff --git a/include/configs/mx7ulp_evk.h b/include/configs/mx7ulp_evk.h index 3d32ff1..b8dcaa1 100644 --- a/include/configs/mx7ulp_evk.h +++ b/include/configs/mx7ulp_evk.h @@ -27,7 +27,6 @@ #define IRAM_BASE_ADDR OCRAM_0_BASE #define IOMUXC_BASE_ADDR IOMUXC1_RBASE -#define CONFIG_BOUNCE_BUFFER #define CONFIG_FSL_USDHC #define CONFIG_SUPPORT_EMMC_BOOT /* eMMC specific */ diff --git a/include/configs/mxs.h b/include/configs/mxs.h index 9e59e7a..20719c9 100644 --- a/include/configs/mxs.h +++ b/include/configs/mxs.h @@ -124,11 +124,6 @@ #define CONFIG_VIDEO_MXS #endif -/* MMC */ -#ifdef CONFIG_CMD_MMC -#define CONFIG_BOUNCE_BUFFER -#endif - /* NAND */ #ifdef CONFIG_CMD_NAND #define CONFIG_SYS_MAX_NAND_DEVICE 1 -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/6] mmc: tegra: select BOUNCE_BUFFER unconditionally
The driver for the SDHCI_TEGRA depends on the bounce buffer utility functions. Unconditionally select BOUNCE_BUFFER, when this driver is enabled. Includes the migration (moveconfig with manual postprocessing of config-headers to drop unused comments) for the boards using SDHCI_TEGRA. Signed-off-by: Philipp Tomsich --- drivers/mmc/Kconfig| 1 + include/configs/tegra-common.h | 3 --- 2 files changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig index e16dd6a..eb2e9bc 100644 --- a/drivers/mmc/Kconfig +++ b/drivers/mmc/Kconfig @@ -531,6 +531,7 @@ config MMC_SDHCI_TANGIER config MMC_SDHCI_TEGRA bool "SDHCI platform support for the Tegra SD/MMC Controller" depends on TEGRA + select BOUNCE_BUFFER default y help This selects the Tegra SD/MMC controller. If you have a Tegra diff --git a/include/configs/tegra-common.h b/include/configs/tegra-common.h index 4d249dd..d37e2d7 100644 --- a/include/configs/tegra-common.h +++ b/include/configs/tegra-common.h @@ -88,7 +88,4 @@ #define CONFIG_SYS_SPL_MALLOC_SIZE 0x0001 #endif -/* Misc utility code */ -#define CONFIG_BOUNCE_BUFFER - #endif /* _TEGRA_COMMON_H_ */ -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 5/6] arc: select BOUNCE_BUFFER for CMD_NAND on AXS10x
The NAND driver of AXS10x depends on the availability of the bounce buffer. As the NAND driver is gated by CMD_NAND only, we need to select BOUNCE_BUFFER conditionally (on CMD_NAND) for TARGET_AXS101 and TARGET_AXS103. This change also contains the modification to configs/axs10x.h to avoid redefining BOUNCE_BUFFER there. Signed-off-by: Philipp Tomsich --- arch/arc/Kconfig | 2 ++ include/configs/axs10x.h | 5 - 2 files changed, 2 insertions(+), 5 deletions(-) diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig index fa6b344..50369d5 100644 --- a/arch/arc/Kconfig +++ b/arch/arc/Kconfig @@ -146,9 +146,11 @@ config TARGET_NSIM config TARGET_AXS101 bool "Support Synopsys Designware SDP board AXS101" + select BOUNCE_BUFFER if CMD_NAND config TARGET_AXS103 bool "Support Synopsys Designware SDP board AXS103" + select BOUNCE_BUFFER if CMD_NAND config TARGET_EMSDP bool "Synopsys EM Software Development Platform" diff --git a/include/configs/axs10x.h b/include/configs/axs10x.h index 1b2966f..bd1c902 100644 --- a/include/configs/axs10x.h +++ b/include/configs/axs10x.h @@ -82,9 +82,4 @@ * Console configuration */ -/* - * Misc utility configuration - */ -#define CONFIG_BOUNCE_BUFFER - #endif /* _CONFIG_AXS10X_H_ */ -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 6/6] Kconfig: migrate BOUNCE_BUFFER (final moveconfig)
There's a few boards that seem to have BOUNCE_BUFFER as a purely elective option: at least I could not find a driver that actually depends on it for these. As a final migration step, these boards have BOUNCE_BUFFER moved from their header files into the corresponding defconfig using moveconfig. Signed-off-by: Philipp Tomsich --- configs/bcm911360_entphn-ns_defconfig | 1 + configs/bcm911360_entphn_defconfig| 1 + configs/bcm911360k_defconfig | 1 + configs/bcm958300k-ns_defconfig | 1 + configs/bcm958300k_defconfig | 1 + configs/bcm958305k_defconfig | 1 + configs/bcm958622hr_defconfig | 1 + configs/socfpga_arria10_defconfig | 1 + include/configs/bcm_ep_board.h| 3 --- include/configs/socfpga_common.h | 1 - include/configs/socfpga_stratix10_socdk.h | 1 - 11 files changed, 8 insertions(+), 5 deletions(-) diff --git a/configs/bcm911360_entphn-ns_defconfig b/configs/bcm911360_entphn-ns_defconfig index 7e4920f..be8a90e 100644 --- a/configs/bcm911360_entphn-ns_defconfig +++ b/configs/bcm911360_entphn-ns_defconfig @@ -6,6 +6,7 @@ CONFIG_SYS_EXTRA_OPTIONS="SYS_SDRAM_SIZE=0x2000,ARMV7_NONSEC" CONFIG_VERSION_VARIABLE=y # CONFIG_DISPLAY_CPUINFO is not set # CONFIG_DISPLAY_BOARDINFO is not set +CONFIG_BOUNCE_BUFFER=y CONFIG_HUSH_PARSER=y # CONFIG_AUTOBOOT is not set CONFIG_CMD_BOOTZ=y diff --git a/configs/bcm911360_entphn_defconfig b/configs/bcm911360_entphn_defconfig index a7c6475..ba81847 100644 --- a/configs/bcm911360_entphn_defconfig +++ b/configs/bcm911360_entphn_defconfig @@ -6,6 +6,7 @@ CONFIG_SYS_EXTRA_OPTIONS="SYS_SDRAM_SIZE=0x2000" CONFIG_VERSION_VARIABLE=y # CONFIG_DISPLAY_CPUINFO is not set # CONFIG_DISPLAY_BOARDINFO is not set +CONFIG_BOUNCE_BUFFER=y CONFIG_HUSH_PARSER=y # CONFIG_AUTOBOOT is not set CONFIG_CMD_BOOTZ=y diff --git a/configs/bcm911360k_defconfig b/configs/bcm911360k_defconfig index 349f2b8..132234c 100644 --- a/configs/bcm911360k_defconfig +++ b/configs/bcm911360k_defconfig @@ -6,6 +6,7 @@ CONFIG_SYS_EXTRA_OPTIONS="SYS_SDRAM_SIZE=0x4000" CONFIG_VERSION_VARIABLE=y # CONFIG_DISPLAY_CPUINFO is not set # CONFIG_DISPLAY_BOARDINFO is not set +CONFIG_BOUNCE_BUFFER=y CONFIG_HUSH_PARSER=y # CONFIG_AUTOBOOT is not set CONFIG_CMD_BOOTZ=y diff --git a/configs/bcm958300k-ns_defconfig b/configs/bcm958300k-ns_defconfig index fd0da02..d95ef15 100644 --- a/configs/bcm958300k-ns_defconfig +++ b/configs/bcm958300k-ns_defconfig @@ -6,6 +6,7 @@ CONFIG_SYS_EXTRA_OPTIONS="SYS_SDRAM_SIZE=0x4000,ARMV7_NONSEC" CONFIG_VERSION_VARIABLE=y # CONFIG_DISPLAY_CPUINFO is not set # CONFIG_DISPLAY_BOARDINFO is not set +CONFIG_BOUNCE_BUFFER=y CONFIG_HUSH_PARSER=y # CONFIG_AUTOBOOT is not set CONFIG_CMD_BOOTZ=y diff --git a/configs/bcm958300k_defconfig b/configs/bcm958300k_defconfig index 349f2b8..132234c 100644 --- a/configs/bcm958300k_defconfig +++ b/configs/bcm958300k_defconfig @@ -6,6 +6,7 @@ CONFIG_SYS_EXTRA_OPTIONS="SYS_SDRAM_SIZE=0x4000" CONFIG_VERSION_VARIABLE=y # CONFIG_DISPLAY_CPUINFO is not set # CONFIG_DISPLAY_BOARDINFO is not set +CONFIG_BOUNCE_BUFFER=y CONFIG_HUSH_PARSER=y # CONFIG_AUTOBOOT is not set CONFIG_CMD_BOOTZ=y diff --git a/configs/bcm958305k_defconfig b/configs/bcm958305k_defconfig index 349f2b8..132234c 100644 --- a/configs/bcm958305k_defconfig +++ b/configs/bcm958305k_defconfig @@ -6,6 +6,7 @@ CONFIG_SYS_EXTRA_OPTIONS="SYS_SDRAM_SIZE=0x4000" CONFIG_VERSION_VARIABLE=y # CONFIG_DISPLAY_CPUINFO is not set # CONFIG_DISPLAY_BOARDINFO is not set +CONFIG_BOUNCE_BUFFER=y CONFIG_HUSH_PARSER=y # CONFIG_AUTOBOOT is not set CONFIG_CMD_BOOTZ=y diff --git a/configs/bcm958622hr_defconfig b/configs/bcm958622hr_defconfig index 74d9f25..d5cb7f6 100644 --- a/configs/bcm958622hr_defconfig +++ b/configs/bcm958622hr_defconfig @@ -6,6 +6,7 @@ CONFIG_SYS_EXTRA_OPTIONS="SYS_SDRAM_SIZE=0x0100" CONFIG_VERSION_VARIABLE=y # CONFIG_DISPLAY_CPUINFO is not set # CONFIG_DISPLAY_BOARDINFO is not set +CONFIG_BOUNCE_BUFFER=y CONFIG_HUSH_PARSER=y # CONFIG_AUTOBOOT is not set CONFIG_CMD_BOOTZ=y diff --git a/configs/socfpga_arria10_defconfig b/configs/socfpga_arria10_defconfig index 6ebda81..f321a0a 100644 --- a/configs/socfpga_arria10_defconfig +++ b/configs/socfpga_arria10_defconfig @@ -12,6 +12,7 @@ CONFIG_BOOTARGS="console=ttyS0,115200" # CONFIG_USE_BOOTCOMMAND is not set CONFIG_DEFAULT_FDT_FILE="socfpga_arria10_socdk_sdmmc.dtb" CONFIG_DISPLAY_BOARDINFO_LATE=y +CONFIG_BOUNCE_BUFFER=y CONFIG_SPL_FPGA_SUPPORT=y CONFIG_SPL_SPI_LOAD=y CONFIG_CMD_ASKENV=y diff --git a/include/configs/bcm_ep_board.h b/include/configs/bcm_ep_board.h index 0586c53a..09a5804 100644 --- a/include/configs/bcm_ep_board.h +++ b/include/configs/bcm_ep_board.h @@ -55,7 +55,4 @@ /* Enable Time Command */ -/* Misc utility code */ -#define CONFIG_BOUNCE_BUFFER - #endif /* __BCM
Re: [U-Boot] [PATCH v4 2/6] ARM: rockchip: rv1108: Enable BOUNCE_BUFFER
Otavio, > On 27.11.2018, at 11:11, Otavio Salvador wrote: > > In order to be able to build the Rockchip eMMC driver on rv1108, the > BOUNCE_BUFFER option needs to be selected. Select it like it is done > on the other Rockchip SoC common files. > > Reviewed-by: Andy Yan > Signed-off-by: Otavio Salvador > --- > > Changes in v4: None > Changes in v3: > - rework commit log > > Changes in v2: > - new patch > > include/configs/rv1108_common.h | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/include/configs/rv1108_common.h b/include/configs/rv1108_common.h > index 2ab3b85e0c..cc0384e2f4 100644 > --- a/include/configs/rv1108_common.h > +++ b/include/configs/rv1108_common.h > @@ -17,6 +17,9 @@ > #define CONFIG_SYS_TIMER_BASE 0x10350020 > #define CONFIG_SYS_TIMER_COUNTER (CONFIG_SYS_TIMER_BASE + 8) > > +/* MMC/SD IP block */ > +#define CONFIG_BOUNCE_BUFFER I just submitted a series that migrates BOUNCE_BUFFER into Kconfig and selects it unconditionally for MMC_DW. If that one makes it in before I merge this, I’ll drop this patch (i.e.: keep in v5, but don’t be surprised if never makes it into the tree). > + > #define CONFIG_SYS_SDRAM_BASE 0x6000 > #define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_TEXT_BASE + > 0x10) > #define CONFIG_SYS_LOAD_ADDR (CONFIG_SYS_SDRAM_BASE + 0x200) > -- > 2.19.2 > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/6] Migrate BOUNCE_BUFFER
A number of MMC drivers uses BOUNCE_BUFFER for their DMA buffers. This moves it into Kconfig and performs a step-by-step migration for the affected boards/drivers. In doing so, it turns out that a few boards/configs enabled CONFIG_BOUNCE_BUFFER in their config headers without an apparent need. The migration (using moveconfig) for those boards is kept in a separate patch, so it can be more easily reviewed by the affected parties to make a determination whether it is actually needed. Given that BOUNCE_BUFFER only controls whether the bounce_buffer_* functions are build and linked, this configuration option could be entirely removed and the utility functions built unconditionally. For platforms that don't make use of these functions, the linker will then remove the unused symbols. I'll leave the final decision if this would be a better implementation (or if this should be done in a two-stage process) to someone else... END. Philipp Tomsich (6): Kconfig: Migrate BOUNCE_BUFFER mmc: dw_mmc: depend on BOUNCE_BUFFER mmc: mxsmmc: select BOUNCE_BUFFER unconditionally mmc: tegra: select BOUNCE_BUFFER unconditionally arc: select BOUNCE_BUFFER for CMD_NAND on AXS10x Kconfig: migrate BOUNCE_BUFFER (final moveconfig) arch/arc/Kconfig | 2 ++ common/Kconfig| 8 configs/bcm911360_entphn-ns_defconfig | 1 + configs/bcm911360_entphn_defconfig| 1 + configs/bcm911360k_defconfig | 1 + configs/bcm958300k-ns_defconfig | 1 + configs/bcm958300k_defconfig | 1 + configs/bcm958305k_defconfig | 1 + configs/bcm958622hr_defconfig | 1 + configs/socfpga_arria10_defconfig | 1 + drivers/mmc/Kconfig | 3 +++ include/configs/axs10x.h | 5 - include/configs/bcm_ep_board.h| 3 --- include/configs/emsdp.h | 3 --- include/configs/exynos-common.h | 3 --- include/configs/hikey.h | 3 --- include/configs/hsdk.h| 5 - include/configs/iot_devkit.h | 3 --- include/configs/mx6_common.h | 1 - include/configs/mx7_common.h | 1 - include/configs/mx7ulp_evk.h | 1 - include/configs/mxs.h | 5 - include/configs/poplar.h | 3 --- include/configs/rk3036_common.h | 2 -- include/configs/rk3128_common.h | 3 --- include/configs/rk3188_common.h | 3 --- include/configs/rk322x_common.h | 3 --- include/configs/rk3288_common.h | 3 --- include/configs/rk3328_common.h | 3 --- include/configs/rk3368_common.h | 2 -- include/configs/rk3399_common.h | 1 - include/configs/socfpga_common.h | 1 - include/configs/socfpga_stratix10_socdk.h | 1 - include/configs/tegra-common.h| 3 --- scripts/config_whitelist.txt | 1 - 35 files changed, 21 insertions(+), 62 deletions(-) -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] Migrate BOUNCE_BUFFER
Simon, > On 30.11.2018, at 14:55, Simon Goldschmidt > wrote: > > [cut down CC list as gmail won't let me send to that many people :-( ] Sometimes I wonder if patman will at some point get a feature to avoid those endless CC lists for changes like this one. > Am 30.11.2018 um 12:39 schrieb Philipp Tomsich: >> A number of MMC drivers uses BOUNCE_BUFFER for their DMA buffers. >> This moves it into Kconfig and performs a step-by-step migration for >> the affected boards/drivers. >> >> In doing so, it turns out that a few boards/configs enabled >> CONFIG_BOUNCE_BUFFER in their config headers without an apparent need. >> The migration (using moveconfig) for those boards is kept in a >> separate patch, so it can be more easily reviewed by the affected >> parties to make a determination whether it is actually needed. >> >> Given that BOUNCE_BUFFER only controls whether the bounce_buffer_* >> functions are build and linked, this configuration option could be >> entirely removed and the utility functions built unconditionally. For >> platforms that don't make use of these functions, the linker will then >> remove the unused symbols. >> >> I'll leave the final decision if this would be a better implementation >> (or if this should be done in a two-stage process) to someone else... >> END. > > I think this is a good idea, but I get build errors after applying patch 2/6 > since CONFIG_BOUNCE_BUFFER is now enabled via Kconfig and defined as 1 while > at the same time it is just defined (but to nothing) in socfpga_common.h. This is a problem of having multiple individual patches for a moveconfig-style change. You need the final patch (6/6) in addition to (1/6) for socfpga. > Can you change or reorder this series so that every commit compiles? There’s a couple options (none of they appeal to me): 1. I lump everything together into one big change. 2. I have a complete moveconfig (i.e. polluting all defconfig files) in the first patch and the individual changes to the MMC drivers then remove the defconfig entries for their platforms. 3. We skip this part of the conversion and directly skip forward to having bounce-buffer always included and leave the cleanup to the linker… I’m happy to change this to any of the 3 options (although I’ll probably need a shower afterwards to feel less dirty, if we go with option #1 …) Philipp. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] Migrate BOUNCE_BUFFER
Tom, > On 30.11.2018, at 15:13, Philipp Tomsich > wrote: > > Simon, > >> On 30.11.2018, at 14:55, Simon Goldschmidt > <mailto:simon.k.r.goldschm...@gmail.com>> wrote: >> >> [cut down CC list as gmail won't let me send to that many people :-( ] > > Sometimes I wonder if patman will at some point get a feature to avoid those > endless CC lists for changes like this one. > >> Am 30.11.2018 um 12:39 schrieb Philipp Tomsich: >>> A number of MMC drivers uses BOUNCE_BUFFER for their DMA buffers. >>> This moves it into Kconfig and performs a step-by-step migration for >>> the affected boards/drivers. >>> >>> In doing so, it turns out that a few boards/configs enabled >>> CONFIG_BOUNCE_BUFFER in their config headers without an apparent need. >>> The migration (using moveconfig) for those boards is kept in a >>> separate patch, so it can be more easily reviewed by the affected >>> parties to make a determination whether it is actually needed. >>> >>> Given that BOUNCE_BUFFER only controls whether the bounce_buffer_* >>> functions are build and linked, this configuration option could be >>> entirely removed and the utility functions built unconditionally. For >>> platforms that don't make use of these functions, the linker will then >>> remove the unused symbols. >>> >>> I'll leave the final decision if this would be a better implementation >>> (or if this should be done in a two-stage process) to someone else... >>> END. >> >> I think this is a good idea, but I get build errors after applying patch 2/6 >> since CONFIG_BOUNCE_BUFFER is now enabled via Kconfig and defined as 1 while >> at the same time it is just defined (but to nothing) in socfpga_common.h. > > This is a problem of having multiple individual patches for a moveconfig-style > change. You need the final patch (6/6) in addition to (1/6) for socfpga. > >> Can you change or reorder this series so that every commit compiles? > > There’s a couple options (none of they appeal to me): > 1.I lump everything together into one big change. > 2.I have a complete moveconfig (i.e. polluting all defconfig files) in the > first patch and the individual changes to the MMC drivers then remove > the defconfig entries for their platforms. > 3.We skip this part of the conversion and directly skip forward to having > bounce-buffer always included and leave the cleanup to the linker… > > I’m happy to change this to any of the 3 options (although I’ll probably need > a shower afterwards to feel less dirty, if we go with option #1 …) I now tried option #2, but that leads to the final patch being subsumed into the first one (i.e. the maintainers of socfpga and the bcm* ports don’t get a chance to say “we confirm that this is not needed, just drop patch 6/6”). So this boils down to whether Tom is ok with this being a series that has failures if not fully applied (i.e. patch 1/1 leaving loose ends that the follow-on patches address on a per-MMC-controller and per-platform basis)… …or if we skip the conversion and trust the linker to do the right thing. Thanks, Philipp. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 3/5] mmc: mxsmmc: select BOUNCE_BUFFER unconditionally
The driver for the mxsmmc depends on the bounce buffer utility functions. Unconditionally select BOUNCE_BUFFER, when this driver is enabled. This commit also includes the postprocessing to remove now-unused comments from the config-header after moveconfig has run. Signed-off-by: Philipp Tomsich Reviewed-by: Fabio Estevam --- Changes in v2: None drivers/mmc/Kconfig | 1 + include/configs/mxs.h | 2 -- 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig index 65d43a5..e16dd6a 100644 --- a/drivers/mmc/Kconfig +++ b/drivers/mmc/Kconfig @@ -240,6 +240,7 @@ config MMC_MXC config MMC_MXS bool "Freescale MXS Multimedia Card Interface support" depends on MX23 || MX28 || MX6 || MX7 + select BOUNCE_BUFFER select APBH_DMA select APBH_DMA_BURST if ARCH_MX6 || ARCH_MX7 select APBH_DMA_BURST8 if ARCH_MX6 || ARCH_MX7 diff --git a/include/configs/mxs.h b/include/configs/mxs.h index 140fe87..20719c9 100644 --- a/include/configs/mxs.h +++ b/include/configs/mxs.h @@ -124,8 +124,6 @@ #define CONFIG_VIDEO_MXS #endif -/* MMC */ - /* NAND */ #ifdef CONFIG_CMD_NAND #define CONFIG_SYS_MAX_NAND_DEVICE 1 -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 4/5] mmc: tegra: select BOUNCE_BUFFER unconditionally
The driver for the SDHCI_TEGRA depends on the bounce buffer utility functions. Unconditionally select BOUNCE_BUFFER, when this driver is enabled. This also includes the post-processing to drop unused comments after running moveconfig. Signed-off-by: Philipp Tomsich --- Changes in v2: None drivers/mmc/Kconfig| 1 + include/configs/tegra-common.h | 2 -- 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig index e16dd6a..eb2e9bc 100644 --- a/drivers/mmc/Kconfig +++ b/drivers/mmc/Kconfig @@ -531,6 +531,7 @@ config MMC_SDHCI_TANGIER config MMC_SDHCI_TEGRA bool "SDHCI platform support for the Tegra SD/MMC Controller" depends on TEGRA + select BOUNCE_BUFFER default y help This selects the Tegra SD/MMC controller. If you have a Tegra diff --git a/include/configs/tegra-common.h b/include/configs/tegra-common.h index 178f170..d37e2d7 100644 --- a/include/configs/tegra-common.h +++ b/include/configs/tegra-common.h @@ -88,6 +88,4 @@ #define CONFIG_SYS_SPL_MALLOC_SIZE 0x0001 #endif -/* Misc utility code */ - #endif /* _TEGRA_COMMON_H_ */ -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/5] mmc: dw_mmc: depend on BOUNCE_BUFFER
The driver for the dw_mmc depends on the bounce buffer utility functions. Unconditionally select BOUNCE_BUFFER, when DW_MMC is enabled. This also includes the postprocessing of the config-headers to drop now-unused comments after moveconfig has run. Signed-off-by: Philipp Tomsich Reviewed-by: Otavio Salvador --- Changes in v2: None drivers/mmc/Kconfig | 1 + include/configs/emsdp.h | 2 -- include/configs/exynos-common.h | 2 -- include/configs/hikey.h | 2 -- include/configs/hsdk.h | 4 include/configs/iot_devkit.h| 2 -- include/configs/poplar.h| 2 -- include/configs/rk3036_common.h | 2 -- include/configs/rk3128_common.h | 2 -- include/configs/rk3188_common.h | 2 -- include/configs/rk322x_common.h | 2 -- include/configs/rk3288_common.h | 2 -- include/configs/rk3328_common.h | 3 --- 13 files changed, 1 insertion(+), 27 deletions(-) diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig index fbd1396..65d43a5 100644 --- a/drivers/mmc/Kconfig +++ b/drivers/mmc/Kconfig @@ -178,6 +178,7 @@ config MMC_DAVINCI config MMC_DW bool "Synopsys DesignWare Memory Card Interface" + select BOUNCE_BUFFER help This selects support for the Synopsys DesignWare Mobile Storage IP block, this provides host support for SD and MMC interfaces, in both diff --git a/include/configs/emsdp.h b/include/configs/emsdp.h index a77f262..23c71f4 100644 --- a/include/configs/emsdp.h +++ b/include/configs/emsdp.h @@ -18,8 +18,6 @@ #define CONFIG_SYS_MALLOC_LEN SZ_64K #define CONFIG_SYS_LOAD_ADDR CONFIG_SYS_SDRAM_BASE -/* Required by DW MMC driver */ - /* * Environment */ diff --git a/include/configs/exynos-common.h b/include/configs/exynos-common.h index 543bf8e..752acc5 100644 --- a/include/configs/exynos-common.h +++ b/include/configs/exynos-common.h @@ -34,8 +34,6 @@ /* select serial console configuration */ -/* SD/MMC configuration */ - /* PWM */ #define CONFIG_PWM diff --git a/include/configs/hikey.h b/include/configs/hikey.h index 3a308cf..6d9e6eb 100644 --- a/include/configs/hikey.h +++ b/include/configs/hikey.h @@ -53,8 +53,6 @@ #define CONFIG_HIKEY_GPIO -/* SD/MMC configuration */ - /* Command line configuration */ /* BOOTP options */ diff --git a/include/configs/hsdk.h b/include/configs/hsdk.h index bafd8d0..2ec2fd1 100644 --- a/include/configs/hsdk.h +++ b/include/configs/hsdk.h @@ -116,10 +116,6 @@ setenv core_iccm_3 0x6; setenv core_dccm_3 0x6;\0" #define CONFIG_BOOTFILE"uImage" #define CONFIG_LOADADDRCONFIG_SYS_LOAD_ADDR -/* - * Misc utility configuration - */ - /* Cli configuration */ #define CONFIG_SYS_CBSIZE SZ_2K diff --git a/include/configs/iot_devkit.h b/include/configs/iot_devkit.h index 1f40d61..cd1309d 100644 --- a/include/configs/iot_devkit.h +++ b/include/configs/iot_devkit.h @@ -71,8 +71,6 @@ CONFIG_SYS_MALLOC_LEN - \ CONFIG_ENV_SIZE -/* Required by DW MMC driver */ - /* * Environment */ diff --git a/include/configs/poplar.h b/include/configs/poplar.h index 6ca9ae9..a7a77ec 100644 --- a/include/configs/poplar.h +++ b/include/configs/poplar.h @@ -26,8 +26,6 @@ /* USB configuration */ #define CONFIG_USB_MAX_CONTROLLER_COUNT2 -/* SD/MMC */ - /* * Initial environment variables */ diff --git a/include/configs/rk3036_common.h b/include/configs/rk3036_common.h index 301bd2f..e307855 100644 --- a/include/configs/rk3036_common.h +++ b/include/configs/rk3036_common.h @@ -24,8 +24,6 @@ #define CONFIG_ROCKCHIP_MAX_INIT_SIZE (4 << 10) #define CONFIG_ROCKCHIP_CHIP_TAG "RK30" -/* MMC/SD IP block */ - #define CONFIG_SYS_SDRAM_BASE 0x6000 #define SDRAM_BANK_SIZE(512UL << 20UL) #define SDRAM_MAX_SIZE (CONFIG_NR_DRAM_BANKS * SDRAM_BANK_SIZE) diff --git a/include/configs/rk3128_common.h b/include/configs/rk3128_common.h index a8a4e02..f4f64ed 100644 --- a/include/configs/rk3128_common.h +++ b/include/configs/rk3128_common.h @@ -23,8 +23,6 @@ #define CONFIG_SYS_BOOTM_LEN (64 << 20) /* 64M */ -/* MMC/SD IP block */ - /* RAW SD card / eMMC locations. */ #define CONFIG_SYS_SPI_U_BOOT_OFFS (128 << 10) diff --git a/include/configs/rk3188_common.h b/include/configs/rk3188_common.h index 23938f7..612d643 100644 --- a/include/configs/rk3188_common.h +++ b/include/configs/rk3188_common.h @@ -33,8 +33,6 @@ #define CONFIG_SPL_STACK 0x10087fff -/* MMC/SD IP block */ - #define CONFIG_SYS_SDRAM_BASE 0x6000 #define SDRAM_BANK_SIZE(2UL << 30) #define SDRAM
[U-Boot] [PATCH v2 5/5] arc: select BOUNCE_BUFFER for CMD_NAND on AXS10x
The NAND driver of AXS10x depends on the availability of the bounce buffer. As the NAND driver is gated by CMD_NAND only, we need to select BOUNCE_BUFFER conditionally (on CMD_NAND) for TARGET_AXS101 and TARGET_AXS103. Signed-off-by: Philipp Tomsich --- Changes in v2: None arch/arc/Kconfig | 2 ++ include/configs/axs10x.h | 4 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig index fa6b344..50369d5 100644 --- a/arch/arc/Kconfig +++ b/arch/arc/Kconfig @@ -146,9 +146,11 @@ config TARGET_NSIM config TARGET_AXS101 bool "Support Synopsys Designware SDP board AXS101" + select BOUNCE_BUFFER if CMD_NAND config TARGET_AXS103 bool "Support Synopsys Designware SDP board AXS103" + select BOUNCE_BUFFER if CMD_NAND config TARGET_EMSDP bool "Synopsys EM Software Development Platform" diff --git a/include/configs/axs10x.h b/include/configs/axs10x.h index 8febe09..bd1c902 100644 --- a/include/configs/axs10x.h +++ b/include/configs/axs10x.h @@ -82,8 +82,4 @@ * Console configuration */ -/* - * Misc utility configuration - */ - #endif /* _CONFIG_AXS10X_H_ */ -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] rockchip: rk3399-puma: reduce sd card max-frequency to 40MHz
Some SanDisk Ultra cards trigger intermittent errors on detection
resulting in an -EOPNOTSUPP, when running at 50MHz.
Waveform analysis suggest that the level shifters that are used on the
RK3399-Q7 module (for voltage translation between the on-module
voltages and the 3.3V required on the card-edge) don't handle clock
rates at or above 48MHz properly. This change reduces the maximum
frequency on the external SD-interface to 40MHz (for a safety margin
of 20%).
Reported-by: Jakob Unterwurzacher
Signed-off-by: Philipp Tomsich
Tested-by: Christoph Muellner
---
arch/arm/dts/rk3399-puma.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/dts/rk3399-puma.dtsi b/arch/arm/dts/rk3399-puma.dtsi
index 261df42..ba9bb4c 100644
--- a/arch/arm/dts/rk3399-puma.dtsi
+++ b/arch/arm/dts/rk3399-puma.dtsi
@@ -505,7 +505,7 @@
&sdmmc {
u-boot,dm-pre-reloc;
clock-frequency = <15000>;
- clock-freq-min-max = <10 15000>;
+ max-frequency = <4000>;
supports-sd;
bus-width = <4>;
cap-mmc-highspeed;
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] rockchp: rock_defconfig: remove TPL_TINY_MEMSET
> The rk3188 rock board does not need TPL, remove relate MACRO. > > Signed-off-by: Kever Yang > --- > > configs/rock_defconfig | 1 - > 1 file changed, 1 deletion(-) > Reviewed-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v5, 3/6] ARM: dts: rockchip: Add rv1108 eMMC pinctrl
> This adds the pinctrl handles to enable the use of eMMC on custom > boards (as minievk) and makes it easier for later addition. > > Signed-off-by: Otavio Salvador > --- > > Changes in v5: None > Changes in v4: None > Changes in v3: > - rework commit log > > Changes in v2: > - split bounce buffer change on a new patch > > arch/arm/dts/rv1108.dtsi | 29 + > 1 file changed, 29 insertions(+) > Reviewed-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] rockchip: rk3399: Initialize CPU B clock.
> This patch sets the PLL of CPU cluster B (BPLL) to 600 MHz. > This decreases the boot time of Linux 4.19 by about 8%. > > The 600 MHz are inspired by the 600 MHz used for LPLL initialization > (came in with commit 9f636a249c1). > > Tested on RK3399-Q7 on Haikou base board. > > Signed-off-by: Christoph Muellner > --- > arch/arm/include/asm/arch-rockchip/cru_rk3399.h | 22 +-- > drivers/clk/rockchip/clk_rk3399.c | 79 > ++--- > 2 files changed, 88 insertions(+), 13 deletions(-) > Reviewed-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v5, 1/6] ARM: rockchip: rv1108: Sync clock with vendor tree
> Make adjustments to the rv1108 clock driver in order to align it > with the internal Rockchip version. > > Signed-off-by: Otavio Salvador > --- > > Changes in v5: > - applied changes sent by Vicent Chi > > Changes in v4: > - revert a wrong removal of devices > > Changes in v3: None > Changes in v2: None > > arch/arm/include/asm/arch-rockchip/clock.h| 6 + > .../include/asm/arch-rockchip/cru_rv1108.h| 144 +- > drivers/clk/rockchip/clk_rv1108.c | 475 +- > include/dt-bindings/clock/rv1108-cru.h| 137 - > 4 files changed, 729 insertions(+), 33 deletions(-) > Reviewed-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v5, 6/6] ARM: rockchip: rv1108: Add support for default distro_bootcmd
> This allow easier integration of RV1108 based boards on generic > distributions and build systems. > > To avoid behavior change, we make evb-rv1108 to use the existing > environment as it boots from its SPI NOR. > > Signed-off-by: Otavio Salvador > --- > > Changes in v5: None > Changes in v4: None > Changes in v3: None > Changes in v2: None > > include/configs/evb_rv1108.h| 3 +++ > include/configs/rv1108_common.h | 15 +++ > 2 files changed, 18 insertions(+) > Reviewed-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v5, 2/6] ARM: rockchip: rv1108: Enable BOUNCE_BUFFER
> In order to be able to build the Rockchip eMMC driver on rv1108, the > BOUNCE_BUFFER option needs to be selected. Select it like it is done > on the other Rockchip SoC common files. > > Reviewed-by: Andy Yan > Signed-off-by: Otavio Salvador > --- > > Changes in v5: None > Changes in v4: None > Changes in v3: > - rework commit log > > Changes in v2: > - new patch > > include/configs/rv1108_common.h | 3 +++ > 1 file changed, 3 insertions(+) > Reviewed-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v5, 5/6] ARM: dts: rockchip: Add rv1108 USB OTG pinctrl
> This adds the definitions need to use the USB OTG in rv1108 > board. This has been tested using USB Mass Storage to export and > program a eMMC device. > > Signed-off-by: Otavio Salvador > --- > > Changes in v5: None > Changes in v4: > - new patch > > Changes in v3: None > Changes in v2: None > > arch/arm/dts/rv1108.dtsi | 45 +--- > 1 file changed, 42 insertions(+), 3 deletions(-) > Reviewed-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v5, 4/6] ARM: rockchip: rv1108: Add a board_usb_init for USB OTG
> Like it is done for other Rockchip SoCs, introduce a board_usb_init() > function so that USB OTG can be functional on rv1108 too. > > Signed-off-by: Otavio Salvador > --- > > Changes in v5: None > Changes in v4: > - split out dts changes > > Changes in v3: > - rework commit log > > Changes in v2: None > > arch/arm/mach-rockchip/Makefile | 1 + > arch/arm/mach-rockchip/rv1108-board.c | 81 +++ > 2 files changed, 82 insertions(+) > create mode 100644 arch/arm/mach-rockchip/rv1108-board.c > Reviewed-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 3/6] ARM: dts: rockchip: Add rv1108 eMMC pinctrl
> On 30.11.2018, at 14:34, Otavio Salvador wrote: > > This adds the pinctrl handles to enable the use of eMMC on custom > boards (as minievk) and makes it easier for later addition. I forgot to remark that this is not really useful in U-Boot today, as the pinctrl driver does not parse the DTS... ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v5 2/3] rockchip: rk3399-puma: defconfig: enable FAN53555 regulator driver
With a driver for the FAN53555 regulator family available, let's enable it for the RK3399-Q7 (which has two of these devices on-module). We enable this for the full U-Boot stage only, as these regulators provide a suitable default voltage and supply non-critical (i.e. for booting up) power rails only. Signed-off-by: Philipp Tomsich --- Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None configs/puma-rk3399_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/puma-rk3399_defconfig b/configs/puma-rk3399_defconfig index bec03c7..e83a616 100644 --- a/configs/puma-rk3399_defconfig +++ b/configs/puma-rk3399_defconfig @@ -77,6 +77,7 @@ CONFIG_PINCTRL=y CONFIG_SPL_PINCTRL=y CONFIG_PINCTRL_ROCKCHIP_RK3399=y CONFIG_DM_PMIC=y +CONFIG_DM_PMIC_FAN53555=y CONFIG_PMIC_RK8XX=y CONFIG_SPL_DM_REGULATOR=y CONFIG_DM_REGULATOR_FIXED=y -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v5 1/3] power: add FAN53555 family support
This adds a driver for the FAN53555 family of regulators and wraps it
in a PMIC implementation.
While these devices support a 'normal' and 'suspend' mode (controlled
via an external pin) to switch between two programmable voltages, this
incarnation of the driver assumes that the device is always operating
in 'normal' mode.
Only setting/reading the programmed voltage is supported at this time
and the following device functionality remains unsupported:
- switching the selected voltage (via a GPIO)
- disabling the voltage output via software-control
This matches the functionality of the Linux driver.
Tested on a RK3399-Q7 (with 'option 5' devices): setting voltages from
the U-Boot shell and verifying output voltages on the board.
Signed-off-by: Philipp Tomsich
Tested-by: Klaus Goger
---
Changes in v5:
- introduced a PMIC (as requested by SJG) to wrap the single regulator
Changes in v4:
- fix issues introduced when updating for review comments (sorry for
this: my submit-branch had diverged from the WIP-branch I used for
testing and I didn't notice)
Changes in v3:
- update for review comments
Changes in v2:
- adapted documentation on the device-tree binding from Linux
doc/device-tree-bindings/regulator/fan53555.txt | 23 +++
drivers/power/pmic/Kconfig | 14 ++
drivers/power/pmic/Makefile | 1 +
drivers/power/pmic/fan53555.c | 82 +
drivers/power/regulator/Kconfig | 16 ++
drivers/power/regulator/Makefile| 1 +
drivers/power/regulator/fan53555.c | 222
7 files changed, 359 insertions(+)
create mode 100644 doc/device-tree-bindings/regulator/fan53555.txt
create mode 100644 drivers/power/pmic/fan53555.c
create mode 100644 drivers/power/regulator/fan53555.c
diff --git a/doc/device-tree-bindings/regulator/fan53555.txt
b/doc/device-tree-bindings/regulator/fan53555.txt
new file mode 100644
index 000..b183738
--- /dev/null
+++ b/doc/device-tree-bindings/regulator/fan53555.txt
@@ -0,0 +1,23 @@
+Binding for Fairchild FAN53555 regulators
+
+Required properties:
+ - compatible: "fcs,fan53555"
+ - reg: I2C address
+
+Optional properties:
+ - fcs,suspend-voltage-selector: declare which of the two available
+ voltage selector registers should be used for the suspend
+ voltage. The other one is used for the runtime voltage setting
+ Possible values are either <0> or <1>
+ - vin-supply: regulator supplying the vin pin
+
+Example:
+
+ regulator@40 {
+ compatible = "fcs,fan53555";
+ regulator-name = "fan53555";
+ regulator-min-microvolt = <100>;
+ regulator-max-microvolt = <180>;
+ vin-supply = <&parent_reg>;
+ fcs,suspend-voltage-selector = <1>;
+ };
diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig
index cba48e1..8cf60eb 100644
--- a/drivers/power/pmic/Kconfig
+++ b/drivers/power/pmic/Kconfig
@@ -48,6 +48,20 @@ config PMIC_AS3722
interface and is designs to cover most of the power managementment
required for a tablets or laptop.
+config DM_PMIC_FAN53555
+ bool "Enable support for OnSemi FAN53555"
+ depends on DM_PMIC && DM_REGULATOR && DM_I2C
+ select DM_REGULATOR_FAN53555
+ help
+ This config enables implementation of driver-model PMIC
+ uclass features for the FAN53555 regulator. The FAN53555 is
+ a (family of) single-output regulators that supports
+ transitioning between two different output voltages based on
+ an voltage selection pin.
+
+ The driver implements read/write operations for use with the FAN53555
+ regulator driver and binds the regulator driver to its node.
+
config DM_PMIC_PFUZE100
bool "Enable Driver Model for PMIC PFUZE100"
depends on DM_PMIC
diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
index 29ca442..637352a 100644
--- a/drivers/power/pmic/Makefile
+++ b/drivers/power/pmic/Makefile
@@ -4,6 +4,7 @@
# Lukasz Majewski
obj-$(CONFIG_DM_PMIC) += pmic-uclass.o
+obj-$(CONFIG_DM_PMIC_FAN53555) += fan53555.o
obj-$(CONFIG_DM_PMIC_MAX77686) += max77686.o
obj-$(CONFIG_DM_PMIC_MAX8998) += max8998.o
obj-$(CONFIG_DM_PMIC_MC34708) += mc34708.o
diff --git a/drivers/power/pmic/fan53555.c b/drivers/power/pmic/fan53555.c
new file mode 100644
index 000..1ca59c5
--- /dev/null
+++ b/drivers/power/pmic/fan53555.c
@@ -0,0 +1,82 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) 2018 Theobroma Systems Design und Consulting GmbH
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int pmic_fan53555_reg_count(struct udevice *dev)
+{
+ return 1;
+
[U-Boot] [PATCH v5 3/3] rockchip: rk3399-puma: enable fan53555 regulators in DTS
Now that we have FAN53555 support, we can enable the regulators in our
DTS. To make these easier to identify on the U-Boot commandline, we
rename them to the names of the voltage rails they control.
Signed-off-by: Philipp Tomsich
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
arch/arm/dts/rk3399-puma.dtsi | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/rk3399-puma.dtsi b/arch/arm/dts/rk3399-puma.dtsi
index 11ffcb7..ba9bb4c 100644
--- a/arch/arm/dts/rk3399-puma.dtsi
+++ b/arch/arm/dts/rk3399-puma.dtsi
@@ -218,7 +218,8 @@
i2c-scl-falling-time-ns = <4>;
clock-frequency = <40>;
- vdd_gpu: fan53@60 {
+ vdd_gpu: vdd_gpu {
+ status = "okay";
compatible = "fcs,fan53555";
reg = <0x60>;
vsel-gpios = <&gpio1 RK_PB6 GPIO_ACTIVE_HIGH>;
@@ -420,7 +421,8 @@
status = "okay";
clock-frequency = <40>;
- vdd_cpu_b: fan53555@60 {
+ vdd_cpu_b: vdd_cpu_b {
+ status = "okay";
compatible = "fcs,fan53555";
reg = <0x60>;
vsel-gpios = <&gpio1 RK_PA4 GPIO_ACTIVE_HIGH>;
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] rockchip: rk3399: Initialize CPU B clock.
On 30.11.2018, at 20:32, Christoph Muellner wrote: > > This patch sets the PLL of CPU cluster B (BPLL) to 600 MHz. > This decreases the boot time of Linux 4.19 by about 8%. > > The 600 MHz are inspired by the 600 MHz used for LPLL initialization > (came in with commit 9f636a249c1). > > Tested on RK3399-Q7 on Haikou base board. > > Changes since v1: > > * Set clk_core_b parent to BPLL instead of LPLL. > Kudos to Mark Kettenis for spotting this. > > Signed-off-by: Christoph Muellner 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] rockchip: rk3399: Initialize CPU B clock.
Christoph, On 30.11.2018, at 20:32, Christoph Muellner wrote: > > This patch sets the PLL of CPU cluster B (BPLL) to 600 MHz. > This decreases the boot time of Linux 4.19 by about 8%. > > The 600 MHz are inspired by the 600 MHz used for LPLL initialization > (came in with commit 9f636a249c1). > > Tested on RK3399-Q7 on Haikou base board. > > Changes since v1: > > * Set clk_core_b parent to BPLL instead of LPLL. > Kudos to Mark Kettenis for spotting this. Please use patman in the future (or format this as a note), so it can automatically get supressed when applying. For this specific instance, I will hand-edit when applying… Thanks, Philipp. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 1/2] rockchip: add support for veyron-speedy (ASUS Chromebook C201)
> This adds support for the ASUS C201, a RK3288-based clamshell > device. The device tree comes from linus's linux tree at > 3f16503b7d2274ac8cbab11163047ac0b4c66cfe. The SDRAM parameters > are for 4GB Samsung LPDDR3, decoded from coreboot's > src/mainboard/google/veyron/sdram_inf/sdram-lpddr3-samsung-4GB.inc > > Signed-off-by: Marty E. Plummer > Reviewed-by: Simon Glass > Reviewed-by: Philipp Tomsich > --- > arch/arm/dts/Makefile | 1 + > arch/arm/dts/rk3288-veyron-speedy-u-boot.dtsi | 31 > arch/arm/dts/rk3288-veyron-speedy.dts | 143 ++ > arch/arm/mach-rockchip/rk3288-board-spl.c | 3 +- > arch/arm/mach-rockchip/rk3288/Kconfig | 11 ++ > board/google/veyron/Kconfig | 16 ++ > configs/chromebook_speedy_defconfig | 98 > 7 files changed, 302 insertions(+), 1 deletion(-) > create mode 100644 arch/arm/dts/rk3288-veyron-speedy-u-boot.dtsi > create mode 100644 arch/arm/dts/rk3288-veyron-speedy.dts > create mode 100644 configs/chromebook_speedy_defconfig > 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] [U-Boot, v2, 2/2] rockchip: fix incorrect detection of ram size
> Taken from coreboot's src/soc/rockchip/rk3288/sdram.c > > Without this change, my u-boot build for the asus c201 chromebook (4GiB) > is incorrectly detected as 0 Bytes of ram. > > Signed-off-by: Marty E. Plummer > Reviewed-by: Philipp Tomsich > --- > arch/arm/mach-rockchip/sdram_common.c | 2 ++ > 1 file changed, 2 insertions(+) > Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
