January 2021 - U-Boot

iMX8MM USB support?
by Tim Harvey 09 Mar '22

09 Mar '22

Peng, It looks like IMX8MM USB support hasn't made it upstream yet. Is this something your working on? I'm interested in booting an IMX8MM via SDP. Best Regards, Tim

7 21

IMX8MM 4GiB boundary issue
by Tim Harvey 28 Feb '22

28 Feb '22

Greetings, I'm working with an IMX8MM board that has 4GiB of DRAM. I've found that in this configuration the MMC driver and FEC network driver appear to have some issues with crossing the 4GiB address space. If I tell U-Boot I have 3GiB everything is ok, but when I set it to 4GiB I see the following: MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2 Loading Environment from MMC... Error found for upper 32 bits Error found for upper 32 bits Error found for upper 32 bits *** Warning - No block device, using default environment In: serial Out: serial Err: serial Net: DP83867 Warning: ethernet@30be0000 (eth0) using random MAC address - ea:22:3a:4d:8f:d5 eth0: ethernet@30be0000 [PRIME] Hit any key to stop autoboot: 0 On the FEC ethernet side I don't see any errors reported but ping's fail with 4GiB DRAM. I suspect drivers have 32bit addressing issues as the base of mem for IMX8MM is 1GiB so anything over 3GiB of DRAM runs you over the 32bit boundary. Anyone run into this yet? Marek, I noticed you are the maintainer for the technexion pico-imx8mq which has support for 1, 2, 3, and 4 GiB DRAM. Did you encounter such issues on the 4GiB variant? Best Regards, Tim

5 23

IMX8MM SD UHS support
by Tim Harvey 14 Jan '22

14 Jan '22

Greetings, In 50b1a69cee0d ("ARM: dts: imx8m: add UHS or HS400/HS400ES properties") u-boot dt props were added to enable UHS and HS400 on a couple of IMX8MM boards including the imx8mm-evk and in the subsequent patch enabled the config items. While I see this making a huge difference for eMMC performance in U-Boot I find it doesn't do anything for microSD performance. The issue appears to be that sd_get_capabilities() is not appropriately detecting UHS speeds on cards that appropriately detect as SDR104/DDR50 in Linux: u-boot=> mmc info Device: FSL_SDHC Manufacturer ID: 1b OEM: 534d Name: 00000 Bus Speed: 50000000 Mode: SD High Speed (50MHz) card capabilities: widths [4, 1] modes [MMC legacy, SD High Speed (50MHz)] ^^^^ no SDR104 detected for this card host capabilities: widths [4, 1] modes [MMC legacy, MMC High Speed (26MHz), SD High Speed (50MHz), MMC High Speed (52MHz), UHS DDR50 (50MHz), UHS SDR104 (208MHz)] Rd Block Len: 512 SD version 3.0 High Capacity: Yes Capacity: 14.9 GiB Bus Width: 4-bit Erase Group Size: 512 Bytes The same card in Linux shows the following upon insertion and performance tests show that it is operating at SDR104 speeds: mmc1: new ultra high speed SDR104 SDHC card at address 0001 I haven't found very good documentation on the SD switch settings to understand if something is wrong in the U-Boot implementation of of sd_get_capabilities() and I suppose it also could be an issue in sdhci-esdhc-imx.c. Any ideas where to look? Anyone see SDR104 cards being detected properly for other platforms? Best regards, Tim

6 18

[PATCH 0/5] board: mediatek: pumpkin: add fastboot support
by Fabien Parent 16 Dec '21

16 Dec '21

This series adds USB/Fastboot support on MT8516 Pumpkin board. Fabien Parent (5): arm: dts: mt8516: add support for USB arm: dts: mt8516-pumpkin: enable usb port board: mediatek: pumpkin: initialize usb device configs: pumpkin: enable USB gadget configs: pumpkin: enable fastboot arch/arm/dts/mt8516-pumpkin.dts | 10 ++++++++++ arch/arm/dts/mt8516.dtsi | 14 ++++++++++++++ board/mediatek/pumpkin/pumpkin.c | 17 +++++++++++++++++ configs/pumpkin_defconfig | 15 ++++++++++++++- 4 files changed, 55 insertions(+), 1 deletion(-) -- 2.28.0

3 12

Re: rk3399-gru-kevin: issues on bringup
by Alper Nebi Yasak 25 Nov '21

25 Nov '21

