[PATCH v1 3/7] doc: board: apalis-imx8x: add documentation

[sbabic]

> From: Igor Opaniuk 
> This documents the u-boot build and deployment procedure.
> Signed-off-by: Igor Opaniuk 
> Reviewed-by: Oleksandr Suvorov 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

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

[PATCH v1 3/9] power: pmic: add SPL_DM_PMIC_PCA9450 symbol to Kconfig

[sbabic]

> From: Igor Opaniuk 
> Add SPL_DM_PMIC_PCA9450 symbol to Kconfig.
> Signed-off-by: Igor Opaniuk 
> Reviewed-by: Jaehoon Chung 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

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

[PATCH v1 2/7] board: toradex: add apalis-imx8x 2gb wb it v1.1a module support

[sbabic]

> From: Igor Opaniuk 
> This commit adds initial support for the Toradex Apalis iMX8X 2GB WB
> IT V1.1A System on Module support [1].
> Boot log:
> U-Boot 2020.10-02940-g894aebb7e8-dirty (Oct 22 2020 - 09:43:57 +0300)
> CPU:   NXP i.MX8QXP RevB A35 at 1200 MHz at 30C
> DRAM:  2 GiB
> MMC:   FSL_SDHC: 0, FSL_SDHC: 1
> Loading Environment from MMC... OK
> In:serial@5a07
> Out:   serial@5a07
> Err:   serial@5a07
> Model: Toradex Apalis iMX8 QuadXPlus 2GB Wi-Fi / BT IT V1.1A,
> Serial# 06617018
> Net:   eth0: ethernet@5b04 [PRIME]
> Hit any key to stop autoboot:  0
> Functionality wise the following is known to be working:
>   - eMMC and MMC/SD card
>   - Ethernet (*)
>   - GPIOs
>   - I2C
> Unfortunately, there is no USB functionality for the i.MX 8QXP as of
> yet.
> * With the SCU FW from the latest Toradex BSP 5.0.0 (SCU FW 1.5.1)
> ETH PHY encounters bring up problems after reset, this will be fixed
> soon on SCU FW side.
> [1] https://www.toradex.com/computer-on-modules/apalis-arm-family/nxp-imx-8x
> Signed-off-by: Igor Opaniuk 
> Acked-by: Oleksandr Suvorov 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

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

[PATCH v1 9/9] verdin-imx8mm: automatic ram size detection

[sbabic]

> From: Marcel Ziswiler 
> Implement board_phys_sdram_size() to automatically detect Verdin iMX8M
> Mini DualLite 1GB vs. Verdin iMX8M Mini Quad 2GB.
> Note: This only works if we keep using similar RAM chips!
> Signed-off-by: Marcel Ziswiler 
> Acked-by: Oleksandr Suvorov 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

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

[PATCH v1 6/9] verdin-imx8mm: implement hardware version detection

[sbabic]

> From: Max Krummenacher 
> And select the correct devicetree accordingly by setting the variant
> environment variable.
> Signed-off-by: Igor Opaniuk 
> Signed-off-by: Max Krummenacher 
> Acked-by: Marcel Ziswiler 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

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

[PATCH v1 4/4] imx: aristainetos: enable U-Boot Environment variables protection

[sbabic]

> enable Environment protection with:
> CONFIG_ENV_APPEND=y
> CONFIG_ENV_WRITEABLE_LIST=y
> CONFIG_ENV_ACCESS_IGNORE_FORCE
> and add board specific env_get_location()
> function.
> Signed-off-by: Heiko Schocher 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

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

[PATCH] imx8mp_evk: README instruction fixes

[sbabic]

> Use the full name of firmware self extracting file to make it run.
> Also, don't use sudo when not needed.
> Signed-off-by: Baruch Siach 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

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

[PATCH v1] imx: clk: added IPG Clock for I2C on imx8qm

[sbabic]

> This patch fixes this clk issue on I2C on imx8qm
>  => i2c bus
>  Bus 3:  i2c@5a83
>  => i2c dev 3
>  Setting bus to 3
>  Failed to enable ipg clk
>  Failure changing bus number (-524)
> Signed-off-by: Oliver Graute 
> Cc: Stefano Babic 
> Cc: Peng Fan 
> Cc: uboot-imx 
> Reviewed-by: Stefano Babic 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

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

Re: [u-boot, v1 0/1] mtd: spi-nor-ids: add Micron MT25QL01G flash

[Patrice CHOTARD]

Hi Hongwei

On 12/7/20 11:40 PM, Hongwei Zhang wrote:
>> From:  Patrice CHOTARD 
>>
>> Hi Hongwei
>>
>> On 12/4/20 11:06 PM, Hongwei Zhang wrote:
>>> Add STMICRO MT25QL01G flash, used on AST2600 board.
>> MT25QL01G is not a STMicroelectronics flash but a Micron one ;-)
> Thanks for the correction, Patrice.
>
> I came back to spi-nor-ids.c, there are two places in the code checking
> CONFIG_SPI_FLASH_STMICRO define, at line 167 (a lot of Micron flashes
> included in the block), and at line 239, furthermore, there is no
> SPI_FLASH_MICRON config menu in Kconfig file. I got confused, why 
> SPI_FLASH_MICRON is not in Kconfig?
To sum up, at the beginning, it was STMicroelectronics flashes, since 2010, 
MICRON acquired this activities.
If you want the full history, you will find information here: 
https://en.wikipedia.org/wiki/Numonyx
So the CONFIG_SPI_FLASH_STMICRO compilation flag is historical and didn't get 
renamed to CONFIG_SPI_FLASH_MICRON.

Patrice

>
>> Patrice
>>
>>> Signed-off-by: Hongwei Zhang 
>>> ---
>>>  drivers/mtd/spi/spi-nor-ids.c | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/mtd/spi/spi-nor-ids.c
>>> b/drivers/mtd/spi/spi-nor-ids.c index 09e8196048..6d22b80586 100644
>>> --- a/drivers/mtd/spi/spi-nor-ids.c
>>> +++ b/drivers/mtd/spi/spi-nor-ids.c
>>> @@ -185,6 +185,7 @@ const struct flash_info spi_nor_ids[] = {
>>>  { INFO("n25q512ax3",  0x20ba20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR |
>> SPI_NOR_QUAD_READ) },
>>>  { INFO("n25q00",  0x20ba21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR 
>>> | SPI_NOR_QUAD_READ
>> | NO_CHIP_ERASE) },
>>>  { INFO("n25q00a", 0x20bb21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR 
>>> | SPI_NOR_QUAD_READ
>> | NO_CHIP_ERASE) },
>>> +{ INFO("mt25ql01g",   0x21ba20, 0, 64 * 1024, 2048, SECT_4K | USE_FSR |
>> SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
>>>  { INFO("mt25qu02g",   0x20bb22, 0, 64 * 1024, 4096, SECT_4K | USE_FSR |
>> SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },

Re: U-Boot: spl: partition error (stm32mp157)

[Patrice CHOTARD]

Hi Jagan


On 12/7/20 6:46 PM, Jagan Teki wrote:
> Hi Patrick,
>
> Not sure, it's an issue with the current tree, or I may miss something.
>
> Any suggestions?
>
> U-Boot SPL 2021.01-rc2-00143-g345dd00160-dirty (Dec 07 2020 - 01:48:44 +0530)
> Model: Engicam i.Core STM32MP1 EDIMM2.2 Starter Kit
> RAM: DDR3-DDR3L 32bits 528000Khz
> WDT:   Started with servicing (60s timeout)
> ## Unknown partition table type 0
> spl: partition error
> SPL: failed to boot from all boot devices
> ### ERROR ### Please RESET the board ###
>
> Disk /dev/sda: 29.83 GiB, 32010928128 bytes, 62521344 sectors
> Disk model: Storage Device
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: gpt
> Disk identifier: 6524CDDB-929F-4A12-96B2-C04F07403931
>
> Device Start  End  Sectors  Size Type
> /dev/sda1 34  545  512  256K Linux filesystem
> /dev/sda2546 1057  512  256K Linux filesystem
> /dev/sda3   1058 5153 40962M Linux filesystem
> /dev/sda4   5154 62521310 62516157 29.8G Linux filesystem

I am not sure that the 3 first partition are using the correct filesystem type.

Do you follow indications in ./doc/board/st/stm32mp1.rst and more precisely the 
"Prepare an SD card" chapter ?

Thanks


>
> $ sudo dd if=u-boot-spl.stm32 of=/dev/sda1
> $ sudo dd if=u-boot-spl.stm32 of=/dev/sda2
> $ sudo dd if=u-boot.img of=/dev/sda3
>
> .config:
>
> #
> # Automatically generated file; DO NOT EDIT.
> # U-Boot 2021.01-rc2 Configuration
> #
>
> #
> # Compiler: arm-buildroot-linux-gnueabihf-gcc.br_real (Buildroot
> 2020.08-849-gdcd4b75069-dirty) 9.3.0
> #
> CONFIG_CREATE_ARCH_SYMLINK=y
> # CONFIG_ARC is not set
> CONFIG_ARM=y
> # CONFIG_M68K is not set
> # CONFIG_MICROBLAZE is not set
> # CONFIG_MIPS is not set
> # CONFIG_NDS32 is not set
> # CONFIG_NIOS2 is not set
> # CONFIG_PPC is not set
> # CONFIG_RISCV is not set
> # CONFIG_SANDBOX is not set
> # CONFIG_SH is not set
> # CONFIG_X86 is not set
> # CONFIG_XTENSA is not set
> CONFIG_SYS_ARCH="arm"
> CONFIG_SYS_CPU="armv7"
> CONFIG_SYS_SOC="stm32mp"
> CONFIG_SYS_VENDOR="engicam"
> CONFIG_SYS_BOARD="stm32mp1"
> CONFIG_SYS_CONFIG_NAME="stm32mp1"
> # CONFIG_SYS_ICACHE_OFF is not set
> # CONFIG_SPL_SYS_ICACHE_OFF is not set
> # CONFIG_SYS_DCACHE_OFF is not set
> # CONFIG_SPL_SYS_DCACHE_OFF is not set
>
> #
> # ARM architecture
> #
> # CONFIG_GIC_V3_ITS is not set
> CONFIG_HAS_VBAR=y
> CONFIG_HAS_THUMB2=y
> CONFIG_ARM_ASM_UNIFIED=y
> CONFIG_SYS_ARM_CACHE_CP15=y
> CONFIG_SYS_ARM_MMU=y
> # CONFIG_SYS_ARM_MPU is not set
> CONFIG_CPU_V7A=y
> CONFIG_SYS_ARM_ARCH=7
> CONFIG_SYS_CACHE_SHIFT_6=y
> CONFIG_SYS_CACHELINE_SIZE=64
> CONFIG_SYS_ARM_CACHE_WRITEBACK=y
> # CONFIG_SYS_ARM_CACHE_WRITETHROUGH is not set
> # CONFIG_SYS_ARM_CACHE_WRITEALLOC is not set
> # CONFIG_ARCH_CPU_INIT is not set
> CONFIG_SYS_ARCH_TIMER=y
> # CONFIG_ARM_SMCCC is not set
> # CONFIG_SEMIHOSTING is not set
> CONFIG_SYS_THUMB_BUILD=y
> CONFIG_SPL_SYS_THUMB_BUILD=y
> # CONFIG_SYS_L2CACHE_OFF is not set
> # CONFIG_ENABLE_ARM_SOC_BOOT0_HOOK is not set
> CONFIG_USE_ARCH_MEMCPY=y
> CONFIG_SPL_USE_ARCH_MEMCPY=y
> CONFIG_USE_ARCH_MEMSET=y
> CONFIG_SPL_USE_ARCH_MEMSET=y
> # CONFIG_ARCH_AT91 is not set
> # CONFIG_TARGET_EDB93XX is not set
> # CONFIG_TARGET_ASPENITE is not set
> # CONFIG_TARGET_GPLUGD is not set
> # CONFIG_ARCH_DAVINCI is not set
> # CONFIG_ARCH_KIRKWOOD is not set
> # CONFIG_ARCH_MVEBU is not set
> # CONFIG_TARGET_APF27 is not set
> # CONFIG_ARCH_ORION5X is not set
> # CONFIG_TARGET_SPEAR300 is not set
> # CONFIG_TARGET_SPEAR310 is not set
> # CONFIG_TARGET_SPEAR320 is not set
> # CONFIG_TARGET_SPEAR600 is not set
> # CONFIG_TARGET_STV0991 is not set
> # CONFIG_TARGET_X600 is not set
> # CONFIG_TARGET_FLEA3 is not set
> # CONFIG_TARGET_MX35PDK is not set
> # CONFIG_ARCH_BCM283X is not set
> # CONFIG_ARCH_BCM63158 is not set
> # CONFIG_ARCH_BCM68360 is not set
> # CONFIG_ARCH_BCM6858 is not set
> # CONFIG_TARGET_VEXPRESS_CA15_TC2 is not set
> # CONFIG_ARCH_BCMSTB is not set
> # CONFIG_TARGET_VEXPRESS_CA5X2 is not set
> # CONFIG_TARGET_VEXPRESS_CA9X4 is not set
> # CONFIG_TARGET_BCM23550_W1D is not set
> # CONFIG_TARGET_BCM28155_AP is not set
> # CONFIG_TARGET_BCMCYGNUS is not set
> # CONFIG_TARGET_BCMNSP is not set
> # CONFIG_TARGET_BCMNS2 is not set
> # CONFIG_TARGET_BCMNS3 is not set
> # CONFIG_ARCH_EXYNOS is not set
> # CONFIG_ARCH_S5PC1XX is not set
> # CONFIG_ARCH_HIGHBANK is not set
> # CONFIG_ARCH_INTEGRATOR is not set
> # CONFIG_ARCH_IPQ40XX is not set
> # CONFIG_ARCH_KEYSTONE is not set
> # CONFIG_ARCH_K3 is not set
> # CONFIG_ARCH_OMAP2PLUS is not set
> # CONFIG_ARCH_MESON is not set
> # CONFIG_ARCH_MEDIATEK is not set
> # CONFIG_ARCH_LPC32XX is not set
> # CONFIG_ARCH_IMX8 is not set
> # CONFIG_ARCH_IMX8M is not set
> # CONFIG_ARCH_IMXRT is not set
> # CONFIG_ARCH_MX23 is not set
> # CONFIG_ARCH_MX25 is not set
> # CONFIG_ARCH_MX28 is not set
> # CONFIG_ARCH_MX31 is no

RE: [PATCH v2] arm: fsl: common: Improve NXP VID driver PMBus support

[Wasim Khan]

-Original Message-
From: U-Boot  On Behalf Of Priyanka Jain
Sent: Monday, December 7, 2020 5:56 PM
To: Stephen Carlson ; U-Boot Mailing List 

Subject: RE: [PATCH v2] arm: fsl: common: Improve NXP VID driver PMBus support

>-Original Message-
>From: Stephen Carlson 
>Sent: Tuesday, November 3, 2020 3:06 AM
>To: U-Boot Mailing List 
>Cc: Priyanka Jain 
>Subject: [PATCH v2] arm: fsl: common: Improve NXP VID driver PMBus 
>support
>
>This patch adds support for more PMBus compatible devices to the NXP 
>drivers for its QorIQ family devices. At runtime, the voltage regulator 
>is queried over I2C, and the required voltage multiplier determined. 
>This change supports the DIRECT and LINEAR PMBus voltage reporting modes.
>
>Previously, the driver only supported a few specific devices such as 
>the
>IR36021 and LTC3882, so this change allows the QorIQ series to be used 
>with a much larger variety of core voltage regulator devices.
>
>checkpatch warning "Use if (IS_DEFINED (...))" was ignored to maintain 
>consistency with the existing code.

Hi Shephen,
Can you please help to fix the checkpatch warnings . Even a additional patch on 
top should work.

>
>Signed-off-by: Stephen Carlson 
>Cc: Priyanka Jain 
>---

Kindly help to rebase the patch to master branch of u-boot tree 
(git://git.denx.de/u-boot.git).

Regards
Priyanka

Re: [PATCH 01/14] qemu: arm: Use the generated DTB only when CONGIG_OF_BOARD is defined

[Sughosh Ganu]

On Mon, 7 Dec 2020 at 23:28, Heinrich Schuchardt  wrote:

> On 07.12.20 13:50, Heinrich Schuchardt wrote:
> > On 07.12.20 06:15, Sughosh Ganu wrote:
> >> hello Heinrich,
> >>
> >> On Sat, 5 Dec 2020 at 15:01, Heinrich Schuchardt  >> > wrote:
> >>
> >> On 11/26/20 7:40 PM, Sughosh Ganu wrote:
> >> > The Qemu platform emulator generates a device tree blob and
> places it
> >> > at the start of the dram, which is then used by u-boot. Use this
> dtb
> >> > only if CONFIG_OF_BOARD is defined. This allows using a different
> >> > device tree, using the CONFIG_OF_SEPARATE option. This dtb is
> attached
> >> > to the u-boot binary as a u-boot-fdt.bin file
> >>
> >> Dear Sughosh,
> >>
> >> thank your for this series which will allow us to better
> demonstrate and
> >> test capsule updates.
> >>
> >> I am not sure if the approach that you take at device-trees here is
> the
> >> right one.
> >>
> >> On QEMU the device-tree is generated on the fly by the QEMU binary
> >> depending on which devices the user has specified.
> >>
> >> Your idea is to replace this device-tree completely to be able to
> add
> >> extra elements (the EFI signature list, see patch 2/14). Thus a
> >> device-tree might be loaded that does not match the user selected
> >> devices.
> >>
> >> An alternative approach would be to apply all additions to the
> >> device-tree as an FDT overlay (or fixup). This would allow the
> dynamic
> >> parts of the QEMU device-tree still to be passed through.
> >>
> >>
> >> I will take a look at storing the public key as part of the fdt overlay,
> >> with a runtime fixup. Although, I think the issue that you are pointing
> >> to would be specific to Qemu and not other platforms. But I do see the
> >> merit in having the public-key certificate stored as part of an overlay.
> >> If I hit any issues while implementing this, I will get back to you.
> Thanks.
> >>
> >> -sughosh
> >
> > OpenSBI can supply a device-tree to U-Boot. So this would be an
> > equivalent case.
> >
> > Best regards
> >
> > Heinrich
>
> : "I am unable to think of a simple and elegant way to generate
> the overlay dtb, since this would require creation of a corresponding
> dts file, compiling it into a dtb and then using this on the platform."
>
> Jean-Jacques' patch series introduced some of the necessary code:
>
> [PATCH PATCH v6 00/13] Add support for applications of overlays in SPL
> https://lists.denx.de/pipermail/u-boot/2019-October/387653.html
>
> https://patchwork.ozlabs.org/project/uboot/list/?series=137810&state=%2A&archive=both
>
> CONFIG_OF_OVERLAY_LIST is used to specify the overlays to be compiled.
> You will have to remove the CONFIG_SPL_LOAD_FIT_APPLY_OVERLAY and
> CONFIG_SPL_LOAD_FIT dependency.


What i meant was that the process to generate the fdt overlay on the host,
embed it with the public-key certificate is more cumbersome than the
current solution. So, for comparing the embedding the pub-key cert in the
fdt overlay, as against the platform dtb

Embedding the certificate in the overlay
1) Generate a skeleton overlay dts file
2) Convert it to a dtb
3) Run it through the mkeficapsule utility to embed the pub-key certificate
in the overlay(dtb)
4) Store the overlay dtb on some nv storage on the platform(ESP partition?)
5) Load the overlay and apply it to the platform's dtb
6) Retrieve the certificate from the dtb at the time of capsule
authentication

Embedding the certificate in the platform's dtb
1) Run the platform's dtb through the mkeficapsule utility to embed
the pub-key certificate
2) Boot the platform with the platform's dtb
3) Retrieve the certificate from the dtb at the time of capsule
authentication

You had mentioned OpenSBI passing the dtb to u-boot. Does the OpenSBI
generate the device tree for the platform on the fly even for non-qemu
platforms. If it does not, the dtb that OpenSBI uses can be run through the
mkeficapsule utility to embed the certificate.

-sughosh

Re: [PATCH 06/14] qemu: arm64: Set dfu_alt_info variable for the platform

[Sughosh Ganu]

On Tue, 8 Dec 2020 at 00:17, Tom Rini  wrote:

> On Sat, Dec 05, 2020 at 11:31:49AM +0100, Heinrich Schuchardt wrote:
> > On 11/26/20 7:41 PM, Sughosh Ganu wrote:
> > > The dfu framework uses the dfu_alt_info environment variable to get
> > > information that is needed for performing the firmware update. Set the
> > > dfu_alt_info for the platform to reflect the two mtd partitions
> > > created for the u-boot env and the firmware image.
> > >
> > > Signed-off-by: Sughosh Ganu 
> >
> > I can't see anything QEMU specific in this patch. Why is the code under
> > board/emulation/?
> >
> > Best regards
> >
> > Heinrich
> >
> > > ---
> > >   board/emulation/qemu-arm/qemu-arm.c | 55
> +
> > >   include/configs/qemu-arm.h  |  1 +
> > >   2 files changed, 56 insertions(+)
> > >
> > > diff --git a/board/emulation/qemu-arm/qemu-arm.c
> b/board/emulation/qemu-arm/qemu-arm.c
> > > index d5ed3eebaf..8cad54c76f 100644
> > > --- a/board/emulation/qemu-arm/qemu-arm.c
> > > +++ b/board/emulation/qemu-arm/qemu-arm.c
> > > @@ -200,8 +200,63 @@ void flash_write32(u32 value, void *addr)
> > >
> > >   #if defined(CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT)
> > >
> > > +#include 
> > >   #include 
> > >
> > > +#define MTDPARTS_LEN   256
> > > +#define MTDIDS_LEN 128
> > > +
> > > +#define DFU_ALT_BUF_LENSZ_1K
> > > +
> > > +static void board_get_alt_info(struct mtd_info *mtd, char *buf)
> > > +{
> > > +   struct mtd_info *part;
> > > +   bool first = true;
> > > +   const char *name;
> > > +   int len, partnum = 0;
> > > +
> > > +   name = mtd->name;
> > > +   len = strlen(buf);
> > > +
> > > +   if (buf[0] != '\0')
> > > +   len += snprintf(buf + len, DFU_ALT_BUF_LEN - len, "&");
> > > +   len += snprintf(buf + len, DFU_ALT_BUF_LEN - len,
> > > +   "mtd %s=", name);
> > > +
> > > +   list_for_each_entry(part, &mtd->partitions, node) {
> > > +   partnum++;
> > > +   if (!first)
> > > +   len += snprintf(buf + len, DFU_ALT_BUF_LEN - len,
> ";");
> > > +   first = false;
> > > +
> > > +   len += snprintf(buf + len, DFU_ALT_BUF_LEN - len,
> > > +   "%s part %d",
> > > +   part->name, partnum);
> > > +   }
> > > +}
> > > +
> > > +void set_dfu_alt_info(char *interface, char *devstr)
> > > +{
> > > +   struct mtd_info *mtd;
> > > +
> > > +   ALLOC_CACHE_ALIGN_BUFFER(char, buf, DFU_ALT_BUF_LEN);
> > > +
> > > +   if (env_get("dfu_alt_info"))
> > > +   return;
> > > +
> > > +   memset(buf, 0, sizeof(buf));
> > > +
> > > +   /* probe all MTD devices */
> > > +   mtd_probe_devices();
> > > +
> > > +   mtd = get_mtd_device_nm("nor0");
> > > +   if (!IS_ERR_OR_NULL(mtd))
> > > +   board_get_alt_info(mtd, buf);
> > > +
> > > +   env_set("dfu_alt_info", buf);
> > > +   printf("dfu_alt_info set\n");
> > > +}
> > > +
> > >   static void board_get_mtdparts(const char *dev, const char
> *partition,
> > >char *mtdids, char *mtdparts)
> > >   {
> > > diff --git a/include/configs/qemu-arm.h b/include/configs/qemu-arm.h
> > > index 69ff329434..726f985d35 100644
> > > --- a/include/configs/qemu-arm.h
> > > +++ b/include/configs/qemu-arm.h
> > > @@ -33,6 +33,7 @@
> > >   #include 
> > >
> > >   #if defined(CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT)
> > > +#define CONFIG_SET_DFU_ALT_INFO
> > >   #define CONFIG_SYS_MTDPARTS_RUNTIME
>
> First, CONFIG_SET_DFU_ALT_INFO is in Kconfig and needs to be enabled
> that way.


Will change in the next version.


> Second, typically we just set the information in the
> environment part of the header.  This is especially true if in both this
> case and the previous patch to add mtdparts, we don't really have this
> being dynamic?  Or are we really expecting / supporting arbitrary sized
> flash as this is qemu?  Thanks.
>

I am not sure I understand this. One thing that can be done is to move the
setting of the mtd partitions to the Kconfig file, on similar lines to what
is being done for the st platforms, e.g MTDPARTS_NOR0_TEE. I can move the
mtd partition definitions to the Kconfig file if that is what you are
asking for.

-sughosh

Re: [PATCH 05/14] qemu: arm64: Add support for dynamic mtdparts for the platform

[Sughosh Ganu]

On Tue, 8 Dec 2020 at 00:14, Tom Rini  wrote:

> On Sat, Dec 05, 2020 at 11:29:58AM +0100, Heinrich Schuchardt wrote:
> > On 11/26/20 7:41 PM, Sughosh Ganu wrote:
> > > Add support for setting the default values for mtd partitions on the
> > > platform for the nor flash. This would be used for updating the
> > > firmware image using uefi capsule update with the dfu mtd backend
> > > driver.
> > >
> > > Signed-off-by: Sughosh Ganu 
> > > ---
> > >   board/emulation/qemu-arm/qemu-arm.c | 70
> +
> > >   include/configs/qemu-arm.h  |  7 +++
> > >   2 files changed, 77 insertions(+)
> > >
> > > diff --git a/board/emulation/qemu-arm/qemu-arm.c
> b/board/emulation/qemu-arm/qemu-arm.c
> > > index b3d5b3d5c2..d5ed3eebaf 100644
> > > --- a/board/emulation/qemu-arm/qemu-arm.c
> > > +++ b/board/emulation/qemu-arm/qemu-arm.c
> [snip]
> > > +#if defined(CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT)
> > > +#define CONFIG_SYS_MTDPARTS_RUNTIME
> > > +#endif
>
> This symbol is in Kconfig and needs to be enabled that way.
>

Will make the necessary change in the next version. Thanks.

-sughosh

[PATCH v2 4/4] mkimge: Reject signing-related flags without FIT_SIGNATURE

[Joel Stanley]

When CONFIG_FIT_SIGNATURE=n the signing options are not available. If a
user is careful they will notice this when looking at the help output.

If they are not careful they will waste several hours wondering why
their FIT doesn't contain a /signature node, as mkimage will silently
ingore the signing related options.

Make it obvious that the commands don't work by removing them from the
getopt opt_string.

 $ mkimage -f machine.its -k keys -K u-boot-pubkey.dtb -r image.fit
 mkimage: invalid option -- 'k'
 Error: Invalid option

Signed-off-by: Joel Stanley 
--
v2: Leave padding related options in the CONFIG_FIT_SIGNATURE=y optargs
---
 tools/mkimage.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/tools/mkimage.c b/tools/mkimage.c
index 68d5206cb4fd..f7d3ac40e681 100644
--- a/tools/mkimage.c
+++ b/tools/mkimage.c
@@ -142,7 +142,11 @@ static int add_content(int type, const char *fname)
return 0;
 }
 
+#ifdef CONFIG_FIT_SIGNATURE
 #define OPT_STRING "a:A:b:B:c:C:d:D:e:Ef:Fk:i:K:ln:N:p:O:rR:qstT:vVx"
+#else
+#define OPT_STRING "a:A:b:B:C:d:D:e:Ef:i:ln:O:R:qstT:vVx"
+#endif
 static void process_args(int argc, char **argv)
 {
char *ptr;
@@ -150,8 +154,7 @@ static void process_args(int argc, char **argv)
char *datafile = NULL;
int opt;
 
-   while ((opt = getopt(argc, argv,
-  "a:A:b:B:c:C:d:D:e:Ef:Fk:i:K:ln:N:p:O:rR:qstT:vVx")) != -1) {
+   while ((opt = getopt(argc, argv, OPT_STRING)) != -1) {
switch (opt) {
case 'a':
params.addr = strtoull(optarg, &ptr, 16);
-- 
2.29.2

[PATCH v2 3/4] mkimage: Move padding commands outside of FIT_SIGNATURE

[Joel Stanley]

These commands were disabled when CONFIG_FIT_SIGNATURE is disabled, but
they do not depend on crypto support so they can be unconditionally
enabled.

Signed-off-by: Joel Stanley 
--
v2: New patch
---
 tools/mkimage.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/tools/mkimage.c b/tools/mkimage.c
index e78608293e72..68d5206cb4fd 100644
--- a/tools/mkimage.c
+++ b/tools/mkimage.c
@@ -94,18 +94,18 @@ static void usage(const char *msg)
"  -x ==> set XIP (execute in place)\n",
params.cmdname);
fprintf(stderr,
-   "   %s [-D dtc_options] [-f fit-image.its|-f auto|-F] [-b 
 [-b ]] [-i ] fit-image\n"
+   "   %s [-D dtc_options] [-f fit-image.its|-f auto|-F] [-b 
 [-b ]] [-E] [-B size] [-i ] fit-image\n"
"file is used with -f auto, it may occur 
multiple times.\n",
params.cmdname);
fprintf(stderr,
"  -D => set all options for device tree compiler\n"
"  -f => input filename for FIT source\n"
-   "  -i => input filename for ramdisk file\n");
+   "  -i => input filename for ramdisk file\n"
+   "  -E => place data outside of the FIT structure\n"
+   "  -B => align size in hex for FIT structure and 
header\n");
 #ifdef CONFIG_FIT_SIGNATURE
fprintf(stderr,
-   "Signing / verified boot options: [-E] [-B size] [-k keydir] 
[-K dtb] [ -c ] [-p addr] [-r] [-N engine]\n"
-   "  -E => place data outside of the FIT structure\n"
-   "  -B => align size in hex for FIT structure and 
header\n"
+   "Signing / verified boot options: [-k keydir] [-K dtb] [ -c 
] [-p addr] [-r] [-N engine]\n"
"  -k => set directory containing private keys\n"
"  -K => write public keys to this .dtb file\n"
"  -c => add comment in signature node\n"
@@ -142,6 +142,7 @@ static int add_content(int type, const char *fname)
return 0;
 }
 
