Variables that are only used locally in a module should not be exported.
* Make the HII test data variables static.
* Remove unused GUIDs.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Bastien Curutchet <bastien.curutchet@bootlin.com> says:
Hi all,
This patch series aims to add DM support for the AEMIF controller that
can be found in the DaVinci SoCs.
This controller has already a driver used by the Keystone SoCs so I
add my work to it.
As we can now easily import Linux device-trees, I try to stick the
most I can to the Linux bindings of the AEMIF controller. To do so I add
an 'intermediate' driver called 'ti-aemif-cs'. It's in charge of
configuring timings for a given chip select of the AEMIF controller.
Link: https://lore.kernel.org/r/20241021151330.1860929-1-bastien.curutchet@bootlin.com
The Linux bindings of the AEMIF offer properties that specify the
transaction timings for each chips select.
Add parsing of these properties to calculate the chip select's
configuration from them and the rate of the AEMIF's reference clock.
Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
The AEMIF's bindings in the Linux tree have a node for the AEMIF
controller and then a node for each AEMIF's chip select. This CS node
doesn't have a compatible property but describes the timing parameters
used by a given chip select.
The U-Boot DM framework expects every node to have a 'compatible'
property. If no 'compatible' is present in a node, its children won't be
parsed by u-boot.
Add DM support to the ti-aemif driver.
Add a new ti-aemif-cs driver to comply with the Linux bindings and the
U-Boot's DM philosophy. This driver handles the timing parameters
of an AEMIF's chip select so move aemif_cs_configure() from ti-aemif.c
to ti-aemif-cs.c.
Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
Wrap the CS configuration into a aemif_configure_cs() to ease its
migration to another driver when adding DM support.
Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
TI_AEMIF configuration doesn't depend on ARCH_DAVINCI while the AEMIF
controller is present in the DaVinci SoCs.
Add ARCH_DAVINCI to the potential users of the TI_AEMIF driver
Add <asm/io.h> to driver's includes to fix build issue on ARCH_DAVINCI
Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
AEMIF controller is present on other SoCs than the Keystone ones.
Remove Keystone specificities from the driver to be able to use it from
other architectures.
Adapt the ks2_evm/board.c to fit the new driver.
Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Fix following CHECK pointed out by checkpatch:
CHECK: Macro argument 'cs' may be better as '(cs)' to avoid precedence issues
#62: FILE: drivers/memory/ti-aemif.c:15:
+#define AEMIF_CONFIG(cs) (0x10 + (cs * 4))
Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
The "dollar" tests require CONFIG_CONSOLE_RECORD to be enabled so guard
with that.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Tom Rini <trini@konsulko.com>
Currently, the "dm" suite in unit tests (ut) is only available on
sandbox. Make sure that all cmd tests that are part of this suite are
only available on sandbox and not attempted to be run on hardware (where
it will fail to be able to be started).
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Tom Rini <trini@konsulko.com>
These were missed when removing the rest of the tricorder platform.
Fixes: d137604c20 ("arm: Remove tricorder board")
Signed-off-by: Tom Rini <trini@konsulko.com>
Mark all the functions that are only defined locally as static and
quiesce W=1 warnings
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
[trini: Add __maybe_unused as it's now seen as unused in some cases]
Signed-off-by: Tom Rini <trini@konsulko.com>
lmb_alloc_flags() & lmb_alloc_base_flags() are just a wrappers for
_lmb_alloc_base(). Since the only difference is the max address of the
allowed allocation which _lmb_alloc_base() already supports with the
LMB_ALLOC_ANYWHERE flag, remove one of them.
Keep the lmb_alloc_base_flags() which also prints an error on failures
and adjust efi_allocate_pages() to only use one of them.
While at it clean up the duplicate function description from the header
file.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
We never call lmb_map_update_notify() without checking the result of
lmb_should_notify(). Instead of running that function everytime fold it
in there and add the additional flags parameter
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
The function description says this should return 0 or -1 on failures.
When regions coalesce though this returns the number of coalescedregions
which is confusing and requires special handling of the return code.
On top of that no one is using the number of coalesced regions.
So let's just return 0 on success and adjust our selftests accordingly
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>
efi_loader.h is included twice. Remove one and move the other in
alphabetical order
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Due to the removal of weak functions in 7d6cee2cd0 ("cmd: cache: Remove
weak function"), U-Boot fails to compile after updating to v2024.10 for
mediatek target in OpenWrt with GCC-14 with error:
cmd/cache.c: In function 'do_dcache':
cmd/cache.c:57:25: error: implicit declaration of function
'noncached_set_region' [-Wimplicit-function-declaration]
Thus, provide a prototype in include/cpu_func.h to fix a build
error in cmd/cache.c, since related prototypes are also located there.
The issue occurred after the update of uboot-mediatek in OpenWrt to
v2024.10, in combination with GCC-14 toolchain. It was reported and
discussed in https://github.com/openwrt/openwrt/issues/16697, and
temporarily fixed with
92ca322dd1.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/issues/16697
Link: 92ca322dd1
Fixes: 7d6cee2cd0 ("cmd: cache: Remove weak function")
Signed-off-by: Tom Rini <trini@konsulko.com>
Currently, a number of generic cache related functions have their common
prototype declared in include/cpu_func.h. Move the current set of
noncached functions there as well to match.
Signed-off-by: Tom Rini <trini@konsulko.com>
They were added with commit 0e9d23945c ("net: eqos: implement callbaks
to get interface and set txclk rate") but were not removed with
commit 5fc783b5d9 ("net: dwc_eth_qos: move i.MX code out") when i.MX
specific code was moved to a separate file.
Signed-off-by: Erik Schumacher <erik.schumacher@iris-sensing.com>
The EQOS on i.MX93 fails to finish the reset procedure in RMII mode.
This is described in errata ERR051683. This patch implements the
provided workaround which sets the PS and FES bits after the SWR is set
by using the eqos_fix_soc_reset function.
Adapted from linux-kernel commit b536f32b5b03 ("net: stmmac: dwmac-imx:
use platform specific reset for imx93 SoCs")
Signed-off-by: Erik Schumacher <erik.schumacher@iris-sensing.com>
This patch adds support for optional platform specific reset logic in
the dwc_eth_qos driver. This new function 'eqos_fix_soc_reset' is called
after the EQOS_DMA_MODE_SWR is set and before the driver waits for this
bit to clear.
Signed-off-by: Erik Schumacher <erik.schumacher@iris-sensing.com>
The Emcraft Systems NavQ+ kit is a mobile robotics platform
based on NXP i.MX8 MPlus SoC.
The following interfaces and devices are enabled:
- eMMC
- Gigabit Ethernet (through eQOS interface)
- SD-Card
- UART console
The device tree file is taken from upstream Linux Kernel
through OF_UPSTREAM
Signed-off-by: Gilles Talis <gilles.talis@gmail.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Loading flash.bin using uuu fails when flash.bin does not have the
right size.
When flash.bin is loaded from some storage medium (sd card/emmc), SPL
just loads some random garbage bytes from beyond what has been
populated when flash.bin was written, but when loaded via uuu, SPL
hangs waiting for the host to send the expected number of bytes. Which
is (size of FIT image aligned to 0x1000)+CONFIG_CSF_SIZE. The
alignment to 0x1000 is already done and is necessary in all cases
because that's the exact expected location of the 32 byte IVT
header. But the IVT+CSF blob tacked onto the end must be a total of
CONFIG_CSF_SIZE.
This is exactly the same fix as 89f19f45d6, except that this time
around I don't know how to cleanly get CONFIG_CSF_SIZE.
Fixes: bc6beae7c5 (binman: Add nxp_imx8mcst etype for i.MX8M flash.bin signing)
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Tested-by: Heiko Schocher <hs@denx.de>
The Aspeed SGPIO driver supports the SGPIO controllers found in the
AST2400, AST2500 and AST2600 BMC SoCs. The implementation is a cut-down
copy of the upstream Linux kernel driver, adapted for u-boot.
Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
The boot_fdt_add_mem_rsv_regions() function reserves the memreserve and
reserved-memory regions. These regions are being set with the LMB_NONE
flag which allows overwriting and re-using the regions. This was fine
earlier when the LMB memory map was local and not enforced
globally. But that is no longer the case. Mark these regions as
LMB_NOOVERWRITE so that they cannot be used.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reported-by: Vaishnav Achath <vaishnav.a@ti.com>
When printing the LMB flags for a memory region, there is a need to
check that the array index that is computed is a sane value. Put a
noisy assert in case this check fails, as that implies something with
the LMB code is not working as expected.
Reported-by: Coverity (CID 510463)
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
/Makefile already adds lib include paths to UBOOTINCLUDE. There is no point
in adding the same paths again.
Clearly separate the lines relating to NET and to NET_LWIP.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
People complained that enabling (SPL_)DM_WARN was now totally unusable
due to the amount of messages printed on the console.
Let's downgrade the log level of some messages that are clearly not on
the error path.
Note that there's one pr_debug in there, because it is followed by
pr_cont so it made sense to reuse the same family of functions.
Reported-by: Alexander Dahl <ada@thorsis.com>
Fixes: 6afdb15851 ("dm: core: migrate debug() messages to use dm_warn")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Jan Kiszka <jan.kiszka@siemens.com> says:
This adds support for the new IOT2050 SM variant, introduces a sysinfo
driver which also permits SMBIOS support and switches the board to
OF_UPSTREAM. There are some further fixes for the boards included as well.
Not yet included is configuration support for DMA isolation via the PVU as
this depends on not yet merged DT bindings and another overlay.
[trini: This is just the first 10 patches in the series for now]
Link: https://lore.kernel.org/r/cover.1729577070.git.jan.kiszka@siemens.com
Main differences between the new variant and Advanced PG2:
1. Arduino interface is removed. Instead, an new ASIC is added for
communicating with PLC 1200 signal modules.
2. USB 3.0 type A connector is removed, only USB 2.0 type A connector is
available.
3. DP interface is tailored down. Instead, to communicate with the
PLC 1200 signal modules, a USB 3.0 type B connector is added but the
signal is not USB.
4. DDR size is increased to 4 GB.
5. Two sensors are added, one tilt sensor and one light sensor.
Signed-off-by: Baocheng Su <baocheng.su@siemens.com>
[Jan: rebased over OF_UPSTREAM]
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
The U-Boot copy of the mpfs devicetree has, in general, been neglected
somewhat in comparison to the one in Linux. Moving to OF_UPSTREAM to
keep both in sync should serve to eliminate that discrepancy.
Additionally, moving to OF_UPSTREAM will let U-Boot automatically pick
up the devicetree rework that is in progress at [1].
Link: https://lore.kernel.org/all/20241002-private-unequal-33cfa6101338@spud/ [1]
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
The clock driver for PolarFire SoC now requires syscon and regmap
features, so imply them to preserve implication of the clock driver.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Why get a devicetree description wrong once when you can get it wrong
twice? The original mistake, which the driver supports was failing to
describe the main PLL that the "cfg" and "periph" clocks parented by.
The second mistake was describing the "cfg" and "periph" clocks a
reg region within the clock controller, rather as two registers within
a syscon region that also contains pinctrl, interrupt muxing controls
and other functions.
Make up for lost time and describe these regions as they should have
been originally, preserving support for the existing two configurations
for the sake of existing systems with firmware-provided devicetrees.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
If we take an exception before u-boot is relocated, there's a good
chance we will end up in an endless loop of exceptions because resume is
invalid until after relocation.
Signed-off-by: Anton Blanchard <antonb@tenstorrent.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Align U-Boot with QEMU amd-microblaze-v-virt platform to be able to wire
it with CI.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Padmarao Begari <padmarao.begari@amd.com>
This requires some tweaking of the defconfig and
board_fit_config_name_match so that the new sources are taken into
account.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
To allow firmware to pick up all DTs from here, move the overlays that
are normally applied during DT fixup to the kernel source as well. Hook
then into the build nevertheless to ensure that regular checks are
performed.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Link: https://lore.kernel.org/r/91f8b825467651ebd51a4051f153ab136eeb1849.1724830741.git.jan.kiszka@siemens.com
Signed-off-by: Nishanth Menon <nm@ti.com>
[ upstream commit: dba27d026fc841d28a0ed373f617cc84ec0e4504 ]
(cherry picked from commit 741915246a92fc4c21537f9623a69612f7cef03a)
The PG1 A variant of the iot2050 series has been identified which
partially lacks support for lock-step mode. This implies that all
iot2050 boards can't support this mode. As a result, lock-step mode has
been disabled across all iot2050 boards for consistency and to avoid
potential issues.
Signed-off-by: Li Hua Qian <huaqian.li@siemens.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Link: https://lore.kernel.org/r/d1f5f84db7a1597cd29628a0b503e578367b7b40.1724830741.git.jan.kiszka@siemens.com
Signed-off-by: Nishanth Menon <nm@ti.com>
[ upstream commit: e0133f883cf115d9e97e704169a9fb6003caefb2 ]
(cherry picked from commit 4b4872feb66a9043741819a57af280ffb4a96608)
We can simply use the default DT, Basic PG1, because no nodes that are
different between the variants play a role for SPL. Will help with the
migration to OF_UPSTREAM.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
The fdt fixup logic actually also applies to other possible variants who
also have device tree overlays. So generalize this part by extracting
it from the m.2 specific function and make it a standalone one.
Since now we only have M.2 variant consuming the overlay, it may not
have immediate effect for other variant, however this makes the future
variant more easier to apply fdt fixups.
Signed-off-by: Baocheng Su <baocheng.su@siemens.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Due to new DDR size introduction, the current logic of determining the
DDR size is not able to get the correct size.
Instead, the DDR size is determined by the FSBL(SEBOOT) then passed to
u-boot through the scratchpad info.
The SEBoot version must be >= D/V01.04.01.02 to support this change.
Also now for some variants, the DDR size may > 2GB, so borrow some code
from the TI evm to iot2050 to support more than 2GB DDR.
Signed-off-by: Baocheng Su <baocheng.su@siemens.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
