December 2019 - U-Boot

[PATCH] arm64: zynqmp: Do not assing MIO34 that early on zcu100
by Michal Simek 03 Dec '19

03 Dec '19

MIO34 is connected to POWER_KILL signal. When MIO configuration is done in psu_init() and this pin is assigned to PMU but PMU configuration is not loaded yet. PMU gpio output is high that means board is powered off immediately. The patch is fixing this sequence that MIO34 stays assing to ps gpio IP. PMU config is loaded in SPL and then pin assigned to PMU through psu_post_config_data(). Signed-off-by: Michal Simek <michal.simek(a)xilinx.com> --- arch/arm/mach-zynqmp/psu_spl_init.c | 9 +++++++++ arch/arm/mach-zynqmp/spl.c | 1 + board/xilinx/zynqmp/zynqmp-zcu100-revC/psu_init_gpl.c | 7 ++++++- 3 files changed, 16 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-zynqmp/psu_spl_init.c b/arch/arm/mach-zynqmp/psu_spl_init.c index b357de32358c..b6abdfd608ee 100644 --- a/arch/arm/mach-zynqmp/psu_spl_init.c +++ b/arch/arm/mach-zynqmp/psu_spl_init.c @@ -77,3 +77,12 @@ __weak int psu_init(void) */ return -1; } + +__weak unsigned long psu_post_config_data(void) +{ + /* + * This function is overridden by the one in + * board/xilinx/zynqmp/(platform)/psu_init_gpl.c, if it exists. + */ + return 0; +} diff --git a/arch/arm/mach-zynqmp/spl.c b/arch/arm/mach-zynqmp/spl.c index 6ba42bb42f62..6551b33f42d0 100644 --- a/arch/arm/mach-zynqmp/spl.c +++ b/arch/arm/mach-zynqmp/spl.c @@ -60,6 +60,7 @@ void spl_board_init(void) preloader_console_init(); ps_mode_reset(MODE_RESET); board_init(); + psu_post_config_data(); } #endif diff --git a/board/xilinx/zynqmp/zynqmp-zcu100-revC/psu_init_gpl.c b/board/xilinx/zynqmp/zynqmp-zcu100-revC/psu_init_gpl.c index e1fdabaeb9d1..585b3afc218a 100644 --- a/board/xilinx/zynqmp/zynqmp-zcu100-revC/psu_init_gpl.c +++ b/board/xilinx/zynqmp/zynqmp-zcu100-revC/psu_init_gpl.c @@ -409,7 +409,6 @@ static unsigned long psu_mio_init_data(void) psu_mask_write(0xFF18007C, 0x000000FEU, 0x00000000U); psu_mask_write(0xFF180080, 0x000000FEU, 0x00000008U); psu_mask_write(0xFF180084, 0x000000FEU, 0x00000008U); - psu_mask_write(0xFF180088, 0x000000FEU, 0x00000008U); psu_mask_write(0xFF18008C, 0x000000FEU, 0x00000000U); psu_mask_write(0xFF180090, 0x000000FEU, 0x00000000U); psu_mask_write(0xFF180094, 0x000000FEU, 0x00000000U); @@ -990,3 +989,9 @@ int psu_init(void) return 1; return 0; } + +unsigned long psu_post_config_data(void) +{ + psu_mask_write(0xFF180088, 0x000000FEU, 0x00000008U); + return 0; +} -- 2.24.0

1 0

Re: [U-Boot-Custodians] [ANN] U-Boot v2020.01-rc4 released
by Tom Rini 03 Dec '19

03 Dec '19

