Use the new boot_firmwares labels that help make documentation more
specific as to which firmwares are used in which devices
Signed-off-by: Dhruva Gole <d-gole@ti.com>
* Add documentation to briefly explain the role of TIFS Stub in relevant
K3 SoC's.
* Shed light on why TIFS Stub isn't package with the DM firmware itself.
* Modify the platform docs wherever the TIFS Stub documentation applies.
* Also, refactor and add a few new labels to help split the firmware
documentation chunks. This will make it easier to include them one by
one wherever applicable
Reviewed-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Dhruva Gole <d-gole@ti.com>
Acked-by: Francesco Dolcini <francesco.dolcini@toradex.com> # verdin-am62
Block devices can already set partition type at initialization
stage, so, in this case is no point in searching for partition type.
Signed-off-by: Alexey Romanov <avromanov@salutedevices.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
UBI block is an virtual device, that runs on top
of the MTD layer. The blocks are UBI volumes.
Intended to be used in combination with other MTD
drivers.
Despite the fact that it, like mtdblock abstraction,
it used with UCLASS_MTD, they can be used together
on the system without conflicting. For example,
using bcb command:
# Trying to load bcb via mtdblock:
$ bcb load mtd 0 mtd_partition_name
# Trying to load bcb via UBI block:
$ bcb load ubi 1 ubi_volume_name
User always must attach UBI layer (for example, using
ubi_part()) before using UBI block device.
Signed-off-by: Alexey Romanov <avromanov@salutedevices.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Acked-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
Introduce ubi_volume_offset_write() helper, which
allow to write to ubi volume with specified offset.
Signed-off-by: Alexey Romanov <avromanov@salutedevices.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Acked-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
MTD block - abstraction over MTD subsystem, allowing
to read and write in blocks using BLK UCLASS.
Signed-off-by: Alexey Romanov <avromanov@salutedevices.com>
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
This updates the "old style" DTs to that of Linux v6.10, matching what
OF_UPSTREAM is at now. Hopefully we won't need to do this (manually)
anymore. Since this brings in the DT for a new board (Tanix TX1), also
add the defconfig for that, which has just been waiting for that sync.
There are three more fixes: two for the SPI clock setup, which avoids
too high frequencies in some cases, and one fix to avoid a build warning
with GCC 14 for the sunxi TOC0 part of the mkimage tool.
The gitlab CI passed, and I tested the SPI flash on the OrangePi Zero 3
and also booted that into Linux.
AMD/Xilinx changes for v2024.10-rc2
amd/xilinx:
- Enable CONFIG_MMC_SPEED_MODE_SET
env:
- support overriding spi dev from board code
clk:
- Add set_rate support for display clocks
spi:
- Describe is25lp01gg flash
zynq:
- Add support for 7z010_lr and 7z020_lr
zynqmp:
- Add support for zu1eg_lr
- Enable NFS for Kria
- DT changes
- Cleanup firmware handling in board_init()
versal-net:
- Setup spi seq number based on boot device
- dt-schema update for mini configurations
versal2:
- Disable uartlite driver
- Add support for mini configurations
- Enable NFS
tpm_tis_wait_init() is using the 'chip->timeout_b' field which is
initialized in tpm_tis_init(). However, the init-function is called
*after* tpm_tis_wait_init() introducing an uninitalized field access.
This commit switches both routines.
Signed-off-by: Lukas Funke <lukas.funke@weidmueller.com>
Acked-by: Miquel Raynal <miquel.raynal@bootlin.com>
[Ilias removed unusged 'chip' definition in tpm_tis_spi_probe()]
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Fixes: a5c30c26b2 ("tpm: Use the new API on tpm2 spi driver")
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
If the maximum frequency is requested, we still fall into the CDR2
handling. But there the minimal divider is 2. For the sun6i and sun8i we
can do better with the CDR1 setting where the minimal divider is 1:
SPI_CLK = MOD_CLK / 2 ^ cdr with cdr = 0
Thus, handle the div = 1 case specially.
While at it, correct the comment above the calculation.
Signed-off-by: Michael Walle <mwalle@kernel.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
The CDR2 divider calculation always yield a frequency greater than the
requested one. Use DIV_ROUND_UP() to keep the frequency equal or below
the requested one. This way, we can also drop the "if div > 0" check
because we know for a fact that div cannot be zero.
FWIW, this aligns the CDR2 calculation with the linux driver.
Suggested-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Michael Walle <mwalle@kernel.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
The Tanix TX1 is a tiny TV box, featuring the Allwinner H313 SoC with up
to 2GB of DRAM and 16GB of eMMC. There is no SD card or Ethernet port on
this small device, but it can be booted via the USB debug "FEL" mode.
The bootloader could then be written to the eMMC.
Add the defconfig for that board, and add the devicetree file to the
Makefile, for it to be built.
The DRAM parameters were taken from the vendor firmware on the eMMC.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
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
