In some use cases, board-specific device tree changes must not be
overwritten by system fixups. Although U-Boot provides
ft_board_setup_ex() for this purpose, it is currently only used on TI
Keystone. Make ft_board_setup_ex() to be a generic option, allowing its
use by other architectures/boards. To maintain backward compatibility,
enable it by default on TI Keystone.

Signed-off-by: João Paulo Gonçalves <joao.goncalves@toradex.com>

One of the problems an OS may face, when running in EFI, is that
a mounted ISO, after calling ExitBootServices goes away, if that ISO
is resident in RAM memory as a ramdisk.

ACPI has NFIT and NVDIMM support to provide ramdisks to the OS, but we
don't have anything in place for DTs. Linux and device trees have support
for persistent memory devices. So add a function that can inject a pmem
node in a DT, so we can pass information on the ramdisk the OS.

Signed-off-by: Masahisa Kojima <kojima.masahisa@socionext.com>
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

Dmitry Rokosov <ddrokosov@salutedevices.com> says:

This series consists of three patches.

The first patch modifies the function documentation style in the
include/fdt_support.h file to comply with kernel-doc requirements.

The second patch modifies the board_fdt_chosen_bootargs() function to
return a const char* type. This change clarifies to the caller that the
returned string should neither be freed nor modified. It aligns with the
existing fdt_setprop() function, which already utilizes a const char*
parameter. This promotes consistency within the codebase and enhances
code safety by preventing unintended modifications to the returned
string.

The third patch addresses the need for flexibility in providing kernel
command line arguments (bootargs) for different kernel images within the
same U-Boot environment. It introduces a read-only (RO) fdt_property
argument to the board_fdt_chosen_bootargs() function, allowing access to
the original chosen/bootargs data. This is crucial for scenarios where
different kernel versions require distinct console setups (e.g., ttyS0
for vendor kernels and ttyAML0 for upstream kernels). By enabling board
developers to either merge or replace the original bootargs, this
patch enhances the configurability of U-Boot for various kernel
images without relying on outdated configurations like CMDLINE_EXTEND.

CI/CD results: https://github.com/u-boot/u-boot/pull/716/checks

Link: https://lore.kernel.org/r/20241220-board_fdt_chosen_bootargs_improvements-v1-0-f6a7181787c5@salutedevices.com

Sometimes, it is necessary to provide an additional bootargs string to
the kernel command line.

We have a real scenario where one U-Boot blob needs to boot several
kernel images: the vendor-patched kernel image and the latest upstream
kernel image. The Amlogic (Meson architecture) tty driver has different
tty suffixes in these kernels: the vendor uses 'ttySx', while the
upstream implementation uses 'ttyAMLx'. The initial console setup is
provided to the kernel using the kernel command line (bootargs). For the
vendor kernel, we should use 'console=ttyS0,115200', while for the
upstream kernel, it must be 'console=ttyAML0,115200'. This means we have
to use different command line strings depending on the kernel version.

To resolve this issue, we cannot use the CMDLINE_EXTEND kernel
configuration because it is considered legacy and is not supported for
the arm64 architecture. CMDLINE_EXTEND is outdated primarily because we
can provide additional command line strings through the
'chosen/bootargs' FDT node. However, U-Boot uses this node to inject the
U-Boot bootargs environment variable content, which results in U-Boot
silently overriding all data in the 'chosen/bootargs' node. While we do
have the board_fdt_chosen_bootargs() board hook to address such issues,
this function lacks any FDT context, such as the original value of the
'chosen/bootargs' node.

This patch introduces a read-only (RO) fdt_property argument to
board_fdt_chosen_bootargs() to share the original 'chosen/bootargs' data
with the board code. Consequently, the board developer can decide how to
handle this information for their board setup: whether to drop it or
merge it with the bootargs environment.

Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

It should be structured this way to demonstrate to the caller that
freeing the return value is unnecessary and that the caller cannot
modify it.
The function fdt_setprop() includes a parameter with a const char*
prototype, so it is better to use the const qualifier.

Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

