January 2020 - U-Boot

kwboot : bug when board stops acking
by SC 06 Jan '23

06 Jan '23

Hi list, I think there's a bug in kwboot. I have a faulty board that stops acking xmodem frames after a certain number of packets and kwboot instead of exiting continues to send frames up to 100%. With the one second retry timer it's very long! More than 2 hours :-( The bug is in the kwboot_xm_sendblock() fonction : https://gitlab.denx.de/u-boot/u-boot/blob/master/tools/kwboot.c#L375 kwboot_tty_recv detects the timeout but the return value is based on the last character received (line 403) The variable c is not initialized so if it keeps the previous value which is ACK => rc=0 => infinite loop There are several ways to fix the bug: * Surround the "switch(c)" with a test: if ( !((rc == -1) && (errno == ETIMEDOUT)) ) { rc = -1; switch (c) { case ACK: rc = 0; break; case NAK: errno = EBADMSG; break; case CAN: errno = ECANCELED; break; default: errno = EPROTO; break; } } return rc; * In the case of a TIMEOUT set c to a specific value and add the case in the switch Do you agree with my diagnosis? What is the best solution to fix this bug? Should I provide a patch? Thank you, Stephane

3 2

[U-Boot] [PATCH 1/2] rockchip: rk3399: fix force power on reset
by Vasily Khoruzhick 19 May '22

19 May '22

Currently code doesn't even compile since it uses wrong define for ifdef. Fix that and also add missing include Fixes: 07586ee4322a ("rockchip: rk3399: Support common spl_board_init") Signed-off-by: Vasily Khoruzhick <anarsoul(a)gmail.com> --- arch/arm/mach-rockchip/rk3399/rk3399.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c b/arch/arm/mach-rockchip/rk3399/rk3399.c index 863024d071..eeb99dd11b 100644 --- a/arch/arm/mach-rockchip/rk3399/rk3399.c +++ b/arch/arm/mach-rockchip/rk3399/rk3399.c @@ -11,6 +11,7 @@ #include <asm/io.h> #include <asm/arch-rockchip/bootrom.h> #include <asm/arch-rockchip/clock.h> +#include <asm/arch-rockchip/cru_rk3399.h> #include <asm/arch-rockchip/gpio.h> #include <asm/arch-rockchip/grf_rk3399.h> #include <asm/arch-rockchip/hardware.h> @@ -213,7 +214,7 @@ void spl_perform_fixups(struct spl_image_info *spl_image) "u-boot,spl-boot-device", boot_ofpath); } -#if defined(SPL_GPIO_SUPPORT) +#if defined(CONFIG_SPL_GPIO_SUPPORT) static void rk3399_force_power_on_reset(void) { ofnode node; @@ -239,7 +240,7 @@ static void rk3399_force_power_on_reset(void) void spl_board_init(void) { -#if defined(SPL_GPIO_SUPPORT) +#if defined(CONFIG_SPL_GPIO_SUPPORT) struct rk3399_cru *cru = rockchip_get_cru(); /* -- 2.24.0

5 23

[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

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

[u-boot PATCH] arm: mach-k3: am6_init: Prioritize MSMC traffic over DDR in NAVSS Northbridge
by Roger Quadros 08 Sep '21

08 Sep '21

NB0 is bridge to SRAM and NB1 is bridge to DDR. To ensure that SRAM transfers are not stalled due to delays during DDR refreshes, SRAM traffic should be higher priority (threadmap=2) than DDR traffic (threadmap=0). This patch does just that. This is required to fix ICSSG TX lock-ups due to delays in MSMC transfers due to incorrect Northbridge configuration. Signed-off-by: Roger Quadros <rogerq(a)ti.com> Acked-by: Andrew F. Davis <afd(a)ti.com> Acked-by: Tomi Valkeinen <tomi.valkeinen(a)ti.com> Acked-by: Benoit Parrot <bparrot(a)ti.com> --- arch/arm/mach-k3/am6_init.c | 14 ++++++++++++++ arch/arm/mach-k3/include/mach/am6_hardware.h | 7 +++++++ 2 files changed, 21 insertions(+) diff --git a/arch/arm/mach-k3/am6_init.c b/arch/arm/mach-k3/am6_init.c index 8d107b870b..9379b95bdb 100644 --- a/arch/arm/mach-k3/am6_init.c +++ b/arch/arm/mach-k3/am6_init.c @@ -86,6 +86,18 @@ static void store_boot_index_from_rom(void) bootindex = *(u32 *)(CONFIG_SYS_K3_BOOT_PARAM_TABLE_INDEX); } +static void setup_am654_navss_northbridge(void) +{ + /* + * NB0 is bridge to SRAM and NB1 is bridge to DDR. + * To ensure that SRAM transfers are not stalled due to + * delays during DDR refreshes, SRAM traffic should be higher + * priority (threadmap=2) than DDR traffic (threadmap=0). + */ + writel(0x2, NAVSS0_NBSS_NB0_CFG_BASE + NAVSS_NBSS_THREADMAP); + writel(0x0, NAVSS0_NBSS_NB1_CFG_BASE + NAVSS_NBSS_THREADMAP); +} + void board_init_f(ulong dummy) { #if defined(CONFIG_K3_LOAD_SYSFW) || defined(CONFIG_K3_AM654_DDRSS) @@ -101,6 +113,8 @@ void board_init_f(ulong dummy) /* Make all control module registers accessible */ ctrl_mmr_unlock(); + setup_am654_navss_northbridge(); + #ifdef CONFIG_CPU_V7R disable_linefill_optimization(); setup_k3_mpu_regions(); diff --git a/arch/arm/mach-k3/include/mach/am6_hardware.h b/arch/arm/mach-k3/include/mach/am6_hardware.h index 6df7631545..45a5b31c52 100644 --- a/arch/arm/mach-k3/include/mach/am6_hardware.h +++ b/arch/arm/mach-k3/include/mach/am6_hardware.h @@ -47,4 +47,11 @@ /* MCU SCRATCHPAD usage */ #define TI_SRAM_SCRATCH_BOARD_EEPROM_START CONFIG_SYS_K3_MCU_SCRATCHPAD_BASE +/* NAVSS Northbridge config */ +#define NAVSS0_NBSS_NB0_CFG_BASE 0x03802000 +#define NAVSS0_NBSS_NB1_CFG_BASE 0x03803000 + +#define NAVSS_NBSS_PID 0x0 +#define NAVSS_NBSS_THREADMAP 0x10 + #endif /* __ASM_ARCH_AM6_HARDWARE_H */ -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

4 7

[U-Boot] [PATCH v3 00/20] Bring NAND support to Nintendo NES Classic
by Miquel Raynal 07 Jul '21

07 Jul '21

Hello, This series first adds fixes and enhancements to sunxi NAND drivers (SPL and U-Boot). Once this is done, the SPL NAND driver is converted to use PIO instead of DMA with the goal to support all SoCs with this IP without the need for DMA-related code. Finally, NAND support is added to Nintendo NES Classic through Kconfig and DT additions. Thanks, Miquèl Changes since v2: ================= - Added Boris and Maxime Acked-by tags. - Removed extra space in nand_reset_column() - Fixed the useless wait period on failure in nand_change_column(). - Changed the title "sunxi: allow NAND support to be compiled for..." (removed the "in SPL" precision which is wrong). - Enbraced the deassertion of the reset line by #if statements about the SoCs in use. Wolfgang Denk made a comment on my proposal but I could not find a better solution, so I kept it for now. - s/alwinner,[pin,functions]/[pin,functions]/ in the DT. - Change Alwinner-specific parts in the SPL to generic sentences. Changes since v1: ================= All: ---- - Enhance all commit messages. - Rebased on top of master branch (I should have done that earlier but I forgot I was on an old revision). Fix binman_sym output check --------------------------- - SPL seems to be broken for a few weeks when using raw NAND, fix it by changing the error condition. Fix strength ------------ - Add comment explaining the added line and moved the line for clarification on why it is needed. - Add forgotten Boris' Suggested-by tag. Fix second case of modulo by zero error ---------------------------------------- - Added a reference to the first occurence of this issue. Allow SPL to be compiled for sun8i platforms -------------------------------------------- - This commit is not about compiling the SPL, but the NAND support in the SPL, as corrected by Maxime. Enhancements and cleaning ------------------------- - Patch split into several logical chunks, as requested. - Removed useless udelay(1), that was added for debugging purpose. - Introduced the nand_exec_cmd() helper to mutualize code one step further. - Add an udelay(1) after changing the column to respect the minimum tCCS delay (Change Column Setup time). - Canceled moving to global scope the ecc_strength array. Use PIO instead of DMA ---------------------- - Change commit message/title. - Cancel removing NFC related definitions: they can be useful as the this IP is quite under-documented. - Merge nand_reset_column and nand_change_column (in another patch). - Moved the copy of the data after the check of the ECC status. - ECC chunks are read manually, return if the first chunk is empty only (needed for configuration research), otherwise it should not be treated as an error. Add NAND node to sun8i ---------------------- - U-Boot master branch already has this node, remove the patch. Enable NAND on NES classic -------------------------- - Change the DT cells size from 2 to 1. Add NAND support for NES classic -------------------------------- - Split in several patches, moving SPL_NAND_SUPPORT and NAND_SUNXI out of the defconfig files (NES and CHIP pro) to be automatically selected depending on NAND_SUNXI and ARCH_SUNXI. - Moved the NAND parameters to Kconfig (only for SUNXI because the tool did not work as expected, maybe due to some definitions that are not "numbers" but multiplications and sometimes use other definitions (NAND page size, 2K_SZ, etc). Miquel Raynal (20): spl: fix binman_sym output check mtd: nand: sunxi: fix ECC strength choice spl: nand: sunxi: fix second case of modulo by zero error spl: nand: sunxi: fix typo on register name spl: nand: sunxi: introduce the nand_wait_int() helper spl: nand: sunxi: introduce the nand_wait_cmd_fifo_empty() helper spl: nand: sunxi: add missing status clear spl: nand: sunxi: create an helper to handle command execution spl: nand: sunxi: ensure enough time has passed after changing the column spl: nand: sunxi: make the reset column helper more generic sunxi: spl: deassert the NAND controller reset line spl: nand: sunxi: declare the ecc_bytes array globally spl: nand: sunxi: use PIO instead of DMA sunxi: spl: remove DMA related settings of the NAND controller sunxi: allow NAND support to be compiled for sun8i platforms sunxi: dts: enable NAND on NES classic sunxi: automatically select SPL_NAND_SUPPORT in Kconfig sunxi: make NAND_SUNXI use ARCH_SUNXI as default in Kconfig sunxi: move the NAND parameters to Kconfig configs: add NAND support for NES Classic arch/arm/dts/sun8i-a23-a33.dtsi | 17 ++ .../dts/sun8i-r16-nintendo-nes-classic-edition.dts | 14 ++ arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 6 + board/sunxi/board.c | 7 +- common/spl/spl.c | 10 +- configs/CHIP_pro_defconfig | 6 +- configs/Nintendo_NES_Classic_Edition_defconfig | 4 + drivers/mtd/nand/Kconfig | 26 ++- drivers/mtd/nand/sunxi_nand.c | 8 +- drivers/mtd/nand/sunxi_nand_spl.c | 242 ++++++++++----------- 10 files changed, 208 insertions(+), 132 deletions(-) -- 2.14.1

5 31

imx8qxp mek: Booting mainline kernel with mainline U-Boot
by Fabio Estevam 12 Jun '21

12 Jun '21

Hi Peng, Have you managed to boot a mainline kernel with mainline U-Boot on a imx8qxp mek? Here is what I get: U-Boot SPL 2020.01-00369-ge80a8b0222-dirty (Jan 13 2020 - 12:30:21 -0300) Normal Boot WDT: Not found! Trying to boot from MMC2_2 Load image from MMC/SD 0x46800 U-Boot 2020.01-00369-ge80a8b0222-dirty (Jan 13 2020 - 12:30:21 -0300) CPU: NXP i.MX8QXP RevB A35 at 1200 MHz at 32C Model: Freescale i.MX8QXP MEK Board: iMX8QXP MEK Build: SCFW 550f3079, SECO-FW d7523fe8, ATF 70fa7bc Boot: SD1 DRAM: 3 GiB Failed to enable ipg clk MMC: FSL_SDHC: 0, FSL_SDHC: 1 Loading Environment from MMC... OK In: serial@5a060000 Out: serial@5a060000 Err: serial@5a060000 Net: Failed to enable ipg clk Warning: ethernet@5b040000 (eth0) using random MAC address - e2:9c:db:94:fc:d5 eth0: ethernet@5b040000 Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc1 is current device 26221056 bytes read in 1134 ms (22.1 MiB/s) Booting from mmc ... 13953 bytes read in 14 ms (972.7 KiB/s) ## Flattened Device Tree blob at 83000000 Booting using the fdt blob at 0x83000000 Using Device Tree in place at 0000000083000000, end 0000000083006680 Starting kernel ... [It hangs here] Booting a NXP kernel also did not work. Any ideas? Regards, Fabio Estevam

8 17

[PATCH v1] doc: README.distro: Special case with Windows formatted disk
by Andy Shevchenko 30 Jan '21

30 Jan '21

If someone wants to use shared (by installed OS) eMMC partition to the Windows to boot from, it's not possible due to U-Boot limitations. Describe this case and possible workaround. Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> --- doc/README.distro | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/doc/README.distro b/doc/README.distro index ab6e6f4e74..807a82c910 100644 --- a/doc/README.distro +++ b/doc/README.distro @@ -405,3 +405,23 @@ of the boot environment and are not guaranteed to exist or work in the same way in future u-boot versions. In particular the <device type>_boot variables (e.g. mmc_boot, usb_boot) are a strictly internal implementation detail and must not be used as a public interface. + +Using a eMMC partition that has been formatted as a disk by Windows 10 +====================================================================== + +Let's assume we have an (embedded) board with U-Boot and Linux OS +installed on eMMC. Linux OS shares one of the eMMC partitions as +a disk via USB Mass Storage protocol. + +It may be useful to utilize that disk to copy bootable files from +Windows machine to the board in case someone doesn't want to erase +stock installation on it. + +Unfortunately, Windows 10 doesn't provide knobs and always formats +that disk as a whole, meaning that it creates a partition table on it +with requested (FAT) partition. As a result U-Boot may not see any +files on it due to nesting partition tables. + +The workaround may be in formatting the partition under Linux OS, +setting up a network connection between Linux OS and Windows 10 and +use it to copy files to the partition. -- 2.24.1

5 10

[PATCH v1 1/2] imx: imx8qm_rom7720: added missing USDHC Base address defines
by Oliver Graute 06 Dec '20

06 Dec '20

Added missing USDHC Base address defines Signed-off-by: Oliver Graute <oliver.graute(a)kococonnector.com> Cc: Stefano Babic <sbabic(a)denx.de> Cc: Fabio Estevam <festevam(a)gmail.com> Cc: Peng Fan <peng.fan(a)nxp.com> Cc: Simon Glass <sjg(a)chromium.org> Cc: Ye Li <ye.li(a)nxp.com> Cc: uboot-imx <uboot-imx(a)nxp.com> --- include/configs/imx8qm_rom7720.h | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/include/configs/imx8qm_rom7720.h b/include/configs/imx8qm_rom7720.h index 865863eb7c..8e1427da8a 100644 --- a/include/configs/imx8qm_rom7720.h +++ b/include/configs/imx8qm_rom7720.h @@ -18,6 +18,10 @@ #define CONFIG_FSL_USDHC #define CONFIG_SYS_FSL_ESDHC_ADDR 0 +#define USDHC1_BASE_ADDR 0x5B010000 +#define USDHC2_BASE_ADDR 0x5B020000 +#define USDHC3_BASE_ADDR 0x5B030000 + #define CONFIG_SUPPORT_EMMC_BOOT /* eMMC specific */ #define CONFIG_ENV_OVERWRITE -- 2.17.1

4 6