Re: [PATCH] efi_loader: capsule: return a corret error code at find_boot_device()

[Heinrich Schuchardt]

On 4/20/21 3:03 AM, AKASHI Takahiro wrote:

In case of failure at efi_get_variable_int("BootOrder"), we should
skip examining boot option variables and return an appropriate error
code which is the one the function returned.

Fixes: CID 331153 Code maintainability issues  (UNUSED_VALUE)
Signed-off-by: AKASHI Takahiro 


Reviewed-by: Heinrich Schuchardt 


---
  lib/efi_loader/efi_capsule.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
index 691eda5e0d14..2d10f47bff24 100644
--- a/lib/efi_loader/efi_capsule.c
+++ b/lib/efi_loader/efi_capsule.c
@@ -685,7 +685,6 @@ skip:
efi_free_pool(boot_dev);
boot_dev = NULL;
}
-out:
if (boot_dev) {
u16 *path_str;

@@ -703,6 +702,7 @@ out:
} else {
ret = EFI_NOT_FOUND;
}
+out:
free(boot_order);

return ret;

Re: [PATCH v2 12/13] doc: qemu: arm64: Fix the documentation of capsule update

[Takahiro Akashi]

Heinrich, Sughosh,

On Mon, Apr 19, 2021 at 04:35:15AM +0200, Heinrich Schuchardt wrote:
> Am 19. April 2021 04:24:37 MESZ schrieb Masami Hiramatsu 
> :
> >Hi,
> >
> >2021年4月19日(月) 9:37 Takahiro Akashi :
> >>
> >> Sughosh,
> >>
> >> On Sun, Apr 18, 2021 at 01:37:58PM +0530, Sughosh Ganu wrote:
> >> > On Sat, 17 Apr 2021 at 23:51, Heinrich Schuchardt
> >
> >> > wrote:
> >> >
> >> > > On 4/17/21 1:39 AM, Masami Hiramatsu wrote:
> >> > > > Since the EDK2 GenerateCapsule script is out of date and it
> >> > > > doesn't generate the supported version capsule file, the
> >document
> >> > > > should refer the mkeficapsule in tools.
> >> > > >
> >> > > > Signed-off-by: Masami Hiramatsu 
> >> > > > ---
> >> > > >   doc/board/emulation/qemu_capsule_update.rst |   11
> >++-
> >> > > >   1 file changed, 2 insertions(+), 9 deletions(-)
> >> > > >
> >> > > > diff --git a/doc/board/emulation/qemu_capsule_update.rst
> >> > > b/doc/board/emulation/qemu_capsule_update.rst
> >> > > > index 9fec75f8f1..e2a9f0db71 100644
> >> > > > --- a/c
> >> > > > +++ b/doc/board/emulation/qemu_capsule_update.rst
> >> > > > @@ -39,16 +39,9 @@ In addition, the following config needs to
> >be
> >> > > disabled(QEMU ARM specific)::
> >> > > >
> >> > > >   CONFIG_TFABOOT
> >> > > >
> >> > > > -The capsule file can be generated by using the
> >GenerateCapsule.py
> >> > > > -script in EDKII::
> >> > > > -
> >> > > > -$ ./BaseTools/BinWrappers/PosixLike/GenerateCapsule -e -o
> >\
> >> > > > - --fw-version  --lsv  --guid
> >\
> >> > > > -e2bb9c06-70e9-4b14-97a3-5a7913176e3f --verbose
> >--update-image-index
> >> > > \
> >> > > > - --verbose 
> >> > > > +The capsule file can be generated by using the
> >tools/mkeficapsule::
> >> > > >
> >> > > > -The above is a wrapper script(GenerateCapsule) which
> >eventually calls
> >> > > > -the actual GenerateCapsule.py script.
> >> > > > +$ mkeficapsule --raw  --index 1
> >
> >> > >
> >> > > Thanks for the change.
> >> > >
> >> > > Could you, please, adjust the same in chapter "Enabling Capsule
> >> > > Authentication" below.
> >
> >So as Sughosh said, since currently mkeficapsule doesn't support
> >authentication,
> >I only changed it for the normal capsule update. Without this change,
> >the capsule
> >update just failed.
> >
> >
> >> > Currently, we do not have support for adding authentication header
> >to the
> >> > capsule. This is because I have been using the GenerateCapsule
> >script in
> >> > edk2 for generation of a capsule with authentication header. I
> >think adding
> >> > the signature to the capsule is easier when done through a python
> >script
> >> > rather than C code.
> >>
> >> Why do you think so?
> >> At a quick glance at the script, it internally uses openssl command
> >like:
> >> openssl smime -sign -binary -outform DER -md sha256 \
> >> -signer <...> -certfile <...>
> >> (See PayloadDescriptor.Encode in the script.)
> >>
> >> The output from the standard output is exactly what you want
> >> to use to build a capsule file, that is "AuthInfo".
> >> Then you can naturally extend mkeficapsule to insert this signature
> >> between the header and the image itself in a capsule file.
> >
> >Hmm, if it can be done by just calling openssl, I think it is easier
> >for me
> >to run the tools/mkeficapsule, because I don't need to build EDK2
> >for U-Boot.
> >
> >If GenerateCapsule becomes a standard implementation and
> >independent from the EDK2 project, from the interoperability point
> >of view, it is better to use that. But it is a part of EDK2 and the
> >GenerateCapsule seems out-of-date and not maintained well
> >(why doesn't it support the latest version yet??)
> 
> Sughosh told me that EDK II cannot create a signed capsule that is usable 
> with U-Boot due to an outdated header version used by EDK II.

I decided to add a signing feature to mkeficapsule, and actually
have finished the coding (half-a-day work). Yet I have to find some time
to debug the command as I have never tried capsule authentication.
(Hopefully Masami will help here.)

The syntax will look like:
  mkeficapsule -m  -P  -C 
-r  

-Takahiro Akashi

> It should be sufficient to describe the steps used by U-Boot's test script 
> here.
> 
> Best regards
> 
> Heinrich
> 
> >
> >Thank you,
> >
> >> Furthermore, I believe, it is fairly straightforward to add a native
> >> 'signing' feature to mkeficapsule if you use openssl library.
> >>
> >> -Takahiro Akashi
> >>
> >>
> >> > I am working on adding support for the latest version
> >> > of the EFI_FIRMWARE_MANAGEMENT_CAPSULE_IMAGE_HEADER in the
> >GenerateCapsule
> >> > script in edk2. Meanwhile, would it be possible to have support for
> >the
> >> > version 2 of this header in the capsule driver -- it is a minor
> >change and
> >> > I already have a patch for it. If you are fine, I can submit a
> >patch for
> >> > the same.
> >> >
> >> > -sughosh
> >> >
> >> >
> >> > >
> >> > > Best regards
> >> > >
> >> > > Heinrich
> >> > >
> >> >

Re: [scan-ad...@coverity.com: New Defects reported by Coverity Scan for Das U-Boot]

[Dario Binacchi]

Hi Tom,

> Il 19/04/2021 14:20 Tom Rini  ha scritto:
> 
>  
> Hey all,
> 
> Here's the latest report.
> 
> - Forwarded message from scan-ad...@coverity.com -
> 
> Date: Mon, 19 Apr 2021 01:18:55 + (UTC)
> From: scan-ad...@coverity.com
> To: tom.r...@gmail.com
> Subject: New Defects reported by Coverity Scan for Das U-Boot
> 
> Hi,
> 
> Please find the latest report on new defect(s) introduced to Das U-Boot found 
> with Coverity Scan.
> 
> 13 new defect(s) introduced to Das U-Boot found with Coverity Scan.
> 5 defect(s), reported by Coverity Scan earlier, were marked fixed in the 
> recent build analyzed by Coverity Scan.
> 
> New defect(s) Reported-by: Coverity Scan
> Showing 13 of 13 defect(s)
> 
> 
> ** CID 331158:  Control flow issues  (NO_EFFECT)
> /drivers/pinctrl/pinctrl-single.c: 347 in single_configure_bits()
> 
> 
> 
> *** CID 331158:  Control flow issues  (NO_EFFECT)
> /drivers/pinctrl/pinctrl-single.c: 347 in single_configure_bits()
> 341   return PTR_ERR(func);
> 342 
> 343   func->name = fname;
> 344   func->npins = 0;
> 345   for (n = 0; n < count; n++, pins++) {
> 346   offset = fdt32_to_cpu(pins->reg);
> >>> CID 331158:  Control flow issues  (NO_EFFECT)
> >>> This less-than-zero comparison of an unsigned value is never true. 
> >>> "offset < 0U".
> 347   if (offset < 0 || offset > pdata->offset) {
> 348   dev_dbg(dev, "  invalid register offset 0x%x\n",
> 349   offset);
> 350   continue;
> 351   }
> 352 
> 
> ** CID 331157:  Null pointer dereferences  (NULL_RETURNS)
> /drivers/misc/cros_ec_sandbox.c: 229 in keyscan_read_fdt_matrix()
> 
> 
> 
> *** CID 331157:  Null pointer dereferences  (NULL_RETURNS)
> /drivers/misc/cros_ec_sandbox.c: 229 in keyscan_read_fdt_matrix()
> 223 
> 224   /* Now read the data */
> 225   for (upto = 0; upto < ec->matrix_count; upto++) {
> 226   struct ec_keymatrix_entry *matrix = &ec->matrix[upto];
> 227   u32 word;
> 228 
> >>> CID 331157:  Null pointer dereferences  (NULL_RETURNS)
> >>> Incrementing a pointer which might be null: "cell".
> 229   word = fdt32_to_cpu(*cell++);
> 230   matrix->row = word >> 24;
> 231   matrix->col = (word >> 16) & 0xff;
> 232   matrix->keycode = word & 0x;
> 233 
> 234   /* Hard-code some sanity limits for now */
> 
> ** CID 331156:  Incorrect expression  (UNUSED_VALUE)
> /cmd/qfw.c: 40 in qemu_fwcfg_cmd_setup_kernel()
> 
> 
> 
> *** CID 331156:  Incorrect expression  (UNUSED_VALUE)
> /cmd/qfw.c: 40 in qemu_fwcfg_cmd_setup_kernel()
> 34qfw_read_entry(qfw_dev, FW_CFG_SETUP_DATA,
> 35   le32_to_cpu(setup_size), data_addr);
> 36data_addr += le32_to_cpu(setup_size);
> 37 
> 38qfw_read_entry(qfw_dev, FW_CFG_KERNEL_DATA,
> 39   le32_to_cpu(kernel_size), data_addr);
> >>> CID 331156:  Incorrect expression  (UNUSED_VALUE)
> >>> Assigning value from "(__u32)(__le32)kernel_size" to "data_addr" 
> >>> here, but that stored value is overwritten before it can be used.
> 40data_addr += le32_to_cpu(kernel_size);
> 41 
> 42data_addr = initrd_addr;
> 43qfw_read_entry(qfw_dev, FW_CFG_INITRD_SIZE, 4, &initrd_size);
> 44if (initrd_size == 0) {
> 45printf("warning: no initrd available\n");
> 
> ** CID 331155:  Insecure data handling  (TAINTED_SCALAR)
> 
> 
> 
> *** CID 331155:  Insecure data handling  (TAINTED_SCALAR)
> /fs/cbfs/cbfs.c: 170 in file_cbfs_next_file()
> 164   size -= align;
> 165   start += align;
> 166   continue;
> 167   }
> 168 
> 169   swap_file_header(&header, file_header);
> >>> CID 331155:  Insecure data handling  (TAINTED_SCALAR)
> >>> Passing tainted variable "header.offset" to a tainted sink.
> 170   ret = fill_node(node, start, &header);
> 171   if (ret) {
> 172   priv->result = CBFS_BAD_FILE;
> 173   return log_msg_ret("fill", ret);
> 174   }
> 175 
> 
> ** CID 331154:  Integer handling issues  (DIVIDE_BY_ZERO)
> /drivers/pinctrl/pinctrl-single.c: 473 in single_probe()
> 
> 
> ___

[PATCH] Add support for Raspberry Pi 3B+(32bit)

[Toshifumi NISHINAGA]

Hello all.

I will add rpi_3_32b_plus_defconfig to easy to build u-boot for
Raspberry Pi 3B+(32bit).
Could you merge this patch?

Thanks,
Toshifumi NISHINAGA


>From 28d13f48761ab7c137a5fdf07c76a857967e3590 Mon Sep 17 00:00:00 2001
From: Toshifumi NISHINAGA 
Date: Thu, 15 Apr 2021 16:53:33 +0900
Subject: [PATCH] Add support for Raspberry Pi 3B+(32bit)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

It also boots on Raspberry Pi 3B+ using rpi_3_32b_defconfig,
but the network card doesn't work.

This defconfig is based on rpi_3_32b_defconfig.

Signed-off-by: Toshifumi NISHINAGA 
---

configs/rpi_3_32b_plus_defconfig | 46 
1 file changed, 46 insertions(+)
create mode 100644 configs/rpi_3_32b_plus_defconfig

diff --git a/configs/rpi_3_32b_plus_defconfig b/configs/rpi_3_32b_plus_defconfig
new file mode 100644
index 00..d147a46ae7
--- /dev/null
+++ b/configs/rpi_3_32b_plus_defconfig
@@ -0,0 +1,46 @@
+CONFIG_ARM=y
+CONFIG_ARCH_CPU_INIT=y
+CONFIG_ARCH_BCM283X=y
+CONFIG_SYS_TEXT_BASE=0x8000
+CONFIG_TARGET_RPI_3_32B=y
+CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_ENV_SIZE=0x4000
+CONFIG_DEFAULT_DEVICE_TREE="bcm2837-rpi-3-b-plus"
+CONFIG_DISTRO_DEFAULTS=y
+CONFIG_OF_BOARD_SETUP=y
+CONFIG_USE_PREBOOT=y
+# CONFIG_DISPLAY_CPUINFO is not set
+# CONFIG_DISPLAY_BOARDINFO is not set
+CONFIG_MISC_INIT_R=y
+CONFIG_SYS_PROMPT="U-Boot> "
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_FS_UUID=y
+CONFIG_OF_EMBED=y
+CONFIG_ENV_FAT_DEVICE_AND_PART="0:1"
+CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
+CONFIG_DM_MMC=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_BCM2835=y
+CONFIG_PHYLIB=y
+CONFIG_DM_ETH=y
+CONFIG_PINCTRL=y
+# CONFIG_PINCTRL_GENERIC is not set
+# CONFIG_REQUIRE_SERIAL_CONSOLE is not set
+CONFIG_USB=y
+CONFIG_DM_USB=y
+CONFIG_USB_DWC2=y
+CONFIG_USB_KEYBOARD=y
+CONFIG_USB_HOST_ETHER=y
+CONFIG_USB_ETHER_LAN78XX=y
+CONFIG_USB_ETHER_SMSC95XX=y
+CONFIG_DM_VIDEO=y
+# CONFIG_VIDEO_BPP8 is not set
+# CONFIG_VIDEO_BPP16 is not set
+CONFIG_SYS_WHITE_ON_BLACK=y
+CONFIG_CONSOLE_SCROLL_LINES=10
+CONFIG_PHYS_TO_BUS=y
+CONFIG_OF_LIBFDT_OVERLAY=y
-- 
2.24.3 (Apple Git-128)

Re: [PATCH v2 07/13] mmc: synquacer: Add SynQuacer F_SDH30 SDHCI driver

[Jaehoon Chung]

On 4/20/21 9:59 AM, Masami Hiramatsu wrote:
> Hi Jaehoon,
> 
> Thanks for your comments.
> 
> 2021年4月20日(火) 7:05 Jaehoon Chung :
>>
>> Hi Masami,
>>
>> On 4/17/21 8:38 AM, Masami Hiramatsu wrote:
>>> From: Jassi Brar 
>>>
>>> Signed-off-by: Jassi Brar 
>>> Signed-off-by: Masami Hiramatsu 
>>> ---
>>>  drivers/mmc/Kconfig   |   10 ++
>>>  drivers/mmc/Makefile  |1 +
>>>  drivers/mmc/f_sdh30.c |   81 
>>> +
>>>  drivers/mmc/sdhci.c   |9 +
>>>  4 files changed, 101 insertions(+)
>>>  create mode 100644 drivers/mmc/f_sdh30.c
>>>
>>> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
>>> index f8ca52efb6..a9ae419e41 100644
>>> --- a/drivers/mmc/Kconfig
>>> +++ b/drivers/mmc/Kconfig
>>> @@ -549,6 +549,16 @@ config MMC_SDHCI_IPROC
>>>
>>> If unsure, say N.
>>>
>>> +config F_SDH30_SDHCI
>>
>> MMS_SDHCI_F_SDH30 or MMC_SDHCI_xxx.
> 
> OK. I'll change it.
> 
>>
>>> + bool "SDHCI support for Fujitsu Semiconductor F_SDH30"
>>> + depends on BLK && DM_MMC
>>> + depends on MMC_SDHCI
>>> + help
>>> +   This selects the Secure Digital Host Controller Interface (SDHCI)
>>> +   Needed by some Fujitsu SoC for MMC / SD / SDIO support.
>>> +   If you have a controller with this interface, say Y or M here.
>>> +   If unsure, say N.
>>> +
>>>  config MMC_SDHCI_KONA
>>>   bool "SDHCI support on Broadcom KONA platform"
>>>   depends on MMC_SDHCI
>>> diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
>>> index 89d6af3db3..b48a76ba94 100644
>>> --- a/drivers/mmc/Makefile
>>> +++ b/drivers/mmc/Makefile
>>> @@ -76,3 +76,4 @@ obj-$(CONFIG_MMC_UNIPHIER)  += tmio-common.o 
>>> uniphier-sd.o
>>>  obj-$(CONFIG_RENESAS_SDHI)   += tmio-common.o renesas-sdhi.o
>>>  obj-$(CONFIG_MMC_BCM2835)+= bcm2835_sdhost.o
>>>  obj-$(CONFIG_MMC_MTK)+= mtk-sd.o
>>> +obj-$(CONFIG_F_SDH30_SDHCI)  += f_sdh30.o
>>> diff --git a/drivers/mmc/f_sdh30.c b/drivers/mmc/f_sdh30.c
>>> new file mode 100644
>>> index 00..44c6521bfe
>>> --- /dev/null
>>> +++ b/drivers/mmc/f_sdh30.c
>>> @@ -0,0 +1,81 @@
>>> +// SPDX-License-Identifier: GPL-2.0+
>>> +/*
>>> + * Socionext F_SDH30 eMMC driver
>>> + * Copyright 2021 Linaro Ltd.
>>> + * Copyright 2021 Socionext, Inc.
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +struct f_sdh30_plat {
>>> + struct mmc_config cfg;
>>> + struct mmc mmc;
>>> +};
>>> +
>>> +DECLARE_GLOBAL_DATA_PTR;
>>> +
>>> +static int f_sdh30_probe(struct udevice *dev)
>>
>> xxx_sdhci_probe().
> 
> Let me confirm. The controller name is F_SDH30, so it is better to be
> f_sdh30_sdhci_probe(), correct?

I think that it's better. :)
It's my preference. But other driver are using the similar naming.

> 
>>> +{
>>> + struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
>>> + struct f_sdh30_plat *plat = dev_get_plat(dev);
>>> + struct sdhci_host *host = dev_get_priv(dev);
>>> + int ret;
>>> +
>>> + ret = mmc_of_parse(dev, &plat->cfg);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + host->mmc = &plat->mmc;
>>> + host->mmc->dev = dev;
>>> + host->mmc->priv = host;
>>> +
>>> + ret = sdhci_setup_cfg(&plat->cfg, host, 2, 40);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + upriv->mmc = host->mmc;
>>> +
>>> + mmc_set_clock(host->mmc, host->mmc->cfg->f_min, MMC_CLK_ENABLE);
>>> +
>>> + return sdhci_probe(dev);
>>> +}
>>> +
>>> +static int f_sdh30_of_to_plat(struct udevice *dev)
>>> +{
>>> + struct sdhci_host *host = dev_get_priv(dev);
>>> +
>>> + host->name = strdup(dev->name);
>>> + host->ioaddr = dev_read_addr_ptr(dev);
>>> + host->bus_width = dev_read_u32_default(dev, "bus-width", 4);
>>> + host->index = dev_read_u32_default(dev, "index", 0);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static int f_sdh30_bind(struct udevice *dev)
>>> +{
>>> + struct f_sdh30_plat *plat = dev_get_plat(dev);
>>> +
>>> + return sdhci_bind(dev, &plat->mmc, &plat->cfg);
>>> +}
>>> +
>>> +static const struct udevice_id f_sdh30_mmc_ids[] = {
>>> + { .compatible = "fujitsu,mb86s70-sdhci-3.0" },
>>> + { }
>>> +};
>>> +
>>> +U_BOOT_DRIVER(f_sdh30_drv) = {
>>> + .name   = "f_sdh30_sdhci",
>>> + .id = UCLASS_MMC,
>>> + .of_match   = f_sdh30_mmc_ids,
>>> + .of_to_plat = f_sdh30_of_to_plat,
>>> + .ops= &sdhci_ops,
>>> + .bind   = f_sdh30_bind,
>>> + .probe  = f_sdh30_probe,
>>> + .priv_auto  = sizeof(struct sdhci_host),
>>> + .plat_auto  = sizeof(struct f_sdh30_plat),
>>> +};
>>> diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
>>> index d9ab6a0a83..f038debc6c 100644
>>> --- a/drivers/mmc/sdhci.c
>>> +++ b/drivers/mmc/sdhci.c
>>> @@ -708,6 +708,15 @@ static int sdhci_init(struct mmc *mmc)
>>>
>>>   sdhci_set_power(host, fls(mmc

RE: [PATCH v2 4/4] sandbox: enable IRQ using select for sandbox architecture

[Priyanka Jain]

>-Original Message-
>From: U-Boot  On Behalf Of Wasim Khan
>(OSS)
>Sent: Friday, April 16, 2021 1:52 PM
>To: Tom Rini ; Simon Glass 
>Cc: u-boot@lists.denx.de
>Subject: RE: [PATCH v2 4/4] sandbox: enable IRQ using select for sandbox
>architecture
>
>Hi Tom,
>
>> -Original Message-
>> From: Simon Glass 
>> Sent: Tuesday, March 30, 2021 10:27 PM
>> To: Wasim Khan (OSS) 
>> Cc: Bin Meng ; Mario Six ;
>> Bharat Gooty ; Rayagonda Kokatanur
>> ; Tero Kristo ;
>> Varun Sethi ; U-Boot Mailing List
>> ; Wasim Khan 
>> Subject: Re: [PATCH v2 4/4] sandbox: enable IRQ using select for
>> sandbox architecture
>>
>> Hi Wasim,
>>
>> On Tue, 9 Mar 2021 at 04:48, Wasim Khan 
>wrote:
>> >
>> > From: Wasim Khan 
>> >
>> > Enable IRQ using select for sandbox architecture.
>> >
>> > Signed-off-by: Wasim Khan 
>> > Reviewed-by: Simon Glass 
>> > ---
>> > Changes in v2:
>> >  - no change
>> >
>> >  arch/Kconfig   | 1 +
>> >  configs/sandbox64_defconfig| 1 -
>> >  configs/sandbox_defconfig  | 1 -
>> >  configs/sandbox_flattree_defconfig | 1 -
>> >  configs/sandbox_spl_defconfig  | 1 -
>> >  5 files changed, 1 insertion(+), 4 deletions(-)
>>
>> You can see the status of your series here:
>>
>> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatch
>> wor
>>
>k.ozlabs.org%2Fproject%2Fuboot%2Flist%2F%3Fseries%3D232773&data
>=0
>>
>4%7C01%7Cwasim.khan%40nxp.com%7Cbabc6763976e4d9c257808d8f39cd77b
>> %7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63752720224208941
>0
>> %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
>LCJB
>>
>TiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=cmOzxfmhlIdP6A0G1P%
>2
>> BAXg%2FhPVky02%2BeUEMxd5y1bHs%3D&reserved=0
>>
>> It is assigned to Tom Rini.
>>
>> Regards,
>> Simon
>
>https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
>work.ozlabs.org%2Fproject%2Fuboot%2Flist%2F%3Fseries%3D232773&d
>ata=04%7C01%7Cpriyanka.jain%40nxp.com%7C7a5eea075a364cc3863d08d900
>b0b077%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6375415811448
>67361%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
>MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ZBoZ4dxhQBW
>cFuR3E5zE0fQVb55e%2BxbWWxnFgyo411s%3D&reserved=0 this series is
>tested, reviewed.
>It can be merged after
>https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
>work.ozlabs.org%2Fproject%2Fuboot%2Fpatch%2F20210305070235.13547-1-
>Zhiqiang.Hou%40nxp.com%2F&data=04%7C01%7Cpriyanka.jain%40nxp.c
>om%7C7a5eea075a364cc3863d08d900b0b077%7C686ea1d3bc2b4c6fa92cd99c5
>c301635%7C0%7C0%7C637541581144867361%7CUnknown%7CTWFpbGZsb3d8
>eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
>%7C1000&sdata=%2FidlO6hAGlxGD1cO2fA5cQORDIorCY%2FPq%2FQkZQ
>4pEm0%3D&reserved=0
>
>Kindly do the needful
>
>Regards,
>Wasim

Reviewed-by: Priyanka Jain 

Tom,

Kindly help to merge this patch.
This is required to fix boot issue on many of NXP fsl-qoriq platforms like 
lx2160ardb.

Thanks
Priyanka

RE: [PATCH v2 3/4] arch: Kconfig: enable IRQ using select for x86 architecture

[Priyanka Jain]

>-Original Message-
>From: U-Boot  On Behalf Of Wasim Khan
>Sent: Monday, March 8, 2021 9:18 PM
>To: s...@chromium.org; bmeng...@gmail.com; mario@gdsys.cc;
>bharat.go...@broadcom.com; rayagonda.kokata...@broadcom.com; t-
>kri...@ti.com; Varun Sethi 
>Cc: u-boot@lists.denx.de; Wasim Khan ; Z.q. Hou
>
>Subject: [PATCH v2 3/4] arch: Kconfig: enable IRQ using select for x86
>architecture
>
>From: Wasim Khan 
>
>use 'select' to enable IRQ as it does not have architecture specific 
>dependency.
>
>Signed-off-by: Wasim Khan 
>Reviewed-by: Hou Zhiqiang 
>Reviewed-by: Simon Glass 
>---
>Changes in v2:
> - no change
>
> arch/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/arch/Kconfig b/arch/Kconfig index 3aa99e08fc..362b220948 100644
>--- a/arch/Kconfig
>+++ b/arch/Kconfig
>@@ -167,6 +167,7 @@ config X86
>   select TIMER
>   select USE_PRIVATE_LIBGCC
>   select X86_TSC_TIMER
>+  select IRQ
>   imply HAS_ROM if X86_RESET_VECTOR
>   imply BLK
>   imply CMD_DM
>@@ -197,7 +198,6 @@ config X86
>   imply USB_HOST_ETHER
>   imply PCH
>   imply RTC_MC146818
>-  imply IRQ
>   imply ACPIGEN if !QEMU
>   imply SYSINFO if GENERATE_SMBIOS_TABLE
>   imply SYSINFO_SMBIOS if GENERATE_SMBIOS_TABLE
>--
>2.25.1

Reviewed-by: Priyanka Jain 

Tom,

Kindly help to merge this patch.
This is required to fix boot issue on many of NXP fsl-qoriq platforms like 
lx2160ardb.

Thanks
Priyanka

RE: [PATCH v2 2/4] arch: arm: update Kconfig to select IRQ when GIC_V3_ITS is enabled

[Priyanka Jain]

>-Original Message-
>From: U-Boot  On Behalf Of Wasim Khan
>Sent: Monday, March 8, 2021 9:18 PM
>To: s...@chromium.org; bmeng...@gmail.com; mario@gdsys.cc;
>bharat.go...@broadcom.com; rayagonda.kokata...@broadcom.com; t-
>kri...@ti.com; Varun Sethi 
>Cc: u-boot@lists.denx.de; Wasim Khan ; Z.q. Hou
>
>Subject: [PATCH v2 2/4] arch: arm: update Kconfig to select IRQ when
>GIC_V3_ITS is enabled
>
>From: Wasim Khan 
>
>GIC_V3_ITS uses UCLASS_IRQ driver. Update Kconfig to select IRQ when
>GIC_V3_ITS is enabled.
>
>Signed-off-by: Wasim Khan 
>Reviewed-by: Hou Zhiqiang 
>Reviewed-by: Simon Glass 
>---
>Changes in v2:
> - no change
>
> arch/arm/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
>diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index
>fbe90875ae..f8b4d422d9 100644
>--- a/arch/arm/Kconfig
>+++ b/arch/arm/Kconfig
>@@ -67,6 +67,7 @@ config GIC_V3_ITS
>   bool "ARM GICV3 ITS"
>   select REGMAP
>   select SYSCON
>+  select IRQ
>   help
> ARM GICV3 Interrupt translation service (ITS).
> Basic support for programming locality specific peripheral
>--
>2.25.1

Reviewed-by: Priyanka Jain 

Tom,

Kindly help to merge this patch.
This is required to fix boot issue on many of NXP fsl-qoriq platforms like 
lx2160ardb.

Thanks
Priyanka

RE: [PATCH v2 1/4] misc: make CONFIG_IRQ selectable for all platforms

[Priyanka Jain]

>-Original Message-
>From: U-Boot  On Behalf Of Wasim Khan
>Sent: Monday, March 8, 2021 9:18 PM
>To: s...@chromium.org; bmeng...@gmail.com; mario@gdsys.cc;
>bharat.go...@broadcom.com; rayagonda.kokata...@broadcom.com; t-
>kri...@ti.com; Varun Sethi 
>Cc: u-boot@lists.denx.de; Wasim Khan ; Vladimir
>Oltean 
>Subject: [PATCH v2 1/4] misc: make CONFIG_IRQ selectable for all platforms
>
>From: Wasim Khan 
>
>UCLASS_IRQ driver is not Intel specific. Make CONFIG_IRQ selectable for all
>platforms.
>
>Signed-off-by: Wasim Khan 
>Tested-by: Vladimir Oltean 
>Reviewed-by: Simon Glass 
>---
>Changes in v2:
> - Corrected typo in commit description
>
> drivers/misc/Kconfig | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
>diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index
>29432ae7eb..5eab1ed9c6 100644
>--- a/drivers/misc/Kconfig
>+++ b/drivers/misc/Kconfig
>@@ -211,10 +211,9 @@ config FSL_SEC_MON
> like software violations or hardware security violations.
>
> config IRQ
>-  bool "Intel Interrupt controller"
>-  depends on X86 || SANDBOX
>+  bool "Interrupt controller"
>   help
>-This enables support for Intel interrupt controllers, including ITSS.
>+This enables support for interrupt controllers, including ITSS.
> Some devices have extra features, such as Apollo Lake. The
> device has its own uclass since there are several operations
> involved.
>--
>2.25.1

Reviewed-by: Priyanka Jain 

Tom,

Kindly help to merge this patch.
This is required to fix boot issue on many of NXP fsl-qoriq platforms like 
lx2160ardb.

Thanks
Priyanka

RE: [PATCHv3] arm64: gic-v3-its: Clear the Pending table before enabling LPIs

[Priyanka Jain]

>-Original Message-
>From: Z.q. Hou 
>Sent: Friday, March 5, 2021 12:33 PM
>To: u-boot@lists.denx.de
>Cc: s...@chromium.org; rayagonda.kokata...@broadcom.com; Priyanka Jain
>; Z.q. Hou 
>Subject: [PATCHv3] arm64: gic-v3-its: Clear the Pending table before enabling
>LPIs
>
>From: Hou Zhiqiang 
>
>The GICv3 RM requires "The first 1KB of memory for the LPI Pending tables
>must contain only zeros on initial allocation, and this must be visible to the
>Redistributors, or else the effect is UNPREDICTABLE".
>
>And as the following statement, we here clear the whole Pending tables
>instead of the first 1KB.
>"An LPI Pending table that contains only zeros, including in the first 1KB,
>indicates that there are no pending LPIs.
>The first 1KB of the LPI Pending table is IMPLEMENTATION DEFINED. However,
>if the first 1KB of the LPI Pending table and the rest of the table contain 
>only
>zeros, this must indicate that there are no pending LPIs."
>
>And there isn't any pending LPI under U-Boot, so it's unnecessary to load the
>contents of the Pending table during the enablement, then set the
>GICR_PENDBASER.PTZ flag.
>
>Signed-off-by: Hou Zhiqiang 
>---
>V3:
> - Fix a mistake code delete in v2.
>
> arch/arm/lib/gic-v3-its.c | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
>diff --git a/arch/arm/lib/gic-v3-its.c b/arch/arm/lib/gic-v3-its.c index
>f5a921b3d1..2d3fdb600e 100644
>--- a/arch/arm/lib/gic-v3-its.c
>+++ b/arch/arm/lib/gic-v3-its.c
>@@ -3,6 +3,7 @@
>  * Copyright 2019 Broadcom.
>  */
> #include 
>+#include 
> #include 
> #include 
> #include 
>@@ -108,6 +109,8 @@ int gic_lpi_tables_init(void)
>   int i;
>   u64 redist_lpi_base;
>   u64 pend_base;
>+  ulong pend_tab_total_sz;
>+  void *pend_tab_va;
>
>   if (gic_v3_its_get_gic_addr(&priv))
>   return -EINVAL;
>@@ -161,6 +164,12 @@ int gic_lpi_tables_init(void)
>   }
>
>   redist_lpi_base = priv.lpi_base + LPI_PROPBASE_SZ;
>+  pend_tab_total_sz = priv.num_redist * LPI_PENDBASE_SZ;
>+  pend_tab_va = map_physmem(redist_lpi_base, pend_tab_total_sz,
>+MAP_NOCACHE);
>+  memset(pend_tab_va, 0, pend_tab_total_sz);
>+  flush_cache((ulong)pend_tab_va, pend_tab_total_sz);
>+  unmap_physmem(pend_tab_va, MAP_NOCACHE);
>
>   pend_base = priv.gicr_base + GICR_PENDBASER;
>   for (i = 0; i < priv.num_redist; i++) { @@ -168,7 +177,8 @@ int
>gic_lpi_tables_init(void)
>
>   val = ((redist_lpi_base + (i * LPI_PENDBASE_SZ)) |
>   GICR_PENDBASER_INNERSHAREABLE |
>-  GICR_PENDBASER_RAWAWB);
>+  GICR_PENDBASER_RAWAWB |
>+  GICR_PENDBASER_PTZ);
>
>   writeq(val, (uintptr_t)(pend_base + offset));
>   tmp = readq((uintptr_t)(pend_base + offset));
>--
>2.17.1


Reviewed-by: Priyanka Jain 

Tom,

Kindly help to merge this patch.
This is required to fix boot issue on many of NXP fsl-qoriq platforms like 
lx2160ardb.

Thanks
Priyanka

[PATCH 2/2] drivers: mmc: add OpenPiton MMC support

[Tianrui Wei]

>From b8736bf498afc0d250228b0c29f1b402d0d58361 Mon Sep 17 00:00:00 2001
From: Tianrui Wei 
Date: Mon, 20 April 2021 13:03:25 +0800
Subject: [PATCH 2/2] drivers: mmc: add OpenPiton MMC support

This patch enables support for OpenPiton MMC in u-boot 

Signed-off-by: Tianrui Wei 
Acked-by: Jonathan Balkind 

---

 drivers/mmc/Kconfig |   5 +
 drivers/mmc/Makefile|   1 +
 drivers/mmc/piton_mmc.c | 184 
 3 files changed, 190 insertions(+)
 create mode 100644 drivers/mmc/piton_mmc.c

diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index 14d79139..8cbcd082 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -707,6 +707,11 @@ config MMC_SUNXI_HAS_MODE_SWITCH
bool
depends on MMC_SUNXI
 
+config MMC_PITON
+   bool "MMC support for openpiton SoC"
+   help
+This driver enables sd card support in uboot port for openpiton
+
 config GENERIC_ATMEL_MCI
bool "Atmel Multimedia Card Interface support"
depends on DM_MMC && BLK && ARCH_AT91
diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index 1c849cba..698dfe05 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -71,6 +71,7 @@ obj-$(CONFIG_MMC_SDHCI_XENON) += xenon_sdhci.o
 obj-$(CONFIG_MMC_SDHCI_ZYNQ)   += zynq_sdhci.o
 
 obj-$(CONFIG_MMC_SUNXI)+= sunxi_mmc.o
+obj-$(CONFIG_MMC_PITON)+= piton_mmc.o
 obj-$(CONFIG_MMC_UNIPHIER) += tmio-common.o uniphier-sd.o
 obj-$(CONFIG_RENESAS_SDHI) += tmio-common.o renesas-sdhi.o
 obj-$(CONFIG_MMC_BCM2835)  += bcm2835_sdhost.o
diff --git a/drivers/mmc/piton_mmc.c b/drivers/mmc/piton_mmc.c
new file mode 100644
index ..a749f30a
--- /dev/null
+++ b/drivers/mmc/piton_mmc.c
@@ -0,0 +1,184 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2009 SAMSUNG Electronics
+ * Minkyu Kang 
+ * Jaehoon Chung 
+ * Portions Copyright 2011-2019 NVIDIA Corporation
+ * Portions Copyright 2021 Tianrui Wei
+ * Tianrui Wei 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct piton_mmc_plat {
+   struct mmc_config cfg;
+   struct mmc mmc;
+};
+
+struct piton_mmc_priv {
+   u64 piton_mmc_base_addr; /* peripheral id */
+};
+
+// see mmc_read_blocks to see how it is used.
+// start block is hidden at cmd->arg
+// also, initialize the block size at init
+static int piton_mmc_send_cmd(
+   struct udevice *dev,
+   struct mmc_cmd *cmd,
+   struct mmc_data *data
+)
+{
+   // check first if this is a pure command
+   if (data == NULL) {
+   return 0;
+   }
+
+   // byte count counts all the bytes required for this command
+   u64 byte_cnt = data->blocks * data->blocksize;
+   // get which block in mmc card to start from
+   u64 start_block = cmd->cmdarg;
+   // buff points to the address we store the data stored at mmc card
+   unsigned *buff = (unsigned int *) data->dest;
+
+   struct piton_mmc_priv *priv = dev_get_priv(dev);
+   // start address denotes the absolute address where the transmission 
start
+   u64 start_addr = priv->piton_mmc_base_addr + (start_block);
+
+   /* if data is not empty*/
+   if (data) {
+
+   /* if there is a read */
+   if (data->flags & MMC_DATA_READ) {
+   for (u64 i = 0; i < byte_cnt; i += 4) {
+   *(buff) = readl((void *)(start_addr + i));
+   buff++;
+   }
+   } else {
+   /* else there is a write
+* we don't handle write, so error right away
+*/
+   return -ENODEV;
+   }
+   }
+
+   return 0;
+}
+
+static int piton_mmc_ofdata_to_platdata(struct udevice *dev)
+{
+   struct piton_mmc_priv *priv = dev_get_priv(dev);
+   struct piton_mmc_plat *plat = dev_get_platdata(dev);
+   struct mmc_config *cfg;
+   struct mmc *mmc;
+
+   priv->piton_mmc_base_addr = dev_read_addr(dev);
+   cfg = &plat->cfg;
+   cfg->name = "PITON MMC";
+   cfg->host_caps = MMC_MODE_8BIT;
+   cfg->f_max = 10;
+   cfg->f_min = 40;
+   cfg->voltages = MMC_VDD_21_22;
+
+   mmc = &plat->mmc;
+   mmc->read_bl_len = MMC_MAX_BLOCK_LEN;
+   mmc->capacity_user = 0x1;
+   mmc->capacity_user *= mmc->read_bl_len;
+   mmc->capacity_boot = 0;
+   mmc->capacity_rpmb = 0;
+   for (int i = 0; i < 4; i++)
+   mmc->capacity_gp[i] = 0;
+   mmc->capacity = 0x20ULL;
+   mmc->has_init = 1;
+
+   /* fill in device description */
+   struct blk_desc *bdesc;
+
+   bdesc = mmc_get_blk_desc(mmc);
+   bdesc->lun = 0;
+   bdesc->hwpart = 0;
+   bdesc->type = 

[PATCH 1/2] riscv: board: Support Openpiton Soc

[Tianrui Wei]

>From b8736bf498afc0d250228b0c29f1b402d0d58361 Mon Sep 17 00:00:00 2001
From: Tianrui Wei 
Date: Mon, 20 April 2021 13:03:25 +0800
Subject: [PATCH 1/2] riscv: board: Support Openpiton Soc

This patch enables support for OpenPiton risc-v SoC on
Digilent Genesys2 FPGA with dual cores configuration

Signed-off-by: Tianrui Wei 
Acked-by: Jonathan Balkind 

---

 arch/riscv/Kconfig  |   4 +
 arch/riscv/dts/Makefile |   1 +
 arch/riscv/dts/openpiton-riscv64.dts| 160 +
 board/openpiton/riscv/Kconfig   |  42 ++
 board/openpiton/riscv/MAINTAINERS   |   6 +
 board/openpiton/riscv/Makefile  |   5 +
 board/openpiton/riscv/openpiton-riscv.c |  41 ++
 configs/openpiton_riscv64_defconfig | 132 +
 include/configs/openpiton-riscv.h   |  58 
 9 files changed, 449 insertions(+)
 create mode 100644 arch/riscv/dts/openpiton-riscv64.dts
 create mode 100644 board/openpiton/riscv/Kconfig
 create mode 100644 board/openpiton/riscv/MAINTAINERS
 create mode 100644 board/openpiton/riscv/Makefile
 create mode 100644 board/openpiton/riscv/openpiton-riscv.c
 create mode 100644 configs/openpiton_riscv64_defconfig
 create mode 100644 include/configs/openpiton-riscv.h

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 30b05408..79f2b0b9 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -23,6 +23,9 @@ config TARGET_SIFIVE_FU540
 config TARGET_SIPEED_MAIX
bool "Support Sipeed Maix Board"
 
+config TARGET_OPENPITON_RISCV
+bool "Support riscv cores on openpiton SoC"
+
 endchoice
 
 config SYS_ICACHE_OFF
@@ -57,6 +60,7 @@ source "board/emulation/qemu-riscv/Kconfig"
 source "board/microchip/mpfs_icicle/Kconfig"
 source "board/sifive/fu540/Kconfig"
 source "board/sipeed/maix/Kconfig"
+source "board/openpiton/riscv/Kconfig"
 
 # platform-specific options below
 source "arch/riscv/cpu/ax25/Kconfig"
diff --git a/arch/riscv/dts/Makefile b/arch/riscv/dts/Makefile
index 3a6f96c6..0eb8014b 100644
--- a/arch/riscv/dts/Makefile
+++ b/arch/riscv/dts/Makefile
@@ -3,6 +3,7 @@
 dtb-$(CONFIG_TARGET_AX25_AE350) += ae350_32.dtb ae350_64.dtb
 dtb-$(CONFIG_TARGET_SIFIVE_FU540) += hifive-unleashed-a00.dtb
 dtb-$(CONFIG_TARGET_SIPEED_MAIX) += k210-maix-bit.dtb
+dtb-$(CONFIG_TARGET_OPENPITON_RISCV) += openpiton-riscv64.dtb
 
 targets += $(dtb-y)
 
diff --git a/arch/riscv/dts/openpiton-riscv64.dts 
b/arch/riscv/dts/openpiton-riscv64.dts
new file mode 100644
index ..9ef8280e
--- /dev/null
+++ b/arch/riscv/dts/openpiton-riscv64.dts
@@ -0,0 +1,160 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/* Copyright (c) 2021 Tianrui Wei  */
+
+// This dts is for a dual core instance of OpenPiton+Ariane built
+// to run on a Digilent Genesys 2 FPGA at 66.67MHz. These files
+// are automatically generated by the OpenPiton build system and
+// this configuration may not be what you need if your configuration
+// is different from the below.
+
+/dts-v1/;
+
+/ {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   u-boot,dm-pre-reloc;
+   compatible = "openpiton,ariane";
+
+   chosen {
+  u-boot,dm-pre-reloc;
+  bootargs = "debug loglevel=9";
+  stdout-path = "uart0:115200";
+   };
+
+   aliases {
+   u-boot,dm-pre-reloc;
+   console = &uart0;
+   serial0 = &uart0;
+   };
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   u-boot,dm-pre-reloc;
+   timebase-frequency = <520835>;
+
+   CPU0: cpu@0 {
+   clock-frequency = <7000>;
+   u-boot,dm-pre-reloc;
+   device_type = "cpu";
+   reg = <0>;
+   status = "okay";
+   compatible = "eth, ariane", "riscv";
+   riscv,isa = "rv64imafdc";
+   mmu-type = "riscv,sv39";
+   tlb-split;
+   // HLIC - hart local interrupt controller
+   CPU0_intc: interrupt-controller {
+   #interrupt-cells = <1>;
+   interrupt-controller;
+   compatible = "riscv,cpu-intc";
+   };
+   };
+
+   CPU1: cpu@1 {
+   clock-frequency = <7000>;
+   u-boot,dm-pre-reloc;
+   device_type = "cpu";
+   reg = <1>;
+   status = "okay";
+   compatible = "eth, ariane", "riscv";
+   riscv,isa = "rv64imafdc";
+   mmu-type = "riscv,sv39";
+   tlb-split;
+   // HLIC - hart local interrupt controller
+   CPU1_intc: interrupt-controller {
+   #interrupt-cells = <1>;
+

Re: [PATCH v6 00/14] mtd: spi-nor: Add support for Cypress s25hl-t/s25hs-t

[Takahiro Kuwano]

On 4/19/2021 4:13 PM, Jagan Teki wrote:
> On Wed, Apr 7, 2021 at 9:01 AM  wrote:
>>
>> From: Takahiro Kuwano 
>>
>> The S25HL-T/S25HS-T family is the Cypress Semper Flash with Quad SPI.
>>
>> The summary datasheets can be found in the following links.
>> https://www.cypress.com/file/424146/download (256Mb/512Mb/1Gb, single die)
>> https://www.cypress.com/file/499246/download (2Gb/4Gb, dual/quad die)
>>
>> The full version can be found in the following links (registration
>> required).
>> https://community.cypress.com/t5/Semper-Flash-Access-Program/Datasheet-Semper-Flash-with-Quad-SPI/ta-p/260789?attachment-id=19522
>> https://community.cypress.com/t5/Semper-Flash-Access-Program/Datasheet-2Gb-MCP-Semper-Flash-with-Quad-SPI/ta-p/260823?attachment-id=29503
>>
>> Tested on Xilinx Zynq-7000 FPGA board.
> 
> Any details about footprint statistics?
> 
Please see arm-none-eabi-size output below.

BEFORE patching:
   textdata bss dec hex filename
   6353   0   0635318d1 drivers/mtd/spi/spi-nor-core.o
922   0   0 922 39a drivers/mtd/spi/spi-nor-ids.o
   1879   0   01879 757 spl/drivers/mtd/spi/spi-nor-tiny.o

AFTER patching:
   textdata bss dec hex filename
   7705  12   077171e25 drivers/mtd/spi/spi-nor-core.o
   1150   0   01150 47e drivers/mtd/spi/spi-nor-ids.o
   1919   0   01919 77f spl/drivers/mtd/spi/spi-nor-tiny.o

arm-none-eabi-gcc (GCC) 8.2.0, Optimization level -O2.

Best Regards,
Takahiro

Re: Possible USB Mass Storage bug on Xilinx's Zynq

[Sean Anderson]

On 4/19/21 9:05 AM, Bruno L. Albrecht wrote:

Hello people,
it's my first post here, so forgive me if I do something wrong. I'll try to
be short and clear.

I'm developing on an Avnet PicoZed (based on a Xilinx Zynq SoC) and my
objective is to expose the eMMC as a Mass Storage Device over an USB
Connection.

I used the following config flag on defconfig file (
https://github.com/Xilinx/u-boot-xlnx/blob/master/configs/xilinx_zynq_virt_defconfig
):

CONFIG_CMD_USB_MASS_STORAGE=y


To the Device Tree (
https://github.com/Xilinx/u-boot-xlnx/blob/master/arch/arm/dts/zynq-picozed.dts)
I added the usb configuration:

aliases {

 <...>
 usb0 = &usb0;
};
&usb0 {
 u-boot,dm-pre-reloc;
 status = "okay";
 dr_mode = "peripheral";
};



Compilation goes fine and U-Boot boots fine. The eMMC is correctly
recognized.
Then I use the following command to initiate the USB Mass Storage:

ums 0 mmc 0


When on *Windows*, the command is successful for a brief moment and then
the board resets with the following error:

Zynq> ums 0 mmc 0

UMS: LUN 0, dev 0, hwpart 0, sector 0x0, count 0xe3
\EP1/in FAIL info=4080 pg0=3eb393c0
EP1/in FAIL info=40008080 pg0=3eb3d3c0
EP1/in FAIL info=d8080 pg0=3eaebdc0
CACHE: Misaligned operation at range [0001, 0041]
CACHE: Misaligned operation at range [0001, 0041]
data abort
pc : [<3ff67dec>]  lr : [<3ff67dec>]
reloc pc : [<0405cdec>]lr : [<0405cdec>]


I don't know anything about this platform, but I'd start with figuring
out what function/line these are from. You can find out by grepping
through objdump -S.

--Sean


sp : 3eae81f0  ip : 0031 fp : 3ffd957c
r10: 0001  r9 : 3eaeaed0 r8 : 0001
r7 : 3ffd9524  r6 : 0001 r5 : 3ffd94ec  r4 : 3ffd95a4
r3 : e0001000  r2 : 0001 r1 : 0041  r0 : 0001
Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
Code: ea7e e2861040 e1a6 ebfe91a6 (e5963004)
Resetting CPU ...



Since I'm working on a Windows machine, I have a Ubuntu running on a
Virtual Machine (VirtualBox). So I made a rule to bypass the USB device
that would be created on Windows directly to the Virtual Machine (virtually
connected the USB device to my Ubuntu).

When I do this, the command works. I can access the eMMC and format it and
do whatever I want. If I remove the filter and let Windows enumerate the
device, the board resets again.

I took a look at the dmesg messages on Ubuntu and found the following (the
only unusual messages are in bold):

[101436.784042] usb 1-2: new full-speed USB device number 25 using ohci-pci


*[101437.232208] usb 1-2: config 1 interface 0 altsetting 0 endpoint 0x81
has invalid maxpacket 512, setting to 64[101437.232210] usb 1-2: config 1
interface 0 altsetting 0 endpoint 0x2 has invalid maxpacket 512, setting to
64*
[101437.477816] usb 1-2: New USB device found, idVendor=,
idProduct=, bcdDevice= 2.21
[101437.477818] usb 1-2: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
[101437.477820] usb 1-2: Product: my product name
[101437.477821] usb 1-2: Manufacturer: my manufacturer
[101437.702297] usb-storage 1-2:1.0: USB Mass Storage device detected
[101437.713954] scsi host3: usb-storage 1-2:1.0
[101438.976664] scsi 3:0:0:0: Direct-Access LinuxUMS disk 0
 PQ: 0 ANSI: 2
[101438.979158] sd 3:0:0:0: Attached scsi generic sg2 type 0
[101439.284100] sd 3:0:0:0: [sdb] 14876672 512-byte logical blocks: (7.62
GB/7.09 GiB)
[101439.468523] sd 3:0:0:0: [sdb] Write Protect is off
[101439.468526] sd 3:0:0:0: [sdb] Mode Sense: 0f 00 00 00
[101439.653020] sd 3:0:0:0: [sdb] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[101440.759756]  sdb: sdb1
[101441.559083] sd 3:0:0:0: [sdb] Attached SCSI removable disk



Not that it sounds like it would interfere, but the USB from the SoC is
connected to an USB Hub (USB2514B), to which other devices are connected
and work correctly on both Windows and Linux.

Any ideas of what might be happening?


Cheers
Bruno

Re: [scan-ad...@coverity.com: New Defects reported by Coverity Scan for Das U-Boot]

[Tom Rini]

On Tue, Apr 20, 2021 at 12:58:28AM +, Asherah Connor wrote:
> Looking at cmd/qfw.c as I touched it last:
> 
> On 21/04/19 08:04:p, Tom Rini wrote:
> > ** CID 331156:  Incorrect expression  (UNUSED_VALUE)
> > /cmd/qfw.c: 40 in qemu_fwcfg_cmd_setup_kernel()
> > 
> > 
> > 
> > *** CID 331156:  Incorrect expression  (UNUSED_VALUE)
> > /cmd/qfw.c: 40 in qemu_fwcfg_cmd_setup_kernel()
> > 34  qfw_read_entry(qfw_dev, FW_CFG_SETUP_DATA,
> > 35 le32_to_cpu(setup_size), data_addr);
> > 36  data_addr += le32_to_cpu(setup_size);
> > 37 
> > 38  qfw_read_entry(qfw_dev, FW_CFG_KERNEL_DATA,
> > 39 le32_to_cpu(kernel_size), data_addr);
> > >>> CID 331156:  Incorrect expression  (UNUSED_VALUE)
> > >>> Assigning value from "(__u32)(__le32)kernel_size" to "data_addr" 
> > >>> here, but that stored value is overwritten before it can be used.
> > 40  data_addr += le32_to_cpu(kernel_size);
> > 41 
> > 42  data_addr = initrd_addr;
> > 43  qfw_read_entry(qfw_dev, FW_CFG_INITRD_SIZE, 4, &initrd_size);
> > 44  if (initrd_size == 0) {
> > 45  printf("warning: no initrd available\n");
> 
> This is unchanged since 2016 and I think is fine to leave as-is.  The
> data_addr increment goes together with the qfw_read_entry() to keep
> advancing the data_addr pointer correctly.
> 
> It does get immediately thrown away in this case, but if we moved any
> part of this around or changed it we'd want to keep it, so the warning
> is likely best ignored.

Thanks, I'll mark it as intentional in the dashboard.

-- 
Tom


signature.asc
Description: PGP signature

[PATCH] efi_loader: capsule: return a corret error code at find_boot_device()

[AKASHI Takahiro]

In case of failure at efi_get_variable_int("BootOrder"), we should
skip examining boot option variables and return an appropriate error
code which is the one the function returned.

Fixes: CID 331153 Code maintainability issues  (UNUSED_VALUE)
Signed-off-by: AKASHI Takahiro 
---
 lib/efi_loader/efi_capsule.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
index 691eda5e0d14..2d10f47bff24 100644
--- a/lib/efi_loader/efi_capsule.c
+++ b/lib/efi_loader/efi_capsule.c
@@ -685,7 +685,6 @@ skip:
efi_free_pool(boot_dev);
boot_dev = NULL;
}
-out:
if (boot_dev) {
u16 *path_str;
 
@@ -703,6 +702,7 @@ out:
} else {
ret = EFI_NOT_FOUND;
}
+out:
free(boot_order);
 
return ret;
-- 
2.31.0

Re: [PATCH v2 07/13] mmc: synquacer: Add SynQuacer F_SDH30 SDHCI driver

[Masami Hiramatsu]

Hi Jaehoon,

Thanks for your comments.

2021年4月20日(火) 7:05 Jaehoon Chung :
>
> Hi Masami,
>
> On 4/17/21 8:38 AM, Masami Hiramatsu wrote:
> > From: Jassi Brar 
> >
> > Signed-off-by: Jassi Brar 
> > Signed-off-by: Masami Hiramatsu 
> > ---
> >  drivers/mmc/Kconfig   |   10 ++
> >  drivers/mmc/Makefile  |1 +
> >  drivers/mmc/f_sdh30.c |   81 
> > +
> >  drivers/mmc/sdhci.c   |9 +
> >  4 files changed, 101 insertions(+)
> >  create mode 100644 drivers/mmc/f_sdh30.c
> >
> > diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> > index f8ca52efb6..a9ae419e41 100644
> > --- a/drivers/mmc/Kconfig
> > +++ b/drivers/mmc/Kconfig
> > @@ -549,6 +549,16 @@ config MMC_SDHCI_IPROC
> >
> > If unsure, say N.
> >
> > +config F_SDH30_SDHCI
>
> MMS_SDHCI_F_SDH30 or MMC_SDHCI_xxx.

OK. I'll change it.

>
> > + bool "SDHCI support for Fujitsu Semiconductor F_SDH30"
> > + depends on BLK && DM_MMC
> > + depends on MMC_SDHCI
> > + help
> > +   This selects the Secure Digital Host Controller Interface (SDHCI)
> > +   Needed by some Fujitsu SoC for MMC / SD / SDIO support.
> > +   If you have a controller with this interface, say Y or M here.
> > +   If unsure, say N.
> > +
> >  config MMC_SDHCI_KONA
> >   bool "SDHCI support on Broadcom KONA platform"
> >   depends on MMC_SDHCI
> > diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
> > index 89d6af3db3..b48a76ba94 100644
> > --- a/drivers/mmc/Makefile
> > +++ b/drivers/mmc/Makefile
> > @@ -76,3 +76,4 @@ obj-$(CONFIG_MMC_UNIPHIER)  += tmio-common.o 
> > uniphier-sd.o
> >  obj-$(CONFIG_RENESAS_SDHI)   += tmio-common.o renesas-sdhi.o
> >  obj-$(CONFIG_MMC_BCM2835)+= bcm2835_sdhost.o
> >  obj-$(CONFIG_MMC_MTK)+= mtk-sd.o
> > +obj-$(CONFIG_F_SDH30_SDHCI)  += f_sdh30.o
> > diff --git a/drivers/mmc/f_sdh30.c b/drivers/mmc/f_sdh30.c
> > new file mode 100644
> > index 00..44c6521bfe
> > --- /dev/null
> > +++ b/drivers/mmc/f_sdh30.c
> > @@ -0,0 +1,81 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Socionext F_SDH30 eMMC driver
> > + * Copyright 2021 Linaro Ltd.
> > + * Copyright 2021 Socionext, Inc.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +struct f_sdh30_plat {
> > + struct mmc_config cfg;
> > + struct mmc mmc;
> > +};
> > +
> > +DECLARE_GLOBAL_DATA_PTR;
> > +
> > +static int f_sdh30_probe(struct udevice *dev)
>
> xxx_sdhci_probe().

Let me confirm. The controller name is F_SDH30, so it is better to be
f_sdh30_sdhci_probe(), correct?

> > +{
> > + struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
> > + struct f_sdh30_plat *plat = dev_get_plat(dev);
> > + struct sdhci_host *host = dev_get_priv(dev);
> > + int ret;
> > +
> > + ret = mmc_of_parse(dev, &plat->cfg);
> > + if (ret)
> > + return ret;
> > +
> > + host->mmc = &plat->mmc;
> > + host->mmc->dev = dev;
> > + host->mmc->priv = host;
> > +
> > + ret = sdhci_setup_cfg(&plat->cfg, host, 2, 40);
> > + if (ret)
> > + return ret;
> > +
> > + upriv->mmc = host->mmc;
> > +
> > + mmc_set_clock(host->mmc, host->mmc->cfg->f_min, MMC_CLK_ENABLE);
> > +
> > + return sdhci_probe(dev);
> > +}
> > +
> > +static int f_sdh30_of_to_plat(struct udevice *dev)
> > +{
> > + struct sdhci_host *host = dev_get_priv(dev);
> > +
> > + host->name = strdup(dev->name);
> > + host->ioaddr = dev_read_addr_ptr(dev);
> > + host->bus_width = dev_read_u32_default(dev, "bus-width", 4);
> > + host->index = dev_read_u32_default(dev, "index", 0);
> > +
> > + return 0;
> > +}
> > +
> > +static int f_sdh30_bind(struct udevice *dev)
> > +{
> > + struct f_sdh30_plat *plat = dev_get_plat(dev);
> > +
> > + return sdhci_bind(dev, &plat->mmc, &plat->cfg);
> > +}
> > +
> > +static const struct udevice_id f_sdh30_mmc_ids[] = {
> > + { .compatible = "fujitsu,mb86s70-sdhci-3.0" },
> > + { }
> > +};
> > +
> > +U_BOOT_DRIVER(f_sdh30_drv) = {
> > + .name   = "f_sdh30_sdhci",
> > + .id = UCLASS_MMC,
> > + .of_match   = f_sdh30_mmc_ids,
> > + .of_to_plat = f_sdh30_of_to_plat,
> > + .ops= &sdhci_ops,
> > + .bind   = f_sdh30_bind,
> > + .probe  = f_sdh30_probe,
> > + .priv_auto  = sizeof(struct sdhci_host),
> > + .plat_auto  = sizeof(struct f_sdh30_plat),
> > +};
> > diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
> > index d9ab6a0a83..f038debc6c 100644
> > --- a/drivers/mmc/sdhci.c
> > +++ b/drivers/mmc/sdhci.c
> > @@ -708,6 +708,15 @@ static int sdhci_init(struct mmc *mmc)
> >
> >   sdhci_set_power(host, fls(mmc->cfg->voltages) - 1);
> >
> > + if (IS_ENABLED(CONFIG_F_SDH30_SDHCI)) {
>
> I don't want to add specific sdhci driver configuration in sdhci.c.
>
> According to below com

Re: [scan-ad...@coverity.com: New Defects reported by Coverity Scan for Das U-Boot]

[Asherah Connor]

Looking at cmd/qfw.c as I touched it last:

On 21/04/19 08:04:p, Tom Rini wrote:
> ** CID 331156:  Incorrect expression  (UNUSED_VALUE)
> /cmd/qfw.c: 40 in qemu_fwcfg_cmd_setup_kernel()
> 
> 
> 
> *** CID 331156:  Incorrect expression  (UNUSED_VALUE)
> /cmd/qfw.c: 40 in qemu_fwcfg_cmd_setup_kernel()
> 34qfw_read_entry(qfw_dev, FW_CFG_SETUP_DATA,
> 35   le32_to_cpu(setup_size), data_addr);
> 36data_addr += le32_to_cpu(setup_size);
> 37 
> 38qfw_read_entry(qfw_dev, FW_CFG_KERNEL_DATA,
> 39   le32_to_cpu(kernel_size), data_addr);
> >>> CID 331156:  Incorrect expression  (UNUSED_VALUE)
> >>> Assigning value from "(__u32)(__le32)kernel_size" to "data_addr" 
> >>> here, but that stored value is overwritten before it can be used.
> 40data_addr += le32_to_cpu(kernel_size);
> 41 
> 42data_addr = initrd_addr;
> 43qfw_read_entry(qfw_dev, FW_CFG_INITRD_SIZE, 4, &initrd_size);
> 44if (initrd_size == 0) {
> 45printf("warning: no initrd available\n");

This is unchanged since 2016 and I think is fine to leave as-is.  The
data_addr increment goes together with the qfw_read_entry() to keep
advancing the data_addr pointer correctly.

It does get immediately thrown away in this case, but if we moved any
part of this around or changed it we'd want to keep it, so the warning
is likely best ignored.

Asherah

Re: [PATCH V2 24/24] ARM: imx8m: verdin-imx8mm: Enable USB Host support

[Tim Harvey]

On Sun, Apr 11, 2021 at 9:35 AM Marek Vasut  wrote:
>
> Enable USB host support on MX8MM Verdin.
>
> Signed-off-by: Marek Vasut 
> Cc: Marcel Ziswiler 
> Cc: Max Krummenacher 
> Cc: Oleksandr Suvorov 
> ---
> V2: No change
> ---
>  configs/verdin-imx8mm_defconfig | 8 +++-
>  include/configs/verdin-imx8mm.h | 5 +
>  2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/configs/verdin-imx8mm_defconfig b/configs/verdin-imx8mm_defconfig
> index ea0b5978f1..c8c3420b6a 100644
> --- a/configs/verdin-imx8mm_defconfig
> +++ b/configs/verdin-imx8mm_defconfig
> @@ -37,7 +37,6 @@ CONFIG_SPL_BOARD_INIT=y
>  CONFIG_SPL_SEPARATE_BSS=y
>  CONFIG_SPL_I2C_SUPPORT=y
>  CONFIG_SPL_POWER_SUPPORT=y
> -CONFIG_SPL_USB_HOST_SUPPORT=y
>  CONFIG_SPL_WATCHDOG_SUPPORT=y
>  CONFIG_SYS_PROMPT="Verdin iMX8MM # "
>  # CONFIG_BOOTM_NETBSD is not set
> @@ -50,6 +49,7 @@ CONFIG_CMD_FUSE=y
>  CONFIG_CMD_GPIO=y
>  CONFIG_CMD_I2C=y
>  CONFIG_CMD_MMC=y
> +CONFIG_CMD_USB=y
>  CONFIG_CMD_CACHE=y
>  CONFIG_CMD_UUID=y
>  CONFIG_CMD_REGULATOR=y
> @@ -89,6 +89,8 @@ CONFIG_MII=y
>  CONFIG_PINCTRL=y
>  CONFIG_SPL_PINCTRL=y
>  CONFIG_PINCTRL_IMX8M=y
> +CONFIG_POWER_DOMAIN=y
> +CONFIG_IMX8M_POWER_DOMAIN=y
>  CONFIG_DM_PMIC=y
>  CONFIG_SPL_DM_PMIC_PCA9450=y
>  CONFIG_DM_PMIC_PFUZE100=y
> @@ -101,5 +103,9 @@ CONFIG_SPL_SYSRESET=y
>  CONFIG_SYSRESET_PSCI=y
>  CONFIG_SYSRESET_WATCHDOG=y
>  CONFIG_DM_THERMAL=y
> +CONFIG_USB=y
> +CONFIG_DM_USB=y
> +# CONFIG_SPL_DM_USB is not set
> +CONFIG_USB_EHCI_HCD=y
>  CONFIG_IMX_WATCHDOG=y
>  CONFIG_OF_LIBFDT_OVERLAY=y
> diff --git a/include/configs/verdin-imx8mm.h b/include/configs/verdin-imx8mm.h
> index 4751bf5a5a..e2a817891c 100644
> --- a/include/configs/verdin-imx8mm.h
> +++ b/include/configs/verdin-imx8mm.h
> @@ -117,5 +117,10 @@
>  #define FEC_QUIRK_ENET_MAC
>  #define IMX_FEC_BASE   0x30BE
>
> +/* USB Configs */
> +#define CONFIG_EHCI_HCD_INIT_AFTER_RESET
> +#define CONFIG_MXC_USB_PORTSC  (PORT_PTS_UTMI | PORT_PTS_PTW)
> +#define CONFIG_USB_MAX_CONTROLLER_COUNT 2
> +
>  #endif /*_VERDIN_IMX8MM_H */
>
> --
> 2.30.2
>

Marek,

Thanks for your work on USB support for IMX8M!

I'm attempting to add USB support to the venice board following this
example but I think there are still some things missing from the dt to
make this work. I find that mx6_parse_dt_adds failes; Looks like it is
required to have an alias that points to the phy but then it fails
because the phy doesn't have a reg. Also, it would see the
CONFIG_MXC_USB_PORTSC is no longer needed as that is now the default.

Best regards,

Tim

Re: [PATCH v2 07/13] mmc: synquacer: Add SynQuacer F_SDH30 SDHCI driver

[Jaehoon Chung]

Hi Masami,

On 4/17/21 8:38 AM, Masami Hiramatsu wrote:
> From: Jassi Brar 
> 
> Signed-off-by: Jassi Brar 
> Signed-off-by: Masami Hiramatsu 
> ---
>  drivers/mmc/Kconfig   |   10 ++
>  drivers/mmc/Makefile  |1 +
>  drivers/mmc/f_sdh30.c |   81 
> +
>  drivers/mmc/sdhci.c   |9 +
>  4 files changed, 101 insertions(+)
>  create mode 100644 drivers/mmc/f_sdh30.c
> 
> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> index f8ca52efb6..a9ae419e41 100644
> --- a/drivers/mmc/Kconfig
> +++ b/drivers/mmc/Kconfig
> @@ -549,6 +549,16 @@ config MMC_SDHCI_IPROC
>  
> If unsure, say N.
>  
> +config F_SDH30_SDHCI

MMS_SDHCI_F_SDH30 or MMC_SDHCI_xxx. 

> + bool "SDHCI support for Fujitsu Semiconductor F_SDH30"
> + depends on BLK && DM_MMC
> + depends on MMC_SDHCI
> + help
> +   This selects the Secure Digital Host Controller Interface (SDHCI)
> +   Needed by some Fujitsu SoC for MMC / SD / SDIO support.
> +   If you have a controller with this interface, say Y or M here.
> +   If unsure, say N.
> +
>  config MMC_SDHCI_KONA
>   bool "SDHCI support on Broadcom KONA platform"
>   depends on MMC_SDHCI
> diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
> index 89d6af3db3..b48a76ba94 100644
> --- a/drivers/mmc/Makefile
> +++ b/drivers/mmc/Makefile
> @@ -76,3 +76,4 @@ obj-$(CONFIG_MMC_UNIPHIER)  += tmio-common.o 
> uniphier-sd.o
>  obj-$(CONFIG_RENESAS_SDHI)   += tmio-common.o renesas-sdhi.o
>  obj-$(CONFIG_MMC_BCM2835)+= bcm2835_sdhost.o
>  obj-$(CONFIG_MMC_MTK)+= mtk-sd.o
> +obj-$(CONFIG_F_SDH30_SDHCI)  += f_sdh30.o
> diff --git a/drivers/mmc/f_sdh30.c b/drivers/mmc/f_sdh30.c
> new file mode 100644
> index 00..44c6521bfe
> --- /dev/null
> +++ b/drivers/mmc/f_sdh30.c
> @@ -0,0 +1,81 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Socionext F_SDH30 eMMC driver
> + * Copyright 2021 Linaro Ltd.
> + * Copyright 2021 Socionext, Inc.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct f_sdh30_plat {
> + struct mmc_config cfg;
> + struct mmc mmc;
> +};
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +static int f_sdh30_probe(struct udevice *dev)

xxx_sdhci_probe().

> +{
> + struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
> + struct f_sdh30_plat *plat = dev_get_plat(dev);
> + struct sdhci_host *host = dev_get_priv(dev);
> + int ret;
> +
> + ret = mmc_of_parse(dev, &plat->cfg);
> + if (ret)
> + return ret;
> +
> + host->mmc = &plat->mmc;
> + host->mmc->dev = dev;
> + host->mmc->priv = host;
> +
> + ret = sdhci_setup_cfg(&plat->cfg, host, 2, 40);
> + if (ret)
> + return ret;
> +
> + upriv->mmc = host->mmc;
> +
> + mmc_set_clock(host->mmc, host->mmc->cfg->f_min, MMC_CLK_ENABLE);
> +
> + return sdhci_probe(dev);
> +}
> +
> +static int f_sdh30_of_to_plat(struct udevice *dev)
> +{
> + struct sdhci_host *host = dev_get_priv(dev);
> +
> + host->name = strdup(dev->name);
> + host->ioaddr = dev_read_addr_ptr(dev);
> + host->bus_width = dev_read_u32_default(dev, "bus-width", 4);
> + host->index = dev_read_u32_default(dev, "index", 0);
> +
> + return 0;
> +}
> +
> +static int f_sdh30_bind(struct udevice *dev)
> +{
> + struct f_sdh30_plat *plat = dev_get_plat(dev);
> +
> + return sdhci_bind(dev, &plat->mmc, &plat->cfg);
> +}
> +
> +static const struct udevice_id f_sdh30_mmc_ids[] = {
> + { .compatible = "fujitsu,mb86s70-sdhci-3.0" },
> + { }
> +};
> +
> +U_BOOT_DRIVER(f_sdh30_drv) = {
> + .name   = "f_sdh30_sdhci",
> + .id = UCLASS_MMC,
> + .of_match   = f_sdh30_mmc_ids,
> + .of_to_plat = f_sdh30_of_to_plat,
> + .ops= &sdhci_ops,
> + .bind   = f_sdh30_bind,
> + .probe  = f_sdh30_probe,
> + .priv_auto  = sizeof(struct sdhci_host),
> + .plat_auto  = sizeof(struct f_sdh30_plat),
> +};
> diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
> index d9ab6a0a83..f038debc6c 100644
> --- a/drivers/mmc/sdhci.c
> +++ b/drivers/mmc/sdhci.c
> @@ -708,6 +708,15 @@ static int sdhci_init(struct mmc *mmc)
>  
>   sdhci_set_power(host, fls(mmc->cfg->voltages) - 1);
>  
> + if (IS_ENABLED(CONFIG_F_SDH30_SDHCI)) {

I don't want to add specific sdhci driver configuration in sdhci.c.

According to below comment and Specification,
it has to delay 1ms. Can it be removed the above condition checking?

> + /*
> +  * Reference to Part1 Physical Layer Simplified Specification
> +  * Ver 3.01, 6.4.1 Power Up
> +  * This delay must be at least 74 clock sizes, or 1 ms.
> +  */
> + udelay(1000);

I don't have any objection about this, If possible, it needs to calculate 
clock-cycle with real clock value in future.

Best Regar

[PATCH] arm: dts: stm32mp157c-odyssey-som: enable the RNG1

[Grzegorz Szymaszek]

Enable the true random number generator. It can be used, for example, to
generate partition UUIDs when partitioning with the gpt command. The
generator is already enabled in the device trees of several other
STM32MP1‐based boards, like DKx or DHCOM.

Signed-off-by: Grzegorz Szymaszek 
Cc: Patrice Chotard 
Cc: Patrick Delaunay 
---
 arch/arm/dts/stm32mp157c-odyssey-som.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/dts/stm32mp157c-odyssey-som.dtsi 
b/arch/arm/dts/stm32mp157c-odyssey-som.dtsi
index 83ff2e7ce1..e367a311c4 100644
--- a/arch/arm/dts/stm32mp157c-odyssey-som.dtsi
+++ b/arch/arm/dts/stm32mp157c-odyssey-som.dtsi
@@ -258,6 +258,10 @@
status = "okay";
 };
 
+&rng1 {
+   status = "okay";
+};
+
 &sdmmc2 {
pinctrl-names = "default", "opendrain", "sleep";
pinctrl-0 = <&sdmmc2_b4_pins_a>;
-- 
2.30.2

[PATCH] sysinfo.h: Add re-inclusion guard

[Tom Rini]

Add #ifndef __SYSINFO_H__ ... #endif to prevent re-inclusion of this
file.

Signed-off-by: Tom Rini 
---
 include/sysinfo.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/sysinfo.h b/include/sysinfo.h
index 7b2114088003..b140d742e93d 100644
--- a/include/sysinfo.h
+++ b/include/sysinfo.h
@@ -4,6 +4,9 @@
  * Mario Six,  Guntermann & Drunck GmbH, mario@gdsys.cc
  */
 
+#ifndef __SYSINFO_H__
+#define __SYSINFO_H__
+
 struct udevice;
 
 /*
@@ -236,3 +239,4 @@ static inline int sysinfo_get_fit_loadable(struct udevice 
*dev, int index,
 }
 
 #endif
+#endif
-- 
2.17.1

[PATCH 1/1] doc: fatinfo man-page

[Heinrich Schuchardt]

Provide a man-page for the fatinfo command.

The .rst file was lost in patch 15d9694600fe ("doc: fatinfo man-page").

Fixes: 15d9694600fe ("doc: fatinfo man-page")
Signed-off-by: Heinrich Schuchardt 
---
 doc/usage/fatinfo.rst | 51 +++
 1 file changed, 51 insertions(+)
 create mode 100644 doc/usage/fatinfo.rst

diff --git a/doc/usage/fatinfo.rst b/doc/usage/fatinfo.rst
new file mode 100644
index 00..af2eba4344
--- /dev/null
+++ b/doc/usage/fatinfo.rst
@@ -0,0 +1,51 @@
+.. SPDX-License-Identifier: GPL-2.0+:
+
+fatinfo command
+===
+
+Synopsis
+
+
+::
+
+fatinfo  
+
+Description
+---
+
+The fatinfo command displays information about a FAT partition.
+
+interface
+interface for accessing the block device (mmc, sata, scsi, usb, )
+
+dev
+device number
+
+part
+partition number, defaults to 1
+
+Example
+---
+
+Here is the output for a partition on a 32 GB SD-Card:
+
+::
+
+=> fatinfo mmc 0:1
+Interface:  MMC
+  Device 0: Vendor: Man 1b Snr 97560602 Rev: 13.8 Prod: EB1QT0
+Type: Removable Hard Disk
+Capacity: 30528.0 MB = 29.8 GB (62521344 x 512)
+Filesystem: FAT32 "MYDISK "
+=>
+
+Configuration
+-
+
+The fatinfo command is only available if CONFIG_CMD_FAT=y.
+
+Return value
+
+
+The return value $? is set to 0 (true) if the partition is a FAT partition.
+Otherwise it is set to 1 (false).
--
2.30.2

Re: [PATCH] efi: Fix ESRT refresh after Capsule update

[Heinrich Schuchardt]

On 4/19/21 3:54 PM, Jose Marinho wrote:

Indicated by Coverity Scan CID 331147

The ESRT was being refreshed in situations where the UpdateCapsule
procedure failed. In that scenario:

1) the ESRT refresh was superfluous.
2) a failed ESRT refresh return code overwrites the UpdateCapsule error
return code.

This commit ensures that the ESRT is only refreshed when the
UpdateCapsule performs successfully.

CC: Heinrich Schuchardt 
CC: Sughosh Ganu 
CC: AKASHI Takahiro 
CC: Tom Rini 
CC: Andre Przywara 
CC: n...@arm.com

Signed-off-by: Jose Marinho 


Reviewed-by: Heinrich Schuchardt 


---
  lib/efi_loader/efi_capsule.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
index 691eda5e0d..a984c347e1 100644
--- a/lib/efi_loader/efi_capsule.c
+++ b/lib/efi_loader/efi_capsule.c
@@ -481,7 +481,6 @@ efi_status_t EFIAPI efi_update_capsule(
if (ret != EFI_SUCCESS)
goto out;
}
-out:

if (IS_ENABLED(CONFIG_EFI_ESRT)) {
/* Rebuild the ESRT to reflect any updated FW images. */
@@ -489,6 +488,7 @@ out:
if (ret != EFI_SUCCESS)
log_warning("EFI Capsule: failed to update ESRT\n");
}
+out:

return EFI_EXIT(ret);
  }

Re: [PATCH] cmd: net: add a 'net list' command to list network devs

[Ramon Fried]

On Sat, Apr 17, 2021 at 12:25 AM Tim Harvey  wrote:
>
> In a system with multiple network controllers it can be difficult
> to know the names of the various devices available. This is especially
> true for USB ether devices as they do not display device names upon
> detection.
>
> This is being added as a net sub-system in case other commands may
> want to be added or moved here.
>
> Example:
> U-Boot > net
> net - NET sub-system
>
> Usage:
> net list - list available devices
>
> U-Boot > net list
> eth0 : ethernet@2188000 00:d0:12:98:f5:47 active
> eth1 : e1000#0 00:d0:12:98:f5:48
> eth2 : asix_eth 8c:ae:4c:f5:84:9d
> eth3 : asix_eth 8c:ae:4c:f9:41:e3
>
> Signed-off-by: Tim Harvey 
> ---
>  cmd/net.c | 44 
>  1 file changed, 44 insertions(+)
>
> diff --git a/cmd/net.c b/cmd/net.c
> index beb2877dfd..e51bc443f7 100644
> --- a/cmd/net.c
> +++ b/cmd/net.c
> @@ -10,6 +10,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -480,3 +481,46 @@ U_BOOT_CMD(
>  );
>
>  #endif  /* CONFIG_CMD_LINK_LOCAL */
> +
> +static int do_net_list(struct cmd_tbl *cmdtp, int flag, int argc, char 
> *const argv[])
> +{
> +   const struct udevice *current = eth_get_dev();
> +   unsigned char env_enetaddr[ARP_HLEN];
> +   const struct udevice *dev;
> +   struct uclass *uc;
> +
> +   uclass_id_foreach_dev(UCLASS_ETH, dev, uc) {
> +   eth_env_get_enetaddr_by_index("eth", dev_seq(dev), 
> env_enetaddr);
> +   printf("eth%d : %s %pM %s\n", dev_seq(dev), dev->name, 
> env_enetaddr,
> +  current == dev ? "active" : "");
> +   }
> +   return CMD_RET_SUCCESS;
> +}
> +
> +static struct cmd_tbl cmd_net[] = {
> +   U_BOOT_CMD_MKENT(list, 1, 0, do_net_list, "", ""),
> +};
> +
> +static int do_net(struct cmd_tbl *cmdtp, int flag, int argc, char *const 
> argv[])
> +{
> +   struct cmd_tbl *cp;
> +
> +   cp = find_cmd_tbl(argv[1], cmd_net, ARRAY_SIZE(cmd_net));
> +
> +   /* Drop the net command */
> +   argc--;
> +   argv++;
> +
> +   if (!cp || argc > cp->maxargs)
> +   return CMD_RET_USAGE;
> +   if (flag == CMD_FLAG_REPEAT && !cmd_is_repeatable(cp))
> +   return CMD_RET_SUCCESS;
> +
> +   return cp->cmd(cmdtp, flag, argc, argv);
> +}
> +
> +U_BOOT_CMD(
> +   net, 2, 1, do_net,
> +   "NET sub-system",
> +   "list - list available devices\n"
> +);
> --
> 2.17.1
>
Excellent ! Thanks.

Reviewed-by: Ramon Fried 

Re: [PATCH] Revert "spl: Drop bd_info in the data section"

[Tom Rini]

On Thu, Apr 08, 2021 at 11:56:11AM -0500, Alexandru Gagniuc wrote:

> This reverts commit 38d6b7ebdaee3e0e8426ef1b9df88bdce8ae2e75.
> 
> struct global_data contains a pointer to the bd_info structure. This
> pointer was populated spl_set_bd() to a pre-allocated bd_info in the
> ".data" section. The referenced commit replaced this mechanism to one
> that uses malloc(). That new mechanism is only used if SPL_ALLOC_BD=y.
> which very few boards do.
> 
> The result is that (struct global_data)->bd is NULL in SPL on most
> platforms. This breaks falcon mode, since arch_fixup_fdt() tries to
> access (struct global_data)->bd and set the "/memory" node in the
> devicetree. The result is that the "/memory" node contains garbage
> values, causing linux to panic() as it sets up the page table.
> 
> Instead of trying to fix the mess, potentially causing other issues,
> revert to the code that worked, while this change is reworked.
> 
> Signed-off-by: Alexandru Gagniuc 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PULL] u-boot-atmel-2021.07-b

[Tom Rini]

On Mon, Apr 19, 2021 at 01:24:54PM +, eugen.hris...@microchip.com wrote:

> Hello Tom,
> 
> Please pull tag u-boot-atmel-2021.07-b , the second set of atmel 
> features for the 2021.07 cycle.
> 
> This small feature set include support for 5th PIO bank on pio4 pinctrl 
> driver and a fix for the SPL on sama5d3.
> 
> Thanks,
> Eugen
> 
> The following changes since commit 3a9aaefcaa3efc2a1cef86fbe0bf229a1bff9902:
> 
>Merge tag 'efi-2021-07-rc1-2' of 
> https://source.denx.de/u-boot/custodians/u-boot-efi (2021-04-18 08:47:27 
> -0400)
> 
> are available in the Git repository at:
> 
>https://source.denx.de/u-boot/custodians/u-boot-atmel.git 
> tags/u-boot-atmel-2021.07-b
> 
> for you to fetch changes up to b0080ae1bbfe78caf9cc43cef2b8fdcc75cc4320:
> 
>ARM: dts: at91: sama5d3: add u-boot properties to sama5d3 pit timer 
> (2021-04-19 10:38:52 +0300)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

[PULL] u-boot-atmel-2021.07-b

[Eugen.Hristev]

Hello Tom,

Please pull tag u-boot-atmel-2021.07-b , the second set of atmel 
features for the 2021.07 cycle.

This small feature set include support for 5th PIO bank on pio4 pinctrl 
driver and a fix for the SPL on sama5d3.

Thanks,
Eugen

The following changes since commit 3a9aaefcaa3efc2a1cef86fbe0bf229a1bff9902:

   Merge tag 'efi-2021-07-rc1-2' of 
https://source.denx.de/u-boot/custodians/u-boot-efi (2021-04-18 08:47:27 
-0400)

are available in the Git repository at:

   https://source.denx.de/u-boot/custodians/u-boot-atmel.git 
tags/u-boot-atmel-2021.07-b

for you to fetch changes up to b0080ae1bbfe78caf9cc43cef2b8fdcc75cc4320:

   ARM: dts: at91: sama5d3: add u-boot properties to sama5d3 pit timer 
(2021-04-19 10:38:52 +0300)


Second set of u-boot-atmel features for 2021.07 cycle


Eugen Hristev (2):
   gpio: atmel_pio4: add support for sama7g5 pio4 version with 5 banks
   ARM: dts: at91: sama7g5: change pinctrl compatible to sama7g5

Manuel Reis (1):
   ARM: dts: at91: sama5d3: add u-boot properties to sama5d3 pit timer

  arch/arm/dts/sama5d3.dtsi |  1 +
  arch/arm/dts/sama7g5.dtsi |  2 +-
  drivers/gpio/atmel_pio4.c | 22 ++
  3 files changed, 24 insertions(+), 1 deletion(-)

Re: [PATCH 1/3] clk: mediatek: Add MT8175 clock driver

[Fabien Parent]

Please do NOT merge this patch series. MTK asked me to resend this
patch series with a different SoC Part-Number.

On Tue, Mar 30, 2021 at 4:31 PM Fabien Parent  wrote:
>
> Add the topckgen, apmixedsys and infracfg clock driver for the MT8175
> SoC.
>
> Signed-off-by: Fabien Parent 
> ---
>  drivers/clk/mediatek/Makefile  |   1 +
>  drivers/clk/mediatek/clk-mt8175.c  | 785 +
>  include/dt-bindings/clock/mt8175-clk.h | 392 
>  3 files changed, 1178 insertions(+)
>  create mode 100644 drivers/clk/mediatek/clk-mt8175.c
>  create mode 100644 include/dt-bindings/clock/mt8175-clk.h
>
> diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
> index 522e72422144..0f3135eca39c 100644
> --- a/drivers/clk/mediatek/Makefile
> +++ b/drivers/clk/mediatek/Makefile
> @@ -7,6 +7,7 @@ obj-$(CONFIG_MT8512) += clk-mt8512.o
>  obj-$(CONFIG_TARGET_MT7623) += clk-mt7623.o
>  obj-$(CONFIG_TARGET_MT7622) += clk-mt7622.o
>  obj-$(CONFIG_TARGET_MT7629) += clk-mt7629.o
> +obj-$(CONFIG_TARGET_MT8175) += clk-mt8175.o
>  obj-$(CONFIG_TARGET_MT8183) += clk-mt8183.o
>  obj-$(CONFIG_TARGET_MT8516) += clk-mt8516.o
>  obj-$(CONFIG_TARGET_MT8518) += clk-mt8518.o
> diff --git a/drivers/clk/mediatek/clk-mt8175.c 
> b/drivers/clk/mediatek/clk-mt8175.c
> new file mode 100644
> index ..cb5841181d2d
> --- /dev/null
> +++ b/drivers/clk/mediatek/clk-mt8175.c
> @@ -0,0 +1,785 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * MediaTek clock driver for MT8175 SoC
> + *
> + * Copyright (C) 2021 BayLibre, SAS
> + * Copyright (c) 2021 MediaTek Inc.
> + * Author: Fabien Parent 
> + * Author: Weiyi Lu 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "clk-mtk.h"
> +
> +#define MT8175_PLL_FMAX(3800UL * MHZ)
> +#define MT8175_PLL_FMIN(1500UL * MHZ)
> +
> +/* apmixedsys */
> +#define PLL(_id, _reg, _pwr_reg, _en_mask, _flags, _pcwbits, _pd_reg,  \
> +   _pd_shift, _pcw_reg, _pcw_shift) {  \
> +   .id = _id,  \
> +   .reg = _reg,\
> +   .pwr_reg = _pwr_reg,\
> +   .en_mask = _en_mask,\
> +   .rst_bar_mask = BIT(23),\
> +   .fmax = MT8175_PLL_FMAX,\
> +   .flags = _flags,\
> +   .pcwbits = _pcwbits,\
> +   .pcwibits = 8,  \
> +   .pd_reg = _pd_reg,  \
> +   .pd_shift = _pd_shift,  \
> +   .pcw_reg = _pcw_reg,\
> +   .pcw_shift = _pcw_shift,\
> +   }
> +
> +static const struct mtk_pll_data apmixed_plls[] = {
> +   PLL(CLK_APMIXED_ARMPLL, 0x030C, 0x0318, 0x0001, 0, 22, 0x0310, 24,
> +   0x0310, 0),
> +   PLL(CLK_APMIXED_MAINPLL, 0x0228, 0x0234, 0xFF01, HAVE_RST_BAR, 22,
> +   0x022C, 24, 0x022C, 0),
> +   PLL(CLK_APMIXED_UNIVPLL, 0x0208, 0x0214, 0xFF01, HAVE_RST_BAR, 22,
> +   0x020C, 24, 0x020C, 0),
> +   PLL(CLK_APMIXED_MFGPLL, 0x0218, 0x0224, 0x0001, 0, 22, 0x021C, 24,
> +   0x021C, 0),
> +   PLL(CLK_APMIXED_MSDCPLL, 0x0350, 0x035C, 0x0001, 0, 22, 0x0354, 
> 24,
> +   0x0354, 0),
> +   PLL(CLK_APMIXED_MMPLL, 0x0330, 0x033C, 0x0001, 0, 22, 0x0334, 24,
> +   0x0334, 0),
> +   PLL(CLK_APMIXED_APLL1, 0x031C, 0x032C, 0x0001, 0, 32, 0x0320, 24,
> +   0x0324, 0),
> +   PLL(CLK_APMIXED_APLL2, 0x0360, 0x0370, 0x0001, 0, 32, 0x0364, 24,
> +   0x0368, 0),
> +   PLL(CLK_APMIXED_LVDSPLL, 0x0374, 0x0380, 0x0001, 0, 22, 0x0378, 
> 24,
> +   0x0378, 0),
> +   PLL(CLK_APMIXED_DSPPLL, 0x0390, 0x039C, 0x0001, 0, 22, 0x0394, 24,
> +   0x0394, 0),
> +   PLL(CLK_APMIXED_APUPLL, 0x03A0, 0x03AC, 0x0001, 0, 22, 0x03A4, 24,
> +   0x03A4, 0),
> +};
> +
> +static const struct mtk_fixed_clk top_fixed_clks[] = {
> +   FIXED_CLK(CLK_TOP_CLK_NULL, CLK_XTAL, 0),
> +   FIXED_CLK(CLK_TOP_DSI0_LNTC_DSICK, CLK_TOP_CLK26M, 7500),
> +   FIXED_CLK(CLK_TOP_VPLL_DPIX, CLK_TOP_CLK26M, 7500),
> +   FIXED_CLK(CLK_TOP_LVDSTX_CLKDIG_CTS, CLK_TOP_CLK26M, 5250),
> +   FIXED_CLK(CLK_TOP_CLK26M, CLK_XTAL, 2600),
> +   FIXED_CLK(CLK_TOP_CLK32K, CLK_XTAL, 32000),
> +};
> +
> +static const struct mtk_fixed_factor top_fixed_divs[] = {
> +   FACTOR(CLK_TOP_SYSPLL_D2, CLK_APMIXED_MAINPLL, 1, 2,
> +  CLK_PARENT_APMIXED),
> +   FACTOR(CLK_TOP_SYSPLL1_D2, CLK_APMIXED_MAINPLL, 1, 4,
> +  

Re: [PATCH] sunxi: Select environment MMC based on boot device

[Andre Przywara]

On Sun, 18 Apr 2021 22:16:21 -0500
Samuel Holland  wrote:

(CC:ing Maxime)

Hi,

> Currently, the environment is always stored in eMMC if eMMC is enabled
> in the config. This means images written to SD and eMMC will cross-
> contaminate their environments unless the configuration is changed.
> 
> By dropping the device number from the environment location string and
> implementing mmc_get_env_dev, we will always use the environment from
> the boot device when booting from SD/eMMC.

Yeah, indeed, thanks for sending this. I will have a closer look and
test tonight.

AFAIR Maxime had reservations towards this approach in the past, he
mentioned that this fixed environment location had a use case?

Maxime, can you comment whether this is still needed? I think being
able to just "dd" (or "mmc write" in U-Boot) the very same image to an
eMMC is a very compelling use case, to install firmware from a bootable 
SD card. I have patches to a similar effect, including loading the env
from SPI when booting from SPI, and a U-Boot menu to make this user
friendly, so would like to know whether we can push this forward.

Cheers,
Andre.

> 
> Signed-off-by: Samuel Holland 
> ---
>  board/sunxi/board.c | 14 ++
>  env/Kconfig |  3 +--
>  2 files changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index 718bc313ae..59f7c2c5f1 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -624,6 +624,20 @@ int board_mmc_init(struct bd_info *bis)
>  
>   return 0;
>  }
> +
> +#if CONFIG_MMC_SUNXI_SLOT_EXTRA != -1
> +int mmc_get_env_dev(void)
> +{
> + switch (sunxi_get_boot_device()) {
> + case BOOT_DEVICE_MMC1:
> + return 0;
> + case BOOT_DEVICE_MMC2:
> + return 1;
> + default:
> + return CONFIG_SYS_MMC_ENV_DEV;
> + }
> +}
> +#endif
>  #endif
>  
>  #ifdef CONFIG_SPL_BUILD
> diff --git a/env/Kconfig b/env/Kconfig
> index b473d7cfe1..d7c787ad84 100644
> --- a/env/Kconfig
> +++ b/env/Kconfig
> @@ -430,10 +430,9 @@ config ENV_FAT_INTERFACE
>  config ENV_FAT_DEVICE_AND_PART
>   string "Device and partition for where to store the environemt in FAT"
>   depends on ENV_IS_IN_FAT
> + default ":auto" if ARCH_SUNXI
>   default "0:1" if TI_COMMON_CMD_OPTIONS
>   default "0:auto" if ARCH_ZYNQ || ARCH_ZYNQMP
> - default "0:auto" if ARCH_SUNXI && MMC_SUNXI_SLOT_EXTRA = -1
> - default "1:auto" if ARCH_SUNXI && MMC_SUNXI_SLOT_EXTRA != -1
>   default "0" if ARCH_AT91
>   help
> Define this to a string to specify the partition of the device. It can

[PULL u-boot] Please pull u-boot-amlogic-20210419

[Neil Armstrong]

Hi Tom,

This serie fixes Ethernet on Odroid-C2 and enables support for PCIe on the 
Khadas VIM3 & VIM3L
with all the necessary bits after Bin merged the PCIe driver.

The CI job is at 
https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic/pipelines/7216

Thanks,
Neil

The following changes since commit 3a9aaefcaa3efc2a1cef86fbe0bf229a1bff9902:

  Merge tag 'efi-2021-07-rc1-2' of 
https://source.denx.de/u-boot/custodians/u-boot-efi (2021-04-18 08:47:27 -0400)

are available in the Git repository at:

  https://source.denx.de/u-boot/custodians/u-boot-amlogic.git 
tags/u-boot-amlogic-20210419

for you to fetch changes up to fcf3c9deae1acfda81051c8c211fcbefd4217e1d:

  boards: amlogic: update documentation for PCIe support (2021-04-19 16:59:33 
+0200)


- fix Ethernet on Odroid-C2 by re-adding old bindings style PHY reset
- add G12A PCIe clock gates
- add G12A PCIe PHY OPs
- enable PCIe for Khadas VIM3/VIM3L boards DT
- enable PCIe and NVME for Khadas VIM3/VIM3L boards config
- update Amlogic board documentation for PCIe support


Neil Armstrong (6):
  clk: meson-g12a: add PCIe gates
  phy: meson-g12a-usb3-pcie: add support for PCIe ops
  arm: dts: meson-khadas-vim3: enable PCIe in U-boot
  configs: khadas-vim3: enable PCIe and NVMe
  configs: meson64: add NVME boot target
  boards: amlogic: update documentation for PCIe support

Stefan Agner (1):
  arm64: dts: meson: odroidc2: readd PHY reset properties

 arch/arm/dts/meson-gxbb-odroidc2-u-boot.dtsi |  6 +++
 arch/arm/dts/meson-khadas-vim3-u-boot.dtsi   |  4 ++
 configs/khadas-vim3_defconfig|  5 ++
 configs/khadas-vim3l_defconfig   |  5 ++
 doc/board/amlogic/index.rst  |  2 +
 drivers/clk/meson/g12a.c |  2 +
 drivers/phy/meson-g12a-usb3-pcie.c   | 81 ++--
 include/configs/meson64.h|  7 +++
 8 files changed, 108 insertions(+), 4 deletions(-)

Re: [PATCH] Revert "spl: Drop bd_info in the data section"

[Tom Rini]

On Tue, Apr 13, 2021 at 05:49:19AM +1200, Simon Glass wrote:
> Hi Tom, Alex,
> 
> On Tue, 13 Apr 2021 at 04:26, Tom Rini  wrote:
> >
> > On Mon, Apr 12, 2021 at 10:21:18AM -0500, Alex G. wrote:
> > >
> > >
> > > On 4/12/21 9:40 AM, Tom Rini wrote:
> > > > On Mon, Apr 12, 2021 at 08:51:11AM -0500, Alex G. wrote:
> > > > >
> > > > >
> > > > > On 4/12/21 8:25 AM, Tom Rini wrote:
> > > > > > On Fri, Apr 09, 2021 at 05:29:36PM -0700, Tim Harvey wrote:
> > > > > > > On Fri, Apr 9, 2021 at 1:53 PM Tom Rini  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Fri, Apr 09, 2021 at 03:24:41PM -0500, Adam Ford wrote:
> > > > > > > > > On Fri, Apr 9, 2021 at 2:20 PM Alex G.  
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Simon
> > > > > > > > > >
> > > > > > > > > > On 4/8/21 6:55 PM, Simon Glass wrote:
> > > > > > > > > > > Hi Alexandru,
> > > > > > > > > > >
> > > > > > > > > > > On Fri, 9 Apr 2021 at 04:56, Alexandru Gagniuc 
> > > > > > > > > > >  wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > This reverts commit 
> > > > > > > > > > > > 38d6b7ebdaee3e0e8426ef1b9df88bdce8ae2e75.
> > > > > > > > > > > >
> > > > > > > > > > > > struct global_data contains a pointer to the bd_info 
> > > > > > > > > > > > structure. This
> > > > > > > > > > > > pointer was populated spl_set_bd() to a pre-allocated 
> > > > > > > > > > > > bd_info in the
> > > > > > > > > > > > ".data" section. The referenced commit replaced this 
> > > > > > > > > > > > mechanism to one
> > > > > > > > > > > > that uses malloc(). That new mechanism is only used if 
> > > > > > > > > > > > SPL_ALLOC_BD=y.
> > > > > > > > > > > > which very few boards do.
> > > > > > > > > > > >
> > > > > > > > > > > > The result is that (struct global_data)->bd is NULL in 
> > > > > > > > > > > > SPL on most
> > > > > > > > > > > > platforms. This breaks falcon mode, since 
> > > > > > > > > > > > arch_fixup_fdt() tries to
> > > > > > > > > > > > access (struct global_data)->bd and set the "/memory" 
> > > > > > > > > > > > node in the
> > > > > > > > > > > > devicetree. The result is that the "/memory" node 
> > > > > > > > > > > > contains garbage
> > > > > > > > > > > > values, causing linux to panic() as it sets up the page 
> > > > > > > > > > > > table.
> > > > > > > > > > > >
> > > > > > > > > > > > Instead of trying to fix the mess, potentially causing 
> > > > > > > > > > > > other issues,
> > > > > > > > > > > > revert to the code that worked, while this change is 
> > > > > > > > > > > > reworked.
> > > > > > > > > > >
> > > > > > > > > > > The goal here is to drop a feature that few boards use 
> > > > > > > > > > > and reduce
> > > > > > > > > > > memory usage in SPL. It has been in place for two 
> > > > > > > > > > > releases now.
> > > > > > > > > > >
> > > > > > > > > > > If Falcon mode needs it, perhaps you could add an 'imply' 
> > > > > > > > > > > in the
> > > > > > > > > > > Kconfig for that feature? Is there one? Or perhaps
> > > > > > > > > > > CONFIG_ARCH_FIXUP_FDT_MEMORY ?
> > > > > > > > > > >
> > > > > > > > > > > One option would be to return an error in 
> > > > > > > > > > > arch_fixup_fdt(). In
> > > > > > > > > > > general, fixups make things tricky because there is no 
> > > > > > > > > > > way to
> > > > > > > > > > > determine when they are used but at least this one has a 
> > > > > > > > > > > CONFIG.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > The argument that this has been in place for two releases 
> > > > > > > > > > is incorrect.
> > > > > > > > > > Commit 38d6b7ebdaee3e0e8426ef1b9df88bdce8ae2e75 was only 
> > > > > > > > > > introduced with
> > > > > > > > > > the v2021.04 release. It definitely was not in 2021.01. 
> > > > > > > > > > It's only in the
> > > > > > > > > > last release, which is four days old t the time of this 
> > > > > > > > > > writing.
> > > > > > > >
> > > > > > > > Yes.  But another way of saying that is that we're 4 days in to 
> > > > > > > > the
> > > > > > > > merge window.  That's a bit early to say we must revert the 
> > > > > > > > change.  If
> > > > > > > > this was just before the release, yes, revert would be the 
> > > > > > > > right answer.
> > > > > > > > It's also the case the original commit fixes some cases while 
> > > > > > > > also
> > > > > > > > saving size, if I read it right.  So a strict revert isn't 
> > > > > > > > right, we'd
> > > > > > > > need to also probably also default y SPL_ALLOC_BD in some cases.
> > > > > > > >
> > > > > > > > > > Although I was able to find one example, the reality is 
> > > > > > > > > > that we don't
> > > > > > > > > > know the full extent of the breakage. The prudent thing at 
> > > > > > > > > > this point is
> > > > > > > > > > to revert.
> > > > > > > > > >
> > > > > > > > > > The knowledge of how to init the platform is in the 
> > > > > > > > > > devicetree and code.
> > > > > > > > > > Why should kconfig also be involved in storing this 
> > > > > > > > > > knowledge? By this
> > > 

Re: [PATCH v2] cmd: gpt: remove redundant print messages

[Tom Rini]

On Wed, Mar 31, 2021 at 11:15:49AM -0700, Ravik Hasija wrote:

> Removing printfs from do_gpt API as the messages are generic and does not
> specify error codes for failure cases.
> 
> Signed-off-by: Ravik Hasija 
> Reviewed-by: Patrick Delaunay 
> ---
> Changes for v2:
>   - Updated usage message for gpt read
>   - Added removed printfs for write & verify
>   - Rearranged verify printf

This change in output breaks test_gpt_verify (see
test/py/tests/test_gpt.py) so that needs to be updated at the same time,
thanks.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] boards: amlogic: update documentation for PCIe support

[Neil Armstrong]

On 16/04/2021 14:23, Neil Armstrong wrote:
> Signed-off-by: Neil Armstrong 
> ---
>  doc/board/amlogic/index.rst | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/doc/board/amlogic/index.rst b/doc/board/amlogic/index.rst
> index 275c3664b7..8da7afddb4 100644
> --- a/doc/board/amlogic/index.rst
> +++ b/doc/board/amlogic/index.rst
> @@ -70,6 +70,8 @@ This matrix concerns the actual source code version.
>  
> +---+---+-+--+++-+--+
>  | SoC (version) information | **Yes**   | **Yes** | **Yes**  
> | **Yes**| **Yes**| **Yes** | **Yes**  |
>  
> +---+---+-+--+++-+--+
> +| PCIe (+NVMe)  | *N/A* | *N/A*   | *N/A*
> | **Yes**| **Yes**| **Yes** | **Yes**  |
> ++---+---+-+--+++-+--+
>  
>  Board Documentation
>  ---
> 

Applied to u-boot-amlogic

Possible USB Mass Storage bug on Xilinx's Zynq

[Bruno L. Albrecht]

Hello people,
it's my first post here, so forgive me if I do something wrong. I'll try to
be short and clear.

I'm developing on an Avnet PicoZed (based on a Xilinx Zynq SoC) and my
objective is to expose the eMMC as a Mass Storage Device over an USB
Connection.

I used the following config flag on defconfig file (
https://github.com/Xilinx/u-boot-xlnx/blob/master/configs/xilinx_zynq_virt_defconfig
):

CONFIG_CMD_USB_MASS_STORAGE=y


To the Device Tree (
https://github.com/Xilinx/u-boot-xlnx/blob/master/arch/arm/dts/zynq-picozed.dts)
I added the usb configuration:

aliases {
> <...>
> usb0 = &usb0;
> };
> &usb0 {
> u-boot,dm-pre-reloc;
> status = "okay";
> dr_mode = "peripheral";
> };


Compilation goes fine and U-Boot boots fine. The eMMC is correctly
recognized.
Then I use the following command to initiate the USB Mass Storage:

ums 0 mmc 0


When on *Windows*, the command is successful for a brief moment and then
the board resets with the following error:

Zynq> ums 0 mmc 0
> UMS: LUN 0, dev 0, hwpart 0, sector 0x0, count 0xe3
> \EP1/in FAIL info=4080 pg0=3eb393c0
> EP1/in FAIL info=40008080 pg0=3eb3d3c0
> EP1/in FAIL info=d8080 pg0=3eaebdc0
> CACHE: Misaligned operation at range [0001, 0041]
> CACHE: Misaligned operation at range [0001, 0041]
> data abort
> pc : [<3ff67dec>]  lr : [<3ff67dec>]
> reloc pc : [<0405cdec>]lr : [<0405cdec>]
> sp : 3eae81f0  ip : 0031 fp : 3ffd957c
> r10: 0001  r9 : 3eaeaed0 r8 : 0001
> r7 : 3ffd9524  r6 : 0001 r5 : 3ffd94ec  r4 : 3ffd95a4
> r3 : e0001000  r2 : 0001 r1 : 0041  r0 : 0001
> Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
> Code: ea7e e2861040 e1a6 ebfe91a6 (e5963004)
> Resetting CPU ...
>

Since I'm working on a Windows machine, I have a Ubuntu running on a
Virtual Machine (VirtualBox). So I made a rule to bypass the USB device
that would be created on Windows directly to the Virtual Machine (virtually
connected the USB device to my Ubuntu).

When I do this, the command works. I can access the eMMC and format it and
do whatever I want. If I remove the filter and let Windows enumerate the
device, the board resets again.

I took a look at the dmesg messages on Ubuntu and found the following (the
only unusual messages are in bold):

[101436.784042] usb 1-2: new full-speed USB device number 25 using ohci-pci
>
> *[101437.232208] usb 1-2: config 1 interface 0 altsetting 0 endpoint 0x81
> has invalid maxpacket 512, setting to 64[101437.232210] usb 1-2: config 1
> interface 0 altsetting 0 endpoint 0x2 has invalid maxpacket 512, setting to
> 64*
> [101437.477816] usb 1-2: New USB device found, idVendor=,
> idProduct=, bcdDevice= 2.21
> [101437.477818] usb 1-2: New USB device strings: Mfr=1, Product=2,
> SerialNumber=0
> [101437.477820] usb 1-2: Product: my product name
> [101437.477821] usb 1-2: Manufacturer: my manufacturer
> [101437.702297] usb-storage 1-2:1.0: USB Mass Storage device detected
> [101437.713954] scsi host3: usb-storage 1-2:1.0
> [101438.976664] scsi 3:0:0:0: Direct-Access LinuxUMS disk 0
>  PQ: 0 ANSI: 2
> [101438.979158] sd 3:0:0:0: Attached scsi generic sg2 type 0
> [101439.284100] sd 3:0:0:0: [sdb] 14876672 512-byte logical blocks: (7.62
> GB/7.09 GiB)
> [101439.468523] sd 3:0:0:0: [sdb] Write Protect is off
> [101439.468526] sd 3:0:0:0: [sdb] Mode Sense: 0f 00 00 00
> [101439.653020] sd 3:0:0:0: [sdb] Write cache: enabled, read cache:
> enabled, doesn't support DPO or FUA
> [101440.759756]  sdb: sdb1
> [101441.559083] sd 3:0:0:0: [sdb] Attached SCSI removable disk
>

Not that it sounds like it would interfere, but the USB from the SoC is
connected to an USB Hub (USB2514B), to which other devices are connected
and work correctly on both Windows and Linux.

Any ideas of what might be happening?


Cheers
Bruno


-- 
  Eng. Bruno Landau Albrecht
  e-mail: brunol...@gmail.com

Re: [PATCH] fastboot: Fix overflow when calculating chunk size

[Sean Anderson]

On 4/19/21 12:31 AM, Heiko Schocher wrote:
> Hello Sean,
>
> On 16.04.21 23:58, Sean Anderson wrote:
>> If a chunk was larger than 4GiB, then chunk_data_sz would overflow and
>> blkcnt would not be calculated correctly. Upgrade it to a u64 and cast
>> its multiplicands as well. Also fix bytes_written while we're at it.
>>
>> Signed-off-by: Sean Anderson 
>> ---
>>
>>   lib/image-sparse.c | 12 ++--
>>   1 file changed, 6 insertions(+), 6 deletions(-)
>
> Wow chunk size larger than 4G!

Normally filesystems like ext4 put data all around the disk (i.e. the
used-block bitmap). However, if you use a log filesystem (like F2FS),
then all the data is at the beginning of the disk. In that case, it is
fairly easy to end up with a 4GiB or greater "don't care" chunk taking
up most of the disk.

--Sean

>
> But patch seems valid, so
>
> Reviewed-by: Heiko Schocher 
>
> bye,
> Heiko
>

[PATCH] efi: Fix ESRT refresh after Capsule update

[Jose Marinho]

Indicated by Coverity Scan CID 331147

The ESRT was being refreshed in situations where the UpdateCapsule
procedure failed. In that scenario:

1) the ESRT refresh was superfluous.
2) a failed ESRT refresh return code overwrites the UpdateCapsule error
return code.

This commit ensures that the ESRT is only refreshed when the
UpdateCapsule performs successfully.

CC: Heinrich Schuchardt 
CC: Sughosh Ganu 
CC: AKASHI Takahiro 
CC: Tom Rini 
CC: Andre Przywara 
CC: n...@arm.com

Signed-off-by: Jose Marinho 
---
 lib/efi_loader/efi_capsule.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
index 691eda5e0d..a984c347e1 100644
--- a/lib/efi_loader/efi_capsule.c
+++ b/lib/efi_loader/efi_capsule.c
@@ -481,7 +481,6 @@ efi_status_t EFIAPI efi_update_capsule(
if (ret != EFI_SUCCESS)
goto out;
}
-out:
 
if (IS_ENABLED(CONFIG_EFI_ESRT)) {
/* Rebuild the ESRT to reflect any updated FW images. */
@@ -489,6 +488,7 @@ out:
if (ret != EFI_SUCCESS)
log_warning("EFI Capsule: failed to update ESRT\n");
}
+out:
 
return EFI_EXIT(ret);
 }
-- 
2.17.1

Re: [PATCH v2 00/10] spi: dw: Add support for DUAL/QUAD/OCTAL modes

[Jagan Teki]

On Mon, Apr 19, 2021 at 6:49 PM Sean Anderson  wrote:
>
> On 4/19/21 3:06 AM, Jagan Teki wrote:
> > On Sat, Apr 3, 2021 at 4:37 AM Sean Anderson  wrote:
> >>
> >> On 4/2/21 7:05 PM, Sean Anderson wrote:
> >>> This series adds support for enhanced SPI modes. It was tested on a K210 
> >>> (DWC
> >>> SSI with QSPI flash).
> >>>
> >>> If anyone has a designware device with QSPI flash attached (especially a 
> >>> DW SSI
> >>> APB device), I'd greatly appreciate them testing out this patch series. 
> >>> Given
> >>> that there has been no testing of v2 over the past month, I don't think 
> >>> lack of
> >>> testing should hold up this series.
> >>>
> >>> Changes in v3:
> >>> - Dropped merged patches
> >>> - Rebased on u-boot/master
> >>>
> >>> Changes in v2:
> >>> - Add more information to exec_op debug message
> >>> - Actually mask interrupts
> >>> - Merge CAP_{DUAL,QUAD,OCTAL} into CAP_ENHANCED
> >>> - Fix some inconsistencies in register naming and usage
> >>> - Moved some hunks between commits so things make more sense
> >>>
> >>> Sean Anderson (10):
> >>> mtd: spi-mem: Export spi_mem_default_supports_op
> >>> spi: spi-mem: Add debug message for spi-mem ops
> >>> spi: dw: Log status register on timeout
> >>> spi: dw: Actually mask interrupts
> >>> spi: dw: Switch to capabilities
> >>> spi: dw: Rewrite poll_transfer logic
> >>> spi: dw: Add ENHANCED cap
> >>> spi: dw: Define registers for enhanced mode
> >>> spi: dw: Support enhanced SPI
> >>> spi: dw: Support clock stretching
> >>>
> >>>drivers/spi/designware_spi.c | 647 ---
> >>>drivers/spi/spi-mem.c|   7 +
> >>>include/spi-mem.h|   3 +
> >>>3 files changed, 451 insertions(+), 206 deletions(-)
> >>>
> >>
> >> Looks like I forgot to bump the version. This should be v3. I can resend 
> >> if necessary.
> >
> > Yes, Please.
> >
> > There are few comments,
> >
> > 1. Patch "spi: spi-mem: Add debug message for spi-mem ops"
> >
> > As we discussed in the previous version, drop the unnecessary debug
> > statements after ops execution as this patch trying to add more
> > verbose to before ops execution.
>
>  From last time:
>
> >>> +   dev_dbg(slave->dev,
> >>> +   "exec %02Xh %u-%u-%u addr=%llx dummy cycles=%u data 
> >>> bytes=%u\n",
> >>> +   op->cmd.opcode, op->cmd.buswidth, op->addr.buswidth,
> >>> +   op->data.buswidth, op->addr.val,
> >>> +   op->dummy.buswidth ? op->dummy.nbytes * 8 / 
> >>> op->dummy.buswidth : 0,
> >>> +   op->data.nbytes);
> >>
> >> This looks unnecessary to me, we have debug prints at the end of the
> >> function, which indeed sufficient.
> >>
> >
> > This is insufficient. First, that information is printed after the op
> > is executed. This is too late if one is trying to debug (e.g.) a hang in
> > the spi driver. It's also missing opcode, widths, address, and dummy
> > bytes. The only duplicated info here is nbytes. Since this is debugging
> > information, I think we should print what is most useful for people
> > debugging this subsystem.
>
> I would like if you could respond to my response before I remove this.

Yes, I have commented based on your previous version comments. What
I'm saying here is to adjust even the exiting debug statements in
order to not duplicate if your patch changes.

Jagan.

Re: [PATCH 00/13] display_options: Start to unify print_buffer() and hexdump

[Tom Rini]

On Thu, Mar 18, 2021 at 07:18:27AM +1300, Simon Glass wrote:

> At present we have two ways of showing a hex dump. Once has been in U-Boot
> since the dawn of time and the other was recently added from Linux.
> 
> They both have their own unique features.
> 
> This series makes a few changes to bring them closer together. It also
> adds support for logging a buffer, which is useful since it can put it
> through the same log drivers as other logging output.
> 
> Also it adds tests, so we can check the behaviour.
> 
> The code-size impact of the main part of this series is 160 bytes on
> Thumb2, which seems acceptable. However the final patch adds another 600
> bytes or so, which is not.

This seems good, and to set aside the RFC for now.  But it needs to be
rebased on master now as 12/13 doesn't apply (and I don't see the "why"
and just 1-11 fails to build for sandbox.  Thanks.

-- 
Tom


signature.asc
Description: PGP signature

[PATCH] board:pm9263 - Enable DM_ETH

[Ilko Iliev]

Signed-off-by: Ilko Iliev 
---
 board/ronetix/pm9263/pm9263.c | 57 ---
 configs/pm9263_defconfig  |  2 ++
 include/configs/pm9263.h  |  6 
 3 files changed, 2 insertions(+), 63 deletions(-)

diff --git a/board/ronetix/pm9263/pm9263.c b/board/ronetix/pm9263/pm9263.c
index 95c0dec4db..46494b043f 100644
--- a/board/ronetix/pm9263/pm9263.c
+++ b/board/ronetix/pm9263/pm9263.c
@@ -19,10 +19,6 @@
 #include 
 #include 
 #include 
-#if defined(CONFIG_RESET_PHY_R) && defined(CONFIG_MACB)
-#include 
-#endif
-#include 
 #include 

 DECLARE_GLOBAL_DATA_PTR;
@@ -73,41 +69,6 @@ static void pm9263_nand_hw_init(void)
 }
 #endif

-#ifdef CONFIG_MACB
-static void pm9263_macb_hw_init(void)
-{
-   /*
-* PB27 enables the 50MHz oscillator for Ethernet PHY
-* 1 - enable
-* 0 - disable
-*/
-   at91_set_pio_output(AT91_PIO_PORTB, 27, 1);
-   at91_set_pio_value(AT91_PIO_PORTB, 27, 1); /* 1- enable, 0 - disable */
-
-   at91_periph_clk_enable(ATMEL_ID_EMAC);
-
-   /*
-* Disable pull-up on:
-*  RXDV (PC25) => PHY normal mode (not Test mode)
-*  ERX0 (PE25) => PHY ADDR0
-*  ERX1 (PE26) => PHY ADDR1 => PHYADDR = 0x0
-*
-* PHY has internal pull-down
-*/
-
-   at91_set_pio_pullup(AT91_PIO_PORTC, 25, 0);
-   at91_set_pio_pullup(AT91_PIO_PORTE, 25, 0);
-   at91_set_pio_pullup(AT91_PIO_PORTE, 26, 0);
-
-   /* Re-enable pull-up */
-   at91_set_pio_pullup(AT91_PIO_PORTC, 25, 1);
-   at91_set_pio_pullup(AT91_PIO_PORTE, 25, 1);
-   at91_set_pio_pullup(AT91_PIO_PORTE, 26, 1);
-
-   at91_macb_hw_init();
-}
-#endif
-
 #ifdef CONFIG_LCD

 #ifdef CONFIG_LCD_IN_PSRAM
@@ -233,9 +194,6 @@ int board_init(void)
 #ifdef CONFIG_CMD_NAND
pm9263_nand_hw_init();
 #endif
-#ifdef CONFIG_MACB
-   pm9263_macb_hw_init();
-#endif
 #ifdef CONFIG_USB_OHCI_NEW
at91_uhp_hw_init();
 #endif
@@ -261,21 +219,6 @@ int dram_init_banksize(void)
return 0;
 }