Hi Simon, Marty, I'm interested in getting U-Boot to work with Kevin as well, but don't have a Servo (or the willingness to open up the case yet), so I've been trying to boot from depthcharge as in README.chromium-chainload. I don't have a way to see serial output and I see no other signs of life. Can you give me a tested configuration that immediately powers-off or reboots a Kevin so I can confirm what I'm doing works on the chainloading side? I mean I can boot Linux, but trying the same with U-Boot just gives me a blank screen even after accounting for a lot of things. Meanwhile, I've wrote some code to automate making depthcharge partition images, and to enable the display on Kevin (and perhaps Bob). Since I don't know if chainloading works, I don't know if these are broken or not either. I'm unsure about sending untested patches to the list, so I put them up here if you want to take a look (and maybe test/fix them?): https://github.com/alpernebbi/u-boot/tree/rk3399-gru-kevin/wip They're not really things that'd make a non-booting Kevin boot, though. I hope at least some of it can be useful in some way.

4 15

[U-Boot] cfb_console.c: DM_VIDEO conversion questions/suggestions
by Igor Opaniuk 18 Nov '21

18 Nov '21

Hi everyone, I've finally started looking into the cfb_console.c driver and it's conversion to DM_VIDEO after our initial discussion [1]. Unfortunately I've a bit underestimated the amount of effort that should be done, as mxsfb.c in the Linux mainline obviously pulls the whole core fb subsystem (drivers/video/fbdev/core), which can take a while and frankly I doubt that this is a proper way to do things here. Taking into account that the deadline for DM_VIDEO conversion is 2019.07, it's unlikely that we will manage to do the full conversions this cfb_console driver and all dependent hw specific drivers in a proper way (where we can provide information about videomodes as properties in a proper nodes in DT). Currently the init chain for fb stuff in U-boot (on the other hand, in the Linux, hw specific driver is probed initially, then they trigger fb common routines that are needed from `video/fbdev/core`): stdio_add_devices() -> ./common/stdio.c -> drv_video_init () (drivers/cfb_console.c) - > video_hw_init (particular hw backend, which was statically linked at compile time with a proper video_hw_init() implementation, for example look into mxsfb.c) 2 ways of conversion that come to my mind: 1. Start with simple DM wrappers in cfb_console.c, and introduce dumb DT nodes so the device at least can be probed. All video configuration will be stored the same way as before in the U-boot env (for example, "videomode=video=ctfb:x:640,y:480,depth:18,pclk:39722,le:48,ri:16,up:33,lo:10,hs:96,vs:2,sync:0,vmode:0\0"). Then, step by step, driver by driver, we can move some properties to DT and try to sync Linux/U-boot video DT nodes (at least avoid divergence of tree nodes, so Linux/U-boot video-related DT nodes conform to each other). Yes, this is kind of dirty workaround, but at least this something we can start with, and with minimal amount of intrusive changes. 2. Perform full conversion, where everything works the same way as in Linux kernel. Initially I thought that it could be the proper way to go, but taking into account all differences in the implementation of fb in U-boot/Linux (even the way how the drivers are initialized), I think we will just end up pulling the whole big piece from the Linux kernel, that will definitely take a while (especially further support of this code base, testing/fixing issues etc.). Just to be aware about the amount of effort that should be done: : u-boot.git$ grep -e CONFIG_CFB_CONSOLE -r ./configs/ ./configs/T1042RDB_PI_SDCARD_defconfig:CONFIG_CFB_CONSOLE_ANSI=y ./configs/T1042D4RDB_SDCARD_defconfig:CONFIG_CFB_CONSOLE_ANSI=y ./configs/T1042RDB_PI_NAND_SECURE_BOOT_defconfig:CONFIG_CFB_CONSOLE_ANSI=y ./configs/nokia_rx51_defconfig:CONFIG_CFB_CONSOLE_ANSI=y ./configs/T1042D4RDB_NAND_defconfig:CONFIG_CFB_CONSOLE_ANSI=y ./configs/T1042RDB_PI_SPIFLASH_defconfig:CONFIG_CFB_CONSOLE_ANSI=y ./configs/T1042RDB_PI_NAND_defconfig:CONFIG_CFB_CONSOLE_ANSI=y ./configs/T1042D4RDB_defconfig:CONFIG_CFB_CONSOLE_ANSI=y ./configs/T1042RDB_PI_defconfig:CONFIG_CFB_CONSOLE_ANSI=y ./configs/eb_cpu5282_internal_defconfig:# CONFIG_CFB_CONSOLE is not set ./configs/T1042D4RDB_SPIFLASH_defconfig:CONFIG_CFB_CONSOLE_ANSI=y ./configs/eb_cpu5282_defconfig:# CONFIG_CFB_CONSOLE is not set ./configs/T1042D4RDB_SECURE_BOOT_defconfig:CONFIG_CFB_CONSOLE_ANSI=y Additional Kconfig symbols, that depend on CFB_CONSOLE: * VGA_AS_SINGLE_DEVICE * CONSOLE_EXTRA_INFO * CONSOLE_SCROLL_LINES * SYS_CONSOLE_BG_COL * SYS_CONSOLE_FG_COL Drivers, that don't imply CFG_CONSOLE, but are used alongside with cfb_console.c (kind of particular hw backend driver for fb console): * mxsfb.c * mb862xx.c * sunxi_display.c * ati_radeon_fb.c * fsl_dcu_fb.c * omap3_dss.c * da8xx-fb.c Looking forward to your suggestions/recommendations here (and let me know if I missed something), thanks! [1] https://lists.denx.de/pipermail/u-boot/2019-April/365506.html -- Best regards - Freundliche Grüsse - Meilleures salutations Igor Opaniuk mailto: igor.opaniuk(a)gmail.com skype: igor.opanyuk +380 (93) 836 40 67 http://ua.linkedin.com/in/iopaniuk