On Tue, Dec 03, 2019 at 11:30:28AM +0000, Eugen.Hristev(a)microchip.com wrote: > > > On 03.12.2019 05:10, Tom Rini wrote: > > > Hey all, > > > > It's release day and here is v2020.01-rc4. Yes, I'm still working on > > fixing all of the issues that pop up as I get the MTD clean-up series > > ready to go. In fact, what I need to do at this point is grab the > > handful of size reduction patches that this has shown are worthwhile, > > then I can do the MTD series. Then we're down to just fixing up > > misconversions where things got turned off. > > > > Once again, for a changelog, > > git log --merges v2020.01-rc3..v2020.01-rc4 > > and as always, I ask for more details in the PRs people send me so I can > > put them in the merge commit. > > > > I'm planning on doing -rc5 on December 23rd with the release scheduled > > on January 6th. Thanks all! > > Hi Tom, > > Isn't Jan 6th a bit tight considering the new year vacations ? > Not like I would expect last minute bugs, but, just to make sure. I expect things to get very quiet after this week, so I think things will be safe. I'm grabbing some assorted fixes now, and then the MTD cleanups, and then that's about it. -- Tom

1 0

Re: [U-Boot] [PATCH v4 2/2] sifive: fu540: Enable OF_SEPARATE
by Rick Chen 03 Dec '19

03 Dec '19

Hi Jagon > From: Jagan Teki [mailto:jagan@amarulasolutions.com] > Sent: Monday, November 18, 2019 7:30 PM > To: Rick Jian-Zhi Chen(陳建志) > Cc: u-boot(a)lists.denx.de; Jagan Teki > Subject: [PATCH v4 2/2] sifive: fu540: Enable OF_SEPARATE > > Use dts support from U-Boot via OF_SEPARATE instead of depending from opensbi. > > This would help to make the necessary changes in drivers and device trees in U-Boot tree itself. This feature would also be helpful to not pass dtb during opensbi builds. > > Signed-off-by: Jagan Teki <jagan(a)amarulasolutions.com> > --- > Changes for v4: > - Drop abosolete text > > configs/sifive_fu540_defconfig | 3 ++- > doc/board/sifive/fu540.rst | 5 +---- > 2 files changed, 3 insertions(+), 5 deletions(-) > > diff --git a/configs/sifive_fu540_defconfig b/configs/sifive_fu540_defconfig index 48865e5f11..979d0a0418 100644 > --- a/configs/sifive_fu540_defconfig > +++ b/configs/sifive_fu540_defconfig > @@ -6,6 +6,7 @@ CONFIG_RISCV_SMODE=y > CONFIG_DISTRO_DEFAULTS=y > CONFIG_FIT=y > CONFIG_MISC_INIT_R=y > +CONFIG_DEFAULT_DEVICE_TREE="hifive-unleashed-a00" > CONFIG_DISPLAY_CPUINFO=y > CONFIG_DISPLAY_BOARDINFO=y > -CONFIG_OF_PRIOR_STAGE=y > +CONFIG_OF_SEPARATE=y > diff --git a/doc/board/sifive/fu540.rst b/doc/board/sifive/fu540.rst index 7807f5b2c1..dd279f6a03 100644 > --- a/doc/board/sifive/fu540.rst > +++ b/doc/board/sifive/fu540.rst > @@ -58,10 +58,7 @@ firmware. We need to compile OpenSBI with below command: > > .. code-block:: none > > - make PLATFORM=sifive/fu540 FW_PAYLOAD_PATH=<path to u-boot.bin> FW_PAYLOAD_FDT_PATH=<path to hifive-unleashed-a00.dtb from Linux> > - > -(Note: Prefer hifive-unleashed-a00.dtb from Linux-5.3 or higher) > -(Note: Linux-5.2 is also fine but it does not have ethernet DT node) > + make PLATFORM=sifive/fu540 FW_PAYLOAD_PATH=<path to u-boot-dtb.bin> > > More detailed description of steps required to build FW_PAYLOAD firmware is beyond the scope of this document. Please refer OpenSBI documenation. > -- > 2.18.0.321.gffc6fa0e3 > I am trying to prepare a PR, but it encounter a conflict with the master when applying this patch. Can you rebase it again ? Or if you don't mind I can modify your patch directly. Thanks Rick

2 1

[PATCH] arm64: zynqmp: Add support for u-boot.itb generation with ATF.
by Michal Simek 03 Dec '19

03 Dec '19