-#ifdef CONFIG_RESET_PHY_R
-void reset_phy(void)
-{
-}
-#endif
-
-int board_eth_init(struct bd_info *bis)
-{
-   int rc = 0;
-#ifdef CONFIG_MACB
-   rc = macb_eth_initialize(0, (void *)ATMEL_BASE_EMAC, 0x01);
-#endif
-   return rc;
-}
-
 #ifdef CONFIG_DISPLAY_BOARDINFO
 int checkboard (void)
 {
diff --git a/configs/pm9263_defconfig b/configs/pm9263_defconfig
index 817a9847be..ef18e742d2 100644
--- a/configs/pm9263_defconfig
+++ b/configs/pm9263_defconfig
@@ -50,6 +50,8 @@ CONFIG_NAND_ATMEL=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH_ATMEL=y
 CONFIG_SPI_FLASH_DATAFLASH=y
+CONFIG_DM_ETH=y
+CONFIG_MACB=y
 CONFIG_DM_SERIAL=y
 CONFIG_ATMEL_USART=y
 CONFIG_SPI=y
diff --git a/include/configs/pm9263.h b/include/configs/pm9263.h
index 6c882b6ff9..7b028751bd 100644
--- a/include/configs/pm9263.h
+++ b/include/configs/pm9263.h
@@ -204,12 +204,6 @@
 AT91_MATRIX_SCFG_DEFMSTR_TYPE_FIXED
| \
 AT91_MATRIX_SCFG_SLOT_CYCLE(255))