5 6

[U-Boot] [PATCH] usb: Make USB_MUSB_PIO_ONLY conditional on USB_MUSB_{HOST, GADGET}
by Samuel Dionne-Riel 15 Nov '21

15 Nov '21

This ensures the USB_MUSB_PIO_ONLY config is set to an apppropriate default values from the changes enabling USB_MUSB_GADGET does. Namely, USB_MUSB_PIO_ONLY default to =y on USB_MUSB_SUNXI being y. Since USB_MUSB_SUNXI is behind the conditional, the option does not exist when using make ..._defconfig, thus the default of USB_MUSB_PIO_ONLY is kept "# ... is not set". This, _is_ counter-intuitively a set value, meaning that the default will not be applied once USB_MUSB_SUNXI is set to y by toggling USB_MUSB_GADGET via menuconfig. Signed-off-by: Samuel Dionne-Riel <samuel(a)dionne-riel.com> --- Some additional context about the bug. Using `make ..._defconfig` for a sunxi board, then using `make menuconfig` to change the option `CONFIG_USB_MUSB_GADGET=y` causes builds to fail. When the same option is set to `=y` via the defconfig file, the option work. Follows the failure: ``` CC drivers/usb/musb-new/musb_gadget.o drivers/usb/musb-new/musb_gadget.c: In function 'map_dma_buffer': drivers/usb/musb-new/musb_gadget.c:103:26: warning: implicit declaration of function 'dma_map_single'; did you mean 'malloc_simple'? [-Wimplicit-function-declaration] request->request.dma = dma_map_single( ^~~~~~~~~~~~~~ malloc_simple drivers/usb/musb-new/musb_gadget.c:108:8: error: 'DMA_TO_DEVICE' undeclared (first use in this function); did you mean 'USB_DT_DEVICE'? ? DMA_TO_DEVICE ^~~~~~~~~~~~~ USB_DT_DEVICE drivers/usb/musb-new/musb_gadget.c:108:8: note: each undeclared identifier is reported only once for each function it appears in drivers/usb/musb-new/musb_gadget.c:109:8: error: 'DMA_FROM_DEVICE' undeclared (first use in this function); did you mean 'U_BOOT_DEVICE'? : DMA_FROM_DEVICE); ^~~~~~~~~~~~~~~ U_BOOT_DEVICE drivers/usb/musb-new/musb_gadget.c:112:3: warning: implicit declaration of function 'dma_sync_single_for_device' [-Wimplicit-function-declaration] dma_sync_single_for_device(musb->controller, ^~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/usb/musb-new/musb_gadget.c: In function 'unmap_dma_buffer': drivers/usb/musb-new/musb_gadget.c:135:3: warning: implicit declaration of function 'dma_unmap_single' [-Wimplicit-function-declaration] dma_unmap_single(musb->controller, ^~~~~~~~~~~~~~~~ drivers/usb/musb-new/musb_gadget.c:139:7: error: 'DMA_TO_DEVICE' undeclared (first use in this function); did you mean 'USB_DT_DEVICE'? ? DMA_TO_DEVICE ^~~~~~~~~~~~~ USB_DT_DEVICE drivers/usb/musb-new/musb_gadget.c:140:7: error: 'DMA_FROM_DEVICE' undeclared (first use in this function); did you mean 'U_BOOT_DEVICE'? : DMA_FROM_DEVICE); ^~~~~~~~~~~~~~~ U_BOOT_DEVICE drivers/usb/musb-new/musb_gadget.c:143:3: warning: implicit declaration of function 'dma_sync_single_for_cpu' [-Wimplicit-function-declaration] dma_sync_single_for_cpu(musb->controller, ^~~~~~~~~~~~~~~~~~~~~~~ make[1]: *** [scripts/Makefile.build:279: drivers/usb/musb-new/musb_gadget.o] Error 1 ``` By diffing the resulting configuration, Othe main difference found is `CONFIG_USB_MUSB_PIO_ONLY` is not set when failing, and set to `=y` when working. This was verified to be the missing option. As far as I understand it in Kconfig, "is not set" basically marks the option as using a negative "unset" value, and does not mean that it will use the default value. This difference in meaning makes it so that when toggling the option with `make menuconfig`, the option has already been set to "is not set", and it does not change to its default value. The actual bug may be that there is a regression and the code should work when this value is unset, in this case I do not know how to provide the proper fix. This fix corrects the issue by gating the option behind `if USB_MUSB_HOST || USB_MUSB_GADGET`. To me, it looks like this was the intention, in the initial patch, but might have been overlooked. I assume so since the option was defined after the `if`, rather than before, like the other options not gated behind the option. drivers/usb/musb-new/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/musb-new/Kconfig b/drivers/usb/musb-new/Kconfig index 79ad14ef66..95499f1b17 100644 --- a/drivers/usb/musb-new/Kconfig +++ b/drivers/usb/musb-new/Kconfig @@ -72,11 +72,11 @@ config USB_MUSB_DISABLE_BULK_COMBINE_SPLIT support it yet. Select this option to disable the feature until the driver adds the support. -endif - config USB_MUSB_PIO_ONLY bool "Disable DMA (always use PIO)" default y if USB_MUSB_AM35X || USB_MUSB_PIC32 || USB_MUSB_OMAP2PLUS || USB_MUSB_DSPS || USB_MUSB_SUNXI help All data is copied between memory and FIFO by the CPU. DMA controllers are ignored. + +endif -- 2.23.0