Follow i.MX, Sunxi, RISC-V and Rockchip to generate u-boot.itb which includes U-Boot proper, ATF and DTBs in FIT format. ZynqMP supports FIT for quite a long time but with using out of tree solution. The patch is filling this gap. Tested on zcu102, zcu104 and zcu100/Ultra96. Signed-off-by: Michal Simek <michal.simek(a)xilinx.com> --- Kconfig | 3 +- arch/arm/mach-zynqmp/mkimage_fit_atf.sh | 99 +++++++++++++++++++++++++ include/configs/xilinx_zynqmp.h | 6 +- 3 files changed, 106 insertions(+), 2 deletions(-) create mode 100755 arch/arm/mach-zynqmp/mkimage_fit_atf.sh diff --git a/Kconfig b/Kconfig index e22417ec4471..7efafffec0a4 100644 --- a/Kconfig +++ b/Kconfig @@ -253,7 +253,7 @@ config BUILD_TARGET default "u-boot-spl.kwb" if ARCH_MVEBU && SPL default "u-boot-elf.srec" if RCAR_GEN3 default "u-boot.itb" if SPL_LOAD_FIT && (ARCH_ROCKCHIP || \ - ARCH_SUNXI || RISCV) + ARCH_SUNXI || RISCV || ARCH_ZYNQMP) default "u-boot.kwb" if KIRKWOOD default "u-boot-with-spl.bin" if ARCH_AT91 && SPL_NAND_SUPPORT default "u-boot-with-spl.imx" if ARCH_MX6 && SPL @@ -481,6 +481,7 @@ config SPL_FIT_GENERATOR depends on SPL_FIT default "board/sunxi/mksunxi_fit_atf.sh" if SPL_LOAD_FIT && ARCH_SUNXI default "arch/arm/mach-rockchip/make_fit_atf.py" if SPL_LOAD_FIT && ARCH_ROCKCHIP + default "arch/arm/mach-zynqmp/mkimage_fit_atf.sh" if SPL_LOAD_FIT && ARCH_ZYNQMP default "arch/riscv/lib/mkimage_fit_opensbi.sh" if SPL_LOAD_FIT && RISCV help Specifies a (platform specific) script file to generate the FIT diff --git a/arch/arm/mach-zynqmp/mkimage_fit_atf.sh b/arch/arm/mach-zynqmp/mkimage_fit_atf.sh new file mode 100755 index 000000000000..1a4f396d1c3a --- /dev/null +++ b/arch/arm/mach-zynqmp/mkimage_fit_atf.sh @@ -0,0 +1,99 @@ +#!/bin/sh +# SPDX-License-Identifier: GPL-2.0+ +# +# script to generate FIT image source for Xilinx ZynqMP boards with +# ARM Trusted Firmware and multiple device trees (given on the command line) +# +# usage: $0 <dt_name> [<dt_name> [<dt_name] ...] + +BL33="u-boot-nodtb.bin" +[ -z "$BL31" ] && BL31="bl31.bin" +[ -z "$ATF_LOAD_ADDR" ] && ATF_LOAD_ADDR="0xfffe0000" +[ -z "$BL33_LOAD_ADDR" ] && BL33_LOAD_ADDR="0x8000000" + +if [ ! -f $BL31 ]; then + echo "ERROR: BL31 file $BL31 NOT found" >&2 +else + echo "$BL31 size: " >&2 + ls -lct $BL31 | awk '{print $5}' >&2 +fi + + + +cat << __HEADER_EOF +/dts-v1/; + +/ { + description = "Configuration to load ATF before U-Boot"; + + images { + uboot { + description = "U-Boot (64-bit)"; + data = /incbin/("$BL33"); + type = "firmware"; + os = "u-boot"; + arch = "arm64"; + compression = "none"; + load = <$BL33_LOAD_ADDR>; + hash { + algo = "md5"; + }; + }; + atf { + description = "ARM Trusted Firmware"; + data = /incbin/("$BL31"); + type = "firmware"; + os = "arm-trusted-firmware"; + arch = "arm64"; + compression = "none"; + load = <$ATF_LOAD_ADDR>; + entry = <$ATF_LOAD_ADDR>; + hash { + algo = "md5"; + }; + }; +__HEADER_EOF + +cnt=1 +for dtname in $* +do + cat << __FDT_IMAGE_EOF + fdt_$cnt { + description = "$(basename $dtname .dtb)"; + data = /incbin/("$dtname"); + type = "flat_dt"; + arch = "arm64"; + compression = "none"; + hash { + algo = "md5"; + }; + }; +__FDT_IMAGE_EOF +cnt=$((cnt+1)) +done + +cat << __CONF_HEADER_EOF + }; + configurations { + default = "config_1"; + +__CONF_HEADER_EOF + +cnt=1 +for dtname in $* +do +cat << __CONF_SECTION1_EOF + config_$cnt { + description = "$(basename $dtname .dtb)"; + firmware = "uboot"; + loadables = "atf"; + fdt = "fdt_$cnt"; + }; +__CONF_SECTION1_EOF +cnt=$((cnt+1)) +done + +cat << __ITS_EOF + }; +}; +__ITS_EOF diff --git a/include/configs/xilinx_zynqmp.h b/include/configs/xilinx_zynqmp.h index ee1ceebf1291..e7eb8dbfcb45 100644 --- a/include/configs/xilinx_zynqmp.h +++ b/include/configs/xilinx_zynqmp.h @@ -243,7 +243,11 @@ # define CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTOR 0 /* unused */ # define CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTORS 0 /* unused */ # define CONFIG_SYS_MMCSD_RAW_MODE_KERNEL_SECTOR 0 /* unused */ -# define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME "u-boot.img" +# if defined(CONFIG_SPL_LOAD_FIT) +# define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME "u-boot.itb" +# else +# define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME "u-boot.img" +# endif #endif #if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_DFU) -- 2.24.0

