Re: [PATCH v4 03/16] common: update: add a generic interface for FIT image
Heinrich,
On Wed, Jul 22, 2020 at 03:07:51PM +0200, Heinrich Schuchardt wrote:
> On 22.07.20 08:05, AKASHI Takahiro wrote:
> > The main purpose of this patch is to separate a generic interface for
> > updating firmware using DFU drivers from "auto-update" via tftp.
> >
> > This function will also be used in implementing UEFI capsule update
> > in a later commit.
> >
> > Signed-off-by: AKASHI Takahiro
> > ---
> > common/Kconfig | 14 +
> > common/Makefile | 3 +-
> > common/update.c | 71 +
> > drivers/dfu/Kconfig | 1 +
> > include/image.h | 12
> > 5 files changed, 99 insertions(+), 2 deletions(-)
> >
> > diff --git a/common/Kconfig b/common/Kconfig
> > index ca42ba37b726..86568dec2e25 100644
> > --- a/common/Kconfig
> > +++ b/common/Kconfig
> > @@ -1014,6 +1014,20 @@ endmenu
> >
> > menu "Update support"
> >
> > +config UPDATE_COMMON
> > + bool
> > + default n
> > + select DFU_ALT
>
> Why do we need separate symbols DFU_ALT and DFU_COMMON?
Because we have different compile targets.
I believe that 'update.c' should still stay in common (or preferably lib/)
because it is a kind of 'high-level' helper functions for a specific use/
subsystem, tftp update or UEFI capsule in this case, while drivers/dfu is
a low-level/generic drivers for multiple uses.
> > +
> > +config UPDATE_FIT
> > + bool "Firmware update using fitImage"
> > + depends on FIT
> > + depends on DFU
> > + select UPDATE_COMMON
> > + help
> > + This option allows performing update of DFU-capable storage with
> > + data in fitImage.
> > +
> > config ANDROID_AB
> > bool "Android A/B updates"
> > default n
> > diff --git a/common/Makefile b/common/Makefile
> > index 2e7a090588d9..bcf352d01652 100644
> > --- a/common/Makefile
> > +++ b/common/Makefile
> > @@ -53,8 +53,7 @@ obj-$(CONFIG_LCD_ROTATION) += lcd_console_rotation.o
> > obj-$(CONFIG_LCD_DT_SIMPLEFB) += lcd_simplefb.o
> > obj-$(CONFIG_LYNXKDI) += lynxkdi.o
> > obj-$(CONFIG_MENU) += menu.o
> > -obj-$(CONFIG_UPDATE_TFTP) += update.o
> > -obj-$(CONFIG_DFU_TFTP) += update.o
> > +obj-$(CONFIG_UPDATE_COMMON) += update.o
> > obj-$(CONFIG_USB_KEYBOARD) += usb_kbd.o
> > obj-$(CONFIG_CMDLINE) += cli_readline.o cli_simple.o
> >
> > diff --git a/common/update.c b/common/update.c
> > index f82d77cc0be9..2c75b37f19e6 100644
> > --- a/common/update.c
> > +++ b/common/update.c
> > @@ -23,6 +23,7 @@
> > #include
> > #include
> >
> > +#ifdef CONFIG_DFU_TFTP
> > /* env variable holding the location of the update file */
> > #define UPDATE_FILE_ENV"updatefile"
> >
> > @@ -89,6 +90,7 @@ static int update_load(char *filename, ulong msec_max,
> > int cnt_max, ulong addr)
> >
> > return rv;
> > }
> > +#endif /* CONFIG_DFU_TFTP */
> >
> > static int update_fit_getparams(const void *fit, int noffset, ulong *addr,
> > ulong *fladdr, ulong *size)
> > @@ -106,6 +108,7 @@ static int update_fit_getparams(const void *fit, int
> > noffset, ulong *addr,
> > return 0;
> > }
> >
> > +#ifdef CONFIG_DFU_TFTP
> > int update_tftp(ulong addr, char *interface, char *devstring)
> > {
> > char *filename, *env_addr, *fit_image_name;
> > @@ -194,3 +197,71 @@ next_node:
> >
> > return ret;
> > }
> > +#endif /* CONFIG_DFU_UPDATE */
>
> Why do we need all those #ifdef? The linker removes all unused functions.
I think this kind of use of #ifdef is quite common across
u-boot source code.
If you want to prohibit such usages, we should have
a written document/guideline.
> We should move update_tftp() to drivers/dfu/dfu_tftp.c
I can't agree. See the above.
-Takahiro Akashi
> Best regards
>
> Heinrich
>
> > +
> > +#ifdef CONFIG_UPDATE_FIT
> > +/**
> > + * fit_update - update storage with FIT image
> > + * @fit: Pointer to FIT image
> > + *
> > + * Update firmware on storage using FIT image as input.
> > + * The storage area to be update will be identified by the name
> > + * in FIT and matching it to "dfu_alt_info" variable.
> > + *
> > + * Return: 0 - on success, non-zero - otherwise
> > + */
> > +int fit_update(const void *fit)
> > +{
> > + char *fit_image_name;
> > + ulong update_addr, update_fladdr, update_size;
> > + int images_noffset, ndepth, noffset;
> > + int ret = 0;
> > +
> > + if (!fit)
> > + return -EINVAL;
> > +
> > + if (!fit_check_format((void *)fit)) {
> > + printf("Bad FIT format of the update file, aborting
> > auto-update\n");
> > + return -EINVAL;
> > + }
> > +
> > + /* process updates */
> > + images_noffset = fdt_path_offset(fit, FIT_IMAGES_PATH);
> > +
> > + ndepth = 0;
> > + noffset = fdt_next_node(fit, images_noffset, );
> > + while (noffset >= 0 && ndepth > 0) {
> > + if (ndepth != 1)
> > + goto next_node;
> > +
> > + fit_image_name = (char *)fit_get_name(fit, noffset, NULL);
> > +
[PATCH v2] board: Add support for iMX8QXP AI_ML board
This commit adds initial board support for iMX8QXP AI_ML board from Einfochips. This board is one of the 96Boards Consumer Edition and AI boards of the 96Boards family based on i.MX8QXP SoC from NXP/Freescale. This initial supports contains following peripherals which are tested and known to work: 1. Debug serial via UART2 2. SD card 3. Ethernet More information about this board can be found in arrow website: https://www.arrow.com/en/products/imx8-ai-ml/arrow-development-tools Reviewed-by: Peng Fan Reviewed-by: Fabio Estevam Signed-off-by: Manivannan Sadhasivam --- Changes in v2: * Rebased onto u-boot/master and fixed one build issue * Added review from Fabio arch/arm/mach-imx/imx8/Kconfig| 6 ++ board/einfochips/imx8qxp_ai_ml/Kconfig| 21 board/einfochips/imx8qxp_ai_ml/MAINTAINERS| 6 ++ board/einfochips/imx8qxp_ai_ml/Makefile | 8 ++ board/einfochips/imx8qxp_ai_ml/README | 49 ++ .../einfochips/imx8qxp_ai_ml/imx8qxp_ai_ml.c | 78 +++ board/einfochips/imx8qxp_ai_ml/imximage.cfg | 24 + board/einfochips/imx8qxp_ai_ml/spl.c | 39 configs/imx8qxp_ai_ml_defconfig | 83 include/configs/imx8qxp_ai_ml.h | 95 +++ 10 files changed, 409 insertions(+) create mode 100644 board/einfochips/imx8qxp_ai_ml/Kconfig create mode 100644 board/einfochips/imx8qxp_ai_ml/MAINTAINERS create mode 100644 board/einfochips/imx8qxp_ai_ml/Makefile create mode 100644 board/einfochips/imx8qxp_ai_ml/README create mode 100644 board/einfochips/imx8qxp_ai_ml/imx8qxp_ai_ml.c create mode 100644 board/einfochips/imx8qxp_ai_ml/imximage.cfg create mode 100644 board/einfochips/imx8qxp_ai_ml/spl.c create mode 100644 configs/imx8qxp_ai_ml_defconfig create mode 100644 include/configs/imx8qxp_ai_ml.h diff --git a/arch/arm/mach-imx/imx8/Kconfig b/arch/arm/mach-imx/imx8/Kconfig index 9d1f73dfc7..308122d62a 100644 --- a/arch/arm/mach-imx/imx8/Kconfig +++ b/arch/arm/mach-imx/imx8/Kconfig @@ -75,6 +75,11 @@ config TARGET_GIEDI select BOARD_LATE_INIT select IMX8QXP +config TARGET_IMX8QXP_AI_ML + bool "Support i.MX8QXP AI_ML board" + select BOARD_EARLY_INIT_F + select IMX8QXP + config TARGET_IMX8QM_MEK bool "Support i.MX8QM MEK board" select BOARD_LATE_INIT @@ -93,6 +98,7 @@ config TARGET_IMX8QXP_MEK endchoice +source "board/einfochips/imx8qxp_ai_ml/Kconfig" source "board/freescale/imx8qm_mek/Kconfig" source "board/freescale/imx8qxp_mek/Kconfig" source "board/advantech/imx8qm_rom7720_a1/Kconfig" diff --git a/board/einfochips/imx8qxp_ai_ml/Kconfig b/board/einfochips/imx8qxp_ai_ml/Kconfig new file mode 100644 index 00..b6806b8859 --- /dev/null +++ b/board/einfochips/imx8qxp_ai_ml/Kconfig @@ -0,0 +1,21 @@ +if TARGET_IMX8QXP_AI_ML + +config SYS_BOARD + default "imx8qxp_ai_ml" + +config SYS_VENDOR + default "einfochips" + +config SYS_CONFIG_NAME + default "imx8qxp_ai_ml" + +config SYS_MALLOC_LEN + default 0x240 + +config ENV_SIZE + default 0x1000 + +config ENV_OFFSET + default 0x40 + +endif diff --git a/board/einfochips/imx8qxp_ai_ml/MAINTAINERS b/board/einfochips/imx8qxp_ai_ml/MAINTAINERS new file mode 100644 index 00..add0bd9431 --- /dev/null +++ b/board/einfochips/imx8qxp_ai_ml/MAINTAINERS @@ -0,0 +1,6 @@ +i.MX8QXP AI_ML BOARD +M: Manivannan Sadhasivam +S: Maintained +F: board/einfochips/imx8qxp_ai_ml/ +F: include/configs/imx8qxp_ai_ml.h +F: configs/imx8qxp_ai_ml_defconfig diff --git a/board/einfochips/imx8qxp_ai_ml/Makefile b/board/einfochips/imx8qxp_ai_ml/Makefile new file mode 100644 index 00..e08774dc6e --- /dev/null +++ b/board/einfochips/imx8qxp_ai_ml/Makefile @@ -0,0 +1,8 @@ +# +# Copyright 2019 Linaro Ltd. +# +# SPDX-License-Identifier: GPL-2.0+ +# + +obj-y += imx8qxp_ai_ml.o +obj-$(CONFIG_SPL_BUILD) += spl.o diff --git a/board/einfochips/imx8qxp_ai_ml/README b/board/einfochips/imx8qxp_ai_ml/README new file mode 100644 index 00..488920580f --- /dev/null +++ b/board/einfochips/imx8qxp_ai_ml/README @@ -0,0 +1,49 @@ +U-Boot for the Einfochips i.MX8QXP AI_ML board + +Quick Start +=== + +- Get and Build the ARM Trusted firmware +- Get scfw_tcm.bin and ahab-container.img +- Build U-Boot +- Flash the binary into the SD card +- Boot + +Get and Build the ARM Trusted firmware +== + +$ git clone https://source.codeaurora.org/external/imx/imx-atf +$ cd imx-atf/ +$ git checkout origin/imx_4.9.88_imx8qxp_beta2 -b imx_4.9.88_imx8qxp_beta2 +$ make PLAT=imx8qxp bl31 + +Get scfw_tcm.bin and ahab-container.img +=== + +$ wget https://raw.githubusercontent.com/96boards-ai-ml/binaries/master/mx8qx-aiml-scfw-tcm.bin +$ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.1.bin +$ chmod +x firmware-imx-8.1.bin +$ ./firmware-imx-8.1.bin + +Copy the
Re: [PATCH 1/1] cmd: bdinfo: cleanup phys_addr_t output
Hello Heinrich, Am 28.07.2020 um 17:56 schrieb Heinrich Schuchardt: We currently print the memory size with at least 8 hexadecimal digits. This creates a ragged output on 64 bit boards, e.g. on a Kendryte K210: DRAM bank = 0x0002 -> start= 0x8060 -> size = 0x0020 memstart= 0x memsize = 0x flashstart = 0x flashsize = 0x flashoffset = 0x All other numbers are printed with the number of digits needed for the type ulong. So use this value as minimum number of digits (precision) for printing physical addresses. Signed-off-by: Heinrich Schuchardt --- cmd/bdinfo.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) Reviewed-by: Heiko Schocher bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
RE: [PATCH v4 0/5] add DM based reset driver for SiFive SoC's
Hi Rick,
> -Original Message-
> From: Rick Chen
> Sent: Wednesday, July 29, 2020 7:26 AM
> To: Sagar Kadam
> Cc: U-Boot Mailing List ; Paul Walmsley ( Sifive)
> ; Palmer Dabbelt ; Anup
> Patel ; Atish Patra ; Lukasz
> Majewski ; Pragnesh Patel ;
> bin.m...@windriver.com; Jagan Teki ;
> Simon Glass ; Trevor Woerner ;
> patr...@blueri.se; mbrug...@suse.com; Eugeniy Paltsev
> ; weijie@mediatek.com;
> nsaenzjulie...@suse.de; feste...@gmail.com; Sean Anderson
> ; rick ; Alan Kao
>
> Subject: Re: [PATCH v4 0/5] add DM based reset driver for SiFive SoC's
>
> [External Email] Do not click links or attachments unless you recognize the
> sender and know the content is safe
>
> Hi Sagar
>
> > From: Sagar Kadam [mailto:sagar.ka...@sifive.com]
> > Sent: Tuesday, July 28, 2020 11:19 PM
> > To: u-boot@lists.denx.de
> > Cc: Rick Jian-Zhi Chen(陳建志); Paul Walmsley ( Sifive);
> > pal...@dabbelt.com; anup.pa...@wdc.com; atish.pa...@wdc.com;
> > lu...@denx.de; Pragnesh Patel; bin.m...@windriver.com;
> > ja...@amarulasolutions.com; s...@chromium.org; twoer...@gmail.com;
> > patr...@blueri.se; mbrug...@suse.com; eugeniy.palt...@synopsys.com;
> > weijie@mediatek.com; nsaenzjulie...@suse.de;
> feste...@gmail.com;
> > sean...@gmail.com
> > Subject: RE: [PATCH v4 0/5] add DM based reset driver for SiFive SoC's
> >
> > Hello Rick,
> >
> > > -Original Message-
> > > From: Sagar Kadam
> > > Sent: Monday, July 27, 2020 8:56 PM
> > > To: u-boot@lists.denx.de
> > > Cc: r...@andestech.com; Paul Walmsley ( Sifive)
> > > ; pal...@dabbelt.com;
> anup.pa...@wdc.com;
> > > atish.pa...@wdc.com; lu...@denx.de; Pragnesh Patel
> > > ; bin.m...@windriver.com;
> > > ja...@amarulasolutions.com; s...@chromium.org;
> twoer...@gmail.com;
> > > patr...@blueri.se; mbrug...@suse.com; eugeniy.palt...@synopsys.com;
> > > weijie@mediatek.com; nsaenzjulie...@suse.de;
> feste...@gmail.com;
> > > sean...@gmail.com
> > > Subject: RE: [PATCH v4 0/5] add DM based reset driver for SiFive
> > > SoC's
> > >
> > > Hi Rick,
> > > > -Original Message-
> > > > From: Sagar Kadam
> > > > Sent: Friday, July 24, 2020 2:17 PM
> > > > To: u-boot@lists.denx.de
> > > > Cc: r...@andestech.com; Paul Walmsley ( Sifive)
> > > > ; pal...@dabbelt.com;
> > > anup.pa...@wdc.com;
> > > > atish.pa...@wdc.com; lu...@denx.de; Pragnesh Patel
> > > > ; bin.m...@windriver.com;
> > > > ja...@amarulasolutions.com; s...@chromium.org;
> twoer...@gmail.com;
> > > > patr...@blueri.se; mbrug...@suse.com;
> > > > eugeniy.palt...@synopsys.com; weijie@mediatek.com;
> > > > nsaenzjulie...@suse.de;
> > > feste...@gmail.com;
> > > > sean...@gmail.com; Sagar Kadam
> > > > Subject: [PATCH v4 0/5] add DM based reset driver for SiFive SoC's
> > > >
> > > > The FU540-C000 support in U-Boot is missing DM based reset driver,
> > > > and is handling reset's to sub-system within the prci driver itself.
> > > > The series here adds a generic DM reset driver for SiFive SoC's so
> > > > as to leverage the U-Boot's reset framework and binds the reset
> > > > driver with prci driver.
> > > > The PRCI driver takes care of triggering the consumers reset
> > > > signals appropriately.
> > > >
> > > > Patch 1: Add necessary dt indexes for device reset register.
> > > > Patch 2: Update macro's to use common dt indexes from binding
> header.
> > > > Patch 3: Add reset producer and consumer entries within the device
> tree.
> > > > Patch 4: Add reset dm driver and bind it within prci module.
> > > > Patch 5: Add Kconfig, Makefile entries and enable the driver
> > > >
> > > > This series is re-based on mainline U-Boot commit 5d3a21df6694
> > > > ("Merge
> > > tag
> > > > 'dm-pull-20jul20' of git://git.denx.de/u-boot-dm") and depends on
> > > > [1]
> > > >
> > > > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=190862
> > > >
> > >
> > > I have rebased this series on u-boot/master.
> > > Can you please pull it and let me know if any issues are there.
> > >
> > It seems that u-boot/master is moved ahead and the commit on which this
> series was based is reverted "Revert "Merge tag 'dm-pull-20jul20' of
> git://git.denx.de/u-boot-dm""
> > and will again conflict considering other patch's that are merged in u-
> boot/master.
> > I can rebase it again, but would like to know what you would prefer me to
> rebase on u-boot/master or u-boot-riscv/master?
>
> Yes, it conflict again.
> Applying: configs: reset: fu540: enable dm reset framework for SiFive
> error: patch failed: configs/sifive_fu540_defconfig:21
> error: configs/sifive_fu540_defconfig: patch does not apply Patch failed at
> 0001 configs: reset: fu540: enable dm reset framework for SiFive
>
> You can rebase on u-boot-riscv/master.
>
Thanks for confirmation. I will rebase on u-boot-riscv/master.
BR,
Sagar
> Thanks,
> Rick
>
> >
> > Thanks & BR,
> > Sagar
> >
> > > Thanks & BR,
> > > Sagar
> > >
> > > > History:
> > > > ==
> > > > V4:
> > > > -Rebased the series to u-boot/master.
> > >
RE: [PATCH v4 0/5] add DM based reset driver for SiFive SoC's
Hi Simon,
> -Original Message-
> From: Simon Glass
> Sent: Wednesday, July 29, 2020 12:28 AM
> To: Sagar Kadam
> Cc: u-boot@lists.denx.de; r...@andestech.com; Paul Walmsley ( Sifive)
> ; pal...@dabbelt.com; anup.pa...@wdc.com;
> atish.pa...@wdc.com; lu...@denx.de; Pragnesh Patel
> ; bin.m...@windriver.com;
> ja...@amarulasolutions.com; twoer...@gmail.com; patr...@blueri.se;
> mbrug...@suse.com; eugeniy.palt...@synopsys.com;
> weijie@mediatek.com; nsaenzjulie...@suse.de; feste...@gmail.com;
> sean...@gmail.com
> Subject: Re: [PATCH v4 0/5] add DM based reset driver for SiFive SoC's
>
> [External Email] Do not click links or attachments unless you recognize the
> sender and know the content is safe
>
> Hi Sagar,
>
> On Tue, 28 Jul 2020 at 09:19, Sagar Kadam wrote:
> >
> > Hello Rick,
> >
> > > -Original Message-
> > > From: Sagar Kadam
> > > Sent: Monday, July 27, 2020 8:56 PM
> > > To: u-boot@lists.denx.de
> > > Cc: r...@andestech.com; Paul Walmsley ( Sifive)
> > > ; pal...@dabbelt.com;
> anup.pa...@wdc.com;
> > > atish.pa...@wdc.com; lu...@denx.de; Pragnesh Patel
> > > ; bin.m...@windriver.com;
> > > ja...@amarulasolutions.com; s...@chromium.org;
> twoer...@gmail.com;
> > > patr...@blueri.se; mbrug...@suse.com; eugeniy.palt...@synopsys.com;
> > > weijie@mediatek.com; nsaenzjulie...@suse.de;
> feste...@gmail.com;
> > > sean...@gmail.com
> > > Subject: RE: [PATCH v4 0/5] add DM based reset driver for SiFive
> > > SoC's
> > >
> > > Hi Rick,
> > > > -Original Message-
> > > > From: Sagar Kadam
> > > > Sent: Friday, July 24, 2020 2:17 PM
> > > > To: u-boot@lists.denx.de
> > > > Cc: r...@andestech.com; Paul Walmsley ( Sifive)
> > > > ; pal...@dabbelt.com;
> > > anup.pa...@wdc.com;
> > > > atish.pa...@wdc.com; lu...@denx.de; Pragnesh Patel
> > > > ; bin.m...@windriver.com;
> > > > ja...@amarulasolutions.com; s...@chromium.org;
> twoer...@gmail.com;
> > > > patr...@blueri.se; mbrug...@suse.com;
> > > > eugeniy.palt...@synopsys.com; weijie@mediatek.com;
> > > > nsaenzjulie...@suse.de;
> > > feste...@gmail.com;
> > > > sean...@gmail.com; Sagar Kadam
> > > > Subject: [PATCH v4 0/5] add DM based reset driver for SiFive SoC's
> > > >
> > > > The FU540-C000 support in U-Boot is missing DM based reset driver,
> > > > and is handling reset's to sub-system within the prci driver itself.
> > > > The series here adds a generic DM reset driver for SiFive SoC's so
> > > > as to leverage the U-Boot's reset framework and binds the reset
> > > > driver with prci driver.
> > > > The PRCI driver takes care of triggering the consumers reset
> > > > signals appropriately.
> > > >
> > > > Patch 1: Add necessary dt indexes for device reset register.
> > > > Patch 2: Update macro's to use common dt indexes from binding
> header.
> > > > Patch 3: Add reset producer and consumer entries within the device
> tree.
> > > > Patch 4: Add reset dm driver and bind it within prci module.
> > > > Patch 5: Add Kconfig, Makefile entries and enable the driver
> > > >
> > > > This series is re-based on mainline U-Boot commit 5d3a21df6694
> > > > ("Merge
> > > tag
> > > > 'dm-pull-20jul20' of git://git.denx.de/u-boot-dm") and depends on
> > > > [1]
> > > >
> > > > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=190862
> > > >
> > >
> > > I have rebased this series on u-boot/master.
> > > Can you please pull it and let me know if any issues are there.
> > >
> > It seems that u-boot/master is moved ahead and the commit on which
> > this series was based is reverted "Revert "Merge tag 'dm-pull-20jul20' of
> git://git.denx.de/u-boot-dm""
> > and will again conflict considering other patch's that are merged in u-
> boot/master.
> > I can rebase it again, but would like to know what you would prefer me
> > to rebase on u-boot/master or u-boot-riscv/master?
>
> Can you take another look? The DM stuff landed again yesterday.
>
Yes sure, I will revisit it again.
BR,
Sagar
> Regards,
> Simon
Re: [PATCH v5 6/8] efi_loader: signature: rework for intermediate certificates support
Heinrich,
On Wed, Jul 22, 2020 at 01:00:30PM +0200, Heinrich Schuchardt wrote:
> On 21.07.20 12:35, AKASHI Takahiro wrote:
> > In this commit, efi_signature_verify(with_sigdb) will be re-implemented
> > using pcks7_verify_one() in order to support certificates chain, where
> > the signer's certificate will be signed by an intermediate CA (certificate
> > authority) and the latter's certificate will also be signed by another CA
> > and so on.
> >
> > What we need to do here is to search for certificates in a signature,
> > build up a chain of certificates and verify one by one. pkcs7_verify_one()
> > handles most of these steps except the last one.
> >
> > pkcs7_verify_one() returns, if succeeded, the last certificate to verify,
> > which can be either a self-signed one or one that should be signed by one
> > of certificates in "db". Re-worked efi_signature_verify() will take care
> > of this step.
> >
> > Signed-off-by: AKASHI Takahiro
> > ---
> > include/efi_loader.h | 8 +-
> > lib/efi_loader/Kconfig| 1 +
> > lib/efi_loader/efi_image_loader.c | 2 +-
> > lib/efi_loader/efi_signature.c| 385 ++
> > lib/efi_loader/efi_variable.c | 5 +-
> > 5 files changed, 188 insertions(+), 213 deletions(-)
> >
> > diff --git a/include/efi_loader.h b/include/efi_loader.h
> > index 98944640bee7..df8dc377257c 100644
> > --- a/include/efi_loader.h
> > +++ b/include/efi_loader.h
> > @@ -773,10 +773,10 @@ bool efi_signature_lookup_digest(struct
> > efi_image_regions *regs,
> > bool efi_signature_verify_one(struct efi_image_regions *regs,
> > struct pkcs7_message *msg,
> > struct efi_signature_store *db);
> > -bool efi_signature_verify_with_sigdb(struct efi_image_regions *regs,
> > -struct pkcs7_message *msg,
> > -struct efi_signature_store *db,
> > -struct efi_signature_store *dbx);
> > +bool efi_signature_verify(struct efi_image_regions *regs,
> > + struct pkcs7_message *msg,
> > + struct efi_signature_store *db,
> > + struct efi_signature_store *dbx);
> > bool efi_signature_check_signers(struct pkcs7_message *msg,
> > struct efi_signature_store *dbx);
> >
> > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> > index 6017ffe9a600..bad1a29ba804 100644
> > --- a/lib/efi_loader/Kconfig
> > +++ b/lib/efi_loader/Kconfig
> > @@ -205,6 +205,7 @@ config EFI_SECURE_BOOT
> > select ASYMMETRIC_PUBLIC_KEY_SUBTYPE
> > select X509_CERTIFICATE_PARSER
> > select PKCS7_MESSAGE_PARSER
> > + select PKCS7_VERIFY
> > default n
> > help
> > Select this option to enable EFI secure boot support.
> > diff --git a/lib/efi_loader/efi_image_loader.c
> > b/lib/efi_loader/efi_image_loader.c
> > index d81ae8c93a52..d930811141af 100644
> > --- a/lib/efi_loader/efi_image_loader.c
> > +++ b/lib/efi_loader/efi_image_loader.c
> > @@ -642,7 +642,7 @@ static bool efi_image_authenticate(void *efi, size_t
> > efi_size)
> > }
> >
> > /* try white-list */
> > - if (efi_signature_verify_with_sigdb(regs, msg, db, dbx))
> > + if (efi_signature_verify(regs, msg, db, dbx))
> > continue;
> >
> > debug("Signature was not verified by \"db\"\n");
> > diff --git a/lib/efi_loader/efi_signature.c b/lib/efi_loader/efi_signature.c
> > index 8413d83e343b..7b33a4010fe8 100644
> > --- a/lib/efi_loader/efi_signature.c
> > +++ b/lib/efi_loader/efi_signature.c
> > @@ -10,7 +10,9 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > +#include
> > #include
>
> This line does not exist in origin master. Which patch is missing?
The line is what you deleted when you merged this file while
I said that the header should be directly included because
this file uses an x509 parser function explicitly.
I still believe that it should.
>
> Using sbsigntool 0.9.4 and this whole series applied 'make test' fails
>
> test/py/tests/test_efi_secboot/test_authvar.py F
> test/py/tests/test_efi_secboot/test_signed.py .FF.FF
> test/py/tests/test_efi_secboot/test_signed_intca.py .FF
> test/py/tests/test_efi_secboot/test_unsigned.py ..F
I rebased v5 to your *current* efi-2020-10 and tried to reproduce
the problem but failed. All the test cases passed.
-Takahiro Akashi
> Up to patch 5 make test succeeds. I will take patches 1-5 into my next
> pull-request.
>
> Anyway we have to wait for sbsigntool 0.9.4 in the Docker image and
> Travis CI.
>
> Best regards
>
> Heinrich
>
>
> > #include
> > #include
> > @@ -61,143 +63,6 @@ static bool efi_hash_regions(struct image_region *regs,
> > int count,
> > return true;
> > }
> >
> > -/**
> > - * efi_hash_msg_content - calculate a hash value of contentInfo
> > - * @msg: Signature
> > - *
Re: [RFC 3/4] dtoc: add support for generate stuct udevice_id
Hi Walter,
On Sun, 26 Jul 2020 at 20:16, Walter Lozano wrote:
>
> Hi Simon,
>
> On 26/7/20 11:53, Simon Glass wrote:
> > Hi Walter,
> >
> > On Tue, 7 Jul 2020 at 08:08, Walter Lozano
> > wrote:
> >> Hi Simon
> >>
> >> On 6/7/20 16:21, Simon Glass wrote:
> >>> Hi Walter,
> >>>
> >>> On Fri, 19 Jun 2020 at 15:12, Walter Lozano
> >>> wrote:
> Based on several reports there is an increasing concern in the impact
> of adding additional features to drivers based on compatible strings.
> A good example of this situation is found in [1].
>
> In order to reduce this impact and as an initial step for further
> reduction, propose a new way to declare compatible strings, which allows
> to only include the useful ones.
> >>> What are the useful ones?
> >> The useful ones would be those that are used by the selected DTB by the
> >> current configuration. The idea of this patch is to declare all the
> >> possible compatible strings in a way that dtoc can generate code for
> >> only those which are going to be used, and in this way avoid lots of
> >> #ifdef like the ones shows in
> >>
> >> http://patchwork.ozlabs.org/project/uboot/patch/20200525202429.2146-1-ag...@denx.de/
> >>
> >>
> The idea is to define compatible strings in a way to be easily parsed by
> dtoc, which will be responsible to build struct udevice_id [] based on
> the compatible strings present in the dtb.
>
> Additional features can be easily added, such as define constants
> depending on the presence of compatible strings, which allows to enable
> code blocks only in such cases without the need of adding additional
> configuration options.
>
> [1]
> http://patchwork.ozlabs.org/project/uboot/patch/20200525202429.2146-1-ag...@denx.de/
>
> Signed-off-by: Walter Lozano
> ---
> tools/dtoc/dtb_platdata.py | 32
> 1 file changed, 32 insertions(+)
> >>> I think dtoc should be able to parse the compatible strings as they
> >>> are today - e.g. see the tiny-dm stuff.
> >>
> >> Yes, I agree. My idea is that dtoc parses compatible strings as they are
> >> today but also in this new way. The reason for this is to allow dtoc to
> >> generate the code to include the useful compatible strings. Of course,
> >> this only makes sense if the idea of generating the compatible string
> >> associated code is accepted.
> >>
> >> What do you think?
> > I think this is useful and better than using #ifdef in the source code
> > for this sort of thing. We need a way to specify the driver_data value
> > as well, right?
>
> Yes, I agree, it is better than #ifdef and c/ould give us some extra
> functionality.
>
> What doe you mean by driver_data value? Are you referring to the data
> field? like
>
> static struct esdhc_soc_data usdhc_imx7d_data = {
> .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING
> | ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_HS200
> | ESDHC_FLAG_HS400,
> };
>
Actually I was talking about the .data member in struct udevice_id.
> If that is the case, I was thinking in defining a constant when specific
> compatible strings are enabled by dtoc, based in the above case
>
> #ifdef FSL_ESDHC_IMX_V2
> static struct esdhc_soc_data usdhc_imx7d_data = {
> .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING
> | ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_HS200
> | ESDHC_FLAG_HS400,
> };
> #endif
>
> COMPATIBLE(FSL_ESDHC, "fsl,imx7d-usdhc", _imx7d_data, FSL_ESDHC_IMX_V2)
>
> So when dtoc parses COMPATIBLE and determines that compatible
> "fsl,imx7d-usdhc" should be added it also defines FSL_ESDHC_IMX_V2.
I think we can put that data in the dt-platdata.c file perhaps.
>
> This is alsoAs I comment you in the tread about tiny-dm I think that we
> can save some space following your suggestions, and for instance implement
>
>
> > Re naming, perhaps DT_COMPAT() might be better than COMPATIBLE()? Or
> > even a name that indicates that it is optional, like DT_OPT_COMPAT() ?
> >
> I totally agree, naming is very important, and DT_COMPAT() is much better.
>
> What I don't fully understand is what are the cases for DT_OPT_COMPAT(),
> could you please clarify?
It's just an alternative name, with OPT meaning optional. But I think
we can leave out the OPT.
Regards,
Simon
Please pull u-boot-dm
Hi Tom, The following changes since commit 3b191c56c841596771b4120f09fb556adf958b5c: Merge branch '2020-07-28-Kconfig-migrations' (2020-07-28 18:27:34 -0400) are available in the Git repository at: git://git.denx.de/u-boot-dm.git tags/dm-pull-28jul20 for you to fetch changes up to b9390ce51cb46f4b4acda320e7ea8e0bd120e4b8: dm: remove superfluous comment for union ofnode_union (2020-07-28 19:30:39 -0600) Use binman instead of one of the Rockchip build scripts Refactor to allow any arch to create SPI-flash images New button uclass Dan Murphy (1): dm: Fix build error when OF_CONTROL is not set Heinrich Schuchardt (2): cmd: host: return value of do_host_bind() dm: remove superfluous comment for union ofnode_union Patrick Oppenlander (1): sandbox: enable FIT cipher support in defconfig Philippe Reynes (9): sandbox, test: change hog gpio dm: button: add an uclass for button dm: button: add a driver for button driven by gpio cmd: button: add a new 'button' command sandbox: dtsi: add buttons sandbox64: enable button sandbox: enable button test/py: add tests for the button commands test: dm: add a test for class button Simon Glass (30): buildman: Allow using older versions of genboardscfg.py buildman: Correct the testOutputDir() unit test buildman: Show the build rate at the end x86: Change how selection of ROMs works rockchip: Allow Bob to use SPI boot Makefile: Allow building .rom files for non-x86 boards rockchip: jerry: Add serial support rockchip: bob: Support SPI-flash booting rockchip: Enable building a SPI ROM image on jerry rockchip: Enable building a SPI ROM image on bob tegra: Drop the unused non-binman code tegra: Don't enable binman on ARMv8 SoCs Makefile: Rename ALL-y to INPUTS-y powerpc: mpc85xx: Only enable binman when it is needed x86: Makefile: Drop explicit targets built by binman x86: Drop CONFIG_BUILD_ROM and repurpose BUILD_ROM sunxi: Makefile: Drop explicit targets built by binman tegra: Makefile: Drop explicit targets built by binman mediatek: Makefile: Drop explicit targets built by binman Makefile: Move CONFIG_TOOLS_DEBUG check to later Makefile: Fix a long line in cmd_mkfitimage Makefile: Allow CONFIG_SPL_FIT_GENERATOR to be empty Makefile: Warn against using CONFIG_SPL_FIT_GENERATOR rockchip: Convert evb-rk3288 over to use binman rockchip: Convert evb-rk3229 over to use binman rockchip: Drop the fit_spl_optee.sh script x86: Move the fdtmap away from the binary blobs x86: chromebook_link64: Correct the image layout x86: chromebook_panther: Correct the image layout x86: chromebook_samus_tpl: Correct the image layout Walter Lozano (4): dtoc: add coverage test for unicode error dtoc: look for compatible string aliases in driver list drivers: avoid using aliases on drivers when OF_PLATDATA is enabled dtoc: remove compatible string aliases support chenshuo (1): find dtb in android boot image with header version 2 during bootm Kconfig | 29 +++- Makefile | 169 +- arch/Kconfig | 1 + arch/arm/config.mk| 10 +-- arch/arm/dts/rk3288-u-boot.dtsi | 25 +++ arch/arm/dts/rk3399-gru-u-boot.dtsi | 4 ++ arch/arm/dts/rk3399-gru.dtsi | 2 +- arch/arm/dts/rk3399-u-boot.dtsi | 27 arch/arm/dts/rockchip-optee.dtsi | 64 ++ arch/arm/dts/rockchip-u-boot.dtsi | 10 ++- arch/arm/mach-at91/config.mk | 2 +- arch/arm/mach-davinci/config.mk | 2 +- arch/arm/mach-k3/config.mk| 10 +-- arch/arm/mach-keystone/config.mk | 4 +- arch/arm/mach-omap2/config.mk | 28 arch/arm/mach-rmobile/Makefile| 2 +- arch/arm/mach-rockchip/Kconfig| 9 +++ arch/arm/mach-rockchip/fit_spl_optee.sh | 84 --- arch/arm/mach-rockchip/rk3288/Kconfig | 3 + arch/arm/mach-rockchip/rk3399/Kconfig | 2 + arch/arm/mach-rockchip/spl.c | 3 +- arch/arm/mach-stm32mp/config.mk | 4 +- arch/arm/mach-tegra/Kconfig | 2 +- arch/powerpc/Kconfig | 2 +- arch/sandbox/dts/sandbox.dtsi | 14 arch/sandbox/dts/test.dts | 22 -- arch/x86/Kconfig | 11 ++- arch/x86/cpu/quark/Kconfig| 1 + arch/x86/dts/u-boot.dtsi | 10 ++- board/BuR/brppt1/config.mk| 4
[PATCH v2] travis: update sbsigntools to 0.9.4
This version of sbsigntools is a prerequisite in testing "intermediate
certificates" support as part of UEFI secure boot as I added '--addcert'
option to 'sbsign' command:
===
commit 7d6210e4b1fd
Author: AKASHI Takahiro
Date: Thu Jun 4 16:50:22 2020 +0900
sbsign: allow for adding intermediate certificates
===
Please note that, even after this patch is applied, UEFI secure boot
test can fail due to an issue with make-virt-fs.
Signed-off-by: AKASHI Takahiro
---
v2:
* move the code to 'build' section per Tom
v1:
* execute 'make install' with sudo
---
.travis.yml | 20
1 file changed, 20 insertions(+)
diff --git a/.travis.yml b/.travis.yml
index 1ff140855ea3..dfc110a403b2 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -52,6 +52,14 @@ addons:
- sbsigntool
- fakeroot
- mtd-utils
+- automake
+- binutils-dev
+- gnu-efi
+- help2man
+- libguestfs-tools
+- linux-image-kvm
+- pkg-config
+- uuid-dev
install:
# Clone uboot-test-hooks
@@ -112,6 +120,18 @@ before_script:
./tools/buildman/buildman --fetch-arch riscv32 &&
./tools/buildman/buildman --fetch-arch riscv64;
fi
+ # Build sbsigntools, 0.9.4
+ - if [[ "${TEST_PY_BD}" != "" ]]; then
+ git clone
https://git.kernel.org/pub/scm/linux/kernel/git/jejb/sbsigntools.git
/tmp/sbsigntools &&
+ pushd /tmp/sbsigntools &&
+ git checkout -b latest v0.9.4 &&
+ ./autogen.sh &&
+ ./configure &&
+ make &&
+ sudo make install &&
+ popd
+fi
+
- if [[ "${QEMU_TARGET}" != "" ]]; then
git clone git://git.qemu.org/qemu.git /tmp/qemu;
pushd /tmp/qemu;
--
2.27.0
[PATCH v1 3/3] pico-imx6ul: convert ethernet function to DM_ETH
From: Wig Cheng
- Remove pinmux definition from pico-imx6ul.c
- Enable NET_RANDOM_ETHADDR for temporary solution, because micrel_ksz8xxx
driver does not support DM_ETH yet, so cannot read MAC address directly.
Before enable DM_ETH:
Net: FEC [PRIME]
After enable DM_ETH:
Net:
Warning: using random MAC address - ca:3f:43:8f:67:d4
eth1: ethernet@20b4000
Here is the test commands:
=> dhcp
BOOTP broadcast 1
DHCP client bound to address 10.88.88.94 (139 ms)
*** ERROR: `serverip' not set
Cannot autoload with TFTPGET
=> ping 8.8.8.8
Using ethernet@20b4000 device
host 8.8.8.8 is alive
Signed-off-by: Wig Cheng
---
board/technexion/pico-imx6ul/pico-imx6ul.c | 53 --
configs/pico-imx6ul_defconfig | 2 +
2 files changed, 2 insertions(+), 53 deletions(-)
diff --git a/board/technexion/pico-imx6ul/pico-imx6ul.c
b/board/technexion/pico-imx6ul/pico-imx6ul.c
index 5d6be26faa..126823fce0 100644
--- a/board/technexion/pico-imx6ul/pico-imx6ul.c
+++ b/board/technexion/pico-imx6ul/pico-imx6ul.c
@@ -18,7 +18,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -39,61 +38,9 @@ DECLARE_GLOBAL_DATA_PTR;
#define MDIO_PAD_CTRL (PAD_CTL_PUS_100K_UP | PAD_CTL_PUE | \
PAD_CTL_DSE_48ohm | PAD_CTL_SRE_FAST | PAD_CTL_ODE)
-#define ENET_PAD_CTRL (PAD_CTL_PUS_100K_UP | PAD_CTL_PUE | \
- PAD_CTL_SPEED_HIGH | \
- PAD_CTL_DSE_48ohm | PAD_CTL_SRE_FAST)
-
-#define ENET_CLK_PAD_CTRL (PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST)
-
#define LCD_PAD_CTRL(PAD_CTL_HYS | PAD_CTL_PUS_100K_UP | PAD_CTL_PUE | \
PAD_CTL_PKE | PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm)
-#define RMII_PHY_RESET IMX_GPIO_NR(1, 28)
-
-static iomux_v3_cfg_t const fec_pads[] = {
- MX6_PAD_ENET1_TX_EN__ENET2_MDC | MUX_PAD_CTRL(MDIO_PAD_CTRL),
- MX6_PAD_ENET1_TX_DATA1__ENET2_MDIO | MUX_PAD_CTRL(MDIO_PAD_CTRL),
- MX6_PAD_ENET2_TX_DATA0__ENET2_TDATA00 | MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_ENET2_TX_DATA1__ENET2_TDATA01 | MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_ENET2_TX_CLK__ENET2_REF_CLK2|
MUX_PAD_CTRL(ENET_CLK_PAD_CTRL),
- MX6_PAD_ENET2_TX_EN__ENET2_TX_EN| MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_ENET2_RX_DATA0__ENET2_RDATA00 | MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_ENET2_RX_DATA1__ENET2_RDATA01 | MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_ENET2_RX_EN__ENET2_RX_EN| MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_ENET2_RX_ER__ENET2_RX_ER| MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_UART4_TX_DATA__GPIO1_IO28 | MUX_PAD_CTRL(NO_PAD_CTRL),
-};
-
-static void setup_iomux_fec(void)
-{
- imx_iomux_v3_setup_multiple_pads(fec_pads, ARRAY_SIZE(fec_pads));
-}
-
-int board_eth_init(struct bd_info *bis)
-{
- setup_iomux_fec();
-
- gpio_request(RMII_PHY_RESET, "enet_phy_reset");
- gpio_direction_output(RMII_PHY_RESET, 0);
- /*
-* According to KSZ8081MNX-RNB manual:
-* For warm reset, the reset (RST#) pin should be asserted low for a
-* minimum of 500μs. The strap-in pin values are read and updated
-* at the de-assertion of reset.
-*/
- udelay(500);
-
- gpio_direction_output(RMII_PHY_RESET, 1);
- /*
-* According to KSZ8081MNX-RNB manual:
-* After the de-assertion of reset, wait a minimum of 100μs before
-* starting programming on the MIIM (MDC/MDIO) interface.
-*/
- udelay(100);
-
- return fecmxc_initialize(bis);
-}
-
static int setup_fec(void)
{
struct iomuxc *const iomuxc_regs = (struct iomuxc *)IOMUXC_BASE_ADDR;
diff --git a/configs/pico-imx6ul_defconfig b/configs/pico-imx6ul_defconfig
index f02d370b7d..432ac0cff0 100644
--- a/configs/pico-imx6ul_defconfig
+++ b/configs/pico-imx6ul_defconfig
@@ -44,6 +44,7 @@ CONFIG_OF_CONTROL=y
CONFIG_ENV_OVERWRITE=y
CONFIG_ENV_IS_IN_MMC=y
CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_NET_RANDOM_ETHADDR=y
CONFIG_DFU_MMC=y
CONFIG_USB_FUNCTION_FASTBOOT=y
CONFIG_FASTBOOT_BUF_SIZE=0x1000
@@ -57,6 +58,7 @@ CONFIG_FSL_USDHC=y
CONFIG_PHYLIB=y
CONFIG_PHY_MICREL=y
CONFIG_PHY_MICREL_KSZ8XXX=y
+CONFIG_DM_ETH=y
CONFIG_MII=y
CONFIG_PINCTRL=y
CONFIG_PINCTRL_IMX6=y
--
2.17.1
[PATCH v1 2/3] configs: pico-imx6ul: convert DM_VIDEO
From: Wig Cheng Fix compile warning messages. Signed-off-by: Wig Cheng --- configs/pico-imx6ul_defconfig | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/configs/pico-imx6ul_defconfig b/configs/pico-imx6ul_defconfig index e8cbf3bc1e..f02d370b7d 100644 --- a/configs/pico-imx6ul_defconfig +++ b/configs/pico-imx6ul_defconfig @@ -75,4 +75,8 @@ CONFIG_USB_GADGET_MANUFACTURER="FSL" CONFIG_USB_GADGET_VENDOR_NUM=0x0525 CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 CONFIG_CI_UDC=y -CONFIG_VIDEO=y +CONFIG_DM_VIDEO=y +CONFIG_VIDEO_PCI_DEFAULT_FB_SIZE=0x0 +# CONFIG_CMD_VIDCONSOLE is not set +# CONFIG_VIDEO_BPP8 is not set +# CONFIG_VIDEO_BPP16 is not set -- 2.17.1
Re: [PATCH v2 06/18] arm: mach-k3: sysfw-loader: Add support for rom loading sysfw image
On 27/07/20 10:47 pm, Suman Anna wrote: > Hi Lokesh, > > On 7/27/20 4:45 AM, Lokesh Vutla wrote: >> Starting J7200 SoC, ROM supports for loading sysfw directly from boot >> image. In such cases, SPL need not load sysfw from boot media, but need >> to receive boot notification message from sysfw. So separate out >> remoteproc calls for system controller from sysfw loader and just >> receive the boot notification if sysfw is already loaded. >> >> Signed-off-by: Lokesh Vutla >> --- >> arch/arm/mach-k3/am6_init.c | 2 +- >> arch/arm/mach-k3/include/mach/sysfw-loader.h | 4 +- >> arch/arm/mach-k3/j721e_init.c | 2 +- >> arch/arm/mach-k3/sysfw-loader.c | 56 +--- >> 4 files changed, 43 insertions(+), 21 deletions(-) >> >> diff --git a/arch/arm/mach-k3/am6_init.c b/arch/arm/mach-k3/am6_init.c >> index abdec76d73..4250ac355b 100644 >> --- a/arch/arm/mach-k3/am6_init.c >> +++ b/arch/arm/mach-k3/am6_init.c >> @@ -155,7 +155,7 @@ void board_init_f(ulong dummy) >> * Load, start up, and configure system controller firmware while >> * also populating the SYSFW post-PM configuration callback hook. >> */ >> - k3_sysfw_loader(k3_mmc_stop_clock, k3_mmc_restart_clock); >> + k3_sysfw_loader(false, k3_mmc_stop_clock, k3_mmc_restart_clock); >> /* Prepare console output */ >> preloader_console_init(); >> diff --git a/arch/arm/mach-k3/include/mach/sysfw-loader.h >> b/arch/arm/mach-k3/include/mach/sysfw-loader.h >> index 6f5612b4fd..b23a9e821e 100644 >> --- a/arch/arm/mach-k3/include/mach/sysfw-loader.h >> +++ b/arch/arm/mach-k3/include/mach/sysfw-loader.h >> @@ -7,6 +7,8 @@ >> #ifndef _SYSFW_LOADER_H_ >> #define _SYSFW_LOADER_H_ >> -void k3_sysfw_loader(void (*config_pm_pre_callback)(void), void >> (*config_pm_done_callback)(void)); >> +void k3_sysfw_loader(bool rom_loaded_sysfw, >> + void (*config_pm_pre_callback)(void), >> + void (*config_pm_done_callback)(void)); >> #endif >> diff --git a/arch/arm/mach-k3/j721e_init.c b/arch/arm/mach-k3/j721e_init.c >> index 2010cab1d1..461a9d7f8f 100644 >> --- a/arch/arm/mach-k3/j721e_init.c >> +++ b/arch/arm/mach-k3/j721e_init.c >> @@ -174,7 +174,7 @@ void board_init_f(ulong dummy) >> * callback hook, effectively switching on (or over) the console >> * output. >> */ >> - k3_sysfw_loader(k3_mmc_stop_clock, k3_mmc_restart_clock); >> + k3_sysfw_loader(false, k3_mmc_stop_clock, k3_mmc_restart_clock); > > Any reason why you want to add the new argument at the front, rather than the > end which is typical? Yes this was intentional. It made more sense to get the sysfw state as a first parameter and then look for other parameters, > >> /* Prepare console output */ >> preloader_console_init(); >> diff --git a/arch/arm/mach-k3/sysfw-loader.c >> b/arch/arm/mach-k3/sysfw-loader.c >> index 513be09c68..f62bfa995c 100644 >> --- a/arch/arm/mach-k3/sysfw-loader.c >> +++ b/arch/arm/mach-k3/sysfw-loader.c >> @@ -32,6 +32,12 @@ DECLARE_GLOBAL_DATA_PTR; >> #define SYSFW_CFG_RM "rm-cfg.bin" >> #define SYSFW_CFG_SEC "sec-cfg.bin" >> +/* >> + * It is assumed that remoteproc device 0 is the corresponding >> + * system-controller that runs SYSFW. Make sure DT reflects the same. >> + */ >> +#define K3_SYSTEM_CONTROLLER_RPROC_ID 0 >> + >> static bool sysfw_loaded; >> static void *sysfw_load_address; >> @@ -71,6 +77,26 @@ static int fit_get_data_by_name(const void *fit, int >> images, const char *name, >> return fit_image_get_data(fit, node_offset, addr, size); >> } >> +static void k3_start_system_controller(int rproc_id, bool rproc_loaded, >> + ulong addr, ulong size) > > Are you expecting the SYSTEM_CONTROLLER_RPROC_ID to be a different value from > 0? > Do you really need the rproc_id argument, rather than directly using it in > code? I didn't want to hardcode in multiple places and I cannot guarantee if it can change in future. So I added it as a future proof. Thanks and regards, Lokesh
RE: [PATCH] mmc: am654_sdhci: Use MMC_MODES_END value instead of hardcoded value
> Subject: [PATCH] mmc: am654_sdhci: Use MMC_MODES_END value instead
> of hardcoded value
>
> The hardcoded array size leads to array overflows with changes in speed
> modes enum in mmc core. Use MMC_MODES_END for otap_del_sel array
> declaration to fix this.
>
> Signed-off-by: Faiz Abbas
> ---
> drivers/mmc/am654_sdhci.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/am654_sdhci.c b/drivers/mmc/am654_sdhci.c index
> cbc531dc53..82abf484e4 100644
> --- a/drivers/mmc/am654_sdhci.c
> +++ b/drivers/mmc/am654_sdhci.c
> @@ -75,7 +75,7 @@ struct am654_sdhci_plat {
> struct mmc mmc;
> struct regmap *base;
> bool non_removable;
> - u32 otap_del_sel[11];
> + u32 otap_del_sel[MMC_MODES_END];
> u32 trm_icp;
> u32 drv_strength;
> u32 strb_sel;
Reviewed-by: Peng Fan
> --
> 2.17.1
[PATCH v1 1/3] configs: pico-imx6ul: convert DM_USB
From: Wig Cheng Here is the test commands: => ums 0 mmc 0 UMS: LUN 0, dev 0, hwpart 0, sector 0x0, count 0x71 Signed-off-by: Wig Cheng --- configs/pico-imx6ul_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/pico-imx6ul_defconfig b/configs/pico-imx6ul_defconfig index 72d2af19f4..49e406316a 100644 --- a/configs/pico-imx6ul_defconfig +++ b/configs/pico-imx6ul_defconfig @@ -67,6 +67,8 @@ CONFIG_DM_REGULATOR_FIXED=y CONFIG_DM_REGULATOR_GPIO=y CONFIG_MXC_UART=y CONFIG_USB=y +CONFIG_DM_USB=y +# CONFIG_USB_STORAGE is not set CONFIG_USB_GADGET=y CONFIG_USB_GADGET_MANUFACTURER="FSL" CONFIG_USB_GADGET_VENDOR_NUM=0x0525 -- 2.17.1
[PATCH v2] configs: pico-imx6: convert ethernet function to DM_ETH
From: Wig Cheng Before enable _DM_ETH: Net: FEC [PRIME] After enable DM_ETH: Net: eth0: ethernet@2188000 Here is the test commands: => dhcp BOOTP broadcast 1 DHCP client bound to address 10.88.88.152 (146 ms) *** ERROR: `serverip' not set Cannot autoload with TFTPGET => ping 8.8.8.8 Using ethernet@2188000 device host 8.8.8.8 is alive Signed-off-by: Wig Cheng --- configs/pico-imx6_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/pico-imx6_defconfig b/configs/pico-imx6_defconfig index a1773e4c7e..138fdfae53 100644 --- a/configs/pico-imx6_defconfig +++ b/configs/pico-imx6_defconfig @@ -65,6 +65,8 @@ CONFIG_DM_MMC=y CONFIG_FSL_USDHC=y CONFIG_PHYLIB=y CONFIG_PHY_ATHEROS=y +CONFIG_DM_ETH=y +CONFIG_RGMII=y CONFIG_PINCTRL=y CONFIG_PINCTRL_IMX6=y CONFIG_MXC_UART=y -- 2.17.1
[PATCH v2 3/5] dm: Rename DM test flags to make them more generic
The test flags used by driver model are currently not available to other
tests. Rather than creating two sets of flags, make these flags generic
by changing the DM_ prefix to UT_ and moving them to the test.h header.
This will allow adding other test flags without confusion.
Signed-off-by: Simon Glass
---
(no changes since v1)
doc/README.commands | 2 +-
include/dm/test.h | 9
include/test/test.h | 10 +
test/dm/acpi.c | 28 -
test/dm/acpi_dp.c | 2 +-
test/dm/acpigen.c | 18
test/dm/adc.c | 16 +++---
test/dm/audio.c | 2 +-
test/dm/axi.c | 6 +++---
test/dm/blk.c | 10 -
test/dm/board.c | 2 +-
test/dm/bootcount.c | 2 +-
test/dm/bus.c | 26 +++
test/dm/cache.c | 2 +-
test/dm/clk.c | 6 +++---
test/dm/clk_ccf.c | 2 +-
test/dm/core.c | 30 +--
test/dm/cpu.c | 2 +-
test/dm/devres.c| 12 +--
test/dm/dma.c | 6 +++---
test/dm/dsi_host.c | 2 +-
test/dm/eth.c | 16 +++---
test/dm/fdtdec.c| 4 ++--
test/dm/firmware.c | 2 +-
test/dm/gpio.c | 20 +-
test/dm/hwspinlock.c| 2 +-
test/dm/i2c.c | 16 +++---
test/dm/i2s.c | 2 +-
test/dm/irq.c | 10 -
test/dm/led.c | 12 +--
test/dm/mailbox.c | 2 +-
test/dm/mdio.c | 2 +-
test/dm/mdio_mux.c | 2 +-
test/dm/misc.c | 2 +-
test/dm/mmc.c | 4 ++--
test/dm/nop.c | 2 +-
test/dm/ofnode.c| 12 +--
test/dm/ofread.c| 2 +-
test/dm/osd.c | 4 ++--
test/dm/p2sb.c | 2 +-
test/dm/panel.c | 2 +-
test/dm/pch.c | 4 ++--
test/dm/pci.c | 26 +++
test/dm/pci_ep.c| 2 +-
test/dm/phy.c | 6 +++---
test/dm/pmc.c | 2 +-
test/dm/pmic.c | 10 -
test/dm/power-domain.c | 2 +-
test/dm/pwm.c | 2 +-
test/dm/ram.c | 2 +-
test/dm/regmap.c| 10 -
test/dm/regulator.c | 20 +-
test/dm/remoteproc.c| 4 ++--
test/dm/reset.c | 6 +++---
test/dm/rng.c | 2 +-
test/dm/rtc.c | 14 ++---
test/dm/serial.c| 2 +-
test/dm/sf.c| 4 ++--
test/dm/simple-pm-bus.c | 2 +-
test/dm/smem.c | 2 +-
test/dm/soc.c | 2 +-
test/dm/sound.c | 4 ++--
test/dm/spi.c | 4 ++--
test/dm/spmi.c | 6 +++---
test/dm/syscon-reset.c | 2 +-
test/dm/syscon.c| 6 +++---
test/dm/sysreset.c | 8 +++
test/dm/tee.c | 2 +-
test/dm/test-fdt.c | 46 -
test/dm/test-main.c | 10 -
test/dm/timer.c | 2 +-
test/dm/usb.c | 12 +--
test/dm/video.c | 26 +++
test/dm/virtio.c| 8 +++
test/dm/wdt.c | 2 +-
test/lib/lmb.c | 18
76 files changed, 298 insertions(+), 297 deletions(-)
diff --git a/doc/README.commands b/doc/README.commands
index 229f86d8fb2..22ab063fdc0 100644
--- a/doc/README.commands
+++ b/doc/README.commands
@@ -183,4 +183,4 @@ static int dm_test_acpi_cmd_items(struct unit_test_state
*uts)
return 0;
}
-DM_TEST(dm_test_acpi_cmd_items, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+DM_TEST(dm_test_acpi_cmd_items, UT_TESTF_SCAN_PDATA | UT_TESTF_SCAN_FDT);
diff --git a/include/dm/test.h b/include/dm/test.h
index d39686cde28..f86f9b44733 100644
--- a/include/dm/test.h
+++ b/include/dm/test.h
@@ -147,15 +147,6 @@ struct dm_test_state {
struct udevice *removed;
};
-/* Test flags for each test */
-enum {
- DM_TESTF_SCAN_PDATA = 1 << 0, /* test needs platform data */
- DM_TESTF_PROBE_TEST = 1 << 1, /* probe test uclass */
- DM_TESTF_SCAN_FDT = 1 << 2, /* scan device tree */
- DM_TESTF_FLAT_TREE = 1 << 3, /* test needs flat DT */
- DM_TESTF_LIVE_TREE = 1 << 4, /* needs live device tree */
-};
-
/* Declare a new driver model test */
#define DM_TEST(_name, _flags) UNIT_TEST(_name, _flags, dm_test)
diff --git a/include/test/test.h b/include/test/test.h
index 029288de880..ff92c39006b 100644
--- a/include/test/test.h
+++ b/include/test/test.h
@@ -7,6 +7,7 @@
#define __TEST_TEST_H
#include
+#include
/*
* struct unit_test_state - Entire state of test system
@@ -27,6 +28,15 @@ struct unit_test_state {
char actual_str[256];
};
+/* Test flags for each test */
+enum {
+ UT_TESTF_SCAN_PDATA = BIT(0), /* test needs platform data */
+ UT_TESTF_PROBE_TEST = BIT(1), /* probe test uclass */
+
Re: [PATCH v4 0/5] add DM based reset driver for SiFive SoC's
Hi Sagar
> From: Sagar Kadam [mailto:sagar.ka...@sifive.com]
> Sent: Tuesday, July 28, 2020 11:19 PM
> To: u-boot@lists.denx.de
> Cc: Rick Jian-Zhi Chen(陳建志); Paul Walmsley ( Sifive); pal...@dabbelt.com;
> anup.pa...@wdc.com; atish.pa...@wdc.com; lu...@denx.de; Pragnesh Patel;
> bin.m...@windriver.com; ja...@amarulasolutions.com; s...@chromium.org;
> twoer...@gmail.com; patr...@blueri.se; mbrug...@suse.com;
> eugeniy.palt...@synopsys.com; weijie@mediatek.com;
> nsaenzjulie...@suse.de; feste...@gmail.com; sean...@gmail.com
> Subject: RE: [PATCH v4 0/5] add DM based reset driver for SiFive SoC's
>
> Hello Rick,
>
> > -Original Message-
> > From: Sagar Kadam
> > Sent: Monday, July 27, 2020 8:56 PM
> > To: u-boot@lists.denx.de
> > Cc: r...@andestech.com; Paul Walmsley ( Sifive)
> > ; pal...@dabbelt.com; anup.pa...@wdc.com;
> > atish.pa...@wdc.com; lu...@denx.de; Pragnesh Patel
> > ; bin.m...@windriver.com;
> > ja...@amarulasolutions.com; s...@chromium.org; twoer...@gmail.com;
> > patr...@blueri.se; mbrug...@suse.com; eugeniy.palt...@synopsys.com;
> > weijie@mediatek.com; nsaenzjulie...@suse.de; feste...@gmail.com;
> > sean...@gmail.com
> > Subject: RE: [PATCH v4 0/5] add DM based reset driver for SiFive SoC's
> >
> > Hi Rick,
> > > -Original Message-
> > > From: Sagar Kadam
> > > Sent: Friday, July 24, 2020 2:17 PM
> > > To: u-boot@lists.denx.de
> > > Cc: r...@andestech.com; Paul Walmsley ( Sifive)
> > > ; pal...@dabbelt.com;
> > anup.pa...@wdc.com;
> > > atish.pa...@wdc.com; lu...@denx.de; Pragnesh Patel
> > > ; bin.m...@windriver.com;
> > > ja...@amarulasolutions.com; s...@chromium.org; twoer...@gmail.com;
> > > patr...@blueri.se; mbrug...@suse.com; eugeniy.palt...@synopsys.com;
> > > weijie@mediatek.com; nsaenzjulie...@suse.de;
> > feste...@gmail.com;
> > > sean...@gmail.com; Sagar Kadam
> > > Subject: [PATCH v4 0/5] add DM based reset driver for SiFive SoC's
> > >
> > > The FU540-C000 support in U-Boot is missing DM based reset driver,
> > > and is handling reset's to sub-system within the prci driver itself.
> > > The series here adds a generic DM reset driver for SiFive SoC's so
> > > as to leverage the U-Boot's reset framework and binds the reset
> > > driver with prci driver.
> > > The PRCI driver takes care of triggering the consumers reset signals
> > > appropriately.
> > >
> > > Patch 1: Add necessary dt indexes for device reset register.
> > > Patch 2: Update macro's to use common dt indexes from binding header.
> > > Patch 3: Add reset producer and consumer entries within the device tree.
> > > Patch 4: Add reset dm driver and bind it within prci module.
> > > Patch 5: Add Kconfig, Makefile entries and enable the driver
> > >
> > > This series is re-based on mainline U-Boot commit 5d3a21df6694
> > > ("Merge
> > tag
> > > 'dm-pull-20jul20' of git://git.denx.de/u-boot-dm") and depends on
> > > [1]
> > >
> > > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=190862
> > >
> >
> > I have rebased this series on u-boot/master.
> > Can you please pull it and let me know if any issues are there.
> >
> It seems that u-boot/master is moved ahead and the commit on which this
> series was based is reverted "Revert "Merge tag 'dm-pull-20jul20' of
> git://git.denx.de/u-boot-dm""
> and will again conflict considering other patch's that are merged in
> u-boot/master.
> I can rebase it again, but would like to know what you would prefer me to
> rebase on u-boot/master or u-boot-riscv/master?
Yes, it conflict again.
Applying: configs: reset: fu540: enable dm reset framework for SiFive
error: patch failed: configs/sifive_fu540_defconfig:21
error: configs/sifive_fu540_defconfig: patch does not apply
Patch failed at 0001 configs: reset: fu540: enable dm reset framework for SiFive
You can rebase on u-boot-riscv/master.
Thanks,
Rick
>
> Thanks & BR,
> Sagar
>
> > Thanks & BR,
> > Sagar
> >
> > > History:
> > > ==
> > > V4:
> > > -Rebased the series to u-boot/master.
> > >
> > > V3:
> > > -Add reset indexes in separate dt binding header instead of
> > > updating the clock dt binding header which is synced from Linux
> > >
> > > V2:
> > > -Removed extra character in commit log of 2nd patch
> > >
> > > V1:
> > > -Base version.
> > >
> > > Sagar Shrikant Kadam (5):
> > > dt-bindings: prci: add indexes for reset signals available in prci
> > > fu540: prci: use common reset indexes defined in binding header
> > > fu540: dtsi: add reset producer and consumer entries
> > > sifive: reset: add DM based reset driver for SiFive SoC's
> > > configs: reset: fu540: enable dm reset framework for SiFive
> > >
> > > arch/riscv/dts/fu540-c000-u-boot.dtsi | 12 +++
> > > arch/riscv/include/asm/arch-fu540/reset.h | 13 +++
> > > configs/sifive_fu540_defconfig| 2 +
> > > drivers/clk/sifive/fu540-prci.c | 90 ++--
> > > drivers/reset/Kconfig | 9 ++
> > >
[PATCH v2 2/5] console: Always define the console-recording functions
On boards without console recording these function are currently missing.
It is more convenient for them to be present but to return dummy values.
That way if we know that a test needs recording, we can check if it is
available, and skip the test if not, while avoiding #ifdefs.
Update the header file according and adjust console_record_reset_enable()
to return an error if recording is not available.
Signed-off-by: Simon Glass
---
(no changes since v1)
common/console.c | 4 +++-
include/console.h | 40 +++-
2 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/common/console.c b/common/console.c
index 07c483f820e..8e50af1f9d2 100644
--- a/common/console.c
+++ b/common/console.c
@@ -635,10 +635,12 @@ void console_record_reset(void)
membuff_purge((struct membuff *)>console_in);
}
-void console_record_reset_enable(void)
+int console_record_reset_enable(void)
{
console_record_reset();
gd->flags |= GD_FLG_RECORD;
+
+ return 0;
}
int console_record_readline(char *str, int maxlen)
diff --git a/include/console.h b/include/console.h
index 4c6b8f2614c..432f892b6cc 100644
--- a/include/console.h
+++ b/include/console.h
@@ -8,6 +8,7 @@
#define __CONSOLE_H
#include
+#include
extern char console_buffer[];
@@ -21,11 +22,14 @@ void clear_ctrlc(void); /* clear the Control-C
condition */
int disable_ctrlc(int);/* 1 to disable, 0 to enable Control-C detect */
int confirm_yesno(void);/* 1 if input is "y", "Y", "yes" or "YES" */
+#ifdef CONFIG_CONSOLE_RECORD
/**
* console_record_init() - set up the console recording buffers
*
* This should be called as soon as malloc() is available so that the maximum
* amount of console output can be recorded.
+ *
+ * @return 0 if OK, -ENOMEM if out of memory
*/
int console_record_init(void);
@@ -40,8 +44,10 @@ void console_record_reset(void);
* console_record_reset_enable() - reset and enable the console buffers
*
* This should be called to enable the console buffer.
+ *
+ * @return 0 (always)
*/
-void console_record_reset_enable(void);
+int console_record_reset_enable(void);
/**
* console_record_readline() - Read a line from the console output
@@ -61,6 +67,38 @@ int console_record_readline(char *str, int maxlen);
* @return available bytes (0 if empty)
*/
int console_record_avail(void);
+#else
+static inline int console_record_init(void)
+{
+ /* Always succeed, since it is not enabled */
+
+ return 0;
+}
+
+static inline void console_record_reset(void)
+{
+ /* Nothing to do here */
+}
+
+static inline int console_record_reset_enable(void)
+{
+ /* Cannot enable it as it is not supported */
+ return -ENOSYS;
+}
+
+static inline int console_record_readline(char *str, int maxlen)
+{
+ /* Nothing to read */
+ return 0;
+}
+
+static inline int console_record_avail(void)
+{
+ /* There is never anything available */
+ return 0;
+}
+
+#endif /* !CONFIG_CONSOLE_RECORD */
/**
* console_announce_r() - print a U-Boot console on non-serial consoles
--
2.28.0.rc0.142.g3c755180ce-goog
[PATCH v2 4/5] test: Add a flag for tests that need console recording
Allow tests that need console recording to be marked, so they can be
skipped if it is not available.
Signed-off-by: Simon Glass
---
(no changes since v1)
include/test/test.h | 1 +
test/cmd_ut.c | 10 ++
2 files changed, 11 insertions(+)
diff --git a/include/test/test.h b/include/test/test.h
index ff92c39006b..67c7d69d488 100644
--- a/include/test/test.h
+++ b/include/test/test.h
@@ -35,6 +35,7 @@ enum {
UT_TESTF_SCAN_FDT = BIT(2), /* scan device tree */
UT_TESTF_FLAT_TREE = BIT(3), /* test needs flat DT */
UT_TESTF_LIVE_TREE = BIT(4), /* needs live device tree */
+ UT_TESTF_CONSOLE_REC= BIT(5), /* needs console recording */
};
/**
diff --git a/test/cmd_ut.c b/test/cmd_ut.c
index cc9543c315c..1963f3792cf 100644
--- a/test/cmd_ut.c
+++ b/test/cmd_ut.c
@@ -6,6 +6,7 @@
#include
#include
+#include
#include
#include
@@ -34,6 +35,15 @@ int cmd_ut_category(const char *name, const char *prefix,
continue;
printf("Test: %s\n", test->name);
+ if (test->flags & UT_TESTF_CONSOLE_REC) {
+ int ret = console_record_reset_enable();
+
+ if (ret) {
+ printf("Skipping: Console recording
disabled\n");
+ continue;
+ }
+ }
+
uts.start = mallinfo();
test->func();
--
2.28.0.rc0.142.g3c755180ce-goog
[PATCH v2 1/5] test: Add a way to check part of a console line or skip it
Some lines of the output are not worth testing, or not worth testing in
their entirety. For example, when checking a hex dump we know that the
hex-dump routine can display ASCII so we only need to check the hex bytes,
not the ASCII dump. Add a new test macros which can check only part of
a console line.
Sometimes it is useful to skip a line altogether, so add a macro for that
also.
Signed-off-by: Simon Glass
---
Changes in v2:
- Add new patch to check part of a console line or skip it
include/test/ut.h | 59 +++
test/ut.c | 22 ++
2 files changed, 81 insertions(+)
diff --git a/include/test/ut.h b/include/test/ut.h
index 99bbb1230c7..017dd0d8702 100644
--- a/include/test/ut.h
+++ b/include/test/ut.h
@@ -56,6 +56,31 @@ void ut_failf(struct unit_test_state *uts, const char
*fname, int line,
int ut_check_console_line(struct unit_test_state *uts, const char *fmt, ...)
__attribute__ ((format (__printf__, 2, 3)));
+/**
+ * ut_check_console_linen() - Check part of the next console line
+ *
+ * This creates a string and then checks it against the next line of console
+ * output obtained with console_record_readline(). Only the length of the
+ * string is checked
+ *
+ * After the function returns, uts->expect_str holds the expected string and
+ * uts->actual_str holds the actual string read from the console.
+ *
+ * @uts: Test state
+ * @fmt: printf() format string for the error, followed by args
+ * @return 0 if OK, other value on error
+ */
+int ut_check_console_linen(struct unit_test_state *uts, const char *fmt, ...)
+ __attribute__ ((format (__printf__, 2, 3)));
+
+/**
+ * ut_check_skipline() - Check that the next console line exists and skip it
+ *
+ * @uts: Test state
+ * @return 0 if OK, other value on error
+ */
+int ut_check_skipline(struct unit_test_state *uts);
+
/**
* ut_check_console_end() - Check there is no more console output
*
@@ -151,6 +176,23 @@ int ut_check_console_dump(struct unit_test_state *uts, int
total_bytes);
} \
}
+/*
+ * Assert that two string expressions are equal, up to length of the
+ * first
+ */
+#define ut_asserteq_strn(expr1, expr2) { \
+ const char *_val1 = (expr1), *_val2 = (expr2); \
+ int _len = strlen(_val1); \
+ \
+ if (memcmp(_val1, _val2, _len)) { \
+ ut_failf(uts, __FILE__, __LINE__, __func__, \
+#expr1 " = " #expr2, \
+"Expected \"%.*s\", got \"%.*s\"", \
+_len, _val1, _len, _val2); \
+ return CMD_RET_FAILURE; \
+ } \
+}
+
/* Assert that two memory areas are equal */
#define ut_asserteq_mem(expr1, expr2, len) { \
const u8 *_val1 = (u8 *)(expr1), *_val2 = (u8 *)(expr2);\
@@ -230,6 +272,23 @@ int ut_check_console_dump(struct unit_test_state *uts, int
total_bytes);
return CMD_RET_FAILURE; \
} \
+/* Assert that the next console output line matches up to the length */
+#define ut_assert_nextlinen(fmt, args...) \
+ if (ut_check_console_linen(uts, fmt, ##args)) { \
+ ut_failf(uts, __FILE__, __LINE__, __func__, \
+"console", "\nExpected '%s',\n got '%s'", \
+uts->expect_str, uts->actual_str); \
+ return CMD_RET_FAILURE; \
+ } \
+
+/* Assert that there is a 'next' console output line, and skip it */
+#define ut_assert_skipline() \
+ if (ut_check_skipline(uts)) { \
+ ut_failf(uts, __FILE__, __LINE__, __func__, \
+"console", "\nExpected a line, got end"); \
+ return CMD_RET_FAILURE; \
+ } \
+
/* Assert that there is no more console output */
#define ut_assert_console_end()
\
if (ut_check_console_end(uts)) {\
diff --git a/test/ut.c b/test/ut.c
index c64f0b554d5..95bdd66de6a 100644
--- a/test/ut.c
+++ b/test/ut.c
@@ -59,6 +59,28 @@ int ut_check_console_line(struct
[PATCH v2 0/5] cmd: Fix 'md' and add a memory-search command
Add various fixes and improvements to this command that were missed in the original version. Unfortunately I forgot to send v2. Changes in v2: - Add new patch to check part of a console line or skip it - Rename the Kconfig to CONFIG_CMD_MEM_SEARCH - Use a separate var for the remaining search length - Drop unnecessary ':' in the U_BOOT_CMD - Enable the command for sandbox - Split the argc/argv changes over two lines - Add the missing cover-letter tags - Correct a bug when auto-repeating right at the end (and add test) - Move tests to a new suite of their own, instead of DM tests - Add -q flag to the 'quiet' test to test operation when console is enabled Simon Glass (5): test: Add a way to check part of a console line or skip it console: Always define the console-recording functions dm: Rename DM test flags to make them more generic test: Add a flag for tests that need console recording cmd: Update the memory-search command cmd/Kconfig | 2 +- cmd/mem.c | 30 ++- common/console.c | 4 +- configs/sandbox_defconfig | 1 + doc/README.commands | 2 +- include/console.h | 40 +- include/dm/test.h | 9 include/test/suites.h | 1 + include/test/test.h | 11 include/test/ut.h | 59 + test/cmd/Makefile | 3 +- test/cmd/mem.c| 20 +++ test/cmd/mem_search.c | 108 -- test/cmd_ut.c | 12 + test/dm/acpi.c| 28 +- test/dm/acpi_dp.c | 2 +- test/dm/acpigen.c | 18 +++ test/dm/adc.c | 16 +++--- test/dm/audio.c | 2 +- test/dm/axi.c | 6 +-- test/dm/blk.c | 10 ++-- test/dm/board.c | 2 +- test/dm/bootcount.c | 2 +- test/dm/bus.c | 26 - test/dm/cache.c | 2 +- test/dm/clk.c | 6 +-- test/dm/clk_ccf.c | 2 +- test/dm/core.c| 30 +-- test/dm/cpu.c | 2 +- test/dm/devres.c | 12 ++--- test/dm/dma.c | 6 +-- test/dm/dsi_host.c| 2 +- test/dm/eth.c | 16 +++--- test/dm/fdtdec.c | 4 +- test/dm/firmware.c| 2 +- test/dm/gpio.c| 20 +++ test/dm/hwspinlock.c | 2 +- test/dm/i2c.c | 16 +++--- test/dm/i2s.c | 2 +- test/dm/irq.c | 10 ++-- test/dm/led.c | 12 ++--- test/dm/mailbox.c | 2 +- test/dm/mdio.c| 2 +- test/dm/mdio_mux.c| 2 +- test/dm/misc.c| 2 +- test/dm/mmc.c | 4 +- test/dm/nop.c | 2 +- test/dm/ofnode.c | 12 ++--- test/dm/ofread.c | 2 +- test/dm/osd.c | 4 +- test/dm/p2sb.c| 2 +- test/dm/panel.c | 2 +- test/dm/pch.c | 4 +- test/dm/pci.c | 26 - test/dm/pci_ep.c | 2 +- test/dm/phy.c | 6 +-- test/dm/pmc.c | 2 +- test/dm/pmic.c| 10 ++-- test/dm/power-domain.c| 2 +- test/dm/pwm.c | 2 +- test/dm/ram.c | 2 +- test/dm/regmap.c | 10 ++-- test/dm/regulator.c | 20 +++ test/dm/remoteproc.c | 4 +- test/dm/reset.c | 6 +-- test/dm/rng.c | 2 +- test/dm/rtc.c | 14 ++--- test/dm/serial.c | 2 +- test/dm/sf.c | 4 +- test/dm/simple-pm-bus.c | 2 +- test/dm/smem.c| 2 +- test/dm/soc.c | 2 +- test/dm/sound.c | 4 +- test/dm/spi.c | 4 +- test/dm/spmi.c| 6 +-- test/dm/syscon-reset.c| 2 +- test/dm/syscon.c | 6 +-- test/dm/sysreset.c| 8 +-- test/dm/tee.c | 2 +- test/dm/test-fdt.c| 46 test/dm/test-main.c | 10 ++-- test/dm/timer.c | 2 +- test/dm/usb.c | 12 ++--- test/dm/video.c | 26 - test/dm/virtio.c | 8 +-- test/dm/wdt.c | 2 +- test/lib/lmb.c| 18 +++ test/ut.c | 22 88 files changed, 556 insertions(+), 342 deletions(-) create mode 100644 test/cmd/mem.c -- 2.28.0.rc0.142.g3c755180ce-goog
[PATCH v2 5/5] cmd: Update the memory-search command
Add various fixes and improvements to this command that were missed in
the original version. Unfortunately I forgot to send v2.
- Fix Kconfig name
- Use a separate variable for the remaining search length
- Correct a minor bug
- Move into a separate test suite
- Add -q flag to the 'quiet' test to test operation when console is enabled
- Enable the feature for sandbox
Signed-off-by: Simon Glass
---
Changes in v2:
- Rename the Kconfig to CONFIG_CMD_MEM_SEARCH
- Use a separate var for the remaining search length
- Drop unnecessary ':' in the U_BOOT_CMD
- Enable the command for sandbox
- Split the argc/argv changes over two lines
- Add the missing cover-letter tags
- Correct a bug when auto-repeating right at the end (and add test)
- Move tests to a new suite of their own, instead of DM tests
- Add -q flag to the 'quiet' test to test operation when console is enabled
cmd/Kconfig | 2 +-
cmd/mem.c | 30 ++-
configs/sandbox_defconfig | 1 +
include/test/suites.h | 1 +
test/cmd/Makefile | 3 +-
test/cmd/mem.c| 20 +++
test/cmd/mem_search.c | 108 --
test/cmd_ut.c | 2 +
8 files changed, 124 insertions(+), 43 deletions(-)
create mode 100644 test/cmd/mem.c
diff --git a/cmd/Kconfig b/cmd/Kconfig
index e2b0a4fbc01..d6586f8c134 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -713,7 +713,7 @@ config CMD_MEMORY
base - print or set address offset
loop - initialize loop on address range
-config MEM_SEARCH
+config CMD_MEM_SEARCH
bool "ms - Memory search"
help
Memory-search command
diff --git a/cmd/mem.c b/cmd/mem.c
index 575893c18df..190e2b94a7d 100644
--- a/cmd/mem.c
+++ b/cmd/mem.c
@@ -53,7 +53,8 @@ static ulong dp_last_length = 0x40;
static ulong mm_last_addr, mm_last_size;
static ulong base_address = 0;
-#ifdef CONFIG_MEM_SEARCH
+#ifdef CONFIG_CMD_MEM_SEARCH
+static ulong dp_last_ms_length;
static u8 search_buf[64];
static uint search_len;
#endif
@@ -367,7 +368,7 @@ static int do_mem_cp(struct cmd_tbl *cmdtp, int flag, int
argc,
return 0;
}
-#ifdef CONFIG_MEM_SEARCH
+#ifdef CONFIG_CMD_MEM_SEARCH
static int do_mem_search(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
{
@@ -377,6 +378,7 @@ static int do_mem_search(struct cmd_tbl *cmdtp, int flag,
int argc,
ulong last_pos; /* Offset of last match in 'size' units*/
ulong last_addr;/* Address of last displayed line */
int limit = 10;
+ int used_len;
int count;
int size;
int i;
@@ -384,12 +386,12 @@ static int do_mem_search(struct cmd_tbl *cmdtp, int flag,
int argc,
/* We use the last specified parameters, unless new ones are entered */
addr = dp_last_addr;
size = dp_last_size;
- length = dp_last_length;
+ length = dp_last_ms_length;
if (argc < 3)
return CMD_RET_USAGE;
- if ((!flag & CMD_FLAG_REPEAT)) {
+ if (!(flag & CMD_FLAG_REPEAT)) {
/*
* Check for a size specification.
* Defaults to long if no or incorrect specification.
@@ -398,7 +400,8 @@ static int do_mem_search(struct cmd_tbl *cmdtp, int flag,
int argc,
if (size < 0 && size != -2 /* string */)
return 1;
- argc--; argv++;
+ argc--;
+ argv++;
while (argc && *argv[0] == '-') {
int ch = argv[0][1];
@@ -408,7 +411,8 @@ static int do_mem_search(struct cmd_tbl *cmdtp, int flag,
int argc,
limit = simple_strtoul(argv[0] + 2, NULL, 16);
else
return CMD_RET_USAGE;
- argc--; argv++;
+ argc--;
+ argv++;
}
/* Address is specified since argc > 1 */
@@ -421,7 +425,7 @@ static int do_mem_search(struct cmd_tbl *cmdtp, int flag,
int argc,
/* Read the bytes to search for */
end = search_buf + sizeof(search_buf);
for (i = 2, ptr = search_buf; i < argc && ptr < end; i++) {
- if (SUPPORT_64BIT_DATA && size == 8) {
+ if (MEM_SUPPORT_64BIT_DATA && size == 8) {
u64 val = simple_strtoull(argv[i], NULL, 16);
*(u64 *)ptr = val;
@@ -460,7 +464,8 @@ static int do_mem_search(struct cmd_tbl *cmdtp, int flag,
int argc,
last_pos = 0;
last_addr = 0;
count = 0;
- for (offset = 0; offset <= bytes - search_len && count < limit;
+ for (offset = 0;
+offset < bytes && offset <= bytes - search_len && count < limit;
offset += size) {
void *ptr = buf + offset;
@@ -495,9
[PATCH] mmc: am654_sdhci: Use MMC_MODES_END value instead of hardcoded value
The hardcoded array size leads to array overflows with changes in
speed modes enum in mmc core. Use MMC_MODES_END for otap_del_sel
array declaration to fix this.
Signed-off-by: Faiz Abbas
---
drivers/mmc/am654_sdhci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/am654_sdhci.c b/drivers/mmc/am654_sdhci.c
index cbc531dc53..82abf484e4 100644
--- a/drivers/mmc/am654_sdhci.c
+++ b/drivers/mmc/am654_sdhci.c
@@ -75,7 +75,7 @@ struct am654_sdhci_plat {
struct mmc mmc;
struct regmap *base;
bool non_removable;
- u32 otap_del_sel[11];
+ u32 otap_del_sel[MMC_MODES_END];
u32 trm_icp;
u32 drv_strength;
u32 strb_sel;
--
2.17.1
Re: [PATCH 6/8] arm: dts: Sync the sun50i-a64.dtsi from Linux 5.8-rc1
On 27/07/2020 14:16, Heinrich Schuchardt wrote: Hi Peter, Heinrich, > On 26.07.20 12:17, Peter Robinson wrote: >> On Thu, Jul 23, 2020 at 12:15 AM André Przywara >> wrote: >>> >>> On 22/07/2020 15:18, Peter Robinson wrote: Sync the Allwinner A64 sun50i-a64.dtsi from Linux. >>> >>> Hi Peter, >>> >>> thanks for your series! >>> >>> While this looks mostly straight-forward, the problem is that this patch >>> here affects all Allwinner boards. And for them it breaks older kernels, >>> which cannot cope with some of the changed bindings or nodes. >>> Your patches up until here are fine, since they only add nodes and >>> properties, but this update changes nodes, some in a non-compatible way. >>> >>> Examples are dropping the "syscon" compatible (which requires 4.18 to >>> know about the new compatible string) and the dropping of >>> internal-osc-clk and the connected RTC change. This breaks any kernels >>> that don't know about the third RTC clock (< 2>) or the new >>> compatible string (introduced in 4.20). Similar effects show up in other >>> OSes. >> >> The 4.18 kernel is over 2 years old. How many users are going to >> actively upgrade U-Boot to the latest and not the kernel all while >> using the U-Boot provided DT and not just loading the matching kernel >> DT supplied by what ever ancient kernel they happen to choose to use? Everyone who wants to boot the UEFI/distro way, using the DT as a hardware description, provided by the firmware. Yes, for years people got used to somehow get some matching revision of the right DT loaded together with the kernel, but the UEFI boot flow makes this rather hard to do. And with the availability of $fdtcontroladdr (which is actually implicit if bootefi is just called with one argument) this would all fit so nicely: You have your device specific firmware build (firmware in the classis sense, not the Android meaning), and the rest (kernel, userland, secondary bootloaders) is generic and everything falls in place. >> I feel this use case is quite a corner case and in those cases they're >> probably not using a vanilla upstream U-Boot anyway. > > Sure people using an old Linux distribution not providing an U-Boot > image may do so. > > But here we are talking about the U-Boot device tree. What is a "U-Boot device tree"? The device tree describes the hardware, so how would that be different between Linux, U-Boot, FreeBSD or Zephyr? For practical reasons (no on-board storage, for instance) the DT is shipped with some software/firmware, but the concept is still that of a kernel-agnostic description. Actually U-Boot's own DT needs are very minimal: we could get away with a VERY basic DT, barely containing a clock node, and MMC, EMAC and USB nodes with just reg and clocks properties. But since a U-Boot build is per-board, it sounds natural to make this the only place which holds the respective devicetree, so any user would just consume it and doesn't need to have any further board specific information. > As Linux device > trees are release specific you should not try to boot Linux using a > devicetree not provided by the exact same Linux version. Where does this statement come from? Definitely you can boot Linux with DTs from a previous version, but conceptually DTs are independent from any software consumer. It's just very hard to get that right if you don't have all the documentation upfront, to create DT nodes which describe everything you need. That's why some platform maintainers decided to not guarantee forward compatibility for their platform. Which doesn't mean we should not still aim at this, hence my request to tweak some compatible string to restore compatibility across various Linux kernel releases (used by distributions as their official kernel). > So incompatiblities between old Linux releases and U-Boot's device tree > should be irrelevant. > > Best regards > > Heinrich > >> >>> I was experimenting with some small changes (compared to mainline) to >>> overcome those issues, mostly by *adding* compatible strings instead of >>> *replacing* them. >> >> Shouldn't they be added to a -u-boot.dtsi? This might be a possible way to implement this, although the idea of those files is to accommodate U-Boot specific nodes or properties. Cheers, Andre >>> So I would like to ask for a few days so that I can do more testing with >>> various kernels. I would then post those changes, so that we can discuss >>> them. >>> >>> Cheers, >>> Andre >>> Signed-off-by: Peter Robinson --- arch/arm/dts/sun50i-a64.dtsi | 532 --- 1 file changed, 434 insertions(+), 98 deletions(-)
Re: [PATCH 2/2] configs: migrate CONFIG_SPL_LOAD_FIT_ADDRESS to defconfigs
On Mon, Jul 06, 2020 at 03:35:01PM +0800, peng@nxp.com wrote: > From: Peng Fan > > Done with: > ./tools/moveconfig.py -S SPL_LOAD_FIT_ADDRESS > ./tools/moveconfig.py -S SPL_LOAD_FIT_ADDRESS -H > > Signed-off-by: Peng Fan Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] configs: Remove dead CONFIG options
On Fri, Jul 03, 2020 at 09:06:36AM -0500, Adam Ford wrote: > BOOTP_DEFAULT is defined in several boards, but this config > option is never checked or used. > > This patch removes this config option from config files and > the whitelist.txt > > Signed-off-by: Adam Ford > > diff --git a/include/configs/am335x_shc.h b/include/configs/am335x_shc.h > index c88067c012..7240ff6901 100644 Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] Convert CONFIG_SYS_MMCSD_FS_BOOT_PARTITION to Kconfig
On Fri, Jul 03, 2020 at 10:17:30AM -0500, Adam Ford wrote: > This converts the following to Kconfig: >CONFIG_SYS_MMCSD_FS_BOOT_PARTITION > > Signed-off-by: Adam Ford > > diff --git a/README b/README > index 6bac583666..b45c7b27d7 100644 Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/2] Kconfig: add SPL_LOAD_FIT_ADDRESS
On Mon, Jul 06, 2020 at 03:35:00PM +0800, peng@nxp.com wrote: > From: Peng Fan > > Add SPL_LOAD_FIT_ADDRESS to make user could add it in defconfig > > Signed-off-by: Peng Fan Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] Convert CONFIG_ENV_OVERWRITE to Kconfig
On Fri, Jul 03, 2020 at 06:48:56AM -0500, Adam Ford wrote: > This converts the following to Kconfig: >CONFIG_ENV_OVERWRITE > > Signed-off-by: Adam Ford > > diff --git a/arch/arm/mach-kirkwood/include/mach/config.h > b/arch/arm/mach-kirkwood/include/mach/config.h > index b6cf629c4f..beedc125b6 100644 Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/2] Convert CONFIG_SPL_NAND_BASE et al to Kconfig
On Fri, Jul 03, 2020 at 08:09:45AM -0500, Adam Ford wrote: > This converts the following to Kconfig: >CONFIG_SPL_NAND_BASE >CONFIG_SPL_NAND_IDENT > > Signed-off-by: Adam Ford > > diff --git a/README b/README > index b6d368041c..60d8e77256 100644 Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] Convert CONFIG_BOOTP_SEND_HOSTNAME to Kconfig
On Fri, Jul 03, 2020 at 09:00:14AM -0500, Adam Ford wrote: > This converts the following to Kconfig: >CONFIG_BOOTP_SEND_HOSTNAME > > Signed-off-by: Adam Ford > > diff --git a/README b/README > index 60d8e77256..6bac583666 100644 Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/2] Convert CONFIG_SPL_NAND_DRIVERS et al to Kconfig
On Fri, Jul 03, 2020 at 08:09:44AM -0500, Adam Ford wrote: > This converts the following to Kconfig: >CONFIG_SPL_NAND_DRIVERS >CONFIG_SPL_NAND_ECC >CONFIG_SPL_NAND_SIMPLE > > Signed-off-by: Adam Ford Note: While you're the listed maintainer of da850evm_nand, the patch as sent also increased the size of SPL on that platform by enabling CONFIG_SPL_SPI_LOAD which I think based on other discussions wasn't needed on this platform and was dropped at one point and I assume was re-added by accident here. So I've dropped that change here and the patch (and rest of the branch I'm including this in) is once again size neutral on this platform. Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] Convert CONFIG_DRIVER_TI_EMAC_USE_RMII to Kconfig
On Fri, Jul 03, 2020 at 08:27:12AM -0500, Adam Ford wrote: > This converts the following to Kconfig: >CONFIG_DRIVER_TI_EMAC_USE_RMII > > Signed-off-by: Adam Ford > > diff --git a/configs/am3517_evm_defconfig b/configs/am3517_evm_defconfig > index 58fb91c1c5..a78a596d4d 100644 Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] Convert CONFIG_BOOTP_DNS2 to Kconfig
On Fri, Jul 03, 2020 at 08:45:28AM -0500, Adam Ford wrote: > The Kconfig already has BOOTP_DNS2, but not all boards have been > converted. This finishes converting the following to Kconfig: >CONFIG_BOOTP_DNS2 > > Signed-off-by: Adam Ford This migration was done in a previous patch, so deferring this one, sorry. -- Tom signature.asc Description: PGP signature
[PATCH v2] dtoc: add coverage test for unicode error
Add an additional test to dtoc in order improve the coverage,
specifically to take into account the case of unicode error when
scanning drivers.
Signed-off-by: Walter Lozano
---
Changes in v2:
- Add missing files
- Extend scan_drivers to use both relative and absolute paths
tools/dtoc/dtb_platdata.py| 18 +++---
tools/dtoc/dtoc_test_scan_drivers.cxx | 1 +
tools/dtoc/test_dtoc.py | 26 ++
3 files changed, 42 insertions(+), 3 deletions(-)
create mode 100644 tools/dtoc/dtoc_test_scan_drivers.cxx
diff --git a/tools/dtoc/dtb_platdata.py b/tools/dtoc/dtb_platdata.py
index c28768f4a2..f870ebdb78 100644
--- a/tools/dtoc/dtb_platdata.py
+++ b/tools/dtoc/dtb_platdata.py
@@ -145,8 +145,10 @@ class DtbPlatdata(object):
U_BOOT_DRIVER_ALIAS(driver_alias, driver_name)
value: Driver name declared with U_BOOT_DRIVER(driver_name)
_links: List of links to be included in dm_populate_phandle_data()
+_drivers_additional: List of additional drivers to use during scanning
"""
-def __init__(self, dtb_fname, include_disabled, warning_disabled):
+def __init__(self, dtb_fname, include_disabled, warning_disabled,
+ drivers_additional=[]):
self._fdt = None
self._dtb_fname = dtb_fname
self._valid_nodes = None
@@ -157,6 +159,7 @@ class DtbPlatdata(object):
self._drivers = []
self._driver_aliases = {}
self._links = []
+self._drivers_additional = drivers_additional
def get_normalized_compat_name(self, node):
"""Get a node's normalized compat name
@@ -338,6 +341,14 @@ class DtbPlatdata(object):
continue
self.scan_driver(dirpath + '/' + fn)
+for fn in self._drivers_additional:
+if not isinstance(fn, str) or len(fn) == 0:
+continue
+if fn[0] == '/':
+self.scan_driver(fn)
+else:
+self.scan_driver(basedir + '/' + fn)
+
def scan_dtb(self):
"""Scan the device tree to obtain a tree of nodes and properties
@@ -654,7 +665,8 @@ class DtbPlatdata(object):
self.out(''.join(self.get_buf()))
-def run_steps(args, dtb_file, include_disabled, output,
warning_disabled=False):
+def run_steps(args, dtb_file, include_disabled, output, warning_disabled=False,
+ drivers_additional=[]):
"""Run all the steps of the dtoc tool
Args:
@@ -666,7 +678,7 @@ def run_steps(args, dtb_file, include_disabled, output,
warning_disabled=False):
if not args:
raise ValueError('Please specify a command: struct, platdata')
-plat = DtbPlatdata(dtb_file, include_disabled, warning_disabled)
+plat = DtbPlatdata(dtb_file, include_disabled, warning_disabled,
drivers_additional)
plat.scan_drivers()
plat.scan_dtb()
plat.scan_tree()
diff --git a/tools/dtoc/dtoc_test_scan_drivers.cxx
b/tools/dtoc/dtoc_test_scan_drivers.cxx
new file mode 100644
index 00..557c692ba2
--- /dev/null
+++ b/tools/dtoc/dtoc_test_scan_drivers.cxx
@@ -0,0 +1 @@
+U_BOOT_DRIVER_ALIAS(sandbox_gpio, sandbox_gpio_alias2)
diff --git a/tools/dtoc/test_dtoc.py b/tools/dtoc/test_dtoc.py
index 169ecd6e6e..f1b0eb824a 100755
--- a/tools/dtoc/test_dtoc.py
+++ b/tools/dtoc/test_dtoc.py
@@ -13,6 +13,7 @@ import collections
import os
import struct
import sys
+import tempfile
import unittest
from dtoc import dtb_platdata
@@ -829,3 +830,28 @@ U_BOOT_DEVICE(spl_test2) = {
self.run_test(['invalid-cmd'], dtb_file, output)
self.assertIn("Unknown command 'invalid-cmd': (use: struct, platdata)",
str(e.exception))
+
+def testScanDrivers(self):
+"""Test running dtoc with additional drivers to scan"""
+dtb_file = get_dtb_file('dtoc_test_simple.dts')
+output = tools.GetOutputFilename('output')
+with test_util.capture_sys_output() as (stdout, stderr):
+dtb_platdata.run_steps(['struct'], dtb_file, False, output, True,
+ [None, '',
'tools/dtoc/dtoc_test_scan_drivers.cxx'])
+
+def testUnicodeError(self):
+"""Test running dtoc with an invalid unicode file
+
+To be able to perform this test without adding a weird text file which
+would produce issues when using checkpatch.pl or patman, generate the
+file at runtime and then process it.
+"""
+dtb_file = get_dtb_file('dtoc_test_simple.dts')
+output = tools.GetOutputFilename('output')
+driver_fn = '/tmp/' + next(tempfile._get_candidate_names())
+with open(driver_fn, 'wb+') as df:
+df.write(b'\x81')
+
+with test_util.capture_sys_output() as (stdout, stderr):
+dtb_platdata.run_steps(['struct'], dtb_file, False, output, True,
+ [driver_fn])
--
2.20.1
Re: [PATCH] dtoc: add coverage test for unicode error
Hi Simon, On 27/7/20 20:35, Simon Glass wrote: Hi Walter, On Mon, 20 Jul 2020 at 12:29, Walter Lozano wrote: Add an additional test to dtoc in order improve the coverage, specifically to take into account the case of unicode error when scanning drivers. Signed-off-by: Walter Lozano --- tools/dtoc/dtb_platdata.py | 14 +++--- tools/dtoc/test_dtoc.py| 18 ++ 2 files changed, 29 insertions(+), 3 deletions(-) This seems to be missing a .cxx file, so gives a build error. Sorry for the error. I'm sending a new version with some additional improvements. Regards, Walter
Re: AM335X Bootp of u-boot-spl.bin followed by tftp of u-boot.img. Is it possible?
Here is more information... I dumped the DTB to decompile to see what was
in the device tree.
I am working on a new board based upon the AM3352 that has only ethernet
and a serial port.
The goal is to use the device model exclusively for this. I am working with
u-boot 2020.07rc4 presently.
I am having a lot of trouble getting second stage booting over TFTP from
the u-boot-spl.bin image.
If I serial boot and after loading the second image to DRAM, tftp is
working fine, so the hardware is okay.
Any insight would be greatly appreciated.
Thank
Dump of device tree from u-boot-spl.bin
Note: magic header number is 0x0dd0 0xedfe
Use hexdump and grep to search for it.
rich@poseiden:~/u-boot/spl$ tail -c 4556 u-boot-spl.bin | fdtdump -
fdtdump is a low-level debugging tool, not meant for general use.
If you want to decompile a dtb, you probably want
dtc -I dtb -O dts
/dts-v1/;
// magic: 0xd00dfeed
// totalsize: 0x675 (1653)
// off_dt_struct:0x38
// off_dt_strings:0x51c
// off_mem_rsvmap:0x28
// version: 17
// last_comp_version:2
// boot_cpuid_phys:0x0
// size_dt_strings:0x159
// size_dt_struct:0x4e4
/ {
compatible = "ti,am33xx";
#address-cells = <0x0001>;
#size-cells = <0x0001>;
model = "Flight Circuits EPN11291";
chosen {
stdout-path = "/ocp/serial@44e09000";
tick-timer = "/ocp/timer@4804";
};
aliases {
serial0 = "/ocp/serial@44e09000";
};
ocp {
compatible = "simple-bus";
#address-cells = <0x0001>;
#size-cells = <0x0001>;
ranges;
ti,hwmods = "l3_main";
l4_wkup@44c0 {
scm@21 {
pinmux@800 {
compatible = "pinctrl-single";
reg = <0x0800 0x0238>;
#address-cells = <0x0001>;
#size-cells = <0x>;
#pinctrl-cells = <0x0001>;
pinctrl-single,register-width = <0x0020>;
pinctrl-single,function-mask = <0x007f>;
};
};
};
serial@44e09000 {
compatible = "ti,am3352-uart", "ti,omap3-uart";
ti,hwmods = "uart1";
clock-frequency = <0x02dc6c00>;
reg = <0x44e09000 0x2000>;
status = "okay";
dmas = <0x0025 0x001a 0x 0x0025 0x001b
0x>;
dma-names = "tx", "rx";
};
mmc@481d8000 {
compatible = "ti,omap4-hsmmc";
ti,hwmods = "mmc2";
ti,needs-special-reset;
dmas = <0x0025 0x0002 0x 0x0025 0x0003
0x>;
dma-names = "tx", "rx";
reg = <0x481d8000 0x1000>;
status = "okay";
bus-width = <0x0008>;
ti,non-removable;
max-frequency = <0x05b8d800>;
};
usb@4740 {
dma-controller@47402000 {
compatible = "ti,am3359-cppi41";
reg = <0x4740 0x1000 0x47402000 0x1000
0x47403000 0x1000 0x47404000 0x4000>;
reg-names = "glue", "controller", "scheduler", "queuemgr";
interrupt-names = "glue";
#dma-cells = <0x0002>;
#dma-channels = <0x001e>;
#dma-requests = <0x0100>;
status = "okay";
phandle = <0x0032>;
};
};
};
};
Added u-boot, dm-spl to all drivers in the DTS
Still crashing
rich@poseiden:~/u-boot/spl$ tail -c 5388 u-boot-spl.bin | fdtdump -
fdtdump is a low-level debugging tool, not meant for general use.
If you want to decompile a dtb, you probably want
dtc -I dtb -O dts
/dts-v1/;
// magic:0xd00dfeed
// totalsize:0x9bd (2493)
// off_dt_struct:0x38
// off_dt_strings:0x7b8
// off_mem_rsvmap:0x28
// version:17
// last_comp_version:2
// boot_cpuid_phys:0x0
// size_dt_strings:0x205
// size_dt_struct:0x780
/ {
compatible = "ti,am33xx";
#address-cells = <0x0001>;
#size-cells = <0x0001>;
model = "Flight Circuits EPN11291";
chosen {
stdout-path = "/ocp/serial@44e09000";
tick-timer = "/ocp/timer@4804";
};
aliases {
serial0 = "/ocp/serial@44e09000";
ethernet0 = "/ocp/ethernet@4a10/slave@4a100200";
};
ocp {
compatible = "simple-bus";
#address-cells = <0x0001>;
#size-cells = <0x0001>;
ranges;
ti,hwmods = "l3_main";
l4_wkup@44c0 {
scm@21 {
pinmux@800 {
compatible = "pinctrl-single";
reg = <0x0800 0x0238>;
#address-cells = <0x0001>;
#size-cells = <0x>;
RE: [PATCH] Clean up the Spansion/Cypress/Infineon device ID table
The device s25fl512s is not offered with neither 64kB sector size, nor 512kB sector size, that's why s25fl512s_64k and s25fl512s_512k need to be removed from the device ID table. The device ID entries "s25fl512s_256k" and "s25fl512s" are exactly the same, that's why the entry "s25fl512s_256k" needs to be removed. Any legacy board having that device will still be able to probe the Flash memory as "s25fl512s" and will definitely not fail. Best regards, Bacem Daassi Principal Applications Engineer Cypress Semiconductor GmbH An Infineon Technologies Company Willy-Brandt-Allee 4, 81829 Munich, Germany www.infineon.com www.cypress.com -Original Message- From: Jagan Teki Sent: Thursday, July 9, 2020 10:19 AM To: bacem.daa...@gmail.com Cc: U-Boot-Denx ; Vignesh R ; Bacem Daassi ; Takahiro Kuwano Subject: Re: [PATCH] Clean up the Spansion/Cypress/Infineon device ID table On Fri, May 22, 2020 at 10:41 PM wrote: > > From: Bacem Daassi > > Signed-off-by: Bacem Daassi > > Clean up the Spansion/Cypress/Infineon device ID table. >Remove s25fl512s_256k since it's a duplicate of s25fl512s. >Remove s25fl512s_64k and s25fl512s_512k since these devices do not exist. Why these removed, what if legacy board usage still exists? >Rename s25fl128s to s25fl128s1. >Add the new device s25fl128s0. >Add device s25fl256l to the device ID table. > All devices were tested on real silicon and confirmed to be working. > --- Please work with a proper commit message. mtd: spi: Clean up Spansion/Cypress/Infineon ID table < body > Signed-off-by: Bacem Daassi This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.
[PATCH v5 3/3] fastboot: Add default fastboot_set_reboot_flag implementation
Default implementation of fastboot_set_reboot_flag function that depends
on "bcb" commands could be used in general case if there are no need to
make any platform-specific implementation, otherwise it could be
disabled via Kconfig option FASTBOOT_USE_BCB_SET_REBOOT_FLAG.
Please note that FASTBOOT_USE_BCB_SET_REBOOT_FLAG is mutually exclusive
with some platforms which already have their own implementation of this
function.
Signed-off-by: Roman Kovalivskyi
---
drivers/fastboot/Kconfig | 12 ++
drivers/fastboot/Makefile | 1 +
drivers/fastboot/fb_bcb_impl.c | 43 ++
include/fastboot.h | 9 +++
4 files changed, 65 insertions(+)
create mode 100644 drivers/fastboot/fb_bcb_impl.c
diff --git a/drivers/fastboot/Kconfig b/drivers/fastboot/Kconfig
index d4436dfc9173..4352ba67a713 100644
--- a/drivers/fastboot/Kconfig
+++ b/drivers/fastboot/Kconfig
@@ -165,6 +165,18 @@ config FASTBOOT_CMD_OEM_FORMAT
relies on the env variable partitions to contain the list of
partitions as required by the gpt command.
+config FASTBOOT_USE_BCB_SET_REBOOT_FLAG
+ bool "Use BCB by fastboot to set boot reason"
+ depends on CMD_BCB && !ARCH_MESON && !ARCH_ROCKCHIP && !TARGET_KC1 && \
+ !TARGET_SNIPER && !TARGET_AM57XX_EVM && !TARGET_DRA7XX_EVM
+ default y
+ help
+ Fastboot could implement setting of reboot reason in a generic fashion
+ via BCB commands. BCB commands are able to write reboot reason into
+ command field of boot control block. In general case it is sufficient
+ implementation if your platform supports BCB commands and doesn't
+ require any specific reboot reason handling.
+
endif # FASTBOOT
endmenu
diff --git a/drivers/fastboot/Makefile b/drivers/fastboot/Makefile
index 048af5aa8234..2b2c390fe4de 100644
--- a/drivers/fastboot/Makefile
+++ b/drivers/fastboot/Makefile
@@ -5,3 +5,4 @@ obj-y += fb_getvar.o
obj-y += fb_command.o
obj-$(CONFIG_FASTBOOT_FLASH_MMC) += fb_mmc.o
obj-$(CONFIG_FASTBOOT_FLASH_NAND) += fb_nand.o
+obj-$(CONFIG_FASTBOOT_USE_BCB_SET_REBOOT_FLAG) += fb_bcb_impl.o
diff --git a/drivers/fastboot/fb_bcb_impl.c b/drivers/fastboot/fb_bcb_impl.c
new file mode 100644
index ..89ec3601b6f6
--- /dev/null
+++ b/drivers/fastboot/fb_bcb_impl.c
@@ -0,0 +1,43 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2020 GlobalLogic.
+ * Roman Kovalivskyi
+ */
+
+#include
+#include
+
+/**
+ * fastboot_set_reboot_flag() - Set flag to indicate reboot-bootloader
+ *
+ * Set flag which indicates that we should reboot into the bootloader
+ * following the reboot that fastboot executes after this function.
+ *
+ * This function should be overridden in your board file with one
+ * which sets whatever flag your board specific Android bootloader flow
+ * requires in order to re-enter the bootloader.
+ */
+int fastboot_set_reboot_flag(enum fastboot_reboot_reason reason)
+{
+ char cmd[64];
+
+ if (reason >= FASTBOOT_REBOOT_REASONS_COUNT)
+ return -EINVAL;
+
+ snprintf(cmd, sizeof(cmd), "bcb load %d misc",
+CONFIG_FASTBOOT_FLASH_MMC_DEV);
+
+ if (run_command(cmd, 0))
+ return -ENODEV;
+
+ snprintf(cmd, sizeof(cmd), "bcb set command %s",
+fastboot_boot_cmds[reason]);
+
+ if (run_command(cmd, 0))
+ return -ENOEXEC;
+
+ if (run_command("bcb store", 0))
+ return -EIO;
+
+ return 0;
+}
diff --git a/include/fastboot.h b/include/fastboot.h
index b86b508e69fd..8e9ee80907df 100644
--- a/include/fastboot.h
+++ b/include/fastboot.h
@@ -52,6 +52,15 @@ enum fastboot_reboot_reason {
FASTBOOT_REBOOT_REASONS_COUNT
};
+/**
+ * BCB boot commands
+ */
+static const char * const fastboot_boot_cmds[] = {
+ [FASTBOOT_REBOOT_REASON_BOOTLOADER] = "bootonce-bootloader",
+ [FASTBOOT_REBOOT_REASON_FASTBOOTD] = "boot-fastboot",
+ [FASTBOOT_REBOOT_REASON_RECOVERY] = "boot-recovery"
+};
+
/**
* fastboot_response() - Writes a response of the form "$tag$reason".
*
--
2.17.1
[PATCH v5 2/3] fastboot: Add support for 'reboot fastboot' command
Android 10 adds support for dynamic partitions and in order to support
this userspace fastboot must be used[1]. New tool fastbootd is
included into recovery.
Userspace fastboot works from recovery and is launched if:
1) - Dynamic partitioning is enabled
2) - Boot control block has 'boot-fastboot' value into command field
The bootloader is expected to load and boot into the recovery image
upon seeing boot-fastboot in the BCB command. Recovery then parses the
BCB message and switches to fastbootd mode[2].
Please note that boot script is expected to handle 'boot-fastboot'
command in BCB and load into recovery mode.
Bootloader must support 'reboot fastboot' command which should reboot
device into userspace fastboot to accomodate those changes[3].
Another command that bootloader must support[3] is 'reboot recovery'. This
command should simply reboot device into recovery mode.
[1] - https://source.android.com/devices/bootloader/fastbootd
[2] -
https://source.android.com/devices/bootloader/fastbootd#unified_fastboot_and_recovery
[3] -
https://source.android.com/devices/bootloader/fastbootd#modifications_to_the_bootloader
Signed-off-by: Roman Kovalivskyi
Signed-off-by: Roman Stratiienko
Change-Id: I9d2bdc9a6f6f31ea98572fe155e1cc8341e9af76
---
drivers/fastboot/fb_command.c | 38 +
drivers/usb/gadget/f_fastboot.c | 2 ++
include/fastboot.h | 4
net/fastboot.c | 2 ++
4 files changed, 46 insertions(+)
diff --git a/drivers/fastboot/fb_command.c b/drivers/fastboot/fb_command.c
index 8ce5d32fb2ba..d3c578672dc6 100644
--- a/drivers/fastboot/fb_command.c
+++ b/drivers/fastboot/fb_command.c
@@ -37,6 +37,8 @@ static void flash(char *, char *);
static void erase(char *, char *);
#endif
static void reboot_bootloader(char *, char *);
+static void reboot_fastbootd(char *, char *);
+static void reboot_recovery(char *, char *);
#if CONFIG_IS_ENABLED(FASTBOOT_CMD_OEM_FORMAT)
static void oem_format(char *, char *);
#endif
@@ -79,6 +81,14 @@ static const struct {
.command = "reboot-bootloader",
.dispatch = reboot_bootloader
},
+ [FASTBOOT_COMMAND_REBOOT_FASTBOOTD] = {
+ .command = "reboot-fastboot",
+ .dispatch = reboot_fastbootd
+ },
+ [FASTBOOT_COMMAND_REBOOT_RECOVERY] = {
+ .command = "reboot-recovery",
+ .dispatch = reboot_recovery
+ },
[FASTBOOT_COMMAND_SET_ACTIVE] = {
.command = "set_active",
.dispatch = okay
@@ -313,6 +323,34 @@ static void reboot_bootloader(char *cmd_parameter, char
*response)
fastboot_okay(NULL, response);
}
+/**
+ * reboot_fastbootd() - Sets reboot fastboot flag.
+ *
+ * @cmd_parameter: Pointer to command parameter
+ * @response: Pointer to fastboot response buffer
+ */
+static void reboot_fastbootd(char *cmd_parameter, char *response)
+{
+ if (fastboot_set_reboot_flag(FASTBOOT_REBOOT_REASON_FASTBOOTD))
+ fastboot_fail("Cannot set fastboot flag", response);
+ else
+ fastboot_okay(NULL, response);
+}
+
+/**
+ * reboot_recovery() - Sets reboot recovery flag.
+ *
+ * @cmd_parameter: Pointer to command parameter
+ * @response: Pointer to fastboot response buffer
+ */
+static void reboot_recovery(char *cmd_parameter, char *response)
+{
+ if (fastboot_set_reboot_flag(FASTBOOT_REBOOT_REASON_RECOVERY))
+ fastboot_fail("Cannot set recovery flag", response);
+ else
+ fastboot_okay(NULL, response);
+}
+
#if CONFIG_IS_ENABLED(FASTBOOT_CMD_OEM_FORMAT)
/**
* oem_format() - Execute the OEM format command
diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c
index 384c0f6f6e27..30f7a52087fc 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -455,6 +455,8 @@ static void rx_handler_command(struct usb_ep *ep, struct
usb_request *req)
case FASTBOOT_COMMAND_REBOOT:
case FASTBOOT_COMMAND_REBOOT_BOOTLOADER:
+ case FASTBOOT_COMMAND_REBOOT_FASTBOOTD:
+ case FASTBOOT_COMMAND_REBOOT_RECOVERY:
fastboot_func->in_req->complete = compl_do_reset;
break;
}
diff --git a/include/fastboot.h b/include/fastboot.h
index 14f4c68868d8..b86b508e69fd 100644
--- a/include/fastboot.h
+++ b/include/fastboot.h
@@ -32,6 +32,8 @@ enum {
FASTBOOT_COMMAND_CONTINUE,
FASTBOOT_COMMAND_REBOOT,
FASTBOOT_COMMAND_REBOOT_BOOTLOADER,
+ FASTBOOT_COMMAND_REBOOT_FASTBOOTD,
+ FASTBOOT_COMMAND_REBOOT_RECOVERY,
FASTBOOT_COMMAND_SET_ACTIVE,
#if CONFIG_IS_ENABLED(FASTBOOT_CMD_OEM_FORMAT)
FASTBOOT_COMMAND_OEM_FORMAT,
@@ -45,6 +47,8 @@ enum {
*/
enum fastboot_reboot_reason {
FASTBOOT_REBOOT_REASON_BOOTLOADER,
+ FASTBOOT_REBOOT_REASON_FASTBOOTD,
+
[PATCH v5 0/3] Add support for booting into userspace fastboot
Android 10 adds support for dynamic partitions and in order to support them userspace fastboot must be used[1]. New tool called fastbootd is included into recovery image. Userspace fastboot works from recovery and is launched if: 1) - Dynamic partitioning is enabled 2) - Boot control block has 'boot-fastboot' value into command field The bootloader is expected[2] to load and boot into the recovery image upon seeing boot-fastboot in the BCB command. Recovery then parses the BCB message and switches to fastbootd mode. Please note that boot script is expected to handle 'boot-fastboot' command in BCB and load into recovery mode. Bootloader must support[3] 'reboot fastboot' command which should reboot device into userspace fastboot to accomodate those changes. Another command that bootloader must support[3] is 'reboot recovery'. This command should simply reboot device into recovery mode. Changes since v4[7]: * Moved BCB commands table next to reboot reasons enum to avoid issues in future with keeping them in sync * Changed command buffer size to 64 to fix issue with longer string in case of bootonce-bootloader command Changes since v3[6]: * Fixed indentation in Kconfig * Fixed default value for FASTBOOT_USE_BCB_SET_REBOOT_FLAG * Extended help message for FASTBOOT_USE_BCB_SET_REBOOT_FLAG Changes since v2[5]: * Split patch 1 into two separate patches: * Patch 1 extends fastboot_set_reboot_flag arguments with reboot reason * Patch 2 adds new reboot reasons for fastbootd and recovery * Added name for fastboot_rebot_reason enum * Replaced switch inside fastboot_set_reboot_flag with table lookup * Moved fastboot_set_reboot_flag BCB implementation to separate file Changes since v1[4]: * Added missing handling of reboot commands for network protocol * Extended fastboot_set_reboot_flag command to accept reboot reason * Made former fastboot_set_flag function as an optional implementation of fastboot_set_reboot_flag which could be turned on by Kconfig [1] - https://source.android.com/devices/bootloader/fastbootd [2] - https://source.android.com/devices/bootloader/fastbootd#unified_fastboot_and_recovery [3] - https://source.android.com/devices/bootloader/fastbootd#modifications_to_the_bootloader [4] - http://patchwork.ozlabs.org/project/uboot/cover/cover.1590539734.git.roman.kovalivs...@globallogic.com/ [5] - http://patchwork.ozlabs.org/project/uboot/cover/cover.1591254465.git.roman.kovalivs...@globallogic.com/ [6] - http://patchwork.ozlabs.org/project/uboot/cover/cover.1591806433.git.roman.kovalivs...@globallogic.com/ [7] - http://patchwork.ozlabs.org/project/uboot/cover/cover.1592871839.git.roman.kovalivs...@globallogic.com/ Roman Kovalivskyi (3): fastboot: Extend fastboot_set_reboot_flag with reboot reason fastboot: Add support for 'reboot fastboot' command fastboot: Add default fastboot_set_reboot_flag implementation arch/arm/mach-meson/board-common.c | 6 - arch/arm/mach-rockchip/board.c | 6 - board/amazon/kc1/kc1.c | 6 - board/lg/sniper/sniper.c | 6 - board/ti/am57xx/board.c| 6 - board/ti/dra7xx/evm.c | 6 - drivers/fastboot/Kconfig | 12 + drivers/fastboot/Makefile | 1 + drivers/fastboot/fb_bcb_impl.c | 43 ++ drivers/fastboot/fb_command.c | 40 ++- drivers/fastboot/fb_common.c | 2 +- drivers/usb/gadget/f_fastboot.c| 2 ++ include/fastboot.h | 23 +++- net/fastboot.c | 2 ++ 14 files changed, 152 insertions(+), 9 deletions(-) create mode 100644 drivers/fastboot/fb_bcb_impl.c -- 2.17.1
[PATCH v5 1/3] fastboot: Extend fastboot_set_reboot_flag with reboot reason
Extend fastboot_set_reboot_flag arguments with reboot reason so that
it could handle different reboot cases in future.
Signed-off-by: Roman Kovalivskyi
---
arch/arm/mach-meson/board-common.c | 6 +-
arch/arm/mach-rockchip/board.c | 6 +-
board/amazon/kc1/kc1.c | 6 +-
board/lg/sniper/sniper.c | 6 +-
board/ti/am57xx/board.c| 6 +-
board/ti/dra7xx/evm.c | 6 +-
drivers/fastboot/fb_command.c | 2 +-
drivers/fastboot/fb_common.c | 2 +-
include/fastboot.h | 10 +-
9 files changed, 41 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-meson/board-common.c
b/arch/arm/mach-meson/board-common.c
index 19e5bfd3660c..a1f08bb98c6f 100644
--- a/arch/arm/mach-meson/board-common.c
+++ b/arch/arm/mach-meson/board-common.c
@@ -5,6 +5,7 @@
#include
#include
+#include
#include
#include
#include
@@ -153,8 +154,11 @@ int board_late_init(void)
#if CONFIG_IS_ENABLED(FASTBOOT)
static unsigned int reboot_reason = REBOOT_REASON_NORMAL;
-int fastboot_set_reboot_flag()
+int fastboot_set_reboot_flag(enum fastboot_reboot_reason reason)
{
+ if (reason != FASTBOOT_REBOOT_REASON_BOOTLOADER)
+ return -ENOTSUPP;
+
reboot_reason = REBOOT_REASON_BOOTLOADER;
printf("Using reboot reason: 0x%x\n", reboot_reason);
diff --git a/arch/arm/mach-rockchip/board.c b/arch/arm/mach-rockchip/board.c
index 430c0cbf41e4..ba4da72b3910 100644
--- a/arch/arm/mach-rockchip/board.c
+++ b/arch/arm/mach-rockchip/board.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -152,8 +153,11 @@ int board_usb_init(int index, enum usb_init_type init)
#endif /* CONFIG_USB_GADGET */
#if CONFIG_IS_ENABLED(FASTBOOT)
-int fastboot_set_reboot_flag(void)
+int fastboot_set_reboot_flag(enum fastboot_reboot_reason reason)
{
+ if (reason != FASTBOOT_REBOOT_REASON_BOOTLOADER)
+ return -ENOTSUPP;
+
printf("Setting reboot to fastboot flag ...\n");
/* Set boot mode to fastboot */
writel(BOOT_FASTBOOT, CONFIG_ROCKCHIP_BOOT_MODE_REG);
diff --git a/board/amazon/kc1/kc1.c b/board/amazon/kc1/kc1.c
index fb1828ff44da..445980f16e62 100644
--- a/board/amazon/kc1/kc1.c
+++ b/board/amazon/kc1/kc1.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -163,8 +164,11 @@ void get_board_serial(struct tag_serialnr *serialnr)
omap_die_id_get_board_serial(serialnr);
}
-int fastboot_set_reboot_flag(void)
+int fastboot_set_reboot_flag(enum fastboot_reboot_reason reason)
{
+ if (reason != FASTBOOT_REBOOT_REASON_BOOTLOADER)
+ return -ENOTSUPP;
+
return omap_reboot_mode_store("b");
}
diff --git a/board/lg/sniper/sniper.c b/board/lg/sniper/sniper.c
index 2825eccc035a..99b832fe601b 100644
--- a/board/lg/sniper/sniper.c
+++ b/board/lg/sniper/sniper.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -175,8 +176,11 @@ void reset_misc(void)
omap_reboot_mode_store(reboot_mode);
}
-int fastboot_set_reboot_flag(void)
+int fastboot_set_reboot_flag(enum fastboot_reboot_reason reason)
{
+ if (reason != FASTBOOT_REBOOT_REASON_BOOTLOADER)
+ return -ENOTSUPP;
+
return omap_reboot_mode_store("b");
}
diff --git a/board/ti/am57xx/board.c b/board/ti/am57xx/board.c
index 8720eb87a55d..49afd3bc927b 100644
--- a/board/ti/am57xx/board.c
+++ b/board/ti/am57xx/board.c
@@ -9,6 +9,7 @@
#include
#include
+#include
#include
#include
#include
@@ -1169,8 +1170,11 @@ int board_fit_config_name_match(const char *name)
#endif
#if CONFIG_IS_ENABLED(FASTBOOT) && !CONFIG_IS_ENABLED(ENV_IS_NOWHERE)
-int fastboot_set_reboot_flag(void)
+int fastboot_set_reboot_flag(enum fastboot_reboot_reason reason)
{
+ if (reason != FASTBOOT_REBOOT_REASON_BOOTLOADER)
+ return -ENOTSUPP;
+
printf("Setting reboot to fastboot flag ...\n");
env_set("dofastboot", "1");
env_save();
diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
index acf7ff169170..3bc40c721146 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1050,8 +1051,11 @@ int board_fit_config_name_match(const char *name)
#endif
#if CONFIG_IS_ENABLED(FASTBOOT) && !CONFIG_IS_ENABLED(ENV_IS_NOWHERE)
-int fastboot_set_reboot_flag(void)
+int fastboot_set_reboot_flag(enum fastboot_reboot_reason reason)
{
+ if (reason != FASTBOOT_REBOOT_REASON_BOOTLOADER)
+ return -ENOTSUPP;
+
printf("Setting reboot to fastboot flag ...\n");
env_set("dofastboot", "1");
env_save();
diff --git a/drivers/fastboot/fb_command.c b/drivers/fastboot/fb_command.c
index 49f6a61c3745..8ce5d32fb2ba 100644
--- a/drivers/fastboot/fb_command.c
+++
Re: [PATCH v1 05/24] pci: pci-uclass: Make DT subnode parse optional
On Fri, 24 Jul 2020 at 04:09, Stefan Roese wrote: > > From: Suneel Garapati > > Parse subnode DT properties only if parent node is valid. > Otherwise, assert is triggered on ofnode_valid in ofnode_first_subnode > from dev_for_each_subnode. > > Signed-off-by: Suneel Garapati > Reviewed-by: Simon Glass > Cc: Bin Meng > > Signed-off-by: Stefan Roese > --- > > Changes in v1: > - Change patch subject > > drivers/pci/pci-uclass.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) Reviewed-by: Simon Glass
Re: [PATCH v2] fit_image: Use calloc() to fix reproducibility issue
On 2020-07-27, Fabio Estevam wrote:
> Vagrant Cascadian reported that mx6cuboxi target no longer builds
> reproducibility on Debian.
>
> One example of builds mismatches:
>
> 00096680: 696e 6700 736f 756e 642d 6461 6900 6465 ing.sound-dai.de
> -00096690: 7465 6374 2d67 7069 6f73 tect-gpios..
> +00096690: 7465 6374 2d67 7069 6f73 0061tect-gpios.a
>
> This problem happens because all the buffers in fit_image.c are
> allocated via malloc(), which does not zero out the allocated buffer.
>
> Using calloc() fixes this unpredictable behaviour as it guarantees
> that the allocated buffer are zero initialized.
>
> Reported-by: Vagrant Cascadian
> Suggested-by: Tom Rini
> Signed-off-by: Fabio Estevam
Tested that it boots on the mx6cuboxi supported board hummingboard i2ex,
and that it fixes the reproducibility issues.
Thanks!
Tested-by: Vagrant Cascadian
live well,
vagrant
> ---
> Changes since v1:
> - Improve the commit log description by stating why calloc() helps.
>
> tools/fit_image.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/tools/fit_image.c b/tools/fit_image.c
> index a082d9386d..0c6185d892 100644
> --- a/tools/fit_image.c
> +++ b/tools/fit_image.c
> @@ -388,7 +388,7 @@ static int fit_build(struct image_tool_params *params,
> const char *fname)
> size = fit_calc_size(params);
> if (size < 0)
> return -1;
> - buf = malloc(size);
> + buf = calloc(1, size);
> if (!buf) {
> fprintf(stderr, "%s: Out of memory (%d bytes)\n",
> params->cmdname, size);
> @@ -467,7 +467,7 @@ static int fit_extract_data(struct image_tool_params
> *params, const char *fname)
>* Allocate space to hold the image data we will extract,
>* extral space allocate for image alignment to prevent overflow.
>*/
> - buf = malloc(fit_size + (align_size * image_number));
> + buf = calloc(1, fit_size + (align_size * image_number));
> if (!buf) {
> ret = -ENOMEM;
> goto err_munmap;
> @@ -572,7 +572,7 @@ static int fit_import_data(struct image_tool_params
> *params, const char *fname)
>
> /* Allocate space to hold the new FIT */
> size = sbuf.st_size + 16384;
> - fdt = malloc(size);
> + fdt = calloc(1, size);
> if (!fdt) {
> fprintf(stderr, "%s: Failed to allocate memory (%d bytes)\n",
> __func__, size);
> @@ -673,7 +673,7 @@ static int copyfile(const char *src, const char *dst)
> goto out;
> }
>
> - buf = malloc(512);
> + buf = calloc(1, 512);
> if (!buf) {
> printf("Can't allocate buffer to copy file\n");
> goto out;
> --
> 2.17.1
signature.asc
Description: PGP signature
Re: [PATCH v1 02/24] pci: pci-uclass: Remove #ifdef CONFIG_NR_DRAM_BANKS as its always set
Hi Stefan, On Fri, 24 Jul 2020 at 04:09, Stefan Roese wrote: > > Since the migration to Kconfig, CONFIG_NR_DRAM_BANKS is configured for > all boards. Hence we can remove the conditional compilation and the code > path that will never get compiled. > > Signed-off-by: Stefan Roese > Cc: Tom Rini > Cc: Simon Glass > Cc: Bin Meng > > --- > > Changes in v1: > - New patch > > drivers/pci/pci-uclass.c | 17 + > 1 file changed, 1 insertion(+), 16 deletions(-) > Reviewed-by: Simon Glass
Re: [PATCH v1 01/24] fdtdec: Add API to read pci bus-range property
On Fri, 24 Jul 2020 at 04:09, Stefan Roese wrote:
>
> From: Suneel Garapati
>
> Add fdtdec_get_pci_bus_range to read bus-range property
> values.
>
> Signed-off-by: Suneel Garapati
> Cc: Simon Glass
>
> Signed-off-by: Stefan Roese
> ---
>
> Changes in v1:
> - Added return value description to function prototype in header
> - Changed from using be32_to_cpup() to fdt32_to_cpu()
>
> include/fdtdec.h | 13 +
> lib/fdtdec.c | 16
> 2 files changed, 29 insertions(+)
Reviewed-by: Simon Glass
Is the address always 32-bit?
>
> diff --git a/include/fdtdec.h b/include/fdtdec.h
> index 760b392bdf..f6759c7f8e 100644
> --- a/include/fdtdec.h
> +++ b/include/fdtdec.h
> @@ -444,6 +444,19 @@ int fdtdec_get_pci_vendev(const void *blob, int node,
> int fdtdec_get_pci_bar32(const struct udevice *dev, struct fdt_pci_addr
> *addr,
> u32 *bar);
>
> +/**
> + * Look at the bus range property of a device node and return the pci bus
> + * range for this node.
> + * The property must hold one fdt_pci_addr with a length.
> + * @param blob FDT blob
> + * @param node node to examine
> + * @param res the resource structure to return the bus range
> + * @return 0 if ok, negative on error
> + */
> +
> +int fdtdec_get_pci_bus_range(const void *blob, int node,
> +struct fdt_resource *res);
> +
> /**
> * Look up a 32-bit integer property in a node and return it. The property
> * must have at least 4 bytes of data. The value of the first cell is
> diff --git a/lib/fdtdec.c b/lib/fdtdec.c
> index 78576b530f..0b40fa374a 100644
> --- a/lib/fdtdec.c
> +++ b/lib/fdtdec.c
> @@ -242,6 +242,22 @@ int fdtdec_get_pci_bar32(const struct udevice *dev,
> struct fdt_pci_addr *addr,
>
> return 0;
> }
> +
> +int fdtdec_get_pci_bus_range(const void *blob, int node,
> +struct fdt_resource *res)
> +{
> + const u32 *values;
> + int len;
> +
> + values = fdt_getprop(blob, node, "bus-range", );
> + if (!values || len < sizeof(*values) * 2)
> + return -EINVAL;
> +
> + res->start = fdt32_to_cpu(*values++);
> + res->end = fdt32_to_cpu(*values);
> +
> + return 0;
> +}
> #endif
>
> uint64_t fdtdec_get_uint64(const void *blob, int node, const char *prop_name,
> --
> 2.27.0
>
Re: [PATCH v2 01/18] Add MIT License
On Mon, 20 Jul 2020 at 05:02, Anastasiia Lukianenko wrote: > > From: Anastasiia Lukianenko Please add commit message > > Signed-off-by: Anastasiia Lukianenko > --- > Licenses/README | 1 + > Licenses/mit.txt | 20 > 2 files changed, 21 insertions(+) > create mode 100644 Licenses/mit.txt Reviewed-by: Simon Glass
Re: [PATCH v1 04/24] pci: pci-uclass: Fix incorrect argument in map_sysmem
On Fri, 24 Jul 2020 at 04:09, Stefan Roese wrote: > > From: Suneel Garapati > > Minor spelling correction. Need to update this > > Signed-off-by: Suneel Garapati > Reviewed-by: Simon Glass > Cc: Bin Meng > > Signed-off-by: Stefan Roese > --- > > Changes in v1: > - Change patch subject > > drivers/pci/pci-uclass.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Simon Glass > > diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c > index 0fbbef70c8..207302cfc4 100644 > --- a/drivers/pci/pci-uclass.c > +++ b/drivers/pci/pci-uclass.c > @@ -1382,7 +1382,7 @@ static void *dm_pci_map_ea_bar(struct udevice *dev, int > bar, int flags, > } > > /* size ignored for now */ > - return map_physmem(addr, flags, 0); > + return map_physmem(addr, 0, flags); > } > > return 0; > @@ -1408,7 +1408,7 @@ void *dm_pci_map_bar(struct udevice *dev, int bar, int > flags) > > /* > * Pass "0" as the length argument to pci_bus_to_virt. The arg > -* isn't actualy used on any platform because u-boot assumes a static > +* isn't actually used on any platform because u-boot assumes a static U-Boot > * linear mapping. In the future, this could read the BAR size > * and pass that as the size if needed. > */ > -- > 2.27.0 >
Re: [PATCH v1 03/24] pci: pci-uclass: Dynamically allocate the PCI regions
Hi Stefan,
On Fri, 24 Jul 2020 at 04:09, Stefan Roese wrote:
>
> Instead of using a fixed length pre-allocated array of regions, this
> patch moves to dynamically allocating the regions based on the number
> of available regions plus the necessary regions for DRAM banks.
>
> Since MAX_PCI_REGIONS is not needed any more, its removed completely
> with this patch.
>
> Signed-off-by: Stefan Roese
> Cc: Simon Glass
> Cc: Bin Meng
> Cc: Thierry Reding
> Cc: Marek Vasut
>
> ---
>
> Changes in v1:
> - New patch, replaces increase of MAX_PCI_REGIONS to 10
>
> board/renesas/rcar-common/common.c | 10 +-
> drivers/pci/pci-uclass.c | 14 --
> include/pci.h | 4 +---
> 3 files changed, 14 insertions(+), 14 deletions(-)
>
Can you please split out the generic PCI changes into a separate patch?
> diff --git a/board/renesas/rcar-common/common.c
> b/board/renesas/rcar-common/common.c
> index 83dd288847..83440c11ef 100644
> --- a/board/renesas/rcar-common/common.c
> +++ b/board/renesas/rcar-common/common.c
> @@ -58,12 +58,12 @@ int ft_board_setup(void *blob, struct bd_info *bd)
> uclass_foreach_dev(dev, uc) {
> struct pci_controller hose = { 0 };
>
> - for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) {
> - if (hose.region_count == MAX_PCI_REGIONS) {
> - printf("maximum number of regions parsed,
> aborting\n");
> - break;
> - }
> + /* Dynamically allocate the regions array */
Why is the driver allocating this? Shouldn't it happen in pci-uclass.c ?
> + hose.regions = (struct pci_region *)
> + calloc(1, CONFIG_NR_DRAM_BANKS *
> + sizeof(struct pci_region));
>
> + for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) {
> if (bd->bi_dram[i].size) {
>
> pci_set_region([hose.region_count++],
>bd->bi_dram[i].start,
> diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
> index 69fb46d3f4..0fbbef70c8 100644
> --- a/drivers/pci/pci-uclass.c
> +++ b/drivers/pci/pci-uclass.c
> @@ -874,6 +874,7 @@ static void decode_regions(struct pci_controller *hose,
> ofnode parent_node,
> struct bd_info *bd = gd->bd;
> int cells_per_record;
> const u32 *prop;
> + int max_regions;
> int len;
> int i;
>
> @@ -893,7 +894,13 @@ static void decode_regions(struct pci_controller *hose,
> ofnode parent_node,
> hose->region_count = 0;
> debug("%s: len=%d, cells_per_record=%d\n", __func__, len,
> cells_per_record);
> - for (i = 0; i < MAX_PCI_REGIONS; i++, len -= cells_per_record) {
> +
> + /* Dynamically allocate the regions array */
> + max_regions = len / cells_per_record + CONFIG_NR_DRAM_BANKS;
> + hose->regions = (struct pci_region *)
> + calloc(1, max_regions * sizeof(struct pci_region));
> +
> + for (i = 0; i < max_regions; i++, len -= cells_per_record) {
> u64 pci_addr, addr, size;
> int space_code;
> u32 flags;
> @@ -943,11 +950,6 @@ static void decode_regions(struct pci_controller *hose,
> ofnode parent_node,
> return;
>
> for (i = 0; i < CONFIG_NR_DRAM_BANKS; ++i) {
> - if (hose->region_count == MAX_PCI_REGIONS) {
> - pr_err("maximum number of regions parsed,
> aborting\n");
> - break;
> - }
> -
> if (bd->bi_dram[i].size) {
> pci_set_region(hose->regions + hose->region_count++,
>bd->bi_dram[i].start,
> diff --git a/include/pci.h b/include/pci.h
> index 281f353916..53f1386fd4 100644
> --- a/include/pci.h
> +++ b/include/pci.h
> @@ -590,8 +590,6 @@ extern void pci_cfgfunc_do_nothing(struct pci_controller*
> hose, pci_dev_t dev,
> extern void pci_cfgfunc_config_device(struct pci_controller* hose, pci_dev_t
> dev,
> struct pci_config_table *);
>
> -#define MAX_PCI_REGIONS7
> -
> #define INDIRECT_TYPE_NO_PCIE_LINK 1
>
> /**
> @@ -632,7 +630,7 @@ struct pci_controller {
> * for PCI controllers and a separate UCLASS (or perhaps
> * UCLASS_PCI_GENERIC) is used for bridges.
> */
> - struct pci_region regions[MAX_PCI_REGIONS];
> + struct pci_region *regions;
> int region_count;
>
> struct pci_config_table *config_table;
> --
> 2.27.0
>
Re: [PATCH v1 22/24] watchdog: Add reset support for OcteonTX / TX2
On Fri, 24 Jul 2020 at 04:09, Stefan Roese wrote:
>
> From: Suneel Garapati
>
> Adds support for Core 0 watchdog poke on OcteonTX and OcteonTX2
> platforms.
>
> Signed-off-by: Suneel Garapati
> Signed-off-by: Stefan Roese
>
> ---
>
> Changes in v1:
> - Change patch subject
> - Remove inclusion of common.h
> - Remove global wdt_dev as its unused
> - Remove #ifdef's
> - Remove optional fixed register access - only use address passed via
> DT while probing
> - Use dev_remap_addr() instead of dev_read_addr_index()
>
> drivers/watchdog/Kconfig| 10 ++
> drivers/watchdog/Makefile | 1 +
> drivers/watchdog/octeontx_wdt.c | 57 +
> 3 files changed, 68 insertions(+)
> create mode 100644 drivers/watchdog/octeontx_wdt.c
Reviewed-by: Simon Glass
>
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index bf06180cdd..981b33355d 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -139,6 +139,16 @@ config WDT_MTK
> The watchdog timer is stopped when initialized.
> It performs full SoC reset.
>
> +config WDT_OCTEONTX
> + bool "OcteonTX core watchdog support"
> + depends on WDT && (ARCH_OCTEONTX || ARCH_OCTEONTX2)
> + default y if WDT && ARCH_OCTEONTX || ARCH_OCTEONTX2
> + imply WATCHDOG
> + help
> + This enables OcteonTX watchdog driver, which can be
> + found on OcteonTX/TX2 chipsets and inline with driver model.
> + Only supports watchdog reset.
> +
> config WDT_OMAP3
> bool "TI OMAP watchdog timer support"
> depends on WDT && ARCH_OMAP2PLUS
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index 519bbd3a40..fbba0ca386 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -26,6 +26,7 @@ obj-$(CONFIG_WDT_CDNS) += cdns_wdt.o
> obj-$(CONFIG_WDT_MPC8xx) += mpc8xx_wdt.o
> obj-$(CONFIG_WDT_MT7621) += mt7621_wdt.o
> obj-$(CONFIG_WDT_MTK) += mtk_wdt.o
> +obj-$(CONFIG_WDT_OCTEONTX) += octeontx_wdt.o
> obj-$(CONFIG_WDT_OMAP3) += omap_wdt.o
> obj-$(CONFIG_WDT_SP805) += sp805_wdt.o
> obj-$(CONFIG_WDT_STM32MP) += stm32mp_wdt.o
> diff --git a/drivers/watchdog/octeontx_wdt.c b/drivers/watchdog/octeontx_wdt.c
> new file mode 100644
> index 00..a9c29ef26a
> --- /dev/null
> +++ b/drivers/watchdog/octeontx_wdt.c
> @@ -0,0 +1,57 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019 Marvell International Ltd.
> + *
> + * https://spdx.org/licenses
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +#define CORE0_POKE_OFFSET 0x5
> +
> +struct octeontx_wdt {
> + void __iomem *reg;
> +};
> +
> +static int octeontx_wdt_reset(struct udevice *dev)
> +{
> + struct octeontx_wdt *priv = dev_get_priv(dev);
> +
> + writeq(~0ULL, ((u64)priv->reg & ~0xfULL) | CORE0_POKE_OFFSET);
Do you actually need the mask? It seems odd that ->reg is part-way
through the register set.
> +
> + return 0;
> +}
> +
> +static int octeontx_wdt_probe(struct udevice *dev)
> +{
> + struct octeontx_wdt *priv = dev_get_priv(dev);
> +
> + priv->reg = dev_remap_addr(dev);
> + if (!priv->reg)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +static const struct wdt_ops octeontx_wdt_ops = {
> + .reset = octeontx_wdt_reset,
> +};
> +
> +static const struct udevice_id octeontx_wdt_ids[] = {
> + { .compatible = "arm,sbsa-gwdt" },
> + {}
> +};
> +
> +U_BOOT_DRIVER(wdt_octeontx) = {
> + .name = "wdt_octeontx",
> + .id = UCLASS_WDT,
> + .of_match = octeontx_wdt_ids,
> + .ops = _wdt_ops,
> + .priv_auto_alloc_size = sizeof(struct octeontx_wdt),
> + .probe = octeontx_wdt_probe,
> +};
> --
> 2.27.0
>
Re: [PATCH v1 14/24] arm: octeontx2: Add headers for OcteonTX2
Hi Stefan, On Fri, 24 Jul 2020 at 04:09, Stefan Roese wrote: > > From: Suneel Garapati > > Signed-off-by: Suneel Garapati > > Signed-off-by: Stefan Roese > --- > > Changes in v1: > - Change patch subject > > arch/arm/include/asm/arch-octeontx2/board.h | 128 + > arch/arm/include/asm/arch-octeontx2/clock.h |24 + > .../asm/arch-octeontx2/csrs/csrs-cgx.h| 7851 > .../asm/arch-octeontx2/csrs/csrs-lmt.h|60 + > .../asm/arch-octeontx2/csrs/csrs-mio_emm.h| 1193 ++ > .../asm/arch-octeontx2/csrs/csrs-nix.h| 10404 > .../asm/arch-octeontx2/csrs/csrs-npa.h| 2294 > .../asm/arch-octeontx2/csrs/csrs-npc.h| 1629 +++ > .../asm/arch-octeontx2/csrs/csrs-rvu.h| 2276 > arch/arm/include/asm/arch-octeontx2/gpio.h| 6 + > arch/arm/include/asm/arch-octeontx2/smc-id.h |32 + > arch/arm/include/asm/arch-octeontx2/smc.h |18 + > arch/arm/include/asm/arch-octeontx2/soc.h |33 + > 13 files changed, 25948 insertions(+) > create mode 100644 arch/arm/include/asm/arch-octeontx2/board.h > create mode 100644 arch/arm/include/asm/arch-octeontx2/clock.h > create mode 100644 arch/arm/include/asm/arch-octeontx2/csrs/csrs-cgx.h > create mode 100644 arch/arm/include/asm/arch-octeontx2/csrs/csrs-lmt.h > create mode 100644 arch/arm/include/asm/arch-octeontx2/csrs/csrs-mio_emm.h > create mode 100644 arch/arm/include/asm/arch-octeontx2/csrs/csrs-nix.h > create mode 100644 arch/arm/include/asm/arch-octeontx2/csrs/csrs-npa.h > create mode 100644 arch/arm/include/asm/arch-octeontx2/csrs/csrs-npc.h > create mode 100644 arch/arm/include/asm/arch-octeontx2/csrs/csrs-rvu.h > create mode 100644 arch/arm/include/asm/arch-octeontx2/gpio.h > create mode 100644 arch/arm/include/asm/arch-octeontx2/smc-id.h > create mode 100644 arch/arm/include/asm/arch-octeontx2/smc.h > create mode 100644 arch/arm/include/asm/arch-octeontx2/soc.h Same comments as the previous patch. Also, how much of this ~20K lines of code is actually used in U-Boot? Regards, Simon
Re: [PATCH v1 17/24] mmc: Remove static qualifier on mmc_power_init
Hi Stefan,
On Fri, 24 Jul 2020 at 04:09, Stefan Roese wrote:
>
> From: Suneel Garapati
>
> For platforms with multiple slot support like OcteonTX,
> this is invoked per slot.
>
> Signed-off-by: Suneel Garapati
> Cc: Peng Fan
>
> Signed-off-by: Stefan Roese
> ---
>
> Changes in v1:
> - Change patch subject
>
> drivers/mmc/mmc.c | 2 +-
> include/mmc.h | 1 +
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index f36d11ddc8..b26df59b91 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -2683,7 +2683,7 @@ __weak void board_mmc_power_init(void)
> }
> #endif
>
> -static int mmc_power_init(struct mmc *mmc)
> +int mmc_power_init(struct mmc *mmc)
Shouldn't multi-slot be a core MMC featuren then?
> {
> #if CONFIG_IS_ENABLED(DM_MMC)
> #if CONFIG_IS_ENABLED(DM_REGULATOR)
> diff --git a/include/mmc.h b/include/mmc.h
> index 82562193cc..e05c59713c 100644
> --- a/include/mmc.h
> +++ b/include/mmc.h
> @@ -747,6 +747,7 @@ int mmc_unbind(struct udevice *dev);
> int mmc_initialize(struct bd_info *bis);
> int mmc_init_device(int num);
> int mmc_init(struct mmc *mmc);
> +int mmc_power_init(struct mmc *mmc);
This badly needs a comment to explain what it is for and when to call it.
> int mmc_send_tuning(struct mmc *mmc, u32 opcode, int *cmd_error);
>
> #if CONFIG_IS_ENABLED(MMC_UHS_SUPPORT) || \
> --
> 2.27.0
>
Regards,
Simon
Re: [PATCH v1 13/24] arm: octeontx: Add headers for OcteonTX
Hi Stefan, On Fri, 24 Jul 2020 at 04:09, Stefan Roese wrote: > > From: Suneel Garapati > > Signed-off-by: Suneel Garapati > > Signed-off-by: Stefan Roese > --- > > Changes in v1: > - Change patch subject > > arch/arm/include/asm/arch-octeontx/board.h| 123 ++ > arch/arm/include/asm/arch-octeontx/clock.h| 25 + > .../asm/arch-octeontx/csrs/csrs-mio_emm.h | 1193 + > .../include/asm/arch-octeontx/csrs/csrs-xcv.h | 428 ++ > arch/arm/include/asm/arch-octeontx/gpio.h |6 + > arch/arm/include/asm/arch-octeontx/smc.h | 20 + > arch/arm/include/asm/arch-octeontx/soc.h | 33 + > 7 files changed, 1828 insertions(+) > create mode 100644 arch/arm/include/asm/arch-octeontx/board.h > create mode 100644 arch/arm/include/asm/arch-octeontx/clock.h > create mode 100644 arch/arm/include/asm/arch-octeontx/csrs/csrs-mio_emm.h > create mode 100644 arch/arm/include/asm/arch-octeontx/csrs/csrs-xcv.h > create mode 100644 arch/arm/include/asm/arch-octeontx/gpio.h > create mode 100644 arch/arm/include/asm/arch-octeontx/smc.h > create mode 100644 arch/arm/include/asm/arch-octeontx/soc.h Reviewed-by: Simon Glass Generic thoughts to consider: - drop extra brackets around constants - e.g. MIO_EMM_BAR_E_MIO_EMM_PF_BAR4 - use #define or enum instead of inline functions, e.g. MIO_EMM_DMA - lower-case hex I don't normally see bitfields in U-Boot. Is that a good idea? Regards, Simon
Re: [PATCH v1 15/24] ata: ahci: Add BAR index quirk for Cavium PCI SATA device
Hi Stefan,
On Fri, 24 Jul 2020 at 04:09, Stefan Roese wrote:
>
> From: Suneel Garapati
>
> For SATA controller found on OcteonTX SoC's, use non-standard PCI BAR0
> instead of BAR5.
>
> Signed-off-by: Suneel Garapati
> Cc: Simon Glass
>
> Signed-off-by: Stefan Roese
> ---
>
> Changes in v1:
> - Change patch subject
> - Use constants from pci_ids.h instead of hardcoded values
>
> drivers/ata/ahci.c | 8
> 1 file changed, 8 insertions(+)
Reviewed-by: Simon Glass
>
> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
> index 47cdea1f58..28161b5e62 100644
> --- a/drivers/ata/ahci.c
> +++ b/drivers/ata/ahci.c
> @@ -1198,10 +1198,18 @@ int ahci_probe_scsi(struct udevice *ahci_dev, ulong
> base)
> int ahci_probe_scsi_pci(struct udevice *ahci_dev)
> {
> ulong base;
> + u16 vendor, device;
>
> base = (ulong)dm_pci_map_bar(ahci_dev, PCI_BASE_ADDRESS_5,
> PCI_REGION_MEM);
>
> + dm_pci_read_config16(ahci_dev, PCI_VENDOR_ID, );
> + dm_pci_read_config16(ahci_dev, PCI_DEVICE_ID, );
> +
> + if (vendor == PCI_VENDOR_ID_CAVIUM &&
> + device == PCI_DEVICE_ID_CAVIUM_SATA)
> + base = (uintptr_t)dm_pci_map_bar(ahci_dev, PCI_BASE_ADDRESS_0,
> +PCI_REGION_MEM);
How should we handle this in general? Should we have a Kconfig to
enable quirks in ahci?
> return ahci_probe_scsi(ahci_dev, base);
> }
> #endif
> --
> 2.27.0
>
Regards,
Simon
Re: [PATCH v1 09/24] pci: pci-uclass: Add VF BAR map support for Enhanced Allocation
On Fri, 24 Jul 2020 at 04:09, Stefan Roese wrote: > > From: Suneel Garapati > > Makes dm_pci_map_bar API available to map BAR for Virtual function > PCI devices which support Enhanced Allocation. > > Signed-off-by: Suneel Garapati > Cc: Simon Glass > Cc: Bin Meng > > Signed-off-by: Stefan Roese > --- > > Changes in v1: > - Change patch subject > - Fixed multi-line comment style > - Moved "feature" into new function which is only called, when > CONFIG_PCI_SRIOV is enabled, so that the code is not increased in > all cases > - Changed variable declaration to use reverse xmas tree order > > drivers/pci/pci-uclass.c | 67 +--- > include/pci.h| 3 ++ > 2 files changed, 65 insertions(+), 5 deletions(-) Again this needs a test... - Simon
Re: [PATCH v1 16/24] pci: Add PCI controller driver for OcteonTX / TX2
Hi Stefan,
On Fri, 24 Jul 2020 at 04:09, Stefan Roese wrote:
>
> From: Suneel Garapati
>
> Adds support for PCI ECAM/PEM controllers found on OcteonTX
> or OcteonTX2 SoC platforms.
>
> Signed-off-by: Suneel Garapati
> Cc: Simon Glass
> Cc: Bin Meng
>
> Signed-off-by: Stefan Roese
> ---
>
> Changes in v1:
> - Change patch subject
> - Remove inclusion of common.h
> - Remove #ifdef's and use driver specific data instead
> - Add comments to struct
> - Add some helper functions to reduce code size
> - Misc coding style changes (blank lines etc)
> - Use debug() instead of printf() in some cases
>
> drivers/pci/Kconfig| 8 +
> drivers/pci/Makefile | 1 +
> drivers/pci/pci_octeontx.c | 344 +
> 3 files changed, 353 insertions(+)
> create mode 100644 drivers/pci/pci_octeontx.c
Reviewed-by: Simon Glass
>
> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
> index bc77c23f89..89cca6ffb3 100644
> --- a/drivers/pci/Kconfig
> +++ b/drivers/pci/Kconfig
> @@ -149,6 +149,14 @@ config PCI_TEGRA
> with a total of 5 lanes. Some boards require this for Ethernet
> support to work (e.g. beaver, jetson-tk1).
>
> +config PCI_OCTEONTX
> + bool "OcteonTX PCI support"
> + depends on (ARCH_OCTEONTX || ARCH_OCTEONTX2)
> + help
> + Enable support for the OcteonTX/TX2 SoC family ECAM/PEM controllers.
> + These controllers provide PCI configuration access to all on-board
> + peripherals so it should only be disabled for testing purposes
> +
> config PCI_XILINX
> bool "Xilinx AXI Bridge for PCI Express"
> depends on DM_PCI
> diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
> index 6378821aaf..0529cceee7 100644
> --- a/drivers/pci/Makefile
> +++ b/drivers/pci/Makefile
> @@ -45,3 +45,4 @@ obj-$(CONFIG_PCI_KEYSTONE) += pcie_dw_ti.o
> obj-$(CONFIG_PCIE_MEDIATEK) += pcie_mediatek.o
> obj-$(CONFIG_PCIE_ROCKCHIP) += pcie_rockchip.o
> obj-$(CONFIG_PCI_BRCMSTB) += pcie_brcmstb.o
> +obj-$(CONFIG_PCI_OCTEONTX) += pci_octeontx.o
> diff --git a/drivers/pci/pci_octeontx.c b/drivers/pci/pci_octeontx.c
> new file mode 100644
> index 00..5c6a6f05f2
> --- /dev/null
> +++ b/drivers/pci/pci_octeontx.c
> @@ -0,0 +1,344 @@
> +// SPDX-License-Identifier:GPL-2.0
> +/*
> + * Copyright (C) 2018 Marvell International Ltd.
> + *
> + * https://spdx.org/licenses
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +enum {
comment?
> + OTX_ECAM,
> + OTX_PEM,
> + OTX2_PEM,
> +};
> +
> +/**
> + * struct octeontx_pci - Driver private data
> + * @type: Device type matched via compatible
> + * @cfg: Config resource
> + * @bus: Bus resource
> + */
> +struct octeontx_pci {
> + unsigned int type;
Is this the enum above?
> +
> + struct fdt_resource cfg;
> + struct fdt_resource bus;
> +};
> +
> +static uintptr_t octeontx_cfg_addr(struct octeontx_pci *pcie,
> + int bus_offs, int shift_offs,
> + pci_dev_t bdf, uint offset)
> +{
> + u32 bus, dev, func;
> + uintptr_t address;
> +
> + bus = PCI_BUS(bdf) + bus_offs;
> + dev = PCI_DEV(bdf);
> + func = PCI_FUNC(bdf);
> +
> + address = (bus << (20 + shift_offs)) |
> + (dev << (15 + shift_offs)) |
> + (func << (12 + shift_offs)) | offset;
> + address += pcie->cfg.start;
> +
> + return address;
> +}
> +
> +static ulong readl_size(uintptr_t addr, enum pci_size_t size)
> +{
> + ulong val;
> +
> + switch (size) {
> + case PCI_SIZE_8:
> + val = readb(addr);
> + break;
> + case PCI_SIZE_16:
> + val = readw(addr);
> + break;
> + case PCI_SIZE_32:
> + val = readl(addr);
> + break;
> + default:
> + printf("Invalid size\n");
return -EINVAL perhaps? Otherwise val is unset.
> + };
> +
> + return val;
> +}
> +
> +static void writel_size(uintptr_t addr, enum pci_size_t size, ulong valuep)
> +{
> + switch (size) {
> + case PCI_SIZE_8:
> + writeb(valuep, addr);
> + break;
> + case PCI_SIZE_16:
> + writew(valuep, addr);
> + break;
> + case PCI_SIZE_32:
> + writel(valuep, addr);
> + break;
> + default:
> + printf("Invalid size\n");
> + };
> +}
> +
> +static int octeontx_ecam_read_config(const struct udevice *bus, pci_dev_t
> bdf,
> +uint offset, ulong *valuep,
> +enum pci_size_t size)
> +{
> + struct octeontx_pci *pcie = (struct octeontx_pci *)dev_get_priv(bus);
> + struct pci_controller *hose = dev_get_uclass_priv(bus);
> + uintptr_t
Re: [PATCH v1 11/24] pci: pci-uclass: Check validity of ofnode
On Fri, 24 Jul 2020 at 04:09, Stefan Roese wrote: > > From: Suneel Garapati > > Add check if the referenced ofnode is valid. > > Signed-off-by: Suneel Garapati > Cc: Simon Glass > Cc: Bin Meng > > Signed-off-by: Stefan Roese > --- > > Changes in v1: > - New patch > > drivers/pci/pci-uclass.c | 10 +++--- > 1 file changed, 7 insertions(+), 3 deletions(-) > Reviewed-by: Simon Glass
Re: [PATCH v1 08/24] pci: pci-uclass: Add support for Single-Root I/O Virtualization
Hi Stefan, On Fri, 24 Jul 2020 at 04:09, Stefan Roese wrote: > > From: Suneel Garapati > > SR-IOV - Single Root I/O Virtualization > PF - Physical Function VF - Virtual Function > > If SR-IOV capability is present, use it to initialize Virtual Function > PCI device instances. pci_sriov_init function will read SR-IOV > registers to create VF devices under the PF PCI device and also bind > driver if available. This function needs to be invoked from Physical > function device driver which expects VF device support, creating > minimal impact on existing framework. > > Signed-off-by: Suneel Garapati > Cc: Simon Glass > Cc: Bin Meng > > Signed-off-by: Stefan Roese > --- > > Changes in v1: > - Change patch subject > - Enhance commit text: expanded the abbreviations > - Changed some printf() to debug() > - Changed 0 to '\0' in memset() > - Comments for variables in struct pci_child_platdata added > - Comments for newly introduced functions added in prototype / header > > drivers/pci/Kconfig | 10 > drivers/pci/pci-uclass.c | 114 +++ > include/pci.h| 38 + > 3 files changed, 162 insertions(+) This looks OK but all of these patches need updates to the sandbox tests to cover the new functionality. Regards, SImon
Re: [PATCH v1 06/24] pci: pci-uclass: Add multi entry support for memory regions
Hi Stefan, On Fri, 24 Jul 2020 at 04:09, Stefan Roese wrote: > > From: Suneel Garapati > > Enable PCI memory regions in ranges property to be of multiple entry. > This helps to add support for SoC's like OcteonTX/TX2 where every > peripheral is on PCI bus. > > Signed-off-by: Suneel Garapati > Cc: Simon Glass > Cc: Bin Meng > > Signed-off-by: Stefan Roese > --- > > Changes in v1: > - Change patch subject > - Enhance Kconfig help descrition > - Use if() instead of #if > > drivers/pci/Kconfig | 10 ++ > drivers/pci/pci-uclass.c | 9 ++--- > 2 files changed, 16 insertions(+), 3 deletions(-) This needs an update to a sandbox test to handle this behaviour.
Re: [PATCH] sandbox, test: change hog gpio
Hello Philippe,
Am 24.07.2020 um 15:51 schrieb Philippe Reynes:
> Since commit 9ba84329dc45 ("sandbox, test: add test for GPIO_HOG
> function"), the gpio_a 0,1,2 and 3 are used by hog in test.dts.
> But 2 leds 'sandbox:red' and 'sandbox:green' are using gpio_a 0
> and 1. As hog always request his gpios, the led command on both
> led is broken:
>
> => led sandbox:red
> LED 'sandbox:red' not found (err=-16)
>
> The gpio is already requested by hog, so it can't be enabled
> for led 'sandbox:red'.
>
> This commit change the gpio used by hog to 10, 11, 12 and 13,
> so the led command could be used again with 'sandbox:red' and
> 'sandbox:green'.
>
> Signed-off-by: Philippe Reynes
> ---
> arch/sandbox/dts/test.dts | 8
> test/dm/gpio.c| 12 ++--
> 2 files changed, 10 insertions(+), 10 deletions(-)
Thanks!
Reviewed-by: Heiko Schocher
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
Applied to u-boot-dm, thanks!
Re: [PATCH v1 07/24] pci: pci-uclass: Add support for Enhanced Allocation in Bridges
On Fri, 24 Jul 2020 at 04:09, Stefan Roese wrote: > > From: Suneel Garapati > > If Enhanced Allocation capability is present in bridges, use it > to read the fixed sub-ordinate bus number. > > Signed-off-by: Suneel Garapati > Reviewed-by: Simon Glass > Cc: Bin Meng > > Signed-off-by: Stefan Roese > --- > > Changes in v1: > - Change patch subject > > drivers/pci/pci-uclass.c | 25 +++-- > 1 file changed, 19 insertions(+), 6 deletions(-) Reviewed-by: Simon Glass Needs a sandbox test.
Re: [PATCH v3 11/17] board_f: ppc: Factor out ppc-specific bdinfo setup
Hi Ovidiu,
On Tue, 21 Jul 2020 at 10:43, Ovidiu Panait wrote:
>
> Hi Simon,
>
> On 21.07.2020 17:17, Simon Glass wrote:
> > On Mon, 20 Jul 2020 at 08:20, Ovidiu Panait
> > wrote:
> >> Factor out ppc-specific bdinfo setup from generic init sequence to
> >> arch_setup_bdinfo in arch/powerpc/lib/bdinfo.c.
> >>
> >> Signed-off-by: Ovidiu Panait
> >> ---
> >>
> >> arch/powerpc/lib/bdinfo.c | 25 +
> >> common/board_f.c | 36 ++--
> >> 2 files changed, 27 insertions(+), 34 deletions(-)
> > Reviewed-by: Simon Glass
> >
> > Could this be a way to remove the weak SDRAM function?
>
> I think the SDRAM weak function can be eliminated by overwriting the
> values set in common/board_f.c using the xtensa-specific
> arch_setup_bdinfo (arch/xtensa/lib/bdinfo.c), as you suggested.
>
>
> I plan to replace the weak SDRAM function patch with this one:
>
> iff --git a/arch/Kconfig b/arch/Kconfig
> index 9be02d1319..4d9557959c 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -10,7 +10,6 @@ choice
>
> config ARC
> bool "ARC architecture"
> -select ARCH_EARLY_INIT_R
> select ARC_TIMER
> select CLK
> select HAVE_PRIVATE_LIBGCC
> diff --git a/arch/arc/lib/cpu.c b/arch/arc/lib/cpu.c
> index 27b5832a0c..d66a8c867a 100644
> --- a/arch/arc/lib/cpu.c
> +++ b/arch/arc/lib/cpu.c
> @@ -25,13 +25,6 @@ int arch_cpu_init(void)
> return 0;
> }
>
> -int arch_early_init_r(void)
> -{
> -gd->bd->bi_memstart = CONFIG_SYS_SDRAM_BASE;
> -gd->bd->bi_memsize = CONFIG_SYS_SDRAM_SIZE;
> -return 0;
> -}
> -
> /* This is a dummy function on arc */
> int dram_init(void)
> {
> diff --git a/arch/xtensa/lib/bdinfo.c b/arch/xtensa/lib/bdinfo.c
> new file mode 100644
> index 00..b3ab7227aa
> --- /dev/null
> +++ b/arch/xtensa/lib/bdinfo.c
> @@ -0,0 +1,20 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * XTENSA-specific information for the 'bd' command
> + *
> + * (C) Copyright 2003
> + * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
> + */
> +
> +#include
> +#include
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +int arch_setup_bdinfo(void)
> +{
> +struct bd_info *bd = gd->bd;
> +
> +gd->bd->bi_memstart = PHYSADDR(CONFIG_SYS_SDRAM_BASE);
> +gd->bd->bi_memsize = CONFIG_SYS_SDRAM_SIZE;
> +}
> diff --git a/board/cadence/xtfpga/xtfpga.c b/board/cadence/xtfpga/xtfpga.c
> index 2869e5cf68..4b49b6e5c8 100644
> --- a/board/cadence/xtfpga/xtfpga.c
> +++ b/board/cadence/xtfpga/xtfpga.c
> @@ -51,9 +51,6 @@ int checkboard(void)
>
> int dram_init_banksize(void)
> {
> -gd->bd->bi_memstart = PHYSADDR(CONFIG_SYS_SDRAM_BASE);
> -gd->bd->bi_memsize = CONFIG_SYS_SDRAM_SIZE;
> -
> return 0;
> }
>
> diff --git a/common/board_f.c b/common/board_f.c
> index 4356431488..3b11f08725 100644
> --- a/common/board_f.c
> +++ b/common/board_f.c
> @@ -605,6 +605,11 @@ __weak int arch_setup_bdinfo(void)
>
> int setup_bdinfo(void)
> {
> +struct bd_info *bd = gd->bd;
> +
> +bd->bi_memstart = gd->ram_base; /* start of memory */
> +bd->bi_memsize = gd->ram_size; /* size in bytes */
> +
> return arch_setup_bdinfo();
> }
>
> @@ -614,12 +619,6 @@ static int setup_board_part1(void)
> {
> struct bd_info *bd = gd->bd;
>
> -/*
> - * Save local variables to board info struct
> - */
> -bd->bi_memstart = CONFIG_SYS_SDRAM_BASE;/* start of memory */
> -bd->bi_memsize = gd->ram_size;/* size in bytes */
> -
> #ifdef CONFIG_SYS_SRAM_BASE
> bd->bi_sramstart = CONFIG_SYS_SRAM_BASE;/* start of SRAM */
> bd->bi_sramsize = CONFIG_SYS_SRAM_SIZE;/* size of SRAM */
>
> Do you think this is a better approach?
Yes it looks better to me.
Regards,
Simon
Re: [PATCH v4 23/27] rockchip: Drop the fit_spl_optee.sh script
Now that all board use binman instead of this script, drop it. Signed-off-by: Simon Glass Reviewed-by: Bin Meng --- (no changes since v1) arch/arm/mach-rockchip/fit_spl_optee.sh | 84 - 1 file changed, 84 deletions(-) delete mode 100755 arch/arm/mach-rockchip/fit_spl_optee.sh Applied to u-boot-dm, thanks!
Re: [PATCH] gpio: Add support for gpio-line-names reading
On Tue, 21 Jul 2020 at 07:15, Michal Simek wrote:
>
> The commit 2bd261dd1712 ("gpio: search for gpio label if gpio is not found
> through bank name") introduced the option to search gpio via labels (gpio
> hog). This patch is just follow up on this and fills pin name based on
> gpio-line-names DT property.
>
> Signed-off-by: Michal Simek
> ---
>
> arch/sandbox/dts/test.dts | 2 ++
> drivers/gpio/gpio-uclass.c | 31 +++
> test/dm/gpio.c | 6 ++
> 3 files changed, 39 insertions(+)
Reviewed-by: Simon Glass
Re: [PATCH v3 1/8] dm: button: add an uclass for button
Add a new uclass for button that implements two functions: - button_get_by_label - button_get_status Reviewed-by: Simon Glass Signed-off-by: Philippe Reynes --- Changelog: v3: - no change v2: - re-order include - use uclass_id_foreach_dev - add comments to enum button_state_t drivers/Kconfig| 2 ++ drivers/Makefile | 1 + drivers/button/Kconfig | 12 + drivers/button/Makefile| 5 drivers/button/button-uclass.c | 43 ++ include/button.h | 59 ++ include/dm/uclass-id.h | 1 + 7 files changed, 123 insertions(+) create mode 100644 drivers/button/Kconfig create mode 100644 drivers/button/Makefile create mode 100644 drivers/button/button-uclass.c create mode 100644 include/button.h Applied to u-boot-dm, thanks!
Re: [PATCH v2 3/3] doc: verified-boot: add required-mode information
Hi Thirupathaiah, On Fri, 17 Jul 2020 at 21:20, Thirupathaiah Annapureddy wrote: > > Signed-off-by: Thirupathaiah Annapureddy > --- > > Changes in v2: > - New > > doc/uImage.FIT/signature.txt | 14 ++ > 1 file changed, 14 insertions(+) > Reviewed-by: Simon Glass But I think we need a new mkimage option to set the required-mode > diff --git a/doc/uImage.FIT/signature.txt b/doc/uImage.FIT/signature.txt > index d4afd755e9..a3455889ed 100644 > --- a/doc/uImage.FIT/signature.txt > +++ b/doc/uImage.FIT/signature.txt > @@ -386,6 +386,20 @@ that might be used by the target needs to be signed with > 'required' keys. > > This happens automatically as part of a bootm command when FITs are used. > > +For Signed Configurations, the default verification behavior can be changed > by > +the following optional property in /signature node in U-Boot's control FDT. > + > +- required-mode: Valid values are "any" to allow verified boot to succeed if > +the selected configuration is signed by any of the 'required' keys, and "all" > +to allow verified boot to succeed if the selected configuration is signed by > +all of the 'required' keys. > + > +This property can be added to a binary device tree using fdtput as shown in > +below examples:: > + > + fdtput -t s control.dtb /signature required-mode any > + fdtput -t s control.dtb /signature required-mode all > + > > Enabling FIT Verification > - > -- > 2.25.2 >
Re: [PATCH] sandbox: enable FIT cipher support in defconfig
On Thu, 16 Jul 2020 at 21:45, wrote: > > From: Patrick Oppenlander > > Linux distributions generally use the "make defconfig && make tools-all" > recipe to generate a uboot-tools (or similar) package. > > This patch enables FIT cipher support in the default mkimage build. > > Signed-off-by: Patrick Oppenlander > --- > configs/sandbox_defconfig | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Simon Glass
Re: [PATCH v2 2/3] test: vboot: add tests for multiple required keys
On Fri, 17 Jul 2020 at 21:20, Thirupathaiah Annapureddy wrote: > > This patch adds vboot tests to verify the support for multiple > required keys using new required-mode DTB policy. > > This patch also fixes existing test where dev > key is assumed to be marked as not required, although > it is marked as required. > > Note that this patch re-added sign_fit_norequire(). > sign_fit_norequire() was removed as part of the commit: > b008677daf2a9dc0335260c7c4e24390487fe0ca > (test: vboot: Fix pylint errors) > This patch leverages sign_fit_norequire() to fix the > existing bug. > > Signed-off-by: Thirupathaiah Annapureddy > --- > > Changes in v2: > - Added tests to cover any or all required keys policy. > > test/py/tests/test_vboot.py | 46 +++-- > 1 file changed, 44 insertions(+), 2 deletions(-) Reviewed-by: Simon Glass
Re: [PATCH v2 1/3] vboot: add DTB policy for supporting multiple required conf keys
Hi Thirupathaiah,
On Fri, 17 Jul 2020 at 21:20, Thirupathaiah Annapureddy
wrote:
>
> Currently FIT image must be signed by all required conf keys. This means
> Verified Boot fails if there is a signature verification failure
> using any required key in U-boot DTB.
>
> This patch introduces a new policy in DTB that can be set to any required
> conf key. This means if verified boot passes with one of the required
> keys, u-boot will continue the OS hand off.
U-Boot
>
> There were prior attempts to address this:
> https://lists.denx.de/pipermail/u-boot/2019-April/366047.html
> The above patch was failing "make tests".
> https://lists.denx.de/pipermail/u-boot/2020-January/396629.html
>
> Signed-off-by: Thirupathaiah Annapureddy
> ---
>
> Changes in v2:
> - Modify fit_config_verify_required_sigs() to process required-mode
> policy variable in U-boot DTB.
>
> common/image-fit-sig.c | 30 +++---
> 1 file changed, 27 insertions(+), 3 deletions(-)
Reviewed-by: Simon Glass
Please see below
>
> diff --git a/common/image-fit-sig.c b/common/image-fit-sig.c
> index cc1967109e..d9b1c93a9b 100644
> --- a/common/image-fit-sig.c
> +++ b/common/image-fit-sig.c
> @@ -416,6 +416,10 @@ int fit_config_verify_required_sigs(const void *fit, int
> conf_noffset,
> {
> int noffset;
> int sig_node;
> + int verified = 0;
> + int reqd_sigs = 0;
> + bool reqd_policy_all = true;
> + const char *reqd_mode;
>
> /* Work out what we need to verify */
> sig_node = fdt_subnode_offset(sig_blob, 0, FIT_SIG_NODENAME);
> @@ -425,6 +429,14 @@ int fit_config_verify_required_sigs(const void *fit, int
> conf_noffset,
> return 0;
> }
>
> + /* Get required-mode policy property from DTB */
> + reqd_mode = fdt_getprop(sig_blob, sig_node, "required-mode", NULL);
> + if (reqd_mode && !strcmp(reqd_mode, "any"))
> + reqd_policy_all = false;
> +
> + debug("%s: required-mode policy set to '%s'\n", __func__,
> + reqd_policy_all ? "all" : "any");
> +
> fdt_for_each_subnode(noffset, sig_blob, sig_node) {
> const char *required;
> int ret;
> @@ -433,15 +445,27 @@ int fit_config_verify_required_sigs(const void *fit,
> int conf_noffset,
>NULL);
> if (!required || strcmp(required, "conf"))
> continue;
> +
> + reqd_sigs++;
> +
> ret = fit_config_verify_sig(fit, conf_noffset, sig_blob,
> noffset);
> if (ret) {
> - printf("Failed to verify required signature '%s'\n",
> - fit_get_name(sig_blob, noffset, NULL));
> - return ret;
> + if (reqd_policy_all) {
> + printf("Failed to verify required signature
> '%s'\n",
> + fit_get_name(sig_blob, noffset, NULL));
I think we should keep this message outside the if(). Otherwise there
is no indication what is going on.
> + return ret;
> + }
> + } else {
> + verified++;
> + if (!reqd_policy_all)
> + break;
> }
> }
>
> + if (reqd_sigs && !verified)
I think we need a message here, indicating that no signature was verified.
> + return -EPERM;
> +
> return 0;
> }
>
> --
> 2.25.2
>
Re: [PATCH v4 0/5] add DM based reset driver for SiFive SoC's
Hi Sagar,
On Tue, 28 Jul 2020 at 09:19, Sagar Kadam wrote:
>
> Hello Rick,
>
> > -Original Message-
> > From: Sagar Kadam
> > Sent: Monday, July 27, 2020 8:56 PM
> > To: u-boot@lists.denx.de
> > Cc: r...@andestech.com; Paul Walmsley ( Sifive)
> > ; pal...@dabbelt.com; anup.pa...@wdc.com;
> > atish.pa...@wdc.com; lu...@denx.de; Pragnesh Patel
> > ; bin.m...@windriver.com;
> > ja...@amarulasolutions.com; s...@chromium.org; twoer...@gmail.com;
> > patr...@blueri.se; mbrug...@suse.com; eugeniy.palt...@synopsys.com;
> > weijie@mediatek.com; nsaenzjulie...@suse.de; feste...@gmail.com;
> > sean...@gmail.com
> > Subject: RE: [PATCH v4 0/5] add DM based reset driver for SiFive SoC's
> >
> > Hi Rick,
> > > -Original Message-
> > > From: Sagar Kadam
> > > Sent: Friday, July 24, 2020 2:17 PM
> > > To: u-boot@lists.denx.de
> > > Cc: r...@andestech.com; Paul Walmsley ( Sifive)
> > > ; pal...@dabbelt.com;
> > anup.pa...@wdc.com;
> > > atish.pa...@wdc.com; lu...@denx.de; Pragnesh Patel
> > > ; bin.m...@windriver.com;
> > > ja...@amarulasolutions.com; s...@chromium.org; twoer...@gmail.com;
> > > patr...@blueri.se; mbrug...@suse.com; eugeniy.palt...@synopsys.com;
> > > weijie@mediatek.com; nsaenzjulie...@suse.de;
> > feste...@gmail.com;
> > > sean...@gmail.com; Sagar Kadam
> > > Subject: [PATCH v4 0/5] add DM based reset driver for SiFive SoC's
> > >
> > > The FU540-C000 support in U-Boot is missing DM based reset driver, and is
> > > handling reset's to sub-system within the prci driver itself.
> > > The series here adds a generic DM reset driver for SiFive SoC's so as to
> > > leverage the U-Boot's reset framework and binds the reset driver with prci
> > > driver.
> > > The PRCI driver takes care of triggering the consumers reset signals
> > > appropriately.
> > >
> > > Patch 1: Add necessary dt indexes for device reset register.
> > > Patch 2: Update macro's to use common dt indexes from binding header.
> > > Patch 3: Add reset producer and consumer entries within the device tree.
> > > Patch 4: Add reset dm driver and bind it within prci module.
> > > Patch 5: Add Kconfig, Makefile entries and enable the driver
> > >
> > > This series is re-based on mainline U-Boot commit 5d3a21df6694 ("Merge
> > tag
> > > 'dm-pull-20jul20' of git://git.denx.de/u-boot-dm") and depends on [1]
> > >
> > > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=190862
> > >
> >
> > I have rebased this series on u-boot/master.
> > Can you please pull it and let me know if any issues are there.
> >
> It seems that u-boot/master is moved ahead and the commit on which this series
> was based is reverted "Revert "Merge tag 'dm-pull-20jul20' of
> git://git.denx.de/u-boot-dm""
> and will again conflict considering other patch's that are merged in
> u-boot/master.
> I can rebase it again, but would like to know what you would prefer me to
> rebase on u-boot/master
> or u-boot-riscv/master?
Can you take another look? The DM stuff landed again yesterday.
Regards,
Simon
Re: [PATCH v3 3/8] cmd: button: add a new 'button' command
Adds a command 'button' that provides the list of buttons supported by the board, and the state of a button. Reviewed-by: Simon Glass Signed-off-by: Philippe Reynes --- Changelog: v3: - no change v2 - no change cmd/Kconfig | 11 cmd/Makefile | 1 + cmd/button.c | 86 3 files changed, 98 insertions(+) create mode 100644 cmd/button.c Applied to u-boot-dm, thanks!
Re: [PATCH v4 05/27] rockchip: bob: Support SPI-flash booting
Update the config for chromebook_bob to support booting from SPI flash. The existing SPL size is too small since ATF is needed, so double it. Signed-off-by: Simon Glass --- (no changes since v1) configs/chromebook_bob_defconfig | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) Applied to u-boot-dm, thanks!
Re: [PATCH v3 4/8] sandbox: dtsi: add buttons
Adds two buttons on sandbox so button framework may be tested. Reviewed-by: Simon Glass Signed-off-by: Philippe Reynes --- Changelog: v3: - update comptatible to "gpio-keys" v2: - no change arch/sandbox/dts/sandbox.dtsi | 14 ++ 1 file changed, 14 insertions(+) Applied to u-boot-dm, thanks!
Re: [PATCH] sandbox: enable FIT cipher support in defconfig
On Thu, 16 Jul 2020 at 21:45, wrote: > > From: Patrick Oppenlander > > Linux distributions generally use the "make defconfig && make tools-all" > recipe to generate a uboot-tools (or similar) package. > > This patch enables FIT cipher support in the default mkimage build. > > Signed-off-by: Patrick Oppenlander > --- > configs/sandbox_defconfig | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Simon Glass Applied to u-boot-dm, thanks!
Re: [PATCH] buildman: Allow using older versions of genboardscfg.py
Older versions of this script don't support the -q flag. Since buildman runs this script from when it starts, we may get the old version. Fix this in two ways: 1. Use the version from the same tree as buildman is run from, if available 2. Failing that, allow the -q flag to be missing Signed-off-by: Simon Glass --- tools/buildman/control.py | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) Applied to u-boot-dm, thanks!
Re: [PATCH v4 1/1] cmd: gpt: add eMMC and GPT support
Hi Rayagonda, On Thu, 23 Jul 2020 at 06:01, Rayagonda Kokatanur wrote: > > From: Corneliu Doban > > Add eMMC and GPT support. > - GPT partition list and command to create the GPT added to u-boot > environment > - eMMC boot commands added to u-boot environment > - new gpt commands (enumarate and setenv) that are used by broadcom > update scripts and boot commands > - eMMC specific u-boot configurations with environment saved in eMMC > and GPT support > > Signed-off-by: Corneliu Doban > Signed-off-by: Rayagonda Kokatanur > --- > Changes from v3: > -Address review comments from Simon Glass, > Return -ve number instead of 1 upon failure, > Use shorter variable name, > Modified code to avoid buffer overflow, > Use if (!strcmp(...)) instead of if (strcmp(...) == 0) > > Changes from v2: > -Address review comments from Simon Glass, > Check for return value of part_driver_get_count(), > Don't check return value of part_driver_get(), > Rewrite part_driver_get() and rename to part_driver_get_first(), > Use env_set_ulong() whereever applicable, > > -Address review comments from Michael Nazzareno Trimarchi, > Add new function to set all env vriables, > > Changes from v1: > -Address review comments from Simon Glass, > Correct function comments, > Check for return value, > Add helper function in part.h > > cmd/gpt.c | 161 + > include/part.h | 29 + > 2 files changed, 190 insertions(+) Yes this looks OK to me. What sort of trouble are you having with the test? Regards, SImon
Re: [PATCH] buildman: Correct the testOutputDir() unit test
This current fails with an error. Fix it.
Signed-off-by: Simon Glass
Fixes: 7664b03ffc5 ("buildman: Remove _of_#_ from results directory paths")
---
tools/buildman/test.py | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Applied to u-boot-dm, thanks!
Re: [PATCH v4 08/27] tegra: Drop the unused non-binman code
This has been in the Makefile long enough to ensure migration is complete. Drop it. Signed-off-by: Simon Glass --- (no changes since v1) Makefile | 16 +--- 1 file changed, 1 insertion(+), 15 deletions(-) Applied to u-boot-dm, thanks!
Re: [PATCH] cmd: host: return value of do_host_bind()
On Fri, 24 Jul 2020 at 00:30, Heinrich Schuchardt wrote: > > When trying to bind to a non-existent file the following output is > displayed: > > => host bind 0 non_existent > Failed to access host backing file 'non_existent' > exit not allowed from main input shell. > > The last line is quite unexpected and due to an incorrect return value. > > If do_host_bind() fails, return CMD_RET_FAILURE (= 1). > > Signed-off-by: Heinrich Schuchardt > --- > cmd/host.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass
Re: [PATCH] pinctrl: aspeed: Fix Kconfig entry indentation
On Thu, 23 Jul 2020 at 01:00, Michal Simek wrote:
>
> Fix Kconfig entry indentation for Aspeed ast2500 pin control driver.
>
> Fixes: 4f0e44e46615 ("aspeed: AST2500 Pinctrl Driver")
> Signed-off-by: Michal Simek
> ---
>
> drivers/pinctrl/Kconfig | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
Reviewed-by: Simon Glass
Re: [PATCH v4 03/27] Makefile: Allow building .rom files for non-x86 boards
Some non-x86 devices can use SPI flash to boot and need to produce images of a fixed size to program the flash. Add a way to handle this for non-x86 boards. Signed-off-by: Simon Glass --- (no changes since v3) Changes in v3: - Add a comment about CONFIG_SPL_FRAMEWORK Makefile | 14 ++ 1 file changed, 14 insertions(+) Applied to u-boot-dm, thanks!
Re: [PATCH v2] dm: Fix build error when OF_CONTROL is not set
On Thu, 23 Jul 2020 at 06:01, Dan Murphy wrote:
>
> With OF_CONTROL disabled the build fails for
> include/dm/read.h:932:10: error: ‘ENOTSUPP’ undeclared (first use in this
> function)
> 932 | return -ENOTSUPP;
>
> Fixes: 45224e8f2691 ("dm: core: gracefully handle alias seq without of")
> Signed-off-by: Dan Murphy
> ---
> include/dm/read.h | 2 ++
> 1 file changed, 2 insertions(+)
>
Reviewed-by: Simon Glass
Re: [PATCH v3] i2c: eeprom: Use reg property instead of offset and size
On Wed, 22 Jul 2020 at 04:14, Michal Simek wrote: > > Remove adhoc dt binding for fixed-partition definition for i2c eeprom. > fixed-partition are using reg property instead of offset/size pair. > > Signed-off-by: Michal Simek > --- > > Changes in v3: > - Add test for sandbox > - Fix issues related to OF_TRANSLATE > - Remove address/size cells from parent because of OF_TRANSLATE > > Changes in v2: > - Bootcount tested on zynqmp zcu104 > - Add missing address/size cells > - Use dev_read_addr_size_index > - Check parameters > > Just build tested - ge_bx50v3_defconfig > Tested on zcu104 > > --- > arch/arm/dts/imx53-ppd-uboot.dtsi| 12 ++-- > arch/arm/dts/imx6q-bx50v3-uboot.dtsi | 10 +- > arch/sandbox/dts/test.dts| 13 + > configs/sandbox_defconfig| 1 + > drivers/misc/i2c_eeprom.c| 15 --- > test/dm/bootcount.c | 8 > 6 files changed, 41 insertions(+), 18 deletions(-) > Reviewed-by: Simon Glass
Re: [PATCH v2] gpio: octeon_gpio: Add GPIO controller driver for Octeon
Hi Daniel, On Wed, 22 Jul 2020 at 05:47, Daniel Schwierzeck wrote: > > > Hi Daniel, > > > > On 21.07.20 16:59, Daniel Schwierzeck wrote: > > > > Hi Daniel, > > > > > > > > On 18.07.20 15:25, Daniel Schwierzeck wrote: > > > > > > From: Suneel Garapati > > > ... > > > > > found another issue: > > > > > > > > > > drivers/gpio/octeon_gpio.c: In function 'octeon_gpio_probe': > > > > > drivers/gpio/octeon_gpio.c:189:16: warning: implicit declaration of > > > > > function 'dm_pci_map_bar'; did you mean 'pci_map_bar'? [-Wimplicit- > > > > > function-declaration] > > > > > 189 | priv->base = dm_pci_map_bar(dev, PCI_BASE_ADDRESS_0, > > > > > |^~ > > > > > |pci_map_bar > > > > > drivers/gpio/octeon_gpio.c:189:14: warning: assignment to 'void *' > > > > > from > > > > > 'int' makes pointer from integer without a cast [-Wint-conversion] > > > > > 189 | priv->base = dm_pci_map_bar(dev, PCI_BASE_ADDRESS_0, > > > > > | ^ > > > > > > > > Ah, I did not see this in my local builds, as I have enabled DM_PCI > > > > here and forgot to add this dependency. > > > > > > > > > due to the dependency on DM_PCI you need to express this in Kconfig > > > > > with "depends on DM_PCI ...". Alternatively you need to wrap the PCI > > > > > specific code with a "#ifdef CONFIG_DM_PCI" as the DM_PCI specific > > > > > function prototypes in pci.h are also wrapped with "#ifdef > > > > > CONFIG_DM_PCI". The former option will build and link DM PCI code > > > > > which > > > > > is not used and therefore bloats the U-Boot binary. > > > > > > > > > > I guess the choice mainly depends on whether you'll add a PCI host > > > > > controller driver for Octeon MIPS64 in the future and can live with > > > > > the > > > > > extra but unused PCI code until then. > > > > > > > > We can definitely live with the temporarily unused PCI code. I don't > > > > want to add these #ifdefs again, which I removed explicitly upon Simon's > > > > request. > > > > > > > > To solve this, I would prefer to add a "select DM_PCI & PCI" to > > > > arch/mips/Kconfig for Octeon, as this PCI probing construct is not > > > > only used in this GPIO driver, but also in many other drivers shared > > > > between MIPS Octeon and the also upcoming ARM64 Octeon TX/TX2 support, > > > > like I2C, SPI etc. Here all devices are PCI based hence the PCI probing > > > > dependency. > > > > > > > > Is this okay with you? Or should I stay with the dependency in the > > > > drivers Kconfig file? > > > > > > > > > > I would also prefer a "select DM_PCI". I just struggle a bit with the > > > "& PCI" part. IMHO DM_PCI should not depend on PCI because DM_PCI > > > should be a hidden option which is selected by the SoC dependent on the > > > SoC specific drivers and whether them support DM. It doesn't make sense > > > to let the user choose all those DM_* options. Most other DM_* options > > > already work like this except that them are not hidden. > > > > > > BTW: When you prepare a patch, you can also "select DM_I2C" and > > > "DM_SPI" which have the same issues with the PCI dependency. > > > > Sure. But selecting only "DM_PCI" and not "PCI" leads to these issues: > > > > WARNING: unmet direct dependencies detected for DM_PCI > >Depends on [n]: PCI [=n] && DM [=y] > >Selected by [y]: > >- ARCH_OCTEON [=y] && > > > > It doesn't make sense to have DM_PCI enabled and PCI not. Same happens > > with DM_SPI BTW. > > exactly that is my problem. The dependency doesn't make sense and > should be removed IMHO. Options like DM_PCI should be interpreted as > "this platform with its drivers support PCI witrh DM". It doesn't nake > sense to let an user choose this option. I just wanted to point out > this inconsistency. Maybe Simon has an opinion about that. Yes that's right. We have it as an option since supporting DM_PCI can be board-by-board at present. Once migration is finished, we can drop DM_PCI. [..] Regards, Simon
Re: [PATCH] Makefile.lib: Build all DTS with -@ if OF_LIBFDT_OVERLAY is enabled
On Wed, 22 Jul 2020 at 06:58, Michal Simek wrote:
>
> The commit 47818e23a228 ("Makefile.lib: include /__symbols__ in dtb if
> SPL_LOAD_FIT_APPLY_OVERLAY is enabled") enables DT building as overlays
> based on symbols which depends on SPL. But there is already an option to
> apply overlays in full U-Boot too.
> And there are platforms which are not using SPL and there is no option to
> build DTs with -@ parameter.
> That's why change dependency on OF_LIBFDT_OVERLAY which is already symbol
> which is selected when SPL_LOAD_FIT_APPLY_OVERLAY is enabled but also
> adding support for platforms which don't enable SPL and want to work with
> overlays on U-Boot prompt.
>
> Signed-off-by: Michal Simek
> ---
>
> scripts/Makefile.lib | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Simon Glass
Re: [PATCH v4 09/27] tegra: Don't enable binman on ARMv8 SoCs
At present only the ARMv7 tegra SoCs actually use binman to create an image. Change the config to reflect this, since otherwise running binman will produce an error. Signed-off-by: Simon Glass --- (no changes since v1) arch/arm/mach-tegra/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Applied to u-boot-dm, thanks!
Re: rk3399-gru-kevin: issues on bringup
Hi Marty,
On Tue, 21 Jul 2020 at 21:07, Marty E. Plummer wrote:
>
> On Tue, Jul 21, 2020 at 10:21:52AM -0600, Simon Glass wrote:
> > Hi Marty,
> >
> > Did you check spl_boot_device()?
> >
> After sending the initial email I noticed your binman work, which does
> some of the stuff I think I need. My current setup is as follows:
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index cee10f533f..0e3e1cc553 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -122,6 +122,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3399) += \
> rk3399-ficus.dtb \
> rk3399-firefly.dtb \
> rk3399-gru-bob.dtb \
> + rk3399-gru-kevin.dtb \
> rk3399-khadas-edge.dtb \
> rk3399-khadas-edge-captain.dtb \
> rk3399-khadas-edge-v.dtb \
> diff --git a/arch/arm/dts/rk3399-gru-kevin-u-boot.dtsi
> b/arch/arm/dts/rk3399-gru-kevin-u-boot.dtsi
> new file mode 100644
> index 00..726f396f32
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-gru-kevin-u-boot.dtsi
> @@ -0,0 +1,7 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019 Jagan Teki
> + */
> +
> +#include "rk3399-gru-u-boot.dtsi"
> +#include "rk3399-sdram-lpddr3-samsung-4GB-1866.dtsi"
> diff --git a/arch/arm/mach-rockchip/rk3399/Kconfig
> b/arch/arm/mach-rockchip/rk3399/Kconfig
> index 17628f9171..851083cd8a 100644
> --- a/arch/arm/mach-rockchip/rk3399/Kconfig
> +++ b/arch/arm/mach-rockchip/rk3399/Kconfig
> @@ -14,6 +14,11 @@ config TARGET_CHROMEBOOK_BOB
> display. It includes a Chrome OS EC (Cortex-M3) to provide access to
> the keyboard and battery functions.
>
> +config TARGET_CHROMEBOOK_KEVIN
> + bool "Samsung Chromebook Plus (RK3399)"
> + select HAS_ROM
> + select ROCKCHIP_SPI_IMAGE
> +
> config TARGET_EVB_RK3399
> bool "RK3399 evaluation board"
> help
> diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c
> b/arch/arm/mach-rockchip/rk3399/rk3399.c
> index 4fda93b152..92b418a9cf 100644
> --- a/arch/arm/mach-rockchip/rk3399/rk3399.c
> +++ b/arch/arm/mach-rockchip/rk3399/rk3399.c
> @@ -117,7 +117,7 @@ void board_debug_uart_init(void)
> #define GPIO0_BASE 0xff72
> #define PMUGRF_BASE0xff32
> struct rk3399_grf_regs * const grf = (void *)GRF_BASE;
> -#ifdef CONFIG_TARGET_CHROMEBOOK_BOB
> +#if defined(CONFIG_TARGET_CHROMEBOOK_BOB) ||
> defined(CONFIG_TARGET_CHROMEBOOK_KEVIN)
> struct rk3399_pmugrf_regs * const pmugrf = (void *)PMUGRF_BASE;
> struct rockchip_gpio_regs * const gpio = (void *)GPIO0_BASE;
> #endif
> @@ -139,7 +139,7 @@ void board_debug_uart_init(void)
> GRF_GPIO3B7_SEL_MASK,
> GRF_UART3_SOUT << GRF_GPIO3B7_SEL_SHIFT);
> #else
> -# ifdef CONFIG_TARGET_CHROMEBOOK_BOB
> +# if defined(CONFIG_TARGET_CHROMEBOOK_BOB) ||
> defined(CONFIG_TARGET_CHROMEBOOK_KEVIN)
> rk_setreg(>io_vsel, 1 << 0);
>
> /*
> diff --git a/arch/arm/mach-rockchip/spl.c b/arch/arm/mach-rockchip/spl.c
> index f148d48b6a..a7a2bf10a1 100644
> --- a/arch/arm/mach-rockchip/spl.c
> +++ b/arch/arm/mach-rockchip/spl.c
> @@ -55,7 +55,8 @@ u32 spl_boot_device(void)
> defined(CONFIG_TARGET_CHROMEBIT_MICKEY) || \
> defined(CONFIG_TARGET_CHROMEBOOK_MINNIE) || \
> defined(CONFIG_TARGET_CHROMEBOOK_SPEEDY) || \
> - defined(CONFIG_TARGET_CHROMEBOOK_BOB)
> + defined(CONFIG_TARGET_CHROMEBOOK_BOB) || \
> + defined(CONFIG_TARGET_CHROMEBOOK_KEVIN)
> return BOOT_DEVICE_SPI;
> #endif
> if (CONFIG_IS_ENABLED(ROCKCHIP_BACK_TO_BROM))
> diff --git a/board/google/gru/Kconfig b/board/google/gru/Kconfig
> index 61f7bbca98..1455e1481d 100644
> --- a/board/google/gru/Kconfig
> +++ b/board/google/gru/Kconfig
> @@ -13,3 +13,19 @@ config BOARD_SPECIFIC_OPTIONS # dummy
> def_bool y
>
> endif
> +
> +if TARGET_CHROMEBOOK_KEVIN
> +
> +config SYS_BOARD
> + default "gru"
> +
> +config SYS_VENDOR
> + default "google"
> +
> +config SYS_CONFIG_NAME
> + default "gru"
> +
> +config BOARD_SPECIFIC_OPTIONS # dummy
> + def_bool y
> +
> +endif
> diff --git a/board/google/gru/gru.c b/board/google/gru/gru.c
> index 7dfbc3ac86..99ac658e32 100644
> --- a/board/google/gru/gru.c
> +++ b/board/google/gru/gru.c
> @@ -14,7 +14,7 @@ void gru_dummy_function(int i)
>
> int board_early_init_f(void)
> {
> -# ifdef CONFIG_TARGET_CHROMEBOOK_BOB
> +# if defined(CONFIG_TARGET_CHROMEBOOK_BOB) ||
> defined(CONFIG_TARGET_CHROMEBOOK_KEVIN)
> int sum, i;
>
> /*
> diff --git a/configs/chromebook_kevin_defconfig
> b/configs/chromebook_kevin_defconfig
> new file mode 100644
> index 00..ea975264b5
> --- /dev/null
> +++ b/configs/chromebook_kevin_defconfig
> @@ -0,0 +1,82 @@
> +CONFIG_ARM=y
> +CONFIG_ARCH_ROCKCHIP=y
> +CONFIG_SYS_TEXT_BASE=0x0020
> +CONFIG_SPL_GPIO_SUPPORT=y
> +CONFIG_ENV_OFFSET=0x3F8000
> +CONFIG_SYS_SPI_U_BOOT_OFFS=0x4
>
Re: [PATCH v4 20/27] Makefile: Warn against using CONFIG_SPL_FIT_GENERATOR
This option is used to run arch-specific shell scripts which produce .its files which are used to produce FIT images. We already have binman which is designed to produce firmware images. It is more powerful and has tests. So this option should be deprecated and not used. Existing uses should be migrated. Mentions of this in code reviews over the last year or so do not seem to have resulted in action, and things are getting worse. So let's add a warning. Signed-off-by: Simon Glass Reviewed-by: Bin Meng --- (no changes since v1) Makefile | 9 + 1 file changed, 9 insertions(+) Applied to u-boot-dm, thanks!
Re: [PATCH v2 02/18] Kconfig: Introduce CONFIG_XEN
Hi Anastasiia, On Mon, 20 Jul 2020 at 05:02, Anastasiia Lukianenko wrote: > > From: Peng Fan > > Introduce CONFIG_XEN to make U-Boot could be used as bootloader > for a virtual machine. > > Without bootloader, we could successfully boot up android on XEN, but > we need need bootloader to support A/B, dm verify and etc. > > Signed-off-by: Peng Fan > Signed-off-by: Oleksandr Andrushchenko > Signed-off-by: Anastasiia Lukianenko > --- > Kconfig | 18 ++ > 1 file changed, 18 insertions(+) > This is v2 but I don't see a change log? Regards, Simon
Re: [PATCH v4 07/27] rockchip: Enable building a SPI ROM image on bob
Add a simple binman config and enable CONFIG_HAS_ROM so that U-Boot produces a ROM for bob. Signed-off-by: Simon Glass --- Changes in v4: - Use CONFIG_ROCKCHIP_SPI_IMAGE to select the image arch/arm/dts/rk3399-gru-u-boot.dtsi | 4 arch/arm/dts/rk3399-gru.dtsi | 2 +- arch/arm/dts/rk3399-u-boot.dtsi | 27 +++ arch/arm/mach-rockchip/rk3399/Kconfig | 2 ++ 4 files changed, 34 insertions(+), 1 deletion(-) Applied to u-boot-dm, thanks!
Re: [PATCH v4 1/2] arm: move CONFIG_PREBOOT="usb start" to KConfig
On Sun, 19 Jul 2020 at 07:56, Jonas Smedegaard wrote:
>
> This commit moves CONFIG_PREBOOT="usb start" to common/KConfig
> for all boards also declaring USB_KEYBOARD.
>
> Besides simplifying defconfig files, this also enables support for
> board-specific CONFIG_PREBOOT for sunxi boards:
> commit 37304aaf60bf ("Convert CONFIG_USE_PREBOOT and CONFIG_PREBOOT to
> Kconfig") intended to support CONFIG_PREBOOT, but
> include/configs/sunxi-common.h hardcodes preboot as part of internally
> defined CONSOLE_STDIN_SETTINGS, silently ignoring any board-specific
> CONFIG_PREBOOT.
>
> Signed-off-by: Jonas Smedegaard
> Series-Cc: Jagan Teki
> Series-Cc: Lukasz Majewski
> Series-Cc: Andre Przywara
>
> ---
>
> (no changes since v1)
>
>
> Changes in v4:
> - generalize to cover all boards, thanks to Jagan Teki
>
> Changes in v3:
> - move default setting to KConfig, thanks to Andre Przywara and Lukasz
> Majewski
>
> Changes in v2:
> - Rephrase commit message to clarify relationship with KConfig entries
>
> ---
> common/Kconfig| 1 +
> configs/libretech-ac_defconfig| 1 -
> configs/libretech-s905d-pc_defconfig | 1 -
> configs/libretech-s912-pc_defconfig | 1 -
> configs/pinebook-pro-rk3399_defconfig | 1 -
> configs/rockpro64-rk3399_defconfig| 1 -
> configs/rpi_0_w_defconfig | 1 -
> configs/rpi_2_defconfig | 1 -
> configs/rpi_3_32b_defconfig | 1 -
> configs/rpi_3_b_plus_defconfig| 1 -
> configs/rpi_3_defconfig | 1 -
> configs/rpi_defconfig | 1 -
> configs/seaboard_defconfig| 1 -
> configs/ventana_defconfig | 1 -
> include/configs/sunxi-common.h| 1 -
> 15 files changed, 1 insertion(+), 14 deletions(-)
Reviewed-by: Simon Glass
Re: [PATCH v4 02/27] rockchip: Allow Bob to use SPI boot
Bob is a Chromebook and can boot from SPI flash. Add it to the condition check for this. Signed-off-by: Simon Glass --- (no changes since v1) arch/arm/mach-rockchip/spl.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) Applied to u-boot-dm, thanks!
Re: [PATCH v4 22/27] rockchip: Convert evb-rk3229 over to use binman
At present this board uses a custom script to produce the .its file. Update it to use binman instead. Binman can create all the images that are needed. Signed-off-by: Simon Glass --- (no changes since v3) Changes in v3: - Drop leftover debugging configs/evb-rk3229_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Applied to u-boot-dm, thanks!
Re: [PATCH 1/1] dm: remove superfluous comment for union ofnode_union
On Fri, 24 Jul 2020 at 10:39, Heinrich Schuchardt wrote: > > "future live tree" does not make sense anymore as we have CONFIG_OF_LIVE. > > Signed-off-by: Heinrich Schuchardt > --- > include/dm/ofnode.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Reviewed-by: Simon Glass
Re: [PATCH v4 04/27] rockchip: jerry: Add serial support
This option allows the serial console to work correctly. Add it. Signed-off-by: Simon Glass --- (no changes since v1) configs/chromebook_jerry_defconfig | 1 + 1 file changed, 1 insertion(+) Applied to u-boot-dm, thanks!
Re: [PATCH v3 8/8] test: dm: add a test for class button
On Fri, 24 Jul 2020 at 10:20, Philippe Reynes wrote: > > Add a test to confirm that we can read button state > using the button-gpio driver. > > Signed-off-by: Philippe Reynes > --- > Changelog: > v3: > - no change > v2: > - new commit in the serie > > test/dm/Makefile | 1 + > test/dm/button.c | 74 > > 2 files changed, 75 insertions(+) > create mode 100644 test/dm/button.c > Reviewed-by: Simon Glass
Re: [PATCH v4 10/27] Makefile: Rename ALL-y to INPUTS-y
When binman is in use, most of the targets built by the Makefile are inputs to binman. We then need a final rule to run binman to produce the final outputs. Rename the variable to indicate this, and add a new 'inputs' target. Signed-off-by: Simon Glass Reviewed-by: Bin Meng --- Changes in v4: - Update for changes to arch/arm/mach-k3/config.mk Makefile | 60 +--- arch/arm/config.mk | 10 +++--- arch/arm/mach-at91/config.mk | 2 +- arch/arm/mach-davinci/config.mk | 2 +- arch/arm/mach-k3/config.mk | 10 +++--- arch/arm/mach-keystone/config.mk | 4 +-- arch/arm/mach-omap2/config.mk| 28 +++ arch/arm/mach-rmobile/Makefile | 2 +- arch/arm/mach-stm32mp/config.mk | 4 +-- board/BuR/brppt1/config.mk | 4 +-- board/BuR/brppt2/config.mk | 4 +-- board/BuR/brsmarc1/config.mk | 6 ++-- board/imgtec/boston/config.mk| 2 +- board/intel/edison/config.mk | 2 +- scripts/Makefile.spl | 24 ++--- tools/binman/README | 2 +- 16 files changed, 85 insertions(+), 81 deletions(-) Applied to u-boot-dm, thanks!
Re: [PATCH v4 16/27] mediatek: Makefile: Drop explicit targets built by binman
On mediatek various files that need to be created by binman. It does not make sense to enumerate these in the Makefile. They are described in the configuration (devicetree) for each board and we can simply run binman (always) to generate them. This avoid sprinkling the Makefile with arch-specific code. Also update the binman definition so that idbloader.img is only needed when SPL is actually being used. Reviewed-by: Bin Meng Signed-off-by: Simon Glass --- (no changes since v3) Changes in v3: - Move in the rockchip changes mistakenly in the earlier x86 patch Makefile | 24 arch/arm/dts/rockchip-u-boot.dtsi | 2 ++ 2 files changed, 18 insertions(+), 8 deletions(-) Applied to u-boot-dm, thanks!
Re: [PATCH v4 06/27] rockchip: Enable building a SPI ROM image on jerry
Add a simple binman config and enable CONFIG_HAS_ROM so that U-Boot produces a ROM for jerry. Change the binman image definition to support multiple images, since it may be used to build both u-boot-rockchip.bin and u-boot.rom Signed-off-by: Simon Glass --- Changes in v4: - Add a new CONFIG_ROCKCHIP_SPI_IMAGE to control SPI-image generation arch/arm/dts/rk3288-u-boot.dtsi | 24 arch/arm/dts/rockchip-u-boot.dtsi | 8 +++- arch/arm/mach-rockchip/Kconfig| 9 + arch/arm/mach-rockchip/rk3288/Kconfig | 2 ++ 4 files changed, 42 insertions(+), 1 deletion(-) Applied to u-boot-dm, thanks!
Re: [PATCH v4 21/27] rockchip: Convert evb-rk3288 over to use binman
At present this board uses a custom script to produce the .its file. Update it to use binman instead. Binman can create all the images that are needed. Signed-off-by: Simon Glass --- Changes in v4: - Move the .itb output to a separate rockchip-optee.dtsi file - Add a check for CONFIG_FIT before building the .its Changes in v3: - Drop use of rk322x.dtsi - Add changes to rk3288-u-boot.dtsi instead Kconfig | 2 +- arch/arm/dts/rk3288-u-boot.dtsi | 1 + arch/arm/dts/rockchip-optee.dtsi | 64 +++ arch/arm/mach-rockchip/rk3288/Kconfig | 1 + configs/evb-rk3288_defconfig | 2 +- 5 files changed, 68 insertions(+), 2 deletions(-) create mode 100644 arch/arm/dts/rockchip-optee.dtsi Applied to u-boot-dm, thanks!