2 2

[PATCH v3 0/2] Use RNG to get random behaviour
by matthias.bgg＠kernel.org 22 Oct '21

22 Oct '21

From: Matthias Brugger <mbrugger(a)suse.com> For now bootp and uuid code use a weak seed for generating random data. U-Boot as support for RNG devices now, so we should change to code to use them if they are present. This will help mitigate issues like seen in CVE-2019-11690. Changes in v3: - use IS_ENABLED instead of #if - use 4 byte for entropy - use IS_ENABLED instead of #if Changes in v2: - fix dm_rng_read() parameters - add missing include - fix dm_rng_read() parameters - add missing include file Matthias Brugger (2): lib: uuid: use RNG device if present net: Use NDRNG device in srand_mac() lib/uuid.c | 21 ++++++++++++++++++--- net/net_rand.h | 19 ++++++++++++++++++- 2 files changed, 36 insertions(+), 4 deletions(-) -- 2.29.2

4 7

[PATCH v2 0/6] dwc3-generic: Add Layerscape support
by Ran Wang 03 Oct '21

03 Oct '21

Hello, The purpose of this patch set is to switch from driver xhci-fsl to dwc3-generic for DWC3 IP on Layerscape platforms. Whith this change, now user can enable USB device mode by merely updating property 'dr_mode' accordingly. I also port some DWC3's errata workaorunds from driver xhci-fsl (by referring to Linux kernel mainline version implemenattion). Besides that, I fixed a PHY init problem which observed on Lyerscape platforms (such as LS1088ardb). Regards, Ran Change in v2: - Remove [2/7] usb: dwc3: add disable receiver detection in P3 quirk, because I found it causes Linux kenrel fail to detect USB device, need further check. Ran Wang (6): usb: dwc3: Add frame length adjustment quirk usb: dwc3: Enable undefined length INCR burst type usb: dwc3-generic: fix dwc3_setup_phy() return -ENOTSUPP causing init failure usb: dwc3-generic: Add support for the layerscape configs: ls1088a: add usb mass storage (device mode) support arm: dts: ls1088a: change dwc3 compatible to match dwc3-generic driver arch/arm/dts/fsl-ls1088a.dtsi | 38 ++++++--- configs/ls1088aqds_defconfig | 5 ++ configs/ls1088aqds_qspi_defconfig | 5 ++ configs/ls1088aqds_sdcard_ifc_defconfig | 5 ++ configs/ls1088aqds_sdcard_qspi_defconfig | 5 ++ configs/ls1088aqds_tfa_defconfig | 5 ++ configs/ls1088ardb_qspi_defconfig | 5 ++ configs/ls1088ardb_sdcard_qspi_defconfig | 5 ++ configs/ls1088ardb_tfa_defconfig | 5 ++ drivers/usb/dwc3/core.c | 130 +++++++++++++++++++++++++++++++ drivers/usb/dwc3/core.h | 20 +++++ drivers/usb/dwc3/dwc3-generic.c | 3 +- 12 files changed, 220 insertions(+), 11 deletions(-) -- 2.7.4