-/* Ethernet */
-#define CONFIG_MACB1
-#define CONFIG_RMII1
-#define CONFIG_NET_RETRY_COUNT 20
-#define CONFIG_RESET_PHY_R 1
-
 /* USB */
 #define CONFIG_USB_ATMEL
 #define CONFIG_USB_ATMEL_CLK_SEL_PLLB
--
2.25.1

[PATCH v2] board:pm9261 - Enable DM_ETH

[Ilko Iliev]

This patch remove the network support for PM9261 because
currently there is no DM suport for Davicom D9000.

Signed-off-by: Ilko Iliev 
---
Changes for v2:
 - add Signed-off-by

 board/ronetix/pm9261/pm9261.c | 54 ---
 configs/pm9261_defconfig  |  1 +
 include/configs/pm9261.h  |  9 --
 3 files changed, 1 insertion(+), 63 deletions(-)

diff --git a/board/ronetix/pm9261/pm9261.c b/board/ronetix/pm9261/pm9261.c
index 5be2c5e192..fe52c7c176 100644
--- a/board/ronetix/pm9261/pm9261.c
+++ b/board/ronetix/pm9261/pm9261.c
@@ -20,10 +20,6 @@
 #include 
 #include 
 #include 
-#if defined(CONFIG_RESET_PHY_R) && defined(CONFIG_DRIVER_DM9000)
-#include 
-#endif
-#include 
 #include 

 DECLARE_GLOBAL_DATA_PTR;
