May 2020 - U-Boot

Pull request for UEFI sub-system for efi-2020-07-rc2-4
by Heinrich Schuchardt 11 May '20

11 May '20

The following changes since commit c5c657644bc35fd6b3d6e5517698721e90646b8d: Merge branch '2020-05-08-assorted-fixes' (2020-05-08 18:58:19 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git tags/efi-2020-07-rc2-4 for you to fetch changes up to bdb15776f6d93a1fe7902346db06a2a9fd43381e: cmd: efidebug: fix -Werror=type-limits warning (2020-05-10 00:01:12 +0200) No problems were reported by Gitlab CI and Travis: https://travis-ci.org/github/xypron2/u-boot/builds/685166920 https://gitlab.denx.de/u-boot/custodians/u-boot-efi/pipelines/3170 ---------------------------------------------------------------- Pull request for UEFI sub-system for efi-2020-07-rc2-4 This pull request comprises: * bug fixes * documentation fixes * a new function to determine u16 string sizes and its unit test ---------------------------------------------------------------- AKASHI Takahiro (4): efi_loader: image_loader: fix a Coverity check against array access efi_loader: variable: check a return value of uuid__str_to_bin() cmd: efidebug: fix a wrong handling of arguments cmd: efidebug: add a comment against Coverity check (300329) Heinrich Schuchardt (5): efi_selftest: add unit test functions to HTML documentation test: unit test for u16_strsize() lib: charset: correct function descriptions doc: add Unicode functions to API description cmd: efidebug: fix -Werror=type-limits warning Sughosh Ganu (1): charset: Add support for calculating bytes occupied by a u16 string cmd/efidebug.c | 9 +++- doc/api/efi.rst | 9 ++++ doc/api/index.rst | 1 + doc/api/unicode.rst | 7 +++ include/charset.h | 49 ++++++++++++----- include/efi_selftest.h | 110 +++++++++++++++++++++++++------------- lib/charset.c | 5 ++ lib/efi_loader/efi_image_loader.c | 6 +-- lib/efi_loader/efi_variable.c | 5 +- test/unicode_ut.c | 10 ++++ 10 files changed, 154 insertions(+), 57 deletions(-) create mode 100644 doc/api/unicode.rst

2 1

[PATCH] kbuild: add -Werror=implicit-function-declaration
by Masahiro Yamada 11 May '20

11 May '20

Add -Werror=implicit-function-declaration as Linux does. If you do not check the prototype, it may go wrong run-time. It is better to break the build, and require to include correct headers. Signed-off-by: Masahiro Yamada <yamada.masahiro(a)socionext.com> --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index cc99873062..f8b136a07f 100644 --- a/Makefile +++ b/Makefile @@ -419,7 +419,7 @@ CHECKFLAGS := -D__linux__ -Dlinux -D__STDC__ -Dunix -D__unix__ \ KBUILD_CPPFLAGS := -D__KERNEL__ -D__UBOOT__ KBUILD_CFLAGS := -Wall -Wstrict-prototypes \ - -Wno-format-security \ + -Werror=implicit-function-declaration -Wno-format-security \ -fno-builtin -ffreestanding $(CSTD_FLAG) KBUILD_CFLAGS += -fshort-wchar -fno-strict-aliasing KBUILD_AFLAGS := -D__ASSEMBLY__ -- 2.25.1

5 11

Calling i2c set speed twice for i2c_mux_bus
by Michal Simek 11 May '20

11 May '20

Hi Heiko and Simon, I have find out one bug in i2c class. I am using zcu104 revC board which has dts in mainline where i2c1 has i2c mux with some channels. In DT clock-frequency = <400000>; is specified and it is read in i2c_post_probe(). But i2c_mux_bus_drv is also UCLASS_I2C which means that post probe is called for it too. And because clock-frequency property is not there default 100k is used. I think that is bug and should be fixed. Heiko: Are you aware about this issue? Simon: I think that make sense to use some flags to skip calling post_probe in this case. Or any suggestion how to fix it would be great. Thanks, Michal

3 14

[U-Boot] [PATCH v2 0/4] regmap: Add a managed API, custom read/write callbacks and support for regmap fields
by Jean-Jacques Hiblot 11 May '20

11 May '20

This is the first of a few series, the goal of which is to facilitate porting drivers from the linux kernel. Most of the series will be about adding managed API to existing infrastructure (GPIO, reset, phy,...) This particular series is about regmaps. It adds the managed API, using the same API as linux. It also adds support for regmap fields and for custom read/write callbacks. Changes in v2: - Fix comment for devm_regmap_init() - Fix spelling in commit log - Only use custom accessors if {,SPL,TPL}_REGMAP_ACCESSORS is enabled Jean-Jacques Hiblot (4): regmap: Add devm_regmap_init() regmap: Allow providing read/write callbacks through struct regmap_config regmap: Add support for regmap fields test: dm: Add tests for regmap managed API and regmap fields arch/sandbox/dts/test.dts | 13 +++ drivers/core/Kconfig | 25 +++++ drivers/core/regmap.c | 123 ++++++++++++++++++++++++- include/regmap.h | 148 +++++++++++++++++++++++++++++ test/dm/regmap.c | 189 ++++++++++++++++++++++++++++++++++++++ 5 files changed, 497 insertions(+), 1 deletion(-) -- 2.17.1

5 15

Setting up test.py for a platform with 2 U-Boots?
by Tom Rini 11 May '20

11 May '20

Hey, So I'm trying to enable our test.py framework on am65x_evm_r5 + am65x_evm_a53. The short version is this platform has an R5 core that sets things up and fires off the A53 cores. So there's two U-Boots and the console log looks like this (I used SOURCE_DATE_EPOCH to give both binaries the same timestamp): U-Boot SPL 2020.07-rc1-00386-g8737c65fe4e3 (May 07 2020 - 18:29:35 +0000) SYSFW ABI: 2.9 (firmware rev 0x0013 '19.12.2-v2019.12b (Terrific Lla') Trying to boot from MMC2 Starting ATF on ARM64 core... NOTICE: BL31: v2.3():v2.3 NOTICE: BL31: Built : 11:22:40, Apr 21 2020 INFO: GICv3 without legacy support detected. INFO: ARM GICv3 driver initialized in EL3 INFO: SYSFW ABI: 2.9 (firmware rev 0x0013 '19.12.2-v2019.12b (Terrific Lla') INFO: BL31: Initializing runtime services INFO: BL31: cortex_a53: CPU workaround for 855873 was applied INFO: BL31: Initializing BL32 I/TC: I/TC: OP-TEE version: 3.8.0-267-g8287cbcf (gcc version 9.2.1 20191025 (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10))) #1 Tue Apr 21 05:57:19 UTC 2020 aarch64 I/TC: Initialized INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x80080000 INFO: SPSR = 0x3c9 U-Boot SPL 2020.07-rc1-00386-g8737c65fe4e3 (May 07 2020 - 18:29:35 +0000) SYSFW ABI: 2.9 (firmware rev 0x0013 '19.12.2-v2019.12b (Terrific Lla') Trying to boot from MMC2 U-Boot 2020.07-rc1-00386-g8737c65fe4e3 (May 07 2020 - 18:29:35 +0000) SoC: AM65x SR 1.0 Model: Texas Instruments AM654 Base Board Board: AM6-COMPROCEVM rev E3 DRAM: 4 GiB MMC: sdhci@4f80000: 0, sdhci@04FA0000: 1 Loading Environment from MMC... *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Detected: SER-PCIEUSBEVM rev E3 Net: Warning: cpsw_nuss@046000000 using MAC address from ROM eth0: cpsw_nuss@046000000 Hit any key to stop autoboot: 2 0 => But when I run test.py: ... if m != 0: raise Exception('Bad pattern found on console: ' + > self.bad_pattern_ids[m - 1]) E Exception: Bad pattern found on console: spl_signon test/py/u_boot_console_base.py:365: Exception ------------------------------------------------------ Captured stdout setup ------------------------------------------------------ +u-boot-test-reset am65x_evm_a53 na picocom v2.2 port is : /dev/serial/by-path/pci-0000:08:00.0-usb-0:1.4.2.5:1.0-port0 flowcontrol : none baudrate is : 115200 parity is : none databits are : 8 stopbits are : 1 escape is : C-a local echo is : no noinit is : no noreset is : no nolock is : no send_cmd is : sz -vv receive_cmd is : rz -vv -E imap is : omap is : emap is : crcrlf,delbs, Type [C-a] [C-h] to see available commands Terminal ready U-Boot SPL 2020.07-rc1-00386-g8737c65fe4e3 (May 07 2020 - 18:29:35 +0000) SYSFW ABI: 2.9 (firmware rev 0x0013 '19.12.2-v2019.12b (Terrific Lla') ================================================ 308 deselected, 1 error in 5.30s ================================================= And that's even with: env__spl_skipped = True in u_boot_boardenv_am65x_evm_a53_na.py for the platform. Any ideas on what to do here? I even tried turning off serial support in the R5 side of things, but it still failed. Thanks! -- Tom

