We had previously gotten this package through a chain of dependencies
with guestfs-tools. Now that we no longer install that package, install
fdisk (for sfdisk) directly.
Fixes: eb1b90ec57 ("Dockerfile: Update to drop virt-make-fs packages")
Signed-off-by: Tom Rini <trini@konsulko.com>
There are some reference platforms from Arm which are not found in QEMU
but instead in the FVP tool. As we can make use of this in CI later on,
download and extract it in our Dockerfile today.
Signed-off-by: Tom Rini <trini@konsulko.com>
Outside of changing versions here the other visible change is that we
tell grub that riscv64 does not have "large model" support. Without this
change the resulting mkimage is non-functional. This is known upstream
already.
Link: https://savannah.gnu.org/bugs/?65909
Signed-off-by: Tom Rini <trini@konsulko.com>
u-boot-dfu-20250410
CI:
- https://source.denx.de/u-boot/custodians/u-boot-dfu/-/pipelines/25615
Usb gadget:
- Add SAM9X60 support to atmel driver
- Fix memory leaks in f_mass_storage gadget driver
- Fix comment typo in dwc3 gadget driver
Fastboot:
- Lift restrictions on !NET_LWIP for USB
Android:
- Fix possible NULL ptr when AVB is out of memory
Recent addition of support for SDM660 inadvertently broke USB PHY power
on sequence on RB1/RB2 and others with following error:
starting USB...
Bus usb@4e00000: QUSB2PHY pll lock failed: status reg = 0
qcom-qusb2-phy phy@1613000: PHY: Failed to power on phy@1613000: -16.
Can't power on PHY0
probe failed, error -16
No USB controllers found
The root cause was the addition of flag se_clk_scheme_default which was
configured correctly for SDM660 but incorrect for all other supported
SoC. Fix that by properly assignment as per upstream Linux driver.
Fixes: 475497dc3c15 ("phy: Add SDM660 support to Qualcomm QUSB2 phy")
Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Reviewed-by:
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20250410080027.208674-3-sumit.garg@kernel.org
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Currently the msm_sdhci doesn't yet support DLL configurations which are
required to enable bus speeds greater that 100MHz. So disable HS200 mode
support as of now as it requires bus speeds of 200MHz.
This should fix eMMC issues reported on RB1/RB2 although it should fix
issues for all Qcom platforms but it's not seen there as mostly SD cards
available don't support HS200 mode. The SD cards usually works in high
speed mode whose performance remains unaffected by this change. It only
affects RB1/RB2 as eMMC flash on these support HS200 mode but the U-Boot
driver currently is incapable of supporting that.
Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>
Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20250410080027.208674-2-sumit.garg@kernel.org
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
On v5 & v7 controllers, multiple mapping for different
Execution Environment exists, if the mapping owner is for
a different Execution Environment we can only read and
not write any data.
To allow us to find a Write mapping for our Execution
Environment, we can overwritte a mapping if we encounter
a new one which we own.
Implement this logic, the result is the same mapping
table as in Linux.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Tested-by: caleb.connolly@linaro.org # sdm845
Link: https://lore.kernel.org/r/20250328-topic-sm8x50-spmi-fix-v1-4-a7548d3aef0d@linaro.org
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Enable fastboot support over USB, using MMC as the backend. This will be
the internal eMMC on devices that have it, or the sdcard slot on devices
with UFS (if available).
We don't use a fixed address for the fastboot buffer because it's
allocated at runtime per-board. Entering fastboot mode should be done by
executing "run fastboot" or manually running:
fastboot -l $fastboot_addr_r usb 0
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20250324-sdm845-fixes-fastboot-v1-4-d177a10f336d@linaro.org
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
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>
Fastboot works either over TCP, UDP or USB. The latter doesn't have
anything to do with networking, thus should work just fine with
regardless which network stack is selected. In practice, header symbols
are used inside common code paths. Add some ifdeffery to guard against
that.
This will make fastboot over USB work with the new LWIP stack.
Signed-off-by: Michael Walle <mwalle@kernel.org>
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Link: https://lore.kernel.org/r/20250312073655.2281377-1-mwalle@kernel.org
Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Currently, this platform is failing in CI due to seemingly platform
specific reasons. For now, remove it from CI until the maintainers have
a chance to look in to it.
Signed-off-by: Tom Rini <trini@konsulko.com>
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 argument parsing in the SPL configuration command uses an implicit
switch/case fallthrough when dealing with a different number of
arguments.
Add our "fallthrough;" statement-like macro before the respective labels
in the bootm 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 argument parsing code in the pmic command uses an implicit switch/case
fallthrough to handle the common part of having one or two arguments.
Add our "fallthrough;" statement-like macro before the second branch in
the parsing 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 raw NAND flash code uses an implicit switch/case fallthrough to
share code when dealing with different ECC modes, and also when handling
some read command.
Add our "fallthrough;" statement-like macro before the respective labels
in the NAND code, to avoid a warning when GCC's -Wimplicit-fallthrough
warning option is enabled.
This copies the fallthrough annotations that the original kernel code
gained, before this function got refactored there.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Michael Trimrachi <michael@amarulasolutions.com>
The SPI NOR code uses an implicit switch/case fallthrough when checking
different vendors to determine how to deal with extended addressig modes.
Add our "fallthrough;" statement-like macro before some label in the
4-byte addressing mode 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 MMC boot mode selection for the TI AM62P series of SoCs uses an
implicit switch/case fallthrough for falling back to some default
boot mode.
Add our "fallthrough;" statement-like macro before the default branch in
the 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 UBI code uses an implicit switch/case fallthrough when handling two
related cases of bad header errors. Also there is a switch/case for unit
prefix handling (G/M/K), which accumulates multiplications.
Add our "fallthrough;" statement-like macro before the respective labels
in both cases, to avoid a warning when GCC's -Wimplicit-fallthrough
warning option is enabled.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
The E1000 driver uses an implicit switch/case fallthrough for sharing
some code supporting different PHYs.
Add our "fallthrough;" statement-like macro before the two labels in
e1000_set_phy_type(), to avoid a warning when GCC's -Wimplicit-fallthrough
warning option is enabled.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
The generic DM video code uses an implicit switch/case fallthrough to
provide fallback code paths when certain colour depths are not enabled.
Add our "fallthrough;" statement-like macro to the video_fill() function
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>
