[RESEND PATCH v5 9/11] ARM: socfpga: Add initial support for ic-automation Moritz III
Add initial support for ic-automation Moritz III, which is
an Cyclone V SOM with ethernet, usb, uart. Booting via
sd-card or flash is supported.
Changes for v5:
- fixed random ethaddr at failure
- fixed comments
Changes for v4:
- re-sort list alphabetically
- c style comments
Changes for v3:
- Resend via git send-email
Changes for v2:
- Coding Style cleanup
Signed-off-by: Nico Becker
---
arch/arm/dts/Makefile | 1 +
...ocfpga_cyclone5_ica_moritz_iii-u-boot.dtsi | 45 ++
.../dts/socfpga_cyclone5_ica_moritz_iii.dts | 123
arch/arm/mach-socfpga/Kconfig | 8 +
board/ic-automation/moritz_iii/MAINTAINERS| 8 +
board/ic-automation/moritz_iii/Makefile | 8 +
.../moritz_iii/moritz_iii_board.c | 127
.../moritz_iii/qts/iocsr_config.h | 658 ++
.../moritz_iii/qts/pinmux_config.h| 218 ++
.../ic-automation/moritz_iii/qts/pll_config.h | 83 +++
.../moritz_iii/qts/sdram_config.h | 344 +
board/ic-automation/moritz_iii/socfpga.c | 5 +
configs/socfpga_moritz_iii_defconfig | 75 ++
include/configs/socfpga_ica_moritz_iii.h | 46 ++
14 files changed, 1749 insertions(+)
create mode 100644 arch/arm/dts/socfpga_cyclone5_ica_moritz_iii-u-boot.dtsi
create mode 100644 arch/arm/dts/socfpga_cyclone5_ica_moritz_iii.dts
create mode 100644 board/ic-automation/moritz_iii/MAINTAINERS
create mode 100644 board/ic-automation/moritz_iii/Makefile
create mode 100644 board/ic-automation/moritz_iii/moritz_iii_board.c
create mode 100644 board/ic-automation/moritz_iii/qts/iocsr_config.h
create mode 100644 board/ic-automation/moritz_iii/qts/pinmux_config.h
create mode 100644 board/ic-automation/moritz_iii/qts/pll_config.h
create mode 100644 board/ic-automation/moritz_iii/qts/sdram_config.h
create mode 100644 board/ic-automation/moritz_iii/socfpga.c
create mode 100644 configs/socfpga_moritz_iii_defconfig
create mode 100644 include/configs/socfpga_ica_moritz_iii.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 9900b44274..6fbedfe3b3 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -352,6 +352,7 @@ dtb-$(CONFIG_ARCH_SOCFPGA) +=
\
socfpga_cyclone5_de0_nano_soc.dtb \
socfpga_cyclone5_de1_soc.dtb\
socfpga_cyclone5_de10_nano.dtb \
+ socfpga_cyclone5_ica_moritz_iii.dtb \
socfpga_cyclone5_sockit.dtb \
socfpga_cyclone5_socrates.dtb \
socfpga_cyclone5_sr1500.dtb \
diff --git a/arch/arm/dts/socfpga_cyclone5_ica_moritz_iii-u-boot.dtsi
b/arch/arm/dts/socfpga_cyclone5_ica_moritz_iii-u-boot.dtsi
new file mode 100644
index 00..3ba01d1fd9
--- /dev/null
+++ b/arch/arm/dts/socfpga_cyclone5_ica_moritz_iii-u-boot.dtsi
@@ -0,0 +1,45 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * U-Boot additions
+ *
+ * Copyright (C) 2012 Altera Corporation
+ * Copyright (c) 2018 Simon Goldschmidt
+ */
+
+#include "socfpga-common-u-boot.dtsi"
+
+/{
+ aliases {
+ spi0 = "/soc/spi@ff705000";
+ udc0 = &usb1;
+ };
+};
+
+&watchdog0 {
+ status = "disabled";
+};
+
+&mmc {
+ u-boot,dm-pre-reloc;
+};
+
+&qspi {
+ u-boot,dm-pre-reloc;
+};
+
+&uart0 {
+ clock-frequency = <1>;
+ u-boot,dm-pre-reloc;
+};
+
+&porta {
+ bank-name = "porta";
+};
+
+&portb {
+ bank-name = "portb";
+};
+
+&portc {
+ bank-name = "portc";
+};
diff --git a/arch/arm/dts/socfpga_cyclone5_ica_moritz_iii.dts
b/arch/arm/dts/socfpga_cyclone5_ica_moritz_iii.dts
new file mode 100644
index 00..d81f8ea5bf
--- /dev/null
+++ b/arch/arm/dts/socfpga_cyclone5_ica_moritz_iii.dts
@@ -0,0 +1,123 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2012 Altera Corporation
+ * Copyright (C) 2020 Nico Becker ic-automation GmbH
+ */
+
+#include "socfpga_cyclone5.dtsi"
+
+/ {
+ model = "ic-automation Moritz III";
+ compatible = "ic-automation,moritz_iii", "altr,socfpga-cyclone5",
"altr,socfpga";
+
+ chosen {
+ bootargs = "earlyprintk";
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory@0 {
+ name = "memory";
+ device_type = "memory";
+ reg = <0x0 0x4000>; /* 1GB */
+ };
+
+ aliases {
+ /* this allow the ethaddr uboot environmnet variable contents
+* to be added to the gmac1 device tree blob.
+*/
+ ethernet0 = &gmac1;
+ };
+
+ fpga_bridge3: fpga_bridge@ffc25080 {
+ compatible = "altr,socfpga-fpga2sdram-bridge";
+ reg = <0xffc25080 0x4>;
+ };
+
+ regulator_3_3v: 3-3-v-regulator {
+ compatible = "regulator-fixed";
Re: [PATCH 1/1] riscv: add DT binding for BOOT button on Maix board
On Thu, Sep 3, 2020 at 4:12 AM Heinrich Schuchardt wrote:
>
> Add a device tree binding for the BOOT button on the Maix board.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> Together with
> [PATCH 1/1] cmd/button: return button status
> https://lists.denx.de/pipermail/u-boot/2020-September/425221.html
> we can use the button status to decide which program to boot.
> ---
> arch/riscv/dts/k210-maix-bit.dts | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/riscv/dts/k210-maix-bit.dts
> b/arch/riscv/dts/k210-maix-bit.dts
> index e840e04ada..c2beec602c 100644
> --- a/arch/riscv/dts/k210-maix-bit.dts
> +++ b/arch/riscv/dts/k210-maix-bit.dts
> @@ -8,6 +8,7 @@
> #include "k210.dtsi"
>
> #include
> +#include
>
> / {
> model = "Sipeed Maix Bit 2.0";
> @@ -33,6 +34,16 @@
> };
> };
>
> + gpio-keys {
> + compatible = "gpio-keys";
> +
> + boot {
> + label = "BOOT";
> + linux,code = ;
I cannot find how U-Boot is handling "linux,code". Any pointers?
> + gpios = <&gpio0 0 GPIO_ACTIVE_LOW>;
> + };
> + };
> +
> sound {
> compatible = "simple-audio-card";
> simple-audio-card,format = "i2s";
> --
Regards,
Bin
Re: [RESEND PATCH v5 9/11] ARM: socfpga: Add initial support for ic-automation Moritz III
On 9/11/20 9:02 AM, Nico Becker wrote:
> Add initial support for ic-automation Moritz III, which is
> an Cyclone V SOM with ethernet, usb, uart. Booting via
> sd-card or flash is supported.
>
> Changes for v5:
The changelog shouldn't be part of the commmit message, so it goes below
the "---" line. Git then ignores it.
> - fixed random ethaddr at failure
> - fixed comments
>
> Changes for v4:
> - re-sort list alphabetically
> - c style comments
>
> Changes for v3:
> - Resend via git send-email
>
> Changes for v2:
> - Coding Style cleanup
>
> Signed-off-by: Nico Becker
> ---
Here ...
[...]
> +++ b/arch/arm/dts/socfpga_cyclone5_ica_moritz_iii-u-boot.dtsi
> @@ -0,0 +1,45 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * U-Boot additions
> + *
> + * Copyright (C) 2012 Altera Corporation
> + * Copyright (c) 2018 Simon Goldschmidt
I think the copyright assignment needs updating.
> + */
> +
> +#include "socfpga-common-u-boot.dtsi"
> +
> +/{
> + aliases {
> + spi0 = "/soc/spi@ff705000";
spi0 = &qspi; should work too ?
[...]
> diff --git a/arch/arm/dts/socfpga_cyclone5_ica_moritz_iii.dts
> b/arch/arm/dts/socfpga_cyclone5_ica_moritz_iii.dts
> new file mode 100644
> index 00..d81f8ea5bf
> --- /dev/null
> +++ b/arch/arm/dts/socfpga_cyclone5_ica_moritz_iii.dts
> @@ -0,0 +1,123 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2012 Altera Corporation
> + * Copyright (C) 2020 Nico Becker ic-automation GmbH
>
> + */
> +
> +#include "socfpga_cyclone5.dtsi"
> +
> +/ {
> + model = "ic-automation Moritz III";
> + compatible = "ic-automation,moritz_iii", "altr,socfpga-cyclone5",
> "altr,socfpga";
> +
> + chosen {
> + bootargs = "earlyprintk";
> + stdout-path = "serial0:115200n8";
> + };
> +
> + memory@0 {
> + name = "memory";
> + device_type = "memory";
> + reg = <0x0 0x4000>; /* 1GB */
> + };
> +
> + aliases {
> + /* this allow the ethaddr uboot environmnet variable contents
environment (typo)
> + * to be added to the gmac1 device tree blob.
> + */
> + ethernet0 = &gmac1;
> + };
[...]
[...]
> +++ b/board/ic-automation/moritz_iii/moritz_iii_board.c
[...]
> +int board_late_init(void)
> +{
> + u8 mac[MAC_LENGTH];
> + char serial[SERIALNUMBER_LENGTH + 1];
> + u8 eeprom_data[OVERALL_LENGTH];
> + u32 calc_crc32;
> + u32 *read_crc32;
> + u8 w_data;
> + int error;
> + u8 registers[] = {0x02, 0x03, 0x06, 0x07};
> +
> + for (int i = 0; i < OVERALL_LENGTH; i++)
> + eeprom_data[i] = 0x00;
Is that a memset() ?
[...]
> + /* delete environment var first. Otherwise we are unable to set it's
> value... */
> + env_set("ethaddr", "");
ethaddr is not a string, so this will fail. Use NULL instead of "" .
But you might just want to check whether ethaddr is set and skip
overwriting it, that way the user can set their own ethaddr and make it
persistent.
> + struct udevice *bus;
> + struct udevice *dev;
Move this to the beginning of the function, just like all the other vars.
[...]
> + /* check crc32 */
> + calc_crc32 = crc32(0, eeprom_data, OVERALL_LENGTH - CRC32_LENGTH);
> + read_crc32 = (u32 *)&eeprom_data[SERIALNUMBER_LENGTH + MAC_LENGTH];
Use get_unaligned on the eeprom data, otherwise this will fail on ARM
hardware with CPSR A-bit clear.
> + if (*read_crc32 != calc_crc32) {
> + /* print read data is crc32 not valid */
> + printf("read data:");
> + for (int i = 0; i < OVERALL_LENGTH; i++)
> + printf("%02X", eeprom_data[i]);
> + printf("\n");
> + /* print crc32 */
> + printf("read crc32 %08X calc crc32 %08X\n", *read_crc32,
> calc_crc32);
> +
> + strncpy(serial, "", 8);
> + memset((void *)mac, 0x00, 8);
> + } else {
> + /* copy serial */
> + memcpy((void *)serial, (void *)eeprom_data,
> SERIALNUMBER_LENGTH);
The typecasts are not needed for memset()/memcpy() .
> + /* copy MAC address */
> + memcpy((void *)mac, (void *)&eeprom_data[SERIALNUMBER_LENGTH],
> MAC_LENGTH);
> + }
> +
> + serial[SERIALNUMBER_LENGTH] = 0x00;
> + printf("Serialnumber = %s\n", serial);
[...]
> +++ b/include/configs/socfpga_ica_moritz_iii.h
> @@ -0,0 +1,46 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright (C) 2014 Marek Vasut
> + * Copyright (C) 2020 Nico Becker ic-automation GmbH
>
> + */
> +
> +#ifndef __CONFIG_SOCFPGA_MORITZ_III_H__
> +#define __CONFIG_SOCFPGA_MORITZ_III_H__
> +
> +#include
> +
> +/* Memory configurations */
> +#define PHYS_SDRAM_1_SIZE0x4000
> /* 1GiB on SoCDK */
> +
> +/* Booting Linux */
> +#define CONFIG_LOADADDR
[PATCH] driver: net: fm: add support for XFI
All the 10G ports that were working in XFI mode were described as using XGMII (as PHY_INTERFACE_MODE_XFI was not added at the time). Add the minimal changes required for the FMan code to support XFI. Signed-off-by: Madalin Bucur --- drivers/net/fm/memac.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/fm/memac.c b/drivers/net/fm/memac.c index 0f0f7b0..36f50d2 100644 --- a/drivers/net/fm/memac.c +++ b/drivers/net/fm/memac.c @@ -98,6 +98,7 @@ static void memac_set_interface_mode(struct fsl_enet_mac *mac, if_mode &= ~IF_MODE_MASK; if_mode |= (IF_MODE_GMII); break; + case PHY_INTERFACE_MODE_XFI: case PHY_INTERFACE_MODE_XGMII: if_mode &= ~IF_MODE_MASK; if_mode |= IF_MODE_XGMII; @@ -106,7 +107,7 @@ static void memac_set_interface_mode(struct fsl_enet_mac *mac, break; } /* Enable automatic speed selection for Non-XGMII */ - if (type != PHY_INTERFACE_MODE_XGMII) + if (type != PHY_INTERFACE_MODE_XGMII && type != PHY_INTERFACE_MODE_XFI) if_mode |= IF_MODE_EN_AUTO; if (type == PHY_INTERFACE_MODE_RGMII || -- 2.1.0
Re: [PATCH] riscv: Only enable OF_BOARD_FIXUP for S-Mode
Hi Sean,
On Sat, Sep 5, 2020 at 9:22 PM Sean Anderson wrote:
>
> It is unsafe to enable OF_BOARD_FIXUP only based on OF_SEPARATE.
> OF_SEPARATE may indicate that the user wishes U-Boot to use a different
> device tree than one obtained via OF_PRIOR_STAGE. However, OF_SEPARATE may
> also indicate that the device tree which would be obtained via
> OF_PRIOR_STAGE is invalid, nonexistant, or otherwise unusable. In this
typo: nonexistent
> latter case, enabling OF_BOARD_FIXUP will result in corruption of the
> device tree. To remedy this, only enable OF_BOARD_FIXUP if U-Boot is
> configured for S-Mode.
>
> Fixes: 1c17e55594a394ced7de88d91be294eaf8c564c1
nits: the format should be: commit_id ("description")
> Signed-off-by: Sean Anderson
> ---
>
> arch/riscv/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 009a545fcf..13fac51483 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -288,6 +288,6 @@ config STACK_SIZE_SHIFT
> default 14
>
> config OF_BOARD_FIXUP
> - default y if OF_SEPARATE
> + default y if OF_SEPARATE && RISCV_SMODE
Is that your board is running U-Boot M-mode with OF_SEPARATE that does not work?
>
> endmenu
> --
Regards,
Bin
Re: [PATCH 1/7] Revert "riscv: Clear pending interrupts before enabling IPIs"
Hi Sean, On Tue, Sep 8, 2020 at 2:17 AM Sean Anderson wrote: > > Clearing MIP doesn't do anything. Whoops. The following commits should Which following commits? > tackle this problem in a more robust manner. > > This reverts commit 9472630337e7c4ac442066b5a752aaa8c3b4d4a6. > > Signed-off-by: Sean Anderson > --- > > arch/riscv/cpu/start.S | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S > index bf9fdf369b..e3222b1ea7 100644 > --- a/arch/riscv/cpu/start.S > +++ b/arch/riscv/cpu/start.S > @@ -65,8 +65,6 @@ _start: > #else > li t0, SIE_SSIE > #endif > - /* Clear any pending IPIs */ > - csrcMODE_PREFIX(ip), t0 Did you mean the clearing MIP.MSIP actually does nothing, but the following commit is the correct fix? commit 40686c394e533fec765fe237936e353c84e73fff Author: Sean Anderson Date: Wed Jun 24 06:41:18 2020 -0400 riscv: Clean up IPI initialization code The previous IPI code initialized the device whenever the first call was made to a riscv_*_ipi function. This made it difficult to determine when the IPI device was initialized. This patch introduces a new function riscv_init_ipi. It is called once during arch_cpu_init_dm. In SPL, it is called in spl_invoke_opensbi. Before this point, no riscv_*_ipi functions should be called. Signed-off-by: Sean Anderson Reviewed-by: Rick Chen > csrsMODE_PREFIX(ie), t0 > #endif > Regards, Bin
Re: [PATCH 2/7] riscv: Match memory barriers between send_ipi_many and handle_ipi
On Tue, Sep 8, 2020 at 2:17 AM Sean Anderson wrote:
>
> Without a matching barrier on the write side, the barrier in handle_ipi
> does nothing. It was entirely possible for the boot hart to write to addr,
> arg0, and arg1 *after* sending the IPI, because there was no barrier on the
> sending side.
>
> Fixes: 90ae28143700bae4edd23930a7772899ad259058
nits: wrong format of Fixes tag
> Signed-off-by: Sean Anderson
> ---
>
> arch/riscv/lib/smp.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/riscv/lib/smp.c b/arch/riscv/lib/smp.c
> index ac22136314..ab6d8bd7fa 100644
> --- a/arch/riscv/lib/smp.c
> +++ b/arch/riscv/lib/smp.c
> @@ -54,6 +54,8 @@ static int send_ipi_many(struct ipi_data *ipi, int wait)
> gd->arch.ipi[reg].arg0 = ipi->arg0;
> gd->arch.ipi[reg].arg1 = ipi->arg1;
>
> + __smp_mb();
> +
> ret = riscv_send_ipi(reg);
> if (ret) {
> pr_err("Cannot send IPI to hart %d\n", reg);
Reviewed-by: Bin Meng
Regards,
Bin
Re: [PATCH] mmc: stm32_sdmmc2: Use mmc_of_parse() to read host capabilities
On 9/10/20 6:54 AM, Alexandru Gagniuc wrote:
> mmc_of_parse() can populate the 'f_max' and 'host_caps' fields of
> struct mmc_config from devicetree.
> The same logic is duplicated in stm32_sdmmc2_probe(). Use
> mmc_of_parse(), which is more generic.
>
> Signed-off-by: Alexandru Gagniuc
> ---
> drivers/mmc/stm32_sdmmc2.c | 18 ++
> 1 file changed, 2 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/mmc/stm32_sdmmc2.c b/drivers/mmc/stm32_sdmmc2.c
> index 6d50356217..77871d5afc 100644
> --- a/drivers/mmc/stm32_sdmmc2.c
> +++ b/drivers/mmc/stm32_sdmmc2.c
> @@ -676,27 +676,13 @@ static int stm32_sdmmc2_probe(struct udevice *dev)
>GPIOD_IS_IN);
>
> cfg->f_min = 40;
> - cfg->f_max = dev_read_u32_default(dev, "max-frequency", 5200);
> cfg->voltages = MMC_VDD_32_33 | MMC_VDD_33_34 | MMC_VDD_165_195;
> cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
> cfg->name = "STM32 SD/MMC";
>
> cfg->host_caps = 0;
> - if (cfg->f_max > 2500)
> - cfg->host_caps |= MMC_MODE_HS_52MHz | MMC_MODE_HS;
> -
> - switch (dev_read_u32_default(dev, "bus-width", 1)) {
> - case 8:
> - cfg->host_caps |= MMC_MODE_8BIT;
> - /* fall through */
> - case 4:
> - cfg->host_caps |= MMC_MODE_4BIT;
> - break;
> - case 1:
> - break;
> - default:
> - pr_err("invalid \"bus-width\" property, force to 1\n");
> - }
> + cfg->f_max = 5200;
cfg->f_max can be also removed?
Best Regards,
Jaehoon Chung
> + mmc_of_parse(dev, cfg);
>
> upriv->mmc = &plat->mmc;
>
>
Re: [PATCH 3/7] riscv: Use NULL as a sentinel value for smp_call_function
On Tue, Sep 8, 2020 at 2:17 AM Sean Anderson wrote: > > Some IPIs may already be pending when U-Boot is started. This could be a > problem if a secondary hart tries to handle an IPI before the boot hart has > initialized the IPI device. > > This commit uses NULL as a sentinel for secondary harts so they know when > the IPI is initialized, and it is safe to use the IPI API. The smp addr > parameter is initialized to NULL by board_init_f_init_reserve. Before this, > secondary harts wait in wait_for_gd_init. > > This imposes a minor restriction because harts may no longer jump to NULL. > However, given that the RISC-V debug device is likely to be located at > 0x400, it is unlikely for any RISC-V implementation to have usable ram > located at 0x0. > > Signed-off-by: Sean Anderson > --- > > arch/riscv/lib/smp.c | 26 ++ > 1 file changed, 22 insertions(+), 4 deletions(-) > Reviewed-by: Bin Meng
[PATCH v2 2/3] xilinx: zynqmp: Add missing 43/46/47dr ID codes
Add support for 43/46/47dr devices.
Signed-off-by: Michal Simek
---
Changes in v2:
- new patch in this series
board/xilinx/zynqmp/zynqmp.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index ef35b0e5992d..177e03906178 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -160,6 +160,21 @@ static const struct {
.device = 39,
.variants = ZYNQMP_VARIANT_DR,
},
+ {
+ .id = 0x047FD093,
+ .device = 43,
+ .variants = ZYNQMP_VARIANT_DR,
+ },
+ {
+ .id = 0x047F8093,
+ .device = 46,
+ .variants = ZYNQMP_VARIANT_DR,
+ },
+ {
+ .id = 0x047FF093,
+ .device = 47,
+ .variants = ZYNQMP_VARIANT_DR,
+ },
{
.id = 0x047FB093,
.device = 48,
--
2.28.0
[PATCH v2 3/3] xilinx: zynqmp: Remove one static variable
There is no reason to have name variable saved in BSS section when it
doesn't need to be really used. That's why remove static from variable
definition and use strdup() to duplicate string with exact size from malloc
area instead.
Signed-off-by: Michal Simek
---
(no changes since v1)
board/xilinx/zynqmp/zynqmp.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index 177e03906178..f5a88ac5d040 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -191,7 +191,7 @@ static char *zynqmp_get_silicon_idcode_name(void)
{
u32 i;
u32 idcode, idcode2;
- static char name[ZYNQMP_VERSION_SIZE];
+ char name[ZYNQMP_VERSION_SIZE];
u32 ret_payload[PAYLOAD_ARG_CNT];
xilinx_pm_request(PM_GET_CHIPID, 0, 0, 0, 0, ret_payload);
@@ -219,7 +219,7 @@ static char *zynqmp_get_silicon_idcode_name(void)
return "unknown";
/* Add device prefix to the name */
- strncat(name, "zu", 2);
+ strncpy(name, "zu", ZYNQMP_VERSION_SIZE);
strncat(&name[2], simple_itoa(zynqmp_devices[i].device), 2);
if (zynqmp_devices[i].variants & ZYNQMP_VARIANT_EV) {
@@ -269,7 +269,7 @@ static char *zynqmp_get_silicon_idcode_name(void)
debug("Variant not identified\n");
}
- return name;
+ return strdup(name);
}
#endif
--
2.28.0
[PATCH v2 0/3] xilinx: zynqmp: Silicon name cleanup
Hi, This patch series is intended to cleanup the functions used to get the silicon name for ZynqMPSoC devices. It make use the firmware driver rather than SMC call and impements more understandable agorithm to compute the device name. v2 series contains only patches which hasn't been applied yet. And also one more patch for adding new dr devices. Thanks, Ibai/Michal Changes in v2: - Add missing 23/39/48/49dr devices - new patch in this series Ibai Erkiaga (1): xilinx: zynqmp: refactor silicon name function Michal Simek (2): xilinx: zynqmp: Add missing 43/46/47dr ID codes xilinx: zynqmp: Remove one static variable board/xilinx/zynqmp/zynqmp.c | 312 +-- 1 file changed, 150 insertions(+), 162 deletions(-) -- 2.28.0
[PATCH v5 0/2] gpio: Add a managed API
Hi, This is a re-submission of Jean-Jacques' earlier work in October last year. It can be found at [0]. The goal is to facilitate porting drivers from the Linux kernel. Most of the series will be about adding managed APIs to existing infrastructure (GPIO, reset, regmap). This particular series is about GPIOs. It adds a managed API using the API as Linux. To make it 100% compatible with linux, there is a small deviation from u-boot's way of naming the gpio lists: the managed equivalent of gpio_request_by_name(..,"blabla-gpios", ...) is devm_gpiod_get_index(..., "blabla", ...) Changes in v5: In individual patches. Changes in v4: - Rebase on latest master and fix merge conflicts. - Move "another-test" node down the order to make sure dm_test_fdt_uclass_seq() continues to work. - Bump num_devices to 9 in dm_test_bus_children(), dm_test_fdt(), and dm_test_uclass_foreach() to fix broken tests. - s/DM_TESTF/UT_TESTF/g Changes in v3: - Add a blank line before return in devm_gpiod_get_index(). - Add Simon's Reviwed-by in both patches. Changes in v2: - The original series had a patch that checked for NULL pointers in the core GPIO functions. The checks were needed because of the addition of devm_gpiod_get_index_optional() which would return NULL when when no GPIO was assigned to the requested function. This is convenient for drivers that need to handle optional GPIOs. Simon argued that those should be behind a Kconfig option because of code size concerns. He also argued against implicit return in the macro that checked for the optional GPIOs. This submission removes the controversial patch so that base functionality can get merged. We still need to take a stance on who is responsible for the NULL check: the driver or the GPIO core? Do we want to trust drivers to take care of the NULL checks, or do we want to distrust them and make sure they don't send us anything bogus in the GPIO core. I will send a separate RFC of the NULL check patch and we can probably discuss the issue there. [0] https://patchwork.ozlabs.org/project/uboot/cover/20191001115130.18886-1-jjhib...@ti.com/ Jean-Jacques Hiblot (2): drivers: gpio: Add a managed API to get a GPIO from the device-tree test: gpio: Add tests for the managed API arch/sandbox/dts/test.dts | 10 drivers/gpio/gpio-uclass.c | 71 ++ include/asm-generic/gpio.h | 47 + test/dm/bus.c | 2 +- test/dm/gpio.c | 102 + test/dm/test-fdt.c | 6 +-- 6 files changed, 234 insertions(+), 4 deletions(-) -- 2.28.0
[PATCH v5 1/2] drivers: gpio: Add a managed API to get a GPIO from the device-tree
From: Jean-Jacques Hiblot
Add managed functions to get a gpio from the devce-tree, based on a
property name (minus the '-gpios' suffix) and optionally an index.
When the device is unbound, the GPIO is automatically released and the
data structure is freed.
Signed-off-by: Jean-Jacques Hiblot
Reviewed-by: Simon Glass
Signed-off-by: Pratyush Yadav
---
Notes:
Heinrich,
I tried adding API documentation for GPIO but sphinx throws a lot of
warnings and errors, some of which are not trivial to fix. I will send
those changes as a separate series. Since it will just pull the
documentation from the kernel-doc comments, which we already have for
all the new and old functions, this series should be treated independent
of the API documentation series.
Changes in v5:
- s/driver detach/device unbind/ in devm_gpiod_get_index()
documentation.
drivers/gpio/gpio-uclass.c | 71 ++
include/asm-generic/gpio.h | 47 +
2 files changed, 118 insertions(+)
diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c
index 9c53299b6a..0c01413b58 100644
--- a/drivers/gpio/gpio-uclass.c
+++ b/drivers/gpio/gpio-uclass.c
@@ -6,6 +6,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -1209,6 +1211,75 @@ int gpio_dev_request_index(struct udevice *dev, const
char *nodename,
flags, 0, dev);
}
+static void devm_gpiod_release(struct udevice *dev, void *res)
+{
+ dm_gpio_free(dev, res);
+}
+
+static int devm_gpiod_match(struct udevice *dev, void *res, void *data)
+{
+ return res == data;
+}
+
+struct gpio_desc *devm_gpiod_get_index(struct udevice *dev, const char *id,
+ unsigned int index, int flags)
+{
+ int rc;
+ struct gpio_desc *desc;
+ char *propname;
+ static const char suffix[] = "-gpios";
+
+ propname = malloc(strlen(id) + sizeof(suffix));
+ if (!propname) {
+ rc = -ENOMEM;
+ goto end;
+ }
+
+ strcpy(propname, id);
+ strcat(propname, suffix);
+
+ desc = devres_alloc(devm_gpiod_release, sizeof(struct gpio_desc),
+ __GFP_ZERO);
+ if (unlikely(!desc)) {
+ rc = -ENOMEM;
+ goto end;
+ }
+
+ rc = gpio_request_by_name(dev, propname, index, desc, flags);
+
+end:
+ if (propname)
+ free(propname);
+
+ if (rc)
+ return ERR_PTR(rc);
+
+ devres_add(dev, desc);
+
+ return desc;
+}
+
+struct gpio_desc *devm_gpiod_get_index_optional(struct udevice *dev,
+ const char *id,
+ unsigned int index,
+ int flags)
+{
+ struct gpio_desc *desc = devm_gpiod_get_index(dev, id, index, flags);
+
+ if (IS_ERR(desc))
+ return NULL;
+
+ return desc;
+}
+
+void devm_gpiod_put(struct udevice *dev, struct gpio_desc *desc)
+{
+ int rc;
+
+ rc = devres_release(dev, devm_gpiod_release, devm_gpiod_match, desc);
+ WARN_ON(rc);
+}
+
static int gpio_post_bind(struct udevice *dev)
{
struct udevice *child;
diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index a57dd2665c..3ae1894a98 100644
--- a/include/asm-generic/gpio.h
+++ b/include/asm-generic/gpio.h
@@ -701,4 +701,51 @@ int gpio_get_number(const struct gpio_desc *desc);
*/
int gpio_get_acpi(const struct gpio_desc *desc, struct acpi_gpio *gpio);
+/**
+ * devm_gpiod_get_index - Resource-managed gpiod_get()
+ * @dev: GPIO consumer
+ * @con_id:function within the GPIO consumer
+ * @index: index of the GPIO to obtain in the consumer
+ * @flags: optional GPIO initialization flags
+ *
+ * Managed gpiod_get(). GPIO descriptors returned from this function are
+ * automatically disposed on device unbind.
+ * Return the GPIO descriptor corresponding to the function con_id of device
+ * dev, -ENOENT if no GPIO has been assigned to the requested function, or
+ * another IS_ERR() code if an error occurred while trying to acquire the GPIO.
+ */
+struct gpio_desc *devm_gpiod_get_index(struct udevice *dev, const char *id,
+ unsigned int index, int flags);
+
+#define devm_gpiod_get(dev, id, flags) devm_gpiod_get_index(dev, id, 0, flags)
+/**
+ * gpiod_get_optional - obtain an optional GPIO for a given GPIO function
+ * @dev: GPIO consumer, can be NULL for system-global GPIOs
+ * @con_id: function within the GPIO consumer
+ * @index: index of the GPIO to obtain in the consumer
+ * @flags: optional GPIO initialization flags
+ *
+ * This is equivalent to devm_gpiod_get(), except that when no GPIO was
+ * assigned to the requested function it will return NULL. This is convenient
+ * for drivers that need
[PATCH v2 1/3] xilinx: zynqmp: refactor silicon name function
From: Ibai Erkiaga
Current algorithm used to get the silicon name is bit complicated and
hard to follow. Updated to use more straightforward mechanism based on
the Device ID code table (Table 1-2). The full IDCODE register is used
(except device revision bits [31:28]) to get the device name and IDCODE2
value is used for identifying the variant.
Additionally to make the algorithm bit more clear it also save some space
as the devices table is slightly bit smaller.
Signed-off-by: Ibai Erkiaga
Signed-off-by: Michal Simek
---
Changes in v2:
- Add missing 23/39/48/49dr devices
board/xilinx/zynqmp/zynqmp.c | 303 ---
1 file changed, 138 insertions(+), 165 deletions(-)
diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index fe2e219b98c3..ef35b0e5992d 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -39,180 +39,143 @@
#include "pm_cfg_obj.h"
+#define ZYNQMP_VERSION_SIZE7
+#define EFUSE_VCU_DIS_MASK 0x100
+#define EFUSE_VCU_DIS_SHIFT8
+#define EFUSE_GPU_DIS_MASK 0x20
+#define EFUSE_GPU_DIS_SHIFT5
+#define IDCODE2_PL_INIT_MASK 0x200
+#define IDCODE2_PL_INIT_SHIFT 9
+
DECLARE_GLOBAL_DATA_PTR;
#if defined(CONFIG_FPGA) && defined(CONFIG_FPGA_ZYNQMPPL) && \
-!defined(CONFIG_SPL_BUILD)
+!defined(CONFIG_SPL_BUILD) || (defined(CONFIG_SPL_FPGA_SUPPORT) && \
+defined(CONFIG_SPL_BUILD))
+
static xilinx_desc zynqmppl = XILINX_ZYNQMP_DESC;
+enum {
+ ZYNQMP_VARIANT_EG = BIT(0U),
+ ZYNQMP_VARIANT_EV = BIT(1U),
+ ZYNQMP_VARIANT_CG = BIT(2U),
+ ZYNQMP_VARIANT_DR = BIT(3U),
+};
+
static const struct {
u32 id;
- u32 ver;
- char *name;
- bool evexists;
+ u8 device;
+ u8 variants;
} zynqmp_devices[] = {
{
- .id = 0x10,
- .name = "3eg",
- },
- {
- .id = 0x10,
- .ver = 0x2c,
- .name = "3cg",
- },
- {
- .id = 0x11,
- .name = "2eg",
- },
- {
- .id = 0x11,
- .ver = 0x2c,
- .name = "2cg",
- },
- {
- .id = 0x20,
- .name = "5ev",
- .evexists = 1,
- },
- {
- .id = 0x20,
- .ver = 0x100,
- .name = "5eg",
- .evexists = 1,
- },
- {
- .id = 0x20,
- .ver = 0x12c,
- .name = "5cg",
- .evexists = 1,
- },
- {
- .id = 0x21,
- .name = "4ev",
- .evexists = 1,
- },
- {
- .id = 0x21,
- .ver = 0x100,
- .name = "4eg",
- .evexists = 1,
- },
- {
- .id = 0x21,
- .ver = 0x12c,
- .name = "4cg",
- .evexists = 1,
- },
- {
- .id = 0x30,
- .name = "7ev",
- .evexists = 1,
+ .id = 0x04711093,
+ .device = 2,
+ .variants = ZYNQMP_VARIANT_EG | ZYNQMP_VARIANT_CG,
},
{
- .id = 0x30,
- .ver = 0x100,
- .name = "7eg",
- .evexists = 1,
+ .id = 0x04710093,
+ .device = 3,
+ .variants = ZYNQMP_VARIANT_EG | ZYNQMP_VARIANT_CG,
},
{
- .id = 0x30,
- .ver = 0x12c,
- .name = "7cg",
- .evexists = 1,
+ .id = 0x04721093,
+ .device = 4,
+ .variants = ZYNQMP_VARIANT_EG | ZYNQMP_VARIANT_CG |
+ ZYNQMP_VARIANT_EV,
},
{
- .id = 0x38,
- .name = "9eg",
+ .id = 0x04720093,
+ .device = 5,
+ .variants = ZYNQMP_VARIANT_EG | ZYNQMP_VARIANT_CG |
+ ZYNQMP_VARIANT_EV,
},
{
- .id = 0x38,
- .ver = 0x2c,
- .name = "9cg",
+ .id = 0x04739093,
+ .device = 6,
+ .variants = ZYNQMP_VARIANT_EG | ZYNQMP_VARIANT_CG,
},
{
- .id = 0x39,
- .name = "6eg",
+ .id = 0x04730093,
+ .device = 7,
+ .variants = ZYNQMP_VARIANT_EG | ZYNQMP_VARIANT_CG |
+ ZYNQMP_VARIANT_EV,
},
{
- .id = 0x39,
- .ver = 0x2c,
- .name = "6cg",
+ .id = 0x04738093,
+ .device = 9,
+ .variants = ZYNQMP_VARIANT_EG,
},
{
- .id = 0x40,
- .name = "11eg",
- },
- { /* For testing purpose only */
- .id = 0x50,
- .ver = 0x2c,
- .name = "15cg",
+ .id = 0x
[PATCH v5 2/2] test: gpio: Add tests for the managed API
From: Jean-Jacques Hiblot
Add a test to verify that GPIOs can be acquired/released using the managed
API. Also check that the GPIOs are released when the consumer device is
removed.
Signed-off-by: Jean-Jacques Hiblot
Reviewed-by: Simon Glass
Signed-off-by: Pratyush Yadav
---
Notes:
Changes in v5:
- Add Simon's Reviewed-by.
Changes in v4:
- Fix merge conflicts.
- Move "another-test" node down the order to make sure
dm_test_fdt_uclass_seq() continues to work.
- Bump num_devices to 9 in dm_test_bus_children(), dm_test_fdt(), and
dm_test_uclass_foreach() to fix broken tests.
- s/DM_TESTF/UT_TESTF/g
arch/sandbox/dts/test.dts | 10
test/dm/bus.c | 2 +-
test/dm/gpio.c| 102 ++
test/dm/test-fdt.c| 6 +--
4 files changed, 116 insertions(+), 4 deletions(-)
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 9f45c48e4e..d35aa6d1f5 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -121,6 +121,9 @@
<&gpio_c 5 GPIO_IN>,
<&gpio_c 6 (GPIO_ACTIVE_LOW|GPIO_OUT|GPIO_OPEN_DRAIN)>,
<&gpio_c 7 (GPIO_ACTIVE_LOW|GPIO_OUT|GPIO_OPEN_SOURCE)>;
+ test4-gpios = <&gpio_a 14>, <&gpio_b 4 1 3 2 1>;
+ test5-gpios = <&gpio_a 19>;
+
int-value = <1234>;
uint-value = <(-1234)>;
int64-value = /bits/ 64 <0x>;
@@ -270,6 +273,13 @@
compatible = "denx,u-boot-devres-test";
};
+ another-test {
+ reg = <0 2>;
+ compatible = "denx,u-boot-fdt-test";
+ test4-gpios = <&gpio_a 14>, <&gpio_b 4 1 3 2 1>;
+ test5-gpios = <&gpio_a 19>;
+ };
+
acpi_test1: acpi-test {
compatible = "denx,u-boot-acpi-test";
acpi-ssdt-test-data = "ab";
diff --git a/test/dm/bus.c b/test/dm/bus.c
index 865e8bd9fb..27b7266645 100644
--- a/test/dm/bus.c
+++ b/test/dm/bus.c
@@ -120,7 +120,7 @@ UCLASS_DRIVER(testbus) = {
/* Test that we can probe for children */
static int dm_test_bus_children(struct unit_test_state *uts)
{
- int num_devices = 8;
+ int num_devices = 9;
struct udevice *bus;
struct uclass *uc;
diff --git a/test/dm/gpio.c b/test/dm/gpio.c
index 4848152644..54e960b185 100644
--- a/test/dm/gpio.c
+++ b/test/dm/gpio.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -480,3 +481,104 @@ static int dm_test_gpio_get_acpi_irq(struct
unit_test_state *uts)
return 0;
}
DM_TEST(dm_test_gpio_get_acpi_irq, UT_TESTF_SCAN_PDATA | UT_TESTF_SCAN_FDT);
+
+/* Test that we can get/release GPIOs using managed API */
+static int dm_test_gpio_devm(struct unit_test_state *uts)
+{
+ static const u32 flags = GPIOD_IS_OUT | GPIOD_IS_OUT_ACTIVE;
+ struct gpio_desc *desc1, *desc2, *desc3, *desc_err;
+ struct udevice *dev;
+ struct udevice *dev2;
+
+ ut_assertok(uclass_get_device_by_name(UCLASS_TEST_FDT, "a-test",
+ &dev));
+ ut_assertok(uclass_get_device_by_name(UCLASS_TEST_FDT, "another-test",
+ &dev2));
+
+ /* Get 3 GPIOs from 'a-test' dev */
+ desc1 = devm_gpiod_get_index(dev, "test4", 0, flags);
+ ut_assert(!IS_ERR(desc1));
+ desc2 = devm_gpiod_get_index(dev, "test4", 1, flags);
+ ut_assert(!IS_ERR(desc2));
+ desc3 = devm_gpiod_get_index_optional(dev, "test5", 0, flags);
+ ut_assert(!IS_ERR(desc3));
+ ut_assert(desc3);
+
+ /*
+* Try get the same 3 GPIOs from 'a-test' and 'another-test' devices.
+* check that it fails
+*/
+ desc_err = devm_gpiod_get_index(dev, "test4", 0, flags);
+ ut_asserteq(-EBUSY, PTR_ERR(desc_err));
+ desc_err = devm_gpiod_get_index(dev2, "test4", 0, flags);
+ ut_asserteq(-EBUSY, PTR_ERR(desc_err));
+ desc_err = devm_gpiod_get_index(dev, "test4", 1, flags);
+ ut_asserteq(-EBUSY, PTR_ERR(desc_err));
+ desc_err = devm_gpiod_get_index(dev2, "test4", 1, flags);
+ ut_asserteq(-EBUSY, PTR_ERR(desc_err));
+ desc_err = devm_gpiod_get_index_optional(dev, "test5", 0, flags);
+ ut_asserteq_ptr(NULL, desc_err);
+ desc_err = devm_gpiod_get_index_optional(dev2, "test5", 0, flags);
+ ut_asserteq_ptr(NULL, desc_err);
+
+ /* Try get GPIOs outside of the list */
+ desc_err = devm_gpiod_get_index(dev, "test4", 2, flags);
+ ut_assert(IS_ERR(desc_err));
+ desc_err = devm_gpiod_get_index_optional(dev, "test5", 1, flags);
+ ut_asserteq_ptr(NULL, desc_err);
+
+ /* Manipulate the GPIOs */
+ ut_assertok(dm_gpio_set_value(desc1, 1));
+ ut_asserteq(1, dm_gpio_get_value(desc1));
+ ut_assertok(dm_gpio_set_v
Re: [PATCH 1/1] riscv: add DT binding for BOOT button on Maix board
On 11.09.20 09:14, Bin Meng wrote:
> On Thu, Sep 3, 2020 at 4:12 AM Heinrich Schuchardt wrote:
>>
>> Add a device tree binding for the BOOT button on the Maix board.
>>
>> Signed-off-by: Heinrich Schuchardt
>> ---
>> Together with
>> [PATCH 1/1] cmd/button: return button status
>> https://lists.denx.de/pipermail/u-boot/2020-September/425221.html
>> we can use the button status to decide which program to boot.
>> ---
>> arch/riscv/dts/k210-maix-bit.dts | 11 +++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/arch/riscv/dts/k210-maix-bit.dts
>> b/arch/riscv/dts/k210-maix-bit.dts
>> index e840e04ada..c2beec602c 100644
>> --- a/arch/riscv/dts/k210-maix-bit.dts
>> +++ b/arch/riscv/dts/k210-maix-bit.dts
>> @@ -8,6 +8,7 @@
>> #include "k210.dtsi"
>>
>> #include
>> +#include
>>
>> / {
>> model = "Sipeed Maix Bit 2.0";
>> @@ -33,6 +34,16 @@
>> };
>> };
>>
>> + gpio-keys {
>> + compatible = "gpio-keys";
>> +
>> + boot {
>> + label = "BOOT";
>> + linux,code = ;
>
> I cannot find how U-Boot is handling "linux,code". Any pointers?
U-Boot does not use the information. It is used by Linux to determine
which key code should be emitted. See
Documentation/devicetree/bindings/input/gpio-keys.txt
Hence this entry is only relevant if we pass our internal device tree to
Linux. In arch/arm/dts/ I saw that the property is typically set.
Best regards
Heinrich
>
>> + gpios = <&gpio0 0 GPIO_ACTIVE_LOW>;
>> + };
>> + };
>> +
>> sound {
>> compatible = "simple-audio-card";
>> simple-audio-card,format = "i2s";
>> --
>
> Regards,
> Bin
>
Re: [PATCH v3 4/4] arm64: Trap non-PIE builds early if starting from wrong address
On Thu, Sep 10, 2020 at 05:02:56PM +0200, Michal Simek wrote: > > > On 10. 09. 20 15:50, Tom Rini wrote: > > On Thu, Sep 10, 2020 at 03:38:25PM +0200, Michal Simek wrote: > >> > >> > >> On 10. 09. 20 15:06, André Przywara wrote: > >>> On 10/09/2020 13:38, Michal Simek wrote: > > > On 09. 09. 20 19:07, Edgar E. Iglesias wrote: > > From: "Edgar E. Iglesias" > > > > Trap non-PIE builds early if the start address doesn't > > match between run-time and link-time. This will trap the > > startup sequence rather than letting it run into obscure > > errors. > > > > Signed-off-by: Edgar E. Iglesias > > --- arch/arm/cpu/armv8/start.S > > | 13 + 1 file changed, 13 insertions(+) > > > > diff --git a/arch/arm/cpu/armv8/start.S > > b/arch/arm/cpu/armv8/start.S index e5c2856cf5..39e1b842c4 > > 100644 --- a/arch/arm/cpu/armv8/start.S +++ > > b/arch/arm/cpu/armv8/start.S @@ -101,6 +101,19 @@ > > pie_skip_reloc: cmp x2, x3 b.lo pie_fix_loop > > pie_fixup_done: +#else +adr x0, _start +ldr x1, > > _TEXT_BASE +cmp x0, x1 +beq 1f +0: +/* + > > * FATAL, can't > > continue. + * U-Boot needs to start executing at > > CONFIG_SYS_TEXT_BASE. + */ + wfi + b 0b +1: #endif > > > > #ifdef CONFIG_SYS_RESET_SCTRL > > > > NACK for this. > > 1. It breaks SPL flow because CONFIG_SYS_TEXT_BASE is text > base for U-Boot proper 2. It likely also breaks TPL flow for > the same reason > > 3. And last thing is that this code is used only for U-Boot > proper. .globl _TEXT_BASE _TEXT_BASE: .quad > CONFIG_SYS_TEXT_BASE > > The fixes are below. Point 3 should be likely be in separate > patch because it is unrelated. > >>> > >>> So if this patch causes issues, can't we just drop it? I mean > >>> right now you will probably just crash anyway if you load it at > >>> the wrong address, but maybe late enough that you get more > >>> hints or even some output. > >>> > >>> Now this patch makes sure that you don't get anything, so I > >>> don't see how this is really improving the situation. It seems > >>> like a case of "don't fix things that ain't broken". > >> > >> I am fine with dropping it. Tom: What do you think? > > > > OK, yes, we can set this aside for now at least. I assume this is > > all for v2021.01 anyhow? > > > > I would target it for 2021.01. > Dropping #4 and queueing the rest for 2021.01 sounds good to me too. We can revisit a possible check for non-PIE later. Cheers, Edgar
RE: [RESEND PATCH v5 9/11] ARM: socfpga: Add initial support for ic-automation Moritz III
> -Original Message- > From: Nico Becker > Sent: Friday, September 11, 2020 3:03 PM > To: u-boot@lists.denx.de; ma...@denx.de; Tan, Ley Foon > ; simon.k.r.goldschm...@gmail.com > Cc: Nico Becker > Subject: [RESEND PATCH v5 9/11] ARM: socfpga: Add initial support for ic- > automation Moritz III > > Add initial support for ic-automation Moritz III, which is an Cyclone V SOM > with ethernet, usb, uart. Booting via sd-card or flash is supported. > > Changes for v5: > - fixed random ethaddr at failure > - fixed comments > > Changes for v4: > - re-sort list alphabetically > - c style comments > > Changes for v3: > - Resend via git send-email > > Changes for v2: > - Coding Style cleanup > > Signed-off-by: Nico Becker > --- > arch/arm/dts/Makefile | 1 + > ...ocfpga_cyclone5_ica_moritz_iii-u-boot.dtsi | 45 ++ > .../dts/socfpga_cyclone5_ica_moritz_iii.dts | 123 > arch/arm/mach-socfpga/Kconfig | 8 + > board/ic-automation/moritz_iii/MAINTAINERS| 8 + > board/ic-automation/moritz_iii/Makefile | 8 + > .../moritz_iii/moritz_iii_board.c | 127 > .../moritz_iii/qts/iocsr_config.h | 658 ++ > .../moritz_iii/qts/pinmux_config.h| 218 ++ > .../ic-automation/moritz_iii/qts/pll_config.h | 83 +++ > .../moritz_iii/qts/sdram_config.h | 344 + > board/ic-automation/moritz_iii/socfpga.c | 5 + > configs/socfpga_moritz_iii_defconfig | 75 ++ > include/configs/socfpga_ica_moritz_iii.h | 46 ++ > 14 files changed, 1749 insertions(+) > create mode 100644 arch/arm/dts/socfpga_cyclone5_ica_moritz_iii-u- > boot.dtsi > create mode 100644 arch/arm/dts/socfpga_cyclone5_ica_moritz_iii.dts > create mode 100644 board/ic-automation/moritz_iii/MAINTAINERS > create mode 100644 board/ic-automation/moritz_iii/Makefile > create mode 100644 board/ic-automation/moritz_iii/moritz_iii_board.c > create mode 100644 board/ic-automation/moritz_iii/qts/iocsr_config.h > create mode 100644 board/ic-automation/moritz_iii/qts/pinmux_config.h > create mode 100644 board/ic-automation/moritz_iii/qts/pll_config.h > create mode 100644 board/ic-automation/moritz_iii/qts/sdram_config.h > create mode 100644 board/ic-automation/moritz_iii/socfpga.c > create mode 100644 configs/socfpga_moritz_iii_defconfig > create mode 100644 include/configs/socfpga_ica_moritz_iii.h > What is different from patch https://patchwork.ozlabs.org/project/uboot/patch/20200909120223.10174-1-n.bec...@ic-automation.de/ ? This is patch 9/11? Regards Ley Foon
Re: [PATCH] mmc: xenon_sdhci: Add missing common host capabilities
On 11/09/2020 08:43, Stefan Roese wrote: Hi Pali, Andre and others, On 10.09.20 21:04, Pali Rohár wrote: On Thursday 10 September 2020 19:53:40 Andre Heider wrote: Use mmc_of_parse() to set the common host properties. That includes "bus-width", so parsing it can be removed from the driver. But more importantly, "non-removable" is now respected, which fixes the usage of eMMC. Signed-off-by: Andre Heider --- Adding Marek to loop, can you test this patch on MOX A to verify that it does not break MOX uSD and SDIO support? (PS: Andre, for one week I would not be available, therefore in this time I would not be able to test or review Armada 3720 patches...) I'll also be on vacation next week. Sorry, I was not able to follow all discussions on these Armada related patches lately. Could someone please summarize, which patches (fixes) are "okay" for merging in this rc stage (rc4)? That would really be helpful. Going by patchwork we have: All superseded: https://patchwork.ozlabs.org/project/uboot/list/?series=198544 https://patchwork.ozlabs.org/project/uboot/list/?series=198545 https://patchwork.ozlabs.org/project/uboot/list/?series=198756 https://patchwork.ozlabs.org/project/uboot/list/?series=199690 From my point of view these can go in: This one, fix emmc: https://patchwork.ozlabs.org/project/uboot/list/?series=200919 dts: fix vendor, add -emmc variant: https://patchwork.ozlabs.org/project/uboot/list/?series=199579 These two for uDPU from its maintainer, taken from the OpenWRT uboot-mvebu package: CONFIG_SYS_BOOTM_LEN to 64MB: https://patchwork.ozlabs.org/project/uboot/list/?series=199858 add support for Macronix mx25u12835f flash: https://patchwork.ozlabs.org/project/uboot/list/?series=199857 And I'd take these two too, Pali has different opinion though: enable NET_RANDOM_ETHADDR: https://patchwork.ozlabs.org/project/uboot/list/?series=200115 set fdtfile: https://patchwork.ozlabs.org/project/uboot/list/?series=201051 Thanks, Andre
RE: [PATCH v1 03/16] arm: socfpga: Add function for checking description from FIT image
> -Original Message-
> From: Ang, Chee Hong
> Sent: Monday, August 17, 2020 12:34 PM
> To: u-boot@lists.denx.de
> Cc: Marek Vasut ; Simon Goldschmidt
> ; Tom Rini ; See,
> Chin Liang ; Tan, Ley Foon
> ; Ang, Chee Hong ;
> Chee, Tien Fong ; Lim, Elly Siew Chin
>
> Subject: [PATCH v1 03/16] arm: socfpga: Add function for checking
> description from FIT image
>
> Add board_fit_config_name_match() for matching board name with device
> tree files in FIT image. This will ensure correct DTB file is loaded for
> different
> board type. Currently, we are not supporting multiple device tree files in FIT
> image therefore this function basically do nothing for now.
> Users are allowed to override this 'weak' function in their specific board
> implementation.
>
> Signed-off-by: Chee Hong Ang
> ---
> arch/arm/mach-socfpga/board.c | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-socfpga/board.c b/arch/arm/mach-
> socfpga/board.c index 340abf9305..7993c27646 100644
> --- a/arch/arm/mach-socfpga/board.c
> +++ b/arch/arm/mach-socfpga/board.c
> @@ -13,7 +13,7 @@
> #include
> #include
> #include
> -
> +#include
> #include
> #include
>
> @@ -87,3 +87,13 @@ int g_dnl_board_usb_cable_connected(void)
> return 1;
> }
> #endif
> +
> +#ifdef CONFIG_SPL_BUILD
> +__weak int board_fit_config_name_match(const char *name) {
> + /* Just empty function now - can't decide what to choose */
> + debug("%s: %s\n", __func__, name);
> +
> + return 0;
> +}
> +#endif
Reviewed-by: Ley Foon Tan
RE: [PATCH] drivers: net: ldpaa_eth: lx2160a: fix bug in checking if a DPMAC is enabled
>-Original Message-
>From: Ioana Ciornei
>Sent: Thursday, September 10, 2020 3:29 PM
>To: Priyanka Jain ; joe.hershber...@ni.com; u-
>b...@lists.denx.de
>Cc: Grigore Popescu ; Ioana Ciornei
>
>Subject: [PATCH] drivers: net: ldpaa_eth: lx2160a: fix bug in checking if a
>DPMAC is enabled
>
>From: Grigore Popescu
>
>The next DPMAC was always verified if it is enabled. In case of DPMAC@6, the
>DPMAC@7 is verified. As DPMAC@7 is disabled, DPMAC@6 will be considered
>disabled and not detected by uboot.
>
>Signed-off-by: Grigore Popescu
>Signed-off-by: Ioana Ciornei
>---
> drivers/net/ldpaa_eth/lx2160a.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/net/ldpaa_eth/lx2160a.c b/drivers/net/ldpaa_eth/lx2160a.c
>index 9432b6eb85c7..1e62c642039e 100644
>--- a/drivers/net/ldpaa_eth/lx2160a.c
>+++ b/drivers/net/ldpaa_eth/lx2160a.c
>@@ -1,6 +1,6 @@
> // SPDX-License-Identifier: GPL-2.0+
> /*
>- * Copyright 2018 NXP
>+ * Copyright 2018, 2020 NXP
> */
> #include
> #include
>@@ -57,7 +57,7 @@ phy_interface_t wriop_dpmac_enet_if(int dpmac_id, int
>lane_prtcl) {
> enum srds_prtcl;
>
>- if (is_device_disabled(dpmac_id + 1))
>+ if (is_device_disabled(dpmac_id))
> return PHY_INTERFACE_MODE_NONE;
>
> if (lane_prtcl >= SGMII1 && lane_prtcl <= SGMII18)
>--
>2.17.1
Reviewed-by: Priyanka Jain
RE: [PATCH] mmc: stm32_sdmmc2: Use mmc_of_parse() to read host capabilities
Hi Alex, > From: Alex G. > Sent: jeudi 10 septembre 2020 22:10 > > On 9/10/20 11:04 AM, Patrick DELAUNAY wrote: > > Hi Alexandru, > > Hi > > [snip] > > >> + cfg->f_max = 5200; > >> + mmc_of_parse(dev, cfg); > > > > Result of mmc_of_parse is not tested ? > > > > I proposed: > > > > + ret = mmc_of_parse(dev, cfg); > > + if (ret) > > + return ret; > > You're right. I'll get that updated. Thanks; > > > I test this patch with a trace in stm32_sdmmc2_probe on > > STM32MP157C-EV1 > [snip] > > I think that it is a issue U-Boot, in mmc uclass in mmc_of_parse(): > > > > if (dev_read_bool(dev, "cap-mmc-highspeed")) > > - cfg->host_caps |= MMC_CAP(MMC_HS); > > + cfg->host_caps |= MMC_CAP(MMC_HS) | > MMC_CAP(MMC_HS_52); > > > > In U-Boot this capability is splitted in 2 bits = one for 26MHz one > > for 52MHz And for card side it is managed on card side by > > mmc_get_capabilities() > > I agree. I am preparing a patch to address this. Thanks; > > [snip] > > 2) some host caps can be added in device tree (they are supported by SOC and > by Linux driver) > > but they are not supported by U-Boot driver, for example: > > > > #define MMC_MODE_DDR_52MHz MMC_CAP(MMC_DDR_52) > > #define MMC_MODE_HS200 MMC_CAP(MMC_HS_200) > > #define MMC_MODE_HS400 MMC_CAP(MMC_HS_400) > > #define MMC_MODE_HS400_ES MMC_CAP(MMC_HS_400_ES) > > > > > > I afraid (I don't sure) that this added caps change the mmc core > > behavior in U-Boot = U-Boot try to select the high speed mode even if not > supported by driver > > Two issues here. The first is when devicetree enables an unsupported mode, say > "mmc-hs400-1_2v". That's a devicetree bug, and not something we should fix in > the code. Hypothetical exam: DT says > bus-width = <8>; > but only four lines are routed on the board. Yes it is a device tree issue when the mode is not supported by board / SOC. But high mode is supported by the STM32MP15x SOC but only if additional Operation are done (IO configuration to support higher speed) It is not supported in U-Boot driver (yet ?) but it is supported by Linux driver... > The second issue is what happens when somebody plugs in a UHS SD card? > UHS support is not enabled by default in the stm32mp1 defconfigs, so the mmc > core won't try to run it at UHS. > > Now if somebody were to enable UHS manually: > CONFIG_MMC_IO_VOLTAGE=y > CONFIG_MMC_UHS_SUPPORT=y > Then yes, the UHS switch will be attempted, fail, and the card will not be > detected. > > To work around that, one could implement a .wait_dat0() that returns an error > other than -ENOSYS. This would cause mmc_switch_voltage() to fail, making the > mmc core to leave the card at default speeds. > > My argument is that it takes conscious effort to break things in the first > place, so > it's not a situation we should worry about. > Yes we should have issue only if UHS defconfig was activated (CONFIG_MMC_UHS_SUPPORT, CONFIG_MMC_HS*_SUPPORT) And it is not the case today in stm32*defconfig And my proposal is protection (over). > > The host_caps bitfield should be limited by the supported features in the > > driver > (or remove the unsupported features) > [snip] > > cfg->host_caps &= SDMMC_SUPPORTED_CAPS; > > or > > cfg->host_caps |= ~SDMMC_UNSUPPORTED_CAPS; > > I think this sort of playing with the flags will cause more confusion. > People would expect this to come from DT. For example, somebody sets > "sd-uhs-ddr52" in devicetree. It's more confusing to check host_caps, > and find that MMC_MODE_DDR_52MHz is not set than it is to see the driver > trying to place the card in DDR52 and failing. - card_caps = CARD capacity For you - host_caps is SOC capacity (read from DT) For me - host_caps is SOC capacity (read from DT) AND driver capacity => then in mmc u-class, the real capacity is host_caps | card_caps I already see this kind of limitation in one driver omap_hsmmc.c:1939: cfg->host_caps &= ~fixups->unsupported_caps; But I agree it is today an over protection on host_caps and it can be confusing so you can forget this point > Alex Regards Patrick
RE: [PATCH v1 06/16] arm: socfpga: Disable "spin-table" method for booting Linux
> -Original Message- > From: Ang, Chee Hong > Sent: Monday, August 17, 2020 12:34 PM > To: u-boot@lists.denx.de > Cc: Marek Vasut ; Simon Goldschmidt > ; Tom Rini ; See, > Chin Liang ; Tan, Ley Foon > ; Ang, Chee Hong ; > Chee, Tien Fong ; Lim, Elly Siew Chin > > Subject: [PATCH v1 06/16] arm: socfpga: Disable "spin-table" method for > booting Linux > > Standard PSCI function "CPU_ON" provided by ATF is now used by Linux > kernel to bring up the secondary CPUs to enable SMP booting in Linux on SoC > 64bits platform. > > Signed-off-by: Chee Hong Ang > --- > arch/arm/mach-socfpga/Kconfig | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach- > socfpga/Kconfig index 26f2cf8e47..01f5a1fc41 100644 > --- a/arch/arm/mach-socfpga/Kconfig > +++ b/arch/arm/mach-socfpga/Kconfig > @@ -33,7 +33,6 @@ config TARGET_SOCFPGA_AGILEX > bool > select ARMV8_MULTIENTRY > select ARMV8_SET_SMPEN > - select ARMV8_SPIN_TABLE > select CLK > select FPGA_INTEL_SDM_MAILBOX > select NCORE_CACHE > @@ -79,7 +78,6 @@ config TARGET_SOCFPGA_STRATIX10 > bool > select ARMV8_MULTIENTRY > select ARMV8_SET_SMPEN > - select ARMV8_SPIN_TABLE > select FPGA_INTEL_SDM_MAILBOX > > choice > -- > 2.19.0 Reviewed-by: Ley Foon Tan
RE: [PATCH v1 07/16] arm: socfpga: soc64: Add SMC helper function for Intel SOCFPGA (64bits)
> -Original Message-
> From: Ang, Chee Hong
> Sent: Monday, August 17, 2020 12:34 PM
> To: u-boot@lists.denx.de
> Cc: Marek Vasut ; Simon Goldschmidt
> ; Tom Rini ; See,
> Chin Liang ; Tan, Ley Foon
> ; Ang, Chee Hong ;
> Chee, Tien Fong ; Lim, Elly Siew Chin
>
> Subject: [PATCH v1 07/16] arm: socfpga: soc64: Add SMC helper function for
> Intel SOCFPGA (64bits)
>
> invoke_smc() allow U-Boot proper running in non-secure mode (EL2) to
> invoke SMC call to ATF's PSCI runtime services such as System Manager's
> registers access, 2nd phase bitstream FPGA reconfiguration, Remote System
> Update (RSU) and etc.
>
> smc_send_mailbox() is a send mailbox command helper function which
> invokes the ATF's PSCI runtime service (function ID:
> INTEL_SIP_SMC_MBOX_SEND_CMD) to send mailbox messages to Secure
> Device Manager (SDM).
>
> Signed-off-by: Chee Hong Ang
> ---
> arch/arm/mach-socfpga/Makefile | 2 +
> arch/arm/mach-socfpga/include/mach/smc_api.h | 13 +
> arch/arm/mach-socfpga/smc_api.c | 56
> 3 files changed, 71 insertions(+)
> create mode 100644 arch/arm/mach-socfpga/include/mach/smc_api.h
> create mode 100644 arch/arm/mach-socfpga/smc_api.c
>
> diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-
> socfpga/Makefile index c63162a5c6..0b05283a7a 100644
> --- a/arch/arm/mach-socfpga/Makefile
> +++ b/arch/arm/mach-socfpga/Makefile
> @@ -72,6 +72,8 @@ ifdef CONFIG_TARGET_SOCFPGA_AGILEX
> obj-y+= firewall.o
> obj-y+= spl_agilex.o
> endif
> +else
> +obj-$(CONFIG_SPL_ATF) += smc_api.o
> endif
>
> ifdef CONFIG_TARGET_SOCFPGA_GEN5
> diff --git a/arch/arm/mach-socfpga/include/mach/smc_api.h
> b/arch/arm/mach-socfpga/include/mach/smc_api.h
> new file mode 100644
> index 00..bbefdd8dd9
> --- /dev/null
> +++ b/arch/arm/mach-socfpga/include/mach/smc_api.h
> @@ -0,0 +1,13 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright (C) 2020 Intel Corporation */
> +
> +#ifndef _SMC_API_H_
> +#define _SMC_API_H_
> +
> +int invoke_smc(u32 func_id, u64 *args, int arg_len, u64 *ret_arg, int
> +ret_len); int smc_send_mailbox(u32 cmd, u32 len, u32 *arg, u8 urgent, u32
> *resp_buf_len,
> + u32 *resp_buf);
> +
> +#endif /* _SMC_API_H_ */
> diff --git a/arch/arm/mach-socfpga/smc_api.c b/arch/arm/mach-
> socfpga/smc_api.c new file mode 100644 index 00..085daba162
> --- /dev/null
> +++ b/arch/arm/mach-socfpga/smc_api.c
> @@ -0,0 +1,56 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2020 Intel Corporation
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +int invoke_smc(u32 func_id, u64 *args, int arg_len, u64 *ret_arg, int
> +ret_len) {
> + struct pt_regs regs;
> +
> + memset(®s, 0, sizeof(regs));
> + regs.regs[0] = func_id;
> +
> + if (args)
> + memcpy(®s.regs[1], args, arg_len * sizeof(*args));
> +
> + smc_call(®s);
> +
> + if (ret_arg)
> + memcpy(ret_arg, ®s.regs[1], ret_len * sizeof(*ret_arg));
> +
> + return regs.regs[0];
> +}
> +
> +int smc_send_mailbox(u32 cmd, u32 len, u32 *arg, u8 urgent, u32
> *resp_buf_len,
> + u32 *resp_buf)
> +{
> + int ret;
> + u64 args[6];
> + u64 resp[3];
> +
> + args[0] = cmd;
> + args[1] = (u64)arg;
> + args[2] = len;
> + args[3] = urgent;
> + args[4] = (u64)resp_buf;
> + if (resp_buf_len)
> + args[5] = *resp_buf_len;
> + else
> + args[5] = 0;
> +
> + ret = invoke_smc(INTEL_SIP_SMC_MBOX_SEND_CMD, args,
> ARRAY_SIZE(args),
> + resp, ARRAY_SIZE(resp));
> +
> + if (ret == INTEL_SIP_SMC_STATUS_OK && resp_buf && resp_buf_len)
> {
> + if (!resp[0])
> + *resp_buf_len = resp[1];
> + }
> +
> + return (int)resp[0];
> +}
> --
> 2.19.0
Reviewed-by: Ley Foon Tan
RE: [PATCH v1 05/16] arm: socfpga: soc64: Override 'lowlevel_init' to support ATF
> -Original Message- > From: Ang, Chee Hong > Sent: Monday, August 17, 2020 12:34 PM > To: u-boot@lists.denx.de > Cc: Marek Vasut ; Simon Goldschmidt > ; Tom Rini ; See, > Chin Liang ; Tan, Ley Foon > ; Ang, Chee Hong ; > Chee, Tien Fong ; Lim, Elly Siew Chin > > Subject: [PATCH v1 05/16] arm: socfpga: soc64: Override 'lowlevel_init' to > support ATF > > Override 'lowlevel_init' to make sure secondary CPUs trapped in ATF instead > of SPL. After ATF is initialized, it will signal the secondary CPUs to jump > from > SPL to ATF waiting to be 'activated' > by Linux OS via PSCI call. > > Signed-off-by: Chee Hong Ang > --- > arch/arm/mach-socfpga/Makefile | 2 + > arch/arm/mach-socfpga/lowlevel_init_soc64.S | 76 Reviewed-by: Ley Foon Tan
RE: [PATCH v1 12/16] arm: socfpga: soc64: Add ATF support for FPGA reconfig driver
> -Original Message- > From: Ang, Chee Hong > Sent: Monday, August 17, 2020 12:34 PM > To: u-boot@lists.denx.de > Cc: Marek Vasut ; Simon Goldschmidt > ; Tom Rini ; See, > Chin Liang ; Tan, Ley Foon > ; Ang, Chee Hong ; > Chee, Tien Fong ; Lim, Elly Siew Chin > > Subject: [PATCH v1 12/16] arm: socfpga: soc64: Add ATF support for FPGA > reconfig driver > > In non-secure mode (EL2), FPGA reconfiguration driver calls the SMC/PSCI > services provided by ATF to configure the FPGA. > > Signed-off-by: Chee Hong Ang > --- > drivers/fpga/intel_sdm_mb.c | 139 > > 1 file changed, 139 insertions(+) > Reviewed-by: Ley Foon Tan
Re: [PATCH] riscv: Only enable OF_BOARD_FIXUP for S-Mode
On 9/11/20 3:29 AM, Bin Meng wrote:
> Hi Sean,
>
> On Sat, Sep 5, 2020 at 9:22 PM Sean Anderson wrote:
>>
>> It is unsafe to enable OF_BOARD_FIXUP only based on OF_SEPARATE.
>> OF_SEPARATE may indicate that the user wishes U-Boot to use a different
>> device tree than one obtained via OF_PRIOR_STAGE. However, OF_SEPARATE may
>> also indicate that the device tree which would be obtained via
>> OF_PRIOR_STAGE is invalid, nonexistant, or otherwise unusable. In this
>
> typo: nonexistent
>
>> latter case, enabling OF_BOARD_FIXUP will result in corruption of the
>> device tree. To remedy this, only enable OF_BOARD_FIXUP if U-Boot is
>> configured for S-Mode.
>>
>> Fixes: 1c17e55594a394ced7de88d91be294eaf8c564c1
>
> nits: the format should be: commit_id ("description")>
>> Signed-off-by: Sean Anderson
>> ---
>>
>> arch/riscv/Kconfig | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
>> index 009a545fcf..13fac51483 100644
>> --- a/arch/riscv/Kconfig
>> +++ b/arch/riscv/Kconfig
>> @@ -288,6 +288,6 @@ config STACK_SIZE_SHIFT
>> default 14
>>
>> config OF_BOARD_FIXUP
>> - default y if OF_SEPARATE
>> + default y if OF_SEPARATE && RISCV_SMODE
>
> Is that your board is running U-Boot M-mode with OF_SEPARATE that does not
> work?
Yes, because the reason we use OF_SEPARATE is because no device tree is
passed to U-Boot. Trying to use the device tree passed to U-Boot even
though OF_SEPARATE is enabled results in garbage being written to the
actual device tree. Without this patch, booting on the K210 randomly
fails.
>
>>
>> endmenu
>> --
>
> Regards,
> Bin
>
Re: [PATCH 1/7] Revert "riscv: Clear pending interrupts before enabling IPIs"
On 9/11/20 3:38 AM, Bin Meng wrote: > Hi Sean, > > On Tue, Sep 8, 2020 at 2:17 AM Sean Anderson wrote: >> >> Clearing MIP doesn't do anything. Whoops. The following commits should > > Which following commits? > >> tackle this problem in a more robust manner. >> >> This reverts commit 9472630337e7c4ac442066b5a752aaa8c3b4d4a6. >> >> Signed-off-by: Sean Anderson >> --- >> >> arch/riscv/cpu/start.S | 2 -- >> 1 file changed, 2 deletions(-) >> >> diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S >> index bf9fdf369b..e3222b1ea7 100644 >> --- a/arch/riscv/cpu/start.S >> +++ b/arch/riscv/cpu/start.S >> @@ -65,8 +65,6 @@ _start: >> #else >> li t0, SIE_SSIE >> #endif >> - /* Clear any pending IPIs */ >> - csrcMODE_PREFIX(ip), t0 > > Did you mean the clearing MIP.MSIP actually does nothing, but the > following commit is the correct fix? Yes, but we also need [PATCH 3/7] riscv: Use NULL as a sentinel value for smp_call_function so the secondary harts know not to take any IPIs not raised by U-Boot. > > commit 40686c394e533fec765fe237936e353c84e73fff > Author: Sean Anderson > Date: Wed Jun 24 06:41:18 2020 -0400 > > riscv: Clean up IPI initialization code > > The previous IPI code initialized the device whenever the first call was > made to a riscv_*_ipi function. This made it difficult to determine when > the IPI device was initialized. This patch introduces a new function > riscv_init_ipi. It is called once during arch_cpu_init_dm. In SPL, it is > called in spl_invoke_opensbi. Before this point, no riscv_*_ipi functions > should be called. > > Signed-off-by: Sean Anderson > Reviewed-by: Rick Chen > >> csrsMODE_PREFIX(ie), t0 >> #endif >> --Sean
configs: lx2162aqds: enable CONFIG_BOARD_EARLY_INIT_R
From: Guanhua Gao From: Yangbo Lu Enable CONFIG_BOARD_EARLY_INIT_R for SDHC adapter card identification and configuration. Signed-off-by: Yangbo Lu diff --git a/configs/lx2162aqds_tfa_SECURE_BOOT_defconfig b/configs/lx2162aqds_tfa_SECURE_BOOT_defconfig index 9b1850c..e658592 100644 --- a/configs/lx2162aqds_tfa_SECURE_BOOT_defconfig +++ b/configs/lx2162aqds_tfa_SECURE_BOOT_defconfig @@ -16,6 +16,7 @@ CONFIG_OF_STDOUT_VIA_ALIAS=y CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS="console=ttyAMA0,115200 root=/dev/ram0 earlycon=pl011,mmio32,0x21c ramdisk_size=0x200 default_hugepagesz=1024m hugepagesz=1024m hugepages=2 pci=pcie_bus_perf" # CONFIG_USE_BOOTCOMMAND is not set +CONFIG_BOARD_EARLY_INIT_R=y CONFIG_MISC_INIT_R=y CONFIG_CMD_GREPENV=y CONFIG_CMD_EEPROM=y diff --git a/configs/lx2162aqds_tfa_defconfig b/configs/lx2162aqds_tfa_defconfig index 07837b9..ade6b7b 100644 --- a/configs/lx2162aqds_tfa_defconfig +++ b/configs/lx2162aqds_tfa_defconfig @@ -18,6 +18,7 @@ CONFIG_BOOTDELAY=10 CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS="console=ttyAMA0,115200 root=/dev/ram0 earlycon=pl011,mmio32,0x21c ramdisk_size=0x200 default_hugepagesz=1024m hugepagesz=1024m hugepages=2 pci=pcie_bus_perf" # CONFIG_USE_BOOTCOMMAND is not set +CONFIG_BOARD_EARLY_INIT_R=y CONFIG_MISC_INIT_R=y CONFIG_CMD_GREPENV=y CONFIG_CMD_EEPROM=y diff --git a/configs/lx2162aqds_tfa_verified_boot_defconfig b/configs/lx2162aqds_tfa_verified_boot_defconfig index 5d4ad47..3131fb3 100644 --- a/configs/lx2162aqds_tfa_verified_boot_defconfig +++ b/configs/lx2162aqds_tfa_verified_boot_defconfig @@ -20,6 +20,7 @@ CONFIG_BOOTDELAY=10 CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS="console=ttyAMA0,115200 root=/dev/ram0 earlycon=pl011,mmio32,0x21c ramdisk_size=0x200 default_hugepagesz=1024m hugepagesz=1024m hugepages=2 pci=pcie_bus_perf" # CONFIG_USE_BOOTCOMMAND is not set +CONFIG_BOARD_EARLY_INIT_R=y CONFIG_MISC_INIT_R=y CONFIG_CMD_GREPENV=y CONFIG_CMD_EEPROM=y
arm: dts: lx2162aqds: support eMMC HS400 mode
From: Guanhua Gao
From: Yangbo Lu
Add properties related to eMMC HS400 mode.
Signed-off-by: Yangbo Lu
diff --git a/arch/arm/dts/fsl-lx2162a-qds.dts b/arch/arm/dts/fsl-lx2162a-qds.dts
index 8c29fd2..a2be9ac 100644
--- a/arch/arm/dts/fsl-lx2162a-qds.dts
+++ b/arch/arm/dts/fsl-lx2162a-qds.dts
@@ -55,6 +55,9 @@
&esdhc1 {
status = "okay";
+ mmc-hs200-1_8v;
+ mmc-hs400-1_8v;
+ bus-width = <8>;
};
&i2c0 {
configs: lx2162aqds: enable eMMC HS400 mode support
From: Guanhua Gao From: Yangbo Lu Enable eMMC HS400 mode support on LX2162AQDS. Signed-off-by: Yangbo Lu diff --git a/configs/lx2162aqds_tfa_SECURE_BOOT_defconfig b/configs/lx2162aqds_tfa_SECURE_BOOT_defconfig index 9b1850c..75ee76d 100644 --- a/configs/lx2162aqds_tfa_SECURE_BOOT_defconfig +++ b/configs/lx2162aqds_tfa_SECURE_BOOT_defconfig @@ -36,6 +36,7 @@ CONFIG_NET_RANDOM_ETHADDR=y CONFIG_DM=y CONFIG_SATA_CEVA=y CONFIG_DM_MMC=y +CONFIG_MMC_HS400_SUPPORT=y CONFIG_FSL_ESDHC=y CONFIG_MTD=y CONFIG_DM_SPI_FLASH=y diff --git a/configs/lx2162aqds_tfa_defconfig b/configs/lx2162aqds_tfa_defconfig index 07837b9..181b8d1 100644 --- a/configs/lx2162aqds_tfa_defconfig +++ b/configs/lx2162aqds_tfa_defconfig @@ -42,6 +42,7 @@ CONFIG_DM=y CONFIG_SATA_CEVA=y CONFIG_FSL_CAAM=y CONFIG_DM_MMC=y +CONFIG_MMC_HS400_SUPPORT=y CONFIG_FSL_ESDHC=y CONFIG_MTD=y CONFIG_DM_SPI_FLASH=y diff --git a/configs/lx2162aqds_tfa_verified_boot_defconfig b/configs/lx2162aqds_tfa_verified_boot_defconfig index 5d4ad47..4008412 100644 --- a/configs/lx2162aqds_tfa_verified_boot_defconfig +++ b/configs/lx2162aqds_tfa_verified_boot_defconfig @@ -44,6 +44,7 @@ CONFIG_DM=y CONFIG_SATA_CEVA=y CONFIG_FSL_CAAM=y CONFIG_DM_MMC=y +ONFIG_MMC_HS400_SUPPORT=y CONFIG_FSL_ESDHC=y CONFIG_MTD=y CONFIG_DM_SPI_FLASH=y
Re: [PATCH 5/7] riscv: Add fence to available_harts_lock
On 9/9/20 11:26 PM, Rick Chen wrote: > Hi Sean > >> Without these fences, it is perfectly valid for an out-of-order core to >> re-order memory accesses to outside of the available_harts_lock critical >> section. >> >> Signed-off-by: Sean Anderson >> --- >> >> arch/riscv/cpu/start.S | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S >> index e3222b1ea7..ad18e746b6 100644 >> --- a/arch/riscv/cpu/start.S >> +++ b/arch/riscv/cpu/start.S >> @@ -126,12 +126,12 @@ call_board_init_f_0: >> #ifndef CONFIG_XIP >> la t0, available_harts_lock >> fence rw, w >> - amoswap.w zero, zero, 0(t0) >> + amoswap.w.rl zero, zero, 0(t0) > > fence rw, w can also be removed. Hmm. Actually, upon reading the spec I noticed this paragraph > To help implement multiprocessor synchronization, the AMOs optionally > provide release consistency semantics. If the aq bit is set, then no > later memory operations in this RISC-V hart can be observed to take > place before the AMO. Conversely, if the rl bit is set, then other > RISC-V harts will not observe the AMO before memory accesses preceding > the AMO in this RISC-V hart. Setting both the aq and the rl bit on an > AMO makes the sequence sequentially consistent, meaning that it cannot > be reordered with earlier or later memory operations from the same > hart. The key word being optionally. However, I could not find any information on how to detect if this option is enabled. Perhaps a separate fence was used to prevent having to try and detect this feature? >> >> wait_for_gd_init: >> la t0, available_harts_lock >> li t1, 1 >> -1: amoswap.w t1, t1, 0(t0) >> +1: amoswap.w.aq t1, t1, 0(t0) >> fence r, rw > > fence r, rw can also be removed. > >> bnezt1, 1b >> >> @@ -143,7 +143,7 @@ wait_for_gd_init: >> SREGt2, GD_AVAILABLE_HARTS(gp) >> >> fence rw, w > > fence rw, w can also be removed. > > Thanks, > Rick > >> - amoswap.w zero, zero, 0(t0) >> + amoswap.w.rl zero, zero, 0(t0) >> >> /* >> * Continue on hart lottery winner, others branch to >> -- >> 2.28.0 >>
[PATCH] fs/squashfs: Fix Coverity Scan defects
Fix control flow issues and null pointer dereferences.
Signed-off-by: Joao Marcos Costa
---
fs/squashfs/sqfs.c | 20 +---
fs/squashfs/sqfs_dir.c | 3 +--
fs/squashfs/sqfs_inode.c | 5 -
3 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/fs/squashfs/sqfs.c b/fs/squashfs/sqfs.c
index f67f7c4a40..15208b4dab 100644
--- a/fs/squashfs/sqfs.c
+++ b/fs/squashfs/sqfs.c
@@ -154,7 +154,7 @@ static int sqfs_frag_lookup(u32 inode_fragment_index,
header = get_unaligned_le16(metadata_buffer + table_offset);
metadata = metadata_buffer + table_offset + SQFS_HEADER_SIZE;
- if (!metadata) {
+ if (!metadata || !header) {
ret = -ENOMEM;
goto free_buffer;
}
@@ -434,9 +434,9 @@ static int sqfs_search_dir(struct squashfs_dir_stream
*dirs, char **token_list,
{
struct squashfs_super_block *sblk = ctxt.sblk;
char *path, *target, **sym_tokens, *res, *rem;
- struct squashfs_ldir_inode *ldir = NULL;
int j, ret, new_inode_number, offset;
struct squashfs_symlink_inode *sym;
+ struct squashfs_ldir_inode *ldir;
struct squashfs_dir_inode *dir;
struct fs_dir_stream *dirsp;
struct fs_dirent *dent;
@@ -448,8 +448,8 @@ static int sqfs_search_dir(struct squashfs_dir_stream
*dirs, char **token_list,
table = sqfs_find_inode(dirs->inode_table, le32_to_cpu(sblk->inodes),
sblk->inodes, sblk->block_size);
- /* root is a regular directory, not an extended one */
dir = (struct squashfs_dir_inode *)table;
+ ldir = (struct squashfs_ldir_inode *)table;
/* get directory offset in directory table */
offset = sqfs_dir_offset(table, m_list, m_count);
@@ -1146,7 +1146,10 @@ static int sqfs_get_regfile_info(struct
squashfs_reg_inode *reg,
finfo->start = get_unaligned_le32(®->start_block);
finfo->frag = SQFS_IS_FRAGMENTED(get_unaligned_le32(®->fragment));
- if (finfo->size < 1 || finfo->offset < 0 || finfo->start < 0)
+ if (finfo->frag && finfo->offset == 0x)
+ return -EINVAL;
+
+ if (finfo->size < 1 || finfo->start == 0x)
return -EINVAL;
if (finfo->frag) {
@@ -1156,7 +1159,7 @@ static int sqfs_get_regfile_info(struct
squashfs_reg_inode *reg,
if (ret < 0)
return -EINVAL;
finfo->comp = true;
- if (fentry->size < 1 || fentry->start < 0)
+ if (fentry->size < 1 || fentry->start == 0x7FFF)
return -EINVAL;
} else {
datablk_count = DIV_ROUND_UP(finfo->size, le32_to_cpu(blksz));
@@ -1181,7 +1184,10 @@ static int sqfs_get_lregfile_info(struct
squashfs_lreg_inode *lreg,
finfo->start = get_unaligned_le64(&lreg->start_block);
finfo->frag = SQFS_IS_FRAGMENTED(get_unaligned_le32(&lreg->fragment));
- if (finfo->size < 1 || finfo->offset < 0 || finfo->start < 0)
+ if (finfo->frag && finfo->offset == 0x)
+ return -EINVAL;
+
+ if (finfo->size < 1 || finfo->start == 0x7FFF)
return -EINVAL;
if (finfo->frag) {
@@ -1191,7 +1197,7 @@ static int sqfs_get_lregfile_info(struct
squashfs_lreg_inode *lreg,
if (ret < 0)
return -EINVAL;
finfo->comp = true;
- if (fentry->size < 1 || fentry->start < 0)
+ if (fentry->size < 1 || fentry->start == 0x7FFF)
return -EINVAL;
} else {
datablk_count = DIV_ROUND_UP(finfo->size, le32_to_cpu(blksz));
diff --git a/fs/squashfs/sqfs_dir.c b/fs/squashfs/sqfs_dir.c
index 00d2891e7d..a265b98fe6 100644
--- a/fs/squashfs/sqfs_dir.c
+++ b/fs/squashfs/sqfs_dir.c
@@ -34,8 +34,7 @@ int sqfs_dir_offset(void *dir_i, u32 *m_list, int m_count)
struct squashfs_ldir_inode *ldir;
struct squashfs_dir_inode *dir;
u32 start_block;
- u16 offset;
- int j;
+ int j, offset;
switch (get_unaligned_le16(&base->inode_type)) {
case SQFS_DIR_TYPE:
diff --git a/fs/squashfs/sqfs_inode.c b/fs/squashfs/sqfs_inode.c
index 1387779a85..1368f3063c 100644
--- a/fs/squashfs/sqfs_inode.c
+++ b/fs/squashfs/sqfs_inode.c
@@ -142,8 +142,11 @@ int sqfs_read_metablock(unsigned char *file_mapping, int
offset,
u16 header;
data = file_mapping + offset;
+ if (!data)
+ return -EFAULT;
+
header = get_unaligned((u16 *)data);
- if (!header || !data)
+ if (!header)
return -EINVAL;
*compressed = SQFS_COMPRESSED_METADATA(header);
--
2.17.1
[PATCH 1/2] net: pfe_eth: Fix resoure leak in pfe_spi_flash_init
Fix Coverity issue: RESOURCE_LEAK.
leaked_storage: Variable addr going out of scope leaks the storage it
points to.
Fixes: e0152dbed683 ("net: pfe_eth: Use spi_flash_read API to access
flash memory")
Signed-off-by: Kuldeep Singh
---
drivers/net/pfe_eth/pfe_firmware.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/net/pfe_eth/pfe_firmware.c
b/drivers/net/pfe_eth/pfe_firmware.c
index 55e661c..4ad09dd 100644
--- a/drivers/net/pfe_eth/pfe_firmware.c
+++ b/drivers/net/pfe_eth/pfe_firmware.c
@@ -170,6 +170,9 @@ int pfe_spi_flash_init(void)
int ret = 0;
void *addr = malloc(CONFIG_SYS_QE_FMAN_FW_LENGTH);
+ if (!addr)
+ return -ENOMEM;
+
#ifdef CONFIG_DM_SPI_FLASH
struct udevice *new;
@@ -186,6 +189,7 @@ int pfe_spi_flash_init(void)
#endif
if (!pfe_flash) {
printf("SF: probe for pfe failed\n");
+ free(addr);
return -ENODEV;
}
--
2.7.4
[PATCH 2/2] net: pfe_eth: Remove non-DM code check from pfe_spi_flash_init
CONFIG_DM_SPI_FLASH is only supported now with passing of driver
conversion deadline from non-DM to DM model. Hence, it's safe to remove
non-DM code check from pfe_spi_flash_init.
Also use CONFIG_ENV_SPI_MODE and CONFIG_ENV_SPI_MAX_HZ instead of
reading reading values from DT.
Signed-off-by: Kuldeep Singh
---
drivers/net/pfe_eth/pfe_firmware.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/net/pfe_eth/pfe_firmware.c
b/drivers/net/pfe_eth/pfe_firmware.c
index 4ad09dd..d414c75 100644
--- a/drivers/net/pfe_eth/pfe_firmware.c
+++ b/drivers/net/pfe_eth/pfe_firmware.c
@@ -167,26 +167,20 @@ static int pfe_fit_check(void)
int pfe_spi_flash_init(void)
{
struct spi_flash *pfe_flash;
+ struct udevice *new;
int ret = 0;
void *addr = malloc(CONFIG_SYS_QE_FMAN_FW_LENGTH);
if (!addr)
return -ENOMEM;
-#ifdef CONFIG_DM_SPI_FLASH
- struct udevice *new;
-
- /* speed and mode will be read from DT */
ret = spi_flash_probe_bus_cs(CONFIG_ENV_SPI_BUS,
-CONFIG_ENV_SPI_CS, 0, 0, &new);
+CONFIG_ENV_SPI_CS,
+CONFIG_ENV_SPI_MAX_HZ,
+CONFIG_ENV_SPI_MODE,
+&new);
pfe_flash = dev_get_uclass_priv(new);
-#else
- pfe_flash = spi_flash_probe(CONFIG_ENV_SPI_BUS,
- CONFIG_ENV_SPI_CS,
- CONFIG_ENV_SPI_MAX_HZ,
- CONFIG_ENV_SPI_MODE);
-#endif
if (!pfe_flash) {
printf("SF: probe for pfe failed\n");
free(addr);
--
2.7.4
RE: [PATCH] mmc: stm32_sdmmc2: Use mmc_of_parse() to read host capabilities
Hi Jaehoon
> From: Jaehoon Chung
> Sent: vendredi 11 septembre 2020 09:50
>
> On 9/10/20 6:54 AM, Alexandru Gagniuc wrote:
> > mmc_of_parse() can populate the 'f_max' and 'host_caps' fields of
> > struct mmc_config from devicetree.
> > The same logic is duplicated in stm32_sdmmc2_probe(). Use
> > mmc_of_parse(), which is more generic.
> >
> > Signed-off-by: Alexandru Gagniuc
> > ---
> > drivers/mmc/stm32_sdmmc2.c | 18 ++
> > 1 file changed, 2 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/mmc/stm32_sdmmc2.c b/drivers/mmc/stm32_sdmmc2.c
> > index 6d50356217..77871d5afc 100644
> > --- a/drivers/mmc/stm32_sdmmc2.c
> > +++ b/drivers/mmc/stm32_sdmmc2.c
> > @@ -676,27 +676,13 @@ static int stm32_sdmmc2_probe(struct udevice *dev)
> > GPIOD_IS_IN);
> >
> > cfg->f_min = 40;
> > - cfg->f_max = dev_read_u32_default(dev, "max-frequency", 5200);
> > cfg->voltages = MMC_VDD_32_33 | MMC_VDD_33_34 |
> MMC_VDD_165_195;
> > cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
> > cfg->name = "STM32 SD/MMC";
> >
> > cfg->host_caps = 0;
> > - if (cfg->f_max > 2500)
> > - cfg->host_caps |= MMC_MODE_HS_52MHz | MMC_MODE_HS;
> > -
> > - switch (dev_read_u32_default(dev, "bus-width", 1)) {
> > - case 8:
> > - cfg->host_caps |= MMC_MODE_8BIT;
> > - /* fall through */
> > - case 4:
> > - cfg->host_caps |= MMC_MODE_4BIT;
> > - break;
> > - case 1:
> > - break;
> > - default:
> > - pr_err("invalid \"bus-width\" property, force to 1\n");
> > - }
> > + cfg->f_max = 5200;
>
> cfg->f_max can be also removed?
>
> Best Regards,
> Jaehoon Chung
I don't think because " max-frequency" is optional in device tree (only "reg"
is required)
Here 52MHz is a default value when it is absent in device tree
That avoids cfg->f_max = 0 after mmc_of_parse() call.
>
> > + mmc_of_parse(dev, cfg);
> >
> > upriv->mmc = &plat->mmc;
> >
> >
Patrick
Re: [PATCH] defconfig: espressobin: enable NET_RANDOM_ETHADDR
On Wed, 9 Sep 2020 00:38:31 +0200 Pali Rohár wrote: > On Tuesday 08 September 2020 08:52:56 Tom Rini wrote: > > On Tue, Sep 08, 2020 at 10:14:15AM +0200, Andre Heider wrote: > > > On 08/09/2020 09:42, Pali Rohár wrote: > > > > On Tuesday 08 September 2020 08:35:00 Andre Heider wrote: > > > > > The hardware does not provide a MAC address. Enable this so > > > > > that network access works with just the default environment. > > > > > > > > Well, this is not fully truth as MAC address is stored in SPI, > > > > just in non-standard format, in U-Boot env stored in env > > > > partition and it is hard to use outside of U-Boot, plus easy to > > > > erase / overwrite / lost. > > > > > > True, but updating the bootloader usually implies wiping the env, > > > so it's very easy to lose it. > > > > It most certainly should NOT wipe out the existing environment, it > > should be using the same environment location as before. > > The main issue is that downstream distributions are doing it. Plus > they probably have custom U-Boot patches. Nothing which mainline > U-Boot can forbid or change. > > Also if somebody is updating from old Marvell factory U-Boot to > mainline U-Boot, SPI env offset may be different and therefore it > wipes env. > > And also, if U-Boot is upgrading from ancient version to new, it is > suggested to reset env to have e.g. new distroboot support. > > So any of above situation can lead to erasing env and therefore it is > a very good idea to create backup of MAC address(es). > > > > > I'm not a big fan of this change. This looks like a workaround > > > > / hack for boards where MAC address was erased (e.g. by broken > > > > U-Boot distro scripts) or for early boards where MAC address > > > > was not written at all (as I was told). > > > > > > > > And on these boards this patch would cause that U-Boot would > > > > see on every boot different MAC address. This would cause > > > > another mess in network for U-Boot netboot as DHCP/TFTP server > > > > would see for one board every time different MAC address. > > > > > > > > Is not really better to instruct user how to fix board where > > > > e.g. broken distro scripts erased MAC address? We have already > > > > paragraph in README.marvell about it. > > > > > > > > Also this change affects "default" defconfig value. And based > > > > on above arguments I do not think that this change should be > > > > enabled by default. > > > > > > > > I understand that for some situations it may be useful (e.g. > > > > mass board reparation process via netboot), but as this is > > > > config option, users in such situation can enable this option > > > > manually. > > > > > > > > I think that for default behavior is not provide network access > > > > in U-Boot if for some reasons factory permanent MAC address was > > > > removed. User can easier and faster detect this issue and fix > > > > it. > > > > > > It can be argued both ways I guess. If this option wouldn't make > > > sense it wouldn't exist. > > As I wrote, I understand that this option is useful in some > situations. > > > > Out of the box working network access is probably what most users > > > care about. > > Of course! But what does "working network access" means? Somebody > wants to have DHCP, even semi/half-working and does not care about RFC > compliance. Somebody does not want to have mess in the network and so > every device must use only assigned MAC / IP (v4/v6) address and not > any different. And somebody just to want working TFTP, does not care > about DHCP, IP or MAC address. > > And for some of these situation is CONFIG_NET_RANDOM_ETHADDR great, > for some harmless and for other is harmful (in context that all these > devices got assigned MAC address in factory). > > Also I know that in some networks is forbidden to use other than > factory MAC address (users are not allowed to connect device with > changed MAC address). > > > > Changing this default means that you need to build the whole > > > firmware yourself, and let's face it: building it for this board > > > is a total clusterfuck. Most users will just download a binary. I > > > don't care too much for this patch, but I would consider what > > > fits most users. > > > > > > Right now most users will probably run the downstream binaries > > > provided by armbian, and as you know, that even has single > > > hardcoded MAC, used for all boards. So this would already be an > > > improvement ;) > > I think that we do not have to care about people who use downstream > patched U-Boot. In most case default U-Boot defconfig may be changed > or be different. > > Change is in this patch is only about default mainline U-Boot > configuration. I think it should be sane default and for me sane > default is the least surprise. So if configuration is missing either > throw error so can immediately fix it or make it predicable / > deterministic. > > > Note that when CONFIG_NET_RANDOM_ETHADDR is set, we only us
Re: [PATCH] mmc: xenon_sdhci: Add missing common host capabilities
On Fri, 11 Sep 2020 10:37:42 +0200 Andre Heider wrote: > On 11/09/2020 08:43, Stefan Roese wrote: > > Hi Pali, Andre and others, > > > > On 10.09.20 21:04, Pali Rohár wrote: > >> On Thursday 10 September 2020 19:53:40 Andre Heider wrote: > >>> Use mmc_of_parse() to set the common host properties. That > >>> includes "bus-width", so parsing it can be removed from the > >>> driver. > >>> > >>> But more importantly, "non-removable" is now respected, which > >>> fixes the usage of eMMC. > >>> > >>> Signed-off-by: Andre Heider > >>> --- > >> > >> Adding Marek to loop, can you test this patch on MOX A to verify > >> that it does not break MOX uSD and SDIO support? > >> > >> (PS: Andre, for one week I would not be available, therefore in > >> this time I would not be able to test or review Armada 3720 > >> patches...) > > > > I'll also be on vacation next week. Sorry, I was not able to follow > > all discussions on these Armada related patches lately. Could > > someone please summarize, which patches (fixes) are "okay" for > > merging in this rc stage (rc4)? That would really be helpful. > > Going by patchwork we have: > > All superseded: > https://patchwork.ozlabs.org/project/uboot/list/?series=198544 > https://patchwork.ozlabs.org/project/uboot/list/?series=198545 > https://patchwork.ozlabs.org/project/uboot/list/?series=198756 > https://patchwork.ozlabs.org/project/uboot/list/?series=199690 > > From my point of view these can go in: > > This one, fix emmc: > https://patchwork.ozlabs.org/project/uboot/list/?series=200919 I shall check this if it does not break our boards. > dts: fix vendor, add -emmc variant: > https://patchwork.ozlabs.org/project/uboot/list/?series=199579 > > These two for uDPU from its maintainer, taken from the OpenWRT > uboot-mvebu package: > CONFIG_SYS_BOOTM_LEN to 64MB: > https://patchwork.ozlabs.org/project/uboot/list/?series=199858 > add support for Macronix mx25u12835f flash: > https://patchwork.ozlabs.org/project/uboot/list/?series=199857 > > And I'd take these two too, Pali has different opinion though: > enable NET_RANDOM_ETHADDR: > https://patchwork.ozlabs.org/project/uboot/list/?series=200115 > set fdtfile: > https://patchwork.ozlabs.org/project/uboot/list/?series=201051 I have replied to the NET_RANDOM_ETHADDR patch, please comment on my reply. As for the fdtfile I think it is good to go. > Thanks, > Andre
Re: [PATCH] mmc: xenon_sdhci: Add missing common host capabilities
On 11.09.20 14:09, Marek Behún wrote: On Fri, 11 Sep 2020 10:37:42 +0200 Andre Heider wrote: On 11/09/2020 08:43, Stefan Roese wrote: Hi Pali, Andre and others, On 10.09.20 21:04, Pali Rohár wrote: On Thursday 10 September 2020 19:53:40 Andre Heider wrote: Use mmc_of_parse() to set the common host properties. That includes "bus-width", so parsing it can be removed from the driver. But more importantly, "non-removable" is now respected, which fixes the usage of eMMC. Signed-off-by: Andre Heider --- Adding Marek to loop, can you test this patch on MOX A to verify that it does not break MOX uSD and SDIO support? (PS: Andre, for one week I would not be available, therefore in this time I would not be able to test or review Armada 3720 patches...) I'll also be on vacation next week. Sorry, I was not able to follow all discussions on these Armada related patches lately. Could someone please summarize, which patches (fixes) are "okay" for merging in this rc stage (rc4)? That would really be helpful. Going by patchwork we have: All superseded: https://patchwork.ozlabs.org/project/uboot/list/?series=198544 https://patchwork.ozlabs.org/project/uboot/list/?series=198545 https://patchwork.ozlabs.org/project/uboot/list/?series=198756 https://patchwork.ozlabs.org/project/uboot/list/?series=199690 From my point of view these can go in: This one, fix emmc: https://patchwork.ozlabs.org/project/uboot/list/?series=200919 I shall check this if it does not break our boards. dts: fix vendor, add -emmc variant: https://patchwork.ozlabs.org/project/uboot/list/?series=199579 These two for uDPU from its maintainer, taken from the OpenWRT uboot-mvebu package: CONFIG_SYS_BOOTM_LEN to 64MB: https://patchwork.ozlabs.org/project/uboot/list/?series=199858 add support for Macronix mx25u12835f flash: https://patchwork.ozlabs.org/project/uboot/list/?series=199857 And I'd take these two too, Pali has different opinion though: enable NET_RANDOM_ETHADDR: https://patchwork.ozlabs.org/project/uboot/list/?series=200115 set fdtfile: https://patchwork.ozlabs.org/project/uboot/list/?series=201051 I have replied to the NET_RANDOM_ETHADDR patch, please comment on my reply. As for the fdtfile I think it is good to go. Thanks. Unfortunately this is taking a bit too long for me, as I have to leave in about an hour. I will take care of these patches in a bit over a week. Thanks, Stefan
Re: [PATCH] mmc: xenon_sdhci: Add missing common host capabilities
On Fri, 11 Sep 2020 14:21:46 +0200 Stefan Roese wrote: > Thanks. Unfortunately this is taking a bit too long for me, as I > have to leave in about an hour. I will take care of these patches > in a bit over a week. > > Thanks, > Stefan Happy vacation, Stefan :)
Re: [PATCH] mmc: xenon_sdhci: Add missing common host capabilities
On Thu, 10 Sep 2020 19:53:40 +0200
Andre Heider wrote:
> Use mmc_of_parse() to set the common host properties. That includes
> "bus-width", so parsing it can be removed from the driver.
>
> But more importantly, "non-removable" is now respected, which fixes
> the usage of eMMC.
>
> Signed-off-by: Andre Heider
> ---
>
> Tested myself on v5 without emmc, `mmc info` is unchanged for my sd
> card
>
> Tested by Gérald on v7 emmc, which started working with this patch:
> => mmc info
> Device: sdhci@d8000
> Manufacturer ID: 45
> OEM: 100
> Name: SEM04
> Bus Speed: 5200
> Mode: MMC High Speed (52MHz)
> Rd Block Len: 512
> MMC version 4.5
> High Capacity: Yes
> Capacity: 3.7 GiB
> Bus Width: 8-bit
> Erase Group Size: 256 KiB
> HC WP Group Size: 8 MiB
> User Capacity: 3.7 GiB WRREL
> Boot Capacity: 2 MiB
> RPMB Capacity: 2 MiB
> Boot area 0 is not write protected
> Boot area 1 is not write protected
>
> drivers/mmc/xenon_sdhci.c | 18 --
> 1 file changed, 4 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/mmc/xenon_sdhci.c b/drivers/mmc/xenon_sdhci.c
> index 7f9a579c83..6ce9d00d0a 100644
> --- a/drivers/mmc/xenon_sdhci.c
> +++ b/drivers/mmc/xenon_sdhci.c
> @@ -485,20 +485,10 @@ static int xenon_sdhci_probe(struct udevice
> *dev) armada_3700_soc_pad_voltage_set(host);
>
> host->host_caps = MMC_MODE_HS | MMC_MODE_HS_52MHz |
> MMC_MODE_DDR_52MHz;
> - switch (fdtdec_get_int(gd->fdt_blob, dev_of_offset(dev),
> "bus-width",
> - 1)) {
> - case 8:
> - host->host_caps |= MMC_MODE_8BIT;
> - break;
> - case 4:
> - host->host_caps |= MMC_MODE_4BIT;
> - break;
> - case 1:
> - break;
> - default:
> - printf("Invalid \"bus-width\" value\n");
> - return -EINVAL;
> - }
> +
> + ret = mmc_of_parse(dev, &plat->cfg);
> + if (ret)
> + return ret;
>
> host->ops = &xenon_sdhci_ops;
>
Tested-by: Marek Behún
Re: [PATCH] riscv: Only enable OF_BOARD_FIXUP for S-Mode
On Fri, Sep 11, 2020 at 6:20 PM Sean Anderson wrote:
>
> On 9/11/20 3:29 AM, Bin Meng wrote:
> > Hi Sean,
> >
> > On Sat, Sep 5, 2020 at 9:22 PM Sean Anderson wrote:
> >>
> >> It is unsafe to enable OF_BOARD_FIXUP only based on OF_SEPARATE.
> >> OF_SEPARATE may indicate that the user wishes U-Boot to use a different
> >> device tree than one obtained via OF_PRIOR_STAGE. However, OF_SEPARATE may
> >> also indicate that the device tree which would be obtained via
> >> OF_PRIOR_STAGE is invalid, nonexistant, or otherwise unusable. In this
> >
> > typo: nonexistent
> >
> >> latter case, enabling OF_BOARD_FIXUP will result in corruption of the
> >> device tree. To remedy this, only enable OF_BOARD_FIXUP if U-Boot is
> >> configured for S-Mode.
> >>
> >> Fixes: 1c17e55594a394ced7de88d91be294eaf8c564c1
> >
> > nits: the format should be: commit_id ("description")>
> >> Signed-off-by: Sean Anderson
> >> ---
> >>
> >> arch/riscv/Kconfig | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> >> index 009a545fcf..13fac51483 100644
> >> --- a/arch/riscv/Kconfig
> >> +++ b/arch/riscv/Kconfig
> >> @@ -288,6 +288,6 @@ config STACK_SIZE_SHIFT
> >> default 14
> >>
> >> config OF_BOARD_FIXUP
> >> - default y if OF_SEPARATE
> >> + default y if OF_SEPARATE && RISCV_SMODE
> >
> > Is that your board is running U-Boot M-mode with OF_SEPARATE that does not
> > work?
>
> Yes, because the reason we use OF_SEPARATE is because no device tree is
> passed to U-Boot. Trying to use the device tree passed to U-Boot even
I don't get it. If no device tree is passed to U-Boot, why using
OF_SEPARATE in the first place?
> though OF_SEPARATE is enabled results in garbage being written to the
What garbage data is written?
> actual device tree. Without this patch, booting on the K210 randomly
> fails.
Regards,
Bin
Re: [PATCH 1/7] Revert "riscv: Clear pending interrupts before enabling IPIs"
On Fri, Sep 11, 2020 at 6:22 PM Sean Anderson wrote: > > On 9/11/20 3:38 AM, Bin Meng wrote: > > Hi Sean, > > > > On Tue, Sep 8, 2020 at 2:17 AM Sean Anderson wrote: > >> > >> Clearing MIP doesn't do anything. Whoops. The following commits should > > > > Which following commits? > > > >> tackle this problem in a more robust manner. > >> > >> This reverts commit 9472630337e7c4ac442066b5a752aaa8c3b4d4a6. > >> > >> Signed-off-by: Sean Anderson > >> --- > >> > >> arch/riscv/cpu/start.S | 2 -- > >> 1 file changed, 2 deletions(-) > >> > >> diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S > >> index bf9fdf369b..e3222b1ea7 100644 > >> --- a/arch/riscv/cpu/start.S > >> +++ b/arch/riscv/cpu/start.S > >> @@ -65,8 +65,6 @@ _start: > >> #else > >> li t0, SIE_SSIE > >> #endif > >> - /* Clear any pending IPIs */ > >> - csrcMODE_PREFIX(ip), t0 > > > > Did you mean the clearing MIP.MSIP actually does nothing, but the > > following commit is the correct fix? > > Yes, but we also need Is MIP.MSIP read-only on K210? > > [PATCH 3/7] riscv: Use NULL as a sentinel value for smp_call_function > > so the secondary harts know not to take any IPIs not raised by U-Boot. > > > > > commit 40686c394e533fec765fe237936e353c84e73fff > > Author: Sean Anderson > > Date: Wed Jun 24 06:41:18 2020 -0400 > > > > riscv: Clean up IPI initialization code > > > > The previous IPI code initialized the device whenever the first call was > > made to a riscv_*_ipi function. This made it difficult to determine when > > the IPI device was initialized. This patch introduces a new function > > riscv_init_ipi. It is called once during arch_cpu_init_dm. In SPL, it is > > called in spl_invoke_opensbi. Before this point, no riscv_*_ipi > > functions > > should be called. > > > > Signed-off-by: Sean Anderson > > Reviewed-by: Rick Chen > > > >> csrsMODE_PREFIX(ie), t0 > >> #endif Regards, Bin
Re: [PATCH 5/7] riscv: Add fence to available_harts_lock
On Tue, Sep 8, 2020 at 2:17 AM Sean Anderson wrote: > > Without these fences, it is perfectly valid for an out-of-order core to > re-order memory accesses to outside of the available_harts_lock critical > section. The commit message should be reworded, because current codes do nothing wrong as "fence" instruction is used. What was done in this patch is using .aq / .rl to replace "fence". > > Signed-off-by: Sean Anderson > --- > > arch/riscv/cpu/start.S | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > Regards, Bin
[PATCH] x86: fsp: Replace e-mmc with emmc in devicetree bindings
The term eMMC is used inconsistently within the FSP devicetree
bindigs (e-mmc and emmc), especially for "emmc-host-max-speed"
documentation and code disagree.
Change all eMMC instances within the FSP bindings to consistently
use "emmc". The term "emmc" is already used a lot within U-Boot,
while "e-mmc" is only used in the FSP bindings.
Signed-off-by: Wolfgang Wallner
---
arch/x86/cpu/apollolake/fsp_bindings.c | 6 +++---
doc/device-tree-bindings/fsp/fsp2/apollolake/fsp-m.txt | 2 +-
doc/device-tree-bindings/fsp/fsp2/apollolake/fsp-s.txt | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/x86/cpu/apollolake/fsp_bindings.c
b/arch/x86/cpu/apollolake/fsp_bindings.c
index bbf04b5009..319c78b95a 100644
--- a/arch/x86/cpu/apollolake/fsp_bindings.c
+++ b/arch/x86/cpu/apollolake/fsp_bindings.c
@@ -555,7 +555,7 @@ const struct fsp_binding fsp_m_bindings[] = {
}, {
.type = FSP_UINT8,
.offset = offsetof(struct fsp_m_config, e_mmc_trace_len),
- .propname = "fspm,e-mmc-trace-len",
+ .propname = "fspm,emmc-trace-len",
}, {
.type = FSP_UINT8,
.offset = offsetof(struct fsp_m_config, skip_cse_rbp),
@@ -1465,11 +1465,11 @@ const struct fsp_binding fsp_s_bindings[] = {
}, {
.type = FSP_UINT8,
.offset = offsetof(struct fsp_s_config, e_mmc_enabled),
- .propname = "fsps,e-mmc-enabled",
+ .propname = "fsps,emmc-enabled",
}, {
.type = FSP_UINT8,
.offset = offsetof(struct fsp_s_config, e_mmc_host_max_speed),
- .propname = "fsps,e-mmc-host-max-speed",
+ .propname = "fsps,emmc-host-max-speed",
}, {
.type = FSP_UINT8,
.offset = offsetof(struct fsp_s_config, ufs_enabled),
diff --git a/doc/device-tree-bindings/fsp/fsp2/apollolake/fsp-m.txt
b/doc/device-tree-bindings/fsp/fsp2/apollolake/fsp-m.txt
index 666400e085..36936f2eb6 100644
--- a/doc/device-tree-bindings/fsp/fsp2/apollolake/fsp-m.txt
+++ b/doc/device-tree-bindings/fsp/fsp2/apollolake/fsp-m.txt
@@ -174,7 +174,7 @@ Optional properties:
- fspm,oem-loading-base: OEM File Loading Address
- fspm,oem-file-name: OEM File Name to Load
- fspm,mrc-boot-data-ptr:
-- fspm,e-mmc-trace-len: eMMC Trace Length
+- fspm,emmc-trace-len: eMMC Trace Length
0x0: Long
0x1: Short
- fspm,skip-cse-rbp: Skip CSE RBP to support zero sized IBB
diff --git a/doc/device-tree-bindings/fsp/fsp2/apollolake/fsp-s.txt
b/doc/device-tree-bindings/fsp/fsp2/apollolake/fsp-s.txt
index 731a310cf8..b605ed0056 100644
--- a/doc/device-tree-bindings/fsp/fsp2/apollolake/fsp-s.txt
+++ b/doc/device-tree-bindings/fsp/fsp2/apollolake/fsp-s.txt
@@ -318,7 +318,7 @@ Optional properties:
0x6: warm reset (default)
0xE: cold reset
- fsps,sdcard-enabled: SD Card Support (D27:F0)
-- fsps,e-mmc-enabled: SeMMC Support (D28:F0)
+- fsps,emmc-enabled: SeMMC Support (D28:F0)
- fsps,emmc-host-max-speed: eMMC Max Speed
0: HS400(default)
1: HS200
--
2.28.0
[PATCH] dm: arm: bcmstb: Enable driver model for Ethernet drivers
Eliminate the Driver Model migration warning for the bcm7260 and bcm7445 ports (though neither port has Ethernet support yet). Signed-off-by: Thomas Fitzsimmons --- configs/bcm7260_defconfig | 1 + configs/bcm7445_defconfig | 1 + 2 files changed, 2 insertions(+) diff --git a/configs/bcm7260_defconfig b/configs/bcm7260_defconfig index f25659db48..47157f04eb 100644 --- a/configs/bcm7260_defconfig +++ b/configs/bcm7260_defconfig @@ -31,4 +31,5 @@ CONFIG_DM_MMC=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_BCMSTB=y CONFIG_MTD=y +CONFIG_DM_ETH=y # CONFIG_EFI_LOADER is not set diff --git a/configs/bcm7445_defconfig b/configs/bcm7445_defconfig index 18d31048ff..0f80e309ab 100644 --- a/configs/bcm7445_defconfig +++ b/configs/bcm7445_defconfig @@ -33,6 +33,7 @@ CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_BCMSTB=y CONFIG_MTD=y CONFIG_DM_SPI_FLASH=y +CONFIG_DM_ETH=y CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_BCMSTB_SPI=y -- 2.26.0.rc2
Re: [PATCH] defconfig: espressobin: enable NET_RANDOM_ETHADDR
Hi Marek, On 11/09/2020 13:55, Marek Behún wrote: On Wed, 9 Sep 2020 00:38:31 +0200 Pali Rohár wrote: On Tuesday 08 September 2020 08:52:56 Tom Rini wrote: Note that when CONFIG_NET_RANDOM_ETHADDR is set, we only use a random MAC address when we haven't found one either on the hardware or environment. I know. It also prints a warning that you are using a random MAC, so if it's documented on how to recover the real MAC a user should see that warning and fix it. In case you did backup of MAC address or you have MAC address printed on sticker, you can restore it. If you loaded distribution U-Boot which erase MAC address and you have not did any backup, then your MAC address is forever lost. On Turris MOX we write the MAC address into OTP of the SOC during manufacturing. It is possible to write code that burns the MAC address into OTP, I consider this a better option than enabling random MAC address. Maybe we can enable random MAC address, and if MAC address is not found in environment nor OTP, issue a warning, something like "WARNING: MAC address lost, please burn the MAC address of your device to OTP with command xyz" What do you think? if there's a mac stored in otp during manufacturing, that's of course the best solution. There's no need for CONFIG_NET_RANDOM_ETHADDR then. But globalscale does not do that. Doing it afterwards, so u-boot claiming some otp space for itself, and instructing the user how to write to it sounds too dangerous/error-prone. For me CONFIG_NET_RANDOM_ETHADDR is a knob that should be enabled if there's no mac address stored in a sane way (where saving it just to an u-boot env during manufacturing doesn't count as sane, especially if the vendor moves the spi env offset around in a firmware update). So I think CONFIG_NET_RANDOM_ETHADDR is enough. But it would be nice if e.g. a board could set specific env vars as indestructible/unwipeable/precious/whatever, which instructs `env default -a` to keep those (which is common after updating the bootloader). Maybe that's an idea worth pursuing? Thanks, Andre
Re: [PATCH] mmc: xenon_sdhci: Add missing common host capabilities
On 11/09/2020 14:21, Stefan Roese wrote: On 11.09.20 14:09, Marek Behún wrote: On Fri, 11 Sep 2020 10:37:42 +0200 Andre Heider wrote: On 11/09/2020 08:43, Stefan Roese wrote: Hi Pali, Andre and others, On 10.09.20 21:04, Pali Rohár wrote: On Thursday 10 September 2020 19:53:40 Andre Heider wrote: Use mmc_of_parse() to set the common host properties. That includes "bus-width", so parsing it can be removed from the driver. But more importantly, "non-removable" is now respected, which fixes the usage of eMMC. Signed-off-by: Andre Heider --- Adding Marek to loop, can you test this patch on MOX A to verify that it does not break MOX uSD and SDIO support? (PS: Andre, for one week I would not be available, therefore in this time I would not be able to test or review Armada 3720 patches...) I'll also be on vacation next week. Sorry, I was not able to follow all discussions on these Armada related patches lately. Could someone please summarize, which patches (fixes) are "okay" for merging in this rc stage (rc4)? That would really be helpful. Going by patchwork we have: All superseded: https://patchwork.ozlabs.org/project/uboot/list/?series=198544 https://patchwork.ozlabs.org/project/uboot/list/?series=198545 https://patchwork.ozlabs.org/project/uboot/list/?series=198756 https://patchwork.ozlabs.org/project/uboot/list/?series=199690 From my point of view these can go in: This one, fix emmc: https://patchwork.ozlabs.org/project/uboot/list/?series=200919 I shall check this if it does not break our boards. dts: fix vendor, add -emmc variant: https://patchwork.ozlabs.org/project/uboot/list/?series=199579 These two for uDPU from its maintainer, taken from the OpenWRT uboot-mvebu package: CONFIG_SYS_BOOTM_LEN to 64MB: https://patchwork.ozlabs.org/project/uboot/list/?series=199858 add support for Macronix mx25u12835f flash: https://patchwork.ozlabs.org/project/uboot/list/?series=199857 And I'd take these two too, Pali has different opinion though: enable NET_RANDOM_ETHADDR: https://patchwork.ozlabs.org/project/uboot/list/?series=200115 set fdtfile: https://patchwork.ozlabs.org/project/uboot/list/?series=201051 I have replied to the NET_RANDOM_ETHADDR patch, please comment on my reply. As for the fdtfile I think it is good to go. Thanks. Unfortunately this is taking a bit too long for me, as I have to leave in about an hour. I will take care of these patches in a bit over a week. Sounds good, thanks! Have a nice vacation, Andre
Re: [PATCH 00/16] Kconfig: Tidy up the top-level kconfig menu
On Thu, Sep 10, 2020 at 08:21:11PM -0600, Simon Glass wrote: > > At present this menu is pretty messy, with quite a few minor options shown > at the top level. This series creates a few new menus and moves things > around so that the top-level menu is cleaner. > > There is more to do, but this is a start. [snip] > Kconfig | 340 +--- > cmd/Kconfig | 117 -- > common/Kconfig | 505 ++-- > common/Kconfig.boot | 894 +++ > drivers/core/Kconfig | 11 + > dts/Kconfig | 9 - > env/Kconfig | 9 + > tools/Kconfig| 12 + > 8 files changed, 955 insertions(+), 942 deletions(-) > create mode 100644 common/Kconfig.boot > create mode 100644 tools/Kconfig And after a resync of the defconfigs: 555 files changed, 941 insertions(+), 941 deletions(-) and a partial wc -l: 449 Kconfig 697 common/Kconfig 894 common/Kconfig.boot 2190 cmd/Kconfig So in the end, yes, this is I think making things easier to maintain but will cause a few merge hiccups. -- Tom signature.asc Description: PGP signature
[PATCH v3 1/2] net: add a generic udp protocol
This commit adds a generic udp protocol framework in the
network loop. So protocol based on udp may be implemented
without modifying the network loop (for example custom
wait magic packet).
Signed-off-by: Philippe Reynes
Reviewed-by: Simon Glass
---
Changelog:
v3:
- add file doc/README.udp
- add more comments on function udp_loop
- fix sentence in Kconfig
- use if (IS_ENABLE(...)) when it is possible
- avoid checking null pointer twice
v2:
- no change
doc/README.udp| 35 +++
include/net.h | 2 +-
include/net/udp.h | 41 +
net/Kconfig | 6 ++
net/Makefile | 1 +
net/net.c | 13 -
net/udp.c | 46 ++
7 files changed, 142 insertions(+), 2 deletions(-)
create mode 100644 doc/README.udp
create mode 100644 include/net/udp.h
create mode 100644 net/udp.c
diff --git a/doc/README.udp b/doc/README.udp
new file mode 100644
index 000..da07257
--- /dev/null
+++ b/doc/README.udp
@@ -0,0 +1,35 @@
+Udp framework
+
+The udp framework is build on top of network framework and is designed
+to define new protocol or new command based on udp without modifying
+the network framework.
+
+The udp framework define a function udp_loop that take as argument
+a structure udp_ops (defined in include/net/udp.h) :
+
+struct udp_ops {
+ int (*prereq)(void *data);
+ int (*start)(void *data);
+ void *data;
+};
+
+The callback prereq define if all the requirements are
+valid before running the network/udp loop.
+
+The callback start define the first step in the network/udp loop,
+and it may also be used to configure a timemout and udp handler.
+
+The pointer data is used to store private data that
+could be used by both callback.
+
+A simple example to use this framework:
+
+static struct udp_ops udp_ops = {
+ .prereq = wmp_prereq,
+ .start = wmp_start,
+ .data = NULL,
+};
+
+...
+
+err = udp_loop(&udp_ops);
diff --git a/include/net.h b/include/net.h
index 1bf9867..2191071 100644
--- a/include/net.h
+++ b/include/net.h
@@ -551,7 +551,7 @@ extern int net_restart_wrap; /* Tried all
network devices */
enum proto_t {
BOOTP, RARP, ARP, TFTPGET, DHCP, PING, DNS, NFS, CDP, NETCONS, SNTP,
- TFTPSRV, TFTPPUT, LINKLOCAL, FASTBOOT, WOL
+ TFTPSRV, TFTPPUT, LINKLOCAL, FASTBOOT, WOL, UDP
};
extern charnet_boot_file_name[1024];/* Boot File name */
diff --git a/include/net/udp.h b/include/net/udp.h
new file mode 100644
index 000..2ae56e8
--- /dev/null
+++ b/include/net/udp.h
@@ -0,0 +1,41 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2020 Philippe Reynes
+ */
+
+#ifndef __UDP
+#define __UDP
+
+/**
+ * struct udp_ops - function to handle udp packet
+ *
+ * This structure provides the function to handle udp packet in
+ * the network loop.
+ *
+ * @prereq: callback called to check the requirement
+ * @start: callback called to start the protocol/feature
+ * @data: pointer to store private data (used by prereq and start)
+ */
+struct udp_ops {
+ int (*prereq)(void *data);
+ int (*start)(void *data);
+ void *data;
+};
+
+int udp_prereq(void);
+
+int udp_start(void);
+
+/**
+ * udp_loop() - network loop for udp protocol
+ *
+ * Launch a network loop for udp protocol and use callbacks
+ * provided in parameter @ops to initialize the loop, and then
+ * to handle udp packet.
+ *
+ * @ops: udp callback
+ * @return: 0 if success, otherwise < 0 on error
+ */
+int udp_loop(struct udp_ops *ops);
+
+#endif
diff --git a/net/Kconfig b/net/Kconfig
index 6874b55..1b3e420 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -8,6 +8,12 @@ menuconfig NET
if NET
+config PROT_UDP
+ bool "Enable generic udp framework"
+ help
+ Enable a generic udp framework that allows defining a custom
+ handler for udp protocol.
+
config BOOTP_SEND_HOSTNAME
bool "Send hostname to DNS server"
help
diff --git a/net/Makefile b/net/Makefile
index fef71b9..76527f7 100644
--- a/net/Makefile
+++ b/net/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_CMD_SNTP) += sntp.o
obj-$(CONFIG_CMD_TFTPBOOT) += tftp.o
obj-$(CONFIG_UDP_FUNCTION_FASTBOOT) += fastboot.o
obj-$(CONFIG_CMD_WOL) += wol.o
+obj-$(CONFIG_PROT_UDP) += udp.o
# Disable this warning as it is triggered by:
# sprintf(buf, index ? "foo%d" : "foo", index)
diff --git a/net/net.c b/net/net.c
index 28d9eeb..1ce0eb5 100644
--- a/net/net.c
+++ b/net/net.c
@@ -102,6 +102,7 @@
#if defined(CONFIG_CMD_PCAP)
#include
#endif
+#include
#if defined(CONFIG_LED_STATUS)
#include
#include
@@ -544,6 +545,9 @@ restart:
break;
}
+ if (IS_ENABLED(CONFIG_PROT_UDP) && protocol == UDP)
+ udp_start();
+
break;
}
@@ -1364,6 +1368,13 @@ static int net_check_prereq(enum proto_t protocol)
}
[PATCH v3 2/2] sandbox: enable support of generic udp protocol
This commit enable the support of the generic udp protocol. Signed-off-by: Philippe Reynes Reviewed-by: Simon Glass --- Changelog: v3: - no change v2: - new patch in the serie configs/sandbox_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig index 6e9f029..5ceff7d 100644 --- a/configs/sandbox_defconfig +++ b/configs/sandbox_defconfig @@ -102,6 +102,7 @@ CONFIG_ENV_IS_NOWHERE=y CONFIG_ENV_IS_IN_EXT4=y CONFIG_ENV_EXT4_INTERFACE="host" CONFIG_ENV_EXT4_DEVICE_AND_PART="0:0" +CONFIG_PROT_UDP=y CONFIG_BOOTP_SEND_HOSTNAME=y CONFIG_NETCONSOLE=y CONFIG_IP_DEFRAG=y -- 2.7.4
Re: [PATCH] defconfig: espressobin: enable NET_RANDOM_ETHADDR
On Fri, 11 Sep 2020 17:52:26 +0200 Andre Heider wrote: > Hi Marek, > > On 11/09/2020 13:55, Marek Behún wrote: > > On Wed, 9 Sep 2020 00:38:31 +0200 Pali Rohár > > wrote: > >> On Tuesday 08 September 2020 08:52:56 Tom Rini wrote: > >>> Note that when CONFIG_NET_RANDOM_ETHADDR is set, we only use a > >>> random MAC address when we haven't found one either on the > >>> hardware or environment. > >> > >> I know. > >> > >>> It also prints a warning that you are using a random MAC, > >>> so if it's documented on how to recover the real MAC a user should > >>> see that warning and fix it. > >> > >> In case you did backup of MAC address or you have MAC address > >> printed on sticker, you can restore it. If you loaded distribution > >> U-Boot which erase MAC address and you have not did any backup, > >> then your MAC address is forever lost. > > > > On Turris MOX we write the MAC address into OTP of the SOC during > > manufacturing. > > > > It is possible to write code that burns the MAC address into OTP, I > > consider this a better option than enabling random MAC address. > > > > Maybe we can enable random MAC address, and if MAC address is not > > found in environment nor OTP, issue a warning, something like > >"WARNING: MAC address lost, please burn the MAC address of your > > device to OTP with command xyz" > > > > What do you think? > > if there's a mac stored in otp during manufacturing, that's of course > the best solution. There's no need for CONFIG_NET_RANDOM_ETHADDR > then. But globalscale does not do that. > > Doing it afterwards, so u-boot claiming some otp space for itself, > and instructing the user how to write to it sounds too > dangerous/error-prone. > > For me CONFIG_NET_RANDOM_ETHADDR is a knob that should be enabled if > there's no mac address stored in a sane way (where saving it just to > an u-boot env during manufacturing doesn't count as sane, especially > if the vendor moves the spi env offset around in a firmware update). > > So I think CONFIG_NET_RANDOM_ETHADDR is enough. > I understand Pali's concerns, though. The thing is that if we enable CONFIG_NET_RANDOM_ETHADDR by default, many users that have managed to wipe their env won't care about that they are using randomly generated MAC address and won't solve the issue, which is again the spirit of correctly configure networks. If we do not enable CONFIG_NET_RANDOM_ETHADDR, the worst that can happen is that the device won't boot from network. This will force the users to solve the issue, which is not that hard setenv ethaddr aa:bb:cc:dd:ee:ff (address from the sticker) saveenv If the users boots from SD/eMMC/SATA/USB, Linux won't have problem with network, since it will generate random MAC address anyway. The worst case scenario does not look that bad to me if we don't enable CONFIG_NET_RANDOM_ETHADDR by default. I think the option CONFIG_NET_RANDOM_ETHADDR should be used only by developers when they are developing on devices that have not yet burned the MAC addresses, or on some embedded devices that don't have space for saving a MAC address (no storage for env or anything else, do such devices exist?). But it shouldn't be used as a default setting for a device that has storage where it can store the address. > But it would be nice if e.g. a board could set specific env vars as > indestructible/unwipeable/precious/whatever, which instructs `env > default -a` to keep those (which is common after updating the > bootloader). Maybe that's an idea worth pursuing? > Yes, that would be nice :) > Thanks, > Andre Marek
Re: [PATCH] defconfig: espressobin: enable NET_RANDOM_ETHADDR
On 11/09/2020 18:22, Marek Behún wrote: On Fri, 11 Sep 2020 17:52:26 +0200 Andre Heider wrote: Hi Marek, On 11/09/2020 13:55, Marek Behún wrote: On Wed, 9 Sep 2020 00:38:31 +0200 Pali Rohár wrote: On Tuesday 08 September 2020 08:52:56 Tom Rini wrote: Note that when CONFIG_NET_RANDOM_ETHADDR is set, we only use a random MAC address when we haven't found one either on the hardware or environment. I know. It also prints a warning that you are using a random MAC, so if it's documented on how to recover the real MAC a user should see that warning and fix it. In case you did backup of MAC address or you have MAC address printed on sticker, you can restore it. If you loaded distribution U-Boot which erase MAC address and you have not did any backup, then your MAC address is forever lost. On Turris MOX we write the MAC address into OTP of the SOC during manufacturing. It is possible to write code that burns the MAC address into OTP, I consider this a better option than enabling random MAC address. Maybe we can enable random MAC address, and if MAC address is not found in environment nor OTP, issue a warning, something like "WARNING: MAC address lost, please burn the MAC address of your device to OTP with command xyz" What do you think? if there's a mac stored in otp during manufacturing, that's of course the best solution. There's no need for CONFIG_NET_RANDOM_ETHADDR then. But globalscale does not do that. Doing it afterwards, so u-boot claiming some otp space for itself, and instructing the user how to write to it sounds too dangerous/error-prone. For me CONFIG_NET_RANDOM_ETHADDR is a knob that should be enabled if there's no mac address stored in a sane way (where saving it just to an u-boot env during manufacturing doesn't count as sane, especially if the vendor moves the spi env offset around in a firmware update). So I think CONFIG_NET_RANDOM_ETHADDR is enough. I understand Pali's concerns, though. The thing is that if we enable CONFIG_NET_RANDOM_ETHADDR by default, many users that have managed to wipe their env won't care about that they are using randomly generated MAC address and won't solve the issue, which is again the spirit of correctly configure networks. If we do not enable CONFIG_NET_RANDOM_ETHADDR, the worst that can happen is that the device won't boot from network. This will force the users to solve the issue, which is not that hard setenv ethaddr aa:bb:cc:dd:ee:ff (address from the sticker) saveenv If the users boots from SD/eMMC/SATA/USB, Linux won't have problem with network, since it will generate random MAC address anyway. Good point, so let's assume the user doesn't have a mac stored. Without CONFIG_NET_RANDOM_ETHADDR: * u-boot refuses to do anything network related * Linux generates a random mac, network works With CONFIG_NET_RANDOM_ETHADDR: * u-boot generates a random mac, network works * Linux uses the same random mac, passed on from u-boot throught the device-tree, network works It's still random, but at least it's consistent ;) The worst case scenario does not look that bad to me if we don't enable CONFIG_NET_RANDOM_ETHADDR by default. I think the option CONFIG_NET_RANDOM_ETHADDR should be used only by developers when they are developing on devices that have not yet burned the MAC addresses, or on some embedded devices that don't have space for saving a MAC address (no storage for env or anything else, do such devices exist?). It looks like it's used for more than that though: $ git ls-files configs|wc -l 1362 $ git grep CONFIG_NET_RANDOM_ETHADDR configs|wc -l 209 Some popular sbc's are part of that list. But it shouldn't be used as a default setting for a device that has storage where it can store the address. But it would be nice if e.g. a board could set specific env vars as indestructible/unwipeable/precious/whatever, which instructs `env default -a` to keep those (which is common after updating the bootloader). Maybe that's an idea worth pursuing? Yes, that would be nice :) Thanks, Andre Marek
[PATCH v2] ARM: Distro boot: document the need for fdtfile variable to be set
From: Dennis Gilmore
When testing builds provided in https://github.com/openwrt/openwrt/pull/3360
I discovered that fdtfile was not set and as a result the firmware was not
functional. So I am documenting what is needed.
Signed-off-by: Dennis Gilmore
Cc: Atish Patra
Cc: Lukas Auer
Cc: Tom Rini
Cc: Masahiro Yamada
Cc: Vagrant Cascadian
Cc: Stephen Warren
Cc: Karsten Merker
---
doc/README.distro | 11 +++
1 file changed, 11 insertions(+)
diff --git a/doc/README.distro b/doc/README.distro
index 5076bebd18..cc1c41ecb3 100644
--- a/doc/README.distro
+++ b/doc/README.distro
@@ -224,6 +224,17 @@ fdt_addr_r:
A size of 1MB for the FDT/DTB seems reasonable.
+fdtfile:
+
+ Mandatory. the name of the DTB file for the specific board for instance
+ the espressobin v5 board the value is "marvell/armada-3720-espressobin.dtb"
+ while on a clearfog pro it is "armada-388-clearfog-pro.dtb" in the case of
+ a board providing its firmware based DTB this value can be used to override
+ the DTB with a different DTB. fdtfile will automatically be set for you if
+ it matches the format ${soc}-${board}.dtb which covers most 32 bit use cases.
+ AArch64 generally does not match as the Linux kernel put the dtb files under
+ SoC vendor directories.
+
ramdisk_addr_r:
Mandatory. The location in RAM where the initial ramdisk will be loaded to
--
2.28.0
Re: [PATCH] defconfig: espressobin: enable NET_RANDOM_ETHADDR
On Fri, Sep 11, 2020 at 06:47:02PM +0200, Andre Heider wrote: > On 11/09/2020 18:22, Marek Behún wrote: > > On Fri, 11 Sep 2020 17:52:26 +0200 > > Andre Heider wrote: > > > > > Hi Marek, > > > > > > On 11/09/2020 13:55, Marek Behún wrote: > > > > On Wed, 9 Sep 2020 00:38:31 +0200 Pali Rohár > > > > wrote: > > > > > On Tuesday 08 September 2020 08:52:56 Tom Rini wrote: > > > > > > Note that when CONFIG_NET_RANDOM_ETHADDR is set, we only use a > > > > > > random MAC address when we haven't found one either on the > > > > > > hardware or environment. > > > > > > > > > > I know. > > > > > > It also prints a warning that you are using a random MAC, > > > > > > so if it's documented on how to recover the real MAC a user should > > > > > > see that warning and fix it. > > > > > > > > > > In case you did backup of MAC address or you have MAC address > > > > > printed on sticker, you can restore it. If you loaded distribution > > > > > U-Boot which erase MAC address and you have not did any backup, > > > > > then your MAC address is forever lost. > > > > > > > > On Turris MOX we write the MAC address into OTP of the SOC during > > > > manufacturing. > > > > > > > > It is possible to write code that burns the MAC address into OTP, I > > > > consider this a better option than enabling random MAC address. > > > > > > > > Maybe we can enable random MAC address, and if MAC address is not > > > > found in environment nor OTP, issue a warning, something like > > > > "WARNING: MAC address lost, please burn the MAC address of your > > > > device to OTP with command xyz" > > > > > > > > What do you think? > > > > > > if there's a mac stored in otp during manufacturing, that's of course > > > the best solution. There's no need for CONFIG_NET_RANDOM_ETHADDR > > > then. But globalscale does not do that. > > > > > > Doing it afterwards, so u-boot claiming some otp space for itself, > > > and instructing the user how to write to it sounds too > > > dangerous/error-prone. > > > > > > For me CONFIG_NET_RANDOM_ETHADDR is a knob that should be enabled if > > > there's no mac address stored in a sane way (where saving it just to > > > an u-boot env during manufacturing doesn't count as sane, especially > > > if the vendor moves the spi env offset around in a firmware update). > > > > > > So I think CONFIG_NET_RANDOM_ETHADDR is enough. > > > > > > > I understand Pali's concerns, though. > > > > The thing is that if we enable CONFIG_NET_RANDOM_ETHADDR by default, > > many users that have managed to wipe their env won't care about that > > they are using randomly generated MAC address and won't solve the issue, > > which is again the spirit of correctly configure networks. > > > > If we do not enable CONFIG_NET_RANDOM_ETHADDR, the worst that can > > happen is that the device won't boot from network. This will force the > > users to solve the issue, which is not that hard > >setenv ethaddr aa:bb:cc:dd:ee:ff (address from the sticker) > >saveenv > > If the users boots from SD/eMMC/SATA/USB, Linux won't have problem with > > network, since it will generate random MAC address anyway. > > Good point, so let's assume the user doesn't have a mac stored. > > Without CONFIG_NET_RANDOM_ETHADDR: > * u-boot refuses to do anything network related > * Linux generates a random mac, network works > > With CONFIG_NET_RANDOM_ETHADDR: > * u-boot generates a random mac, network works > * Linux uses the same random mac, passed on from u-boot throught the > device-tree, network works > > It's still random, but at least it's consistent ;) It's also only used when we cannot find the MAC. At the end of the day, the final decision here is Konstantin's (as the listed maintainer). I personally think enabling the option is good given the apparent number of ways the real MAC will have been lost from SW, but if the maintainer wants to instead opt for a verbose failure message, that's fine too. -- Tom signature.asc Description: PGP signature
Re: [PATCH] defconfig: espressobin: enable NET_RANDOM_ETHADDR
I agree with Tom here, I have a few different systems that use this feature, it is useful. I think most if not all of the systems I have using it have Marvell SoC's Dennis On Fri, Sep 11, 2020 at 12:11 PM Tom Rini wrote: > > On Fri, Sep 11, 2020 at 06:47:02PM +0200, Andre Heider wrote: > > On 11/09/2020 18:22, Marek Behún wrote: > > > On Fri, 11 Sep 2020 17:52:26 +0200 > > > Andre Heider wrote: > > > > > > > Hi Marek, > > > > > > > > On 11/09/2020 13:55, Marek Behún wrote: > > > > > On Wed, 9 Sep 2020 00:38:31 +0200 Pali Rohár > > > > > wrote: > > > > > > On Tuesday 08 September 2020 08:52:56 Tom Rini wrote: > > > > > > > Note that when CONFIG_NET_RANDOM_ETHADDR is set, we only use a > > > > > > > random MAC address when we haven't found one either on the > > > > > > > hardware or environment. > > > > > > > > > > > > I know. > > > > > > > It also prints a warning that you are using a random MAC, > > > > > > > so if it's documented on how to recover the real MAC a user should > > > > > > > see that warning and fix it. > > > > > > > > > > > > In case you did backup of MAC address or you have MAC address > > > > > > printed on sticker, you can restore it. If you loaded distribution > > > > > > U-Boot which erase MAC address and you have not did any backup, > > > > > > then your MAC address is forever lost. > > > > > > > > > > On Turris MOX we write the MAC address into OTP of the SOC during > > > > > manufacturing. > > > > > > > > > > It is possible to write code that burns the MAC address into OTP, I > > > > > consider this a better option than enabling random MAC address. > > > > > > > > > > Maybe we can enable random MAC address, and if MAC address is not > > > > > found in environment nor OTP, issue a warning, something like > > > > > "WARNING: MAC address lost, please burn the MAC address of your > > > > > device to OTP with command xyz" > > > > > > > > > > What do you think? > > > > > > > > if there's a mac stored in otp during manufacturing, that's of course > > > > the best solution. There's no need for CONFIG_NET_RANDOM_ETHADDR > > > > then. But globalscale does not do that. > > > > > > > > Doing it afterwards, so u-boot claiming some otp space for itself, > > > > and instructing the user how to write to it sounds too > > > > dangerous/error-prone. > > > > > > > > For me CONFIG_NET_RANDOM_ETHADDR is a knob that should be enabled if > > > > there's no mac address stored in a sane way (where saving it just to > > > > an u-boot env during manufacturing doesn't count as sane, especially > > > > if the vendor moves the spi env offset around in a firmware update). > > > > > > > > So I think CONFIG_NET_RANDOM_ETHADDR is enough. > > > > > > > > > > I understand Pali's concerns, though. > > > > > > The thing is that if we enable CONFIG_NET_RANDOM_ETHADDR by default, > > > many users that have managed to wipe their env won't care about that > > > they are using randomly generated MAC address and won't solve the issue, > > > which is again the spirit of correctly configure networks. > > > > > > If we do not enable CONFIG_NET_RANDOM_ETHADDR, the worst that can > > > happen is that the device won't boot from network. This will force the > > > users to solve the issue, which is not that hard > > >setenv ethaddr aa:bb:cc:dd:ee:ff (address from the sticker) > > >saveenv > > > If the users boots from SD/eMMC/SATA/USB, Linux won't have problem with > > > network, since it will generate random MAC address anyway. > > > > Good point, so let's assume the user doesn't have a mac stored. > > > > Without CONFIG_NET_RANDOM_ETHADDR: > > * u-boot refuses to do anything network related > > * Linux generates a random mac, network works > > > > With CONFIG_NET_RANDOM_ETHADDR: > > * u-boot generates a random mac, network works > > * Linux uses the same random mac, passed on from u-boot throught the > > device-tree, network works > > > > It's still random, but at least it's consistent ;) > > It's also only used when we cannot find the MAC. At the end of the day, > the final decision here is Konstantin's (as the listed maintainer). I > personally think enabling the option is good given the apparent number > of ways the real MAC will have been lost from SW, but if the maintainer > wants to instead opt for a verbose failure message, that's fine too. > > -- > Tom
Re: [PATCH] dm: arm: bcmstb: Enable driver model for Ethernet drivers
On Fri, Sep 11, 2020 at 11:31:06AM -0400, Thomas Fitzsimmons wrote: > Eliminate the Driver Model migration warning for the bcm7260 and bcm7445 > ports (though neither port has Ethernet support yet). > > Signed-off-by: Thomas Fitzsimmons > --- > configs/bcm7260_defconfig | 1 + > configs/bcm7445_defconfig | 1 + > 2 files changed, 2 insertions(+) > > diff --git a/configs/bcm7260_defconfig b/configs/bcm7260_defconfig > index f25659db48..47157f04eb 100644 > --- a/configs/bcm7260_defconfig > +++ b/configs/bcm7260_defconfig > @@ -31,4 +31,5 @@ CONFIG_DM_MMC=y > CONFIG_MMC_SDHCI=y > CONFIG_MMC_SDHCI_BCMSTB=y > CONFIG_MTD=y > +CONFIG_DM_ETH=y > # CONFIG_EFI_LOADER is not set > diff --git a/configs/bcm7445_defconfig b/configs/bcm7445_defconfig > index 18d31048ff..0f80e309ab 100644 > --- a/configs/bcm7445_defconfig > +++ b/configs/bcm7445_defconfig > @@ -33,6 +33,7 @@ CONFIG_MMC_SDHCI=y > CONFIG_MMC_SDHCI_BCMSTB=y > CONFIG_MTD=y > CONFIG_DM_SPI_FLASH=y > +CONFIG_DM_ETH=y > CONFIG_SPI=y > CONFIG_DM_SPI=y > CONFIG_BCMSTB_SPI=y If we're just silencing the warning, I'd rather see CONFIG_NET disabled. Thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] riscv: Only enable OF_BOARD_FIXUP for S-Mode
On 9/11/20 10:43 AM, Bin Meng wrote:
> On Fri, Sep 11, 2020 at 6:20 PM Sean Anderson wrote:
>>
>> On 9/11/20 3:29 AM, Bin Meng wrote:
>>> Hi Sean,
>>>
>>> On Sat, Sep 5, 2020 at 9:22 PM Sean Anderson wrote:
It is unsafe to enable OF_BOARD_FIXUP only based on OF_SEPARATE.
OF_SEPARATE may indicate that the user wishes U-Boot to use a different
device tree than one obtained via OF_PRIOR_STAGE. However, OF_SEPARATE may
also indicate that the device tree which would be obtained via
OF_PRIOR_STAGE is invalid, nonexistant, or otherwise unusable. In this
>>>
>>> typo: nonexistent
>>>
latter case, enabling OF_BOARD_FIXUP will result in corruption of the
device tree. To remedy this, only enable OF_BOARD_FIXUP if U-Boot is
configured for S-Mode.
Fixes: 1c17e55594a394ced7de88d91be294eaf8c564c1
>>>
>>> nits: the format should be: commit_id ("description")>
Signed-off-by: Sean Anderson
---
arch/riscv/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 009a545fcf..13fac51483 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -288,6 +288,6 @@ config STACK_SIZE_SHIFT
default 14
config OF_BOARD_FIXUP
- default y if OF_SEPARATE
+ default y if OF_SEPARATE && RISCV_SMODE
>>>
>>> Is that your board is running U-Boot M-mode with OF_SEPARATE that does not
>>> work?
>>
>> Yes, because the reason we use OF_SEPARATE is because no device tree is
>> passed to U-Boot. Trying to use the device tree passed to U-Boot even
>
> I don't get it. If no device tree is passed to U-Boot, why using
> OF_SEPARATE in the first place?
Because it has to come from somewhere. Where else would U-Boot get the
device tree?
>> though OF_SEPARATE is enabled results in garbage being written to the
>
> What garbage data is written?
It might not be garbage written. I didn't document the exact failure
mode at the time I discovered this bug, so I went back to try and
reproduce it for a more thorough analysis. However, I was unable to
reproduce this bug, even on the branch where I originally triggered it.
I documented my reasoning behind this patch at [1]. In my testing, I
could only trigger a "periodic-32" bug.
In any case, this behavior could still cause problems in the future.
>From my testing, on the k210, a1 usually holds some address on the ROM's
stack. However, if it (for instance) instead held an address which
raised a load access fault, or was misaligned, then booting would fail.
In the general case, I was very surpised that U-Boot was using the value
of a1 on entry even with OF_SEPARATE specified. I would expect it only
to use that value if configured with OF_PRIOR_STAGE.
--Sean
[1]
https://patchwork.ozlabs.org/project/uboot/patch/20200815155237.467720-12-sean...@gmail.com/#2520514
Re: [PATCH 1/7] Revert "riscv: Clear pending interrupts before enabling IPIs"
On 9/11/20 10:45 AM, Bin Meng wrote: > On Fri, Sep 11, 2020 at 6:22 PM Sean Anderson wrote: >> >> On 9/11/20 3:38 AM, Bin Meng wrote: >>> Hi Sean, >>> >>> On Tue, Sep 8, 2020 at 2:17 AM Sean Anderson wrote: Clearing MIP doesn't do anything. Whoops. The following commits should >>> >>> Which following commits? >>> tackle this problem in a more robust manner. This reverts commit 9472630337e7c4ac442066b5a752aaa8c3b4d4a6. Signed-off-by: Sean Anderson --- arch/riscv/cpu/start.S | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index bf9fdf369b..e3222b1ea7 100644 --- a/arch/riscv/cpu/start.S +++ b/arch/riscv/cpu/start.S @@ -65,8 +65,6 @@ _start: #else li t0, SIE_SSIE #endif - /* Clear any pending IPIs */ - csrcMODE_PREFIX(ip), t0 >>> >>> Did you mean the clearing MIP.MSIP actually does nothing, but the >>> following commit is the correct fix? >> >> Yes, but we also need > > Is MIP.MSIP read-only on K210? I think so. See [1] where only ssip, stip, and seip are written (and new_mip is not otherwise used). The spec doesn't require MIP.MSIP to be writable at all. --Sean [1] https://github.com/chipsalliance/rocket-chip/blob/master/src/main/scala/rocket/CSR.scala#L859
[PATCH v2] configs: bcmstb: Disable networking support
Silence the "Driver Model for Ethernet drivers" migration warning for the bcm7445 and bcm7260 ports, neither of which supports networking yet. Signed-off-by: Thomas Fitzsimmons --- configs/bcm7260_defconfig | 1 + configs/bcm7445_defconfig | 1 + 2 files changed, 2 insertions(+) diff --git a/configs/bcm7260_defconfig b/configs/bcm7260_defconfig index f25659db48..d1b05309e1 100644 --- a/configs/bcm7260_defconfig +++ b/configs/bcm7260_defconfig @@ -27,6 +27,7 @@ CONFIG_ENV_OVERWRITE=y CONFIG_ENV_IS_IN_MMC=y CONFIG_SYS_REDUNDAND_ENVIRONMENT=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y +# CONFIG_NET is not set CONFIG_DM_MMC=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_BCMSTB=y diff --git a/configs/bcm7445_defconfig b/configs/bcm7445_defconfig index 18d31048ff..1f9ab482a2 100644 --- a/configs/bcm7445_defconfig +++ b/configs/bcm7445_defconfig @@ -28,6 +28,7 @@ CONFIG_ENV_OVERWRITE=y CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_SYS_REDUNDAND_ENVIRONMENT=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y +# CONFIG_NET is not set CONFIG_DM_MMC=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_BCMSTB=y -- 2.26.0.rc2
[PATCH] RFC: tegra: xhci: Allocate from non-cached memory
From: Tom Warren This fixes the XHCI driver on T210 boards (TX1, Nano). I was seeing that Set_Address wasn't completing, returning with a Context Parameter error. Examining the slot context, etc. showed that the correct info was there in RAM. Once I set 'dcache off' globally, it started working. This patch was created to force the TRB, etc. allocation to be in non-cached memory, which resulted in XHCI working on Nano/TX1 w/o the need for a global dcache disable. Thierry Reding pointed to a similar fix he'd done for the rtl6189 driver. Sending this to the list for comment, as this should have affected other XHCI implementations on other SoCs. Note that Tegra X1 (T210) has a 64-byte cache line size (64-bit ARMv8), and I do see the flush_cache/inval_cache ARM code being called via xhci_cache_flash/xhci_inval_cache. Change-Id: I591fd232425bf444b93be3695ee639d528d6713b Signed-off-by: Tom Warren --- drivers/usb/host/xhci-mem.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c index ed649c0..d52fe6c 100644 --- a/drivers/usb/host/xhci-mem.c +++ b/drivers/usb/host/xhci-mem.c @@ -193,7 +193,11 @@ static void *xhci_malloc(unsigned int size) void *ptr; size_t cacheline_size = max(XHCI_ALIGNMENT, CACHELINE_SIZE); +#ifdef CONFIG_SYS_NONCACHED_MEMORY + ptr = (void *)noncached_alloc(ALIGN(size, cacheline_size), cacheline_size); +#else ptr = memalign(cacheline_size, ALIGN(size, cacheline_size)); +#endif BUG_ON(!ptr); memset(ptr, '\0', size); -- 1.8.2.1.610.g562af5b
Re: [PATCH v2] configs: bcmstb: Disable networking support
On Fri, Sep 11, 2020 at 02:41:44PM -0400, Thomas Fitzsimmons wrote: > Silence the "Driver Model for Ethernet drivers" migration warning for > the bcm7445 and bcm7260 ports, neither of which supports networking yet. > > Signed-off-by: Thomas Fitzsimmons Thanks! Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH] x86: fsp: Replace e-mmc with emmc in devicetree bindings
On Fri, 11 Sep 2020 at 08:52, Wolfgang Wallner wrote: > > The term eMMC is used inconsistently within the FSP devicetree > bindigs (e-mmc and emmc), especially for "emmc-host-max-speed" > documentation and code disagree. > > Change all eMMC instances within the FSP bindings to consistently > use "emmc". The term "emmc" is already used a lot within U-Boot, > while "e-mmc" is only used in the FSP bindings. > > Signed-off-by: Wolfgang Wallner > > --- > > arch/x86/cpu/apollolake/fsp_bindings.c | 6 +++--- > doc/device-tree-bindings/fsp/fsp2/apollolake/fsp-m.txt | 2 +- > doc/device-tree-bindings/fsp/fsp2/apollolake/fsp-s.txt | 2 +- > 3 files changed, 5 insertions(+), 5 deletions(-) > Reviewed-by: Simon Glass
Re: [PATCH 00/16] Kconfig: Tidy up the top-level kconfig menu
Hi Tom, On Fri, 11 Sep 2020 at 10:11, Tom Rini wrote: > > On Thu, Sep 10, 2020 at 08:21:11PM -0600, Simon Glass wrote: > > > > > At present this menu is pretty messy, with quite a few minor options shown > > at the top level. This series creates a few new menus and moves things > > around so that the top-level menu is cleaner. > > > > There is more to do, but this is a start. > [snip] > > Kconfig | 340 +--- > > cmd/Kconfig | 117 -- > > common/Kconfig | 505 ++-- > > common/Kconfig.boot | 894 +++ > > drivers/core/Kconfig | 11 + > > dts/Kconfig | 9 - > > env/Kconfig | 9 + > > tools/Kconfig| 12 + > > 8 files changed, 955 insertions(+), 942 deletions(-) > > create mode 100644 common/Kconfig.boot > > create mode 100644 tools/Kconfig > > And after a resync of the defconfigs: > 555 files changed, 941 insertions(+), 941 deletions(-) > and a partial wc -l: >449 Kconfig >697 common/Kconfig >894 common/Kconfig.boot > 2190 cmd/Kconfig > > So in the end, yes, this is I think making things easier to maintain but > will cause a few merge hiccups. Oh dear, I completely forgot about that aspect. Should I add a resync patch at the end, or is it better to do it when reviewed/applied? Regards, Simon
Re: [PATCH 00/16] Kconfig: Tidy up the top-level kconfig menu
On Fri, Sep 11, 2020 at 02:15:50PM -0600, Simon Glass wrote: > Hi Tom, > > On Fri, 11 Sep 2020 at 10:11, Tom Rini wrote: > > > > On Thu, Sep 10, 2020 at 08:21:11PM -0600, Simon Glass wrote: > > > > > > > > At present this menu is pretty messy, with quite a few minor options shown > > > at the top level. This series creates a few new menus and moves things > > > around so that the top-level menu is cleaner. > > > > > > There is more to do, but this is a start. > > [snip] > > > Kconfig | 340 +--- > > > cmd/Kconfig | 117 -- > > > common/Kconfig | 505 ++-- > > > common/Kconfig.boot | 894 +++ > > > drivers/core/Kconfig | 11 + > > > dts/Kconfig | 9 - > > > env/Kconfig | 9 + > > > tools/Kconfig| 12 + > > > 8 files changed, 955 insertions(+), 942 deletions(-) > > > create mode 100644 common/Kconfig.boot > > > create mode 100644 tools/Kconfig > > > > And after a resync of the defconfigs: > > 555 files changed, 941 insertions(+), 941 deletions(-) > > and a partial wc -l: > >449 Kconfig > >697 common/Kconfig > >894 common/Kconfig.boot > > 2190 cmd/Kconfig > > > > So in the end, yes, this is I think making things easier to maintain but > > will cause a few merge hiccups. > > Oh dear, I completely forgot about that aspect. Should I add a resync > patch at the end, or is it better to do it when reviewed/applied? Don't worry about re-sync patches, those are trivially generated and fail to apply easily. Really I'm fine with most cases not touching defconfigs EXCEPT when we're changing requires / depends stuff. That requires a defconfig change at the same time to not break things. -- Tom signature.asc Description: PGP signature
SPL FIT configuration signature verification
Hi there, Is it possible to make SPL U-Boot to verify signature located in configuration section of FIT image, and do not continue in case the signature is missing or doesn't match? Asking because I couldn't find any configuration option for that, and I have FIT image with signature but SPL U-boot doesn't check it at all, it only checks signatures for images if present. Thanks Cheers, Andy
Ways to copy FIT image from the flash to RAM
Hi there, What are the ways of copying whole FIT image form NOR flash to RAM by specifying flash offset without any extra bytes. I've seen quite a lot of times when kernel image size has a fixed value (as an uboot environment variable), which is greater than the actual kernel size. Problem with that that we copy from flash whatever is after kernel which is not required, and there is a potential problem when kernel gets bigger at some point than the fixed size specified in the variable mentioned above. As FIT file has all required info about size, is there a command to copy it to RAM from flash? Thank you Cheers, Andy
U-Boot FIT Signature Verification
Hi there, Does U-boot take into account certificate expiration date when verifying signed images in FIT? In other words, is date stored along with the public key in DTB file? Cheers, Andy
Re: [PATCH] mmc: xenon_sdhci: Add missing common host capabilities
Le 11/09/2020 à 14:38, Marek Behún a écrit :
On Thu, 10 Sep 2020 19:53:40 +0200
Andre Heider wrote:
Use mmc_of_parse() to set the common host properties. That includes
"bus-width", so parsing it can be removed from the driver.
But more importantly, "non-removable" is now respected, which fixes
the usage of eMMC.
Signed-off-by: Andre Heider
---
Tested myself on v5 without emmc, `mmc info` is unchanged for my sd
card
Tested by Gérald on v7 emmc, which started working with this patch:
=> mmc info
Device: sdhci@d8000
Manufacturer ID: 45
OEM: 100
Name: SEM04
Bus Speed: 5200
Mode: MMC High Speed (52MHz)
Rd Block Len: 512
MMC version 4.5
High Capacity: Yes
Capacity: 3.7 GiB
Bus Width: 8-bit
Erase Group Size: 256 KiB
HC WP Group Size: 8 MiB
User Capacity: 3.7 GiB WRREL
Boot Capacity: 2 MiB
RPMB Capacity: 2 MiB
Boot area 0 is not write protected
Boot area 1 is not write protected
drivers/mmc/xenon_sdhci.c | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
diff --git a/drivers/mmc/xenon_sdhci.c b/drivers/mmc/xenon_sdhci.c
index 7f9a579c83..6ce9d00d0a 100644
--- a/drivers/mmc/xenon_sdhci.c
+++ b/drivers/mmc/xenon_sdhci.c
@@ -485,20 +485,10 @@ static int xenon_sdhci_probe(struct udevice
*dev) armada_3700_soc_pad_voltage_set(host);
host->host_caps = MMC_MODE_HS | MMC_MODE_HS_52MHz |
MMC_MODE_DDR_52MHz;
- switch (fdtdec_get_int(gd->fdt_blob, dev_of_offset(dev),
"bus-width",
- 1)) {
- case 8:
- host->host_caps |= MMC_MODE_8BIT;
- break;
- case 4:
- host->host_caps |= MMC_MODE_4BIT;
- break;
- case 1:
- break;
- default:
- printf("Invalid \"bus-width\" value\n");
- return -EINVAL;
- }
+
+ ret = mmc_of_parse(dev, &plat->cfg);
+ if (ret)
+ return ret;
host->ops = &xenon_sdhci_ops;
Tested-by: Marek Behún
|Tested-by: Gérald Kerma | ||
Re: [PATCH v2] arm: mvebu: Espressobin: Set environment variable fdtfile
Le 11/09/2020 à 06:35, Andre Heider a écrit :
Required for the generic distro mechanism.
Linux ships with 4 variants:
marvell/armada-3720-espressobin-v7-emmc.dtb
marvell/armada-3720-espressobin-v7.dtb
marvell/armada-3720-espressobin-emmc.dtb
marvell/armada-3720-espressobin.dtb
Use available information to determine the appropriate filename.
Fixes booting GRUB EFI arm64 on Fedora.
Reported-by: Dennis Gilmore
Signed-off-by: Andre Heider
---
v2:
- enable BOARD_LATE_INIT only for espressobin, via defconfig
- don't overwrite a set/saved $fdtfile
This still has the issue that $fdtfile doesn't show up after `env
default -a`. Pali may look into that, but the infrastructure for it
needs to be created first.
Until then, this can be considered as v2010.10 material as it fixes
booting distros relying on $fdtfile.
Tested myself on a v5 board without eMMC.
Tested by Gérald on v7 emmc, v7/ddr4 detection confirmed working.
board/Marvell/mvebu_armada-37xx/board.c | 47 +
configs/mvebu_espressobin-88f3720_defconfig | 1 +
2 files changed, 48 insertions(+)
diff --git a/board/Marvell/mvebu_armada-37xx/board.c
b/board/Marvell/mvebu_armada-37xx/board.c
index 90bfc139aa..73d69e0388 100644
--- a/board/Marvell/mvebu_armada-37xx/board.c
+++ b/board/Marvell/mvebu_armada-37xx/board.c
@@ -5,6 +5,7 @@
#include
#include
+#include
#include
#include
#include
@@ -50,6 +51,22 @@ DECLARE_GLOBAL_DATA_PTR;
#define MVEBU_G2_SMI_PHY_CMD_REG (24)
#define MVEBU_G2_SMI_PHY_DATA_REG (25)
+/*
+ * Memory Controller Registers
+ *
+ * Assembled based on public information:
+ *
https://gitlab.nic.cz/turris/mox-boot-builder/-/blob/master/wtmi/main.c#L332-336
+ *
https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell/blob/mv_ddr-armada-18.12/drivers/mv_ddr_mc6.h#L309-L332
+ *
+ * And checked against the written register values for the various topologies:
+ *
https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell/blob/mv_ddr-armada-atf-mainline/a3700/mv_ddr_tim.h
+ */
+#define A3700_CH0_MC_CTRL2_REG MVEBU_REGISTER(0x002c4)
+#define A3700_MC_CTRL2_SDRAM_TYPE_MASK 0xf
+#define A3700_MC_CTRL2_SDRAM_TYPE_OFFS 4
+#define A3700_MC_CTRL2_SDRAM_TYPE_DDR3 2
+#define A3700_MC_CTRL2_SDRAM_TYPE_DDR4 3
+
int board_early_init_f(void)
{
return 0;
@@ -63,6 +80,36 @@ int board_init(void)
return 0;
}
+#ifdef CONFIG_BOARD_LATE_INIT
+int board_late_init(void)
+{
+ bool ddr4, emmc;
+
+ if (env_get("fdtfile"))
+ return 0;
+
+ if (!of_machine_is_compatible("globalscale,espressobin"))
+ return 0;
+
+ /* If the memory controller has been configured for DDR4, we're running
on v7 */
+ ddr4 = ((readl(A3700_CH0_MC_CTRL2_REG) >>
A3700_MC_CTRL2_SDRAM_TYPE_OFFS)
+ & A3700_MC_CTRL2_SDRAM_TYPE_MASK) ==
A3700_MC_CTRL2_SDRAM_TYPE_DDR4;
+
+ emmc = of_machine_is_compatible("globalscale,espressobin-emmc");
+
+ if (ddr4 && emmc)
+ env_set("fdtfile",
"marvell/armada-3720-espressobin-v7-emmc.dtb");
+ else if (ddr4)
+ env_set("fdtfile", "marvell/armada-3720-espressobin-v7.dtb");
+ else if (emmc)
+ env_set("fdtfile", "marvell/armada-3720-espressobin-emmc.dtb");
+ else
+ env_set("fdtfile", "marvell/armada-3720-espressobin.dtb");
+
+ return 0;
+}
+#endif
+
/* Board specific AHCI / SATA enable code */
int board_ahci_enable(void)
{
diff --git a/configs/mvebu_espressobin-88f3720_defconfig
b/configs/mvebu_espressobin-88f3720_defconfig
index 5e9fcd1f26..559aeb076f 100644
--- a/configs/mvebu_espressobin-88f3720_defconfig
+++ b/configs/mvebu_espressobin-88f3720_defconfig
@@ -85,3 +85,4 @@ CONFIG_USB_ETHER_SMSC95XX=y
CONFIG_SHA1=y
CONFIG_SHA256=y
CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_BOARD_LATE_INIT=y
|Tested-by: Gérald Kerma |
Re: [PATCH] RFC: tegra: xhci: Allocate from non-cached memory
Hi Tom, On Sat, Sep 12, 2020 at 3:43 AM wrote: > > From: Tom Warren > > This fixes the XHCI driver on T210 boards (TX1, Nano). I was seeing > that Set_Address wasn't completing, returning with a Context Parameter > error. Examining the slot context, etc. showed that the correct info was > there in RAM. Once I set 'dcache off' globally, it started working. > This patch was created to force the TRB, etc. allocation to be in > non-cached memory, which resulted in XHCI working on Nano/TX1 w/o the > need for a global dcache disable. Thierry Reding pointed to a similar > fix he'd done for the rtl6189 driver. > > Sending this to the list for comment, as this should have affected other > XHCI implementations on other SoCs. Note that Tegra X1 (T210) has a > 64-byte cache line size (64-bit ARMv8), and I do see the > flush_cache/inval_cache ARM code being called via > xhci_cache_flash/xhci_inval_cache. > > Change-Id: I591fd232425bf444b93be3695ee639d528d6713b > Signed-off-by: Tom Warren > --- > drivers/usb/host/xhci-mem.c | 4 > 1 file changed, 4 insertions(+) > There are some fixes recently in the xHCI codes. Could you please retest to see if this works on TX1? Regards, Bin