@@ -80,36 +76,6 @@ static void pm9261_nand_hw_init(void)
 }
 #endif

-
-#ifdef CONFIG_DRIVER_DM9000
-static void pm9261_dm9000_hw_init(void)
-{
-   struct at91_smc *smc = (struct at91_smc *)ATMEL_BASE_SMC;
-
-   /* Configure SMC CS2 for DM9000 */
-   writel(AT91_SMC_SETUP_NWE(2) | AT91_SMC_SETUP_NCS_WR(0) |
-   AT91_SMC_SETUP_NRD(2) | AT91_SMC_SETUP_NCS_RD(0),
-   &smc->cs[2].setup);
-
-   writel(AT91_SMC_PULSE_NWE(4) | AT91_SMC_PULSE_NCS_WR(8) |
-   AT91_SMC_PULSE_NRD(4) | AT91_SMC_PULSE_NCS_RD(8),
-   &smc->cs[2].pulse);
-
-   writel(AT91_SMC_CYCLE_NWE(16) | AT91_SMC_CYCLE_NRD(16),
-   &smc->cs[2].cycle);
-
-   writel(AT91_SMC_MODE_RM_NRD | AT91_SMC_MODE_WM_NWE |
-   AT91_SMC_MODE_EXNW_DISABLE |
-   AT91_SMC_MODE_BAT | AT91_SMC_MODE_DBW_16 |
-   AT91_SMC_MODE_TDF_CYCLE(1),
-   &smc->cs[2].mode);
-
-   /* Configure Interrupt pin as input, no pull-up */
-   at91_periph_clk_enable(ATMEL_ID_PIOA);
-   at91_set_pio_input(AT91_PIO_PORTA, 24, 0);
-}
-#endif
-
 int board_early_init_f(void)
 {
return 0;
@@ -132,13 +98,6 @@ int board_init(void)
return 0;
 }

