Re: [PATCH v3 2/2] phy: mv88e61xx: add support for MV88E6171
On Tue, 5 Jan 2021, 10:28 AM Pawel Dembicki,
wrote:
> This patch add MV88E6171 id to driver data.
>
> Tested on Checkpoint L-50 board.
>
> Cc: Chris Packham
> Cc: Joe Hershberger
> Cc: Anatolij Gustschin
> Cc: Tim Harvey
> Signed-off-by: Pawel Dembicki
>
Looks good to me.
Reviewed-by: Chris Packham
---
> Changes in v3,v2:
> - resend only
> drivers/net/phy/mv88e61xx.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/net/phy/mv88e61xx.c b/drivers/net/phy/mv88e61xx.c
> index 3bcd2ba242..82f1587ff5 100644
> --- a/drivers/net/phy/mv88e61xx.c
> +++ b/drivers/net/phy/mv88e61xx.c
> @@ -183,6 +183,7 @@
> #define PORT_SWITCH_ID_60710x0710
> #define PORT_SWITCH_ID_60960x0980
> #define PORT_SWITCH_ID_60970x0990
> +#define PORT_SWITCH_ID_61710x1710
> #define PORT_SWITCH_ID_61720x1720
> #define PORT_SWITCH_ID_61760x1760
> #define PORT_SWITCH_ID_62200x2200
> @@ -1055,6 +1056,7 @@ static int mv88e61xx_probe(struct phy_device *phydev)
> switch (priv->id) {
> case PORT_SWITCH_ID_6096:
> case PORT_SWITCH_ID_6097:
> + case PORT_SWITCH_ID_6171:
> case PORT_SWITCH_ID_6172:
> case PORT_SWITCH_ID_6176:
> case PORT_SWITCH_ID_6240:
> @@ -1210,6 +1212,17 @@ static struct phy_driver mv88e61xx_driver = {
> .shutdown = &genphy_shutdown,
> };
>
> +static struct phy_driver mv88e617x_driver = {
> + .name = "Marvell MV88E617x",
> + .uid = 0x01410e70,
> + .mask = 0xfff0,
> + .features = PHY_GBIT_FEATURES,
> + .probe = mv88e61xx_probe,
> + .config = mv88e61xx_phy_config,
> + .startup = mv88e61xx_phy_startup,
> + .shutdown = &genphy_shutdown,
> +};
> +
> static struct phy_driver mv88e609x_driver = {
> .name = "Marvell MV88E609x",
> .uid = 0x1410c89,
> @@ -1235,6 +1248,7 @@ static struct phy_driver mv88e6071_driver = {
> int phy_mv88e61xx_init(void)
> {
> phy_register(&mv88e61xx_driver);
> + phy_register(&mv88e617x_driver);
> phy_register(&mv88e609x_driver);
> phy_register(&mv88e6071_driver);
>
> --
> 2.25.1
>
>
Re: [PATCH v3 1/2] phy: mv88e61xx: add support for RGMII TX/RX delay
On Tue, 5 Jan 2021, 10:28 AM Pawel Dembicki,
wrote:
> Clock delay in RGMII is required for some boards.
>
> Clock delay is read from phy-mode dts property. Delay is configured via
> proper bits in PORT_REG_PHYS_CTRL register.
>
> Cc: Chris Packham
> Cc: Joe Hershberger
> Cc: Anatolij Gustschin
> Cc: Tim Harvey
> Cc: Tom Rini
> Signed-off-by: Pawel Dembicki
>
Looks good to me.
Reviewed-by: Chris Packham
---
> Changes in v3:
> - clear initial values of RX and TX delay bit
> Changes in v2:
> - change source info about delay: from hardcode to phy-mode propoperty in
> dts
> drivers/net/phy/mv88e61xx.c | 66 -
> 1 file changed, 65 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/phy/mv88e61xx.c b/drivers/net/phy/mv88e61xx.c
> index 7eff37b244..3bcd2ba242 100644
> --- a/drivers/net/phy/mv88e61xx.c
> +++ b/drivers/net/phy/mv88e61xx.c
> @@ -97,6 +97,8 @@
> #define PORT_REG_STATUS_CMODE_1000BASE_X 0x9
> #define PORT_REG_STATUS_CMODE_SGMII0xa
>
> +#define PORT_REG_PHYS_CTRL_RGMII_RX_DELAY BIT(15)
> +#define PORT_REG_PHYS_CTRL_RGMII_TX_DELAY BIT(14)
> #define PORT_REG_PHYS_CTRL_PCS_AN_EN BIT(10)
> #define PORT_REG_PHYS_CTRL_PCS_AN_RST BIT(9)
> #define PORT_REG_PHYS_CTRL_FC_VALUEBIT(7)
> @@ -729,7 +731,45 @@ unforce:
> static int mv88e61xx_fixed_port_setup(struct phy_device *phydev, u8 port)
> {
> struct mv88e61xx_phy_priv *priv = phydev->priv;
> - int val;
> + ofnode node;
> + const char *str;
> + int val, phy_mode;
> + u32 phy_handle;
> +
> + if (!ofnode_valid(phydev->node)) {
> + node = dev_ofnode(phydev->dev);
> + phy_handle = ofnode_read_u32_default(node, "phy-handle",
> -ENXIO);
> +
> + if (phy_handle == -ENXIO) {
> + node = ofnode_first_subnode(node);
> +
> + while (ofnode_valid(node)) {
> + phy_handle = ofnode_read_u32_default(node,
> "phy-handle", -ENXIO);
> + if (phy_handle != -ENXIO)
> + break;
> + node = ofnode_next_subnode(node);
> + }
> + }
> +
> + if (phy_handle != -ENXIO)
> + node = ofnode_get_by_phandle(phy_handle);
> + else
> + node = ofnode_null();
> + } else {
> + node = phy_get_ofnode(phydev);
> + }
> +
> + node = ofnode_find_subnode(node, "ports");
> + node = ofnode_first_subnode(node);
> +
> + while (ofnode_valid(node)) {
> + u8 port_no = (u8)ofnode_read_u32_default(node, "reg", -1);
> +
> + if (port_no == port)
> + break;
> +
> + node = ofnode_next_subnode(node);
> + }
>
> val = mv88e61xx_port_read(phydev, port, PORT_REG_PHYS_CTRL);
> if (val < 0)
> @@ -754,6 +794,30 @@ static int mv88e61xx_fixed_port_setup(struct
> phy_device *phydev, u8 port)
> val |= PORT_REG_PHYS_CTRL_LINK_VALUE |
>PORT_REG_PHYS_CTRL_LINK_FORCE;
>
> + if (ofnode_valid(node)) {
> + str = ofnode_read_string(node, "phy-mode");
> + if (str) {
> + phy_mode = phy_get_interface_by_name(str);
> + val &= ~(PORT_REG_PHYS_CTRL_RGMII_RX_DELAY |
> + PORT_REG_PHYS_CTRL_RGMII_TX_DELAY);
> +
> + switch (phy_mode) {
> + case PHY_INTERFACE_MODE_RGMII_ID:
> + val |= PORT_REG_PHYS_CTRL_RGMII_RX_DELAY;
> + val |= PORT_REG_PHYS_CTRL_RGMII_TX_DELAY;
> + break;
> + case PHY_INTERFACE_MODE_RGMII_RXID:
> + val |= PORT_REG_PHYS_CTRL_RGMII_RX_DELAY;
> + break;
> + case PHY_INTERFACE_MODE_RGMII_TXID:
> + val |= PORT_REG_PHYS_CTRL_RGMII_TX_DELAY;
> + break;
> + default:
> + break;
> + }
> + }
> + }
> +
> return mv88e61xx_port_write(phydev, port, PORT_REG_PHYS_CTRL,
>val);
> }
> --
> 2.25.1
>
>
Re: [PATCH v2 2/2] riscv: timer: Add support for an early timer
On Tue, Jan 5, 2021 at 7:12 AM Sean Anderson wrote: > > On 1/4/21 8:37 PM, Rick Chen wrote: > > Hi Pragnesh > > > >>> From: Pragnesh Patel [mailto:pragnesh.pa...@sifive.com] > >>> Sent: Tuesday, December 22, 2020 2:23 PM > >>> To: u-boot@lists.denx.de > >>> Cc: atish.pa...@wdc.com; palmerdabb...@google.com; bmeng...@gmail.com; > >>> paul.walms...@sifive.com; anup.pa...@wdc.com; sagar.ka...@sifive.com; > >>> Rick Jian-Zhi Chen(陳建志); pragnesh.pa...@openfive.com; Pragnesh Patel; > >>> Palmer Dabbelt; Sean Anderson; Claudiu Beznea; Simon Glass > >>> Subject: [PATCH v2 2/2] riscv: timer: Add support for an early timer > >>> > >>> Added support for timer_early_get_count() and timer_early_get_rate() > >>> This is mostly useful in tracing. > >>> > >>> Signed-off-by: Pragnesh Patel > >>> --- > >>> > >>> Changes in v2: > >>> - make u-boot compile for qemu (include/configs/qemu-riscv.h) > >>> > >>> drivers/timer/andes_plmt_timer.c | 21 - > >>> drivers/timer/riscv_timer.c| 21 - > >>> drivers/timer/sifive_clint_timer.c | 21 - > >>> include/configs/ax25-ae350.h | 5 + > >>> include/configs/qemu-riscv.h | 5 + > >>> include/configs/sifive-fu540.h | 5 + > >>> 6 files changed, 75 insertions(+), 3 deletions(-) > >> > >> Reviewed-by: Rick Chen > > > > Please check about the CI failure item: > > https://gitlab.denx.de/u-boot/custodians/u-boot-riscv/-/jobs/196578 > > 404 for me (though I suspect it's really a 403). 404 for me also. > > --Sean >
Re: [PATCH] Nokia RX-51: Do not try calling both ext2load and ext4load
On 01/12/20 12:40 am, Pali Rohár wrote:
> Those two commands now doing same thing, reading from ext2/3/4 filesystem.
> So remove useless duplicated call.
>
> Signed-off-by: Pali Rohár
Applied to u-boot-ti/for-next branch
Thanks and regards,
Lokesh
> ---
> include/configs/nokia_rx51.h | 17 +++--
> 1 file changed, 3 insertions(+), 14 deletions(-)
>
> diff --git a/include/configs/nokia_rx51.h b/include/configs/nokia_rx51.h
> index 6879f52a0c..3f2700d8e2 100644
> --- a/include/configs/nokia_rx51.h
> +++ b/include/configs/nokia_rx51.h
> @@ -169,8 +169,6 @@ int rx51_kp_getc(struct stdio_dev *sdev);
> "trymmcboot=if run switchmmc; then " \
> "setenv mmctype fat;" \
> "run trymmcallpartboot;" \
> - "setenv mmctype ext2;" \
> - "run trymmcallpartboot;" \
> "setenv mmctype ext4;" \
> "run trymmcallpartboot;" \
> "fi\0" \
> @@ -179,19 +177,10 @@ int rx51_kp_getc(struct stdio_dev *sdev);
> "preboot=setenv mmcnum 1; setenv mmcpart 1;" \
> "setenv mmcscriptfile bootmenu.scr;" \
> "if run switchmmc; then " \
> - "setenv mmcdone true;" \
> "setenv mmctype fat;" \
> - "if run scriptload; then true; else " \
> - "setenv mmctype ext2;" \
> - "if run scriptload; then true; else " \
> - "setenv mmctype ext4;" \
> - "if run scriptload; then true; else " \
> - "setenv mmcdone false;" \
> - "fi;" \
> - "fi;" \
> - "fi;" \
> - "if ${mmcdone}; then " \
> - "run scriptboot;" \
> + "if run scriptload; then run scriptboot; else " \
> + "setenv mmctype ext4;" \
> + "if run scriptload; then run scriptboot; fi;" \
> "fi;" \
> "fi;" \
> "if run slide; then true; else " \
>
Re: [PATCH] Nokia RX-51: Convert to CONFIG_DM_MMC
On 22/11/20 4:03 am, Pali Rohár wrote:
> Move twl4030_power_mmc_init() from board_mmc_power_init() to misc_init_r()
> and disable CONFIG_SYS_MALLOC_F. Otherwise U-Boot cannot initialize MMC.
> Also disable CONFIG_CMD_SLEEP and CONFIG_DM_DEVICE_REMOVE to free some
> space.
>
> Signed-off-by: Pali Rohár
> ---
> board/nokia/rx51/rx51.c | 32
> configs/nokia_rx51_defconfig | 4
> 2 files changed, 20 insertions(+), 16 deletions(-)
>
> diff --git a/board/nokia/rx51/rx51.c b/board/nokia/rx51/rx51.c
> index 2dd41604c9..7390e5be65 100644
> --- a/board/nokia/rx51/rx51.c
> +++ b/board/nokia/rx51/rx51.c
> @@ -415,6 +415,8 @@ int misc_init_r(void)
>
> /* initialize twl4030 power managment */
> twl4030_power_init();
> + twl4030_power_mmc_init(0);
> + twl4030_power_mmc_init(1);
>
> /* set VSIM to 1.8V */
> twl4030_pmrecv_vsel_cfg(TWL4030_PM_RECEIVER_VSIM_DEDICATED,
> @@ -686,22 +688,18 @@ int rx51_kp_getc(struct stdio_dev *sdev)
> return keybuf[keybuf_head++];
> }
>
> -/*
> - * Routine: board_mmc_init
> - * Description: Initialize mmc devices.
> - */
> -int board_mmc_init(struct bd_info *bis)
> -{
> - omap_mmc_init(0, 0, 0, -1, -1);
> - omap_mmc_init(1, 0, 0, -1, -1);
> - return 0;
> -}
> +static const struct mmc_config rx51_mmc_cfg = {
> + .host_caps = MMC_MODE_4BIT | MMC_MODE_HS_52MHz | MMC_MODE_HS,
> + .f_min = 40,
> + .f_max = 5200,
> + .b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT,
> + .voltages = MMC_VDD_32_33 | MMC_VDD_33_34 | MMC_VDD_165_195,
> +};
>
> -void board_mmc_power_init(void)
> -{
> - twl4030_power_mmc_init(0);
> - twl4030_power_mmc_init(1);
> -}
> +static const struct omap_hsmmc_plat rx51_mmc[] = {
> + { rx51_mmc_cfg, (struct hsmmc *)OMAP_HSMMC1_BASE },
> + { rx51_mmc_cfg, (struct hsmmc *)OMAP_HSMMC2_BASE },
> +};
>
> static const struct omap_i2c_platdata rx51_i2c[] = {
> { I2C_BASE1, 10, OMAP_I2C_REV_V1 },
> @@ -709,7 +707,9 @@ static const struct omap_i2c_platdata rx51_i2c[] = {
> { I2C_BASE3, 10, OMAP_I2C_REV_V1 },
> };
>
> -U_BOOT_DEVICES(rx51_i2c) = {
> +U_BOOT_DEVICES(rx51) = {
> + { "omap_hsmmc", &rx51_mmc[0] },
> + { "omap_hsmmc", &rx51_mmc[1] },
> { "i2c_omap", &rx51_i2c[0] },
> { "i2c_omap", &rx51_i2c[1] },
> { "i2c_omap", &rx51_i2c[2] },
> diff --git a/configs/nokia_rx51_defconfig b/configs/nokia_rx51_defconfig
> index 6310a12aaa..0f05fe6fc3 100644
> --- a/configs/nokia_rx51_defconfig
> +++ b/configs/nokia_rx51_defconfig
> @@ -29,6 +29,7 @@ CONFIG_CMD_BOOTMENU=y
> # CONFIG_CMD_SAVEENV is not set
> # CONFIG_CMD_ENV_EXISTS is not set
> # CONFIG_CMD_FLASH is not set
> +# CONFIG_CMD_SLEEP is not set
> CONFIG_CMD_GPIO=y
> CONFIG_CMD_I2C=y
> CONFIG_CMD_MMC=y
> @@ -62,3 +63,6 @@ CONFIG_SPLASH_SCREEN=y
> # CONFIG_GZIP is not set
> CONFIG_DM=y
> CONFIG_DM_I2C=y
> +CONFIG_DM_MMC=y
> +# CONFIG_DM_DEVICE_REMOVE is not set
> +# CONFIG_SYS_MALLOC_F is not set
As you suggested disabled MMC_VERBOSE and applied to u-boot-ti/for-next branch.
Thanks and regards,
Lokesh
>
Re: [PATCH] Nokia RX-51: Decrease i2c speed to 100000
On 22/11/20 4:00 am, Pali Rohár wrote:
> It looks like that i2c bus lot of times timeout on some units. Prior
> migration to CONFIG_DM_I2C i2c speed was set to CONFIG_SYS_OMAP24_I2C_SPEED
> value which was 10. Lower speed fixes timeout problems, so change speed
> back to its previous value.
>
> Signed-off-by: Pali Rohár
> Fixes: 8d8c18170325 ("Nokia RX-51: Convert to CONFIG_DM_I2C")
Applied to u-boot-ti/for-next branch
Thanks and regards,
Lokesh
> ---
> Please include this patch into U-Boot master branch for 2020.01 release
> to have i2c bus working.
> ---
> board/nokia/rx51/rx51.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/board/nokia/rx51/rx51.c b/board/nokia/rx51/rx51.c
> index 3d62b5d9ad..2dd41604c9 100644
> --- a/board/nokia/rx51/rx51.c
> +++ b/board/nokia/rx51/rx51.c
> @@ -704,9 +704,9 @@ void board_mmc_power_init(void)
> }
>
> static const struct omap_i2c_platdata rx51_i2c[] = {
> - { I2C_BASE1, 220, OMAP_I2C_REV_V1 },
> + { I2C_BASE1, 10, OMAP_I2C_REV_V1 },
> { I2C_BASE2, 10, OMAP_I2C_REV_V1 },
> - { I2C_BASE3, 40, OMAP_I2C_REV_V1 },
> + { I2C_BASE3, 10, OMAP_I2C_REV_V1 },
> };
>
> U_BOOT_DEVICES(rx51_i2c) = {
>
Re: [linux-sunxi] [PATCH 11/17] sunxi: Add H616 DRAM support
On 1/4/21 12:39 PM, Jernej Škrabec wrote:
> Dne ponedeljek, 04. januar 2021 ob 03:39:52 CET je Samuel Holland napisal(a):
>> On 1/3/21 3:26 AM, Jernej Skrabec wrote:
>>> Allwinner H616 supports many types of DRAM. Most notably it supports
>>> LPDDR4. However, all commercially available boards at this time use
>>> only DDR3, so this commit adds only DDR3 support.
>>>
>>> Controller and MBUS are very similar to H6 but PHY is completely
>>> unknown.
>>>
>>> Signed-off-by: Jernej Skrabec
>>> ---
>>>
>>> arch/arm/include/asm/arch-sunxi/dram.h|2 +
>>> .../include/asm/arch-sunxi/dram_sun50i_h616.h | 159 +++
>>> arch/arm/mach-sunxi/Kconfig | 43 +
>>> arch/arm/mach-sunxi/Makefile |2 +
>>> arch/arm/mach-sunxi/dram_sun50i_h616.c| 1023 +
>>> arch/arm/mach-sunxi/dram_timings/Makefile |2 +
>>> .../mach-sunxi/dram_timings/h616_ddr3_1333.c | 94 ++
>>> 7 files changed, 1325 insertions(+)
>>> create mode 100644 arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
>>> create mode 100644 arch/arm/mach-sunxi/dram_sun50i_h616.c
>>> create mode 100644 arch/arm/mach-sunxi/dram_timings/h616_ddr3_1333.c
>>>
>>> diff --git a/arch/arm/include/asm/arch-sunxi/dram.h
>>> b/arch/arm/include/asm/arch-sunxi/dram.h index 8002b7efdc19..c3b3e1f512b2
>>> 100644
>>> --- a/arch/arm/include/asm/arch-sunxi/dram.h
>>> +++ b/arch/arm/include/asm/arch-sunxi/dram.h
>>> @@ -29,6 +29,8 @@
>>>
>>> #include
>>> #elif defined(CONFIG_MACH_SUN50I_H6)
>>> #include
>>>
>>> +#elif defined(CONFIG_MACH_SUN50I_H616)
>>> +#include
>>>
>>> #else
>>> #include
>>> #endif
>>>
>>> diff --git a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
>>> b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h new file mode 100644
>>> index ..5d105afd6110
>>> --- /dev/null
>>> +++ b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
>>> @@ -0,0 +1,159 @@
>>> +/*
>>> + * H616 dram controller register and constant defines
>>> + *
>>> + * (C) Copyright 2020 Jernej Skrabec
>>> + *
>>> + * Based on H6 one, which is:
>>> + * (C) Copyright 2017 Icenowy Zheng
>>> + *
>>> + * SPDX-License-Identifier:GPL-2.0+
>>> + */
>>> +
>>> +#ifndef _SUNXI_DRAM_SUN50I_H616_H
>>> +#define _SUNXI_DRAM_SUN50I_H616_H
>>> +
>>> +#include
>>> +#ifndef __ASSEMBLY__
>>> +#include
>>> +#endif
>>> +
>>> +enum sunxi_dram_type {
>>> + SUNXI_DRAM_TYPE_DDR3 = 3,
>>> + SUNXI_DRAM_TYPE_DDR4,
>>> + SUNXI_DRAM_TYPE_LPDDR3 = 7,
>>> + SUNXI_DRAM_TYPE_LPDDR4
>>> +};
>>> +
>>> +/* MBUS part is largely the same as in H6, except for one special
>>> register */ +struct sunxi_mctl_com_reg {
>>> + u32 cr; /* 0x000 control register */
>>> + u8 reserved_0x004[4]; /* 0x004 */
>>> + u32 unk_0x008; /* 0x008 */
>>> + u32 tmr;/* 0x00c timer register */
>>> + u8 reserved_0x010[4]; /* 0x010 */
>>> + u32 unk_0x014; /* 0x014 */
>>> + u8 reserved_0x018[8]; /* 0x018 */
>>> + u32 maer0; /* 0x020 master enable register 0 */
>>> + u32 maer1; /* 0x024 master enable register 1 */
>>> + u32 maer2; /* 0x028 master enable register 2 */
>>> + u8 reserved_0x02c[468]; /* 0x02c */
>>> + u32 bwcr; /* 0x200 bandwidth control register */
>>> + u8 reserved_0x204[12]; /* 0x204 */
>>> + /*
>>> +* The last master configured by BSP libdram is at 0x49x, so the
>>> +* size of this struct array is set to 41 (0x29) now.
>>> +*/
>>> + struct {
>>> + u32 cfg0; /* 0x0 */
>>> + u32 cfg1; /* 0x4 */
>>> + u8 reserved_0x8[8]; /* 0x8 */
>>> + } master[41]; /* 0x210 + index * 0x10 */
>>> + u8 reserved_0x4a0[96]; /* 0x4a0 */
>>> + u32 unk_0x500; /* 0x500 */
>>> +};
>>> +check_member(sunxi_mctl_com_reg, unk_0x500, 0x500);
>>> +
>>> +/*
>>> + * Controller registers seems to be the same or at least very similar
>>> + * to those in H6.
>>> + */
>>> +struct sunxi_mctl_ctl_reg {
>>> + u32 mstr; /* 0x000 */
>>> + u32 statr; /* 0x004 unused */
>>> + u32 mstr1; /* 0x008 unused */
>>> + u32 unk_0x00c; /* 0x00c */
>>
>> This is clken (and the same on H6). It is obvious when looking at the
>> standby power-down sequence.
>
> Where is that sequence? I mostly consulted H6 and Zynq docs where this
> register is not explained. I'll update it in next revision.
This is from the H6 ARISC firmware, which has a similar structure to earlier
generations with known registers.
Cheers,
Samuel
> Best regards,
> Jernej
>
>>
>>> + u32 mrctrl0;/* 0x010 unused */
>>> + u32 mrctrl1;/* 0x014 unused */
>>> + u32 mrstatr;/* 0x018 unused */
>>> + u32 mrctrl2;/* 0x01c unused */
>>> + u32 derateen; /* 0x020 unused */
>>> + u32 derateint; /* 0x024 unused */
>>> + u8 reserved_0x028[8]; /* 0x028 *
Re: [PATCH 6/8 v2] efi_loader: Replace config option with EFI variable for initrd loading
On Wed, Dec 30, 2020 at 05:07:18PM +0200, Ilias Apalodimas wrote:
> Up to now we install EFI_LOAD_FILE2_PROTOCOL to load an initrd
> unconditionally. Although we correctly return various EFI exit codes
> depending on the file status (i.e EFI_NO_MEDIA, EFI_NOT_FOUND etc), the
> kernel loader, only falls back to the cmdline interpreted initrd if the
> protocol is not installed.
>
> This creates a problem for EFI installers, since they won't be able to
> load their own initrd and continue the installation. It also makes the
> feature hard to use, since we can either have a single initrd or we have
> to recompile u-boot if the filename changes.
>
> So let's introduce a different logic that will decouple the initrd
> path from the config option we currently have.
> When the EFI application is launched through the bootmgr, we'll try to
> match the BootCurrent value to an Initrd EFI variable.
> e.g Boot -> Initrd, Boot0010 -> Initrd0010 etc.
Do you think this semantics be kept U-boot specific?
It seems that it can work for any other EFI firmware (implementation).
> The Initrd EFI variable is expected to include the full file path,
> i.e 'mmc 0:1 initrd'. If the file is found, we'll install the
If so, the content of "Initrd" should contain a generic EFI
representation of file path.
Please note that "Boot" internally contains a flattened string of
"EFI device path" to the image while efidebug command accepts a style of
"mmc 0:1 image" as arguments to "efidebug boot add" sub-command.
-Takahiro Akashi
> appropriate protocol so the kernel's efi-stub can use it and load our
> initrd. If the file is not found the kernel will still try to load an
> initrd parsing the kernel cmdline, since the protocol won't be installed.
>
> This opens up another path using U-Boot and defines a new boot flow.
> A user will be able to control the kernel/initrd pairs without explicit
> cmdline args or GRUB. So we can base the whole boot flow on the Boot
> and Initrd paired values.
>
> Suggested-by: Heinrich Schuchardt
> Signed-off-by: Ilias Apalodimas
> ---
> cmd/bootefi.c| 13 +
> include/efi_loader.h | 2 +-
> lib/efi_loader/Kconfig | 13 ++---
> lib/efi_loader/efi_load_initrd.c | 93 ++--
> 4 files changed, 46 insertions(+), 75 deletions(-)
>
> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> index fdf909f8da2c..0234b0df2258 100644
> --- a/cmd/bootefi.c
> +++ b/cmd/bootefi.c
> @@ -377,6 +377,19 @@ static int do_efibootmgr(void)
> return CMD_RET_FAILURE;
> }
>
> + /* efi_exit() will delete all protocols and the handle itself on exit */
> + if (IS_ENABLED(CONFIG_EFI_LOAD_FILE2_INITRD)) {
> + ret = efi_initrd_register(&handle);
> + /* Just warn the user. If the installation fails, the kernel
> + * either load an initrd specificied in the cmdline or fail
> + * to boot.
> + * If we decide to fail the command here we need to uninstall
> + * the protocols efi_bootmgr_load() installed
> + */
> + if (ret != EFI_SUCCESS)
> + log_warning("EFI boot manager: Failed to install
> Loadfile2 for initrd\n");
> + }
> +
> ret = do_bootefi_exec(handle, load_options);
>
> if (ret != EFI_SUCCESS)
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index af30dbafab77..000cc942e31c 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -422,7 +422,7 @@ efi_status_t efi_gop_register(void);
> efi_status_t efi_net_register(void);
> /* Called by bootefi to make the watchdog available */
> efi_status_t efi_watchdog_register(void);
> -efi_status_t efi_initrd_register(void);
> +efi_status_t efi_initrd_register(efi_handle_t *initrd_handle);
> /* Called by bootefi to make SMBIOS tables available */
> /**
> * efi_acpi_register() - write out ACPI tables
> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> index dd8b93bd3c5a..96b5934a221d 100644
> --- a/lib/efi_loader/Kconfig
> +++ b/lib/efi_loader/Kconfig
> @@ -212,14 +212,11 @@ config EFI_LOAD_FILE2_INITRD
> help
> Expose a EFI_FILE_LOAD2_PROTOCOL that the Linux UEFI stub can
> use to load the initial ramdisk. Once this is enabled using
> - initrd= will stop working.
> -
> -config EFI_INITRD_FILESPEC
> - string "initramfs path"
> - default "host 0:1 initrd"
> - depends on EFI_LOAD_FILE2_INITRD
> - help
> - Full path of the initramfs file, e.g. mmc 0:2 initramfs.cpio.gz.
> + initrd= will stop working. The protocol will only be
> + installed if bootmgr is used and the file is found on the defined
> + path. A boot entry of Boot0001 will try to match Initrd0001 and use
> + it. Initrd EFI variable format should be ' '
> + i.e 'mmc 0:1 boot/initrd'
>
> config EFI_SECURE_BOOT
> bool "Enable EFI secure boot suppor
Re: [PATCH v7 2/7] net: macb: Add DMA 64-bit address support for macb
Hi Joe
> From: Padmarao Begari [mailto:padmarao.beg...@microchip.com]
> Sent: Tuesday, December 22, 2020 9:12 PM
> To: u-boot@lists.denx.de; bmeng...@gmail.com; Rick Jian-Zhi Chen(陳建志);
> anup.pa...@wdc.com; lukas.a...@aisec.fraunhofer.de; joe.hershber...@ni.com;
> lu...@denx.de; atish.pa...@wdc.com
> Cc: cyril.j...@microchip.com; lewis.ha...@microchip.com;
> ivan.grif...@emdalo.com; daire.mcnam...@emdalo.com;
> conor.doo...@microchip.com; Padmarao Begari
> Subject: [PATCH v7 2/7] net: macb: Add DMA 64-bit address support for macb
>
> Enable 32-bit or 64-bit DMA in the macb driver based on the macb
> hardware compatibility and it is configured with structure macb_config
> in the driver.
>
> The Microchip PolarFire SoC Memory Protection Unit(MPU) gives the 64-bit
> DMA access with the GEM, the MPU transactions on the AXI bus is 64-bit
> not 32-bit So 64-bit DMA is enabled for the Microchip PolarFire SoC GEM.
>
> Signed-off-by: Padmarao Begari
> Reviewed-by: Anup Patel
> Tested-by: Bin Meng
> ---
> drivers/net/macb.c | 131 +++--
> drivers/net/macb.h | 6 +++
> 2 files changed, 120 insertions(+), 17 deletions(-)
>
Do you have any comment with this series about net macb driver.
If you are ok with it, I will pull via riscv tree.
Thanks,
Rick
> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
> index b80a259ff7..626ee49227 100644
> --- a/drivers/net/macb.c
> +++ b/drivers/net/macb.c
> @@ -83,7 +83,16 @@ struct macb_dma_desc {
> u32 ctrl;
> };
>
> -#define DMA_DESC_BYTES(n) (n * sizeof(struct macb_dma_desc))
> +struct macb_dma_desc_64 {
> + u32 addrh;
> + u32 unused;
> +};
> +
> +#define HW_DMA_CAP_32B 0
> +#define HW_DMA_CAP_64B 1
> +
> +#define DMA_DESC_SIZE 16
> +#define DMA_DESC_BYTES(n) ((n) * DMA_DESC_SIZE)
> #define MACB_TX_DMA_DESC_SIZE (DMA_DESC_BYTES(MACB_TX_RING_SIZE))
> #define MACB_RX_DMA_DESC_SIZE (DMA_DESC_BYTES(MACB_RX_RING_SIZE))
> #define MACB_TX_DUMMY_DMA_DESC_SIZE(DMA_DESC_BYTES(1))
> @@ -137,6 +146,7 @@ struct macb_device {
>
> struct macb_config {
> unsigned intdma_burst_length;
> + unsigned inthw_dma_cap;
>
> int (*clk_init)(struct udevice *dev, ulong rate);
> };
> @@ -307,6 +317,24 @@ static inline void macb_invalidate_rx_buffer(struct
> macb_device *macb)
>
> #if defined(CONFIG_CMD_NET)
>
> +static struct macb_dma_desc_64 *macb_64b_desc(struct macb_dma_desc *desc)
> +{
> + return (struct macb_dma_desc_64 *)((void *)desc
> + + sizeof(struct macb_dma_desc));
> +}
> +
> +static void macb_set_addr(struct macb_device *macb, struct macb_dma_desc
> *desc,
> + ulong addr)
> +{
> + struct macb_dma_desc_64 *desc_64;
> +
> + if (macb->config->hw_dma_cap & HW_DMA_CAP_64B) {
> + desc_64 = macb_64b_desc(desc);
> + desc_64->addrh = upper_32_bits(addr);
> + }
> + desc->addr = lower_32_bits(addr);
> +}
> +
> static int _macb_send(struct macb_device *macb, const char *name, void
> *packet,
> int length)
> {
> @@ -325,8 +353,12 @@ static int _macb_send(struct macb_device *macb, const
> char *name, void *packet,
> macb->tx_head++;
> }
>
> + if (macb->config->hw_dma_cap & HW_DMA_CAP_64B)
> + tx_head = tx_head * 2;
> +
> macb->tx_ring[tx_head].ctrl = ctrl;
> - macb->tx_ring[tx_head].addr = paddr;
> + macb_set_addr(macb, &macb->tx_ring[tx_head], paddr);
> +
> barrier();
> macb_flush_ring_desc(macb, TX);
> macb_writel(macb, NCR, MACB_BIT(TE) | MACB_BIT(RE) |
> MACB_BIT(TSTART));
> @@ -363,19 +395,28 @@ static void reclaim_rx_buffers(struct macb_device *macb,
>unsigned int new_tail)
> {
> unsigned int i;
> + unsigned int count;
>
> i = macb->rx_tail;
>
> macb_invalidate_ring_desc(macb, RX);
> while (i > new_tail) {
> - macb->rx_ring[i].addr &= ~MACB_BIT(RX_USED);
> + if (macb->config->hw_dma_cap & HW_DMA_CAP_64B)
> + count = i * 2;
> + else
> + count = i;
> + macb->rx_ring[count].addr &= ~MACB_BIT(RX_USED);
> i++;
> if (i > MACB_RX_RING_SIZE)
> i = 0;
> }
>
> while (i < new_tail) {
> - macb->rx_ring[i].addr &= ~MACB_BIT(RX_USED);
> + if (macb->config->hw_dma_cap & HW_DMA_CAP_64B)
> + count = i * 2;
> + else
> + count = i;
> + macb->rx_ring[count].addr &= ~MACB_BIT(RX_USED);
> i++;
> }
>
> @@ -390,16 +431,25 @@ static int _macb_recv(struct macb_device *macb, uchar
> **packetp)
> void *buffer;
> int length;
> u32 status;
> +
Re: [PATCH v2 2/2] riscv: timer: Add support for an early timer
On 1/4/21 8:37 PM, Rick Chen wrote: Hi Pragnesh From: Pragnesh Patel [mailto:pragnesh.pa...@sifive.com] Sent: Tuesday, December 22, 2020 2:23 PM To: u-boot@lists.denx.de Cc: atish.pa...@wdc.com; palmerdabb...@google.com; bmeng...@gmail.com; paul.walms...@sifive.com; anup.pa...@wdc.com; sagar.ka...@sifive.com; Rick Jian-Zhi Chen(陳建志); pragnesh.pa...@openfive.com; Pragnesh Patel; Palmer Dabbelt; Sean Anderson; Claudiu Beznea; Simon Glass Subject: [PATCH v2 2/2] riscv: timer: Add support for an early timer Added support for timer_early_get_count() and timer_early_get_rate() This is mostly useful in tracing. Signed-off-by: Pragnesh Patel --- Changes in v2: - make u-boot compile for qemu (include/configs/qemu-riscv.h) drivers/timer/andes_plmt_timer.c | 21 - drivers/timer/riscv_timer.c| 21 - drivers/timer/sifive_clint_timer.c | 21 - include/configs/ax25-ae350.h | 5 + include/configs/qemu-riscv.h | 5 + include/configs/sifive-fu540.h | 5 + 6 files changed, 75 insertions(+), 3 deletions(-) Reviewed-by: Rick Chen Please check about the CI failure item: https://gitlab.denx.de/u-boot/custodians/u-boot-riscv/-/jobs/196578 404 for me (though I suspect it's really a 403). --Sean
Re: [PATCH v2 2/2] riscv: timer: Add support for an early timer
Hi Pragnesh > > From: Pragnesh Patel [mailto:pragnesh.pa...@sifive.com] > > Sent: Tuesday, December 22, 2020 2:23 PM > > To: u-boot@lists.denx.de > > Cc: atish.pa...@wdc.com; palmerdabb...@google.com; bmeng...@gmail.com; > > paul.walms...@sifive.com; anup.pa...@wdc.com; sagar.ka...@sifive.com; Rick > > Jian-Zhi Chen(陳建志); pragnesh.pa...@openfive.com; Pragnesh Patel; Palmer > > Dabbelt; Sean Anderson; Claudiu Beznea; Simon Glass > > Subject: [PATCH v2 2/2] riscv: timer: Add support for an early timer > > > > Added support for timer_early_get_count() and timer_early_get_rate() > > This is mostly useful in tracing. > > > > Signed-off-by: Pragnesh Patel > > --- > > > > Changes in v2: > > - make u-boot compile for qemu (include/configs/qemu-riscv.h) > > > > drivers/timer/andes_plmt_timer.c | 21 - > > drivers/timer/riscv_timer.c| 21 - > > drivers/timer/sifive_clint_timer.c | 21 - > > include/configs/ax25-ae350.h | 5 + > > include/configs/qemu-riscv.h | 5 + > > include/configs/sifive-fu540.h | 5 + > > 6 files changed, 75 insertions(+), 3 deletions(-) > > Reviewed-by: Rick Chen Please check about the CI failure item: https://gitlab.denx.de/u-boot/custodians/u-boot-riscv/-/jobs/196578 Thanks, Rick
Re: [PATCH v2] cmd: mmc: add mmcboot command
On 1/5/21 3:40 AM, Ravik Hasija wrote:
> Similar to usbboot, add command line to boot from raw mmc partition
> using common_diskboot(), which supports legacy or FIT images.
>
> Usage:
> mmcboot [loadAaddr] [dev:part]
>
> Where [loadAddr] defaults to CONFIG_SYS_LOAD_ADDR, and [dev:part]
> defaults to ${bootdevice}.
>
> Also fixing config macro usage for CONFIG_SUPPORT_EMMC_BOOT (suggested
> by checkpatch.pl).
>
> Signed-off-by: Ravik Hasija
> Signed-off-by: Dhananjay Phadke
> Reviewed-by: Jaehoon Chung
> Reviewed-by: Simon Glass
> ---
> v2:
> * Fixed build failure.
> * Updated syntax of mmcboot cmd.
> ---
> cmd/Makefile | 2 +-
> cmd/mmc.c| 22 +++---
> 2 files changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/cmd/Makefile b/cmd/Makefile
> index dd86675bf2..573e4776f5 100644
> --- a/cmd/Makefile
> +++ b/cmd/Makefile
> @@ -97,7 +97,7 @@ obj-$(CONFIG_CMD_MII) += mii.o
> obj-$(CONFIG_CMD_MISC) += misc.o
> obj-$(CONFIG_CMD_MDIO) += mdio.o
> obj-$(CONFIG_CMD_SLEEP) += sleep.o
> -obj-$(CONFIG_CMD_MMC) += mmc.o
> +obj-$(CONFIG_CMD_MMC) += mmc.o disk.o
I think that it's not good about building disk.c by default when CONFIG_CMD_MMC
is enabled.
Best Regards,
Jaehoon Chung
> obj-$(CONFIG_CMD_OPTEE_RPMB) += optee_rpmb.o
> obj-$(CONFIG_MP) += mp.o
> obj-$(CONFIG_CMD_MTD) += mtd.o
> diff --git a/cmd/mmc.c b/cmd/mmc.c
> index 1529a3e05d..0c3ed6c108 100644
> --- a/cmd/mmc.c
> +++ b/cmd/mmc.c
> @@ -711,7 +711,7 @@ static int do_mmc_hwpartition(struct cmd_tbl *cmdtp, int
> flag,
> }
> #endif
>
> -#ifdef CONFIG_SUPPORT_EMMC_BOOT
> +#if CONFIG_IS_ENABLED(SUPPORT_EMMC_BOOT)
> static int do_mmc_bootbus(struct cmd_tbl *cmdtp, int flag,
> int argc, char *const argv[])
> {
> @@ -950,7 +950,7 @@ static struct cmd_tbl cmd_mmc[] = {
> #if CONFIG_IS_ENABLED(MMC_HW_PARTITIONING)
> U_BOOT_CMD_MKENT(hwpartition, 28, 0, do_mmc_hwpartition, "", ""),
> #endif
> -#ifdef CONFIG_SUPPORT_EMMC_BOOT
> +#if CONFIG_IS_ENABLED(SUPPORT_EMMC_BOOT)
> U_BOOT_CMD_MKENT(bootbus, 5, 0, do_mmc_bootbus, "", ""),
> U_BOOT_CMD_MKENT(bootpart-resize, 4, 0, do_mmc_boot_resize, "", ""),
> U_BOOT_CMD_MKENT(partconf, 5, 0, do_mmc_partconf, "", ""),
> @@ -992,6 +992,14 @@ static int do_mmcops(struct cmd_tbl *cmdtp, int flag,
> int argc,
> return cp->cmd(cmdtp, flag, argc, argv);
> }
>
> +#if CONFIG_IS_ENABLED(SUPPORT_EMMC_BOOT)
> +static int do_mmcboot(struct cmd_tbl *cmdtp, int flag, int argc,
> + char *const argv[])
> +{
> + return common_diskboot(cmdtp, "mmc", argc, argv);
> +}
> +#endif
> +
> U_BOOT_CMD(
> mmc, 29, 1, do_mmcops,
> "MMC sub system",
> @@ -1016,7 +1024,7 @@ U_BOOT_CMD(
> " WARNING: Partitioning is a write-once setting once it is set to
> complete.\n"
> " Power cycling is required to initialize partitions after set to
> complete.\n"
> #endif
> -#ifdef CONFIG_SUPPORT_EMMC_BOOT
> +#if CONFIG_IS_ENABLED(SUPPORT_EMMC_BOOT)
> "mmc bootbus dev boot_bus_width reset_boot_bus_width boot_mode\n"
> " - Set the BOOT_BUS_WIDTH field of the specified device\n"
> "mmc bootpart-resize \n"
> @@ -1046,3 +1054,11 @@ U_BOOT_CMD(
> "display MMC info",
> "- display info of the current MMC device"
> );
> +
> +#if CONFIG_IS_ENABLED(SUPPORT_EMMC_BOOT)
> +U_BOOT_CMD(
> + mmcboot, 3, 1, do_mmcboot,
> + "boot from eMMC",
> + "[loadAddr] [dev:part]"
> +);
> +#endif
>
Re: [PATCH] drivers: mmc: support secure erase.
Hi Dennis, On 1/1/21 8:42 PM, dennis laplacian1 wrote: > Hi Jaehoon. > The only degradation is that the check will be for every block in the > deleted range and not for the range. > I can move the check to mmc_erase_t, but then if the device is not > supporting secure erase the error message will be printed for every block. > I can check the support also in mmc_berase and print an error message only > in this function. > What do you think? I understood what you said. Your code is displaying "secure erase not supported..". So it will be displayed spamming when card doesn't support secure erase. In this case, your mention is right. Well, if you're ok, it can be changed from printf to debug. And I think that it can be located to mmc->sec_feature_support is assigned. If it needs to know whether card is sec_feature_support or not, i think that it can be implemented into mmcinfo. I don't think what's correct or wrong. :) It's just my preference. Best Regards, Jaehoon Chung > > בתאריך יום ב׳, 28 בדצמ׳ 2020 ב-0:39 מאת Jaehoon Chung < > jh80.ch...@samsung.com>: > >> Hi Dennis, >> >> On 12/26/20 5:44 PM, dennis laplacian1 wrote: >>> Hi Jaehoon Chung, >>> for your comment: >>> "ditto. if (IS_ENABLED()) instead of #if. >>> And i don't know why doesn't check this in mmc_erase_t(). >>> Then it doesn't need to pass arg as argument." >>> >>> I check the support of secure erase in the mmc_berase and not in >>> mmc_erase_t because mmc_erase_t is called multiple times for each block. >>> So to prevent unnecessary checks, I check the support in mmc_berase >>> function. >> >> It there any problem to check a condition in mmc_erase_t()? or any >> dramatic degradation? >> And CONFIG_MMC_SECURE_ERASE is not enabled by default. So It doesn't need >> to add a variable. >> >> Best Regards, >> Jaehoon Chung >> >>> >> >> >
[PATCH v3 2/2] phy: mv88e61xx: add support for MV88E6171
This patch add MV88E6171 id to driver data.
Tested on Checkpoint L-50 board.
Cc: Chris Packham
Cc: Joe Hershberger
Cc: Anatolij Gustschin
Cc: Tim Harvey
Signed-off-by: Pawel Dembicki
---
Changes in v3,v2:
- resend only
drivers/net/phy/mv88e61xx.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/net/phy/mv88e61xx.c b/drivers/net/phy/mv88e61xx.c
index 3bcd2ba242..82f1587ff5 100644
--- a/drivers/net/phy/mv88e61xx.c
+++ b/drivers/net/phy/mv88e61xx.c
@@ -183,6 +183,7 @@
#define PORT_SWITCH_ID_60710x0710
#define PORT_SWITCH_ID_60960x0980
#define PORT_SWITCH_ID_60970x0990
+#define PORT_SWITCH_ID_61710x1710
#define PORT_SWITCH_ID_61720x1720
#define PORT_SWITCH_ID_61760x1760
#define PORT_SWITCH_ID_62200x2200
@@ -1055,6 +1056,7 @@ static int mv88e61xx_probe(struct phy_device *phydev)
switch (priv->id) {
case PORT_SWITCH_ID_6096:
case PORT_SWITCH_ID_6097:
+ case PORT_SWITCH_ID_6171:
case PORT_SWITCH_ID_6172:
case PORT_SWITCH_ID_6176:
case PORT_SWITCH_ID_6240:
@@ -1210,6 +1212,17 @@ static struct phy_driver mv88e61xx_driver = {
.shutdown = &genphy_shutdown,
};
+static struct phy_driver mv88e617x_driver = {
+ .name = "Marvell MV88E617x",
+ .uid = 0x01410e70,
+ .mask = 0xfff0,
+ .features = PHY_GBIT_FEATURES,
+ .probe = mv88e61xx_probe,
+ .config = mv88e61xx_phy_config,
+ .startup = mv88e61xx_phy_startup,
+ .shutdown = &genphy_shutdown,
+};
+
static struct phy_driver mv88e609x_driver = {
.name = "Marvell MV88E609x",
.uid = 0x1410c89,
@@ -1235,6 +1248,7 @@ static struct phy_driver mv88e6071_driver = {
int phy_mv88e61xx_init(void)
{
phy_register(&mv88e61xx_driver);
+ phy_register(&mv88e617x_driver);
phy_register(&mv88e609x_driver);
phy_register(&mv88e6071_driver);
--
2.25.1
[PATCH v3 1/2] phy: mv88e61xx: add support for RGMII TX/RX delay
Clock delay in RGMII is required for some boards.
Clock delay is read from phy-mode dts property. Delay is configured via
proper bits in PORT_REG_PHYS_CTRL register.
Cc: Chris Packham
Cc: Joe Hershberger
Cc: Anatolij Gustschin
Cc: Tim Harvey
Cc: Tom Rini
Signed-off-by: Pawel Dembicki
---
Changes in v3:
- clear initial values of RX and TX delay bit
Changes in v2:
- change source info about delay: from hardcode to phy-mode propoperty in dts
drivers/net/phy/mv88e61xx.c | 66 -
1 file changed, 65 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/mv88e61xx.c b/drivers/net/phy/mv88e61xx.c
index 7eff37b244..3bcd2ba242 100644
--- a/drivers/net/phy/mv88e61xx.c
+++ b/drivers/net/phy/mv88e61xx.c
@@ -97,6 +97,8 @@
#define PORT_REG_STATUS_CMODE_1000BASE_X 0x9
#define PORT_REG_STATUS_CMODE_SGMII0xa
+#define PORT_REG_PHYS_CTRL_RGMII_RX_DELAY BIT(15)
+#define PORT_REG_PHYS_CTRL_RGMII_TX_DELAY BIT(14)
#define PORT_REG_PHYS_CTRL_PCS_AN_EN BIT(10)
#define PORT_REG_PHYS_CTRL_PCS_AN_RST BIT(9)
#define PORT_REG_PHYS_CTRL_FC_VALUEBIT(7)
@@ -729,7 +731,45 @@ unforce:
static int mv88e61xx_fixed_port_setup(struct phy_device *phydev, u8 port)
{
struct mv88e61xx_phy_priv *priv = phydev->priv;
- int val;
+ ofnode node;
+ const char *str;
+ int val, phy_mode;
+ u32 phy_handle;
+
+ if (!ofnode_valid(phydev->node)) {
+ node = dev_ofnode(phydev->dev);
+ phy_handle = ofnode_read_u32_default(node, "phy-handle",
-ENXIO);
+
+ if (phy_handle == -ENXIO) {
+ node = ofnode_first_subnode(node);
+
+ while (ofnode_valid(node)) {
+ phy_handle = ofnode_read_u32_default(node,
"phy-handle", -ENXIO);
+ if (phy_handle != -ENXIO)
+ break;
+ node = ofnode_next_subnode(node);
+ }
+ }
+
+ if (phy_handle != -ENXIO)
+ node = ofnode_get_by_phandle(phy_handle);
+ else
+ node = ofnode_null();
+ } else {
+ node = phy_get_ofnode(phydev);
+ }
+
+ node = ofnode_find_subnode(node, "ports");
+ node = ofnode_first_subnode(node);
+
+ while (ofnode_valid(node)) {
+ u8 port_no = (u8)ofnode_read_u32_default(node, "reg", -1);
+
+ if (port_no == port)
+ break;
+
+ node = ofnode_next_subnode(node);
+ }
val = mv88e61xx_port_read(phydev, port, PORT_REG_PHYS_CTRL);
if (val < 0)
@@ -754,6 +794,30 @@ static int mv88e61xx_fixed_port_setup(struct phy_device
*phydev, u8 port)
val |= PORT_REG_PHYS_CTRL_LINK_VALUE |
PORT_REG_PHYS_CTRL_LINK_FORCE;
+ if (ofnode_valid(node)) {
+ str = ofnode_read_string(node, "phy-mode");
+ if (str) {
+ phy_mode = phy_get_interface_by_name(str);
+ val &= ~(PORT_REG_PHYS_CTRL_RGMII_RX_DELAY |
+ PORT_REG_PHYS_CTRL_RGMII_TX_DELAY);
+
+ switch (phy_mode) {
+ case PHY_INTERFACE_MODE_RGMII_ID:
+ val |= PORT_REG_PHYS_CTRL_RGMII_RX_DELAY;
+ val |= PORT_REG_PHYS_CTRL_RGMII_TX_DELAY;
+ break;
+ case PHY_INTERFACE_MODE_RGMII_RXID:
+ val |= PORT_REG_PHYS_CTRL_RGMII_RX_DELAY;
+ break;
+ case PHY_INTERFACE_MODE_RGMII_TXID:
+ val |= PORT_REG_PHYS_CTRL_RGMII_TX_DELAY;
+ break;
+ default:
+ break;
+ }
+ }
+ }
+
return mv88e61xx_port_write(phydev, port, PORT_REG_PHYS_CTRL,
val);
}
--
2.25.1
[PATCH] arm: dart6ul: fix ddr size macro
From: Marc Ferland
The previous macro was off by one bit and so we were getting a ddr
size which was twice the real size. This commit refactors the macro so
it returns the right size in _bytes_ and modifies the printf call so the
size is still printed in MiB.
Signed-off-by: Marc Ferland
---
board/variscite/dart_6ul/dart_6ul.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/variscite/dart_6ul/dart_6ul.c
b/board/variscite/dart_6ul/dart_6ul.c
index 360be758bb..12e222e96e 100644
--- a/board/variscite/dart_6ul/dart_6ul.c
+++ b/board/variscite/dart_6ul/dart_6ul.c
@@ -250,7 +250,7 @@ struct dart6ul_info {
#define DART6UL_INFO_STORAGE_GET(n) ((n) & 0x3)
#define DART6UL_INFO_WIFI_GET(n)((n) >> 2 & 0x1)
#define DART6UL_INFO_REV_GET(n) ((n) >> 3 & 0x3)
-#define DART6UL_DDRSIZE_IN_MIB(n) ((n) << 8)
+#define DART6UL_DDRSIZE(n) ((n) * SZ_128M)
#define DART6UL_INFO_MAGIC 0x32524156
static const char *som_info_storage_to_str(u8 som_info)
@@ -323,7 +323,7 @@ int checkboard(void)
info->date,
som_info_storage_to_str(info->som_info),
DART6UL_INFO_WIFI_GET(info->som_info) ? "yes" : "no",
- DART6UL_DDRSIZE_IN_MIB(info->ddr_size),
+ DART6UL_DDRSIZE(info->ddr_size) / SZ_1M,
som_info_rev_to_str(info->som_info));
free(info);
--
2.25.1
Re: [PATCH v2] cmd: mmc: add mmcboot command
On 1/4/21 7:40 PM, Ravik Hasija wrote:
Similar to usbboot, add command line to boot from raw mmc partition
using common_diskboot(), which supports legacy or FIT images.
Usage:
mmcboot [loadAaddr] [dev:part]
Where [loadAddr] defaults to CONFIG_SYS_LOAD_ADDR, and [dev:part]
defaults to ${bootdevice}.
Also fixing config macro usage for CONFIG_SUPPORT_EMMC_BOOT (suggested
by checkpatch.pl).
Can this not be implemented by some U-Boot script ?
I can imagine that reading the first few bytes from the partition (mmc
read) would permit you to obtain the uImage/fitImage header from the
partition, from which you can obtain the image size, which is the total
number of bytes to read (iminfo might help , or fdt header), and then
read out the entire image and bootm it.
[PATCHv3 2/2] image: support board_fit_config_name_match
Support reusing board_fit_config_name_match() to automatically
select a sensible default configuration for booting fitImages
using 'bootm'.
Reviewed-by: Simon Glass
Signed-off-by: Sebastian Reichel
---
common/image-fit.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/common/image-fit.c b/common/image-fit.c
index 097cd38af05c..6a8787ca0aa0 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -1738,12 +1738,19 @@ int fit_conf_get_node(const void *fit, const char
*conf_uname)
if (conf_uname == NULL) {
/* get configuration unit name from the default property */
debug("No configuration specified, trying default...\n");
- conf_uname = (char *)fdt_getprop(fit, confs_noffset,
-FIT_DEFAULT_PROP, &len);
- if (conf_uname == NULL) {
- fit_get_debug(fit, confs_noffset, FIT_DEFAULT_PROP,
- len);
- return len;
+ if (!host_build() && IS_ENABLED(CONFIG_MULTI_DTB_FIT)) {
+ noffset = fit_find_config_node(fit);
+ if (noffset < 0)
+ return noffset;
+ conf_uname = fdt_get_name(fit, noffset, NULL);
+ } else {
+ conf_uname = (char *)fdt_getprop(fit, confs_noffset,
+FIT_DEFAULT_PROP,
&len);
+ if (conf_uname == NULL) {
+ fit_get_debug(fit, confs_noffset,
FIT_DEFAULT_PROP,
+ len);
+ return len;
+ }
}
debug("Found default configuration: '%s'\n", conf_uname);
}
--
2.29.2
[PATCHv3 0/2] Support automatic fitImage config selection
This was part of a cleanup series for GE Bx50v3 board. Board specific patches have already been merged to i.MX tree; this needs to be applied to get the default configuration working again. Changes since PATCHv2: * rebase against imx/next (so basically drop patches 1,4,5) * drop OF_LIBFDT_OVERLAY ifdef removal from PATCH 1, this change requires more work -- Sebastian Sebastian Reichel (2): image: cleanup pre-processor usage image: support board_fit_config_name_match common/image-fit.c | 65 +++--- include/image.h| 4 +++ 2 files changed, 37 insertions(+), 32 deletions(-) -- 2.29.2
[PATCHv3 1/2] image: cleanup pre-processor usage
Replace most #ifdef checks for USE_HOSTCC and CONFIG_*
with normal if instructions.
Reviewed-by: Simon Glass
Signed-off-by: Sebastian Reichel
---
common/image-fit.c | 46 --
include/image.h| 4
2 files changed, 24 insertions(+), 26 deletions(-)
diff --git a/common/image-fit.c b/common/image-fit.c
index c82d4d8015f0..097cd38af05c 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -15,7 +15,6 @@
#include
#else
#include
-#include
#include
#include
#include
@@ -28,6 +27,7 @@ DECLARE_GLOBAL_DATA_PTR;
#include
#include
#include
+#include
#include
#include
#include
@@ -486,16 +486,16 @@ void fit_image_print(const void *fit, int image_noffset,
const char *p)
ret = fit_image_get_data_and_size(fit, image_noffset, &data, &size);
-#ifndef USE_HOSTCC
- printf("%s Data Start: ", p);
- if (ret) {
- printf("unavailable\n");
- } else {
- void *vdata = (void *)data;
+ if (!host_build()) {
+ printf("%s Data Start: ", p);
+ if (ret) {
+ printf("unavailable\n");
+ } else {
+ void *vdata = (void *)data;
- printf("0x%08lx\n", (ulong)map_to_sysmem(vdata));
+ printf("0x%08lx\n", (ulong)map_to_sysmem(vdata));
+ }
}
-#endif
printf("%s Data Size:", p);
if (ret)
@@ -1420,7 +1420,6 @@ int fit_all_image_verify(const void *fit)
return 1;
}
-#ifdef CONFIG_FIT_CIPHER
static int fit_image_uncipher(const void *fit, int image_noffset,
void **data, size_t *size)
{
@@ -1444,7 +1443,6 @@ static int fit_image_uncipher(const void *fit, int
image_noffset,
out:
return ret;
}
-#endif /* CONFIG_FIT_CIPHER */
/**
* fit_image_check_os - check whether image node is of a given os type
@@ -1486,9 +1484,8 @@ int fit_image_check_arch(const void *fit, int noffset,
uint8_t arch)
uint8_t image_arch;
int aarch32_support = 0;
-#ifdef CONFIG_ARM64_SUPPORT_AARCH32
- aarch32_support = 1;
-#endif
+ if (IS_ENABLED(CONFIG_ARM64_SUPPORT_AARCH32))
+ aarch32_support = 1;
if (fit_image_get_arch(fit, noffset, &image_arch))
return 0;
@@ -1977,13 +1974,13 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
}
bootstage_mark(bootstage_id + BOOTSTAGE_SUB_CHECK_ARCH);
-#if !defined(USE_HOSTCC) && !defined(CONFIG_SANDBOX)
- if (!fit_image_check_target_arch(fit, noffset)) {
- puts("Unsupported Architecture\n");
- bootstage_error(bootstage_id + BOOTSTAGE_SUB_CHECK_ARCH);
- return -ENOEXEC;
+ if (!host_build() && IS_ENABLED(CONFIG_SANDBOX)) {
+ if (!fit_image_check_target_arch(fit, noffset)) {
+ puts("Unsupported Architecture\n");
+ bootstage_error(bootstage_id +
BOOTSTAGE_SUB_CHECK_ARCH);
+ return -ENOEXEC;
+ }
}
-#endif
#ifndef USE_HOSTCC
fit_image_get_arch(fit, noffset, &os_arch);
@@ -2029,9 +2026,8 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
return -ENOENT;
}
-#ifdef CONFIG_FIT_CIPHER
/* Decrypt data before uncompress/move */
- if (IMAGE_ENABLE_DECRYPT) {
+ if (IS_ENABLED(CONFIG_FIT_CIPHER) && IMAGE_ENABLE_DECRYPT) {
puts(" Decrypting Data ... ");
if (fit_image_uncipher(fit, noffset, &buf, &size)) {
puts("Error\n");
@@ -2039,12 +2035,10 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
}
puts("OK\n");
}
-#endif
-#if !defined(USE_HOSTCC) && defined(CONFIG_FIT_IMAGE_POST_PROCESS)
/* perform any post-processing on the image data */
- board_fit_image_post_process(&buf, &size);
-#endif
+ if (!host_build() && IS_ENABLED(CONFIG_FIT_IMAGE_POST_PROCESS))
+ board_fit_image_post_process(&buf, &size);
len = (ulong)size;
diff --git a/include/image.h b/include/image.h
index 00bc03bebece..41473dbb9cdf 100644
--- a/include/image.h
+++ b/include/image.h
@@ -1552,6 +1552,10 @@ int board_fit_config_name_match(const char *name);
* @return no return value (failure should be handled internally)
*/
void board_fit_image_post_process(void **p_image, size_t *p_size);
+#else
+static inline void board_fit_image_post_process(void **p_image, size_t *p_size)
+{
+}
#endif /* CONFIG_SPL_FIT_IMAGE_POST_PROCESS */
#define FDT_ERROR ((ulong)(-1))
--
2.29.2
Re: [PATCHv2 3/5] image: support board_fit_config_name_match
Hi Sebastian,
On 04.01.21 20:27, Sebastian Reichel wrote:
Hi,
On Mon, Dec 28, 2020 at 12:39:57PM +0100, Stefano Babic wrote:
On 15.12.20 00:41, Sebastian Reichel wrote:
Support reusing board_fit_config_name_match() to automatically
select a sensible default configuration for booting fitImages
using 'bootm'.
For reasons I have not understood, this patch breaks "sometimes" the build :
+common/image-fit.c: In function 'boot_get_fdt_fit':
+common/image-fit.c:2279:10: error: implicit declaration of function
'fdt_overlay_apply_verbose'; did you mean 'fdt_overlay_apply_node'?
[-Werror=implicit-function-declaration]
+ 2279 |err = fdt_overlay_apply_verbose(base, ov);
+ | ^
+ | fdt_overlay_apply_node
+cc1: all warnings being treated as errors
https://gitlab.denx.de/u-boot/custodians/u-boot-imx/-/jobs/193967
And it looks to me that fdt_support.h is included.
This happens if I run buildman locally, too. But it is not
deterministic, sometimes it succeed.
snapper9g20 and snapper9260 seem to trigger more frequently the issues
(but they are not the ones).
I found the root cause. It's not this patch, but the previous one.
fdt_support.h is included, but in it all declartions only happen
if OF_LIBFDT is defined. My previous patch changes the code block
calling fdt_overlay_apply_verbose() from ifdef OF_LIBFDT_OVERLAY
to IS_ENABLED(OF_LIBFDT_OVERLAY). Note, that OF_LIBFDT_OVERLAY
requires OF_LIBFDT.
Good catch !
I'm about to send PATCHv3 dropping the OF_LIBFDT_OVERLAY related
cleanup.
Thanks !
So I applied the patches related to the board, but I left this
out.
Not applying this patch results in GE Bx50v3 boards no longer
booting properly with the default config :(
I will then apply it and ask Tom to include it in the release - thanks !
Best regards,
Stefano
-- Sebastian
Best regards,
Stefano Babic
Signed-off-by: Sebastian Reichel
---
common/image-fit.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/common/image-fit.c b/common/image-fit.c
index 1f382d87e207..b3aeff8c5e4a 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -1738,12 +1738,19 @@ int fit_conf_get_node(const void *fit, const char
*conf_uname)
if (conf_uname == NULL) {
/* get configuration unit name from the default property */
debug("No configuration specified, trying default...\n");
- conf_uname = (char *)fdt_getprop(fit, confs_noffset,
-FIT_DEFAULT_PROP, &len);
- if (conf_uname == NULL) {
- fit_get_debug(fit, confs_noffset, FIT_DEFAULT_PROP,
- len);
- return len;
+ if (!host_build() && IS_ENABLED(CONFIG_MULTI_DTB_FIT)) {
+ noffset = fit_find_config_node(fit);
+ if (noffset < 0)
+ return noffset;
+ conf_uname = fdt_get_name(fit, noffset, NULL);
+ } else {
+ conf_uname = (char *)fdt_getprop(fit, confs_noffset,
+FIT_DEFAULT_PROP,
&len);
+ if (conf_uname == NULL) {
+ fit_get_debug(fit, confs_noffset,
FIT_DEFAULT_PROP,
+ len);
+ return len;
+ }
}
debug("Found default configuration: '%s'\n", conf_uname);
}
--
=
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
--
=
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
Re: [PATCHv2 3/5] image: support board_fit_config_name_match
Hi,
On Mon, Dec 28, 2020 at 12:39:57PM +0100, Stefano Babic wrote:
> On 15.12.20 00:41, Sebastian Reichel wrote:
> > Support reusing board_fit_config_name_match() to automatically
> > select a sensible default configuration for booting fitImages
> > using 'bootm'.
> >
>
> For reasons I have not understood, this patch breaks "sometimes" the build :
>
> +common/image-fit.c: In function 'boot_get_fdt_fit':
> +common/image-fit.c:2279:10: error: implicit declaration of function
> 'fdt_overlay_apply_verbose'; did you mean 'fdt_overlay_apply_node'?
> [-Werror=implicit-function-declaration]
> + 2279 |err = fdt_overlay_apply_verbose(base, ov);
> + | ^
> + | fdt_overlay_apply_node
> +cc1: all warnings being treated as errors
>
> https://gitlab.denx.de/u-boot/custodians/u-boot-imx/-/jobs/193967
>
> And it looks to me that fdt_support.h is included.
>
> This happens if I run buildman locally, too. But it is not
> deterministic, sometimes it succeed.
>
> snapper9g20 and snapper9260 seem to trigger more frequently the issues
> (but they are not the ones).
I found the root cause. It's not this patch, but the previous one.
fdt_support.h is included, but in it all declartions only happen
if OF_LIBFDT is defined. My previous patch changes the code block
calling fdt_overlay_apply_verbose() from ifdef OF_LIBFDT_OVERLAY
to IS_ENABLED(OF_LIBFDT_OVERLAY). Note, that OF_LIBFDT_OVERLAY
requires OF_LIBFDT.
I'm about to send PATCHv3 dropping the OF_LIBFDT_OVERLAY related
cleanup.
> So I applied the patches related to the board, but I left this
> out.
Not applying this patch results in GE Bx50v3 boards no longer
booting properly with the default config :(
-- Sebastian
> Best regards,
> Stefano Babic
>
> > Signed-off-by: Sebastian Reichel
> > ---
> > common/image-fit.c | 19 +--
> > 1 file changed, 13 insertions(+), 6 deletions(-)
> >
> > diff --git a/common/image-fit.c b/common/image-fit.c
> > index 1f382d87e207..b3aeff8c5e4a 100644
> > --- a/common/image-fit.c
> > +++ b/common/image-fit.c
> > @@ -1738,12 +1738,19 @@ int fit_conf_get_node(const void *fit, const char
> > *conf_uname)
> > if (conf_uname == NULL) {
> > /* get configuration unit name from the default property */
> > debug("No configuration specified, trying default...\n");
> > - conf_uname = (char *)fdt_getprop(fit, confs_noffset,
> > -FIT_DEFAULT_PROP, &len);
> > - if (conf_uname == NULL) {
> > - fit_get_debug(fit, confs_noffset, FIT_DEFAULT_PROP,
> > - len);
> > - return len;
> > + if (!host_build() && IS_ENABLED(CONFIG_MULTI_DTB_FIT)) {
> > + noffset = fit_find_config_node(fit);
> > + if (noffset < 0)
> > + return noffset;
> > + conf_uname = fdt_get_name(fit, noffset, NULL);
> > + } else {
> > + conf_uname = (char *)fdt_getprop(fit, confs_noffset,
> > +FIT_DEFAULT_PROP,
> > &len);
> > + if (conf_uname == NULL) {
> > + fit_get_debug(fit, confs_noffset,
> > FIT_DEFAULT_PROP,
> > + len);
> > + return len;
> > + }
> > }
> > debug("Found default configuration: '%s'\n", conf_uname);
> > }
> >
>
>
> --
> =
> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
> =
signature.asc
Description: PGP signature
Re: [linux-sunxi] [PATCH 12/17] sunxi: Add support for H616 SoC
Dne ponedeljek, 04. januar 2021 ob 03:47:06 CET je Samuel Holland napisal(a):
> On 1/3/21 3:26 AM, Jernej Skrabec wrote:
> > H616 is very similar to H6 so most of the infrastructure can be reused.
> > However, two big differences are that it doesn't have functional SRAM A2
> > which is usually used for TF-A and it doesn't have ARISC co-processor.
> > It also needs bigger SPL size - 48 KiB.
> >
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > arch/arm/dts/sunxi-u-boot.dtsi | 9 +
> > arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h | 7 +++
> > arch/arm/mach-sunxi/Kconfig | 11 ++-
> > arch/arm/mach-sunxi/cpu_info.c | 2 ++
> > drivers/power/Kconfig | 1 +
> > include/configs/sunxi-common.h | 10 ++
> > 6 files changed, 39 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/dts/sunxi-u-boot.dtsi
> > b/arch/arm/dts/sunxi-u-boot.dtsi index c77cf7cacf0c..7e8644f390a8 100644
> > --- a/arch/arm/dts/sunxi-u-boot.dtsi
> > +++ b/arch/arm/dts/sunxi-u-boot.dtsi
> > @@ -3,6 +3,9 @@
> >
> > #ifdef CONFIG_MACH_SUN50I_H6
> > #define BL31_ADDR 0x104000
> > #define SCP_ADDR 0x114000
> >
> > +#elif defined(CONFIG_MACH_SUN50I_H616)
> > +#define BL31_ADDR 0x40004000
> > +#define SCP_ADDR 0x028000
>
> There should be no SCP_ADDR if there is no SCP firmware.
Nice catch!
>
> > #else
> > #define BL31_ADDR 0x44000
> > #define SCP_ADDR 0x5
> >
> > @@ -61,6 +64,7 @@
> >
> > };
> >
> > };
> >
> > +#ifndef CONFIG_MACH_SUN50I_H616
> >
> > scp {
> >
> > description = "SCP
firmware";
> > type = "firmware";
> >
> > @@ -73,6 +77,7 @@
> >
> > missing-msg
= "scp-sunxi";
> >
> > };
> >
> > };
> >
> > +#endif
> >
> > @fdt-SEQ {
> >
> > description = "NAME";
> >
> > @@ -87,7 +92,11 @@
> >
> > @config-SEQ {
> >
> > description = "NAME";
> > firmware = "atf";
> >
> > +#ifdef CONFIG_MACH_SUN50I_H616
> > + loadables = "uboot";
> > +#else
> >
> > loadables = "scp",
"uboot";
> >
> > +#endif
> >
> > fdt = "fdt-SEQ";
> >
> > };
> >
> > };
> >
> > diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h
> > b/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h index
> > 6392cb07b472..d9cf8ae04288 100644
> > --- a/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h
> > +++ b/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h
> > @@ -28,13 +28,20 @@
> >
> > #define SUNXI_GIC400_BASE 0x0302
> > #define SUNXI_IOMMU_BASE 0x030F
> >
> > +#ifdef CONFIG_MACH_SUN50I_H6
> >
> > #define SUNXI_DRAM_COM_BASE0x04002000
> > #define SUNXI_DRAM_CTL0_BASE 0x04003000
> > #define SUNXI_DRAM_PHY0_BASE 0x04005000
> >
> > +#endif
> >
> > #define SUNXI_NFC_BASE 0x04011000
> > #define SUNXI_MMC0_BASE0x0402
> > #define SUNXI_MMC1_BASE0x04021000
> > #define SUNXI_MMC2_BASE0x04022000
> >
> > +#ifdef CONFIG_MACH_SUN50I_H616
> > +#define SUNXI_DRAM_COM_BASE0x047FA000
> > +#define SUNXI_DRAM_CTL0_BASE 0x047FB000
> > +#define SUNXI_DRAM_PHY0_BASE 0x0480
> > +#endif
> >
> > #define SUNXI_UART0_BASE 0x0500
> > #define SUNXI_UART1_BASE 0x05000400
> >
> > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> > index 1a5497989f04..859b30d74ceb 100644
> > --- a/arch/arm/mach-sunxi/Kconfig
> > +++ b/arch/arm/mach-sunxi/Kconfig
> > @@ -190,9 +190,10 @@ config MACH_SUNXI_H3_H5
> >
> > select SUPPORT_SPL
> >
> > # TODO: try out A80's 8GiB DRAM space
> >
> > +# TODO: H616 supports 4 GiB DRAM space
> >
> > config SUNXI_DRAM_MAX_SIZE
> >
> > hex
> >
> > - default 0xC000 if MACH_SUN50I || MACH_SUN50I_H5 ||
MACH_SUN50I_H6
> > + default 0xC000 if MACH_SUN50I || MACH_SUN50I_H5 ||
MACH_SUN50I_H6 ||
> > MACH_SUN50I_H616>
> > default 0x8000
> >
> > choice
> >
> > @@ -354,6 +355,12 @@ config MACH_SUN50I_H6
> >
> > select PHY_SUN4I_USB
> > select DRAM_SUN50I_H6
> >
> > +config MACH_SUN50I_H616
> > + bool "sun50i (A
[PATCH v2] cmd: mmc: add mmcboot command
Similar to usbboot, add command line to boot from raw mmc partition
using common_diskboot(), which supports legacy or FIT images.
Usage:
mmcboot [loadAaddr] [dev:part]
Where [loadAddr] defaults to CONFIG_SYS_LOAD_ADDR, and [dev:part]
defaults to ${bootdevice}.
Also fixing config macro usage for CONFIG_SUPPORT_EMMC_BOOT (suggested
by checkpatch.pl).
Signed-off-by: Ravik Hasija
Signed-off-by: Dhananjay Phadke
Reviewed-by: Jaehoon Chung
Reviewed-by: Simon Glass
---
v2:
* Fixed build failure.
* Updated syntax of mmcboot cmd.
---
cmd/Makefile | 2 +-
cmd/mmc.c| 22 +++---
2 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/cmd/Makefile b/cmd/Makefile
index dd86675bf2..573e4776f5 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -97,7 +97,7 @@ obj-$(CONFIG_CMD_MII) += mii.o
obj-$(CONFIG_CMD_MISC) += misc.o
obj-$(CONFIG_CMD_MDIO) += mdio.o
obj-$(CONFIG_CMD_SLEEP) += sleep.o
-obj-$(CONFIG_CMD_MMC) += mmc.o
+obj-$(CONFIG_CMD_MMC) += mmc.o disk.o
obj-$(CONFIG_CMD_OPTEE_RPMB) += optee_rpmb.o
obj-$(CONFIG_MP) += mp.o
obj-$(CONFIG_CMD_MTD) += mtd.o
diff --git a/cmd/mmc.c b/cmd/mmc.c
index 1529a3e05d..0c3ed6c108 100644
--- a/cmd/mmc.c
+++ b/cmd/mmc.c
@@ -711,7 +711,7 @@ static int do_mmc_hwpartition(struct cmd_tbl *cmdtp, int
flag,
}
#endif
-#ifdef CONFIG_SUPPORT_EMMC_BOOT
+#if CONFIG_IS_ENABLED(SUPPORT_EMMC_BOOT)
static int do_mmc_bootbus(struct cmd_tbl *cmdtp, int flag,
int argc, char *const argv[])
{
@@ -950,7 +950,7 @@ static struct cmd_tbl cmd_mmc[] = {
#if CONFIG_IS_ENABLED(MMC_HW_PARTITIONING)
U_BOOT_CMD_MKENT(hwpartition, 28, 0, do_mmc_hwpartition, "", ""),
#endif
-#ifdef CONFIG_SUPPORT_EMMC_BOOT
+#if CONFIG_IS_ENABLED(SUPPORT_EMMC_BOOT)
U_BOOT_CMD_MKENT(bootbus, 5, 0, do_mmc_bootbus, "", ""),
U_BOOT_CMD_MKENT(bootpart-resize, 4, 0, do_mmc_boot_resize, "", ""),
U_BOOT_CMD_MKENT(partconf, 5, 0, do_mmc_partconf, "", ""),
@@ -992,6 +992,14 @@ static int do_mmcops(struct cmd_tbl *cmdtp, int flag, int
argc,
return cp->cmd(cmdtp, flag, argc, argv);
}
+#if CONFIG_IS_ENABLED(SUPPORT_EMMC_BOOT)
+static int do_mmcboot(struct cmd_tbl *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+ return common_diskboot(cmdtp, "mmc", argc, argv);
+}
+#endif
+
U_BOOT_CMD(
mmc, 29, 1, do_mmcops,
"MMC sub system",
@@ -1016,7 +1024,7 @@ U_BOOT_CMD(
" WARNING: Partitioning is a write-once setting once it is set to
complete.\n"
" Power cycling is required to initialize partitions after set to
complete.\n"
#endif
-#ifdef CONFIG_SUPPORT_EMMC_BOOT
+#if CONFIG_IS_ENABLED(SUPPORT_EMMC_BOOT)
"mmc bootbus dev boot_bus_width reset_boot_bus_width boot_mode\n"
" - Set the BOOT_BUS_WIDTH field of the specified device\n"
"mmc bootpart-resize \n"
@@ -1046,3 +1054,11 @@ U_BOOT_CMD(
"display MMC info",
"- display info of the current MMC device"
);
+
+#if CONFIG_IS_ENABLED(SUPPORT_EMMC_BOOT)
+U_BOOT_CMD(
+ mmcboot, 3, 1, do_mmcboot,
+ "boot from eMMC",
+ "[loadAddr] [dev:part]"
+);
+#endif
--
2.17.1
Re: [linux-sunxi] [PATCH 11/17] sunxi: Add H616 DRAM support
Dne ponedeljek, 04. januar 2021 ob 03:39:52 CET je Samuel Holland napisal(a):
> On 1/3/21 3:26 AM, Jernej Skrabec wrote:
> > Allwinner H616 supports many types of DRAM. Most notably it supports
> > LPDDR4. However, all commercially available boards at this time use
> > only DDR3, so this commit adds only DDR3 support.
> >
> > Controller and MBUS are very similar to H6 but PHY is completely
> > unknown.
> >
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > arch/arm/include/asm/arch-sunxi/dram.h|2 +
> > .../include/asm/arch-sunxi/dram_sun50i_h616.h | 159 +++
> > arch/arm/mach-sunxi/Kconfig | 43 +
> > arch/arm/mach-sunxi/Makefile |2 +
> > arch/arm/mach-sunxi/dram_sun50i_h616.c| 1023 +
> > arch/arm/mach-sunxi/dram_timings/Makefile |2 +
> > .../mach-sunxi/dram_timings/h616_ddr3_1333.c | 94 ++
> > 7 files changed, 1325 insertions(+)
> > create mode 100644 arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> > create mode 100644 arch/arm/mach-sunxi/dram_sun50i_h616.c
> > create mode 100644 arch/arm/mach-sunxi/dram_timings/h616_ddr3_1333.c
> >
> > diff --git a/arch/arm/include/asm/arch-sunxi/dram.h
> > b/arch/arm/include/asm/arch-sunxi/dram.h index 8002b7efdc19..c3b3e1f512b2
> > 100644
> > --- a/arch/arm/include/asm/arch-sunxi/dram.h
> > +++ b/arch/arm/include/asm/arch-sunxi/dram.h
> > @@ -29,6 +29,8 @@
> >
> > #include
> > #elif defined(CONFIG_MACH_SUN50I_H6)
> > #include
> >
> > +#elif defined(CONFIG_MACH_SUN50I_H616)
> > +#include
> >
> > #else
> > #include
> > #endif
> >
> > diff --git a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> > b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h new file mode 100644
> > index ..5d105afd6110
> > --- /dev/null
> > +++ b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> > @@ -0,0 +1,159 @@
> > +/*
> > + * H616 dram controller register and constant defines
> > + *
> > + * (C) Copyright 2020 Jernej Skrabec
> > + *
> > + * Based on H6 one, which is:
> > + * (C) Copyright 2017 Icenowy Zheng
> > + *
> > + * SPDX-License-Identifier:GPL-2.0+
> > + */
> > +
> > +#ifndef _SUNXI_DRAM_SUN50I_H616_H
> > +#define _SUNXI_DRAM_SUN50I_H616_H
> > +
> > +#include
> > +#ifndef __ASSEMBLY__
> > +#include
> > +#endif
> > +
> > +enum sunxi_dram_type {
> > + SUNXI_DRAM_TYPE_DDR3 = 3,
> > + SUNXI_DRAM_TYPE_DDR4,
> > + SUNXI_DRAM_TYPE_LPDDR3 = 7,
> > + SUNXI_DRAM_TYPE_LPDDR4
> > +};
> > +
> > +/* MBUS part is largely the same as in H6, except for one special
> > register */ +struct sunxi_mctl_com_reg {
> > + u32 cr; /* 0x000 control register */
> > + u8 reserved_0x004[4]; /* 0x004 */
> > + u32 unk_0x008; /* 0x008 */
> > + u32 tmr;/* 0x00c timer register */
> > + u8 reserved_0x010[4]; /* 0x010 */
> > + u32 unk_0x014; /* 0x014 */
> > + u8 reserved_0x018[8]; /* 0x018 */
> > + u32 maer0; /* 0x020 master enable register 0 */
> > + u32 maer1; /* 0x024 master enable register 1 */
> > + u32 maer2; /* 0x028 master enable register 2 */
> > + u8 reserved_0x02c[468]; /* 0x02c */
> > + u32 bwcr; /* 0x200 bandwidth control register */
> > + u8 reserved_0x204[12]; /* 0x204 */
> > + /*
> > +* The last master configured by BSP libdram is at 0x49x, so the
> > +* size of this struct array is set to 41 (0x29) now.
> > +*/
> > + struct {
> > + u32 cfg0; /* 0x0 */
> > + u32 cfg1; /* 0x4 */
> > + u8 reserved_0x8[8]; /* 0x8 */
> > + } master[41]; /* 0x210 + index * 0x10 */
> > + u8 reserved_0x4a0[96]; /* 0x4a0 */
> > + u32 unk_0x500; /* 0x500 */
> > +};
> > +check_member(sunxi_mctl_com_reg, unk_0x500, 0x500);
> > +
> > +/*
> > + * Controller registers seems to be the same or at least very similar
> > + * to those in H6.
> > + */
> > +struct sunxi_mctl_ctl_reg {
> > + u32 mstr; /* 0x000 */
> > + u32 statr; /* 0x004 unused */
> > + u32 mstr1; /* 0x008 unused */
> > + u32 unk_0x00c; /* 0x00c */
>
> This is clken (and the same on H6). It is obvious when looking at the
> standby power-down sequence.
Where is that sequence? I mostly consulted H6 and Zynq docs where this
register is not explained. I'll update it in next revision.
Best regards,
Jernej
>
> > + u32 mrctrl0;/* 0x010 unused */
> > + u32 mrctrl1;/* 0x014 unused */
> > + u32 mrstatr;/* 0x018 unused */
> > + u32 mrctrl2;/* 0x01c unused */
> > + u32 derateen; /* 0x020 unused */
> > + u32 derateint; /* 0x024 unused */
> > + u8 reserved_0x028[8]; /* 0x028 */
> > + u32 pwrctl; /* 0x030 unused */
> > + u32 pwrtmg; /* 0x034 unused */
> > + u32 hwlpctl;/* 0x038 unused */
> > + u8 reserved_0x03
Re: [linux-sunxi] [PATCH 10/17] sunxi: add support for R_I2C on H616
Dne ponedeljek, 04. januar 2021 ob 03:33:12 CET je Samuel Holland napisal(a):
> On 1/3/21 3:26 AM, Jernej Skrabec wrote:
> > This port is needed for communication with PMIC. SPL uses it to set DRAM
> > voltage on H616 boards.
> >
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > arch/arm/include/asm/arch-sunxi/gpio.h | 1 +
> > board/sunxi/board.c| 4
> > 2 files changed, 5 insertions(+)
> >
> > diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h
> > b/arch/arm/include/asm/arch-sunxi/gpio.h index cdb7dbd5b8e5..de77bf638e21
> > 100644
> > --- a/arch/arm/include/asm/arch-sunxi/gpio.h
> > +++ b/arch/arm/include/asm/arch-sunxi/gpio.h
> > @@ -220,6 +220,7 @@ enum sunxi_gpio_number {
> >
> > #define SUN8I_A23_GPL_R_TWI3
> > #define SUN8I_GPL_R_UART 2
> > #define SUN50I_GPL_R_TWI 2
> >
> > +#define SUN50I_H616_GPL_R_TWI 3
>
> The fact that I2C is at function 3 makes me suspicious that there is RSB
> at function 2. Have you checked if that is the case?
BSP Linux pinctrl has function 2 s_rsb0, so yes, that should be the case.
However, it doesn't have RSB DT node anywhere. Datasheet mentions RSB only in
CCU diagram, so no details anywhere. I didn't test it.
Best regards,
Jernej
>
> Either way:
>
> Reviewed-by: Samuel Holland
>
> > #define SUN9I_GPN_R_RSB3
> >
> > diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> > index 54ff9bc92396..727e8320318f 100644
> > --- a/board/sunxi/board.c
> > +++ b/board/sunxi/board.c
> > @@ -196,6 +196,10 @@ void i2c_init_board(void)
> >
> > clock_twi_onoff(5, 1);
> > sunxi_gpio_set_cfgpin(SUNXI_GPL(8), SUN50I_GPL_R_TWI);
> > sunxi_gpio_set_cfgpin(SUNXI_GPL(9), SUN50I_GPL_R_TWI);
> >
> > +#elif CONFIG_MACH_SUN50I_H616
> > + clock_twi_onoff(5, 1);
> > + sunxi_gpio_set_cfgpin(SUNXI_GPL(0), SUN50I_H616_GPL_R_TWI);
> > + sunxi_gpio_set_cfgpin(SUNXI_GPL(1), SUN50I_H616_GPL_R_TWI);
> >
> > #else
> >
> > clock_twi_onoff(5, 1);
> > sunxi_gpio_set_cfgpin(SUNXI_GPL(0), SUN8I_H3_GPL_R_TWI);
Re: [linux-sunxi] [PATCH 02/17] sunxi: Introduce common symbol for H6 like SoCs
Dne ponedeljek, 04. januar 2021 ob 11:35:41 CET je André Przywara napisal(a):
> On 03/01/2021 23:43, Samuel Holland wrote:
>
> Hi Jernej,
>
> thanks for that patch, that's a nice solution to avoid those long #ifdef
> chains!
>
> > On 1/3/21 3:26 AM, Jernej Skrabec wrote:
> >> It turns out that there are at least 2 other SoCs which have basically
> >> the same memory map, similar clocks and other features as H6. It's very
> >> likely that we'll see more such SoCs in the future. In order to ease
> >> porting to new SoCs and lower ifdef clutter, introduce common symbol for
> >> them.
> >>
> >> Signed-off-by: Jernej Skrabec
> >> ---
> >>
> >> arch/arm/include/asm/arch-sunxi/boot0.h | 2 +-
> >> arch/arm/include/asm/arch-sunxi/clock.h | 2 +-
> >> arch/arm/include/asm/arch-sunxi/cpu.h | 2 +-
> >> arch/arm/include/asm/arch-sunxi/timer.h | 2 +-
> >> arch/arm/mach-sunxi/Kconfig | 21 +
> >> arch/arm/mach-sunxi/Makefile| 2 +-
> >> arch/arm/mach-sunxi/board.c | 4 ++--
> >> arch/arm/mach-sunxi/rmr_switch.S| 2 +-
> >> common/spl/Kconfig | 4 ++--
> >> include/configs/sun50i.h| 2 +-
> >> 10 files changed, 24 insertions(+), 19 deletions(-)
> >>
> >> diff --git a/arch/arm/include/asm/arch-sunxi/boot0.h
> >> b/arch/arm/include/asm/arch-sunxi/boot0.h index
> >> 46d0f0666c2b..e8e8e38f0556 100644
> >> --- a/arch/arm/include/asm/arch-sunxi/boot0.h
> >> +++ b/arch/arm/include/asm/arch-sunxi/boot0.h
> >> @@ -39,7 +39,7 @@
> >>
> >>.word 0xf57ff06f // isb sy
> >>.word 0xe320f003 // wfi
> >>.word 0xeafd // b @wfi
> >>
> >> -#ifndef CONFIG_MACH_SUN50I_H6
> >> +#ifndef CONFIG_SUN50I_GEN_H6
> >>
> >>.word 0x017000a0 // writeable RVBAR mapping address
> >>
> >> #else
> >>
> >>.word 0x09010040 // writeable RVBAR mapping address
> >>
> >> diff --git a/arch/arm/include/asm/arch-sunxi/clock.h
> >> b/arch/arm/include/asm/arch-sunxi/clock.h index
> >> 5994130e6b54..cbbe5c7a1e68 100644
> >> --- a/arch/arm/include/asm/arch-sunxi/clock.h
> >> +++ b/arch/arm/include/asm/arch-sunxi/clock.h
> >> @@ -16,7 +16,7 @@
> >>
> >> /* clock control module regs definition */
> >> #if defined(CONFIG_MACH_SUN8I_A83T)
> >> #include
> >>
> >> -#elif defined(CONFIG_MACH_SUN50I_H6)
> >> +#elif defined(CONFIG_SUN50I_GEN_H6)
> >>
> >> #include
> >> #elif defined(CONFIG_MACH_SUN6I) || defined(CONFIG_MACH_SUN8I) || \
> >>
> >>defined(CONFIG_MACH_SUN50I)
> >>
> >> diff --git a/arch/arm/include/asm/arch-sunxi/cpu.h
> >> b/arch/arm/include/asm/arch-sunxi/cpu.h index 8b57d24e2f0c..b08f2023748c
> >> 100644
> >> --- a/arch/arm/include/asm/arch-sunxi/cpu.h
> >> +++ b/arch/arm/include/asm/arch-sunxi/cpu.h
> >> @@ -8,7 +8,7 @@
> >>
> >> #if defined(CONFIG_MACH_SUN9I)
> >> #include
> >>
> >> -#elif defined(CONFIG_MACH_SUN50I_H6)
> >> +#elif defined(CONFIG_SUN50I_GEN_H6)
> >>
> >> #include
> >> #else
> >> #include
> >>
> >> diff --git a/arch/arm/include/asm/arch-sunxi/timer.h
> >> b/arch/arm/include/asm/arch-sunxi/timer.h index
> >> 6f138d04b806..bb5626d893bb 100644
> >> --- a/arch/arm/include/asm/arch-sunxi/timer.h
> >> +++ b/arch/arm/include/asm/arch-sunxi/timer.h
> >> @@ -76,7 +76,7 @@ struct sunxi_timer_reg {
> >>
> >>struct sunxi_tgp tgp[4];
> >>u8 res5[8];
> >>u32 cpu_cfg;
> >>
> >> -#elif defined(CONFIG_SUNXI_GEN_SUN6I) || defined(CONFIG_MACH_SUN50I_H6)
> >> +#elif defined(CONFIG_SUNXI_GEN_SUN6I) || defined(CONFIG_SUN50I_GEN_H6)
> >>
> >>u8 res3[16];
> >>struct sunxi_wdog wdog[5]; /* We have 5 watchdogs */
> >>
> >> #endif
> >>
> >> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> >> index 49ef217f08c0..1cf79bad7cf6 100644
> >> --- a/arch/arm/mach-sunxi/Kconfig
> >> +++ b/arch/arm/mach-sunxi/Kconfig
> >> @@ -82,7 +82,7 @@ config SUN8I_RSB
> >>
> >> config SUNXI_SRAM_ADDRESS
> >>
> >>hex
> >>default 0x1 if MACH_SUN9I || MACH_SUN50I || MACH_SUN50I_H5
> >>
> >> - default 0x2 if MACH_SUN50I_H6
> >> + default 0x2 if SUN50I_GEN_H6
> >>
> >>default 0x0
> >>---help---
> >>Older Allwinner SoCs have their mask boot ROM mapped just below
4GB,
> >>
> >> @@ -108,6 +108,15 @@ config SUNXI_GEN_SUN6I
> >>
> >>separate ahb reset control registers, custom pmic bus, new style
> >>watchdog, etc.
> >>
> >> +config SUN50I_GEN_H6
> >
> > The new memory map is also used for 32-bit SoCs V5 (sun8iw12p1) and
> > newer. So this is not sun50i-specific, and I'd suggest SUNXI_GEN_H6 (or
> > even SUNXI_GEN_H6_V5). It is unfortunate there appears to be no name for
> > this family.
>
> Yeah, the Allwinner generation naming being *core* dependent is really
> annyoing and not helpful.
> I am fine with a rename, but then it would be very close to
> "CONFIG_SUNXI_GEN_SUN6I", which is quite confusing to any readers
> (already stumbled upon it myself in patch 04/17).
[PATCH 1/1] arm: dart6ul: enable DM_ETH for the dart6ul
From: Marc Ferland
This patch converts the dart6ul ethernet support to DM_ETH and cleans
up the legacy ethernet code. The clean up, more specifically:
* moves the fec2 node and pin definition to the carrier board DTS
since the phy associated with it is on the carrier board and not on
the SoM;
* add the reset pin associated to each phy;
* separate the ethernet, mdio and reset pins of each fec so that they
are easier to reference;
* add clock properties to the phy nodes since they are connected to the
50Mhz ENET[12]_TX_CLK clock of the SoC;
* remove CONFIG_BOARD_EARLY_INIT_F since the function is now empty.
Signed-off-by: Marc Ferland
---
arch/arm/dts/imx6ull-dart-6ul.dts | 48 +++
arch/arm/dts/imx6ull-dart-6ul.dtsi | 57 +--
board/variscite/dart_6ul/dart_6ul.c | 72 +
board/variscite/dart_6ul/spl.c | 3 --
configs/variscite_dart6ul_defconfig | 2 +-
include/configs/dart_6ul.h | 7 ---
6 files changed, 73 insertions(+), 116 deletions(-)
diff --git a/arch/arm/dts/imx6ull-dart-6ul.dts
b/arch/arm/dts/imx6ull-dart-6ul.dts
index 4cab1a048b..9e217ba09f 100644
--- a/arch/arm/dts/imx6ull-dart-6ul.dts
+++ b/arch/arm/dts/imx6ull-dart-6ul.dts
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0+
/*
* Copyright (C) 2019 Parthiban Nallathambi
+ * Copyright (C) 2021 Marc Ferland, Amotus Solutions Inc.,
*/
/dts-v1/;
@@ -13,6 +14,28 @@
compatible = "variscite,imx6ull-dart-6ul", "fsl,imx6ull";
};
+&mdio1 {
+ /* KSZ8081RNB (carrier-board) */
+ ethphy1: ethernet-phy@3 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ clocks = <&clks IMX6UL_CLK_ENET2_REF>;
+ clock-names = "rmii-ref";
+ micrel,led-mode = <1>;
+ max-speed = <100>;
+ reg = <3>;
+ };
+};
+
+&fec2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet2 &pinctrl_enet2_rst>;
+ phy-mode = "rmii";
+ phy-handle = <ðphy1>;
+ phy-reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
+ phy-reset-duration = <100>;
+ status = "okay";
+};
+
&usdhc2 {
status = "okay";
};
@@ -36,4 +59,29 @@
>;
};
+ pinctrl_enet2: enet2grp {
+ fsl,pins = <
+ MX6UL_PAD_ENET2_RX_EN__ENET2_RX_EN 0x1b0b0
+ MX6UL_PAD_ENET2_RX_ER__ENET2_RX_ER 0x1b0b0
+ MX6UL_PAD_ENET2_RX_DATA0__ENET2_RDATA00 0x1b0b0
+ MX6UL_PAD_ENET2_RX_DATA1__ENET2_RDATA01 0x1b0b0
+ MX6UL_PAD_ENET2_TX_EN__ENET2_TX_EN 0x1b0b0
+ MX6UL_PAD_ENET2_TX_DATA0__ENET2_TDATA00 0x1b0b0
+ MX6UL_PAD_ENET2_TX_DATA1__ENET2_TDATA01 0x1b0b0
+ MX6UL_PAD_ENET2_TX_CLK__ENET2_REF_CLK2 0x4001b031
+ >;
+ };
+
+ pinctrl_enet2_mdio: mdio_enet2_grp {
+ fsl,pins = <
+ MX6UL_PAD_GPIO1_IO07__ENET2_MDC 0x1b0b0
+ MX6UL_PAD_GPIO1_IO06__ENET2_MDIO0x1b0b0
+ >;
+ };
+
+ pinctrl_enet2_rst: enet2-rst-grp {
+ fsl,pins = <
+ MX6UL_PAD_JTAG_MOD__GPIO1_IO10 0x1b0b0
+ >;
+ };
};
diff --git a/arch/arm/dts/imx6ull-dart-6ul.dtsi
b/arch/arm/dts/imx6ull-dart-6ul.dtsi
index 805a382da9..fab926f5b7 100644
--- a/arch/arm/dts/imx6ull-dart-6ul.dtsi
+++ b/arch/arm/dts/imx6ull-dart-6ul.dtsi
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0+
/*
* Copyright (C) 2019 Parthiban Nallathambi
+ * Copyright (C) 2021 Marc Ferland, Amotus Solutions Inc.,
*/
/ {
@@ -22,36 +23,25 @@
&fec1 {
pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_enet1>;
+ pinctrl-0 = <&pinctrl_enet1 &pinctrl_enet1_rst &pinctrl_enet1_mdio>;
phy-mode = "rmii";
phy-handle = <ðphy0>;
+ phy-reset-gpios = <&gpio5 0 GPIO_ACTIVE_LOW>;
+ phy-reset-duration = <100>;
status = "okay";
- mdio1: mdio1 {
+ mdio1: mdio {
#address-cells = <1>;
#size-cells = <0>;
+ /* KSZ8081RNB (SoM) */
ethphy0: ethernet-phy@1 {
- reg = <1>;
- micrel,led-mode = <1>;
- };
- };
-};
-
-&fec2 {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_enet2>;
- phy-mode = "rmii";
- phy-handle = <ðphy1>;
- status = "okay";
-
- mdio2: mdio2 {
- #address-cells = <1>;
- #size-cells = <0>;
-
- ethphy1: ethernet-phy@2 {
- reg = <2>;
+ compatible = "ethernet-phy-ieee802.3-c22";
+ clocks = <&clks IMX6UL_CLK_ENET_REF>;
+ clock-names = "rmii-ref";
micrel,led-mode = <1>;
+
[PATCH] spi: renesas_rpc_spi: Fix fallback compatibility string
A generic compatibility string was added, but it doesn't match the
name used by Linux or the device tree bindings from any of the SoC's.
Fix it to read "renesas,rcar-gen3-rpc-if"
Fixes: 2f220c639a2a ("spi: renesas_rpc_spi: Add R-Car Gen3 and RZ/G2 fallback
compatibility string")
Signed-off-by: Adam Ford
diff --git a/drivers/spi/renesas_rpc_spi.c b/drivers/spi/renesas_rpc_spi.c
index d0ff918af8..0724a03a34 100644
--- a/drivers/spi/renesas_rpc_spi.c
+++ b/drivers/spi/renesas_rpc_spi.c
@@ -454,7 +454,7 @@ static const struct udevice_id rpc_spi_ids[] = {
{ .compatible = "renesas,rpc-r8a77965" },
{ .compatible = "renesas,rpc-r8a77970" },
{ .compatible = "renesas,rpc-r8a77995" },
- { .compatible = "renesas,rcar-gen3-rpc" },
+ { .compatible = "renesas,rcar-gen3-rpc-if" },
{ }
};
--
2.25.1
Re: [PATCH 8/9] fastboot: Allow u-boot-style partitions
On 12/31/20 5:48 PM, Sean Anderson wrote:
> This adds support for partitions of the form "dev.hwpart:part" and
> "dev#partname". This allows one to flash to eMMC boot partitions without
> having to use CONFIG_FASTBOOT_MMC_BOOT1_SUPPORT. It also allows one to
> flash to an entire device without needing CONFIG_FASTBOOT_MMC_USER_NAME.
> Lastly, one can also flash MMC devices other than
> CONFIG_FASTBOOT_FLASH_MMC_DEV.
>
> Because devices can be specified explicitly,
CONFIG_FASTBOOT_FLASH_MMC_DEV
> is used only when necessary for existing functionality. For those cases,
> fastboot_mmc_get_dev has been added as a helper function. This allows
>
> There should be no conflicts with the existing system, but just in
case, I
> have ordered detection of these names after all existing names.
>
> The fastboot_mmc_part test has been updated for these new names.
>
> Signed-off-by: Sean Anderson
> ---
>
> drivers/fastboot/fb_mmc.c | 150 +++---
> test/dm/fastboot.c| 37 +-
> 2 files changed, 127 insertions(+), 60 deletions(-)
>
> diff --git a/drivers/fastboot/fb_mmc.c b/drivers/fastboot/fb_mmc.c
> index b0610d3151..a52b1e3ed6 100644
> --- a/drivers/fastboot/fb_mmc.c
> +++ b/drivers/fastboot/fb_mmc.c
> @@ -37,6 +37,7 @@ static int raw_part_get_info_by_name(struct
blk_desc *dev_desc,
>char *raw_part_desc;
>const char *argv[2];
>const char **parg = argv;
> + int ret;
>
>/* check for raw partition descriptor */
>strcpy(env_desc_name, "fastboot_raw_partition_");
> @@ -60,7 +61,7 @@ static int raw_part_get_info_by_name(struct
blk_desc *dev_desc,
>
>info->start = simple_strtoul(argv[0], NULL, 0);
>info->size = simple_strtoul(argv[1], NULL, 0);
> - info->blksz = dev_desc->blksz;
> + info->blksz = *dev_desc->blksz;
>strncpy((char *)info->name, name, PART_NAME_LEN);
Looks like this slipped through while rebasing. The above two hunks
shouldn't have been included; will be fixed in v2.
--Sean
>
>if (raw_part_desc) {
> @@ -76,12 +77,37 @@ static int raw_part_get_info_by_name(struct
blk_desc *dev_desc,
>return 0;
> }
>
> -static int part_get_info_by_name_or_alias(struct blk_desc *dev_desc,
> - const char *name, struct disk_partition *info)
> +static int do_get_part_info(struct blk_desc **dev_desc, const char
*name,
> + struct disk_partition *info)
> +{
> + int ret;
> +
> + /* First try partition names on the default device */
> + *dev_desc = blk_get_dev("mmc", CONFIG_FASTBOOT_FLASH_MMC_DEV);
> + if (*dev_desc) {
> + ret = part_get_info_by_name(*dev_desc, name, info);
> + if (ret >= 0)
> + return ret;
> +
> + /* Then try raw partitions */
> + ret = raw_part_get_info_by_name(*dev_desc, name, info);
> + if (ret >= 0)
> + return ret;
> + }
> +
> + /* Then try dev.hwpart:part */
> + ret = part_get_info_by_dev_and_name_or_num("mmc", name, dev_desc,
> + info, true);
> + return ret;
> +}
> +
> +static int part_get_info_by_name_or_alias(struct blk_desc **dev_desc,
> +const char *name,
> +struct disk_partition *info)
> {
>int ret;
>
> - ret = part_get_info_by_name(dev_desc, name, info);
> + ret = do_get_part_info(dev_desc, name, info);
>if (ret < 0) {
>/* strlen("fastboot_partition_alias_") + PART_NAME_LEN + 1 */
>char env_alias_name[25 + PART_NAME_LEN + 1];
> @@ -92,8 +118,8 @@ static int part_get_info_by_name_or_alias(struct
blk_desc *dev_desc,
>strncat(env_alias_name, name, PART_NAME_LEN);
>aliased_part_name = env_get(env_alias_name);
>if (aliased_part_name != NULL)
> - ret = part_get_info_by_name(dev_desc,
> - aliased_part_name, info);
> + ret = do_get_part_info(dev_desc, aliased_part_name,
> + info);
>}
>return ret;
> }
> @@ -424,27 +450,49 @@ int fastboot_mmc_get_part_info(const char
*part_name,
> struct blk_desc **dev_desc,
> struct disk_partition *part_info, char *response)
> {
> - int r = 0;
> + int ret;
>
> - *dev_desc = blk_get_dev("mmc", CONFIG_FASTBOOT_FLASH_MMC_DEV);
> - if (!*dev_desc) {
> - fastboot_fail("block device not found", response);
> - return -ENOENT;
> - }
>if (!part_name || !strcmp(part_name, "")) {
>fastboot_fail("partition not given", response);
>return -ENOENT;
>}
>
> - if (raw_part_get_info_by_name(*dev_desc, part_name, part_info) < 0) {
> - r = part_get_info_by_name_or_alias(*dev_desc, part_name,
part_info);
> - if (r < 0) {
> - fastboot_fail("partition not found", response);
> - return r;
> + ret = part_get_info_by_name_
Re: [PATCH v2] cmd: pxe: add support for FDT overlays
Dne ponedeljek, 04. januar 2021 ob 15:41:17 CET je Tom Rini napisal(a): > On Mon, Jan 04, 2021 at 03:33:43PM +0100, Neil Armstrong wrote: > > This adds support for specifying FDT overlays in an extlinux/pxelinux > > configuration file. > > > > Without this, there is no simple way to apply overlays when the kernel > > and fdt is loaded by the pxe command. > > > > This change adds the 'fdtoverlays' keyword for a label, supporting > > multiple > > overlay files to be applied on top of the fdt specified in the 'fdt' or > > 'devicetree' keyword. > > > > Example: > > label linux > > > > kernel /Image > > devicetree /soc-board.dtb This should be "fdt /soc-board.dtb", > > fdtoverlays /soc-board-function.dtbo > > append console=ttyS0,115200 root=/dev/mmcblk0p2 rootwait > > > > This code makes usage of a new variable called fdtoverlay_addr_r used to > > load the overlay files without overwritting anything important. > > > > Cc: Tom Rini > > Cc: Andre Heider > > Cc: Jernej Škrabec > > Cc: Jonas Karlman > > Signed-off-by: Neil Armstrong Tested-by: Jernej Skrabec With above fix: Reviewed-by: Jernej Skrabec > > --- > > Hi Tom, > > > > This is repost of my last year's attempt. > > It fills a hole to allow loading FDT overlays using PXE/Extlinux without > > using FIT. > > > > V2 adds documentation. > > Thanks for following up. I assume this follows what the spec says for > this file? Which specs? Official extlinux configuration specs [1] don't say anything about device tree files, so anything related to that is an extension (I hope I found correct specs). I think this one is extremely useful, users can easily specify which overlay file(s) they want to be applied in a text file. Best regards, Jernej [1] https://repo.or.cz/syslinux.git/blob/HEAD:/doc/syslinux.txt
[PATCH] MAINTAINERS: Update STi and STM32 maintainers emails in remaining files
A previous series already update STMicroelectronics emails maintainers but some files have been omitted (Makefile, .dts, .dtsi and .rst files). Update Patrick and my email address with the one dedicated to upstream activities. Signed-off-by: Patrice Chotard --- arch/arm/dts/stih410-b2260-u-boot.dtsi| 2 +- arch/arm/dts/stih410-b2260.dts| 2 +- arch/arm/dts/stm32429i-eval-u-boot.dtsi | 2 +- arch/arm/dts/stm32f429-disco-u-boot.dtsi | 2 +- arch/arm/dts/stm32f469-disco-u-boot.dtsi | 2 +- arch/arm/dts/stm32h743i-disco.dts | 2 +- board/st/common/MAINTAINERS | 2 +- board/st/stih410-b2260/MAINTAINERS| 2 +- board/st/stih410-b2260/Makefile | 2 +- board/st/stm32f429-evaluation/MAINTAINERS | 2 +- board/st/stm32f429-evaluation/Makefile| 2 +- board/st/stm32f469-discovery/MAINTAINERS | 2 +- board/st/stm32f469-discovery/Makefile | 2 +- board/st/stm32h743-disco/MAINTAINERS | 2 +- board/st/stm32h743-disco/Makefile | 2 +- board/st/stm32h743-eval/MAINTAINERS | 2 +- board/st/stm32h743-eval/Makefile | 2 +- board/st/stm32mp1/MAINTAINERS | 2 +- doc/board/st/stm32mp1.rst | 2 +- doc/driver-model/bind.rst | 2 +- 20 files changed, 20 insertions(+), 20 deletions(-) diff --git a/arch/arm/dts/stih410-b2260-u-boot.dtsi b/arch/arm/dts/stih410-b2260-u-boot.dtsi index 897c42146a..3b080ac7a1 100644 --- a/arch/arm/dts/stih410-b2260-u-boot.dtsi +++ b/arch/arm/dts/stih410-b2260-u-boot.dtsi @@ -1,7 +1,7 @@ // SPDX-License-Identifier: GPL-2.0 /* * Copyright (C) 2018, STMicroelectronics - All Rights Reserved - * Author(s): Patrice Chotard, for STMicroelectronics. + * Author(s): Patrice Chotard, for STMicroelectronics. * */ diff --git a/arch/arm/dts/stih410-b2260.dts b/arch/arm/dts/stih410-b2260.dts index 4fbd8e9eb5..8c4155b622 100644 --- a/arch/arm/dts/stih410-b2260.dts +++ b/arch/arm/dts/stih410-b2260.dts @@ -1,7 +1,7 @@ // SPDX-License-Identifier: GPL-2.0-only /* * Copyright (C) 2016 STMicroelectronics (R&D) Limited. - * Author: Patrice Chotard + * Author: Patrice Chotard */ /dts-v1/; #include "stih410.dtsi" diff --git a/arch/arm/dts/stm32429i-eval-u-boot.dtsi b/arch/arm/dts/stm32429i-eval-u-boot.dtsi index e75cf99f8f..09d9d9ab9b 100644 --- a/arch/arm/dts/stm32429i-eval-u-boot.dtsi +++ b/arch/arm/dts/stm32429i-eval-u-boot.dtsi @@ -1,7 +1,7 @@ // SPDX-License-Identifier: GPL-2.0+ /* * Copyright (C) 2018, STMicroelectronics - All Rights Reserved - * Author(s): Patrice Chotard, for STMicroelectronics. + * Author(s): Patrice Chotard, for STMicroelectronics. */ #include diff --git a/arch/arm/dts/stm32f429-disco-u-boot.dtsi b/arch/arm/dts/stm32f429-disco-u-boot.dtsi index df99e01393..297cc56144 100644 --- a/arch/arm/dts/stm32f429-disco-u-boot.dtsi +++ b/arch/arm/dts/stm32f429-disco-u-boot.dtsi @@ -1,7 +1,7 @@ // SPDX-License-Identifier: GPL-2.0+ /* * Copyright (C) 2017, STMicroelectronics - All Rights Reserved - * Author(s): Patrice Chotard, for STMicroelectronics. + * Author(s): Patrice Chotard, for STMicroelectronics. */ #include diff --git a/arch/arm/dts/stm32f469-disco-u-boot.dtsi b/arch/arm/dts/stm32f469-disco-u-boot.dtsi index 7223ba4a60..9eda8f535b 100644 --- a/arch/arm/dts/stm32f469-disco-u-boot.dtsi +++ b/arch/arm/dts/stm32f469-disco-u-boot.dtsi @@ -1,7 +1,7 @@ // SPDX-License-Identifier: GPL-2.0+ /* * Copyright (C) 2017, STMicroelectronics - All Rights Reserved - * Author(s): Patrice Chotard, for STMicroelectronics. + * Author(s): Patrice Chotard, for STMicroelectronics. */ #include diff --git a/arch/arm/dts/stm32h743i-disco.dts b/arch/arm/dts/stm32h743i-disco.dts index 81007161e7..7927310d8e 100644 --- a/arch/arm/dts/stm32h743i-disco.dts +++ b/arch/arm/dts/stm32h743i-disco.dts @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0+ OR X11 /* - * Copyright 2017 - Patrice Chotard + * Copyright 2017 - Patrice Chotard * */ diff --git a/board/st/common/MAINTAINERS b/board/st/common/MAINTAINERS index 3b02f4ab98..c4e0c5fd94 100644 --- a/board/st/common/MAINTAINERS +++ b/board/st/common/MAINTAINERS @@ -1,5 +1,5 @@ ST BOARDS -M: Patrick Delaunay +M: Patrick Delaunay L: uboot-st...@st-md-mailman.stormreply.com (moderated for non-subscribers) T: git https://gitlab.denx.de/u-boot/custodians/u-boot-stm.git S: Maintained diff --git a/board/st/stih410-b2260/MAINTAINERS b/board/st/stih410-b2260/MAINTAINERS index 4f557ac7d9..6fa625507b 100644 --- a/board/st/stih410-b2260/MAINTAINERS +++ b/board/st/stih410-b2260/MAINTAINERS @@ -1,5 +1,5 @@ STIH410-B2260 BOARD -M: Patrice Chotard +M: Patrice Chotard S: Maintained F: board/st/stih410-b2260/ F: include/configs/stih410-b2260.h diff --git a/board/st/stih410-b2260/Makefile b/board/st/stih410-b2260/Makefile index dc3e1d3959..ea573ca145 100644 --- a/board/st/stih410-b2260/Makefile +++ b/board/st/stih410-b2260/Makefile @@ -1,6 +1,6
Re: [PATCH v2] cmd: pxe: add support for FDT overlays
On Mon, Jan 04, 2021 at 03:33:43PM +0100, Neil Armstrong wrote: > This adds support for specifying FDT overlays in an extlinux/pxelinux > configuration file. > > Without this, there is no simple way to apply overlays when the kernel > and fdt is loaded by the pxe command. > > This change adds the 'fdtoverlays' keyword for a label, supporting multiple > overlay files to be applied on top of the fdt specified in the 'fdt' or > 'devicetree' keyword. > > Example: > label linux > kernel /Image > devicetree /soc-board.dtb > fdtoverlays /soc-board-function.dtbo > append console=ttyS0,115200 root=/dev/mmcblk0p2 rootwait > > This code makes usage of a new variable called fdtoverlay_addr_r used to load > the overlay files without overwritting anything important. > > Cc: Tom Rini > Cc: Andre Heider > Cc: Jernej Škrabec > Cc: Jonas Karlman > Signed-off-by: Neil Armstrong > --- > Hi Tom, > > This is repost of my last year's attempt. > It fills a hole to allow loading FDT overlays using PXE/Extlinux without > using FIT. > > V2 adds documentation. Thanks for following up. I assume this follows what the spec says for this file? -- Tom signature.asc Description: PGP signature
Re: Pull request for UEFI sub-system for next
On Mon, Jan 04, 2021 at 03:30:47PM +0100, Heinrich Schuchardt wrote: > On 04.01.21 14:27, Ilias Apalodimas wrote: > > On Sat, Jan 02, 2021 at 05:42:23PM -0500, Tom Rini wrote: > >> On Thu, Dec 31, 2020 at 05:25:14PM +0100, Heinrich Schuchardt wrote: > >> > >>> Dear Tom, > >>> > >>> please, merge into origin/next. > >>> > >>> @Takahiro, Ilias, Sughosh > >>> *Thanks a lot for all your contributions this year.* > >>> > >>> The following changes since commit > >>> 958b9e2482538ebfeb2e1161257603d4dec498cb: > >>> > >>> Merge tag 'dm-next-23dec20' of git://git.denx.de/u-boot-dm into next > >>> (2020-12-23 18:10:15 -0500) > >>> > >>> are available in the Git repository at: > >>> > >>> https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git tags/efi-next > >>> > >>> for you to fetch changes up to c35df7c9e43eaf5f8bf2113a58ea257291988589: > >>> > >>> qemu: arm64: Add documentation for capsule update (2020-12-31 > >>> 14:41:31 +0100) > >>> > >>> Gitlab CI showed no problems: > >>> https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/5718 > >>> > >> > >> Applied to u-boot/master, thanks! > > @Tom > This seems to be a typo. You applied the series to u-boot/next. Yes, sorry. -- Tom signature.asc Description: PGP signature
[PATCH v2] cmd: pxe: add support for FDT overlays
This adds support for specifying FDT overlays in an extlinux/pxelinux
configuration file.
Without this, there is no simple way to apply overlays when the kernel
and fdt is loaded by the pxe command.
This change adds the 'fdtoverlays' keyword for a label, supporting multiple
overlay files to be applied on top of the fdt specified in the 'fdt' or
'devicetree' keyword.
Example:
label linux
kernel /Image
devicetree /soc-board.dtb
fdtoverlays /soc-board-function.dtbo
append console=ttyS0,115200 root=/dev/mmcblk0p2 rootwait
This code makes usage of a new variable called fdtoverlay_addr_r used to load
the overlay files without overwritting anything important.
Cc: Tom Rini
Cc: Andre Heider
Cc: Jernej Škrabec
Cc: Jonas Karlman
Signed-off-by: Neil Armstrong
---
Hi Tom,
This is repost of my last year's attempt.
It fills a hole to allow loading FDT overlays using PXE/Extlinux without
using FIT.
V2 adds documentation.
Neil
cmd/pxe_utils.c | 103
cmd/pxe_utils.h | 1 +
doc/README.pxe | 9 +
3 files changed, 113 insertions(+)
diff --git a/cmd/pxe_utils.c b/cmd/pxe_utils.c
index 8716e782f6..25367190a7 100644
--- a/cmd/pxe_utils.c
+++ b/cmd/pxe_utils.c
@@ -13,6 +13,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -284,6 +286,9 @@ static void label_destroy(struct pxe_label *label)
if (label->fdtdir)
free(label->fdtdir);
+ if (label->fdtoverlays)
+ free(label->fdtoverlays);
+
free(label);
}
@@ -331,6 +336,92 @@ static int label_localboot(struct pxe_label *label)
return run_command_list(localcmd, strlen(localcmd), 0);
}
+/*
+ * Loads fdt overlays specified in 'fdtoverlays'.
+ */
+#ifdef CONFIG_OF_LIBFDT_OVERLAY
+static void label_boot_fdtoverlay(struct cmd_tbl *cmdtp, struct pxe_label
*label)
+{
+ char *fdtoverlay = label->fdtoverlays;
+ struct fdt_header *working_fdt;
+ char *fdtoverlay_addr_env;
+ ulong fdtoverlay_addr;
+ ulong fdt_addr;
+ int err;
+
+ /* Get the main fdt and map it */
+ fdt_addr = simple_strtoul(env_get("fdt_addr_r"), NULL, 16);
+ working_fdt = map_sysmem(fdt_addr, 0);
+ err = fdt_check_header(working_fdt);
+ if (err)
+ return;
+
+ /* Get the specific overlay loading address */
+ fdtoverlay_addr_env = env_get("fdtoverlay_addr_r");
+ if (!fdtoverlay_addr_env) {
+ printf("Invalid fdtoverlay_addr_r for loading overlays\n");
+ return;
+ }
+
+ fdtoverlay_addr = simple_strtoul(fdtoverlay_addr_env, NULL, 16);
+
+ /* Cycle over the overlay files and apply them in order */
+ do {
+ struct fdt_header *blob;
+ char *overlayfile;
+ char *end;
+ int len;
+
+ /* Drop leading spaces */
+ while (*fdtoverlay == ' ')
+ ++fdtoverlay;
+
+ /* Copy a single filename if multiple provided */
+ end = strstr(fdtoverlay, " ");
+ if (end) {
+ len = (int)(end - fdtoverlay);
+ overlayfile = malloc(len + 1);
+ strncpy(overlayfile, fdtoverlay, len);
+ overlayfile[len] = '\0';
+ } else
+ overlayfile = fdtoverlay;
+
+ if (!strlen(overlayfile))
+ goto skip_overlay;
+
+ /* Load overlay file */
+ err = get_relfile_envaddr(cmdtp, overlayfile,
+ "fdtoverlay_addr_r");
+ if (err < 0) {
+ printf("Failed loading overlay %s\n", overlayfile);
+ goto skip_overlay;
+ }
+
+ /* Resize main fdt */
+ fdt_shrink_to_minimum(working_fdt, 8192);
+
+ blob = map_sysmem(fdtoverlay_addr, 0);
+ err = fdt_check_header(blob);
+ if (err) {
+ printf("Invalid overlay %s, skipping\n",
+ overlayfile);
+ goto skip_overlay;
+ }
+
+ err = fdt_overlay_apply_verbose(working_fdt, blob);
+ if (err) {
+ printf("Failed to apply overlay %s, skipping\n",
+ overlayfile);
+ goto skip_overlay;
+ }
+
+skip_overlay:
+ if (end)
+ free(overlayfile);
+ } while ((fdtoverlay = strstr(fdtoverlay, " ")));
+}
+#endif
+
/*
* Boot according to the contents of a pxe_label.
*
@@ -525,6 +616,11 @@ static int label_boot(struct cmd_tbl *cmdtp, struct
pxe_label *label)
label->name);
goto cleanup;
}
+
+#if
[PATCH] lib: cosmetic update of CONFIG_LIB_ELF description
Change 2 typo error in CONFIG_LIB_ELF description: - Supoort => Support - fir => for Signed-off-by: Patrick Delaunay --- lib/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/Kconfig b/lib/Kconfig index 7673d2e4e0..cc89fb4d91 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -695,7 +695,7 @@ config LIB_DATE config LIB_ELF bool help - Supoort basic elf loading/validating functions. - This supports fir 32 bit and 64 bit versions. + Support basic elf loading/validating functions. + This supports for 32 bit and 64 bit versions. endmenu -- 2.17.1
Re: Pull request for UEFI sub-system for next
On 04.01.21 14:27, Ilias Apalodimas wrote: > On Sat, Jan 02, 2021 at 05:42:23PM -0500, Tom Rini wrote: >> On Thu, Dec 31, 2020 at 05:25:14PM +0100, Heinrich Schuchardt wrote: >> >>> Dear Tom, >>> >>> please, merge into origin/next. >>> >>> @Takahiro, Ilias, Sughosh >>> *Thanks a lot for all your contributions this year.* >>> >>> The following changes since commit 958b9e2482538ebfeb2e1161257603d4dec498cb: >>> >>> Merge tag 'dm-next-23dec20' of git://git.denx.de/u-boot-dm into next >>> (2020-12-23 18:10:15 -0500) >>> >>> are available in the Git repository at: >>> >>> https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git tags/efi-next >>> >>> for you to fetch changes up to c35df7c9e43eaf5f8bf2113a58ea257291988589: >>> >>> qemu: arm64: Add documentation for capsule update (2020-12-31 >>> 14:41:31 +0100) >>> >>> Gitlab CI showed no problems: >>> https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/5718 >>> >> >> Applied to u-boot/master, thanks! @Tom This seems to be a typo. You applied the series to u-boot/next. >> > > 47d2b3b9c98e efi_loader: Remove unconditional installation of file2 protocol > for initrd > > will cause initrd loading to stop working. > This was supposed to go in when the additional patches for the new initrd > logic got merged. That's fine by me, since the feature was quite new and I > doubt we'll break any users. I intend to send the rest of the patches soon > anyway, so this is mostly a heads up. > @Ilias Patch "efi_loader: Remove unconditional installation of file2 protocol for initrd" only went into u-boot/next not into u-boot/master. So this will not appear in v2021.01. Best regards Heinrich
[PATCH] env: sf: cosmetic: remove unnecessary space
Remove the unnecessary space before the 2 "done:" labels
in env_sf_save().
Signed-off-by: Patrick Delaunay
---
env/sf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/env/sf.c b/env/sf.c
index 91ed2860ed..42d762714e 100644
--- a/env/sf.c
+++ b/env/sf.c
@@ -139,7 +139,7 @@ static int env_sf_save(void)
printf("Valid environment: %d\n", (int)gd->env_valid);
- done:
+done:
if (saved_buffer)
free(saved_buffer);
@@ -236,7 +236,7 @@ static int env_sf_save(void)
ret = 0;
puts("done\n");
- done:
+done:
if (saved_buffer)
free(saved_buffer);
--
2.17.1
Re: Pull request for UEFI sub-system for next
On Sat, Jan 02, 2021 at 05:42:23PM -0500, Tom Rini wrote: > On Thu, Dec 31, 2020 at 05:25:14PM +0100, Heinrich Schuchardt wrote: > > > Dear Tom, > > > > please, merge into origin/next. > > > > @Takahiro, Ilias, Sughosh > > *Thanks a lot for all your contributions this year.* > > > > The following changes since commit 958b9e2482538ebfeb2e1161257603d4dec498cb: > > > > Merge tag 'dm-next-23dec20' of git://git.denx.de/u-boot-dm into next > > (2020-12-23 18:10:15 -0500) > > > > are available in the Git repository at: > > > > https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git tags/efi-next > > > > for you to fetch changes up to c35df7c9e43eaf5f8bf2113a58ea257291988589: > > > > qemu: arm64: Add documentation for capsule update (2020-12-31 > > 14:41:31 +0100) > > > > Gitlab CI showed no problems: > > https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/5718 > > > > Applied to u-boot/master, thanks! > 47d2b3b9c98e efi_loader: Remove unconditional installation of file2 protocol for initrd will cause initrd loading to stop working. This was supposed to go in when the additional patches for the new initrd logic got merged. That's fine by me, since the feature was quite new and I doubt we'll break any users. I intend to send the rest of the patches soon anyway, so this is mostly a heads up. Cheers /Ilias > -- > Tom
Re: [PATCH 22/26] dm: core: Access device ofnode through functions
Hi Simon,
On 12/19/20 6:40 PM, Simon Glass wrote:
At present ofnode is present in the device even if it is never used. With
of-platdata this field is not used, so can be removed. In preparation for
this, change the access to go through inline functions.
Signed-off-by: Simon Glass
---
arch/arm/mach-stm32mp/pwr_regulator.c | 2 +-
board/synopsys/hsdk/clk-lib.c | 2 +-
drivers/ata/mtk_ahci.c| 3 ++-
drivers/clk/meson/axg.c | 2 +-
drivers/clk/meson/g12a.c | 2 +-
drivers/clk/meson/gxbb.c | 2 +-
drivers/core/device.c | 2 +-
drivers/core/root.c | 2 +-
drivers/gpio/mpc8xxx_gpio.c | 4 ++--
drivers/gpio/octeon_gpio.c| 2 +-
drivers/misc/swap_case.c | 2 +-
drivers/mmc/octeontx_hsmmc.c | 23 +--
drivers/mtd/nand/raw/octeontx_nand.c | 2 +-
drivers/mtd/nand/spi/core.c | 2 +-
drivers/net/fm/eth.c | 4 ++--
drivers/net/fsl_enetc.c | 8
drivers/net/fsl_enetc_mdio.c | 2 +-
drivers/net/mdio-ipq4019.c| 4 ++--
drivers/net/mdio_mux_i2creg.c | 2 +-
drivers/net/mvmdio.c | 4 ++--
drivers/net/octeontx/smi.c| 2 +-
drivers/net/tsec.c| 3 ++-
drivers/phy/phy-ti-am654.c| 2 +-
drivers/power/domain/meson-ee-pwrc.c | 4 ++--
drivers/power/domain/meson-gx-pwrc-vpu.c | 4 ++--
drivers/power/regulator/pbias_regulator.c | 3 ++-
drivers/pwm/pwm-meson.c | 9 ++---
drivers/reset/reset-socfpga.c | 2 +-
drivers/spi/fsl_dspi.c| 6 --
drivers/tee/optee/core.c | 2 +-
drivers/usb/cdns3/core.c | 4 ++--
drivers/usb/dwc3/core.c | 2 +-
drivers/usb/dwc3/dwc3-generic.c | 6 +++---
drivers/usb/dwc3/dwc3-meson-g12a.c| 2 +-
drivers/usb/dwc3/dwc3-meson-gxl.c | 2 +-
drivers/usb/gadget/dwc2_udc_otg.c | 4 ++--
drivers/usb/host/dwc3-octeon-glue.c | 2 +-
drivers/usb/host/dwc3-sti-glue.c | 5 +++--
drivers/usb/host/ehci-mx6.c | 2 +-
drivers/usb/host/xhci-dwc3.c | 2 +-
drivers/usb/mtu3/mtu3_core.c | 2 +-
drivers/usb/mtu3/mtu3_plat.c | 4 ++--
drivers/usb/musb-new/ti-musb.c| 2 +-
drivers/video/nexell_display.c| 2 +-
drivers/video/rockchip/rk_mipi.c | 2 +-
include/dm/device.h | 23 +--
include/dm/read.h | 2 +-
include/linux/mtd/mtd.h | 4 ++--
net/mdio-mux-uclass.c | 2 +-
net/mdio-uclass.c | 8
50 files changed, 113 insertions(+), 82 deletions(-)
in all the modified drivers,
for the functions ofnode_(dev->node,...) modified to
ofnode_(dev_ofnode(dev),
they can also modified to dev_XXX function :
ofnode_read_u32(dev_ofnode(dev), ...) => dev_read_u32(dev,)
ofnode_read_string(dev_ofnode(dev), ...) => dev_read_string(dev,)
ofnode_valid(dev_ofnode(dev)) => dev_has_ofnode(dev)
but you prefer perhaps minizes the modifications in this patchset and if
it is the case :
Reviewed-by: Patrick Delaunay
You can found some other examples below.
diff --git a/arch/arm/mach-stm32mp/pwr_regulator.c
b/arch/arm/mach-stm32mp/pwr_regulator.c
index af6ea439646..766ed95f1a6 100644
--- a/arch/arm/mach-stm32mp/pwr_regulator.c
+++ b/arch/arm/mach-stm32mp/pwr_regulator.c
@@ -81,7 +81,7 @@ static int stm32mp_pwr_bind(struct udevice *dev)
{
int children;
- children = pmic_bind_children(dev, dev->node, pwr_children_info);
+ children = pmic_bind_children(dev, dev_ofnode(dev), pwr_children_info);
if (!children)
dev_dbg(dev, "no child found\n");
diff --git a/board/synopsys/hsdk/clk-lib.c b/board/synopsys/hsdk/clk-lib.c
index 1c74bfb93a3..bd43179fc79 100644
--- a/board/synopsys/hsdk/clk-lib.c
+++ b/board/synopsys/hsdk/clk-lib.c
@@ -23,8 +23,8 @@ int soc_clk_ctl(const char *name, ulong *rate, enum
clk_ctl_ops ctl)
/* Dummy fmeas device, just to be able to use standard clk_* api */
struct udevice fmeas = {
.name = "clk-fmeas",
- .node = ofnode_path("/clk-fmeas"),
};
+ dev_set_ofnode(&fmeas, ofnode_path("/clk-fmeas"));
ret = clk_get_by_name(&fmeas, name, &clk);
if (ret) {
diff --git a/drivers/ata/mtk_ahci.c b/drivers/ata/mtk_ahci.c
index cd28e0cae37..46b7677783f 100644
--- a/drivers/ata/mtk_ahci.c
+++ b/drivers/ata/mtk_ahci.c
@@ -68,7 +68,8 @@ static int mtk_ahci_parse_property(struct ahci_uc_priv *hpriv,
SYS_CFG_SATA_M
[PATCH v2 2/2] phy: mv88e61xx: add support for MV88E6171
This patch add MV88E6171 id to driver data.
Tested on Checkpoint L-50 board.
Cc: Chris Packham
Cc: Joe Hershberger
Cc: Anatolij Gustschin
Cc: Tim Harvey
Signed-off-by: Pawel Dembicki
---
Changes in v2:
- resend only
drivers/net/phy/mv88e61xx.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/net/phy/mv88e61xx.c b/drivers/net/phy/mv88e61xx.c
index 70adec6578..432cc4165b 100644
--- a/drivers/net/phy/mv88e61xx.c
+++ b/drivers/net/phy/mv88e61xx.c
@@ -183,6 +183,7 @@
#define PORT_SWITCH_ID_60710x0710
#define PORT_SWITCH_ID_60960x0980
#define PORT_SWITCH_ID_60970x0990
+#define PORT_SWITCH_ID_61710x1710
#define PORT_SWITCH_ID_61720x1720
#define PORT_SWITCH_ID_61760x1760
#define PORT_SWITCH_ID_62200x2200
@@ -1051,6 +1052,7 @@ static int mv88e61xx_probe(struct phy_device *phydev)
switch (priv->id) {
case PORT_SWITCH_ID_6096:
case PORT_SWITCH_ID_6097:
+ case PORT_SWITCH_ID_6171:
case PORT_SWITCH_ID_6172:
case PORT_SWITCH_ID_6176:
case PORT_SWITCH_ID_6240:
@@ -1206,6 +1208,17 @@ static struct phy_driver mv88e61xx_driver = {
.shutdown = &genphy_shutdown,
};
+static struct phy_driver mv88e617x_driver = {
+ .name = "Marvell MV88E617x",
+ .uid = 0x01410e70,
+ .mask = 0xfff0,
+ .features = PHY_GBIT_FEATURES,
+ .probe = mv88e61xx_probe,
+ .config = mv88e61xx_phy_config,
+ .startup = mv88e61xx_phy_startup,
+ .shutdown = &genphy_shutdown,
+};
+
static struct phy_driver mv88e609x_driver = {
.name = "Marvell MV88E609x",
.uid = 0x1410c89,
@@ -1231,6 +1244,7 @@ static struct phy_driver mv88e6071_driver = {
int phy_mv88e61xx_init(void)
{
phy_register(&mv88e61xx_driver);
+ phy_register(&mv88e617x_driver);
phy_register(&mv88e609x_driver);
phy_register(&mv88e6071_driver);
--
2.25.1
[PATCH v2 1/2] phy: mv88e61xx: add support for RGMII TX/RX delay
Clock delay in RGMII is required for some boards.
Clock delay is read from phy-mode dts property. Delay is configured via
proper bits in PORT_REG_PHYS_CTRL register.
Cc: Chris Packham
Cc: Joe Hershberger
Cc: Anatolij Gustschin
Cc: Tim Harvey
Cc: Tom Rini
Signed-off-by: Pawel Dembicki
---
Changes in v2:
- change source info about delay: from hardcode to phy-mode propoperty in dts
drivers/net/phy/mv88e61xx.c | 62 -
1 file changed, 61 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/mv88e61xx.c b/drivers/net/phy/mv88e61xx.c
index 7eff37b244..70adec6578 100644
--- a/drivers/net/phy/mv88e61xx.c
+++ b/drivers/net/phy/mv88e61xx.c
@@ -97,6 +97,8 @@
#define PORT_REG_STATUS_CMODE_1000BASE_X 0x9
#define PORT_REG_STATUS_CMODE_SGMII0xa
+#define PORT_REG_PHYS_CTRL_RGMII_RX_DELAY BIT(15)
+#define PORT_REG_PHYS_CTRL_RGMII_TX_DELAY BIT(14)
#define PORT_REG_PHYS_CTRL_PCS_AN_EN BIT(10)
#define PORT_REG_PHYS_CTRL_PCS_AN_RST BIT(9)
#define PORT_REG_PHYS_CTRL_FC_VALUEBIT(7)
@@ -729,7 +731,45 @@ unforce:
static int mv88e61xx_fixed_port_setup(struct phy_device *phydev, u8 port)
{
struct mv88e61xx_phy_priv *priv = phydev->priv;
- int val;
+ ofnode node;
+ const char *str;
+ int val, phy_mode;
+ u32 phy_handle;
+
+ if (!ofnode_valid(phydev->node)) {
+ node = dev_ofnode(phydev->dev);
+ phy_handle = ofnode_read_u32_default(node, "phy-handle",
-ENXIO);
+
+ if (phy_handle == -ENXIO) {
+ node = ofnode_first_subnode(node);
+
+ while (ofnode_valid(node)) {
+ phy_handle = ofnode_read_u32_default(node,
"phy-handle", -ENXIO);
+ if (phy_handle != -ENXIO)
+ break;
+ node = ofnode_next_subnode(node);
+ }
+ }
+
+ if (phy_handle != -ENXIO)
+ node = ofnode_get_by_phandle(phy_handle);
+ else
+ node = ofnode_null();
+ } else {
+ node = phy_get_ofnode(phydev);
+ }
+
+ node = ofnode_find_subnode(node, "ports");
+ node = ofnode_first_subnode(node);
+
+ while (ofnode_valid(node)) {
+ u8 port_no = (u8)ofnode_read_u32_default(node, "reg", -1);
+
+ if (port_no == port)
+ break;
+
+ node = ofnode_next_subnode(node);
+ }
val = mv88e61xx_port_read(phydev, port, PORT_REG_PHYS_CTRL);
if (val < 0)
@@ -754,6 +794,26 @@ static int mv88e61xx_fixed_port_setup(struct phy_device
*phydev, u8 port)
val |= PORT_REG_PHYS_CTRL_LINK_VALUE |
PORT_REG_PHYS_CTRL_LINK_FORCE;
+ if (ofnode_valid(node)) {
+ str = ofnode_read_string(node, "phy-mode");
+ if (str)
+ phy_mode = phy_get_interface_by_name(str);
+ switch (phy_mode) {
+ case PHY_INTERFACE_MODE_RGMII_ID:
+ val |= PORT_REG_PHYS_CTRL_RGMII_RX_DELAY;
+ val |= PORT_REG_PHYS_CTRL_RGMII_TX_DELAY;
+ break;
+ case PHY_INTERFACE_MODE_RGMII_RXID:
+ val |= PORT_REG_PHYS_CTRL_RGMII_RX_DELAY;
+ break;
+ case PHY_INTERFACE_MODE_RGMII_TXID:
+ val |= PORT_REG_PHYS_CTRL_RGMII_TX_DELAY;
+ break;
+ default:
+ break;
+ }
+ }
+
return mv88e61xx_port_write(phydev, port, PORT_REG_PHYS_CTRL,
val);
}
--
2.25.1
Re: [PATCH v3 3/4] console: remove #ifdef CONFIG_CONSOLE_RECORD
On 12/19/20 4:34 AM, Simon Glass wrote: On Fri, 18 Dec 2020 at 04:46, Patrick Delaunay wrote: From: Patrick Delaunay Add helper functions to access to gd->console_out and gd->console_in I don't see those in this patch These helper function are console_record_putc() / _puts() / _getc() / _tstc(); they use "gd->console_out" and "gd->console_in" only if CONFIG_CONSOLE_RECORD is defined: diff --git a/common/console.c b/common/console.c index 036dd0358a..295c10f242 100644 --- a/common/console.c +++ b/common/console.c @@ -88,6 +88,64 @@ static int on_silent(const char *name, const char *value, enum env_op op, U_BOOT_ENV_CALLBACK(silent, on_silent); #endif +#ifdef CONFIG_CONSOLE_RECORD +/* helper function: access to gd->console_out and gd->console_in */ ... +#else ... stubs => do nothings +#endif with membuff API and replace the #ifdef CONFIG_CONSOLE_RECORD test by if (IS_ENABLED(CONFIG_CONSOLE_RECORD)) to respect the U-Boot coding rule. Signed-off-by: Patrick Delaunay Signed-off-by: Patrick Delaunay --- (no changes since v2) Changes in v2: - move the tests on gd->flags & GD_FLG_RECORD in helper functions - remove test on IS_ENABLED(CONFIG_CONSOLE_RECORD) before to call helper functions common/console.c | 95 +--- 1 file changed, 73 insertions(+), 22 deletions(-) Reviewed-by: Simon Glass Regards Patrick
Re: [PATCH v5 00/13] Raspberry Pi 400/Compute Module 4 support
On Sun, Jan 3, 2021 at 5:36 PM Nicolas Saenz Julienne wrote: > > Hi Peter, thanks for taking the time to test this, I'll send a new hopefully > definitive version soon. > > On Tue, 2020-12-29 at 10:58 +, Peter Robinson wrote: > > Hi Nicolas, > > > > With the xhci patch snippet the pci/xhci crash I was seeing is now gone. > > Yes that was unfortunate, I tested most revisions of this series on a board on > which I had forgotten contained an older firmware version which failed to > update the dma-ranges in DT. Hence missing the XHCI fix. One other thing to note, and I'm not sure if it's related to bits that U-Boot does or something else, but USB doesn't work in linux on the 8Gb model, does on all others inc the rpi-400, when booted on newer firmware Oct 15th works, Dec 15th doesn't. > > I am seeing an error which I need to test a bit more around mmc > > voltage select which I didn't see previously: > > > > Card did not respond to voltage select! : -110 > > I'll look into this myself, but I doubt it's related to this series in > particular. I did a bit more testing and I think it's unrelated as well, I'll try and dig some more when I get a moment. > > I'm going to do some wider testing. > > > > Overall this looks good > > Series Tested-by: Peter Robinson > > Thanks, > Nicolas >
[PATCH] xilinx: Fill git repository for Xilinx boards
All Xilinx SoCs have repository location filled already but boards are covered by different fragment which is missing this link. The patch is extending description with adding proper link to the same repository. Reported-by: Heinrich Schuchardt Signed-off-by: Michal Simek --- board/xilinx/microblaze-generic/MAINTAINERS | 1 + board/xilinx/versal/MAINTAINERS | 1 + board/xilinx/zynq/MAINTAINERS | 1 + board/xilinx/zynqmp/MAINTAINERS | 1 + 4 files changed, 4 insertions(+) diff --git a/board/xilinx/microblaze-generic/MAINTAINERS b/board/xilinx/microblaze-generic/MAINTAINERS index 6796d4d51ae3..9a42a8b7401b 100644 --- a/board/xilinx/microblaze-generic/MAINTAINERS +++ b/board/xilinx/microblaze-generic/MAINTAINERS @@ -1,6 +1,7 @@ MICROBLAZE-GENERIC BOARD M: Michal Simek S: Maintained +T: git https://gitlab.denx.de/u-boot/custodians/u-boot-microblaze.git F: board/xilinx/microblaze-generic/ F: include/configs/microblaze-generic.h F: configs/microblaze-generic_defconfig diff --git a/board/xilinx/versal/MAINTAINERS b/board/xilinx/versal/MAINTAINERS index 2d2b80824538..0d40196ade60 100644 --- a/board/xilinx/versal/MAINTAINERS +++ b/board/xilinx/versal/MAINTAINERS @@ -1,6 +1,7 @@ XILINX_VERSAL BOARDS M: Michal Simek S: Maintained +T: git https://gitlab.denx.de/u-boot/custodians/u-boot-microblaze.git F: arch/arm/dts/versal* F: board/xilinx/versal/ F: include/configs/xilinx_versal* diff --git a/board/xilinx/zynq/MAINTAINERS b/board/xilinx/zynq/MAINTAINERS index 78bcd84d30e5..ce760ab02c34 100644 --- a/board/xilinx/zynq/MAINTAINERS +++ b/board/xilinx/zynq/MAINTAINERS @@ -1,6 +1,7 @@ ZYNQ BOARD M: Michal Simek S: Maintained +T: git https://gitlab.denx.de/u-boot/custodians/u-boot-microblaze.git F: arch/arm/dts/zynq-* F: board/xilinx/zynq/ F: include/configs/zynq*.h diff --git a/board/xilinx/zynqmp/MAINTAINERS b/board/xilinx/zynqmp/MAINTAINERS index 9cd4f3f53efd..a631b380bdd3 100644 --- a/board/xilinx/zynqmp/MAINTAINERS +++ b/board/xilinx/zynqmp/MAINTAINERS @@ -1,6 +1,7 @@ XILINX_ZYNQMP BOARDS M: Michal Simek S: Maintained +T: git https://gitlab.denx.de/u-boot/custodians/u-boot-microblaze.git F: arch/arm/dts/zynqmp-* F: arch/arm/dts/avnet-ultra96* F: board/xilinx/common/ -- 2.30.0
Re: [PATCH V2 12/12] imx: imx8m: move CONFIG_SPL_SYS_[I,D]CACHE_OFF to defconfig
Hi Peng, On Sun, Jan 3, 2021 at 11:33 PM Peng Fan wrote: > No need to disable icache. Dcache needs to be off, since we not have MMU > setup. Is the requirement to disable D-Cache in SPL specific to i.MX8MN and i.MX8MP? We do not pass CONFIG_SPL_SYS_ICACHE_OFF=y and CONFIG_SPL_SYS_DCACHE_OFF=y for imx8mq_evk_defconfig, for example. Regards, Fabio Estevam
Re: [PATCH 21/26] dm: core: Use dev_has_ofnode() instead of dev_of_valid()
Hi Simon, On 12/19/20 6:40 PM, Simon Glass wrote: We have two functions which do the same thing. Standardise on dev_has_ofnode() since there is no such thing as an 'invalid' ofnode in normal operation: it is either null or missing. Also move the functions into one place. Signed-off-by: Simon Glass --- drivers/clk/clk-uclass.c| 2 +- drivers/core/device.c | 2 +- drivers/gpio/sandbox.c | 2 +- drivers/i2c/designware_i2c_pci.c| 4 ++-- drivers/i2c/i2c-uclass.c| 2 +- drivers/mmc/pci_mmc.c | 2 +- drivers/pci/pci-uclass.c| 6 +++--- drivers/pinctrl/pinctrl-uclass.c| 2 +- drivers/spi/spi-uclass.c| 2 +- drivers/sysreset/sysreset_sandbox.c | 2 +- drivers/timer/timer-uclass.c| 2 +- drivers/usb/host/usb-uclass.c | 2 +- include/dm/device.h | 13 - include/dm/read.h | 16 test/dm/pci.c | 6 +++--- 15 files changed, 30 insertions(+), 35 deletions(-) Reviewed-by: Patrick Delaunay Thanks Patrick
Re: [linux-sunxi] [PATCH 02/17] sunxi: Introduce common symbol for H6 like SoCs
On 03/01/2021 23:43, Samuel Holland wrote:
Hi Jernej,
thanks for that patch, that's a nice solution to avoid those long #ifdef
chains!
> On 1/3/21 3:26 AM, Jernej Skrabec wrote:
>> It turns out that there are at least 2 other SoCs which have basically
>> the same memory map, similar clocks and other features as H6. It's very
>> likely that we'll see more such SoCs in the future. In order to ease
>> porting to new SoCs and lower ifdef clutter, introduce common symbol for
>> them.
>>
>> Signed-off-by: Jernej Skrabec
>> ---
>> arch/arm/include/asm/arch-sunxi/boot0.h | 2 +-
>> arch/arm/include/asm/arch-sunxi/clock.h | 2 +-
>> arch/arm/include/asm/arch-sunxi/cpu.h | 2 +-
>> arch/arm/include/asm/arch-sunxi/timer.h | 2 +-
>> arch/arm/mach-sunxi/Kconfig | 21 +
>> arch/arm/mach-sunxi/Makefile| 2 +-
>> arch/arm/mach-sunxi/board.c | 4 ++--
>> arch/arm/mach-sunxi/rmr_switch.S| 2 +-
>> common/spl/Kconfig | 4 ++--
>> include/configs/sun50i.h| 2 +-
>> 10 files changed, 24 insertions(+), 19 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/arch-sunxi/boot0.h
>> b/arch/arm/include/asm/arch-sunxi/boot0.h
>> index 46d0f0666c2b..e8e8e38f0556 100644
>> --- a/arch/arm/include/asm/arch-sunxi/boot0.h
>> +++ b/arch/arm/include/asm/arch-sunxi/boot0.h
>> @@ -39,7 +39,7 @@
>> .word 0xf57ff06f // isb sy
>> .word 0xe320f003 // wfi
>> .word 0xeafd // b @wfi
>> -#ifndef CONFIG_MACH_SUN50I_H6
>> +#ifndef CONFIG_SUN50I_GEN_H6
>> .word 0x017000a0 // writeable RVBAR mapping address
>> #else
>> .word 0x09010040 // writeable RVBAR mapping address
>> diff --git a/arch/arm/include/asm/arch-sunxi/clock.h
>> b/arch/arm/include/asm/arch-sunxi/clock.h
>> index 5994130e6b54..cbbe5c7a1e68 100644
>> --- a/arch/arm/include/asm/arch-sunxi/clock.h
>> +++ b/arch/arm/include/asm/arch-sunxi/clock.h
>> @@ -16,7 +16,7 @@
>> /* clock control module regs definition */
>> #if defined(CONFIG_MACH_SUN8I_A83T)
>> #include
>> -#elif defined(CONFIG_MACH_SUN50I_H6)
>> +#elif defined(CONFIG_SUN50I_GEN_H6)
>> #include
>> #elif defined(CONFIG_MACH_SUN6I) || defined(CONFIG_MACH_SUN8I) || \
>>defined(CONFIG_MACH_SUN50I)
>> diff --git a/arch/arm/include/asm/arch-sunxi/cpu.h
>> b/arch/arm/include/asm/arch-sunxi/cpu.h
>> index 8b57d24e2f0c..b08f2023748c 100644
>> --- a/arch/arm/include/asm/arch-sunxi/cpu.h
>> +++ b/arch/arm/include/asm/arch-sunxi/cpu.h
>> @@ -8,7 +8,7 @@
>>
>> #if defined(CONFIG_MACH_SUN9I)
>> #include
>> -#elif defined(CONFIG_MACH_SUN50I_H6)
>> +#elif defined(CONFIG_SUN50I_GEN_H6)
>> #include
>> #else
>> #include
>> diff --git a/arch/arm/include/asm/arch-sunxi/timer.h
>> b/arch/arm/include/asm/arch-sunxi/timer.h
>> index 6f138d04b806..bb5626d893bb 100644
>> --- a/arch/arm/include/asm/arch-sunxi/timer.h
>> +++ b/arch/arm/include/asm/arch-sunxi/timer.h
>> @@ -76,7 +76,7 @@ struct sunxi_timer_reg {
>> struct sunxi_tgp tgp[4];
>> u8 res5[8];
>> u32 cpu_cfg;
>> -#elif defined(CONFIG_SUNXI_GEN_SUN6I) || defined(CONFIG_MACH_SUN50I_H6)
>> +#elif defined(CONFIG_SUNXI_GEN_SUN6I) || defined(CONFIG_SUN50I_GEN_H6)
>> u8 res3[16];
>> struct sunxi_wdog wdog[5]; /* We have 5 watchdogs */
>> #endif
>> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
>> index 49ef217f08c0..1cf79bad7cf6 100644
>> --- a/arch/arm/mach-sunxi/Kconfig
>> +++ b/arch/arm/mach-sunxi/Kconfig
>> @@ -82,7 +82,7 @@ config SUN8I_RSB
>> config SUNXI_SRAM_ADDRESS
>> hex
>> default 0x1 if MACH_SUN9I || MACH_SUN50I || MACH_SUN50I_H5
>> -default 0x2 if MACH_SUN50I_H6
>> +default 0x2 if SUN50I_GEN_H6
>> default 0x0
>> ---help---
>> Older Allwinner SoCs have their mask boot ROM mapped just below 4GB,
>> @@ -108,6 +108,15 @@ config SUNXI_GEN_SUN6I
>> separate ahb reset control registers, custom pmic bus, new style
>> watchdog, etc.
>>
>> +config SUN50I_GEN_H6
>
> The new memory map is also used for 32-bit SoCs V5 (sun8iw12p1) and
> newer. So this is not sun50i-specific, and I'd suggest SUNXI_GEN_H6 (or
> even SUNXI_GEN_H6_V5). It is unfortunate there appears to be no name for
> this family.
Yeah, the Allwinner generation naming being *core* dependent is really
annyoing and not helpful.
I am fine with a rename, but then it would be very close to
"CONFIG_SUNXI_GEN_SUN6I", which is quite confusing to any readers
(already stumbled upon it myself in patch 04/17).
Any opinions?
>
>> +bool
>> +select FIT
>> +select SPL_LOAD_FIT
>> +select SUPPORT_SPL
>> +---help---
>> +Select this for sunxi SoCs which have H6 like peripherals, clocks
>> +and memory map.
>> +
>> config SUNXI_DRAM_DW
>> bool
>> ---help---
>> @@ -302,10 +311,7 @@ config MACH_SUN50I_H5
>> config MACH_SUN50I_H6
>> bool "sun50i (Allwinner H6)"
>> select ARM64
>> -s
Re: [PATCH 1/2] ARM: zynq: add Digilent Zynq PYNQ Board(s)
On 27. 12. 20 21:34, Florian Klink wrote:
> This adds the dts and entry in CONFIG_OF_LIST for the Digilent Zynq PYNQ
> Board(s).
>
> They're Zynq 7000 - based boards, the Z1 is from Digilent, the Z2 from
> TUL.
This is just saying that dt name is wrong. Pynq is not any board name.
>
> They have a slightly different audio system, and a different pin header,
> but these aren't really accessible from the PS, only from the PL, so the
> DTB is the same.
I am fine with this.
>
> Co-authored-by: Thomas Heijligen
This is not standard tag - please remove it. I see SoB below.
> Signed-off-by: Florian Klink
> Signed-off-by: Thomas Heijligen
> ---
> arch/arm/dts/Makefile | 1 +
> arch/arm/dts/zynq-pynq.dts | 68 ++
> configs/xilinx_zynq_virt_defconfig | 2 +-
> 3 files changed, 70 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/dts/zynq-pynq.dts
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index fd47e408f8..0631404dbd 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -267,6 +267,7 @@ dtb-$(CONFIG_ARCH_ZYNQ) += \
> zynq-microzed.dtb \
> zynq-minized.dtb \
> zynq-picozed.dtb \
> + zynq-pynq.dtb \
> zynq-syzygy-hub.dtb \
> zynq-topic-miami.dtb \
> zynq-topic-miamilite.dtb \
> diff --git a/arch/arm/dts/zynq-pynq.dts b/arch/arm/dts/zynq-pynq.dts
> new file mode 100644
> index 00..04ac0f7cdc
> --- /dev/null
> +++ b/arch/arm/dts/zynq-pynq.dts
> @@ -0,0 +1,68 @@
> +// SPDX-License-Identifier: GPL-2.0+
Just GPL-2.0
> +/dts-v1/;
> +#include "zynq-7000.dtsi"
> +#include
> +
> +/ {
> + model = "Digilent/TUL Zynq PYNQ";
> + compatible = "digilent,zynq-pynq", "digilent,zynq-pynq-z1",
> "tul,zynq-pynq", "tul,zynq-pynq-z2", "xlnx,zynq-7000";
1. tul is not recorded in Linux
Documentation/devicetree/bindings/vendor-prefixes.yaml
That's why please send a patch against Linux first to get it recorded.
2. Order is wrong. You all the time need to specify the most accurate
description.
For example:
"digilent,zynq-pynq-z1", "digilent,zynq-pynq", "xlnx,zynq-7000";
> +
> + aliases {
> + ethernet0 = &gem0;
> + serial0 = &uart0;
> + };
> +
> + memory@0 {
> + device_type = "memory";
> + reg = <0x0 0x2000>;
> + };
> +
> + chosen {
> + bootargs = "";
> + stdout-path = "serial0:115200n8";
> + };
> +
> + gpio-leds {
> + compatible = "gpio-leds";
> +
> + ld4 {
kernel dtb check reports that this should have led- prefix.
> + label = "zynq-pynq:green:ld4";
> + gpios = <&gpio0 7 GPIO_ACTIVE_HIGH>;
> + };
> + };
> +
> + usb_phy0: phy0 {
> + #phy-cells = <0>;
> + compatible = "usb-nop-xceiv";
> + reset-gpios = <&gpio0 46 GPIO_ACTIVE_LOW>;
> + };
> +};
> +
> +&clkc {
> + ps-clk-frequency = <5000>;
> +};
> +
> +&gem0 {
> + status = "okay";
> + phy-mode = "rgmii-id";
> + phy-handle = <ðernet_phy>;
> +
> + ethernet_phy: ethernet-phy@0 {
> + reg = <0>;
> + device_type = "ethernet-phy";
> + };
> +};
> +
> +&sdhci0 {
> + status = "okay";
> +};
> +
> +&uart0 {
> + status = "okay";
> +};
> +
> +&usb0 {
> + status = "okay";
> + dr_mode = "host";
> + usb-phy = <&usb_phy0>;
> +};
> diff --git a/configs/xilinx_zynq_virt_defconfig
> b/configs/xilinx_zynq_virt_defconfig
> index 552f1b4dfb..c46f531d4d 100644
> --- a/configs/xilinx_zynq_virt_defconfig
> +++ b/configs/xilinx_zynq_virt_defconfig
> @@ -52,7 +52,7 @@ CONFIG_CMD_MTDPARTS=y
> CONFIG_CMD_MTDPARTS_SPREAD=y
> CONFIG_CMD_MTDPARTS_SHOW_NET_SIZES=y
> CONFIG_CMD_UBI=y
> -CONFIG_OF_LIST="zynq-zc702 zynq-zc706 zynq-zc770-xm010 zynq-zc770-xm011
> zynq-zc770-xm011-x16 zynq-zc770-xm012 zynq-zc770-xm013 zynq-cc108
> zynq-microzed zynq-minized zynq-picozed zynq-zed zynq-zturn zynq-zturn-v5
> zynq-zybo zynq-zybo-z7 zynq-dlc20-rev1.0"
> +CONFIG_OF_LIST="zynq-zc702 zynq-zc706 zynq-zc770-xm010 zynq-zc770-xm011
> zynq-zc770-xm011-x16 zynq-zc770-xm012 zynq-zc770-xm013 zynq-cc108
> zynq-microzed zynq-minized zynq-picozed zynq-pynq zynq-zed zynq-zturn
> zynq-zturn-v5 zynq-zybo zynq-zybo-z7 zynq-dlc20-rev1.0"
> CONFIG_ENV_OVERWRITE=y
> CONFIG_ENV_IS_IN_SPI_FLASH=y
> CONFIG_SYS_RELOC_GD_ENV_ADDR=y
>
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
Re: [PATCH v7 1/7] riscv: Add DMA 64-bit address support
> From: Padmarao Begari [mailto:padmarao.beg...@microchip.com] > Sent: Tuesday, December 22, 2020 9:12 PM > To: u-boot@lists.denx.de; bmeng...@gmail.com; Rick Jian-Zhi Chen(陳建志); > anup.pa...@wdc.com; lukas.a...@aisec.fraunhofer.de; joe.hershber...@ni.com; > lu...@denx.de; atish.pa...@wdc.com > Cc: cyril.j...@microchip.com; lewis.ha...@microchip.com; > ivan.grif...@emdalo.com; daire.mcnam...@emdalo.com; > conor.doo...@microchip.com; Padmarao Begari > Subject: [PATCH v7 1/7] riscv: Add DMA 64-bit address support > > dma_addr_t holds any valid DMA address. If the DMA API only uses 32/64-bit > addresses, dma_addr_t need only be 32/64 bits wide. > > Signed-off-by: Padmarao Begari > Reviewed-by: Anup Patel > Reviewed-by: Bin Meng > --- > arch/riscv/Kconfig | 4 > arch/riscv/include/asm/types.h | 4 > 2 files changed, 8 insertions(+) > Reviewed-by: Rick Chen
Re: [PATCH 1/1] fru: ops: avoid out of bounds access
On 03. 01. 21 18:07, Heinrich Schuchardt wrote:
> Building xilinx_zynq_virt_defconfig fails on origin/next as reported by
> GCC 10.2 (as provided by Debian Bullseye):
>
> CC board/xilinx/common/fru_ops.o
> board/xilinx/common/fru_ops.c: In function ‘fru_capture’:
> board/xilinx/common/fru_ops.c:173:8:
> error: array subscript 284 is outside array bounds of
> ‘struct fru_table[1]’ [-Werror=array-bounds]
> 173 | limit = data + sizeof(struct fru_board_data);
> | ~~^~
> board/xilinx/common/fru_ops.c:17:18: note: while referencing ‘fru_data’
>17 | struct fru_table fru_data __section(.data);
> | ^~~~
>
> When using sizeof(struct fru_board_data) to find the end of the structure
> you should add it to the start of the structure.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> board/xilinx/common/fru_ops.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/board/xilinx/common/fru_ops.c b/board/xilinx/common/fru_ops.c
> index b4cd3d4998..44f0913f2e 100644
> --- a/board/xilinx/common/fru_ops.c
> +++ b/board/xilinx/common/fru_ops.c
> @@ -170,7 +170,7 @@ static int fru_parse_board(unsigned long addr)
> data = (u8 *)&fru_data.brd.manufacturer_type_len;
>
> /* Record max structure limit not to write data over allocated space */
> - limit = data + sizeof(struct fru_board_data);
> + limit = (u8 *)&fru_data.brd + sizeof(struct fru_board_data);
>
> for (i = 0; ; i++, data += FRU_BOARD_MAX_LEN) {
> len = fru_check_type_len(*(u8 *)addr, fru_data.brd.lang_code,
> --
> 2.29.2
>
Applied.
M
Re: [PATCH 1/1] zynq: mtd: nand: remove superfluous if
On 27. 12. 20 11:28, Heinrich Schuchardt wrote:
> This sort of code does not make much sense:
>
> if (ondie_ecc_enabled) {
> if (ondie_ecc_enabled) {
>
> Remove the inner if.
>
> The problem was indicated by cppcheck.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> drivers/mtd/nand/raw/zynq_nand.c | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/mtd/nand/raw/zynq_nand.c
> b/drivers/mtd/nand/raw/zynq_nand.c
> index 92db2aa19c..65817ea7f2 100644
> --- a/drivers/mtd/nand/raw/zynq_nand.c
> +++ b/drivers/mtd/nand/raw/zynq_nand.c
> @@ -1206,12 +1206,10 @@ static int zynq_nand_probe(struct udevice *dev)
> nand_chip->options |= NAND_SUBPAGE_READ;
>
> /* On-Die ECC spare bytes offset 8 is used for ECC codes */
> - if (ondie_ecc_enabled) {
> - nand_chip->ecc.layout = &ondie_nand_oob_64;
> - /* Use the BBT pattern descriptors */
> - nand_chip->bbt_td = &bbt_main_descr;
> - nand_chip->bbt_md = &bbt_mirror_descr;
> - }
> + nand_chip->ecc.layout = &ondie_nand_oob_64;
> + /* Use the BBT pattern descriptors */
> + nand_chip->bbt_td = &bbt_main_descr;
> + nand_chip->bbt_md = &bbt_mirror_descr;
> } else {
> /* Hardware ECC generates 3 bytes ECC code for each 512 bytes */
> nand_chip->ecc.mode = NAND_ECC_HW;
> --
> 2.29.2
>
Applied.
M
