u-boot.git/drivers/usb, branch v2025.01-rc2

Merge patch series "Implement ACPI on aarch64"

2024-10-28T00:44:13Z

Patrick Rudolph says: Based on the existing work done by Simon Glass this series adds support for booting aarch64 devices using ACPI only. As first target QEMU SBSA support is added, which relies on ACPI only to boot an OS. As secondary target the Raspberry Pi4 was used, which is broadly available and allows easy testing of the proposed solution. The series is split into ACPI cleanups and code movements, adding Arm specific ACPI tables and finally SoC and mainboard related changes to boot a Linux on the QEMU SBSA and RPi4. Currently only the mandatory ACPI tables are supported, allowing to boot into Linux without errors. The QEMU SBSA support is feature complete and provides the same functionality as the EDK2 implementation. The changes were tested on real hardware as well on QEMU v9.0: qemu-system-aarch64 -machine sbsa-ref -nographic -cpu cortex-a57 \ -pflash secure-world.rom \ -pflash unsecure-world.rom qemu-system-aarch64 -machine raspi4b -kernel u-boot.bin -cpu cortex-a72 \ -smp 4 -m 2G -drive file=raspbian.img,format=raw,index=0 \ -dtb bcm2711-rpi-4-b.dtb -nographic Tested against FWTS V24.03.00. Known issues: - The QEMU rpi4 support is currently limited as it doesn't emulate PCI, USB or ethernet devices! - The SMP bringup doesn't work on RPi4, but works in QEMU (Possibly cache related). - PCI on RPI4 isn't working on real hardware since the pcie_brcmstb Linux kernel module doesn't support ACPI yet. Link: https://lore.kernel.org/r/20241023132116.970117-1-patrick.rudolph@9elements.com

drivers: usb: Add generic XHCI

2024-10-27T23:24:13Z

Add support for the generic XHCI driver that contains no SoC specific code. It can be used on platforms that simply work out of the box, like on emulated platforms. TEST: Booted on QEMU sbsa machine using the generic xhci driver. Signed-off-by: Patrick Rudolph Reviewed-by: Marek Vasut Cc: Tom Rini Cc: Marek Vasut

Merge tag 'u-boot-dfu-20241017' of https://source.denx.de/u-boot/custodians/u-boot-dfu

2024-10-17T14:34:01Z

u-boot-dfu-20241017 CI: https://source.denx.de/u-boot/custodians/u-boot-dfu/-/pipelines/22742 Usb Gadget: - Fix cdns3 endpoint configuration by setting maxpacket - Fix dwc3 cache handling when using DMA Fastboot: - Make AVB_VERIFY depends on FASTBOOT

usb: tcpm: fusb302: add driver

2024-10-17T01:12:47Z

Now that the TCPM framework exists we can introduce fusb302 driver using it. This chip is a very common USB-C controller chip with PD support, which can be found in the Radxa Rock 5B among many other boards. Apart from Power Delivery, it also handles detection of the cable orientation. That can be used to control a mux for connecting the right USB3 lane pair to the USB3 controller. The driver is originally from the Linux kernel, but has been adapted to the requirements of U-Boot and its TCPM framework. Co-developed-by: Wang Jie Signed-off-by: Wang Jie Tested-by: Soeren Moch Tested-by: Anand Moon Reviewed-by: Jonas Karlman Signed-off-by: Sebastian Reichel

usb: tcpm: add core framework

2024-10-17T01:12:47Z

This adds TCPM framework in preparation for fusb302 support, which can handle USB power delivery messages. This is needed to solve issues with devices, that are running from a USB-C port supporting USB-PD, but not having a battery. Such a device currently boots to the kernel without interacting with the power-supply at all. If there are no USB-PD message replies within 5 seconds, the power-supply assumes the peripheral is not capable of USB-PD. It usually takes more than 5 seconds for the system to reach the kernel and probe the I2C based fusb302 chip driver. Thus the system always runs into this state. The power-supply's solution to fix this error state is a hard reset, which involves removing the power from VBUS. Boards without a battery (or huge capacitors) will reset at this point resulting in a boot loop. This imports the TCPM framework from the kernel. The porting has originally been done by Rockchip using hardware timers and the Linux kernel's TCPM code from some years ago. I had a look at upgrading to the latest TCPM kernel code, but that beast became a lot more complex due to adding more USB-C features. I believe these features are not needed in U-Boot and with multiple kthreads and hrtimers being involved it is non-trivial to port them. Instead I worked on stripping down features from the Rockchip port to an even more basic level. Also the TCPM code has been reworked to avoid complete use of any timers (Rockchip used SoC specific hardware timers + IRQ to implement delayed work mechanism). Instead the delayed state changes are handled directly from the poll loop. Note, that (in contrast to the original Rockchip port) the state machine has the same hard reset quirk, that the kernel has - i.e. it avoids disabling the CC pin resistors for devices that are not self-powered. Without that quirk, the Radxa Rock 5B will not just end up doing a machine reset when a hard reset is triggered, but will not even recover, because the CPU will loose power and the FUSB302 will keep this state because of leak voltage arriving through the RX serial pin (assuming a serial adapter is connected). This also includes a 'tcpm' command, which can be used to get information about the current state and the negotiated voltage and current. Co-developed-by: Wang Jie Signed-off-by: Wang Jie Tested-by: Soeren Moch Tested-by: Anand Moon Reviewed-by: Jonas Karlman Signed-off-by: Sebastian Reichel

