Marek Vasut [Thu, 28 Nov 2024 04:11:19 +0000 (05:11 +0100)]
arm64: renesas: Disable AVB1 and AVB2 on R8A779G0 V4H White Hawk board
The U-Boot is currently not capable of handling ethernet-phy-ieee802.3-c45
PHYs correctly, and also does not handle MDIO bus wide reset-gpios property.
Until proper C45 PHY support lands in U-Boot, disable AVB1/AVB2 interfaces.
This only disables the two MACs with 88Q2110/88Q2112 100/1000BASE-T1 PHYs
on ethenet sub-board, the main board AVB0 ethernet is unaffected.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Paul Barker [Wed, 20 Nov 2024 09:48:29 +0000 (09:48 +0000)]
pinctrl: rzg2l: Support Ethernet TXC output enable
On the RZ/G2L SoC family, the direction of the Ethernet TXC/TX_CLK
signal is selectable to support an Ethernet PHY operating in either MII
or RGMII mode. By default, the signal is configured as an input and MII
mode is supported. The ETH_MODE register can be modified to configure
this signal as an output to support RGMII mode.
As this signal is be default an input, and can optionally be switched to
an output, it maps neatly onto an `output-enable` property in the device
tree.
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Paul Barker [Wed, 20 Nov 2024 09:48:28 +0000 (09:48 +0000)]
pinctrl: rzg2l: Support 2.5V PVDD for Ethernet interfaces
The Ethenet interfaces on the Renesas RZ/G2L SoC family can operate at
multiple power supply voltages: 3.3V (default value), 2.5V and 1.8V.
rzg2l_pinconf_set() is extended to support the 2.5V setting, with a
check to ensure this is only used on Ethernet interfaces as it is not
supported on the SD & QSPI interfaces.
While we're modifying rzg2l_pinconf_set(), drop the unnecessary default
value for pwr_reg as it is set in every branch of the following if
condition.
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Paul Barker [Tue, 19 Nov 2024 19:36:26 +0000 (19:36 +0000)]
clk: rzg2l: Ignore enable for core clocks
In the RZ/G2L family, core clocks are always on and can't be disabled.
However, drivers which are shared with other SoCs may call clk_enable()
or clk_enable_bulk() for a clock referenced in the device tree which
happens to be a core clock on the RZ/G2L. To avoid the need for
conditionals in these drivers, simply ignore attempts to enable a core
clock.
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
When MbedTLS TLS features were added MBEDTLS_HAVE_TIME was defined as part
of enabling https:// support. However that pointed to the wrong function
which could crash if it received a NULL pointer.
Looking closer that function is not really needed, as it only seems to
increase the RNG entropy by using 4b of the current time and date.
The reason that was enabled is that lwIP was unconditionally requiring it,
although it's configurable and can be turned off.
Since lwIP doesn't use that field anywhere else, make it conditional and
disable it from our config.
Vincent Stehlé [Fri, 6 Dec 2024 07:58:53 +0000 (08:58 +0100)]
arm: qemu: fix update_info declaration
Add a missing comma in the update_info structure declaration.
This fixes the following build error when building with
EFI_RUNTIME_UPDATE_CAPSULE or EFI_CAPSULE_ON_DISK:
board/emulation/qemu-arm/qemu-arm.c:52:9: error: request for member ‘images’ in something not a structure or union
Fixes: cccea18813c4 ("efi_loader: add the number of image entries in efi_capsule_update_info") Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com> Cc: Masahisa Kojima <masahisa.kojima@linaro.org> Cc: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi> Cc: Tom Rini <trini@konsulko.com>
Sughosh Ganu [Mon, 2 Dec 2024 07:06:24 +0000 (12:36 +0530)]
lmb: prohibit allocations above ram_top even from same bank
There are platforms which set the value of ram_top based on certain
restrictions that the platform might have in accessing memory above
ram_top, even when the memory region is in the same DRAM bank. So,
even though the LMB allocator works as expected, when trying to
allocate memory above ram_top, prohibit this by marking all memory
above ram_top as reserved, even if the said memory region is from the
same bank.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Tested-by: Andreas Schwab <schwab@suse.de>
Two fixes for the EFI subsystem coming via the TPM tree as agreed by Heinrich
The LMB patch fixes a failure in SystemReady testing. Nothing bad happens
without the patch in the device operation, but the return values are wrong
and SCT tests fail for MemoryAllocationServicesTest category.
The second is a shielding the device against mistakes in the definition of
struct fields needed by the capsule update mechanism. Instead of crashing,
print a humna readable message of what's wrong.
lmb: Fix the allocation of overlapping memory areas with !LMB_NONE
At the moment the LMB allocator will return 'success' immediately on two
consecutive allocations if the second one is smaller and the flags match
without resizing the reserved area.
This is problematic for two reasons, first of all the new updated
allocation won't update the size and we end up holding more memory than
needed, but most importantly it breaks the EFI SCT tests since EFI
now allocates via LMB.
More specifically when EFI requests a specific address twice with the
EFI_ALLOCATE_ADDRESS flag set, the first allocation will succeed and
update the EFI memory map. Due to the LMB behavior the second allocation
will also succeed but the address ranges are already in the EFI memory
map due the first allocation. EFI will then fail to update the memory map,
returning EFI_OUT_OF_RESOURCES instead of EFI_NOT_FOUND which break EFI
conformance.
So let's remove the fast check with is problematic anyway and leave LMB
resize and calculate address properly. LMB will now
- try to resize the reservations for LMB_NONE
- return -1 if the memory is not LMB_NONE and already reserved
The LMB code needs some cleanup in that part, but since we are close to
2025.01 do the easy fix and plan to refactor it later.
Also update the dm tests with the new behavior.
Fixes: commit 22f2c9ed9f53 ("efi: memory: use the lmb API's for allocating and freeing memory") Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
efi_loader: Check for a valid fw_name before auto generating GUIDs
The gen_v5_guid() is a void and does no error checking with pointers
being available etc. Instead it expects all things to be in place to
generate GUIDs. If a board capsule definition is buggy and does not
define the firmware names when enabling capsule updates, the board will
crash trying to bring up the EFI subsystem.
Check for a valid firmware name before generating GUIDs.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Evgeny Bachinin [Mon, 25 Nov 2024 09:15:07 +0000 (12:15 +0300)]
common: relocate fdt_blob in global_data for FDTSRC_EMBED case
Patch resolves two kind of bugs, one of which is vulnerability related
to KASLR.
=== Issue briefly ===
Working with FDT (via non-relocated gd::fdt_blob) from inside bootm
command may lead to the reading the garbage instead of FDT nodes. And
this can result in various side-effects depending on DTS nodes, being
parsed during bootm.
But below is my specific story how I faced with this issue due to
MESON_RNG probing failure.
=== Bugs description ===
1) Bug is revealed on:
* configuration below
* U-boot 2024.10 - f919c3a889f ("Prepare v2024.10")
It seems, the following patch is a trigger: ea955eea4f ("fdt: automatically add /chosen/kaslr-seed if DM_RNG is enabled")
Generally, CONFIG_OF_EMBED=y & CONFIG_RNG_MESON=y are the most
valuable ones for reproducing the issue.
```
CONFIG_ARCH_FIXUP_FDT_MEMORY=y
CONFIG_CMD_FDT=y
CONFIG_DEFAULT_FDT_FILE=""
CONFIG_FDT_64BIT=y
CONFIG_OF_BOARD_SETUP=y
CONFIG_OF_CONTROL=y
CONFIG_OF_EMBED=y
CONFIG_OF_LIBFDT_ASSUME_MASK=0x0
CONFIG_OF_LIBFDT_OVERLAY=y
CONFIG_OF_LIBFDT=y
CONFIG_OF_LIST="meson-axg-our-device-name"
CONFIG_OF_REAL=y
CONFIG_OF_TRANSLATE=y
CONFIG_SUPPORT_OF_CONTROL=y
CONFIG_SYS_FDT_PAD=0x3000
CONFIG_TOOLS_OF_LIBFDT=y
CONFIG_DM_RNG=y
CONFIG_RNG_MESON=y
```
2) Due to CONFIG_OF_EMBED, the DTS is embedded into U-boot ELF and
accessible via __dtb_dt_begin symbol.
On early boot stage (board_f.c) the fdtdec_setup() is called only
once before U-boot's relocation into top of RAM. fdtdec_setup()
initializes gd::fdt_blob for FDTSRC_EMBED case:
```
gd->fdt_blob = dtb_dt_embedded();
gd->fdt_src = FDTSRC_EMBED;
```
3) Then reloc_fdt() is called in board_f.c
But due to CONFIG_OF_EMBED=y the reloc_fdt() does not update
gd::fdt_blob value (strictly speaking, it is impossible for
CONFIG_OF_EMBED=y, because U-boot ELF has not been relocated yet
at this moment).
As a result after relocation we get fdt_blob, pointing to DTS address
before relocation:
```
# bdinfo
<...>
relocaddr = 0x000000000fedf000
reloc off = 0x000000000eedf000
<...>
fdt_blob = 0x010ce6c0 << points to __dtb_dt_begin before relocation
new_fdt = 0x0000000000000000 << empty erroneously
fdt_size = 0x0000000000000000 << zero erroneously
```
4) During bootm command (according to our ITS-config file) the Linux
is loaded into 0x01080000 (which is very close to fdt_blob addr
0x010ce6c0).
```
## Loading kernel from FIT Image at 04000000 ...
Trying 'kernel' kernel subimage
<...>
Load Address: 0x01080000
```
So Linux image overwrites the gd::fdt_blob memory location
in RAM (0x010ce6c0).
5) Issue:
Hence any manipulation with DTS (say, via FDT API) inside
implementation of bootm command leads to accessing the fdt_blob area
with garbage, that can lead to two situations:
Almost the same as in (5.1), but 2 situations happen (depending on
the value of garbage):
* call to fdt_offset_ptr_() :: fdt_off_dt_struct(fdt)
returns not so big garbage, leading to tagp, being inside RAM.
* or calculations of absoffset inside fdt_offset_ptr() leads to
failure of the one of if() conditions with NULL as retval.
Result is fdt_next_tag() interprets the tagp as FDT_END. And we are
returning from our callstack via functions' error paths, leading to
"No RNG device" and "KASLR disabled due to lack of seed":
```
fdt_kaslrseed()
uclass_get_device()
<...>
device_probe()
device_of_to_plat()
meson_rng_of_to_plat()
clk_get_by_name()
clk_get_by_name_nodev()
<...>
fdt_stringlist_search()
fdt_getprop()
fdt_get_property_namelen_()
fdt_first_property_offset()
fdt_check_node_offset_()
fdt_next_tag():
```
tagp = fdt_offset_ptr(fdt, offset, FDT_TAGSIZE);
```
fdt_next_tag() tagp:0000000001890677
fdt_next_tag() ram_top:0x10000000 (tagp is inside RAM)
uclass_get_device_tail():486 device_probe() ret:-22
No RNG device
Starting kernel ...
[ 0.000000] Linux version 6.9.12
[ 0.000000] KASLR disabled due to lack of seed
```
Mark Kettenis [Tue, 26 Nov 2024 19:12:14 +0000 (20:12 +0100)]
Makefile: avoid non-standard sed expressions
The '?' that is used in the sed expression that determines MK_ARCH
is part of the extended regular expression syntax, but the default
behaviour of sed as specified by POSIX is to use only basic regular
expression syntax. Use the equivalent '\{0,1\}' instead as
suggested by the OpenBSD re_format(7) man page.
Fixes: 04b1d84221d5 ("Makefile: fix empty MK_ARCH when using ccache") Signed-off-by: Mark Kettenis <kettenis@openbsd.org> Reviewed-by: Marek Vasut <marex@denx.de> Tested-by: Quentin Schulz <quentin.schulz@cherry.de>
Jerome Forissier [Tue, 26 Nov 2024 14:45:06 +0000 (15:45 +0100)]
net: lwip: wget: fix legacy syntax
Commit 356011f7ac25 ("lwip: fix code style issues") has inadvertently
broken the support for the legacy syntax:
=> wget 192.168.0.16:test.bin
invalid uri, no file path
Invalid URL. Use http(s)://
The reason is two calls to strncpy() were replaced by strlcpy() without
paying attention to the fact that they are not equivalent in the present
case. Since we are using a character counter (n) and since we do not
depend on having a properly null-terminated string at each step in the
parsing, strlcpy() is not justified and strncpy() is the right tool for
the job. So use it again.
Reported-by: Tom Rini <trini@konsulko.com> Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Ilias Apalodimas [Fri, 29 Nov 2024 17:08:13 +0000 (19:08 +0200)]
Revert "efi_memory: do not add U-Boot memory to the memory map"
This reverts commit ("commit a68c9ac5d8af ("efi_memory: do not add
U-Boot memory to the memory map").
This code was removed when the EFI subsystem started using LMB calls for
the reservations. In hindsight it unearthed two problems.
The e820 code is adding u-boot memory as EfiReservedMemory while it
should look at what LMB added and decide instead of blindly overwriting
it. The reason this worked is that we marked that code properly late,
when the EFI came up. But now with the LMB changes, the EFI map gets
added first and the e820 code overwrites it.
The second problem is that we never mark SetVirtualAddressMap as runtime
code, which we should according to the spec. Until we fix this the
current hack can't go away, at least for architectures that *need* to
call SVAM.
More specifically x86 currently requires SVAM and sets the NX bit for
pages not marked as *_CODE. So unless we do that late, it will crash
trying to execute from non-executable memory. It's also worth noting
that x86 calls SVAM late in the boot, so this will work until someone
decides to overwrite/use BootServicesCode from the OS.
Notably arm64 disables it explicitly if the VA space is > 48bits, so
doesn't suffer from any of these problems.
This doesn't really deserve a fixes tag, since it brings back a hack to
remedy a situation that was wrong long before that commit, but in case
anyone hits the same bug ...
Simon sent the original revert in the link, but we need a proper
justification for it.
- Make DRAM coding GPIOs available before relocation on Data Modul
i.MX8M Mini/Plus eDM SBC because the DRAM configuration GPIO straps
must be accessible in SPL and before relocation because the GPIOs are
sampled both in U-Boot SPL as well as early on in U-Boot proper.
- Pick safe DRAM size on failure on Data Modul i.MX8M Mini/Plus eDM SBC
instead of failing with hang() or panic().
- Replace YModem with SDP on Data Modul i.MX8M Mini eDM SBC SPL since
SDP is much more flexible.
- Deduplicate Data Modul i.MX8M eDM SBC defconfigs.
- Perform plain boot in altbootcmd on Data Modul i.MX8M Mini/Plus eDM
SBC.
Jerome Forissier [Fri, 15 Nov 2024 16:45:14 +0000 (17:45 +0100)]
test/cmd/wget.c: move net_test_wget() to the cmd test suite
Since net_test_wget() is testing a command and is in test/cmd it should
be in the 'cmd' test suite, not 'lib'.
Saving and restoring the values of the environment variables that the
test manipulates is necessary to avoid a regression when running the
whole ut test suite. A minimal reproducer is:
Marek Vasut [Fri, 29 Nov 2024 00:35:43 +0000 (01:35 +0100)]
ARM: dts: imx: Enable PCIe and NVMe on Data Modul i.MX8M Mini eDM SBC
Enable PCIe/NVMe support on Data Modul i.MX8M Mini eDM SBC. Except for
the configuration options which are enabled, add slight adjustment
to board u-boot.dtsi, which is necessary as there is currently no
driver for the I2C PCIe clock generator. Since the generator is
strapped to be always on, it is possible to supplant the generator
functionality by fixed-clock.
Marek Vasut [Fri, 29 Nov 2024 02:41:47 +0000 (03:41 +0100)]
ARM: imx: Replace YModem with SDP on Data Modul i.MX8M Mini eDM SBC SPL
The YModem support in SPL was never really used on this device,
the SDP support is much more convenient on i.MX8M Mini based
hardware. Replace the YModem support with SDP support.
The SDP can be utilized by forcing the board into SDP boot mode
by grounding test point right next to silkscreen label U30, and
then by using mfgtools 'uuu -brun spl flash.bin' once the device
enumerates on host system USB bus. The SDP capable USB port is
available on the USB micro-B port on the base board.
Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Peng Fan <peng.fan@nxp.com>
Marek Vasut [Fri, 29 Nov 2024 00:13:56 +0000 (01:13 +0100)]
ARM: imx: Deduplicate Data Modul i.MX8M eDM SBC defconfigs
Deduplicate defconfigs for all Data Modul i.MX8M eDM SBC systems by factoring
out the common parts into generic imx8m_data_modul.config and including
those using the #include <configs/...> preprocessor macro in the current
set of board specific defconfigs. The preprocessor macro is applicable
to defconfigs as well.
This introduces no functional change, the resulting .config is almost
identical for all Data Modul i.MX8M eDM SBC systems, except for slight
alignment in DEBUG_UART and SYS_PBSIZE.
Marek Vasut [Fri, 29 Nov 2024 00:13:55 +0000 (01:13 +0100)]
ARM: imx: Perform plain boot in altbootcmd on Data Modul i.MX8M Mini/Plus eDM SBC
The current A/B switching preparatory altbootcmd is confusing
to users, replace it with plain 'run bootcmd' which can be
replaced by proper A/B switching altbootcmd when the matching
updater is added on top of the platform. By default, keep the
boot counter incrementing, but do not do any A/B partition
switching.
Marek Vasut [Fri, 29 Nov 2024 00:13:54 +0000 (01:13 +0100)]
ARM: dts: imx: Pick safe DRAM size on failure on Data Modul i.MX8M Mini/Plus eDM SBC
In case gpio_request_list_by_name_nodev() in board dmo_get_memcfg()
returns error code, pick a safe default DRAM configuration instead
of bailing out with some sort of hang() or panic(). The BIT(2)|BIT(0)
strap option is the lowest known option of 2 GiB , use that.
Marek Vasut [Fri, 29 Nov 2024 00:13:53 +0000 (01:13 +0100)]
ARM: dts: imx: Make DRAM coding GPIOs available before relocation on Data Modul i.MX8M Mini/Plus eDM SBC
The DRAM configuration GPIO straps must be accessible in SPL and before
relocation because the GPIOs are sampled both in U-Boot SPL as well as early
on in U-Boot proper. The already present bootph-pre-ram DT property made the
GPIO controllers available in SPL, but not early on in U-Boot proper, which
made gpio_request_list_by_name_nodev() in board dmo_get_memcfg() fail. Add
missing bootph-some-ram DT property to all GPIO controllers which are
referenced in dmo,ram-coding-gpios DT property to make those GPIO
controllers available early in U-Boot proper as well.
Fixes: 8c103c33fb14 ("dm: dts: Convert driver model tags to use new schema") Signed-off-by: Marek Vasut <marex@denx.de>
Yuri Zaporozhets [Tue, 19 Nov 2024 20:59:59 +0000 (21:59 +0100)]
configs: enable CONFIG_PCI_REGION_MULTI_ENTRY=y in sifive_unmatched_defconfig
Currently, the PCI subsystem selects the small "region 2" (which starts at 0x7000000)
as bus_addr/phys_addr. As a consequence, the BAR0 on PCIe video card cannot be initialized,
because it simply doesn't fit into 0x1000000 bytes size of "region 2".
U-Boot should use "region 1" instead (the one which starts at 0x60090000), because
it has much bigger size (0xFF70000), and easily accomodates BAR0 of the video card.
Linux kernel also uses 0x60090000 as bus_start/phys_start.
Signed-off-by: Yuri Zaporozhets <yuriz@vodafonemail.de> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
To restore MMC boot, enable SPL_SYS_MMCSD_RAW_MODE and recover
SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION and
SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION.
Fixes: 2a00d73d081 ("spl: mmc: Try to clean up raw-mode options") Signed-off-by: Andreas Schwab <schwab@suse.de> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
With the move from script based booting to using bootmeth a lot of
environment variables have changed. To always use the default environment
it is recommendable to erase the environment stored in the SPI flash.
This can be done with the 'env erase' sub-command.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Yuri Zaporozhets [Mon, 11 Nov 2024 19:24:04 +0000 (20:24 +0100)]
spl: increase SPL_SYS_MALLOC_SIZE when using BIOSEMU on RISC-V
If BIOSEMU is compiled for RISC-V (SiFive Unmatched board) and the function
dm_pci_run_vga_bios() is executed, U-Boot stops with error message saying
that the SPL malloc pool is too small. So increase the default pool size
when both BIOSEMU and RISCV parameters are set.
Signed-off-by: Yuri Zaporozhets <yuriz@qrv-systems.net> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
david regan [Wed, 13 Nov 2024 06:27:14 +0000 (22:27 -0800)]
mtd: rawnand: brcmnand: Default bcmbca parameter_page_big_endian to zero
Set parameter_page_big_endian to zero for bcmbca
Signed-off-by: david regan <dregan@broadcom.com> Reviewed-by: William Zhang <william.zhang@broadcom.com> Reviewed-by: Anand Gore <anand.gore@broadcom.com>
Chris Packham [Mon, 25 Nov 2024 19:55:53 +0000 (08:55 +1300)]
arm: mvebu: Add Allied Telesis x250 board
The x250 and SE250 are series of 10G L2+ switches from Allied Telesis.
There are a number of them in the range but as far as U-Boot is
concerned all the CPU block components are the same so there's only one
board defined.
Signed-off-by: Chris Packham <judge.packham@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
Tony Dinh [Thu, 21 Nov 2024 19:02:27 +0000 (11:02 -0800)]
arm: kirkwood: Enable bootstd for Sheevaplug board
Enable bootstd for Sheevaplug board.
Remove JFFS2 support. See JFFS2 Vulnerability[1].
Enable LTO to keep board size within limit.
Move default envs to text-base environment
Tony Dinh [Mon, 18 Nov 2024 19:34:59 +0000 (11:34 -0800)]
arm: mvebu: Disable JFFS2 support for Kirkwood and Armada XP boards
These boards don't use JFFS2 file system for booting so remove it.
Ref: https://lore.kernel.org/u-boot/20241114233005.GN3600562@bill-the-cat/T/#t Signed-off-by: Tony Dinh <mibodhi@gmail.com> Acked-by: Phil Sutter <phil@nwl.cc> Reviewed-by: Stefan Roese <sr@denx.de>
Ion Agorria [Tue, 26 Nov 2024 07:29:56 +0000 (09:29 +0200)]
usb: ci_udc: don't use "advance" feature when setting address
In the older USB controllers like for example in ChipIdea controller
used by the Tegra 2 the "USBADRA: Device Address Advance" bitflag
does not exist, so the new device address set during SET_ADDRESS
can't be deferred by hardware, which causes the host to not recognize
the device and give an error.
Instead store it until ep completes to apply the change into the hw
register as Linux kernel does. This should fix regression on old and
and be compatible with newer controllers.
spi: Fix missed rename from SPI_ADVANCE to SPI_STACKED_PARALLEL
Fix missed rename from SPI_ADVANCE to SPI_STACKED_PARALLEL. This fixes
an issue encountered while testing the Zynq-7000 QSPI parallel Flash
implementation.
Khoa Hoang [Fri, 8 Nov 2024 05:51:36 +0000 (21:51 -0800)]
eth: asix88179: packet drop when receiving large fragmented packets
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>
Khoa Hoang [Fri, 8 Nov 2024 05:51:35 +0000 (21:51 -0800)]
eth: asix88179: Fix ASIX AX88179A PHY hang
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>
usb: onboard-hub: Add i2c initialization for usb5744 hub
Add i2c initialization hook and set usb5744 platform
data with function having required i2c initialization sequence.
Apart from the USB command attach, prevent the hub from suspend.
when the “USB Attach with SMBUS (0xAA56)” command is issued to the hub,
the hub is getting enumerated and then it puts in a suspend mode.
This causes the hub to NAK any SMBUS access made by the SMBUS Master
during this period and not able to see the hub's slave address while
running the "i2c probe" command.
Prevent the MCU from the putting the HUB in suspend mode through register
write. The BYPASS_UDC_SUSPEND bit (Bit 3) of the RuntimeFlags2 register at
address 0x411D controls this aspect of the hub. The BYPASS_UDC_SUSPEND
bit in register 0x411Dh must be set to ensure that the MCU is always
enabled and ready to respond to SMBus runtime commands. This register
needs to be written before the USB attach command is issued.
The byte sequence is as follows:
Slave addr: 0x2d 00 00 05 00 01 41 1D 08
Slave addr: 0x2d 99 37 00
Slave addr: 0x2d AA 56 00
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com> Reviewed-by: Marek Vasut <marex@denx.de>
usb: onboard-hub: add support for Microchip USB5744
Add support for the Microchip USB5744 USB3.0 and USB2.0 Hub.
The usb5744 driver trigger hub reset signal after soft reset.
The usb5744 hub need to reset after the phy initialization,
which toggles the gpio.
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com> Reviewed-by: Marek Vasut <marex@denx.de>
As part of the reset, sets the direction of the pin to output before
toggling the pin. Delay of millisecond is added in between low and
high to meet the setup and hold time requirement of the reset.
Update the usb2514 hub_data with the reset delay and power on
delay values.
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com> Reviewed-by: Marek Vasut <marex@denx.de>
Tom Rini [Sun, 24 Nov 2024 21:41:32 +0000 (15:41 -0600)]
Merge patch series "Fix device removal order for Apple dart iommu"
Janne Grunau <j@jannau.net> says:
Starting with v2024.10 dev_iommu_dma_unmap calls during device removal
trigger a NULL pointer dereference in the Apple dart iommu driver. The
iommu device is removed before its user. The sparsely used DM_FLAG_VITAL
flag is intended to describe this dependency. Add it to the driver.
Adding this flag is unfortunately not enough since the boot routines
except the arm one simply remove all drivers. Add and use a new function
which calls
dm_remove_devioce_flags(DM_REMOVE_ACTIVE_ALL | DM_REMOVE_NON_VITAL);
dm_remove_devices_flags(DM_REMOVE_ACTIVE_ALL);
to ensure this order dependency is head consistently.
Janne Grunau [Sat, 23 Nov 2024 21:44:05 +0000 (22:44 +0100)]
dm: Add dm_remove_devices_active() for ordered device removal
This replaces dm_remove_devices_flags() calls in all boot
implementations to ensure non vital devices are consistently removed
first. All boot implementation except arch/arm/lib/bootm.c currently
just call dm_remove_devices_flags(DM_REMOVE_ACTIVE_ALL). This can result
in crashes when dependencies between devices exists. The driver model's
design document describes DM_FLAG_VITAL as "indicates that the device is
'vital' to the operation of other devices". Device removal at boot
should follow this.
Instead of adding dm_remove_devices_flags() with (DM_REMOVE_ACTIVE_ALL |
DM_REMOVE_NON_VITAL) everywhere add dm_remove_devices_active() which
does this.
Fixes a NULL pointer deref in the apple dart IOMMU driver during EFI
boot. The xhci-pci (driver which depends on the IOMMU to work) removes
its mapping on removal. This explodes when the IOMMU device was removed
first.
dm_remove_devices_flags() is kept since it is used for testing of
device_remove() calls in dm.
Janne Grunau [Sat, 23 Nov 2024 21:44:04 +0000 (22:44 +0100)]
iommu: apple: Mark device with DM_FLAG_VITAL
Avoids NULL pointer dereferences in apple_dart_unmap when the iommu
device is removed before its user. U-boot's device model does not track
dependencies between devices.
Observed on a M1 Ultra Mac Studio with v2024.10.
Acked-by: Mark Kettenis <kettenis@openbsd.org> Signed-off-by: Janne Grunau <j@jannau.net>
Ilias Apalodimas [Sun, 24 Nov 2024 09:00:03 +0000 (11:00 +0200)]
lmb: Correctly unmap and free memory on errors
We never free and unmap the memory on errors and we never unmap it when
freeing it. The latter won't cause any problems even on sandbox, but for
consistency always use unmap_sysmem()
Fixes: commit 22f2c9ed9f53 ("efi: memory: use the lmb API's for allocating and freeing memory") Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
efi_loader: allow EFI_LOADER_BOUNCE_BUFFER on all architectures
Commit 775f7657ba58 ("Kconfig: clean up the efi configuration status")
by mistake revoked commit dcd1b63b7072 ("efi_loader: allow
EFI_LOADER_BOUNCE_BUFFER on all architectures").
Fixes: 775f7657ba58 ("Kconfig: clean up the efi configuration status") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Tested-by: Loic Devulder <ldevulder@suse.com>
Marek Vasut [Fri, 22 Nov 2024 01:58:12 +0000 (02:58 +0100)]
arm64: dts: imx8mn: Include 32kHz oscillator clock in SPL DTs
Since 50cdd3f74af3 ("clk: imx: clk-imx8mn Fix nand and spi clock parent"),
drivers/clk/imx/clk-imx8mn.c clk_get_by_name(dev, "osc_24m", &osc_24m_clk)
fails with error -22 EINVAL in SPL. This is because clk_get_by_name() in the
end calls fdtdec_parse_phandle_with_args(), which iterates over all phandles
in clock-controller@30380000 { clocks = <&osc_32k>, <&osc_24m>, ... } node
'clocks' property in an attempt to find the "osc_24m" clock, but fails to
resolve the &osc_32k phandle and returns with -EINVAL.
Include the osc_32k clock in SPL DTs as a low risk fix for v2025.01 release.
This way, fdtdec_parse_phandle_with_args() can resolve both the osc_32k and
following osc_24m phandle and successfully look up the osc_24m clock.
Fixes: 50cdd3f74af3 ("clk: imx: clk-imx8mn Fix nand and spi clock parent") Signed-off-by: Marek Vasut <marex@denx.de> Tested-by: Adam Ford <aford173@gmail.com> #imx8mn-beacon
projects / u-boot.git / log