VBE is currently quite careful with function arguments because it is
used in VPL which cannot be updated after manufacture. Bugs can cause
security holes.
Unfortunately this adds to code size.
In several cases we are reading values from a devicetree which is part
of U-Boot (or at least VPL) and so known to be good. Also, in several
places, getting bad values does not matter.
So change a few checks to assert() to reduce code size.
Signed-off-by: Simon Glass <sjg@chromium.org>
Pass the private data instead of the device, to help the compiler
optimise better. This saves 16 bytes of code on pinecube (rk3288)
Signed-off-by: Simon Glass <sjg@chromium.org>
Pass a struct udevice instead of the descriptor structure, since this is
the native argument for blk_read()
Signed-off-by: Simon Glass <sjg@chromium.org>
Move a few things into a new, common header file so that vbe-simple can
share code with the upcoming abrec.
Put struct simple_nvdata in it and rename it.
Signed-off-by: Simon Glass <sjg@chromium.org>
We should not be using the old blk_d...() interface, is only there to
aid migration to driver model.
Move to blk_read() instead.
Changes in v2:
- Split patch into several pieces
Signed-off-by: Simon Glass <sjg@chromium.org>
commit fc37a73e66 ("fdt: Swap the signature for
board_fdt_blob_setup()") introduced a subtle change to the Snapdragon
implementation, removing the assignment to gd->fdt_blob partway through
the function.
This breaks qcom_parse_memory() which was also called during
board_fdt_blob_setup().
The underlying issue here is that qcom_parse_memory is using the of_ api
to traverse a devicetree, which relies on the fdt_blob in global data.
Rather than relying on this subtle behaviour, explicitly pass the FDT
that should be consulted for a /memory node.
Using the OF API is typically preferable because it's easier to read,
but using the lower level fdt_ methods instead here doesn't add too much
complexity, I think.
Finally, a minor tweak was made to board_fdt_blob_setup to use the
passed fdt blob pointer instead of gd->fdt_blob, which removes the last
of the references to global data in this area.
Fixes: fc37a73e66 (fdt: Swap the signature for board_fdt_blob_setup())
Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>
Signed-off-by: Sam Day <me@samcday.com>
Link: https://lore.kernel.org/r/20250122-qcom-parse-memory-updates-v2-1-98dfcac821d7@samcday.com
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
On 32-bit architectures, LAST_LINE (_LAST_LINE - 1UL) is 64 bits long,
but size_t (from ARRAY_SIZE(...)) is 32 bits. This results in a warning
because the max() macro expects the same type on both sides:
cmd/ufetch.c: In function ‘do_ufetch’:
include/linux/kernel.h:179:24: warning: comparison of distinct pointer types lacks a cast [-Wcompare-distinct-pointer-types]
179 | (void) (&_max1 == &_max2); \
| ^~
cmd/ufetch.c:92:25: note: in expansion of macro ‘max’
92 | int num_lines = max(LAST_LINE + 1, ARRAY_SIZE(logo_lines));
| ^~~
Fix this by casting LAST_LINE to size_t.
Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>
Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
Link: https://lore.kernel.org/r/20241211-ufetch-v2-1-2b5432ffaeb1@posteo.net
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Add support for the PCIe busses on Qualcomm platforms,
by using the pcie_dw_common infrastructure.
The driver is based on the Linux driver but only supporting
the "1_9_0" and compatible platforms like:
- sa8540p
- sc7280
- sc8180x
- sc8280xp
- sdm845
- sdx55
- sm8150
- sm8250
- sm8350
- sm8450
- sm8550
- sm8650
- x1e80100
But it has only been tested on:
- sc7280
- sm8550
- sm8650
- x1e80100
It supports setting the IOMMU SID table for supported platforms.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20241125-topic-pcie-controller-v1-2-45c20070dd53@linaro.org
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Replace delay_ns by delay_us which is the field name used into
struct cyclic_info.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Stefan Roese <sr@denx.de>
On 32 bits platforms, timer_get_us() returns an unsigned long which
is a 32 bits. timer_get_us() wraps around every 72 minutes
(2 ^ 32 / 1000000 =~ 4295 sec =~ 72 min).
So the test "if time_after_eq64(now, cyclic->next_call)" is no more
true when cyclic->next_call becomes above 32 bits max value (4294967295).
At this point after 72 min, no more cyclic function are
executed included watchdog one.
Instead of using timer_get_us(), use get_timer_us() which returns a
uint64_t, this allows a rollover every 584942 years.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Move differences in DT files between upstream Linux DT and U-Boot DT to
mt7629-rfb-u-boot.dtsi.
Remove old copies of mt7629-related clock bindings, .dts, and .dtsi files.
Update defconfig to switch the whole mt7629 SoC to use OF_UPSTREAM.
Signed-off-by: Sam Shih <sam.shih@mediatek.com>
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
The clock definitions in mt7629-clk.h indicate that CLK_PERIBUS_SEL is the
first element in the pericfg clock tree and also serves as a clock mux,
unlike other clocks belonging to the clock gate in pericfg.
This make the clock consumer get a wrong clock gate during request a clock
from <&pericfg>.
Since CLK_PERIBUS_SEL clock is not required in U-Boot, add a clock gate
offset for the pericfg clock tree to resolve this problem.
Signed-off-by: Sam Shih <sam.shih@mediatek.com>
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
Enable rudimentary nand read/write capability.
Changes in v2:
- New patch in series added enabling of nand functionality
Signed-off-by: david regan <dregan@broadcom.com>
Reviewed-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Anand Gore <anand.gore@broadcom.com>
Update bcmbca dts to current nand node naming convention.
Changes in v2:
- Removed addition of nand-on-flash-bbt parameter
Signed-off-by: david regan <dregan@broadcom.com>
Reviewed-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Anand Gore <anand.gore@broadcom.com>
OSPI flash writing was broken on am62x SKs as the OSPI flash device has a
256k sector size but was set to 20k. This breaks OSPI flash writes because
the current implementation of the SF DFU backend requires that the DFU data
buffer size be the same as the sector erase size, and the USB DFU config
fragment (for both A53 and R5) reduced the size of the DFU data buffer,
presumably so that it can fit into SPL's much smaller heap.
Change the SYS_DFU_DATA_BUF_SIZE to the erase sector size, which still fits
within the post-relocation heap size in SPL.
Fixes: dfc2dff5a8 ("configs: am62x_evm_*: Enable USB and DFU support")
Signed-off-by: Jonathan Humphreys <j-humphreys@ti.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
When using the ACPI tables supplied by QEMU, we don't need to build the
FADT and MADT tables in U-Boot.
This patch avoids a build failure
make qemu-riscv64_smode_defconfig acpi.config
riscv64-linux-gnu-ld.bfd: lib/acpi/acpi_table.o:
in function `acpi_write_fadt':
lib/acpi/acpi_table.c:265:(.text.acpi_write_fadt+0x15c):
undefined reference to `acpi_fill_fadt'
riscv64-linux-gnu-ld.bfd: lib/acpi/acpi_table.o:
in function `acpi_write_madt':
lib/acpi/acpi_table.c:294:(.text.acpi_write_madt+0x52):
undefined reference to `acpi_fill_madt'
Fixes: f5f7962091 ("acpi: x86: Write FADT in common code")
Fixes: 4a3fc0f525 ("acpi: x86: Move MADT to common code")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tom Rini <trini@konsulko.com> says:
One problem we have today is how the BLK symbol is set and used in
Kconfig files. Part of the challenge is that we use it as a gating
symbol for "we have a block device" and also for "enable block device
library code". What this series does is move to always use "select BLK"
by block drivers (a few were and a few others had it the inverse) and
then "depends on BLK" for functionality that needs a block device
present. The end result of this series is that a number of platforms
which had disabled EFI_LOADER now don't ask for it (they have no block
device) and espresso7420 has a regression about MMC support fixed. With
v2 of this I've picked up the review tags from v1 and also reworded the
body of the commit in the first patch.
Link: https://lore.kernel.org/r/20250115012322.215243-1-trini@konsulko.com
Now that block drivers are all selecting the BLK symbol, there's no need
for other options to be select'ing BLK so that other required
functionality can be enabled. Remove these places.
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Tom Rini <trini@konsulko.com>
In the case of MTD_BLOCK and UBI_BLOCK they should be select'ing BLK as
they provide block device functionality and not depending on some other
block device already being enabled too (as is the typical case).
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
The BLK symbol has a few meanings, one of which is that it controls the
driver model portion of a "block device". Rather than having this hidden
symbol be "default y if ..." it should be select'd by the various block
subsystems. Symbols such as PVBLOCK which already select'd BLK are
unchanged".
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Tom Rini <trini@konsulko.com>
In reworking the BLK usage in Kconfig, I found there's a few issues with
EFI_LOADER=y and BLK=n. In general, we can easily say that
lib/efi_loader/efi_file.c also should only be built with CONFIG_BLK.
That however leaves the bootmgr code, eficonfig code and then parts of
efi_device_path.c, efi_boottime.c and efi_setup.c which functionally
depend on BLK. While these calls can be if'd out, I'm unsure if the
result is usable. So rather than leave that buildable and imply that it
is, I'm leaving that combination non-buildable and commenting that
EFI_LOADER depends on BLK in the Kconfig currently.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Tom Rini <trini@konsulko.com>