net: introduce alternative implementation as net/lwip/

2024-10-16T17:11:56Z

Prepare the introduction of the lwIP (lightweight IP) TCP/IP stack by adding a new net/lwip/ directory and the NET_LWIP symbol. Network support is either NO_NET, NET (legacy stack) or NET_LWIP. Subsequent commits will introduce the lwIP code, re-work the NETDEVICE integration and port some of the NET commands and features to lwIP. SPL_NET cannot be enabled when NET_LWIP=y. SPL_NET pulls some symbols that are part of NET (such as arp_init(), arp_timeout_check(), arp_receive(), net_arp_wait_packet_ip()). lwIP support in SPL may be added later. Similarly, DFU_TFTP and FASTBOOT are not compatible with NET_LWIP because of dependencies on net_loop(), tftp_timeout_ms, tftp_timeout_count_max and other NET things. Let's add a dependency on !NET_LWIP for now. SANDBOX can select NET_LWIP but doing so will currently disable the eth dm tests as well as the wget tests which have strong dependencies on the NET code. Other adjustments to Kconfig files are made to fix "unmet direct dependencies detected" for USB_FUNCTION_SDP and CMD_FASTBOOT when the default networking stack is set to NET_LWIP ("default NET_LWIP" instead of "default NET" in Kconfig). The networking stack is now a choice between NO_NET, NET and NET_LWIP. Therefore '# CONFIG_NET is not set' should be 'CONFIG_NO_NET=y'. Adjust the defconfigs accordingly. Signed-off-by: Jerome Forissier Acked-by: Ilias Apalodimas

usb: dwc3: invalidate dcache on buffer used in interrupt handling

2024-10-15T09:03:57Z

On Qualcomm systems, the setup buffer and even buffers are in a bad state at interrupt handling, so invalidate the dcache lines for the setup_buf and event buffer to make sure we read correct data written by the hardware. This fixes the following error: dwc3-generic-peripheral usb@a600000: UNKNOWN IRQ type -1 dwc3-generic-peripheral usb@a600000: UNKNOWN IRQ type 4673109 and invalid situation in dwc3_gadget_giveback() because setup_buf content is read at 0s and leads to fatal crash fixed by [1]. [1] https://lore.kernel.org/all/20240528-topic-sm8x50-dwc3-gadget-crash-fix-v1-1-58434ab4b3d3@linaro.org/ Reviewed-by: Mattijs Korpershoek Signed-off-by: Neil Armstrong Reviewed-by: Marek Vasut Link: https://lore.kernel.org/r/20241011-u-boot-dwc3-gadget-dcache-fixup-v4-3-5f3498d8035b@linaro.org Signed-off-by: Mattijs Korpershoek

usb: dwc3: fix dcache flush range calculation

2024-10-15T09:03:57Z

The current flush operation will omit doing a flush/invalidate on the first and last bytes if the base address and size are not aligned with CACHELINE_SIZE. This causes operation failures Qualcomm platforms. Take in account the alignment and size of the buffer and also flush the previous and last cacheline. Reviewed-by: Mattijs Korpershoek Signed-off-by: Neil Armstrong Reviewed-by: Marek Vasut Link: https://lore.kernel.org/r/20241011-u-boot-dwc3-gadget-dcache-fixup-v4-2-5f3498d8035b@linaro.org Signed-off-by: Mattijs Korpershoek

usb: dwc3: allocate setup_buf with dma_alloc_coherent()

2024-10-15T09:03:56Z

Since setup_buf is also consumed by hardware DMA, aligns it's allocation like other hardware buffers by introduce setup_buf_addr populated by dma_alloc_coherent(), and use it to pass the physical address of the buffer to the hardware. Reviewed-by: Mattijs Korpershoek Reviewed-by: Marek Vasut Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20241011-u-boot-dwc3-gadget-dcache-fixup-v4-1-5f3498d8035b@linaro.org Signed-off-by: Mattijs Korpershoek

usb: xhci: pet watchdog during transfers

2024-10-14T20:17:17Z

On some platforms with low USB throughput, tranfers of huge files take a long time and watchdog timer can expire resulting in hardware reset. Avoid this by petting the watchdog as long as we have pending transfers. Signed-off-by: Godfrey Mwangi Reviewed-by: Marek Vasut