In case MULTI_DTB_FIT_GZIP is enabled, fdtdec_setup() does uncompress
the compressed DTs in uncompress_blob() using gunzip(), which invokes
malloc() internally. The early simple malloc is initialized in board_f
initf_malloc() call, which sets up the early simple malloc limit and
offset pointer in global data. Currently, the initf_malloc() is called
after fdtdec_setup(), which leads to malloc failure in fdtdec_setup()
during the gzip decompression, because the early simple malloc is not
initialized yet.
Call initf_malloc() before fdtdec_setup() to assure fdtdec_setup() can
use malloc() during gzip decompression of the DTs.
The impact of this change on boot time is negligible, because the
initf_malloc() only assigns two fields in global data.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Fixes: 95f4bbd581 ("lib: fdt: Allow LZO and GZIP DT compression in U-Boot")
Reviewed-by: Simon Glass <sjg@chromium.org>
[trini: Update test/py/tests/test_trace.py]
Signed-off-by: Tom Rini <trini@konsulko.com>
When CONFIG_MULTI_DTB_FIT is enabled, fit-dtb.blob is produced by
mkimage with one "-b " argument for every entry in CONFIG_OF_LIST.
The make rule, however, only listed dts/dt.dtb (i.e. the
CONFIG_DEFAULT_DEVICE_TREE blob) as a prerequisite:
fit-dtb.blob: dts/dt.dtb FORCE
$(call if_changed,mkimage)
Because FORCE is PHONY, if_changed ignores it and rebuilds only when
any-prereq or arg-check is non-empty. Editing a non-default dts in
OF_LIST rebuilds its .dtb (tracked correctly via fixdep), but that
.dtb was not a prerequisite of fit-dtb.blob, so $? stayed empty; the
mkimage command line was unchanged too, so arg-check was empty as
well. if_changed therefore skipped mkimage and fit-dtb.blob kept the
stale dtbs. u-boot.bin, which appends fit-dtb.blob, then shipped the
old device tree and the dts change did not take effect.
A previous attempt to fix this added every OF_LIST .dtb *output* as a
prerequisite. That is wrong on two counts:
- Clean build regression: the OF_LIST .dtb files are produced only
by the recursive dts/dt.dtb -> arch-dtbs sub-make descent and have
no rule at the top make level, so listing them as prerequisites
makes them rule-less/intermediate. After a from-scratch rebuild
(e.g. wiping an out-of-tree build directory) it fails:
make[1]: *** No rule to make target 'arch/arm/dts/.dtb',
needed by 'fit-dtb.blob'. Stop.
- Incremental two-build race still present: the .dtb outputs are
written by a child sub-make descent while the parent make level
checks prerequisites, so under `make -j` an edit can still need
two make invocations to take effect.
List the .dts *sources* instead, which the top make level can see via
VPATH in both objtree and srctree. Use $(dt_dir), as
MKIMAGEFLAGS_fit-dtb.blob already does just below, so that
CONFIG_OF_UPSTREAM boards (whose sources live under dts/upstream/src/)
are handled too; a helper variable keeps the rule under 80 columns.
Limitation: this only catches edits to the top-level .dts files in
OF_LIST. An edit to an included .dtsi (including the *-u-boot.dtsi
files) rebuilds the .dtb but leaves fit-dtb.blob stale, so the
two-build problem remains in that case. Fixing that fully would need
the .dtb outputs (rather than the .dts sources) as prerequisites,
which reintroduces the clean-build problem above; covering top-level
.dts edits is already a worthwhile improvement.
Signed-off-by: Lianghong Liu <liulhong617@163.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit aa5ef3c0a7 ("bootretry: check for bootretry variable changes")
broke the feature where one can define different keys for "delaying"
versus "stopping" boot. The way the latter is implemented is by the code
in autoboot.c calling bootretry_dont_retry() when the stop sequence
has been detected, and that simply sets the retry_time variable in
bootretry.c to -1.
However, with the mentioned commit, that is unconditionally overridden
on every command, since it gets re-initialized from either the
bootretry environment variable or CONFIG_BOOT_RETRY_TIME, thus making
"delay" and "stop" effectively the same.
To fix that, while still picking up changes to the bootretry
environment variable, use the proper mechanism for C code to be
notified about changes to environment variables.
Since the callback is invoked before the change has actually been done
to the environment (callbacks can reject the change from taking
effect), we cannot simply call the existing
bootretry_init_cmd_timeout() from the callback, as its env_get() would
not see the new value. Instead, refactor most of it to an internal
bootretry_parse(), and call that with the new value (which is NULL in
the case bootretry is being deleted, so that works exactly as it
should).
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Enable main_uart2 and main_uart3 for console log functionality.
Add clk and device data for main_uart2 and main_uart3
which can be used by main_uart driver to configure clocks and PSC.
Signed-off-by: Gokul <g-praveen@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
U-Boot running as a coreboot payload obtains serial console
information either from the coreboot table or from the ACPI DBG2
table.
When serial console support is disabled in coreboot, the coreboot
table does not contain serial information. In this case U-Boot falls
back to parsing the DBG2 table.
Some AMD platforms or any other platforms that uses memory-mapped I/O
advertise the debug UART using DBG2 subtype 0x0012 ("16550-compatible
with parameters defined in Generic Address Structure"). U-Boot
currently accepts only subtype 0x0000, causing DBG2 UART detection to
fail and leaving no console output.
Accept subtype 0x0012 as well and keep the existing handling logic.
Signed-off-by: Desapogu Jayaramudu <jayaramudu.desapogu@amd.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The SCSI command currently prints the following duplicate prefix:
"
=> scsi
scsi - SCSI sub-system
Usage:
scsi scsi info - show available SCSI devices
^^^^^^^^^
scsi scan - (re-)scan SCSI bus
"
Drop one copy of the scsi prefix.
Fixes: 460c322f13 ("(re)enabled scsi commands do_scsi() and do_scsiboot() Patch by Denis Peter, 06 Dec 2004")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: David Lechner <dlechner@baylibre.com>
Simplify the code, replace env_get_f() with env_get_yesno(). The
env_get_yesno() internally calls env_get() which may fall back to
env_get_f() if the environment access is not initialized yet.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Stefan Roese <stefan.roese@mailbox.org>
Cole Munz <Munzzyy1@proton.me> says:
As agreed on the v1 thread, the fix and the cleanups are now separate
patches:
- patch 1 is the fix in the v1 shape
- patch 2 makes btrfs_search_slot() release the path on error like
the kernel version does. That is where the btrfs_size() leak came
from. Suggested by Qu.
- patch 3 is the dedup Alexey asked about. One helper shared by
btrfs_readdir() and btrfs_size().
The pending btrfs test suite still passes on top of the readdir
series: 5 passed.
Link: https://lore.kernel.org/r/cover.1785660029.git.Munzzyy1@proton.me
btrfs_readdir() and btrfs_size() both open code the same search for an
inode item to read its size field. Move it into one helper.
Signed-off-by: Cole Munz <Munzzyy1@proton.me>
Reviewed-by: Qu Wenruo <wqu@suse.com>
The U-Boot copy of btrfs_search_slot() returns on error with the nodes
it has descended through still attached to the path. The kernel one
releases the path on any error unless p->skip_release_on_error is set,
and callers written against that convention treat a failed search as
owning nothing. btrfs_size() is one: it returns straight away on a
search error and never reaches its btrfs_release_path() call, so the
attached extent buffer references leak.
Route both error exits through a release of the path. The error
returns of read_node_slot() carry no extra reference, so the path is
the only thing to clean up.
Suggested-by: Qu Wenruo <quwenruo.btrfs@gmx.com>
Signed-off-by: Cole Munz <Munzzyy1@proton.me>
Reviewed-by: Qu Wenruo <wqu@suse.com>
btrfs_readdir() zeroes the dirent and fills in only the name and the
type, so dent->size stays 0 and every file is listed as zero bytes:
=> ls host 0 /
0 f_192k.bin
0 small_3k.bin
Reads themselves are fine, since btrfs_read() takes the size from
btrfs_size(), which does its own inode item lookup. It affects EFI
too: dir_read() in lib/efi_loader/efi_file.c copies dent->size into
both file_size and physical_size, so an EFI application enumerating a
directory on btrfs sees every file as empty, which is the generic-code
path Alexey's readdir series moves btrfs onto.
The custom listing that fs_ls_generic() replaced looked the inode item
up and printed the real size, and every other filesystem in the tree
fills dent->size in its own readdir: ext4fs.c:327, exfat io.c:805,
erofs fs.c:186, squashfs sqfs.c:1095 and fat.c:1555.
btrfs_next_dir_entry() already has the dir item mapped, so read the
key it points at while we are there and hand it back to the caller,
and use that to reach the inode item. A subvolume entry points at a
root item instead and has no size of its own, so leave that one at 0.
=> ls host 0 /
196608 f_192k.bin
3000 small_3k.bin
Fixes: 31cf3f1778 ("fs: btrfs: use fs_ls_generic() and drop custom implementation")
Signed-off-by: Cole Munz <Munzzyy1@proton.me>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Daniel Golle <daniel@makrotopia.org> says:
A signed FIT configuration can delegate the integrity of a (potentially
large) root filesystem image to the kernel's dm-verity instead of having
U-Boot hash the whole payload at boot: the FIT carries a "dm-verity"
subnode with the roothash, salt and block parameters, U-Boot passes the
roothash to Linux through the dm-mod.create bootargs, and dm-verity then
validates the filesystem block by block against it.
For that to be safe the roothash has to be trusted, and in a signed
configuration the only thing that establishes trust is the configuration
signature. The roothash was not covered by it. fit_config_add_hash()
collected the image node, its hash subnodes and its cipher subnode into
the signed region, but not the dm-verity subnode, so the roothash, the
sole integrity anchor for the filesystem, was left unsigned.
The result is a verified-boot bypass for the root filesystem: an
attacker who can rewrite the boot medium can replace the filesystem,
recompute a matching dm-verity tree, write the new roothash into the
unsigned dm-verity subnode, and the configuration signature still
verifies. dm-verity then faithfully validates the malicious filesystem
against the attacker's roothash.
This series closes the gap.
Link: https://lore.kernel.org/r/cover.1785276461.git.daniel@makrotopia.org
A dm-verity protected filesystem image is not hashed by U-Boot; its
integrity is delegated to the kernel, which trusts the roothash taken
from the FIT dm-verity subnode. For that chain of trust to hold, the
roothash (and salt) must be part of the region covered by the
configuration signature, otherwise an attacker can replace both the
filesystem and the roothash while keeping the signature valid.
Add two independent checks of this property:
- test/py/tests/test_fit_verity_sign.py signs a configuration that
references a filesystem image carrying a dm-verity subnode, then
confirms that tampering the roothash or the salt is rejected by
fit_check_sign. A control that tampers a byte known to be signed
proves the check can fail. A matching page is added under
doc/develop/pytest/ so the module documentation is rendered with
the rest of the generated docs.
- test/boot/fit_verity.c gains a runtime unit test that builds the
exact node list the configuration signature is computed over,
turns it into hashed regions and checks both that the roothash
bytes fall inside a signed region and that tampering them changes
the hash. It needs no private key, so it also runs on real devices
and uses the same hash path a device would.
To let the unit test build the signed-region node list, rename the
config node-list helper to fit_config_get_signed_nodes(), make it
non-static and declare it in image.h.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
A dm-verity protected filesystem image is not hashed by U-Boot when it
is loaded; its integrity is delegated to the kernel, which validates the
filesystem on the fly against the roothash taken from the FIT dm-verity
subnode. The roothash is therefore the sole integrity anchor for the
filesystem, yet fit_config_add_hash() only adds the image node, its
hash subnodes and its cipher subnode to the signed region, leaving the
dm-verity subnode (roothash, salt and block parameters) unsigned.
An attacker able to rewrite the boot medium could then replace both the
filesystem and the roothash, recompute a matching dm-verity tree and
keep the configuration signature valid, defeating verified boot for the
root filesystem.
Add the dm-verity subnode to the list of nodes covered by the
configuration signature, both when signing (tools/image-host.c) and when
verifying (boot/image-fit-sig.c), so the roothash and salt are
authenticated together with the rest of the configuration.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Both the boot-side and host-side fit_config_add_hash() repeat the same
sequence to append a node's path to the hashed-node list three times:
for the image node, for each hash subnode and for the cipher subnode.
Extract it into a helper, fit_config_add_node(), in each file, with no
functional change.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
MediaTek platforms may need the MTU3 controller before U-Boot proper is
available, but the driver is currently selected and built only with the
main U-Boot configuration symbols.
Add an explicit SPL controller option with host and gadget modes. Make
the driver build and its role checks phase-aware so each phase can select
the MTU3 role it needs without coupling it to the U-Boot proper controller
configuration.
The upstream binding locates the xHCI child registers through the parent
ranges property. Select SPL_OF_TRANSLATE for host mode so SPL can resolve
that address before mapping it.
Signed-off-by: Julien Masson <jmasson@baylibre.com>
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
Reviewed-by: Marek Vasut <marek.vasut+usb@mailbox.org>
The MTU3 glue driver expects a synthetic mediatek,ssusb child that
combines the device and xHCI register windows. Upstream devicetrees
instead put the device resources on the controller node and describe the
xHCI window with a standard child node, so U-Boot cannot use an upstream
topology.
Switch to the upstream layout. The controller owns the shared resources
and the device MAC, with the device register offsets relative to it as in
Linux. The gadget role binds as a node-less internal device, while the
host role binds to an enabled xHCI child and uses its own clocks,
supplies and register window. dr_mode selects the role and defaults to
otg, and the Kconfig choice constrains which role the build provides.
The legacy child layout is rejected explicitly so its combined register
window cannot be mistaken for the device MAC.
Convert the in-tree MT8183 and MT8512 devicetrees in the same commit so
neither platform is left without USB. MT8512 stays peripheral-only
because its xHCI host interrupt is not documented and the
mediatek,mtk-xhci binding requires it.
Reviewed-by: Marek Vasut <marek.vasut+usb@mailbox.org>
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
The MediaTek MTU3 and xHCI text bindings describe legacy U-Boot layouts
which have been superseded by the canonical Linux schemas. Those schemas
are already synchronized into `dts/upstream/Bindings/usb`.
Remove the duplicate text bindings so new devicetrees and driver changes
use the maintained YAML definitions.
Reviewed-by: Marek Vasut <marek.vasut+usb@mailbox.org>
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
This includes temporary U-Boot DT ECC carveouts for R-Car Gen5, they
will be dropped from U-Boot DTs once OF_UPSTREAM DTs get re-synced.
This also includes RPC-IF support for R-Car Gen5 and env storage in RPC
HF.
This also includes an update for R-Car Gen5 UFS controller driver.
The DBSC5 DRAM controller protects DRAM content using inline ECC.
The inline ECC utilizes areas of DRAM for its operation, which are
in the DRAM address range, but must not be accessed or modified.
Describe the inline ECC carveout areas used by the DBSC5 controller
on this hardware as reserved-memory, which must not be accessed.
Include DRAM areas which are unprotected by ECC as well, those are
parts of the DRAM which directly precede the ECC carveout.
In case of high DRAM utilization, unless the inline ECC carveouts
are properly reserved, Linux may use and corrupt the memory used
by the DBSC5 DRAM controller for inline ECC, which would lead to
the system becoming unstable.
Ported from Linux 7.2-rc5 commit
6fa6ee724d8d ("arm64: dts: renesas: ironhide: Describe inline ECC carveouts")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Fully describe all available DRAM in the DT, and describe regions which
are not accessible because they are used by firmware in reserved-memory
nodes.
Replace the first memory bank memory@60600000 with memory@40000000 and a
518 MiB long reserved-memory no-map subnode. This memory region is used
by other cores in the system.
Reserve 32 kiB of memory at 0x8c100000 for parameters shared by IPL,
SCP, TFA BL31 and TEE.
Reserve 512 kiB of memory at 0x8c200000 for TFA BL31. The upcoming
upstream TFA 2.15 BL31 uses memory from 0x8c200000..0x8c242fff; rounding
up to 512 kiB is slight future-proofing.
Reserve 32 MiB of memory at 0x8c400000 for OPTEE-OS, which is the entire
OPTEE-OS TZ protected DRAM area.
Neither TFA BL31 nor OPTEE-OS modify the DT passed to Linux in any way
with any new reserved-memory {} nodes to reserve memory areas used by
the TFA BL31 or OPTEE-OS to prevent the next stage from using those
areas, which lets Linux use all of the available DRAM as it is described
in the DT that was passed in by U-Boot, including the areas that are
newly utilized by TFA BL31 or OPTEE-OS.
In case of high DRAM utilization, unless the memory used by TFA BL31 or
OPTEE-OS is properly reserved, Linux may use and corrupt the memory used
by TFA BL31 or OPTEE-OS, which would lead to the system becoming
unresponsive.
Ported from Linux 7.2-rc5 commit
5250b3b1ad99 ("arm64: dts: renesas: ironhide: Describe all reserved memory")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Store U-Boot environment in the last sector of HyperFlash on
R-Car R8A78000 X5H Cortex-M33 RSIP port. This allows the RSIP
port to have persistent environment, which is very useful for
development.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Enable RPC and HyperFlash support on R-Car R8A78000 X5H Cortex-M33 RSIP.
RPC is used both to update the HF content, which includes the U-Boot on
RSIP itself and SCP firmware, as well as access the U-Boot environment
for U-Boot on RSIP.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Bind RPC and HyperFlash in DT on R-Car R8A78000 X5H Cortex-M33 RSIP.
RPC is used both to update the HF content, which includes the U-Boot on
RSIP itself and SCP firmware, as well as access the U-Boot environment
for U-Boot on RSIP.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Disable MMC support on R-Car R8A78000 X5H Cortex-M33 RSIP port.
The MMC is never used by the RSIP core, disable the support.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add device tree compatible string "renesas,rcar-gen5-rpc-if" to
the driver to match on upstream RPC DT node in R-Car Gen5 DTs.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Remove the IF from RPCIF to align the register macros with each other.
No functional change.
Fixes: d516246324 ("mtd: spi: renesas: Configure RPC PHY timing registers")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add device tree compatible string "renesas,rcar-gen5-rpc-if" to
the driver to match on upstream RPC DT node in R-Car Gen5 DTs.
Adjust Kconfig to allow driver enablement on all 64bit R-Car.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Simplify the DT register address parsing using dev_read_addr_name(),
switch away from raw fdt_*() functions. No functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
CI: https://git.u-boot-project.org/u-boot/custodians/u-boot-imx/-/pipelines/906
- Fix a boot regression on i.MX7 related to the system counter.
- Add Aquila iMX95 0243 PID4.
- Update phycore_imx8mm DDR timings.
- Add FRDM-IMX95 initial support.
- Handle FCFB header during SPI NOR boot and CST backend selection.
With commit 623f6c5b6a ("boot: image-fdt: free old dtb reservations")
we now get:
ERROR: freeing fdt memory region failed (addr=3ef667e0 size=36 flags=2): -1
ERROR: freeing fdt memory region failed (addr=3ef663a0 size=400 flags=2): -1
on console when booting, which is non-fatal but leads to the test
failing. Disable this test for now.
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
* Clock fix for MT8188 (Genio 700/520)
* SPL support preparatory patch for MT8188.
* Compile error fix for when enabling LWIP network stack on some MediaTek targets.
* Fix a regression in clock driver binding from the previous PR.
* Add display-related clocks on MT8188.
* Another wave of clock driver refactoring and de-duplication.
In case the image that is wrapped in the nxp_imx8mcst already contains
an FCFB header which is mandatory for SPI NOR boot, then the IVT is at
offset 0x1000 instead of offset 0x0, but the whole image including the
FCFB header must be signed to prevent attacker from tampering with any
of the headers. Add the FCFB handling.
Signed-off-by: Marek Vasut <marex@nabladev.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add boot support and peripherals like eMMC/SD, UART, I2C, GPIO, ENETC0/1
and PCIE0/1 for iMX95 15x15 FRDM.
Updated doc for build instructions.
Signed-off-by: Lei Xu <lei.xu@nxp.com>
Signed-off-by: Joseph Guo <qijian.guo@nxp.com>
MT8188 reset_cpu() checks the U-Boot proper PSCI symbol even when the
function is built for SPL. A standalone SPL download agent runs before
BL31, so fastboot acknowledges a reboot request and then stalls while
attempting an unavailable PSCI system reset.
Use the phase-aware configuration check so SPL falls back to the
watchdog reset provider. U-Boot proper continues to use PSCI as before.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
Reviewed-by: Julien Stephan <jstephan@baylibre.com>
Link: https://patch.msgid.link/20260724-ccaione-upstream-mt8188-spl-reset-v1-1-08da6554ecd8@baylibre.com
Signed-off-by: David Lechner <dlechner@baylibre.com>
Add U-Boot support for Milk-V Duo 256M.
This board has a different SoC compared to the Milk-V Duo 64M, it uses
the Sophgo SG2002 instead of the Sophgo CV1800B. Both SoCs share many
common IP blocks, so this board reuses the existing cv1800b CPU support.
The board shares the same 'board.c' with Milk-V Duo 64MB (CV1800B), so
use the same file for now.
Link: https://milkv.io/docs/duo/getting-started/duo256m
Signed-off-by: Hiago De Franco <hfranco@baylibre.com>
Acked-by: Leo Yu-Chi Liang <leo.liang@sifive.com>
This will make easier for future boards to reuse the same driver (e.g.
Milk-V Duo 256MB).
Signed-off-by: Hiago De Franco <hfranco@baylibre.com>
Acked-by: Leo Yu-Chi Liang <leo.liang@sifive.com>
The MPFS mailbox driver currently checks the BUSY bit at the start of
mpfs_mbox_send() and immediately returns -EBUSY if the controller is
busy.
On MPFS, BUSY may be transiently asserted during early boot even though
no other U-Boot service is actively executing. In Linux, returning
-EBUSY here is retryable via the mailbox framework and scheduler, but in
U-Boot this results in a hard failure.
Replace the immediate BUSY check with a bounded wait using
regmap_read_poll_timeout(), waiting for the controller to become idle
before issuing a new request. This preserves the intent of the BUSY
check while avoiding spurious early-boot failures in U-Boot’s
synchronous, polled execution model.
The timeout is conservative and based on observed MPFS behaviour, where
BUSY clears within a few milliseconds.
Signed-off-by: Jamie Gibbons <jamie.gibbons@microchip.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
The MPFS mailbox driver used unbounded polling loops and treated the
BUSY bit as a fatal condition in several paths. On MPFS, BUSY may be
transiently reasserted even after response data is written, which is
observable in U-Boot’s synchronous, polled execution model.
Replace the unbounded loops with a bounded
regmap_read_poll_timeout()-based helper that waits for the controller to
become idle.
This preserves existing behaviour while preventing infinite stalls
and avoiding spurious failures during early boot.
Signed-off-by: Jamie Gibbons <jamie.gibbons@microchip.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Enable the MPFS hardware RNG and associated infrastructure in
the Microchip PolarFire SoC generic defconfig.
Signed-off-by: Jamie Gibbons <jamie.gibbons@microchip.com>
Reviewed-by: Leo Yu-Chi Liang <leo.liang@sifive.com>
Tom Rini
Marek VasutandTom Rini
Lianghong LiuandTom Rini
Rasmus VillemoesandTom Rini
GokulandTom Rini
Desapogu JayaramuduandTom Rini
Cole MunzandTom Rini
Daniel GolleandTom Rini
Carlo CaioneandMarek Vasut
Tuyen DangandMarek Vasut
Marek VasutandFabio Estevam
Joseph GuoandFabio Estevam
Julien StephanandDavid Lechner
Hiago De FrancoandLeo Yu-Chi Liang
Jamie GibbonsandLeo Yu-Chi Liang