board: ti: am62px: env: include environment for DFU Boot
Include the TI K3 DFU environment to support DFU Boot and DFU Flash.
Also add "usb" to the list of "boot_targets". While at it, add a newline
at the end of the file.
configs: am62ax_evm_a53_defconfig: enable USB DFU support
The config fragment "am62x_a53_usbdfu.config" which adds USB DFU support
for AM62x SoC is applicable to the AM62Ax SoC as well. Hence, include it
in "am62ax_evm_a53_defconfig" in order to enable support for USB DFU flash
and boot.
* create a parent device for all EFI block devices
* move lmb_map_update_notify() to EFI
* make efi_add_memory_map_pg() static
* remove comparisons to string literals from runtime
* ix potential deref-after-null
Other:
* avoid superfluous value check in lmb_map_update_notify()
* support more efi protocols in uuid_guid_get_str()
Please pull the fixes for rockchip platform:
- Fix for rk3399 bob and kevin
- Fix for sdram more than 4GB
- Fix for dwc_eth on rk356x/rk3588
- Fix for sdmmc access on rk33080rock-s9
When building with qemu_arm64_defconfig with CONFIG_CC_OPTIMIZE_FOR_DEBUG=y
and CONFIG_EFI_LOADER=n an error undefined reference to efi_add_memory_map_pg
occurs.
Move the EFI dependent part of lmb_map_update_notify() to the EFI
sub-system.
Reported-by: Liya Huang <1425075683@qq.com> Acked-by: Liya Huang <1425075683@qq.com> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
efi_driver: create a parent device for all EFI block devices
Up to now root has been the parent device for all block devices created via
calling ConnectController(). This does not work well together with the
implementation of bootstd.
Add a dummy parent device for all EFI block devices.
With this change EFI block devices are also accessible via commands like
'cat', 'load', and 'ls'.
Ilias Apalodimas [Fri, 14 Feb 2025 13:46:45 +0000 (15:46 +0200)]
efi_loader: remove comparisons to string literals from runtime
For EFI runtime services, we manage to preserve string literals
by placing the .efi_runtime section just before .data and preserving
it when marking the runtime memory by marking surrounding boottime
code as runtime. This is ok for now but will break if we update any
linker scripts and decouple .text and .runtime sections.
So let's define the strings we used to compare in the appropriate
section for runtime services
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
Tom Rini [Thu, 20 Feb 2025 00:49:47 +0000 (18:49 -0600)]
Merge patch series "bloblist: refactor xferlist and bloblist"
Tom Rini <trini@konsulko.com> says:
This small series separates "bloblist" and "standard passage" to allow
for these similar concepts to explore solutions to problems without
introduces breaking changes to the other.
Raymond Mao [Thu, 20 Feb 2025 00:02:20 +0000 (16:02 -0800)]
bloblist: kconfig for mandatory incoming standard passage
In previous commit, incoming standard passage is used by default
when initializing the bloblist, so explicitly BLOBLIST_PASSAGE is
no more needed.
Rename it as BLOBLIST_PASSAGE_MANDATORY to determine the behaviors
when an incoming transfer list does not exist or is invalid.
When it is selected, incoming standard passage is mandatory and
U-Boot will report an error when a valid incoming transfer list is
missing.
Signed-off-by: Raymond Mao <raymond.mao@linaro.org>
Raymond Mao [Thu, 20 Feb 2025 00:02:19 +0000 (16:02 -0800)]
bloblist: refactor xferlist and bloblist
Refactor the xferlist to remove the relocating when bloblist passed
from the boot args.
Refactor bloblist init to use incoming standard passage by default
if a valid transfer list exists in the boot args.
For bloblist relocation, use the actual total size if it has a smaller
BLOBLIST_SIZE_RELOC.
Signed-off-by: Raymond Mao <raymond.mao@linaro.org> Suggested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Jonas Karlman [Tue, 4 Feb 2025 21:38:43 +0000 (21:38 +0000)]
arm64: dts: rockchip: Fix sdmmc access on rk3308-rock-s0 v1.1 boards
BootROM leave GPIO4_D6 configured as SDMMC_PWREN function and DW MCI
driver set PRWEN high on MMC_POWER_UP and low on MMC_POWER_OFF.
Similarly U-Boot also set PRWEN high before accessing mmc.
However, HW revision prior to v1.2 must pull GPIO4_D6 low to access
sdmmc. For HW revision v1.2 the state of GPIO4_D6 has no impact.
Model an always-on active low fixed regulator using GPIO4_D6 to fix
use of sdmmc on older HW revisions of the board.
Jonas Karlman [Sun, 9 Feb 2025 23:27:56 +0000 (23:27 +0000)]
net: dwc_eth_qos_rockchip: Fix disable of RX/TX delay for RK3588
When rgmii-rxid/txid/id phy-mode is used the MAC should not add RX
and/or TX delay. Currently RX/TX delay is configured as enabled using
zero as delay value for the rgmii-rxid/txid/id modes.
Change to disable RX and/or TX delay and using zero as delay value.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Jonas Karlman [Sun, 9 Feb 2025 23:27:55 +0000 (23:27 +0000)]
net: dwc_eth_qos_rockchip: Fix disable of RX/TX delay for RK356x
When rgmii-rxid/txid/id phy-mode is used the MAC should not add RX
and/or TX delay. Currently RX/TX delay is configured as enabled using
zero as delay value for the rgmii-rxid/txid/id modes.
Change to disable RX and/or TX delay and using zero as delay value.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Jonas Karlman [Mon, 6 Jan 2025 21:39:42 +0000 (21:39 +0000)]
pinctrl: rockchip: rk3328: Fix pinmux for GPIO2-B and GPIO3-B pins
The pinmux bits for GPIO2-B0 to GPIO2-B6 actually have 2 bits width,
correct the bank flag for GPIO2-B. The pinmux bits for GPIO2-B7 is
recalculated so it remain unchanged. Add missing GPIO3-B1 to GPIO3-B7
pinmux data to rk3328_mux_recalced_data as mux register offset for these
pins does not follow rockchip convention.
This matches changes in following Linux commits:
- e8448a6c817c ("pinctrl: rockchip: fix pinmux bits for RK3328 GPIO2-B pins")
- 5ef6914e0bf5 ("pinctrl: rockchip: fix pinmux bits for RK3328 GPIO3-B pins")
- 128f71fe014f ("pinctrl: rockchip: correct RK3328 iomux width flag for GPIO2-B pins")
Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Jonas Karlman [Sun, 12 Jan 2025 22:27:29 +0000 (22:27 +0000)]
rockchip: rk3288: Use rk3288-cru.h from dts/upstream
clock/rk3288-cru.h in include/dt-bindings is almost identical to the
version in dts/upstream, remove the copy from include/dt-bindings to
only use the version from dts/upstream.
One clk, SCLK_MAC_PLL, is not part of the upstream bindings, this clk is
not used by upstream, in-tree or vendor DTs and can safely be dropped.
No functional change to board DTs is intended with this removal.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Jonas Karlman [Thu, 30 Jan 2025 22:07:11 +0000 (22:07 +0000)]
rockchip: sdram: Allow the first bank to extend beyond 4 GiB
Allow the first bank to extend beyond 4 GiB when the blob of space for
peripheral is located before start of DRAM, e.g. when start of DRAM
is 0x40000000 and continue beyond the 4 GiB mark.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Add the dram_init_banksize function to the board file to properly set
DRAM memory sizes during boot.
The commit bc07851897bd ("board: ti: Pull redundant DDR functions to a
common location and Fixup DDR size when ECC is enabled") relocated the
dram_init_banksize function from architecture specific initialization to
the TI board initialization code. As a result, boards relying on the
previous setup now require this function to be defined within their
board file to handle DRAM sizing correctly.
Without this function defined the following error appears during boot:
ERROR: Failed to allocate 0x1000 bytes below 0x0.
Fixes: bc07851897bd ("board: ti: Pull redundant DDR functions to a common location and Fixup DDR size when ECC is enabled") Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com> Acked-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Add the dram_init_banksize function to the board file to properly set
DRAM memory sizes during boot.
The commit bc07851897bd ("board: ti: Pull redundant DDR functions to a
common location and Fixup DDR size when ECC is enabled") relocated the
dram_init_banksize function from architecture specific initialization to
the TI board initialization code. As a result, boards relying on the
previous setup now require this function to be defined within their
board file to handle DRAM sizing correctly.
Without this function defined the following error appears during boot:
ERROR: Failed to allocate 0x1000 bytes below 0x0.
Fixes: bc07851897bd ("board: ti: Pull redundant DDR functions to a common location and Fixup DDR size when ECC is enabled") Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com> Acked-by: Francesco Dolcini <francesco.dolcini@toradex.com>
The PRNG implementing the random() function only has 2^31 states and
therefore is unsafe to use for cryptography. Use arc4random() instead.
Fixes: cc34f04efd63 ("tools: image-host.c: use random instead of rand")
Addresses-Coverity-ID: 312953 Calling risky function Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Udit Kumar [Tue, 11 Feb 2025 17:51:58 +0000 (23:21 +0530)]
power: regulator: tps65941: Fix voltage calculation for ldo
As per TRM[0] Section 8.7.1 "TPS6594-Q1 Registers", LDOx_Vout
bit 6-1, define the NVM voltage settings.
Along side table 8-4 of above TRM, shows voltage to value mapping.
Driver wrongly using bits 5-1 to calculate voltage, and to convert
voltage to value driver was using buck's calculation.
So fix those calculation.
Fixes: 5d7dbd22cf7d ("power: regulator: tps65941: use function callbacks for conversion ops") Signed-off-by: Udit Kumar <u-kumar1@ti.com> Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Tom Rini [Tue, 18 Feb 2025 13:59:59 +0000 (07:59 -0600)]
Merge tag 'u-boot-at91-2025.07-a' of https://source.denx.de/u-boot/custodians/u-boot-at91 into next
First set of u-boot-at91 features for the 2025.07 cycle:
This feature set includes improvements on the atmel-quadspi driver, a
fix for the nand driver, and improvements on the pinctrl driver to be
able to use the Linux DT (also sync on the DT side as well).
Tom Rini [Sun, 16 Feb 2025 16:29:03 +0000 (10:29 -0600)]
Gitlab: Add missing symlink for qemu_arm64_lwip boardenv file
When adding the symlink for the conf file so qemu_arm64_lwip uses
qemu_arm64 configuration information, the symlink for the boardenv file
was missed in Gitlab (but not Azure). Add that in now.
Fixes: fd10d156db3f ("CI: add qemu_arm64_lwip to the test matrix") Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org> Signed-off-by: Tom Rini <trini@konsulko.com>
Svyatoslav Ryhel [Sun, 21 Jan 2024 13:37:57 +0000 (15:37 +0200)]
board: acer: picasso: add Acer Iconia Tab A500 support
The Acer Iconia A500 is a tablet computer designed, developed and
marketed by Acer Inc. It is powered by 1 GHz Nvidia Tegra 2 processor
and 1GB DDR2 RAM. The A500 is sold with 64 GB, although both 16 GB
and 32 GB models are available.
Tom Rini [Sat, 15 Feb 2025 21:29:20 +0000 (15:29 -0600)]
Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-sh
Add empty weak assembler function armv8_switch_to_el2_prep() which is
jumped to just before U-Boot determines which EL it is running in and
decides which path to take to boot the Linux kernel. Add
IH_TYPE_TFA_BL31 into supported images type, to allow implementation of
board specific U_BOOT_FIT_LOADABLE_HANDLER(IH_TYPE_TFA_BL31, ...) TFA
BL31 loadable handler for fitImages.
This PR contains common hooks which are noop, R-Car Gen4 board specific
implementation using these hooks is coming in next PR.
Marek Vasut [Wed, 29 Jan 2025 21:59:19 +0000 (22:59 +0100)]
image: Add support for starting TFA BL31 as fitImage loadables
Add support for starting TFA from U-Boot running in EL3 as part of
fitImage boot, so the user can start U-Boot in the highest privilege
level on the platform, bundle TFA, Linux, DT into a single fitImage
and boot such a bundle as a whole.
There are two main benefits of this approach. First is the ability
to run U-Boot in EL3, where it has unrestricted access to the entire
system and can act as a useful debug tool, as it was always intended
to be used. Second is the ability to easily and safely update of any
component in the fitImage, be it TFA, Linux or DT.
The boot process is similar to regular Linux with DT fitImage boot
process, except the TFA has to be bundled into the fitImage. For the
bundling instructions, see below. The TFA is started as a 'loadables'
with custom U_BOOT_FIT_LOADABLE_HANDLER and armv8_switch_to_el2_prep()
handling implemented in board code, and performing the handoff and
boot in case the TFA was loaded.
The loadables handler is optional and meant to set up any sort of
handoff structures used by the TFA BL31 or perform any other setup
that is needed by the blob. The custom armv8_switch_to_el2_prep()
has to implement the jump to TFA BL31 with return to U-Boot just
before booting the Linux kernel.
Example fitImage image and configuration section:
/dts-v1/;
/ {
description = "Linux kernel with FDT blob and TFA BL31";
images {
kernel-1 { ... };
fdt-1 { ... };
atf-1 { /* This is the TFA BL31 image */
description = "TFA BL31";
data = /incbin/("../build/plat/release/bl31.bin");
type = "tfa-bl31";
arch = "arm64";
os = "arm-trusted-firmware";
compression = "none";
load = <0x46400000>;
entry = <0x46400000>;
};
};
Marek Vasut [Wed, 29 Jan 2025 21:59:18 +0000 (22:59 +0100)]
arm64: Add late jump to kernel board hook
Add empty weak assembler function armv8_switch_to_el2_prep() which is
jumped to just before U-Boot determines which EL it is running in and
decides which path to take to boot the Linux kernel.
This weak function is meant to be used by architecture specific code
to implement jump to a firmware blob, which then returns right past
this weak function and continues execution of U-Boot code which then
boots the Linux kernel. One example of such use case is when U-Boot
jump tp TFA BL31, which switches from EL3 to EL2 and then returns to
U-Boot code newly running in EL2 and starts the Linux kernel.
The weak function is called with caches already disabled and DM shut
down. Any preparatory work or even loading of more data must be done
in board_prep_linux(), this hook is meant only for the final jump to
the firmware and return to U-Boot before booting Linux.
Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Hironori KIKUCHI [Fri, 31 Jan 2025 01:38:41 +0000 (10:38 +0900)]
spi: soft_spi: Add support for SPI_3WIRE
When 3-wire mode is claimed on the bus, use the MOSI (output) pin to
receive data. In this mode, since the transfer can only be either TX
or RX, return -EINVAL if both are required at the same time.
Tom Rini [Fri, 14 Feb 2025 23:11:37 +0000 (17:11 -0600)]
Merge patch series "Rework requirements.txt files"
Tom Rini <trini@konsulko.com> says:
A challenge we've run in to is making it easier for more people to use
various python tools that we include in the tree. Part of the problem is
that when we have a requirements.txt file, aside from the doc one we
share with the kernel, I created it using "pip freeze". And while this
might have been a best (or at least OK) practice at the time, that's no
longer the case and is why our files have so many things in them. What
this series does is create multiple files, one per project/tool and then
has CI install them as needed. There's a few places here where this
means that we update the requirements as well, but we keep a few big
things where they are currently. This is because updating them
introduces problems of their own and delaing with that would best be a
follow up series. I've put this through GitLab and Azure to make sure
everything is still going fine on both platforms.
Tom Rini [Tue, 4 Feb 2025 23:12:09 +0000 (17:12 -0600)]
Dockerfile: Update for having more requirements.txt files
Now that we have more requirements.txt files we need to grab all of them
for creating our cache. Also, we do longer should install
python3-pyelftools on the host as it's not used.
Tom Rini [Tue, 4 Feb 2025 23:12:08 +0000 (17:12 -0600)]
python: Recreate test/py and tools/buildman requirements.txt files
Use the "pipreqs" tool to re-create these files, with a few manual
corrections. We still need to include pytest-xdist which the tool does
not detect. We also for now don't upgrade most of the required tools as
that creates problems with various tests, which should be resolved
independently.
board: ti: am62px: tifs-rm-cfg/rm-cfg: Update DMA resource sharing for CPSW
The CPSW3G instance of CPSW on AM62PX SoC provides Ethernet functionality.
Currently, Ethernet is supported on Linux which runs on the A53 core on the
SoC, by allocating all of the DMA resources associated with CPSW to A53_2.
In order to enable use-cases where the Ethernet traffic is sent from or
consumed by various CPU cores on the SoC simultaneously, while at the
same time, maintaining backward compatibility with the existing use-case
of A53 being the sole entity that exchanges traffic with CPSW via DMA,
update the DMA resource sharing scheme on AM62PX SoC to the following:
In the absence of primary owners of resources (existing use-case
where A53 owns all of the CPSW DMA resources), the secondary owner
can claim all of the resources as its own. For shared use-cases,
the resources that are not claimed by the primary are communicated
to the secondary owner allowing it to claim them. This ensures that
Linux on A53_2 can continue claiming all DMA resources associated
with CPSW in the absence of primary owners, while at the same time
providing users the flexibility to share CPSW DMA resources across
various CPU cores listed above if needed.
While Linux has been mentioned as the Operating System running
on A53, there is no dependency between the Operating System
running on A53 and its ability to claim the CPSW DMA resources
listed above.
Tom Rini [Fri, 14 Feb 2025 19:17:47 +0000 (13:17 -0600)]
Merge patch series "Introduce K3 remoteproc driver for M4 subsystem"
Judith Mendez <jm@ti.com> says:
Some K3 devices like am62x and am64x have a M4 processor in the MCU
voltage domain. This patch series introduces remoteproc M4 driver which
will be used to load firmware into and start the M4 remote core.
This series also adds support for R5F cores on am64x SoCs in patch 2 and
sets up environment to load FW in remote cores in patch 3,4,5.
This patch series also enables remoteproc drivers by default as per what
remoteproc sybsystem is supported per SoC, thus all remoteproc options
are now deleted in configs/* since they are no longer required.
This patch series was tested on am64x EVM, am62x SK, am62ax SK,
am62px SK boards.
Any additional tested by's are welcome since I was not able to
test any additional boards.
Tested by running the following commands in u-boot prompt:
Judith Mendez [Mon, 10 Feb 2025 20:29:40 +0000 (14:29 -0600)]
remoteproc: Enable ARM64 remoteproc driver by default for K3 ARCH
If SYS_K3_SPL_ATF is enabled, for K3 ARCH enable the
remoteproc ARM64 driver by default so that it does not
have to be defined in each board defconfig file.
Signed-off-by: Judith Mendez <jm@ti.com> Reviewed-by: Andrew Davis <afd@ti.com>
Hari Nagalla [Mon, 10 Feb 2025 20:29:39 +0000 (14:29 -0600)]
board: ti: am62px: Add remoteproc specific env support
Add remoteproc specific env support for am62px device. If the
remoteproc CMD is defined, include the K3 remoteproc environment.
Also define rproc_fw_binaries which holds a list of remoteproc FW
binaries for u-boot loading of remote cores.
Signed-off-by: Hari Nagalla <hnagalla@ti.com> Signed-off-by: Judith Mendez <jm@ti.com> Reviewed-by: Andrew Davis <afd@ti.com>
Hari Nagalla [Mon, 10 Feb 2025 20:29:38 +0000 (14:29 -0600)]
board: ti: am62x: Add remoteproc specific env support
Add remoteproc specific env support for am62x device. If the
remoteproc CMD is defined, include the K3 remoteproc environment.
Also define rproc_fw_binaries which holds a list of remoteproc FW
binaries for u-boot loading of remote cores.
Signed-off-by: Hari Nagalla <hnagalla@ti.com> Signed-off-by: Judith Mendez <jm@ti.com> Reviewed-by: Andrew Davis <afd@ti.com>
Hari Nagalla [Mon, 10 Feb 2025 20:29:37 +0000 (14:29 -0600)]
board: ti: am64x: Add remoteproc specific env support
Add remoteproc specific env support for am64x device. If the
remoteproc CMD is defined, include the K3 remoteproc environment.
Also define rproc_fw_binaries which holds a list of remoteproc FW
binaries for u-boot loading of remote cores.
Signed-off-by: Hari Nagalla <hnagalla@ti.com> Signed-off-by: Judith Mendez <jm@ti.com> Reviewed-by: Andrew Davis <afd@ti.com>
Hari Nagalla [Mon, 10 Feb 2025 20:29:36 +0000 (14:29 -0600)]
remoteproc: k3-r5: Add support for R5F cores on AM64x SoCs
AM64x SoCs have two R5F clusters in the main power domain.
Extend support for R5F remote proc driver on AM64x with compatible
strings.
Signed-off-by: Hari Nagalla <hnagalla@ti.com> Signed-off-by: Judith Mendez <jm@ti.com> Reviewed-by: Daniel Schultz <d.schultz@phytec.de> Reviewed-by: Andrew Davis <afd@ti.com>
Tomas Peterka [Fri, 31 Jan 2025 10:08:44 +0000 (11:08 +0100)]
Kconfig: Move CONFIG_BOOTCOUNT_ALTBOOTCMD to Kconfig
Add CONFIG_BOOTCOUNT_ALTBOOTCMD so the developer is able to add
custom altbootcmd via Kconfig when they enable BOOTCOUNT. With this now
in Kconfig, we need to move it from environment files / config.h files
and in to the defconfig file.
This was done by generating u-boot-initial-env for all platforms before
the Kconfig change, to extract altbootcmd values and then again after to
compare the result.
[trini: Perform migration to defconfigs, reword commit message] Signed-off-by: Tom Rini <trini@konsulko.com>
Tom Rini [Thu, 13 Feb 2025 15:52:16 +0000 (09:52 -0600)]
Merge patch series "test: Complete the suite migration"
Simon Glass <sjg@chromium.org> says:
This series completes the removal of test commands for suites. With this
it is possible to declare a suite (including init and uninit functions)
without needing to write a command.
It also adds timing for test suites, so we can keep track of how long
things take.
ZHANG Yuntian [Tue, 11 Feb 2025 07:30:27 +0000 (15:30 +0800)]
mbedtls/external: remove broken git submodule
When we squash imported mbedtls, the git submodule "framework" was
preserved in the commit. However, U-Boot itself does not use git
submodule, and provides no .gitmodules file to specify the submodule
repository.
This is normally not an issue when cloning U-Boot repository. However,
when U-Boot is imported as a submodule, this will break git option
`--recurse-submodules` as it fails to resolve "framework".
As we do not use the submodule, remove it to unbreak existing workflows.
Svyatoslav Ryhel [Sat, 28 Dec 2024 13:21:03 +0000 (15:21 +0200)]
board: transformer-t30: fix model detection
PCBID1 seems to be high not only on TF600T, but on TF700T as well,
that caused boot failure for TF700T. Switching PCBID1 to PCBID7
should fix this issue.
Co-developed-by: Ion Agorria <ion@agorria.com> Signed-off-by: Ion Agorria <ion@agorria.com> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
net-lwip:
* Fix incorrect selection of ethernet device on boards having more than
one
* Fix TFTP option processing
* Make the WGET_HTTPS Kconfig symbol depend on DM_RNG
net/lwip/wget.c/mbedtls_hardware_poll() is calling dm_rng_read() but
dependency is not recorded anywhere that's why depend on DM_RNG
when WGET_HTTPS is used.
Suggested-by: Michal Simek <michal.simek@amd.com> Co-developed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org> Tested-by: Michal Simek <michal.simek@amd.com>
Find_option() is used to retrieve the block size value in an option
acknowledgment in response to a request containing a block size option
according to RFC2348.
The format of an OACK response is described in RFC2347 as
The current implementation of find_option() only works if
* blksize is the first option
* lwip_strnstr() ignores the length parameter,
i.e. is implemented via strstr()
The OACK messages starts with 0x00 0x06. If 'blksize' is the first option,
strstr() reports a match when the first parameter points to 0x06. Adding
the string length of 'blksize' plus 2 to the location of the 0x06 byte
points to the value.
Find_option() would report a match for option 'blksize' if the response
contained an option called 'foo_blksize_bar'. In this case find_option()
would return 'bar' as the value string.
If 'blksize' were the second option, find_option() would return a pointer
to the second character of the value string.
Furthermore find_option() does not detect if the value string is NUL
terminated. This may lead to a buffer overrun.
Provide an implementation that correctly steps from option to option.
Fixes: 27d7ccda94fa ("net: lwip: tftp: add support of blksize option to client") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org> Tested-by: Jerome Forissier <jerome.forissier@linaro.org> (qemu_arm64_lwip) Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Jerome Forissier [Thu, 30 Jan 2025 08:22:20 +0000 (09:22 +0100)]
net: lwip: move eth_init() out of new_netif()
Move the initialization of the ethernet devices out of the new_netif()
function. Indeed, new_netif() accepts a struct device argument, which
is expected to be valid and active. The activation and selection of
this device are achieved by eth_init() (on first time the network
stack is used) and eth_set_current(). This is what takes care of the
ethrotate and ethact environment variables. Therefore, move these calls
to a new function: net_lwip_set_current(), and use it whenever a
net-lwip command is run.
This patch hopefully fixes the incorrect net-lwip behavior observed on
boards with multiple ethernet interfaces [1].
Tested on an i.MX8MPlus EVK equipped wih two ethernet ports. The dhcp
command succeeds whether the cable is plugged into the first or second
port.
Alexander Dahl [Mon, 15 Apr 2024 07:57:55 +0000 (09:57 +0200)]
mtd: nand: raw: atmel: Fix pulse read timing for certain NAND flashes
From reading the S34ML02G1 and the SAM9X60 datasheets again, it seems
like we have to wait tREA after rising RE# before sampling the data.
Thus pulse time must be at least tREA.
Without this fix we got PMECC errors when reading, after switching to
ONFI timing mode 3 on SAM9X60 SoC with S34ML02G1 raw NAND flash chip.
The approach to set timings used before worked on sam9g20 and sama5d2
with the same flash (S34ML02G1), probably because those have a slower
mck clock rate and thus the resolution of the timings setup is not as
tight as with sam9x60.
The approach to fix the issue was carried over from at91bootstrap, and
has been successfully tested in at91bootstrap, U-Boot and Linux.
ARM: dts: at91: Align pinctrl node with Linux Devicetree
The GPIO banks are added as sub nodes or child nodes under the
pinctrl node (as per Linux ABI) and the reg property which points
to an array of controllers physical base address is removed
to align with the Linux devicetree.
pinctrl: at91: Add support to align with Linux Devicetree
U-Boot pinctrl driver expects a reg property explicitly unlike linux.
To align the DT of U-boot with the Linux, reg property is also arrvied
from child GPIO bank nodes when configured under the pinctrl node.
pinctrl: at91: Bind GPIO driver to the pinctrl DT node
In Linux DT,the pinctrl node acts as parent nodes with all other
gpio banks as child nodes and a single driver in Linux handles both
pinctrl settings and gpio requests.Current U-Boot DT maintains both
pinctrl and gpio nodes as separate nodes and offers two different class
of U-Boot drivers: UCLASS_PINCTRL which handles pin functions and
UCLASS_GPIO which handles gpio requests. In order to align the DT
of U-Boot with the DT of Linux, a hook is been added in the pinctrl
driver to bind the gpio driver with the pinctrl driver so that
when adding gpio nodes as subnodes to pinctrl node (as per the Linux ABI),
the corresponding APIs will be redirected and handled by valid
drivers attached to the pinctrl driver.
projects / thirdparty / u-boot.git / log
