[PATCH v2] configs: ls1021a: Append othbootargs to bootargs
This patch appends CMA configuration to bootargs for LS1021ATWR board. Signed-off-by: Shengzhou Liu Signed-off-by: Alison Wang --- Changes for v2: - Append CMA configuration to bootargs directly include/configs/ls1021atwr.h | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h index 8e2784b..5f73821 100644 --- a/include/configs/ls1021atwr.h +++ b/include/configs/ls1021atwr.h @@ -297,7 +297,8 @@ #ifdef CONFIG_LPUART #define CONFIG_EXTRA_ENV_SETTINGS \ - "bootargs=root=/dev/ram0 rw console=ttyLP0,115200\0" \ + "bootargs=root=/dev/ram0 rw console=ttyLP0,115200 " \ + "cma=64M@0x0-0xb000\0" \ "initrd_high=0x\0" \ "fdt_high=0x\0" \ "fdt_addr=0x64f0\0" \ @@ -313,7 +314,6 @@ "kernel_size=0x280\0" \ "kernel_addr_sd=0x8000\0" \ "kernel_size_sd=0x14000\0" \ - "$othbootargs\0"\ "othbootargs=cma=64M@0x0-0xb000\0" \ BOOTENV \ "boot_scripts=ls1021atwr_boot.scr\0"\ @@ -355,7 +355,8 @@ "$kernel_size && bootm $load_addr#$board\0" #else #define CONFIG_EXTRA_ENV_SETTINGS \ - "bootargs=root=/dev/ram0 rw console=ttyS0,115200\0" \ + "bootargs=root=/dev/ram0 rw console=ttyS0,115200 " \ + "cma=64M@0x0-0xb000\0" \ "initrd_high=0x\0" \ "fdt_high=0x\0" \ "fdt_addr=0x64f0\0" \ @@ -375,7 +376,6 @@ "kernel_size_sd=0x14000\0" \ "kernelhdr_addr_sd=0x4000\0"\ "kernelhdr_size_sd=0x10\0" \ - "$othbootargs\0"\ "othbootargs=cma=64M@0x0-0xb000\0" \ BOOTENV \ "boot_scripts=ls1021atwr_boot.scr\0"\ -- 2.9.5
Re: [PATCH v4 5/6] riscv: Copy the reserved-memory nodes to final DT
On Tue, Mar 24, 2020 at 3:11 PM Heinrich Schuchardt wrote:
>
> On 3/24/20 8:15 AM, Atish Patra wrote:
> > On Mon, Mar 23, 2020 at 11:23 PM Heinrich Schuchardt
> > wrote:
> >>
> >> On 3/24/20 5:16 AM, Atish Patra wrote:
> >>> The DT used by U-Boot may be different from the DT being passed to
> >>> the OS if the DT is loaded from external media such as network or
> >>> mmc. In that case, the reserved-memory node needs to be copied to
> >>> the DT passed to the OS.
> >>
> >> The bootefi command works in the following sequence:
> >>
> >> * copy the passed fdt of if none is passed the internal fdt
> >> * call image_setup_libfdt() for the copy
> >> * create memory reservations in the UEFI memory map
> >>
> >> Cf.
> >> fef907b2e440 ("efi_loader: create reservations after ft_board_setup")
> >> 7be64b885a36 ("cmd: bootefi: Parse reserved-memory node from DT")
> >>
> >> image_setup_libfdt() executes among others:
> >>
> >> * fdt_chosen()
> >> * arch_fixup_fdt()
> >>
> >> Please, explain why you need to copy memory reservations, if
> >> arch_fixup_fdt() is executed inside the bootefi command:
> >>
> >
> > As per my understanding, there can be two different DTs in U-Boot.
> > 1. Internal device tree or DT passed from previous stage (gd->fdt_blob).
> > This
> > device tree is being used to boot OS as well.
> > 2. User can load the DT from MMC/network to any valid address and use
> > that address in bootefi/booti command line to boot OS.
> >
> > efi_install_fdt copies DT from the given user address (via cmdline) and
> > copies
> > to the efi memory.
> >
> > There is no need to 2nd copy for case 1 as the DT already contains the
> > reserved-memory node. In case 2, the DT loaded from external media may not
> > have the reserved memory regions set by the firmware. That's why we need to
> > copy the reserved-memory nodes. Now, arch_fixup_fdt() is the last place to
> > edit
> > the DT passed to OS. The copy operation has to be done in arch_fixup_fdt.
> > For case 1, fdtdec_add_reserved_memory will simply return without
> > modifying the DT.
>
> There are three cases of device trees:
>
> * U-Boot's internal device trees
> * device trees provided by a earlier stage firmware to U-Boot
>(e.g. on QEMU)
> * device trees supplied by the user
>
Yes. I combined 1st & 2nd case into one.
> We cannot use U-Boot's internal device tree directly because a program
> called via bootefi may manipulate the device tree and return afterwards.
>
> As arch_fixup_fdt is called by all boot commands there is no need to
> insert reserved memory nodes at an earlier stage.
>
> The copy operation is only needed for bootefi as the other boot commands
> cannot return. So it does not make to me to move the device tree copying
> to arch_fixup_fdt().
>
This series is aimed at providing reserved memory support all boot
commands in RISC-V.
All other boot commands booti/bootm also load the device tree supplied
by the user.
Hence, we need to copy the reserved memory nodes so that proper kernel
sees those DT
nodes.
The code path for booti/bootm is
image_setup_linux->image_setup_libfdt->arch_fixup_fdt
This is executed while executing booti/bootm and fixes the DT that
passed to the OS.
> Best regards
>
> Heinrich
>
> >
> >> What would be the source of memory reservation that you would otherwise
> >> miss in the final device tree? Do you expect that the Linux device tree
> >> would lack reservation that are generated on the fly before U-Boot?
> >>
> >> Best regards
> >>
> >> Heinrich
> >>
> >>>
> >>> Signed-off-by: Atish Patra
> >>> Reviewed-by: Bin Meng
> >>> ---
> >>>arch/riscv/lib/bootm.c | 8 +++-
> >>>1 file changed, 7 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/arch/riscv/lib/bootm.c b/arch/riscv/lib/bootm.c
> >>> index 87cadad5016d..8ff8db6bf533 100644
> >>> --- a/arch/riscv/lib/bootm.c
> >>> +++ b/arch/riscv/lib/bootm.c
> >>> @@ -28,8 +28,8 @@ __weak void board_quiesce_devices(void)
> >>>
> >>>int arch_fixup_fdt(void *blob)
> >>>{
> >>> -#ifdef CONFIG_EFI_LOADER
> >>>int err;
> >>> +#ifdef CONFIG_EFI_LOADER
> >>>u32 size;
> >>>int chosen_offset;
> >>>
> >>> @@ -50,6 +50,12 @@ int arch_fixup_fdt(void *blob)
> >>>/* Overwrite the boot-hartid as U-Boot is the last stage BL */
> >>>fdt_setprop_u32(blob, chosen_offset, "boot-hartid",
> >>> gd->arch.boot_hart);
> >>>#endif
> >>> +
> >>> + /* Copy the reserved-memory node to the DT used by OS */
> >>> + err = riscv_fdt_copy_resv_mem_node(gd->fdt_blob, blob);
> >>> + if (err < 0)
> >>> + return err;
> >>> +
> >>>return 0;
> >>>}
> >>>
> >>>
> >>
> >
> >
>
--
Regards,
Atish
STM32MP1 boot slow
Hi, I was looking at the STM32MP1 boot time and I noticed it takes about 2 seconds to get to U-Boot. One problem is the insane I2C timing calculation in stm32f7 i2c driver, which is almost a mallocator and CPU stress test and takes about 1 second to complete in SPL -- we need some simpler replacement for that, possibly the one in DWC I2C driver might do? Another item I found is that, in U-Boot, initf_dm() takes about half a second and so does serial_init(). I didn't dig into it to find out why, but I suspect it has to do with the massive amount of UCLASSes the DM has to traverse OR with the CPU being slow at that point, as the clock driver didn't get probed just yet. Thoughts ? -- Best regards, Marek Vasut
[PATCH v3 1/3] mmc: sdhci: use phys2bus macro when dma address is accessed
Use phys2bus macro when dma address is accessed.
Some targets need to use pyhs2bus macro. (e.g, RPI4)
After applied it, SDMA mode can be used.
Signed-off-by: Jaehoon Chung
Reviewed-by: Peng Fan
Reviewed-by: Minkyu Kang
---
drivers/mmc/sdhci.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 520c9f9feb..2b7493fbac 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
static void sdhci_reset(struct sdhci_host *host, u8 mask)
{
@@ -150,7 +151,8 @@ static void sdhci_prepare_dma(struct sdhci_host *host,
struct mmc_data *data,
mmc_get_dma_dir(data));
if (host->flags & USE_SDMA) {
- sdhci_writel(host, host->start_addr, SDHCI_DMA_ADDRESS);
+ sdhci_writel(host, phys_to_bus((ulong)host->start_addr),
+ SDHCI_DMA_ADDRESS);
} else if (host->flags & (USE_ADMA | USE_ADMA64)) {
sdhci_prepare_adma_table(host, data);
@@ -204,7 +206,7 @@ static int sdhci_transfer_data(struct sdhci_host *host,
struct mmc_data *data)
start_addr &=
~(SDHCI_DEFAULT_BOUNDARY_SIZE - 1);
start_addr += SDHCI_DEFAULT_BOUNDARY_SIZE;
- sdhci_writel(host, start_addr,
+ sdhci_writel(host,
phys_to_bus((ulong)start_addr),
SDHCI_DMA_ADDRESS);
}
}
--
2.25.2
[PATCH v3 0/3] Support SDMA mode on RPI4 target - 32bit
RPI4's SDHCI controller is supported SDMA mode. (Checked on kernel side) But It doesn't use on u-boot side. Then it's too slow about read/write performance. This patchset is supported SDMA mode on RPI4 target(32bit). - I didn't test on RPI4 64bit. Read/write time about 8MB file Before - Read : 1.472 seconds - Write : 4.690 seconds After - Read : 0.359 seconds - Write : 0.574 seconds This patch is based on my RFC's patches.RPI4's SDHCI controller is supported SDMA mode. (Checked on kernel side) But It doesn't use on u-boot side. Then it's too slow about read/write performance. This patchset is supported SDMA mode on RPI4 target(32bit). - I didn't test on RPI4 64bit. Read/write time about 8MB file Before - Read : 1.472 seconds - Write : 4.690 seconds After - Read : 0.359 seconds - Write : 0.574 seconds Changelog on V3 - Rebased on latest u-boot-mmc Changelog on V2 - Keep printf message instead of debug - Add Peng's Reviewed-by tag Jaehoon Chung (3): mmc: sdhci: use phys2bus macro when dma address is accessed mmc: sdhci: not return error when SDMA is not supported configs: rpi_4_32b_defconfig: enable SDHCI_SDMA config configs/rpi_4_32b_defconfig | 1 + drivers/mmc/sdhci.c | 13 +++-- 2 files changed, 8 insertions(+), 6 deletions(-) -- 2.25.2
[PATCH v3 2/3] mmc: sdhci: not return error when SDMA is not supported
If Host controller doesn't support SDMA, it doesn't need to return
error. Because it can be worked with PIO mode.
Signed-off-by: Jaehoon Chung
Reviewed-by: Peng Fan
Reviewed-by: Minkyu Kang
---
drivers/mmc/sdhci.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 2b7493fbac..49e67fc7bd 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -741,13 +741,12 @@ int sdhci_setup_cfg(struct mmc_config *cfg, struct
sdhci_host *host,
debug("%s, caps: 0x%x\n", __func__, caps);
#ifdef CONFIG_MMC_SDHCI_SDMA
- if (!(caps & SDHCI_CAN_DO_SDMA)) {
+ if ((caps & SDHCI_CAN_DO_SDMA)) {
+ host->flags |= USE_SDMA;
+ } else {
printf("%s: Your controller doesn't support SDMA!!\n",
__func__);
- return -EINVAL;
}
-
- host->flags |= USE_SDMA;
#endif
#if CONFIG_IS_ENABLED(MMC_SDHCI_ADMA)
if (!(caps & SDHCI_CAN_DO_ADMA2)) {
--
2.25.2
[PATCH v3 3/3] configs: rpi_4_32b_defconfig: enable SDHCI_SDMA config
Enable SDHCI_SDMA configuration. Signed-off-by: Jaehoon Chung Reviewed-by: Peng Fan Reviewed-by: Minkyu Kang --- configs/rpi_4_32b_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/rpi_4_32b_defconfig b/configs/rpi_4_32b_defconfig index 72cda5d949..7189914606 100644 --- a/configs/rpi_4_32b_defconfig +++ b/configs/rpi_4_32b_defconfig @@ -25,6 +25,7 @@ CONFIG_DFU_MMC=y CONFIG_DM_KEYBOARD=y CONFIG_DM_MMC=y CONFIG_MMC_SDHCI=y +CONFIG_MMC_SDHCI_SDMA=y CONFIG_MMC_SDHCI_BCM2835=y CONFIG_DM_ETH=y CONFIG_BCMGENET=y -- 2.25.2
Re: [PATCH] [RFC] i2c: stm32f2: FIXME: Disable I2C timing calculation
On 3/24/20 11:46 PM, Marek Vasut wrote: > WARNING: This is NOT a fix, but rather a bug report / notice of a problem. > Disable the I2C timing calculation. The calculation is adding 1 second (!) > to the SPL boot time only to calculate I2C timing parameters, that is not > acceptable. Moreover, it is exercising the memory allocator massively. > > Is there no simplified timing parameter calculation which could replace > that horribleness ? Also note the DWC i2c driver has some rather simple I2C setup/hold time calculation, maybe that could be recycled ? -- Best regards, Marek Vasut
[PATCH] [RFC] i2c: stm32f2: FIXME: Disable I2C timing calculation
WARNING: This is NOT a fix, but rather a bug report / notice of a problem. Disable the I2C timing calculation. The calculation is adding 1 second (!) to the SPL boot time only to calculate I2C timing parameters, that is not acceptable. Moreover, it is exercising the memory allocator massively. Is there no simplified timing parameter calculation which could replace that horribleness ? Signed-off-by: Marek Vasut Cc: Nicolas Le Bayon Cc: Patrick Delaunay --- drivers/i2c/stm32f7_i2c.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/i2c/stm32f7_i2c.c b/drivers/i2c/stm32f7_i2c.c index 7d046c1a1e..d549fd0058 100644 --- a/drivers/i2c/stm32f7_i2c.c +++ b/drivers/i2c/stm32f7_i2c.c @@ -743,20 +743,25 @@ static int stm32_i2c_hw_config(struct stm32_i2c_priv *i2c_priv) struct stm32_i2c_timings t; int ret; u32 timing = 0; - + /* This calculation adds 1 second to SPL boot time */ +#if 0 ret = stm32_i2c_setup_timing(i2c_priv, ); if (ret) return ret; - +#endif /* Disable I2C */ clrbits_le32(>cr1, STM32_I2C_CR1_PE); /* Timing settings */ +#if 0 timing |= STM32_I2C_TIMINGR_PRESC(t.presc); timing |= STM32_I2C_TIMINGR_SCLDEL(t.scldel); timing |= STM32_I2C_TIMINGR_SDADEL(t.sdadel); timing |= STM32_I2C_TIMINGR_SCLH(t.sclh); timing |= STM32_I2C_TIMINGR_SCLL(t.scll); +#else +timing = 0x10d09b90; +#endif writel(timing, >timingr); /* Enable I2C */ -- 2.25.1
Re: [PATCH v4 5/6] riscv: Copy the reserved-memory nodes to final DT
On 3/24/20 8:15 AM, Atish Patra wrote:
On Mon, Mar 23, 2020 at 11:23 PM Heinrich Schuchardt wrote:
On 3/24/20 5:16 AM, Atish Patra wrote:
The DT used by U-Boot may be different from the DT being passed to
the OS if the DT is loaded from external media such as network or
mmc. In that case, the reserved-memory node needs to be copied to
the DT passed to the OS.
The bootefi command works in the following sequence:
* copy the passed fdt of if none is passed the internal fdt
* call image_setup_libfdt() for the copy
* create memory reservations in the UEFI memory map
Cf.
fef907b2e440 ("efi_loader: create reservations after ft_board_setup")
7be64b885a36 ("cmd: bootefi: Parse reserved-memory node from DT")
image_setup_libfdt() executes among others:
* fdt_chosen()
* arch_fixup_fdt()
Please, explain why you need to copy memory reservations, if
arch_fixup_fdt() is executed inside the bootefi command:
As per my understanding, there can be two different DTs in U-Boot.
1. Internal device tree or DT passed from previous stage (gd->fdt_blob). This
device tree is being used to boot OS as well.
2. User can load the DT from MMC/network to any valid address and use
that address in bootefi/booti command line to boot OS.
efi_install_fdt copies DT from the given user address (via cmdline) and copies
to the efi memory.
There is no need to 2nd copy for case 1 as the DT already contains the
reserved-memory node. In case 2, the DT loaded from external media may not
have the reserved memory regions set by the firmware. That's why we need to
copy the reserved-memory nodes. Now, arch_fixup_fdt() is the last place to edit
the DT passed to OS. The copy operation has to be done in arch_fixup_fdt.
For case 1, fdtdec_add_reserved_memory will simply return without
modifying the DT.
There are three cases of device trees:
* U-Boot's internal device trees
* device trees provided by a earlier stage firmware to U-Boot
(e.g. on QEMU)
* device trees supplied by the user
We cannot use U-Boot's internal device tree directly because a program
called via bootefi may manipulate the device tree and return afterwards.
As arch_fixup_fdt is called by all boot commands there is no need to
insert reserved memory nodes at an earlier stage.
The copy operation is only needed for bootefi as the other boot commands
cannot return. So it does not make to me to move the device tree copying
to arch_fixup_fdt().
Best regards
Heinrich
What would be the source of memory reservation that you would otherwise
miss in the final device tree? Do you expect that the Linux device tree
would lack reservation that are generated on the fly before U-Boot?
Best regards
Heinrich
Signed-off-by: Atish Patra
Reviewed-by: Bin Meng
---
arch/riscv/lib/bootm.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/riscv/lib/bootm.c b/arch/riscv/lib/bootm.c
index 87cadad5016d..8ff8db6bf533 100644
--- a/arch/riscv/lib/bootm.c
+++ b/arch/riscv/lib/bootm.c
@@ -28,8 +28,8 @@ __weak void board_quiesce_devices(void)
int arch_fixup_fdt(void *blob)
{
-#ifdef CONFIG_EFI_LOADER
int err;
+#ifdef CONFIG_EFI_LOADER
u32 size;
int chosen_offset;
@@ -50,6 +50,12 @@ int arch_fixup_fdt(void *blob)
/* Overwrite the boot-hartid as U-Boot is the last stage BL */
fdt_setprop_u32(blob, chosen_offset, "boot-hartid", gd->arch.boot_hart);
#endif
+
+ /* Copy the reserved-memory node to the DT used by OS */
+ err = riscv_fdt_copy_resv_mem_node(gd->fdt_blob, blob);
+ if (err < 0)
+ return err;
+
return 0;
}
Re: [PATCH v2 1/8] mmc: ca_dw_mmc: add DesignWare based DM support for CAxxxx SoCs
Hi Jaehoon,
We incorporated your comments locally. We will release the next series as v4
once all feedback is received
for the rest of the patches in the series. Thank you for your feedback.
-BR
AN
> On Mar 24, 2020, at 12:16 AM, Jaehoon Chung wrote:
>
> Hi,
>
> On 3/20/20 9:57 AM, Alex Nemirovsky wrote:
>> From: Arthur Li
>>
>> Initial DesignWare based DM support for Cortina Access CA SoCs.
>>
>> Signed-off-by: Arthur Li
>> Signed-off-by: Alex Nemirovsky
>> CC: Peng Fan
>
> I didn't receive any reply about my previous comments.
> And Is there patch v3 or v2? Subject is v2..but change log is v3.
> What is correct version?
>
> Best Regards,
> Jaehoon Chung
>
>>
>> ---
>>
>> Changes in v3: None
>> Changes in v2:
>> - Add I2C controller
>> - Add LED controller
>> - Add SPI NAND and NOR controller
>>
>> MAINTAINERS | 2 +
>> drivers/mmc/Kconfig | 11 +++
>> drivers/mmc/Makefile| 1 +
>> drivers/mmc/ca_dw_mmc.c | 181
>>
>> 4 files changed, 195 insertions(+)
>> create mode 100644 drivers/mmc/ca_dw_mmc.c
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 82e4159..bb45d3c 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -180,6 +180,7 @@ F: board/cortina/common/
>> F: drivers/gpio/cortina_gpio.c
>> F: drivers/watchdog/cortina_wdt.c
>> F: drivers/serial/serial_cortina.c
>> +F: drivers/mmc/ca_dw_mmc.c
>>
>> ARM/CZ.NIC TURRIS MOX SUPPORT
>> M: Marek Behun
>> @@ -670,6 +671,7 @@ F: board/cortina/common/
>> F: drivers/gpio/cortina_gpio.c
>> F: drivers/watchdog/cortina_wdt.c
>> F: drivers/serial/serial_cortina.c
>> +F: drivers/mmc/ca_dw_mmc.c
>>
>> MIPS MSCC
>> M: Gregory CLEMENT
>> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
>> index 2f0eedc..bb38787 100644
>> --- a/drivers/mmc/Kconfig
>> +++ b/drivers/mmc/Kconfig
>> @@ -205,6 +205,17 @@ config MMC_DW
>>block, this provides host support for SD and MMC interfaces, in both
>>PIO, internal DMA mode and external DMA mode.
>>
>> +config MMC_DW_CORTINA
>> +bool "Cortina specific extensions for Synopsys DW Memory Card Interface"
>> +depends on DM_MMC
>> +depends on MMC_DW
>> +depends on BLK
>> +default n
>> +help
>> + This selects support for Cortina SoC specific extensions to the
>> + Synopsys DesignWare Memory Card Interface driver. Select this option
>> + for platforms based on Cortina CA Soc's.
>> +
>> config MMC_DW_EXYNOS
>> bool "Exynos specific extensions for Synopsys DW Memory Card Interface"
>> depends on ARCH_EXYNOS
>> diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
>> index 9c1f8e5..615b724 100644
>> --- a/drivers/mmc/Makefile
>> +++ b/drivers/mmc/Makefile
>> @@ -20,6 +20,7 @@ endif
>> obj-$(CONFIG_ARM_PL180_MMCI) += arm_pl180_mmci.o
>> obj-$(CONFIG_MMC_DAVINCI)+= davinci_mmc.o
>> obj-$(CONFIG_MMC_DW) += dw_mmc.o
>> +obj-$(CONFIG_MMC_DW_CORTINA)+= ca_dw_mmc.o
>> obj-$(CONFIG_MMC_DW_EXYNOS) += exynos_dw_mmc.o
>> obj-$(CONFIG_MMC_DW_K3) += hi6220_dw_mmc.o
>> obj-$(CONFIG_MMC_DW_ROCKCHIP)+= rockchip_dw_mmc.o
>> diff --git a/drivers/mmc/ca_dw_mmc.c b/drivers/mmc/ca_dw_mmc.c
>> new file mode 100644
>> index 000..acbc850
>> --- /dev/null
>> +++ b/drivers/mmc/ca_dw_mmc.c
>> @@ -0,0 +1,181 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * (C) Copyright 2019 Cortina Access
>> + * Arthur Li
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#define SD_CLK_SEL_MASK (0x3)
>> +#define SD_DLL_DEFAULT (0x143000)
>> +#define SD_SCLK_MAX (2)
>> +
>> +#define SD_CLK_SEL_200MHZ (0x2)
>> +#define SD_CLK_SEL_100MHZ (0x1)
>> +
>> +#define IO_DRV_SD_DS_OFFSET (16)
>> +#define IO_DRV_SD_DS_MASK (0xff << IO_DRV_SD_DS_OFFSET)
>> +
>> +#define MIN_FREQ (40)
>> +
>> +DECLARE_GLOBAL_DATA_PTR;
>> +
>> +struct ca_mmc_plat {
>> +struct mmc_config cfg;
>> +struct mmc mmc;
>> +};
>> +
>> +struct ca_dwmmc_priv_data {
>> +struct dwmci_host host;
>> +void __iomem *sd_dll_reg;
>> +void __iomem *io_drv_reg;
>> +u8 ds;
>> +};
>> +
>> +static void ca_dwmci_clksel(struct dwmci_host *host)
>> +{
>> +struct ca_dwmmc_priv_data *priv = host->priv;
>> +u32 val = readl(priv->sd_dll_reg);
>> +
>> +if (host->bus_hz >= 2) {
>> +val &= ~SD_CLK_SEL_MASK;
>> +val |= SD_CLK_SEL_200MHZ;
>> +} else if (host->bus_hz >= 1) {
>> +val &= ~SD_CLK_SEL_MASK;
>> +val |= SD_CLK_SEL_100MHZ;
>> +} else {
>> +val &= ~SD_CLK_SEL_MASK;
>> +}
>> +
>> +writel(val, priv->sd_dll_reg);
>> +}
>> +
>> +static void ca_dwmci_board_init(struct dwmci_host *host)
>> +{
>> +struct ca_dwmmc_priv_data *priv = host->priv;
>> +u32 val = readl(priv->io_drv_reg);
>> +
>> +writel(SD_DLL_DEFAULT,
Re: [PATCH 0/5] CMD_SAVEENV ifdef cleanup
On 19/02/2020 10.47, Rasmus Villemoes wrote: > The various env storage drivers almost all have their own logic [1] > for deciding whether to compile and provide the .save method, many of > which fail to honour CONFIG_SPL_SAVEENV. For example, fat.c and sf.c > define a CMD_SAVEENV macro only for !CONFIG_SPL_BUILD, while ext4.c > "only" depends on CONFIG_CMD_SAVEENV - but CONFIG_SPL_SAVEENV=y, > CONFIG_CMD_SAVEENV=n is a valid combination. > > A lot of that ifdeffery can be removed while at the same time > providing the .save method if either CONFIG_SPL_SAVEENV (for an SPL > build) or CONFIG_CMD_SAVEENV (for U-Boot proper) is set. The first two > patches introduce infrastructure for that, while the last three are > example conversions for the above-mentioned three storage drivers. The > sf.c is the one I need to use in the SPL and have actually tested, > ext4.c and fat.c are included mostly as low-hanging fruit. Dear Wolfgang Can I ask whether you request changes to this patch series or if my answers to your various comments have been satisfactory? Thanks, Rasmus
[PATCH] ARC: fix up memory accessors
Commit 07906b3dad15 ("ARC: Switch to generic accessors") introduces
a regression as it removes compiler barriers from __raw_readX \
__raw_writeX accessors. It breaks DW SPI driver (and possibly others)
Let's fix that and return compiler barriers back. However that's
not all. Let's add read/write barriers to __raw_readX \ __raw_writeX
accessors as lots of drivers use them instead of regular readX \
writeX accessors.
It will save us from lot's of debugging in the future and it is OK
as U-Boot is not that performance oriented as real run-time
software like OS or user bare-metal app so we may afford being not
super fast as we only being executed once.
Signed-off-by: Eugeniy Paltsev
---
arch/arc/include/asm/io.h | 49 ++-
1 file changed, 33 insertions(+), 16 deletions(-)
diff --git a/arch/arc/include/asm/io.h b/arch/arc/include/asm/io.h
index 70d050590de..46cf11ff893 100644
--- a/arch/arc/include/asm/io.h
+++ b/arch/arc/include/asm/io.h
@@ -64,21 +64,28 @@ static inline void sync(void)
#define __arch_putl(v, a) (*(unsigned int *)(a) = (v))
#define __arch_putq(v, a) (*(unsigned long long *)(a) = (v))
-#define __raw_writeb(v, a) __arch_putb(v, a)
-#define __raw_writew(v, a) __arch_putw(v, a)
-#define __raw_writel(v, a) __arch_putl(v, a)
-#define __raw_writeq(v, a) __arch_putq(v, a)
+/*
+ * We add memory barriers for __raw_* operations as lots of U-boot driver uses
+ * then instead of proper accessor with barrier.
+ */
+#define __raw_writeb(v, c) ({ __iowmb(); __arch_putb(v, c); })
+#define __raw_writew(v, c) ({ __iowmb(); __arch_putw(v, c); })
+#define __raw_writel(v, c) ({ __iowmb(); __arch_putl(v, c); })
+#define __raw_writeq(v, c) ({ __iowmb(); __arch_putq(v, c); })
+
+#define __raw_readb(c) ({ u8 __v = __arch_getb(c); __iormb(); __v; })
+#define __raw_readw(c) ({ u16 __v = __arch_getw(c); __iormb(); __v; })
+#define __raw_readl(c) ({ u32 __v = __arch_getl(c); __iormb(); __v; })
+#define __raw_readq(c) ({ u64 __v = __arch_getq(c); __iormb(); __v; })
-#define __raw_readb(a) __arch_getb(a)
-#define __raw_readw(a) __arch_getw(a)
-#define __raw_readl(a) __arch_getl(a)
-#define __raw_readq(a) __arch_getq(a)
static inline void __raw_writesb(unsigned long addr, const void *data,
int bytelen)
{
u8 *buf = (uint8_t *)data;
+ __iowmb();
+
while (bytelen--)
__arch_putb(*buf++, addr);
}
@@ -88,6 +95,8 @@ static inline void __raw_writesw(unsigned long addr, const
void *data,
{
u16 *buf = (uint16_t *)data;
+ __iowmb();
+
while (wordlen--)
__arch_putw(*buf++, addr);
}
@@ -97,6 +106,8 @@ static inline void __raw_writesl(unsigned long addr, const
void *data,
{
u32 *buf = (uint32_t *)data;
+ __iowmb();
+
while (longlen--)
__arch_putl(*buf++, addr);
}
@@ -107,6 +118,8 @@ static inline void __raw_readsb(unsigned long addr, void
*data, int bytelen)
while (bytelen--)
*buf++ = __arch_getb(addr);
+
+ __iormb();
}
static inline void __raw_readsw(unsigned long addr, void *data, int wordlen)
@@ -115,6 +128,8 @@ static inline void __raw_readsw(unsigned long addr, void
*data, int wordlen)
while (wordlen--)
*buf++ = __arch_getw(addr);
+
+ __iormb();
}
static inline void __raw_readsl(unsigned long addr, void *data, int longlen)
@@ -123,6 +138,8 @@ static inline void __raw_readsl(unsigned long addr, void
*data, int longlen)
while (longlen--)
*buf++ = __arch_getl(addr);
+
+ __iormb();
}
/*
@@ -130,20 +147,20 @@ static inline void __raw_readsl(unsigned long addr, void
*data, int longlen)
* ordering rules but do not guarantee any ordering relative to Normal memory
* accesses.
*/
-#define readb_relaxed(c) ({ u8 __r = __raw_readb(c); __r; })
+#define readb_relaxed(c) ({ u8 __r = __arch_getb(c); __r; })
#define readw_relaxed(c) ({ u16 __r = le16_to_cpu((__force __le16) \
- __raw_readw(c)); __r; })
+ __arch_getw(c)); __r; })
#define readl_relaxed(c) ({ u32 __r = le32_to_cpu((__force __le32) \
- __raw_readl(c)); __r; })
+ __arch_getl(c)); __r; })
#define readq_relaxed(c) ({ u64 __r = le64_to_cpu((__force __le64) \
- __raw_readq(c)); __r; })
+ __arch_getq(c)); __r; })
-#define writeb_relaxed(v, c) ((void)__raw_writeb((v), (c)))
-#define writew_relaxed(v, c) ((void)__raw_writew((__force u16) \
+#define writeb_relaxed(v, c) ((void)__arch_putb((v), (c)))
+#define writew_relaxed(v, c)
[PATCH] ARM: tegra: Add NVIDIA Jetson Nano Developer Kit support
From: Tom Warren
The Jetson Nano Developer Kit is a Tegra X1-based development board. It
is similar to Jetson TX1 but it is not pin compatible. It features 4GB
of LPDDR4, a SPI NOR flash for early boot firmware and an SD card slot
used for storage.
HDMI 2.0 or DP 1.2 are available for display, four USB ports (3 USB 2.0
and 1 USB 3.0) can be used to attach a variety of peripherals and a PCI
Ethernet controller provides onboard network connectivity. NVMe support
has also been added. Env save is at the end of QSPI (4MB-8K).
A 40-pin header on the board can be used to extend the capabilities and
exposed interfaces of the Jetson Nano.
Signed-off-by: Thierry Reding
Signed-off-by: Tom Warren
---
arch/arm/dts/Makefile| 3 +-
arch/arm/dts/tegra210-p3450-.dts | 147 +
arch/arm/mach-tegra/board2.c | 25 +
arch/arm/mach-tegra/tegra210/Kconfig | 7 ++
board/nvidia/p3450-/Kconfig | 12 +++
board/nvidia/p3450-/MAINTAINERS | 6 ++
board/nvidia/p3450-/Makefile | 8 ++
board/nvidia/p3450-/p3450-.c | 178 +++
configs/p3450-_defconfig | 64 +
include/configs/p3450-.h | 46 +
10 files changed, 495 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/tegra210-p3450-.dts
create mode 100644 board/nvidia/p3450-/Kconfig
create mode 100644 board/nvidia/p3450-/MAINTAINERS
create mode 100644 board/nvidia/p3450-/Makefile
create mode 100644 board/nvidia/p3450-/p3450-.c
create mode 100644 configs/p3450-_defconfig
create mode 100644 include/configs/p3450-.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 9c593b2..820ee97 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -180,7 +180,8 @@ dtb-$(CONFIG_TEGRA) += tegra20-harmony.dtb \
tegra210-e2220-1170.dtb \
tegra210-p2371-.dtb \
tegra210-p2371-2180.dtb \
- tegra210-p2571.dtb
+ tegra210-p2571.dtb \
+ tegra210-p3450-.dtb
dtb-$(CONFIG_ARCH_MVEBU) +=\
armada-3720-db.dtb \
diff --git a/arch/arm/dts/tegra210-p3450-.dts
b/arch/arm/dts/tegra210-p3450-.dts
new file mode 100644
index 000..9ef744a
--- /dev/null
+++ b/arch/arm/dts/tegra210-p3450-.dts
@@ -0,0 +1,147 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2019-2020 NVIDIA Corporation
+ */
+/dts-v1/;
+
+#include "tegra210.dtsi"
+
+/ {
+ model = "NVIDIA Jetson Nano Developer Kit";
+ compatible = "nvidia,p3450-", "nvidia,tegra210";
+
+ chosen {
+ stdout-path =
+ };
+
+ aliases {
+ ethernet = "/pcie@1003000/pci@2,0/ethernet@0,0";
+ i2c0 = "/i2c@7000d000";
+ i2c2 = "/i2c@7000c400";
+ i2c3 = "/i2c@7000c500";
+ i2c4 = "/i2c@7000c700";
+ mmc0 = "/sdhci@700b0600";
+ mmc1 = "/sdhci@700b";
+ spi0 = "/spi@7041";
+ usb0 = "/usb@7d00";
+ };
+
+ memory {
+ reg = <0x0 0x8000 0x0 0xc000>;
+ };
+
+ pcie@1003000 {
+ status = "okay";
+
+ pci@1,0 {
+ status = "okay";
+ };
+
+ pci@2,0 {
+ status = "okay";
+
+ ethernet@0,0 {
+ reg = <0x00 0 0 0 0>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ };
+ };
+ };
+
+ serial@70006000 {
+ status = "okay";
+ };
+
+ padctl@7009f000 {
+ pinctrl-0 = <_default>;
+ pinctrl-names = "default";
+
+ padctl_default: pinmux {
+ xusb {
+ nvidia,lanes = "otg-1", "otg-2";
+ nvidia,function = "xusb";
+ nvidia,iddq = <0>;
+ };
+
+ usb3 {
+ nvidia,lanes = "pcie-5", "pcie-6";
+ nvidia,function = "usb3";
+ nvidia,iddq = <0>;
+ };
+
+ pcie-x1 {
+ nvidia,lanes = "pcie-0";
+ nvidia,function = "pcie-x1";
+ nvidia,iddq = <0>;
+ };
+
+ pcie-x4 {
+ nvidia,lanes = "pcie-1", "pcie-2",
+ "pcie-3", "pcie-4";
+ nvidia,function = "pcie-x4";
+ nvidia,iddq = <0>;
+ };
+
+ sata {
+ nvidia,lanes = "sata-0";
+
Re: [RFT PATCH v1 1/5] Revert "usb: ehci-hcd: Keep async schedule running"
On 3/24/20 7:11 PM, Lukasz Majewski wrote: > Hi Marek, Hi, >> On 3/24/20 8:06 AM, Lukasz Majewski wrote: >>> Hi Marek, >> >> Hi, >> >> [...] >> >> You should probably figure out why this doesn't work first and >> then add fixes on top. > > Haven't you seen such problem during code development on your > setup when developing this patch? During the development of the patch, I don't remember, sorry. I most certainly saw various failure modes, however those should not be present mainline. >>> >>> The issue is that the qhtoken is not updated at all. >>> >>> Maybe you remember - is Linux using async setup by default (as >>> introduced in SHA1: 02b0e1a36c5bc20174299312556ec4e266872bd6) ? >> >> If I recall correctly, it is using async schedule for bulk transfers. >> But the code is available, so you can double-check that. >> I tested this patch with the problematic USB sticks on R-Car Gen3 and with SMSC95xx USB ethernet adapter last weekend and I didn't see a problem. >>> >>> Ok. >>> >>> For i.MX6Q: >>> The SHA1: 02b0e1a36c5bc20174299312556ec4e266872bd6 patch causes the >>> iMX6Q to fail after a few minutes of testing. General in i.MX6Q the >>> usb is NOT robust at all. >>> >>> For i.MX53: >>> With patch 02b0e1a36c5bc20174299312556ec4e266872bd6 applied it also >>> breaks after a few minutes. >> >> So on CI HDRC , there is some difference in behavior. That is what you >> need to find and fix then. > > The conclusion is that some boards/implementations are broken. At least systems with CI HDRC. >>> With this patch series applied it works for 2 days now without any >>> issue. >> >> Except performance is totally degraded > > So we do have _very_ fast USB which breaks after a few minutes of > constant testing (with procedure stated earlier). No, we have a controller which manifests some problem and that problem needs to be identified and fixed. Whether it's in the stack or in the controller driver is to be seen. >> and there is still no clear >> explanation _why_ any of these patches are needed > > Haven't I explicitly explained in previous mails why XACTARR error shall > be handled? Nor the original thread did it? Wasn't the cover-letter > verbose enough? Regarding XACTERR, I agree it should be handled somehow. However, I don't think handling XACTERR is what fixes your problems with the USB sticks, is it ? Also, it is still unclear whether handling XACTERR exactly the same as STALL is the right thing to do. Is it ? I think it's not. >> and/or whether doing >> write to a block device with these patches may cause data corruption. > > So I will ask differently - what _may_ happen when the "TD - > token=" error shows up and the board hangs? Wouldn't we risk some > unwanted storage corruption? The behavior is undefined. -- Best regards, Marek Vasut
Re: [PATCH 1/1] efi_loader: only reserve memory if fdt node enabled
On Mon, Mar 23, 2020 at 11:55 PM Heinrich Schuchardt wrote:
>
> Sub-nodes of /reserved-memory may be disabled. In this case we should not
> reserve memory in the memory map.
>
> Reported-by: Patrick DELAUNAY
> Fixes: fef907b2e440 ("efi_loader: create reservations after
> ft_board_setup")
> Signed-off-by: Heinrich Schuchardt
> ---
> cmd/bootefi.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> index 3bbe2d6a1a..aaed575505 100644
> --- a/cmd/bootefi.c
> +++ b/cmd/bootefi.c
> @@ -199,7 +199,8 @@ static void efi_carve_out_dt_rsv(void *fdt)
> * The /reserved-memory node may have children with
> * a size instead of a reg property.
> */
> - if (addr != FDT_ADDR_T_NONE)
> + if (addr != FDT_ADDR_T_NONE &&
> + fdtdec_get_is_enabled(fdt, subnode))
> efi_reserve_memory(addr, size);
> subnode = fdt_next_subnode(fdt, subnode);
> }
> --
> 2.25.1
>
Reviewed-by: Atish Patra
--
Regards,
Atish
Re: [RFT PATCH v1 1/5] Revert "usb: ehci-hcd: Keep async schedule running"
Hi Marek, > On 3/24/20 8:06 AM, Lukasz Majewski wrote: > > Hi Marek, > > Hi, > > [...] > > You should probably figure out why this doesn't work first and > then add fixes on top. > >>> > >>> Haven't you seen such problem during code development on your > >>> setup when developing this patch? > >> > >> During the development of the patch, I don't remember, sorry. I > >> most certainly saw various failure modes, however those should not > >> be present mainline. > > > > The issue is that the qhtoken is not updated at all. > > > > Maybe you remember - is Linux using async setup by default (as > > introduced in SHA1: 02b0e1a36c5bc20174299312556ec4e266872bd6) ? > > If I recall correctly, it is using async schedule for bulk transfers. > But the code is available, so you can double-check that. > > >> I tested this patch with the problematic USB sticks on R-Car Gen3 > >> and with SMSC95xx USB ethernet adapter last weekend and I didn't > >> see a problem. > > > > Ok. > > > > For i.MX6Q: > > The SHA1: 02b0e1a36c5bc20174299312556ec4e266872bd6 patch causes the > > iMX6Q to fail after a few minutes of testing. General in i.MX6Q the > > usb is NOT robust at all. > > > > For i.MX53: > > With patch 02b0e1a36c5bc20174299312556ec4e266872bd6 applied it also > > breaks after a few minutes. > > So on CI HDRC , there is some difference in behavior. That is what you > need to find and fix then. The conclusion is that some boards/implementations are broken. > > > With this patch series applied it works for 2 days now without any > > issue. > > Except performance is totally degraded So we do have _very_ fast USB which breaks after a few minutes of constant testing (with procedure stated earlier). > and there is still no clear > explanation _why_ any of these patches are needed Haven't I explicitly explained in previous mails why XACTARR error shall be handled? Nor the original thread did it? Wasn't the cover-letter verbose enough? > and/or whether doing > write to a block device with these patches may cause data corruption. So I will ask differently - what _may_ happen when the "TD - token=" error shows up and the board hangs? Wouldn't we risk some unwanted storage corruption? Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpYYZkqi3st8.pgp Description: OpenPGP digital signature
Re: Totally wrecked my ENV
Thank you very much Wolfgang, reinstalling U-Boot helped. Cheers, udo. On 24/03/2020 15:18, Wolfgang Denk wrote: > Dear Udo, > > In message you wrote: >> >> while trying to set the mac-address of a device in u-boot I somehow >> wrecked the whole thing. >> >> I think I did 'setenv eth0addr xx:xx:xx:xx:xx:xx' followed by 'saveenv' >> After that, my device tells me "Unknown command 'run' - try 'help'" and >> also "Unknown command 'env' - try 'help'" > > I can't imagine of a situation where a correctly running U-Boot > would suffer in such a way from any misspelled environment settings. > >> I seemed to me that some wrong quoting in the above 'setenv' command >> messed up all the strings. > > No, the cause of the problem must be elsewhere. > >> I'm lost now, how can I achienve a total reset of my ENV? > > Resetting your environment will not help. When U-Boot cannot find > command names like run or printenv, it's internal data stuctures > have been corrupted, and this will not go away if you clean up the > environment. You must reflash the whole U-Boot image. If you can > still boot into Linux, I would use this to write the new U-Boot > image, as you cannot really trust your U-Boot any more. If not, and > you can still load and flash an image in U-Boot, then try that. If > this doesn't work either, then you probably have to use a JTAG > debugger (if you have a JTAG connector on your board). > > Best regards, > > Wolfgang Denk > signature.asc Description: OpenPGP digital signature
[PATCH v3 2/3] cmd: fs: Add command to list supported fs types
Added command "fstypes" to list supported/included filesystems.
Signed-off-by: Niel Fourie
Cc: Simon Glass
Reviewed-by: Simon Glass
---
Changes in v2:
- Add Python test
Changes in v3:
- Rewrote comment for do_fs_types() in fs.h
cmd/fs.c | 11 +++
fs/fs.c | 20
include/fs.h | 11 +++
test/py/tests/test_fs/test_fs_cmd.py | 12
4 files changed, 54 insertions(+)
create mode 100644 test/py/tests/test_fs/test_fs_cmd.py
diff --git a/cmd/fs.c b/cmd/fs.c
index db74767b7b..26b47bd001 100644
--- a/cmd/fs.c
+++ b/cmd/fs.c
@@ -99,3 +99,14 @@ U_BOOT_CMD(
"fstype : \n"
"- set environment variable to filesystem type\n"
);
+
+static int do_fstypes_wrapper(cmd_tbl_t *cmdtp, int flag, int argc,
+ char * const argv[])
+{
+ return do_fs_types(cmdtp, flag, argc, argv);
+}
+
+U_BOOT_CMD(
+ fstypes, 1, 1, do_fstypes_wrapper,
+ "List supported filesystem types", ""
+);
diff --git a/fs/fs.c b/fs/fs.c
index 0c66d60477..3e38b2e27a 100644
--- a/fs/fs.c
+++ b/fs/fs.c
@@ -900,3 +900,23 @@ int do_ln(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[],
return 0;
}
+
+int do_fs_types(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+ struct fstype_info *drv = fstypes;
+ const int n_ents = ARRAY_SIZE(fstypes);
+ struct fstype_info *entry;
+ int i = 0;
+
+ puts("Supported filesystems");
+ for (entry = drv; entry != drv + n_ents; entry++) {
+ if (entry->fstype != FS_TYPE_ANY) {
+ printf("%c %s", i ? ',' : ':', entry->name);
+ i++;
+ }
+ }
+ if (!i)
+ puts(": ");
+ puts("\n");
+ return CMD_RET_SUCCESS;
+}
diff --git a/include/fs.h b/include/fs.h
index 37e35c2120..514c248e50 100644
--- a/include/fs.h
+++ b/include/fs.h
@@ -254,4 +254,15 @@ int do_fs_uuid(cmd_tbl_t *cmdtp, int flag, int argc, char
* const argv[],
*/
int do_fs_type(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]);
+/**
+ * do_fs_types - List supported filesystems.
+ *
+ * @cmdtp: Command information for fstypes
+ * @flag: Command flags (CMD_FLAG_...)
+ * @argc: Number of arguments
+ * @argv: List of arguments
+ * @return result (see enum command_ret_t)
+ */
+int do_fs_types(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]);
+
#endif /* _FS_H */
diff --git a/test/py/tests/test_fs/test_fs_cmd.py
b/test/py/tests/test_fs/test_fs_cmd.py
new file mode 100644
index 00..86ba92e025
--- /dev/null
+++ b/test/py/tests/test_fs/test_fs_cmd.py
@@ -0,0 +1,12 @@
+# SPDX-License-Identifier: GPL-2.0
+# Copyright (C) 2020
+# Niel Fourie, DENX Software Engineering, lu...@denx.de
+
+import pytest
+
+@pytest.mark.buildconfigspec('cmd_fs_generic')
+def test_dm_compat(u_boot_console):
+"""Test that `fstypes` prints a result which includes `sandbox`."""
+output = u_boot_console.run_command('fstypes')
+assert "Supported filesystems:" in output
+assert "sandbox" in output
--
2.25.1
[PATCH v3 1/3] cmd: part: Add subcommand to list supported partition tables
Add a subcommand "types" to the part command, which lists the supported
partition table types.
Signed-off-by: Niel Fourie
Cc: Simon Glass
Reviewed-by: Simon Glass
---
Changes in v2:
- Add Python test
Changes in v3:
- none
cmd/part.c | 27 +--
test/py/tests/test_part.py | 14 ++
2 files changed, 39 insertions(+), 2 deletions(-)
create mode 100644 test/py/tests/test_part.py
diff --git a/cmd/part.c b/cmd/part.c
index 5e4e45ca6d..fae5df7b71 100644
--- a/cmd/part.c
+++ b/cmd/part.c
@@ -182,6 +182,26 @@ static int do_part_number(int argc, char * const argv[])
return do_part_info(argc, argv, CMD_PART_INFO_NUMBER);
}
+static int do_part_types(int argc, char * const argv[])
+{
+ struct part_driver *drv = ll_entry_start(struct part_driver,
+part_driver);
+ const int n_ents = ll_entry_count(struct part_driver, part_driver);
+ struct part_driver *entry;
+ int i = 0;
+
+ puts("Supported partition tables");
+
+ for (entry = drv; entry != drv + n_ents; entry++) {
+ printf("%c %s", i ? ',' : ':', entry->name);
+ i++;
+ }
+ if (!i)
+ puts(": ");
+ puts("\n");
+ return CMD_RET_SUCCESS;
+}
+
static int do_part(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
if (argc < 2)
@@ -197,7 +217,8 @@ static int do_part(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
return do_part_size(argc - 2, argv + 2);
else if (!strcmp(argv[1], "number"))
return do_part_number(argc - 2, argv + 2);
-
+ else if (!strcmp(argv[1], "types"))
+ return do_part_types(argc - 2, argv + 2);
return CMD_RET_USAGE;
}
@@ -221,5 +242,7 @@ U_BOOT_CMD(
" part can be either partition number or partition name\n"
"part number\n"
"- set environment variable to the partition number using the
partition name\n"
- " part must be specified as partition name"
+ " part must be specified as partition name\n"
+ "part types\n"
+ "- list supported partition table types"
);
diff --git a/test/py/tests/test_part.py b/test/py/tests/test_part.py
new file mode 100644
index 00..cba9804510
--- /dev/null
+++ b/test/py/tests/test_part.py
@@ -0,0 +1,14 @@
+# SPDX-License-Identifier: GPL-2.0
+# Copyright (C) 2020
+# Niel Fourie, DENX Software Engineering, lu...@denx.de
+
+import pytest
+
+@pytest.mark.buildconfigspec('cmd_part')
+@pytest.mark.buildconfigspec('partitions')
+@pytest.mark.buildconfigspec('efi_partition')
+def test_dm_compat(u_boot_console):
+"""Test that `part types` prints a result which includes `EFI`."""
+output = u_boot_console.run_command('part types')
+assert "Supported partition tables:" in output
+assert "EFI" in output
--
2.25.1
[PATCH v3 0/3] cmd: add driver, fs and part type listing commands
This series adds commands for listing the supported partition tables, listing supported filesystems and expands Driver Model listing commands. The existing "dm drivers" command, which lists the DM drivers and their compatibility strings, segmentation faulted on drivers for which of_match was unpopulated (which appears to not be uncommon). This was fixed, and the command was renamed "dm compat", and a new more extensive "dm drivers" command was added, which list all DM drivers and for each, their uclass id, uclass driver and the device names for active driver instances. The purpose is show available drivers, but also to highlight unused drivers or drivers with uclass ids without uclass drivers, etc. The following commands were added: -"part types", lists partition tables supported -"fstypes", lists filesystem types supported -"dm compat", lists drivers and their compatibility strings (equivalent to existing "dm drivers" command) -"dm drivers", lists all DM drivers, and for each their uclass id, uclass driver and the device names for active driver instances. -"dm static", lists all DM drivers which use static platform data (instead of the device tree). These patches were tested in the Sandbox and on the Wandboard i.MX6Quad Board rev B1. Changes in v2: - Rebased on https://patchwork.ozlabs.org/patch/1234460/ - Added Python tests - Fixed minor typographical errors Changes in v3: - Rewrote comment for do_fs_types() in fs.h Niel Fourie (3): cmd: part: Add subcommand to list supported partition tables cmd: fs: Add command to list supported fs types cmd: dm: Fixed/Added DM driver listing subcommands cmd/dm.c | 22 ++- cmd/fs.c | 11 ++ cmd/part.c | 27 +- drivers/core/dump.c | 55 +++- fs/fs.c | 20 ++ include/dm/util.h| 6 +++ include/fs.h | 11 ++ test/py/tests/test_dm.py | 22 ++- test/py/tests/test_fs/test_fs_cmd.py | 12 ++ test/py/tests/test_part.py | 14 +++ 10 files changed, 194 insertions(+), 6 deletions(-) create mode 100644 test/py/tests/test_fs/test_fs_cmd.py create mode 100644 test/py/tests/test_part.py -- 2.25.1
[PATCH v3 3/3] cmd: dm: Fixed/Added DM driver listing subcommands
Renamed dm "drivers" subcommand to "compat" (as it listed
compatibility strings) and prevent it from segfaulting when
drivers have no of_match populated.
Added a new "drivers" subcommand to dump a list of all known DM
drivers and for each, their uclass id, uclass driver and names of
attached devices.
Added a new "static" subcommand to dump a list of DM drivers with
statically defined platform data.
Signed-off-by: Niel Fourie
Cc: Simon Glass
Cc: Sean Anderson
Reviewed-by: Simon Glass
---
Depends on: https://patchwork.ozlabs.org/patch/1234460/
Changes in v2:
- Add/extend Python tests
- Fixed minor formatting/typographical errors
Changes in v3:
- none
cmd/dm.c | 22 +++-
drivers/core/dump.c | 55 +++-
include/dm/util.h| 6 +
test/py/tests/test_dm.py | 22 ++--
4 files changed, 101 insertions(+), 4 deletions(-)
diff --git a/cmd/dm.c b/cmd/dm.c
index 7a90685f8b..fa7eba6a17 100644
--- a/cmd/dm.c
+++ b/cmd/dm.c
@@ -48,11 +48,29 @@ static int do_dm_dump_drivers(cmd_tbl_t *cmdtp, int flag,
int argc,
return 0;
}
+static int do_dm_dump_driver_compat(cmd_tbl_t *cmdtp, int flag, int argc,
+ char * const argv[])
+{
+ dm_dump_driver_compat();
+
+ return 0;
+}
+
+static int do_dm_dump_static_driver_info(cmd_tbl_t *cmdtp, int flag, int argc,
+char * const argv[])
+{
+ dm_dump_static_driver_info();
+
+ return 0;
+}
+
static cmd_tbl_t test_commands[] = {
U_BOOT_CMD_MKENT(tree, 0, 1, do_dm_dump_all, "", ""),
U_BOOT_CMD_MKENT(uclass, 1, 1, do_dm_dump_uclass, "", ""),
U_BOOT_CMD_MKENT(devres, 1, 1, do_dm_dump_devres, "", ""),
U_BOOT_CMD_MKENT(drivers, 1, 1, do_dm_dump_drivers, "", ""),
+ U_BOOT_CMD_MKENT(compat, 1, 1, do_dm_dump_driver_compat, "", ""),
+ U_BOOT_CMD_MKENT(static, 1, 1, do_dm_dump_static_driver_info, "", ""),
};
static __maybe_unused void dm_reloc(void)
@@ -94,5 +112,7 @@ U_BOOT_CMD(
"tree Dump driver model tree ('*' = activated)\n"
"dm uclassDump list of instances for each uclass\n"
"dm devresDump list of device resources for each device\n"
- "dm drivers Dump list of drivers and their compatible strings"
+ "dm drivers Dump list of drivers with uclass and instances\n"
+ "dm compatDump list of drivers with compatibility strings\n"
+ "dm staticDump list of drivers with static platform data"
);
diff --git a/drivers/core/dump.c b/drivers/core/dump.c
index b5046398d4..e96d59f861 100644
--- a/drivers/core/dump.c
+++ b/drivers/core/dump.c
@@ -97,7 +97,7 @@ void dm_dump_uclass(void)
}
}
-void dm_dump_drivers(void)
+void dm_dump_driver_compat(void)
{
struct driver *d = ll_entry_start(struct driver, driver);
const int n_ents = ll_entry_count(struct driver, driver);
@@ -116,3 +116,56 @@ void dm_dump_drivers(void)
printf("%-20.20s\n", entry->name);
}
}
+
+void dm_dump_drivers(void)
+{
+ struct driver *d = ll_entry_start(struct driver, driver);
+ const int n_ents = ll_entry_count(struct driver, driver);
+ struct driver *entry;
+ struct udevice *udev;
+ struct uclass *uc;
+ int i;
+
+ puts("Driveruid uclass Devices\n");
+ puts("--\n");
+
+ for (entry = d; entry < d + n_ents; entry++) {
+ uclass_get(entry->id, );
+
+ printf("%-25.25s %-3.3d %-20.20s ", entry->name, entry->id,
+ uc ? uc->uc_drv->name : "");
+
+ if (!uc) {
+ puts("\n");
+ continue;
+ }
+
+ i = 0;
+ uclass_foreach_dev(udev, uc) {
+ if (udev->driver != entry)
+ continue;
+ if (i)
+ printf("%-51.51s", "");
+
+ printf("%-25.25s\n", udev->name);
+ i++;
+ }
+ if (!i)
+ puts("\n");
+ }
+}
+
+void dm_dump_static_driver_info(void)
+{
+ struct driver_info *drv = ll_entry_start(struct driver_info,
+driver_info);
+ const int n_ents = ll_entry_count(struct driver_info, driver_info);
+ struct driver_info *entry;
+
+ puts("DriverAddress\n");
+ puts("-\n");
+ for (entry = drv; entry != drv + n_ents; entry++) {
+ printf("%-25.25s @%08lx\n", entry->name,
+ (ulong)map_to_sysmem(entry->platdata));
+ }
+}
diff --git a/include/dm/util.h b/include/dm/util.h
index 0ccb3fbadf..974347ce0b 100644
---
Re: [RFT PATCH v1 1/5] Revert "usb: ehci-hcd: Keep async schedule running"
On 3/24/20 8:06 AM, Lukasz Majewski wrote: > Hi Marek, Hi, [...] You should probably figure out why this doesn't work first and then add fixes on top. >>> >>> Haven't you seen such problem during code development on your setup >>> when developing this patch? >> >> During the development of the patch, I don't remember, sorry. I most >> certainly saw various failure modes, however those should not be >> present mainline. > > The issue is that the qhtoken is not updated at all. > > Maybe you remember - is Linux using async setup by default (as > introduced in SHA1: 02b0e1a36c5bc20174299312556ec4e266872bd6) ? If I recall correctly, it is using async schedule for bulk transfers. But the code is available, so you can double-check that. >> I tested this patch with the problematic USB sticks on R-Car Gen3 and >> with SMSC95xx USB ethernet adapter last weekend and I didn't see a >> problem. > > Ok. > > For i.MX6Q: > The SHA1: 02b0e1a36c5bc20174299312556ec4e266872bd6 patch causes the > iMX6Q to fail after a few minutes of testing. General in i.MX6Q the > usb is NOT robust at all. > > For i.MX53: > With patch 02b0e1a36c5bc20174299312556ec4e266872bd6 applied it also > breaks after a few minutes. So on CI HDRC , there is some difference in behavior. That is what you need to find and fix then. > With this patch series applied it works for 2 days now without any > issue. Except performance is totally degraded and there is still no clear explanation _why_ any of these patches are needed and/or whether doing write to a block device with these patches may cause data corruption.
Seeed BeagleBone Green Wireless: U-boot cli not shown
I cannot get the u-boot cli. Device: BeagleBone Green Wireless Connection: BBGW -> Serial -> PL2303 -> PC Build: --- cd u-boot-v2020.01/ export CROSS_COMPILE='arm-linux-gnueabihf-' export KBUILD_OUTPUT='O' make -j3 am335x_evm_defconfig make -j3 all --- ls -lh u-boot-v2020.01/O/spl/u-boot-spl.bin u-boot-v2020.01/O/u-boot.bin --- -rwxr-xr-x 1 darren darren 105K Mar 24 21:19 u-boot-v2020.01/O/spl/u-boot-spl.bin -rw-r--r-- 1 darren darren 546K Mar 24 21:19 u-boot-v2020.01/O/u-boot.bin --- Test: --- echo ' 115200 -clocal ignbrk ignpar -icrnl -ixon -opost -isig -icanon -iexten -echo ' | xargs stty -F /dev/ttyUSB0 sx --xmodem -k -vv /dev/ttyUSB0 u-boot-v2020.01/O/spl/u-boot-spl.bin sx --xmodem -k -vv /dev/ttyUSB0 u-boot-v2020.01/O/u-boot.bin cu -l /dev/ttyUSB0 -s 115200 --- After that, what I get in cu is nothing but the following --- xyzModem - CRC mode, 5975(SOH)/0(STX)/0(CAN) packets, 4 retries Loaded 764512 bytes CCC --- But I want this --- => --- Thanks.
Re: [PATCH v2 1/2] spi: call WATCHDOG_RESET() in spi_nor_wait_till_ready_with_timeout()
Dear Vignesh,
In message <05694b0e-50a1-de5d-25d8-0444a2cae...@ti.com> you wrote:
>
> Aim of spi-nor-tiny.c is to have a tiny stack that can be used in
> SPL/TPL or on resource constraint boards to only support _reading_ from
> the flash. So tiny stack would be subset of spi-nor-core.
I fully understand this goal.
> There are few options here:
> One is to have single driver and hide things that are not required for
> tiny stack under #ifdef. But this makes code harder to read and modify
#ifdef is one way to implement conditioan code, plain C code like
if (IS_ENABLED(CONFIG_ Second option, is to factor out common functions into a separate file as
> a library. This would avoid ifdef'ry. But whenever a new feature is
> added that would add to the size of these common functions, it would be
> probably mean moving it out of common library and into individual
> stacks. This may need to unnecessary code churn whenever a new feature
> is added.
This is all speculation, and experience says that this risks and
disadvantages of duplicated code are much higher.
> So, suggestion was to add a parallel tiny stack (which was supposed to
> plug into tiny read only MTD stack) that only supports reading from
> flash. This would mean that new features can be freely added to
> spi-nor-core.c without worrying about bloating SPL for older devices.
Yes, and the result is that you have two different implementations
that are out of sync from day one after you created them, bugs get
fixed here but no there, support for new chips same, etc.
> If the opinion is to switch to second option now, then I can rework the
> framework. But note that this would make adding new features bit harder
> due to need to maintain size of spi-nor-tiny.c.
I agree that the reorganization will take additional efforts, but in
the long term, maintenance efforts will be much smaller, as you have
to maintain one common code base only. And if you add new features
and see that they have negative impact on the SPL configurations,
you can always encapsulate these parts in IS_ENABLED() code.
> Please, let me know?
Well, for large parts things are pretty easy:
> > All the functions
> >
> > spi_nor_read_write_reg()
> > spi_nor_read_reg()
> > spi_nor_write_reg()
> > spi_nor_read_data()
> > mtd_to_spi_nor()
> > spi_nor_convert_opcode()
> > spi_nor_ready()
> > spi_nor_wait_till_ready_with_timeout()
> > spi_nor_wait_till_ready()
> > macronix_quad_enable()
> > spansion_read_cr_quad_enable()
> > spi_nor_set_read_settings()
> >
> >
> > are absolutely identical;
For these functions there is absolutely no justification to have
them duplicated.
> > functions
> >
> > read_cr()
> > write_sr()
> > write_disable()
> > set_4byte()
> > spi_nor_read()
> > write_sr_cr()
> >
> > are mostly identical, but I wonder if the differences (like
> > nor->write_reg() versus spi_nor_write_reg()) is indeed intended to
> > save memory footprint or lack an update to later code?
>
> I am in the process of dropping nor->*() functions altogether as I don't
> see any users outside of spi-nor-core.c
>
> Note that some of these will no longer be same with 8D-8D-8D support[1]
> thus further reducing the similarities.
Well, maybe this rework should consider the idea of having common
code both for normal and size-limited use cases?
In the current form, the differences are so small they could easily
be handled by a few macro definitions so the code would be
indentical again.
Maybe this is also possible in your rework?
> > Function
> >
> > spi_nor_convert_3to4_read()
> > spi_nor_set_4byte_opcodes()
> >
> > looks like it has not been updated/synced for some time.
>
> Thats intentional... Adding Octal mode support to tiny stack would add
> to code size and possibly break few boards.
OK - I did not look deeply enough into the code if it was just new
features that will never be needed in the SPL, of if they might
actually be needed, or if they were actually bug fixes.
You are the expert here, so I trust your assessment.
> Any addition to spi-nor-tiny.c should be debated whether or not that
> change is absolutely needed for low footprint boards.
Agreed.
> > Function
> >
> > spi_nor_sr_ready()
> > spi_nor_fsr_ready()
> >
> > is lacking error handling in spi-nor-tiny.c; and the rror handling
> > code in spi-nor-core.c is also mostly duplicated a couple or times.
>
> Error handling is not required, as tiny stack does not support writing
> to flash and these errors are raised when writing or erasing flash.
These differences are tricial to handle using IS_ENABLED() for code
parts that are needed only when erase/write support is configured.
> > Function
> >
> > spi_nor_read_id()
> >
> > differs in "interesting" ways, i. e. we have
> >
> > 370 info = spi_nor_ids;
> > 371 for (; info->sector_size != 0; info++) {
> > 372 if (info->id_len) {
> >
> >
[PATCH v5 5/5] cmd: mvebu: bubt: show image boot device
When a mismatch is found trying to write an image for one boot method
to a different boot device, print an error message including the image
header marked target boot device type.
Signed-off-by: Joel Johnson
Reviewed-by: Stefan Roese
---
v2 changes:
- newly added in v2 series
v3 changes:
- none
v4 changes:
- adjust to ARRAY_SIZE usage
v5 changes:
- remove double space (one each line) in error message
---
cmd/mvebu/bubt.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/cmd/mvebu/bubt.c b/cmd/mvebu/bubt.c
index b03924ca06..728633e60a 100644
--- a/cmd/mvebu/bubt.c
+++ b/cmd/mvebu/bubt.c
@@ -676,6 +676,17 @@ static int a38x_check_boot_mode(const struct bubt_dev *dst)
if (a38x_boot_modes[mode].id == hdr->blockid)
return 0;
+ for (int i = 0; i < ARRAY_SIZE(a38x_boot_modes); i++) {
+ if (a38x_boot_modes[i].id == hdr->blockid) {
+ printf("Error: image meant to be booted from"
+ " \"%s\", not \"%s\"!\n",
+ a38x_boot_modes[i].name, dst->name);
+ return -ENOEXEC;
+ }
+ }
+
+ printf("Error: unknown boot device in image header: 0x%x\n",
+ hdr->blockid);
return -ENOEXEC;
}
@@ -746,7 +757,6 @@ static int bubt_verify(const struct bubt_dev *dst)
if (IS_ENABLED(CONFIG_ARMADA_38X)) {
err = a38x_check_boot_mode(dst);
if (err) {
- puts("Error: image not built for destination
device!\n");
return err;
}
}
--
2.25.0
[PATCH v5 1/5] cmd: mvebu: bubt: add A38x support
Add support for Armada 38x devices in bubt flashing utility.
This is based on (and streamlined from) the support in the SolidRun
master-a38x vendor fork.
Signed-off-by: Joel Johnson
Reviewed-by: Stefan Roese
---
v2 changes
- none
v3 changes
- none
v4 changes
- none
v5 changes
- none
---
cmd/mvebu/bubt.c | 69 +++-
1 file changed, 68 insertions(+), 1 deletion(-)
diff --git a/cmd/mvebu/bubt.c b/cmd/mvebu/bubt.c
index 2041a7a29a..d399fb6da4 100644
--- a/cmd/mvebu/bubt.c
+++ b/cmd/mvebu/bubt.c
@@ -85,7 +85,29 @@ struct mvebu_image_info {
u32 encrypt_start_offset;
u32 encrypt_size;
};
-#endif /* CONFIG_ARMADA_XXX */
+#elif defined(CONFIG_ARMADA_38X) /* A38X */
+
+/* Structure of the main header, version 1 (Armada 370/38x/XP) */
+struct a38x_main_hdr_v1 {
+ u8 blockid; /* 0x0 */
+ u8 flags; /* 0x1 */
+ u16 reserved2; /* 0x2-0x3 */
+ u32 blocksize; /* 0x4-0x7 */
+ u8 version; /* 0x8 */
+ u8 headersz_msb; /* 0x9 */
+ u16 headersz_lsb; /* 0xA-0xB */
+ u32 srcaddr; /* 0xC-0xF */
+ u32 destaddr; /* 0x10-0x13 */
+ u32 execaddr; /* 0x14-0x17 */
+ u8 options; /* 0x18 */
+ u8 nandblocksize; /* 0x19 */
+ u8 nandbadblklocation;/* 0x1A */
+ u8 reserved4; /* 0x1B */
+ u16 reserved5; /* 0x1C-0x1D */
+ u8 ext; /* 0x1E */
+ u8 checksum; /* 0x1F */
+};
+#endif
struct bubt_dev {
char name[8];
@@ -621,7 +643,52 @@ static int check_image_header(void)
return 0;
}
+#elif defined(CONFIG_ARMADA_38X)
+static size_t a38x_header_size(const struct a38x_main_hdr_v1 *h)
+{
+ if (h->version == 1)
+ return (h->headersz_msb << 16) | le16_to_cpu(h->headersz_lsb);
+
+ printf("Error: Invalid A38x image (header version 0x%x unknown)!\n",
+ h->version);
+ return 0;
+}
+
+static uint8_t image_checksum8(const void *start, size_t len)
+{
+ u8 csum = 0;
+ const u8 *p = start;
+
+ while (len) {
+ csum += *p;
+ ++p;
+ --len;
+ }
+
+ return csum;
+}
+static int check_image_header(void)
+{
+ u8 checksum;
+ const struct a38x_main_hdr_v1 *hdr =
+ (struct a38x_main_hdr_v1 *)get_load_addr();
+ const size_t image_size = a38x_header_size(hdr);
+
+ if (!image_size)
+ return -ENOEXEC;
+
+ checksum = image_checksum8(hdr, image_size);
+ checksum -= hdr->checksum;
+ if (checksum != hdr->checksum) {
+ printf("Error: Bad A38x image checksum. 0x%x != 0x%x\n",
+ checksum, hdr->checksum);
+ return -ENOEXEC;
+ }
+
+ printf("Image checksum...OK!\n");
+ return 0;
+}
#else /* Not ARMADA? */
static int check_image_header(void)
{
--
2.25.0
[PATCH v5 3/5] cmd: mvebu: bubt: verify A38x target device type
Ensure that the device to which an image is being written includes
header information indicating boot support for the destination
device.
This is derived from the support in the SolidRun master-a38x vendor
fork.
Signed-off-by: Joel Johnson
Reviewed-by: Stefan Roese
---
v2 changes:
- none
v3 changes:
- use ARRAY_SIZE instead of #define size
v4 changes:
- none
v5 changes:
- use if(IS_ENABLED()) for inline check instead of ifdef
---
cmd/mvebu/bubt.c | 47 +--
1 file changed, 45 insertions(+), 2 deletions(-)
diff --git a/cmd/mvebu/bubt.c b/cmd/mvebu/bubt.c
index b80b81c82a..b03924ca06 100644
--- a/cmd/mvebu/bubt.c
+++ b/cmd/mvebu/bubt.c
@@ -107,6 +107,24 @@ struct a38x_main_hdr_v1 {
u8 ext; /* 0x1E */
u8 checksum; /* 0x1F */
};
+
+struct a38x_boot_mode {
+ unsigned int id;
+ const char *name;
+};
+
+/* The blockid header field values used to indicate boot device of image */
+struct a38x_boot_mode a38x_boot_modes[] = {
+ { 0x4D, "i2c" },
+ { 0x5A, "spi" },
+ { 0x69, "uart" },
+ { 0x78, "sata" },
+ { 0x8B, "nand" },
+ { 0x9C, "pex" },
+ { 0xAE, "mmc" },
+ {},
+};
+
#endif
struct bubt_dev {
@@ -644,6 +662,23 @@ static int check_image_header(void)
return 0;
}
#elif defined(CONFIG_ARMADA_38X)
+static int a38x_check_boot_mode(const struct bubt_dev *dst)
+{
+ int mode;
+ const struct a38x_main_hdr_v1 *hdr =
+ (struct a38x_main_hdr_v1 *)get_load_addr();
+
+ for (mode = 0; mode < ARRAY_SIZE(a38x_boot_modes); mode++) {
+ if (strcmp(a38x_boot_modes[mode].name, dst->name) == 0)
+ break;
+ }
+
+ if (a38x_boot_modes[mode].id == hdr->blockid)
+ return 0;
+
+ return -ENOEXEC;
+}
+
static size_t a38x_header_size(const struct a38x_main_hdr_v1 *h)
{
if (h->version == 1)
@@ -697,7 +732,7 @@ static int check_image_header(void)
}
#endif
-static int bubt_verify(size_t image_size)
+static int bubt_verify(const struct bubt_dev *dst)
{
int err;
@@ -708,6 +743,14 @@ static int bubt_verify(size_t image_size)
return err;
}
+ if (IS_ENABLED(CONFIG_ARMADA_38X)) {
+ err = a38x_check_boot_mode(dst);
+ if (err) {
+ puts("Error: image not built for destination
device!\n");
+ return err;
+ }
+ }
+
return 0;
}
@@ -829,7 +872,7 @@ int do_bubt_cmd(cmd_tbl_t *cmdtp, int flag, int argc, char
* const argv[])
if (!image_size)
return -EIO;
- err = bubt_verify(image_size);
+ err = bubt_verify(dst);
if (err)
return err;
--
2.25.0
[PATCH v5 4/5] arm: mvebu: clearfog: enable bubt command
With support added for Armada 38x, include the bubt command in ClearFog defconfig. Signed-off-by: Joel Johnson Reviewed-by: Stefan Roese --- v2 changes: - none v3 changes: - none v4 changes: - none v5 changes: - none --- configs/clearfog_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig index c938448c30..0d7e19e731 100644 --- a/configs/clearfog_defconfig +++ b/configs/clearfog_defconfig @@ -35,6 +35,7 @@ CONFIG_SPL_CMD_TLV_EEPROM=y CONFIG_CMD_GPIO=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y +CONFIG_CMD_MVEBU_BUBT=y CONFIG_CMD_PCI=y CONFIG_CMD_SPI=y CONFIG_CMD_USB=y -- 2.25.0
[PATCH v5 2/5] cmd: mvebu: bubt: correct U-Boot spelling
Replace "U-BOOT" text with correct spelling
Signed-off-by: Joel Johnson
Reviewed-by: Stefan Roese
---
v2 changes:
- none
v3 changes:
- none
v4 changes:
- none
v5 changes:
- none
---
cmd/mvebu/bubt.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/cmd/mvebu/bubt.c b/cmd/mvebu/bubt.c
index d399fb6da4..b80b81c82a 100644
--- a/cmd/mvebu/bubt.c
+++ b/cmd/mvebu/bubt.c
@@ -346,7 +346,7 @@ static int nand_burn_image(size_t image_size)
/* Align U-Boot size to currently used blocksize */
image_size = ((image_size + (block_size - 1)) & (~(block_size - 1)));
- /* Erase the U-BOOT image space */
+ /* Erase the U-Boot image space */
printf("Erasing 0x%x - 0x%x:...", 0, (int)image_size);
ret = nand_erase(mtd, 0, image_size);
if (ret) {
@@ -734,7 +734,7 @@ static int bubt_read_file(struct bubt_dev *src)
static int bubt_is_dev_active(struct bubt_dev *dev)
{
if (!dev->active) {
- printf("Device \"%s\" not supported by U-BOOT image\n",
+ printf("Device \"%s\" not supported by U-Boot image\n",
dev->name);
return 0;
}
@@ -822,7 +822,7 @@ int do_bubt_cmd(cmd_tbl_t *cmdtp, int flag, int argc, char
* const argv[])
if (!bubt_is_dev_active(src))
return -ENODEV;
- printf("Burning U-BOOT image \"%s\" from \"%s\" to \"%s\"\n",
+ printf("Burning U-Boot image \"%s\" from \"%s\" to \"%s\"\n",
net_boot_file_name, src->name, dst->name);
image_size = bubt_read_file(src);
--
2.25.0
Re: Totally wrecked my ENV
Dear Udo, In message you wrote: > > while trying to set the mac-address of a device in u-boot I somehow > wrecked the whole thing. > > I think I did 'setenv eth0addr xx:xx:xx:xx:xx:xx' followed by 'saveenv' > After that, my device tells me "Unknown command 'run' - try 'help'" and > also "Unknown command 'env' - try 'help'" I can't imagine of a situation where a correctly running U-Boot would suffer in such a way from any misspelled environment settings. > I seemed to me that some wrong quoting in the above 'setenv' command > messed up all the strings. No, the cause of the problem must be elsewhere. > I'm lost now, how can I achienve a total reset of my ENV? Resetting your environment will not help. When U-Boot cannot find command names like run or printenv, it's internal data stuctures have been corrupted, and this will not go away if you clean up the environment. You must reflash the whole U-Boot image. If you can still boot into Linux, I would use this to write the new U-Boot image, as you cannot really trust your U-Boot any more. If not, and you can still load and flash an image in U-Boot, then try that. If this doesn't work either, then you probably have to use a JTAG debugger (if you have a JTAG connector on your board). Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de There are two ways to write error-free programs. Only the third one works.
Re: [PATCH v3 5/5] cmd: mvebu: bubt: show image boot device
On 2020-03-24 01:28, Stefan Roese wrote:
On 23.03.20 18:43, Joel Johnson wrote:
When a mismatch is found trying to write an image for one boot method
to a different boot device, print an error message including the image
header marked target boot device type.
Signed-off-by: Joel Johnson
Reviewed-by: Stefan Roese
---
v2 changes:
- newly added in v2 series
v3 changes:
- none
---
cmd/mvebu/bubt.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/cmd/mvebu/bubt.c b/cmd/mvebu/bubt.c
index fbcad37c40..f992507041 100644
--- a/cmd/mvebu/bubt.c
+++ b/cmd/mvebu/bubt.c
@@ -676,6 +676,17 @@ static int a38x_check_boot_mode(const struct
bubt_dev *dst)
if (a38x_boot_modes[mode].id == hdr->blockid)
return 0;
+ for (int i = 0; i < A38X_BOOT_MODE_MAX; i++) {
This will fail, as A38X_BOOT_MODE_MAX is not defined any more. Please
use ARRAY_SIZE() here as well.
Thanks,
Stefan
Yeah, I caught that but missed committing it for this series - I'd sent
out a v4 with this fixed. A v5 with your other ifdef change will include
it.
Joel
Re: [PATCH v2 1/2] spi: call WATCHDOG_RESET() in spi_nor_wait_till_ready_with_timeout()
Dear Wolfgang,
On 20/03/20 4:48 pm, Wolfgang Denk wrote:
> Dear Vignesh,
>
> In message <20200320101448.10714-1-rasmus.villem...@prevas.dk> Rasmus
> Villemoes wrote:
>> I have a board for which doing "sf erase 0x10 0x8"
>> consistently causes the external watchdog circuit to reset the
>> board. Make sure to pet the watchdog during slow operations such as
>> erasing or writing large areas of a spi nor flash.
> ...
>
>> drivers/mtd/spi/spi-nor-core.c | 2 ++
>> drivers/mtd/spi/spi-nor-tiny.c | 2 ++
>
> Rasmus' patch triggers a few interesting questions about the SPI NOR
> code:
>
>
> Is there any specific reason why spi-nor-core.c and spi-nor-tiny.c
> contain large parts of absolutely identical code?
>
Aim of spi-nor-tiny.c is to have a tiny stack that can be used in
SPL/TPL or on resource constraint boards to only support _reading_ from
the flash. So tiny stack would be subset of spi-nor-core.
There are few options here:
One is to have single driver and hide things that are not required for
tiny stack under #ifdef. But this makes code harder to read and modify
Second option, is to factor out common functions into a separate file as
a library. This would avoid ifdef'ry. But whenever a new feature is
added that would add to the size of these common functions, it would be
probably mean moving it out of common library and into individual
stacks. This may need to unnecessary code churn whenever a new feature
is added.
So, suggestion was to add a parallel tiny stack (which was supposed to
plug into tiny read only MTD stack) that only supports reading from
flash. This would mean that new features can be freely added to
spi-nor-core.c without worrying about bloating SPL for older devices.
If the opinion is to switch to second option now, then I can rework the
framework. But note that this would make adding new features bit harder
due to need to maintain size of spi-nor-tiny.c.
Please, let me know?
> All the functions
>
> spi_nor_read_write_reg()
> spi_nor_read_reg()
> spi_nor_write_reg()
> spi_nor_read_data()
> mtd_to_spi_nor()
> spi_nor_convert_opcode()
> spi_nor_ready()
> spi_nor_wait_till_ready_with_timeout()
> spi_nor_wait_till_ready()
> macronix_quad_enable()
> spansion_read_cr_quad_enable()
> spi_nor_set_read_settings()
>
>
> are absolutely identical;
>
> functions
>
> read_cr()
> write_sr()
> write_disable()
> set_4byte()
> spi_nor_read()
> write_sr_cr()
>
> are mostly identical, but I wonder if the differences (like
> nor->write_reg() versus spi_nor_write_reg()) is indeed intended to
> save memory footprint or lack an update to later code?
>
I am in the process of dropping nor->*() functions altogether as I don't
see any users outside of spi-nor-core.c
Note that some of these will no longer be same with 8D-8D-8D support[1]
thus further reducing the similarities.
[1] https://patchwork.ozlabs.org/project/uboot/list/?series=166175
> Function
>
> spi_nor_convert_3to4_read()
> spi_nor_set_4byte_opcodes()
>
> looks like it has not been updated/synced for some time.
Thats intentional... Adding Octal mode support to tiny stack would add
to code size and possibly break few boards.
Any addition to spi-nor-tiny.c should be debated whether or not that
change is absolutely needed for low footprint boards.
>
> Function
>
> spi_nor_sr_ready()
> spi_nor_fsr_ready()
>
> is lacking error handling in spi-nor-tiny.c; and the rror handling
> code in spi-nor-core.c is also mostly duplicated a couple or times.
>
Error handling is not required, as tiny stack does not support writing
to flash and these errors are raised when writing or erasing flash.
>
> Function
>
> spi_nor_read_id()
>
> differs in "interesting" ways, i. e. we have
>
> 370 info = spi_nor_ids;
> 371 for (; info->sector_size != 0; info++) {
> 372 if (info->id_len) {
>
> here, and
In case of tiny stack, we save space by not storing flash names in
spi_nor_ids[] table (its a significant saving) and hence have to rely on
another field to detect EOL.
>
> 894 info = spi_nor_ids;
> 895 for (; info->name; info++) {
> 896 if (info->id_len) {
>
> there, while all the rest is idential. Lack of synchronization?
>
>
> Also the differences in
>
> spi_nor_select_read()
>
> make we wonder...
>
>
>
> This extensive code duplication looks really painful and error prone
> to me.
Duplication is to avoid feature creep leading to increase in code size.
But I can factor out common code if there is a wider agreement.
>
> Do you have any intentions to clean this up any time soon?
>
> Best regards,
>
> Wolfgang Denk
>
[PATCH] x86: spi: Only use the fast SPI peripheral when support
At present we query the memory map on boards which don't support it. Fix
this by only doing it on Apollo Lake.
This fixes booting on chromebook_link.
Signed-off-by: Simon Glass
Fixes: 92842147c31 ("spi: ich: Add support for get_mmap() method")
---
drivers/spi/ich.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/spi/ich.c b/drivers/spi/ich.c
index a9d7715a55..9f8af45242 100644
--- a/drivers/spi/ich.c
+++ b/drivers/spi/ich.c
@@ -637,7 +637,10 @@ static int ich_get_mmap(struct udevice *dev, ulong
*map_basep, uint *map_sizep,
uint *offsetp)
{
struct udevice *bus = dev_get_parent(dev);
+ struct ich_spi_platdata *plat = dev_get_platdata(bus);
+ if (plat->ich_version != ICHV_APL)
+ return -ENOENT;
return ich_get_mmap_bus(bus, map_basep, map_sizep, offsetp);
}
--
2.25.1.696.g5e7596f4ac-goog
[PATCH v3] board: stm32mp1: add finished good in board identifier OTP
Update the command stboard to support the updated coding of OTP 59 with
finished good.
The ST product codification have several element
- "Commercial Product Name" (CPN): type of product board (DKX, EVX)
associated to the board ID "MB"
- "Finished Good" or "Finish Good" (FG):
effective content of the product without chip STM32MP1 (LCD, Wifi, …)
- BOM: cost variant for same FG
(for example, several provider of the same component)
For example
- commercial product = STM32MP157C-EV1
- Finished Good = EVA32MP157A1$AU1
Booth information are written on board and these information is also saved
in OTP59:
bit [31:16] (hex) => Board id, MB
bit [15:12] (dec) => Variant CPN (115)
bit [11:8] (dec) => Revision board (index with A = 1, Z = 26)
bit [7:4] (dec) => Variant FG : finished good (NEW)
bit [3:0] (dec) => BOM (01, 255)
The updated command is:
stboard [-y]
And the displayed STMicroelectronics board identification is:
Board: MB Var. Rev.-
Signed-off-by: Patrick Delaunay
Reviewed-by: Patrice Chotard
---
Changes in v3:
- fix comment after Patrice Chotard review
Changes in v2:
- update commit message
- add comments in cmd_stboard.c
board/st/common/cmd_stboard.c | 60 ---
board/st/stm32mp1/stm32mp1.c | 4 ++-
2 files changed, 52 insertions(+), 12 deletions(-)
diff --git a/board/st/common/cmd_stboard.c b/board/st/common/cmd_stboard.c
index 1573e35410..915164aa0b 100644
--- a/board/st/common/cmd_stboard.c
+++ b/board/st/common/cmd_stboard.c
@@ -1,6 +1,32 @@
// SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
/*
* Copyright (C) 2019, STMicroelectronics - All Rights Reserved
+ *
+ * the st command stboard supports the STMicroelectronics board identification
+ * saved in OTP 59.
+ *
+ * The ST product codification have several element
+ * - "Commercial Product Name" (CPN): type of product board (DKX, EVX)
+ * associated to the board ID "MB"
+ * - "Finished Good" or "Finish Good" (FG):
+ * effective content of the product without chip STM32MP1xx (LCD, Wifi,…)
+ * - BOM: cost variant for same FG (for example, several provider of the same
+ * component)
+ *
+ * For example
+ * - commercial product = STM32MP157C-EV1 for board MB1263
+ * - Finished Good = EVA32MP157A1$AU1
+ *
+ * Both information are written on board and these information are also saved
+ * in OTP59, with:
+ * bit [31:16] (hex) => Board id, MB
+ * bit [15:12] (dec) => Variant CPN (115)
+ * bit [11:8] (dec) => Revision board (index with A = 1, Z = 26)
+ * bit [7:4] (dec) => Variant FG : finished good index
+ * bit [3:0] (dec) => BOM (01, 255)
+ *
+ * and displayed with the format:
+ * Board: MB Var. Rev.-
*/
#ifndef CONFIG_SPL_BUILD
@@ -13,6 +39,7 @@
static bool check_stboard(u16 board)
{
unsigned int i;
+ /* list of supported ST boards */
const u16 st_board_id[] = {
0x1272,
0x1263,
@@ -31,9 +58,11 @@ static bool check_stboard(u16 board)
static void display_stboard(u32 otp)
{
- printf("Board: MB%04x Var%d Rev.%c-%02d\n",
+ /* display board indentification with OPT coding */
+ printf("Board: MB%04x Var%d.%d Rev.%c-%02d\n",
otp >> 16,
(otp >> 12) & 0xF,
+ (otp >> 4) & 0xF,
((otp >> 8) & 0xF) - 1 + 'A',
otp & 0xF);
}
@@ -44,14 +73,14 @@ static int do_stboard(cmd_tbl_t *cmdtp, int flag, int argc,
int ret;
u32 otp, lock;
u8 revision;
- unsigned long board, variant, bom;
+ unsigned long board, var_cpn, var_fg, bom;
struct udevice *dev;
- int confirmed = argc == 6 && !strcmp(argv[1], "-y");
+ int confirmed = argc == 7 && !strcmp(argv[1], "-y");
argc -= 1 + confirmed;
argv += 1 + confirmed;
- if (argc != 0 && argc != 4)
+ if (argc != 0 && argc != 5)
return CMD_RET_USAGE;
ret = uclass_get_device_by_driver(UCLASS_MISC,
@@ -95,8 +124,8 @@ static int do_stboard(cmd_tbl_t *cmdtp, int flag, int argc,
return CMD_RET_USAGE;
}
- if (strict_strtoul(argv[1], 10, ) < 0 ||
- variant == 0 || variant > 15) {
+ if (strict_strtoul(argv[1], 10, _cpn) < 0 ||
+ var_cpn == 0 || var_cpn > 15) {
printf("argument %d invalid: %s\n", 2, argv[1]);
return CMD_RET_USAGE;
}
@@ -107,13 +136,21 @@ static int do_stboard(cmd_tbl_t *cmdtp, int flag, int
argc,
return CMD_RET_USAGE;
}
- if (strict_strtoul(argv[3], 10, ) < 0 ||
+ if (strict_strtoul(argv[3], 10, _fg) < 0 ||
+ var_fg > 15) {
+ printf("argument %d invalid: %s\n", 4, argv[3]);
+ return CMD_RET_USAGE;
+ }
+
+ if (strict_strtoul(argv[4], 10, ) < 0 ||
bom == 0 || bom > 15) {
printf("argument %d invalid: %s\n", 4, argv[3]);
return
[PATCH v2] tools: fw_env: use erasesize from MEMGETINFO ioctl
We have a board with several revisions. The older ones use a nor flash with 64k erase size, while the newer have a flash with 4k sectors. The environment size is 8k. Currently, we have to put a column containing 0x1 (64k) in fw_env.config in order for it to work on the older boards. But that ends up wasting quite a lot of time on the newer boards that could just erase the 8k occupied by the environment - strace says the 64k erase takes 0.405 seconds. With this patch, as expected, that's about an 8-fold better, at 0.043 seconds. Having different fw_env.config files for the different revisions is highly impractical, and the correct information is already available right at our fingertips. So use the erasesize returned by the MEMGETINFO ioctl when the fourth and fifth columns (sector size and #sectors, respectively) are absent or contain 0, a case where the logic previously used to use the environment size as erase size (and consequently computed ENVSECTORS(dev) as 1). As I'm only testing this on a NOR flash, I'm only changing the logic for that case, though I think it should be possible for the other types as well. Signed-off-by: Rasmus Villemoes --- v2: Also require ENVSECTORS(dev) to be absent (or 0) to apply this, in order to prevent regressions in the somewhat odd case where someone used 0 as sector size (and hence used the environment size as sector size) and explicitly listed 1 as #sectors. tools/env/fw_env.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c index 381739d28d..8734663cd4 100644 --- a/tools/env/fw_env.c +++ b/tools/env/fw_env.c @@ -1647,6 +1647,9 @@ static int check_device_config(int dev) goto err; } DEVTYPE(dev) = mtdinfo.type; + if (DEVESIZE(dev) == 0 && ENVSECTORS(dev) == 0 && + mtdinfo.type == MTD_NORFLASH) + DEVESIZE(dev) = mtdinfo.erasesize; if (DEVESIZE(dev) == 0) /* Assume the erase size is the same as the env-size */ DEVESIZE(dev) = ENVSIZE(dev); -- 2.23.0
[RFH] ath79: chunking diff from wndr3800 tarball
Please note this email has two parts: the technical / working on stuff part and some footnotes[1]. Please do not reply to the footnotes on list. While they are u-boot related they are only included for reasons outlined in[2]. I know I'm late to the party but I ended up wanting to replace the u-boot on my various Netgear WNDR3800 devices[1]. This led to looking for support in current master (not present; there is some ar71xx/ath79 support but not enough (from what I can see) and the wndr3800 also requires an rtl8366s driver which is not currently available in u-boot. Unfortunately there are reasons, which I discovered, that the support has never made it into master. The fact that the devices are based on a highly modified version of u-boot from a point between 1.1.4 and 1.1.5, combined with the fact the mod looks (to me) rather ugly has hindered efforts to get the support into mainline. One can see the >43k-line diff (although some of that is context) at https://github.com/cshoredaniel/u-boot-wndr3800/commit/145826194799377f48671fb3354f3bed159a21c7 which is based on copying the Netgear open source tarball onto https://github.com/cshoredaniel/u-boot-wndr3800/commit/5fbb2cd3b1b11352dfb73f0b8326c323662182a8 (upstream u-boot commit 5fbb2cd3b) which is the commit of the last changelog message that appears in netgear tarball. It looks like there may be some other commits without changelog entries that are in the tarball code, which I have not yet identified. It be nice to have help with that, if there is anyone still interested in this support, since even though I could do it, there is a rather a big chunk of work to do, and it'd go faster with help. It is my thought that rather than trying to use huge diff to identify what needs to be added to mainline, that the first step is to take a relaxed tree (the github repo from I've pointed to specific commits above) and split the diff into separate commits that are more like the kind of commits one would normally see (that is reasonably small commits that are changing the base code for a narrow and specific purpose). If you are aware of someone who has already done this, or part of it, please point me to the code! For that matter any docs or work that's already been done, I'd like to know about. So far I've taken a brief look at the OpenWrt ar71xx for a different device (which looks like it can help) and https://github.com/pepe2k/u-boot_mod (which doesn't because it looks more like hacking on top of merge of various ar71xx tarballs, although I haven't looked closely; that and the README specifically warns against trying to use that repo get anything upstream (here)). I've seen the occasional patch series to add ar71xx support to mainline, but from a *brief* peek it looks like it was more a case taking chunks of the tarball diff, and merging against mainline, without actually understanding mainline and/or the tarball. I'm trying to avoid doing that, but first the diff needs to be chunked into manageable bits. I'll be working on it, but any help in getting there would appreciated (this is a side scratch-my-own-itch project so it won't happen quickly, if it all, without help). I know I have reading and learning to do on mainline to make this happen too, but I'm not sure how much help can be offered there other me just reading the available docs and poking away at the sandbox and x86 and/or qemu versions (which are the supported devices I currently have available). So, please, if anyone can offer help and/or helpful suggestions, info, or advice, it would be appreciated. === Footnotes: Do not reply to anything below here on the u-boot mailing list[2] [1] The short summary is that I ended up needing to use the u-boot serial console to recover a soft-bricked WNDR3800 and thought that the devices I'd bought on eBay had been maliciously altered. I turns out that the reboot behavior of advertising the router's readiness to accept a firmware, and being able to reflash the router over the network was by design. (You read that right, on boot a number of netgear devices *advertise* themselves as reflashable over the network and accepts firmware via a protocol netgear calls NMRP -- am I the only one who wonders what exec in their right mind thought this was fine for millions of production units, and am boggled that it's real? ) (For the curious the main NMRP code sections are in these files: https://github.com/cshoredaniel/u-boot-wndr3800/commit/145826194799377f48671fb3354f3bed159a21c7#diff-158d650f8c314f5cf37ed472eed53b5b, https://github.com/cshoredaniel/u-boot-wndr3800/commit/145826194799377f48671fb3354f3bed159a21c7#diff-6e2be3e4732599d1f72e8f01bc470020, https://github.com/cshoredaniel/u-boot-wndr3800/commit/145826194799377f48671fb3354f3bed159a21c7#diff-672b862a81954376cf7802c24acc3791,
[PATCH] serial: zynq: Change uart initialization logic
The commit a673025535ae ("serial: zynq: Initialize uart only before
relocation") introduced code which detects relocation which is working for
single uart instance. With multiple instances in place there is a need to
enable and setup every instance. That's why detect if TX is enabled. If it
is then don't initialize uart again.
In post probe setbrg is called to setup baudrate but values should be the
same.
As a side effect of this change is that DECLARE_GLOBAL_DATA_PTR can be
removed completely.
Signed-off-by: Michal Simek
---
drivers/serial/serial_zynq.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/serial/serial_zynq.c b/drivers/serial/serial_zynq.c
index e4e4c3928582..0dd6cec82a65 100644
--- a/drivers/serial/serial_zynq.c
+++ b/drivers/serial/serial_zynq.c
@@ -17,8 +17,6 @@
#include
#include
-DECLARE_GLOBAL_DATA_PTR;
-
#define ZYNQ_UART_SR_TXACTIVE BIT(11) /* TX active */
#define ZYNQ_UART_SR_TXFULLBIT(4) /* TX FIFO full */
#define ZYNQ_UART_SR_RXEMPTY BIT(1) /* RX FIFO empty */
@@ -45,7 +43,7 @@ struct zynq_uart_platdata {
struct uart_zynq *regs;
};
-/* Set up the baud rate in gd struct */
+/* Set up the baud rate */
static void _uart_zynq_serial_setbrg(struct uart_zynq *regs,
unsigned long clock, unsigned long baud)
{
@@ -140,9 +138,12 @@ static int zynq_serial_setbrg(struct udevice *dev, int
baudrate)
static int zynq_serial_probe(struct udevice *dev)
{
struct zynq_uart_platdata *platdata = dev_get_platdata(dev);
+ struct uart_zynq *regs = platdata->regs;
+ u32 val;
- /* No need to reinitialize the UART after relocation */
- if (gd->flags & GD_FLG_RELOC)
+ /* No need to reinitialize the UART if TX already enabled */
+ val = readl(>control);
+ if (val & ZYNQ_UART_CR_TX_EN)
return 0;
_uart_zynq_serial_init(platdata->regs);
--
2.25.1
Re: [PATCH 2/2] uboot: fs/btrfs: Fix LZO false decompression error caused by pending zero
On 2020/3/20 上午12:28, David Sterba wrote: > On Thu, Mar 19, 2020 at 03:34:12PM +0100, Matthias Brugger wrote: >> >> >> On 19/03/2020 14:56, David Sterba wrote: >>> On Thu, Mar 19, 2020 at 02:33:28PM +0100, Matthias Brugger wrote: > dlen -= out_len; > > res += out_len; > + > + /* > + * If the 4 bytes header does not fit to the rest of the page we > + * have to move to next one, or we read some garbage. > + */ > + mod_page = tot_in % PAGE_SIZE; in U-Boot we use 4K page sizes, but the OS could use another page size (16K or 64k). Would we need to adapt that code to reflect which page size is used on the medium we want to access? >>> >>> Yes, it is the 'sectorsize' as it's set up in fs_info or it's equivalent >>> in uboot. For kernel the page size == sectorsize is kind of implicit and >>> verified at mount time. >>> >> >> Does this mean we would need to add a Kconfig option to set the sectorsize in >> U-Boot? > > No, the value depends on the filesystem so it can't be a config option. > What I mean is btrfs_super_block::sectorsize, where the superblock is > btrfs_info::sb. > Sorry for the delayed reply. (Stupid filter setup). Currently most Uboot boards should use the same page size setup for its kernel, and most btrfs uses 4K sector size. So for Uboot it should be no problem. Although the best practice is to read the fs_info::sectorsize as David mentioned, but the code base doesn't allow us to do that yet. So I'm going to backport the read part code from btrfs-progs in the near-future, and completely solve it, making it sector size independent. Would this plan looks sound? Or we need to wait for the full re-implementation? Thanks, Qu signature.asc Description: OpenPGP digital signature
Re: [PATCH 2/2] uboot: fs/btrfs: Fix LZO false decompression error caused by pending zero
On 2020/3/20 上午12:28, David Sterba wrote: > On Thu, Mar 19, 2020 at 03:34:12PM +0100, Matthias Brugger wrote: >> >> >> On 19/03/2020 14:56, David Sterba wrote: >>> On Thu, Mar 19, 2020 at 02:33:28PM +0100, Matthias Brugger wrote: > dlen -= out_len; > > res += out_len; > + > + /* > + * If the 4 bytes header does not fit to the rest of the page we > + * have to move to next one, or we read some garbage. > + */ > + mod_page = tot_in % PAGE_SIZE; in U-Boot we use 4K page sizes, but the OS could use another page size (16K or 64k). Would we need to adapt that code to reflect which page size is used on the medium we want to access? >>> >>> Yes, it is the 'sectorsize' as it's set up in fs_info or it's equivalent >>> in uboot. For kernel the page size == sectorsize is kind of implicit and >>> verified at mount time. >>> >> >> Does this mean we would need to add a Kconfig option to set the sectorsize in >> U-Boot? > > No, the value depends on the filesystem so it can't be a config option. > What I mean is btrfs_super_block::sectorsize, where the superblock is > btrfs_info::sb. > Sorry for the delayed reply. (Stupid filter setup). Currently most Uboot boards should use the same page size setup for its kernel, and most btrfs uses 4K sector size. So for Uboot it should be no problem. Although the best practice is to read the fs_info::sectorsize as David mentioned, but the code base doesn't allow us to do that yet. So I'm going to backport the read part code from btrfs-progs in the near-future, and completely solve it, making it sector size independent. Would this plan look OK to you? Or we need to wait for the full re-implementation? Thanks, Qu signature.asc Description: OpenPGP digital signature
Re: [Uboot-stm32] [PATCH v2] board: stm32mp1: add finished good in board identifier OTP
Hi Patrick
On 3/24/20 9:05 AM, Patrick Delaunay wrote:
> Update the command stboard to support the updated coding of OTP 59 with
> finished good.
>
> The ST product codification have several element
> - "Commercial Product Name" (CPN): type of product board (DKX, EVX)
> associated to the board ID "MB"
> - "Finished Good" or "Finish Good" (FG):
> effective content of the product without chip STM32MP1 (LCD, Wifi, …)
> - BOM: cost variant for same FG
> (for example, several provider of the same component)
>
> For example
> - commercial product = STM32MP157C-EV1
> - Finished Good = EVA32MP157A1$AU1
>
> Booth information are written on board and this information is also saved
> in OTP59:
s/Booth/Both
s/this information is/these information are
>
> bit [31:16] (hex) => Board id, MB
> bit [15:12] (dec) => Variant CPN (115)
> bit [11:8] (dec) => Revision board (index with A = 1, Z = 26)
> bit [7:4] (dec) => Variant FG : finished good (NEW)
> bit [3:0] (dec) => BOM (01, 255)
>
> The updated command is:
> stboard [-y]
>
> And the displayed STMicroelectronics board identification is:
> Board: MB Var. Rev.-
>
>
> Signed-off-by: Patrick Delaunay
> ---
>
> Changes in v2:
> - update commit message
> - add comments in cmd_stboard.c
>
> board/st/common/cmd_stboard.c | 60 ---
> board/st/stm32mp1/stm32mp1.c | 4 ++-
> 2 files changed, 52 insertions(+), 12 deletions(-)
>
> diff --git a/board/st/common/cmd_stboard.c b/board/st/common/cmd_stboard.c
> index 1573e35410..78f99daead 100644
> --- a/board/st/common/cmd_stboard.c
> +++ b/board/st/common/cmd_stboard.c
> @@ -1,6 +1,32 @@
> // SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
> /*
> * Copyright (C) 2019, STMicroelectronics - All Rights Reserved
> + *
> + * the st command stboard supports the STMicroelectronics board
> identification
> + * saved in OTP 59.
> + *
> + * The ST product codification have several element
> + * - "Commercial Product Name" (CPN): type of product board (DKX, EVX)
> + * associated to the board ID "MB"
> + * - "Finished Good" or "Finish Good" (FG):
> + * effective content of the product without chip STM32MP1xx (LCD, Wifi,…)
> + * - BOM: cost variant for same FG (for example, several provider of the same
> + * component)
> + *
> + * For example
> + * - commercial product = STM32MP157C-EV1 for board MB1263
> + * - Finished Good = EVA32MP157A1$AU1
> + *
> + * Booth information are written on board and this information is also saved
> + * in OTP59, with:
> + * bit [31:16] (hex) => Board id, MB
> + * bit [15:12] (dec) => Variant CPN (115)
> + * bit [11:8] (dec) => Revision board (index with A = 1, Z = 26)
> + * bit [7:4] (dec) => Variant FG : finished good index
> + * bit [3:0] (dec) => BOM (01, 255)
> + *
> + * and displayed with the format:
> + * Board: MB Var. Rev.-
> */
>
> #ifndef CONFIG_SPL_BUILD
> @@ -13,6 +39,7 @@
> static bool check_stboard(u16 board)
> {
> unsigned int i;
> + /* list of supported ST boards */
> const u16 st_board_id[] = {
> 0x1272,
> 0x1263,
> @@ -31,9 +58,11 @@ static bool check_stboard(u16 board)
>
> static void display_stboard(u32 otp)
> {
> - printf("Board: MB%04x Var%d Rev.%c-%02d\n",
> + /* display board indentification with OPT coding */
> + printf("Board: MB%04x Var%d.%d Rev.%c-%02d\n",
> otp >> 16,
> (otp >> 12) & 0xF,
> +(otp >> 4) & 0xF,
> ((otp >> 8) & 0xF) - 1 + 'A',
> otp & 0xF);
> }
> @@ -44,14 +73,14 @@ static int do_stboard(cmd_tbl_t *cmdtp, int flag, int
> argc,
> int ret;
> u32 otp, lock;
> u8 revision;
> - unsigned long board, variant, bom;
> + unsigned long board, var_cpn, var_fg, bom;
> struct udevice *dev;
> - int confirmed = argc == 6 && !strcmp(argv[1], "-y");
> + int confirmed = argc == 7 && !strcmp(argv[1], "-y");
>
> argc -= 1 + confirmed;
> argv += 1 + confirmed;
>
> - if (argc != 0 && argc != 4)
> + if (argc != 0 && argc != 5)
> return CMD_RET_USAGE;
>
> ret = uclass_get_device_by_driver(UCLASS_MISC,
> @@ -95,8 +124,8 @@ static int do_stboard(cmd_tbl_t *cmdtp, int flag, int argc,
> return CMD_RET_USAGE;
> }
>
> - if (strict_strtoul(argv[1], 10, ) < 0 ||
> - variant == 0 || variant > 15) {
> + if (strict_strtoul(argv[1], 10, _cpn) < 0 ||
> + var_cpn == 0 || var_cpn > 15) {
> printf("argument %d invalid: %s\n", 2, argv[1]);
> return CMD_RET_USAGE;
> }
> @@ -107,13 +136,21 @@ static int do_stboard(cmd_tbl_t *cmdtp, int flag, int
> argc,
> return CMD_RET_USAGE;
> }
>
> - if (strict_strtoul(argv[3], 10, ) < 0 ||
> + if (strict_strtoul(argv[3], 10, _fg) < 0 ||
> + var_fg > 15) {
> + printf("argument %d invalid: %s\n", 4, argv[3]);
> +
RE: [PATCH] i2c: stm32f7_i2c: allows for any bus frequency
Hi > From: Patrick DELAUNAY > Sent: vendredi 6 mars 2020 11:09 > > From: Alain Volmat > > Do not limit to 3 (100KHz, 400KHz, 1MHz) bus frequencies, but instead allow > for > any frequency. Depending on the requested frequency (via the clock-frequency > DT entry), use the spec data from either Standard, Fast or Fast Plus mode. > > In order to do so, the driver do not use anymore spec identifier by directly > handle > the requested frequency and from it retrieve the corresponding spec data to be > used for the computation of the timing register. > > Signed-off-by: Alain Volmat > Reviewed-by: Patrick DELAUNAY > Signed-off-by: Patrick Delaunay > --- Applied to u-boot-stm/next, thanks! Regards Patrick
RE: [PATCH 9/9] ram: stm32mp1: the property st,phy-cal becomes optional
Hi, > From: Patrick DELAUNAY > Sent: vendredi 6 mars 2020 11:14 > > This parameter "st,phy-cal" becomes optional and when it is absent the > built-in > PHY calibration is done. > > It is the case in the helper dtsi file "stm32mp15-ddr.dtsi" > except if DDR_PHY_CAL_SKIP is defined. > > This patch also impact the ddr interactive mode > - the registers of the param 'phy.cal' are initialized to 0 when > "st,phy-cal" is not present in device tree (default behavior when > DDR_PHY_CAL_SKIP is not activated) > - the info 'cal' field can be use to change the calibration behavior > - cal=1 => use param phy.cal to initialize the PHY, built-in training > is skipped > - cal=0 => param phy.cal is absent, built-in training is used (default) > > Signed-off-by: Patrick Delaunay > --- Applied to u-boot-stm/next, thanks! Regards Patrick
RE: [PATCH 6/9] ram: stm32mp1: update BIST config for tuning
Hi, > From: Patrick DELAUNAY > Sent: vendredi 6 mars 2020 11:14 > > Update the BIST config to compute the real use mask for the real bank, row and > col of the used DDR. The values are get from addrmap register value. > > Signed-off-by: Patrick Delaunay > --- Applied to u-boot-stm/next, thanks! Regards Patrick
RE: [PATCH 8/9] ram: stm32mp1: reduce delay after BIST reset for tuning
Hi, > From: Patrick DELAUNAY > Sent: vendredi 6 mars 2020 11:14 > > Reduce the delay after BIST delay, from 1ms to 10us which is enough accoriding > datasheet. > > Signed-off-by: Patrick Delaunay > --- Applied to u-boot-stm/next, thanks! Regards Patrick
RE: [PATCH 7/9] ram: stm32mp1_ddr: fix self refresh disable during DQS training
Hi, > From: Patrick DELAUNAY > Sent: vendredi 6 mars 2020 11:14 > > DDRCTRL_PWRCTL.SELFREF_EN needs to be reset before DQS training step, > not to enter in self refresh mode during the execution of this phase. > Depending on settings, it can be set after the DQS training. > > Signed-off-by: Patrick Delaunay > --- Applied to u-boot-stm/next, thanks! Regards Patrick
RE: [PATCH 4/9] ram: stm32mp1: tuning: add timeout for polling BISTGSR.BDDONE
Hi, > From: Patrick DELAUNAY > Sent: vendredi 6 mars 2020 11:14 > > Avoid to block the tuning procedure on BIST error (not finished BIST > procedure) > by adding a 1000us timeout on the polling of BISTGSR.BDDONE executed to > detect the end of BIST. > > The normal duration of the BIST test is around 5us. > > This patch also cleanup comments. > > Signed-off-by: Patrick Delaunay > --- Applied to u-boot-stm/next, thanks! Regards Patrick
RE: [PATCH 5/9] ram: stm32mp1: tuning: deactivate derating during BIST test
Hi, > From: Patrick DELAUNAY > Sent: vendredi 6 mars 2020 11:14 > > The derating (timing parameter derating using MR4 read value) can't be > activated > during BIST test, as the MR4 read answer will be not understood by BIST > (BISTGSR.BDONE bit stay at 0, BISTWCSR.DXWCNT = 0x206 instead of > BISTWCR.BWCNT = 0x200). > > This patch only impacts the tuning on LPDDR2/LPDDR3, if > derateen.derate_enable = 1. > > Signed-off-by: Patrick Delaunay > --- Applied to u-boot-stm/next, thanks! Regards Patrick
RE: [PATCH 2/9] ram: stm32mp1: display result for software read DQS gating
Hi, > From: Patrick DELAUNAY > Sent: vendredi 6 mars 2020 11:14 > > Display result information for software read DQS gating, the tuning 0 which be > used by CubeMX DDR tuning tools. > > Signed-off-by: Patrick Delaunay > --- Applied to u-boot-stm/next, thanks! Regards Patrick
RE: [PATCH 3/9] ram: stm32mp1: don't display the prompt two times
Hi, > From: Patrick DELAUNAY > Sent: vendredi 6 mars 2020 11:14 > > Remove one "DDR>" display on command > - next > - step > - go > > Signed-off-by: Patrick Delaunay > --- Applied to u-boot-stm/next, thanks! Regards Patrick
RE: [PATCH 1/9] ram: stm32mp1: increase vdd2_ddr: buck2 for 32bits LPDDR
Hi, > From: Patrick DELAUNAY > Sent: vendredi 6 mars 2020 11:14 > > Need to increase the LPDDR2/LPDDR3 the voltage vdd2_ddr: buck2 form 1.2V to > 1.25V for 32bits configuration. > > Signed-off-by: Patrick Delaunay > --- Applied to u-boot-stm/next, thanks! Regards Patrick
RE: [PATCH v2] ARM: dts: stm32mp1: DT alignment with Linux 5.6-rc1
Hi, > From: Patrick DELAUNAY > Sent: vendredi 6 mars 2020 17:55 > > This commit manages diversity for STM32M15x SOCs with: > - dedicated files to support all STM32MP15 SOCs family. > The differences between those SOCs are: > -STM32MP151 [1]: common file. > -STM32MP153 [2]: STM32MP151 + CANs + a second CortexA7-CPU. > -STM32MP157 [3]: STM32MP153 + DSI + GPU. > - new files to manage security diversity on STM32MP15x SOCs. > On STM32MP15xY, "Y" gives information: > -Y = A means no cryp IP and no secure boot. > -Y = C means cryp IP + secure boot. > - stm32mp157 pinctrl files to better manage package diversity. > > Signed-off-by: Patrick Delaunay > --- Applied to u-boot-stm/next, thanks! Regards Patrick
Re: [PATCH v2 1/2] efi_loader: correct reported length in GetNextVariable()
Heinrich Schuchardt writes:
> The runtime service GetNextVariable() returns the length of the next
> variable including the closing 0x. This length should be in bytes.
>
> Comparing the output of EDK2 and U-Boot shows that this is currently not
> correctly implemented:
>
> EDK2:
> OsIndicationsSupported: 46
> PlatformLang: 26
> PlatformLangCodes: 36
>
> U-Boot:
> OsIndicationsSupported: 23
> PlatformLang: 13
> PlatformLangCodes: 18
>
> Provide correct length in GetNextVariable().
>
> Fixes: d99a87f84b75 ("efi_loader: implement GetNextVariableName()")
> Signed-off-by: Heinrich Schuchardt
> ---
> v2:
> correct return value of the initial call too
> ---
> lib/efi_loader/efi_variable.c | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
> index 99d2f01f57..3bec2d0d17 100644
> --- a/lib/efi_loader/efi_variable.c
> +++ b/lib/efi_loader/efi_variable.c
> @@ -273,7 +273,8 @@ static efi_status_t parse_uboot_variable(char *variable,
>u32 *attributes)
> {
> char *guid, *name, *end, c;
> - unsigned long name_len;
> + size_t name_len;
> + efi_uintn_t old_variable_name_size;
> u16 *p;
>
> guid = strchr(variable, '_');
> @@ -289,17 +290,17 @@ static efi_status_t parse_uboot_variable(char *variable,
> return EFI_INVALID_PARAMETER;
>
> name_len = end - name;
> - if (*variable_name_size < (name_len + 1)) {
> - *variable_name_size = name_len + 1;
> + old_variable_name_size = *variable_name_size;
> + *variable_name_size = sizeof(u16) * (name_len + 1);
> + if (old_variable_name_size < *variable_name_size)
> return EFI_BUFFER_TOO_SMALL;
> - }
> +
Ah I see it's fixed in this version. Please ignore my comment on the
previous version.
Thanks,
Punit
> end++; /* point to value */
>
> /* variable name */
> p = variable_name;
> utf8_utf16_strncpy(, name, name_len);
> variable_name[name_len] = 0;
> - *variable_name_size = name_len + 1;
>
> /* guid */
> c = *(name - 1);
> --
> 2.25.1
RE: [PATCH 2/2] clk: stm32mp1: add SPI5_K support
Hi, > From: Patrick DELAUNAY > Sent: lundi 9 mars 2020 14:59 > > Add clock support for SPI5, as this instance is available on extension > connector of > ST board. > > Signed-off-by: Patrick Delaunay > --- Applied to u-boot-stm/next, thanks! Regards Patrick
RE: [PATCH 1/2] clk: stm32mp1: correct CKSELR masks
Hi, > From: Patrick DELAUNAY > Sent: lundi 9 mars 2020 14:59 > > Correct three masks used to access on the RCC register RCC_QSPICKSELR, > RCC_FMCCKSELR and RCC_ADCCKSELR: only 3 bits. > > Signed-off-by: Patrick Delaunay > --- Applied to u-boot-stm/next, thanks! Regards Patrick
Re: [PATCH 1/2] efi_loader: correct reported length in GetNextVariable()
Hi Heinrich,
Heinrich Schuchardt writes:
> The runtime service GetNextVariable() returns the length of the next
> variable including the closing 0x. This length should be in bytes.
>
> Comparing the output of EDK2 and U-Boot shows that this is currently not
> correctly implemented:
>
> EDK2:
> OsIndicationsSupported: 46
> PlatformLang: 26
> PlatformLangCodes: 36
>
> U-Boot:
> OsIndicationsSupported: 23
> PlatformLang: 13
> PlatformLangCodes: 18
>
> Provide correct length in GetNextVariable().
>
> Fixes: d99a87f84b75 ("efi_loader: implement GetNextVariableName()")
> Signed-off-by: Heinrich Schuchardt
> ---
> lib/efi_loader/efi_variable.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
> index c316bdfec0..04ead34c6f 100644
> --- a/lib/efi_loader/efi_variable.c
> +++ b/lib/efi_loader/efi_variable.c
> @@ -299,7 +299,7 @@ static efi_status_t parse_uboot_variable(char *variable,
> p = variable_name;
> utf8_utf16_strncpy(, name, name_len);
> variable_name[name_len] = 0;
> - *variable_name_size = name_len + 1;
> + *variable_name_size = sizeof(u16) * (name_len + 1);
Maybe I am missing something, but isn't a similar fix needed in the
function where the buffer is checked for sufficient size?
For context, I am referring to
if (*variable_name_size < (name_len + 1)) {
*variable_name_size = name_len + 1;
return EFI_BUFFER_TOO_SMALL;
}
Thanks,
Punit
>
> /* guid */
> c = *(name - 1);
> --
> 2.25.1
RE: [PATCH] stm32mp: psci: set cntfrq register of cpu on
Hi, > From: Patrick DELAUNAY > Sent: lundi 2 mars 2020 11:27 > > From: Ludovic Barre > > This path allows to set the cntfrq register of targeted cpu. > > Signed-off-by: Ludovic Barre > Reviewed-by: Patrick DELAUNAY > Signed-off-by: Patrick Delaunay > --- Applied to u-boot-stm/next, thanks! Regards Patrick
RE: [PATCH] stm32mp1: add 800 MHz profile support
Hi, > From: Patrick DELAUNAY > Sent: mercredi 26 février 2020 11:27 > > The STM32MP1 series is available in 3 different lines which are pin-to-pin > compatible: > - STM32MP157: Dual Cortex-A7 cores, Cortex-M4 core @ 209 MHz, > 3D GPU, DSI display interface and CAN FD > - STM32MP153: Dual Cortex-A7 cores, Cortex-M4 core @ 209 MHz > and CAN FD > - STM32MP151: Single Cortex-A7 core, Cortex-M4 core @ 209 MHz > > Each line comes with a security option (cryptography & secure boot) & a > Cortex-A > frequency option : > > - A : Cortex-A7 @ 650 MHz > - C : Secure Boot + HW Crypto + Cortex-A7 @ 650 MHz > - D : Cortex-A7 @ 800 MHz > - F : Secure Boot + HW Crypto + Cortex-A7 @ 800 MHz > > This patch adds the support of STM32MP15xD and STM32MP15xF in U-Boot. > > Signed-off-by: Patrick Delaunay > --- Applied to u-boot-stm/next, thanks! Regards Patrick
RE: [PATCH 10/10] arm: stm32mp: fdt: update kernel device tree according the part number
Hi, > From: Patrick DELAUNAY > Sent: mercredi 12 février 2020 19:38 > > Update the kernel device tree for STM32MP15x product lines according the used > soc and its part number, when CONFIG_OF_SYSTEM_SETUP is activated: > - STM32MP15XA hasn't Crypto (cryp1/2) > - STM32M151 and STM32M153 hasn't 3D GPU and DSI host > - STM32M151 hasn't CAN FD and has single A7 > > For example: > > FDT: cpu 1 node remove for STM32MP151AAA Rev.B > FDT: can@4400e000 node disabled for STM32MP151AAA Rev.B > FDT: gpu@5900 node disabled for STM32MP151AAA Rev.B > FDT: dsi@5a00 node disabled for STM32MP151AAA Rev.B > > Signed-off-by: Patrick Delaunay > --- Applied to u-boot-stm/next, thanks! Regards Patrick
RE: [PATCH 09/10] arm: stm32mp: add function get_soc_name
Hi, > From: Patrick DELAUNAY > Sent: mercredi 12 février 2020 19:38 > > Add a function get_soc_name to get a string with the full name of the SOC > "STM32MP15xxx Rev.x" > > Signed-off-by: Patrick Delaunay > --- Applied to u-boot-stm/next, thanks! Regards Patrick
RE: [PATCH 08/10] board: stm32mp1: display reference only for STMicroelectronics board
Hi, > From: Patrick DELAUNAY > Sent: mercredi 12 février 2020 19:38 > > Display the reference MB found in OTP49 only for STMicroelectronics boards > when CONFIG_CMD_STBOARD is activated. > > Signed-off-by: Patrick Delaunay > --- Applied to u-boot-stm/next, thanks! Regards Patrick
RE: [PATCH 06/10] arm: stm32mp: improve the error message for smc
Hi, > From: Patrick DELAUNAY > Sent: mercredi 12 février 2020 19:38 > > Add the SMC code and operation for trace on errors. > > Signed-off-by: Patrick Delaunay > --- Applied to u-boot-stm/next, thanks! Regards Patrick
RE: [PATCH 05/10] board: stm32mp1: stboard: lock the OTP after programming
Hi, > From: Patrick DELAUNAY > Sent: mercredi 12 février 2020 19:38 > > Lock the OTP used for board identification for the ST boards after > programming. > > Signed-off-by: Patrick Delaunay > --- Applied to u-boot-stm/next, thanks! Regards Patrick
RE: [PATCH 04/10] arm: stm32mp: bsec: add permanent lock support in bsec driver
Hi, > From: Patrick DELAUNAY > Sent: mercredi 12 février 2020 19:38 > > Add BSEC lock access (read / write) at 0xC000 offset of misc driver. > The write access only available for Trusted boot mode, based on new SMC > STM32_SMC_WRLOCK_OTP. > > With the fuse command, the permanent lock status is accessed with > 0x1000 offset (0xC000 - 0x800 for OTP sense/program divided by > u32 size), for example: > > Read lock status of fuse 57 (0x39) > > STM32MP> fuse sense 0 0x1039 1 > > Sensing bank 0: > > Word 0x1039: > > Set permanent lock of fuse 57 (0x39) > > STM32MP> fuse prog 0 0x1039 1 > > Sensing bank 0: > > Word 0x1039: > > WARNING: the OTP lock is updated only after reboot > > WARING: Programming lock or fuses is an irreversible operation! > This may brick your system. > > Signed-off-by: Patrick Delaunay > --- Applied to u-boot-stm/next, thanks! Regards Patrick
RE: [PATCH 03/10] arm: stm32mp: bsec: remove unneeded test
Hi, > From: Patrick DELAUNAY > Sent: mercredi 12 février 2020 19:38 > > Remove the test offs < 0 , as offs is unsigned. > > This patch solves the warnings when compiling with W=1 on stm32mp1 board: > > In function ‘stm32mp_bsec_read’: > arch/arm/mach-stm32mp/bsec.c:368:11: warning: > comparison of unsigned expression < 0 is always false [-Wtype-limits] > 368 | if (offs < 0 || (offs % 4) || (size % 4)) > | ^ > In function ‘stm32mp_bsec_write’: > arch/arm/mach-stm32mp/bsec.c:405:11: warning: > comparison of unsigned expression < 0 is always false [-Wtype-limits] > 405 | if (offs < 0 || (offs % 4) || (size % 4)) > | ^ > > Signed-off-by: Patrick Delaunay > --- Applied to u-boot-stm/next, thanks! Regards Patrick
RE: [PATCH 01/10] board: stm32mp1: update command stboard on misc_write result
Hi,
> From: Patrick DELAUNAY
> Sent: mercredi 12 février 2020 19:38
>
> Update management of misc_write, which now return length of data after the
> commit 8729b1ae2cbd ("misc: Update read() and write() methods to return bytes
> xfered")
>
> Signed-off-by: Patrick Delaunay
> ---
Applied to u-boot-stm/next, thanks!
Regards
Patrick
RE: [PATCH 02/10] board: stm32mp1: read OTP in command stboard
Hi, > From: Patrick DELAUNAY > Sent: mercredi 12 février 2020 19:38 > > Read the value directly from the OTP and no more of the shadows to avoid the > need of reboot after stboard command to have correct value. > > Signed-off-by: Patrick Delaunay > --- Applied to u-boot-stm/next, thanks! Regards Patrick
Re: [PATCH 1/2] part: detect EFI system partition
Hi Heinrich,
Heinrich Schuchardt writes:
> Up to now for MBR and GPT partitions the info field 'bootable' was set to 1
> if either the partition was an EFI system partition or the bootable flag
> was set.
>
> Turn info field 'bootable' into a bit mask with separate bits for bootable
> and EFI system partition.
>
> This will allow us to identify the EFI system partition in the UEFI
> sub-system.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> disk/part_dos.c | 10 --
> disk/part_efi.c | 12
> include/part.h | 11 ++-
> 3 files changed, 26 insertions(+), 7 deletions(-)
>
[...]
> diff --git a/include/part.h b/include/part.h
> index 0b5cf3d5e8..a63d1d0cda 100644
> --- a/include/part.h
> +++ b/include/part.h
> @@ -51,13 +51,22 @@ struct block_drvr {
> #define PART_TYPE_LEN 32
> #define MAX_SEARCH_PARTITIONS 64
>
> +#define PART_BOOTABLE1
> +#define PART_EFI_SYSTEM_PARTITION2
As these defines are used as flags, it be better to use the BIT() macro
to make it explicit that these are bit positions rather than sequential
values.
Thanks,
Punit
> +
> typedef struct disk_partition {
> lbaint_tstart; /* # of first block in partition*/
> lbaint_tsize; /* number of blocks in partition*/
> ulong blksz; /* block size in bytes */
> uchar name[PART_NAME_LEN];/* partition name
> */
> uchar type[PART_TYPE_LEN];/* string type description
> */
> - int bootable; /* Active/Bootable flag is set */
> + /*
> + * The bootable is a bitmask with the following fields:
> + *
> + * PART_BOOTABLEthe MBR bootable flag is set
> + * PART_EFI_SYSTEM_PARTITIONthe partition is an EFI system partition
> + */
> + int bootable;
> #if CONFIG_IS_ENABLED(PARTITION_UUIDS)
> charuuid[UUID_STR_LEN + 1]; /* filesystem UUID as string, if exists
> */
> #endif
> --
> 2.20.1
[PATCHv2 8/9] configs: ls1028a: Enable GIC_V3_ITS config
From: Hou Zhiqiang Enable GIC_V3_ITS config to initialize the GIC redistributor tables. Signed-off-by: Hou Zhiqiang --- V2: - No change. configs/ls1028aqds_tfa_SECURE_BOOT_defconfig | 1 + configs/ls1028aqds_tfa_defconfig | 1 + configs/ls1028ardb_tfa_SECURE_BOOT_defconfig | 1 + configs/ls1028ardb_tfa_defconfig | 1 + 4 files changed, 4 insertions(+) diff --git a/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig b/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig index c5f0bd85da..92b944f426 100644 --- a/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig +++ b/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig @@ -79,3 +79,4 @@ CONFIG_WDT_SP805=y CONFIG_RSA=y CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_GIC_V3_ITS=y diff --git a/configs/ls1028aqds_tfa_defconfig b/configs/ls1028aqds_tfa_defconfig index 7085be77fe..66d3ee1761 100644 --- a/configs/ls1028aqds_tfa_defconfig +++ b/configs/ls1028aqds_tfa_defconfig @@ -84,3 +84,4 @@ CONFIG_WDT=y CONFIG_WDT_SP805=y CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_GIC_V3_ITS=y diff --git a/configs/ls1028ardb_tfa_SECURE_BOOT_defconfig b/configs/ls1028ardb_tfa_SECURE_BOOT_defconfig index 6fa14af6af..c999f3e6ef 100644 --- a/configs/ls1028ardb_tfa_SECURE_BOOT_defconfig +++ b/configs/ls1028ardb_tfa_SECURE_BOOT_defconfig @@ -76,3 +76,4 @@ CONFIG_WDT_SP805=y CONFIG_RSA=y CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_GIC_V3_ITS=y diff --git a/configs/ls1028ardb_tfa_defconfig b/configs/ls1028ardb_tfa_defconfig index 3ef5520969..150123bc7b 100644 --- a/configs/ls1028ardb_tfa_defconfig +++ b/configs/ls1028ardb_tfa_defconfig @@ -86,3 +86,4 @@ CONFIG_WDT=y CONFIG_WDT_SP805=y CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_GIC_V3_ITS=y -- 2.17.1
[PATCHv2 5/9] fsl-layerscape: Kconfig: Select RESV_RAM config if GIC_V3_ITS is enabled
From: Hou Zhiqiang The GIC redistributor tables initialization depends on RESV_RAM config, so select RESV_RAM if GIC_V3_ITS is enabled. Signed-off-by: Hou Zhiqiang --- V2: - The #6 of v1 patchset. arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig index 275c66d992..af1c148c26 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig +++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig @@ -46,6 +46,7 @@ config ARCH_LS1028A select SYS_FSL_ERRATUM_A009663 if !TFABOOT select SYS_FSL_ERRATUM_A009942 if !TFABOOT select SYS_FSL_ERRATUM_A050382 + select RESV_RAM if GIC_V3_ITS imply PANIC_HANG config ARCH_LS1043A @@ -152,6 +153,7 @@ config ARCH_LS1088A select SYS_I2C_MXC_I2C2 if !TFABOOT select SYS_I2C_MXC_I2C3 if !TFABOOT select SYS_I2C_MXC_I2C4 if !TFABOOT + select RESV_RAM if GIC_V3_ITS imply SCSI imply PANIC_HANG @@ -202,6 +204,7 @@ config ARCH_LS2080A select SYS_I2C_MXC_I2C2 if !TFABOOT select SYS_I2C_MXC_I2C3 if !TFABOOT select SYS_I2C_MXC_I2C4 if !TFABOOT + select RESV_RAM if GIC_V3_ITS imply DISTRO_DEFAULTS imply PANIC_HANG @@ -229,6 +232,7 @@ config ARCH_LX2160A select ARCH_EARLY_INIT_R select BOARD_EARLY_INIT_F select SYS_I2C_MXC + select RESV_RAM if GIC_V3_ITS imply DISTRO_DEFAULTS imply PANIC_HANG imply SCSI -- 2.17.1
[PATCHv2 6/9] arm64: layerscape: Move GIC RD tables initialization to CPU setup function
From: Hou Zhiqiang
Move GIC redistributor tables initialization to CPU setup function.
This patch introduces a GIC redistributor tables init function, and
moves the function of reserving memory for GIC redistributor tables
to soc.c and adds a argument for the memory size to reserve, BTW
rename the function so that it is more readable.
Signed-off-by: Hou Zhiqiang
---
V2:
- New patch.
arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 4 ++
arch/arm/cpu/armv8/fsl-layerscape/soc.c | 44 +++
.../arm/include/asm/arch-fsl-layerscape/soc.h | 4 ++
board/freescale/lx2160a/lx2160a.c | 28
4 files changed, 52 insertions(+), 28 deletions(-)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
index 87c3e05f45..36e0a2380e 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
@@ -462,6 +462,10 @@ void ft_cpu_setup(void *blob, bd_t *bd)
do_fixup_by_path_u32(blob, "/sysclk", "clock-frequency",
CONFIG_SYS_CLK_FREQ, 1);
+#ifdef CONFIG_GIC_V3_ITS
+ ls_gic_rd_tables_init(blob);
+#endif
+
#if defined(CONFIG_PCIE_LAYERSCAPE) || defined(CONFIG_PCIE_LAYERSCAPE_GEN4)
ft_pci_setup(blob, bd);
#endif
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
index d0e10cb007..28bb1d7401 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
@@ -6,10 +6,12 @@
#include
#include
+#include
#include
#include
#include
#include
+#include
#include
#include
#include
@@ -17,6 +19,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_LAYERSCAPE_NS_ACCESS
#include
#endif
@@ -30,9 +33,50 @@
#include
#ifdef CONFIG_TFABOOT
#include
+#endif
+#if defined(CONFIG_TFABOOT) || defined(CONFIG_GIC_V3_ITS)
DECLARE_GLOBAL_DATA_PTR;
#endif
+#ifdef CONFIG_GIC_V3_ITS
+#define PENDTABLE_MAX_SZ ALIGN(BIT(ITS_MAX_LPI_NRBITS), SZ_64K)
+#define PROPTABLE_MAX_SZ ALIGN(BIT(ITS_MAX_LPI_NRBITS) / 8, SZ_64K)
+#define GIC_LPI_SIZE ALIGN(cpu_numcores() * PENDTABLE_MAX_SZ + \
+ PROPTABLE_MAX_SZ, SZ_1M)
+static int fdt_add_resv_mem_gic_rd_tables(void *blob, u64 base, size_t size)
+{
+ u32 phandle;
+ int err;
+ struct fdt_memory gic_rd_tables;
+
+ gic_rd_tables.start = base;
+ gic_rd_tables.end = base + size - 1;
+ err = fdtdec_add_reserved_memory(blob, "gic-rd-tables", _rd_tables,
+);
+ if (err < 0)
+ debug("%s: failed to add reserved memory: %d\n", __func__, err);
+
+ return err;
+}
+
+int ls_gic_rd_tables_init(void *blob)
+{
+ u64 gic_lpi_base;
+ int ret;
+
+ gic_lpi_base = ALIGN(gd->arch.resv_ram - GIC_LPI_SIZE, SZ_64K);
+ ret = fdt_add_resv_mem_gic_rd_tables(blob, gic_lpi_base, GIC_LPI_SIZE);
+ if (ret)
+ return ret;
+
+ ret = gic_lpi_tables_init(gic_lpi_base, cpu_numcores());
+ if (ret)
+ debug("%s: failed to init gic-lpi-tables\n", __func__);
+
+ return ret;
+}
+#endif
+
bool soc_has_dp_ddr(void)
{
struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/soc.h
b/arch/arm/include/asm/arch-fsl-layerscape/soc.h
index c62d414aac..020548ac6c 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/soc.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/soc.h
@@ -158,6 +158,10 @@ void erratum_a010315(void);
bool soc_has_dp_ddr(void);
bool soc_has_aiop(void);
+
+#ifdef CONFIG_GIC_V3_ITS
+int ls_gic_rd_tables_init(void *blob);
+#endif
#endif
#endif /* _ASM_ARMV8_FSL_LAYERSCAPE_SOC_H_ */
diff --git a/board/freescale/lx2160a/lx2160a.c
b/board/freescale/lx2160a/lx2160a.c
index c8e962ce3d..cd6a9a34ac 100644
--- a/board/freescale/lx2160a/lx2160a.c
+++ b/board/freescale/lx2160a/lx2160a.c
@@ -5,7 +5,6 @@
#include
#include
-#include
#include
#include
#include
@@ -17,7 +16,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -31,13 +29,11 @@
#include "../common/vid.h"
#include
#include
-#include
#ifdef CONFIG_EMC2305
#include "../common/emc2305.h"
#endif
-#define GIC_LPI_SIZE 0x20
#ifdef CONFIG_TARGET_LX2160AQDS
#define CFG_MUX_I2C_SDHC(reg, value) ((reg & 0x3f) | value)
#define SET_CFG_MUX1_SDHC1_SDHC(reg) (reg & 0x3f)
@@ -631,21 +627,6 @@ void board_quiesce_devices(void)
}
#endif
-#ifdef CONFIG_GIC_V3_ITS
-void fdt_fixup_gic_lpi_memory(void *blob, u64 gic_lpi_base)
-{
- u32 phandle;
- int err;
- struct fdt_memory gic_lpi;
-
- gic_lpi.start = gic_lpi_base;
- gic_lpi.end = gic_lpi_base + GIC_LPI_SIZE - 1;
- err = fdtdec_add_reserved_memory(blob, "gic-lpi", _lpi, );
- if (err < 0)
- debug("failed
[PATCHv2 9/9] configs: ls208xa: Enable GIC_V3_ITS config
From: Hou Zhiqiang Enable GIC_V3_ITS config to initialize the GIC redistributor tables. Signed-off-by: Hou Zhiqiang --- V2: - No change. configs/ls2080aqds_SECURE_BOOT_defconfig | 1 + configs/ls2080aqds_defconfig | 1 + configs/ls2080aqds_nand_defconfig | 1 + configs/ls2080aqds_qspi_defconfig | 1 + configs/ls2080aqds_sdcard_defconfig | 1 + configs/ls2080ardb_SECURE_BOOT_defconfig | 1 + configs/ls2080ardb_defconfig | 1 + configs/ls2080ardb_nand_defconfig | 1 + configs/ls2081ardb_defconfig | 1 + configs/ls2088aqds_tfa_defconfig | 1 + configs/ls2088ardb_qspi_SECURE_BOOT_defconfig | 1 + configs/ls2088ardb_qspi_defconfig | 1 + configs/ls2088ardb_tfa_SECURE_BOOT_defconfig | 1 + configs/ls2088ardb_tfa_defconfig | 1 + 14 files changed, 14 insertions(+) diff --git a/configs/ls2080aqds_SECURE_BOOT_defconfig b/configs/ls2080aqds_SECURE_BOOT_defconfig index 8a792e449a..9039b252c1 100644 --- a/configs/ls2080aqds_SECURE_BOOT_defconfig +++ b/configs/ls2080aqds_SECURE_BOOT_defconfig @@ -62,3 +62,4 @@ CONFIG_USB_XHCI_DWC3=y CONFIG_RSA=y CONFIG_RSA_SOFTWARE_EXP=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_GIC_V3_ITS=y diff --git a/configs/ls2080aqds_defconfig b/configs/ls2080aqds_defconfig index bc4c218c21..b14b3ca5e7 100644 --- a/configs/ls2080aqds_defconfig +++ b/configs/ls2080aqds_defconfig @@ -63,3 +63,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_GIC_V3_ITS=y diff --git a/configs/ls2080aqds_nand_defconfig b/configs/ls2080aqds_nand_defconfig index e840cbf0ef..fac2b04068 100644 --- a/configs/ls2080aqds_nand_defconfig +++ b/configs/ls2080aqds_nand_defconfig @@ -70,3 +70,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_GIC_V3_ITS=y diff --git a/configs/ls2080aqds_qspi_defconfig b/configs/ls2080aqds_qspi_defconfig index 861e652f7f..343c7675e0 100644 --- a/configs/ls2080aqds_qspi_defconfig +++ b/configs/ls2080aqds_qspi_defconfig @@ -62,3 +62,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_GIC_V3_ITS=y diff --git a/configs/ls2080aqds_sdcard_defconfig b/configs/ls2080aqds_sdcard_defconfig index 864e70d334..dd2862ffe0 100644 --- a/configs/ls2080aqds_sdcard_defconfig +++ b/configs/ls2080aqds_sdcard_defconfig @@ -69,3 +69,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_GIC_V3_ITS=y diff --git a/configs/ls2080ardb_SECURE_BOOT_defconfig b/configs/ls2080ardb_SECURE_BOOT_defconfig index 4abfc64705..743e25f7b7 100644 --- a/configs/ls2080ardb_SECURE_BOOT_defconfig +++ b/configs/ls2080ardb_SECURE_BOOT_defconfig @@ -64,3 +64,4 @@ CONFIG_USB_XHCI_DWC3=y CONFIG_RSA=y CONFIG_RSA_SOFTWARE_EXP=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_GIC_V3_ITS=y diff --git a/configs/ls2080ardb_defconfig b/configs/ls2080ardb_defconfig index 0102e14ecb..e9dfc3603e 100644 --- a/configs/ls2080ardb_defconfig +++ b/configs/ls2080ardb_defconfig @@ -65,3 +65,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_GIC_V3_ITS=y diff --git a/configs/ls2080ardb_nand_defconfig b/configs/ls2080ardb_nand_defconfig index 448e0fe58d..68ec26e405 100644 --- a/configs/ls2080ardb_nand_defconfig +++ b/configs/ls2080ardb_nand_defconfig @@ -70,3 +70,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_GIC_V3_ITS=y diff --git a/configs/ls2081ardb_defconfig b/configs/ls2081ardb_defconfig index e446a1120b..4036ed94e5 100644 --- a/configs/ls2081ardb_defconfig +++ b/configs/ls2081ardb_defconfig @@ -62,3 +62,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_GIC_V3_ITS=y diff --git a/configs/ls2088aqds_tfa_defconfig b/configs/ls2088aqds_tfa_defconfig index 9f49736b4f..d3ee37cabe 100644 --- a/configs/ls2088aqds_tfa_defconfig +++ b/configs/ls2088aqds_tfa_defconfig @@ -74,3 +74,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_GIC_V3_ITS=y diff --git a/configs/ls2088ardb_qspi_SECURE_BOOT_defconfig b/configs/ls2088ardb_qspi_SECURE_BOOT_defconfig index ae4a6820ff..9b06bf4257 100644 --- a/configs/ls2088ardb_qspi_SECURE_BOOT_defconfig +++ b/configs/ls2088ardb_qspi_SECURE_BOOT_defconfig @@ -59,3 +59,4 @@ CONFIG_USB_XHCI_DWC3=y CONFIG_RSA=y CONFIG_RSA_SOFTWARE_EXP=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_GIC_V3_ITS=y diff --git a/configs/ls2088ardb_qspi_defconfig b/configs/ls2088ardb_qspi_defconfig index 1ad5f3b367..3203384c5b 100644 --- a/configs/ls2088ardb_qspi_defconfig +++ b/configs/ls2088ardb_qspi_defconfig @@ -63,3 +63,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
[PATCHv2 4/9] board: lx2160a: Make sure the RD tables address align to 64KB
From: Hou Zhiqiang
As the lower 16bit of the redistributor pending table is reserved
for describing the memory attributes, we must give a 64KB aligned
address to the GIC LPI initialization function.
Signed-off-by: Hou Zhiqiang
---
V2:
- The #5 of v1 patchset.
board/freescale/lx2160a/lx2160a.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/board/freescale/lx2160a/lx2160a.c
b/board/freescale/lx2160a/lx2160a.c
index 7f22110dc6..c8e962ce3d 100644
--- a/board/freescale/lx2160a/lx2160a.c
+++ b/board/freescale/lx2160a/lx2160a.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -678,7 +679,7 @@ int ft_board_setup(void *blob, bd_t *bd)
}
#ifdef CONFIG_GIC_V3_ITS
- gic_lpi_base = gd->arch.resv_ram - GIC_LPI_SIZE;
+ gic_lpi_base = ALIGN(gd->arch.resv_ram - GIC_LPI_SIZE, SZ_64K);
ret = fdt_fixup_gic_lpi_memory(blob, gic_lpi_base);
if (!ret && gic_lpi_tables_init(gic_lpi_base, cpu_numcores()))
debug("%s: failed to init gic-lpi-tables\n", __func__);
--
2.17.1
[PATCHv2 7/9] configs: ls1088a: Enable GIC_V3_ITS config
From: Hou Zhiqiang Enable GIC_V3_ITS config to initialize the GIC redistributor tables. Signed-off-by: Hou Zhiqiang --- V2: - No change. configs/ls1088aqds_defconfig | 1 + configs/ls1088aqds_qspi_SECURE_BOOT_defconfig| 1 + configs/ls1088aqds_qspi_defconfig| 1 + configs/ls1088aqds_sdcard_ifc_defconfig | 1 + configs/ls1088aqds_sdcard_qspi_defconfig | 1 + configs/ls1088aqds_tfa_defconfig | 1 + configs/ls1088ardb_qspi_SECURE_BOOT_defconfig| 1 + configs/ls1088ardb_qspi_defconfig| 1 + configs/ls1088ardb_sdcard_qspi_SECURE_BOOT_defconfig | 1 + configs/ls1088ardb_sdcard_qspi_defconfig | 1 + configs/ls1088ardb_tfa_SECURE_BOOT_defconfig | 1 + configs/ls1088ardb_tfa_defconfig | 1 + 12 files changed, 12 insertions(+) diff --git a/configs/ls1088aqds_defconfig b/configs/ls1088aqds_defconfig index 7713e58bbe..b1b74f9af4 100644 --- a/configs/ls1088aqds_defconfig +++ b/configs/ls1088aqds_defconfig @@ -59,3 +59,4 @@ CONFIG_USB_XHCI_DWC3=y CONFIG_USB_DWC3=y CONFIG_USB_STORAGE=y CONFIG_USB_GADGET=y +CONFIG_GIC_V3_ITS=y diff --git a/configs/ls1088aqds_qspi_SECURE_BOOT_defconfig b/configs/ls1088aqds_qspi_SECURE_BOOT_defconfig index 242c40b8b5..943b914e01 100644 --- a/configs/ls1088aqds_qspi_SECURE_BOOT_defconfig +++ b/configs/ls1088aqds_qspi_SECURE_BOOT_defconfig @@ -60,3 +60,4 @@ CONFIG_USB_GADGET=y CONFIG_RSA=y CONFIG_RSA_SOFTWARE_EXP=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_GIC_V3_ITS=y diff --git a/configs/ls1088aqds_qspi_defconfig b/configs/ls1088aqds_qspi_defconfig index 3649b06a75..490782ebfc 100644 --- a/configs/ls1088aqds_qspi_defconfig +++ b/configs/ls1088aqds_qspi_defconfig @@ -61,3 +61,4 @@ CONFIG_USB_XHCI_DWC3=y CONFIG_USB_DWC3=y CONFIG_USB_GADGET=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_GIC_V3_ITS=y diff --git a/configs/ls1088aqds_sdcard_ifc_defconfig b/configs/ls1088aqds_sdcard_ifc_defconfig index 815ea5ce4a..a4c6b27a3d 100644 --- a/configs/ls1088aqds_sdcard_ifc_defconfig +++ b/configs/ls1088aqds_sdcard_ifc_defconfig @@ -67,3 +67,4 @@ CONFIG_USB_XHCI_DWC3=y CONFIG_USB_DWC3=y CONFIG_USB_STORAGE=y CONFIG_USB_GADGET=y +CONFIG_GIC_V3_ITS=y diff --git a/configs/ls1088aqds_sdcard_qspi_defconfig b/configs/ls1088aqds_sdcard_qspi_defconfig index 275dbf9e0e..435f704eb3 100644 --- a/configs/ls1088aqds_sdcard_qspi_defconfig +++ b/configs/ls1088aqds_sdcard_qspi_defconfig @@ -70,3 +70,4 @@ CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_USB_DWC3=y CONFIG_USB_GADGET=y +CONFIG_GIC_V3_ITS=y diff --git a/configs/ls1088aqds_tfa_defconfig b/configs/ls1088aqds_tfa_defconfig index 1144cba983..5c2a699849 100644 --- a/configs/ls1088aqds_tfa_defconfig +++ b/configs/ls1088aqds_tfa_defconfig @@ -78,3 +78,4 @@ CONFIG_USB_XHCI_DWC3=y CONFIG_USB_DWC3=y CONFIG_USB_GADGET=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_GIC_V3_ITS=y diff --git a/configs/ls1088ardb_qspi_SECURE_BOOT_defconfig b/configs/ls1088ardb_qspi_SECURE_BOOT_defconfig index 3f654e2e1d..89e9a46c4f 100644 --- a/configs/ls1088ardb_qspi_SECURE_BOOT_defconfig +++ b/configs/ls1088ardb_qspi_SECURE_BOOT_defconfig @@ -61,3 +61,4 @@ CONFIG_USB_GADGET=y CONFIG_RSA=y CONFIG_RSA_SOFTWARE_EXP=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_GIC_V3_ITS=y diff --git a/configs/ls1088ardb_qspi_defconfig b/configs/ls1088ardb_qspi_defconfig index 935d76b4be..3c2fda4593 100644 --- a/configs/ls1088ardb_qspi_defconfig +++ b/configs/ls1088ardb_qspi_defconfig @@ -62,3 +62,4 @@ CONFIG_USB_XHCI_DWC3=y CONFIG_USB_DWC3=y CONFIG_USB_GADGET=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_GIC_V3_ITS=y diff --git a/configs/ls1088ardb_sdcard_qspi_SECURE_BOOT_defconfig b/configs/ls1088ardb_sdcard_qspi_SECURE_BOOT_defconfig index 562cbdd3ab..da41ccaa29 100644 --- a/configs/ls1088ardb_sdcard_qspi_SECURE_BOOT_defconfig +++ b/configs/ls1088ardb_sdcard_qspi_SECURE_BOOT_defconfig @@ -70,3 +70,4 @@ CONFIG_USB_XHCI_DWC3=y CONFIG_USB_DWC3=y CONFIG_RSA=y CONFIG_SPL_RSA=y +CONFIG_GIC_V3_ITS=y diff --git a/configs/ls1088ardb_sdcard_qspi_defconfig b/configs/ls1088ardb_sdcard_qspi_defconfig index 1e6fdceca1..0483e5d8d2 100644 --- a/configs/ls1088ardb_sdcard_qspi_defconfig +++ b/configs/ls1088ardb_sdcard_qspi_defconfig @@ -71,3 +71,4 @@ CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_USB_DWC3=y CONFIG_USB_GADGET=y +CONFIG_GIC_V3_ITS=y diff --git a/configs/ls1088ardb_tfa_SECURE_BOOT_defconfig b/configs/ls1088ardb_tfa_SECURE_BOOT_defconfig index 0086039e52..079e6c53fb 100644 --- a/configs/ls1088ardb_tfa_SECURE_BOOT_defconfig +++ b/configs/ls1088ardb_tfa_SECURE_BOOT_defconfig @@ -71,3 +71,4 @@ CONFIG_RSA=y CONFIG_SPL_RSA=y CONFIG_RSA_SOFTWARE_EXP=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_GIC_V3_ITS=y diff --git a/configs/ls1088ardb_tfa_defconfig b/configs/ls1088ardb_tfa_defconfig index a7908e95b5..e3d4b02d21 100644 --- a/configs/ls1088ardb_tfa_defconfig +++ b/configs/ls1088ardb_tfa_defconfig @@ -77,3
[PATCHv2 3/9] board: lx2160a: Don't program the GIC RD tables if failed to reserve memory
From: Hou Zhiqiang
Program the GIC redistributor tables only when succeeded to reserve memory
for them, otherwise kernel will lose the chance to program them using
allocated memory.
Signed-off-by: Hou Zhiqiang
---
V2:
- The #4 of v1 patchset.
board/freescale/lx2160a/lx2160a.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/board/freescale/lx2160a/lx2160a.c
b/board/freescale/lx2160a/lx2160a.c
index 595c774b42..7f22110dc6 100644
--- a/board/freescale/lx2160a/lx2160a.c
+++ b/board/freescale/lx2160a/lx2160a.c
@@ -657,6 +657,7 @@ int ft_board_setup(void *blob, bd_t *bd)
u64 mc_memory_size = 0;
u16 total_memory_banks;
u64 gic_lpi_base;
+ int ret;
ft_cpu_setup(blob, bd);
@@ -678,8 +679,9 @@ int ft_board_setup(void *blob, bd_t *bd)
#ifdef CONFIG_GIC_V3_ITS
gic_lpi_base = gd->arch.resv_ram - GIC_LPI_SIZE;
- gic_lpi_tables_init(gic_lpi_base, cpu_numcores());
- fdt_fixup_gic_lpi_memory(blob, gic_lpi_base);
+ ret = fdt_fixup_gic_lpi_memory(blob, gic_lpi_base);
+ if (!ret && gic_lpi_tables_init(gic_lpi_base, cpu_numcores()))
+ debug("%s: failed to init gic-lpi-tables\n", __func__);
#endif
#ifdef CONFIG_RESV_RAM
--
2.17.1
[PATCHv2 2/9] arm64: fsl-layerscape: Assign addr to resv_ram if enabled RESV_RAM config
From: Hou Zhiqiang The initialization of gd->arch.resv_ram pointer should depend on if the RESV_RAM config is enabled. Signed-off-by: Hou Zhiqiang --- V2: - No change. arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c index b443894453..1b7729c046 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c +++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c @@ -1379,7 +1379,7 @@ static int tfa_dram_init_banksize(void) if (i > 0) ret = 0; -#if defined(CONFIG_FSL_MC_ENET) && !defined(CONFIG_SPL_BUILD) +#if defined(CONFIG_RESV_RAM) && !defined(CONFIG_SPL_BUILD) /* Assign memory for MC */ #ifdef CONFIG_SYS_DDR_BLOCK3_BASE if (gd->bd->bi_dram[2].size >= @@ -1402,7 +1402,7 @@ static int tfa_dram_init_banksize(void) board_reserve_ram_top(gd->bd->bi_dram[0].size); } } -#endif /* CONFIG_FSL_MC_ENET */ +#endif /* CONFIG_RESV_RAM */ return ret; } @@ -1465,7 +1465,7 @@ int dram_init_banksize(void) } #endif /* CONFIG_SYS_MEM_RESERVE_SECURE */ -#if defined(CONFIG_FSL_MC_ENET) && !defined(CONFIG_SPL_BUILD) +#if defined(CONFIG_RESV_RAM) && !defined(CONFIG_SPL_BUILD) /* Assign memory for MC */ #ifdef CONFIG_SYS_DDR_BLOCK3_BASE if (gd->bd->bi_dram[2].size >= @@ -1488,7 +1488,7 @@ int dram_init_banksize(void) board_reserve_ram_top(gd->bd->bi_dram[0].size); } } -#endif /* CONFIG_FSL_MC_ENET */ +#endif /* CONFIG_RESV_RAM */ #ifdef CONFIG_SYS_DP_DDR_BASE_PHY #ifdef CONFIG_SYS_DDR_BLOCK3_BASE -- 2.17.1
[PATCHv2 0/9] fsl: layerscape: Initialize the GIC redistributor
From: Hou Zhiqiang This patch set is to initialize the GIC redistributor tables and add the tables to kernel DT's reserved memeory node. Hou Zhiqiang (9): board: lx2160a: Add header file cpu_func.h arm64: fsl-layerscape: Assign addr to resv_ram if enabled RESV_RAM config board: lx2160a: Don't program the GIC RD tables if failed to reserve memory board: lx2160a: Make sure the RD tables address align to 64KB fsl-layerscape: Kconfig: Select RESV_RAM config if GIC_V3_ITS is enabled arm64: layerscape: Move GIC RD tables initialization to CPU setup function configs: ls1088a: Enable GIC_V3_ITS config configs: ls1028a: Enable GIC_V3_ITS config configs: ls208xa: Enable GIC_V3_ITS config Depends on: https://patchwork.ozlabs.org/project/uboot/list/?series=158486 arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 4 ++ arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 8 ++-- arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 4 ++ arch/arm/cpu/armv8/fsl-layerscape/soc.c | 44 +++ .../arm/include/asm/arch-fsl-layerscape/soc.h | 4 ++ board/freescale/lx2160a/lx2160a.c | 24 -- configs/ls1028aqds_tfa_SECURE_BOOT_defconfig | 1 + configs/ls1028aqds_tfa_defconfig | 1 + configs/ls1028ardb_tfa_SECURE_BOOT_defconfig | 1 + configs/ls1028ardb_tfa_defconfig | 1 + configs/ls1088aqds_defconfig | 1 + configs/ls1088aqds_qspi_SECURE_BOOT_defconfig | 1 + configs/ls1088aqds_qspi_defconfig | 1 + configs/ls1088aqds_sdcard_ifc_defconfig | 1 + configs/ls1088aqds_sdcard_qspi_defconfig | 1 + configs/ls1088aqds_tfa_defconfig | 1 + configs/ls1088ardb_qspi_SECURE_BOOT_defconfig | 1 + configs/ls1088ardb_qspi_defconfig | 1 + ...1088ardb_sdcard_qspi_SECURE_BOOT_defconfig | 1 + configs/ls1088ardb_sdcard_qspi_defconfig | 1 + configs/ls1088ardb_tfa_SECURE_BOOT_defconfig | 1 + configs/ls1088ardb_tfa_defconfig | 1 + configs/ls2080aqds_SECURE_BOOT_defconfig | 1 + configs/ls2080aqds_defconfig | 1 + configs/ls2080aqds_nand_defconfig | 1 + configs/ls2080aqds_qspi_defconfig | 1 + configs/ls2080aqds_sdcard_defconfig | 1 + configs/ls2080ardb_SECURE_BOOT_defconfig | 1 + configs/ls2080ardb_defconfig | 1 + configs/ls2080ardb_nand_defconfig | 1 + configs/ls2081ardb_defconfig | 1 + configs/ls2088aqds_tfa_defconfig | 1 + configs/ls2088ardb_qspi_SECURE_BOOT_defconfig | 1 + configs/ls2088ardb_qspi_defconfig | 1 + configs/ls2088ardb_tfa_SECURE_BOOT_defconfig | 1 + configs/ls2088ardb_tfa_defconfig | 1 + 36 files changed, 90 insertions(+), 28 deletions(-) -- 2.17.1
[PATCHv2 1/9] board: lx2160a: Add header file cpu_func.h
From: Hou Zhiqiang The declaration of the function cpu_numcores() has been moved to cpu_func.h, so add including of the header file to avoid build error. Signed-off-by: Hou Zhiqiang --- V2: - No change. board/freescale/lx2160a/lx2160a.c | 1 + 1 file changed, 1 insertion(+) diff --git a/board/freescale/lx2160a/lx2160a.c b/board/freescale/lx2160a/lx2160a.c index 134ae22f85..595c774b42 100644 --- a/board/freescale/lx2160a/lx2160a.c +++ b/board/freescale/lx2160a/lx2160a.c @@ -5,6 +5,7 @@ #include #include +#include #include #include #include -- 2.17.1
[PATCH v2] board: stm32mp1: add finished good in board identifier OTP
Update the command stboard to support the updated coding of OTP 59 with
finished good.
The ST product codification have several element
- "Commercial Product Name" (CPN): type of product board (DKX, EVX)
associated to the board ID "MB"
- "Finished Good" or "Finish Good" (FG):
effective content of the product without chip STM32MP1 (LCD, Wifi, …)
- BOM: cost variant for same FG
(for example, several provider of the same component)
For example
- commercial product = STM32MP157C-EV1
- Finished Good = EVA32MP157A1$AU1
Booth information are written on board and this information is also saved
in OTP59:
bit [31:16] (hex) => Board id, MB
bit [15:12] (dec) => Variant CPN (115)
bit [11:8] (dec) => Revision board (index with A = 1, Z = 26)
bit [7:4] (dec) => Variant FG : finished good (NEW)
bit [3:0] (dec) => BOM (01, 255)
The updated command is:
stboard [-y]
And the displayed STMicroelectronics board identification is:
Board: MB Var. Rev.-
Signed-off-by: Patrick Delaunay
---
Changes in v2:
- update commit message
- add comments in cmd_stboard.c
board/st/common/cmd_stboard.c | 60 ---
board/st/stm32mp1/stm32mp1.c | 4 ++-
2 files changed, 52 insertions(+), 12 deletions(-)
diff --git a/board/st/common/cmd_stboard.c b/board/st/common/cmd_stboard.c
index 1573e35410..78f99daead 100644
--- a/board/st/common/cmd_stboard.c
+++ b/board/st/common/cmd_stboard.c
@@ -1,6 +1,32 @@
// SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
/*
* Copyright (C) 2019, STMicroelectronics - All Rights Reserved
+ *
+ * the st command stboard supports the STMicroelectronics board identification
+ * saved in OTP 59.
+ *
+ * The ST product codification have several element
+ * - "Commercial Product Name" (CPN): type of product board (DKX, EVX)
+ * associated to the board ID "MB"
+ * - "Finished Good" or "Finish Good" (FG):
+ * effective content of the product without chip STM32MP1xx (LCD, Wifi,…)
+ * - BOM: cost variant for same FG (for example, several provider of the same
+ * component)
+ *
+ * For example
+ * - commercial product = STM32MP157C-EV1 for board MB1263
+ * - Finished Good = EVA32MP157A1$AU1
+ *
+ * Booth information are written on board and this information is also saved
+ * in OTP59, with:
+ * bit [31:16] (hex) => Board id, MB
+ * bit [15:12] (dec) => Variant CPN (115)
+ * bit [11:8] (dec) => Revision board (index with A = 1, Z = 26)
+ * bit [7:4] (dec) => Variant FG : finished good index
+ * bit [3:0] (dec) => BOM (01, 255)
+ *
+ * and displayed with the format:
+ * Board: MB Var. Rev.-
*/
#ifndef CONFIG_SPL_BUILD
@@ -13,6 +39,7 @@
static bool check_stboard(u16 board)
{
unsigned int i;
+ /* list of supported ST boards */
const u16 st_board_id[] = {
0x1272,
0x1263,
@@ -31,9 +58,11 @@ static bool check_stboard(u16 board)
static void display_stboard(u32 otp)
{
- printf("Board: MB%04x Var%d Rev.%c-%02d\n",
+ /* display board indentification with OPT coding */
+ printf("Board: MB%04x Var%d.%d Rev.%c-%02d\n",
otp >> 16,
(otp >> 12) & 0xF,
+ (otp >> 4) & 0xF,
((otp >> 8) & 0xF) - 1 + 'A',
otp & 0xF);
}
@@ -44,14 +73,14 @@ static int do_stboard(cmd_tbl_t *cmdtp, int flag, int argc,
int ret;
u32 otp, lock;
u8 revision;
- unsigned long board, variant, bom;
+ unsigned long board, var_cpn, var_fg, bom;
struct udevice *dev;
- int confirmed = argc == 6 && !strcmp(argv[1], "-y");
+ int confirmed = argc == 7 && !strcmp(argv[1], "-y");
argc -= 1 + confirmed;
argv += 1 + confirmed;
- if (argc != 0 && argc != 4)
+ if (argc != 0 && argc != 5)
return CMD_RET_USAGE;
ret = uclass_get_device_by_driver(UCLASS_MISC,
@@ -95,8 +124,8 @@ static int do_stboard(cmd_tbl_t *cmdtp, int flag, int argc,
return CMD_RET_USAGE;
}
- if (strict_strtoul(argv[1], 10, ) < 0 ||
- variant == 0 || variant > 15) {
+ if (strict_strtoul(argv[1], 10, _cpn) < 0 ||
+ var_cpn == 0 || var_cpn > 15) {
printf("argument %d invalid: %s\n", 2, argv[1]);
return CMD_RET_USAGE;
}
@@ -107,13 +136,21 @@ static int do_stboard(cmd_tbl_t *cmdtp, int flag, int
argc,
return CMD_RET_USAGE;
}
- if (strict_strtoul(argv[3], 10, ) < 0 ||
+ if (strict_strtoul(argv[3], 10, _fg) < 0 ||
+ var_fg > 15) {
+ printf("argument %d invalid: %s\n", 4, argv[3]);
+ return CMD_RET_USAGE;
+ }
+
+ if (strict_strtoul(argv[4], 10, ) < 0 ||
bom == 0 || bom > 15) {
printf("argument %d invalid: %s\n", 4, argv[3]);
return CMD_RET_USAGE;
}
- otp = (board << 16) | (variant << 12) | (revision << 8) | bom;
Re: [PATCH v2] watchdog: versal: Add support for Xilinx window watchdog
On 23.03.20 15:47, Michal Simek wrote: From: Ashok Reddy Soma Add support for Xilinx window watchdog, which can be found on Versal platforms. Signed-off-by: Ashok Reddy Soma Signed-off-by: Michal Simek --- Changes in v2: - Reverse subject prefixes - Convert to regmap as was asked - Rename WWDT_XILINX to WDT_XILINX Reviewed-by: Stefan Roese Thanks, Stefan
Re: [PATCH v6 04/12] arm: mvebu: clearfog: initial ClearFog Base variant
On 23.03.20 21:21, Joel Johnson wrote:
Add a unique entry for ClearFog Base variant, reflected in the board
name and adjusted SerDes topology.
Signed-off-by: Joel Johnson
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
v2 changes:
- reworked based on Baruch's run-time TLV EEPROM detection series
v3 changes:
- rebased on mvebu merged run-time TLV EEPROM detection series
- minor update to help test regarding runtime detection failures
v4 changes:
- use runtime static config adjust instead of #ifdef in cases where
hardware EEPROM detection fails or is disabled in build
SPL size change for defconfig increases 36 bytes (122893 to 122929)
SPL size change for defconfig+Base increases 60 bytes (122893 to 122953)
- add placeholder support for EEPROM based Clearfog Pro, based on
initial name confirmation from Baruch. I wanted to include the check
at least in the patch for review to indicate expected usage to
ensure that a Clearfog Pro EEPROM device boots correctly even if the
image is built with Base static configuration. If there are other
prerelease concerns and this should be added separately later, I'd
be fine with that too.
- Note that this approach *does not* currently provide any mechanism
for EEPROM detected boards to have their SFP speed changed or switch
between PCIE/SATA signalling. I'm assuming that will be done based on
hardware detection, but confirmation/acceptance in review would be
appreciated so it can be revisited if needed.
v5 changes:
- only make Base variant adjustment based on runtime configuration
v6 changes:
- print console message when falling back to static default; this
would be nice to issue separate messages for the cause (no EEPROM
detected, not compiled in, no matching product name) but that is
better done as a separate changeset
---
arch/arm/mach-mvebu/Kconfig| 2 ++
board/solidrun/clearfog/Kconfig| 18 ++
board/solidrun/clearfog/clearfog.c | 38 +-
3 files changed, 52 insertions(+), 6 deletions(-)
create mode 100644 board/solidrun/clearfog/Kconfig
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index bc5eaa5a76..161dee937f 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -280,4 +280,6 @@ config SECURED_MODE_CSK_INDEX
default 0
depends on SECURED_MODE_IMAGE
+source "board/solidrun/clearfog/Kconfig"
+
endif
diff --git a/board/solidrun/clearfog/Kconfig b/board/solidrun/clearfog/Kconfig
new file mode 100644
index 00..936d5918f8
--- /dev/null
+++ b/board/solidrun/clearfog/Kconfig
@@ -0,0 +1,18 @@
+menu "ClearFog configuration"
+ depends on TARGET_CLEARFOG
+
+config TARGET_CLEARFOG_BASE
+ bool "Use ClearFog Base static configuration"
+ help
+ Use the ClearFog Base as the static configuration instead of the
+ default which uses the ClearFog Pro.
+
+ Runtime board detection is always attempted and used if available. The
+ static configuration is used as a fallback in cases where runtime
+ detection is disabled, is not available in hardware, or otherwise
fails.
+
+ Only newer revisions of the ClearFog product line support runtime
+ detection via additional EEPROM hardware. This option enables
selecting
+ the Base variant for older hardware revisions.
+
+endmenu
diff --git a/board/solidrun/clearfog/clearfog.c
b/board/solidrun/clearfog/clearfog.c
index 9b31902c70..11d3a7f877 100644
--- a/board/solidrun/clearfog/clearfog.c
+++ b/board/solidrun/clearfog/clearfog.c
@@ -42,6 +42,7 @@ static void cf_read_tlv_data(void)
read_tlv_data(_tlv_data);
}
+/* The starting board_serdes_map reflects original Clearfog Pro usage */
static struct serdes_map board_serdes_map[] = {
{SATA0, SERDES_SPEED_3_GBPS, SERDES_DEFAULT_MODE, 0, 0},
{SGMII1, SERDES_SPEED_1_25_GBPS, SERDES_DEFAULT_MODE, 0, 0},
@@ -51,6 +52,13 @@ static struct serdes_map board_serdes_map[] = {
{SGMII2, SERDES_SPEED_1_25_GBPS, SERDES_DEFAULT_MODE, 0, 0},
};
+void config_cfbase_serdes_map(void)
+{
+ board_serdes_map[4].serdes_type = USB3_HOST0;
+ board_serdes_map[4].serdes_speed = SERDES_SPEED_5_GBPS;
+ board_serdes_map[4].serdes_mode = SERDES_DEFAULT_MODE;
+}
+
int hws_board_topology_load(struct serdes_map **serdes_map_array, u8 *count)
{
cf_read_tlv_data();
@@ -59,12 +67,26 @@ int hws_board_topology_load(struct serdes_map
**serdes_map_array, u8 *count)
board_serdes_map[0].serdes_type = PEX0;
board_serdes_map[0].serdes_speed = SERDES_SPEED_5_GBPS;
board_serdes_map[0].serdes_mode = PEX_ROOT_COMPLEX_X1;
- }
-
- if (sr_product_is(_tlv_data, "Clearfog Base")) {
- board_serdes_map[4].serdes_type = USB3_HOST0;
- board_serdes_map[4].serdes_speed =
Re: [PATCH v3 5/5] cmd: mvebu: bubt: show image boot device
On 23.03.20 18:43, Joel Johnson wrote:
When a mismatch is found trying to write an image for one boot method
to a different boot device, print an error message including the image
header marked target boot device type.
Signed-off-by: Joel Johnson
Reviewed-by: Stefan Roese
---
v2 changes:
- newly added in v2 series
v3 changes:
- none
---
cmd/mvebu/bubt.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/cmd/mvebu/bubt.c b/cmd/mvebu/bubt.c
index fbcad37c40..f992507041 100644
--- a/cmd/mvebu/bubt.c
+++ b/cmd/mvebu/bubt.c
@@ -676,6 +676,17 @@ static int a38x_check_boot_mode(const struct bubt_dev *dst)
if (a38x_boot_modes[mode].id == hdr->blockid)
return 0;
+ for (int i = 0; i < A38X_BOOT_MODE_MAX; i++) {
This will fail, as A38X_BOOT_MODE_MAX is not defined any more. Please
use ARRAY_SIZE() here as well.
Thanks,
Stefan
+ if (a38x_boot_modes[i].id == hdr->blockid) {
+ printf("Error: image meant to be booted from "
+ " \"%s\", not \"%s\"!\n",
+ a38x_boot_modes[i].name, dst->name);
+ return -ENOEXEC;
+ }
+ }
+
+ printf("Error: unknown boot device in image header: 0x%x\n",
+ hdr->blockid);
return -ENOEXEC;
}
@@ -745,10 +756,8 @@ static int bubt_verify(const struct bubt_dev *dst)
#if defined(CONFIG_ARMADA_38X)
err = a38x_check_boot_mode(dst);
- if (err) {
- puts("Error: image not built for destination device!\n");
+ if (err)
return err;
- }
#endif
return 0;
Viele Grüße,
Stefan
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH v3 3/5] cmd: mvebu: bubt: verify A38x target device type
On 23.03.20 18:43, Joel Johnson wrote:
Ensure that the device to which an image is being written includes
header information indicating boot support for the destination
device.
This is derived from the support in the SolidRun master-a38x vendor
fork.
Signed-off-by: Joel Johnson
---
v2 changes:
- none
v3 changes:
- use ARRAY_SIZE instead of #define size
---
cmd/mvebu/bubt.c | 47 +--
1 file changed, 45 insertions(+), 2 deletions(-)
diff --git a/cmd/mvebu/bubt.c b/cmd/mvebu/bubt.c
index b80b81c82a..fbcad37c40 100644
--- a/cmd/mvebu/bubt.c
+++ b/cmd/mvebu/bubt.c
@@ -107,6 +107,24 @@ struct a38x_main_hdr_v1 {
u8 ext; /* 0x1E */
u8 checksum; /* 0x1F */
};
+
+struct a38x_boot_mode {
+ unsigned int id;
+ const char *name;
+};
+
+/* The blockid header field values used to indicate boot device of image */
+struct a38x_boot_mode a38x_boot_modes[] = {
+ { 0x4D, "i2c" },
+ { 0x5A, "spi" },
+ { 0x69, "uart" },
+ { 0x78, "sata" },
+ { 0x8B, "nand" },
+ { 0x9C, "pex" },
+ { 0xAE, "mmc" },
+ {},
+};
+
#endif
struct bubt_dev {
@@ -644,6 +662,23 @@ static int check_image_header(void)
return 0;
}
#elif defined(CONFIG_ARMADA_38X)
+static int a38x_check_boot_mode(const struct bubt_dev *dst)
+{
+ int mode;
+ const struct a38x_main_hdr_v1 *hdr =
+ (struct a38x_main_hdr_v1 *)get_load_addr();
+
+ for (mode = 0; mode < ARRAY_SIZE(a38x_boot_modes); mode++) {
+ if (strcmp(a38x_boot_modes[mode].name, dst->name) == 0)
+ break;
+ }
+
+ if (a38x_boot_modes[mode].id == hdr->blockid)
+ return 0;
+
+ return -ENOEXEC;
+}
+
static size_t a38x_header_size(const struct a38x_main_hdr_v1 *h)
{
if (h->version == 1)
@@ -697,7 +732,7 @@ static int check_image_header(void)
}
#endif
-static int bubt_verify(size_t image_size)
+static int bubt_verify(const struct bubt_dev *dst)
{
int err;
@@ -708,6 +743,14 @@ static int bubt_verify(size_t image_size)
return err;
}
+#if defined(CONFIG_ARMADA_38X)
+ err = a38x_check_boot_mode(dst);
+ if (err) {
+ puts("Error: image not built for destination device!\n");
+ return err;
+ }
+#endif
Sorry for spotting this so late, but could you please change this to
if (IS_ENABLED(CONFIG_ARMADA_38X)) {
err = a38x_check_boot_mode(dst);
...
instead (less #ifdef's).
Other than that, please add my:
Reviewed-by: Stefan Roese
Thanks,
Stefan
+
return 0;
}
@@ -829,7 +872,7 @@ int do_bubt_cmd(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
if (!image_size)
return -EIO;
- err = bubt_verify(image_size);
+ err = bubt_verify(dst);
if (err)
return err;
Viele Grüße,
Stefan
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH v2 2/2] arm: mvebu: clearfog: support multiple SATA boot
On 23.03.20 18:26, Joel Johnson wrote:
Enable distro bootcmd support for additional SATA ports if enabled.
Signed-off-by: Joel Johnson
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
This patch builds on and requires the separate patch in the
"ClearFog Base static variant support" series adding configurable
SATA support ("arm: mvebu: clearfog: Add SATA mode flags").
v2 changes:
- name macros SCSI_BUSN to better distinguish between bus and connection
- move not SCSI case first, otherwise it tends to get lost
---
include/configs/clearfog.h | 38 ++
1 file changed, 34 insertions(+), 4 deletions(-)
diff --git a/include/configs/clearfog.h b/include/configs/clearfog.h
index a452f4b009..0c314c4c53 100644
--- a/include/configs/clearfog.h
+++ b/include/configs/clearfog.h
@@ -110,16 +110,46 @@
#define BOOT_TARGET_DEVICES_USB(func)
#endif
-#ifdef CONFIG_SCSI
-#define BOOT_TARGET_DEVICES_SCSI(func) func(SCSI, scsi, 0)
+#ifndef CONFIG_SCSI
+#define BOOT_TARGET_DEVICES_SCSI_BUS0(func)
+#define BOOT_TARGET_DEVICES_SCSI_BUS1(func)
+#define BOOT_TARGET_DEVICES_SCSI_BUS2(func)
+#else
+/*
+ * With SCSI enabled, M.2 SATA is always located on bus 0
+ */
+#define BOOT_TARGET_DEVICES_SCSI_BUS0(func) func(SCSI, scsi, 0)
+
+/*
+ * Either one or both mPCIe slots may be configured as mSATA interfaces. The
+ * SCSI bus ids are assigned based on sequence of hardware present, not always
+ * tied to hardware slot ids. As such, use second SCSI bus if either slot is
+ * set for SATA, and only use third SCSI bus if both slots are SATA enabled.
+ */
+#if defined (CONFIG_CLEARFOG_CON2_SATA) || defined (CONFIG_CLEARFOG_CON3_SATA)
+#define BOOT_TARGET_DEVICES_SCSI_BUS1(func) func(SCSI, scsi, 1)
#else
-#define BOOT_TARGET_DEVICES_SCSI(func)
+#define BOOT_TARGET_DEVICES_SCSI_BUS1(func)
#endif
+#if defined (CONFIG_CLEARFOG_CON2_SATA) && defined (CONFIG_CLEARFOG_CON3_SATA)
+#define BOOT_TARGET_DEVICES_SCSI_BUS2(func) func(SCSI, scsi, 2)
+#else
+#define BOOT_TARGET_DEVICES_SCSI_BUS2(func)
+#endif
+
+#endif /* CONFIG_SCSI */
+
+/*
+ * The SCSI buses are attempted in increasing bus order, there is no current
+ * mechanism to alter the default bus priority order for booting.
+ */
#define BOOT_TARGET_DEVICES(func) \
BOOT_TARGET_DEVICES_MMC(func) \
BOOT_TARGET_DEVICES_USB(func) \
- BOOT_TARGET_DEVICES_SCSI(func) \
+ BOOT_TARGET_DEVICES_SCSI_BUS0(func) \
+ BOOT_TARGET_DEVICES_SCSI_BUS1(func) \
+ BOOT_TARGET_DEVICES_SCSI_BUS2(func) \
func(PXE, pxe, na) \
func(DHCP, dhcp, na)
Viele Grüße,
Stefan
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH v2 1/8] mmc: ca_dw_mmc: add DesignWare based DM support for CAxxxx SoCs
Hi,
On 3/20/20 9:57 AM, Alex Nemirovsky wrote:
> From: Arthur Li
>
> Initial DesignWare based DM support for Cortina Access CA SoCs.
>
> Signed-off-by: Arthur Li
> Signed-off-by: Alex Nemirovsky
> CC: Peng Fan
I didn't receive any reply about my previous comments.
And Is there patch v3 or v2? Subject is v2..but change log is v3.
What is correct version?
Best Regards,
Jaehoon Chung
>
> ---
>
> Changes in v3: None
> Changes in v2:
> - Add I2C controller
> - Add LED controller
> - Add SPI NAND and NOR controller
>
> MAINTAINERS | 2 +
> drivers/mmc/Kconfig | 11 +++
> drivers/mmc/Makefile| 1 +
> drivers/mmc/ca_dw_mmc.c | 181
>
> 4 files changed, 195 insertions(+)
> create mode 100644 drivers/mmc/ca_dw_mmc.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 82e4159..bb45d3c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -180,6 +180,7 @@ F:board/cortina/common/
> F: drivers/gpio/cortina_gpio.c
> F: drivers/watchdog/cortina_wdt.c
> F: drivers/serial/serial_cortina.c
> +F: drivers/mmc/ca_dw_mmc.c
>
> ARM/CZ.NIC TURRIS MOX SUPPORT
> M: Marek Behun
> @@ -670,6 +671,7 @@ F:board/cortina/common/
> F: drivers/gpio/cortina_gpio.c
> F: drivers/watchdog/cortina_wdt.c
> F: drivers/serial/serial_cortina.c
> +F: drivers/mmc/ca_dw_mmc.c
>
> MIPS MSCC
> M: Gregory CLEMENT
> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> index 2f0eedc..bb38787 100644
> --- a/drivers/mmc/Kconfig
> +++ b/drivers/mmc/Kconfig
> @@ -205,6 +205,17 @@ config MMC_DW
> block, this provides host support for SD and MMC interfaces, in both
> PIO, internal DMA mode and external DMA mode.
>
> +config MMC_DW_CORTINA
> + bool "Cortina specific extensions for Synopsys DW Memory Card Interface"
> + depends on DM_MMC
> + depends on MMC_DW
> + depends on BLK
> + default n
> + help
> + This selects support for Cortina SoC specific extensions to the
> + Synopsys DesignWare Memory Card Interface driver. Select this option
> + for platforms based on Cortina CA Soc's.
> +
> config MMC_DW_EXYNOS
> bool "Exynos specific extensions for Synopsys DW Memory Card Interface"
> depends on ARCH_EXYNOS
> diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
> index 9c1f8e5..615b724 100644
> --- a/drivers/mmc/Makefile
> +++ b/drivers/mmc/Makefile
> @@ -20,6 +20,7 @@ endif
> obj-$(CONFIG_ARM_PL180_MMCI) += arm_pl180_mmci.o
> obj-$(CONFIG_MMC_DAVINCI)+= davinci_mmc.o
> obj-$(CONFIG_MMC_DW) += dw_mmc.o
> +obj-$(CONFIG_MMC_DW_CORTINA) += ca_dw_mmc.o
> obj-$(CONFIG_MMC_DW_EXYNOS) += exynos_dw_mmc.o
> obj-$(CONFIG_MMC_DW_K3) += hi6220_dw_mmc.o
> obj-$(CONFIG_MMC_DW_ROCKCHIP)+= rockchip_dw_mmc.o
> diff --git a/drivers/mmc/ca_dw_mmc.c b/drivers/mmc/ca_dw_mmc.c
> new file mode 100644
> index 000..acbc850
> --- /dev/null
> +++ b/drivers/mmc/ca_dw_mmc.c
> @@ -0,0 +1,181 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * (C) Copyright 2019 Cortina Access
> + * Arthur Li
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define SD_CLK_SEL_MASK (0x3)
> +#define SD_DLL_DEFAULT (0x143000)
> +#define SD_SCLK_MAX (2)
> +
> +#define SD_CLK_SEL_200MHZ (0x2)
> +#define SD_CLK_SEL_100MHZ (0x1)
> +
> +#define IO_DRV_SD_DS_OFFSET (16)
> +#define IO_DRV_SD_DS_MASK (0xff << IO_DRV_SD_DS_OFFSET)
> +
> +#define MIN_FREQ (40)
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +struct ca_mmc_plat {
> + struct mmc_config cfg;
> + struct mmc mmc;
> +};
> +
> +struct ca_dwmmc_priv_data {
> + struct dwmci_host host;
> + void __iomem *sd_dll_reg;
> + void __iomem *io_drv_reg;
> + u8 ds;
> +};
> +
> +static void ca_dwmci_clksel(struct dwmci_host *host)
> +{
> + struct ca_dwmmc_priv_data *priv = host->priv;
> + u32 val = readl(priv->sd_dll_reg);
> +
> + if (host->bus_hz >= 2) {
> + val &= ~SD_CLK_SEL_MASK;
> + val |= SD_CLK_SEL_200MHZ;
> + } else if (host->bus_hz >= 1) {
> + val &= ~SD_CLK_SEL_MASK;
> + val |= SD_CLK_SEL_100MHZ;
> + } else {
> + val &= ~SD_CLK_SEL_MASK;
> + }
> +
> + writel(val, priv->sd_dll_reg);
> +}
> +
> +static void ca_dwmci_board_init(struct dwmci_host *host)
> +{
> + struct ca_dwmmc_priv_data *priv = host->priv;
> + u32 val = readl(priv->io_drv_reg);
> +
> + writel(SD_DLL_DEFAULT, priv->sd_dll_reg);
> +
> + val &= ~IO_DRV_SD_DS_MASK;
> + if (priv && priv->ds)
> + val |= priv->ds << IO_DRV_SD_DS_OFFSET;
> + writel(val, priv->io_drv_reg);
> +}
> +
> +unsigned int ca_dwmci_get_mmc_clock(struct dwmci_host *host, uint freq)
> +{
> + struct ca_dwmmc_priv_data *priv = host->priv;
> + u8 sd_clk_sel =
Re: [PATCH v4 3/6] riscv: Provide a mechanism to fix DT for reserved memory
On Mon, Mar 23, 2020 at 11:14 PM Heinrich Schuchardt wrote:
>
> On 3/24/20 5:16 AM, Atish Patra wrote:
> > In RISC-V, M-mode software can reserve physical memory regions
> > by setting appropriate physical memory protection (PMP) csr. As the
> > PMP csr are accessible only in M-mode, S-mode U-Boot can not read
> > this configuration directly. However, M-mode software can pass this
> > information via reserved-memory node in device tree so that S-mode
> > software can access this information.
> >
> > This patch provides a framework to copy to the reserved-memory node
> > from one DT to another. This will be used to update the DT used by
> > U-Boot and the DT passed to the next stage OS.
> >
> > Signed-off-by: Atish Patra
> > ---
> > arch/riscv/cpu/start.S| 1 +
> > arch/riscv/include/asm/global_data.h | 1 +
> > arch/riscv/include/asm/u-boot-riscv.h | 2 +
> > arch/riscv/lib/Makefile | 1 +
> > arch/riscv/lib/asm-offsets.c | 1 +
> > arch/riscv/lib/fdt_fixup.c| 80 +++
> > 6 files changed, 86 insertions(+)
> > create mode 100644 arch/riscv/lib/fdt_fixup.c
> >
> > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> > index 6b3ff99c3882..0282685c2906 100644
> > --- a/arch/riscv/cpu/start.S
> > +++ b/arch/riscv/cpu/start.S
> > @@ -121,6 +121,7 @@ call_board_init_f_0:
> >
> > jal board_init_f_init_reserve
> >
> > + SREGs1, GD_FIRMWARE_FDT_ADDR(gp)
> > /* save the boot hart id to global_data */
> > SREGtp, GD_BOOT_HART(gp)
> >
> > diff --git a/arch/riscv/include/asm/global_data.h
> > b/arch/riscv/include/asm/global_data.h
> > index b74bd7e738bb..51ac8d1c98e2 100644
> > --- a/arch/riscv/include/asm/global_data.h
> > +++ b/arch/riscv/include/asm/global_data.h
> > @@ -15,6 +15,7 @@
> > /* Architecture-specific global data */
> > struct arch_global_data {
> > long boot_hart; /* boot hart id */
> > + phys_addr_t firmware_fdt_addr;
> > #ifdef CONFIG_SIFIVE_CLINT
> > void __iomem *clint;/* clint base address */
> > #endif
> > diff --git a/arch/riscv/include/asm/u-boot-riscv.h
> > b/arch/riscv/include/asm/u-boot-riscv.h
> > index 49febd588102..543a1688db8f 100644
> > --- a/arch/riscv/include/asm/u-boot-riscv.h
> > +++ b/arch/riscv/include/asm/u-boot-riscv.h
> > @@ -17,5 +17,7 @@ int cleanup_before_linux(void);
> > /* board/.../... */
> > int board_init(void);
> > void board_quiesce_devices(void);
> > +int riscv_board_reserved_mem_fixup(void *fdt);
> > +int riscv_fdt_copy_resv_mem_node(const void *src_fdt, void *dest_fdt);
> >
> > #endif /* _U_BOOT_RISCV_H_ */
> > diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile
> > index adadbf4bcbef..d132b59ce32c 100644
> > --- a/arch/riscv/lib/Makefile
> > +++ b/arch/riscv/lib/Makefile
> > @@ -24,6 +24,7 @@ obj-y += reset.o
> > obj-y += setjmp.o
> > obj-$(CONFIG_SMP) += smp.o
> > obj-$(CONFIG_SPL_BUILD) += spl.o
> > +obj-y += fdt_fixup.o
> >
> > # For building EFI apps
> > CFLAGS_$(EFI_CRT0) := $(CFLAGS_EFI)
> > diff --git a/arch/riscv/lib/asm-offsets.c b/arch/riscv/lib/asm-offsets.c
> > index 4fa4fd371473..7301c1b98e23 100644
> > --- a/arch/riscv/lib/asm-offsets.c
> > +++ b/arch/riscv/lib/asm-offsets.c
> > @@ -14,6 +14,7 @@
> > int main(void)
> > {
> > DEFINE(GD_BOOT_HART, offsetof(gd_t, arch.boot_hart));
> > + DEFINE(GD_FIRMWARE_FDT_ADDR, offsetof(gd_t, arch.firmware_fdt_addr));
> > #ifndef CONFIG_XIP
> > DEFINE(GD_AVAILABLE_HARTS, offsetof(gd_t, arch.available_harts));
> > #endif
> > diff --git a/arch/riscv/lib/fdt_fixup.c b/arch/riscv/lib/fdt_fixup.c
> > new file mode 100644
> > index ..f3d1ec5c5d02
> > --- /dev/null
> > +++ b/arch/riscv/lib/fdt_fixup.c
> > @@ -0,0 +1,80 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (c) 2020 Western Digital Corporation or its affiliates
> > + *
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +DECLARE_GLOBAL_DATA_PTR;
> > +
>
> Please, provide Sphinx style comments for new functions. Cf.
> https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html.
>
Sure. I will do that.
> > +int riscv_fdt_copy_resv_mem_node(const void *src, void *dst)
> > +{
> > + u32 phandle;
> > + struct fdt_memory pmp_mem;
> > + fdt_addr_t addr;
> > + fdt_size_t size;
> > + int offset, node, err, rmem_offset;
> > + bool nomap = true;
> > + char basename[32] = {0};
> > + int bname_len;
> > + int max_len = sizeof(basename);
> > + const char *name;
> > + char *temp;
> > +
> > + offset = fdt_path_offset(src, "/reserved-memory");
> > + if (offset < 0) {
> > + printf("No reserved memory region found in source FDT\n");
> > + return 0;
> > + }
> > +
> > + fdt_for_each_subnode(node, src, offset) {
> > + name = fdt_get_name(src, node, NULL);
> > +
> > + addr =
Re: [PATCH v4 5/6] riscv: Copy the reserved-memory nodes to final DT
On Mon, Mar 23, 2020 at 11:23 PM Heinrich Schuchardt wrote:
>
> On 3/24/20 5:16 AM, Atish Patra wrote:
> > The DT used by U-Boot may be different from the DT being passed to
> > the OS if the DT is loaded from external media such as network or
> > mmc. In that case, the reserved-memory node needs to be copied to
> > the DT passed to the OS.
>
> The bootefi command works in the following sequence:
>
> * copy the passed fdt of if none is passed the internal fdt
> * call image_setup_libfdt() for the copy
> * create memory reservations in the UEFI memory map
>
> Cf.
> fef907b2e440 ("efi_loader: create reservations after ft_board_setup")
> 7be64b885a36 ("cmd: bootefi: Parse reserved-memory node from DT")
>
> image_setup_libfdt() executes among others:
>
> * fdt_chosen()
> * arch_fixup_fdt()
>
> Please, explain why you need to copy memory reservations, if
> arch_fixup_fdt() is executed inside the bootefi command:
>
As per my understanding, there can be two different DTs in U-Boot.
1. Internal device tree or DT passed from previous stage (gd->fdt_blob). This
device tree is being used to boot OS as well.
2. User can load the DT from MMC/network to any valid address and use
that address in bootefi/booti command line to boot OS.
efi_install_fdt copies DT from the given user address (via cmdline) and copies
to the efi memory.
There is no need to 2nd copy for case 1 as the DT already contains the
reserved-memory node. In case 2, the DT loaded from external media may not
have the reserved memory regions set by the firmware. That's why we need to
copy the reserved-memory nodes. Now, arch_fixup_fdt() is the last place to edit
the DT passed to OS. The copy operation has to be done in arch_fixup_fdt.
For case 1, fdtdec_add_reserved_memory will simply return without
modifying the DT.
> What would be the source of memory reservation that you would otherwise
> miss in the final device tree? Do you expect that the Linux device tree
> would lack reservation that are generated on the fly before U-Boot?
>
> Best regards
>
> Heinrich
>
> >
> > Signed-off-by: Atish Patra
> > Reviewed-by: Bin Meng
> > ---
> > arch/riscv/lib/bootm.c | 8 +++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/riscv/lib/bootm.c b/arch/riscv/lib/bootm.c
> > index 87cadad5016d..8ff8db6bf533 100644
> > --- a/arch/riscv/lib/bootm.c
> > +++ b/arch/riscv/lib/bootm.c
> > @@ -28,8 +28,8 @@ __weak void board_quiesce_devices(void)
> >
> > int arch_fixup_fdt(void *blob)
> > {
> > -#ifdef CONFIG_EFI_LOADER
> > int err;
> > +#ifdef CONFIG_EFI_LOADER
> > u32 size;
> > int chosen_offset;
> >
> > @@ -50,6 +50,12 @@ int arch_fixup_fdt(void *blob)
> > /* Overwrite the boot-hartid as U-Boot is the last stage BL */
> > fdt_setprop_u32(blob, chosen_offset, "boot-hartid",
> > gd->arch.boot_hart);
> > #endif
> > +
> > + /* Copy the reserved-memory node to the DT used by OS */
> > + err = riscv_fdt_copy_resv_mem_node(gd->fdt_blob, blob);
> > + if (err < 0)
> > + return err;
> > +
> > return 0;
> > }
> >
> >
>
--
Regards,
Atish
Re: [PATCH v2 0/3] Support SDMA mode on RPI4 target - 32bit
On 3/23/20 10:14 AM, Peng Fan wrote: > Hi Jaehoon, > >> Subject: Re: [PATCH v2 0/3] Support SDMA mode on RPI4 target - 32bit >> >> On 3/18/20 10:00 AM, Peng Fan wrote: Subject: Re: [PATCH v2 0/3] Support SDMA mode on RPI4 target - 32bit Hi Is there any comment or plan to apply? >>> >>> Sorry, I missed this patchset. Will pick it up. > > This patchset could not be applied on master, would you rebase? Sure, i will resend after rebase on latest. Best Regards, Jaehoon Chung > > Thanks, > Peng. > >> >> No problem. :) Thanks! >> >> Best Regards, >> Jaehoon Chung >> >>> >>> Thanks, >>> Peng. >>> Best Regards, Jaehoon Chung On 2/18/20 10:25 AM, Jaehoon Chung wrote: > RPI4's SDHCI controller is supported SDMA mode. (Checked on kernel > side) But It doesn't use on u-boot side. Then it's too slow about > read/write performance. > This patchset is supported SDMA mode on RPI4 target(32bit). > - I didn't test on RPI4 64bit. > > Read/write time about 8MB file > Before > - Read : 1.472 seconds > - Write : 4.690 seconds > After > - Read : 0.359 seconds > - Write : 0.574 seconds > > This patch is based on my RFC's patches.RPI4's SDHCI controller is > supported SDMA mode. (Checked on kernel side) But It doesn't use on u-boot side. Then it's too slow about read/write performance. > This patchset is supported SDMA mode on RPI4 target(32bit). > - I didn't test on RPI4 64bit. > > Read/write time about 8MB file > Before > - Read : 1.472 seconds > - Write : 4.690 seconds > After > - Read : 0.359 seconds > - Write : 0.574 seconds > > This patch is based on my RFC's patches. > > Changelog on V2 > - Keep printf message instead of debug > - Add Peng's Reviewed-by tag > > Jaehoon Chung (3): > mmc: sdhci: use phys2bus macro when dma address is accessed > mmc: sdhci: not return error when SDMA is not supported > configs: rpi_4_32b_defconfig: enable SDHCI_SDMA config > > configs/rpi_4_32b_defconfig | 1 + > drivers/mmc/sdhci.c | 13 +++-- > 2 files changed, 8 insertions(+), 6 deletions(-) > >>> >
Re: [RFT PATCH v1 1/5] Revert "usb: ehci-hcd: Keep async schedule running"
Hi Marek, > On 3/23/20 1:41 PM, Lukasz Majewski wrote: > > Hi Marek, > > Hi, > > >> On 3/23/20 7:57 AM, Lukasz Majewski wrote: > >>> Hi Marek, > >> > >> Hi, > >> > On 3/22/20 2:00 PM, Lukasz Majewski wrote: > > This reverts commit 02b0e1a36c5bc20174299312556ec4e266872bd6. > > > > Signed-off-by: Lukasz Majewski > > This patch lacks any and all explanation why this is being > reverted. The patch you are reverting here explains why it was > added and what real issues it was fixing, so instead of reverting > it, if there is an issue with that patch, you should identify the > issue and fix it. > >>> > >>> Marek, have you received the cover letter for this patch series? > >>> > >>> In the cover letter I've written the rationale for reverting this > >>> patch. > >> > >> That should have been explained in this patch description. > >> > >>> In short - qhtoken has value of 0x0, when the token variable shows > >>> errors. As a result the error handling is broken. > >>> Could you comment on those arguments? > >> > >> Maybe you are referencing/reading the wrong token ? > > > > I'm printing the token which is used afterwards for reacting on > > possible errors. > > > >> > >> You should probably figure out why this doesn't work first and then > >> add fixes on top. > > > > Haven't you seen such problem during code development on your setup > > when developing this patch? > > During the development of the patch, I don't remember, sorry. I most > certainly saw various failure modes, however those should not be > present mainline. The issue is that the qhtoken is not updated at all. Maybe you remember - is Linux using async setup by default (as introduced in SHA1: 02b0e1a36c5bc20174299312556ec4e266872bd6) ? > > I tested this patch with the problematic USB sticks on R-Car Gen3 and > with SMSC95xx USB ethernet adapter last weekend and I didn't see a > problem. Ok. For i.MX6Q: The SHA1: 02b0e1a36c5bc20174299312556ec4e266872bd6 patch causes the iMX6Q to fail after a few minutes of testing. General in i.MX6Q the usb is NOT robust at all. For i.MX53: With patch 02b0e1a36c5bc20174299312556ec4e266872bd6 applied it also breaks after a few minutes. With this patch series applied it works for 2 days now without any issue. Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpou41a3i27T.pgp Description: OpenPGP digital signature
[PATCH 1/1] efi_loader: only reserve memory if fdt node enabled
Sub-nodes of /reserved-memory may be disabled. In this case we should not
reserve memory in the memory map.
Reported-by: Patrick DELAUNAY
Fixes: fef907b2e440 ("efi_loader: create reservations after
ft_board_setup")
Signed-off-by: Heinrich Schuchardt
---
cmd/bootefi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 3bbe2d6a1a..aaed575505 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -199,7 +199,8 @@ static void efi_carve_out_dt_rsv(void *fdt)
* The /reserved-memory node may have children with
* a size instead of a reg property.
*/
- if (addr != FDT_ADDR_T_NONE)
+ if (addr != FDT_ADDR_T_NONE &&
+ fdtdec_get_is_enabled(fdt, subnode))
efi_reserve_memory(addr, size);
subnode = fdt_next_subnode(fdt, subnode);
}
--
2.25.1
Re: [PATCH v4 5/6] riscv: Copy the reserved-memory nodes to final DT
On 3/24/20 5:16 AM, Atish Patra wrote:
The DT used by U-Boot may be different from the DT being passed to
the OS if the DT is loaded from external media such as network or
mmc. In that case, the reserved-memory node needs to be copied to
the DT passed to the OS.
The bootefi command works in the following sequence:
* copy the passed fdt of if none is passed the internal fdt
* call image_setup_libfdt() for the copy
* create memory reservations in the UEFI memory map
Cf.
fef907b2e440 ("efi_loader: create reservations after ft_board_setup")
7be64b885a36 ("cmd: bootefi: Parse reserved-memory node from DT")
image_setup_libfdt() executes among others:
* fdt_chosen()
* arch_fixup_fdt()
Please, explain why you need to copy memory reservations, if
arch_fixup_fdt() is executed inside the bootefi command:
What would be the source of memory reservation that you would otherwise
miss in the final device tree? Do you expect that the Linux device tree
would lack reservation that are generated on the fly before U-Boot?
Best regards
Heinrich
Signed-off-by: Atish Patra
Reviewed-by: Bin Meng
---
arch/riscv/lib/bootm.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/riscv/lib/bootm.c b/arch/riscv/lib/bootm.c
index 87cadad5016d..8ff8db6bf533 100644
--- a/arch/riscv/lib/bootm.c
+++ b/arch/riscv/lib/bootm.c
@@ -28,8 +28,8 @@ __weak void board_quiesce_devices(void)
int arch_fixup_fdt(void *blob)
{
-#ifdef CONFIG_EFI_LOADER
int err;
+#ifdef CONFIG_EFI_LOADER
u32 size;
int chosen_offset;
@@ -50,6 +50,12 @@ int arch_fixup_fdt(void *blob)
/* Overwrite the boot-hartid as U-Boot is the last stage BL */
fdt_setprop_u32(blob, chosen_offset, "boot-hartid", gd->arch.boot_hart);
#endif
+
+ /* Copy the reserved-memory node to the DT used by OS */
+ err = riscv_fdt_copy_resv_mem_node(gd->fdt_blob, blob);
+ if (err < 0)
+ return err;
+
return 0;
}
Re: [PATCH v4 3/6] riscv: Provide a mechanism to fix DT for reserved memory
On 3/24/20 5:16 AM, Atish Patra wrote:
In RISC-V, M-mode software can reserve physical memory regions
by setting appropriate physical memory protection (PMP) csr. As the
PMP csr are accessible only in M-mode, S-mode U-Boot can not read
this configuration directly. However, M-mode software can pass this
information via reserved-memory node in device tree so that S-mode
software can access this information.
This patch provides a framework to copy to the reserved-memory node
from one DT to another. This will be used to update the DT used by
U-Boot and the DT passed to the next stage OS.
Signed-off-by: Atish Patra
---
arch/riscv/cpu/start.S| 1 +
arch/riscv/include/asm/global_data.h | 1 +
arch/riscv/include/asm/u-boot-riscv.h | 2 +
arch/riscv/lib/Makefile | 1 +
arch/riscv/lib/asm-offsets.c | 1 +
arch/riscv/lib/fdt_fixup.c| 80 +++
6 files changed, 86 insertions(+)
create mode 100644 arch/riscv/lib/fdt_fixup.c
diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
index 6b3ff99c3882..0282685c2906 100644
--- a/arch/riscv/cpu/start.S
+++ b/arch/riscv/cpu/start.S
@@ -121,6 +121,7 @@ call_board_init_f_0:
jal board_init_f_init_reserve
+ SREGs1, GD_FIRMWARE_FDT_ADDR(gp)
/* save the boot hart id to global_data */
SREGtp, GD_BOOT_HART(gp)
diff --git a/arch/riscv/include/asm/global_data.h
b/arch/riscv/include/asm/global_data.h
index b74bd7e738bb..51ac8d1c98e2 100644
--- a/arch/riscv/include/asm/global_data.h
+++ b/arch/riscv/include/asm/global_data.h
@@ -15,6 +15,7 @@
/* Architecture-specific global data */
struct arch_global_data {
long boot_hart; /* boot hart id */
+ phys_addr_t firmware_fdt_addr;
#ifdef CONFIG_SIFIVE_CLINT
void __iomem *clint;/* clint base address */
#endif
diff --git a/arch/riscv/include/asm/u-boot-riscv.h
b/arch/riscv/include/asm/u-boot-riscv.h
index 49febd588102..543a1688db8f 100644
--- a/arch/riscv/include/asm/u-boot-riscv.h
+++ b/arch/riscv/include/asm/u-boot-riscv.h
@@ -17,5 +17,7 @@ int cleanup_before_linux(void);
/* board/.../... */
int board_init(void);
void board_quiesce_devices(void);
+int riscv_board_reserved_mem_fixup(void *fdt);
+int riscv_fdt_copy_resv_mem_node(const void *src_fdt, void *dest_fdt);
#endif/* _U_BOOT_RISCV_H_ */
diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile
index adadbf4bcbef..d132b59ce32c 100644
--- a/arch/riscv/lib/Makefile
+++ b/arch/riscv/lib/Makefile
@@ -24,6 +24,7 @@ obj-y += reset.o
obj-y += setjmp.o
obj-$(CONFIG_SMP) += smp.o
obj-$(CONFIG_SPL_BUILD) += spl.o
+obj-y += fdt_fixup.o
# For building EFI apps
CFLAGS_$(EFI_CRT0) := $(CFLAGS_EFI)
diff --git a/arch/riscv/lib/asm-offsets.c b/arch/riscv/lib/asm-offsets.c
index 4fa4fd371473..7301c1b98e23 100644
--- a/arch/riscv/lib/asm-offsets.c
+++ b/arch/riscv/lib/asm-offsets.c
@@ -14,6 +14,7 @@
int main(void)
{
DEFINE(GD_BOOT_HART, offsetof(gd_t, arch.boot_hart));
+ DEFINE(GD_FIRMWARE_FDT_ADDR, offsetof(gd_t, arch.firmware_fdt_addr));
#ifndef CONFIG_XIP
DEFINE(GD_AVAILABLE_HARTS, offsetof(gd_t, arch.available_harts));
#endif
diff --git a/arch/riscv/lib/fdt_fixup.c b/arch/riscv/lib/fdt_fixup.c
new file mode 100644
index ..f3d1ec5c5d02
--- /dev/null
+++ b/arch/riscv/lib/fdt_fixup.c
@@ -0,0 +1,80 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2020 Western Digital Corporation or its affiliates
+ *
+ */
+
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
Please, provide Sphinx style comments for new functions. Cf.
https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html.
+int riscv_fdt_copy_resv_mem_node(const void *src, void *dst)
+{
+ u32 phandle;
+ struct fdt_memory pmp_mem;
+ fdt_addr_t addr;
+ fdt_size_t size;
+ int offset, node, err, rmem_offset;
+ bool nomap = true;
+ char basename[32] = {0};
+ int bname_len;
+ int max_len = sizeof(basename);
+ const char *name;
+ char *temp;
+
+ offset = fdt_path_offset(src, "/reserved-memory");
+ if (offset < 0) {
+ printf("No reserved memory region found in source FDT\n");
+ return 0;
+ }
+
+ fdt_for_each_subnode(node, src, offset) {
+ name = fdt_get_name(src, node, NULL);
+
+ addr = fdtdec_get_addr_size_auto_noparent(src, node,
+ "reg", 0, ,
+ false);
+ if (addr == FDT_ADDR_T_NONE) {
+ debug("failed to read address/size for %s\n", name);
+ continue;
+ }
+ strncpy(basename, name, max_len);
+ temp = strchr(basename, '@');
+ if (temp) {
+ bname_len = strnlen(basename,