+#define OPT_STRING "a:A:b:B:c:C:d:D:e:Ef:Fk:i:K:ln:N:p:O:rR:qstT:vVx"
 static void process_args(int argc, char **argv)
 {
char *ptr;
-- 
2.29.2

[PATCH v2 2/4] image-fit: Fix FIT_CIPHER linking

[Joel Stanley]

When CONFIG_FIT_CIPHER=y and CONFIG_FIT_SIGNATURE=n is there is no
implementation of image_get_host_blob for mkimage/dumpimage:

 /usr/bin/ld: tools/common/image-cipher.o: in function `fit_image_decrypt_data':
 image-cipher.c:(.text+0x9a): undefined reference to `image_get_host_blob'

Move the implementation to a common file so it can be shaed between
image-cipher.c and image-fit-sig.c.

Signed-off-by: Joel Stanley 
---
v2: Fix compilation when signature and ciphering are both enabled
---
 common/image-fit-sig.c | 14 --
 common/image-fit.c | 15 +++
 2 files changed, 15 insertions(+), 14 deletions(-)

diff --git a/common/image-fit-sig.c b/common/image-fit-sig.c
index 5401d9411b98..d39741e9058f 100644
--- a/common/image-fit-sig.c
+++ b/common/image-fit-sig.c
@@ -19,20 +19,6 @@ DECLARE_GLOBAL_DATA_PTR;
 
 #define IMAGE_MAX_HASHED_NODES 100
 
-#ifdef USE_HOSTCC
-void *host_blob;
-
-void image_set_host_blob(void *blob)
-{
-   host_blob = blob;
-}
-
-void *image_get_host_blob(void)
-{
-   return host_blob;
-}
-#endif
-
 /**
  * fit_region_make_list() - Make a list of image regions
  *
diff --git a/common/image-fit.c b/common/image-fit.c
index c82d4d8015f0..664a0d6c 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -112,6 +112,21 @@ int fit_parse_subimage(const char *spec, ulong addr_curr,
 }
 #endif /* !USE_HOSTCC */
 
+#ifdef USE_HOSTCC
+/* Host tools use these implementations for Cipher and Signature support */
+static void *host_blob;
+
+void image_set_host_blob(void *blob)
+{
+   host_blob = blob;
+}
+
+void *image_get_host_blob(void)
+{
+   return host_blob;
+}
+#endif /* USE_HOSTCC */
+
 static void fit_get_debug(const void *fit, int noffset,
char *prop_name, int err)
 {
-- 
2.29.2

[PATCH v2 1/4] tools/Makefile: FIT_CIPHER requires libssl

[Joel Stanley]

If CONFIG_FIT_CIPHER is enabled without CONFIG_FIT_SIGNATURE then
mkimage/dumpimage will fail to link:

 /usr/bin/ld: tools/common/image-cipher.o: in function `fit_image_decrypt_data':
 image-cipher.c:(.text+0x9a): undefined reference to `image_get_host_blob'
 /usr/bin/ld: tools/common/image-cipher.o:(.data.rel+0x10): undefined reference 
to `EVP_aes_128_cbc'
 /usr/bin/ld: tools/common/image-cipher.o:(.data.rel+0x40): undefined reference 
to `EVP_aes_192_cbc'
 /usr/bin/ld: tools/common/image-cipher.o:(.data.rel+0x70): undefined reference 
to `EVP_aes_256_cbc'
 /usr/bin/ld: tools/lib/aes/aes-encrypt.o: in function `image_aes_encrypt':
 aes-encrypt.c:(.text+0x22): undefined reference to `EVP_CIPHER_CTX_new'
 /usr/bin/ld: aes-encrypt.c:(.text+0x6f): undefined reference to 
`EVP_EncryptInit_ex'
 /usr/bin/ld: aes-encrypt.c:(.text+0x8d): undefined reference to 
`EVP_EncryptUpdate'
 /usr/bin/ld: aes-encrypt.c:(.text+0xac): undefined reference to 
`EVP_CIPHER_CTX_free'
 /usr/bin/ld: aes-encrypt.c:(.text+0xf2): undefined reference to 
`EVP_EncryptFinal_ex'
 collect2: error: ld returned 1 exit status

Signed-off-by: Joel Stanley 
---
 tools/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/Makefile b/tools/Makefile
index 253a6b97065b..99a931312cd8 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -154,7 +154,7 @@ HOSTCFLAGS_kwbimage.o += -DCONFIG_KWB_SECURE
 endif
 
 # MXSImage needs LibSSL
-ifneq 
($(CONFIG_MX23)$(CONFIG_MX28)$(CONFIG_ARMADA_38X)$(CONFIG_ARMADA_39X)$(CONFIG_FIT_SIGNATURE),)
+ifneq 
($(CONFIG_MX23)$(CONFIG_MX28)$(CONFIG_ARMADA_38X)$(CONFIG_ARMADA_39X)$(CONFIG_FIT_SIGNATURE)$(CONFIG_FIT_CIPHER),)
 HOSTCFLAGS_kwbimage.o += \
$(shell pkg-config --cflags libssl libcrypto 2> /dev/null || echo "")
 HOSTLDLIBS_mkimage += \
-- 
2.29.2

[PATCH v2 0/4] mkimage usability fixes

[Joel Stanley]

v2: Move -B and -E out from FIT_SIGNATURE check, and other fixes from
Philippe's review.

Original cover letter:

I was learning about signed FIT today and was unable to convince mkimage
to produce a signature node in my control device tree. It turns out that
Debian's packaged mkimage doesn't enable FIT_SIGNATURE, so the options I
was passing were silently ignored.

There's an existing Debian bug for that[1] but in the mean time this
changes mkimage's behaviour to fail loudly when FIT_SIGNATURE is
disabled.

The first two patches fix some issues I found when testing the third
patch under sandbox_defconfig with FIT_SIGNATURE=n.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972513

Joel Stanley (4):
  tools/Makefile: FIT_CIPHER requires libssl
  image-fit: Fix FIT_CIPHER linking
  mkimage: Move padding commands outside of FIT_SIGNATURE
  mkimge: Reject signing-related flags without FIT_SIGNATURE

 common/image-fit-sig.c | 14 --
 common/image-fit.c | 15 +++
 tools/Makefile |  2 +-
 tools/mkimage.c| 18 +++---
 4 files changed, 27 insertions(+), 22 deletions(-)

-- 
2.29.2

Re: [PATCH 3/3] mkimge: Reject signing-related flags without FIT_SIGNATURE

[Joel Stanley]

On Mon, 7 Dec 2020 at 17:57, Philippe REYNES
 wrote:
>
> Hi Joel,
>
> Sorry for this very late answer.
>
> You're right, this is a bad behaviour, but I think that this
> solution remove too many options. For example, If signature
> is disabled, this solution also disable the padding in the fit image.

Ok. I can amend my patch but it wasn't obvious which commands should
be moved from outside the FIT_SIGNATURE guard.

Just -E and -B?

>
> Looking a bit deeper, this patch removes all options that are
> not displayed by the help of mkimage when signature is disabled.
> But I think that this help is not correct. If the signature is disabled,
> the padding is still available.
> So I think that we have an issue in the help too.
>
> Regards,
> Philippe
>
> Le 11/11/2020 à 12:18, Joel Stanley a écrit :
> > When CONFIG_FIT_SIGNATURE=n the signing options are not available. If a
> > user is careful they will notice this when looking at the help output.
> >
> > If they are not careful they will waste several hours wondering what
> > they got wrong, as mkimage will silently ignore the signing related
> > options.
> >
> > Make it obvious that the commands don't work by removing them from the
> > getopt opt_string.
> >
> > The tool will now behave as follows:
> >
> >   $ mkimage -f machine.its -k keys -K u-boot-pubkey.dtb -r image.fit
> >   mkimage: invalid option -- 'k'
> >   Error: Invalid option
> >
> > Signed-off-by: Joel Stanley 
> > ---
> >   tools/mkimage.c | 9 +++--
> >   1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/tools/mkimage.c b/tools/mkimage.c
> > index e78608293e72..10a1b3dc8c18 100644
> > --- a/tools/mkimage.c
> > +++ b/tools/mkimage.c
> > @@ -142,6 +142,12 @@ static int add_content(int type, const char *fname)
> >   return 0;
> >   }
> >
> > +#ifdef CONFIG_FIT_SIGNATURE
> > +#define OPT_STRING "a:A:b:B:c:C:d:D:e:Ef:Fk:i:K:ln:N:p:O:rR:qstT:vVx"
> > +#else
> > +#define OPT_STRING "a:A:b:C:d:D:e:f:i:ln:O:R:qstT:vVx"
> > +#endif
> > +
> >   static void process_args(int argc, char **argv)
> >   {
> >   char *ptr;
> > @@ -149,8 +155,7 @@ static void process_args(int argc, char **argv)
> >   char *datafile = NULL;
> >   int opt;
> >
> > - while ((opt = getopt(argc, argv,
> > -"a:A:b:B:c:C:d:D:e:Ef:Fk:i:K:ln:N:p:O:rR:qstT:vVx")) != 
> > -1) {
> > + while ((opt = getopt(argc, argv, OPT_STRING)) != -1) {
> >   switch (opt) {
> >   case 'a':
> >   params.addr = strtoull(optarg, &ptr, 16);

Re: [PATCH 2/3] image-cipher: Fix FIT_CIPHER linking

[Joel Stanley]

On Mon, 7 Dec 2020 at 17:07, Philippe REYNES
 wrote:
>
> Hi Joel,
>
> sorry for this very late answer ..
>
>
> This patch fix this issue when only the ciphering is enabled.
> But it breaks the compilation when signature and ciphering are
> enabled, because both functions image_set_host_blob and
> image_get_host_blob are defined twice.
> So it is a NAK for me.
>
> A simple way to fix it to move this block of code from image-fit-sig.c
> to iamge-fit.c

Agreed, that is a better idea.

I'll send a v2.

>
> Regards,
> Philippe
>
>
> Le 11/11/2020 à 12:18, Joel Stanley a écrit :
> > When CONFIG_FIT_CIPHER=y and CONFIG_FIT_SIGNATURE=n is there is no
> > implementation of image_get_host_blob for mkimage or dumpimage:
> >
> >   /usr/bin/ld: tools/common/image-cipher.o: in function 
> > `fit_image_decrypt_data':
> >   image-cipher.c:(.text+0x9a): undefined reference to `image_get_host_blob'
> >
> > The implementation is the same as common/image-fit-sig.c.
> >
> > Signed-off-by: Joel Stanley 
> > ---
> >   common/image-cipher.c | 14 ++
> >   1 file changed, 14 insertions(+)
> >
> > diff --git a/common/image-cipher.c b/common/image-cipher.c
> > index 4ca9eec4ef15..fcbbceb847a5 100644
> > --- a/common/image-cipher.c
> > +++ b/common/image-cipher.c
> > @@ -15,6 +15,20 @@ DECLARE_GLOBAL_DATA_PTR;
> >   #include 
> >   #include 
> >
> > +#ifdef USE_HOSTCC
> > +void *host_blob;
> > +
> > +void image_set_host_blob(void *blob)
> > +{
> > + host_blob = blob;
> > +}
> > +
> > +void *image_get_host_blob(void)
> > +{
> > + return host_blob;
> > +}
> > +#endif
> > +
> >   struct cipher_algo cipher_algos[] = {
> >   {
> >   .name = "aes128",

Re: [u-boot, v2019.04-aspeed, v1 0/1] Common:fdt: Check for error return

[Joel Stanley]

On Thu, 3 Dec 2020 at 19:11, Hongwei Zhang  wrote:
>
> Thanks Joel,
>
> > From: Joel Stanley 
> > Sent: Wednesday, December 2, 2020 9:17 PM
> > To:   Hongwei Zhang
> >
> > Hello Hongwei,
> >
> > On Wed, 2 Dec 2020 at 19:48, Hongwei Zhang  wrote:
> > >
> > > Hello Reviewer,
> > >
> > > Check for negative return value of fdt_noffset from calling
> > > boot_get_fdt_fit(). Otherwise, when fdt subimage is corrupted, the
> > > u-boot report bad hash value but continue loading kernel image and
> > > get hanged later.
> >
> > I can see from your subject line that you intended this to go to
> > Aspeed's fork of u-boot. That's fine, but you shouldn't cc the
> > upstream maintainers as they don't care for these changes.
> >
> > If the bug exists in mainline u-boot, you should certainly send the
> > fix there and ask for it to be backported to the aspeed fork.
>
> I think this issue existing in mainline u-boot, however, I have difficulty
> to include 'master' branch of u-boot in openbmc project, to acturaly test
> it. There are compiling errors.
>
> Also, I'm not sure for mainline u-boot, which branch should I use to test
> and verification? is it 'master', or 'next' branch?

I suspect it doesn't matter much. As this is a small fix, I would
chose to send it to master. (I see that's what you did)

>
> --Hongwei
> >
> > Cheers,
> >
> > Joel
> >
> > >
> > > Hongwei Zhang (1):
> > >   Common:fdt: Check for error return value
> > >
> > >  common/image-fdt.c | 3 +++
> > >  1 file changed, 3 insertions(+)
> > >
> > > --
> > > 2.17.1
> > >

[PATCH] drivers/net: Add support for 10G Base-R IP core version to xilinx_axi_enet driver

[Alessandro Temil]

diff --git a/drivers/net/xilinx_axi_emac.c b/drivers/net/xilinx_axi_emac.c
index 8af3711204..3b739bd407 100644
--- a/drivers/net/xilinx_axi_emac.c
+++ b/drivers/net/xilinx_axi_emac.c
@@ -1,5 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
+ * Copyright (C) 2020 Waymo LLC
  * Copyright (C) 2011 Michal Simek 
  * Copyright (C) 2011 PetaLogix
  * Copyright (C) 2010 Xilinx, Inc. All rights reserved.
@@ -72,10 +73,25 @@ DECLARE_GLOBAL_DATA_PTR;
 #define XAXIDMA_BD_CTRL_TXSOF_MASK 0x0800 /* First tx packet */
 #define XAXIDMA_BD_CTRL_TXEOF_MASK 0x0400 /* Last tx packet */

+/* Bitmasks for the XXV Ethernet MAC */
+#define XXV_TC_TX_MASK 0x0001
+#define XXV_TC_FCS_MASK 0x0002
+#define XXV_RCW1_RX_MASK 0x0001
+#define XXV_RCW1_FCS_MASK 0x0002
+
 #define DMAALIGN 128

+#define XXV_MIN_PKT_SIZE 60
+
 static u8 rxframe[PKTSIZE_ALIGN] __attribute((aligned(DMAALIGN)));

+static u8 txminframe[XXV_MIN_PKT_SIZE] __attribute((aligned(DMAALIGN)));
+
+enum emac_variant {
+ EMAC_1G = 0,
+ EMAC_10G_25G,
+};
+
 /* Reflect dma offsets */
 struct axidma_reg {
  u32 control; /* DMACR */
@@ -97,6 +113,7 @@ struct axidma_priv {
  struct mii_dev *bus;
  u8 eth_hasnobuf;
  int phy_of_handle;
+ enum emac_variant mactype;
 };

 /* BD descriptors */
@@ -143,6 +160,14 @@ struct axi_regs {
  u32 uaw1; /* 0x704: Unicast address word 1 */
 };

+struct xxv_axi_regs {
+ u32 gt_reset; /* 0x0 */
+ u32 reserved[2];
+ u32 tc;   /* 0xC: Tx Configuration */
+ u32 reserved2;
+ u32 rcw1; /* 0x14: Rx Configuration Word 1 */
+};
+
 /* Use MII register 1 (MII status register) to detect PHY */
 #define PHY_DETECT_REG  1

@@ -191,6 +216,8 @@ static inline void axienet_dma_write(struct
axidma_bd *bd, u32 *desc)
 static u32 phyread(struct axidma_priv *priv, u32 phyaddress, u32 registernum,
 u16 *val)
 {
+ if (priv->mactype == EMAC_10G_25G) return 0;
+
  struct axi_regs *regs = priv->iobase;
  u32 mdioctrlreg = 0;

@@ -217,6 +244,8 @@ static u32 phyread(struct axidma_priv *priv, u32
phyaddress, u32 registernum,
 static u32 phywrite(struct axidma_priv *priv, u32 phyaddress, u32 registernum,
  u32 data)
 {
+ if (priv->mactype == EMAC_10G_25G) return 0;
+
  struct axi_regs *regs = priv->iobase;
  u32 mdioctrlreg = 0;

@@ -374,6 +403,29 @@ static void axiemac_stop(struct udevice *dev)
  debug("axiemac: Halted\n");
 }

+static int xxv_axi_ethernet_init(struct axidma_priv *priv)
+{
+ struct xxv_axi_regs *regs = priv->iobase;
+
+ int val = readl(®s->rcw1) & ~XXV_RCW1_FCS_MASK;
+ val |= XXV_RCW1_FCS_MASK;
+ writel(val, ®s->rcw1);
+
+ val = readl(®s->tc) & ~XXV_TC_FCS_MASK;
+ val |= XXV_TC_FCS_MASK;
+ writel(val, ®s->tc);
+
+ val = readl(®s->tc) & ~XXV_TC_TX_MASK;
+ val |= XXV_TC_TX_MASK;
+ writel(val, ®s->tc);
+
+ val = readl(®s->rcw1) & ~XXV_RCW1_RX_MASK;
+ val |= XXV_RCW1_RX_MASK;
+ writel(val, ®s->rcw1);
+
+ return 0;
+}
+
 static int axi_ethernet_init(struct axidma_priv *priv)
 {
  struct axi_regs *regs = priv->iobase;
@@ -427,6 +479,9 @@ static int axiemac_write_hwaddr(struct udevice *dev)
 {
  struct eth_pdata *pdata = dev_get_platdata(dev);
  struct axidma_priv *priv = dev_get_priv(dev);
+
+ if (priv->mactype == EMAC_10G_25G) return 0;
+
  struct axi_regs *regs = priv->iobase;

  /* Set the MAC address */
@@ -466,7 +521,6 @@ static void axi_dma_init(struct axidma_priv *priv)
 static int axiemac_start(struct udevice *dev)
 {
  struct axidma_priv *priv = dev_get_priv(dev);
- struct axi_regs *regs = priv->iobase;
  u32 temp;

  debug("axiemac: Init started\n");
@@ -479,8 +533,13 @@ static int axiemac_start(struct udevice *dev)
  axi_dma_init(priv);

  /* Initialize AxiEthernet hardware. */
- if (axi_ethernet_init(priv))
- return -1;
+ if (priv->mactype == EMAC_1G) {
+ if (axi_ethernet_init(priv))
+ return -1;
+ } else {
+ if (xxv_axi_ethernet_init(priv))
+ return -1;
+ }

  /* Disable all RX interrupts before RxBD space setup */
  temp = readl(&priv->dmarx->control);
@@ -514,15 +573,29 @@ static int axiemac_start(struct udevice *dev)
  /* Rx BD is ready - start */
  axienet_dma_write(&rx_bd, &priv->dmarx->tail);

- /* Enable TX */
- writel(XAE_TC_TX_MASK, ®s->tc);
- /* Enable RX */
- writel(XAE_RCW1_RX_MASK, ®s->rcw1);
-
- /* PHY setup */
- if (!setup_phy(dev)) {
- axiemac_stop(dev);
- return -1;
+ if (priv->mactype == EMAC_1G) {
+ struct axi_regs *regs = priv->iobase;
+ /* Enable TX */
+ writel(XAE_TC_TX_MASK, ®s->tc);
+ /* Enable RX */
+ writel(XAE_RCW1_RX_MASK, ®s->rcw1);
+
+ /* PHY setup */
+ if (!setup_phy(dev)) {
+ axiemac_stop(dev);
+ return -1;
+ }
+ } else {
+ struct xxv_axi_regs *regs = priv->iobase;
+ /* Enable TX */
+ temp = readl(®s->tc) & ~XXV_TC_TX_MASK;
+ temp |= XXV_TC_TX_MASK;
+ writel(temp, ®s->tc);
+
+ /* Enable RX */
+ temp = readl(®s->rcw1) & ~XXV_RCW1_RX_MASK;
+ temp |= XXV_RCW1_RX_MASK;
+ writel(temp, ®s->rcw1);
  }

  debug("axiemac: Init complete\n");
@@ -537,6 +610,15 @@ static int axiemac_send(struct udevice *dev, void
*ptr, int len)
  if (len > PKTSIZE_ALIGN)
  len = PKTSIZE_ALIGN;

+ /* If si

[u-boot, v1 0/1] mtd: spi-nor-ids: add Micron MT25QL01G flash

[Hongwei Zhang]

>From:  Patrice CHOTARD 
>
>Hi Hongwei
>
>On 12/4/20 11:06 PM, Hongwei Zhang wrote:
>> Add STMICRO MT25QL01G flash, used on AST2600 board.
>
>MT25QL01G is not a STMicroelectronics flash but a Micron one ;-)

Thanks for the correction, Patrice.

I came back to spi-nor-ids.c, there are two places in the code checking
CONFIG_SPI_FLASH_STMICRO define, at line 167 (a lot of Micron flashes
included in the block), and at line 239, furthermore, there is no
SPI_FLASH_MICRON config menu in Kconfig file. I got confused, why 
SPI_FLASH_MICRON is not in Kconfig?

>
>Patrice
>
>>
>> Signed-off-by: Hongwei Zhang 
>> ---
>>  drivers/mtd/spi/spi-nor-ids.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/mtd/spi/spi-nor-ids.c
>> b/drivers/mtd/spi/spi-nor-ids.c index 09e8196048..6d22b80586 100644
>> --- a/drivers/mtd/spi/spi-nor-ids.c
>> +++ b/drivers/mtd/spi/spi-nor-ids.c
>> @@ -185,6 +185,7 @@ const struct flash_info spi_nor_ids[] = {
>>  { INFO("n25q512ax3",  0x20ba20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR |
>SPI_NOR_QUAD_READ) },
>>  { INFO("n25q00",  0x20ba21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR | 
>> SPI_NOR_QUAD_READ
>| NO_CHIP_ERASE) },
>>  { INFO("n25q00a", 0x20bb21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR | 
>> SPI_NOR_QUAD_READ
>| NO_CHIP_ERASE) },
>> +{ INFO("mt25ql01g",   0x21ba20, 0, 64 * 1024, 2048, SECT_4K | USE_FSR |
>SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
>>  { INFO("mt25qu02g",   0x20bb22, 0, 64 * 1024, 4096, SECT_4K | USE_FSR |
>SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },

[u-boot, v1 1/1] mtd: spi-nor-ids: add Micron MT25QL01G flash

[Hongwei Zhang]

Add Micron MT25QL01G flash, used on AST2600 board.

Signed-off-by: Hongwei Zhang 
---
 drivers/mtd/spi/spi-nor-ids.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 09e8196048..6d22b80586 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -185,6 +185,7 @@ const struct flash_info spi_nor_ids[] = {
{ INFO("n25q512ax3",  0x20ba20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR | 
SPI_NOR_QUAD_READ) },
{ INFO("n25q00",  0x20ba21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR | 
SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
{ INFO("n25q00a", 0x20bb21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR | 
SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
+   { INFO("mt25ql01g",   0x21ba20, 0, 64 * 1024, 2048, SECT_4K | USE_FSR | 
SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
{ INFO("mt25qu02g",   0x20bb22, 0, 64 * 1024, 4096, SECT_4K | USE_FSR | 
SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
{ INFO("mt35xu512aba", 0x2c5b1a, 0,  128 * 1024,  512, USE_FSR | 
SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES) },
{ INFO("mt35xu02g",  0x2c5b1c, 0, 128 * 1024,  2048, USE_FSR | 
SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES) },
-- 
2.17.1

[u-boot, v1 0/1] mtd: spi-nor-ids: add Micron MT25QL01G flash

[Hongwei Zhang]

Hello Reviewer,

Micron MT25QL01G flash is used on AST2600 board, this patch add it in
the table.

Please add this update in v2019.04-aspeed-openbmc branch when it is
accepted. If I need to submit a separate patch to that branch, please
let me know.

Thanks!

Hongwei Zhang (1):
  mtd: spi-nor-ids: add Micron MT25QL01G flash

 drivers/mtd/spi/spi-nor-ids.c | 1 +
 1 file changed, 1 insertion(+)

--
2.17.1

Re: [SPECIFICATION RFC] The firmware and bootloader log specification

[Tom Rini]

On Fri, Dec 04, 2020 at 02:23:23PM +0100, Paul Menzel wrote:
> Dear Wim, dear Daniel,
> 
> 
> First, thank you for including all parties in the discussion.
> Am 04.12.20 um 13:52 schrieb Wim Vervoorn:
> 
> > I agree with you. Using an existing standard is better than inventing
> > a new one in this case. I think using the coreboot logging is a good
> > idea as there is indeed a lot of support already available and it is
> > lightweight and simple.
> In my opinion coreboot’s format is lacking, that it does not record the
> timestamp, and the log level is not stored as metadata, but (in coreboot)
> only used to decide if to print the message or not.
> 
> I agree with you, that an existing standard should be used, and in my
> opinion it’s Linux message format. That is most widely supported, and
> existing tools could then also work with pre-Linux messages.
> 
> Sean Hudson from Mentor Graphics presented that idea at Embedded Linux
> Conference Europe 2016 [1]. No idea, if anything came out of that effort.
> (Unfortunately, I couldn’t find an email. Does somebody have contacts at
> Mentor to find out, how to reach him?)

I believe the main thing that came out of this was the reminder that
there was an even older attempt by U-Boot to have such a mechanism, and
that at the time getting the work accepted in Linux faced some hurdles
or another.

That said, I too agree with taking what's already a de facto standard,
the coreboot logging, and expand on it as needed.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 9/9] board: sl28: add OP-TEE Trusted OS support (bl32)

[Tom Rini]

On Wed, Nov 18, 2020 at 05:46:02PM +0100, Michael Walle wrote:

> Add support to load the OP-TEE Trusted OS by the SPL.
> 
> Signed-off-by: Michael Walle 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 8/9] board: sl28: add ATF support (bl31)

[Tom Rini]

On Wed, Nov 18, 2020 at 05:46:01PM +0100, Michael Walle wrote:

> Add support to load the bl31 part of the ARM Trusted Firmware by the
> SPL.
> 
> Signed-off-by: Michael Walle 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 7/9] board: sl28: remove u-boot from loadable DT node

[Tom Rini]

On Wed, Nov 18, 2020 at 05:46:00PM +0100, Michael Walle wrote:

> It is not needed. Remove it.
> 
> Signed-off-by: Michael Walle 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 6/9] armv8: layerscape: don't initialize GIC in SPL

[Tom Rini]

On Wed, Nov 18, 2020 at 05:45:59PM +0100, Michael Walle wrote:

> The BL31 expects the GIC to be uninitialized. Thus, if we are loading
> the BL31 by the SPL we must not initialize it. If u-boot is loaded by
> the SPL directly, it will initialize the GIC again (in the same
> lowlevel_init()).
> 
> This was tested on a custom board with SPL loading the BL31 and jumping
> to u-boot as BL33 as well as loading u-boot directly by the SPL. In case
> the ATF BL1/BL2 is used, this patch won't change anything, because no
> SPL is used at all.
> 
> Signed-off-by: Michael Walle 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 7/9] board: sl28: remove u-boot from loadable DT node

[Tom Rini]

On Wed, Nov 18, 2020 at 05:46:00PM +0100, Michael Walle wrote:

> It is not needed. Remove it.
> 
> Signed-off-by: Michael Walle 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 5/9] spl: atf: add support for LOAD_IMAGE_V2

[Tom Rini]

On Wed, Nov 18, 2020 at 05:45:58PM +0100, Michael Walle wrote:

> Newer platforms use the LOAD_IMAGE_V2 parameter passing method. Add
> support for it.
> 
> Signed-off-by: Michael Walle 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 4/9] spl: atf: remove helper structure from common header

[Tom Rini]

On Wed, Nov 18, 2020 at 05:45:57PM +0100, Michael Walle wrote:

> bl2_to_bl31_params_mem is just an implementation detail of the SPL ATF
> support and is not needed anywhere else. Move it from the header to the
> actual module.
> 
> Signed-off-by: Michael Walle 
> Acked-by: Michal Simek 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 3/9] spl: atf: provide a bl2_plat_get_bl31_params_default()

[Tom Rini]

On Wed, Nov 18, 2020 at 05:45:56PM +0100, Michael Walle wrote:

> Move the actual implementation of the bl2_plat_get_bl31_params() to its
> own function. The weak function will just call the default
> implementation. This has the advantage that board code can still call
> the original implementation if it just want to modify minor things.
> 
> Signed-off-by: Michael Walle 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 2/9] spl: atf: move storage for bl31_params into function

[Tom Rini]

On Wed, Nov 18, 2020 at 05:45:55PM +0100, Michael Walle wrote:

> There is no need to have the storage available globally. This is also a
> preparation for LOAD_IMAGE_V2 support. That will introduce a similar
> generator function which also has its own storage.
> 
> Signed-off-by: Michael Walle 
> Acked-by: Michal Simek 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 1/9] treewide: use CONFIG_IS_ENABLED() for ARMV8_SEC_FIRMWARE_SUPPORT

[Tom Rini]

On Wed, Nov 18, 2020 at 05:45:54PM +0100, Michael Walle wrote:

> There is SPL_ARMV8_SEC_FIRMWARE_SUPPORT and ARMV8_SEC_FIRMWARE_SUPPORT.
> Thus use CONFIG_IS_ENABLED() instead of the simple #ifdef.
> 
> Signed-off-by: Michael Walle 
> Acked-by: Michal Simek 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 12/12] bootm: Support string substitution in bootargs

[Tom Rini]

On Thu, Nov 05, 2020 at 10:33:48AM -0700, Simon Glass wrote:

> In some cases it is necessary to pass parameters to Linux so that it will
> boot correctly. For example, the rootdev parameter is often used to
> specify the root device. However the root device may change depending on
> whence U-Boot loads the kernel. At present it is necessary to build up
> the command line by adding device strings to it one by one.
> 
> It is often more convenient to provide a template for bootargs, with
> U-Boot doing the substitution from other environment variables.
> 
> Add a way to substitute strings in the bootargs variable. This allows
> things like "rootdev=${rootdev}" to be used in bootargs, with the
> ${rootdev} substitution providing the UUID of the root device.
> 
> For example, to substitute the GUID of the kernel partition:
> 
>   setenv bootargs "console=/dev/ttyS0 rootdev=${uuid}/PARTNROFF=1
>   kern_guid=${uuid}"
>   part uuid mmc 2:2 uuid
>   bootm
> 
> This is particularly useful when the command line from another place. For
> example, Chrome OS stores the command line next to the kernel itself. It
> depends on the kernel version being used as well as the hardware features,
> so it is extremely difficult to devise a U-Boot script that works on all
> boards and kernel versions. With this feature, the command line can be
> read from disk and used directly, with a few substitutions set up.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 11/12] cli: Support macro processing with a fixed-size buffer

[Tom Rini]

On Thu, Nov 05, 2020 at 10:33:47AM -0700, Simon Glass wrote:

> At present cli_simple_process_macros() requires that the caller provide
> an output buffer that is exactly CONFIG_SYS_CBSIZE bytes in length. This
> makes sense since it is designed to be used from the command line. But we
> also want to use it for bootargs substitution.
> 
> Update the function to allow the caller to specify the buffer size. Also
> return an error if the buffer is exhausted. The caller can ignore that if
> preferred.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 10/12] x86: zimage: Add silent-console processing

[Tom Rini]

On Thu, Nov 05, 2020 at 10:33:46AM -0700, Simon Glass wrote:

> At present zimage does its own command-line processing and does not
> support the 'silent console' feature. There doesn't seem to be any good
> reason for this.
> 
> Add support for silent console to zimage.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 09/12] bootm: Allow updating the bootargs in a buffer

[Tom Rini]

On Thu, Nov 05, 2020 at 10:33:45AM -0700, Simon Glass wrote:

> At present we only support updating the 'bootargs' environment
> variable. Add another function to update a buffer instead. This will
> allow zimage to use this feature.
> 
> Also add a lot more tests to cover various cases.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 08/12] bootm: Update bootm_process_cmdline_env() to use flags

[Tom Rini]

On Thu, Nov 05, 2020 at 10:33:44AM -0700, Simon Glass wrote:

> At present only one transformation is supported: making the Linux console
> silent. To prepare for adding more, convert the boolean parameter into a
> flag value.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 07/12] bootm: Split out bootargs environment reading / writing

[Tom Rini]

On Thu, Nov 05, 2020 at 10:33:43AM -0700, Simon Glass wrote:

> At present bootm_process_cmdline_env() reads the 'bootargs' variable and
> then writes it back afterwards. This is painful for tests, which would
> rather use a simple buffer.
> 
> It is also useful for zimage to use a buffer, since it does not actually
> put the Linux command line in the bootargs variable.
> 
> Refactor the existing code into two pieces. One handles reading and
> writing the environment variable, as well as allocating a buffer for use
> by the rest of the code, which now operates on a buffer.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 06/12] bootm: Use size rather than length for CONSOLE_ARG

[Tom Rini]

On Thu, Nov 05, 2020 at 10:33:42AM -0700, Simon Glass wrote:

> Use the size (including terminator) for in this function, rather than
> the length. This is arguably easier to follow, with the coming
> refactor.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 05/12] bootm: Add a bool parameter to bootm_process_cmdline_env()

[Tom Rini]

On Thu, Nov 05, 2020 at 10:33:41AM -0700, Simon Glass wrote:

> This function will soon do more than just handle the 'silent linux'
> feature. As a first step, update it to take a boolean parameter,
> indicating whether or not the processing is required.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 04/12] bootm: Rename fixup_silent_linux()

[Tom Rini]

On Thu, Nov 05, 2020 at 10:33:40AM -0700, Simon Glass wrote:

> We want to add more processing to this function. Before doing so, rename
> it to bootm_process_cmdline_env(), which is more generic.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 02/12] bootm: Add tests for fixup_silent_linux()

[Tom Rini]

On Thu, Nov 05, 2020 at 10:33:38AM -0700, Simon Glass wrote:

> This function currently has no tests. Export it so that we can implement
> a simple test on sandbox. Use IS_ENABLED() to remove the unused code,
> instead #ifdef.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 03/12] bootm: Update fixup_silent_linux() to return an error

[Tom Rini]

On Thu, Nov 05, 2020 at 10:33:39AM -0700, Simon Glass wrote:

> At present this function fails silently on error. Update it to produce
> an error code. Report this error to the user and abort the boot, since it
> likely will prevent a successful start.
> 
> No tests are added at this stage, since additional refactoring is taking
> place in subsequent patches.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 01/12] env: Allow returning errors from hdelete_r()

[Tom Rini]

On Thu, Nov 05, 2020 at 10:33:37AM -0700, Simon Glass wrote:

> At present this function returns 1 on success and 0 on failure. But in
> the latter case it provides no indication of what went wrong.
> 
> If an attempt is made to delete a non-existent variable, the caller may
> want to ignore this error. This happens when setting a non-existent
> variable to "", for example.
> 
> Update the function to return 0 on success and a useful error code on
> failure. Add a function comment too.
> 
> Make sure that env_set() does not return an error if it is deleting a
> variable that doesn't exist. We could update env_set() to return useful
> error numbers also, but that is beyond the scope of this change.
> 
> Signed-off-by: Simon Glass 
> 
> wip

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] mmc: initialize an err variable

[Tom Rini]

On Fri, Dec 04, 2020 at 06:36:00AM +0900, Jaehoon Chung wrote:

> Initialize an err variable to 0.
> 
> Signed-off-by: Jaehoon Chung 

Reported-by: Coverity (CID: 313548)
Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature

Re: Please pull u-boot-marvell/master

[Tom Rini]

On Mon, Dec 07, 2020 at 12:18:28PM +0100, Stefan Roese wrote:

> Hi Tom,
> 
> please pull an update of Marvell Armada related fixes and minor
> additions. Here the summary log:
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] mmc: meson-gx: change clock phase value on AGX SoCs

[Jaehoon Chung]

Hi,

On 12/8/20 2:15 AM, Stefan Agner wrote:
> Amlogic AGX SoCs seem to have issue communicating with some eMMC
> devices (in particular with a Micron 128GB eMMC 5.1). The device
> is detected with 1-bit bus width, and at higher temperature loading
> pretty much anything from the storage fails: (e.g. fs_devread read error
> - block).
> 
> When phase is set to 270° it is detected with 8-bit bus width and is
> working fine accross all temperatures.
> 
> Signed-off-by: Stefan Agner 
> ---
> Hi Neil,
> 
> I debugged this issue today on an ODROID N2+ not booting reliably. I am
> not sure if we can safely switch to 270° for all SoCs with
> amlogic,meson-axg-mmc, but I guess we have to try and see what happens?
> I will do a bit broader testing in the comming days here.

Some SoCs don't work fine with 180'. So I have changed 270' phase and Neil had 
applied SoC compatible.
I guess that it's relevant to controlling clock. But In u-boot, meson_gx_mmc 
doesn't follow Linux kernel fully.
I will refactor meson_gxm_mmc file after finished my other work.

> 
> Btw, I do see that 180° is also set in Linux. Do you have a patch to
> address this in Linux?

I didn't check Linux kernel yet in more detail. Also, i will investigate to 
check a meson mmc driver after finished my other job.

Best Regards,
Jaehoon Chung

> 
> --
> Stefan
> 
> 
>  arch/arm/include/asm/arch-meson/sd_emmc.h | 1 +
>  drivers/mmc/meson_gx_mmc.c| 9 +
>  2 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/include/asm/arch-meson/sd_emmc.h 
> b/arch/arm/include/asm/arch-meson/sd_emmc.h
> index cb16f75fc6..db5e058098 100644
> --- a/arch/arm/include/asm/arch-meson/sd_emmc.h
> +++ b/arch/arm/include/asm/arch-meson/sd_emmc.h
> @@ -14,6 +14,7 @@
>  
>  enum meson_gx_mmc_compatible {
>   MMC_COMPATIBLE_GX,
> + MMC_COMPATIBLE_AGX,
>   MMC_COMPATIBLE_SM1,
>  };
>  
> diff --git a/drivers/mmc/meson_gx_mmc.c b/drivers/mmc/meson_gx_mmc.c
> index 5facbfdd9a..2c27113c10 100644
> --- a/drivers/mmc/meson_gx_mmc.c
> +++ b/drivers/mmc/meson_gx_mmc.c
> @@ -64,14 +64,15 @@ static void meson_mmc_config_clock(struct mmc *mmc)
>  
>   /*
>* SM1 SoCs doesn't work fine over 50MHz with CLK_CO_PHASE_180
> +  * AGX SoCs don't work reliable with some eMMCs with CLK_CO_PHASE_180
>* If CLK_CO_PHASE_270 is used, it's more stable than other.
>* Other SoCs use CLK_CO_PHASE_180 by default.
>* It needs to find what is a proper value about each SoCs.
>*/
> - if (meson_gx_mmc_is_compatible(mmc->dev, MMC_COMPATIBLE_SM1))
> - meson_mmc_clk |= CLK_CO_PHASE_270;
> - else
> + if (meson_gx_mmc_is_compatible(mmc->dev, MMC_COMPATIBLE_GX))
>   meson_mmc_clk |= CLK_CO_PHASE_180;
> + else
> + meson_mmc_clk |= CLK_CO_PHASE_270;
>  
>   /* 180 phase tx clock */
>   meson_mmc_clk |= CLK_TX_PHASE_000;
> @@ -327,7 +328,7 @@ int meson_mmc_bind(struct udevice *dev)
>  
>  static const struct udevice_id meson_mmc_match[] = {
>   { .compatible = "amlogic,meson-gx-mmc", .data = MMC_COMPATIBLE_GX },
> - { .compatible = "amlogic,meson-axg-mmc", .data = MMC_COMPATIBLE_GX },
> + { .compatible = "amlogic,meson-axg-mmc", .data = MMC_COMPATIBLE_AGX },
>   { .compatible = "amlogic,meson-sm1-mmc", .data = MMC_COMPATIBLE_SM1 },
>   { /* sentinel */ }
>  };
> 

[PATCH v3 07/34] ARM: dts: sama7g5: add slow rc and main rc oscillators

[Eugen Hristev]

From: Claudiu Beznea 

Add slow rc and main rc oscillators to dtsi.

Signed-off-by: Claudiu Beznea 
---
Changes in v3:
- adapt slow rc frequency to real value: 32 kHz


 arch/arm/dts/sama7g5.dtsi  | 12 
 arch/arm/dts/sama7g5ek-u-boot.dtsi |  8 
 2 files changed, 20 insertions(+)

diff --git a/arch/arm/dts/sama7g5.dtsi b/arch/arm/dts/sama7g5.dtsi
index 618f3a37d5..0fc7a5e197 100644
--- a/arch/arm/dts/sama7g5.dtsi
+++ b/arch/arm/dts/sama7g5.dtsi
@@ -16,6 +16,18 @@
compatible = "microchip,sama7g5";
 
clocks {
+   slow_rc_osc: slow_rc_osc {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <32000>;
+   };
+
+   main_rc: main_rc {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <1200>;
+   };
+
slow_xtal: slow_xtal {
compatible = "fixed-clock";
#clock-cells = <0>;
diff --git a/arch/arm/dts/sama7g5ek-u-boot.dtsi 
b/arch/arm/dts/sama7g5ek-u-boot.dtsi
index c0f8f94027..06af2f74ee 100644
--- a/arch/arm/dts/sama7g5ek-u-boot.dtsi
+++ b/arch/arm/dts/sama7g5ek-u-boot.dtsi
@@ -23,6 +23,14 @@
};
 };
 
+&main_rc {
+   u-boot,dm-pre-reloc;
+};
+
+&slow_rc_osc {
+   u-boot,dm-pre-reloc;
+};
+
 &uart0 {
u-boot,dm-pre-reloc;
 };
-- 
2.25.1

Re: [PATCH 06/14] qemu: arm64: Set dfu_alt_info variable for the platform

[Tom Rini]

On Sat, Dec 05, 2020 at 11:31:49AM +0100, Heinrich Schuchardt wrote:
> On 11/26/20 7:41 PM, Sughosh Ganu wrote:
> > The dfu framework uses the dfu_alt_info environment variable to get
> > information that is needed for performing the firmware update. Set the
> > dfu_alt_info for the platform to reflect the two mtd partitions
> > created for the u-boot env and the firmware image.
> > 
> > Signed-off-by: Sughosh Ganu 
> 
> I can't see anything QEMU specific in this patch. Why is the code under
> board/emulation/?
> 
> Best regards
> 
> Heinrich
> 
> > ---
> >   board/emulation/qemu-arm/qemu-arm.c | 55 +
> >   include/configs/qemu-arm.h  |  1 +
> >   2 files changed, 56 insertions(+)
> > 
> > diff --git a/board/emulation/qemu-arm/qemu-arm.c 
> > b/board/emulation/qemu-arm/qemu-arm.c
> > index d5ed3eebaf..8cad54c76f 100644
> > --- a/board/emulation/qemu-arm/qemu-arm.c
> > +++ b/board/emulation/qemu-arm/qemu-arm.c
> > @@ -200,8 +200,63 @@ void flash_write32(u32 value, void *addr)
> > 
> >   #if defined(CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT)
> > 
> > +#include 
> >   #include 
> > 
> > +#define MTDPARTS_LEN   256
> > +#define MTDIDS_LEN 128
> > +
> > +#define DFU_ALT_BUF_LENSZ_1K
> > +
> > +static void board_get_alt_info(struct mtd_info *mtd, char *buf)
> > +{
> > +   struct mtd_info *part;
> > +   bool first = true;
> > +   const char *name;
> > +   int len, partnum = 0;
> > +
> > +   name = mtd->name;
> > +   len = strlen(buf);
> > +
> > +   if (buf[0] != '\0')
> > +   len += snprintf(buf + len, DFU_ALT_BUF_LEN - len, "&");
> > +   len += snprintf(buf + len, DFU_ALT_BUF_LEN - len,
> > +   "mtd %s=", name);
> > +
> > +   list_for_each_entry(part, &mtd->partitions, node) {
> > +   partnum++;
> > +   if (!first)
> > +   len += snprintf(buf + len, DFU_ALT_BUF_LEN - len, ";");
> > +   first = false;
> > +
> > +   len += snprintf(buf + len, DFU_ALT_BUF_LEN - len,
> > +   "%s part %d",
> > +   part->name, partnum);
> > +   }
> > +}
> > +
> > +void set_dfu_alt_info(char *interface, char *devstr)
> > +{
> > +   struct mtd_info *mtd;
> > +
> > +   ALLOC_CACHE_ALIGN_BUFFER(char, buf, DFU_ALT_BUF_LEN);
> > +
> > +   if (env_get("dfu_alt_info"))
> > +   return;
> > +
> > +   memset(buf, 0, sizeof(buf));
> > +
> > +   /* probe all MTD devices */
> > +   mtd_probe_devices();
> > +
> > +   mtd = get_mtd_device_nm("nor0");
> > +   if (!IS_ERR_OR_NULL(mtd))
> > +   board_get_alt_info(mtd, buf);
> > +
> > +   env_set("dfu_alt_info", buf);
> > +   printf("dfu_alt_info set\n");
> > +}
> > +
> >   static void board_get_mtdparts(const char *dev, const char *partition,
> >char *mtdids, char *mtdparts)
> >   {
> > diff --git a/include/configs/qemu-arm.h b/include/configs/qemu-arm.h
> > index 69ff329434..726f985d35 100644
> > --- a/include/configs/qemu-arm.h
> > +++ b/include/configs/qemu-arm.h
> > @@ -33,6 +33,7 @@
> >   #include 
> > 
> >   #if defined(CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT)
> > +#define CONFIG_SET_DFU_ALT_INFO
> >   #define CONFIG_SYS_MTDPARTS_RUNTIME

First, CONFIG_SET_DFU_ALT_INFO is in Kconfig and needs to be enabled
that way.  Second, typically we just set the information in the
environment part of the header.  This is especially true if in both this
case and the previous patch to add mtdparts, we don't really have this
being dynamic?  Or are we really expecting / supporting arbitrary sized
flash as this is qemu?  Thanks.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 05/14] qemu: arm64: Add support for dynamic mtdparts for the platform

[Tom Rini]

On Sat, Dec 05, 2020 at 11:29:58AM +0100, Heinrich Schuchardt wrote:
> On 11/26/20 7:41 PM, Sughosh Ganu wrote:
> > Add support for setting the default values for mtd partitions on the
> > platform for the nor flash. This would be used for updating the
> > firmware image using uefi capsule update with the dfu mtd backend
> > driver.
> > 
> > Signed-off-by: Sughosh Ganu 
> > ---
> >   board/emulation/qemu-arm/qemu-arm.c | 70 +
> >   include/configs/qemu-arm.h  |  7 +++
> >   2 files changed, 77 insertions(+)
> > 
> > diff --git a/board/emulation/qemu-arm/qemu-arm.c 
> > b/board/emulation/qemu-arm/qemu-arm.c
> > index b3d5b3d5c2..d5ed3eebaf 100644
> > --- a/board/emulation/qemu-arm/qemu-arm.c
> > +++ b/board/emulation/qemu-arm/qemu-arm.c
[snip]
> > +#if defined(CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT)
> > +#define CONFIG_SYS_MTDPARTS_RUNTIME
> > +#endif

This symbol is in Kconfig and needs to be enabled that way.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 01/14] qemu: arm: Use the generated DTB only when CONGIG_OF_BOARD is defined

[Heinrich Schuchardt]

On 07.12.20 13:50, Heinrich Schuchardt wrote:
> On 07.12.20 06:15, Sughosh Ganu wrote:
>> hello Heinrich,
>>
>> On Sat, 5 Dec 2020 at 15:01, Heinrich Schuchardt > > wrote:
>>
>> On 11/26/20 7:40 PM, Sughosh Ganu wrote:
>> > The Qemu platform emulator generates a device tree blob and places it
>> > at the start of the dram, which is then used by u-boot. Use this dtb
>> > only if CONFIG_OF_BOARD is defined. This allows using a different
>> > device tree, using the CONFIG_OF_SEPARATE option. This dtb is attached
>> > to the u-boot binary as a u-boot-fdt.bin file
>>
>> Dear Sughosh,
>>
>> thank your for this series which will allow us to better demonstrate and
>> test capsule updates.
>>
>> I am not sure if the approach that you take at device-trees here is the
>> right one.
>>
>> On QEMU the device-tree is generated on the fly by the QEMU binary
>> depending on which devices the user has specified.
>>
>> Your idea is to replace this device-tree completely to be able to add
>> extra elements (the EFI signature list, see patch 2/14). Thus a
>> device-tree might be loaded that does not match the user selected
>> devices.
>>
>> An alternative approach would be to apply all additions to the
>> device-tree as an FDT overlay (or fixup). This would allow the dynamic
>> parts of the QEMU device-tree still to be passed through.
>>
>>
>> I will take a look at storing the public key as part of the fdt overlay,
>> with a runtime fixup. Although, I think the issue that you are pointing
>> to would be specific to Qemu and not other platforms. But I do see the
>> merit in having the public-key certificate stored as part of an overlay.
>> If I hit any issues while implementing this, I will get back to you. Thanks.
>>
>> -sughosh
>
> OpenSBI can supply a device-tree to U-Boot. So this would be an
> equivalent case.
>
> Best regards
>
> Heinrich

: "I am unable to think of a simple and elegant way to generate
the overlay dtb, since this would require creation of a corresponding
dts file, compiling it into a dtb and then using this on the platform."

Jean-Jacques' patch series introduced some of the necessary code:

[PATCH PATCH v6 00/13] Add support for applications of overlays in SPL
https://lists.denx.de/pipermail/u-boot/2019-October/387653.html
https://patchwork.ozlabs.org/project/uboot/list/?series=137810&state=%2A&archive=both

CONFIG_OF_OVERLAY_LIST is used to specify the overlays to be compiled.
You will have to remove the CONFIG_SPL_LOAD_FIT_APPLY_OVERLAY and
CONFIG_SPL_LOAD_FIT dependency.

Best regards

Heinrich

>
>>
>>
>> Could you, please, assess the pros and cons of the two approaches with
>> respect to:
>>
>> * usability for capsule updates
>> * applicability for non-QEMU systems
>> * integration of DTB overlays with FIT images for other use cases
>>
>> Best regards
>>
>> Heinrich
>>
>>
>> >
>> > Signed-off-by: Sughosh Ganu > >
>> > ---
>> >   board/emulation/qemu-arm/qemu-arm.c | 2 ++
>> >   1 file changed, 2 insertions(+)
>> >
>> > diff --git a/board/emulation/qemu-arm/qemu-arm.c
>> b/board/emulation/qemu-arm/qemu-arm.c
>> > index f18f2ed7da..e146d1cc50 100644
>> > --- a/board/emulation/qemu-arm/qemu-arm.c
>> > +++ b/board/emulation/qemu-arm/qemu-arm.c
>> > @@ -89,11 +89,13 @@ int dram_init_banksize(void)
>> >       return 0;
>> >   }
>> >
>> > +#if defined(CONFIG_OF_BOARD)
>> >   void *board_fdt_blob_setup(void)
>> >   {
>> >       /* QEMU loads a generated DTB for us at the start of RAM. */
>> >       return (void *)CONFIG_SYS_SDRAM_BASE;
>> >   }
>> > +#endif
>> >
>> >   void enable_caches(void)
>> >   {
>> >
>>
>

Re: [PATCH 3/3] mkimge: Reject signing-related flags without FIT_SIGNATURE

[Philippe REYNES]

Hi Joel,

Sorry for this very late answer.

You're right, this is a bad behaviour, but I think that this
solution remove too many options. For example, If signature
is disabled, this solution also disable the padding in the fit image.

Looking a bit deeper, this patch removes all options that are
not displayed by the help of mkimage when signature is disabled.
But I think that this help is not correct. If the signature is disabled,
the padding is still available.
So I think that we have an issue in the help too.

Regards,
Philippe

Le 11/11/2020 à 12:18, Joel Stanley a écrit :

When CONFIG_FIT_SIGNATURE=n the signing options are not available. If a
user is careful they will notice this when looking at the help output.

If they are not careful they will waste several hours wondering what
they got wrong, as mkimage will silently ignore the signing related
options.

Make it obvious that the commands don't work by removing them from the
getopt opt_string.

The tool will now behave as follows:

  $ mkimage -f machine.its -k keys -K u-boot-pubkey.dtb -r image.fit
  mkimage: invalid option -- 'k'
  Error: Invalid option

Signed-off-by: Joel Stanley 
---
  tools/mkimage.c | 9 +++--
  1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/tools/mkimage.c b/tools/mkimage.c
index e78608293e72..10a1b3dc8c18 100644
--- a/tools/mkimage.c
+++ b/tools/mkimage.c
@@ -142,6 +142,12 @@ static int add_content(int type, const char *fname)
return 0;
  }
  
+#ifdef CONFIG_FIT_SIGNATURE

+#define OPT_STRING "a:A:b:B:c:C:d:D:e:Ef:Fk:i:K:ln:N:p:O:rR:qstT:vVx"
+#else
+#define OPT_STRING "a:A:b:C:d:D:e:f:i:ln:O:R:qstT:vVx"
+#endif
+
  static void process_args(int argc, char **argv)
  {
char *ptr;
@@ -149,8 +155,7 @@ static void process_args(int argc, char **argv)
char *datafile = NULL;
int opt;
  
-	while ((opt = getopt(argc, argv,

-  "a:A:b:B:c:C:d:D:e:Ef:Fk:i:K:ln:N:p:O:rR:qstT:vVx")) != -1) {
+   while ((opt = getopt(argc, argv, OPT_STRING)) != -1) {
switch (opt) {
case 'a':
params.addr = strtoull(optarg, &ptr, 16);

Re: [PATCH] sunxi: Add arm64 FEL support

[Jagan Teki]

On Thu, Nov 19, 2020 at 4:24 PM Andre Przywara  wrote:
>
> So far we did not support the BootROM based FEL USB debug mode on the
> 64-bit builds for Allwinner SoCs: The BootROM is using AArch32, but the
> SPL runs in AArch64.
> Returning back to AArch32 was not working as expected, since the RMR
> reset into 32-bit mode always starts execution in the BootROM, but not
> in the FEL routine.
>
> After some debug and research and with help via IRC, the CPU hotplug
> mechanism emerged as a solution: If a certain R_CPUCFG register contains
> some magic, the BootROM will immediately branch to an address stored in
> some other register. This works well for our purposes.
>
> Enable the FEL feature by providing early AArch32 code to first save the
> FEL state, *before* initially entering AArch64.
> If we eventually determine that we should return to FEL, we reset back
> into AArch32, and use the CPU hotplug mechanism to run some small
> AArch32 code snippet that restores the initially saved FEL state.
>
> That allows the normal AArch64 SPL build to be loaded via the sunxi-fel
> tool, with it returning into FEL mode, so that other payloads can be
> transferred via FEL as well.
>
> Tested on A64, H5 and H6.
>
> Signed-off-by: Andre Przywara 
> ---

Acked-by: Jagan Teki 

Re: [PATCH 1/2] spi: mtk_snor: add support for MTK SPI NOR controller

[Jagan Teki]

On Fri, Nov 13, 2020 at 8:32 AM SkyLake Huang
 wrote:
>
> From: "SkyLake.Huang" 
>
> This patch adds support for MTK SPI NOR controller, which you
> can see on mt7622 & mt7629.
>
> This controller is designed only for SPI NOR. We can't adjust
> its bus clock dynamically. Set clock in dts instead.
>
> Signed-off-by: SkyLake.Huang 
> ---
>  drivers/spi/Kconfig|   7 +
>  drivers/spi/Makefile   |   1 +
>  drivers/spi/mtk_snor.c | 597 +
>  3 files changed, 605 insertions(+)
>  create mode 100644 drivers/spi/mtk_snor.c
>
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index fae2040af8..670af450c1 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -174,6 +174,13 @@ config MT7621_SPI
>   the SPI NOR flash on platforms embedding this Ralink / MediaTek
>   SPI core, like MT7621/7628/7688.
>
> +config MTK_SNOR
> +   bool "Mediatek SPI-NOR controller driver"
> +   depends on SPI_MEM
> +   help
> + Enable the Mediatek SPINOR controller driver. This driver has
> +  better read/write performance with NOR.
> +
>  config MTK_SNFI_SPI
> bool "Mediatek SPI memory controller driver"
> depends on SPI_MEM
> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
> index ae4f2958f8..efe92f6b18 100644
> --- a/drivers/spi/Makefile
> +++ b/drivers/spi/Makefile
> @@ -38,6 +38,7 @@ obj-$(CONFIG_MESON_SPIFC) += meson_spifc.o
>  obj-$(CONFIG_MPC8XX_SPI) += mpc8xx_spi.o
>  obj-$(CONFIG_MPC8XXX_SPI) += mpc8xxx_spi.o
>  obj-$(CONFIG_MTK_SNFI_SPI) += mtk_snfi_spi.o
> +obj-$(CONFIG_MTK_SNOR) += mtk_snor.o
>  obj-$(CONFIG_MT7621_SPI) += mt7621_spi.o
>  obj-$(CONFIG_MSCC_BB_SPI) += mscc_bb_spi.o
>  obj-$(CONFIG_MVEBU_A3700_SPI) += mvebu_a3700_spi.o
> diff --git a/drivers/spi/mtk_snor.c b/drivers/spi/mtk_snor.c
> new file mode 100644
> index 00..0a92f1c5a8
> --- /dev/null
> +++ b/drivers/spi/mtk_snor.c
> @@ -0,0 +1,597 @@
> +// SPDX-License-Identifier: GPL-2.0
> +//
> +// Mediatek SPI-NOR controller driver
> +//
> +// Copyright (C) 2020 SkyLake Huang 
> +//
> +// Some parts are based on drivers/spi/spi-mtk-nor.c of linux version
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DRIVER_NAME "mtk-spi-nor"
> +
> +#define MTK_NOR_REG_CMD0x00
> +#define MTK_NOR_CMD_WRSR   BIT(5)
> +#define MTK_NOR_CMD_WRITE  BIT(4)
> +#define MTK_NOR_CMD_PROGRAMBIT(2)
> +#define MTK_NOR_CMD_RDSR   BIT(1)
> +#define MTK_NOR_CMD_READ   BIT(0)
> +#define MTK_NOR_CMD_MASK   GENMASK(5, 0)
> +
> +#define MTK_NOR_REG_PRG_CNT0x04
> +#define MTK_NOR_REG_RDSR   0x08
> +#define MTK_NOR_REG_RDATA  0x0c
> +
> +#define MTK_NOR_REG_RADR0  0x10
> +#define MTK_NOR_REG_RADR(n)(MTK_NOR_REG_RADR0 + 4 * (n))
> +#define MTK_NOR_REG_RADR3  0xc8
> +
> +#define MTK_NOR_REG_WDATA  0x1c
> +
> +#define MTK_NOR_REG_PRGDATA0   0x20
> +#define MTK_NOR_REG_PRGDATA(n) (MTK_NOR_REG_PRGDATA0 + 4 * (n))
> +#define MTK_NOR_REG_PRGDATA_MAX5
> +
> +#define MTK_NOR_REG_SHIFT0 0x38
> +#define MTK_NOR_REG_SHIFT(n)   (MTK_NOR_REG_SHIFT0 + 4 * (n))
> +#define MTK_NOR_REG_SHIFT_MAX  9
> +
> +#define MTK_NOR_REG_CFG1   0x60
> +#define MTK_NOR_FAST_READ  BIT(0)
> +
> +#define MTK_NOR_REG_CFG2   0x64
> +#define MTK_NOR_WR_CUSTOM_OP_ENBIT(4)
> +#define MTK_NOR_WR_BUF_EN  BIT(0)
> +
> +#define MTK_NOR_REG_PP_DATA0x98
> +
> +#define MTK_NOR_REG_IRQ_STAT   0xa8
> +#define MTK_NOR_REG_IRQ_EN 0xac
> +#define MTK_NOR_IRQ_DMABIT(7)
> +#define MTK_NOR_IRQ_WRSR   BIT(5)
> +#define MTK_NOR_IRQ_MASK   GENMASK(7, 0)
> +
> +#define MTK_NOR_REG_CFG3   0xb4
> +#define MTK_NOR_DISABLE_WREN   BIT(7)
> +#define MTK_NOR_DISABLE_SR_POLLBIT(5)
> +
> +#define MTK_NOR_REG_WP 0xc4
> +#define MTK_NOR_ENABLE_SF_CMD  0x30
> +
> +#define MTK_NOR_REG_BUSCFG 0xcc
> +#define MTK_NOR_4B_ADDRBIT(4)
> +#define MTK_NOR_QUAD_ADDR  BIT(3)
> +#define MTK_NOR_QUAD_READ  BIT(2)
> +#define MTK_NOR_DUAL_ADDR  BIT(1)
> +#define MTK_NOR_DUAL_READ  BIT(0)
> +#define MTK_NOR_BUS_MODE_MASK  GENMASK(4, 0)
> +
> +#define MTK_NOR_REG_DMA_CTL0x718
> +#define MTK_NOR_DMA_START  BIT(0)
> +
> +#define MTK_NOR_REG_DMA_FADR   0x71c
> +#define MTK_NOR_REG_DMA_DADR   0x720
> +#define MTK_NOR_REG_DMA_END_DADR   0x724
> +
> +#define MTK_NOR_PRG_MAX_SIZE   6
> +// Reading

U-Boot: spl: partition error (stm32mp157)

[Jagan Teki]

Hi Patrick,

Not sure, it's an issue with the current tree, or I may miss something.

Any suggestions?

U-Boot SPL 2021.01-rc2-00143-g345dd00160-dirty (Dec 07 2020 - 01:48:44 +0530)
Model: Engicam i.Core STM32MP1 EDIMM2.2 Starter Kit
RAM: DDR3-DDR3L 32bits 528000Khz
WDT:   Started with servicing (60s timeout)
## Unknown partition table type 0
spl: partition error
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

Disk /dev/sda: 29.83 GiB, 32010928128 bytes, 62521344 sectors
Disk model: Storage Device
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 6524CDDB-929F-4A12-96B2-C04F07403931

Device Start  End  Sectors  Size Type
/dev/sda1 34  545  512  256K Linux filesystem
/dev/sda2546 1057  512  256K Linux filesystem
/dev/sda3   1058 5153 40962M Linux filesystem
/dev/sda4   5154 62521310 62516157 29.8G Linux filesystem

$ sudo dd if=u-boot-spl.stm32 of=/dev/sda1
$ sudo dd if=u-boot-spl.stm32 of=/dev/sda2
$ sudo dd if=u-boot.img of=/dev/sda3

.config:

#
# Automatically generated file; DO NOT EDIT.
# U-Boot 2021.01-rc2 Configuration
#

#
# Compiler: arm-buildroot-linux-gnueabihf-gcc.br_real (Buildroot
2020.08-849-gdcd4b75069-dirty) 9.3.0
#
CONFIG_CREATE_ARCH_SYMLINK=y
# CONFIG_ARC is not set
CONFIG_ARM=y
# CONFIG_M68K is not set
# CONFIG_MICROBLAZE is not set
# CONFIG_MIPS is not set
# CONFIG_NDS32 is not set
# CONFIG_NIOS2 is not set
# CONFIG_PPC is not set
# CONFIG_RISCV is not set
# CONFIG_SANDBOX is not set
# CONFIG_SH is not set
# CONFIG_X86 is not set
# CONFIG_XTENSA is not set
CONFIG_SYS_ARCH="arm"
CONFIG_SYS_CPU="armv7"
CONFIG_SYS_SOC="stm32mp"
CONFIG_SYS_VENDOR="engicam"
CONFIG_SYS_BOARD="stm32mp1"
CONFIG_SYS_CONFIG_NAME="stm32mp1"
# CONFIG_SYS_ICACHE_OFF is not set
# CONFIG_SPL_SYS_ICACHE_OFF is not set
# CONFIG_SYS_DCACHE_OFF is not set
# CONFIG_SPL_SYS_DCACHE_OFF is not set

#
# ARM architecture
#
# CONFIG_GIC_V3_ITS is not set
CONFIG_HAS_VBAR=y
CONFIG_HAS_THUMB2=y
CONFIG_ARM_ASM_UNIFIED=y
CONFIG_SYS_ARM_CACHE_CP15=y
CONFIG_SYS_ARM_MMU=y
# CONFIG_SYS_ARM_MPU is not set
CONFIG_CPU_V7A=y
CONFIG_SYS_ARM_ARCH=7
CONFIG_SYS_CACHE_SHIFT_6=y
CONFIG_SYS_CACHELINE_SIZE=64
CONFIG_SYS_ARM_CACHE_WRITEBACK=y
# CONFIG_SYS_ARM_CACHE_WRITETHROUGH is not set
# CONFIG_SYS_ARM_CACHE_WRITEALLOC is not set
# CONFIG_ARCH_CPU_INIT is not set
CONFIG_SYS_ARCH_TIMER=y
# CONFIG_ARM_SMCCC is not set
# CONFIG_SEMIHOSTING is not set
CONFIG_SYS_THUMB_BUILD=y
CONFIG_SPL_SYS_THUMB_BUILD=y
# CONFIG_SYS_L2CACHE_OFF is not set
# CONFIG_ENABLE_ARM_SOC_BOOT0_HOOK is not set
CONFIG_USE_ARCH_MEMCPY=y
CONFIG_SPL_USE_ARCH_MEMCPY=y
CONFIG_USE_ARCH_MEMSET=y
CONFIG_SPL_USE_ARCH_MEMSET=y
# CONFIG_ARCH_AT91 is not set
# CONFIG_TARGET_EDB93XX is not set
# CONFIG_TARGET_ASPENITE is not set
# CONFIG_TARGET_GPLUGD is not set
# CONFIG_ARCH_DAVINCI is not set
# CONFIG_ARCH_KIRKWOOD is not set
# CONFIG_ARCH_MVEBU is not set
# CONFIG_TARGET_APF27 is not set
# CONFIG_ARCH_ORION5X is not set
# CONFIG_TARGET_SPEAR300 is not set
# CONFIG_TARGET_SPEAR310 is not set
# CONFIG_TARGET_SPEAR320 is not set
# CONFIG_TARGET_SPEAR600 is not set
# CONFIG_TARGET_STV0991 is not set
# CONFIG_TARGET_X600 is not set
# CONFIG_TARGET_FLEA3 is not set
# CONFIG_TARGET_MX35PDK is not set
# CONFIG_ARCH_BCM283X is not set
# CONFIG_ARCH_BCM63158 is not set
# CONFIG_ARCH_BCM68360 is not set
# CONFIG_ARCH_BCM6858 is not set
# CONFIG_TARGET_VEXPRESS_CA15_TC2 is not set
# CONFIG_ARCH_BCMSTB is not set
# CONFIG_TARGET_VEXPRESS_CA5X2 is not set
# CONFIG_TARGET_VEXPRESS_CA9X4 is not set
# CONFIG_TARGET_BCM23550_W1D is not set
# CONFIG_TARGET_BCM28155_AP is not set
# CONFIG_TARGET_BCMCYGNUS is not set
# CONFIG_TARGET_BCMNSP is not set
# CONFIG_TARGET_BCMNS2 is not set
# CONFIG_TARGET_BCMNS3 is not set
# CONFIG_ARCH_EXYNOS is not set
# CONFIG_ARCH_S5PC1XX is not set
# CONFIG_ARCH_HIGHBANK is not set
# CONFIG_ARCH_INTEGRATOR is not set
# CONFIG_ARCH_IPQ40XX is not set
# CONFIG_ARCH_KEYSTONE is not set
# CONFIG_ARCH_K3 is not set
# CONFIG_ARCH_OMAP2PLUS is not set
# CONFIG_ARCH_MESON is not set
# CONFIG_ARCH_MEDIATEK is not set
# CONFIG_ARCH_LPC32XX is not set
# CONFIG_ARCH_IMX8 is not set
# CONFIG_ARCH_IMX8M is not set
# CONFIG_ARCH_IMXRT is not set
# CONFIG_ARCH_MX23 is not set
# CONFIG_ARCH_MX25 is not set
# CONFIG_ARCH_MX28 is not set
# CONFIG_ARCH_MX31 is not set
# CONFIG_ARCH_MX7ULP is not set
# CONFIG_ARCH_MX7 is not set
# CONFIG_ARCH_MX6 is not set
CONFIG_SPL_LDSCRIPT="arch/$(ARCH)/cpu/u-boot-spl.lds"
# CONFIG_ARCH_MX5 is not set
# CONFIG_ARCH_NEXELL is not set
# CONFIG_ARCH_OWL is not set
# CONFIG_ARCH_QEMU is not set
# CONFIG_ARCH_RMOBILE is not set
# CONFIG_TARGET_S32V234EVB is not set
# CONFIG_ARCH_SNAPDRAGON is not set
# CONFIG_ARCH_SOCFPGA is not set
# CONFIG_ARCH_SUNXI is not set
# CONFIG_ARCH_U8500 is not set
# CONFIG_ARCH_VERSAL is not set
# CONFIG_ARCH_VF610 is not set
# 

[PATCH 1/1] efi_loader: remove EFI_HII_CONFIG_ROUTING_PROTOCOL

[Heinrich Schuchardt]

Our implementation of the EFI_HII_CONFIG_ROUTING_PROTOCOL is a mere stub,
where all services return an error code. The protocol is neither needed for
the EFI shell nor for the UEFI SCT. To reduce the code size remove it from
the U-Boot binary.

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/Makefile |  2 +-
 lib/efi_loader/efi_hii_config.c | 10 +++---
 lib/efi_loader/efi_root_node.c  |  3 ---
 3 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index 0afcaf4813..462d4d9ac4 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -30,7 +30,7 @@ obj-y += efi_device_path.o
 obj-$(CONFIG_EFI_DEVICE_PATH_TO_TEXT) += efi_device_path_to_text.o
 obj-y += efi_device_path_utilities.o
 obj-y += efi_file.o
-obj-$(CONFIG_EFI_LOADER_HII) += efi_hii.o efi_hii_config.o
+obj-$(CONFIG_EFI_LOADER_HII) += efi_hii.o
 obj-y += efi_image_loader.o
 obj-y += efi_memory.o
 obj-y += efi_root_node.o
diff --git a/lib/efi_loader/efi_hii_config.c b/lib/efi_loader/efi_hii_config.c
index 26ea4b9bc0..237e8acf84 100644
--- a/lib/efi_loader/efi_hii_config.c
+++ b/lib/efi_loader/efi_hii_config.c
@@ -1,9 +1,13 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
- *  EFI Human Interface Infrastructure ... Configuration
+ * EFI Human Interface Infrastructure ... Configuration
  *
- *  Copyright (c) 2017 Leif Lindholm
- *  Copyright (c) 2018 AKASHI Takahiro, Linaro Limited
+ * Copyright (c) 2017 Leif Lindholm
+ * Copyright (c) 2018 AKASHI Takahiro, Linaro Limited
+ *
+ * As this is still a non-working stub and the protocol is neither required
+ * by the EFI shell nor by the UEFI SCT this module has been removed from
+ * the Makefile.
  */

 #include 
diff --git a/lib/efi_loader/efi_root_node.c b/lib/efi_loader/efi_root_node.c
index f68b0fdc61..b17db312f7 100644
--- a/lib/efi_loader/efi_root_node.c
+++ b/lib/efi_loader/efi_root_node.c
@@ -77,9 +77,6 @@ efi_status_t efi_root_node_register(void)
 /* HII database protocol */
 &efi_guid_hii_database_protocol,
 (void *)&efi_hii_database,
-/* HII configuration routing protocol */
-&efi_guid_hii_config_routing_protocol,
-(void *)&efi_hii_config_routing,
 #endif
 NULL));
efi_root->type = EFI_OBJECT_TYPE_U_BOOT_FIRMWARE;
--
2.29.2

[PATCH] mmc: meson-gx: change clock phase value on AGX SoCs

[Stefan Agner]

Amlogic AGX SoCs seem to have issue communicating with some eMMC
devices (in particular with a Micron 128GB eMMC 5.1). The device
is detected with 1-bit bus width, and at higher temperature loading
pretty much anything from the storage fails: (e.g. fs_devread read error
- block).

When phase is set to 270° it is detected with 8-bit bus width and is
working fine accross all temperatures.

Signed-off-by: Stefan Agner 
---
Hi Neil,

I debugged this issue today on an ODROID N2+ not booting reliably. I am
not sure if we can safely switch to 270° for all SoCs with
amlogic,meson-axg-mmc, but I guess we have to try and see what happens?
I will do a bit broader testing in the comming days here.

Btw, I do see that 180° is also set in Linux. Do you have a patch to
address this in Linux?

--
Stefan


 arch/arm/include/asm/arch-meson/sd_emmc.h | 1 +
 drivers/mmc/meson_gx_mmc.c| 9 +
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/arm/include/asm/arch-meson/sd_emmc.h 
b/arch/arm/include/asm/arch-meson/sd_emmc.h
index cb16f75fc6..db5e058098 100644
--- a/arch/arm/include/asm/arch-meson/sd_emmc.h
+++ b/arch/arm/include/asm/arch-meson/sd_emmc.h
@@ -14,6 +14,7 @@
 
 enum meson_gx_mmc_compatible {
MMC_COMPATIBLE_GX,
+   MMC_COMPATIBLE_AGX,
MMC_COMPATIBLE_SM1,
 };
 
diff --git a/drivers/mmc/meson_gx_mmc.c b/drivers/mmc/meson_gx_mmc.c
index 5facbfdd9a..2c27113c10 100644
--- a/drivers/mmc/meson_gx_mmc.c
+++ b/drivers/mmc/meson_gx_mmc.c
@@ -64,14 +64,15 @@ static void meson_mmc_config_clock(struct mmc *mmc)
 
/*
 * SM1 SoCs doesn't work fine over 50MHz with CLK_CO_PHASE_180
+* AGX SoCs don't work reliable with some eMMCs with CLK_CO_PHASE_180
 * If CLK_CO_PHASE_270 is used, it's more stable than other.
 * Other SoCs use CLK_CO_PHASE_180 by default.
 * It needs to find what is a proper value about each SoCs.
 */
-   if (meson_gx_mmc_is_compatible(mmc->dev, MMC_COMPATIBLE_SM1))
-   meson_mmc_clk |= CLK_CO_PHASE_270;
-   else
+   if (meson_gx_mmc_is_compatible(mmc->dev, MMC_COMPATIBLE_GX))
meson_mmc_clk |= CLK_CO_PHASE_180;
+   else
+   meson_mmc_clk |= CLK_CO_PHASE_270;
 
/* 180 phase tx clock */
meson_mmc_clk |= CLK_TX_PHASE_000;
@@ -327,7 +328,7 @@ int meson_mmc_bind(struct udevice *dev)
 
 static const struct udevice_id meson_mmc_match[] = {
{ .compatible = "amlogic,meson-gx-mmc", .data = MMC_COMPATIBLE_GX },
-   { .compatible = "amlogic,meson-axg-mmc", .data = MMC_COMPATIBLE_GX },
+   { .compatible = "amlogic,meson-axg-mmc", .data = MMC_COMPATIBLE_AGX },
{ .compatible = "amlogic,meson-sm1-mmc", .data = MMC_COMPATIBLE_SM1 },
{ /* sentinel */ }
 };
-- 
2.29.2

Re: [PATCH 2/3] image-cipher: Fix FIT_CIPHER linking

[Philippe REYNES]

Hi Joel,

sorry for this very late answer ..


This patch fix this issue when only the ciphering is enabled.
But it breaks the compilation when signature and ciphering are
enabled, because both functions image_set_host_blob and
image_get_host_blob are defined twice.
So it is a NAK for me.

A simple way to fix it to move this block of code from image-fit-sig.c 
to iamge-fit.c


Regards,
Philippe


Le 11/11/2020 à 12:18, Joel Stanley a écrit :

When CONFIG_FIT_CIPHER=y and CONFIG_FIT_SIGNATURE=n is there is no
implementation of image_get_host_blob for mkimage or dumpimage:

  /usr/bin/ld: tools/common/image-cipher.o: in function 
`fit_image_decrypt_data':
  image-cipher.c:(.text+0x9a): undefined reference to `image_get_host_blob'

The implementation is the same as common/image-fit-sig.c.

Signed-off-by: Joel Stanley 
---
  common/image-cipher.c | 14 ++
  1 file changed, 14 insertions(+)

diff --git a/common/image-cipher.c b/common/image-cipher.c
index 4ca9eec4ef15..fcbbceb847a5 100644
--- a/common/image-cipher.c
+++ b/common/image-cipher.c
@@ -15,6 +15,20 @@ DECLARE_GLOBAL_DATA_PTR;
  #include 
  #include 
  
+#ifdef USE_HOSTCC

+void *host_blob;
+
+void image_set_host_blob(void *blob)
+{
+   host_blob = blob;
+}
+
+void *image_get_host_blob(void)
+{
+   return host_blob;
+}
+#endif
+
  struct cipher_algo cipher_algos[] = {
{
.name = "aes128",

Re: [PATCH 1/3] tools/Makefile: FIT_CIPHER requires libssl

[Philippe REYNES]

Hi Joel,
Sorry, for this very late answer.


Le 11/11/2020 à 12:18, Joel Stanley a écrit :

If CONFIG_FIT_CIPHER=y and CONFIG_FIT_SIGNATURE=n then mkimage and
dumpimage will fail to link:

  /usr/bin/ld: tools/common/image-cipher.o: in function 
`fit_image_decrypt_data':
  image-cipher.c:(.text+0x9a): undefined reference to `image_get_host_blob'
  /usr/bin/ld: tools/common/image-cipher.o:(.data.rel+0x10): undefined 
reference to `EVP_aes_128_cbc'
  /usr/bin/ld: tools/common/image-cipher.o:(.data.rel+0x40): undefined 
reference to `EVP_aes_192_cbc'
  /usr/bin/ld: tools/common/image-cipher.o:(.data.rel+0x70): undefined 
reference to `EVP_aes_256_cbc'
  /usr/bin/ld: tools/lib/aes/aes-encrypt.o: in function `image_aes_encrypt':
  aes-encrypt.c:(.text+0x22): undefined reference to `EVP_CIPHER_CTX_new'
  /usr/bin/ld: aes-encrypt.c:(.text+0x6f): undefined reference to 
`EVP_EncryptInit_ex'
  /usr/bin/ld: aes-encrypt.c:(.text+0x8d): undefined reference to 
`EVP_EncryptUpdate'
  /usr/bin/ld: aes-encrypt.c:(.text+0xac): undefined reference to 
`EVP_CIPHER_CTX_free'
  /usr/bin/ld: aes-encrypt.c:(.text+0xf2): undefined reference to 
`EVP_EncryptFinal_ex'
  collect2: error: ld returned 1 exit status

Signed-off-by: Joel Stanley 

Reviewed-by: Philippe Reynes 

---
  tools/Makefile | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/Makefile b/tools/Makefile
index 51123fd92983..103b3ab8a7f2 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -154,7 +154,7 @@ HOSTCFLAGS_kwbimage.o += -DCONFIG_KWB_SECURE
  endif
  
  # MXSImage needs LibSSL

-ifneq 
($(CONFIG_MX23)$(CONFIG_MX28)$(CONFIG_ARMADA_38X)$(CONFIG_ARMADA_39X)$(CONFIG_FIT_SIGNATURE),)
+ifneq 
($(CONFIG_MX23)$(CONFIG_MX28)$(CONFIG_ARMADA_38X)$(CONFIG_ARMADA_39X)$(CONFIG_FIT_SIGNATURE)$(CONFIG_FIT_CIPHER),)
  HOSTCFLAGS_kwbimage.o += \
$(shell pkg-config --cflags libssl libcrypto 2> /dev/null || echo "")
  HOSTLDLIBS_mkimage += \


Regards,
Philippe

RE: [PATCH v2 1/3] MAINTAINERS: Update ARM STI and ARM STM STM32MP Arch maintainers emails

[Patrick DELAUNAY]

Hi Patrice,

> From: Patrice CHOTARD - foss 
> Sent: mercredi 2 décembre 2020 18:47
> 
> Update Patrick and my email address with the one dedicated to upstream
> activities.
> 
> Signed-off-by: Patrice Chotard 
> ---
> 
> (no changes since v1)
> 
>  MAINTAINERS | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 874cf2c0e5..ed5d7c3ab6 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -385,7 +385,7 @@ F:drivers/smem/msm_smem.c
>  F:   drivers/usb/host/ehci-msm.c
> 
>  ARM STI
> -M:   Patrice Chotard 
> +M:   Patrice Chotard 
>  S:   Maintained
>  T:   git https://gitlab.denx.de/u-boot/custodians/u-boot-stm.git
>  F:   arch/arm/mach-sti/
> @@ -411,8 +411,8 @@ F:arch/arm/cpu/arm926ejs/spear/
>  F:   arch/arm/include/asm/arch-spear/
> 
>  ARM STM STM32MP
> -M:   Patrick Delaunay 
> -M:   Patrice Chotard 
> +M:   Patrick Delaunay 
> +M:   Patrice Chotard 
>  L:   uboot-st...@st-md-mailman.stormreply.com (moderated for non-
> subscribers)
>  T:   git https://gitlab.denx.de/u-boot/custodians/u-boot-stm.git
>  S:   Maintained
> --
> 2.17.1

Reviewed-by: Patrick Delaunay 

Thanks

Patrick

RE: [PATCH v2 2/3] treewide: Update email address Patrick Delaunay and Patrice Chotard

[Patrick DELAUNAY]

Hi Patrice,

> From: Patrice CHOTARD - foss 
> Sent: mercredi 2 décembre 2020 18:48
> 
> Update Patrick and my email address with the one dedicated to upstream
> activities.
> 
> Signed-off-by: Patrice Chotard 
> ---
> 
> (no changes since v1)
> 
>  arch/arm/include/asm/arch-stih410/sdhci.h| 2 +-
>  arch/arm/include/asm/arch-stih410/sys_proto.h| 2 +-
>  arch/arm/include/asm/arch-stm32/stm32f.h | 2 +-
>  arch/arm/include/asm/arch-stm32f4/stm32_pwr.h| 2 +-
>  arch/arm/include/asm/arch-stm32f7/stm32_pwr.h| 2 +-
>  arch/arm/include/asm/arch-stm32h7/gpio.h | 2 +-
>  arch/arm/include/asm/arch-stm32h7/stm32.h| 2 +-
>  arch/arm/mach-stm32/soc.c| 2 +-
>  board/st/stih410-b2260/board.c   | 2 +-
>  board/st/stm32f429-evaluation/stm32f429-evaluation.c | 2 +-
>  board/st/stm32f469-discovery/stm32f469-discovery.c   | 2 +-
>  board/st/stm32h743-disco/stm32h743-disco.c   | 2 +-
>  board/st/stm32h743-eval/stm32h743-eval.c | 2 +-
>  drivers/clk/clk_stm32h7.c| 2 +-
>  drivers/misc/stm32_rcc.c | 2 +-
>  drivers/mmc/sti_sdhci.c  | 2 +-
>  drivers/mmc/stm32_sdmmc2.c   | 2 +-
>  drivers/phy/sti_usb_phy.c| 2 +-
>  drivers/pinctrl/pinctrl-sti.c| 2 +-
>  drivers/reset/sti-reset.c| 2 +-
>  drivers/reset/stm32-reset.c  | 2 +-
>  drivers/serial/serial_sti_asc.c  | 2 +-
>  drivers/sysreset/sysreset_sti.c  | 2 +-
>  drivers/timer/sti-timer.c| 2 +-
>  drivers/timer/stm32_timer.c  | 2 +-
>  drivers/usb/host/dwc3-sti-glue.c | 2 +-
>  drivers/video/backlight_gpio.c   | 2 +-
>  include/configs/stih410-b2260.h  | 2 +-
>  include/configs/stm32f429-evaluation.h   | 2 +-
>  include/configs/stm32f469-discovery.h| 2 +-
>  include/configs/stm32h743-disco.h| 2 +-
>  include/configs/stm32h743-eval.h | 2 +-
>  include/dwc3-sti-glue.h  | 2 +-
>  include/stm32_rcc.h  | 2 +-
>  34 files changed, 34 insertions(+), 34 deletions(-)
> 

Reviewed-by: Patrick Delaunay 

Thanks

Patrick

RE: [PATCH v2 3/3] .mailmap: map Patrick Delaunay and my email address

[Patrick DELAUNAY]

Hi Patrice,

> From: Patrice CHOTARD - foss 
> Sent: mercredi 2 décembre 2020 18:48
> To: u-boot@lists.denx.de
> 
> Add our new email address dedicated for upstream activities.
> 
> Signed-off-by: Patrice Chotard 
> 
> ---
> 
> Changes in v2:
>   - Add .mailmap update
> 
>  .mailmap | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/.mailmap b/.mailmap
> index 8250015453..33001f1e01 100644
> --- a/.mailmap
> +++ b/.mailmap
> @@ -31,6 +31,8 @@ Jagan Teki   Jagan Teki
> 
>  Igor OpaniukMarkus
> Klotzbuecher 
> +Patrice Chotard  
> +Patrick Delaunay 
> +
>  Paul BurtonPrabhakar
> Kushwaha   Rajeshwari Shinde
> 
> --
> 2.17.1

Reviewed-by: Patrick Delaunay 

Thanks

Patrick

Re: Pull request, u-boot-tegra/master

[Tom Rini]

On Fri, Dec 04, 2020 at 03:47:00PM -0700, Tom Warren wrote:

>  Tom,
> 
> Please pull u-boot-tegra/master into U-Boot/master. Thanks.
> 
> All Tegra builds are OK on my system, and Stephen's test frame reports that
> all tests pass.
> 
> The following changes since commit ee1e04558ff8c8ed812b986939447f129bb0b0bb:
> 
>   Merge branch '2020-12-02-master-imports' (2020-12-03 09:43:47 -0500)
> 
> are available in the git repository at:
> 
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-tegra.git
> 
> for you to fetch changes up to 4f5128ff899d0cb13a7b010f6dbffd0aba71bb25:
> 
>   configs: cei-tk1-som: remove CONFIG_ARMV7_PSCI in include file
> (2020-12-04 13:39:15 -0700)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [u-boot, v1 1/1] mtd: spi-nor-ids: add STMICRO MT25QL01G flash

[Patrice CHOTARD]

Hi Hongwei

On 12/4/20 11:06 PM, Hongwei Zhang wrote:
> Add STMICRO MT25QL01G flash, used on AST2600 board.

MT25QL01G is not a STMicroelectronics flash but a Micron one ;-)

Patrice


>
> Signed-off-by: Hongwei Zhang 
> ---
>  drivers/mtd/spi/spi-nor-ids.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
> index 09e8196048..6d22b80586 100644
> --- a/drivers/mtd/spi/spi-nor-ids.c
> +++ b/drivers/mtd/spi/spi-nor-ids.c
> @@ -185,6 +185,7 @@ const struct flash_info spi_nor_ids[] = {
>   { INFO("n25q512ax3",  0x20ba20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR | 
> SPI_NOR_QUAD_READ) },
>   { INFO("n25q00",  0x20ba21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR | 
> SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
>   { INFO("n25q00a", 0x20bb21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR | 
> SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
> + { INFO("mt25ql01g",   0x21ba20, 0, 64 * 1024, 2048, SECT_4K | USE_FSR | 
> SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
>   { INFO("mt25qu02g",   0x20bb22, 0, 64 * 1024, 4096, SECT_4K | USE_FSR | 
> SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
>   { INFO("mt35xu512aba", 0x2c5b1a, 0,  128 * 1024,  512, USE_FSR | 
> SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES) },
>   { INFO("mt35xu02g",  0x2c5b1c, 0, 128 * 1024,  2048, USE_FSR | 
> SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES) },

Re: [PATCH] spl: fit: Prefer a malloc()'d buffer for loading images

[Alex G.]

On 11/3/20 9:11 AM, Simon Glass wrote:

+Tom Rini too


ping?

Alex


On Wed, 21 Oct 2020 at 17:33, Alexandru Gagniuc  wrote:


Fit images were loaded to a buffer provided by spl_get_load_buffer().
This may work when the FIT image is small and fits between the start
of DRAM and SYS_TEXT_BASE.

One problem with this approach is that the location of the buffer may
be manipulated by changing the 'size' field of the FIT. A maliciously
crafted FIT image could place the buffer over executable code and be
able to take control of SPL. This is unacceptable for secure boot of
signed FIT images.

Another problem is with larger FIT images, usually containing one or
more linux kernels. In such cases the buffer be be large enough so as
to start before DRAM (Figure I). Trying to load an image in this case
has undefined behavior.
For example, on stm32mp1, the MMC controller hits a RX overrun error,
and aborts loading.
 _
|FIT Image|
| |
   /===\/=\
   ||  DRAM   |||DRAM |
   || ||| |
   ||_||  SYS_TEXT_BASE | ___ |
   |   ||| FIT Image ||
   |   |||   ||
   | _ |  SYS_SPL_MALLOC_START  || _ ||
   ||  malloc() data  |||||  malloc() data  |||
   ||_|||||_|||
   |   |||___||
   |   || |

 Figure I   Figure II

One possibility that was analyzed was to remove the negative offset,
such that the buffer starts at SYS_TEXT_BASE. This is not a proper
solution because on a number of platforms, the malloc buffer() is
placed at a fixed address, usually after SYS_TEXT_BASE. A large
enough FIT image could cause the malloc()'d data to be overwritten
(Figure II) when loading.

   /==\
   |DRAM  |
   |  |
   |  |   CONFIG_SYS_TEXT_BASE
   |  |
   |  |
   |  |   CONFIG_SYS_SPL_MALLOC_START
   ||   malloc() data||
   ||||
   || __ ||
   |||FIT Image |||
   |||  |||
   |||  |||

  Figure III

The solution proposed here is to replace the ad-hoc heuristics of
spl_get_load_buffer() with malloc(). This provides two advantages:
 * Bounds checking of the buffer region
 * Guarantees the buffer does not conflict with other memory

The first problem is solved by constraining the buffer such that it
will not overlap currently executing code. This eliminates the chance
of a malicious FIT being able to replace the executing SPL code prior
to signature checking.

The second problem is solved in conjunction with increasing
CONFIG_SYS_SPL_MALLOC_SIZE. Since the SPL malloc() region is
carefully crafted on a per-platform basis, the chances of memory
conflicts are virtually eliminated.

Signed-off-by: Alexandru Gagniuc 
---

Contingency plan:

If the malloc() fails, the backup plan is to use spl_get_load_buffer()
with the negative offset eliminated. This puts the buffer at
CONFIG_SYS_TEXT_BASE as a final measure. We can't use the negative
offset because that would re-introduce the first prooblem.

Expected fallout:

This only affects the FIT image loading path, so no breakage is
expected for default configurations. Most configs have a sufficiently
large SYS_SPL_MALLOC_SIZE, with the most common value at 1 MB. This
adequate for the majority of u-boot FIT images.

No significant breakage is expected.


  common/spl/spl_fit.c | 37 ++---
  1 file changed, 22 insertions(+), 15 deletions(-)

diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index a90d821c82..98a7531f72 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -472,6 +472,23 @@ static int spl_fit_image_get_os(const void *fit, int 
noffset, uint8_t *os)
  #endif
  }

+/*
+ * The purpose of the FIT load buffer is to provide a memory location that is
+ * independent of the load address of any FIT component.
+ */
+static void *spl_get_fit_load_buffer(size_t size)
+{
+   void *buf;
+
+   buf = malloc(size);
+   if (!buf) {
+   pr_err("Could not get FIT buffer of %lu bytes\n", (ulong)size);
+   pr_err("\tcheck CONFIG_SYS_SPL_MALLOC_SIZE\n");
+   buf = spl_get_load_buffer(0, size);
+   }
+   return buf;
+}
+
  /*
   * Weak default function to all

[PATCH v4 1/2] arm: dts: add imx8mm-cl-iot-gate dts file

[Ying-Chun Liu]

From: "Ying-Chun Liu (PaulLiu)" 

Add board dts for imx8mm-cl-iot-gate

Signed-off-by: Kirill Kapranov 
Signed-off-by: Uri Mashiach 
Signed-off-by: Valentin Raevsky 
Signed-off-by: Ying-Chun Liu (PaulLiu) 
Cc: Peter Robinson 
---
v2: Rename iot-gate-imx8 -> imx8mm-cl-iot-gate
v4: Re-sent for adding changelog
---
 arch/arm/dts/Makefile   |   2 +
 arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi | 131 +
 arch/arm/dts/imx8mm-cl-iot-gate.dts | 550 
 3 files changed, 683 insertions(+)
 create mode 100644 arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx8mm-cl-iot-gate.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index e2e8a5fb7a..d00ecb88e0 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1003,6 +1003,8 @@ dtb-$(CONFIG_TARGET_DURIAN) += phytium-durian.dtb
 
 dtb-$(CONFIG_TARGET_PRESIDIO_ASIC) += ca-presidio-engboard.dtb
 
+dtb-$(CONFIG_TARGET_IMX8MM_CL_IOT_GATE) += imx8mm-cl-iot-gate.dtb
+
 targets += $(dtb-y)
 
 # Add any required device tree compiler flags here
diff --git a/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi 
b/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi
new file mode 100644
index 00..a36147eb11
--- /dev/null
+++ b/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi
@@ -0,0 +1,131 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2019 NXP
+ */
+
+/ {
+   wdt-reboot {
+   compatible = "wdt-reboot";
+   wdt = <&wdog1>;
+   u-boot,dm-spl;
+   };
+};
+
+&{/soc@0} {
+   u-boot,dm-pre-reloc;
+   u-boot,dm-spl;
+};
+
+&clk {
+   u-boot,dm-spl;
+   u-boot,dm-pre-reloc;
+   /delete-property/ assigned-clocks;
+   /delete-property/ assigned-clock-parents;
+   /delete-property/ assigned-clock-rates;
+};
+
+&osc_24m {
+   u-boot,dm-spl;
+   u-boot,dm-pre-reloc;
+};
+
+&aips1 {
+   u-boot,dm-spl;
+   u-boot,dm-pre-reloc;
+};
+
+&aips2 {
+   u-boot,dm-spl;
+};
+
+&aips3 {
+   u-boot,dm-spl;
+};
+
+&iomuxc {
+   u-boot,dm-spl;
+};
+
+&pinctrl_reg_usdhc2_vmmc {
+   u-boot,dm-spl;
+};
+
+&pinctrl_uart3 {
+   u-boot,dm-spl;
+};
+
+&pinctrl_usdhc2_gpio {
+   u-boot,dm-spl;
+};
+
+&pinctrl_usdhc2 {
+   u-boot,dm-spl;
+};
+
+&pinctrl_usdhc3 {
+   u-boot,dm-spl;
+};
+
+&gpio1 {
+   u-boot,dm-spl;
+};
+
+&gpio2 {
+   u-boot,dm-spl;
+};
+
+&gpio3 {
+   u-boot,dm-spl;
+};
+
+&gpio4 {
+   u-boot,dm-spl;
+};
+
+&gpio5 {
+   u-boot,dm-spl;
+};
+
+&uart3 {
+   u-boot,dm-spl;
+};
+
+&usdhc1 {
+   u-boot,dm-spl;
+};
+
+&usdhc2 {
+   u-boot,dm-spl;
+};
+
+&usdhc3 {
+   u-boot,dm-spl;
+};
+
+&i2c2 {
+   u-boot,dm-spl;
+};
+
+&{/soc@0/bus@3080/i2c@30a3/pmic@4b} {
+   u-boot,dm-spl;
+};
+
+&{/soc@0/bus@3080/i2c@30a3/pmic@4b/regulators} {
+   u-boot,dm-spl;
+};
+
+&pinctrl_i2c2 {
+   u-boot,dm-spl;
+};
+
+&pinctrl_pmic {
+   u-boot,dm-spl;
+};
+
+&fec1 {
+   phy-reset-gpios = <&gpio4 22 GPIO_ACTIVE_LOW>;
+};
+
+&wdog1 {
+   u-boot,dm-spl;
+};
diff --git a/arch/arm/dts/imx8mm-cl-iot-gate.dts 
b/arch/arm/dts/imx8mm-cl-iot-gate.dts
new file mode 100644
index 00..82e9c0f40b
--- /dev/null
+++ b/arch/arm/dts/imx8mm-cl-iot-gate.dts
@@ -0,0 +1,550 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2019 NXP
+ */
+
+/dts-v1/;
+
+#include 
+#include "imx8mm.dtsi"
+
+/ {
+   model = "CompuLab IOT-GATE-iMX8";
+   compatible = "sb-iotgimx8", "cpl,ucm-imx8m-mini", "fsl,imx8mm-evk", 
"fsl,imx8mm";
+
+   chosen {
+   bootargs = "console=ttymxc2,115200 
earlycon=ec_imx6q,0x3088,115200";
+   stdout-path = &uart3;
+   };
+
+   reg_vusb_5v: regulator-usdhc2 {
+   compatible = "regulator-fixed";
+   regulator-name = "VUSB_5V";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = <&gpio4 28 GPIO_ACTIVE_HIGH>;
+   regulator-boot-on;
+   enable-active-high;
+   };
+
+   reg_usdhc2_vqmmc: regulator-usdhc2_1v8 {
+   compatible = "regulator-fixed";
+   regulator-name = "usdhc2_1v8";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-always-on;
+   };
+
+   reg_usdhc2_vmmc: regulator-usdhc2-vmmc {
+   compatible = "regulator-fixed";
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_reg_usdhc2_vmmc>;
+   regulator-name = "VSD_3V3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   gpio = <&gpio2 19 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   startup-delay-us = <100>;
+   off-on-delay-us = <12000>;
+   };
+};
+
+&A53_0 {
+   cpu-supply = <&buck2_reg>;
+};
+
+&fec1 {

[PATCH v4 0/2] arm: imx8m: add support for Compulab iot-gate-imx8 (imx8mm-cl-iot-gate)

[Ying-Chun Liu]

From: "Ying-Chun Liu (PaulLiu)" 

Add initial support for Compulab iot-gate-imx8 board (imx8mm-cl-iot-gate).
The initial support includes:
 - MMC
 - eMMC
 - I2C
 - FEC
 - Serial console

Ying-Chun Liu (PaulLiu) (2):
  arm: dts: add imx8mm-cl-iot-gate dts file
  arm: imx8m: add support for Compulab iot-gate-imx8
(imx8mm-cl-iot-gate)

v2: Rename iot-gate-imx8 -> imx8mm-cl-iot-gate
v3: Use distro_bootcmd.
v4: Re-sent for adding changelog

 arch/arm/dts/Makefile |2 +
 arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi   |  131 ++
 arch/arm/dts/imx8mm-cl-iot-gate.dts   |  550 +
 arch/arm/mach-imx/imx8m/Kconfig   |8 +
 board/compulab/imx8mm-cl-iot-gate/Kconfig |   12 +
 board/compulab/imx8mm-cl-iot-gate/MAINTAINERS |6 +
 board/compulab/imx8mm-cl-iot-gate/Makefile|   13 +
 .../compulab/imx8mm-cl-iot-gate/ddr/Makefile  |8 +
 board/compulab/imx8mm-cl-iot-gate/ddr/ddr.c   |  211 ++
 board/compulab/imx8mm-cl-iot-gate/ddr/ddr.h   |   26 +
 .../ddr/lpddr4_timing_01061010.1_2.c  | 1848 +
 .../ddr/lpddr4_timing_01061010.c  | 1847 
 .../ddr/lpddr4_timing_ff000110.c  | 1847 
 .../ddr/lpddr4_timing_ff020008.c  | 1847 
 .../imx8mm-cl-iot-gate/imx8mm-cl-iot-gate.c   |   69 +
 board/compulab/imx8mm-cl-iot-gate/spl.c   |  187 ++
 configs/imx8mm-cl-iot-gate_defconfig  |  130 ++
 include/configs/imx8mm-cl-iot-gate.h  |  190 ++
 18 files changed, 8932 insertions(+)
 create mode 100644 arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx8mm-cl-iot-gate.dts
 create mode 100644 board/compulab/imx8mm-cl-iot-gate/Kconfig
 create mode 100644 board/compulab/imx8mm-cl-iot-gate/MAINTAINERS
 create mode 100644 board/compulab/imx8mm-cl-iot-gate/Makefile
 create mode 100644 board/compulab/imx8mm-cl-iot-gate/ddr/Makefile
 create mode 100644 board/compulab/imx8mm-cl-iot-gate/ddr/ddr.c
 create mode 100644 board/compulab/imx8mm-cl-iot-gate/ddr/ddr.h
 create mode 100644 
board/compulab/imx8mm-cl-iot-gate/ddr/lpddr4_timing_01061010.1_2.c
 create mode 100644 
board/compulab/imx8mm-cl-iot-gate/ddr/lpddr4_timing_01061010.c
 create mode 100644 
board/compulab/imx8mm-cl-iot-gate/ddr/lpddr4_timing_ff000110.c
 create mode 100644 
board/compulab/imx8mm-cl-iot-gate/ddr/lpddr4_timing_ff020008.c
 create mode 100644 board/compulab/imx8mm-cl-iot-gate/imx8mm-cl-iot-gate.c
 create mode 100644 board/compulab/imx8mm-cl-iot-gate/spl.c
 create mode 100644 configs/imx8mm-cl-iot-gate_defconfig
 create mode 100644 include/configs/imx8mm-cl-iot-gate.h

-- 
2.29.2

[PATCH v3 1/2] arm: dts: add imx8mm-cl-iot-gate dts file

[Ying-Chun Liu]

From: "Ying-Chun Liu (PaulLiu)" 

Add board dts for imx8mm-cl-iot-gate

Signed-off-by: Kirill Kapranov 
Signed-off-by: Uri Mashiach 
Signed-off-by: Valentin Raevsky 
Signed-off-by: Ying-Chun Liu (PaulLiu) 
Cc: Peter Robinson 
---
 arch/arm/dts/Makefile   |   2 +
 arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi | 131 +
 arch/arm/dts/imx8mm-cl-iot-gate.dts | 550 
 3 files changed, 683 insertions(+)
 create mode 100644 arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx8mm-cl-iot-gate.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index e2e8a5fb7a..d00ecb88e0 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1003,6 +1003,8 @@ dtb-$(CONFIG_TARGET_DURIAN) += phytium-durian.dtb
 
 dtb-$(CONFIG_TARGET_PRESIDIO_ASIC) += ca-presidio-engboard.dtb
 
+dtb-$(CONFIG_TARGET_IMX8MM_CL_IOT_GATE) += imx8mm-cl-iot-gate.dtb
+
 targets += $(dtb-y)
 
 # Add any required device tree compiler flags here
diff --git a/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi 
b/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi
new file mode 100644
index 00..a36147eb11
--- /dev/null
+++ b/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi
@@ -0,0 +1,131 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2019 NXP
+ */
+
+/ {
+   wdt-reboot {
+   compatible = "wdt-reboot";
+   wdt = <&wdog1>;
+   u-boot,dm-spl;
+   };
+};
+
+&{/soc@0} {
+   u-boot,dm-pre-reloc;
+   u-boot,dm-spl;
+};
+
+&clk {
+   u-boot,dm-spl;
+   u-boot,dm-pre-reloc;
+   /delete-property/ assigned-clocks;
+   /delete-property/ assigned-clock-parents;
+   /delete-property/ assigned-clock-rates;
+};
+
+&osc_24m {
+   u-boot,dm-spl;
+   u-boot,dm-pre-reloc;
+};
+
+&aips1 {
+   u-boot,dm-spl;
+   u-boot,dm-pre-reloc;
+};
+
+&aips2 {
+   u-boot,dm-spl;
+};
+
+&aips3 {
+   u-boot,dm-spl;
+};
+
+&iomuxc {
+   u-boot,dm-spl;
+};
+
+&pinctrl_reg_usdhc2_vmmc {
+   u-boot,dm-spl;
+};
+
+&pinctrl_uart3 {
+   u-boot,dm-spl;
+};
+
+&pinctrl_usdhc2_gpio {
+   u-boot,dm-spl;
+};
+
+&pinctrl_usdhc2 {
+   u-boot,dm-spl;
+};
+
+&pinctrl_usdhc3 {
+   u-boot,dm-spl;
+};
+
+&gpio1 {
+   u-boot,dm-spl;
+};
+
+&gpio2 {
+   u-boot,dm-spl;
+};
+
+&gpio3 {
+   u-boot,dm-spl;
+};
+
+&gpio4 {
+   u-boot,dm-spl;
+};
+
+&gpio5 {
+   u-boot,dm-spl;
+};
+
+&uart3 {
+   u-boot,dm-spl;
+};
+
+&usdhc1 {
+   u-boot,dm-spl;
+};
+
+&usdhc2 {
+   u-boot,dm-spl;
+};
+
+&usdhc3 {
+   u-boot,dm-spl;
+};
+
+&i2c2 {
+   u-boot,dm-spl;
+};
+
+&{/soc@0/bus@3080/i2c@30a3/pmic@4b} {
+   u-boot,dm-spl;
+};
+
+&{/soc@0/bus@3080/i2c@30a3/pmic@4b/regulators} {
+   u-boot,dm-spl;
+};
+
+&pinctrl_i2c2 {
+   u-boot,dm-spl;
+};
+
+&pinctrl_pmic {
+   u-boot,dm-spl;
+};
+
+&fec1 {
+   phy-reset-gpios = <&gpio4 22 GPIO_ACTIVE_LOW>;
+};
+
+&wdog1 {
+   u-boot,dm-spl;
+};
diff --git a/arch/arm/dts/imx8mm-cl-iot-gate.dts 
b/arch/arm/dts/imx8mm-cl-iot-gate.dts
new file mode 100644
index 00..82e9c0f40b
--- /dev/null
+++ b/arch/arm/dts/imx8mm-cl-iot-gate.dts
@@ -0,0 +1,550 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2019 NXP
+ */
+
+/dts-v1/;
+
+#include 
+#include "imx8mm.dtsi"
+
+/ {
+   model = "CompuLab IOT-GATE-iMX8";
+   compatible = "sb-iotgimx8", "cpl,ucm-imx8m-mini", "fsl,imx8mm-evk", 
"fsl,imx8mm";
+
+   chosen {
+   bootargs = "console=ttymxc2,115200 
earlycon=ec_imx6q,0x3088,115200";
+   stdout-path = &uart3;
+   };
+
+   reg_vusb_5v: regulator-usdhc2 {
+   compatible = "regulator-fixed";
+   regulator-name = "VUSB_5V";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = <&gpio4 28 GPIO_ACTIVE_HIGH>;
+   regulator-boot-on;
+   enable-active-high;
+   };
+
+   reg_usdhc2_vqmmc: regulator-usdhc2_1v8 {
+   compatible = "regulator-fixed";
+   regulator-name = "usdhc2_1v8";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-always-on;
+   };
+
+   reg_usdhc2_vmmc: regulator-usdhc2-vmmc {
+   compatible = "regulator-fixed";
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_reg_usdhc2_vmmc>;
+   regulator-name = "VSD_3V3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   gpio = <&gpio2 19 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   startup-delay-us = <100>;
+   off-on-delay-us = <12000>;
+   };
+};
+
+&A53_0 {
+   cpu-supply = <&buck2_reg>;
+};
+
+&fec1 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_fec1>;
+   phy-

[PATCH v3 0/2] add support for Compulab iot-gate-imx8

[Ying-Chun Liu]

From: "Ying-Chun Liu (PaulLiu)" 

Add initial support for Compulab iot-gate-imx8 board (imx8mm-cl-iot-gate).
The initial support includes:
 - MMC
 - eMMC
 - I2C
 - FEC
 - Serial console

Ying-Chun Liu (PaulLiu) (2):
  arm: dts: add imx8mm-cl-iot-gate dts file
  arm: imx8m: add support for Compulab iot-gate-imx8
(imx8mm-cl-iot-gate)

 arch/arm/dts/Makefile |2 +
 arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi   |  131 ++
 arch/arm/dts/imx8mm-cl-iot-gate.dts   |  550 +
 arch/arm/mach-imx/imx8m/Kconfig   |8 +
 board/compulab/imx8mm-cl-iot-gate/Kconfig |   12 +
 board/compulab/imx8mm-cl-iot-gate/MAINTAINERS |6 +
 board/compulab/imx8mm-cl-iot-gate/Makefile|   13 +
 .../compulab/imx8mm-cl-iot-gate/ddr/Makefile  |8 +
 board/compulab/imx8mm-cl-iot-gate/ddr/ddr.c   |  211 ++
 board/compulab/imx8mm-cl-iot-gate/ddr/ddr.h   |   26 +
 .../ddr/lpddr4_timing_01061010.1_2.c  | 1848 +
 .../ddr/lpddr4_timing_01061010.c  | 1847 
 .../ddr/lpddr4_timing_ff000110.c  | 1847 
 .../ddr/lpddr4_timing_ff020008.c  | 1847 
 .../imx8mm-cl-iot-gate/imx8mm-cl-iot-gate.c   |   69 +
 board/compulab/imx8mm-cl-iot-gate/spl.c   |  187 ++
 configs/imx8mm-cl-iot-gate_defconfig  |  130 ++
 include/configs/imx8mm-cl-iot-gate.h  |  190 ++
 18 files changed, 8932 insertions(+)
 create mode 100644 arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx8mm-cl-iot-gate.dts
 create mode 100644 board/compulab/imx8mm-cl-iot-gate/Kconfig
 create mode 100644 board/compulab/imx8mm-cl-iot-gate/MAINTAINERS
 create mode 100644 board/compulab/imx8mm-cl-iot-gate/Makefile
 create mode 100644 board/compulab/imx8mm-cl-iot-gate/ddr/Makefile
 create mode 100644 board/compulab/imx8mm-cl-iot-gate/ddr/ddr.c
 create mode 100644 board/compulab/imx8mm-cl-iot-gate/ddr/ddr.h
 create mode 100644 
board/compulab/imx8mm-cl-iot-gate/ddr/lpddr4_timing_01061010.1_2.c
 create mode 100644 
board/compulab/imx8mm-cl-iot-gate/ddr/lpddr4_timing_01061010.c
 create mode 100644 
board/compulab/imx8mm-cl-iot-gate/ddr/lpddr4_timing_ff000110.c
 create mode 100644 
board/compulab/imx8mm-cl-iot-gate/ddr/lpddr4_timing_ff020008.c
 create mode 100644 board/compulab/imx8mm-cl-iot-gate/imx8mm-cl-iot-gate.c
 create mode 100644 board/compulab/imx8mm-cl-iot-gate/spl.c
 create mode 100644 configs/imx8mm-cl-iot-gate_defconfig
 create mode 100644 include/configs/imx8mm-cl-iot-gate.h

-- 
2.29.2

Re: [PATCH] mtd: spi-nor-ids: Add SECT_4K to mx25l12805d

[Robert Marko]

On Fri, Oct 23, 2020 at 10:54 AM Jagan Teki  wrote:
>
> On Mon, Sep 14, 2020 at 7:04 PM Robert Marko  wrote:
> >
> > According to the mx25l12805d datasheet it supports using 4K or 64K sectors.
> > So lets add the SECT_4K to enable 4K sector usage.
> >
> > Datasheet: 
> > https://www.mxic.com.tw/Lists/Datasheet/Attachments/7321/MX25L12805D,%203V,%20128Mb,%20v1.2.pdf
> >
> > Signed-off-by: Robert Marko 
> > Cc: Luka Perkov 
> > ---
>
> Applied to u-boot-spi/master
Hi Jagan,
I am looking for the commit in u-boot-spi/master but am unable to find
it there or in the master U-boot.

Regards

Re: [PATCH 01/14] qemu: arm: Use the generated DTB only when CONGIG_OF_BOARD is defined

[Heinrich Schuchardt]

On 07.12.20 06:15, Sughosh Ganu wrote:
> hello Heinrich,
>
> On Sat, 5 Dec 2020 at 15:01, Heinrich Schuchardt  > wrote:
>
> On 11/26/20 7:40 PM, Sughosh Ganu wrote:
> > The Qemu platform emulator generates a device tree blob and places it
> > at the start of the dram, which is then used by u-boot. Use this dtb
> > only if CONFIG_OF_BOARD is defined. This allows using a different
> > device tree, using the CONFIG_OF_SEPARATE option. This dtb is attached
> > to the u-boot binary as a u-boot-fdt.bin file
>
> Dear Sughosh,
>
> thank your for this series which will allow us to better demonstrate and
> test capsule updates.
>
> I am not sure if the approach that you take at device-trees here is the
> right one.
>
> On QEMU the device-tree is generated on the fly by the QEMU binary
> depending on which devices the user has specified.
>
> Your idea is to replace this device-tree completely to be able to add
> extra elements (the EFI signature list, see patch 2/14). Thus a
> device-tree might be loaded that does not match the user selected
> devices.
>
> An alternative approach would be to apply all additions to the
> device-tree as an FDT overlay (or fixup). This would allow the dynamic
> parts of the QEMU device-tree still to be passed through.
>
>
> I will take a look at storing the public key as part of the fdt overlay,
> with a runtime fixup. Although, I think the issue that you are pointing
> to would be specific to Qemu and not other platforms. But I do see the
> merit in having the public-key certificate stored as part of an overlay.
> If I hit any issues while implementing this, I will get back to you. Thanks.
>
> -sughosh

OpenSBI can supply a device-tree to U-Boot. So this would be an
equivalent case.

Best regards

Heinrich

>
>
> Could you, please, assess the pros and cons of the two approaches with
> respect to:
>
> * usability for capsule updates
> * applicability for non-QEMU systems
> * integration of DTB overlays with FIT images for other use cases
>
> Best regards
>
> Heinrich
>
>
> >
> > Signed-off-by: Sughosh Ganu  >
> > ---
> >   board/emulation/qemu-arm/qemu-arm.c | 2 ++
> >   1 file changed, 2 insertions(+)
> >
> > diff --git a/board/emulation/qemu-arm/qemu-arm.c
> b/board/emulation/qemu-arm/qemu-arm.c
> > index f18f2ed7da..e146d1cc50 100644
> > --- a/board/emulation/qemu-arm/qemu-arm.c
> > +++ b/board/emulation/qemu-arm/qemu-arm.c
> > @@ -89,11 +89,13 @@ int dram_init_banksize(void)
> >       return 0;
> >   }
> >
> > +#if defined(CONFIG_OF_BOARD)
> >   void *board_fdt_blob_setup(void)
> >   {
> >       /* QEMU loads a generated DTB for us at the start of RAM. */
> >       return (void *)CONFIG_SYS_SDRAM_BASE;
> >   }
> > +#endif
> >
> >   void enable_caches(void)
> >   {
> >
>

Re: [BUG]odroid-c2 does not hotplug usb-devices

[Otto Meier]

Am 07.12.20 um 13:29 schrieb Neil Armstrong:

Hi,

(Please CC u-boot-amlo...@groups.io when U-Boot is concerned)

On 07/12/2020 13:19, Otto Meier wrote:

Hi Martin,


I did a lot of googling this weekend and found some interesting problems with
odroid-c2.

1. booting from emmc stop after u-boot 2020.04 (this hits me also)


Indeed, this already has been reported, but the root cause is unknown


2. usb did not work with newer kernels.

This gaves me the idea that something in the configuration of the s905 soc
is not ok.

here: 
https://forum.libreelec.tv/thread/12330-balbes150-le-images-with-kodi-19-for-s9xxx/?postID=147212#post147212
and here: https://lists.denx.de/pipermail/u-boot/2020-November/thread.html

in https://groups.io/g/u-boot-amlogic/topic/77816805#661 some problems in 
pinctrl related to booting from emmc is discussed.

i found that commit dd5f2351e99aad8fcbedbc1305b8b51b09952336 of u-boot
rendered the situation for odroid-c2 bad.

i gave the following patch on Top of commit 
ee1e04558ff8c8ed812b986939447f129bb0b0bb of u-boot
a try ad it fixes the odroid-c2 boot issue.

--- u-boot.git/arch/arm/dts/meson-gxbb.dtsi.orig    2020-11-27 
17:20:04.624193561 +0100
+++ u-boot.git/arch/arm/dts/meson-gxbb.dtsi 2020-11-27 17:23:18.472088934 
+0100
@@ -403,36 +403,33 @@
     gpio-ranges = <&pinctrl_periphs 0 0 119>;
     };
  
-   emmc_pins: emmc {

-   mux-0 {
-   groups = "emmc_nand_d07",
-  "emmc_cmd";
-   function = "emmc";
-   bias-pull-up;
-   };
  
-   mux-1 {

-   groups = "emmc_clk";
-   function = "emmc";
-   bias-disable;
-   };
-   };
+    emmc_pins: emmc {
+    mux {
+    groups = "emmc_nand_d07",
+   "emmc_cmd",
+   "emmc_clk";
+    function = "emmc";
+    };
+    };
  
-   emmc_ds_pins: emmc-ds {

-   mux {
-   groups = "emmc_ds";
-   function = "emmc";
-   bias-pull-down;
-   };
-   };
+    emmc_ds_pins: emmc-ds {
+    mux {
+    groups = "emmc_ds";
+    function = "emmc";
+    };
+    };
  
-   emmc_clk_gate_pins: emmc_clk_gate {

-   mux {
-   groups = "BOOT_8";
-   function = "gpio_periphs";
-   bias-pull-down;
-   };
-   };
+    emmc_clk_gate_pins: emmc_clk_gate {
+    mux {
+    groups = "BOOT_8";
+    function = "gpio_periphs";
+    };
+    cfg-pull-down {
+    pins = "BOOT_8";
+    bias-pull-down;
+    };
+    };
  
     nor_pins: nor {

     mux {



So with the latest u-boot and the kernel from 
https://github.com/chewitt/linux/tree/amlogic-5.10.y
commit 725fc8df7898102f9031ba2075f763884ffa3ee8 everything is working again.
USB does hotplugging as expected.


So, this fixes USB under Linux ?? It's not clear

Neil


The above patch fixes booting from emmc for me.
Using a newer uboot then 2020.04 is mandatory for using the above mentioned 
kernel.
The usb issue, i had with earlier kernels from the above mentioned tree.

Hope that clearifies it. I wanted to run the newest kernel on my system which 
boots from emmc.
I think these issues are probaly independant but in my system they did 
interfere.

Best regards
Otto





For me this make it work again. But i`m sorry, I don´t know what would be a 
real fix.






Am 05.12.20 um 20:55 schrieb Martin Blumenstingl:

Hi Otto,

On Sat, Dec 5, 2020 at 6:40 PM Otto Meier  wrote:


Hi Martin,

i have tried your second notice. but it does'nt solve the issue.
if at leased on device is pluged in new devices are detected. if
all devices have been removed, no new device will be detected anymore.

thanks for trying this out and for reporting back.
can you please also test if running "lsusb -vvv" (as root) makes the
devices show up?

background info: the Amlogic Meson GXBB SoC on your Odroid-C2 board
uses a "dwc2" USB 2.0 controller.
I don't have any GXBB based board, but my Odroid-C1+ uses the same
controller and overall setup. There I can reproduce the problem you

[PATCH] ARM: dts: at91: sama5d2_icp: fix i2c eeprom compatible

[Eugen Hristev]

The correct compatible for this eeproms is microchip,24aa02e48
The previous compatible string was working up to U-boot 2020.04.

Signed-off-by: Eugen Hristev 
Tested-by: Codrin Ciubotariu 
---
 arch/arm/dts/at91-sama5d2_icp.dts | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/dts/at91-sama5d2_icp.dts 
b/arch/arm/dts/at91-sama5d2_icp.dts
index cae8748268..f81fa60171 100644
--- a/arch/arm/dts/at91-sama5d2_icp.dts
+++ b/arch/arm/dts/at91-sama5d2_icp.dts
@@ -53,19 +53,19 @@
status = "okay";
 
eeprom@50 {
-   compatible = "atmel,24c32";
+   compatible = "microchip,24aa02e48";
reg = <0x50>;
pagesize = <16>;
};
 
eeprom@52 {
-   compatible = "atmel,24c32";
+   compatible = "microchip,24aa02e48";
reg = <0x52>;
pagesize = <16>;
};
 
eeprom@53 {
-   compatible = "atmel,24c32";
+   compatible = "microchip,24aa02e48";
reg = <0x53>;
pagesize = <16>;
};
-- 
2.25.1

Re: [BUG]odroid-c2 does not hotplug usb-devices

[Neil Armstrong]

Hi,

(Please CC u-boot-amlo...@groups.io when U-Boot is concerned)

On 07/12/2020 13:19, Otto Meier wrote:
> Hi Martin,
> 
> 
> I did a lot of googling this weekend and found some interesting problems with
> odroid-c2.
> 
> 1. booting from emmc stop after u-boot 2020.04 (this hits me also)

Indeed, this already has been reported, but the root cause is unknown

> 2. usb did not work with newer kernels.
> 
> This gaves me the idea that something in the configuration of the s905 soc
> is not ok.
> 
> here: 
> https://forum.libreelec.tv/thread/12330-balbes150-le-images-with-kodi-19-for-s9xxx/?postID=147212#post147212
> and here: https://lists.denx.de/pipermail/u-boot/2020-November/thread.html
> 
> in https://groups.io/g/u-boot-amlogic/topic/77816805#661 some problems in 
> pinctrl related to booting from emmc is discussed.
> 
> i found that commit dd5f2351e99aad8fcbedbc1305b8b51b09952336 of u-boot
> rendered the situation for odroid-c2 bad.
> 
> i gave the following patch on Top of commit 
> ee1e04558ff8c8ed812b986939447f129bb0b0bb of u-boot
> a try ad it fixes the odroid-c2 boot issue.
> 
> --- u-boot.git/arch/arm/dts/meson-gxbb.dtsi.orig    2020-11-27 
> 17:20:04.624193561 +0100
> +++ u-boot.git/arch/arm/dts/meson-gxbb.dtsi 2020-11-27 17:23:18.472088934 
> +0100
> @@ -403,36 +403,33 @@
>     gpio-ranges = <&pinctrl_periphs 0 0 119>;
>     };
>  
> -   emmc_pins: emmc {
> -   mux-0 {
> -   groups = "emmc_nand_d07",
> -  "emmc_cmd";
> -   function = "emmc";
> -   bias-pull-up;
> -   };
>  
> -   mux-1 {
> -   groups = "emmc_clk";
> -   function = "emmc";
> -   bias-disable;
> -   };
> -   };
> +    emmc_pins: emmc {
> +    mux {
> +    groups = "emmc_nand_d07",
> +   "emmc_cmd",
> +   "emmc_clk";
> +    function = "emmc";
> +    };
> +    };
>  
> -   emmc_ds_pins: emmc-ds {
> -   mux {
> -   groups = "emmc_ds";
> -   function = "emmc";
> -   bias-pull-down;
> -   };
> -   };
> +    emmc_ds_pins: emmc-ds {
> +    mux {
> +    groups = "emmc_ds";
> +    function = "emmc";
> +    };
> +    };
>  
> -   emmc_clk_gate_pins: emmc_clk_gate {
> -   mux {
> -   groups = "BOOT_8";
> -   function = "gpio_periphs";
> -   bias-pull-down;
> -   };
> -   };
> +    emmc_clk_gate_pins: emmc_clk_gate {
> +    mux {
> +    groups = "BOOT_8";
> +    function = "gpio_periphs";
> +    };
> +    cfg-pull-down {
> +    pins = "BOOT_8";
> +    bias-pull-down;
> +    };
> +    };
>  
>     nor_pins: nor {
>     mux {
> 
> 
> 
> So with the latest u-boot and the kernel from 
> https://github.com/chewitt/linux/tree/amlogic-5.10.y
> commit 725fc8df7898102f9031ba2075f763884ffa3ee8 everything is working again.
> USB does hotplugging as expected.

So, this fixes USB under Linux ?? It's not clear

Neil

> 
> For me this make it work again. But i`m sorry, I don´t know what would be a 
> real fix.
> 
> 
> 
> 
> 
> 
> Am 05.12.20 um 20:55 schrieb Martin Blumenstingl:
>> Hi Otto,
>>
>> On Sat, Dec 5, 2020 at 6:40 PM Otto Meier  wrote:
>>>
>>> Hi Martin,
>>>
>>> i have tried your second notice. but it does'nt solve the issue.
>>> if at leased on device is pluged in new devices are detected. if
>>> all devices have been removed, no new device will be detected anymore.
>> thanks for trying this out and for reporting back.
>> can you please also test if running "lsusb -vvv" (as root) makes the
>> devices show up?
>>
>> background info: the Amlogic Meson GXBB SoC on your Odroid-C2 board
>> uses a "dwc2" USB 2.0 controller.
>> I don't have any GXBB based board, but my Odroid-C1+ uses the same
>> controller and overall setup. There I can reproduce the problem you
>> are seeing.
>>
>> I am not sure which part of the "infrastructure" (on-board 4-port USB
>> hub, dwc2 controller, ...) is causing this issue.
>> My suggestion is to involve the linux-usb mailing list and dwc2 d

RE: [PATCH v2] arm: fsl: common: Improve NXP VID driver PMBus support

[Priyanka Jain]

>-Original Message-
>From: Stephen Carlson 
>Sent: Tuesday, November 3, 2020 3:06 AM
>To: U-Boot Mailing List 
>Cc: Priyanka Jain 
>Subject: [PATCH v2] arm: fsl: common: Improve NXP VID driver PMBus support
>
>This patch adds support for more PMBus compatible devices to the NXP drivers
>for its QorIQ family devices. At runtime, the voltage regulator is queried 
>over I2C,
>and the required voltage multiplier determined. This change supports the DIRECT
>and LINEAR PMBus voltage reporting modes.
>
>Previously, the driver only supported a few specific devices such as the
>IR36021 and LTC3882, so this change allows the QorIQ series to be used with a
>much larger variety of core voltage regulator devices.
>
>checkpatch warning "Use if (IS_DEFINED (...))" was ignored to maintain
>consistency with the existing code.
>
>Signed-off-by: Stephen Carlson 
>Cc: Priyanka Jain 
>---

Kindly help to rebase the patch to master branch of u-boot tree 
(git://git.denx.de/u-boot.git).

Regards
Priyanka

Re: [BUG]odroid-c2 does not hotplug usb-devices

[Otto Meier]

Hi Martin,


I did a lot of googling this weekend and found some interesting problems with
odroid-c2.

1. booting from emmc stop after u-boot 2020.04 (this hits me also)
2. usb did not work with newer kernels.

This gaves me the idea that something in the configuration of the s905 soc
is not ok.

here: 
https://forum.libreelec.tv/thread/12330-balbes150-le-images-with-kodi-19-for-s9xxx/?postID=147212#post147212
and here: https://lists.denx.de/pipermail/u-boot/2020-November/thread.html

in https://groups.io/g/u-boot-amlogic/topic/77816805#661 some problems in 
pinctrl related to booting from emmc is discussed.

i found that commit dd5f2351e99aad8fcbedbc1305b8b51b09952336 of u-boot
rendered the situation for odroid-c2 bad.

i gave the following patch on Top of commit 
ee1e04558ff8c8ed812b986939447f129bb0b0bb of u-boot
a try ad it fixes the odroid-c2 boot issue.

--- u-boot.git/arch/arm/dts/meson-gxbb.dtsi.orig2020-11-27 
17:20:04.624193561 +0100
+++ u-boot.git/arch/arm/dts/meson-gxbb.dtsi 2020-11-27 17:23:18.472088934 
+0100
@@ -403,36 +403,33 @@
gpio-ranges = <&pinctrl_periphs 0 0 119>;
};
 
-   emmc_pins: emmc {

-   mux-0 {
-   groups = "emmc_nand_d07",
-  "emmc_cmd";
-   function = "emmc";
-   bias-pull-up;
-   };
 
-   mux-1 {

-   groups = "emmc_clk";
-   function = "emmc";
-   bias-disable;
-   };
-   };
+emmc_pins: emmc {
+mux {
+groups = "emmc_nand_d07",
+   "emmc_cmd",
+   "emmc_clk";
+function = "emmc";
+};
+};
 
-   emmc_ds_pins: emmc-ds {

-   mux {
-   groups = "emmc_ds";
-   function = "emmc";
-   bias-pull-down;
-   };
-   };
+emmc_ds_pins: emmc-ds {
+mux {
+groups = "emmc_ds";
+function = "emmc";
+};
+};
 
-   emmc_clk_gate_pins: emmc_clk_gate {

-   mux {
-   groups = "BOOT_8";
-   function = "gpio_periphs";
-   bias-pull-down;
-   };
-   };
+emmc_clk_gate_pins: emmc_clk_gate {
+mux {
+groups = "BOOT_8";
+function = "gpio_periphs";
+};
+cfg-pull-down {
+pins = "BOOT_8";
+bias-pull-down;
+};
+};
 
nor_pins: nor {

mux {



So with the latest u-boot and the kernel from 
https://github.com/chewitt/linux/tree/amlogic-5.10.y
commit 725fc8df7898102f9031ba2075f763884ffa3ee8 everything is working again.
USB does hotplugging as expected.

For me this make it work again. But i`m sorry, I don´t know what would be a 
real fix.






Am 05.12.20 um 20:55 schrieb Martin Blumenstingl:

Hi Otto,

On Sat, Dec 5, 2020 at 6:40 PM Otto Meier  wrote:


Hi Martin,

i have tried your second notice. but it does'nt solve the issue.
if at leased on device is pluged in new devices are detected. if
all devices have been removed, no new device will be detected anymore.

thanks for trying this out and for reporting back.
can you please also test if running "lsusb -vvv" (as root) makes the
devices show up?

background info: the Amlogic Meson GXBB SoC on your Odroid-C2 board
uses a "dwc2" USB 2.0 controller.
I don't have any GXBB based board, but my Odroid-C1+ uses the same
controller and overall setup. There I can reproduce the problem you
are seeing.

I am not sure which part of the "infrastructure" (on-board 4-port USB
hub, dwc2 controller, ...) is causing this issue.
My suggestion is to involve the linux-usb mailing list and dwc2 driver
maintainer:
- Minas Harutyunyan  (dwc2 driver maintainer)
- linux-...@vger.kernel.org (usb mailing list)

In the past they provided information and helped to debug issues.
Please also keep me Cc'ed so I can help with any Amlogic specific
questions, drivers, etc.


Best regards,
Martin

Re: [PATCH] clk: at91: sam9x60: remove the parsing of atmel,main-osc-bypass

[Eugen.Hristev]

On 02.12.2020 13:39, Claudiu Beznea wrote:
> Remove the parsing of atmel,main-osc-bypass DT property as the SAM9X60
> have no support for crystal oscillator bypass. Setting this bit might
> affect the device functionality.
> 
> Fixes: a64862284f65 ("clk: at91: sam9x60: add support compatible with CCF")
> Signed-off-by: Claudiu Beznea 
> ---

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

Please pull u-boot-marvell/master

[Stefan Roese]

Hi Tom,

please pull an update of Marvell Armada related fixes and minor
additions. Here the summary log:


- Espressobin: Simplify DT handling of board variants (Pali)
- Add Luka Perkov to maintainers of Puzzle-M801 (Luka)
- Armada 38x: Enable board specific USB2 high-speed impedance
  threshold configuration (Joshua)


Here the Azure build, without any issues:

https://dev.azure.com/sr0718/u-boot/_build/results?buildId=64&view=results

Thanks,
Stefan


The following changes since commit ee1e04558ff8c8ed812b986939447f129bb0b0bb:

  Merge branch '2020-12-02-master-imports' (2020-12-03 09:43:47 -0500)

are available in the Git repository at:

  g...@gitlab.denx.de:u-boot/custodians/u-boot-marvell.git

for you to fetch changes up to 061c6d1b238aa100728b3082fc943e8f679f8e7f:

  arm: mvebu: Espressobin: Detect presence of emmc at runtime 
(2020-12-07 07:11:37 +0100)



Joshua Scott (1):
  arm: mvebu: a38x: Configurable USB2 high-speed impedance threshold

Luka Kovacic (1):
  arm: mvebu: puzzle-m801: Add a maintainer

Pali Rohár (4):
  Revert "arm64: dts: armada-3720-espressobin: split common parts 
to .dtsi"
  Revert "arm64: dts: a3720: add support for espressobin with 
populated emmc"

  arm: mvebu: Espressobin: Add support for emmc into dts file
  arm: mvebu: Espressobin: Detect presence of emmc at runtime

 arch/arm/dts/Makefile  |   1 -
 arch/arm/dts/armada-3720-espressobin-emmc.dts  |  44 -
 arch/arm/dts/armada-3720-espressobin.dts   | 186 
-
 arch/arm/dts/armada-3720-espressobin.dtsi  | 167 
--

 arch/arm/mach-mvebu/Kconfig|   6 +
 .../mach-mvebu/serdes/a38x/high_speed_env_spec.c   |   6 +-
 board/Marvell/mvebu_armada-37xx/board.c|   6 +-
 board/Marvell/mvebu_armada-8k/MAINTAINERS  |   1 +
 doc/README.marvell |   7 +-
 9 files changed, 196 insertions(+), 228 deletions(-)
 delete mode 100644 arch/arm/dts/armada-3720-espressobin-emmc.dts
 delete mode 100644 arch/arm/dts/armada-3720-espressobin.dtsi

Re: [PATCH] arm: mvebu: puzzle-m801: Add a maintainer

[Stefan Roese]

On 29.10.20 22:30, Luka Kovacic wrote:

Add Luka Perkov to Puzzle-M801 BOARD MAINTAINERS.

Signed-off-by: Luka Kovacic 
Cc: Luka Perkov 


Applied to u-boot-marvell/master

Thanks,
Stefan


---
  board/Marvell/mvebu_armada-8k/MAINTAINERS | 1 +
  1 file changed, 1 insertion(+)

diff --git a/board/Marvell/mvebu_armada-8k/MAINTAINERS 
b/board/Marvell/mvebu_armada-8k/MAINTAINERS
index 15660cd17d..55e485faa9 100644
--- a/board/Marvell/mvebu_armada-8k/MAINTAINERS
+++ b/board/Marvell/mvebu_armada-8k/MAINTAINERS
@@ -13,6 +13,7 @@ F:configs/mvebu_mcbin-88f8040_defconfig
  
  Puzzle-M801 BOARD

  M:Luka Kovacic 
+M: Luka Perkov 
  S:Maintained
  F:configs/mvebu_puzzle-m801-88f8040_defconfig
  F:arch/arm/dts/armada-8040-puzzle-m801.dts




Viele Grüße,
Stefan

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

Re: [PATCH v2] arm: mvebu: a38x: Configurable USB2 high-speed impedance threshold

[Stefan Roese]

On 08.11.20 22:14, Joshua Scott wrote:

Hardware testing of a board using the Armada 385 has shown that an
impedance threshold setting of 0x7 performs better in an eye-diagram
test than with Marvell's recommended value 0x6.

As other boards may still perform better with Marvell's reccomended value,
a configuration option is added with a default value of 0x6.

Signed-off-by: Joshua Scott 
Reviewed-by: Stefan Roese 


Applied to u-boot-marvell/master

Thanks,
Stefan


---
Changes for v2:
 - Added "range" to Kconfig to prevent invalid values from being
   selected.

  arch/arm/mach-mvebu/Kconfig   | 6 ++
  arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c | 6 +++---
  2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 0d8e0922a2..72aee8b3e5 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -30,6 +30,12 @@ config ARMADA_38X
select ARMADA_32BIT
select HAVE_MVEBU_EFUSE
  
+config ARMADA_38X_HS_IMPEDANCE_THRESH

+   hex  "Armada 38x USB 2.0 High-Speed Impedance Threshold (0x0 - 0x7)"
+   depends on ARMADA_38X
+   default 0x6
+   range 0x0 0x7
+
  config ARMADA_XP
bool
select ARMADA_32BIT
diff --git a/arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c 
b/arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c
index 2454730e6d..ae2a361104 100644
--- a/arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c
+++ b/arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c
@@ -677,9 +677,9 @@ struct op_params usb2_power_up_params[] = {
{0xc200c, 0x0 /*NA*/, 0xf000, {0x1000}, 0, 0},
{0xc400c, 0x0 /*NA*/, 0xf000, {0x1000}, 0, 0},
/* Change the High speed impedance threshold */
-   {0xc0008, 0x0 /*NA*/, 0x700, {0x600}, 0, 0},
-   {0xc2008, 0x0 /*NA*/, 0x700, {0x600}, 0, 0},
-   {0xc4008, 0x0 /*NA*/, 0x700, {0x600}, 0, 0},
+   {0xc0008, 0x0 /*NA*/, 0x700, {CONFIG_ARMADA_38X_HS_IMPEDANCE_THRESH << 
8}, 0, 0},
+   {0xc2008, 0x0 /*NA*/, 0x700, {CONFIG_ARMADA_38X_HS_IMPEDANCE_THRESH << 
8}, 0, 0},
+   {0xc4008, 0x0 /*NA*/, 0x700, {CONFIG_ARMADA_38X_HS_IMPEDANCE_THRESH << 
8}, 0, 0},
/* Change the squelch level of the receiver to meet the receiver 
electrical measurements (squelch and receiver sensitivity tests) */
{0xc0014, 0x0 /*NA*/, 0xf, {0x8}, 0, 0},
{0xc2014, 0x0 /*NA*/, 0xf, {0x8}, 0, 0},




Viele Grüße,
Stefan

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

Re: [PATCH 0/4] Use just one DTS file for all Espressobin variants

[Stefan Roese]

On 25.11.20 19:20, Pali Rohár wrote:

This patch series change Espressobin code to use in U-Boot just one DTS
file for all Espressobin variants. Therefore DT compatible string
globalscale,espressobin-emmc is not used anymore as it is not needed.

It means that setup and compilation of U-Boot for Espressobin is less
complicated and more simple. As there is no need to check for HW details
and just one U-Boot binary would work for all Espressobin variants.

First two patches just revert previous eMMC support and next two patches
add support for eMMC in way that just one DTS file is used and fdtfile
env variable is correctly set for any Espressobin variant.

We have tested that fdtfile env variable is correctly set on Espressobin
variants with eMMC, without eMMC, with DDR3 RAM and also with DDR4 RAM.
Also that eMMC is working on Espressobin variant with eMMC.

Pali Rohár (4):
   Revert "arm64: dts: armada-3720-espressobin: split common parts to
 .dtsi"
   Revert "arm64: dts: a3720: add support for espressobin with populated
 emmc"
   arm: mvebu: Espressobin: Add support for emmc into dts file
   arm: mvebu: Espressobin: Detect presence of emmc at runtime

  arch/arm/dts/Makefile |   1 -
  arch/arm/dts/armada-3720-espressobin-emmc.dts |  44 -
  arch/arm/dts/armada-3720-espressobin.dts  | 186 +-
  arch/arm/dts/armada-3720-espressobin.dtsi | 167 
  board/Marvell/mvebu_armada-37xx/board.c   |   6 +-
  doc/README.marvell|   7 +-
  6 files changed, 186 insertions(+), 225 deletions(-)
  delete mode 100644 arch/arm/dts/armada-3720-espressobin-emmc.dts
  delete mode 100644 arch/arm/dts/armada-3720-espressobin.dtsi


Applied to u-boot-marvell/master

Thanks,
Stefan

Re: [PATCH 4/4] arm: mvebu: Espressobin: Detect presence of emmc at runtime

[Stefan Roese]

On 05.12.20 13:44, Pali Rohár wrote:

On Thursday 03 December 2020 17:30:44 Stefan Roese wrote:

On 03.12.20 16:56, Pali Rohár wrote:

On Wednesday 02 December 2020 15:35:08 Andre Heider wrote:

On 25/11/2020 19:20, Pali Rohár wrote:

Try to initialize emmc in board_late_init() and if it fails then we know
that emmc device is not connected.

This allows to use in U-Boot just one DTS file for all Espressobin variants
and also to correctly set fdtfile env variable for Linux kernel.

Signed-off-by: Pali Rohár 
Tested-by: Gérald Kerma 


Small nit below, with that:
Reviewed-by: Andre Heider 


---
board/Marvell/mvebu_armada-37xx/board.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/board/Marvell/mvebu_armada-37xx/board.c 
b/board/Marvell/mvebu_armada-37xx/board.c
index 73d69e0388..f67b04b78c 100644
--- a/board/Marvell/mvebu_armada-37xx/board.c
+++ b/board/Marvell/mvebu_armada-37xx/board.c
@@ -8,6 +8,7 @@
#include 
#include 
#include 
+#include 
#include 
#include 
#include 
@@ -83,6 +84,7 @@ int board_init(void)
#ifdef CONFIG_BOARD_LATE_INIT
int board_late_init(void)
{
+   struct mmc *mmc_dev;
bool ddr4, emmc;
if (env_get("fdtfile"))
@@ -95,7 +97,9 @@ int board_late_init(void)
ddr4 = ((readl(A3700_CH0_MC_CTRL2_REG) >> 
A3700_MC_CTRL2_SDRAM_TYPE_OFFS)
& A3700_MC_CTRL2_SDRAM_TYPE_MASK) == 
A3700_MC_CTRL2_SDRAM_TYPE_DDR4;
-   emmc = of_machine_is_compatible("globalscale,espressobin-emmc");
+   /* eMMC is mmc dev num 1 */
+   mmc_dev = find_mmc_device(1);
+   emmc = (mmc_dev && mmc_init(mmc_dev) == 0);


I think you meant "mmc_dev && (mmc_init(mmc_dev) == 0);"?


Hm... no... I usually do not put parenthesis around || and && operators.

But both variants are same right?


Yours still has parenthesis around the (a && b) part, which is not
needed. But this is nitpicking AFAIAC.


If U-Boot coding style prefers second (your) variant, I do not have
a problem to change it.


checkpatch should complain if something does not match the coding style.


Stefan, do you need to change this styling?


No, not from my point of view.


Ok! So based on Philipp and Andre replies, would you be sending these
patches to 2021.01 release? As for this release is scheduled usage of
"globalscale,espressobin-emmc" compatible string in U-Boot, these
patches are removing them and previous versions do not used them.


Yes, I'm preparing a pull request just now.

Thanks,
Stefan

RE: [PATCH v2 1/1] board: freescale: vid.c: Add check for return value of adjust_vdd()

[Priyanka Jain]

>-Original Message-
>From: Priyanka Singh 
>Sent: Wednesday, November 25, 2020 2:59 PM
>To: u-boot@lists.denx.de
>Cc: Priyanka Jain ; Biwen Li ;
>Priyanka Singh 
>Subject: [PATCH v2 1/1] board: freescale: vid.c: Add check for return value of
>adjust_vdd()
>
>From: Biwen Li 
>
>Add check for return value of adjust_vdd()
>
>---
>Changes for v2:
>   -Add parantheses to fix build warning
>
>Signed-off-by: Priyanka Singh 
>Signed-off-by: Biwen Li 
>---
> board/freescale/common/vid.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/board/freescale/common/vid.c b/board/freescale/common/vid.c
>index d02d91cdef..0256d035eb 100644
>--- a/board/freescale/common/vid.c
>+++ b/board/freescale/common/vid.c
>@@ -971,11 +971,11 @@ static int do_vdd_override(cmd_tbl_t *cmdtp,
>   if (argc < 2)
>   return CMD_RET_USAGE;
>
>-  if (!strict_strtoul(argv[1], 10, &override))
>+  if (!strict_strtoul(argv[1], 10, &override)) {
>   ret = adjust_vdd(override);   /* the value is checked by callee 
> */
>   if (ret < 0)
>   return CMD_RET_FAILURE;
>-  else
>+  } else
>   return CMD_RET_USAGE;
>   return 0;
> }
>--
>2.17.1

Incomplete patch. Please include changes of previous version of patch as well.

Regards
Priyanka

RE: [PATCH 10/15] configs: ls1043a: enable CONFIG_MPC8XXX_GPIO

[Priyanka Jain]

>-Original Message-
>From: Biwen Li 
>Sent: Friday, October 16, 2020 2:42 PM
>To: Priyanka Jain 
>Cc: Jiafei Pan ; u-boot@lists.denx.de; Xiaobo Xie
>; Biwen Li 
>Subject: [PATCH 10/15] configs: ls1043a: enable CONFIG_MPC8XXX_GPIO
>
>From: Biwen Li 
>
>Enable CONFIG_MPC8XXX_GPIO for SoC LS1043A
>
>Signed-off-by: Biwen Li 
>---
> include/configs/ls1043a_common.h | 10 ++
> 1 file changed, 10 insertions(+)
>
>diff --git a/include/configs/ls1043a_common.h
>b/include/configs/ls1043a_common.h
>index 96fdd6417e..76252a5c67 100644
>--- a/include/configs/ls1043a_common.h
>+++ b/include/configs/ls1043a_common.h
>@@ -119,6 +119,16 @@
>
> #endif
>
>+/* GPIO */
>+#ifdef CONFIG_DM_GPIO
>+#ifndef CONFIG_MPC8XXX_GPIO
>+#define CONFIG_MPC8XXX_GPIO
>+#endif
>+#ifndef CONFIG_CMD_GPIO
>+#define CONFIG_CMD_GPIO
>+#endif
>+#endif
>+
> /* IFC */
> #ifndef SPL_NO_IFC
> #if defined(CONFIG_TFABOOT) || \
>--
>2.17.1

Kindly fix below checkpatch error and similar error in other patches of this 
series: 

ERROR: All commands are managed by Kconfig
#27: FILE: include/configs/ls1043a_common.h:128:
+#define CONFIG_CMD_GPIO

total: 1 errors, 0 warnings, 0 checks, 16 lines checked

Regards
Priyanka

RE: [PATCH 12/15] configs: ls1088a: enable CONFIG_MPC8XXX_GPIO

[Priyanka Jain]

>-Original Message-
>From: Biwen Li 
>Sent: Friday, October 16, 2020 2:42 PM
>To: Priyanka Jain 
>Cc: Jiafei Pan ; u-boot@lists.denx.de; Xiaobo Xie
>; Biwen Li 
>Subject: [PATCH 12/15] configs: ls1088a: enable CONFIG_MPC8XXX_GPIO
>
>From: Biwen Li 
>
>Enable CONFIG_MPC8XXX_GPIO for LS1088A
>
>Signed-off-by: Biwen Li 
>---
> include/configs/ls1088a_common.h | 10 ++
> 1 file changed, 10 insertions(+)
>
>diff --git a/include/configs/ls1088a_common.h
>b/include/configs/ls1088a_common.h
>index f9e349871c..4ef840d89e 100644
>--- a/include/configs/ls1088a_common.h
>+++ b/include/configs/ls1088a_common.h
>@@ -53,6 +53,16 @@
> /* Size of malloc() pool */
> #define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + 2048 *
>1024)
>
>+/* GPIO */
>+#ifdef CONFIG_DM_GPIO
>+#ifndef CONFIG_MPC8XXX_GPIO
>+#define CONFIG_MPC8XXX_GPIO
>+#endif
>+#ifndef CONFIG_CMD_GPIO
>+#define CONFIG_CMD_GPIO
>+#endif
>+#endif
>+
> /* I2C */
> #ifndef CONFIG_DM_I2C
> #define CONFIG_SYS_I2C
>--
>2.17.1
Kindly fix below checkpatch error: 
ERROR: All commands are managed by Kconfig
#29: FILE: include/configs/ls1088a_common.h:62:
+#define CONFIG_CMD_GPIO

total: 1 errors, 0 warnings, 0 checks, 16 lines checked

Regards
Priyanka

RE: [PATCH 15/15] configs: ls1046a: enable MPC8XXX_GPIO

[Priyanka Jain]

>-Original Message-
>From: Biwen Li 
>Sent: Friday, October 16, 2020 2:42 PM
>To: Priyanka Jain 
>Cc: Jiafei Pan ; u-boot@lists.denx.de; Xiaobo Xie
>; Biwen Li 
>Subject: [PATCH 15/15] configs: ls1046a: enable MPC8XXX_GPIO
>
>From: Biwen Li 
>
>Enable MPC8XXX_GPIO for SoC LS1046A
>
>Signed-off-by: Biwen Li 
>---
> include/configs/ls1046a_common.h | 10 ++
> 1 file changed, 10 insertions(+)
>
>diff --git a/include/configs/ls1046a_common.h
>b/include/configs/ls1046a_common.h
>index d44a7f105e..06b4d91676 100644
>--- a/include/configs/ls1046a_common.h
>+++ b/include/configs/ls1046a_common.h
>@@ -126,6 +126,16 @@
> #define CONFIG_SYS_MONITOR_LEN0xa
> #endif
>
>+/* GPIO */
>+#ifdef CONFIG_DM_GPIO
>+#ifndef CONFIG_MPC8XXX_GPIO
>+#define CONFIG_MPC8XXX_GPIO
>+#endif
>+#ifndef CONFIG_CMD_GPIO
>+#define CONFIG_CMD_GPIO
>+#endif
>+#endif
>+
> /* I2C */
> #ifndef CONFIG_DM_I2C
> #define CONFIG_SYS_I2C
>--
>2.17.1
Kindly fix below checkpatch error: 

ERROR: All commands are managed by Kconfig
#27: FILE: include/configs/ls1046a_common.h:135:
+#define CONFIG_CMD_GPIO

total: 1 errors, 0 warnings, 0 checks, 16 lines checked

Regards
Priyanka

RE: [PATCH 11/15] configs: ls1028a: enable CONFIG_MPC8XXX_GPIO

[Priyanka Jain]

>-Original Message-
>From: Biwen Li 
>Sent: Friday, October 16, 2020 2:42 PM
>To: Priyanka Jain 
>Cc: Jiafei Pan ; u-boot@lists.denx.de; Xiaobo Xie
>; Biwen Li 
>Subject: [PATCH 11/15] configs: ls1028a: enable CONFIG_MPC8XXX_GPIO
>
>From: Biwen Li 
>
>Enable CONFIG_MPC8XXX_GPIO for SoC LS1028A
>
>Signed-off-by: Biwen Li 
>---
> include/configs/ls1028a_common.h | 10 ++
> 1 file changed, 10 insertions(+)
>
>diff --git a/include/configs/ls1028a_common.h
>b/include/configs/ls1028a_common.h
>index 8345cd7acf..c89e7b5f3d 100644
>--- a/include/configs/ls1028a_common.h
>+++ b/include/configs/ls1028a_common.h
>@@ -36,6 +36,16 @@
> /* Size of malloc() pool */
> #define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + 2048 *
>1024)
>
>+/* GPIO */
>+#ifdef CONFIG_DM_GPIO
>+#ifndef CONFIG_MPC8XXX_GPIO
>+#define CONFIG_MPC8XXX_GPIO
>+#endif
>+#ifndef CONFIG_CMD_GPIO
>+#define CONFIG_CMD_GPIO
>+#endif
>+#endif
>+
> /* I2C */
> #ifndef CONFIG_DM_I2C
> #define CONFIG_SYS_I2C
>--
>2.17.1
Kindly fix below checkpatch error: 

ERROR: All commands are managed by Kconfig
#27: FILE: include/configs/ls1028a_common.h:45:
+#define CONFIG_CMD_GPIO

total: 1 errors, 0 warnings, 0 checks, 16 lines checked

Regards
Priyanka

RE: [PATCH 14/15] configs: lx2160a: enable CONFIG_MPC8XXX_GPIO

[Priyanka Jain]

>-Original Message-
>From: Biwen Li 
>Sent: Friday, October 16, 2020 2:42 PM
>To: Priyanka Jain 
>Cc: Jiafei Pan ; u-boot@lists.denx.de; Xiaobo Xie
>; Biwen Li 
>Subject: [PATCH 14/15] configs: lx2160a: enable CONFIG_MPC8XXX_GPIO
>
>From: Biwen Li 
>
>Enable CONFIG_MPC8XXX_GPIO for SoC LX2160A
>
>Signed-off-by: Biwen Li 
>---
> include/configs/lx2160a_common.h | 10 ++
> 1 file changed, 10 insertions(+)
>
>diff --git a/include/configs/lx2160a_common.h
>b/include/configs/lx2160a_common.h
>index 0017ac5773..fe79d91f33 100644
>--- a/include/configs/lx2160a_common.h
>+++ b/include/configs/lx2160a_common.h
>@@ -158,6 +158,16 @@
> #define NXP_FSPI_FLASH_NUM1
> #endif
>
>+/* GPIO */
>+#ifdef CONFIG_DM_GPIO
>+#ifndef CONFIG_MPC8XXX_GPIO
>+#define CONFIG_MPC8XXX_GPIO
>+#endif
>+#ifndef CONFIG_CMD_GPIO
>+#define CONFIG_CMD_GPIO
>+#endif
>+#endif
>+
> #ifndef __ASSEMBLY__
> unsigned long get_board_sys_clk(void);
> unsigned long get_board_ddr_clk(void);
>--
>2.17.1
Kindly fix below checkpatch error: 

ERROR: All commands are managed by Kconfig
#27: FILE: include/configs/lx2160a_common.h:169:
+#define CONFIG_CMD_GPIO

total: 1 errors, 0 warnings, 0 checks, 16 lines checked

Regards
Priyanka

RE: [PATCH 13/15] configs: ls208xa: enable CONFIG_MPC8XXX_GPIO

[Priyanka Jain]

>-Original Message-
>From: Biwen Li 
>Sent: Friday, October 16, 2020 2:42 PM
>To: Priyanka Jain 
>Cc: Jiafei Pan ; u-boot@lists.denx.de; Xiaobo Xie
>; Biwen Li 
>Subject: [PATCH 13/15] configs: ls208xa: enable CONFIG_MPC8XXX_GPIO
>
>From: Biwen Li 
>
>Enable CONFIG_MPC8XXX_GPIO for LS208xA
>
>Signed-off-by: Biwen Li 
>---
> include/configs/ls2080a_common.h | 10 ++
> 1 file changed, 10 insertions(+)
>
>diff --git a/include/configs/ls2080a_common.h
>b/include/configs/ls2080a_common.h
>index 444bb8c3b5..3631418f29 100644
>--- a/include/configs/ls2080a_common.h
>+++ b/include/configs/ls2080a_common.h
>@@ -66,6 +66,16 @@
> /* Size of malloc() pool */
> #define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + 2048 *
>1024)
>
>+/* GPIO */
>+#ifdef CONFIG_DM_GPIO
>+#ifndef CONFIG_MPC8XXX_GPIO
>+#define CONFIG_MPC8XXX_GPIO
>+#endif
>+#ifndef CONFIG_CMD_GPIO
>+#define CONFIG_CMD_GPIO
>+#endif
>+#endif
>+
> /* I2C */
> #ifndef CONFIG_DM_I2C
> #define CONFIG_SYS_I2C
>--
>2.17.1
Kindly fix below checkpatch error: 
ERROR: All commands are managed by Kconfig
#29: FILE: include/configs/ls2080a_common.h:75:
+#define CONFIG_CMD_GPIO

total: 1 errors, 0 warnings, 0 checks, 16 lines checked

Regards
Priyanka

[PATCH] common: splash_source: fix -Wint-to-pointer-cast warning

[Jaehoon Chung]

Fix -Wint-to-pointer-cast warning

common/splash_source.c: In function 'splash_load_raw':
common/splash_source.c:100:12: warning: cast to pointer from integer of 
different size [-Wint-to-pointer-cast]
  100 |  bmp_hdr = (struct bmp_header *)bmp_load_addr;
  |^
common/splash_source.c: In function 'splash_sf_read_raw':
common/splash_source.c:39:47: warning: cast to pointer from integer of 
different size [-Wint-to-pointer-cast]
   39 |  return spi_flash_read(sf, offset, read_size, (void *)bmp_load_addr);
  |   ^

Signed-off-by: Jaehoon Chung 
---
 common/splash_source.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/common/splash_source.c b/common/splash_source.c
index f51ca5ddf37c..e50bdfe99c6a 100644
--- a/common/splash_source.c
+++ b/common/splash_source.c
@@ -36,7 +36,7 @@ static int splash_sf_read_raw(u32 bmp_load_addr, int offset, 
size_t read_size)
return -ENODEV;
}
 
-   return spi_flash_read(sf, offset, read_size, (void *)bmp_load_addr);
+   return spi_flash_read(sf, offset, read_size, (void 
*)(uintptr_t)bmp_load_addr);
 }
 #else
 static int splash_sf_read_raw(u32 bmp_load_addr, int offset, size_t read_size)
@@ -97,7 +97,7 @@ static int splash_load_raw(struct splash_location *location, 
u32 bmp_load_addr)
if (res < 0)
return res;
 
-   bmp_hdr = (struct bmp_header *)bmp_load_addr;
+   bmp_hdr = (struct bmp_header *)(uintptr_t)bmp_load_addr;
bmp_size = le32_to_cpu(bmp_hdr->file_size);
 
if (bmp_load_addr + bmp_size >= gd->start_addr_sp)
-- 
2.29.0