Tom Rini <trini@konsulko.com> says:
This series switches to always using $(PHASE_) in Makefiles when
building rather than $(PHASE_) or $(XPL_). It also starts on documenting
this part of the build, but as a follow-up we need to rename
doc/develop/spl.rst and expand on explaining things a bit.
Link: https://lore.kernel.org/r/20250401225851.1125678-1-trini@konsulko.com
It is confusing to have both "$(PHASE_)" and "$(XPL_)" be used in our
Makefiles as part of the macros to determine when to do something in our
Makefiles based on what phase of the build we are in. For consistency,
bring this down to a single macro and use "$(PHASE_)" only.
Signed-off-by: Tom Rini <trini@konsulko.com>
In fsg_common_init, we allocate some buffers via memalign().
However, these buffers are never freed.
Because of that, we cannot call => ums command multiple times on boards
with low memory (CONFIG_SYS_MALLOC_LEN=0x81000):
=> ums 0 mmc 2
UMS: LUN 0, dev mmc 2, hwpart 0, sector 0x0, count 0x3a3e000
|crq->brequest:0x0
CTRL+C - Operation aborted
=> ums 0 mmc 2
UMS: LUN 0, dev mmc 2, hwpart 0, sector 0x0, count 0x3a3e000
failed to start <NULL>: -12
g_dnl_register: failed!, error: -12
g_dnl_register failed
Make sure the fsg buffers are freed when the gadget is unbound by
calling fsg_common_release() in fsg_unbind().
Reported-by: Zixun LI <admin@hifiphile.com>
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Zixun LI <admin@hifiphile.com> # on SAM9X60
Link: https://lore.kernel.org/r/20250328-ums-gadget-leak-v1-4-3b677db99bde@baylibre.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Andre Przywara <andre.przywara@arm.com> says:
C's implicit fallthrough behaviour in switch/case statements can lead to
subtle bugs. Quite some while ago many compilers introduced warnings in
those cases, requiring intentional fallthrough's to be annotated.
So far we were not enabling that compiler option, so many ambiguities
and some bugs in the code went unnoticed.
This series adds the required annotations in code paths that the first
stage of the U-Boot CI covers. There is a large number of cases left
in the libbz2 code. The usage of switch/case is borderline insane there,
labels are hidden in macros, and there are no breaks, but just goto's.
Upstream still uses very similar code, without any annotations. I still
am not 100% sure those are meant to fall through or not, and plan to do
further investigations, but didn't want to hold the rest of the patches
back. You can see for yourself by applying patch 18/18 and building for
sandbox64, for instance.
Because of this we cannot quite enable the warning in the Makefile yet,
but those fixes are worth regardless, and be it to increase readability.
Please note that those patches do not fix anything, really, they just add
those fallthrough annotations, so the series is not really critical.
Link: https://lore.kernel.org/r/20250327153313.2105227-1-andre.przywara@arm.com
The USB XHCI code uses an implicit switch/case fallthrough to share code
for handling full speed and low speed transfers.
Add our "fallthrough;" statement-like macro before the second label in
the XHCI code, to avoid a warning when GCC's -Wimplicit-fallthrough
warning option is enabled.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
The USB OCHI code uses an implicit switch/case fallthrough after checking
for valid descriptor IDs.
Add our "fallthrough;" statement-like macro before the default branch in
the OHCI code, to avoid a warning when GCC's -Wimplicit-fallthrough
warning option is enabled.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Even though we seem to catch POWEROFF and EFSCLEAR commands in the THOR
protocol request handling, we ultimately do not seem to handle them
(apart from sending a response), so those commands still print an error
message.
Annotate the switch/case fallthrough in this case, to make this clear to
the compiler.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Simon Glass <sjg@chromium.org> says:
The membuff implementation curently has no tests. It also assumes that
head and tail can never correspond unless the buffer is empty.
This series provides a compile-time flag to support a 'full' flag. It
also adds some tests of the main routines.
The data structure is also renamed to membuf which fits better with
U-Boot.
There may be some cases in the code which could be optimised a little,
but the implementation is functional.
Link: https://lore.kernel.org/r/20250318152059.1464369-1-sjg@chromium.org
The double 'f' is not necessary and is a bit annoying as elsewhere in
U-Boot we use 'buf'. Rename all the functions before it is used more
widely.
Signed-off-by: Simon Glass <sjg@chromium.org>
The UUU tool excepts the interrupt-in endpoint to be ep1in, otherwise
it crashes. This is a result of the previous hard-coded EP setup in
drivers/usb/gadget/epautoconf.c which did special-case EP allocation
for SPL builds, and which was since converted to this callback, but
without the special-case EP allocation in SPL part.
This reinstates the SPL part in an isolated manner, only for NXP iMX
SoCs, only for SPL builds, and only for the ep1in interrupt-in endpoint.
Fixes: 1918b8010c ("usb: dwc3: gadget: Convert epautoconf workaround to match_ep callback")
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Link: https://lore.kernel.org/r/20250319220805.219001-1-marex@denx.de
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Cdns core driver also get dr mode from wrapper devcie dts node
to make it is same with Starfive cdns USB Linux kernel driver,
Starfive 7110 OF_UPSTREAM is enabled
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
Reviewed-by: Marek Vasut <marex@denx.de>
USB PHY maybe need to set PHY mode in different USB
dr mode. So translate USB PHY mode to generic PHY mode
and call generic_phy_set_mode().
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Greg Malysa <malysagreg@gmail.com> says:
This series adds all of the supported peripheral drivers for the sc5xx
series of SoCs from Analog Devices and other drivers that are used by
the evaluation kits, such as a GPIO expander used by the EZLITE carrier
boards. This series passes gitlab CI tests.
Link: https://lore.kernel.org/r/20250226173150.13198-1-malysagreg@gmail.com
The BLK symbol has a few meanings, one of which is that it controls the
driver model portion of a "block device". Rather than having this hidden
symbol be "default y if ..." it should be select'd by the various block
subsystems. Symbols such as PVBLOCK which already select'd BLK are
unchanged".
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Tom Rini <trini@konsulko.com>
i.MX95 uses the same USB IP as i.MX8MM. It can then reuse the ehci-mx6
driver.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
With the commit 4fcba5d556 ("regulator: implement basic reference
counter") the return value of regulator_set_enable may be EALREADY or
EBUSY for fixed/gpio regulators.
Change to use the more relaxed regulator_set_enable_if_allowed to
continue if regulator already was enabled or disabled.
Based on 335799b725 ("usb: dwc2: Use regulator_set_enable_if_allowed")
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
With the commit 4fcba5d556 ("regulator: implement basic reference
counter") the return value of regulator_set_enable may be EALREADY or
EBUSY for fixed/gpio regulators.
Change to use the more relaxed regulator_set_enable_if_allowed to
continue if regulator already was enabled or disabled.
Based on 335799b725 ("usb: dwc2: Use regulator_set_enable_if_allowed")
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Siddharth Vadapalli <s-vadapalli@ti.com> says:
Hello,
This series adds support for USB DFU boot on TI's AM62A SoC which has
two instances of DWC3 USB Controllers namely USB0 and USB1. The USB0
instance of the USB Controller supports USB DFU boot:
ROM => tiboot3.bin => tispl.bin => u-boot.img
USB DFU Boot requires the USB Controller to be configured for Gadget
mode of operation. Since the USB0 instance of the DWC3 USB Controller
supports both Host and Gadget modes of operation via the Type-C interface
on the AM62A7-SK board, the device-tree specifies the "dr_mode" as "OTG".
However, there is currently no support for dynamically switching the "mode"
from Host to Gadget and vice-versa with the help of a state-machine.
The OTG mode is treated as a separate mode in itself rather than being
treated as an intermediate stage before assuming the Host/Gadget mode.
Due to this, USB DFU boot via the Type-C interface doesn't work as the
USB Controller hasn't been appropriately configured for Device/Gadget
mode of operation. One option is to change the device-tree to specify
"dr_mode" as "peripheral" and force the controller to assume the Device
role. This will imply that the U-Boot device-tree for AM62A diverges
from its Linux counterpart. Therefore, with the intent of keeping the
device-tree uniform across Linux and U-Boot, and at the same time, in
order to enable USB DFU boot in "OTG" mode with the DWC3 Controller,
the first patch in this series sets the "mode" on the basis of the
caller function, rather than using the "dr_mode" property in the
device-tree. There are only two callers of "dwc3_generic_probe()",
each of which clearly specify the expected mode of configuration.
This will enable both Host and Device mode of operation based on the
command executed by the user, thereby truly supporting "OTG"
functionality when the USB Controller supports it.
The second patch in this series adds USB DFU environment for AM62A,
enabling USB DFU Boot and USB DFU flash on AM62A.
In addition to the patches in this series, the following device-tree
changes will be required to test USB DFU on AM62A (bootph-all property
to be added to ensure that USB Controller is present at all stages
for DFU Boot):
https://gist.github.com/Siddharth-Vadapalli-at-TI/53ba02cb0ff4a09c47e920d08247065f
The above device-tree changes will be made to the Linux device-tree,
which shall ensure that the same shall be a part of U-Boot device-tree
eventually.
The USB DFU config fragments for AM62x have been used for enabling
USB DFU boot on AM62a as follows:
R5 => am62ax_evm_r5_defconfig + am62x_r5_usbdfu.config
A53 => am62ax_evm_a53_defconfig + am62x_a53_usbdfu.config
Logs validating USB DFU boot with this series:
https://gist.github.com/Siddharth-Vadapalli-at-TI/daa71da1b0e478a51afea42605fb2d2c
Link: https://lore.kernel.org/r/20241126120322.1760862-1-s-vadapalli@ti.com
There are only two callers of "dwc3_generic_probe()", namely:
1. dwc3_generic_peripheral_probe()
2. dwc3_generic_host_probe()
Currently, the "mode" is set based on the device-tree node of the
platform device. Also, the DWC3 core doesn't support updating the "mode"
dynamically at runtime if it is set to "OTG", i.e. "OTG" is treated as a
separate mode in itself, rather than being treated as a mode which should
eventually lead to "host"/"peripheral".
Given that the callers of "dwc3_generic_probe()" clarify the expected
"mode" of the USB Controller, use that "mode" instead of the one
specified in the device-tree. This shall allow the USB Controller to
function both as a "Host" and as a "Peripheral" when the "mode" is "otg"
in the device-tree, based on the caller of "dwc3_generic_probe()".
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
The correct spelling is R-Car, including the dash, update the usage.
Kconfig strings and comment changes only, no functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The ASIX 88179A drops packets when receiving fragmented packets larger
than the MTU size due to an insufficient URB buffer size. This change
synchronizes the URB buffer size with the configuration used in the
Linux kernel, resolving the packet drop issue.
To reproduce the issue, set the following configuration:
CONFIG_IP_DEFRAG=y
CONFIG_TFTP_BLOCKSIZE=16352
Then, run the `tftp` command. It will fail with a timeout error:
U-Boot> tftp zero.bin
Using ax88179_eth device
TFTP from server 10.0.0.196; our IP address is 10.0.0.18
Filename 'zero.bin'
Load address: 0x10000000
Loading: T T T T T T T T T T T
Retry count exceeded; starting again
Signed-off-by: Khoa Hoang <admin@khoahoang.com>
Reviewed-by: Marek Vasut <marex@denx.de>
The ASIX AX88179A locks up when the ADVERTISE_NPAGE bit is set in the
MII_ADVERTISE register, suggesting that this feature may be broken or
unsupported on this chip. In the Linux kernel, this bit is not set,
and enabling it also causes the PHY to lock up and stay in a
link-down state.
Additionally, the AX88179 and AX88179A variants do not appear to
support the ADVERTISE_LPACK bit, as setting it consistently reads
back as 0.
This patch removes the ADVERTISE_NPAGE and ADVERTISE_LPACK bits from
the MII_ADVERTISE register configuration. It also resets the PHY
before modifying the MII_ADVERTISE register, then restarts
auto-negotiation, following the same flow used in the U-Boot asix.c
driver.
Signed-off-by: Khoa Hoang <admin@khoahoang.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Patrick Rudolph <patrick.rudolph@9elements.com> 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
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 <patrick.rudolph@9elements.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Cc: Tom Rini <trini@konsulko.com>
Cc: Marek Vasut <marex@denx.de>
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 <dave.wang@rock-chips.com>
Signed-off-by: Wang Jie <dave.wang@rock-chips.com>
Tested-by: Soeren Moch <smoch@web.de>
Tested-by: Anand Moon <linux.amoon@gmail.com>
Reviewed-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <dave.wang@rock-chips.com>
Signed-off-by: Wang Jie <dave.wang@rock-chips.com>
Tested-by: Soeren Moch <smoch@web.de>
Tested-by: Anand Moon <linux.amoon@gmail.com>
Reviewed-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <jerome.forissier@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
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 <godmwan@microsoft.com>
Reviewed-by: Marek Vasut <marex@denx.de>
