Sync the devicetree files from the official Linux kernel tree, v6.10.
This is covering Allwinner SoCs with 32-bit and 64-bit ARM cores.
Besides mostly cosmectic changes, this adds cpufreq support to H616
boards, Nothing that U-Boot needs for itself, but helpful to pass on
to kernels. We also get the .dts files for the Tanix TX1 TV box and
three Anbernic handheld gaming devices.
As before, this omits the non-backwards compatible changes to the R_INTC
controller, to remain compatible with older kernels.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
C99 introduced the possibility to mark function parameters declared as
arrays with an extra keyword "static":
void foo(uint8_t digest[static SHA256_DIGEST_LENGTH]);
This requires the respective function argument to be at least as large
as specified. Passing in random pointers (like NULL) then becomes
undefined behaviour, and compilers warn about this.
Newer GCC compilers (starting with GCC 14) will also automatically mark
those parameters as "nonnull", and thus warn if a (redundant) NULL check
is done inside the function:
tools/sunxi_toc0.o tools/sunxi_toc0.c
tools/sunxi_toc0.c: In function 'toc0_verify_cert_item':
tools/sunxi_toc0.c:447:12: warning: 'nonnull' argument 'digest' compared to NULL [-Wnonnull-compare]
447 | if (digest && memcmp(&extension->digest, digest, SHA256_DIGEST_LENGTH)) {
| ^
Remove the unnecessary NULL check from toc0_verify_cert_item(), to avoid
the warning.
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
[Andre: extend commit message]
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Simon Glass <sjg@chromium.org> says:
This series includes fixes to get some rockchip and nvidia boards
working again. It also drops the broken Beaglebone Black config and
provides a devicetree fix for coral (x86).
The code here is confusing due to large blocks which are #ifdefed out.
Add a function phase_sdram_init() which returns whether SDRAM init
should happen in the current phase, using that as needed to control the
code flow.
This increases code size by about 500 bytes in SPL when the cache is on,
since it must call the rather large rockchip_sdram_size() function.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present gd->ram_size is 0 in SPL, meaning that it is not possible to
enable the cache. Correct this by always populating the RAM size
correctly.
This increases code size by about 500 bytes in SPL, since it must call
the rather large rockchip_sdram_size() function.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
On some boards, the bloblist is created in SPL once SDRAM is ready. It
cannot be accessed until that point, so is not available early in SPL.
Add a condition to avoid a hang in this case.
This fixes a hang in chromebook_coral
Fixes: 70fe238594 ("fdt: Allow the devicetree to come from a bloblist")
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Raymond Mao <raymond.mao@linaro.org>
There is no need to remove input files. It makes it harder to diagnose
failures. Keep the payload file.
There is no test for this condition, but one could be added.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Sughosh Ganu <sughosh.ganu@linaro.org>
The tool must return an error code when invalid arguments are provided,
otherwise binman has no way of knowing that anything went wrong.
Correct this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: fab430be2f ("tools: add mkeficapsule command for UEFI...")
Tools cannot be assumed to be present. Add a check for this with the
mkeficpasule tool.
Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: b617611b27 ("binman: capsule: Add support for generating...")
Tools should have an option to obtain the version, so add this to the
mkeficapsule tool.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
The correct operating mode for the fan is inversed (1). The
previous pwm driver implementation had a bug and the polarity
information was propagated incorrectly to the kernel. The normal (0)
polarity specified in the device tree was incorrectly clearing the
polarity bit in the counter control register. After the bug fix,
setting the polarity to inversed (1) in the device tree will clear
the polarity bit.
Signed-off-by: Vishal Patel <vishal.patel@amd.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/4658ae8576882f5d28ad57ca74a7b798a546ec37.1722241096.git.michal.simek@amd.com
This enables boards to choose where to/from the environment
should be saved/loaded. They can then for example support using
the same device (dynamically) from which the bootloader was
launched to load and save env data and do not have to
define CONFIG_ENV_SPI_BUS statically.
In my use case, the environment needs to be on the same device I
booted from. It can be the QSPI or OSPI device.
I therefore would override spi_get_env_dev in the board code,
read the bootmode registers to determine where we booted from
and return the corresponding device index.
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Link: https://lore.kernel.org/r/20240614124811.22945-2-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com> # Move spi_get_env_dev to sf.c
Enable setting speed mode using mmc dev commands.
The speed mode is provided as the last argument in these commands
(ex: mmc dev 0 0 10) and is indicated using the index from enum
bus_mode in include/mmc.h. A speed mode can be set if it is enabled
from device tree or from capabilities register
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Link: https://lore.kernel.org/r/20240708091755.5021-1-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
This change adds support for PCIe connected nvme disk - phyBOARD-Polis
base board.
One needs to call following commands in u-boot:
> pci enum
> nvme scan
> nvme info
And then ones to access proper file system (like fat[ls|load|write],
ext4[ls|load|write]).
Signed-off-by: Lukasz Majewski <lukma@denx.de>
Enable the 'cpu' command to display the CPU info and release CPU core to
run baremetal or RTOS applications.
Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Enable the 'cpu' command and the depended imx CPU driver to
display the CPU info and release CPU core to run baremetal
or RTOS applications.
Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Add documentation for the 'cpu' command, taking NXP i.MX 8M Plus
as a example.
Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add a new subcommand 'release' to bring up a core to run baremetal
and RTOS applications.
For example on i.MX8M Plus EVK, release the LAST core to run a RTOS
application, passing the sequence number of the CPU core to release,
here it is 3:
u-boot=> cpu list
0: cpu@0 NXP i.MX8MP Rev1.1 A53 at 1200 MHz at 31C
1: cpu@1 NXP i.MX8MP Rev1.1 A53 at 1200 MHz at 30C
2: cpu@2 NXP i.MX8MP Rev1.1 A53 at 1200 MHz at 31C
3: cpu@3 NXP i.MX8MP Rev1.1 A53 at 1200 MHz at 31C
u-boot=> load mmc 1:2 c0000000 /hello_world.bin
66008 bytes read in 5 ms (12.6 MiB/s)
u-boot=> dcache flush; icache flush
u-boot=> cpu release 3 c0000000
Released CPU core (mpidr: 0x3) to address 0xc0000000
Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Increase one more bit to cover all CPU types. Otherwise it shows
wrong CPU info on some platforms, such as i.MX8M Plus:
U-Boot 2024.04+g674440bc73e+p0 (Jun 06 2024 - 10:05:34 +0000)
CPU: NXP i.MX8MM Rev1.1 A53 at 4154504685 MHz at 30C
Model: NXP i.MX8MPlus LPDDR4 EVK board
Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Add a new callback release_core to the cpu_ops, which is used to
release a CPU core to run baremetal or RTOS application on a SoC
with multiple CPU cores.
Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Register ARM A53 core clock for i.MX 8M Mini, Nano and Plus, preparing
for enabling the 'cpu' command, which depends on this to print CPU core
frequency.
Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