-#ifdef CONFIG_DRIVER_DM9000
-int board_eth_init(struct bd_info *bis)
-{
-   return dm9000_initialize(bis);
-}
-#endif
-
 int dram_init(void)
 {
/* dram_init must store complete ramsize in gd->ram_size */
@@ -155,19 +114,6 @@ int dram_init_banksize(void)
return 0;
 }

-#ifdef CONFIG_RESET_PHY_R
-void reset_phy(void)
-{
-#ifdef CONFIG_DRIVER_DM9000
-   /*
-* Initialize ethernet HW addr prior to starting Linux,
-* needed for nfsroot
-*/
-   eth_init();
-#endif
-}
-#endif
-
 #ifdef CONFIG_DISPLAY_BOARDINFO
 int checkboard (void)
 {
diff --git a/configs/pm9261_defconfig b/configs/pm9261_defconfig
index e0a2ae18c6..774039e8bc 100644
--- a/configs/pm9261_defconfig
+++ b/configs/pm9261_defconfig
@@ -50,6 +50,7 @@ CONFIG_NAND_ATMEL=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH_ATMEL=y
 CONFIG_SPI_FLASH_DATAFLASH=y
+CONFIG_DM_ETH=y
 CONFIG_PINCTRL=y
 CONFIG_PINCTRL_AT91=y
 CONFIG_DM_SERIAL=y
diff --git a/include/configs/pm9261.h b/include/configs/pm9261.h
index 2cc47d1237..382d19a241 100644
--- a/include/configs/pm9261.h
+++ b/include/configs/pm9261.h
@@ -173,15 +173,6 @@
 #define CONFIG_SYS_MAX_FLASH_SECT  256
 #define CONFIG_SYS_MAX_FLASH_BANKS 1

-/* Ethernet */
-#define CONFIG_DRIVER_DM9000   1
-#define CONFIG_DM9000_BASE 0x3000
-#define DM9000_IO  CONFIG_DM9000_BASE
-#define DM9000_DATA(CONFIG_DM9000_BASE + 4)
-#define CONFIG_DM9000_USE_16BIT1
-#define CONFIG_NET_RETRY_COUNT 20
-#define CONFIG_RESET_PHY_R 1
-
 /* USB */
 #define CONFIG_USB_ATMEL
 #define CONFIG_USB_ATMEL_CLK_SEL_PLLB
--
2.25.1

Re: [PATCH v2 00/10] spi: dw: Add support for DUAL/QUAD/OCTAL modes

[Sean Anderson]

On 4/19/21 3:06 AM, Jagan Teki wrote:

On Sat, Apr 3, 2021 at 4:37 AM Sean Anderson  wrote:


On 4/2/21 7:05 PM, Sean Anderson wrote:

This series adds support for enhanced SPI modes. It was tested on a K210 (DWC
SSI with QSPI flash).

If anyone has a designware device with QSPI flash attached (especially a DW SSI
APB device), I'd greatly appreciate them testing out this patch series. Given
that there has been no testing of v2 over the past month, I don't think lack of
testing should hold up this series.

Changes in v3:
- Dropped merged patches
- Rebased on u-boot/master

Changes in v2:
- Add more information to exec_op debug message
- Actually mask interrupts
- Merge CAP_{DUAL,QUAD,OCTAL} into CAP_ENHANCED
- Fix some inconsistencies in register naming and usage
- Moved some hunks between commits so things make more sense

Sean Anderson (10):
mtd: spi-mem: Export spi_mem_default_supports_op
spi: spi-mem: Add debug message for spi-mem ops
spi: dw: Log status register on timeout
spi: dw: Actually mask interrupts
spi: dw: Switch to capabilities
spi: dw: Rewrite poll_transfer logic
spi: dw: Add ENHANCED cap
spi: dw: Define registers for enhanced mode
spi: dw: Support enhanced SPI
spi: dw: Support clock stretching

   drivers/spi/designware_spi.c | 647 ---
   drivers/spi/spi-mem.c|   7 +
   include/spi-mem.h|   3 +
   3 files changed, 451 insertions(+), 206 deletions(-)



Looks like I forgot to bump the version. This should be v3. I can resend if 
necessary.


Yes, Please.

There are few comments,

1. Patch "spi: spi-mem: Add debug message for spi-mem ops"

As we discussed in the previous version, drop the unnecessary debug
statements after ops execution as this patch trying to add more
verbose to before ops execution.


From last time:


+   dev_dbg(slave->dev,
+   "exec %02Xh %u-%u-%u addr=%llx dummy cycles=%u data bytes=%u\n",
+   op->cmd.opcode, op->cmd.buswidth, op->addr.buswidth,
+   op->data.buswidth, op->addr.val,
+   op->dummy.buswidth ? op->dummy.nbytes * 8 / op->dummy.buswidth 
: 0,
+   op->data.nbytes);


This looks unnecessary to me, we have debug prints at the end of the
function, which indeed sufficient.



This is insufficient. First, that information is printed after the op
is executed. This is too late if one is trying to debug (e.g.) a hang in
the spi driver. It's also missing opcode, widths, address, and dummy
bytes. The only duplicated info here is nbytes. Since this is debugging
information, I think we should print what is most useful for people
debugging this subsystem.


I would like if you could respond to my response before I remove this.



2. Comments in Patch v2,06/10


I will look into that before resending.

--Sean



Jagan.

[PATCH v2] arm64: versal: Remove gd reference

[Michal Simek]

gd is not used in this file that's why doesn't make sense to declare it.

Signed-off-by: Michal Simek 
---

Changes in v2:
- drop asm/global_data.h - reported by trini

 arch/arm/mach-versal/mp.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/arm/mach-versal/mp.c b/arch/arm/mach-versal/mp.c
index c97c311d3130..9b0518d6a2cd 100644
--- a/arch/arm/mach-versal/mp.c
+++ b/arch/arm/mach-versal/mp.c
@@ -5,13 +5,10 @@
  */
 
 #include 
-#include 
 #include 
 #include 
 #include 
 
-DECLARE_GLOBAL_DATA_PTR;
-
 #define HALT   0
 #define RELEASE1
 
-- 
2.31.1

Re: [PATCH] arm64: versal: Remove gd reference

[Michal Simek]

On 4/19/21 2:30 PM, Tom Rini wrote:
> On Thu, Apr 15, 2021 at 11:16:31AM +0200, Michal Simek wrote:
> 
>> gd is not used in this file that's why doesn't make sense to declare it.
>>
>> Signed-off-by: Michal Simek 
>> ---
>>
>>  arch/arm/mach-versal/mp.c | 2 --
>>  1 file changed, 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-versal/mp.c b/arch/arm/mach-versal/mp.c
>> index c97c311d3130..58eab4bdf563 100644
>> --- a/arch/arm/mach-versal/mp.c
>> +++ b/arch/arm/mach-versal/mp.c
>> @@ -10,8 +10,6 @@
>>  #include 
>>  #include 
>>  
>> -DECLARE_GLOBAL_DATA_PTR;
>> -
>>  #define HALT0
>>  #define RELEASE 1
> 
> You should drop  from here too then I believe.
> 

You are right. Will send v2.

M

[PATCH] board:pm9261 - Enable DM_ETH

[Ilko Iliev]

This patch remove the network support for PM9261 because
currently there is no DM suport for Davicom D9000.
---
 board/ronetix/pm9261/pm9261.c | 54 ---
 configs/pm9261_defconfig  |  1 +
 include/configs/pm9261.h  |  9 --
 3 files changed, 1 insertion(+), 63 deletions(-)

diff --git a/board/ronetix/pm9261/pm9261.c b/board/ronetix/pm9261/pm9261.c
index 5be2c5e192..fe52c7c176 100644
--- a/board/ronetix/pm9261/pm9261.c
+++ b/board/ronetix/pm9261/pm9261.c
@@ -20,10 +20,6 @@
 #include 
 #include 
 #include 
-#if defined(CONFIG_RESET_PHY_R) && defined(CONFIG_DRIVER_DM9000)
-#include 
-#endif
-#include 
 #include 
 
 DECLARE_GLOBAL_DATA_PTR;
@@ -80,36 +76,6 @@ static void pm9261_nand_hw_init(void)
 }
 #endif
 