1 0

[U-Boot] [PATCH 1/1] efi_loader: pass address to efi_install_fdt()
by Heinrich Schuchardt 03 Dec '19

03 Dec '19

As part of moving the parsing of command line arguments to do_bootefi() call efi_install_fdt() with the address of the device tree instead of a string. Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> --- cmd/bootefi.c | 30 ++++++++++++++++-------------- 1 file changed, 16 insertions(+), 14 deletions(-) diff --git a/cmd/bootefi.c b/cmd/bootefi.c index f613cce7e2..3cf190889e 100644 --- a/cmd/bootefi.c +++ b/cmd/bootefi.c @@ -196,40 +196,37 @@ static void *get_config_table(const efi_guid_t *guid) #endif /* !CONFIG_IS_ENABLED(GENERATE_ACPI_TABLE) */ /** - * efi_install_fdt() - install fdt passed by a command argument + * efi_install_fdt() - install device tree * - * If fdt_opt is available, the device tree located at that memory address will + * If fdt_addr is available, the device tree located at that memory address will * will be installed as configuration table, otherwise the device tree located * at the address indicated by environment variable fdtcontroladdr will be used. * - * On architectures (x86) using ACPI tables device trees shall not be installed - * as configuration table. + * On architectures using ACPI tables device trees shall not be installed as + * configuration table. * - * @fdt_opt: pointer to argument + * @fdt_addr: address of device tree * Return: status code */ -static efi_status_t efi_install_fdt(const char *fdt_opt) +static efi_status_t efi_install_fdt(uintptr_t fdt_addr) { /* * The EBBR spec requires that we have either an FDT or an ACPI table * but not both. */ #if CONFIG_IS_ENABLED(GENERATE_ACPI_TABLE) - if (fdt_opt) { + if (fdt_addr) { printf("ERROR: can't have ACPI table and device tree.\n"); return EFI_LOAD_ERROR; } #else - unsigned long fdt_addr; void *fdt; bootm_headers_t img = { 0 }; efi_status_t ret; - if (fdt_opt) { - fdt_addr = simple_strtoul(fdt_opt, NULL, 16); - if (!fdt_addr) - return EFI_INVALID_PARAMETER; - } else { + if (!fdt_addr) { + const char* fdt_opt; + /* Look for device tree that is already installed */ if (get_config_table(&efi_guid_fdt)) return EFI_SUCCESS; @@ -556,6 +553,7 @@ static int do_efi_selftest(void) static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) { efi_status_t ret; + uintptr_t fdt_addr; if (argc < 2) return CMD_RET_USAGE; @@ -568,7 +566,11 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) return CMD_RET_FAILURE; } - ret = efi_install_fdt(argc > 2 ? argv[2] : NULL); + if (argc > 2) + fdt_addr = simple_strtoul(argv[2], NULL, 16); + else + fdt_addr = 0UL; + ret = efi_install_fdt(fdt_addr); if (ret == EFI_INVALID_PARAMETER) return CMD_RET_USAGE; else if (ret != EFI_SUCCESS) -- 2.24.0