No errors from kernel-doc with this patch applied:
$ ./scripts/kernel-doc -v -none include/fdt_support.h
    include/fdt_support.h:17: info: Scanning doc for arch_fixup_fdt
    include/fdt_support.h:37: info: Scanning doc for fdt_root
    include/fdt_support.h:48: info: Scanning doc for fdt_chosen
    include/fdt_support.h:59: info: Scanning doc for fdt_initrd
    include/fdt_support.h:100: info: Scanning doc for fdt_fixup_memory
    include/fdt_support.h:115: info: Scanning doc for fdt_fixup_memory_banks
    include/fdt_support.h:148: info: Scanning doc for fdt_fixup_display
    include/fdt_support.h:176: info: Scanning doc for fdt_record_loadable
    include/fdt_support.h:205: info: Scanning doc for ft_board_setup
    include/fdt_support.h:218: info: Scanning doc for board_rng_seed
    include/fdt_support.h:231: info: Scanning doc for board_fdt_chosen_bootargs
    include/fdt_support.h:251: info: Scanning doc for ft_system_setup
    include/fdt_support.h:266: info: Scanning doc for fdt_shrink_to_minimum
    include/fdt_support.h:301: info: Scanning doc for fdt_copy_fixed_partitions
    include/fdt_support.h:314: info: Scanning doc for fdt_translate_address
    include/fdt_support.h:327: info: Scanning doc for fdt_translate_dma_address
    include/fdt_support.h:342: info: Scanning doc for fdt_get_dma_range
    include/fdt_support.h:464: info: Scanning doc for fdt_get_cells_len
    include/fdt_support.h:480: info: Scanning doc for fdtdec_get_child_count
    include/fdt_support.h:500: info: Scanning doc for fdt_kaslrseed

Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
Acked-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

Increase rng-seed size to make Linux happy and initialize rng pool instantly.
Linux 5.19+ requires 32 bytes of entropy to initialize random pool, but u-boot
currently provides only 8 bytes.
Linux 5.18 and probably some versions before it used to require 64 bytes.
Bump min value to 64 bytes to be on a safe side.

Boot with 8 byte rng-seed (Linux 6.11):
    # dmesg | grep crng
    [   12.089286] random: crng init done
Boot with 32 byte rng-seed (Linux 6.11):
    # dmesg | grep crng
    [    0.000000] random: crng init done

Linux source references:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c?h=v5.19#n551
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c?h=v5.18#n236

Signed-off-by: Alex Shumsky <alexthreed@gmail.com>
Fixes: d2048bafae40 ("rockchip: board: Add board_rng_seed() for all Rockchip devices")
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Reviewed-by: Marek Vasut <marex@denx.de>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

If RANDOMIZE_BASE is enabled in the Linux kernel instructing it to
randomize the virtual address at which the kernel image is loaded, it
expects entropy to be provided by the bootloader by populating
/chosen/kaslr-seed with a 64-bit value from source of entropy at boot.

Add a fdt_kaslrseed function to accommodate this allowing an existing
node to be overwritten if present. For now use the first rng device
but it would be good to enhance this in the future to allow some sort
of selection or policy in choosing the rng device used.

Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Michal Simek <michal.simek@amd.com>
Cc: Andy Yan <andy.yan@rock-chips.com>
Cc: Akash Gajjar <gajjar04akash@gmail.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Simon Glass <sjg@chromium.org>
Cc: Patrick Delaunay <patrick.delaunay@foss.st.com>
Cc: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Devarsh Thakkar <devarsht@ti.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Tom Rini <trini@konsulko.com>
Cc: Chris Morgan <macromorgan@hotmail.com>
Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>

Create separate helper for just reserving framebuffer region without
creating or enabling simple-framebuffer node.

This is useful for scenarios where user want to preserve the bootloader
splash screen till OS boots up and display server gets started without
displaying anything else in between and thus not requiring
simple-framebuffer.

Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
Reviewed-by: Nikhil M Jain <n-jain1@ti.com>

This may as well happen before the general event is emitted, so move it.
This will allow us to use the livetree for the event part, but the
flattree for the earlier part.

Signed-off-by: Simon Glass <sjg@chromium.org>