2 2

[PATCH 0/5] CMD_SAVEENV ifdef cleanup
by Rasmus Villemoes 11 May '20

11 May '20

The various env storage drivers almost all have their own logic [1] for deciding whether to compile and provide the .save method, many of which fail to honour CONFIG_SPL_SAVEENV. For example, fat.c and sf.c define a CMD_SAVEENV macro only for !CONFIG_SPL_BUILD, while ext4.c "only" depends on CONFIG_CMD_SAVEENV - but CONFIG_SPL_SAVEENV=y, CONFIG_CMD_SAVEENV=n is a valid combination. A lot of that ifdeffery can be removed while at the same time providing the .save method if either CONFIG_SPL_SAVEENV (for an SPL build) or CONFIG_CMD_SAVEENV (for U-Boot proper) is set. The first two patches introduce infrastructure for that, while the last three are example conversions for the above-mentioned three storage drivers. The sf.c is the one I need to use in the SPL and have actually tested, ext4.c and fat.c are included mostly as low-hanging fruit. [1] Here's the current conditions for which these three drivers provide .save: SPL U-Boot ext4.c CONFIG_CMD_SAVEENV=y CONFIG_CMD_SAVEENV=y fat.c never CONFIG_CMD_SAVEENV=y sf.c never CONFIG_CMD_SAVEENV=y [2] [2] It always compiles env_sf_save for U-Boot proper, but then the use of env_save_ptr() ends up with a build warning in case CONFIG_CMD_SAVEENV=n - fat.c doesn't have that proplem. Rasmus Villemoes (5): env: add SAVEENV as an alias of the CMD_SAVEENV symbol env_internal.h: add alternative ENV_SAVE_PTR macro env/fat.c: remove private CMD_SAVEENV logic env/ext4.c: remove CONFIG_CMD_SAVEENV ifdef env/sf.c: drop private CMD_SAVEENV logic env/Kconfig | 3 +++ env/ext4.c | 4 +--- env/fat.c | 9 +-------- env/sf.c | 12 +----------- include/env_internal.h | 2 ++ 5 files changed, 8 insertions(+), 22 deletions(-) -- 2.23.0