-
-#ifdef CONFIG_DRIVER_DM9000
-static void pm9261_dm9000_hw_init(void)
-{
-   struct at91_smc *smc = (struct at91_smc *)ATMEL_BASE_SMC;
-
-   /* Configure SMC CS2 for DM9000 */
-   writel(AT91_SMC_SETUP_NWE(2) | AT91_SMC_SETUP_NCS_WR(0) |
-   AT91_SMC_SETUP_NRD(2) | AT91_SMC_SETUP_NCS_RD(0),
-   &smc->cs[2].setup);
-
-   writel(AT91_SMC_PULSE_NWE(4) | AT91_SMC_PULSE_NCS_WR(8) |
-   AT91_SMC_PULSE_NRD(4) | AT91_SMC_PULSE_NCS_RD(8),
-   &smc->cs[2].pulse);
-
-   writel(AT91_SMC_CYCLE_NWE(16) | AT91_SMC_CYCLE_NRD(16),
-   &smc->cs[2].cycle);
-
-   writel(AT91_SMC_MODE_RM_NRD | AT91_SMC_MODE_WM_NWE |
-   AT91_SMC_MODE_EXNW_DISABLE |
-   AT91_SMC_MODE_BAT | AT91_SMC_MODE_DBW_16 |
-   AT91_SMC_MODE_TDF_CYCLE(1),
-   &smc->cs[2].mode);
-
-   /* Configure Interrupt pin as input, no pull-up */
-   at91_periph_clk_enable(ATMEL_ID_PIOA);
-   at91_set_pio_input(AT91_PIO_PORTA, 24, 0);
-}
-#endif
-
 int board_early_init_f(void)
 {
return 0;
@@ -132,13 +98,6 @@ int board_init(void)
return 0;
 }
 
-#ifdef CONFIG_DRIVER_DM9000
-int board_eth_init(struct bd_info *bis)
-{
-   return dm9000_initialize(bis);
-}
-#endif
-
 int dram_init(void)
 {
/* dram_init must store complete ramsize in gd->ram_size */
@@ -155,19 +114,6 @@ int dram_init_banksize(void)
return 0;
 }
 
