[PATCH] usb: mtu3: flush cache for next GPD
When flush cache of the current GPD and resume QMU, the controller will try to access the next GPD after processing the current one, if not flush the next GPD, the controller may get wrong GPD status. Signed-off-by: Chunfeng Yun --- drivers/usb/mtu3/mtu3_qmu.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/usb/mtu3/mtu3_qmu.c b/drivers/usb/mtu3/mtu3_qmu.c index 801c2bc416..95eaf6d236 100644 --- a/drivers/usb/mtu3/mtu3_qmu.c +++ b/drivers/usb/mtu3/mtu3_qmu.c @@ -198,6 +198,7 @@ static int mtu3_prepare_tx_gpd(struct mtu3_ep *mep, struct mtu3_request *mreq) enq->flag &= ~GPD_FLAGS_HWO; gpd->next_gpd = cpu_to_le32((u32)gpd_virt_to_dma(ring, enq)); + mtu3_flush_cache((uintptr_t)enq, sizeof(*gpd)); if (req->zero) gpd->ext_flag |= GPD_EXT_FLAG_ZLP; @@ -234,6 +235,8 @@ static int mtu3_prepare_rx_gpd(struct mtu3_ep *mep, struct mtu3_request *mreq) enq->flag &= ~GPD_FLAGS_HWO; gpd->next_gpd = cpu_to_le32((u32)gpd_virt_to_dma(ring, enq)); + mtu3_flush_cache((uintptr_t)enq, sizeof(*gpd)); + gpd->flag |= GPD_FLAGS_IOC | GPD_FLAGS_HWO; mreq->gpd = gpd; -- 2.18.0
RE: [EXT] Re: [PATCH 4/4] imx8mq_evk: Enable the USB3.0 host port
> -Original Message-
> From: Ye Li
> Sent: 2021年2月27日 14:05
> To: feste...@gmail.com; Bough Chen
> Cc: Peng Fan ; u-boot@lists.denx.de; dl-uboot-imx
> ; sba...@denx.de
> Subject: Re: [EXT] Re: [PATCH 4/4] imx8mq_evk: Enable the USB3.0 host port
>
> Hi Fabio,
>
> On Thu, 2021-02-25 at 10:49 -0300, Fabio Estevam wrote:
> > Caution: EXT Email
> >
> > Hi Ye Li,
> >
> > On Thu, Feb 25, 2021 at 10:34 AM Ye Li wrote:
> >
> > >
> > > Sure, I have tested it on 8mq evk. I can reproduce the two issues
> > > you met.
> > > The first issue is caused by the ALIGN. The implementation of
> > > standard ALIGN requires the aligned size to be power of 2. But the
> > > ALIGN in imx8mimage does not have this requirement. So below result
> > > is wrong by using the standard ALIGN. Your fix should be OK for this
> > > issue.
> > Good, could you please reply to my ALIGN macro patch with your
> > Tested-by tag then?
> >
> Replied it.
>
> > >
> > > For the second issue, I did not debug into it. But our vendor tree
> > > also uses off-on-delay-us in both u-boot and kernel. So it is likely
> > > caused by other change.
> > Considering we are already at 2021.04-rc2, I think it would be safer
> > to go with my patch that removes off-on-delay-us.
> >
> > What do you think?
> >
> > Thanks
> My debug shows the issue is triggered by below commit:
>
> commit 9098682200e6cca4b776638a51200dafa16f50fb
> Author: Haibo Chen
> Date: Tue Sep 22 18:11:43 2020 +0800
>
> mmc: fsl_esdhc_imx: remove the 1ms delay before sending command
>
> This 1ms delay before sending command already exist from the beginning
> of the fsl_esdhc driver added in year 2008. Now this driver has been
> split for two files: fsl_esdhc.c and fsl_esdhc_imx.c.
> fsl_esdhc_imx.c
> only for i.MX series. i.MX series esdhc/usdhc do not need this 1ms delay
> before sending any command. So remove this 1ms, this will save a lot
> time if handling a large mmc data.
>
> Signed-off-by: Haibo Chen
>
>
> The first "go idle" command in mmc_get_op_cond seems not put SD card to
> idle status, but if adding a delay before it (like 1ms delay), then everything
> works. This commit removed 1ms delay in sending command, so the issue is
> triggered. The root cause might be "startup-delay-us"
> needed for this regulator to reach a threshold voltage for SD working.
> Below change also can fix the issue.
>
> --- a/arch/arm/dts/imx8mq-evk-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mq-evk-u-boot.dtsi
> @@ -1,6 +1,7 @@
> // SPDX-License-Identifier: (GPL-2.0 OR MIT)
>
> ®_usdhc2_vmmc {
> + startup-delay-us = <1000>;
> u-boot,off-on-delay-us = <2>;
> };
>
>
> @Haibo, Could you help looking into the issue. What's your opinion to add the
> startup-delay-us or revert your commit?
>
Hi Fabio,
I co-debug with Ye, and find the issue is also related with clock
enable/disable. For current logic on imx usdhc, hardware automatically gate off
the card clock when idle.
So before the first command "go idle", there is no clock on the clock line,
which not align with the sd spec.
Refer to SD3.0 spec 6.4.1 Power UP
The host shall supply power to the card so that the voltage is reached to
Vdd_min within 250ms and
start to supply at least 74 SD clocks to the SD card with keeping CMD line to
high. In case of SPI
mode, CS shall be held to high during 74 clock cycles
if we give the card the correct clock rate before the first "go idle" command,
this issue gone.
Please try to apply the patch I send on 2021/1/27 [PATCH] mmc: fsl_esdhc_imx:
use VENDORSPEC_FRC_SDCLK_ON to control card clock output
> Best regards,
> Ye Li
smime.p7s
Description: S/MIME cryptographic signature
RE: [PATCH] Revert "mmc: fsl_esdhc_imx: remove the 1ms delay before sending command"
> -Original Message-
> From: Fabio Estevam [mailto:feste...@gmail.com]
> Sent: 2021年2月27日 21:54
> To: Peng Fan
> Cc: u-boot@lists.denx.de; loru...@gmail.com;
> andrey.zhizhi...@leica-geosystems.com; Ye Li ; Bough Chen
> ; sba...@denx.de; tr...@konsulko.com; Fabio Estevam
>
> Subject: [PATCH] Revert "mmc: fsl_esdhc_imx: remove the 1ms delay before
> sending command"
>
> Removing the 1ms delay before sending command causes a regression on
> imx8mq-evk where the SD card cannot be accessed.
>
> Since this 1ms delay has been present since the driver introduction in
2008,
> keep it to avoid regressions.
>
> This reverts commit 9098682200e6cca4b776638a51200dafa16f50fb.
>
Hi Fabio,
This 1ms delay exist in esdhc_send_cmd_common, which means every time we
send a command, will delay 1ms, which will involve a huge delay overall for
the whole u-boot cycle.
For the issue you meet, I already find the root cause, and already reply in
the mail loop: [EXT] Re: [PATCH 4/4] imx8mq_evk: Enable the USB3.0 host port
So I think no need to involve this 1ms back again.
Best regards
Haibo Chen
> Reported-by: Ye Li
> Signed-off-by: Fabio Estevam
> ---
> drivers/mmc/fsl_esdhc_imx.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/mmc/fsl_esdhc_imx.c b/drivers/mmc/fsl_esdhc_imx.c
index
> e0e132698e30..a0a5c8960563 100644
> --- a/drivers/mmc/fsl_esdhc_imx.c
> +++ b/drivers/mmc/fsl_esdhc_imx.c
> @@ -463,6 +463,13 @@ static int esdhc_send_cmd_common(struct
> fsl_esdhc_priv *priv, struct mmc *mmc,
> while (esdhc_read32(®s->prsstat) & PRSSTAT_DLA)
> ;
>
> + /* Wait at least 8 SD clock cycles before the next command */
> + /*
> + * Note: This is way more than 8 cycles, but 1ms seems to
> + * resolve timing issues with some cards
> + */
> + udelay(1000);
> +
> /* Set up for a data transfer if we have one */
> if (data) {
> err = esdhc_setup_data(priv, mmc, data);
> --
> 2.25.1
smime.p7s
Description: S/MIME cryptographic signature
[PATCH 1/2] mmc: fsl_esdhc_imx: use VENDORSPEC_FRC_SDCLK_ON to control card clock output
From: Haibo Chen
For FSL_USDHC, it do not implement VENDORSPEC_CKEN/PEREN/HCKEN/IPGEN, these
are reserved bits. Instead, use VENDORSPEC_FRC_SDCLK_ON to gate on/off the
card clock output.
After commit b5874b552ffa ("mmc: fsl_esdhc_imx: add wait_dat0() support"),
we meet SD3.0 card can't work at UHS mode, mmc_switch_voltage() fail because
the second mmc_wait_dat0 return -ETIMEDOUT. According to SD spec, during
voltage switch, need to gate off/on the card clock. If not set the FRC_SDCLK_ON,
after CMD11, hardware will gate off the card clock automatically, so card do
not detect the clock off/on behavior, so will draw the data0 line low until
next command.
Fixes: b5874b552ffa ("mmc: fsl_esdhc_imx: add wait_dat0() support")
Tested-by: Tim Harvey
Signed-off-by: Haibo Chen
---
drivers/mmc/fsl_esdhc_imx.c | 29 +
include/fsl_esdhc_imx.h | 2 ++
2 files changed, 23 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc_imx.c b/drivers/mmc/fsl_esdhc_imx.c
index e0e132698e..af36558b3c 100644
--- a/drivers/mmc/fsl_esdhc_imx.c
+++ b/drivers/mmc/fsl_esdhc_imx.c
@@ -654,7 +654,10 @@ static void set_sysctl(struct fsl_esdhc_priv *priv, struct
mmc *mmc, uint clock)
clk = (pre_div << 8) | (div << 4);
#ifdef CONFIG_FSL_USDHC
- esdhc_clrbits32(®s->vendorspec, VENDORSPEC_CKEN);
+ esdhc_clrbits32(®s->vendorspec, VENDORSPEC_FRC_SDCLK_ON);
+ ret = readx_poll_timeout(esdhc_read32, ®s->prsstat, tmp, tmp &
PRSSTAT_SDOFF, 100);
+ if (ret)
+ pr_warn("fsl_esdhc_imx: Internal clock never gate off.\n");
#else
esdhc_clrbits32(®s->sysctl, SYSCTL_CKEN);
#endif
@@ -666,7 +669,7 @@ static void set_sysctl(struct fsl_esdhc_priv *priv, struct
mmc *mmc, uint clock)
pr_warn("fsl_esdhc_imx: Internal clock never stabilised.\n");
#ifdef CONFIG_FSL_USDHC
- esdhc_setbits32(®s->vendorspec, VENDORSPEC_PEREN | VENDORSPEC_CKEN);
+ esdhc_setbits32(®s->vendorspec, VENDORSPEC_FRC_SDCLK_ON);
#else
esdhc_setbits32(®s->sysctl, SYSCTL_PEREN | SYSCTL_CKEN);
#endif
@@ -721,8 +724,14 @@ static void esdhc_set_strobe_dll(struct mmc *mmc)
struct fsl_esdhc_priv *priv = dev_get_priv(mmc->dev);
struct fsl_esdhc *regs = priv->esdhc_regs;
u32 val;
+ u32 tmp;
+ int ret;
if (priv->clock > ESDHC_STROBE_DLL_CLK_FREQ) {
+ esdhc_clrbits32(®s->vendorspec, VENDORSPEC_FRC_SDCLK_ON);
+ ret = readx_poll_timeout(esdhc_read32, ®s->prsstat, tmp, tmp
& PRSSTAT_SDOFF, 100);
+ if (ret)
+ pr_warn("fsl_esdhc_imx: Internal clock never gate
off.\n");
esdhc_write32(®s->strobe_dllctrl,
ESDHC_STROBE_DLL_CTRL_RESET);
/*
@@ -740,6 +749,7 @@ static void esdhc_set_strobe_dll(struct mmc *mmc)
pr_warn("HS400 strobe DLL status REF not lock!\n");
if (!(val & ESDHC_STROBE_DLL_STS_SLV_LOCK))
pr_warn("HS400 strobe DLL status SLV not lock!\n");
+ esdhc_setbits32(®s->vendorspec, VENDORSPEC_FRC_SDCLK_ON);
}
}
@@ -963,14 +973,18 @@ static int esdhc_set_ios_common(struct fsl_esdhc_priv
*priv, struct mmc *mmc)
#ifdef MMC_SUPPORTS_TUNING
if (mmc->clk_disable) {
#ifdef CONFIG_FSL_USDHC
- esdhc_clrbits32(®s->vendorspec, VENDORSPEC_CKEN);
+ u32 tmp;
+
+ esdhc_clrbits32(®s->vendorspec, VENDORSPEC_FRC_SDCLK_ON);
+ ret = readx_poll_timeout(esdhc_read32, ®s->prsstat, tmp, tmp
& PRSSTAT_SDOFF, 100);
+ if (ret)
+ pr_warn("fsl_esdhc_imx: Internal clock never gate
off.\n");
#else
esdhc_clrbits32(®s->sysctl, SYSCTL_CKEN);
#endif
} else {
#ifdef CONFIG_FSL_USDHC
- esdhc_setbits32(®s->vendorspec, VENDORSPEC_PEREN |
- VENDORSPEC_CKEN);
+ esdhc_setbits32(®s->vendorspec, VENDORSPEC_FRC_SDCLK_ON);
#else
esdhc_setbits32(®s->sysctl, SYSCTL_PEREN | SYSCTL_CKEN);
#endif
@@ -1046,7 +1060,7 @@ static int esdhc_init_common(struct fsl_esdhc_priv *priv,
struct mmc *mmc)
#ifndef CONFIG_FSL_USDHC
esdhc_setbits32(®s->sysctl, SYSCTL_HCKEN | SYSCTL_IPGEN);
#else
- esdhc_setbits32(®s->vendorspec, VENDORSPEC_HCKEN | VENDORSPEC_IPGEN);
+ esdhc_setbits32(®s->vendorspec, VENDORSPEC_FRC_SDCLK_ON);
#endif
/* Set the initial clock speed */
@@ -1184,8 +1198,7 @@ static int fsl_esdhc_init(struct fsl_esdhc_priv *priv,
esdhc_write32(®s->autoc12err, 0);
esdhc_write32(®s->clktunectrlstatus, 0);
#else
- esdhc_setbits32(®s->vendorspec, VENDORSPEC_PEREN |
- VENDORSPEC_HCKEN | VENDORSPEC_IPGEN | VENDORSPEC_CKEN);
+ esdhc_setbits32(®s->vendorspec, VENDORSPEC_FRC_SDCLK_ON);
#endif
if (priv->vs18_enable)
diff --git a/include/fsl_esdhc_imx.h b/include/fsl_esdhc_imx.h
index 45ed635a77..b092
[PATCH 2/2] mmc: fsl_esdhc_imx: remove redundant cmd11 related code.
From: Haibo Chen
Common code already handle the voltage switch sequence based on spec,
so remove the redundant voltage switch code.
Signed-off-by: Haibo Chen
---
drivers/mmc/fsl_esdhc_imx.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc_imx.c b/drivers/mmc/fsl_esdhc_imx.c
index af36558b3c..a199cf3df6 100644
--- a/drivers/mmc/fsl_esdhc_imx.c
+++ b/drivers/mmc/fsl_esdhc_imx.c
@@ -515,15 +515,6 @@ static int esdhc_send_cmd_common(struct fsl_esdhc_priv
*priv, struct mmc *mmc,
goto out;
}
- /* Switch voltage to 1.8V if CMD11 succeeded */
- if (cmd->cmdidx == SD_CMD_SWITCH_UHS18V) {
- esdhc_setbits32(®s->vendorspec, ESDHC_VENDORSPEC_VSELECT);
-
- printf("Run CMD11 1.8V switch\n");
- /* Sleep for 5 ms - max time for card to switch to 1.8V */
- udelay(5000);
- }
-
/* Workaround for ESDHC errata ENGcm03648 */
if (!data && (cmd->resp_type & MMC_RSP_BUSY)) {
int timeout = 5;
@@ -839,6 +830,7 @@ static int esdhc_set_voltage(struct mmc *mmc)
}
#endif
esdhc_setbits32(®s->vendorspec, ESDHC_VENDORSPEC_VSELECT);
+ mdelay(5);
if (esdhc_read32(®s->vendorspec) & ESDHC_VENDORSPEC_VSELECT)
return 0;
--
2.17.1
RE: [PATCH 3/3 v5] efi: ESRT creation tests
Hi Takahiro Akashi,
Thank you for reviewing these tests.
> -Original Message-
> From: AKASHI Takahiro
> Sent: 02 March 2021 23:49
> To: Heinrich Schuchardt
> Cc: Jose Marinho ; u-boot@lists.denx.de;
> Sughosh Ganu ; Ilias Apalodimas
> ; Andre Przywara ;
> Alexander Graf ; nd
> Subject: Re: [PATCH 3/3 v5] efi: ESRT creation tests
>
> On Tue, Mar 02, 2021 at 07:30:31PM +0100, Heinrich Schuchardt wrote:
> > On 02.03.21 13:13, Jose Marinho wrote:
> > > This commmit exercises the ESRT creation in two tests.
> > >
> > > test 1:
> > > A fake FMP, with TEST_ESRT_NUM_ENTRIES FW images, is installed in
> > > the system leading to the corresponding ESRT entries being populated.
> > > The ESRT entries are checked against the datastructure used to
> > > initialize the FMP.
> > >
> > > test 1 invocation:
> > > add to sandbox_defconfig:
> > > +CONFIG_EFI_SELFTEST=y
> >
> > EFI_SELFTEST is active on many QEMU devices. So the test could run there.
> >
> > >
> > > make sandbox_capsule_defconfig all
> > > ./u-boot -d arch/sandbox/dts/test.dtb bootefi selftest
> > >
> > > test 2:
> > > The test is part of test_efi_capsule_fw3.
> > >
> > > In order to run the test the following must be added to
> > > sandbox_defconfig:
> > > +CONFIG_CMD_SF=y
> > > +CONFIG_CMD_MEMORY=y
> > > +CONFIG_CMD_FAT=y
> > > +CONFIG_DFU=y
> > >
> > > The ESRT is printed in the u-boot shell by calling efidebug esrt.
> > > The test ensures that, after the capsule is installed, the ESRT
> > > contains entries with the GUIDs:
> > > - EFI_FIRMWARE_IMAGE_TYPE_UBOOT_FIT_GUID;
> > > - EFI_FIRMWARE_IMAGE_TYPE_UBOOT_RAW_GUID;
> > >
> > > test 2 invocation:
> > > sudo ./test/py/test.py --bd sandbox -k capsule_fw3 -l --build
> > >
> > > Signed-off-by: Jose Marinho
> > >
> > > CC: Heinrich Schuchardt
> > > CC: Sughosh Ganu
> > > CC: AKASHI Takahiro
> > > CC: Ilias Apalodimas
> > > CC: Andre Przywara
> > > CC: Alexander Graf
> > > CC: n...@arm.com
> > >
> > > ---
> > > lib/efi_selftest/Makefile | 2 +
> > > lib/efi_selftest/efi_selftest_esrt.c | 227 ++
> > > .../test_efi_capsule/test_capsule_firmware.py | 4 +
> > > 3 files changed, 233 insertions(+)
> > > create mode 100644 lib/efi_selftest/efi_selftest_esrt.c
> > >
> > > diff --git a/lib/efi_selftest/Makefile b/lib/efi_selftest/Makefile
> > > index 7d6ea30102..017b191a46 100644
> > > --- a/lib/efi_selftest/Makefile
> > > +++ b/lib/efi_selftest/Makefile
> > > @@ -72,6 +72,8 @@ ifeq ($(CONFIG_BLK)$(CONFIG_DOS_PARTITION),yy)
> > > obj-y += efi_selftest_block_device.o endif
> > >
> > > +obj-$(CONFIG_EFI_ESRT) += efi_selftest_esrt.o
> > > +
> > > targets += \
> > > efi_miniapp_file_image_exception.h \ efi_miniapp_file_image_exit.h
> > > \ diff --git a/lib/efi_selftest/efi_selftest_esrt.c
> > > b/lib/efi_selftest/efi_selftest_esrt.c
> > > new file mode 100644
> > > index 00..b053b2e6c6
> > > --- /dev/null
> > > +++ b/lib/efi_selftest/efi_selftest_esrt.c
> > > @@ -0,0 +1,227 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +/*
> > > + * Test ESRT tables support
> > > + *
> > > + * Copyright (C) 2021 Arm Ltd.
> > > + */
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +// This value must not exceed 255.
> > > +// An FMP cannot contain more than 255 FW images.
> > > +#define TEST_ESRT_NUM_ENTRIES 255
> > > +
> > > +static
> > > +struct efi_firmware_image_descriptor
> > > +static_img_info[TEST_ESRT_NUM_ENTRIES];
> > > +
> > > +static void efi_test_esrt_init_info(void) {
> > > + for (int idx = 0; idx < TEST_ESRT_NUM_ENTRIES; idx++) {
> > > + static_img_info[idx].image_index = idx;
> > > +
> > > + // Note: the 16 byte value present in
> > > + // static_img_info[idx].image_type_id is not strictly a GUID.
> > > + // The value is used for the sake of code testing.
> > > + static_img_info[idx].image_type_id.b[0] = idx;
> > > +
> > > + static_img_info[idx].image_id = 0;
> > > + static_img_info[idx].image_id_name = NULL;
> > > + static_img_info[idx].version = 0;
> > > + static_img_info[idx].version_name = NULL;
> > > + static_img_info[idx].size = 0;
> > > + static_img_info[idx].lowest_supported_image_version = 1;
> > > + static_img_info[idx].last_attempt_version = 2;
> > > + static_img_info[idx].last_attempt_status = 3;
> > > + static_img_info[idx].hardware_instance = 1;
> > > + }
> > > +}
> > > +
> > > +static efi_status_t
> > > +EFIAPI efi_test_fmp_get_image_info(struct
> efi_firmware_management_protocol *this,
> > > +efi_uintn_t *image_info_size,
> > > +struct efi_firmware_image_descriptor
> *image_info,
> > > +u32 *descriptor_version,
> > > +u8 *descriptor_count,
> > > +efi_uintn_t *descriptor_size,
> > > +u32 *packa
Re: [PATCH] hush: Fix assignments being misinterpreted as commands
Dear Tom, In message <20210302133435.GZ10169@bill-the-cat> you wrote: > > > Only the third example is affected by this patch. > > OK. But to what end? Historically we have a buggy but mostly > compatible "hush" that acts like "sh" does. A more flexible shell could > solve a lot of different use cases including making boot scripts that > people end up writing being clearer and easier to write/debug/maintain. > What I worry about here is making our shell not act like any regular > shell people use. I am always surprised why people try to add minor fixes (and sometimes bells and whistles) to ancient versions of the software without checking recent code first. The shell in busybox v1.32 shows this behaviour: $ foo=bar echo $foo $ echo $foo $ baz=bar echo qux qux $ So the specific problem has (long) been fixed in upstream, and instead of adding a patch to our old version, thus cementing the broken behaviour, we should upgrade hush to recent upstream code. Yes, I am aware that this is a lot more effort that this little patch, but if we could combine the efforts that have already been wasted over the years for such little fixes here and there wew could have upgraded long ago. Grooming a dead horse makes little sense to me. 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 What is research but a blind date with knowledge? -- Will Harvey
[PATCH] fs/squashfs: Fix compilation error
Commit 401d1c4f5d2d29c4bc4beaec95402ca23eb63295 ("common: Drop
asm/global_data.h from common header") broke compilation of squashfs
filesystem when CONFIG_CMD_SQUASHFS=y is enabled.
Compilation is failing on error:
aarch64-linux-gnu-ld.bfd: u-boot/fs/squashfs/sqfs_inode.c:121: undefined
reference to `le32_to_cpu'
Fixes: 401d1c4f5d2d29c4bc4beaec95402ca23eb63295 ("common: Drop
asm/global_data.h from common header")
Suggested-by: Tom Rini
Signed-off-by: Pali Rohár
---
Please include this change into U-Boot master branch which is currently
affected by this issue.
---
fs/squashfs/sqfs_inode.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/squashfs/sqfs_inode.c b/fs/squashfs/sqfs_inode.c
index e76ec7cbdfd9..d25cfb53e75d 100644
--- a/fs/squashfs/sqfs_inode.c
+++ b/fs/squashfs/sqfs_inode.c
@@ -6,6 +6,7 @@
*/
#include
+#include
#include
#include
#include
--
2.20.1
Re: Commit 401d1c4f5d2 ("common: Drop asm/global_data.h from common header") broke CONFIG_CMD_SQUASHFS=y
On Tuesday 02 March 2021 16:27:27 Tom Rini wrote:
> On Tue, Mar 02, 2021 at 05:59:47PM +0100, Pali Rohár wrote:
> > On Friday 26 February 2021 13:54:40 Pali Rohár wrote:
> > > On Friday 26 February 2021 07:51:53 Tom Rini wrote:
> > > > On Fri, Feb 26, 2021 at 01:34:29PM +0100, Pali Rohár wrote:
> > > >
> > > > > Hello!
> > > > >
> > > > > Commit 401d1c4f5d2d29c4bc4beaec95402ca23eb63295 ("common: Drop
> > > > > asm/global_data.h from common header") broke compilation of
> > > > > squashfs filesystem when CONFIG_CMD_SQUASHFS=y is enabled.
> > > > >
> > > > > Here is console output:
> > > > >
> > > > > fs/squashfs/sqfs_inode.c: In function ‘sqfs_find_inode’:
> > > > > fs/squashfs/sqfs_inode.c:121:18: warning: implicit declaration of
> > > > > function ‘le32_to_cpu’ [-Wimplicit-function-declaration]
> > > > > for (k = 0; k < le32_to_cpu(inode_count); k++) {
> > > > > ^~~
> > > > > LD u-boot
> > > > > aarch64-linux-gnu-ld.bfd: fs/built-in.o: in function
> > > > > `sqfs_find_inode':
> > > > > /u-boot/fs/squashfs/sqfs_inode.c:126: undefined reference to
> > > > > `le32_to_cpu'
> > > > > aarch64-linux-gnu-ld.bfd: /u-boot/fs/squashfs/sqfs_inode.c:121:
> > > > > undefined reference to `le32_to_cpu'
> > > > > Segmentation fault
> > > > > make: *** [Makefile:1765: u-boot] Error 139
> > > > > make: *** Deleting file 'u-boot'
> > > > >
> > > > > When compiling U-Boot prior that commit, there is no error.
> > > > >
> > > > > Simon and Tom: you have signed problematic mentioned commit. Could you
> > > > > please look at it?
> > > >
> > > > Yes, that file probably needs , please check.
> > > >
> > > > --
> > > > Tom
> > >
> > > Perfect, including fixed it!
> >
> > Simon, or Tom, are you going to fix this issue in U-Boot master branch?
> > I think patch needs Fixes: tag with mentioned commit as it broke
> > compilation of U-Boot.
>
> No, I was assuming you would submit a patch since nothing in mainline
> atm is tripping on this issue.
Ok, I have done it, I sent patch ML. Please review it.
Re: [PATCH v3 1/4] firmware: scmi: voltage regulator
Hi Etienne,
On 2/22/21 8:27 AM, Etienne Carriere wrote:
Implement voltage regulators interfaced by the SCMI voltage domain
protocol. The DT bindings are defined in the Linux kernel since
SCMI voltage domain and regulators patches [1] and [2] integration
in v5.11-rc7.
Link: [1]
https://github.com/torvalds/linux/commit/0f80fcec08e9c50b8d2992cf26495673765ebaba
Link: [2]
https://github.com/torvalds/linux/commit/2add5cacff3531e54c50b0832128299faa9f0563
Signed-off-by: Etienne Carriere
Reviewed-by: Simon Glass
Reviewed-by: Jaehoon Chung
---
Changes in v3:
- applied review tags
Changes in v2:
- no change
---
doc/device-tree-bindings/arm/arm,scmi.txt | 34 +
drivers/firmware/scmi/scmi_agent-uclass.c | 35 -
drivers/power/regulator/Kconfig | 8 +
drivers/power/regulator/Makefile | 1 +
drivers/power/regulator/scmi_regulator.c | 170 ++
include/scmi_protocols.h | 113 ++
6 files changed, 359 insertions(+), 2 deletions(-)
create mode 100644 drivers/power/regulator/scmi_regulator.c
diff --git a/doc/device-tree-bindings/arm/arm,scmi.txt
b/doc/device-tree-bindings/arm/arm,scmi.txt
index 1f293ea24..a76124f4a 100644
--- a/doc/device-tree-bindings/arm/arm,scmi.txt
+++ b/doc/device-tree-bindings/arm/arm,scmi.txt
@@ -62,6 +62,20 @@ Required properties:
- #power-domain-cells : Should be 1. Contains the device or the power
domain ID value used by SCMI commands.
+Regulator bindings for the SCMI Regulator based on SCMI Message Protocol
+
+An SCMI Regulator is permanently bound to a well defined SCMI Voltage Domain,
+and should be always positioned as a root regulator.
+It does not support any current operation.
+
+SCMI Regulators are grouped under a 'regulators' node which in turn is a child
+of the SCMI Voltage protocol node inside the desired SCMI instance node.
+
+This binding uses the common regulator binding[6].
+
+Required properties:
+ - reg : shall identify an existent SCMI Voltage Domain.
+
Sensor bindings for the sensors based on SCMI Message Protocol
--
SCMI provides an API to access the various sensors on the SoC.
@@ -105,6 +119,7 @@ Required sub-node properties:
[3] Documentation/devicetree/bindings/thermal/thermal.txt
[4] Documentation/devicetree/bindings/sram/sram.yaml
[5] Documentation/devicetree/bindings/reset/reset.txt
+[6] Documentation/devicetree/bindings/regulator/regulator.yaml
Example:
@@ -169,6 +184,25 @@ firmware {
reg = <0x16>;
#reset-cells = <1>;
};
+
+ scmi_voltage: protocol@17 {
+ reg = <0x17>;
+
+ regulators {
+ regulator_devX: regulator@0 {
+ reg = <0x0>;
+ regulator-max-microvolt = <330>;
+ };
+
+ regulator_devY: regulator@9 {
+ reg = <0x9>;
+ regulator-min-microvolt = <50>;
+ regulator-max-microvolt = <420>;
+ };
+
+ ...
+ };
+ };
};
};
diff --git a/drivers/firmware/scmi/scmi_agent-uclass.c b/drivers/firmware/scmi/scmi_agent-uclass.c
index 516e690ac..03d236426 100644
--- a/drivers/firmware/scmi/scmi_agent-uclass.c
+++ b/drivers/firmware/scmi/scmi_agent-uclass.c
@@ -50,6 +50,29 @@ int scmi_to_linux_errno(s32 scmi_code)
return -EPROTO;
}
+static int regulator_devices_bind(struct udevice *dev, struct driver *drv,
+ ofnode protocol_node)
+{
+ ofnode regulators_node;
+ ofnode node;
+ int ret;
+
+ regulators_node = ofnode_find_subnode(protocol_node, "regulators");
+ if (!ofnode_valid(regulators_node)) {
+ dev_err(dev, "regulators subnode not found\n");
+ return -ENXIO;
+ }
+
+ ofnode_for_each_subnode(node, regulators_node) {
+ ret = device_bind(dev, drv, ofnode_get_name(node), NULL, node,
+ NULL);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
This parsing function can be moved in
drivers/power/regulator/scmi_regulator.c
By adding the intermediate NOP uclass, binded with "protocol@17" node
for example
U_BOOT_DRIVER(scmi_regulator) = {
.name = "scmi_regulator",
.id = UCLASS_REGULATOR,
.ops = &scmi_voltd_ops,
.probe = scmi_regulator_probe,
.ofdata_to_platdata = scmi_regulator_ofdata_to_platdata,
.platdata_auto_alloc_size = sizeof(struct scmi_regulator_platdata),
};
static int scmi
Dead code CONFIG_ARMADA_39X?
Hello! I see in more U-Boot files check for ifdef CONFIG_ARMADA_39X but I do not see that CONFIG_ARMADA_39X could be defined in some header or board code. So does it mean that all code under ifdef CONFIG_ARMADA_39X is dead? Has U-Boot support for Marvell A39X SoC? If it is really dead code, should not be ifdef CONFIG_ARMADA_39X completely removed?
Re: [PATCH] net: use the same alias stem for ethernet as linux
Hi Michael,
Thank you for your patch, good complement.
在 2021/2/25 下午11:51, Michael Walle 写道:
Linux uses the prefix "ethernet" whereas u-boot uses "eth". This is from
the linux tree:
$ grep "eth[0-9].*=.*&" arch/**/*dts{,i}|wc -l
0
$ grep "ethernet[0-9].*=.*&" arch/**/*dts{,i}|wc -l
633
In u-boot device trees both prefixes are used. Until recently the only
user of the ethernet alias was the sandbox test device tree. This
changed with commit fc054d563bfb ("net: Introduce DSA class for Ethernet
switches"). There, the MAC addresses are inherited based on the devices
sequence IDs which is in turn given by the device tree.
Before there are more users in u-boot and both worlds will differ even
more, rename the alias prefix to "ethernet" to match the linux ones.
Also adapt the test cases and rename any old aliases in the u-boot
device trees.
Cc: David Wu
Signed-off-by: Michael Walle
---
Vladimir, I didn't do another patch to rename any ethernet aliases to
"eth". Though kontron boards contain "ethernetN" aliases, all in tree
variants don't make use of it. So there is nothing to be fixed.
arch/arm/dts/fsl-ls1028a-rdb.dts | 12 ++--
arch/sandbox/dts/test.dts| 10 +-
net/eth-uclass.c | 4 ++--
test/dm/ofnode.c | 2 +-
test/dm/test-fdt.c | 2 +-
5 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1028a-rdb.dts b/arch/arm/dts/fsl-ls1028a-rdb.dts
index 3432fca352..82a8c0a0cd 100644
--- a/arch/arm/dts/fsl-ls1028a-rdb.dts
+++ b/arch/arm/dts/fsl-ls1028a-rdb.dts
@@ -15,12 +15,12 @@
compatible = "fsl,ls1028a-rdb", "fsl,ls1028a";
aliases {
spi0 = &fspi;
- eth0 = &enetc0;
- eth1 = &enetc2;
- eth2 = &mscc_felix_port0;
- eth3 = &mscc_felix_port1;
- eth4 = &mscc_felix_port2;
- eth5 = &mscc_felix_port3;
+ ethernet0 = &enetc0;
+ ethernet1 = &enetc2;
+ ethernet2 = &mscc_felix_port0;
+ ethernet3 = &mscc_felix_port1;
+ ethernet4 = &mscc_felix_port2;
+ ethernet5 = &mscc_felix_port3;
};
};
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 3ef3ba0b17..7a5d4aa71d 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -14,11 +14,11 @@
aliases {
console = &uart0;
- eth0 = "/eth@10002000";
- eth2 = &swp_0;
- eth3 = ð_3;
- eth4 = &dsa_eth0;
- eth5 = ð_5;
+ ethernet0 = "/eth@10002000";
+ ethernet2 = &swp_0;
+ ethernet3 = ð_3;
+ ethernet4 = &dsa_eth0;
+ ethernet5 = ð_5;
gpio1 = &gpio_a;
gpio2 = &gpio_b;
gpio3 = &gpio_c;
diff --git a/net/eth-uclass.c b/net/eth-uclass.c
index 0b4260dc5b..5146bd 100644
--- a/net/eth-uclass.c
+++ b/net/eth-uclass.c
@@ -605,8 +605,8 @@ static int eth_pre_remove(struct udevice *dev)
return 0;
}
-UCLASS_DRIVER(eth) = {
- .name = "eth",
+UCLASS_DRIVER(ethernet) = {
+ .name = "ethernet",
.id = UCLASS_ETH,
.post_bind = eth_post_bind,
.pre_unbind = eth_pre_unbind,
diff --git a/test/dm/ofnode.c b/test/dm/ofnode.c
index c539134296..3b708b63eb 100644
--- a/test/dm/ofnode.c
+++ b/test/dm/ofnode.c
@@ -213,7 +213,7 @@ static int dm_test_ofnode_read_aliases(struct
unit_test_state *uts)
ofnode node;
int size;
- node = ofnode_get_aliases_node("eth3");
+ node = ofnode_get_aliases_node("ethernet3");
ut_assert(ofnode_valid(node));
ut_asserteq_str("sbe5", ofnode_get_name(node));
diff --git a/test/dm/test-fdt.c b/test/dm/test-fdt.c
index 6e83aeecd9..98972665f2 100644
--- a/test/dm/test-fdt.c
+++ b/test/dm/test-fdt.c
@@ -183,7 +183,7 @@ static int dm_test_alias_highest_id(struct unit_test_state
*uts)
{
int ret;
- ret = dev_read_alias_highest_id("eth");
+ ret = dev_read_alias_highest_id("ethernet");
ut_asserteq(5, ret);
ret = dev_read_alias_highest_id("gpio");
[PATCH] arm: mvebu: Espressobin: Enable additional options
Enable support for NVMe disks which can be connected to mPCIe slot via M.2 reduction. Enable btrfs and squashfs filesystems which are used by more Linux distributions. And enable fsuuid and setexpr commands which can be useful in scripting. Signed-off-by: Pali Rohár --- configs/mvebu_espressobin-88f3720_defconfig | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/configs/mvebu_espressobin-88f3720_defconfig b/configs/mvebu_espressobin-88f3720_defconfig index 4956199ccdac..c791f98dfea5 100644 --- a/configs/mvebu_espressobin-88f3720_defconfig +++ b/configs/mvebu_espressobin-88f3720_defconfig @@ -32,12 +32,14 @@ CONFIG_CMD_MMC=y CONFIG_CMD_PCI=y CONFIG_CMD_SPI=y CONFIG_CMD_USB=y -# CONFIG_CMD_SETEXPR is not set CONFIG_CMD_TFTPPUT=y CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y CONFIG_CMD_MVEBU_BUBT=y +CONFIG_CMD_BTRFS=y CONFIG_CMD_EXT4_WRITE=y +CONFIG_CMD_SQUASHFS=y +CONFIG_CMD_FS_UUID=y CONFIG_MAC_PARTITION=y CONFIG_ENV_OVERWRITE=y CONFIG_ENV_IS_IN_SPI_FLASH=y @@ -65,6 +67,7 @@ CONFIG_PHY_MARVELL=y CONFIG_PHY_GIGE=y CONFIG_E1000=y CONFIG_MVNETA=y +CONFIG_NVME=y CONFIG_PCI=y CONFIG_DM_PCI=y CONFIG_PCI_AARDVARK=y -- 2.20.1
Re: [PATCH 2/2] mmc: fsl_esdhc_imx: remove redundant cmd11 related code.
On Wed, Mar 3, 2021 at 3:18 AM wrote:
>
> From: Haibo Chen
>
> Common code already handle the voltage switch sequence based on spec,
> so remove the redundant voltage switch code.
>
Nice! Thank you.
This lets my eMMC run at HS400ES and the microSD card run as SDR104.
For the series,
Tested-by: Adam Ford #imx8mn_beacon
adam
> Signed-off-by: Haibo Chen
> ---
> drivers/mmc/fsl_esdhc_imx.c | 10 +-
> 1 file changed, 1 insertion(+), 9 deletions(-)
>
> diff --git a/drivers/mmc/fsl_esdhc_imx.c b/drivers/mmc/fsl_esdhc_imx.c
> index af36558b3c..a199cf3df6 100644
> --- a/drivers/mmc/fsl_esdhc_imx.c
> +++ b/drivers/mmc/fsl_esdhc_imx.c
> @@ -515,15 +515,6 @@ static int esdhc_send_cmd_common(struct fsl_esdhc_priv
> *priv, struct mmc *mmc,
> goto out;
> }
>
> - /* Switch voltage to 1.8V if CMD11 succeeded */
> - if (cmd->cmdidx == SD_CMD_SWITCH_UHS18V) {
> - esdhc_setbits32(®s->vendorspec, ESDHC_VENDORSPEC_VSELECT);
> -
> - printf("Run CMD11 1.8V switch\n");
> - /* Sleep for 5 ms - max time for card to switch to 1.8V */
> - udelay(5000);
> - }
> -
> /* Workaround for ESDHC errata ENGcm03648 */
> if (!data && (cmd->resp_type & MMC_RSP_BUSY)) {
> int timeout = 5;
> @@ -839,6 +830,7 @@ static int esdhc_set_voltage(struct mmc *mmc)
> }
> #endif
> esdhc_setbits32(®s->vendorspec, ESDHC_VENDORSPEC_VSELECT);
> + mdelay(5);
> if (esdhc_read32(®s->vendorspec) &
> ESDHC_VENDORSPEC_VSELECT)
> return 0;
>
> --
> 2.17.1
>
RE: [PATCH 1/2] mmc: fsl_esdhc_imx: use VENDORSPEC_FRC_SDCLK_ON to control card clock output
Hello Haibo,
> -Original Message-
> From: haibo.c...@nxp.com
> Sent: Wednesday, March 3, 2021 10:06 AM
> To: peng@nxp.com; u-boot@lists.denx.de; sba...@denx.de
> Cc: haibo.c...@nxp.com; uboot-...@nxp.com; thar...@gateworks.com;
> ZHIZHIKIN Andrey ;
> feste...@gmail.com; ye...@nxp.com
> Subject: [PATCH 1/2] mmc: fsl_esdhc_imx: use VENDORSPEC_FRC_SDCLK_ON to
> control card clock output
>
> From: Haibo Chen
>
> For FSL_USDHC, it do not implement VENDORSPEC_CKEN/PEREN/HCKEN/IPGEN,
> these are reserved bits. Instead, use VENDORSPEC_FRC_SDCLK_ON to gate
> on/off the card clock output.
>
> After commit b5874b552ffa ("mmc: fsl_esdhc_imx: add wait_dat0() support"),
> we meet SD3.0 card can't work at UHS mode, mmc_switch_voltage() fail because
> the second mmc_wait_dat0 return -ETIMEDOUT. According to SD spec, during
> voltage switch, need to gate off/on the card clock. If not set the
> FRC_SDCLK_ON,
> after CMD11, hardware will gate off the card clock automatically, so card do
> not
> detect the clock off/on behavior, so will draw the data0 line low until next
> command.
I believe this patch is a RESEND of the previous one, right? I do recall I was
trying to test the same patch, but was missing the second one from this series.
Maybe it make sense to deprecate the old submission then, so it's not dangling
in Patchwork.
>
> Fixes: b5874b552ffa ("mmc: fsl_esdhc_imx: add wait_dat0() support")
> Tested-by: Tim Harvey
> Signed-off-by: Haibo Chen
> ---
> drivers/mmc/fsl_esdhc_imx.c | 29 +
> include/fsl_esdhc_imx.h | 2 ++
> 2 files changed, 23 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/mmc/fsl_esdhc_imx.c b/drivers/mmc/fsl_esdhc_imx.c index
> e0e132698e..af36558b3c 100644
> --- a/drivers/mmc/fsl_esdhc_imx.c
> +++ b/drivers/mmc/fsl_esdhc_imx.c
> @@ -654,7 +654,10 @@ static void set_sysctl(struct fsl_esdhc_priv *priv,
> struct
> mmc *mmc, uint clock)
> clk = (pre_div << 8) | (div << 4);
>
> #ifdef CONFIG_FSL_USDHC
> - esdhc_clrbits32(®s->vendorspec, VENDORSPEC_CKEN);
> + esdhc_clrbits32(®s->vendorspec, VENDORSPEC_FRC_SDCLK_ON);
> + ret = readx_poll_timeout(esdhc_read32, ®s->prsstat, tmp, tmp &
> PRSSTAT_SDOFF, 100);
> + if (ret)
> + pr_warn("fsl_esdhc_imx: Internal clock never gate
> + off.\n");
> #else
> esdhc_clrbits32(®s->sysctl, SYSCTL_CKEN); #endif @@ -666,7 +669,7
> @@
> static void set_sysctl(struct fsl_esdhc_priv *priv, struct mmc *mmc, uint
> clock)
> pr_warn("fsl_esdhc_imx: Internal clock never stabilised.\n");
>
> #ifdef CONFIG_FSL_USDHC
> - esdhc_setbits32(®s->vendorspec, VENDORSPEC_PEREN |
> VENDORSPEC_CKEN);
> + esdhc_setbits32(®s->vendorspec, VENDORSPEC_FRC_SDCLK_ON);
> #else
> esdhc_setbits32(®s->sysctl, SYSCTL_PEREN | SYSCTL_CKEN); #endif
> @@ -
> 721,8 +724,14 @@ static void esdhc_set_strobe_dll(struct mmc *mmc)
> struct fsl_esdhc_priv *priv = dev_get_priv(mmc->dev);
> struct fsl_esdhc *regs = priv->esdhc_regs;
> u32 val;
> + u32 tmp;
> + int ret;
>
> if (priv->clock > ESDHC_STROBE_DLL_CLK_FREQ) {
> + esdhc_clrbits32(®s->vendorspec, VENDORSPEC_FRC_SDCLK_ON);
> + ret = readx_poll_timeout(esdhc_read32, ®s->prsstat, tmp,
> tmp &
> PRSSTAT_SDOFF, 100);
> + if (ret)
> + pr_warn("fsl_esdhc_imx: Internal clock never
> + gate off.\n");
> esdhc_write32(®s->strobe_dllctrl,
> ESDHC_STROBE_DLL_CTRL_RESET);
>
> /*
> @@ -740,6 +749,7 @@ static void esdhc_set_strobe_dll(struct mmc *mmc)
> pr_warn("HS400 strobe DLL status REF not lock!\n");
> if (!(val & ESDHC_STROBE_DLL_STS_SLV_LOCK))
> pr_warn("HS400 strobe DLL status SLV not lock!\n");
> + esdhc_setbits32(®s->vendorspec,
> + VENDORSPEC_FRC_SDCLK_ON);
> }
> }
>
> @@ -963,14 +973,18 @@ static int esdhc_set_ios_common(struct fsl_esdhc_priv
> *priv, struct mmc *mmc) #ifdef MMC_SUPPORTS_TUNING
> if (mmc->clk_disable) {
> #ifdef CONFIG_FSL_USDHC
> - esdhc_clrbits32(®s->vendorspec, VENDORSPEC_CKEN);
> + u32 tmp;
> +
> + esdhc_clrbits32(®s->vendorspec, VENDORSPEC_FRC_SDCLK_ON);
> + ret = readx_poll_timeout(esdhc_read32, ®s->prsstat, tmp,
> tmp &
> PRSSTAT_SDOFF, 100);
> + if (ret)
> + pr_warn("fsl_esdhc_imx: Internal clock never
> + gate off.\n");
> #else
> esdhc_clrbits32(®s->sysctl, SYSCTL_CKEN); #endif
> } else {
> #ifdef CONFIG_FSL_USDHC
> - esdhc_setbits32(®s->vendorspec, VENDORSPEC_PEREN |
> - VENDORSPEC_CKEN);
> + esdhc_setbits32(®s->vendorspec,
> + VENDORSPEC_FRC_SDCLK_ON);
> #else
> esdhc_setbits32(®s->sysctl, SYSCTL_PEREN | SYSCTL_CKEN);
> #endif
> @@ -1046,7 +1
RE: [PATCH 2/2] mmc: fsl_esdhc_imx: remove redundant cmd11 related code.
Hello Haibo,
> -Original Message-
> From: haibo.c...@nxp.com
> Sent: Wednesday, March 3, 2021 10:06 AM
> To: peng@nxp.com; u-boot@lists.denx.de; sba...@denx.de
> Cc: haibo.c...@nxp.com; uboot-...@nxp.com; thar...@gateworks.com;
> ZHIZHIKIN Andrey ;
> feste...@gmail.com; ye...@nxp.com
> Subject: [PATCH 2/2] mmc: fsl_esdhc_imx: remove redundant cmd11 related
> code.
>
> From: Haibo Chen
>
> Common code already handle the voltage switch sequence based on spec, so
> remove the redundant voltage switch code.
>
> Signed-off-by: Haibo Chen
> ---
> drivers/mmc/fsl_esdhc_imx.c | 10 +-
> 1 file changed, 1 insertion(+), 9 deletions(-)
>
> diff --git a/drivers/mmc/fsl_esdhc_imx.c b/drivers/mmc/fsl_esdhc_imx.c index
> af36558b3c..a199cf3df6 100644
> --- a/drivers/mmc/fsl_esdhc_imx.c
> +++ b/drivers/mmc/fsl_esdhc_imx.c
> @@ -515,15 +515,6 @@ static int esdhc_send_cmd_common(struct
> fsl_esdhc_priv *priv, struct mmc *mmc,
> goto out;
> }
>
> - /* Switch voltage to 1.8V if CMD11 succeeded */
> - if (cmd->cmdidx == SD_CMD_SWITCH_UHS18V) {
> - esdhc_setbits32(®s->vendorspec, ESDHC_VENDORSPEC_VSELECT);
> -
> - printf("Run CMD11 1.8V switch\n");
> - /* Sleep for 5 ms - max time for card to switch to 1.8V */
> - udelay(5000);
> - }
> -
> /* Workaround for ESDHC errata ENGcm03648 */
> if (!data && (cmd->resp_type & MMC_RSP_BUSY)) {
> int timeout = 5;
> @@ -839,6 +830,7 @@ static int esdhc_set_voltage(struct mmc *mmc)
> }
> #endif
> esdhc_setbits32(®s->vendorspec, ESDHC_VENDORSPEC_VSELECT);
> + mdelay(5);
> if (esdhc_read32(®s->vendorspec) &
> ESDHC_VENDORSPEC_VSELECT)
> return 0;
>
> --
> 2.17.1
Just tested the whole series on i.MX8M Mini EVK, boot log with MMC info:
---
U-Boot SPL 2021.04-rc3-9-g1333570cee (Mar 03 2021 - 11:34:24 +0100)
Normal Boot
WDT: Started with servicing (60s timeout)
Trying to boot from MMC1
NOTICE: BL31: v2.2(release):rel_imx_5.4.70_2.3.0-0-gf1d7187f2
NOTICE: BL31: Built : 22:29:05, Jan 17 2021
U-Boot 2021.04-rc3-9-g1333570cee (Mar 03 2021 - 11:34:24 +0100)
CPU: Freescale i.MX8MMQ rev1.0 at 1200 MHz
Reset cause: POR
Model: FSL i.MX8MM EVK board
DRAM: 2 GiB
WDT: Started with servicing (60s timeout)
MMC: FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC... *** Warning - bad CRC, using default environment
In:serial
Out: serial
Err: serial
Net: eth0: ethernet@30be
Hit any key to stop autoboot: 0
u-boot=> mmc dev 1
switch to partitions #0, OK
mmc1 is current device
u-boot=> mmc info
Device: FSL_SDHC
Manufacturer ID: 41
OEM: 3432
Name: SD32G
Bus Speed: 2
Mode: UHS SDR104 (208MHz)
Rd Block Len: 512
SD version 3.0
High Capacity: Yes
Capacity: 29.3 GiB
Bus Width: 4-bit
Erase Group Size: 512 Bytes
u-boot=> mmc dev 2
switch to partitions #0, OK
mmc2(part 0) is current device
u-boot=> mmc info
Device: FSL_SDHC
Manufacturer ID: 45
OEM: 100
Name: DG401
Bus Speed: 2
Mode: HS400ES (200MHz)
Rd Block Len: 512
MMC version 5.1
High Capacity: Yes
Capacity: 14.7 GiB
Bus Width: 8-bit DDR
Erase Group Size: 512 KiB
HC WP Group Size: 8 MiB
User Capacity: 14.7 GiB WRREL
Boot Capacity: 4 MiB ENH
RPMB Capacity: 4 MiB ENH
Boot area 0 is not write protected
Boot area 1 is not write protected
u-boot=>
For the series:
Tested-by: Andrey Zhizhikin # imx8mm_evk
-- andrey
[PULL] u-boot-usb/master
This should be the last one of the stuck USB PRs. The following changes since commit 78af81c345430a9088235f48d302922955d2499f: Merge tag 'rpi-next-2021.04.2' of https://source.denx.de/u-boot/custodians/u-boot-raspberrypi (2021-03-02 16:46:16 -0500) are available in the Git repository at: git://source.denx.de/u-boot-usb.git master for you to fetch changes up to 795d605cab787e6d9151221312b09391aacfb8e5: usb: USB keyboard requires DM_KEYBOARD (2021-03-03 04:12:46 +0100) Heinrich Schuchardt (1): usb: USB keyboard requires DM_KEYBOARD Pali Rohár (16): serial: usbtty: Fix puts function serial: usbtty: Send urb data in correct order usb: musb: Fix compilation of gadget code usb: musb: Always clear the data toggle bit when configuring ep usb: musb: Fix configuring FIFO for endpoints usb: musb: Read value of PERI_RXCSR to 16bit variable usb: musb: Fix transmission of bigger buffers usb: musb: Fix receiving of bigger buffers usb: musb: Fix handling interrupts for EP0 and SET ADDRESS commmand usb: musb: Ensure that we set musb dynamic FIFO buffer for every endpoint usb: gadget: Use dbg_ep0() macro instead of serial_printf() arm: omap3: Compile lowlevel_init() function only when it is used arm: omap3: Compile s_init() function only when it is used Nokia RX-51: Remove function set_muxconf_regs() Nokia RX-51: Move content of rx51.h to rx51.c Nokia RX-51: Enable usbtty serial console by default Makefile | 1 + arch/arm/mach-omap2/omap3/board.c | 3 + arch/arm/mach-omap2/omap3/lowlevel_init.S | 6 +- board/nokia/rx51/rx51.c | 28 --- board/nokia/rx51/rx51.h | 377 --- configs/nokia_rx51_defconfig | 8 +- doc/README.nokia_rx51 | 15 +--- drivers/serial/usbtty.c | 16 ++-- drivers/usb/Kconfig | 1 + drivers/usb/gadget/ep0.c | 16 ++-- drivers/usb/musb/musb_core.c | 12 +-- drivers/usb/musb/musb_udc.c | 61 +++ include/configs/nokia_rx51.h | 21 ++ 13 files changed, 84 insertions(+), 481 deletions(-) delete mode 100644 board/nokia/rx51/rx51.h
Re: [PATCH] usb: mtu3: flush cache for next GPD
On 3/3/21 9:07 AM, Chunfeng Yun wrote: When flush cache of the current GPD and resume QMU, the controller will try to access the next GPD after processing the current one, if not flush the next GPD, the controller may get wrong GPD status. Applied, thanks
RE: [PATCH 2/2] mmc: fsl_esdhc_imx: remove redundant cmd11 related code.
> -Original Message-
> From: haibo.c...@nxp.com
> Sent: Wednesday, March 3, 2021 10:06 AM
> To: peng@nxp.com; u-boot@lists.denx.de; sba...@denx.de
> Cc: haibo.c...@nxp.com; uboot-...@nxp.com; thar...@gateworks.com;
> ZHIZHIKIN Andrey ;
> feste...@gmail.com; ye...@nxp.com
> Subject: [PATCH 2/2] mmc: fsl_esdhc_imx: remove redundant cmd11 related
> code.
>
> From: Haibo Chen
>
> Common code already handle the voltage switch sequence based on spec, so
> remove the redundant voltage switch code.
>
> Signed-off-by: Haibo Chen
> ---
> drivers/mmc/fsl_esdhc_imx.c | 10 +-
> 1 file changed, 1 insertion(+), 9 deletions(-)
>
> diff --git a/drivers/mmc/fsl_esdhc_imx.c b/drivers/mmc/fsl_esdhc_imx.c index
> af36558b3c..a199cf3df6 100644
> --- a/drivers/mmc/fsl_esdhc_imx.c
> +++ b/drivers/mmc/fsl_esdhc_imx.c
> @@ -515,15 +515,6 @@ static int esdhc_send_cmd_common(struct
> fsl_esdhc_priv *priv, struct mmc *mmc,
> goto out;
> }
>
> - /* Switch voltage to 1.8V if CMD11 succeeded */
> - if (cmd->cmdidx == SD_CMD_SWITCH_UHS18V) {
> - esdhc_setbits32(®s->vendorspec, ESDHC_VENDORSPEC_VSELECT);
> -
> - printf("Run CMD11 1.8V switch\n");
> - /* Sleep for 5 ms - max time for card to switch to 1.8V */
> - udelay(5000);
> - }
> -
> /* Workaround for ESDHC errata ENGcm03648 */
> if (!data && (cmd->resp_type & MMC_RSP_BUSY)) {
> int timeout = 5;
> @@ -839,6 +830,7 @@ static int esdhc_set_voltage(struct mmc *mmc)
> }
> #endif
> esdhc_setbits32(®s->vendorspec, ESDHC_VENDORSPEC_VSELECT);
> + mdelay(5);
Why is this delay introduced here? It is not clear from the commit message
whether and why it is required here.
If this is kept from the removed block - maybe it is better to move the
corresponding comment here as well.
> if (esdhc_read32(®s->vendorspec) &
> ESDHC_VENDORSPEC_VSELECT)
> return 0;
>
> --
> 2.17.1
-- andrey
Re: [PATCH v5 6/6] riscv: Enable watchdog for the k210
On Tue, Dec 22, 2020 at 06:59:03PM -0500, Sean Anderson wrote: > This enables the necessary config options. > > Signed-off-by: Sean Anderson > Reviewed-by: Simon Glass > --- > > (no changes since v1) > > board/sipeed/maix/Kconfig | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/board/sipeed/maix/Kconfig b/board/sipeed/maix/Kconfig > index 4c42dd2087..95fe6d9706 100644 > --- a/board/sipeed/maix/Kconfig > +++ b/board/sipeed/maix/Kconfig > @@ -53,4 +53,6 @@ config BOARD_SPECIFIC_OPTIONS > imply CMD_GPIO > imply LED > imply LED_GPIO > + imply WDT > + imply DESIGNWARE_WATCHDOG > endif Hi Sean, This patch has conflicted with current master. Could be please rebase again? Thanks in advance! Leo
Re: [PATCH] riscv: Remove unused define in maix header
On Wed, Aug 05, 2020 at 12:42:19PM -0400, Sean Anderson wrote: > This define was left over from a previous revision, and was never used. > > Signed-off-by: Sean Anderson > Reviewed-by: Heinrich Schuchardt > Reviewed-by: Bin Meng > --- > > include/configs/sipeed-maix.h | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/include/configs/sipeed-maix.h b/include/configs/sipeed-maix.h > index a46473fc78..1cee8259d7 100644 > --- a/include/configs/sipeed-maix.h > +++ b/include/configs/sipeed-maix.h > @@ -18,7 +18,4 @@ > /* Don't relocate into AI ram since it isn't set up yet */ > #define CONFIG_SYS_SDRAM_SIZE (SZ_4M + SZ_2M) > > -/* For early init */ > -#define K210_SYSCTL_BASE 0x5044 > - > #endif /* CONFIGS_SIPEED_MAIX_H */ Hi Sean, This patch also conflicts with current master. Could you please rebase again? Thanks! Leo
Re: [PATCH] nvme: Elaborate on cache maintenance operation in get/set_features
On Wed, 3 Mar 2021 03:42:40 +0100 Marek Vasut wrote: Hi, > On 3/2/21 4:43 PM, Andre Przywara wrote: > > [...] > > > @@ -488,12 +489,20 @@ int nvme_get_features(struct nvme_dev *dev, unsigned > > fid, unsigned nsid, > > c.features.prp1 = cpu_to_le64(dma_addr); > > c.features.fid = cpu_to_le32(fid); > > > > + ret = nvme_submit_admin_cmd(dev, &c, result); > > + > > /* > > -* TODO: add cache invalidate operation when the size of > > -* the DMA buffer is known > > +* TODO: Add some cache invalidation when a DMA buffer is involved > > +* in the request, here and before the command gets submitted. The > > +* buffer size varies by feature, also some features use a different > > +* field in the command packet to hold the buffer address. > > +* Section 5.21.1 (Set Features command) in the NVMe specification > > +* details the buffer requirements for each feature. > > +* > > +* At the moment there is no user of this function. > > If there is no user, remove the function. Well, this function was apparently introduced for a reason, and it's exported. So I am just trying to clarify on the comment here. I'd leave it to people more familiar with NVMe and its implementation in U-Boot to remove something. > > */ > > > > - return nvme_submit_admin_cmd(dev, &c, result); > > + return ret; > > } > > > > int nvme_set_features(struct nvme_dev *dev, unsigned fid, unsigned > > dword11, > > @@ -508,8 +517,14 @@ int nvme_set_features(struct nvme_dev *dev, unsigned > > fid, unsigned dword11, > > c.features.dword11 = cpu_to_le32(dword11); > > > > /* > > -* TODO: add cache flush operation when the size of > > -* the DMA buffer is known > > +* TODO: Add a cache clean (aka flush) operation when a DMA buffer is > The operation is called flush in U-Boot, cache clean is ARM-specific > terminology, avoid it in generic drivers. > > > +* involved in the request. The buffer size varies by feature, also > > +* some features use a different field in the command packet to hold > > +* the buffer address. Section 5.21.1 (Set Features command) in the > > +* NVMe specification details the buffer requirements for each > > +* feature. > > It would be far more useful to explain the buffer requirements here than > to point to an unknown version of some spec, which could very well be > re-enumerated in the next version. I originally wanted to, but didn't for two reasons: - It's not trivial, since the buffer usage seems to differ between the features. This would require to enumerate all the features involved, and then to include all the special cases. I would probably mess this up, so I didn't want to introduce untested and hard-to-verify information. - There is little point in adding specific information when we will never need it. The spec is the authority, anyone can look that up. Yes, the enumeration might change, that's why I added the section name, hoping that people adding a feature can piece things together. The numbering was valid for v1.3 and is still in the latest v1.4b, so I can just add that version number to make this less ambiguous. Cheers, Andre > > > +* At the moment the only user of this function is not using > > +* any DMA buffer at all. > > */ > > > > return nvme_submit_admin_cmd(dev, &c, result); > > [...]
RE: [PATCH 2/2] mmc: fsl_esdhc_imx: remove redundant cmd11 related code.
> -Original Message-
> From: ZHIZHIKIN Andrey [mailto:andrey.zhizhi...@leica-geosystems.com]
> Sent: 2021年3月3日 19:00
> To: Bough Chen ; Peng Fan ;
> u-boot@lists.denx.de; sba...@denx.de
> Cc: dl-uboot-imx ; thar...@gateworks.com;
> feste...@gmail.com; Ye Li
> Subject: RE: [PATCH 2/2] mmc: fsl_esdhc_imx: remove redundant cmd11
> related code.
>
>
>
> > -Original Message-
> > From: haibo.c...@nxp.com
> > Sent: Wednesday, March 3, 2021 10:06 AM
> > To: peng@nxp.com; u-boot@lists.denx.de; sba...@denx.de
> > Cc: haibo.c...@nxp.com; uboot-...@nxp.com; thar...@gateworks.com;
> > ZHIZHIKIN Andrey ;
> > feste...@gmail.com; ye...@nxp.com
> > Subject: [PATCH 2/2] mmc: fsl_esdhc_imx: remove redundant cmd11
> > related code.
> >
> > From: Haibo Chen
> >
> > Common code already handle the voltage switch sequence based on spec,
> > so remove the redundant voltage switch code.
> >
> > Signed-off-by: Haibo Chen
> > ---
> > drivers/mmc/fsl_esdhc_imx.c | 10 +-
> > 1 file changed, 1 insertion(+), 9 deletions(-)
> >
> > diff --git a/drivers/mmc/fsl_esdhc_imx.c b/drivers/mmc/fsl_esdhc_imx.c
> > index
> > af36558b3c..a199cf3df6 100644
> > --- a/drivers/mmc/fsl_esdhc_imx.c
> > +++ b/drivers/mmc/fsl_esdhc_imx.c
> > @@ -515,15 +515,6 @@ static int esdhc_send_cmd_common(struct
> > fsl_esdhc_priv *priv, struct mmc *mmc,
> > goto out;
> > }
> >
> > - /* Switch voltage to 1.8V if CMD11 succeeded */
> > - if (cmd->cmdidx == SD_CMD_SWITCH_UHS18V) {
> > - esdhc_setbits32(®s->vendorspec,
> ESDHC_VENDORSPEC_VSELECT);
> > -
> > - printf("Run CMD11 1.8V switch\n");
> > - /* Sleep for 5 ms - max time for card to switch to 1.8V */
> > - udelay(5000);
> > - }
> > -
> > /* Workaround for ESDHC errata ENGcm03648 */
> > if (!data && (cmd->resp_type & MMC_RSP_BUSY)) {
> > int timeout = 5;
> > @@ -839,6 +830,7 @@ static int esdhc_set_voltage(struct mmc *mmc)
> > }
> > #endif
> > esdhc_setbits32(®s->vendorspec,
> > ESDHC_VENDORSPEC_VSELECT);
> > + mdelay(5);
>
> Why is this delay introduced here? It is not clear from the commit message
> whether and why it is required here.
>
> If this is kept from the removed block - maybe it is better to move the
> corresponding comment here as well.
Hi Andrev,
Thanks for your careful review!
Without this 5ms delay, with patch1 and remove the upper redundant cmd11
related code,
mmc_switch_voltage() will fail, due to the second mmc_wait_dat0() return
timeout. Seems for usdhc,
gate off clock for 10ms is not enough. If total delay 15ms, then the second
mmc_wait_dat0() can return normal.
So I add 5ms delay here. Yes, I should add a comment for this 5ms in the code.
You can also do the test on your side.
Best Regards
Haibo
>
> > if (esdhc_read32(®s->vendorspec) &
> ESDHC_VENDORSPEC_VSELECT)
> > return 0;
> >
> > --
> > 2.17.1
>
> -- andrey
smime.p7s
Description: S/MIME cryptographic signature
[PATCH 0/5] Flexspi cleanups for ls1028a and lx2160a
This patch series aim is to make fspi cleanups for ls1028a and lx2160a. This includes defconfig and header cleanups. Kuldeep Singh (5): configs: lx2160a: Unset CONFIG_SPI_FLASH_SPANSION configs: lx2160a: Remove unused Flexspi config options configs: ls1028a: Unset CONFIG_SPI_FLASH_SPANSION configs: ls1028aqds: Move CONFIG_SPI_FLASH_* definitions to defconfig configs: ls1028a: Correct CONFIG_ENV_SECT_SIZE configs/ls1028aqds_tfa_SECURE_BOOT_defconfig | 3 ++- configs/ls1028aqds_tfa_defconfig | 5 +++-- configs/ls1028aqds_tfa_lpuart_defconfig | 5 +++-- configs/ls1028ardb_tfa_SECURE_BOOT_defconfig | 1 - configs/ls1028ardb_tfa_defconfig | 3 +-- configs/lx2160aqds_tfa_SECURE_BOOT_defconfig | 1 - configs/lx2160aqds_tfa_defconfig | 1 - configs/lx2160ardb_tfa_SECURE_BOOT_defconfig | 1 - configs/lx2160ardb_tfa_defconfig | 1 - configs/lx2160ardb_tfa_stmm_defconfig| 1 - include/configs/ls1028aqds.h | 6 -- include/configs/lx2160a_common.h | 6 -- 12 files changed, 9 insertions(+), 25 deletions(-) -- 2.25.1
[PATCH 1/5] configs: lx2160a: Unset CONFIG_SPI_FLASH_SPANSION
There is no Spansion flash on LX2160A-RDB/QDS boards. Unset CONFIG_SPI_FLASH_SPANSION option for both the boards. Signed-off-by: Kuldeep Singh --- configs/lx2160aqds_tfa_SECURE_BOOT_defconfig | 1 - configs/lx2160aqds_tfa_defconfig | 1 - configs/lx2160ardb_tfa_SECURE_BOOT_defconfig | 1 - configs/lx2160ardb_tfa_defconfig | 1 - configs/lx2160ardb_tfa_stmm_defconfig| 1 - 5 files changed, 5 deletions(-) diff --git a/configs/lx2160aqds_tfa_SECURE_BOOT_defconfig b/configs/lx2160aqds_tfa_SECURE_BOOT_defconfig index 7d6b74db18e..5a7ffe9c4a1 100644 --- a/configs/lx2160aqds_tfa_SECURE_BOOT_defconfig +++ b/configs/lx2160aqds_tfa_SECURE_BOOT_defconfig @@ -50,7 +50,6 @@ CONFIG_FSL_ESDHC=y CONFIG_MTD=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH_EON=y -CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_SPI_FLASH_SST=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set diff --git a/configs/lx2160aqds_tfa_defconfig b/configs/lx2160aqds_tfa_defconfig index 4390b0d928b..ed6f78b0993 100644 --- a/configs/lx2160aqds_tfa_defconfig +++ b/configs/lx2160aqds_tfa_defconfig @@ -57,7 +57,6 @@ CONFIG_FSL_ESDHC=y CONFIG_MTD=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH_EON=y -CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_SPI_FLASH_SST=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set diff --git a/configs/lx2160ardb_tfa_SECURE_BOOT_defconfig b/configs/lx2160ardb_tfa_SECURE_BOOT_defconfig index f5da144e544..bb92fcb6c57 100644 --- a/configs/lx2160ardb_tfa_SECURE_BOOT_defconfig +++ b/configs/lx2160ardb_tfa_SECURE_BOOT_defconfig @@ -46,7 +46,6 @@ CONFIG_MMC_HS400_SUPPORT=y CONFIG_FSL_ESDHC=y CONFIG_MTD=y CONFIG_DM_SPI_FLASH=y -CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_PHYLIB=y diff --git a/configs/lx2160ardb_tfa_defconfig b/configs/lx2160ardb_tfa_defconfig index c5a04101619..1d3b59c849c 100644 --- a/configs/lx2160ardb_tfa_defconfig +++ b/configs/lx2160ardb_tfa_defconfig @@ -55,7 +55,6 @@ CONFIG_MMC_HS400_SUPPORT=y CONFIG_FSL_ESDHC=y CONFIG_MTD=y CONFIG_DM_SPI_FLASH=y -CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_PHYLIB=y diff --git a/configs/lx2160ardb_tfa_stmm_defconfig b/configs/lx2160ardb_tfa_stmm_defconfig index ca1d5cbad95..1b06124269d 100644 --- a/configs/lx2160ardb_tfa_stmm_defconfig +++ b/configs/lx2160ardb_tfa_stmm_defconfig @@ -55,7 +55,6 @@ CONFIG_MMC_HS400_SUPPORT=y CONFIG_FSL_ESDHC=y CONFIG_MTD=y CONFIG_DM_SPI_FLASH=y -CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_PHYLIB=y -- 2.25.1
[PATCH 2/5] configs: lx2160a: Remove unused Flexspi config options
It is now safe to remove Flexspi configs NXP_FSPI_FLASH_SIZE and NXP_FSPI_FLASH_NUM options from headers as they are no longer used by driver anymore. Signed-off-by: Kuldeep Singh --- include/configs/lx2160a_common.h | 6 -- 1 file changed, 6 deletions(-) diff --git a/include/configs/lx2160a_common.h b/include/configs/lx2160a_common.h index 466484c1997..9f2b8999cdb 100644 --- a/include/configs/lx2160a_common.h +++ b/include/configs/lx2160a_common.h @@ -154,12 +154,6 @@ #endif #endif -/* FlexSPI */ -#ifdef CONFIG_NXP_FSPI -#define NXP_FSPI_FLASH_SIZESZ_64M -#define NXP_FSPI_FLASH_NUM 1 -#endif - /* GPIO */ #ifdef CONFIG_DM_GPIO #ifndef CONFIG_MPC8XXX_GPIO -- 2.25.1
[PATCH 5/5] configs: ls1028a: Correct CONFIG_ENV_SECT_SIZE
LS1028A-RDB/QDS has Micron "mt35xu02g" nor flash of size 256M with 128K sector size. Correct CONFIG_ENV_SECT_SIZE value to 128K. Signed-off-by: Kuldeep Singh --- configs/ls1028aqds_tfa_defconfig| 2 +- configs/ls1028aqds_tfa_lpuart_defconfig | 2 +- configs/ls1028ardb_tfa_defconfig| 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/configs/ls1028aqds_tfa_defconfig b/configs/ls1028aqds_tfa_defconfig index 1913f4f1358..cc38bd89570 100644 --- a/configs/ls1028aqds_tfa_defconfig +++ b/configs/ls1028aqds_tfa_defconfig @@ -8,7 +8,7 @@ CONFIG_SYS_MEMTEST_START=0x8000 CONFIG_SYS_MEMTEST_END=0x9fff CONFIG_ENV_SIZE=0x2000 CONFIG_ENV_OFFSET=0x50 -CONFIG_ENV_SECT_SIZE=0x4 +CONFIG_ENV_SECT_SIZE=0x2 CONFIG_DM_GPIO=y CONFIG_FSPI_AHB_EN_4BYTE=y CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT=y diff --git a/configs/ls1028aqds_tfa_lpuart_defconfig b/configs/ls1028aqds_tfa_lpuart_defconfig index 60d515c9c66..bc5f8f4f321 100644 --- a/configs/ls1028aqds_tfa_lpuart_defconfig +++ b/configs/ls1028aqds_tfa_lpuart_defconfig @@ -7,7 +7,7 @@ CONFIG_SYS_MEMTEST_START=0x8000 CONFIG_SYS_MEMTEST_END=0x9fff CONFIG_ENV_SIZE=0x2000 CONFIG_ENV_OFFSET=0x50 -CONFIG_ENV_SECT_SIZE=0x4 +CONFIG_ENV_SECT_SIZE=0x2 CONFIG_DM_GPIO=y CONFIG_FSPI_AHB_EN_4BYTE=y CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT=y diff --git a/configs/ls1028ardb_tfa_defconfig b/configs/ls1028ardb_tfa_defconfig index 801552c6025..2ee57de839a 100644 --- a/configs/ls1028ardb_tfa_defconfig +++ b/configs/ls1028ardb_tfa_defconfig @@ -8,7 +8,7 @@ CONFIG_SYS_MEMTEST_START=0x8000 CONFIG_SYS_MEMTEST_END=0x9fff CONFIG_ENV_SIZE=0x2000 CONFIG_ENV_OFFSET=0x50 -CONFIG_ENV_SECT_SIZE=0x4 +CONFIG_ENV_SECT_SIZE=0x2 CONFIG_DM_GPIO=y CONFIG_FSPI_AHB_EN_4BYTE=y CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT=y -- 2.25.1
[PATCH 4/5] configs: ls1028aqds: Move CONFIG_SPI_FLASH_* definitions to defconfig
LS1028A-QDS has CONFIG_SPI_FLASH_SST and CONFIG_SPI_FLASH_EON defines present in header. Move these entries from header to defconfigs. Signed-off-by: Kuldeep Singh --- configs/ls1028aqds_tfa_SECURE_BOOT_defconfig | 2 ++ configs/ls1028aqds_tfa_defconfig | 2 ++ configs/ls1028aqds_tfa_lpuart_defconfig | 2 ++ include/configs/ls1028aqds.h | 6 -- 4 files changed, 6 insertions(+), 6 deletions(-) diff --git a/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig b/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig index 47dfa3e847e..17daef8d74f 100644 --- a/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig +++ b/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig @@ -49,7 +49,9 @@ CONFIG_DM_MMC=y CONFIG_FSL_ESDHC=y CONFIG_MTD=y CONFIG_DM_SPI_FLASH=y +CONFIG_SPI_FLASH_EON=y CONFIG_SPI_FLASH_STMICRO=y +CONFIG_SPI_FLASH_SST=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_PHYLIB=y CONFIG_PHY_AQUANTIA=y diff --git a/configs/ls1028aqds_tfa_defconfig b/configs/ls1028aqds_tfa_defconfig index 21408bd7322..1913f4f1358 100644 --- a/configs/ls1028aqds_tfa_defconfig +++ b/configs/ls1028aqds_tfa_defconfig @@ -55,7 +55,9 @@ CONFIG_DM_MMC=y CONFIG_FSL_ESDHC=y CONFIG_MTD=y CONFIG_DM_SPI_FLASH=y +CONFIG_SPI_FLASH_EON=y CONFIG_SPI_FLASH_STMICRO=y +CONFIG_SPI_FLASH_SST=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_PHYLIB=y CONFIG_PHY_AQUANTIA=y diff --git a/configs/ls1028aqds_tfa_lpuart_defconfig b/configs/ls1028aqds_tfa_lpuart_defconfig index d016202a242..60d515c9c66 100644 --- a/configs/ls1028aqds_tfa_lpuart_defconfig +++ b/configs/ls1028aqds_tfa_lpuart_defconfig @@ -55,7 +55,9 @@ CONFIG_DM_MMC=y CONFIG_FSL_ESDHC=y CONFIG_MTD=y CONFIG_DM_SPI_FLASH=y +CONFIG_SPI_FLASH_EON=y CONFIG_SPI_FLASH_STMICRO=y +CONFIG_SPI_FLASH_SST=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_PHYLIB=y CONFIG_PHY_AQUANTIA=y diff --git a/include/configs/ls1028aqds.h b/include/configs/ls1028aqds.h index 8ab943cc640..9ae37b96ceb 100644 --- a/include/configs/ls1028aqds.h +++ b/include/configs/ls1028aqds.h @@ -81,12 +81,6 @@ #define CONFIG_SYS_SCSI_MAX_LUN1 #define CONFIG_SYS_SCSI_MAX_DEVICE (CONFIG_SYS_SCSI_MAX_SCSI_ID * \ CONFIG_SYS_SCSI_MAX_LUN) -/* DSPI */ -#ifdef CONFIG_FSL_DSPI -#define CONFIG_SPI_FLASH_SST -#define CONFIG_SPI_FLASH_EON -#endif - #ifndef SPL_NO_ENV #undef CONFIG_EXTRA_ENV_SETTINGS #define CONFIG_EXTRA_ENV_SETTINGS \ -- 2.25.1
[PATCH 3/5] configs: ls1028a: Unset CONFIG_SPI_FLASH_SPANSION
There is no Spansion flash on LS1028A-RDB/QDS boards. Unset CONFIG_SPI_FLASH_SPANSION option for both the boards. Signed-off-by: Kuldeep Singh --- configs/ls1028aqds_tfa_SECURE_BOOT_defconfig | 1 - configs/ls1028aqds_tfa_defconfig | 1 - configs/ls1028aqds_tfa_lpuart_defconfig | 1 - configs/ls1028ardb_tfa_SECURE_BOOT_defconfig | 1 - configs/ls1028ardb_tfa_defconfig | 1 - 5 files changed, 5 deletions(-) diff --git a/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig b/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig index a2bc6c6e6b3..47dfa3e847e 100644 --- a/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig +++ b/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig @@ -49,7 +49,6 @@ CONFIG_DM_MMC=y CONFIG_FSL_ESDHC=y CONFIG_MTD=y CONFIG_DM_SPI_FLASH=y -CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_PHYLIB=y diff --git a/configs/ls1028aqds_tfa_defconfig b/configs/ls1028aqds_tfa_defconfig index 66e008b8ce3..21408bd7322 100644 --- a/configs/ls1028aqds_tfa_defconfig +++ b/configs/ls1028aqds_tfa_defconfig @@ -55,7 +55,6 @@ CONFIG_DM_MMC=y CONFIG_FSL_ESDHC=y CONFIG_MTD=y CONFIG_DM_SPI_FLASH=y -CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_PHYLIB=y diff --git a/configs/ls1028aqds_tfa_lpuart_defconfig b/configs/ls1028aqds_tfa_lpuart_defconfig index cc82ed74b0e..d016202a242 100644 --- a/configs/ls1028aqds_tfa_lpuart_defconfig +++ b/configs/ls1028aqds_tfa_lpuart_defconfig @@ -55,7 +55,6 @@ CONFIG_DM_MMC=y CONFIG_FSL_ESDHC=y CONFIG_MTD=y CONFIG_DM_SPI_FLASH=y -CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_PHYLIB=y diff --git a/configs/ls1028ardb_tfa_SECURE_BOOT_defconfig b/configs/ls1028ardb_tfa_SECURE_BOOT_defconfig index dd189188d22..794632a6c93 100644 --- a/configs/ls1028ardb_tfa_SECURE_BOOT_defconfig +++ b/configs/ls1028ardb_tfa_SECURE_BOOT_defconfig @@ -48,7 +48,6 @@ CONFIG_DM_MMC=y CONFIG_FSL_ESDHC=y CONFIG_MTD=y CONFIG_DM_SPI_FLASH=y -CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_PHYLIB=y diff --git a/configs/ls1028ardb_tfa_defconfig b/configs/ls1028ardb_tfa_defconfig index 9f5116b3641..801552c6025 100644 --- a/configs/ls1028ardb_tfa_defconfig +++ b/configs/ls1028ardb_tfa_defconfig @@ -54,7 +54,6 @@ CONFIG_DM_MMC=y CONFIG_FSL_ESDHC=y CONFIG_MTD=y CONFIG_DM_SPI_FLASH=y -CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_PHYLIB=y -- 2.25.1
Re: [PATCH] Nokia RX-51: Enable CONFIG_CMD_BOOTD
On Wednesday 24 February 2021 01:27:29 Pali Rohár wrote: > CONFIG_CMD_BOOTD provides 'boot' command which is required in more scripts. > > Signed-off-by: Pali Rohár > --- > This patch applies cleanly on top of the patch "Nokia RX-51: Enable > usbtty serial console by default" [1] and CI testing passed without > any issues [2] [3]. Please include it into U-Boot 2021.04 release. > > [1] - > https://patchwork.ozlabs.org/project/uboot/patch/20210220105015.26210-1-p...@kernel.org/ > [2] - https://github.com/u-boot/u-boot/pull/53/checks?check_run_id=1932112532 > [3] - > https://dev.azure.com/u-boot/a1096300-2999-4ec4-a21a-4c22075e3771/_build/results?buildId=1816&view=logs&jobId=9a06d2a9-1498-5de0-2a01-be581d48ba67 Lokesh, could you please look at this patch? > --- > configs/nokia_rx51_defconfig | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/configs/nokia_rx51_defconfig b/configs/nokia_rx51_defconfig > index 0df11b98585b..312ca3a1a991 100644 > --- a/configs/nokia_rx51_defconfig > +++ b/configs/nokia_rx51_defconfig > @@ -17,7 +17,6 @@ CONFIG_CONSOLE_MUX=y > CONFIG_HUSH_PARSER=y > CONFIG_SYS_PROMPT="Nokia RX-51 # " > # CONFIG_CMD_BDI is not set > -# CONFIG_CMD_BOOTD is not set > # CONFIG_BOOTM_NETBSD is not set > # CONFIG_BOOTM_PLAN9 is not set > # CONFIG_BOOTM_RTEMS is not set > -- > 2.20.1 >
Re: [PATCH] Nokia RX-51: Enable CONFIG_CMD_BOOTD
On 03/03/21 5:13 pm, Pali Rohár wrote: > On Wednesday 24 February 2021 01:27:29 Pali Rohár wrote: >> CONFIG_CMD_BOOTD provides 'boot' command which is required in more scripts. >> >> Signed-off-by: Pali Rohár >> --- >> This patch applies cleanly on top of the patch "Nokia RX-51: Enable >> usbtty serial console by default" [1] and CI testing passed without >> any issues [2] [3]. Please include it into U-Boot 2021.04 release. >> >> [1] - >> https://patchwork.ozlabs.org/project/uboot/patch/20210220105015.26210-1-p...@kernel.org/ >> [2] - https://github.com/u-boot/u-boot/pull/53/checks?check_run_id=1932112532 >> [3] - >> https://dev.azure.com/u-boot/a1096300-2999-4ec4-a21a-4c22075e3771/_build/results?buildId=1816&view=logs&jobId=9a06d2a9-1498-5de0-2a01-be581d48ba67 > > Lokesh, could you please look at this patch? I do not see the dependency patch [1] in master yet. Am I missing something? Without that Ill not be able to pull in the patch. Thanks and regards, Lokesh > >> --- >> configs/nokia_rx51_defconfig | 1 - >> 1 file changed, 1 deletion(-) >> >> diff --git a/configs/nokia_rx51_defconfig b/configs/nokia_rx51_defconfig >> index 0df11b98585b..312ca3a1a991 100644 >> --- a/configs/nokia_rx51_defconfig >> +++ b/configs/nokia_rx51_defconfig >> @@ -17,7 +17,6 @@ CONFIG_CONSOLE_MUX=y >> CONFIG_HUSH_PARSER=y >> CONFIG_SYS_PROMPT="Nokia RX-51 # " >> # CONFIG_CMD_BDI is not set >> -# CONFIG_CMD_BOOTD is not set >> # CONFIG_BOOTM_NETBSD is not set >> # CONFIG_BOOTM_PLAN9 is not set >> # CONFIG_BOOTM_RTEMS is not set >> -- >> 2.20.1 >>
Re: [PATCH] Nokia RX-51: Enable CONFIG_CMD_BOOTD
On Wednesday 03 March 2021 17:26:22 Lokesh Vutla wrote: > On 03/03/21 5:13 pm, Pali Rohár wrote: > > On Wednesday 24 February 2021 01:27:29 Pali Rohár wrote: > >> CONFIG_CMD_BOOTD provides 'boot' command which is required in more scripts. > >> > >> Signed-off-by: Pali Rohár > >> --- > >> This patch applies cleanly on top of the patch "Nokia RX-51: Enable > >> usbtty serial console by default" [1] and CI testing passed without > >> any issues [2] [3]. Please include it into U-Boot 2021.04 release. > >> > >> [1] - > >> https://patchwork.ozlabs.org/project/uboot/patch/20210220105015.26210-1-p...@kernel.org/ > >> [2] - > >> https://github.com/u-boot/u-boot/pull/53/checks?check_run_id=1932112532 > >> [3] - > >> https://dev.azure.com/u-boot/a1096300-2999-4ec4-a21a-4c22075e3771/_build/results?buildId=1816&view=logs&jobId=9a06d2a9-1498-5de0-2a01-be581d48ba67 > > > > Lokesh, could you please look at this patch? > > I do not see the dependency patch [1] in master yet. Am I missing something? > Without that Ill not be able to pull in the patch. Hm... it is marked as Accepted by Lukasz Majewski. So it is not accepted yet? Lukasz, could you please look what happened with patch [1] which you have reviewed and taken? It is waiting in some queue? We need [1] in master not only as dependency for this patch, but also for fixing usbtty as it is the only way how to easily debug U-Boot on N900... > Thanks and regards, > Lokesh > > > > >> --- > >> configs/nokia_rx51_defconfig | 1 - > >> 1 file changed, 1 deletion(-) > >> > >> diff --git a/configs/nokia_rx51_defconfig b/configs/nokia_rx51_defconfig > >> index 0df11b98585b..312ca3a1a991 100644 > >> --- a/configs/nokia_rx51_defconfig > >> +++ b/configs/nokia_rx51_defconfig > >> @@ -17,7 +17,6 @@ CONFIG_CONSOLE_MUX=y > >> CONFIG_HUSH_PARSER=y > >> CONFIG_SYS_PROMPT="Nokia RX-51 # " > >> # CONFIG_CMD_BDI is not set > >> -# CONFIG_CMD_BOOTD is not set > >> # CONFIG_BOOTM_NETBSD is not set > >> # CONFIG_BOOTM_PLAN9 is not set > >> # CONFIG_BOOTM_RTEMS is not set > >> -- > >> 2.20.1 > >>
Re: [PATCH] Nokia RX-51: Enable CONFIG_CMD_BOOTD
On Wed, 3 Mar 2021 13:02:37 +0100 Pali Rohár wrote: > On Wednesday 03 March 2021 17:26:22 Lokesh Vutla wrote: > > On 03/03/21 5:13 pm, Pali Rohár wrote: > > > On Wednesday 24 February 2021 01:27:29 Pali Rohár wrote: > > >> CONFIG_CMD_BOOTD provides 'boot' command which is required in > > >> more scripts. > > >> > > >> Signed-off-by: Pali Rohár > > >> --- > > >> This patch applies cleanly on top of the patch "Nokia RX-51: > > >> Enable usbtty serial console by default" [1] and CI testing > > >> passed without any issues [2] [3]. Please include it into U-Boot > > >> 2021.04 release. Code from DFU is pulled by Marek (CC'ed) as he is the overall USB custodian. The code will find its way when Marek prepares his PR and it is pulled by Tom. > > >> > > >> [1] - > > >> https://patchwork.ozlabs.org/project/uboot/patch/20210220105015.26210-1-p...@kernel.org/ > > >> [2] - > > >> https://github.com/u-boot/u-boot/pull/53/checks?check_run_id=1932112532 > > >> [3] - > > >> https://dev.azure.com/u-boot/a1096300-2999-4ec4-a21a-4c22075e3771/_build/results?buildId=1816&view=logs&jobId=9a06d2a9-1498-5de0-2a01-be581d48ba67 > > >> > > > > > > Lokesh, could you please look at this patch? > > > > I do not see the dependency patch [1] in master yet. Am I missing > > something? Without that Ill not be able to pull in the patch. > > Hm... it is marked as Accepted by Lukasz Majewski. So it is not > accepted yet? > > Lukasz, could you please look what happened with patch [1] which you > have reviewed and taken? It is waiting in some queue? We need [1] in > master not only as dependency for this patch, but also for fixing > usbtty as it is the only way how to easily debug U-Boot on N900... > > > Thanks and regards, > > Lokesh > > > > > > > >> --- > > >> configs/nokia_rx51_defconfig | 1 - > > >> 1 file changed, 1 deletion(-) > > >> > > >> diff --git a/configs/nokia_rx51_defconfig > > >> b/configs/nokia_rx51_defconfig index 0df11b98585b..312ca3a1a991 > > >> 100644 --- a/configs/nokia_rx51_defconfig > > >> +++ b/configs/nokia_rx51_defconfig > > >> @@ -17,7 +17,6 @@ CONFIG_CONSOLE_MUX=y > > >> CONFIG_HUSH_PARSER=y > > >> CONFIG_SYS_PROMPT="Nokia RX-51 # " > > >> # CONFIG_CMD_BDI is not set > > >> -# CONFIG_CMD_BOOTD is not set > > >> # CONFIG_BOOTM_NETBSD is not set > > >> # CONFIG_BOOTM_PLAN9 is not set > > >> # CONFIG_BOOTM_RTEMS is not set > > >> -- > > >> 2.20.1 > > >> 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 pgpUS_bpeiNKb.pgp Description: OpenPGP digital signature
RE: [PATCH 2/2] mmc: fsl_esdhc_imx: remove redundant cmd11 related code.
Hello Haibo,
> -Original Message-
> From: Bough Chen
> Sent: Wednesday, March 3, 2021 12:27 PM
> To: ZHIZHIKIN Andrey ; Peng Fan
> ; u-boot@lists.denx.de; sba...@denx.de
> Cc: dl-uboot-imx ; thar...@gateworks.com;
> feste...@gmail.com; Ye Li
> Subject: RE: [PATCH 2/2] mmc: fsl_esdhc_imx: remove redundant cmd11 related
> code.
>
> > -Original Message-
> > From: ZHIZHIKIN Andrey [mailto:andrey.zhizhi...@leica-geosystems.com]
> > Sent: 2021年3月3日 19:00
> > To: Bough Chen ; Peng Fan ;
> > u-boot@lists.denx.de; sba...@denx.de
> > Cc: dl-uboot-imx ; thar...@gateworks.com;
> > feste...@gmail.com; Ye Li
> > Subject: RE: [PATCH 2/2] mmc: fsl_esdhc_imx: remove redundant cmd11
> > related code.
> >
> >
> >
> > > -Original Message-
> > > From: haibo.c...@nxp.com
> > > Sent: Wednesday, March 3, 2021 10:06 AM
> > > To: peng@nxp.com; u-boot@lists.denx.de; sba...@denx.de
> > > Cc: haibo.c...@nxp.com; uboot-...@nxp.com; thar...@gateworks.com;
> > > ZHIZHIKIN Andrey ;
> > > feste...@gmail.com; ye...@nxp.com
> > > Subject: [PATCH 2/2] mmc: fsl_esdhc_imx: remove redundant cmd11
> > > related code.
> > >
> > > From: Haibo Chen
> > >
> > > Common code already handle the voltage switch sequence based on spec,
> > > so remove the redundant voltage switch code.
> > >
> > > Signed-off-by: Haibo Chen
> > > ---
> > > drivers/mmc/fsl_esdhc_imx.c | 10 +-
> > > 1 file changed, 1 insertion(+), 9 deletions(-)
> > >
> > > diff --git a/drivers/mmc/fsl_esdhc_imx.c b/drivers/mmc/fsl_esdhc_imx.c
> > > index
> > > af36558b3c..a199cf3df6 100644
> > > --- a/drivers/mmc/fsl_esdhc_imx.c
> > > +++ b/drivers/mmc/fsl_esdhc_imx.c
> > > @@ -515,15 +515,6 @@ static int esdhc_send_cmd_common(struct
> > > fsl_esdhc_priv *priv, struct mmc *mmc,
> > > goto out;
> > > }
> > >
> > > - /* Switch voltage to 1.8V if CMD11 succeeded */
> > > - if (cmd->cmdidx == SD_CMD_SWITCH_UHS18V) {
> > > - esdhc_setbits32(®s->vendorspec,
> > ESDHC_VENDORSPEC_VSELECT);
> > > -
> > > - printf("Run CMD11 1.8V switch\n");
> > > - /* Sleep for 5 ms - max time for card to switch to 1.8V */
> > > - udelay(5000);
> > > - }
> > > -
> > > /* Workaround for ESDHC errata ENGcm03648 */
> > > if (!data && (cmd->resp_type & MMC_RSP_BUSY)) {
> > > int timeout = 5;
> > > @@ -839,6 +830,7 @@ static int esdhc_set_voltage(struct mmc *mmc)
> > > }
> > > #endif
> > > esdhc_setbits32(®s->vendorspec,
> > > ESDHC_VENDORSPEC_VSELECT);
> > > + mdelay(5);
> >
> > Why is this delay introduced here? It is not clear from the commit message
> > whether and why it is required here.
> >
> > If this is kept from the removed block - maybe it is better to move the
> > corresponding comment here as well.
>
> Hi Andrev,
>
> Thanks for your careful review!
Thanks for the patch series on the first place! This allows to switch uSDHC
into high-speed modes, which is quite valuable.
> Without this 5ms delay, with patch1 and remove the upper redundant cmd11
> related code,
> mmc_switch_voltage() will fail, due to the second mmc_wait_dat0() return
> timeout. Seems for usdhc,
> gate off clock for 10ms is not enough. If total delay 15ms, then the second
> mmc_wait_dat0() can return normal.
> So I add 5ms delay here. Yes, I should add a comment for this 5ms in the code.
Exactly this information is missing with the patch, as later on it would be
quite difficult to grasp on why this mdelay() was added on the first place.
> You can also do the test on your side.
I've already did and reported with the boot log, mmc info, and my Tested-by:
tag.
>
> Best Regards
> Haibo
>
> >
> > > if (esdhc_read32(®s->vendorspec) &
> > ESDHC_VENDORSPEC_VSELECT)
> > > return 0;
> > >
> > > --
> > > 2.17.1
> >
> > -- andrey
-- andrey
Re: [PATCH 0/5] lmb: Add config for the number of memory and reserved regions
Hi Tom, On 3/2/21 9:50 PM, Tom Rini wrote: On Tue, Feb 02, 2021 at 01:59:07PM +0100, Patrick Delaunay wrote: Hi, I propose a update of the lmb library to allow the configuration with Kconfig of the number of memory and reserved regions in lmb libary: - CONFIG_LMB_RESERVED_REGIONS - CONFIG_LMB_MEMORY_REGIONS By default, I keep the default value of 8 regions. This serie avoids issue on stm32mp15 platform, as the kernel device tree defines many and non contiguous reserved regions. Patrick Delaunay (5): lmb: move CONFIG_LMB in Kconfig lmb: remove lmb_region.size lmb: Move lmb property arrays in struct lmb lmb: Add 2 config to define the max number of regions configs: stm32mp15: increase the number of reserved memory region in lmb arch/arc/include/asm/config.h| 2 -- arch/arm/include/asm/config.h| 1 - arch/m68k/include/asm/config.h | 1 - arch/microblaze/include/asm/config.h | 2 -- arch/mips/include/asm/config.h | 1 - arch/nds32/include/asm/config.h | 1 - arch/powerpc/include/asm/config.h| 1 - arch/riscv/include/asm/config.h | 1 - arch/sh/include/asm/config.h | 2 -- arch/x86/include/asm/config.h| 1 - arch/xtensa/include/asm/config.h | 2 -- configs/stm32mp15_basic_defconfig| 1 + configs/stm32mp15_trusted_defconfig | 1 + include/configs/10m50_devboard.h | 5 include/configs/3c120_devboard.h | 5 include/configs/sandbox.h| 2 -- include/configs/x86-common.h | 2 -- include/image.h | 2 +- include/lmb.h| 34 lib/Kconfig | 23 +++ lib/lmb.c| 14 ++-- scripts/config_whitelist.txt | 1 - 22 files changed, 63 insertions(+), 42 deletions(-) This series causes a little bit of size growth everywhere. It's fatal on nokia_rx51 (and caught via the test script). We can bring nokia_rx51 back under size by disabling the optimized memcpy/memset functions, but that's not ideal. Can we do your changes here in a more size-concious way? Thanks! Sure, I will check and correct this issue. Patrick
[PATCH u-boot] regmap: fix a serious pointer casting bug
There is a serious bug in regmap_read() and regmap_write() functions
where an uint pointer is cast to (void *) which is then cast to (u8 *),
(u16 *), (u32 *) or (u64 *), depending on register width of the map.
For example given a regmap with 16-bit register width the code
int val = 0x1234;
regmap_read(map, 0, &val);
only changes the lower 16 bits of val on little-endian machines.
The upper 16 bits will remain 0x1234.
Nobody noticed this probably because this bug can be triggered with
regmap_write() only on big-endian architectures (which are not used by
many people anymore), and on little endian this bug has consequences
only if register width is 8 or 16 bits and also the memory place to
which regmap_read() should store it's result has non-zero upper bits,
which it seems doesn't happen anywhere in U-Boot normally. CI managed to
trigger this bug in unit test of dm_test_devm_regmap_field when compiled
for sandbox_defconfig using LTO.
Fix this simply by taking into account that regmap_raw_read() and
regmap_raw_write() behave as if the data given to these functions were
in little-endian format, i.e. use cpu_to_le32() / le32_to_cpu(). In
regmap_read() also zero out the space so that we don't get invalid
result if regmap_raw_read() does not fill the whole object.
Signed-off-by: Marek Behún
---
drivers/core/regmap.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/core/regmap.c b/drivers/core/regmap.c
index b51ce108c1..5d37006fff 100644
--- a/drivers/core/regmap.c
+++ b/drivers/core/regmap.c
@@ -435,7 +435,16 @@ int regmap_raw_read(struct regmap *map, uint offset, void
*valp, size_t val_len)
int regmap_read(struct regmap *map, uint offset, uint *valp)
{
- return regmap_raw_read(map, offset, valp, map->width);
+ int res;
+
+ *valp = 0;
+ res = regmap_raw_read(map, offset, valp, map->width);
+ if (res)
+ return res;
+
+ *valp = le32_to_cpu(*valp);
+
+ return 0;
}
static inline void __write_8(u8 *addr, const u8 *val,
@@ -546,6 +555,8 @@ int regmap_raw_write(struct regmap *map, uint offset, const
void *val,
int regmap_write(struct regmap *map, uint offset, uint val)
{
+ val = cpu_to_le32(val);
+
return regmap_raw_write(map, offset, &val, map->width);
}
--
2.26.2
Re: [PATCH 16/20] dm: core: Correctly read of simple-bus
On Tue, Mar 02, 2021 at 11:34:47PM +0800, Bin Meng wrote: > At present we decode simple bus using the following assumption: > > - parent #address-cells 1 > - child #address-cells 1 > - child #size-cells 1 > > However this might not always be the case. > > Update to use fdt_addr_t and fdt_size_t in 'struct simple_bus_plat', and > use fdt_read_ranges() to correctly decode it according to the actual > parent and child #address-cells / #size-cells. > > Signed-off-by: Bin Meng > --- > > drivers/core/simple-bus.c | 15 ++- > include/dm/simple_bus.h | 6 +++--- > 2 files changed, 13 insertions(+), 8 deletions(-) > > diff --git a/drivers/core/simple-bus.c b/drivers/core/simple-bus.c > index b0c2c20958..b5863f2b2c 100644 > --- a/drivers/core/simple-bus.c > +++ b/drivers/core/simple-bus.c > @@ -6,6 +6,9 @@ > #include > #include > #include > +#include > + > +DECLARE_GLOBAL_DATA_PTR; You need to add here too. -- Tom signature.asc Description: PGP signature
Re: [PATCH] fs/squashfs: Fix compilation error
On Wed, Mar 03, 2021 at 10:52:36AM +0100, Pali Rohár wrote:
> Commit 401d1c4f5d2d29c4bc4beaec95402ca23eb63295 ("common: Drop
> asm/global_data.h from common header") broke compilation of squashfs
> filesystem when CONFIG_CMD_SQUASHFS=y is enabled.
>
> Compilation is failing on error:
>
> aarch64-linux-gnu-ld.bfd: u-boot/fs/squashfs/sqfs_inode.c:121: undefined
> reference to `le32_to_cpu'
>
> Fixes: 401d1c4f5d2d29c4bc4beaec95402ca23eb63295 ("common: Drop
> asm/global_data.h from common header")
> Suggested-by: Tom Rini
> Signed-off-by: Pali Rohár
Reviewed-by: Tom Rini
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v2] arm: Add support for Kobol Helios64 board
Oh, thanks for the pointer! I guess I should've had another look at the
archive before posting the patch.
If you see this Uwe, thanks for taking it on :)
On Tue, Mar 2, 2021 at 7:27 PM Dennis Gilmore
wrote:
> Uwe submitted this board last Thursday
>
> Dennis
>
> On Tue, Mar 2, 2021 at 10:46 AM Christian Glombek
> wrote:
> >
> > The hardware is described in detail on Kobol's wiki at
> > https://wiki.kobol.io/helios64/intro/.
> >
> > This commit is based on downstream work in Armbian by Aditya Prayoga [1].
> > The devicetree is taken from Linux v5.12-rc1 and was originally
> submitted there by
> > Uwe Kleine-Koenig [2].
> >
> > [1]
> https://github.com/ukleinek/armbian-build/blob/35c85295d351830aa59b624db524ba04b238faae/patch/kernel/rockchip64-current/add-board-helios64.patch
> > [2]
> https://github.com/torvalds/linux/blob/7a7fd0de4a9804299793e564a555a49c1fc924cb/arch/arm64/boot/dts/rockchip/rk3399-kobol-helios64.dts
> > ---
> > arch/arm/dts/Makefile | 1 +
> > .../arm/dts/rk3399-kobol-helios64-u-boot.dtsi | 136 +++
> > arch/arm/dts/rk3399-kobol-helios64.dts| 372 ++
> > arch/arm/mach-rockchip/rk3399/Kconfig | 17 +
> > board/kobol/helios64/Kconfig | 24 ++
> > board/kobol/helios64/MAINTAINERS | 6 +
> > board/kobol/helios64/Makefile | 5 +
> > board/kobol/helios64/helios64.c | 304 ++
> > board/kobol/helios64/sys_otp.c| 250
> > board/kobol/helios64/sys_otp.h| 12 +
> > configs/helios64-rk3399_defconfig | 147 +++
> > include/configs/helios64.h| 47 +++
> > 12 files changed, 1321 insertions(+)
> > create mode 100644 arch/arm/dts/rk3399-kobol-helios64-u-boot.dtsi
> > create mode 100644 arch/arm/dts/rk3399-kobol-helios64.dts
> > create mode 100644 board/kobol/helios64/Kconfig
> > create mode 100644 board/kobol/helios64/MAINTAINERS
> > create mode 100644 board/kobol/helios64/Makefile
> > create mode 100644 board/kobol/helios64/helios64.c
> > create mode 100644 board/kobol/helios64/sys_otp.c
> > create mode 100644 board/kobol/helios64/sys_otp.h
> > create mode 100644 configs/helios64-rk3399_defconfig
> > create mode 100644 include/configs/helios64.h
> >
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > index 33e483f4fb..2c820bc2b7 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -124,6 +124,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3399) += \
> > rk3399-ficus.dtb \
> > rk3399-firefly.dtb \
> > rk3399-gru-bob.dtb \
> > + rk3399-kobol-helios64.dtb \
> > rk3399-khadas-edge.dtb \
> > rk3399-khadas-edge-captain.dtb \
> > rk3399-khadas-edge-v.dtb \
> > diff --git a/arch/arm/dts/rk3399-kobol-helios64-u-boot.dtsi
> b/arch/arm/dts/rk3399-kobol-helios64-u-boot.dtsi
> > new file mode 100644
> > index 00..6fe9d59df3
> > --- /dev/null
> > +++ b/arch/arm/dts/rk3399-kobol-helios64-u-boot.dtsi
> > @@ -0,0 +1,136 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (c) 2020 Aditya Prayoga
> > + */
> > +
> > +#include "rk3399-u-boot.dtsi"
> > +#include "rk3399-sdram-lpddr4-100.dtsi"
> > +/ {
> > + aliases {
> > + spi0 = &spi1;
> > + spi1 = &spi2;
> > + spi2 = &spi5;
> > + ethernet0 = &gmac;
> > + ethernet1 = &usb_lan;
> > + };
> > +
> > + chosen {
> > + bootargs = "earlycon=uart8250,mmio32,0xff1a
> earlyprintk";
> > + stdout-path = "serial2:150n8";
> > + u-boot,spl-boot-order = "same-as-spl", &spiflash,
> &sdmmc, &sdhci;
> > + };
> > +
> > + config {
> > + u-boot,spl-payload-offset = <0x8>; /* @ 512KB */
> > + };
> > +};
> > +
> > +&gpio1 {
> > + usb-mux-hs {
> > + gpio-hog;
> > + gpios = ;
> > + output-low;
> > + line-name = "USB_MUX_HS";
> > + };
> > +
> > + usb-mux-oe {
> > + gpio-hog;
> > + gpios = ;
> > + output-high;
> > + line-name = "USB_MUX_OE#";
> > + };
> > +
> > + soc-flash-wp {
> > + gpio-hog;
> > + gpios = ;
> > + output-low;
> > + line-name = "SOC_WP#";
> > + };
> > +};
> > +
> > +&gpio2 {
> > + sata-flash-wp {
> > + gpio-hog;
> > + gpios = ;
> > + output-high;
> > + line-name = "SATA_WP#_LV";
> > + };
> > +};
> > +
> > +&gpio4 {
> > + auto-on-en-d {
> > + gpio-hog;
> > + gpios = ;
> > + output-low;
> > + line-name = "AUTO_ON_EN_D";
> > + };
> > +
> > + auto-on-en-clk {
> > + gpio-hog;
> > + gpios = ;
> > + output-
[PATCH] arm: a37xx: pci: Implement workaround for the readback value of VEND_ID
Marvell Armada 3720 Functional Errata, Guidelines, and Restrictions document describes in erratum 4.1 PCIe value of vendor ID (Ref #: 243): The readback value of VEND_ID (RD007h [15:0]) is 1B4Bh, while it should read 11ABh. The firmware can write the correct value, 11ABh, through VEND_ID (RD0076044h [15:0]). Implement this workaround in U-Boot PCIe controller driver aardvark for both PCI vendor id and PCI subsystem vendor id. This change affects PCI vendor id of PCIe root bridge emulated by Linux kernel. With this change Linux kernel reports correct vendor id 11AB. Signed-off-by: Pali Rohár --- drivers/pci/pci-aardvark.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/pci/pci-aardvark.c b/drivers/pci/pci-aardvark.c index b4e1b602405f..3b9309f52c57 100644 --- a/drivers/pci/pci-aardvark.c +++ b/drivers/pci/pci-aardvark.c @@ -105,6 +105,7 @@ #define LTSSM_SHIFT24 #define LTSSM_MASK 0x3f #define LTSSM_L0 0x10 +#define VENDOR_ID_REG (LMI_BASE_ADDR + 0x44) /* PCIe core controller registers */ #define CTRL_CORE_BASE_ADDR0x18000 @@ -529,6 +530,15 @@ static int pcie_advk_setup_hw(struct pcie_advk *pcie) reg |= (IS_RC_MSK << IS_RC_SHIFT); advk_writel(pcie, reg, PCIE_CORE_CTRL0_REG); + /* +* Replace incorrect PCI vendor id value 0x1b4b by correct value 0x11ab. +* VENDOR_ID_REG contains vendor id in low 16 bits and subsystem vendor +* id in high 16 bits. Updating this register changes readback value of +* read-only vendor id bits in PCIE_CORE_DEV_ID_REG register. Workaround +* for erratum 4.1: "The value of device and vendor ID is incorrect". +*/ + advk_writel(pcie, 0x11ab11ab, VENDOR_ID_REG); + /* Set Advanced Error Capabilities and Control PF0 register */ reg = PCIE_CORE_ERR_CAPCTL_ECRC_CHK_TX | PCIE_CORE_ERR_CAPCTL_ECRC_CHK_TX_EN | -- 2.20.1
[PATCH v3 1/2] arm: dts: imx8mm: add Gateworks i.MX8 Mini Dev kits
> Add Gateworks i.MX 8M Mini Development kits from Linux-5.12-rc1 > Signed-off-by: Tim Harvey Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de =
[PATCH V4] ARM: imx: Include u-boot.img in u-boot-with-spl.imx if OF_SEPARATE=y
> The u-boot-with-spl.imx is a concatenation of SPL and u-boot.uim. > The u-boot.uim is u-boot.bin wrapped in uImage. In case OF_SEPARATE > is enabled, the u-boot.bin does not contain control DT for U-Boot, > and so u-boot.uim does not contain the DT, and so u-boot-with-spl.imx > does not contain the DT, and a system where u-boot-with-spl.imx is > written to offset 1024B to the start of storage no longer boots, as > it is missing DT. > In case OF_SEPARATE is enabled, u-boot.img contains both u-boot.bin > and the necessary DTs. Therefore, use u-boot.img instead of u-boot.uim > to generate u-boot-with-spl.imx when OF_SEPARATE is enabled. > Signed-off-by: Marek Vasut > Cc: Christoph Niedermaier > Cc: Fabio Estevam > Cc: Peng Fan > Cc: Simon Glass > Cc: Stefano Babic > Cc: Ye Li > Cc: uboot-imx Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de =
[PATCH v3 2/2] board: gateworks: imx8mm: Add Gateworks Venice board support
> Add initial support for Gateworks Venice product family based on the > i.MX 8M Mini SoC > Signed-off-by: Tim Harvey Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de =
Pull request: u-boot-imx u-boot-imx-20210003
Hi Tom, please pull from u-boot-imx, thanks ! The following changes since commit 08cca188c120b8337600091c94dc0e211cd03e10: Merge https://gitlab.denx.de/u-boot/custodians/u-boot-usb (2021-02-26 15:11:08 -0500) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git tags/u-boot-imx-20210303 for you to fetch changes up to 03bf8436a3a5b19ff4ae23868dd479acc050ff08: board: gateworks: imx8mm: Add Gateworks Venice board support (2021-03-03 14:15:02 +0100) i.MX for 2021.04 - new boards: - i.MX8MN Beacon EmbeddedWorks (2GB) - Gateworks Venice imx8mm - convert to DM: - imx53-qsb, mx53loco, mx51evk, mx23-evk - Fixes : - Network : FEC ethernet quirks - DH dh-imx6 CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/6597 Adam Ford (1): imx: Add 2GB lpddr support for i.MX8MN Beacon EmbeddedWorks devkit. Fabio Estevam (13): imx53-qsb: Import devicetree files from Linux mx53loco: Convert to driver model ARM: dts: imx53-qsb: Describe the esdhc1 card detect pin mx53loco: Add myself as maintainer mmc: fsl_esdhc_imx: Add a compatible for i.MX51 imx51-babbage: Import devicetree files from Linux mx51evk: Convert to driver model mx51evk: Add myself as maintainer mx23-evk: Import devicetree file from Linux mx23evk: Convert to driver model mx23evk: Add myself as maintainer tools: imx8mimage: Restore the original __ALIGN_MASK() macro ARM: dts: imx8mq-evk: Remove u-boot,off-on-delay-us property Frieder Schrempf (1): Respect that some compression algos can be enabled separately for SPL Haibo Chen (1): mmc: fsl_esdhc_imx: fix the DTOCV to 0xE Marek Vasut (8): ARM: imx: Revert "dh_imx6: Switch to full DM-aware" ARM: imx6: dh-imx6: Enable support for applying DTO ARM: imx6: dh-imx6: Drop the SF hunk in config ARM: imx6: mx6sabre-common: Replace fatload with FS_GENERIC load ARM: imx6: mx6sabre-common: Search for boot components in /boot too ARM: imx: Add missing FEC ethernet quirk for MX8M ARM: imx: Do not hard-code MX8M MMU table DRAM entry offset ARM: imx: Include u-boot.img in u-boot-with-spl.imx if OF_SEPARATE=y Oleksandr Suvorov (2): ARM: imx8: Add missing FEC ENET quirk for i.MX8/i.MX8X board: toradex: move RGMII delays to PHY side Peter Bergin (1): doc: board: freescale: imx8mp_evk: update to newer versions and change ATF_LOAD_ADDR Sean Anderson (1): ARM: mx6: Add function to set serial# Tim Harvey (3): thermal: imx_tmu: enable monitoring and default alert/critical arm: dts: imx8mm: add Gateworks i.MX8 Mini Dev kits board: gateworks: imx8mm: Add Gateworks Venice board support Ye Li (2): mx6sabre: Fix boot failure arm: dts: imx8mp-evk: Add FEC PHY reset timing Makefile |5 +- arch/arm/dts/Makefile| 11 + arch/arm/dts/fsl-imx8qm-apalis.dts |2 +- arch/arm/dts/fsl-imx8qxp-apalis.dts |2 +- arch/arm/dts/imx23-evk-u-boot.dtsi |4 + arch/arm/dts/imx23-evk.dts | 145 +++ arch/arm/dts/imx23-pinfunc.h | 333 + arch/arm/dts/imx23-u-boot.dtsi | 14 ++ arch/arm/dts/imx23.dtsi | 636 +++ arch/arm/dts/imx51-babbage.dts | 726 ++ arch/arm/dts/imx51-pinfunc.h | 768 + arch/arm/dts/imx51.dtsi | 654 + arch/arm/dts/imx53-qsb-common.dtsi | 387 + arch/arm/dts/imx53-qsb.dts | 111 + arch/arm/dts/imx8mm-venice-gw700x-u-boot.dtsi| 105 arch/arm/dts/imx8mm-venice-gw700x.dtsi | 495 + arch/arm/dts/imx8mm-venice-gw71xx-0x-u-boot.dtsi |5 + arch/arm/dts/imx8mm-venice-gw71xx-0x.dts | 19 ++ arch/arm/dts/imx8mm-venice-gw71xx.dtsi | 186 ++ arch/arm/dts/imx8mm-venice-gw72xx-0x-u-boot.dtsi |5 + arch/arm/dts/imx8mm-venice-gw72xx-0x.dts | 19 ++ arch/arm/dts/imx8mm-venice-gw72xx.dtsi | 311 +++ arch/arm/dts/imx8mm-venice-gw73xx-0x-u-boot.dtsi |5 + arch/arm/dts/imx8mm-venice-gw73xx-0x.dts | 19 ++ arch/arm/dts/imx8mm-venice-gw73xx.dtsi | 362 +++ arch/arm/dts/imx8mm-venice-u-boot.dtsi
Re: [PULL] u-boot-usb/master
On Wed, Mar 03, 2021 at 11:57:09AM +0100, Marek Vasut wrote: > This should be the last one of the stuck USB PRs. > > The following changes since commit 78af81c345430a9088235f48d302922955d2499f: > > Merge tag 'rpi-next-2021.04.2' of > https://source.denx.de/u-boot/custodians/u-boot-raspberrypi (2021-03-02 > 16:46:16 -0500) > > are available in the Git repository at: > > git://source.denx.de/u-boot-usb.git master > > for you to fetch changes up to 795d605cab787e6d9151221312b09391aacfb8e5: > > usb: USB keyboard requires DM_KEYBOARD (2021-03-03 04:12:46 +0100) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [RFC PATCH u-boot 00/12] U-Boot LTO (Sandbox + ARM Nokia RX-51)
On Wed, Mar 03, 2021 at 05:11:59AM +0100, Marek Behún wrote: > Hello, > > I have managed to add support for building U-Boot with LTO (with GCC) > in a rather sane way (in LOC changed). > > This series and its follows will also be available at > https://github.com/elkablo/u-boot branch lto. > > I have tested these builds on Turris Omnia, Turris MOX and on Nokia N900 > (via the test/nokia_rx51_test.sh script). For other tests I have created > a pull-request on github to trigger CI > (https://github.com/u-boot/u-boot/pull/57) > For some reason it is waiting now, maybe Azure is not working or > something. As we're on the free tier with Azure it sometimes just queues us up for a long time, this job finally started running recently. > My tests on Omnia and MOX show that U-Boot boots sucessfully, and basic > commands seem to work. But of course something broken due to LTO may be > found later. > > So for all of you that are interested and have an ARM board, please test > this on your boards by enabling CONFIG_LTO option. Also please report > code size reductions. (Chris Packham reports an error related to > jobserver, so if `make -jN` produces an error, please try without the > `-jN` flag.) > > I have only tested with gcc-10. There are still some warnings printed, > like: > bfd plugin: invalid symbol type found > but these don't seem to matter. I will look into this later. > > Here are some results by how much code size reduced. Note that SPL > binary seems to gain more code reduction (15.4 % on average) than main > binary (4.5 % on average). > > I guess this is because of how drivers are written. The optimizer cannot > know which code paths won't be used, since it does not see the device > tree. Maybe this could be somehow integrated with Simon's work on > OF_PLATDATA_INST in the future, to make the compiler optimize out unused > code paths in drivers by understanding the device tree. > > u-boot.bin u-boot-spl.bin > > clearfog4.34 % 19.0 KB13.55 % 16.8 KB > controlcenterdc4.79 % 24.2 KB16.27 % 21.9 KB >db-88f6820-amc4.23 % 25.0 KB16.17 % 22.9 KB > db-88f6820-gp4.42 % 22.1 KB17.00 % 23.8 KB > helios44.32 % 18.9 KB13.70 % 16.8 KB >nokia_rx516.11 % 16.5 KB >turris_mox4.17 % 31.8 KB > turris_omnia4.32 % 30.2 KB14.91 % 16.6 KB > x5303.93 % 30.0 KB16.26 % 23.4 KB > > Marek Thanks for starting on this! It's been on my list for a long time, especially since it does give overall better reduction than function/data-sections/discard. It does seem like clang fails to build with this series. One thing I want to try locally, and I'll fire off the results once I do it, is moving to LTO by default for ARM. -- Tom signature.asc Description: PGP signature
Re: [RFC PATCH u-boot 00/12] U-Boot LTO (Sandbox + ARM Nokia RX-51)
On Wed, 3 Mar 2021 11:11:59 -0500 Tom Rini wrote: > On Wed, Mar 03, 2021 at 05:11:59AM +0100, Marek Behún wrote: > > > Hello, > > > > I have managed to add support for building U-Boot with LTO (with GCC) > > in a rather sane way (in LOC changed). > > > > This series and its follows will also be available at > > https://github.com/elkablo/u-boot branch lto. > > > > I have tested these builds on Turris Omnia, Turris MOX and on Nokia N900 > > (via the test/nokia_rx51_test.sh script). For other tests I have created > > a pull-request on github to trigger CI > > (https://github.com/u-boot/u-boot/pull/57) > > For some reason it is waiting now, maybe Azure is not working or > > something. > > As we're on the free tier with Azure it sometimes just queues us up for > a long time, this job finally started running recently. > > > My tests on Omnia and MOX show that U-Boot boots sucessfully, and basic > > commands seem to work. But of course something broken due to LTO may be > > found later. > > > > So for all of you that are interested and have an ARM board, please test > > this on your boards by enabling CONFIG_LTO option. Also please report > > code size reductions. (Chris Packham reports an error related to > > jobserver, so if `make -jN` produces an error, please try without the > > `-jN` flag.) > > > > I have only tested with gcc-10. There are still some warnings printed, > > like: > > bfd plugin: invalid symbol type found > > but these don't seem to matter. I will look into this later. > > > > Here are some results by how much code size reduced. Note that SPL > > binary seems to gain more code reduction (15.4 % on average) than main > > binary (4.5 % on average). > > > > I guess this is because of how drivers are written. The optimizer cannot > > know which code paths won't be used, since it does not see the device > > tree. Maybe this could be somehow integrated with Simon's work on > > OF_PLATDATA_INST in the future, to make the compiler optimize out unused > > code paths in drivers by understanding the device tree. > > > > u-boot.bin u-boot-spl.bin > > > > clearfog4.34 % 19.0 KB13.55 % 16.8 KB > > controlcenterdc4.79 % 24.2 KB16.27 % 21.9 KB > >db-88f6820-amc4.23 % 25.0 KB16.17 % 22.9 KB > > db-88f6820-gp4.42 % 22.1 KB17.00 % 23.8 KB > > helios44.32 % 18.9 KB13.70 % 16.8 KB > >nokia_rx516.11 % 16.5 KB > >turris_mox4.17 % 31.8 KB > > turris_omnia4.32 % 30.2 KB14.91 % 16.6 KB > > x5303.93 % 30.0 KB16.26 % 23.4 KB > > > > Marek > > Thanks for starting on this! It's been on my list for a long time, > especially since it does give overall better reduction than > function/data-sections/discard. It does seem like clang fails to build > with this series. One thing I want to try locally, and I'll fire off > the results once I do it, is moving to LTO by default for ARM. > Yes, it seems clang is the last thing I need to look at. I did not even try, really, my first priority was gcc. I will look into this tomorrow. All in all I am happy with this since it seems to be running for several different boards without issue. If you want to enable LTO by default for ARM, we probably need to determine which gcc version should be minimal for this. Because older gcc versions may have problems with LTO. What is the current minimal version of gcc for U-Boot? Marek
Re: [RFC PATCH u-boot 00/12] U-Boot LTO (Sandbox + ARM Nokia RX-51)
On Wed, Mar 03, 2021 at 05:41:57PM +0100, Marek Behun wrote: > On Wed, 3 Mar 2021 11:11:59 -0500 > Tom Rini wrote: > > > On Wed, Mar 03, 2021 at 05:11:59AM +0100, Marek Behún wrote: > > > > > Hello, > > > > > > I have managed to add support for building U-Boot with LTO (with GCC) > > > in a rather sane way (in LOC changed). > > > > > > This series and its follows will also be available at > > > https://github.com/elkablo/u-boot branch lto. > > > > > > I have tested these builds on Turris Omnia, Turris MOX and on Nokia N900 > > > (via the test/nokia_rx51_test.sh script). For other tests I have created > > > a pull-request on github to trigger CI > > > (https://github.com/u-boot/u-boot/pull/57) > > > For some reason it is waiting now, maybe Azure is not working or > > > something. > > > > As we're on the free tier with Azure it sometimes just queues us up for > > a long time, this job finally started running recently. > > > > > My tests on Omnia and MOX show that U-Boot boots sucessfully, and basic > > > commands seem to work. But of course something broken due to LTO may be > > > found later. > > > > > > So for all of you that are interested and have an ARM board, please test > > > this on your boards by enabling CONFIG_LTO option. Also please report > > > code size reductions. (Chris Packham reports an error related to > > > jobserver, so if `make -jN` produces an error, please try without the > > > `-jN` flag.) > > > > > > I have only tested with gcc-10. There are still some warnings printed, > > > like: > > > bfd plugin: invalid symbol type found > > > but these don't seem to matter. I will look into this later. > > > > > > Here are some results by how much code size reduced. Note that SPL > > > binary seems to gain more code reduction (15.4 % on average) than main > > > binary (4.5 % on average). > > > > > > I guess this is because of how drivers are written. The optimizer cannot > > > know which code paths won't be used, since it does not see the device > > > tree. Maybe this could be somehow integrated with Simon's work on > > > OF_PLATDATA_INST in the future, to make the compiler optimize out unused > > > code paths in drivers by understanding the device tree. > > > > > > u-boot.bin u-boot-spl.bin > > > > > > clearfog4.34 % 19.0 KB13.55 % 16.8 KB > > > controlcenterdc4.79 % 24.2 KB16.27 % 21.9 KB > > >db-88f6820-amc4.23 % 25.0 KB16.17 % 22.9 KB > > > db-88f6820-gp4.42 % 22.1 KB17.00 % 23.8 KB > > > helios44.32 % 18.9 KB13.70 % 16.8 KB > > >nokia_rx516.11 % 16.5 KB > > >turris_mox4.17 % 31.8 KB > > > turris_omnia4.32 % 30.2 KB14.91 % 16.6 KB > > > x5303.93 % 30.0 KB16.26 % 23.4 KB > > > > > > Marek > > > > Thanks for starting on this! It's been on my list for a long time, > > especially since it does give overall better reduction than > > function/data-sections/discard. It does seem like clang fails to build > > with this series. One thing I want to try locally, and I'll fire off > > the results once I do it, is moving to LTO by default for ARM. > > > > Yes, it seems clang is the last thing I need to look at. I did not even > try, really, my first priority was gcc. I will look into this tomorrow. > > All in all I am happy with this since it seems to be running for > several different boards without issue. Great. I'll give it a spin on my platforms as well, but I suspect things are good. > If you want to enable LTO by default for ARM, we probably need to > determine which gcc version should be minimal for this. Because older > gcc versions may have problems with LTO. What is the current minimal > version of gcc for U-Boot? We, funny enough, have a check for gcc-4.0.4 on ARM, followed by gcc-6.0. That 4.0.4 check should be dropped, and gcc-6.0 is the minimum. I think gcc-7.2 or so is going to be important to keep working but given the age of the Linux Kernel LTO support, we should be fine in that regard. -- Tom signature.asc Description: PGP signature
Re: [PATCH 00/20] ppc: qemu: Add eTSEC support
On Wed, Mar 03, 2021 at 10:11:45AM +0800, Bin Meng wrote: > Hi Simon, > > On Wed, Mar 3, 2021 at 9:53 AM Simon Glass wrote: > > > > Hi Bin, > > > > On Tue, 2 Mar 2021 at 18:08, Bin Meng wrote: > > > > > > Hi Tom, > > > > > > On Tue, Mar 2, 2021 at 11:35 PM Bin Meng wrote: > > > > > > > > QEMU ppce500 machine can dynamically instantiate an eTSEC device > > > > if "-device eTSEC" is given to QEMU. > > > > > > > > This series updates the fixed-link ethernet PHY driver as well as > > > > the Freescale eTSEC driver to support the QEMU ppce500 board. > > > > > > > > Based-on: > > > > http://patchwork.ozlabs.org/project/uboot/list/?series=230985 > > > > > > > > This series is avaiable at u-boot-x86/eTSEC for testing. > > > > > > > > > > > > > > Azure results say there are several ARM boards fail to build due to > > > size overflow with this series. > > > https://dev.azure.com/bmeng/GitHub/_build/results?buildId=334&view=results > > > > > > How do we handle this? > > > > The one I looked at, imx6dl_mamoj seems to be 0xbc5 over the limit. > > That's a very large growth, indicating that your series is doing > > something odd, perhaps? > > > > I suppose you know this, but you can use: > > > > buildman -b try imx6dl_mamoj > > buildman -b try -sS > > > > to see which commit creates the size growth, and -B to see which functions. > > Thanks, so it's caused by this patch: > http://patchwork.ozlabs.org/project/uboot/patch/20210302153451.19440-17-bmeng...@gmail.com/ > > 16: dm: core: Correctly read of simple-bus >arm: + imx6dl_mamoj >arm: (for 1/1 boards) all +274.0 bss -32.0 spl/u-boot-spl:all > +3232.0 spl/u-boot-spl:data +24.0 spl/u-boot-spl:rodata +2180.0 > spl/u-boot-spl:text +1028.0 text +306.0 > imx6dl_mamoj : all +274 bss -32 spl/u-boot-spl:all +3232 > spl/u-boot-spl:data +24 spl/u-boot-spl:rodata +2180 > spl/u-boot-spl:text +1028 text +306 >spl-u-boot-spl: add: 9/-1, grow: 1/0 bytes: 1070/-24 (1046) > function old new > delta > __of_translate_address - 404 > +404 > fdt_read_range - 208 > +208 > of_bus_default_map - 148 > +148 > of_bus_default_translate - 114 > +114 > fdt_read_prop- 66 > +66 > fdt_support_default_count_cells - 52 > +52 > fdt_getprop_u32_default_node - 36 > +36 > of_busses- 24 > +24 > fdt_translate_address- 12 > +12 > simple_bus_post_bind52 58 > +6 > ofnode_read_u32_array 24 - > -24 >u-boot: add: 3/-1, grow: 1/0 bytes: 316/-24 (292) > function old new > delta > fdt_read_range - 208 > +208 > fdt_read_prop- 66 > +66 > fdt_getprop_u32_default_node - 36 > +36 > simple_bus_post_bind52 58 > +6 > ofnode_read_u32_array 24 - > -24 > > > But this patch is a bug fix. I am not sure how we can avoid the size increase. I'd love to hear there's a clever fix we can do here for SPL, but in the likely case there isn't, this might get stuck until the LTO series that was posted today goes in as well, as that will give us some size back. I assume this was a bug fix your series needed and not something you noticed while in the code. -- Tom signature.asc Description: PGP signature
Re: [PATCH 00/20] ppc: qemu: Add eTSEC support
Hi Bin, On Wed, 3 Mar 2021 at 09:49, Tom Rini wrote: > > On Wed, Mar 03, 2021 at 10:11:45AM +0800, Bin Meng wrote: > > Hi Simon, > > > > On Wed, Mar 3, 2021 at 9:53 AM Simon Glass wrote: > > > > > > Hi Bin, > > > > > > On Tue, 2 Mar 2021 at 18:08, Bin Meng wrote: > > > > > > > > Hi Tom, > > > > > > > > On Tue, Mar 2, 2021 at 11:35 PM Bin Meng wrote: > > > > > > > > > > QEMU ppce500 machine can dynamically instantiate an eTSEC device > > > > > if "-device eTSEC" is given to QEMU. > > > > > > > > > > This series updates the fixed-link ethernet PHY driver as well as > > > > > the Freescale eTSEC driver to support the QEMU ppce500 board. > > > > > > > > > > Based-on: > > > > > http://patchwork.ozlabs.org/project/uboot/list/?series=230985 > > > > > > > > > > This series is avaiable at u-boot-x86/eTSEC for testing. > > > > > > > > > > > > > > > > > > Azure results say there are several ARM boards fail to build due to > > > > size overflow with this series. > > > > https://dev.azure.com/bmeng/GitHub/_build/results?buildId=334&view=results > > > > > > > > How do we handle this? > > > > > > The one I looked at, imx6dl_mamoj seems to be 0xbc5 over the limit. > > > That's a very large growth, indicating that your series is doing > > > something odd, perhaps? > > > > > > I suppose you know this, but you can use: > > > > > > buildman -b try imx6dl_mamoj > > > buildman -b try -sS > > > > > > to see which commit creates the size growth, and -B to see which > > > functions. > > > > Thanks, so it's caused by this patch: > > http://patchwork.ozlabs.org/project/uboot/patch/20210302153451.19440-17-bmeng...@gmail.com/ > > > > 16: dm: core: Correctly read of simple-bus > >arm: + imx6dl_mamoj > >arm: (for 1/1 boards) all +274.0 bss -32.0 spl/u-boot-spl:all > > +3232.0 spl/u-boot-spl:data +24.0 spl/u-boot-spl:rodata +2180.0 > > spl/u-boot-spl:text +1028.0 text +306.0 > > imx6dl_mamoj : all +274 bss -32 spl/u-boot-spl:all +3232 > > spl/u-boot-spl:data +24 spl/u-boot-spl:rodata +2180 > > spl/u-boot-spl:text +1028 text +306 > >spl-u-boot-spl: add: 9/-1, grow: 1/0 bytes: 1070/-24 (1046) > > function old new > > delta > > __of_translate_address - 404 > > +404 > > fdt_read_range - 208 > > +208 > > of_bus_default_map - 148 > > +148 > > of_bus_default_translate - 114 > > +114 > > fdt_read_prop- 66 > > +66 > > fdt_support_default_count_cells - 52 > > +52 > > fdt_getprop_u32_default_node - 36 > > +36 > > of_busses- 24 > > +24 > > fdt_translate_address- 12 > > +12 > > simple_bus_post_bind52 58 > > +6 > > ofnode_read_u32_array 24 - > > -24 > >u-boot: add: 3/-1, grow: 1/0 bytes: 316/-24 (292) > > function old new > > delta > > fdt_read_range - 208 > > +208 > > fdt_read_prop- 66 > > +66 > > fdt_getprop_u32_default_node - 36 > > +36 > > simple_bus_post_bind52 58 > > +6 > > ofnode_read_u32_array 24 - > > -24 > > > > > > But this patch is a bug fix. I am not sure how we can avoid the size > > increase. > > I'd love to hear there's a clever fix we can do here for SPL, but in the > likely case there isn't, this might get stuck until the LTO series that > was posted today goes in as well, as that will give us some size back. > I assume this was a bug fix your series needed and not something you > noticed while in the code. > The size increase is so enormous that I'd argue for a new Kconfig that you can select for the board that needs it. Regards, Simon
Re: [PATCH v3 1/1] env: sf: single function env_sf_save()
On 03.03.21 00:06, Sean Anderson wrote:
On 3/2/21 1:09 PM, Harry Waschkeit wrote:
Hello Sean,
On 02.03.21 00:10, Sean Anderson wrote:
On 3/1/21 11:39 AM, Harry Waschkeit wrote:
Hi again,
gentle ping for that patch, also in view of subsequently sent patch ...
https://lists.denx.de/pipermail/u-boot/2021-February/439797.html
... which saw a competing patch by Patrick Delaunay a week later:
https://lists.denx.de/pipermail/u-boot/2021-February/440769.html
However, the latter doesn't seem to take embedded environments into account.
Can you give an example of where your patch would work while Patrick's wouldn't?
I didn't dig too deep into Patrick's patch and maybe I simply miss
something important, but I don't even see an spi_flash_erase() in his
code, so I'm wondering how it could work at all.
Writing to SPI flash can only set bits to 0. To set bits to 1 you must
erase them. Conceptually, write(buf) does
flash[i] &= buf[i];
And erase() does
flash[i] = -1;
So writing 0s always succeeds, and we are certain to invalidate the
environment (as long as our hash has a non-zero value for an all-zero
input).
Sure.
So it's only the name that is confusing because there's no erase happening at
all in env_sf_erase(), a real flash erase is necessary afterwards if you want
to write data to environment space.
I think it would be worth a comment in the function then, maybe also others get
confused what a function called something with erase actually does with flash
data ;-)
What I do see in his code is spi_flash_write() with a CONFIG_ENV_SIZE
worth of zeroes to the environment environment offset, but this can
only work for an erased flash as far as I know.
env_sf_save always erases the environment before flashing. So your patch
effectively erases env twice before writing to it.
Yeah, you're right, it was made under the false assumption that the erase
function actually should erase something ... ;-/
And erasing the flash part where the environment is stored should take
an environment sizes below sector size into account; the rest of the
environment sector could be used otherwise, i.e. CONFIG_ENV_SIZE <
CONFIG_ENV_SECT_SIZE.
Right, but typically we have a write granularity of one byte for SPI
flashes. So you can clear only the environment, and let enf_sf_save deal
with other data in the sector.
Correct.
So my patches are actually worthless ... interesting that Patrick came up with
his patches only right after my attempts to add that functionality, but not
discussing my approach.
I'd loved to make a small contribution to U-Boot, maybe I've more luck next
time ... ;-)
Best regards,
Harry
--Sean
Function env_sf_save() takes care of all of that, so does the
env_sf_erase() in my patch, Patrick's version of env_sf_erase() does
not.
(side note: using more than a flash sector for environment and sharing
the last one with different data isn't handled at all at the moment,
probably because it was never needed)
Best regards,
Harry
Thanks.
--Sean
Best regards,
Harry
On 02.02.21 09:21, Harry Waschkeit wrote:
Instead of implementing redundant environments in two very similar
functions env_sf_save(), handle redundancy in one function, placing the
few differences in appropriate pre-compiler sections depending on config
option CONFIG_ENV_OFFSET_REDUND.
Additionally, several checkpatch complaints were addressed.
This patch is in preparation for adding support for env erase.
Signed-off-by: Harry Waschkeit
Reviewed-by: Stefan Roese
---
Change in v3:
- no change in patch, only added "reviewed-by" to commit log
Change in v2:
- remove one more #ifdef, instead take advantage of compiler attribute
__maybe_unused for one variable used only in case of redundant
environments
env/sf.c | 130 ++-
1 file changed, 41 insertions(+), 89 deletions(-)
diff --git a/env/sf.c b/env/sf.c
index 937778aa37..199114fd3b 100644
--- a/env/sf.c
+++ b/env/sf.c
@@ -66,13 +66,14 @@ static int setup_flash_device(void)
return 0;
}
-#if defined(CONFIG_ENV_OFFSET_REDUND)
static int env_sf_save(void)
{
env_t env_new;
- char *saved_buffer = NULL, flag = ENV_REDUND_OBSOLETE;
+ char *saved_buffer = NULL;
u32 saved_size, saved_offset, sector;
+ ulong offset;
int ret;
+ __maybe_unused char flag = ENV_REDUND_OBSOLETE;
ret = setup_flash_device();
if (ret)
@@ -81,27 +82,33 @@ static int env_sf_save(void)
ret = env_export(&env_new);
if (ret)
return -EIO;
- env_new.flags = ENV_REDUND_ACTIVE;
- if (gd->env_valid == ENV_VALID) {
- env_new_offset = CONFIG_ENV_OFFSET_REDUND;
- env_offset = CONFIG_ENV_OFFSET;
- } else {
- env_new_offset = CONFIG_ENV_OFFSET;
- env_offset = CONFIG_ENV_OFFSET_REDUND;
- }
+#if CONFIG_IS_ENABLED(SYS_REDUNDAND_ENVIRONMENT)
+ env_new.flags = ENV_REDUND_ACTIVE;
+
+ if (gd->
RE: [EXTERNAL] Re: U-Boot ECDSA Implementation Question
On 2/22/21 6:33 PM, Alex G. wrote: > Verification on the target would be great. My implementation is > platform-specific. It would make sense to also have a software implementation > of ECDSA (as we do for RSA). Once that is in place, it opens the gates for > unit-testing. Currently, we're only testing the host signing part, but it > would be awesome to have a test for ECDSA_UCLASS. That sounds good! It aligns with our though process on the topic too. > I think getting started on a software implementation of ECDSA_UCLASS would be > most beneficial. Is that something you'd like to take on? Yessir, happy to get that started! I've been looking at the Linux and OpenSSL implementations, turns out Linux's ECRDSA is slightly different than what OpenSSL uses so I'm going ahead with isolating the OpenSSL ECDSA implementation right now and will fit it into a UCLASS after. My intuition is this will align the best with your implementation, though if you have different thoughts please let me know. CC'd our @linux.microsoft.com emails, will be using those from now on. All the best, Tim -Original Message- From: Alex G. Sent: February 22, 2021 6:33 PM To: Tim Romanski ; Simon Glass Cc: u-boot@lists.denx.de; Deskin Miller ; Dylan D'Silva Subject: Re: [EXTERNAL] Re: U-Boot ECDSA Implementation Question On 2/10/21 1:45 PM, Tim Romanski wrote: > Hi Alex, > > Thanks for the context! What are your plans for upstreaming your ECDSA > signing implementation? I expect that the ECDSA signing series will get merged soon. > I've currently dedicated the next four weeks to getting signing+verification > implemented, so if you'd like a helping hand either with any leftover signing > work or to get verification started I'm happy to collaborate. Verification on the target would be great. My implementation is platform-specific. It would make sense to also have a software implementation of ECDSA (as we do for RSA). Once that is in place, it opens the gates for unit-testing. Currently, we're only testing the host signing part, but it would be awesome to have a test for ECDSA_UCLASS. I think getting started on a software implementation of ECDSA_UCLASS would be most beneficial. Is that something you'd like to take on? Alex > > All the best, > Tim > > -Original Message- > From: Alex G. > Sent: February 5, 2021 11:09 AM > To: Simon Glass ; Tim Romanski > > Cc: u-boot@lists.denx.de; Deskin Miller ; Dylan > D'Silva > Subject: [EXTERNAL] Re: U-Boot ECDSA Implementation Question > > Hi Tim, > > On 2/5/21 8:35 AM, Simon Glass wrote: >>> I'm a current intern at Microsoft, and one of my priorities is to enable >>> ECDSA for U-Boot image signing/verification. Simon mentioned someone is >>> already working on ECC, it would be great to get synced up with related >>> progress. For signing, I will likely replicate the existing approach of >>> using the openssl library. I'm aware that signing happens on a host machine >>> and verification happens during boot, which implies verification should >>> have a custom implementation to avoid the openssl overhead in the U-Boot >>> binary. My thoughts are to copy an ECC verification implementation from a >>> well-tested widely-used open source project. I was wondering, is U-Boot's >>> current RSA verification copied from another project? If so, how are >>> security patches between the two copies of code usually handled? I'm >>> thinking of deriving from the ECDSA implementation currently in the Linux >>> kernel, though I'd also appreciate suggestions if there's a better/more >>> widely tested & used implementation. >> > > [snip] >> >> Alexandru Gagniuc, on cc, has been looking at implementing the >> signing side of this recently and has sent some patches that you >> could look at. > > I hope I can save you some effort on the signing side. Generally, you > have two types of signed images. The first is the signed bootloader > (BL2 or FSBL in ARM terms). The other one is the signed Flattened > Image Tree > (FIT) that we use in u-boot. The first one is vendor-specific, so you'd > usually use vendor tools or write your own. We use mkimage to deal with the > latter. > > I've implemented the signing part [1] for mkimage. mkimage has the ability to > use hardware signing via the PKCS11 engine of openssl, which I did not > implement. You can read more about it here [3]. > > The verification part is still being defined [4][5]. The idea is to define a > UCLASS which abstracts the underlying implementation. For RSA, it's defined > here [6]. > > My goal with ECDSA verification was to use the ROM API of the STM32MP1. > This meant I don't have to write a software implementation of ECDSA. > This would be useful in two ways. It would enable ECDSA verification on > devices that don't support it in hardware, and would also allow us to add > some unit tests for ECDSA. > > I suspect what you could do from here, is try to build my branch with ECDS
Re: Pull request: u-boot-imx u-boot-imx-20210003
On Wed, Mar 03, 2021 at 03:20:43PM +0100, Stefano Babic wrote: > Hi Tom, > > please pull from u-boot-imx, thanks ! > > > The following changes since commit 08cca188c120b8337600091c94dc0e211cd03e10: > > Merge https://gitlab.denx.de/u-boot/custodians/u-boot-usb (2021-02-26 > 15:11:08 -0500) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git > tags/u-boot-imx-20210303 > > for you to fetch changes up to 03bf8436a3a5b19ff4ae23868dd479acc050ff08: > > board: gateworks: imx8mm: Add Gateworks Venice board support (2021-03-03 > 14:15:02 +0100) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/4] nds32: Remove dead reset_cpu() implementation
On Tue, Dec 15, 2020 at 04:47:49PM +0100, Harald Seiler wrote: > nds32 is one of the only architectures which still have a reset_cpu() > implementation that makes use of the `addr` parameter. The rest of > U-Boot now ignores it and passes 0 everywhere. It turns out that even > here, reset_cpu() is no longer referenced anywhere; reset is either not > implemented (e.g. ae3xx) or realized using a WDT (e.g. ag101). > > Remove this left-over implementation in preparation for the removal of > the `addr` parameter in the entire tree. > > Cc: Rick Chen > Signed-off-by: Harald Seiler > Reviewed-by: Simon Glass > Reviewed-by: Rick Chen Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/4] board: ns3: Remove superfluous reset logic
On Tue, Dec 15, 2020 at 04:47:50PM +0100, Harald Seiler wrote:
> The current implementation of reset_cpu() in the ns3 board code does not
> archieve what it is supposed to (according to the comments), due to
> a number of reasons:
>
> 1. The argument to reset_cpu() is _not_ actually passed from the
> `reset` command, but is set to 0 in all call-sites (in this
> specific case, see arch/arm/lib/reset.c). Thus, performing
> different kinds of resets based on its value will not work as
> expected.
>
> 2. Contrary to its documentation, the passed argument is not
> interpreted, but a static `L3_RESET` define is used. The other
> comment properly notes that this will always perform a L3 reset,
> though.
>
> 3. The "parsing" of the static `L3_RESET` value is not even using the
> upper and lower nibble as stated in the comment, but uses the last
> two decimal digits of the value.
>
> This is currently one of the only implementations left in U-Boot, which
> make "use" of the value passed to reset_cpu(). As this is done under
> false assumption (the value does not have any meaning anymore), it makes
> sense to bring it into line with the rest and start ignoring the
> parameter.
>
> This is a preparation for removal of the reset_cpu() parameter across
> the entire tree in a later patch.
>
> Fixes: b5a152e7ca0b ("board: ns3: default reset type to L3")
> Cc: Bharat Gooty
> Cc: Rayagonda Kokatanur
> Signed-off-by: Harald Seiler
> Reviewed-by: Simon Glass
(Er, 1/4 had the wrong branch ...)
Applied to u-boot/next, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 3/4] Revert "lpc32xx: cpu: add support for soft reset"
On Tue, Dec 15, 2020 at 04:47:51PM +0100, Harald Seiler wrote:
> This reverts commit 576007aec9a4a5f4f3dd1f690fb26a8c05ceb75f.
>
> The paramter passed to reset_cpu() no longer holds a meaning as all
> call-sites now pass the value 0. Thus, branching on it is essentially
> dead code and will just confuse future readers.
>
> Revert soft-reset support and just always perform a hard-reset for now.
> This is a preparation for removal of the reset_cpu() parameter across
> the entire tree in a later patch.
>
> Fixes: 576007aec9a4 ("lpc32xx: cpu: add support for soft reset")
> Cc: Sylvain Lemieux
> Signed-off-by: Harald Seiler
> Signed-off-by: Harald Seiler
Applied to u-boot/next, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 4/4] reset: Remove addr parameter from reset_cpu()
On Tue, Dec 15, 2020 at 04:47:52PM +0100, Harald Seiler wrote:
> Historically, the reset_cpu() function had an `addr` parameter which was
> meant to pass in an address of the reset vector location, where the CPU
> should reset to. This feature is no longer used anywhere in U-Boot as
> all reset_cpu() implementations now ignore the passed value. Generic
> code has been added which always calls reset_cpu() with `0` which means
> this feature can no longer be used easily anyway.
>
> Over time, many implementations seem to have "misunderstood" the
> existence of this parameter as a way to customize/parameterize the reset
> (e.g. COLD vs WARM resets). As this is not properly supported, the
> code will almost always not do what it is intended to (because all
> call-sites just call reset_cpu() with 0).
>
> To avoid confusion and to clean up the codebase from unused left-overs
> of the past, remove the `addr` parameter entirely. Code which intends
> to support different kinds of resets should be rewritten as a sysreset
> driver instead.
>
> This transformation was done with the following coccinelle patch:
>
> @@
> expression argvalue;
> @@
> - reset_cpu(argvalue)
> + reset_cpu()
>
> @@
> identifier argname;
> type argtype;
> @@
> - reset_cpu(argtype argname)
> + reset_cpu(void)
> { ... }
>
> Signed-off-by: Harald Seiler
> Reviewed-by: Simon Glass
Applied to u-boot/next, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 1/8] stm32mp: update MMU config before the relocation
On Fri, Feb 05, 2021 at 01:53:32PM +0100, Patrick Delaunay wrote: > Mark the top of ram, used for relocated U-Boot as a normal memory > (cacheable and executable) to avoid permission access issue when > U-Boot jumps to this relocated code. > > When MMU is activated in pre-reloc stage; only the beginning of > DDR is marked executable. > > This patch avoids access issue when DACR is correctly managed. > > Signed-off-by: Patrick Delaunay Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/8] stm32mp: update the mmu configuration for SPL and prereloc
On Fri, Feb 05, 2021 at 01:53:33PM +0100, Patrick Delaunay wrote: > Overidde the weak function dram_bank_mmu_setup() to set the DDR > (preloc case) or the SYSRAM (in SPL case) executable before to enable > the MMU and configure DACR. > > This weak function is called in dcache_enable/mmu_setup. > > This patchs avoids a permission access issue when the DDR is marked > executable (by calling mmu_set_region_dcache_behaviour with > DCACHE_DEFAULT_OPTION) after MMU setup and domain access permission > activation with DACR in dcache_enable. > > Signed-off-by: Patrick Delaunay Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 4/8] arm: cosmetic: align TTB_SECT define value
On Fri, Feb 05, 2021 at 01:53:35PM +0100, Patrick Delaunay wrote: > Align TTB_SECT define value with previous value. > > Signed-off-by: Patrick Delaunay Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 5/8] arm: cp15: update DACR value to activate access control
On Fri, Feb 05, 2021 at 01:53:36PM +0100, Patrick Delaunay wrote:
> Update the initial value of Domain Access Control Register (DACR)
> and set by default the access permission to client (DACR_Dn_CLIENT = 1U)
> for each of the 16 domains and no more to all-supervisor
> (DACR_Dn_MANAGER = 3U).
>
> This patch allows to activate the domain checking in MMU against the
> permission bits in the translation tables and avoids prefetching issue
> on ARMv7 [1].
>
> Today it was already done for OMAP2 architecture
> ./arch/arm/mach-omap2/omap-cache.c::arm_init_domains
> introduced by commit de63ac278cba ("ARM: mmu: Set domain permissions
> to client access") which fixes lot of speculative prefetch aborts seen
> on OMAP5 secure devices.
>
> [1]
> https://developer.arm.com/documentation/ddi0406/b/System-Level-Architecture/Virtual-Memory-System-Architecture--VMSA-/Memory-access-control/The-Execute-Never--XN--attribute-and-instruction-prefetching
>
> Signed-off-by: Patrick Delaunay
> Reported-by: Ard Biesheuvel
> Signed-off-by: Patrick Delaunay
Applied to u-boot/next, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 3/8] arm: remove TTB_SECT_XN_MASK in DCACHE_WRITETHROUGH
On Fri, Feb 05, 2021 at 01:53:34PM +0100, Patrick Delaunay wrote: > The normal memory (other that DCACHE_OFF) should be executable by default, > only the device memory (DCACHE_OFF) used for peripheral access should have > the bit execute never (TTB_SECT_XN_MASK). > > Signed-off-by: Patrick Delaunay Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 6/8] arm: omap2: remove arm_init_domains
On Fri, Feb 05, 2021 at 01:53:37PM +0100, Patrick Delaunay wrote: > Remove the arm_init_domains and the DACR update, as it is now done > in ARMv7 CP15 level. > > Signed-off-by: Patrick Delaunay Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 7/8] arm: cp15: remove weak function arm_init_domains
On Fri, Feb 05, 2021 at 01:53:38PM +0100, Patrick Delaunay wrote: > Remove the unused weak function arm_init_domains used to change the > DACR value. > > Signed-off-by: Patrick Delaunay Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 8/8] arm: remove set_dacr/get_dacr functions
On Fri, Feb 05, 2021 at 01:53:39PM +0100, Patrick Delaunay wrote: > Remove the unused function set_dacr/get_dacr > > Serie-cc: Ard Biesheuvel > Serie-cc: R Sricharan > Signed-off-by: Patrick Delaunay Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 1/9] spl: Drop duplicate 'Jumping to U-Boot' message
On Sat, Feb 06, 2021 at 09:57:27AM -0700, Simon Glass wrote: > This is printed twice but we only need one message, since there is very > little processing in between them. Drop the second one, since all branches > of the switch() already have output. Update the U-Boot message to include > the phase being jumped to. > > Signed-off-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 2/9] binman: Indicate how to make binman verbose
On Sat, Feb 06, 2021 at 09:57:28AM -0700, Simon Glass wrote: > Add notes about how to make binman produce verbose logging when building. > > Add a comment on how to do this. > > Signed-off-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 3/9] doc: describe the md command
On Sat, Feb 06, 2021 at 09:57:29AM -0700, Simon Glass wrote: > Provide a man-page for the md command. > > Signed-off-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 4/9] doc: Add a note about producing 'md.b' output using hexdump
On Sat, Feb 06, 2021 at 09:57:30AM -0700, Simon Glass wrote: > Comparing a hex dump on the U-Boot command line with the contents of a > file on the host system is fairly easy and convenient to do manually if > it is small. But the format used hexdump by default differs from that > shown by U-Boot. Add a note about how to make them the same. > > (For large dumps, writing the data to the network with tftpput, or to a > USB stick with ext4save is easiest.) > > Signed-off-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 5/9] s5p4418_nanopi2: Drop dead code
On Sat, Feb 06, 2021 at 09:57:31AM -0700, Simon Glass wrote: > This code is still using the old command typedef. It was not noticed since > this file is not currently built. It is using a non-existent option in the > Makefile. > > Drop this file since it is not needed for correct operation. > > Signed-off-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 6/9] sandbox: Add os_realloc()
On Sat, Feb 06, 2021 at 09:57:32AM -0700, Simon Glass wrote: > We provide os_malloc() and os_free() but not os_realloc(). Add this, > following the usual semantics. Also update os_malloc() to behave correctly > when passed a zero size. > > Signed-off-by: Simon Glass > Reviewed-by: Heinrich Schuchardt Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 7/9] sandbox: Avoid using malloc() for system state
On Sat, Feb 06, 2021 at 09:57:33AM -0700, Simon Glass wrote: > This state is not accessible to the running U-Boot but at present it is > allocated in the emulated SDRAM. This doesn't seem very useful. Adjust > it to allocate from the OS instead. > > The RAM buffer is currently not freed, but should be, so add that into > state_uninit(). Update the comment for os_free() to indicate that NULL is > a valid parameter value. > > Note that the strdup() in spl_board_load_image() is changed as well, since > strdup() allocates memory in the RAM buffer. > > Signed-off-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 8/9] sandbox: Write out bloblist when exiting
On Sat, Feb 06, 2021 at 09:57:34AM -0700, Simon Glass wrote: > Sandbox provides a way to write out its emulated memory on exit. This > makes it possible to pass a bloblist from one phase (e.g. SPL) to the > next. > > However the bloblist is not closed off, so the checksum is generally > invalid. Fix this by finishing up the bloblist before writing the memory > file. > > Signed-off-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 9/9] bootm: Fix duplicate debugging in bootm_process_cmdline()
On Sat, Feb 06, 2021 at 09:57:35AM -0700, Simon Glass wrote: > These two returns use the same string so are not distinguishable with > LOG_ERROR_RETURN. Fix it. > > Signed-off-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 03/11] tpm: Add debugging of request in tpm_sendrecv_command()
On Sat, Feb 06, 2021 at 02:23:34PM -0700, Simon Glass wrote: > The response is shown but not the request. Update the code to show both > if debugging is enabled. > > Use a 'uint' type for size so it matches the register-word size on both > 32- and 64-bit machines. > > Signed-off-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 01/11] tpm: Don't include cr50 in TPL/SPL
On Sat, Feb 06, 2021 at 02:23:32PM -0700, Simon Glass wrote: > At present the security chip is not used in these U-Boot phases. Update > the Makefile to exclude it. > > Fix a few logging statements while we are here. > > Signed-off-by: Simon Glass > Reviewed-by: Ilias Apalodimas Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 04/11] tpm: Add an API that can support v1.2 and v2
On Sat, Feb 06, 2021 at 02:23:35PM -0700, Simon Glass wrote: > There are two different TPM standards. U-Boot supports both but each has > its own set of functions. We really need a single TPM API that can call > one or the other. This is not always possible as there are some > differences between the two standards, but it is mostly possible. > > Add an API to handle this. So far it is not plumbed into the build and > only supports TPMv1. > > Signed-off-by: Simon Glass > Acked-by: Ilias Apalodimas Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 02/11] tpm: Use logging in the uclass
On Sat, Feb 06, 2021 at 02:23:33PM -0700, Simon Glass wrote: > Update this to use log_debug() instead of the old debug(). > > Signed-off-by: Simon Glass > Reviewed-by: Ilias Apalodimas Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 05/11] tpm: Switch TPMv1 over to use the new API
On Sat, Feb 06, 2021 at 02:23:36PM -0700, Simon Glass wrote: > Take over the plain 'tpm_...' functions for use by the new TPM API. Rename > all the TPMv1 functions so they are called from the API. > > Update the TPMv1 functions so that they are called from the API. Change > existing users to use the tpm1_ prefix so they don't need to go through > the API, which might introduce uncertainty. > > Signed-off-by: Simon Glass > Acked-by: Ilias Apalodimas Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 06/11] tpm: Add a basic API implementation for TPMv2
On Sat, Feb 06, 2021 at 02:23:37PM -0700, Simon Glass wrote: > Add support for TPMv2 versions of API functions. So far this is not > complete as the standard is quite large, but it implements everything > currently available for TPMv2 in U-Boot. > > Signed-off-by: Simon Glass > Acked-by: Ilias Apalodimas Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 07/11] tpm: Reduce duplication in a few functions
On Sat, Feb 06, 2021 at 02:23:38PM -0700, Simon Glass wrote: > Update tpm2_clear() and tpm2_pcr_extend() so that the command size > is not repeated twice. Add a small comment to the latter. > > Signed-off-by: Simon Glass > Reviewed-by: Ilias Apalodimas Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 08/11] tpm: Add an implementation of define_space
On Sat, Feb 06, 2021 at 02:23:39PM -0700, Simon Glass wrote: > Add support for this so that the TPM can be set up for use with > Chromium OS verified boot. > > Signed-off-by: Simon Glass > Acked-by: Ilias Apalodimas Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 09/11] tpm: Add TPM2 support for read/write values
On Sat, Feb 06, 2021 at 02:23:40PM -0700, Simon Glass wrote: > Implement this API function for TPM2. > > Signed-off-by: Simon Glass > Acked-by: Ilias Apalodimas Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 10/11] tpm: Add TPM2 support for write_lock
On Sat, Feb 06, 2021 at 02:23:41PM -0700, Simon Glass wrote: > Implement this API function for TPM2. > > Signed-off-by: Simon Glass > Acked-by: Ilias Apalodimas Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 11/11] tpm: Allow disabling platform hierarchy with TPM2
On Sat, Feb 06, 2021 at 02:23:42PM -0700, Simon Glass wrote: > With TPM2 we don't actually lock the TPM once verified boot is finished. > Instead we disable the platform hierarchy which serves the same purpose. > Add an implementation of this so we can safely boot into the kernel. > > Signed-off-by: Simon Glass > Acked-by: Ilias Apalodimas Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 00/41] test: Refactor tests to have a single test runner
On Wed, Feb 03, 2021 at 05:44:06AM -0700, Simon Glass wrote: > At present U-Boot has two broad sets of tests in the C code: driver model > tests which do a lot of pre-/post-init and command tests which do not. > > This separation makes it slightly harder to write a test, since there are > two different test-state structures and different rules for running the > two different test types. At present these rules are determined by where > the test is (actually its prefix). > > All unit tests can be run from the command line with the 'ut' command. > Since SPL does not have commands, it currently calls the test runner > directly and offers no control of which tests are run. > > This seems like a good time to refactor the tests into a unified test > runner, allowing U-Boot proper and SPL to use the same path, perhaps with > some different conditions along the way. > > This series sets up a unified runner called ut_run_list(), which runs a > set of tests from a linker_list. Driver model tests are distinguished by > a new UT_TESTF_DM flag so that the necessary init and cleanup can still > be done. > > The runner is modified to support running SPL tests that are not solely > for driver model. An example test for FIT loading is added as a > demonstration. > > In addition, some documentation is added to explain how to write tests. > > This series is available at u-boot-dm/test-working > > Changes in v3: > - Add new patch to re-enable test_ofplatdata > - Reword the SPL tests section for clarity > - Use test_set_state() throughout test-main.c instead of direct assignment > - Update the pytest collector as well > > Changes in v2: > - Use correct rst format for 'Ad-hoc tests' section > - Expand docs on how each type of test is marked > - Put the docs in tests_sandbox since it is more related to sandbox > - Put in a mention of tests_sandbox in the main testing docs > - Add a note that SPL tests can in fact be run individualy > - Document how to run all C tests with 'ut all' > - Fix 'get list' typo > - Fix conditions so non-DM SPL tests are actually run > - Allow for prefix to be NULL, to match function comment > - Add new patches to cover running an SPL test There was a small problem applying one or two of these patches that I fixed up. But then when testing locally (Ubuntu 18.04, but virtualenv setup and populated with test/py/requirements.txt) like 200 tests failed to run for Sandbox. Please check this and that CI runs. -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 00/41] test: Refactor tests to have a single test runner
On Wed, Mar 03, 2021 at 02:37:51PM -0500, Tom Rini wrote: > On Wed, Feb 03, 2021 at 05:44:06AM -0700, Simon Glass wrote: > > > At present U-Boot has two broad sets of tests in the C code: driver model > > tests which do a lot of pre-/post-init and command tests which do not. > > > > This separation makes it slightly harder to write a test, since there are > > two different test-state structures and different rules for running the > > two different test types. At present these rules are determined by where > > the test is (actually its prefix). > > > > All unit tests can be run from the command line with the 'ut' command. > > Since SPL does not have commands, it currently calls the test runner > > directly and offers no control of which tests are run. > > > > This seems like a good time to refactor the tests into a unified test > > runner, allowing U-Boot proper and SPL to use the same path, perhaps with > > some different conditions along the way. > > > > This series sets up a unified runner called ut_run_list(), which runs a > > set of tests from a linker_list. Driver model tests are distinguished by > > a new UT_TESTF_DM flag so that the necessary init and cleanup can still > > be done. > > > > The runner is modified to support running SPL tests that are not solely > > for driver model. An example test for FIT loading is added as a > > demonstration. > > > > In addition, some documentation is added to explain how to write tests. > > > > This series is available at u-boot-dm/test-working > > > > Changes in v3: > > - Add new patch to re-enable test_ofplatdata > > - Reword the SPL tests section for clarity > > - Use test_set_state() throughout test-main.c instead of direct assignment > > - Update the pytest collector as well > > > > Changes in v2: > > - Use correct rst format for 'Ad-hoc tests' section > > - Expand docs on how each type of test is marked > > - Put the docs in tests_sandbox since it is more related to sandbox > > - Put in a mention of tests_sandbox in the main testing docs > > - Add a note that SPL tests can in fact be run individualy > > - Document how to run all C tests with 'ut all' > > - Fix 'get list' typo > > - Fix conditions so non-DM SPL tests are actually run > > - Allow for prefix to be NULL, to match function comment > > - Add new patches to cover running an SPL test > > There was a small problem applying one or two of these patches that I > fixed up. But then when testing locally (Ubuntu 18.04, but virtualenv > setup and populated with test/py/requirements.txt) like 200 tests failed > to run for Sandbox. Please check this and that CI runs. Er, something has gone odd for me locally, please disregard. -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 00/41] test: Refactor tests to have a single test runner
On Wed, Mar 03, 2021 at 03:18:15PM -0500, Tom Rini wrote: > On Wed, Mar 03, 2021 at 02:37:51PM -0500, Tom Rini wrote: > > On Wed, Feb 03, 2021 at 05:44:06AM -0700, Simon Glass wrote: > > > > > At present U-Boot has two broad sets of tests in the C code: driver model > > > tests which do a lot of pre-/post-init and command tests which do not. > > > > > > This separation makes it slightly harder to write a test, since there are > > > two different test-state structures and different rules for running the > > > two different test types. At present these rules are determined by where > > > the test is (actually its prefix). > > > > > > All unit tests can be run from the command line with the 'ut' command. > > > Since SPL does not have commands, it currently calls the test runner > > > directly and offers no control of which tests are run. > > > > > > This seems like a good time to refactor the tests into a unified test > > > runner, allowing U-Boot proper and SPL to use the same path, perhaps with > > > some different conditions along the way. > > > > > > This series sets up a unified runner called ut_run_list(), which runs a > > > set of tests from a linker_list. Driver model tests are distinguished by > > > a new UT_TESTF_DM flag so that the necessary init and cleanup can still > > > be done. > > > > > > The runner is modified to support running SPL tests that are not solely > > > for driver model. An example test for FIT loading is added as a > > > demonstration. > > > > > > In addition, some documentation is added to explain how to write tests. > > > > > > This series is available at u-boot-dm/test-working > > > > > > Changes in v3: > > > - Add new patch to re-enable test_ofplatdata > > > - Reword the SPL tests section for clarity > > > - Use test_set_state() throughout test-main.c instead of direct assignment > > > - Update the pytest collector as well > > > > > > Changes in v2: > > > - Use correct rst format for 'Ad-hoc tests' section > > > - Expand docs on how each type of test is marked > > > - Put the docs in tests_sandbox since it is more related to sandbox > > > - Put in a mention of tests_sandbox in the main testing docs > > > - Add a note that SPL tests can in fact be run individualy > > > - Document how to run all C tests with 'ut all' > > > - Fix 'get list' typo > > > - Fix conditions so non-DM SPL tests are actually run > > > - Allow for prefix to be NULL, to match function comment > > > - Add new patches to cover running an SPL test > > > > There was a small problem applying one or two of these patches that I > > fixed up. But then when testing locally (Ubuntu 18.04, but virtualenv > > setup and populated with test/py/requirements.txt) like 200 tests failed > > to run for Sandbox. Please check this and that CI runs. > > Er, something has gone odd for me locally, please disregard. Two problems! One, this series IS breaking tests for me. Fresh venv, ~260 tests fail to run. Two, I didn't notice a fail-to-build in my build+pytest script, so the binary from this really really failed with the current pytest scripts :) -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 05/16] gpio: Drop dm_gpio_set_dir()
On Thu, Feb 04, 2021 at 09:21:58PM -0700, Simon Glass wrote:
> This function is not used. Drop it.
>
> Signed-off-by: Simon Glass
>
> Reviewed-by: Patrick Delaunay
I'm dropping this patch as it seems to be an explicit break of:
commit 6befb51f349459c96ed64412070feda7472cf152
Author: Harm Berntsen
Date: Sun Nov 29 09:47:15 2020 +
i2c: i2c-gpio: Fix GPIO output
The dm_gpio_set_dir_flags function cannot be used to update the
configuration of a GPIO pin because it does a bitwise OR with the
existing flags. Looks like commit 788ea834124b ("gpio: add function
_dm_gpio_set_dir_flags") has introduced this behaviour and the i2c-gpio
driver has been broken since.
Signed-off-by: Harm Berntsen
CC: Heiko Schocher
CC: Patrick Delaunay
--
Tom
signature.asc
Description: PGP signature
Re: [RFC PATCH u-boot 00/12] U-Boot LTO (Sandbox + ARM Nokia RX-51)
On Wed, Mar 03, 2021 at 05:41:57PM +0100, Marek Behun wrote: > On Wed, 3 Mar 2021 11:11:59 -0500 > Tom Rini wrote: > > > On Wed, Mar 03, 2021 at 05:11:59AM +0100, Marek Behún wrote: > > > > > Hello, > > > > > > I have managed to add support for building U-Boot with LTO (with GCC) > > > in a rather sane way (in LOC changed). > > > > > > This series and its follows will also be available at > > > https://github.com/elkablo/u-boot branch lto. > > > > > > I have tested these builds on Turris Omnia, Turris MOX and on Nokia N900 > > > (via the test/nokia_rx51_test.sh script). For other tests I have created > > > a pull-request on github to trigger CI > > > (https://github.com/u-boot/u-boot/pull/57) > > > For some reason it is waiting now, maybe Azure is not working or > > > something. > > > > As we're on the free tier with Azure it sometimes just queues us up for > > a long time, this job finally started running recently. > > > > > My tests on Omnia and MOX show that U-Boot boots sucessfully, and basic > > > commands seem to work. But of course something broken due to LTO may be > > > found later. > > > > > > So for all of you that are interested and have an ARM board, please test > > > this on your boards by enabling CONFIG_LTO option. Also please report > > > code size reductions. (Chris Packham reports an error related to > > > jobserver, so if `make -jN` produces an error, please try without the > > > `-jN` flag.) > > > > > > I have only tested with gcc-10. There are still some warnings printed, > > > like: > > > bfd plugin: invalid symbol type found > > > but these don't seem to matter. I will look into this later. > > > > > > Here are some results by how much code size reduced. Note that SPL > > > binary seems to gain more code reduction (15.4 % on average) than main > > > binary (4.5 % on average). > > > > > > I guess this is because of how drivers are written. The optimizer cannot > > > know which code paths won't be used, since it does not see the device > > > tree. Maybe this could be somehow integrated with Simon's work on > > > OF_PLATDATA_INST in the future, to make the compiler optimize out unused > > > code paths in drivers by understanding the device tree. > > > > > > u-boot.bin u-boot-spl.bin > > > > > > clearfog4.34 % 19.0 KB13.55 % 16.8 KB > > > controlcenterdc4.79 % 24.2 KB16.27 % 21.9 KB > > >db-88f6820-amc4.23 % 25.0 KB16.17 % 22.9 KB > > > db-88f6820-gp4.42 % 22.1 KB17.00 % 23.8 KB > > > helios44.32 % 18.9 KB13.70 % 16.8 KB > > >nokia_rx516.11 % 16.5 KB > > >turris_mox4.17 % 31.8 KB > > > turris_omnia4.32 % 30.2 KB14.91 % 16.6 KB > > > x5303.93 % 30.0 KB16.26 % 23.4 KB > > > > > > Marek > > > > Thanks for starting on this! It's been on my list for a long time, > > especially since it does give overall better reduction than > > function/data-sections/discard. It does seem like clang fails to build > > with this series. One thing I want to try locally, and I'll fire off > > the results once I do it, is moving to LTO by default for ARM. > > > > Yes, it seems clang is the last thing I need to look at. I did not even > try, really, my first priority was gcc. I will look into this tomorrow. > > All in all I am happy with this since it seems to be running for > several different boards without issue. > > If you want to enable LTO by default for ARM, we probably need to > determine which gcc version should be minimal for this. Because older > gcc versions may have problems with LTO. What is the current minimal > version of gcc for U-Boot? So, as I start testing things locally with two additional changes (1. LTO by default 2. No ffunction/data-sections with LTO) we see: https://gist.github.com/trini/350ab850c42293563228b8d68a1bb89a as the detailed size reduction. This also shows that with LTO we want to turn off -ffunction-sections/etc as it's not useful now. > > Marek -- Tom signature.asc Description: PGP signature
Re: make O=directory parameter
On 26/2/21 11:58 pm, Tom Rini wrote:
On Fri, Feb 26, 2021 at 10:27:46PM +1100, Fred 1 wrote:
On 26/2/21 2:35 am, Tom Rini wrote:
On Thu, Feb 25, 2021 at 12:50:47PM +1100, Fred 1 wrote:
like in the linux kernel build
make O=builds/arm
builds the result to the specified output directory
is this supposed to work for uboot also ?
doesn't seem to work for me, i've fetched older tar files and same problem
maybe my environment?
fedora32
5.10.13-100.fc32.x86_64
GNU Make 4.2.1
the O= does mostly work on older uboot like from ~2010 though
thought i'd ask as debugging the make process is,well umm...horrible,
(i've inserted some extra debug print codes in gnu make (it self no code to
be praised about!
esp when so much open source depends on it!!)
so atm, a bit of a rabbit holeshould I persist?
Can you provide a sample failure? The last "make O=... fails" I saw was
because they were passing ARCH= which isn't valid for U-Boot and
specifically breaks if you're say building for an aarch64 platform as in
the linux kernel you would do ARCH=arm64 but it's all "arm" here.
Thanks!
so ok, i'v dropped using the ARCH=
still
All the configs i tried failed:
make O=builds/rpi2 rpi_2_defconfig
make O=builds/rpi2 mrproper <==tried this too
make O=builds/rpi2 -w -d V=1 CROSS_COMPILE=arm-none-eabi-
qemu_mips_defconfig
orangepi_zero_defconfig
qemu_arm_defconfig
Of course the builds all work just fine without O=, and results in the main
directory.
So this is not just a problem on my machine?, i guess everyone just uses it
like so ?
anyway i am sufficiently annoyed with it, i'll have a go at finding out
why..
I don't know what's going on with your local environment. For me, I
just now did:
make O=builds/rpi2 -w -d V=1 CROSS_COMPILE= rpi_2_defconfig all
and it completed. Perhaps you have something set in your environment?
It's hard to say without seeing your error message.
Thanks your reply, so that lead me to create a new user and try it. It
worked!
so ok i'm floored about that.
doing a diff with output of $set
the user where it worked has additional shell functions
make ()
{
.
}
make_target_extract_script ()
{
}
and missing
LD_LIBRARY_PATH
pyenv ()
{
}
_pyenv_virtualenv_hook ()
{
}
I had tried previously with $unset LD_LIBRARY_PATH
and didn't help
I don't know the origin or why one shell has the make() functionand
works and where/when the other has it removed
or whether that is the actual problem
Re: [PATCH] JFFS2: fix the reading address over nand's limit
Forgot to Cc the maintainer, doing it now, sorry for the spam.
Em seg, 2021-02-22 às 23:30 -0300, Wagner Popov dos Santos escreveu:
> Fixes address violation in functions read_nand_cached() and
> read_onenand_cached(). This happens because these functions
> try to read a fixed amount
> of data even when the offset+length
> is above the nand's limit.
>
> Signed-off-by: Wagner Popov dos Santos
> ---
> fs/jffs2/jffs2_1pass.c | 37 +++--
> 1 file changed, 27 insertions(+), 10 deletions(-)
>
> diff --git a/fs/jffs2/jffs2_1pass.c b/fs/jffs2/jffs2_1pass.c
> index a98745c50e..b39943671c 100644
> --- a/fs/jffs2/jffs2_1pass.c
> +++ b/fs/jffs2/jffs2_1pass.c
> @@ -180,6 +180,7 @@ static int read_nand_cached(u32 off, u32 size, u_char
> *buf)
> struct mtd_info *mtd;
> u32 bytes_read = 0;
> size_t retlen;
> + size_t toread;
> int cpy_bytes;
>
> mtd = get_nand_dev_by_index(id->num);
> @@ -187,8 +188,12 @@ static int read_nand_cached(u32 off, u32 size, u_char
> *buf)
> return -1;
>
> while (bytes_read < size) {
> + retlen = NAND_CACHE_SIZE;
> + if( nand_cache_off + retlen > mtd->size )
> + retlen = mtd->size - nand_cache_off;
> +
> if ((off + bytes_read < nand_cache_off) ||
> - (off + bytes_read >= nand_cache_off+NAND_CACHE_SIZE)) {
> + (off + bytes_read >= nand_cache_off + retlen)) {
> nand_cache_off = (off + bytes_read) & NAND_PAGE_MASK;
> if (!nand_cache) {
> /* This memory never gets freed but 'cause
> @@ -201,16 +206,20 @@ static int read_nand_cached(u32 off, u32 size, u_char
> *buf)
> }
> }
>
> - retlen = NAND_CACHE_SIZE;
> + toread = NAND_CACHE_SIZE;
> + if( nand_cache_off + toread > mtd->size )
> + toread = mtd->size - nand_cache_off;
> +
> + retlen = toread;
> if (nand_read(mtd, nand_cache_off,
> &retlen, nand_cache) < 0 ||
> - retlen != NAND_CACHE_SIZE) {
> + retlen != toread) {
> printf("read_nand_cached: error reading nand
> off %#x size %d bytes\n",
> - nand_cache_off,
> NAND_CACHE_SIZE);
> + nand_cache_off, toread);
> return -1;
> }
> }
> - cpy_bytes = nand_cache_off + NAND_CACHE_SIZE - (off +
> bytes_read);
> + cpy_bytes = nand_cache_off + retlen - (off + bytes_read);
> if (cpy_bytes > size - bytes_read)
> cpy_bytes = size - bytes_read;
> memcpy(buf + bytes_read,
> @@ -283,11 +292,16 @@ static int read_onenand_cached(u32 off, u32 size,
> u_char *buf)
> {
> u32 bytes_read = 0;
> size_t retlen;
> + size_t toread;
> int cpy_bytes;
>
> while (bytes_read < size) {
> + retlen = ONENAND_CACHE_SIZE;
> + if( onenand_cache_off + retlen > onenand_mtd.size )
> + retlen = onenand_mtd.size - onenand_cache_off;
> +
> if ((off + bytes_read < onenand_cache_off) ||
> - (off + bytes_read >= onenand_cache_off +
> ONENAND_CACHE_SIZE)) {
> + (off + bytes_read >= onenand_cache_off + retlen)) {
> onenand_cache_off = (off + bytes_read) &
> ONENAND_PAGE_MASK;
> if (!onenand_cache) {
> /* This memory never gets freed but 'cause
> @@ -300,16 +314,19 @@ static int read_onenand_cached(u32 off, u32 size,
> u_char *buf)
> }
> }
>
> - retlen = ONENAND_CACHE_SIZE;
> + toread = ONENAND_CACHE_SIZE;
> + if( onenand_cache_off + toread > onenand_mtd.size )
> + toread = onenand_mtd.size - onenand_cache_off;
> + retlen = toread;
> if (onenand_read(&onenand_mtd, onenand_cache_off,
> retlen,
> &retlen, onenand_cache) < 0 ||
> - retlen != ONENAND_CACHE_SIZE) {
> + retlen != toread) {
> printf("read_onenand_cached: error reading nand
> off %#x size %d bytes\n",
> - onenand_cache_off, ONENAND_CACHE_SIZE);
> + onenand_cache_off, toread);
> return -1;
> }
> }
> - cpy_bytes = onenand_cac
Re: [PATCH] JFFS2: fix jffs2 summary datacrc status uninitialized
Forgot to Cc the maintainer, doing it now, sorry for the spam. On ter, 2021-02-23 às 00:49 -0300, Wagner Popov dos Santos wrote: > The function jffs2_1pass_read_inode() was discarding the summary > inodes and dirent because the value in datacrc flag wasn't > initialized in function jffs2_sum_process_sum_data(). > > This fix initializes the status of all summary records to indicate > that the CRC needs to be verified when they are loaded. > > Before this fix, the behaviors produced by the undefined value of > datacrc was: > - Summary's registries were discarded when 'b->datacrc' is equal > as 'CRC_BAD'. > - Summary's registries were not checked when b->datacrc differs of > 'CRC_BAD' and 'CRC_UNKNOWN' > > So, almost all of the time the crc just isn't checked, and in some > cases the registries are discarded. > > Signed-off-by: Wagner Popov dos Santos > --- > fs/jffs2/jffs2_1pass.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/fs/jffs2/jffs2_1pass.c b/fs/jffs2/jffs2_1pass.c > index a98745c50e..c9eda54cdb 100644 > --- a/fs/jffs2/jffs2_1pass.c > +++ b/fs/jffs2/jffs2_1pass.c > @@ -1276,6 +1276,7 @@ static int jffs2_sum_process_sum_data(struct part_info > *part, uint32_t offset, > &spi->version); > b->ino = sum_get_unaligned32( > &spi->inode); > + b->datacrc = CRC_UNKNOWN; > } > > sp += JFFS2_SUMMARY_INODE_SIZE; > @@ -1297,6 +1298,7 @@ static int jffs2_sum_process_sum_data(struct part_info > *part, uint32_t offset, > &spd->version); > b->pino = sum_get_unaligned32( > &spd->pino); > + b->datacrc = CRC_UNKNOWN; > } > > sp += JFFS2_SUMMARY_DIRENT_SIZE(
Re: [RFC PATCH u-boot 05/12] binman: declare symbols externally visible
On Wed, Mar 03, 2021 at 05:12:04AM +0100, Marek Behún wrote:
> Use the `__visible` macro to declare binman symbols externally visible,
> so that when building with LTO the compiler does not optimize this data
> away.
>
> Signed-off-by: Marek Behún
> ---
> include/binman.h | 1 +
> include/binman_sym.h | 4 ++--
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/include/binman.h b/include/binman.h
> index 5958dfb448..e72e85d4b7 100644
> --- a/include/binman.h
> +++ b/include/binman.h
> @@ -9,6 +9,7 @@
> #ifndef _BINMAN_H_
> #define _BINMAN_H_
>
> +#include
> #include
>
> /**
> diff --git a/include/binman_sym.h b/include/binman_sym.h
> index 72e6765fe5..55421f5893 100644
> --- a/include/binman_sym.h
> +++ b/include/binman_sym.h
> @@ -33,7 +33,7 @@
> * @_prop_name: Property value to get from that entry (e.g. 'pos')
> */
> #define binman_sym_declare(_type, _entry_name, _prop_name) \
> - _type binman_symname(_entry_name, _prop_name) \
> + _type binman_symname(_entry_name, _prop_name) __visible \
> __attribute__((aligned(4), unused, section(".binman_sym")))
>
> /**
> @@ -58,7 +58,7 @@
> * @_prop_name: Property value to get from that entry (e.g. 'pos')
> */
> #define binman_sym_declare_optional(_type, _entry_name, _prop_name) \
> - _type binman_symname(_entry_name, _prop_name) \
> + _type binman_symname(_entry_name, _prop_name) __visible \
> __attribute__((aligned(4), weak, unused, \
> section(".binman_sym")))
I see failure to run test suites:
https://source.denx.de/u-boot/u-boot/-/jobs/232926
and adding to binman_sym.h leads to the same problem.
--
Tom
signature.asc
Description: PGP signature
Re: [RFC PATCH u-boot 00/12] U-Boot LTO (Sandbox + ARM Nokia RX-51)
On Wed, Mar 3, 2021 at 3:36 PM Tom Rini wrote:
>
> On Wed, Mar 03, 2021 at 05:41:57PM +0100, Marek Behun wrote:
> > On Wed, 3 Mar 2021 11:11:59 -0500
> > Tom Rini wrote:
> >
> > > On Wed, Mar 03, 2021 at 05:11:59AM +0100, Marek Behún wrote:
> > >
> > > > Hello,
> > > >
> > > > I have managed to add support for building U-Boot with LTO (with GCC)
> > > > in a rather sane way (in LOC changed).
> > > >
> > > > This series and its follows will also be available at
> > > > https://github.com/elkablo/u-boot branch lto.
> > > >
> > > > I have tested these builds on Turris Omnia, Turris MOX and on Nokia N900
> > > > (via the test/nokia_rx51_test.sh script). For other tests I have created
> > > > a pull-request on github to trigger CI
> > > > (https://github.com/u-boot/u-boot/pull/57)
> > > > For some reason it is waiting now, maybe Azure is not working or
> > > > something.
> > >
> > > As we're on the free tier with Azure it sometimes just queues us up for
> > > a long time, this job finally started running recently.
> > >
> > > > My tests on Omnia and MOX show that U-Boot boots sucessfully, and basic
> > > > commands seem to work. But of course something broken due to LTO may be
> > > > found later.
> > > >
> > > > So for all of you that are interested and have an ARM board, please test
> > > > this on your boards by enabling CONFIG_LTO option. Also please report
> > > > code size reductions. (Chris Packham reports an error related to
> > > > jobserver, so if `make -jN` produces an error, please try without the
> > > > `-jN` flag.)
> > > >
> > > > I have only tested with gcc-10. There are still some warnings printed,
> > > > like:
> > > > bfd plugin: invalid symbol type found
> > > > but these don't seem to matter. I will look into this later.
> > > >
> > > > Here are some results by how much code size reduced. Note that SPL
> > > > binary seems to gain more code reduction (15.4 % on average) than main
> > > > binary (4.5 % on average).
> > > >
> > > > I guess this is because of how drivers are written. The optimizer cannot
> > > > know which code paths won't be used, since it does not see the device
> > > > tree. Maybe this could be somehow integrated with Simon's work on
> > > > OF_PLATDATA_INST in the future, to make the compiler optimize out unused
> > > > code paths in drivers by understanding the device tree.
> > > >
> > > > u-boot.bin u-boot-spl.bin
> > > >
> > > > clearfog4.34 % 19.0 KB13.55 % 16.8 KB
> > > > controlcenterdc4.79 % 24.2 KB16.27 % 21.9 KB
> > > >db-88f6820-amc4.23 % 25.0 KB16.17 % 22.9 KB
> > > > db-88f6820-gp4.42 % 22.1 KB17.00 % 23.8 KB
> > > > helios44.32 % 18.9 KB13.70 % 16.8 KB
> > > >nokia_rx516.11 % 16.5 KB
> > > >turris_mox4.17 % 31.8 KB
> > > > turris_omnia4.32 % 30.2 KB14.91 % 16.6 KB
> > > > x5303.93 % 30.0 KB16.26 % 23.4 KB
> > > >
> > > > Marek
> > >
> > > Thanks for starting on this! It's been on my list for a long time,
> > > especially since it does give overall better reduction than
> > > function/data-sections/discard. It does seem like clang fails to build
> > > with this series. One thing I want to try locally, and I'll fire off
> > > the results once I do it, is moving to LTO by default for ARM.
> > >
> >
> > Yes, it seems clang is the last thing I need to look at. I did not even
> > try, really, my first priority was gcc. I will look into this tomorrow.
> >
> > All in all I am happy with this since it seems to be running for
> > several different boards without issue.
> >
> > If you want to enable LTO by default for ARM, we probably need to
> > determine which gcc version should be minimal for this. Because older
> > gcc versions may have problems with LTO. What is the current minimal
> > version of gcc for U-Boot?
>
> So, as I start testing things locally with two additional changes (1.
> LTO by default 2. No ffunction/data-sections with LTO) we see:
> https://gist.github.com/trini/350ab850c42293563228b8d68a1bb89a
> as the detailed size reduction. This also shows that with LTO we want
> to turn off -ffunction-sections/etc as it's not useful now.
>
Does ARM vs Thumb matter? I ask because I tried to build the da850evm
which is fairly tight in SPL. It builds fine without LTO, but fails
with the following:
{standard input}: Assembler messages:
{standard input}:7744: Error: selected processor does not support `mrc
p15,0,r2,c1,c0,0' in Thumb mode
{standard input}:7784: Error: selected processor does not support `mcr
p15,0,r3,c1,c0,0' in Thumb mode
{standard input}:13192: Error: selected processor does not support
`mrc p15,0,r3,c1,c0,0' in Thumb mode
{standard input}:36752: Error: selected processor does not support
`mcr p15,0,r3,c7,c7,0' in Thumb mode
lto-wrapper: fatal error: arm-linux-gnueabihf-gcc returned 1 exit status
compilation terminated.
/usr/lib/gcc-cross/arm-linux-gnueabihf/9/../.
Re: [PATCH v3 04/38] ppc: qemu: Support non-identity PCI bus address
Hi Simon,
On Tue, Mar 2, 2021 at 2:34 PM Priyanka Jain (OSS)
wrote:
>
>
>
> >-Original Message-
> >From: Bin Meng
> >Sent: Monday, March 1, 2021 1:25 PM
> >To: Priyanka Jain (OSS)
> >Cc: Simon Glass ; Alexander Graf ; U-
> >Boot Mailing List ; Tom Rini
> >Subject: Re: [PATCH v3 04/38] ppc: qemu: Support non-identity PCI bus address
> >
> >Hi Priyanka,
> >
> >On Mon, Mar 1, 2021 at 3:15 PM Priyanka Jain (OSS)
> >
> >wrote:
> >>
> >>
> >>
> >> >-Original Message-
> >> >From: Bin Meng
> >> >Sent: Friday, February 26, 2021 7:46 PM
> >> >To: Priyanka Jain (OSS)
> >> >Cc: Simon Glass ; Alexander Graf ;
> >> >U- Boot Mailing List ; Tom Rini
> >> >
> >> >Subject: Re: [PATCH v3 04/38] ppc: qemu: Support non-identity PCI bus
> >> >address
> >> >
> >> >Hi Priyanka,
> >> >
> >> >On Fri, Feb 26, 2021 at 5:29 PM Priyanka Jain (OSS)
> >> >
> >> >wrote:
> >> >>
> >> >>
> >> >>
> >> >> >-Original Message-
> >> >> >From: U-Boot On Behalf Of Bin Meng
> >> >> >Sent: Thursday, February 25, 2021 2:52 PM
> >> >> >To: Simon Glass ; Alexander Graf
> >> >> >; Priyanka Jain
> >> >> >Cc: U-Boot Mailing List ; Tom Rini
> >> >> >
> >> >> >Subject: [PATCH v3 04/38] ppc: qemu: Support non-identity PCI bus
> >> >> >address
> >> >> >
> >> >> >When QEMU originally supported the ppce500 machine back in Jan
> >> >> >2014, it was created with a 1:1 mapping of PCI bus address. Things
> >> >> >seemed to change rapidly that in Nov 2014 with the following QEMU
> >commits:
> >> >> >
> >> >> >commit e6b4e5f4795b ("PPC: e500: Move CCSR and MMIO space to upper
> >> >> >end of address space")
> >> >> >
> >> >> >and
> >> >> >
> >> >> >commit cb3778a0455a ("PPC: e500 pci host: Add support for ATMUs")
> >> >> >
> >> >> >the PCI memory and IO physical address were moved to beyond 4 GiB,
> >> >> >but PCI bus address remained below 4 GiB, hence a non-identity
> >> >> >mapping was
> >> >created.
> >> >> >Unfortunately corresponding U-Boot updates were missed along with
> >> >> >the QEMU changes and the U-Boot QEMU ppce500 PCI support has been
> >> >> >broken
> >> >since then.
> >> >> >
> >> >> >This commit makes the PCI (non-DM version) work again.
> >> >> >
> >> >> >Signed-off-by: Bin Meng
> >> >> >---
> >> >> >
> >> >> >(no changes since v1)
> >> >> >
> >> >> > board/freescale/qemu-ppce500/qemu-ppce500.c | 29
> >> >> >++---
> >> >> >
> >> >> > 1 file changed, 14 insertions(+), 15 deletions(-)
> >> >> >
> >> >> >diff --git a/board/freescale/qemu-ppce500/qemu-ppce500.c
> >> >> >b/board/freescale/qemu-ppce500/qemu-ppce500.c
> >> >> >index aa5774f..1d68d30 100644
> >> >> >--- a/board/freescale/qemu-ppce500/qemu-ppce500.c
> >> >> >+++ b/board/freescale/qemu-ppce500/qemu-ppce500.c
> >> >> >@@ -85,20 +85,24 @@ int checkboard(void) }
> >> >> >
> >> >> > static int pci_map_region(void *fdt, int pci_node, int range_id,
> >> >> >-phys_size_t *ppaddr, pci_addr_t *pvaddr,
> >> >> >-pci_size_t *psize, ulong *pmap_addr)
> >> >> >+phys_addr_t *pbaddr, phys_size_t *ppaddr,
> >> >> >+pci_addr_t *pvaddr, pci_size_t *psize,
> >> >> >+ulong *pmap_addr)
> >> >> > {
> >> >> >- uint64_t addr;
> >> >> >+ uint64_t baddr;
> >> >> >+ uint64_t paddr;
> >> >> > uint64_t size;
> >> >> > ulong map_addr;
> >> >> > int r;
> >> >> >
> >> >> >- r = fdt_read_range(fdt, pci_node, range_id, NULL, &addr, &size);
> >> >> >+ r = fdt_read_range(fdt, pci_node, range_id, &baddr, &paddr,
> >> >> >+ &size);
> >> >> > if (r)
> >> >> > return r;
> >> >> >
> >> >> >+ if (pbaddr)
> >> >> >+ *pbaddr = baddr;
> >> >> > if (ppaddr)
> >> >> >- *ppaddr = addr;
> >> >> >+ *ppaddr = paddr;
> >> >> > if (psize)
> >> >> > *psize = size;
> >> >> >
> >> >> >@@ -115,7 +119,7 @@ static int pci_map_region(void *fdt, int
> >> >> >pci_node, int range_id,
> >> >> > return -1;
> >> >> >
> >> >> > /* Map virtual memory for range */
> >> >> >- assert(!tlb_map_range(map_addr, addr, size, TLB_MAP_IO));
> >> >> >+ assert(!tlb_map_range(map_addr, paddr, size, TLB_MAP_IO));
> >> >> > *pmap_addr = map_addr + size;
> >> >> >
> >> >> > if (pvaddr)
> >> >> >@@ -166,24 +170,19 @@ void pci_init_board(void)
> >> >> > pci_info.regs = fdt_translate_address(fdt,
> >> >> >pci_node, reg);
> >> >> >
> >> >> > /* Map MMIO range */
> >> >> >- r = pci_map_region(fdt, pci_node, 0,
> >> >> >&pci_info.mem_phys, NULL,
> >> >> >+ r = pci_map_region(fdt, pci_node, 0, &pci_info.mem_bus,
> >> >> >+ &pci_info.mem_phys, NULL,
> >> >> > &pci_info.mem_size, &map_addr);
> >> >> > if (r)
> >> >> > break;
> >> >> >
> >> >> > /* Map PIO range */
>
Re: u-boot on RPi4 32bit - issue after upgrading the firmware
Hi,
On 2/25/21 8:11 PM, Marek Szyprowski wrote:
> Hi Nicolas,
>
> On 25.02.2021 11:55, Nicolas Saenz Julienne wrote:
>> On Thu, 2021-02-25 at 11:43 +0100, Marek Szyprowski wrote:
>>> Recently I've upgraded a video core firmware on my RPi4 and I've noticed
>>> that u-boot in ARM 32bit mode stopped working properly or even randomly
>>> crashes. I've bisected the firmware releases and the issue appears for
>>> the first time in the commit 63b1922311 ("firmware: arm_loader: Update
>>> armstubs with those from PR 117 See:
>>> https://protect2.fireeye.com/v1/url?k=a201e8b0-fd9ad069-a20063ff-0cc47a3356b2-1ab72bd783ec5635&q=1&e=5f377675-c909-4cc4-a1d5-b740cbf6255e&u=https%3A%2F%2Fgithub.com%2Fraspberrypi%2Ftools%2Fpull%2F117";).
>> Just for confirmation,
>>> This issue can be easily observed as a failure of the xhci. See the
>>> attached log:
>>>
>>> Read start4x.elf bytes 2984808 hnd 0x06e2 sha256 d21bf9d3954fea04
>>> Read fixup4x.dat bytes 8432 hnd 0x06dd sha256 10d3b073ab232613
>>> 0x00a03111 0x 0x001f
>>> MEM GPU: 76 ARM: 948 TOTAL: 1024
>>> Starting start4x.elf @ 0xfec00200 partition 0
>>> PCI reset
>>> +
>>>
>>> MESS:00:00:04.800023:0: arasan: arasan_emmc_open
>>> MESS:00:00:04.975752:0: brfs: File read: /mfs/sd/config.txt
>>> MESS:00:00:04.979162:0: brfs: File read: 2153 bytes
>>> MESS:00:00:05.046081:0: brfs: File read: /mfs/sd/config.txt
>>> MESS:00:00:06.121174:0: gpioman: gpioman_get_pin_num: pin
>>> DISPLAY_DSI_PORT not defined
>>> MESS:00:00:06.128433:0: *** Restart logging
>>> MESS:00:00:06.129897:0: brfs: File read: 2153 bytes
>>> MESS:00:00:06.148533:0: hdmi: HDMI:hdmi_get_state is deprecated, use
>>> hdmi_get_display_state instead
>>> MESS:00:00:06.154474:0: HDMI0: hdmi_pixel_encoding: 3
>>> MESS:00:00:06.159948:0: HDMI1: hdmi_pixel_encoding: 3
>>> MESS:00:00:06.166901:0: dtb_file 'bcm2711-rpi-4-b.dtb'
>>> MESS:00:00:06.178359:0: brfs: File read: /mfs/sd/bcm2711-rpi-4-b.dtb
>>> MESS:00:00:06.181601:0: Loading 'bcm2711-rpi-4-b.dtb' to 0x100 size 0xc901
>>> MESS:00:00:06.201386:0: brfs: File read: 51457 bytes
>>> MESS:00:00:06.267975:0: brfs: File read: /mfs/sd/config.txt
>>> MESS:00:00:06.270915:0: dtparam: audio=on
>>> MESS:00:00:06.283974:0: brfs: File read: 2153 bytes
>>> MESS:00:00:06.286148:0: Failed to load overlay 'vc4-fkms-v3d'
>>> MESS:00:00:06.291378:0: brfs: File read: /mfs/sd/overlays/vc4-fkms-v3d.dtbo
>>> MESS:00:00:06.304096:0: Failed to open command line file 'cmdline.txt'
>>> MESS:00:00:07.484256:0: brfs: File read: /mfs/sd/u-boot.bin
>>> MESS:00:00:07.486726:0: Loading 'u-boot.bin' to 0x8000 size 0x84cf4
>>> MESS:00:00:07.492726:0: Device tree loaded to 0x2eff3100 (size 0xce24)
>>> MESS:00:00:07.500863:0: uart: Set PL011 baud rate to 103448.30 Hz
>>> MESS:00:00:07.508031:0: uart: Baud rate change done...
>>> MESS:00:00:07.510053:0:
>>>
>>> U-Boot 2021.04-rc2 (Feb 25 2021 - 11:21:44 +0100)
>> Can you try with today's master branch, I'm specially interested in seeing if
>> 56f1bcc4b7fb helps.
>
> I've checked the mentioned commit, sadly nothing changes:
>
> U-Boot 2021.04-rc2-00041-g56f1bcc4b7 (Feb 25 2021 - 12:05:07 +0100)
>
> DRAM: 948 MiB
> RPI 4 Model B (0xa03111)
> MMC: mmcnr@7e30: 1, emmc2@7e34: 0
> Loading Environment from FAT... OK
> In: serial
> Out: serial
> Err: serial
> Net: eth0: ethernet@7d58
> Hit any key to stop autoboot: 0
> U-Boot> pci enum
> PCIe BRCM: link up, 5.0 Gbps x1 (SSC)
> U-Boot> usb start
> starting USB...
> Bus xhci_pci: Host not halted after 16000 microseconds.
> probe failed, error -16
> No working controllers found
> U-Boot>
>
> I've checked that on two RPi4 boards (one with 1GB RAM and one with 8GB).
It seems that couldn't get hc_length from capbase.
us xhci_pci: XHCI-PCI init hccr ff80 and hcor ff80 hc_length 0
xhci_register: dev='xhci_pci', ctrl=3a3679c0, hccr=ff80, hcor=ff80
When i have compared with working and not, hc_length is different.
hc_length should be to set 0x20 when it's working fine.
I don't have the knowledge of USB..So it's taking too more time for debugging.
Could you share what i do to check more?
Best Regards,
Jaehoon Chung
>
> Best regards
>
Re: [PATCH 01/19] sunxi: video: select dw-hdmi in Kconfig, not Makefile
On Tue, 23 Feb 2021 21:46:13 +0100 Jernej Skrabec wrote: > Currently sunxi Makefile manually specifies full path to dw-hdmi common > code. However, that is not needed because it can be selected in Kconfig > instead. > > Select proper symbol in Kconfig and drop path from Makefile. Ah, indeed. Good catch! > Signed-off-by: Jernej Skrabec Reviewed-by: Andre Przywara Cheers, Andre > --- > arch/arm/mach-sunxi/Kconfig | 1 + > drivers/video/sunxi/Makefile | 2 +- > 2 files changed, 2 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig > index 0135575ca1eb..9149196b223e 100644 > --- a/arch/arm/mach-sunxi/Kconfig > +++ b/arch/arm/mach-sunxi/Kconfig > @@ -972,6 +972,7 @@ config VIDEO_DE2 > depends on SUNXI_DE2 > select DM_VIDEO > select DISPLAY > + select VIDEO_DW_HDMI > imply VIDEO_DT_SIMPLEFB > default y > ---help--- > diff --git a/drivers/video/sunxi/Makefile b/drivers/video/sunxi/Makefile > index 147e18799229..4321673312bf 100644 > --- a/drivers/video/sunxi/Makefile > +++ b/drivers/video/sunxi/Makefile > @@ -4,4 +4,4 @@ > # Wolfgang Denk, DENX Software Engineering, w...@denx.de. > > obj-$(CONFIG_VIDEO_SUNXI) += sunxi_display.o simplefb_common.o lcdc.o > tve_common.o ../videomodes.o > -obj-$(CONFIG_VIDEO_DE2) += sunxi_de2.o sunxi_dw_hdmi.o simplefb_common.o > lcdc.o ../dw_hdmi.o sunxi_lcd.o > +obj-$(CONFIG_VIDEO_DE2) += sunxi_de2.o sunxi_dw_hdmi.o simplefb_common.o > lcdc.o sunxi_lcd.o
Re: [PATCH 02/19] video: sunxi: Add mode_valid callback to sunxi_dw_hdmi
On Tue, 23 Feb 2021 21:46:14 +0100
Jernej Skrabec wrote:
> Currently driver accepts all resolution which won't work on 4k screens.
> Add validation callback which limits acceptable resolutions to 297 MHz.
Makes sense. Newer SoCs seem to support more, but apparently not
without further code to enable higher clock rates.
> Signed-off-by: Jernej Skrabec
Reviewed-by: Andre Przywara
Cheers,
Andre
> ---
> drivers/video/sunxi/sunxi_dw_hdmi.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/video/sunxi/sunxi_dw_hdmi.c
> b/drivers/video/sunxi/sunxi_dw_hdmi.c
> index 0b8cefc311ef..e3811a2ec15f 100644
> --- a/drivers/video/sunxi/sunxi_dw_hdmi.c
> +++ b/drivers/video/sunxi/sunxi_dw_hdmi.c
> @@ -305,6 +305,12 @@ static int sunxi_dw_hdmi_read_edid(struct udevice *dev,
> u8 *buf, int buf_size)
> return dw_hdmi_read_edid(&priv->hdmi, buf, buf_size);
> }
>
> +static bool sunxi_dw_hdmi_mode_valid(struct udevice *dev,
> + const struct display_timing *timing)
> +{
> + return timing->pixelclock.typ <= 29700;
> +}
> +
> static int sunxi_dw_hdmi_enable(struct udevice *dev, int panel_bpp,
> const struct display_timing *edid)
> {
> @@ -388,6 +394,7 @@ static int sunxi_dw_hdmi_probe(struct udevice *dev)
> static const struct dm_display_ops sunxi_dw_hdmi_ops = {
> .read_edid = sunxi_dw_hdmi_read_edid,
> .enable = sunxi_dw_hdmi_enable,
> + .mode_valid = sunxi_dw_hdmi_mode_valid,
> };
>
> U_BOOT_DRIVER(sunxi_dw_hdmi) = {
Re: [PATCH 03/19] common: edid: check for digital display earlier
On Tue, 23 Feb 2021 21:46:15 +0100
Jernej Skrabec wrote:
Hi,
> When searching for detailed timing in EDID, check for digital display
> earlier. There is no point parsing other parameters if this flag is not
> present.
Indeed we would exit anyway, so we should avoid unneeded work.
> Signed-off-by: Jernej Skrabec
Reviewed-by: Andre Przywara
Cheers,
Andre
> ---
> common/edid.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/common/edid.c b/common/edid.c
> index 553ab8fd01a1..1cb7177742e8 100644
> --- a/common/edid.c
> +++ b/common/edid.c
> @@ -185,6 +185,11 @@ int edid_get_timing_validate(u8 *buf, int buf_size,
> return -EINVAL;
> }
>
> + if (!EDID1_INFO_VIDEO_INPUT_DIGITAL(*edid)) {
> + debug("%s: Not a digital display\n", __func__);
> + return -ENOSYS;
> + }
> +
> if (!EDID1_INFO_FEATURE_PREFERRED_TIMING_MODE(*edid)) {
> debug("%s: No preferred timing\n", __func__);
> return -ENOENT;
> @@ -211,10 +216,6 @@ int edid_get_timing_validate(u8 *buf, int buf_size,
> if (!timing_done)
> return -EINVAL;
>
> - if (!EDID1_INFO_VIDEO_INPUT_DIGITAL(*edid)) {
> - debug("%s: Not a digital display\n", __func__);
> - return -ENOSYS;
> - }
> if (edid->version != 1 || edid->revision < 4) {
> debug("%s: EDID version %d.%d does not have required info\n",
> __func__, edid->version, edid->revision);