3 34

Status i.MX U-Boot patches
by Stefano Babic 11 May '20

11 May '20

Sorry, forgotten ML... Hi Fabio, Peng, I have thought about how to handle Peng's last series and I came to the decision to merge them as soon as possible, letting some more time for fixes if required. Most patches are orthogonal, and this helps to let them in. I merged the two series for NAND, too, with the hope that someone can retest nandbcb on MX6(UL), too. My list contains: - imx8qm/qxp update series, and IMX_BOOTAUX patch - NAND i.MX update and nandbcb series - uclass series(http://patchwork.ozlabs.org/user/todo/uboot/?series=174311) - aloo should be taken at 5/8, because of conflicts I had to solve (IMHO it is ok, but polease test again) - thermal series - with the chance, I merged two additional board form Marek and Adam. Status is on my -next, but I am going to push it to -master, too. I plan then to merge just fixes for 2020.07, if there will be new features they will flow into -next. Regards, Stefano -- ===================================================================== DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic(a)denx.de =====================================================================

3 3

FW: mmc: zynq_sdhci: transfer fails with 8-bit data bus
by Benedikt Grassl 11 May '20

11 May '20

Hi, with commit 942b5fc0 the 8-bit data bus seems to work fine in U-Boot. However, I have one situation where I get transfer errors lateron in Linux. At the moment I suspect that this is rather a problem of the Linux driver, but I would like to make sure here first. My ZynqMP has an eMMC flash connected to SD0 and an SD-card to SD1. When I boot the device from SD-card and load a kernel ITB (tested both 4.14 and 5.4), I immediately get errors when writing to the eMMC flash in Linux: print_req_error: I/O error, dev mmcblk0, sector 2048 Buffer I/O error on dev mmcblk0p1, logical block 0, lost sync page write mmc0: Got data interrupt 0x00000002 even though no data operation was in progress. mmc0: sdhci: ============ SDHCI REGISTER DUMP =========== mmc0: sdhci: Sys addr: 0x00000400 | Version: 0x00001002 mmc0: sdhci: Blk size: 0x00007200 | Blk cnt: 0x00000400 mmc0: sdhci: Argument: 0x00000000 | Trn mode: 0x00000033 mmc0: sdhci: Present: 0x1ff70000 | Host ctl: 0x0000003d mmc0: sdhci: Power: 0x0000000f | Blk gap: 0x00000080 mmc0: sdhci: Wake-up: 0x00000000 | Clock: 0x00000007 mmc0: sdhci: Timeout: 0x00000006 | Int stat: 0x00000000 mmc0: sdhci: Int enab: 0x02ff000b | Sig enab: 0x02ff000b mmc0: sdhci: AC12 err: 0x00000000 | Slot int: 0x00000000 mmc0: sdhci: Caps: 0x75ecc881 | Caps_1: 0x00002007 mmc0: sdhci: Cmd: 0x00000c1a | Max curr: 0x00000000 mmc0: sdhci: Resp[0]: 0x00000b00 | Resp[1]: 0x36475026 mmc0: sdhci: Resp[2]: 0x49533031 | Resp[3]: 0x00000900 mmc0: sdhci: Host ctl2: 0x0000008b mmc0: sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x0000000000000000 mmc0: sdhci: ============================================ Interestingly, I can work-around this by just typing "mmc info" in the U-Boot console. As soon as some interaction with mmc0 happens in U-Boot , this problem disappears (i.e. anything that relies on the mmc layer to issue transfers to the eMMC flash). This did not happen before, when only a 4-bit data bus was supported. Also the latest commit e44c2bc on the Xilinx U-boot git repository does not solve this problem. >From my understanding, the Linux driver should be independent of the initialization done in U-Boot, right? Does anyone have an idea or a comment to this? Did I miss anything? Thanks, Benedikt