2 5

driving Eth PHYs as udevices
by Alexandru Marginean 03 Dec '19

03 Dec '19

Hi, does anyone have any strong feelings either way about the idea of driving Eth PHYs as udevices? I'm looking for a solution for a few problems: - There are a few Eth switches that are accessed over MDIO and could/should be driven as DSA switches instead of PHYs. This requires that MDIO does probing of child devices like any regular bus and doesn't assume they are all PHYs. Also it requires that MDIO enumerates (at least some) of its children instead of wating for an Eth device to come connect to a specific PHY/addr. - PHY scanning using empty 'reg' in PHY DT nodes works for anything more complicated than a single PHY on the bus only only if there is some state in the bus. In Linux child nodes with valid reg are bound first and then any others left are associated with PHYs found scanning. This doesn't work if there is no enumeration on the MDIO bus and it just waits for Eth drivers to connect to PHYs. - there are a few other peculiarities with current PHY support, mentioned by Grygorii on this list, like phy probe being called before its DT node was populated in phydev structure. Using the regular udevice infrastructure should fix that and make PHYs consistent with just about anything else. What I'm thinking to do is to enumerate all child DT nodes when MDIO is probed and bind drivers to them. If some are missing the 'reg' property the bus is scanned. The devices associated with DT child nodes are bound to drivers, probed, if they are PHYs then they have to wait for someone to come connect to them, but if they are switches or anything else they are set up as expected. Thoughts? Alex

1 0

Re: [U-Boot-Custodians] [ANN] U-Boot v2020.01-rc4 released
by Eugen.Hristev＠microchip.com 03 Dec '19

03 Dec '19

Resending because of mailing list server issues. On 03.12.2019 13:30, Eugen Hristev wrote: > > > On 03.12.2019 05:10, Tom Rini wrote: > >> Hey all, >> >> It's release day and here is v2020.01-rc4. Yes, I'm still working on >> fixing all of the issues that pop up as I get the MTD clean-up series >> ready to go. In fact, what I need to do at this point is grab the >> handful of size reduction patches that this has shown are worthwhile, >> then I can do the MTD series. Then we're down to just fixing up >> misconversions where things got turned off. >> >> Once again, for a changelog, >> git log --merges v2020.01-rc3..v2020.01-rc4 >> and as always, I ask for more details in the PRs people send me so I can >> put them in the merge commit. >> >> I'm planning on doing -rc5 on December 23rd with the release scheduled >> on January 6th. Thanks all! > > Hi Tom, > > Isn't Jan 6th a bit tight considering the new year vacations ? > Not like I would expect last minute bugs, but, just to make sure. > > Eugen > >> >> -- >> Tom >> >> >> _______________________________________________ >> U-Boot-Custodians mailing list >> U-Boot-Custodians(a)lists.denx.de >> https://lists.denx.de/listinfo/u-boot-custodians >>

1 0

Repeating of unknown commands
by Martin Kaistra 03 Dec '19

03 Dec '19

