| Age | Commit message (Collapse) | Author |
|---|
|
Tom Rini <trini@konsulko.com> says:
In this series we correct how we handle OF_OMIT_DTB so that we can in
turn not have an empty or fake dts file in the tree, when we are
building for the case where we would be omitting building the final part
of the dtb for use anyhow. With the changes in the previous series, we
can then correct the Kconfig logic around OF_OMIT_DTB and
DEFAULT_DEVICE_TREE so that when we're omitting the device tree binary
we don't try and build one anyhow. Finally, we can remove all of the
empty / fake device tree sources we have, or in some cases have but
never used.
Link: https://lore.kernel.org/r/20260824195224.556419-2-trini@konsulko.com
|
|
Tom Rini <trini@konsulko.com> says:
When we have mandatory passage enabled, we don't allow the fdt
address to still be overriden. This is mostly working today but there
are corner cases where it could still be overriden. Correct that by
enforcing that if we don't find the device tree in the bloblist (when
BLOBLIST_PASSAGE_MANDATORY is enabled) we error out. With that done, we
can rework how the vexpress64 and mandatory passage support works as it
wasn't using the correct symbols either for this case.
Link: https://lore.kernel.org/r/20260824194814.555634-1-trini@konsulko.com
|
|
Now that we do not require device tree files to be built when
OF_OMIT_DTB is set, we can remove a number of unused dts files.
Reviewed-by: Peter Robinson <pbrobinson@gmail.com> - For RPi DTs
Reviewed-by: Yao Zi <me@ziyao.cc>
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
Now that we are not building this device tree, we can drop it from the
tree.
Reviewed-by: Yao Zi <me@ziyao.cc>
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
When we omit writing a device tree file is not something that should be
prompted for but rather it should be selected when needed, and the
"default y if ..." conditions should be used for when this should be
enabled without being selected.
Reviewed-by: Yao Zi <me@ziyao.cc>
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
When we have configured the board to not omit a DTB as part of the
build, we should not have to say that we still need to build a default
DTB for the board.
Reviewed-by: Yao Zi <me@ziyao.cc>
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
When we have enabled CONFIG_OF_OMIT_DTB, we really should then be not
forcing a device tree to be built. This involves two things. First, when
OF_SEPARATE is set, don't say we still need to build dts/dt.dtb. Second,
our init_sp_bss_offset_check check can only cover the non-dtb portion.
Reviewed-by: Yao Zi <me@ziyao.cc>
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
When we don't have BLOBLIST_PASSAGE_MANDATORY enabled, then we're being
passed the device tree in some other manner, via OF_HAS_PRIOR_STAGE.
Correct our logic around which symbols are used to guard what is
generated / used and when.
Reviewed-by: Raymond Mao <raymondmaoca@gmail.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Acked-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
When we have CONFIG_BLOBLIST_PASSAGE_MANDATORY enabled, we don't allow
the device tree address to be overridden. However, in fdtdec_setup() we
had been allowing for various cases of not having found the device tree
in the bloblist, or overriding it, to be possible. Add a check after the
bloblist check such that if we have enabled BLOBLIST_PASSAGE_MANDATORY
we return an error at that point.
Acked-by: Raymond Mao <raymondmaoca@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
https://git.u-boot-project.org/u-boot/custodians/u-boot-mediatek into next
* New mipi_dsi_{generic,dcs}_write_seq() helper macros
* Convert 5 panel drivers to use the new mipi_dsi write_seq macros
* Support num-interpolated-steps in pwm_backlight
* Fix MediaTek clock driver using BSS before relocation
* New MT8366 clock driver and dt-bindings clock header
* MediaTek power domain: bus_prot_sta_mask field and BUS_PROT_WR_IGN() macros
* New MT8366 power domain support and dt-bindings header
* Fix setting DCM_TOP_EN on chips that don't have it in MediaTek power domain driver
* Devicetree cleanups: drop mt8188 tphy fallback, remove unused mt6357.dtsi
* Remove UFS defconfigs for Genio EVKs
|
|
Remove setting DCM_TOP_EN (Dynamic Clock Management). This is not
present in the Linux driver and MT8xxx SoCs don't have this register.
Writing this register causes a hard fault on MT8366.
Fixes: a81e1f8a7cf2 ("power: domain: mediatek: add support for the power-controller model")
Tested-by: Julien Stephan <jstephan@baylibre.com>
Reviewed-by: Julien Stephan <jstephan@baylibre.com>
Reviewed-by: Carlo Caione <ccaione@baylibre.com>
Link: https://patch.msgid.link/20260818-mtk-power-domain-remove-dcm-v1-1-13de7925ceec@baylibre.com
Signed-off-by: David Lechner <dlechner@baylibre.com>
|
|
Remove the UFS defconfigs for Genio 520/720/1200 and enable the UFS
options in the remaining defconfigs. This simplifies things a bit, e.g.
it makes fewer builds to run when testing. Users can instead use the
base defconfigs and pass DEVICE_TREE= to select the correct devicetree
for the target. Or alternatively, include devicetree overlays in a FIT
image that can be selected at runtime by the SPL.
Reviewed-by: Julien Stephan <jstephan@baylibre.com>
Reviewed-by: Carlo Caione <ccaione@baylibre.com>
Link: https://patch.msgid.link/20260814-mtk-genio-720-remove-ufs-defconfig-v1-1-000eb476030f@baylibre.com
Signed-off-by: David Lechner <dlechner@baylibre.com>
|
|
Add support for the num-interpolated-steps devicetree property to the
pwm_backlight driver. This is used in cases where there are many points
and we don't want to list them all in brightness-levels.
Reviewed-by: Julien Stephan <jstephan@baylibre.com>
Reviewed-by: Carlo Caione <ccaione@baylibre.com>
Link: https://patch.msgid.link/20260814-video-pwm-backlight-num-interpolated-steps-v1-1-140b06287868@baylibre.com
Signed-off-by: David Lechner <dlechner@baylibre.com>
|
|
Remove the downstream mt6357.dtsi file. This is no longer needed since
it is available upstream. The upstream version is more correct/complete
as it doesn't have incorrect `compatible = "fixed-regulator"` properties
on the regulators and has an adc node (not used by U-Boot).
Reviewed-by: Julien Stephan <jstephan@baylibre.com>
Link: https://patch.msgid.link/20260817-mtk-dts-drop-mt6357-dtsi-v1-1-fe6ce3fdf1c0@baylibre.com
Signed-off-by: David Lechner <dlechner@baylibre.com>
|
|
Add power domain support for MT8366.
Signed-off-by: Irving-ch Lin <irving-ch.lin@mediatek.com>
Link: https://patch.msgid.link/20260814-mtk-power-domain-mt8366-v1-4-6a0bb4a766bb@baylibre.com
Signed-off-by: David Lechner <dlechner@baylibre.com>
|
|
Add mediatek,mt8366-power.h for mt8366 power domain binding. This is
coming from downstream Linux since upstreaming of MT8366 has not
started yet, so we will have to carry this for a while.
Signed-off-by: Irving-ch Lin <irving-ch.lin@mediatek.com>
Link: https://patch.msgid.link/20260814-mtk-power-domain-mt8366-v1-3-6a0bb4a766bb@baylibre.com
Signed-off-by: David Lechner <dlechner@baylibre.com>
|
|
Add a pair of BUS_PROT_WR_IGN() macros that will be used by domains that
have the ignore flag set to true.
Link: https://patch.msgid.link/20260814-mtk-power-domain-mt8366-v1-2-6a0bb4a766bb@baylibre.com
Signed-off-by: David Lechner <dlechner@baylibre.com>
|
|
Add a bus_prot_sta_mask field to the mtk_bus_prot structure. This will
be used by power domains that have a separate status mask compared to
the bus_prot_mask.
Link: https://patch.msgid.link/20260814-mtk-power-domain-mt8366-v1-1-6a0bb4a766bb@baylibre.com
Signed-off-by: David Lechner <dlechner@baylibre.com>
|
|
Add new clock tables/drivers for MT8366.
Signed-off-by: irving.ch.lin <irving-ch.lin@mediatek.com>
Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
Co-developed-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20260814-mtk-clk-mt8366-v2-2-5e9e952de8d8@baylibre.com
Signed-off-by: David Lechner <dlechner@baylibre.com>
|
|
Add a header with MT8366 clock definitions for use in devicetrees.
Upstreaming of MT8366 has not even started yet, so we will have to
carry a downstream version of this for some time.
Signed-off-by: Irving-CH Lin <irving-ch.lin@mediatek.com>
Link: https://patch.msgid.link/20260814-mtk-clk-mt8366-v2-1-5e9e952de8d8@baylibre.com
Signed-off-by: David Lechner <dlechner@baylibre.com>
|
|
Remove the static mtk_clk_providers array. Static variables cannot be
used before relocation in U-Boot, so it broke systems that used clocks
before relocation, e.g. for UART early console.
The mtk_clk_providers array was likely premature optimization anyway
since it only saves a few cycles of searching a small number of clock
devices on each parent lookup.
Reported-by: Sam Shih <Sam.Shih@mediatek.com>
Tested-by: Sam Shih <Sam.Shih@mediatek.com>
Fixes: 8ef0ad4c7a6d ("clk: mediatek: use registered provider for parent lookup")
Link: https://patch.msgid.link/20260813-mtk-clk-fix-reprobe-regression-v2-1-c7d1076a7ada@baylibre.com
Signed-off-by: David Lechner <dlechner@baylibre.com>
|
|
Aristo Chen <aristo.chen@canonical.com> says:
This is v2 of "bootm: size the noload decompression buffer from the
compressor header". Tom pushed back on v1
(https://lore.kernel.org/r/20260809042338.63397-2-aristo.chen@canonical.com/)
on two grounds:
1. No concrete problem report driving the change.
2. ~1297 platforms grew by ~170-400 bytes; the change is not
opt-in, so the size cost falls on everyone.
On the first point, Nora Schiffer replied with a concrete use case
(EFI-in-FIT plus padded loaders such as shim, systemd-boot, and
OpenWrt's lzma-loader can produce compression ratios that outrun the
8x heuristic), and mentioned this is on the road map for TQ-Systems
standard BSPs.
On the second point, v2 reworks the implementation to cut the size
cost, measures it across the format and architecture buckets, and
splits the work per format so each decompressor's support can be
taken or dropped on its own.
Background: for a compressed kernel_noload image, bootm_load_os()
sizes the decompression buffer as ALIGN(image_len * 8, SZ_1M). The
8x heuristic works for typical kernels, but any well-compressed
payload can exceed it, and no fixed multiplier is safe against
arbitrarily compressible input.
Each implementation patch adds a small static header-parse helper in
bootm.c (no new public API) and wires it into a size-hint switch;
helper and switch case are only compiled when the matching
decompressor is enabled, so boards that do not build a format pay no
code for it. gzip's ISIZE is a fixed trailer read, lzma's size a
fixed header read, lz4 mirrors ulz4fn()'s frame-header validation,
and zstd asks zstd_get_frame_header(), whose frame-parsing code
already ships with the zstd decompressor. The header-recorded value
is attacker-controlled, so it is capped at CONFIG_SYS_BOOTM_LEN, and
it is only an allocation hint: the decoder stays authoritative
during the actual decompression.
Text size deltas of the u-boot ELF (size(1), distro gcc 13.3 cross
toolchains); data/bss are unchanged everywhere. To make the columns
directly comparable, the v1 column is v1's implementation commit
cherry-picked onto this series' base, so both columns share one
baseline:
board arch decompressors v1 v2
qemu_arm arm gzip +160 +104
qemu-ppce500 powerpc gzip +176 +112
mt7623n_bpir2 arm gzip+lzma +184 +128
qemu_arm64 arm64 gzip+lzma+lz4 +384 +368
qemu-riscv64 riscv64 gzip+lzma+lz4 +332 +352
th1520_lpi4a riscv64 all four +412 +404
am62x_evm_a53 arm64 all four, LTO +0 * +8192 *
qemu-x86 x86 none +108 -2
* am62x_evm_a53's number is dominated by the Cortex-A53 erratum
843419 linker workaround (default-enabled in distro binutils for
aarch64): symbol-level code growth (nm -S) is +392 for v1 and
+452 for v2, but those bytes shift which ADRP instructions land
at the erratum's page offsets, and ld pads each inserted veneer
to a full 4 KiB page. v2 happens to trigger two such pages here;
v1 triggered the same two on its own original base and none on
this one. See the world-build note below.
To see how much each bucket weighs, I configured all 1550 defconfigs
and sorted them by which decompressors they enable next to bootm:
858 gzip only (722 of them arm, essentially the 32-bit boards)
530 gzip+lzma+lz4 (494 arm, mostly arm64, plus 36 riscv)
38 gzip+lzma
31 bootm with no decompressor at all
27 gzip+lzma+lz4+zstd
19 gzip+lz4
15 gzip+zstd
6 other combinations
26 do not link bootm at all
To measure at the same scale as the original objection, I also ran a
full world build (buildman, all 1550 defconfigs, distro plus
kernel.org toolchains, gcc 13.3/14.2) over one branch holding the
base, the v1 implementation, its revert, and this series. 1496
boards built on all four commits with the revert reproducing the
base sizes exactly (44 boards did not build on every commit, and 10
built nondeterministically; both sets were excluded). Of those 1496,
the same 1375 change under either version and the rest are
untouched, including every board without bootm or without a
decompressor:
v1 v2
mean delta over all boards +194 B +166 B
median delta (changed boards) +160 B +96 B
median, 856 gzip-only boards +112 B +80 B
median, 517 gzip+lzma+lz4 boards +392 B +376 B
boards cheaper with v2 - 1222
boards costlier with v2 - 74
The world build also puts the am62x footnote in proportion: 53
boards under v1 and 49 under v2 (28 in both sets), all arm64, show
size(1) jumps of one or two 4 KiB pages in either direction (min
-8192, max +8192). The mechanism is the Cortex-A53 erratum 843419
linker workaround: when a code change shifts which ADRP instructions
land at page offsets 0xff8/0xffc, ld materialises a 16-byte veneer
and pads it to a full 4 KiB page so the page offsets of all
downstream code stay unchanged. Any few-hundred-byte change re-rolls
which boards are affected, in both directions; symbol-level growth
on every such board I checked matches the byte ranges above.
Since Tom noted the higher growth in his run was on multi-algorithm
platforms: building each patch in sequence on a gzip+lzma+lz4 board
(qemu_arm64) and an all-four board (th1520_lpi4a) gives the
per-format cost directly, in bytes:
qemu_arm64 th1520_lpi4a
gzip +112 +86
zstd +0 +62
lz4 +176 +176
lzma +80 +80
(zstd is +0 on qemu_arm64 because that board does not enable it, so
the guard really does compile the helper out.) lz4 is the most
expensive parser because it mirrors ulz4fn()'s frame validation;
zstd is the cheapest because zstd_get_frame_header() already ships
with the decompressor. Since the series is split per format, if the
multi-algorithm cost still looks too high, dropping the lz4 patch
alone would cut the 517-board gzip+lzma+lz4 bucket from a median of
+376 to roughly +200; lz4 images then simply keep the 8x fallback.
In the v1 thread Simon suggested recording the uncompressed size as
a FIT property instead. As discussed there, the two compose: a FIT
property could be layered on top later, with bootm preferring the
property, then the stream header, then the 8x fallback. This series
provides the part that works for every existing image and for the
legacy uImage form of kernel_noload.
Series layout, one decompressor at a time:
1. gzip helper + wiring
2. gzip pytests (lying-header overflow, header-sized, boundary)
3. zstd helper
4. zstd pytest (guarded by requiredtool zstd)
5. lz4 helper
6. lz4 pytest (guarded by requiredtool lz4)
7. lzma helper
8. lzma pytests (real size patched into the header field, plus the
"unknown" size marker fallback; needs no external tool since
Python's lzma module is in the standard library)
Every patch builds in isolation on sandbox_defconfig and
qemu_arm_defconfig; the seven kernel_noload_decomp pytests and the
full test_fit class pass on sandbox.
Link: https://lore.kernel.org/r/20260818132332.324173-1-aristo.chen@canonical.com
|
|
Exercise bootm_lzma_uncompressed_size() end-to-end on sandbox:
- test_fit_kernel_noload_decomp_lzma_hdr_sized boots a 6 MiB
kernel_noload payload that lzma compresses far past the 8x fallback
heuristic, so the boot only succeeds when bootm sizes the buffer
from the header's uncompressed-size field. Streaming encoders write
the "unknown" marker into that field, so the test compresses with
Python's lzma module and patches the real size into the fixed
8-byte field, matching what LZMA SDK style encoders record.
- test_fit_kernel_noload_decomp_lzma_unknown_size leaves the marker in
place and checks that bootm falls back to the 8x heuristic buffer
and still boots the image.
No external tool is required: Python's lzma module is part of the
standard library.
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
|
|
Add a small static helper bootm_lzma_uncompressed_size() that reads
the uncompressed size out of the .lzma-alone header, and wire it
into bootm_load_os() alongside gzip, lz4, and zstd.
The .lzma-alone format keeps the uncompressed size in a fixed 8-byte
field right after the 5-byte properties block; a marker of all ones
means the size is unknown, and the caller falls back to the 8x
heuristic in that case. Streaming encoders (xz-utils' 'lzma' shim,
Python's lzma.FORMAT_ALONE) write the unknown marker, while LZMA SDK
style encoders record the real size.
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
|
|
Add test_fit_kernel_noload_decomp_lz4_hdr_sized: a 6 MiB payload
whose lz4 compression ratio is past the 8x heuristic decompresses
cleanly because Content_Size is consulted. The tool must be invoked
with --content-size so the frame's FLG bit is set. The test is
guarded by @pytest.mark.requiredtool('lz4') so it skips on hosts
that do not ship the lz4 command.
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
|
|
Add a small static helper bootm_lz4_uncompressed_size() that parses
the lz4 frame header and returns Content_Size when the FLG bit is
set, and wire it into bootm_load_os() alongside gzip and zstd.
The header parse mirrors ulz4fn()'s validation (magic, version==1,
reserved bits, independent-block flag) so the helper does not accept
a frame the decoder itself would reject. Only Content_Size is
extracted; the full validation still runs inside ulz4fn() during the
actual decompression call.
The lz4 command needs the --content-size option to set the FLG bit
that carries the size; frames produced without it fall back to the
existing 8x heuristic.
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
|
|
Parametrise NOLOAD_ITS on the compression field so a single template
can drive gzip, zstd, and future format tests, and update the
existing gzip callers to pass compression='gzip'.
Add test_fit_kernel_noload_decomp_zstd_hdr_sized: a 6 MiB payload
whose zstd compression ratio is past the 8x heuristic decompresses
cleanly because Frame_Content_Size is consulted. The test is guarded
by @pytest.mark.requiredtool('zstd') so it skips on hosts that do
not ship the zstd command.
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
|
|
Add a small static helper bootm_zstd_uncompressed_size() that returns
the frame's Frame_Content_Size via zstd_get_frame_header(), and wire
it into bootm_load_os() as a new case in the size-hint switch
alongside the existing gzip case.
zstd_get_frame_header() and the frame-parsing code behind it ship
with the zstd decompressor, which is already linked into any board
that enables ZSTD, so calling it here adds no new zstd code to the
image. The returned value is used as an allocation hint only and is
capped by the caller; full validation still runs inside
zstd_decompress() during the actual decompression.
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
|
|
Reshape and extend the kernel_noload decompression pytests to match
the new bootm behaviour that reads ISIZE from the gzip trailer:
- Rename test_fit_kernel_noload_decomp_overflow to
test_fit_kernel_noload_decomp_gzip_lying_hdr. Its setup (a 4 MiB
payload of zeros gzipped) used to force the failure via the 8x
heuristic starving the buffer; now that bootm reads ISIZE, the
honest trailer sizes the buffer correctly, so overwrite ISIZE
with a tiny value instead and verify the resulting decompression
is still stopped at the buffer boundary. This is the direct test
of the CONFIG_SYS_BOOTM_LEN cap on the attacker-controlled
header value.
- Add test_fit_kernel_noload_decomp_gzip_hdr_sized: a 6 MiB gzipped
payload whose compression ratio is past the 8x heuristic
decompresses cleanly because ISIZE is consulted.
- Rename the pre-existing test_fit_kernel_noload_decomp_boundary to
test_fit_kernel_noload_decomp_gzip_boundary so every
noload_decomp test carries the compressor in its name.
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
|
|
For a compressed kernel_noload image, bootm_load_os() allocates a
per-image decompression buffer of ALIGN(image_len * 8, SZ_1M). The 8x
multiplier is a heuristic that comfortably covers what zstd and xz
achieve on real kernels, but a highly compressible payload (say, a
run of zeros) can exceed it and fail decompression.
gzip carries the original size in the last 4 bytes of the stream
(ISIZE, modulo 2^32). Where the compressed image is a gzip stream,
read ISIZE and use ALIGN(hdr_size, SZ_1M) as the buffer, capped at
CONFIG_SYS_BOOTM_LEN because the value is attacker-controlled. For
non-gzip streams or when ISIZE cannot be trusted, fall back to the
existing 8x multiplier.
The size read is done via a small static helper in bootm.c, wired up
via a switch on os.comp so the same pattern can be extended to other
formats without adding a new public interface. The other formats
U-Boot supports (lzma, lz4, zstd) also carry a size hint and are
added in follow-up patches.
Suggested-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
|
|
Now that tphy-v3 support is added to the corresponding U-Boot driver, we
no longer need the hack to fall back to tphy-v2 for mt8188.
Reviewed-by: Julien Stephan <jstephan@baylibre.com>
Link: https://patch.msgid.link/20260813-mtk-mt8188-drop-tphy-compat-v1-1-9e28ce95ed75@baylibre.com
Signed-off-by: David Lechner <dlechner@baylibre.com>
|
|
The current driver defines dsi_dcs_write_seq as a wrapper around
mipi_dsi_dcs_write_buffer.
Now that mipi_dsi.h defines such macro, we can use the common one.
No functional changes intended.
Signed-off-by: Julien Stephan <jstephan@baylibre.com>
Link: https://patch.msgid.link/20260806-add_mipi_dsi_write_seq_helper_macros-v1-6-6b533788d0ac@baylibre.com
Signed-off-by: David Lechner <dlechner@baylibre.com>
|
|
The current driver defines dsi_generic_write_seq as a wrapper around
mipi_dsi_dcs_write_buffer.
Now that mipi_dsi.h defines such macro, we can use the common one.
Note that we use mipi_dsi_dcs_write_seq instead of
mipi_dsi_generic_write_seq to keep the same behaviour.
While at it also use mipi_dsi_dcs_write_seq instead of direct call to
mipi_dsi_dcs_write_buffer for address_mode, and remove static
address_mode variable.
No functional changes intended.
Signed-off-by: Julien Stephan <jstephan@baylibre.com>
Link: https://patch.msgid.link/20260806-add_mipi_dsi_write_seq_helper_macros-v1-5-6b533788d0ac@baylibre.com
Signed-off-by: David Lechner <dlechner@baylibre.com>
|
|
The current driver defines dsi_generic_write_seq as a wrapper around
mipi_dsi_dcs_write_buffer.
Now that mipi_dsi.h defines such macro, we can use the common one.
Note that we use mipi_dsi_dcs_write_seq instead of
mipi_dsi_generic_write_seq to keep the same behaviour.
No functional changes intended.
Signed-off-by: Julien Stephan <jstephan@baylibre.com>
Link: https://patch.msgid.link/20260806-add_mipi_dsi_write_seq_helper_macros-v1-4-6b533788d0ac@baylibre.com
Signed-off-by: David Lechner <dlechner@baylibre.com>
|
|
The current driver defines dsi_generic_write_seq as a wrapper around
mipi_dsi_dcs_write_buffer.
Now that mipi_dsi.h defines such macro, we can use the common one.
Note that we use mipi_dsi_dcs_write_seq instead of
mipi_dsi_generic_write_seq to keep the same behaviour.
No functional changes intended.
Signed-off-by: Julien Stephan <jstephan@baylibre.com>
Link: https://patch.msgid.link/20260806-add_mipi_dsi_write_seq_helper_macros-v1-3-6b533788d0ac@baylibre.com
Signed-off-by: David Lechner <dlechner@baylibre.com>
|
|
The current driver defines dsi_generic_write_seq as a wrapper around
mipi_dsi_dcs_write_buffer.
Now that mipi_dsi.h defines such macro, we can use the common one.
Note that we use mipi_dsi_dcs_write_seq instead of
mipi_dsi_generic_write_seq to keep the same behaviour.
No functional changes intended.
Signed-off-by: Julien Stephan <jstephan@baylibre.com>
Link: https://patch.msgid.link/20260806-add_mipi_dsi_write_seq_helper_macros-v1-2-6b533788d0ac@baylibre.com
Signed-off-by: David Lechner <dlechner@baylibre.com>
|
|
Add wrapper mipi_dsi_generic_write_seq and mipi_dsi_dcs_write_seq helper
macros around mipi_dsi_generic_write and mipi_dsi_dcs_write_buffer to
mimic macros defined in the Kernel. This helps porting drivers from the
Kernel and avoids the manual declaration of static arrays in drivers.
Some drivers (hitachi-tx10d07vm0baa.c, lg-lh400wv3-sd04.c, mot-panel.c,
renesas-r69328.c and himax-hx8394.c) already define such a macro, so
this will avoid duplication.
Signed-off-by: Julien Stephan <jstephan@baylibre.com>
Link: https://patch.msgid.link/20260806-add_mipi_dsi_write_seq_helper_macros-v1-1-6b533788d0ac@baylibre.com
Signed-off-by: David Lechner <dlechner@baylibre.com>
|
|
J721E/J7200 decodes the ROM-selected boot media in j721e_init.c,
which is built only for xPL. This keeps spl_boot_device() working, but
leaves U-Boot proper without the get_boot_device() implementation
declared by the common K3 hardware header. Board code that uses the
helper to select the environment or boot targets therefore cannot link.
Move the existing primary and backup boot-media decoding into a new
boot.c and build it unconditionally for J721E and J7200. Keep
spl_boot_device() as a wrapper around get_boot_device(), preserving the
existing xPL result while making the same decode available outside xPL.
Tested on: J7200X-PM2-SOM rev E8
Signed-off-by: Patryk Biel <pbiel7@gmail.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
|
|
https://git.u-boot-project.org/u-boot/custodians/u-boot-stm into next
STM32MP1:
- Add stm32mp157f-dk2-u-boot.dtsi file
- use debug() for image entry point message
- spl: support loading U-Boot proper from eMMC hardware partitions
Various fixes:
- MAINTAINERS: Replace STM32 and STPMIC with N:
- treewide: Fix STMicroelectronics spelling
|
|
When CONFIG_SUPPORT_EMMC_BOOT is enabled, make spl_mmc_boot_mode()
return MMCSD_MODE_EMMCBOOT instead of MMCSD_MODE_RAW.
This allows the SPL MMC loader to honor the standard configuration
options CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION and
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR when locating U-Boot proper,
whether it is stored in a GPT partition or in an eMMC hardware boot
partition.
As a result, both U-Boot SPL and U-Boot proper can be placed in the
eMMC hardware boot partitions.
Signed-off-by: Sean Nyekjaer <sean@geanix.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
|
|
upstream dtc"
Alexey Charkov <alchark@flipper.net> says:
U-Boot's copy of the libfdt Python bindings in
scripts/dtc/pylibfdt/libfdt.i_shipped was last synced wholesale in 2019,
by commit 903fe17aa8c8 ("pylibfdt: Sync up with upstream"), against dtc
commit 430419c28100. Since then it has only picked up individual fixes,
so it has drifted a long way behind dtc, which is now at v1.8.1-19.
Tom asked for an audit of the divergence when reviewing the FdtSw growth
patch [1]; this is the result. Bring in every missing change from upstream
as an individual commit, referencing its upstream sibling.
This adds: hasprop() and setprop_bool(), get_path(),
Property.as_stringlist() and the as_*int*_list() accessors,
address_cells()/size_cells(), add_mem_rsv()/del_mem_rsv(), geometric FdtSw
buffer growth, a missing Py_INCREF on the Py_None returned by the
fdt_getprop() typemap, correct get_mem_rsv() results on current Python,
and the SWIG 4.3+ return-value compatibility shim.
Not included is dtc commit 5008d1d6a356 ("pylibfdt: Replace removed SWIG
Python 2 compatibility macros"), which already landed independently as
commit 527115ef6783 ("pylibfdt: Replace removed SWIG Python 2
compatibility macros").
The first two patches are preparatory: they take the parts of two upstream
commits that earlier partial imports left behind, so the rest apply
verbatim. The last patch adds test coverage, since none of these bindings
have an in-tree caller yet and dtc's own tests for them live in
tests/pylibfdt_tests.py, which U-Boot does not carry.
Residual differences from upstream left untouched:
- the SPDX comment style;
- the %begin block defining PY_SSIZE_T_CLEAN, which is U-Boot's variant
of a fix dtc applies from its build system;
- the two %include paths, which follow U-Boot's directory layout;
- the retry loop in FdtSw.as_fdt(), from commit 211cfa503f6c ("libfdt:
Detected out-of-space with fdt_finish()") - U-Boot only change
CI passes all green [2]
[1] https://lore.kernel.org/u-boot/20260805-pylibfdt-geo-growth-v1-1-dabe082367e5@flipper.net/
[2] https://git.u-boot-project.org/u-boot/contributors/alchark/u-boot/-/pipelines/1047
Link: https://lore.kernel.org/r/20260824-pylibfdt-sync-v1-0-a42be6fa4872@flipper.net
|
|
Exercise additional pylibfdt bindings imported from upstream against the
existing dtoc test tree, which already carries a boolean property, a
string list, integer arrays and a bus node that overrides #address-cells
and #size-cells.
The FdtSw cases cover both halves of the geometric growth change: that an
out-of-space result at least doubles the buffer, and that a tree needing
several expansions still comes out intact.
Signed-off-by: Alexey Charkov <alchark@flipper.net>
|
|
Commit 97de532e59be ("pylibfdt: Correct the type for fdt_property_stub()")
took two of the three hunks of the upstream change and left the docstring
saying only "Value of property", which is what prompted the type fix in
the first place.
Take the remaining hunk of dtc commit fdf3f6d897ab ("pylibfdt: Correct
the type for fdt_property_stub()").
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
[rewrite commit message for U-Boot]
Signed-off-by: Alexey Charkov <alchark@flipper.net>
|
|
The memory reserve map can be read through num_mem_rsv() and
get_mem_rsv(), but changing it requires calling the raw fdt_* wrappers
with the private Fdt._fdt buffer, as the class exposes no methods for
the write side.
Add them next to the existing accessors.
This is a backport of dtc commit 89c99ce78ac8 ("pylibfdt: Add
add_mem_rsv() and del_mem_rsv()").
Link: https://github.com/dgibson/dtc/pull/190
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexey Charkov <alchark@flipper.net>
|
|
Finding out how many cells a node's children use for addresses and sizes
currently requires calling the raw fdt_address_cells()/fdt_size_cells()
wrappers with the private FdtRo._fdt buffer, as the class exposes no
methods for them.
Add them to FdtRo alongside the other node accessors.
This is a backport of dtc commit 3750493c8b0f ("pylibfdt: Add
address_cells() and size_cells()").
Link: https://github.com/dgibson/dtc/pull/190
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexey Charkov <alchark@flipper.net>
|
|
Every expansion copies the whole tree into a freshly allocated buffer, so
growing by a fixed amount makes building a tree cost time quadratic in
its size. This is especially painful when assembling larger FIT images with
binman, as it assembles the image with the data inline.
Grow by at least as much as the tree already holds, which is what variable
sized arrays usually do specifically to avoid such excessive copying.
With this change, building a Rockchip TF-A+Falcon image whose FIT carries
a 31 MiB kernel takes 33.1 s rather than 44.4 s, with binman itself down
from 25.3 s to 14.0 s, as 7139 reallocations become 187. The images
produced are byte-identical and the binman and dtoc test results are
unaffected.
This is a backport of dtc commit 0748c384fde6 ("pylibfdt: Grow the FdtSw
buffer geometrically").
Link: https://github.com/dgibson/dtc/pull/189
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Alexey Charkov <alchark@flipper.net>
|
|
Spell "Tuple" correctly.
This is the pylibfdt part of dtc commit 205fbef17b7b ("Fix some typos");
the other files that commit touches carry no such typos in tree.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
[adapt to U-Boot, rewrite commit message accordingly]
Signed-off-by: Alexey Charkov <alchark@flipper.net>
|
|
When our Python functions wrap `fdt_getprop()` they return a list
containing `[*data, length]`.
In SWIG v4.2 and earlier SWIG would discard `*data` if it is NULL/None.
Causing the return value to just be `length`.
But starting in SWIG v4.3 it no longer discards `*data`. So the return
value is now `[None, length]`.
Handle this compatibility issue in libfdt.i by checking if the return
value looks like the older 4.2 return value, and casting it to the newer
style.
See https://github.com/swig/swig/pull/2907
This is a backport of dtc commit 9a969f3b70b0 ("pylibfdt/libfdt.i: fix
backwards compatibility of return values"). Its prerequisite is already
in tree as commit a63456b9191f ("scripts/dtc/pylibfdt/libfdt.i_shipped:
Use SWIG_AppendOutput").
Signed-off-by: Brandon Maier <brandon.maier@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
[adapt to U-Boot]
Signed-off-by: Alexey Charkov <alchark@flipper.net>
|
|
The test for get_mem_rsv fails on newer versions of Python with the
following error.
> AssertionError: Lists differ:
> [16045690981097406464, 1048576] != [0, 16045690981097406464, 1048576]
It appears this is because the PyTuple_GET_SIZE() function that was used
to build the fdt_get_mem_rsv() return value has changed. It now is
returning a non-zero value when it's passed an integer, which causes the
SWIG wrapper to append the returned arguments to the return error rather
then ignore them.
This is valid behaviour per Python's documentation, which says it will
"Return the size of the tuple p, which must be non-NULL and point to a
tuple; no error checking is performed"[1]. As passing an integer is not
a tuple, its return value is undefined.
Fix this issue on older and newer versions by avoiding
PyTuple_GET_SIZE() entirely. Always append the arguments to the list,
and instead use the wrapper python function to check the first argument
and then splice the last two arguments as the return value.
[1] https://docs.python.org/3/c-api/tuple.html#c.PyTuple_GET_SIZE
This is a backport of dtc commit 822123856980 ("pylibfdt: fix get_mem_rsv
for newer Python versions"), keeping the SWIG_AppendOutput() spelling
introduced by commit a63456b9191f ("scripts/dtc/pylibfdt/libfdt.i_shipped:
Use SWIG_AppendOutput").
Signed-off-by: Brandon Maier <brandon.maier@collins.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
[adapt to U-Boot]
Signed-off-by: Alexey Charkov <alchark@flipper.net>
|
|
Boolean properties are unusual in that their presense or absence
indicates the value of the property. This makes them a little painful to
support using the existing getprop() support.
Add new methods to deal with booleans specifically.
This is a backport of dtc commit 52157f13ef3d ("pylibfdt: Support boolean
properties"), without the dtc-side tests, which have no counterpart in
U-Boot's test suite.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
[adapt to U-Boot]
Signed-off-by: Alexey Charkov <alchark@flipper.net>
|