1 0

Pull request v2: u-boot-spi/master
by Jagan Teki 11 May '20

11 May '20

Hi Tom, Summary: - zap lpc32xx_ssp driver (Jagan) - rename of phy nodev call (Jagan) - iopoll with sleep_us (Jagan) - MX25R6435F flash (Ye Li) Changes for v2: - rebase to master thanks, Jagan. The following changes since commit c5c657644bc35fd6b3d6e5517698721e90646b8d: Merge branch '2020-05-08-assorted-fixes' (2020-05-08 18:58:19 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-spi master for you to fetch changes up to 8af1caa23728ef689d095eec1ec4e6f1d46f50e4: sf: Add Macronix MX25R6435F SPI NOR flash to flash parameters array (2020-05-11 01:30:49 +0530) ---------------------------------------------------------------- Dario Binacchi (1): spi: fix dev parameter in dev_* calls Jagan Teki (7): spi: Zap lpc32xx_ssp driver-related code phy: Fix node description of phy_get_by_node phy: Use _nodev naming convention if non-device clients clk: Fix clk func names in comments iopoll: Add read_poll_timeout common API iopoll: Add dealy to read poll iopoll: Add readl_poll_sleep_timeout Kuldeep Singh (1): spi: nxp-fspi: Use new readl_poll_sleep_timeout API Ye Li (1): sf: Add Macronix MX25R6435F SPI NOR flash to flash parameters array arch/arm/mach-meson/board-gx.c | 3 +- drivers/mtd/spi/spi-nor-core.c | 19 +++--- drivers/mtd/spi/spi-nor-ids.c | 1 + drivers/phy/phy-uclass.c | 4 +- drivers/spi/Kconfig | 6 -- drivers/spi/Makefile | 1 - drivers/spi/lpc32xx_ssp.c | 134 ----------------------------------------- drivers/spi/nxp_fspi.c | 10 +-- include/clk.h | 12 ++-- include/configs/devkit3250.h | 5 -- include/configs/work_92105.h | 5 -- include/generic-phy.h | 9 ++- include/linux/iopoll.h | 16 ++++- scripts/config_whitelist.txt | 1 - 14 files changed, 47 insertions(+), 179 deletions(-) delete mode 100644 drivers/spi/lpc32xx_ssp.c

2 1

[PATCH v2 0/2] gpio: add gpio open-drain & open-source emulation
by Neil Armstrong 11 May '20

11 May '20

When a line is in open-drain or open-source mode, U-Boot doesn't handle it directly. Let's add gpio open-drain & open-source emulation in gpio u-class to make it transparent to driver using a gpio line from DT. Changes since v1: - fixed all open-drain/open source cases - updated dm gpio test Neil Armstrong (2): gpio: emulate open drain & open source in dm_gpio_set_value() test: dm: update test for open-drain/open-source emulation in gpio-uclass arch/sandbox/dts/test.dts | 4 +- drivers/gpio/gpio-uclass.c | 15 +++++++ test/dm/gpio.c | 89 ++++++++++++++++++++++++++++++++++++++ 3 files changed, 107 insertions(+), 1 deletion(-) -- 2.22.0

3 6