-#ifdef CONFIG_RESET_PHY_R
-void reset_phy(void)
-{
-#ifdef CONFIG_DRIVER_DM9000
-   /*
-* Initialize ethernet HW addr prior to starting Linux,
-* needed for nfsroot
-*/
-   eth_init();
-#endif
-}
-#endif
-
 #ifdef CONFIG_DISPLAY_BOARDINFO
 int checkboard (void)
 {
diff --git a/configs/pm9261_defconfig b/configs/pm9261_defconfig
index e0a2ae18c6..774039e8bc 100644
--- a/configs/pm9261_defconfig
+++ b/configs/pm9261_defconfig
@@ -50,6 +50,7 @@ CONFIG_NAND_ATMEL=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH_ATMEL=y
 CONFIG_SPI_FLASH_DATAFLASH=y
+CONFIG_DM_ETH=y
 CONFIG_PINCTRL=y
 CONFIG_PINCTRL_AT91=y
 CONFIG_DM_SERIAL=y
diff --git a/include/configs/pm9261.h b/include/configs/pm9261.h
index 2cc47d1237..382d19a241 100644
--- a/include/configs/pm9261.h
+++ b/include/configs/pm9261.h
@@ -173,15 +173,6 @@
 #define CONFIG_SYS_MAX_FLASH_SECT  256
 #define CONFIG_SYS_MAX_FLASH_BANKS 1
 
-/* Ethernet */
-#define CONFIG_DRIVER_DM9000   1
-#define CONFIG_DM9000_BASE 0x3000
-#define DM9000_IO  CONFIG_DM9000_BASE
-#define DM9000_DATA(CONFIG_DM9000_BASE + 4)
-#define CONFIG_DM9000_USE_16BIT1
-#define CONFIG_NET_RETRY_COUNT 20
-#define CONFIG_RESET_PHY_R 1
-
 /* USB */
 #define CONFIG_USB_ATMEL
 #define CONFIG_USB_ATMEL_CLK_SEL_PLLB
-- 
2.25.1

Re: [PATCH] arm64: versal: Remove gd reference

[Tom Rini]

On Thu, Apr 15, 2021 at 11:16:31AM +0200, Michal Simek wrote:

> gd is not used in this file that's why doesn't make sense to declare it.
> 
> Signed-off-by: Michal Simek 
> ---
> 
>  arch/arm/mach-versal/mp.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/arch/arm/mach-versal/mp.c b/arch/arm/mach-versal/mp.c
> index c97c311d3130..58eab4bdf563 100644
> --- a/arch/arm/mach-versal/mp.c
> +++ b/arch/arm/mach-versal/mp.c
> @@ -10,8 +10,6 @@
>  #include 
>  #include 
>  
> -DECLARE_GLOBAL_DATA_PTR;
> -
>  #define HALT 0
>  #define RELEASE  1

You should drop  from here too then I believe.

-- 
Tom


signature.asc
Description: PGP signature

[scan-ad...@coverity.com: New Defects reported by Coverity Scan for Das U-Boot]

[Tom Rini]

Hey all,

Here's the latest report.

- Forwarded message from scan-ad...@coverity.com -

Date: Mon, 19 Apr 2021 01:18:55 + (UTC)
From: scan-ad...@coverity.com
To: tom.r...@gmail.com
Subject: New Defects reported by Coverity Scan for Das U-Boot

Hi,

Please find the latest report on new defect(s) introduced to Das U-Boot found 
with Coverity Scan.

13 new defect(s) introduced to Das U-Boot found with Coverity Scan.
5 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent 
build analyzed by Coverity Scan.

New defect(s) Reported-by: Coverity Scan
Showing 13 of 13 defect(s)


** CID 331158:  Control flow issues  (NO_EFFECT)
/drivers/pinctrl/pinctrl-single.c: 347 in single_configure_bits()



*** CID 331158:  Control flow issues  (NO_EFFECT)
/drivers/pinctrl/pinctrl-single.c: 347 in single_configure_bits()
341 return PTR_ERR(func);
342 
343 func->name = fname;
344 func->npins = 0;
345 for (n = 0; n < count; n++, pins++) {
346 offset = fdt32_to_cpu(pins->reg);
>>> CID 331158:  Control flow issues  (NO_EFFECT)
>>> This less-than-zero comparison of an unsigned value is never true. 
>>> "offset < 0U".
347 if (offset < 0 || offset > pdata->offset) {
348 dev_dbg(dev, "  invalid register offset 0x%x\n",
349 offset);
350 continue;
351 }
352 

** CID 331157:  Null pointer dereferences  (NULL_RETURNS)
/drivers/misc/cros_ec_sandbox.c: 229 in keyscan_read_fdt_matrix()



*** CID 331157:  Null pointer dereferences  (NULL_RETURNS)
/drivers/misc/cros_ec_sandbox.c: 229 in keyscan_read_fdt_matrix()
223 
224 /* Now read the data */
225 for (upto = 0; upto < ec->matrix_count; upto++) {
226 struct ec_keymatrix_entry *matrix = &ec->matrix[upto];
227 u32 word;
228 
>>> CID 331157:  Null pointer dereferences  (NULL_RETURNS)
>>> Incrementing a pointer which might be null: "cell".
229 word = fdt32_to_cpu(*cell++);
230 matrix->row = word >> 24;
231 matrix->col = (word >> 16) & 0xff;
232 matrix->keycode = word & 0x;
233 
234 /* Hard-code some sanity limits for now */

** CID 331156:  Incorrect expression  (UNUSED_VALUE)
/cmd/qfw.c: 40 in qemu_fwcfg_cmd_setup_kernel()



*** CID 331156:  Incorrect expression  (UNUSED_VALUE)
/cmd/qfw.c: 40 in qemu_fwcfg_cmd_setup_kernel()
34  qfw_read_entry(qfw_dev, FW_CFG_SETUP_DATA,
35 le32_to_cpu(setup_size), data_addr);
36  data_addr += le32_to_cpu(setup_size);
37 
38  qfw_read_entry(qfw_dev, FW_CFG_KERNEL_DATA,
39 le32_to_cpu(kernel_size), data_addr);
>>> CID 331156:  Incorrect expression  (UNUSED_VALUE)
>>> Assigning value from "(__u32)(__le32)kernel_size" to "data_addr" here, 
>>> but that stored value is overwritten before it can be used.
40  data_addr += le32_to_cpu(kernel_size);
41 
42  data_addr = initrd_addr;
43  qfw_read_entry(qfw_dev, FW_CFG_INITRD_SIZE, 4, &initrd_size);
44  if (initrd_size == 0) {
45  printf("warning: no initrd available\n");

** CID 331155:  Insecure data handling  (TAINTED_SCALAR)



*** CID 331155:  Insecure data handling  (TAINTED_SCALAR)
/fs/cbfs/cbfs.c: 170 in file_cbfs_next_file()
164 size -= align;
165 start += align;
166 continue;
167 }
168 
169 swap_file_header(&header, file_header);
>>> CID 331155:  Insecure data handling  (TAINTED_SCALAR)
>>> Passing tainted variable "header.offset" to a tainted sink.
170 ret = fill_node(node, start, &header);
171 if (ret) {
172 priv->result = CBFS_BAD_FILE;
173 return log_msg_ret("fill", ret);
174 }
175 

** CID 331154:  Integer handling issues  (DIVIDE_BY_ZERO)
/drivers/pinctrl/pinctrl-single.c: 473 in single_probe()



*** CID 331154:  Integer handling issues  (DIVIDE_BY_ZERO)
/drivers/pinctrl/pinctrl-single.c: 473 in single_probe()
467 return -ENOMEM;
468 #endif
469 
470 priv->npins 

Fwd: New Defects reported by Coverity Scan for efi_capsule.c

[Heinrich Schuchardt]

Dear Sughosh, Takahiro, Jose,

could you please, look into the issues below.



 Forwarded Message 
Subject: New Defects reported by Coverity Scan for Das U-Boot
Date: Mon, 19 Apr 2021 01:18:38 + (UTC)
From: scan-ad...@coverity.com
To: xypron.g...@gmx.de

Hi,

Please find the latest report on new defect(s) introduced to Das U-Boot
found with Coverity Scan.

13 new defect(s) introduced to Das U-Boot found with Coverity Scan.
5 defect(s), reported by Coverity Scan earlier, were marked fixed in the
recent build analyzed by Coverity Scan.

New defect(s) Reported-by: Coverity Scan
Showing 13 of 13 defect(s)


** CID 331153:  Code maintainability issues  (UNUSED_VALUE)
/lib/efi_loader/efi_capsule.c: 661 in find_boot_device()



*** CID 331153:  Code maintainability issues  (UNUSED_VALUE)
/lib/efi_loader/efi_capsule.c: 661 in find_boot_device()
655 size = 0;
656 ret = efi_get_variable_int(L"BootOrder", 
&efi_global_variable_guid,
657NULL, &size, NULL, NULL);
658 if (ret == EFI_BUFFER_TOO_SMALL) {
659 boot_order = malloc(size);
660 if (!boot_order) {
>>> CID 331153:  Code maintainability issues  (UNUSED_VALUE)
>>> Assigning value "9223372036854775817UL" to "ret" here, but that stored 
>>> value is overwritten before it can be used.
661 ret = EFI_OUT_OF_RESOURCES;

@Sughosh, Takahiro
The logic after out: should consider ret. Maybe just move the label
further down.

662 goto out;
663 }
664 665 ret = efi_get_variable_int(L"BootOrder",
666&efi_global_variable_guid,



** CID 331147:  Code maintainability issues  (UNUSED_VALUE)
/lib/efi_loader/efi_capsule.c: 456 in efi_update_capsule()



*** CID 331147:  Code maintainability issues  (UNUSED_VALUE)
/lib/efi_loader/efi_capsule.c: 456 in efi_update_capsule()
450 efi_status_t ret;
451 452 EFI_ENTRY("%p, %zu, %llu\n", capsule_header_array,
capsule_count,
453   scatter_gather_list);
454 455 if (!capsule_count) {
>>> CID 331147:  Code maintainability issues  (UNUSED_VALUE)
>>> Assigning value "9223372036854775810UL" to "ret" here, but that stored 
>>> value is overwritten before it can be used.
456 ret = EFI_INVALID_PARAMETER;

@Jose
Calling efi_esrt_populate() in this case might not be the right thing to do.

457 goto out;
458 }
459 460 ret = EFI_SUCCESS;
461 for (i = 0, capsule = *capsule_header_array; i < capsule_count;

Best regards

Heinrich

Re: [PATCH] Fix IDE commands issued, fix endian issues, fix non MMIO

[Heinrich Schuchardt]

On 24.02.21 22:55, Reinoud Zandijk wrote:
> Dear Heinrich,
>
> On Wed, Feb 24, 2021 at 06:57:08PM +0100, Heinrich Schuchardt wrote:
>> On 24.02.21 17:44, Reinoud Zandijk wrote:
>>>
>>> Fixes IDE issues found on the Malta board under Qemu:
>>>
>>> 1) DMA implied commands were sent to the controller in stead of the PIO
>>> variants. The rest of the code is DMA free and written for PIO operation.
>>>
>>> 2) direct pointer access was used to read and write the registers instead
>>> of the inb/inw/outb/outw functions/macros. Registers don't have to be
>>> memory mapped and ATA_CURR_BASE() does not have to return an offset from
>>> address zero.
>>>
>>> 3) Endian isues in ide_ident() and reading/writing data in general. Names
>>> were corrupted and sizes misreported.
>>
>> It is preferable to have each issue fixed in a separate patch.
>
> They are related; 2 and 3 are really one and 1 could in theory be separate but
> it won't work on its own.

Thanks for the background.

>
>>> Tested malta_defconfig and maltael_defconfig to work again in Qemu.
>>
>> What about the other architectures which can use the driver?
>
> As for testing, I compile tested an ARM board, edminiv2, successfully, but
> don't know how to invoke qemu for it. As for running the tests, my setup is
> not capable of running the tests since they seem to be for linux only.
>
> Does the automatic testing check if disks are indeed found correctly and
> checking reading or writing to a disk image?

qemu-x86_64_defconfig and qemu-x86_defconfig have CONFIG_CMD_IDE=y.

Actually without your patch qemu-x86 cannot read the partition table
from an IDE device. With your patch it works fine.

This was my QEMU command:

   qemu-system-i386 -bios u-boot.rom -nographic sct-i386.img

Tested-by: Heinrich Schuchardt 

Re: gpmi-nand ecc

[Fabio Estevam]

Adding Ye Li as the author of such commit.

On Mon, Apr 19, 2021 at 6:34 AM Sean Nyekjaer  wrote:
>
>
>
> On 19/04/2021 09.32, Miquel Raynal wrote:
> > Hi Sean,
> >
> > + u-boot ML
> >
> > Sean Nyekjaer  wrote on Wed, 14 Apr 2021 15:13:39
> > +0200:
> >
> >> Hi,
> >>
> >> I have two boards with a iMX6ULL SoC one attached to a Micron NAND flash 
> >> (MT29F4G08ABAFAWP) and one a Toshiba (TC58BVG2S0HTAI0).
> >>
> >> After updating the boards from u-boot 2018.07 -> 2020.01, the Micron 
> >> fitted boards is having ECC problems(in u-boot).
> >> U-boot 2018.07 selects ecc_strength to 18.
> >> U-boot 2020.01 selects ecc_strength to 8, but if I hardcode u-boot to run 
> >> the mxs_nand_legacy_calc_ecc_layout() it selects 18 bits.
> >>
> >> The Toshiba boards always selects 8 bit ecc_strength so they have no 
> >> issues.
> >>
> >> The kernel driver (gpmi-nand.c) seems to also use the legacy method 
> >> (Resulting 18 bits in ecc strength for the Micron NAND).
> >> In common_nfc_set_geometry(): Both chip->ecc.strength and chip->ecc.size 
> >> are 0.
> >>
> >> I would expect ecc.strength to be set to 8, earlier but cannot find the 
> >> spot where it should be set.
> >> Is the gpmi-nand driver missing a call to nand_ecc_choose_conf()?
> >> Maybe we need a legacy option for the kernel like u-boot.
> >>
> >> We have +10K boards deployed so it's not so easy to switch from 18 -> 8 
> >> bits.
> >> I can explicit fix this in U-boot by forcing the legacy mode via a dt 
> >> flag, but the gut feeling says this will come back to haunt us :)
> >>
> >> /Sean
> > I honestly don't know about such issue on U-Boot side, maybe you can
> > try to be more specific on what commit broke the logic for you as there
> > are not so many of them between the two versions:
> >
> > $ git l v2018.07..v2020.01 -- drivers/mtd/nand/raw/mxs_nand.c
> > 1eb69ae4985 common: Move ARM cache operations out of common.h
> > 9ab5f221a5e nand: mxs_nand: add API for switching different BCH layouts
> > 1d43e24b946 i.MX6: nand: add nandbcb command for imx
> > 1001502545f CONFIG_SPL_SYS_[DI]CACHE_OFF: add
> > 04568bd0b6d MTD: nand: mxs_nand: Allow driver to auto setup ECC in SPL
> > 5645df9e00a MTD: NAND: mxs_nand_init_dma: Make mxs_nand_init_dma static
> > 5ae585ba3a8 MTD: mxs_nand: Fix BCH read timeout error on boards requiring 
> > ECC
> > a430fa06a4a mtd: move NAND files into a raw/ subdirectory
>
> Hi Miquel,
>
> Thanks for CC'ing the u-boot list :)
>
> commit 616f03dabacb6c500e8a7ceb920cd08554c9fcae
> Author: Ye Li 
> Date:   Mon May 4 22:08:50 2020 +0800
>
>  mtd: gpmi: change the BCH layout setting for large oob NAND
>
> This commit  ^^ introduced the legacy function that was the "primary"
> before.
>
> Guess we can say, that u-boot broke compatibility with the kernel.
> I have fixed my setup by enabling the legacy option via dt, in u-boot.
>
> /Sean

Re: [PATCH 1/2] gpio: atmel_pio4: add support for sama7g5 pio4 version with 5 banks

[Eugen.Hristev]

On 4/7/21 11:39 AM, Eugen Hristev wrote:
> Add support for sama7g5 pinctrl variant, with 5 banks with a degraded
> 8 line only 5th bank.
> Based on Linux Kernel implementation.
> 
> Signed-off-by: Eugen Hristev 
> ---
>   drivers/gpio/atmel_pio4.c | 22 ++
>   1 file changed, 22 insertions(+)
> 

Applied both to u-boot-atmel/master

Re: [PATCH v2] ARM: dts: at91: sama5d3: add u-boot properties to sama5d3 pit timer

[Eugen.Hristev]

On 4/7/21 12:39 PM, Manuel Luís Reis wrote:
> Great, thanks for your help.
> 
> Cheers
> Manuel
> 
> M. Luís Reis MSc MIET Chartered Engineer
> 
> 
> 
> On Wed, 7 Apr 2021 at 10:31,  wrote:
>>
>> On 4/7/21 12:16 PM, Manuel Luís Reis wrote:
>>> Hi,
>>>
>>> @Derald: Thanks for trying this out.
>>>
>>> @Eugen: For what is worth, I can also confirm that I also tried with
>>> the latest version v2021.04 and the board boots OK out of the box with
>>> this patch only.
>>>
>>
>> Ok, great news ! Thanks.
>>
>> Until this patch can reach the master of u-boot, if anyone needs a tree,
>> you can have my testing branch in u-boot-atmel custodian tree at denx:
>>
>> https://source.denx.de/u-boot/custodians/u-boot-atmel/-/tree/testing
>>
>> Eugen
>>
>>> 
>>> RomBOOT
>>> 
>>> U-Boot SPL 2021.04-00372-g90eba245a6-dirty (Apr 07 2021 - 10:05:18 +0100)
>>> Trying to boot from MMC1
>>> 
>>> U-Boot 2021.04-00372-g90eba245a6-dirty (Apr 07 2021 - 10:05:18 +0100)
>>> CPU: SAMA5D36
>>> Crystal frequency:   12 MHz
>>> .
>>> 
>>>
>>> Thanks,
>>> Manuel
>>>
>>> On Wed, 7 Apr 2021 at 07:32,  wrote:

 On 4/7/21 1:16 AM, Derald Woods wrote:
> On Tue, Apr 6, 2021 at 4:40 AM Manuel Reis  > wrote:
>
>   in the early SPL boot stage whenever there is a call to udelay,
>   dm_timer_init fails to find the pit timer whenever it traverses
>   the device tree, if this property is not present
>
>   Signed-off-by: Manuel Reis    >
>   CC: Eugen Hristev    >
>   ---
> arch/arm/dts/sama5d3.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
>   diff --git a/arch/arm/dts/sama5d3.dtsi b/arch/arm/dts/sama5d3.dtsi
>   index 6ed218eaad..42c30e9f30 100644
>   --- a/arch/arm/dts/sama5d3.dtsi
>   +++ b/arch/arm/dts/sama5d3.dtsi
>   @@ -1320,6 +1320,7 @@
>reg = <0xfe30 0xf>;
>interrupts = <3 
> IRQ_TYPE_LEVEL_HIGH 5>;
>clocks = <&mck>;
>   +   u-boot,dm-pre-reloc;
>};
>
>watchdog@fe40 {
>   --
>   2.27.0
>
>
> This patch, on top of v2021.04, allows my SAMA5D3 Xplained board to boot
> normally again.
>
> Tested-by: Derald D. Woods  >

Applied to u-boot-atmel/master, thanks, and,

Reviewed-by: Eugen Hristev 

>

 Hi Derald,

 Could I ask, you are using the SPL to boot your board ?
 Did you have to remove any udelay from the ddr2_init code , or it booted
 out of the box by applying this patch only ?

 Thanks,
 Eugen
>>

pcie + nvme + cyclone V

[Brian McKee]

Hello all.

I'm trying to get an NVMe device to work with a PCIe hard core in an Altera
(intel) Cyclone V SOC from u-boot.

It is working well in linux.

I have been hacking on u-boot for about a week and have drawn some
conclusions that may or may not be accurate.

First, let me give you some background.

In linux, the device tree description for the pcie module looks like this:

bridges: bridge@c000 {
compatible = "altr,bridge-20.1", "simple-bus";
reg = <0xc000 0x2000>,
  <0xff20 0x0020>;
reg-names = "axi_h2f", "axi_h2f_lw";
clocks = <&pcie &pll_65 &pcie &pll_65>;
clock-names = "h2f_axi_clock", "h2f_lw_axi_clock", "f2h_sdram0_clock",
"f2h_sdram1_clock";
#address-cells = <2>;
#size-cells = <1>;
ranges = <0x 0x00200080 0xc0200080 0x0010>,
<0x 0x0020 0xc020 0x0080>,
<0x 0x 0xc000 0x0010>,
<0x 0x0010 0xc010 0x4000>,
<0x0001 0x 0xff20 0x0010>;

pcie: pcie@00010 { // The @00010 signifies nothing!
compatible = "altr,pcie-root-port-20.1", "altr,pcie-root-port-1.0";
reg = <0x 0x 0x0010>,
  <0x 0x0010 0x4000>;
reg-names = "Txs", "Cra";
interrupt-parent = <&intc>;
interrupts = <0 40 4>; // 40 is the interrupt, add 32 to relate to the GIC
document
interrupt-controller;  // 4 is IRQ_TYPE_LEVEL_HIGH, 1 is
IRQ_TYPE_EDGE_RISING
#address-cells = <3>;
#size-cells = <2>;
#interrupt-cells = <1>;
#clock-cells = <0>;
clocks = <&clk_100>;
device_type = "pci";
bus-range = <0x00 0xff>;
ranges = <0x8200 0x0 0x 0x0 0x 0x0 0x0010>;
msi-parent = <&msi>;
interrupt-map-mask = <0 0 0 7>;
interrupt-map = <0 0 0 1 &pcie 1>,
<0 0 0 2 &pcie 2>,
<0 0 0 3 &pcie 3>,
<0 0 0 4 &pcie 4>;
status = "disabled"; // Disabled by default
}; //end pcie@00010

msi: msi@000200080 {
compatible = "altr,msi-1.0";
reg = <0x 0x00200080 0x0010>,
  <0x 0x0020 0x0080>;
reg-names = "csr", "vector_slave";
interrupt-parent = <&intc>;
interrupts = <0 41 4>;
clocks = <&pll_65>;
msi-controller = <1>;
num-vectors = <32>;
status = "disabled"; // Disabled by default
}; //end msi@000200080

}; //end bridge@c000 (bridges)

Sorry, the indenting was lost.

That portion of socfpga.dtsi works in linux. BUS 1 BAR 0 of the PCIe
controller is programmed correctly, offset 0x10 gets an address of
0x and CPU space is mapped to 0xc000.

However, from what I can tell, u-boot can't handle the hierarchical nature
of "simple-bus". It doesn't know how to or the two addresses to get a
resultant CPU memory base address. That's not a big problem, because I can
flatten the tree to look like this:

pcie: pcie@00010 {
compatible = "altr,pcie-root-port-1.0";
reg = <0x 0x0010>,
 <0xC010 0x4000>;
reg-names = "Txs", "Cra";
interrupt-parent = <&intc>;
interrupts = <0 40 4>; // 40 is the interrupt, add 32 to relate to the GIC
document
interrupt-controller;  // 4 is IRQ_TYPE_LEVEL_HIGH, 1 is
IRQ_TYPE_EDGE_RISING
#address-cells = <2>;
#size-cells = <1>;
#interrupt-cells = <1>;
#clock-cells = <0>;
clocks = <&clk_100>;
device_type = "pci";
bus-range  = <0x00 0xff>;
ranges = <0x8200 0x 0xc000 0x0010>;
//   <32BITNOPF>   
msi-parent = <&msi>;
interrupt-map-mask = <0 0 0 7>;
interrupt-map = <0 0 0 1 &pcie 1>,
<0 0 0 2 &pcie 2>,
<0 0 0 3 &pcie 3>,
<0 0 0 4 &pcie 4>;
}; //end pcie@00010

msi: msi@C0200080 {
compatible = "altr,msi-1.0";
reg = <0x0 0xC0200080 0x0010>,
 <0x0 0xC020 0x0080>;
reg-names = "csr", "vector_slave";
interrupt-parent = <&intc>;
interrupts = <0 41 4>;
clocks = <&pll_65>;
msi-controller = <1>;
num-vectors = <32>;
}; //end msi@000200080

However, this does not work either.

The PCI driver becomes confused by the ranges description: I think because
it does not understand that the pci device perspective can be different
from the CPU perspective. It can't find the memory described in the ranges
variable and I get debug output (plus printfs that I added) that looks like
this:

pciauto_setup_device: bars_num = 6
cfg_dword_read: bus=1, byte_en=0x3, offset=0x0004, data=0x0010
cfg_dword_write: bus=1, byte_en=0xf, offset=0x0010, data=0x
cfg_dword_read: bus=1, byte_en=0xf, offset=0x0010, data=0xc004
bar_response = 0xc004
PCI address space is 64 bit.
cfg_dword_write: bus=1, byte_en=0xf, offset=0x0014, data=0x
cfg_dword_read: bus=1, byte_en=0xf, offset=0x0014, data=0x
PCI Autoconfig: BAR 0, Mem, size=0x4000
res->bus_lower = 0x0, size = 0x4000, res->size = 0x10
addr = 0x0, res->bus_start = 0xc000
No room in resource, avail start=0 / size=10, need=4000
PCI: Failed autoconfig bar 0
bar_value = 0x

I have hacked pci_auto to get the correct values programmed into BUS 1 BAR
0, however, the nvme driver chokes when it goes and looks for the memory
indicated by BUS 1 BAR 0 and can't find it because the NVMe driver (pci
driver, actually?) needs to 

[PATCH v2 5/5] test/py: Add usb gadget binding test

[Patrice Chotard]

Add a specific usb gadget binding test which check that
binding a driver without compatible string is working as expected.

the command "bind /usb@1 usb_ether" should give the following "dm tree"
command output:

[...]
 usb   0  [   ]   usb_sandbox   |-- usb@1
 usb_hub   0  [   ]   usb_hub   |   |-- hub
 usb_emul  0  [   ]   usb_sandbox_hub   |   |   `-- hub-emul
 usb_emul  1  [   ]   usb_sandbox_flash |   |   |-- flash-stick@0
 usb_emul  2  [   ]   usb_sandbox_flash |   |   |-- flash-stick@1
 usb_emul  3  [   ]   usb_sandbox_flash |   |   |-- flash-stick@2
 usb_emul  4  [   ]   usb_sandbox_keyb  |   |   `-- keyb@3
 eth   4  [   ]   usb_ether |   `-- usb@1
[...]

Signed-off-by: Patrice Chotard 
Cc: Marek Vasut 
Cc: Herbert Poetzl 

---

Changes in v2:
  - add bind test

 test/py/tests/test_bind.py | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/test/py/tests/test_bind.py b/test/py/tests/test_bind.py
index 6703325c0b..56edd78863 100644
--- a/test/py/tests/test_bind.py
+++ b/test/py/tests/test_bind.py
@@ -33,6 +33,13 @@ def test_bind_unbind_with_node(u_boot_console):
assert in_tree(tree, 'bind-test-child1', 'phy', 'phy_sandbox', 1, False)
assert in_tree(tree, 'bind-test-child2', 'simple_bus', 'simple_bus', 1, 
True)
 
+   #bind usb_ether driver (which has no compatible) to usb@1 node.
+   ##New entry usb_ether should appear in the dm tree
+   response = u_boot_console.run_command('bind  /usb@1 usb_ether')
+   assert response == ''
+   tree = u_boot_console.run_command('dm tree')
+   assert in_tree(tree, 'usb@1', 'eth', 'usb_ether', 1, True)
+
#Unbind child #1. No error expected and all devices should be there 
except for bind-test-child1
response = u_boot_console.run_command('unbind  
/bind-test/bind-test-child1')
assert response == ''
-- 
2.17.1

[PATCH v2 1/5] cmd: bind: Fix driver binding on a device

[Patrice Chotard]

Fix a regression brings by commit 84f8e36f03fa ("cmd: bind: allow to
bind driver with driver data")

As example, the following bind command doesn't work:

   bind /soc/usb-otg@4900 usb_ether

As usb_ether driver has no compatible string, it can't be find by
lists_bind_fdt(). In bind_by_node_path(), which called lists_bind_fdt(),
the driver entry is known, pass it to lists_bind_fdt() to force the driver
entry selection.

For this, add a new parameter struct *driver to lists_bind_fdt().
Fix also all lists_bind_fdt() callers.

Fixes: 84f8e36f03fa ("cmd: bind: allow to bind driver with driver data")
Signed-off-by: Patrice Chotard 
Reported-by: Herbert Poetzl 
Cc: Marek Vasut 
Cc: Herbert Poetzl 
Reviewed-by: Andy Shevchenko 
Reviewed-by: Simon Glass 
---

(no changes since v1)

 cmd/bind.c |  2 +-
 drivers/core/device.c  |  2 +-
 drivers/core/lists.c   | 11 ---
 drivers/core/root.c|  2 +-
 drivers/misc/imx8/scu.c|  2 +-
 drivers/serial/serial-uclass.c |  2 +-
 drivers/timer/timer-uclass.c   |  2 +-
 include/dm/lists.h |  3 ++-
 test/dm/nop.c  |  2 +-
 test/dm/test-fdt.c |  2 +-
 10 files changed, 18 insertions(+), 12 deletions(-)

diff --git a/cmd/bind.c b/cmd/bind.c
index af2f22cc4c..d8f610943c 100644
--- a/cmd/bind.c
+++ b/cmd/bind.c
@@ -152,7 +152,7 @@ static int bind_by_node_path(const char *path, const char 
*drv_name)
}
 
ofnode = ofnode_path(path);
-   ret = lists_bind_fdt(parent, ofnode, &dev, false);
+   ret = lists_bind_fdt(parent, ofnode, &dev, drv, false);
 
if (!dev || ret) {
printf("Unable to bind. err:%d\n", ret);
diff --git a/drivers/core/device.c b/drivers/core/device.c
index 81f6880eac..3abd89aca6 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -1133,6 +1133,6 @@ int dev_enable_by_path(const char *path)
if (ret)
return ret;
 
-   return lists_bind_fdt(parent, node, NULL, false);
+   return lists_bind_fdt(parent, node, NULL, NULL, false);
 }
 #endif
diff --git a/drivers/core/lists.c b/drivers/core/lists.c
index e214306b90..2eb808ce2d 100644
--- a/drivers/core/lists.c
+++ b/drivers/core/lists.c
@@ -182,7 +182,7 @@ static int driver_check_compatible(const struct udevice_id 
*of_match,
 }
 
 int lists_bind_fdt(struct udevice *parent, ofnode node, struct udevice **devp,
-  bool pre_reloc_only)
+  struct driver *drv, bool pre_reloc_only)
 {
struct driver *driver = ll_entry_start(struct driver, driver);
const int n_ents = ll_entry_count(struct driver, driver);
@@ -225,8 +225,13 @@ int lists_bind_fdt(struct udevice *parent, ofnode node, 
struct udevice **devp,
for (entry = driver; entry != driver + n_ents; entry++) {
ret = driver_check_compatible(entry->of_match, &id,
  compat);
-   if (!ret)
-   break;
+   if (drv) {
+   if (drv == entry)
+   break;
+   } else {
+   if (!ret)
+   break;
+   }
}
if (entry == driver + n_ents)
continue;
diff --git a/drivers/core/root.c b/drivers/core/root.c
index 9bc682cffe..3c6fa3838d 100644
--- a/drivers/core/root.c
+++ b/drivers/core/root.c
@@ -236,7 +236,7 @@ static int dm_scan_fdt_node(struct udevice *parent, ofnode 
parent_node,
pr_debug("   - ignoring disabled device\n");
continue;
}
-   err = lists_bind_fdt(parent, node, NULL, pre_reloc_only);
+   err = lists_bind_fdt(parent, node, NULL, NULL, pre_reloc_only);
if (err && !ret) {
ret = err;
debug("%s: ret=%d\n", node_name, ret);
diff --git a/drivers/misc/imx8/scu.c b/drivers/misc/imx8/scu.c
index 035a600f71..4ab5cb4bf1 100644
--- a/drivers/misc/imx8/scu.c
+++ b/drivers/misc/imx8/scu.c
@@ -219,7 +219,7 @@ static int imx8_scu_bind(struct udevice *dev)
 
debug("%s(dev=%p)\n", __func__, dev);
ofnode_for_each_subnode(node, dev_ofnode(dev)) {
-   ret = lists_bind_fdt(dev, node, &child, true);
+   ret = lists_bind_fdt(dev, node, &child, NULL, true);
if (ret)
return ret;
debug("bind child dev %s\n", child->name);
diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c
index 8a87eed683..6d1c671efc 100644
--- a/drivers/serial/serial-uclass.c
+++ b/drivers/serial/serial-uclass.c
@@ -67,7 +67,7 @@ static int serial_check_stdout(const void *blob, struct 
udevice **devp)
 * anyway.
 */
if (node > 0 && !lists_bind

[PATCH v2 4/5] configs: sandbox: add USB_ETHER and GADGET_DOWNLOAD gadget support

[Patrice Chotard]

This is needed for new gadget binding test.

Signed-off-by: Patrice Chotard 
Cc: Marek Vasut 
Cc: Herbert Poetzl 
---

(no changes since v1)

 configs/sandbox_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 5bc90d09a8..f7eb27d4a1 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -251,6 +251,9 @@ CONFIG_USB=y
 CONFIG_DM_USB=y
 CONFIG_USB_EMUL=y
 CONFIG_USB_KEYBOARD=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_USB_ETHER=y
 CONFIG_DM_VIDEO=y
 CONFIG_VIDEO_COPY=y
 CONFIG_CONSOLE_ROTATION=y
-- 
2.17.1

[PATCH v2 2/5] usb: gadget: Add bcdDevice for the DWC2 USB Gadget Controller

[Patrice Chotard]

Add an entry in usb_gadget_controller_number() for the DWC2
gadget controller. It is used to bind the USB Ethernet driver.

Signed-off-by: Patrice Chotard 
Reported-by: Herbert Poetzl 
Cc: Marek Vasut 
Cc: Herbert Poetzl 
---

(no changes since v1)

 drivers/usb/gadget/gadget_chips.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/usb/gadget/gadget_chips.h 
b/drivers/usb/gadget/gadget_chips.h
index 0cdf47c2dd..06e6a48949 100644
--- a/drivers/usb/gadget/gadget_chips.h
+++ b/drivers/usb/gadget/gadget_chips.h
@@ -167,6 +167,12 @@
 #define gadget_is_mtu3(g)0
 #endif
 
+#ifdef CONFIG_USB_GADGET_DWC2_OTG
+#define gadget_is_dwc2(g)(!strcmp("dwc2-udc", (g)->name))
+#else
+#define gadget_is_dwc2(g)0
+#endif
+
 /**
  * usb_gadget_controller_number - support bcdDevice id convention
  * @gadget: the controller being driven
@@ -232,5 +238,7 @@ static inline int usb_gadget_controller_number(struct 
usb_gadget *gadget)
return 0x25;
else if (gadget_is_mtu3(gadget))
return 0x26;
+   else if (gadget_is_dwc2(gadget))
+   return 0x27;
return -ENOENT;
 }
-- 
2.17.1

[PATCH v2 0/5] cmd: bind: Fix driver binding

[Patrice Chotard]

This series is fixing issues reported by Herbert Poetzl when trying to
bind Ethernet gadget over USB on STM32MP1 platform.
2 issues have been found:
   - fix the bind command.
   - add dwc2 bcdDevice in USB gadget controller.
   - add test to check binding of driver without compatible string.

Changes in v2:
  - add bind test

Patrice Chotard (5):
  cmd: bind: Fix driver binding on a device
  usb: gadget: Add bcdDevice for the DWC2 USB Gadget Controller
  usb: sandbox: Add gadget callbacks
  configs: sandbox: add USB_ETHER and GADGET_DOWNLOAD gadget support
  test/py: Add usb gadget binding test

 cmd/bind.c|  2 +-
 configs/sandbox_defconfig |  3 +++
 drivers/core/device.c |  2 +-
 drivers/core/lists.c  | 11 ---
 drivers/core/root.c   |  2 +-
 drivers/misc/imx8/scu.c   |  2 +-
 drivers/serial/serial-uclass.c|  2 +-
 drivers/timer/timer-uclass.c  |  2 +-
 drivers/usb/gadget/gadget_chips.h |  8 
 drivers/usb/host/usb-sandbox.c| 28 
 include/dm/lists.h|  3 ++-
 test/dm/nop.c |  2 +-
 test/dm/test-fdt.c|  2 +-
 test/py/tests/test_bind.py|  7 +++
 14 files changed, 64 insertions(+), 12 deletions(-)

-- 
2.17.1

[PATCH v2 3/5] usb: sandbox: Add gadget callbacks

[Patrice Chotard]

Add usb_gadget_handle_interrupts(), usb_gadget_register_driver()
and usb_gadget_unregister_driver() to be able to test
binding usb gadget.

Signed-off-by: Patrice Chotard 
Cc: Marek Vasut 
Cc: Herbert Poetzl 
---

(no changes since v1)

 drivers/usb/host/usb-sandbox.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/drivers/usb/host/usb-sandbox.c b/drivers/usb/host/usb-sandbox.c
index d7cc92aa54..d1103dcb2e 100644
--- a/drivers/usb/host/usb-sandbox.c
+++ b/drivers/usb/host/usb-sandbox.c
@@ -9,6 +9,13 @@
 #include 
 #include 
 #include 
+#include 
+
+struct sandbox_udc {
+   struct usb_gadget gadget;
+};
+
+struct sandbox_udc *this_controller;
 
 struct sandbox_usb_ctrl {
int rootdev;
@@ -117,6 +124,27 @@ static int sandbox_submit_int(struct udevice *bus, struct 
usb_device *udev,
return ret;
 }
 
+int usb_gadget_handle_interrupts(int index)
+{
+   return 0;
+}
+
+int usb_gadget_register_driver(struct usb_gadget_driver *driver)
+{
+   struct sandbox_udc *dev = this_controller;
+
+   return driver->bind(&dev->gadget);
+}
+
+int usb_gadget_unregister_driver(struct usb_gadget_driver *driver)
+{
+   struct sandbox_udc *dev = this_controller;
+
+   driver->unbind(&dev->gadget);
+
+   return 0;
+}
+
 static int sandbox_alloc_device(struct udevice *dev, struct usb_device *udev)
 {
struct sandbox_usb_ctrl *ctrl = dev_get_priv(dev);
-- 
2.17.1

Re: [PATCH] Fix IDE commands issued, fix endian issues, fix non MMIO

[Reinoud Zandijk]

ping?

On Wed, Feb 24, 2021 at 10:55:07PM +0100, Reinoud Zandijk wrote:
> Dear Heinrich,
> 
> On Wed, Feb 24, 2021 at 06:57:08PM +0100, Heinrich Schuchardt wrote:
> > On 24.02.21 17:44, Reinoud Zandijk wrote:
> > >
> > > Fixes IDE issues found on the Malta board under Qemu:
> > >
> > > 1) DMA implied commands were sent to the controller in stead of the PIO
> > > variants. The rest of the code is DMA free and written for PIO operation.
> > >
> > > 2) direct pointer access was used to read and write the registers instead
> > > of the inb/inw/outb/outw functions/macros. Registers don't have to be
> > > memory mapped and ATA_CURR_BASE() does not have to return an offset from
> > > address zero.
> > >
> > > 3) Endian isues in ide_ident() and reading/writing data in general. Names
> > > were corrupted and sizes misreported.
> > 
> > It is preferable to have each issue fixed in a separate patch.
> 
> They are related; 2 and 3 are really one and 1 could in theory be separate but
> it won't work on its own.
> 
> > > Tested malta_defconfig and maltael_defconfig to work again in Qemu.
> > 
> > What about the other architectures which can use the driver?
> 
> As for testing, I compile tested an ARM board, edminiv2, successfully, but
> don't know how to invoke qemu for it. As for running the tests, my setup is
> not capable of running the tests since they seem to be for linux only.
> 
> Does the automatic testing check if disks are indeed found correctly and
> checking reading or writing to a disk image?
> 
> With regards,
> Reinoud

Re: gpmi-nand ecc

[Sean Nyekjaer]

On 19/04/2021 09.32, Miquel Raynal wrote:

Hi Sean,

+ u-boot ML

Sean Nyekjaer  wrote on Wed, 14 Apr 2021 15:13:39
+0200:


Hi,

I have two boards with a iMX6ULL SoC one attached to a Micron NAND flash 
(MT29F4G08ABAFAWP) and one a Toshiba (TC58BVG2S0HTAI0).

After updating the boards from u-boot 2018.07 -> 2020.01, the Micron fitted 
boards is having ECC problems(in u-boot).
U-boot 2018.07 selects ecc_strength to 18.
U-boot 2020.01 selects ecc_strength to 8, but if I hardcode u-boot to run the 
mxs_nand_legacy_calc_ecc_layout() it selects 18 bits.

The Toshiba boards always selects 8 bit ecc_strength so they have no issues.

The kernel driver (gpmi-nand.c) seems to also use the legacy method (Resulting 
18 bits in ecc strength for the Micron NAND).
In common_nfc_set_geometry(): Both chip->ecc.strength and chip->ecc.size are 0.

I would expect ecc.strength to be set to 8, earlier but cannot find the spot 
where it should be set.
Is the gpmi-nand driver missing a call to nand_ecc_choose_conf()?
Maybe we need a legacy option for the kernel like u-boot.

We have +10K boards deployed so it's not so easy to switch from 18 -> 8 bits.
I can explicit fix this in U-boot by forcing the legacy mode via a dt flag, but 
the gut feeling says this will come back to haunt us :)

/Sean

I honestly don't know about such issue on U-Boot side, maybe you can
try to be more specific on what commit broke the logic for you as there
are not so many of them between the two versions:

$ git l v2018.07..v2020.01 -- drivers/mtd/nand/raw/mxs_nand.c
1eb69ae4985 common: Move ARM cache operations out of common.h
9ab5f221a5e nand: mxs_nand: add API for switching different BCH layouts
1d43e24b946 i.MX6: nand: add nandbcb command for imx
1001502545f CONFIG_SPL_SYS_[DI]CACHE_OFF: add
04568bd0b6d MTD: nand: mxs_nand: Allow driver to auto setup ECC in SPL
5645df9e00a MTD: NAND: mxs_nand_init_dma: Make mxs_nand_init_dma static
5ae585ba3a8 MTD: mxs_nand: Fix BCH read timeout error on boards requiring ECC
a430fa06a4a mtd: move NAND files into a raw/ subdirectory


Hi Miquel,

Thanks for CC'ing the u-boot list :)

commit 616f03dabacb6c500e8a7ceb920cd08554c9fcae
Author: Ye Li 
Date:   Mon May 4 22:08:50 2020 +0800

    mtd: gpmi: change the BCH layout setting for large oob NAND

This commit  ^^ introduced the legacy function that was the "primary" 
before.


Guess we can say, that u-boot broke compatibility with the kernel.
I have fixed my setup by enabling the legacy option via dt, in u-boot.

/Sean

[PATCH] arm: allwinner: r40: update R40 DT files from linux 5.12-rc1

[Ivan Uvarov]

Update R40 .dts{,i} and dt-binding headers to current version from kernel.

Files taken from Linux 5.12-rc1 release
(commit fe07bfda2fb9cdef8a4d4008a409bb02f35f1bd8)

Signed-off-by: Ivan Uvarov 
---
 arch/arm/dts/sun8i-r40-bananapi-m2-ultra.dts  |  23 +-
 arch/arm/dts/sun8i-r40.dtsi   | 375 --
 arch/arm/dts/sun8i-v40-bananapi-m2-berry.dts  |  12 +-
 include/dt-bindings/clock/sun8i-r40-ccu.h |   6 +-
 .../interrupt-controller/arm-gic.h|   5 +-
 include/dt-bindings/thermal/thermal.h |   3 +-
 6 files changed, 375 insertions(+), 49 deletions(-)

diff --git a/arch/arm/dts/sun8i-r40-bananapi-m2-ultra.dts 
b/arch/arm/dts/sun8i-r40-bananapi-m2-ultra.dts
index c488aaacbd..a6a1087a0c 100644
--- a/arch/arm/dts/sun8i-r40-bananapi-m2-ultra.dts
+++ b/arch/arm/dts/sun8i-r40-bananapi-m2-ultra.dts
@@ -129,7 +129,7 @@
pinctrl-names = "default";
pinctrl-0 = <&gmac_rgmii_pins>;
phy-handle = <&phy1>;
-   phy-mode = "rgmii";
+   phy-mode = "rgmii-id";
phy-supply = <®_dc1sw>;
status = "okay";
 };
@@ -164,6 +164,10 @@
 
 #include "axp22x.dtsi"
 
+&ir0 {
+   status = "okay";
+};
+
 &mmc0 {
vmmc-supply = <®_dcdc1>;
bus-width = <4>;
@@ -201,10 +205,15 @@
 &pio {
pinctrl-names = "default";
pinctrl-0 = <&clk_out_a_pin>;
+   vcc-pa-supply = <®_aldo2>;
+   vcc-pc-supply = <®_dcdc1>;
+   vcc-pd-supply = <®_dcdc1>;
+   vcc-pe-supply = <®_eldo1>;
+   vcc-pf-supply = <®_dcdc1>;
+   vcc-pg-supply = <®_dldo1>;
 };
 
 ®_aldo2 {
-   regulator-always-on;
regulator-min-microvolt = <250>;
regulator-max-microvolt = <250>;
regulator-name = "vcc-pa";
@@ -218,16 +227,16 @@
 };
 
 ®_dc1sw {
-   regulator-min-microvolt = <300>;
-   regulator-max-microvolt = <300>;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
regulator-name = "vcc-gmac-phy";
 };
 
 ®_dcdc1 {
regulator-always-on;
-   regulator-min-microvolt = <300>;
-   regulator-max-microvolt = <300>;
-   regulator-name = "vcc-3v0";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc-3v3";
 };
 
 ®_dcdc2 {
diff --git a/arch/arm/dts/sun8i-r40.dtsi b/arch/arm/dts/sun8i-r40.dtsi
index 06b685869f..d5ad3b9efd 100644
--- a/arch/arm/dts/sun8i-r40.dtsi
+++ b/arch/arm/dts/sun8i-r40.dtsi
@@ -44,8 +44,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 
 / {
#address-cells = <1>;
@@ -78,25 +80,25 @@
#address-cells = <1>;
#size-cells = <0>;
 
-   cpu@0 {
+   cpu0: cpu@0 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <0>;
};
 
-   cpu@1 {
+   cpu1: cpu@1 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <1>;
};
 
-   cpu@2 {
+   cpu2: cpu@2 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <2>;
};
 
-   cpu@3 {
+   cpu3: cpu@3 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <3>;
@@ -109,6 +111,22 @@
status = "disabled";
};
 
+   thermal-zones {
+   cpu_thermal: cpu0-thermal {
+   /* milliseconds */
+   polling-delay-passive = <0>;
+   polling-delay = <0>;
+   thermal-sensors = <&ths 0>;
+   };
+
+   gpu_thermal: gpu-thermal {
+   /* milliseconds */
+   polling-delay-passive = <0>;
+   polling-delay = <0>;
+   thermal-sensors = <&ths 1>;
+   };
+   };
+
soc {
compatible = "simple-bus";
#address-cells = <1>;
@@ -118,11 +136,11 @@
display_clocks: clock@100 {
compatible = "allwinner,sun8i-r40-de2-clk",
 "allwinner,sun8i-h3-de2-clk";
-   reg = <0x0100 0x10>;
-   clocks = <&ccu CLK_DE>,
-<&ccu CLK_BUS_DE>;
-   clock-names = "mod",
- "bus";
+   reg = <0x0100 0x1>;
+   clocks = <&ccu CLK_BUS_DE>,
+<&ccu CLK_DE>;
+   clock-names = "bus",
+ "mod";
resets = <&ccu RST_BUS_DE>;
   

Re: [PATCH v2 05/13] mtd: spi-nor-ids: add support for Macronix mx25u51245g and mx66u1g45g flash

[Pratyush Yadav]

On 17/04/21 08:38AM, Masami Hiramatsu wrote:
> From: Jassi Brar 
> 
> Signed-off-by: Jassi Brar 
> ---
>  drivers/mtd/spi/spi-nor-ids.c |2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
> index 2b57797954..30a18b4140 100644
> --- a/drivers/mtd/spi/spi-nor-ids.c
> +++ b/drivers/mtd/spi/spi-nor-ids.c
> @@ -160,9 +160,11 @@ const struct flash_info spi_nor_ids[] = {
>   { INFO("mx25l12855e", 0xc22618, 0, 64 * 1024, 256, 0) },
>   { INFO("mx25l25635e", 0xc22019, 0, 64 * 1024, 512, SPI_NOR_DUAL_READ | 
> SPI_NOR_QUAD_READ) },
>   { INFO("mx25u25635f", 0xc22539, 0, 64 * 1024, 512, SECT_4K | 
> SPI_NOR_4B_OPCODES) },
> + { INFO("mx25u51245g", 0xc2253a, 0, 64 * 1024, 1024, SECT_4K | 
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },

The flash ID is the same as that of mx66u51235f. Because the ID matching 
function searches through this array in linear fashion, mx66u51235f can 
never be detected. This is a regression.

I am seeing a lot of ID collisions on Macronix flashes recently [0]. Not 
sure how to handle them though. At least in this case both flashes use 
the same set of flags so it should just change the name of the flash 
detected.

[0] 
https://lore.kernel.org/linux-mtd/caeymn7zep9f1sue6umrdwkr8bvt5hdri-4f3+g-gp9anugg...@mail.gmail.com/T/#u

>   { INFO("mx25l25655e", 0xc22619, 0, 64 * 1024, 512, 0) },
>   { INFO("mx66l51235l", 0xc2201a, 0, 64 * 1024, 1024, SPI_NOR_DUAL_READ | 
> SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
>   { INFO("mx66u51235f", 0xc2253a, 0, 64 * 1024, 1024, SECT_4K | 
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
> + { INFO("mx66u1g45g",  0xc2253b, 0, 64 * 1024, 2048, SECT_4K | 
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
>   { INFO("mx66u2g45g",  0xc2253c, 0, 64 * 1024, 4096, SECT_4K | 
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
>   { INFO("mx66l1g45g",  0xc2201b, 0, 64 * 1024, 2048, SECT_4K | 
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
>   { INFO("mx25l1633e", 0xc22415, 0, 64 * 1024,   32, SPI_NOR_QUAD_READ | 
> SPI_NOR_4B_OPCODES | SECT_4K) },
> 

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.

Re: gpmi-nand ecc

[Miquel Raynal]

Hi Sean,

+ u-boot ML

Sean Nyekjaer  wrote on Wed, 14 Apr 2021 15:13:39
+0200:

> Hi,
> 
> I have two boards with a iMX6ULL SoC one attached to a Micron NAND flash 
> (MT29F4G08ABAFAWP) and one a Toshiba (TC58BVG2S0HTAI0).
> 
> After updating the boards from u-boot 2018.07 -> 2020.01, the Micron fitted 
> boards is having ECC problems(in u-boot).
> U-boot 2018.07 selects ecc_strength to 18.
> U-boot 2020.01 selects ecc_strength to 8, but if I hardcode u-boot to run the 
> mxs_nand_legacy_calc_ecc_layout() it selects 18 bits.
> 
> The Toshiba boards always selects 8 bit ecc_strength so they have no issues.
> 
> The kernel driver (gpmi-nand.c) seems to also use the legacy method 
> (Resulting 18 bits in ecc strength for the Micron NAND).
> In common_nfc_set_geometry(): Both chip->ecc.strength and chip->ecc.size are 
> 0.
> 
> I would expect ecc.strength to be set to 8, earlier but cannot find the spot 
> where it should be set.
> Is the gpmi-nand driver missing a call to nand_ecc_choose_conf()?
> Maybe we need a legacy option for the kernel like u-boot.
> 
> We have +10K boards deployed so it's not so easy to switch from 18 -> 8 bits.
> I can explicit fix this in U-boot by forcing the legacy mode via a dt flag, 
> but the gut feeling says this will come back to haunt us :)
> 
> /Sean

I honestly don't know about such issue on U-Boot side, maybe you can
try to be more specific on what commit broke the logic for you as there
are not so many of them between the two versions:

$ git l v2018.07..v2020.01 -- drivers/mtd/nand/raw/mxs_nand.c 
1eb69ae4985 common: Move ARM cache operations out of common.h
9ab5f221a5e nand: mxs_nand: add API for switching different BCH layouts
1d43e24b946 i.MX6: nand: add nandbcb command for imx
1001502545f CONFIG_SPL_SYS_[DI]CACHE_OFF: add
04568bd0b6d MTD: nand: mxs_nand: Allow driver to auto setup ECC in SPL
5645df9e00a MTD: NAND: mxs_nand_init_dma: Make mxs_nand_init_dma static
5ae585ba3a8 MTD: mxs_nand: Fix BCH read timeout error on boards requiring ECC
a430fa06a4a mtd: move NAND files into a raw/ subdirectory

Good luck with your debugging,
Miquèl

Re: [PATCH v6 00/14] mtd: spi-nor: Add support for Cypress s25hl-t/s25hs-t

[Jagan Teki]

On Wed, Apr 7, 2021 at 9:01 AM  wrote:
>
> From: Takahiro Kuwano 
>
> The S25HL-T/S25HS-T family is the Cypress Semper Flash with Quad SPI.
>
> The summary datasheets can be found in the following links.
> https://www.cypress.com/file/424146/download (256Mb/512Mb/1Gb, single die)
> https://www.cypress.com/file/499246/download (2Gb/4Gb, dual/quad die)
>
> The full version can be found in the following links (registration
> required).
> https://community.cypress.com/t5/Semper-Flash-Access-Program/Datasheet-Semper-Flash-with-Quad-SPI/ta-p/260789?attachment-id=19522
> https://community.cypress.com/t5/Semper-Flash-Access-Program/Datasheet-2Gb-MCP-Semper-Flash-with-Quad-SPI/ta-p/260823?attachment-id=29503
>
> Tested on Xilinx Zynq-7000 FPGA board.

Any details about footprint statistics?

Jagan.

Re: [PATCH v2 00/10] spi: dw: Add support for DUAL/QUAD/OCTAL modes

[Jagan Teki]

On Sat, Apr 3, 2021 at 4:37 AM Sean Anderson  wrote:
>
> On 4/2/21 7:05 PM, Sean Anderson wrote:
> > This series adds support for enhanced SPI modes. It was tested on a K210 
> > (DWC
> > SSI with QSPI flash).
> >
> > If anyone has a designware device with QSPI flash attached (especially a DW 
> > SSI
> > APB device), I'd greatly appreciate them testing out this patch series. 
> > Given
> > that there has been no testing of v2 over the past month, I don't think 
> > lack of
> > testing should hold up this series.
> >
> > Changes in v3:
> > - Dropped merged patches
> > - Rebased on u-boot/master
> >
> > Changes in v2:
> > - Add more information to exec_op debug message
> > - Actually mask interrupts
> > - Merge CAP_{DUAL,QUAD,OCTAL} into CAP_ENHANCED
> > - Fix some inconsistencies in register naming and usage
> > - Moved some hunks between commits so things make more sense
> >
> > Sean Anderson (10):
> >mtd: spi-mem: Export spi_mem_default_supports_op
> >spi: spi-mem: Add debug message for spi-mem ops
> >spi: dw: Log status register on timeout
> >spi: dw: Actually mask interrupts
> >spi: dw: Switch to capabilities
> >spi: dw: Rewrite poll_transfer logic
> >spi: dw: Add ENHANCED cap
> >spi: dw: Define registers for enhanced mode
> >spi: dw: Support enhanced SPI
> >spi: dw: Support clock stretching
> >
> >   drivers/spi/designware_spi.c | 647 ---
> >   drivers/spi/spi-mem.c|   7 +
> >   include/spi-mem.h|   3 +
> >   3 files changed, 451 insertions(+), 206 deletions(-)
> >
>
> Looks like I forgot to bump the version. This should be v3. I can resend if 
> necessary.

Yes, Please.

There are few comments,

1. Patch "spi: spi-mem: Add debug message for spi-mem ops"

As we discussed in the previous version, drop the unnecessary debug
statements after ops execution as this patch trying to add more
verbose to before ops execution.

2. Comments in Patch v2,06/10

Jagan.

Re: [PATCH] cmd: net: add a 'net list' command to list network devs

[Stefan Roese]

On 16.04.21 23:25, Tim Harvey wrote:

In a system with multiple network controllers it can be difficult
to know the names of the various devices available. This is especially
true for USB ether devices as they do not display device names upon
detection.

This is being added as a net sub-system in case other commands may
want to be added or moved here.

Example:
U-Boot > net
net - NET sub-system

Usage:
net list - list available devices

U-Boot > net list
eth0 : ethernet@2188000 00:d0:12:98:f5:47 active
eth1 : e1000#0 00:d0:12:98:f5:48
eth2 : asix_eth 8c:ae:4c:f5:84:9d
eth3 : asix_eth 8c:ae:4c:f9:41:e3

Signed-off-by: Tim Harvey 


I like it:

Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  cmd/net.c | 44 
  1 file changed, 44 insertions(+)

diff --git a/cmd/net.c b/cmd/net.c
index beb2877dfd..e51bc443f7 100644
--- a/cmd/net.c
+++ b/cmd/net.c
@@ -10,6 +10,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -480,3 +481,46 @@ U_BOOT_CMD(
  );
  
  #endif  /* CONFIG_CMD_LINK_LOCAL */

+
+static int do_net_list(struct cmd_tbl *cmdtp, int flag, int argc, char *const 
argv[])
+{
+   const struct udevice *current = eth_get_dev();
+   unsigned char env_enetaddr[ARP_HLEN];
+   const struct udevice *dev;
+   struct uclass *uc;
+
+   uclass_id_foreach_dev(UCLASS_ETH, dev, uc) {
+   eth_env_get_enetaddr_by_index("eth", dev_seq(dev), 
env_enetaddr);
+   printf("eth%d : %s %pM %s\n", dev_seq(dev), dev->name, 
env_enetaddr,
+  current == dev ? "active" : "");
+   }
+   return CMD_RET_SUCCESS;
+}
+
+static struct cmd_tbl cmd_net[] = {
+   U_BOOT_CMD_MKENT(list, 1, 0, do_net_list, "", ""),
+};
+
+static int do_net(struct cmd_tbl *cmdtp, int flag, int argc, char *const 
argv[])
+{
+   struct cmd_tbl *cp;
+
+   cp = find_cmd_tbl(argv[1], cmd_net, ARRAY_SIZE(cmd_net));
+
+   /* Drop the net command */
+   argc--;
+   argv++;
+
+   if (!cp || argc > cp->maxargs)
+   return CMD_RET_USAGE;
+   if (flag == CMD_FLAG_REPEAT && !cmd_is_repeatable(cp))
+   return CMD_RET_SUCCESS;
+
+   return cp->cmd(cmdtp, flag, argc, argv);
+}
+
+U_BOOT_CMD(
+   net, 2, 1, do_net,
+   "NET sub-system",
+   "list - list available devices\n"
+);




Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de