December 2023 - U-Boot

[PATCH] mtd: spi-nor: Add IS25LP02G flash support
by Venkatesh Yadav Abbarapu 04 Dec '23

04 Dec '23

Add support for ISSI 256MB flash IS25LP02G. This part supports 4byte opcodes. It also supports dual and quad read. Signed-off-by: sreekanth sunnam <sreekanth.sunnam(a)amd.com> Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu(a)amd.com> --- drivers/mtd/spi/spi-nor-ids.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c index 3cb132dcff..9a73198227 100644 --- a/drivers/mtd/spi/spi-nor-ids.c +++ b/drivers/mtd/spi/spi-nor-ids.c @@ -217,6 +217,8 @@ const struct flash_info spi_nor_ids[] = { SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) }, { INFO("is25lp01g", 0x9d601b, 0, 64 * 1024, 2048, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) }, + { INFO("is25lp02g", 0x9d6022, 0, 64 * 1024, 4096, + SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) }, { INFO("is25wp008", 0x9d7014, 0, 64 * 1024, 16, SPI_NOR_QUAD_READ) }, { INFO("is25wp016", 0x9d7015, 0, 64 * 1024, 32, SPI_NOR_QUAD_READ) }, { INFO("is25wp032", 0x9d7016, 0, 64 * 1024, 64, -- 2.17.1

2 1

[PATCH] clk: zynqmp: enable topsw_lsbus clock
by Venkatesh Yadav Abbarapu 04 Dec '23

04 Dec '23

Display port is using topsw_lsbus clock, it is failing while enabling the clock, so enable the topsw_lsbus clock. Signed-off-by: sreekanth sunnam <sreekanth.sunnam(a)amd.com> Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu(a)amd.com> --- drivers/clk/clk_zynqmp.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/clk/clk_zynqmp.c b/drivers/clk/clk_zynqmp.c index 1cfe0e25b1..c059b9e8e6 100644 --- a/drivers/clk/clk_zynqmp.c +++ b/drivers/clk/clk_zynqmp.c @@ -844,6 +844,7 @@ static int zynqmp_clk_enable(struct clk *clk) break; case qspi_ref ... can1_ref: case lpd_lsbus: + case topsw_lsbus: clkact_shift = 24; mask = 0x1; break; -- 2.17.1

2 1

[PATCH 0/5] video: Improve syncing performance with cyclic
by Simon Glass 04 Dec '23

04 Dec '23

Now that U-Boot has a background-processing feature, it is possible to reduce the amount of 'foreground' syncing of the display. At present this happens quite often. Foreground syncing blocks all other processing, sometimes for 10ms or more. When pasting commands into U-Boot over the UART, this typically result in characters being dropped. For example, on rpi_4 it isn't possible to paste in more than 35 characters before things fail. This makes updating the environment or entering long commands very painful over the console, since text must be pasted in chunks, or the vidconsole device must be dropped from stdout. This series introduces background syncing, enabled by default for boards which use video. The sync rates for foreground and background are configurable. With this series it is possible to paste in any amount of text to the command line. Some sandbox-specific work-arounds can now be removed and sandbox video (./u-boot -Dl) is significantly more responsive. This obviously increases code size, since it enables a subsystem not normally used by default. However it only applies to boards which have VIDEO enabled, which are presumably less worried about memory space since the video code is fairly large. Also it is possible to disable CMD_CYCLIC and reduce the groth to: aarch64: (for 1/1 boards) all +1081.0 rodata +65.0 text +1016.0 arm: (for 1/1 boards) all +945.0 rodata +65.0 text +880.0 Without that, the increase doubles. It is of course possible to disable CYCLIC and still use VIDEO but this reverts to the current behaviour Simon Glass (5): cyclic: Disable in SPL builds video: Move last_sync to private data video: Use cyclic to handle video sync sandbox: Increase cyclic CPU-time limit sandbox: Drop video-sync in serial driver common/Kconfig | 1 + common/Makefile | 2 +- drivers/serial/sandbox.c | 2 -- drivers/video/Kconfig | 30 +++++++++++++++++++++ drivers/video/video-uclass.c | 52 +++++++++++++++++++++++++++++------- include/cyclic.h | 6 +++-- include/video.h | 2 ++ 7 files changed, 81 insertions(+), 14 deletions(-) -- 2.43.0.rc0.421.g78406f8d94-goog

3 12

efi: Set Variable Runtime implementation
by Shantur Rathore 04 Dec '23

04 Dec '23

Hi Heinrich, I am trying to work out how to enable the SetVariableRT service in U-Boot and came across your patch [1] which initially had the SetVariable RT service enabled in EFI but in the final patch this was removed. I am hoping to implement it on top of the SPI Flash EFI store [2] to be able to set Boot order and boot items from Linux the UEFI way. Can I pick your brain on why it was dropped in the patch? Is there any limitation in SetVariableRT service ? Kind regards, Shantur [1] : https://patches.linaro.org/project/u-boot/patch/20200331060541.4212-1-xypro… [2] : https://patchwork.ozlabs.org/project/uboot/list/?series=383699

4 13

[PATCH v3 0/3] With this patch series we implement SPI Flash storage for EFI
by Shantur Rathore 04 Dec '23

04 Dec '23

variables. Changes in v3: - Fixed compiler warnings. Changes in v2: - Refactored efi_var_file to move common parts out as requested - Changed ifdefs to use CONFIG_IS_DEFINED - Fixed typos Shantur Rathore (3): efi_var_file: refactor to move buffer functions efi_vars: Implement SPI Flash store defconfig: rockpro64: Enable SF EFI var store configs/rockpro64-rk3399_defconfig | 2 + include/efi_variable.h | 26 +++++++ lib/efi_loader/Kconfig | 25 ++++++ lib/efi_loader/Makefile | 3 +- lib/efi_loader/efi_var_common.c | 109 ++++++++++++++++++++++++++ lib/efi_loader/efi_var_file.c | 121 ----------------------------- lib/efi_loader/efi_var_sf.c | 91 ++++++++++++++++++++++ lib/efi_loader/efi_variable.c | 17 +++- 8 files changed, 270 insertions(+), 124 deletions(-) create mode 100644 lib/efi_loader/efi_var_sf.c -- 2.40.1

4 11

[PATCH 0/3] sunxi: add OrangePi Zero 3 board support
by Andre Przywara 04 Dec '23

04 Dec '23

The OrangePi Zero 3 is a small development board featuring the Allwinner H618 SoC. Compared to its predecessor OrangePi Zero 2, the new board uses LPDDR4 DRAM instead of DDR3 DRAM, and an X-Powers AXP313 PMIC instead of the AXP305. U-Boot gained support for both LPDDR4 DRAM and the new PMIC just recently, so add a user for those features by adding a defconfig for the new board. To make this work, patch 1/3 introduces support for zBIT SPI NOR flash chip, and patch 2/3 removes the default AXP305 PMIC selection when compiling for H616 SoCs. Patch 3/3 then adds the defconfig. The DT was already synced from the Linux kernel repo a few weeks ago. Cheers, Andre Andre Przywara (3): mtd: spi-nor: Add support for zBIT ZB25VQ128 sunxi: H616: remove default AXP305 selection sunxi: H616: Add OrangePi Zero 3 board support arch/arm/dts/Makefile | 1 + board/sunxi/MAINTAINERS | 5 +++++ configs/orangepi_zero2_defconfig | 1 + configs/orangepi_zero3_defconfig | 30 ++++++++++++++++++++++++++++++ configs/x96_mate_defconfig | 1 + drivers/mtd/spi/Kconfig | 5 +++++ drivers/mtd/spi/spi-nor-ids.c | 5 +++++ drivers/power/Kconfig | 1 - 8 files changed, 48 insertions(+), 1 deletion(-) create mode 100644 configs/orangepi_zero3_defconfig -- 2.35.8

6 26

[PULL] u-boot-sh/master-rpc-off
by Marek Vasut 03 Dec '23

03 Dec '23

The following changes since commit 43f2873fa98b1da6eb56d756315c7bd7db63db27: MAINTAINERS: Step up as co-maintainer of Tegra SOC platform (2023-11-28 11:23:02 -0500) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-sh.git master-rpc-off for you to fetch changes up to 13bdb6a269108d3f9b953bf4b73079d66ecc37af: ARM: dts: renesas: Disable RPC driver on R8A779G0 V4H White Hawk board (2023-12-02 17:16:01 +0100) ---------------------------------------------------------------- Cong Dang (1): ARM: dts: renesas: Disable RPC driver on R8A779G0 V4H White Hawk board Marek Vasut (1): ARM: dts: renesas: Clean up R8A779G0 V4H RPC SPI DT node arch/arm/dts/r8a779g0-u-boot.dtsi | 18 ++++-------------- arch/arm/dts/r8a779g0-white-hawk-u-boot.dts | 2 +- 2 files changed, 5 insertions(+), 15 deletions(-)

2 1

[PULL] u-boot-usb/master
by Marek Vasut 03 Dec '23

03 Dec '23

The following changes since commit 43f2873fa98b1da6eb56d756315c7bd7db63db27: MAINTAINERS: Step up as co-maintainer of Tegra SOC platform (2023-11-28 11:23:02 -0500) are available in the Git repository at: git://source.denx.de/u-boot-usb.git master for you to fetch changes up to 493e0e2577bfe11b3065a30a6f5c827f95c1df94: usb: USB_XHCI_PCI depends on PCI (2023-12-01 16:01:59 +0100) ---------------------------------------------------------------- Hector Martin (9): usb: xhci: Guard all calls to xhci_wait_for_event usb: xhci: Better error handling in abort_td() usb: xhci: Allow context state errors when halting an endpoint usb: xhci: Recover from halted bulk endpoints usb: xhci: Fail on attempt to queue TRBs to a halted endpoint usb: xhci: Do not panic on event timeouts usb: xhci: Fix DMA address calculation in queue_trb usb: hub: Add missing reset recovery delay usb: storage: Use the correct CBW lengths Heinrich Schuchardt (1): usb: USB_XHCI_PCI depends on PCI Jonas Karlman (1): usb: dwc3-generic: Use combined glue and ctrl node for RK3588 common/usb_hub.c | 7 ++++ common/usb_storage.c | 22 ++++++++----- drivers/usb/dwc3/dwc3-generic.c | 1 + drivers/usb/host/Kconfig | 2 +- drivers/usb/host/xhci-ring.c | 72 ++++++++++++++++++++++++++++++++--------- drivers/usb/host/xhci.c | 9 ++++++ include/usb/xhci.h | 2 ++ 7 files changed, 90 insertions(+), 25 deletions(-)

2 1

[PATCH] usb: xhci: Replace terrible formatting with different terrible formatting
by Marek Vasut 03 Dec '23

03 Dec '23

Replace one type of terrible code formatting with a different type of terrible code formatting. No functional change. Signed-off-by: Marek Vasut <marex(a)denx.de> --- Cc: Bin Meng <bmeng.cn(a)gmail.com> Cc: Hector Martin <marcan(a)marcan.st> --- drivers/usb/host/xhci-ring.c | 18 +++++++----------- 1 file changed, 7 insertions(+), 11 deletions(-) diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index dabe6cf86af..be3e35102d6 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -543,9 +543,8 @@ static void reset_ep(struct usb_device *udev, int ep_index) if (!event) return; - BUG_ON(TRB_TO_SLOT_ID(le32_to_cpu(event->event_cmd.flags)) - != udev->slot_id || GET_COMP_CODE(le32_to_cpu( - event->event_cmd.status)) != COMP_SUCCESS); + BUG_ON(TRB_TO_SLOT_ID(le32_to_cpu(event->event_cmd.flags)) != udev->slot_id || + GET_COMP_CODE(le32_to_cpu(event->event_cmd.status)) != COMP_SUCCESS); xhci_acknowledge_event(ctrl); } @@ -578,8 +577,7 @@ static void abort_td(struct usb_device *udev, int ep_index) field = le32_to_cpu(event->trans_event.flags); BUG_ON(TRB_TO_SLOT_ID(field) != udev->slot_id); BUG_ON(TRB_TO_EP_INDEX(field) != ep_index); - BUG_ON(GET_COMP_CODE(le32_to_cpu(event->trans_event.transfer_len - != COMP_STOP))); + BUG_ON(GET_COMP_CODE(le32_to_cpu(event->trans_event.transfer_len != COMP_STOP))); xhci_acknowledge_event(ctrl); event = xhci_wait_for_event(ctrl, TRB_COMPLETION); @@ -593,9 +591,8 @@ static void abort_td(struct usb_device *udev, int ep_index) comp = GET_COMP_CODE(le32_to_cpu(event->event_cmd.status)); BUG_ON(type != TRB_COMPLETION || - TRB_TO_SLOT_ID(le32_to_cpu(event->event_cmd.flags)) - != udev->slot_id || (comp != COMP_SUCCESS && comp - != COMP_CTX_STATE)); + TRB_TO_SLOT_ID(le32_to_cpu(event->event_cmd.flags)) != udev->slot_id || + (comp != COMP_SUCCESS && comp != COMP_CTX_STATE)); xhci_acknowledge_event(ctrl); addr = xhci_trb_virt_to_dma(ring->enq_seg, @@ -605,9 +602,8 @@ static void abort_td(struct usb_device *udev, int ep_index) if (!event) return; - BUG_ON(TRB_TO_SLOT_ID(le32_to_cpu(event->event_cmd.flags)) - != udev->slot_id || GET_COMP_CODE(le32_to_cpu( - event->event_cmd.status)) != COMP_SUCCESS); + BUG_ON(TRB_TO_SLOT_ID(le32_to_cpu(event->event_cmd.flags)) != udev->slot_id || + GET_COMP_CODE(le32_to_cpu(event->event_cmd.status)) != COMP_SUCCESS); xhci_acknowledge_event(ctrl); } -- 2.42.0

2 2

rk3328 gmac does U-Boot erroneously not set RSF?
by ubroot37 03 Dec '23

03 Dec '23

Hi all, I suspect U-Boot is not setting the RSF bit in GMAC_OP_MODE register. This can result in allowing to receive frames with bad CRC. I suspect the Linux driver may be similarly affected, but I have not checked it out. Unfortunately all my spare time is taken up by development on my own OS, so I do not have the time to investigate fully and/or provide a patch. I am just reporting this potential issue as a good Samaritan, but please understand that I am not willing to apply any patches or recompile U-Boot or conduct any tests or anything of that nature. Thanks all.

1 0