For armv8, U-Boot uses a static map defined as 'mem_map' for configuring
the MMU's page tables, done by mmu_setup.
Though this works well for simpler platforms, it makes creating runtime
carveouts by modifying the static array at runtime exceedingly complex
like in mach-snapdragon/board.c.
Creation of such carveouts are much better handled by APIs such as
mmu_change_region_attr once the page tables are configured. Usually such
carveouts are configured via the device-tree's reserved-memory node
which provides the address and size for the carveout.
Therefore this patch adds mmu_unmap_reserved_mem which acts as a wrapper
over mmu_change_region_attr, helping unmap a reserved-memory region.
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Tested-by: Wadim Egorov <w.egorov@phytec.de>
The static memory map for K3 (k3_mem_map) only maps the first DRAM bank
and therefore doesn't scale for platforms with multiple memory banks.
This patch modifies enable_caches to add mem_map_from_dram_banks which
appends all the memory banks to k3_mem_map before calling mmu_setup.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Tested-by: Wadim Egorov <w.egorov@phytec.de>
For armv8, U-Boot uses a static map defined as 'mem_map' for configuring
the MMU as part of mmu_setup.
But since the exact configuration of memory banks might not be known at
build time, many platforms such as imx9, versal2 etc. utilize
gd->bd->bi_dram to configure the static map at runtime.
Therefore this patch adds a new API mem_map_from_dram_banks that
modifies the static map in a similar way. Allowing the caller to map all
dram banks by just passing the index to last entry in their mem_map and
it's length.
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Tested-by: Wadim Egorov <w.egorov@phytec.de>
In dcache_enable, currently the dcache entries are only invalidated when
the MMU is not enabled. This causes issues when dcache_enable is called
with the MMU already configured, in such cases the existing dcache
entries are not flushed which might result in un-expected behavior.
This patch invalidates the cache entries on every call of dcache_enable
before enabling dcache (by setting CR_C). This makes dcache_enable
behave similar to icache_enable as well.
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Tested-by: Wadim Egorov <w.egorov@phytec.de>
The mmu_setup function configures the page tables based on the board
supplied mem_map struct array. It is called implicitly as part of
dcache_enable but this limits us to only be able to use APIs such as
mmu_change_region_attr only after caches are enabled.
This might lead to speculative accesses before we can unmap a region
that is marked as cacheable in the static memory map.
Therefore this patch exports the mmu_setup function in mmu.h allowing
users to have more control over when the mmu is configured.
For K3 specifically this allows for the following configuration sequence
as part of enable_caches:
static mem_map fixups (TODO) -> mmu_setup -> carveouts using
mmu_change_region_attr (TODO) -> icache/dcache enable
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Tested-by: Wadim Egorov <w.egorov@phytec.de>
U-Boot's provided enable_caches enforces the following sequence:
icache_enable -> mmu_setup (as part of dcache_enable) -> dcache_enable
Whereas for K3 devices, we would like to add entries to the provided
static array (k3_mem_map) as per gd->bd->bi_dram and then call mmu_setup
to configure the MMU but also create carveouts for TFA/TEE before we
enable caches to prevent speculative accesses to the region. Thus the
following desired sequence:
add dram banks -> mmu_setup -> carveout TFA/TEE -> icache/dcache enable
Therefore this patch adds K3's own implementation of enable_cache for
ARM64, allowing for greater control over the cache enablement sequence.
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Tested-by: Wadim Egorov <w.egorov@phytec.de>
The K3 family of SoCs encompasses a wide variety of devices with varying
DDR configurations and memory carveout requirements, the current static
memory map provides basic support for TI EVMs but does not scale well
for newer platforms (such as AM62SiP with 512MiB of RAM).
Therefore this patch replaces the existing memory map with a minimal
one, that could be more easily modified at runtime.
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Tested-by: Wadim Egorov <w.egorov@phytec.de>
Pull request net-20251022
net:
- airoha: improvements
- Tighten a few more driver dependencies
- designware: fix bitbang init error
- phy: Make driver overloading get_phy_id depend on !COMPILE_TEST
- phy: add paged PHY register accessors
- make dhcp_run() common for NET and NET_LWIP
- dwc_eth_ops: Correct check for FDT_64BIT
- mediatek: mt7988: various fixup + MDIO detach
- phy: aquantia: switch to use phy_get_ofnode(), fix bindings typo
net-legacy:
- bootp: Prevent buffer overflow to avoid leaking the RAM content
- tftp: make TFTP ports unconditionally configurable
misc:
- uthreads: Make use of CONFIG_IS_ENABLED consistently
First set of u-boot-at91 features for the 2026.01 cycle:
This small fixes set includes a change on clocks register value and a
fix for the sam9x60ek default timer.
The Synchronous Abort and reset errors occurred due
to incorrect parameter passing during initialization.
Signed-off-by: Jim Liu <JJLIU0@nuvoton.com>
[jf: add missing #if IS_ENABLED(CONFIG_BITBANGMII)]
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
With commit 597fe041a8 ("net/phy: enable get_phy_id redefinable") we
made get_phy_id a public but weak function, so that PHY drivers that had
required non-standard ways of getting the PHY ID could be supported.
However, overloading a weak function multiple times is (rightly) a link
error. At this point, we have two PHYs which make use of this feature,
so make both of them only available when COMPILE_TEST is unset, as part
of being able to support "allyesconfig" in the future.
Signed-off-by: Tom Rini <trini@konsulko.com>
CVE-2024-42040 describes a possible buffer overflow when calling
bootp_process_vendor() in bootp_handler() since the total length
of the packet is passed to bootp_process_vendor() without being
reduced to len-(offsetof(struct bootp_hdr,bp_vend)+4).
The packet length is also checked against its minimum size to avoid
reading data from struct bootp_hdr outside of the packet length.
Signed-off-by: Paul HENRYS <paul.henrys_ext@softathome.com>
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
Synchronize paged PHY helpers with Linux v6.17.
Add support for PHY devices that use paged register access by
implementing the following functions:
- phy_save_page(): Save current page number
- phy_select_page(): Switch to a specific page and return previous page
- phy_restore_page(): Restore previously saved page
Also adds read_page and write_page callbacks to the phy_driver
structure to enable driver-specific page handling.
These helpers allow safe access to paged PHY registers by ensuring
proper page selection and restoration,
even in error conditions, which will be used by the Airoha PHY driver.
Signed-off-by: Lucien.Jheng <lucienzx159@gmail.com>
According to commit 997786bbf4 ("drivers/net/airoha_eth: fix stalling
in package receiving") the minimal possible value of SYS_RX_ETH_BUFFER
is 4. Unfortunately it's too small for reliable ping.
Observations shows that SYS_RX_ETH_BUFFER must be at least 8.
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
The commit 997786bbf4 ("drivers/net/airoha_eth: fix stalling in package
receiving") can be improved. Instead of returning previous descriptor
it's possible:
* do nothing in even descriptor case
* return 2 descriptor to the queue (current and previous) in the odd
descriptor case.
This patch:
* implements above approach
* remove logic not required within new approach
* adds note that PKTBUFSRX must be even and larger than 7
for reliable driver operations
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
There are currently two implementations of dhcp_run(): one in cmd/net.c
for NET and one in net/lwip/dhcp.c for NET_LWIP. There is no
justification for that. Therefore, move the NET version into
net/net-common.c to be used by both stacks, and drop the NET_LWIP
version which by the way does not look totally correct.
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Suggested-by: Tom Rini <trini@konsulko.com>
Acked-by: Benjamin Hahn <B.Hahn@phytec.de>
In preparation for support of MDIO on AN7581, move the MT7531 MMIO logic
to a dedicated driver and permit usage of the mdio read/write function
to the mtk_eth driver.
This only affect MT7988 that can use MMIO operation to access the Switch
register. The MT7988 code is updated to make use of the external driver.
This permits Airoha driver to make use of DM_MDIO to bind for the MT7531
driver that have the same exact register.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Correctly free the MDIO Bus on calling cleanup function. While at it
also fix a copy-paste error and rename the cleanup function name to the
more specific name.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
On exiting the phy_setting function for MT7988, the PHY page is never
restored to Page 0. This can cause all kind of problem with reading the
status of the PHY at runtime.
Correctly restore PHY page on exiting the PHY setting function.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
The PHY for MT7531/MT7988 are never actully turned ON/OFF for the
affected PHY as we are read/writing to the wrong PHY address.
This is caused by the fact that we use the MT753X_PHY_ADDR macro 2
times offsetting the address multiple times.
One in the _setup() function and one in the mt7531_mii_read/write.
Drop the additional usage of MT753X_PHY_ADDR in setup() to correctly
set the PHY.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
In this case, the mediatek network drivers cannot build outside of
ARCH_MEDIATEK or ARCH_MTMIPS, and so express this requirement in Kconfig
as well. In the case of DWC_ETH_XGMAC / DWC_ETH_XGMAC_SOCFPGA, the file
controlled by the DWC_ETH_XGMAC option references a socfpga-specific
array defined in the file controlled by DWC_ETH_XGMAC_SOCFPGA. Rework
these options in Kconfig to handle this dependency.
Signed-off-by: Tom Rini <trini@konsulko.com>
It has been over a decade since we had a platform that implemented the
bootp vendor extension support hook. Remove this option due to lack of
use.
Signed-off-by: Tom Rini <trini@konsulko.com>
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>
The support found under SYS_FAULT_ECHO_LINK_DOWN requires that the
SYS_FAULT_MII_ADDR symbol also be set. This wasn't previously found in
Kconfig, so add it now.
Signed-off-by: Tom Rini <trini@konsulko.com>
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>
Some drivers which depend on SoCFPGA specific headers had not had
appropriate dependencies list in Kconfig. Add ARCH_SOCFPGA or
TARGET_SOCFPGA_SOC64 where appropriate.
Signed-off-by: Tom Rini <trini@konsulko.com>
We do not yet support UTHREADS in xPL phases. However, we have the need
to dummy out certain functions so that xPL can build when full U-Boot
has UTHREADS enabled. Update the few places that need to use
CONFIG_IS_ENABLED so that we have the correct dummy in xPL.
Signed-off-by: Tom Rini <trini@konsulko.com>
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>
A few lines of code being guarded by the CONFIG_TFTP_PORT option seems
an unnecessary restriction on the TFTP support provided by a vanilla
U-Boot image. In cases where the TFTP server cannot run as superuser -
and hence cannot run on the well-known port 69 - this quirk incurs a
full reconfiguration and rebuild of the bootloader only in order to
select the appropriate destination port.
Remove the CONFIG_TFTP_PORT option entirely and make the tftpdstp and
tftpsrcp variables always have an effect. Their being unset will mean
that U-Boot behaves the same as if CONFIG_TFTP_PORT was unset. Update
the documentation accordingly. And fix up the single board which was
originally enabling this option.
Signed-off-by: Alvin Šipraga <alvin@pqrs.dk>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
The email forwarder I'm using has run into severe problems with Gmail
lately. Switch over to my kernel.org address.
Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
The A/B update strategy of the env's has a gap in the first 2 calls of saveenv.
The env's are stored twice on the first memory area if:
gd->env_valid == ENV_INVALID.
u-boot=> saveenv
Saving Environment to MMC... Writing to MMC(1)... OK
u-boot=> saveenv
Saving Environment to MMC... Writing to MMC(1)... OK <-- !!!
u-boot=> saveenv
Saving Environment to MMC... Writing to redundant MMC(1)... OK
u-boot=> saveenv
Saving Environment to MMC... Writing to MMC(1)... OK
This is the same issue as resolved in commit e589d5822c ("env: spi:
Fix gd->env_valid for the first write")
Signed-off-by: Michael Glembotzki <Michael.Glembotzki@iris-sensing.com>
Signed-off-by: Jasper Orschulko <jasper@fancydomain.eu>
Signed-off-by: Michael Heimpold <mhei@heimpold.de>
[trini: Amend the commit message]
---
Changes in v2:
- Rebase to current master
- Amend the commit message to reference the SPI version of this fix,
which had significant follow-up discussion.
When falcon mode is enabled and SPL_OS_BOOT_SECURE is not enabled,
restore the previous default behavior of having an args file be
expected. Platforms which are using a FIT image here and do not need
this can update at their convenience to disable this option now.
Fixes: b1a3ed0688 ("spl: make args file optional in falcon mode")
Signed-off-by: Tom Rini <trini@konsulko.com>
Anshul Dalal <anshuld@ti.com> says:
Continuing from the last series[1], this patch series addresses the requirement
to disable the args file in falcon mode.
The args file is used in falcon mode for loading the device-tree for the kernel.
However in secure falcon mode, the expected payload is a FIT containing a signed
device-tree and kernel image. Thus removing the need to load the extra args
file in the first place. Also, loading the extra file without any authentication
mechanism exposes an attack vector and should therefore be disabled to keep the
boot secure.
This patch set builds on the last few to first optionally allow for loading the
args file in non-secure falcon boot flow [1/3] and then disable them altogether
in the next patch [2/3] for secure falcon mode.
[1]: https://lore.kernel.org/u-boot/20251006101057.4172248-1-anshuld@ti.com/
Link: https://lore.kernel.org/r/20251009115846.897186-1-anshuld@ti.com
The arg field of `struct spl_image_info` is used by jump_to_image_linux
as the argument for the kernel in falcon mode.
Since commit 601cebc29d ("cmd: spl: Remove ATAG support from this
command"), fdt is the only valid argument for kernel in falcon mode.
However fdt was only being set as the argument in nor and xip boot
modes, this patch fixes it for all boot modes and removes the now
redundant code from spl_nor and spl_xip.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
The expected payload for the SPL in secure falcon mode is a fitImage
that contains the kernel image and the DT. This removes the need to load
an additional args file, which exposes an additional attack vector since
it can not be verified.
Therefore this patch disables loading of the arg file when
SPL_OS_BOOT_SECURE is set.
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Falcon mode loads a kernel file and an args file which is the
device-tree. However in the case of kernel file being a FIT that
contains the device-tree within it, loading the args file is not
required.
Therefore, this patch introduces a new SPL_OS_BOOT_ARGS config options
that allows us to enable or disable loading of the args file in falcon
mode.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Anshul Dalal <anshuld@ti.com> says:
Continuing from the last series[1], this patch series addresses the requirement of
allowing no fallbacks in secure falcon mode.
To do this in a clean way, all the falcon mode logic for each boot media was
refactored to a corresponding *_load_image_os function whereas the regular
boot is implemented in *_load_image, this allows us to easily return early in
case the *_load_image_os function fails with secure mode enabled.
The series also introduces the new SPL_OS_BOOT_SECURE config symbol which
enables secure falcon boot flow.
The generic flow after the patch series looks as follows:
static int spl_<bootmedia>_load_image(...) {
if (CONFIG_IS_ENABLED(OS_BOOT)) {
ret = spl_<bootmedia>_load_image_os(...);
puts("Failcon mode failed\n");
if (CONFIG_IS_ENABLED(OS_BOOT_SECURE)) {
puts("no fallback allowed!\n");
return ret;
}
puts("Falling back to U-Boot\n");
}
/* Regular boot flow */
}
[1]: https://lore.kernel.org/u-boot/20250923124639.667718-1-anshuld@ti.com/
Link: https://lore.kernel.org/r/20251017193318.4124997-1-anshuld@ti.com
Instead of falling back to the standard U-Boot boot flow, we should just
halt boot if the expected boot flow in falcon mode fails.
This prevents a malicious actor from accessing U-Boot proper if they can
cause a boot failure on falcon mode.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
This patch moves the falcon mode handling logic out of
spl_ubi_load_image to spl_ubi_load_image_os, this allows for cleaner
handling for fallback to U-Boot in case falcon mode fails.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
This patch moves the falcon mode handling logic out of
spl_nor_load_image to spl_nor_load_image_os, this allows for cleaner
handling for fallback to U-Boot in case falcon mode fails.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
This patch moves the falcon mode handling logic out of
spl_spi_load_image to spl_spi_load_image_os, this allows for cleaner
handling for fallback to U-Boot in case falcon mode fails.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
This patch moves the falcon mode handling logic out of
spl_ubi_load_image to spl_ubi_load_image_os, this allows for cleaner
handling for fallback to U-Boot in case falcon mode fails.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Currently the logic to handle falcon mode as well as the regular boot is
inside spl_mmc_do_fs_boot, this prevents us from cleanly extending
falcon mode functionality like toggleable fallback to U-Boot proper.
Therefore this patch splits the logic into spl_mmc_fs_load and
spl_mmc_fs_load_os to handle the regular boot and falcon mode use case.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
This patch adds the new SPL_OS_BOOT_SECURE symbol that enables secure
boot flow in falcon mode. This symbol can be used to disable certain
inherently insecure options during falcon boot.
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Anshul Dalal <anshuld@ti.com>
This reverts commit a040578d82.
Based on feedback other SOCs (for example Star64) are using driver in non
DMA mode which is causing issues that's why revert this patch.
cdns,is-dma should be removed differently.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Reported-by: E Shattow <e@freeshell.de>
Pull request efi-2026-01-rc1
CI:
* https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/27944
Documentation:
* samsung: Extend E850-96 documentation to be comprehensive
* environment: fix links to Linux kernel documentation
* sandbox: fix typos
* document dmareset command
* ti: j722s_evm: drop outdated boot note
UEFI:
* Prevent leak of memory from tmp_files
* Correctly check if the HTTP protocol is found
* Use ESRT_FW_TYPE_SYSTEMFIRMWARE instead of ESRT_FW_TYPE_UNKNOWN
* dbginfodump: use guid definition
Others:
* lib/uuid: add support for efi debug image info table guid
The j722s_evm support is now largely complete and is certainly
not limited to UART boot so drop the confusing note from the docs.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Add the EFI Debug Image Info Table GUID to the translation table used by
uuid_guid_get_str().
This allows to print a human readable table name with `efidebug tables'
instead of "(unknown)".
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Tom Rini <trini@konsulko.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
We currently set the firmware image type to ESRT_FW_TYPE_UNKNOWN.
The spec defines the following:
ESRT_FW_TYPE_UNKNOWN 0x00000000
ESRT_FW_TYPE_SYSTEMFIRMWARE 0x00000001
ESRT_FW_TYPE_DEVICEFIRMWARE 0x00000002
ESRT_FW_TYPE_UEFIDRIVER 0x00000003
Since we don't support updating DEVICEFIRMWARE or UEFIDRIVER types,
let's switch over to SYSTEMFIRMWARE which seems more appropriate.
Suggested-by: Michal Simek <michal.simek@amd.com>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