Hi, I have a question regarding the command repeat feature when you press return without additional input. The current behavior is, that unknown commands are repeated like regular commands: => foobar Unknown command 'foobar' - try 'help' => Unknown command 'foobar' - try 'help' This wasn't the case in older versions like 2011.12, which I have running on a board. I believe this was changed in 9d12d5d41d "Add cmd_process() to process commands in one place" but I couldn't find a mention of this change in behavior. Was this intentional or not? Thanks, Martin

1 0

[U-Boot] [PATCH v3 0/2] imx6ull: Fix missing initial output from UART
by Igor Opaniuk 03 Dec '19

03 Dec '19

For Colibri iMX6ULL we have to set pinmux for uart configuration ASAP (ideally before relocation) to get serial console working. Without this we miss almost the half of output (U-boot version, CPU defails, Reset cause, DRAM details etc.). To achieve this we need to force pinctrl-mx6 to get probed before relocation (is already applied) and add u-boot,dm-pre-reloc properties to uart pinmux configuration nodes. Setting pinmux configuration for UART before was done in board_early_init_f(). Igor Opaniuk (2): ARM: dts: imx6ull-colibri: change hierarchy of DTS files ARM: dts: imx6ull-colibri: pre-reloc for uart pinmux modes v3: - Applied R-b tags [Fabio Estevam], [Oleksandr Suvorov]. - Rebased on the latest u-boot-imx/master. - Excluded from patch series c115cd154c("pinctrl: nxp: DM_FLAG_PRE_RELOC by default") as it was already applied by Stefano (https://patchwork.ozlabs.org/patch/1136382/). v2: - Addressed comments [Fabio Estevam]. arch/arm/dts/imx6ull-colibri-u-boot.dtsi | 12 + arch/arm/dts/imx6ull-colibri.dts | 628 +-------------------- arch/arm/dts/imx6ull-colibri.dtsi | 633 ++++++++++++++++++++++ board/toradex/colibri-imx6ull/MAINTAINERS | 2 + 4 files changed, 649 insertions(+), 626 deletions(-) create mode 100644 arch/arm/dts/imx6ull-colibri-u-boot.dtsi create mode 100644 arch/arm/dts/imx6ull-colibri.dtsi -- 2.17.1

4 11

[U-Boot] [PATCH v2 0/4] mtd: spi: spi-nor-core: Add SST vendor specific SFDP parser
by Tudor.Ambarus＠microchip.com 03 Dec '19

03 Dec '19

From: Tudor Ambarus <tudor.ambarus(a)microchip.com> Parse manufacturer specific SFDP table. The SST SFDP table contains pre-programmed globally unique MAC addresses. Retrieve the MAC address from the SPI NOR flash and set it in ethaddr in env. v2: - s/SFDP_MICROCHIP_ID/SFDP_SST_ID - don't drop all information we extracted from BFPT if optional table parsers fail. In case of failing, each optional SFDP parser is responsible to roll back to the previously known spi_nor data. Tudor Ambarus (4): mtd: spi: spi-nor-core: Add SST vendor specific SFDP parser board: atmel: sama5d27_wlsom1_ek: Set ethaddr from spi-nor flash configs: sama5d27_wlsom1_ek: qspiflash: Enable SPI NOR ethaddr retrieval configs: sama5d27_wlsom1_ek: mmc: Enable SPI NOR ethaddr retrieval arch/arm/mach-at91/include/mach/at91_common.h | 1 + board/atmel/common/Makefile | 1 + board/atmel/common/mac-spi-nor.c | 127 +++++++++++++++++++++ .../atmel/sama5d27_wlsom1_ek/sama5d27_wlsom1_ek.c | 3 + configs/sama5d27_wlsom1_ek_mmc_defconfig | 5 + configs/sama5d27_wlsom1_ek_qspiflash_defconfig | 1 + drivers/mtd/spi/spi-nor-core.c | 46 +++++++- include/linux/mtd/spi-nor.h | 2 + 8 files changed, 184 insertions(+), 2 deletions(-) create mode 100644 board/atmel/common/mac-spi-nor.c -- 2.9.5

3 6