2 8

Bug: qemu_arm64: Cannot access the second flash bank
by Robin Randhawa 13 Sep '21

13 Sep '21

Hi folks. [CC'ing some hopefully relevant folks]. As of: commit 0ba41ce1b7816c229cc19e0621148b98f990cb68 libfdt: return correct value if #size-cells property is not present .. accesses to the second flash bank on the qemu_arm64 virtual board appear broken. To demonstrate, consider that the physical memory map for the 2 flash banks is: Bank 1: 0x0000_0000 - 0x03FC_0000 Bank 2: 0x0400_0000 - 0x7FC0_0000 Now, consider the abbreviated output of the flinfo command pre and post the above commit: Pre: === => flinfo Bank # 1: CFI conformant flash (32 x 16) Size: 64 MB in 256 Sectors Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x0018 Erase timeout: 16384 ms, write timeout: 3 ms Buffer write timeout: 3 ms, buffer size: 2048 bytes Sector Start Addresses: 00000000 RO 00040000 RO 00080000 RO 000C0000 00100000 00140000 00180000 001C0000 00200000 00240000 . . 03E80000 03EC0000 03F00000 03F40000 03F80000 03FC0000 Bank # 2: CFI conformant flash (32 x 16) Size: 64 MB in 256 Sectors Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x0018 Erase timeout: 16384 ms, write timeout: 3 ms Buffer write timeout: 3 ms, buffer size: 2048 bytes Sector Start Addresses: 04000000 RO 04040000 04080000 040C0000 04100000 04140000 04180000 041C0000 04200000 04240000 . . 07E80000 07EC0000 07F00000 07F40000 07F80000 07FC0000 Post: ==== => flinfo Bank # 1: CFI conformant flash (32 x 16) Size: 64 MB in 256 Sectors Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x0018 Erase timeout: 16384 ms, write timeout: 3 ms Buffer write timeout: 3 ms, buffer size: 2048 bytes Sector Start Addresses: 00000000 RO 00040000 RO 00080000 RO 000C0000 00100000 00140000 00180000 001C0000 00200000 00240000 . . 03E80000 03EC0000 03F00000 03F40000 03F80000 03FC0000 Bank # 2: CFI conformant flash (32 x 16) Size: 64 MB in 256 Sectors Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x0018 Erase timeout: 16384 ms, write timeout: 3 ms Buffer write timeout: 3 ms, buffer size: 2048 bytes Sector Start Addresses: 400000000000000 400000000040000 400000000080000 4000000000C0000 400000000100000 400000000140000 400000000180000 4000000001C0000 400000000200000 400000000240000 . . 400000003E80000 400000003EC0000 400000003F00000 40 0000003F40000 400000003F80000 400000003FC0000 As a result, the second bank is unusable for environment stores (CONFIG_ENV_ADDR is 0x4000000): => saveenv Saving Environment to Flash... Error: start and/or end address not on sector boundary Error: start and/or end address not on sector boundary Failed (1) Rewinding the u-boot repo to before this commit fixes the problem. Manually (uncleanly) reverting the commit and it's dependent commits fixes the problem. Here are the HEAD commits from the relevant repos that I used for the data above: qemu: commit dd5b0f95490883cd8bc7d070db8de70d5c979cbc u-boot: commit 6cb87cbb1475f668689f95911d1521ee6ba7f55c Here is the qemu invocation I used: $ dd if=/dev/zero of=./flash0-with-uboot.img bs=1M count=64 && dd if=/path/to/u-boot.bin of=./flash0-with-uboot.img conv=notrunc $ qemu-system-aarch64 -M virt -cpu cortex-a53 -m 1024M -nographic -drive if=pflash,format=raw,index=0,file=flash0-with-uboot.img -drive if=pflash,format=raw,index=1,file=flash1.img I'm happy to help test any fixes if and as needed. Cheers, Robin

3 9