arm: mach-k3: j7200: Add mcu_timer0 id to the dev list

mcu_timer0 is now used as the tick timer in u-boot, so this adds the
timer to the soc device list so it can be enabled via the k3 power
controller.

Reviewed-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Reid Tonking <reidt@ti.com>

board: ti: am64x: Switch to standard boot flow

Switch to using bootstd. Note with this change, we will stop using
distro_bootcmd and instead depend entirely on bootflow method of
starting the system up.

Drop header files that are no longer needed in am64x_evm.h.
k3_dfu.h is available via k3_dfu.env in am64x.env.

Drop unused macro CFG_SYS_SDRAM_BASE1.

Signed-off-by: Roger Quadros <rogerq@kernel.org>
Reviewed-by: Nishanth Menon <nm@ti.com>

board: ti: am62x: am62x.env: Fix boot_targets

ti_mmc is not a valid boot_target for standard boot flow so
remove it. Prefer mmc1 (sd-card) over mmc0 (emmc).

Signed-off-by: Roger Quadros <rogerq@kernel.org>
Reviewed-by: Nishanth Menon <nm@ti.com>

clk: ti: clk-sci: Notify AVS driver based upon clock rate

AVS driver needs to be notified before or after clock change,
depending upon new rate is greater or less than current clock rate.

Fixes: 1e0aa873bc7cd ("clk: clk-ti-sci: Notify AVS driver upon setting clock rate")
Cc: Keerthy <j-keerthy@ti.com>
Signed-off-by: Udit Kumar <u-kumar1@ti.com>

clk: ti: clk-k3: Notify AVS driver upon setting clock rate

AVS is enabled at R5 SPL stage, on few platforms like J721E
and J7200 clk-k3 is used instead if clk-sci driver.

Add support in clk-k3 driver as well to notify AVS driver
on setting clock rate so that voltage is changed accordingly.

Cc: Keerthy <j-keerthy@ti.com>
Signed-off-by: Udit Kumar <u-kumar1@ti.com>

Merge branch '2023-10-12-expo-add-support-for-edting-lines-of-text'

To quote the author:
So far expo only supports menus. These are quite flexible for various
kinds of settings, but cannot deal with free-form input, such as a
serial number or a machine name.

This series adds support for a textline object, which is a single line
of text. It has a maximum length and its value is stored within the expo
structure.

U-Boot already has a command-line editor which provides most of the
features needed by expo. But the code runs in its own loop and only
returns when the line is finished. This is not suitable for expo, which
must handle a keypress at a time, returning to its caller after each
one.

In order to use the CLI code, some significant refactoring is included
here. This mostly involves moving the internal loop of the CLI to a
separate function and recording its state in a struct, just as was done
for single keypresses some time back. A minor addition is support for
Ctrl-W to delete a word, since strangely this is currently only present
in the simple version.

The video-console system provides most of the features needed by
testline, but a few things are missing. This series provides:

- primitive cursor support so the user can see where he is typing
- saving and restoring of the text-entry context, so that expo can allow
  the user to continue where he left off, including deleting previously
  entered characters correctly (for Truetype)
- obtaining the nominal width of a string of n characters, so that a
  suitable width can be chosen for the textline object

Note that no support is provided for clearing the cursor. This was
addressed in a previous series[1] which could perhaps be rebased. For
this implementation, the cursor is therefore not enabled for the normal
command line, only for expo.

Reading and writing textline objects is supported for FDT and
environment, but not for CMOS RAM, since it would likely use too much
RAM to store a string.

In terms of code size, the overall size increase is 180 bytes for
Thumb02 boards, 160 of whcih is the addition of Ctrl-W to delete a word.

[1] https://patchwork.ozlabs.org/project/uboot/list/?series=280178&state=*

expo: Update documentation to include textline

Update the expo documentation to include mention of this new object
type.

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

expo: Update tests to include textline

Provide test coverage for the new expo object type, including building
and reading/writing settings.

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

expo: Support building an expo with a textline

Add textline to the list of objects which tthe expo builder can build.
This allows them to be provided in the description.

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

expo: Plumb in textline to cedit

Support textlines in the configuration editor.

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

expo: Support handling any key in cedit

At present cedit only supports menu keys. For textline objects we need
to insert normal ASCII characters.

We also need to handle backspace, which is ASCII 9.

In fact, expo does not make use of all the menu keys, so partition
them accordingly and update the logic to support normal ASCII
characters, too.

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

video: Mark truetype_measure() static

This function is not used outside this file, so mark it static.

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

expo: Plumb in textlines to a scene

Provide an implementation for textlines in the scene code, so that they
are displayed correctly. Provide a way to have a border around the
textline, with the internal part being the same colour as the
background. This looks more natural.

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

expo: Support opening a textline

This object needs special handling when it is opened, to set up the CLI
and the vidconsole context. Add special support for this.

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

expo: Add basic support for textline objects

A textline is a line of text which can be edited by the user. It has a
maximum length (in chracters) but otherwise there are no restrictions.

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

expo: Add some scene fields needed for text entry

Add the CLI state, a buffer to hold the old value of the text being
edited and a place to save vidconsole entry context. These will be use
by the textline object.

Set an upper limit on the maximum number of characters in a textline
object supported by expo, at least for now.

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

expo: Allow rendering the background of any object

So far only menus have a background. When other object types are
rendered, they may have a background too. Make this code more generic
so it will be usable by new object types.

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

expo: Make calculation of an object bounding box generic

We want to support this for any object, not just menus. Move the code
around to allow this.

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

expo: Add a function to write a property to a devicetree

When the devicetree is too small for the property being written, we need
to expand the devicetree and retry the write.

Put this logic into a function so it can be reused.

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

expo: Allow highlighting other scene-object types

So far only menus can be highlighted. With the coming addition of
text lines we need to be able to highlight other objects. Add a function
to determine whether an object can be highlighted.

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

expo: Correct the logic for duplicate-ID detection

Update scene_txt_str() to account for the possibility that the passed-in
str_id may be 0

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

expo: Correct some swallowed errors in scene

Return the reported error, rather than assuming it is -ENOMEM

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

expo: Use switch statements more for object types

In a lot of cases menus are the only objects which are have their own
behaviour in the cedit, e.g. to move between menus. With expo expanding
to support text, this is no-longer true.

Use a switch() statement so that we can simply insert a new 'case' for
the new object types.

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

expo: Fix up comments for get_cur_menuitem_text() et al

This internal function could use a comment. Add one.

Also tidy up a few other comments.

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

expo: Add better error reporting

When building an expo fails, show some information about which node
caused the problem. Use -ENOENT consistently when the ID is missing.
This makes it easier for the user to debug things.

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

video: Support showing a cursor

Add rudimentary support for displaying a cursor on a vidconsole. This
helps the user to see where text is being entered.

The implementation so far is very simple: the cursor is just a vertical
bar of fixed width and cannot be erased. To erase the cursor, the text
must be redrawn over it.

This is good enough for expo but will need enhancement to be useful for
the command-line console. For example, it could save and restore the
area behind the cursor.

For now, enable this only for expo, to reduce code size.

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

video: Export vidconsole_entry_start()

At present this is called only when a newline is detected, since this
indicates the start of a line of text being entered.

Export this function so it can be used by expo, which may start a new
text line itself, without first writing out a newline.

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

video: Allow saving and restoring text-entry state

Text entry operates within a context which includes quite a bit of
information. For example, with Truetype fonts, each character in the
text string has a position stored, so that it is possible to
backspace to that character. This information is built up as strings
are drawn on the display.

For the command line, there is just a single context. It is created
when command-line entry starts and it is destroyed (or at least not
needed anymore) when the user presses <enter> to enter the command.

By contrast, expo needs to be able to switch in and out of a text-entry
context, since it is also displaying other objects in the scene.

Add a way to save and restore the entry context for a vidconsole. This
is only needed for the truetype vidconsole, so add a method for that,
storing the information in an abuf struct.

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

video: Allow obtaining the nominal size of a string size

At present there is a method for measuring text, but if the actual text
string is not known, it cannot be used.

For text editor we want to set the size of the entry box to cover the
expected text size. Add the concept of a 'norminal' size with a method
to calculate that for the vidconsole.

If the method is not implemented, fall back to using the font size,
which is sufficient for fixed-width fonts.

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

cli: Add a function to set up a new cread

Create a init function so that it is easy to use command-line reading.

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

cli: Allow command completion to be disabled

When inputting text outside the command line we don't want to use tab
for command completion. Add an option to control this.

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

cli: Allow history to be disabled

When inputting text outside the command line we don't want history to be
accessible. Add an option to control this.

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

cli: Terminate the string in cread_line_process_ch()

Rather than relying on the caller, terminate the string inside this
function. Do this each time we return, whether input is finished or
not. It is not needed when the input is aborted, since the string will
be discarded in that case.

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

cli: Create a function to process characters

Move most of the inner loop from cread_line() into a new function. This
will allow using it from other code.

This involves adding a few more members to the state struct.

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

cli: Unindent some code in cread_line()

Reduce the indentation level of this code so it is easier to review the
next patch, which moves it into a function.

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

cli: Convert cread_line() to use a struct for the main vars

We want to reuse the editing code elsewhere. As a first step, move the
common variables into a struct. This will allow us to eventually put the
contents of the inner loop in a function, so it can be called from
elsewhere.

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

cli: Use unsigned int instead of unsigned long

The index values are not very large so it makes no sense to use a long
integer. Change these to uint instead.

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

cli: Implement delete-word in cread_line()

The Ctrl-W option is implemented in the cread_line_simple() but not in
the full version. This seems odd, so add an implementation.

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

cli: Drop #ifdefs for CONFIG_AUTO_COMPLETE in cli_readline

Use a static inline and adjust the logic to avoid the need for #ifdefs in
cli_readline_into_buffer()

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

cli: Drop some #ifdefs in cli_readline

Add a few static inlines to avoid the need for #ifdefs in
cli_readline_into_buffer()

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

cli: Add a command to show cmdline history

There is a function for this but it is never used. Showing the history is
a useful feature, so add a new 'history' command.

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

cli: Move simple readline into a function

Move this code into its own function since it is a separate
implementation from the full version.

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

Revert "mkimage: update man page and -h output"

This is part of a longer series, which isn't quite ready.  Revert this
for now at least.

This reverts commit 4cb6c8e5f0de3c4c5f9eba51c6a1610934a8cf77.

Signed-off-by: Tom Rini <trini@konsulko.com>

Merge branch '2023-10-11-port-gen_compile_commands_py'

To quote the author:
I'm submitting a patch series that ports the gen_compile_commands.py
script from the Linux kernel's sources to U-Boot. This script,
originally located in scripts/clang-tools/gen_compile_commands.py,
enables the generation of compile_commands.json file for improved code
navigation and analysis. The series consists of the initial script
import, the necessary modifications for U-Boot compatibility, and
finally some documentation.

scripts/gen_compile_commands: fix usage message

Replace mentions to 'kernel' by 'U-Boot' to avoid confusion.

Signed-off-by: Joao Marcos Costa <jmcosta944@gmail.com>
Tested-by: Joao Paulo Goncalves <joao.goncalves@toradex.com>

doc: add ide_integration.rst to doc/develop

Add 'Integration with IDEs' chapter.

For now, this chapter is mostly a reference to the documentation of
gen_compile_commands, in doc/build, but it can be futurely used as
a guide for other IDE-friendly features.

Signed-off-by: Joao Marcos Costa <jmcosta944@gmail.com>
Tested-by: Joao Paulo Goncalves <joao.goncalves@toradex.com>

doc: add documentation for gen_compile_commands.py

This documentation briefly explains what is a compilation database,
and how to use the script to generate one.

This is not a portage, as there was no original documentation in the
Linux sources.

Acknowledge the documentation in the script's header and in doc/build
index.

Signed-off-by: Joao Marcos Costa <jmcosta944@gmail.com>
Tested-by: Joao Paulo Goncalves <joao.goncalves@toradex.com>

.gitignore: add compile_commands.json

Add Clang's compilation database file (i.e. compile_commands.json) to
.gitignore, at the root of the repository.

Signed-off-by: Joao Marcos Costa <jmcosta944@gmail.com>
Tested-by: Joao Paulo Goncalves <joao.goncalves@toradex.com>

scripts/gen_compile_commands.py: add acknowledgments

Add acknowledgments for porting and modifying the script. Of course, the
license, author, and copyright notice remain the same as in the original
script.

Signed-off-by: Joao Marcos Costa <jmcosta944@gmail.com>
Tested-by: Joao Paulo Goncalves <joao.goncalves@toradex.com>

scripts/gen_compile_commands.py: fix docstring

The referred tool is now in U-Boot. Replace "the Linux kernel" by
"U-Boot" to make the docstring coherent.

Signed-off-by: Joao Marcos Costa <jmcosta944@gmail.com>
Tested-by: Joao Paulo Goncalves <joao.goncalves@toradex.com>

scripts/gen_compile_commands.py: adapt _LINE_PATTERN

For U-Boot's context, the regular expression defined by _LINE_PATTERN
should be adapted. Replace 'savedcmd' by 'cmd'.

Signed-off-by: Joao Marcos Costa <jmcosta944@gmail.com>
Tested-by: Joao Paulo Goncalves <joao.goncalves@toradex.com>

scripts: Port Linux's gen_compile_commands.py to U-Boot

This script generates a database of compiler flags, namely
compile_commands.json. It is quite useful for text editors that use
clangd LSP (e.g. Vim, Neovim).

It was ported from Linux's sources:
- tag: v6.4
- revision 6995e2de6891c724bfeb2db33d7b87775f913ad1

Modifications for U-Boot compatibility will be added in a follow-up
commit.

Signed-off-by: Joao Marcos Costa <jmcosta944@gmail.com>
Tested-by: Joao Paulo Goncalves <joao.goncalves@toradex.com>

configs: Resync with savedefconfig

Rsync all defconfig files using moveconfig.py

Signed-off-by: Tom Rini <trini@konsulko.com>

Merge branch '2023-10-11-assorted-fixes-and-updates'

- Assorted TI K3 updates, use ".dtso" for device tree overlays to match
  general usage, mkimage fixes/improvements, assorted platform
  updates/fixes, other assorted driver/platform fixes.

configs: Make TI_SECURE_DEVICE default for K3

All K3 boards now are secure by default, instead of setting this in each
defconfig, make it implied by the ARCH config.

The only exception is IOT2050, which I do not believe will have any
problems with being a TI_SECURE_DEVICE, but for now turn it off to keep
its config the same.

Signed-off-by: Andrew Davis <afd@ti.com>
Tested-by: Tom Rini <trini@konsulko.com>

configs: am65x: Merge the HS and non-HS defconfigs

K3 devices have runtime type board detection. Make the default defconfig
include the secure configuration. Then remove the HS specific config.

Non-HS devices will continue to boot due to runtime device type detection.

Signed-off-by: Andrew Davis <afd@ti.com>
Tested-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Manorit Chawdhry <m-chawdhry@ti.com>

ARM: psci: move GIC address override to Kconfig

As the code to switch an ARM core from secure to the non-secure state
needs to know the base address of the Generic Interrupt Controller
(GIC), we read an Arm Cortex defined system register that is supposed to
hold that base address. However there are SoCs out there that get this
wrong, and this CBAR register either reads as 0 or points to the wrong
address. To accommodate those systems, so far we use a macro defined in
some platform specific header files, for affected boards.

To simplify future extensions, replace that macro with a Kconfig variable
that holds this override address, and define a default value for SoCs
that need it.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Sam Edwards <CFSworks@gmail.com>

misc: fs_loader: Fix alignment of fs_loader driver

DM_DRIVER_GET will redeclare the fs_loader driver without the correct
alignment. This causes GCC to use the default section alignment of 32
bytes. This in turn creates a gap in the linker list due to the padding
required to achieve the correct alignment, corrupting all further entries.
Use DM_DRIVER_REF instead, which doesn't redeclare anything.

Fixes: 0998a20cfc6 ("misc: fs_loader: Add function to get the chosen loader")
Signed-off-by: Sean Anderson <seanga2@gmail.com>

mkimage: update man page and -h output

The man page correctly said that -B was ignored without -E, while the
`mkimage -h` output suggested otherwise. Now that -B can actually be
used by itself, update the man page.

While at it, also amend the `mkimage -h` line to mention the
connection with -E.

The FDT header is a fixed 40 bytes, so its size cannot (and is not)
modified, while its alignment is a property of the address in RAM one
loads the FIT to, so not something mkimage can affect in any way. (In
the file itself, the header is of course at offset 0, which has all
possible alignments already.)

Reported-by: Sean Anderson <seanga2@gmail.com>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>

doc: use .dtso as extension for device tree overlay sources

Moving towards using .dtso for overlay sources, update the
documentation examples to follow that pattern.

Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>

sandbox: rename overlay sources to .dtso

Distinguish more clearly between source files meant for producing .dtb
from those meant for producing .dtbo. No functional change, as we
currently have rules for producing a foo.dtbo from either foo.dts or
foo.dtso.

Note that in the linux tree, all device tree overlay sources have been
renamed to .dtso, and the .dts->.dtbo rule is gone since v6.5 (commit
81d362732bac). So this is also a step towards staying closer to linux
with respect to both Kbuild and device tree sources.

Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>

arm64: zynqmp: rename overlay sources to .dtso

Distinguish more clearly between source files meant for producing .dtb
from those meant for producing .dtbo. No functional change, as we
currently have rules for producing a foo.dtbo from either foo.dts or
foo.dtso.

Note that in the linux tree, all device tree overlay sources have been
renamed to .dtso, and the .dts->.dtbo rule is gone since v6.5 (commit
81d362732bac). So this is also a step towards staying closer to linux
with respect to both Kbuild and device tree sources.

Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>

iot2050: rename overlay sources to .dtso

Distinguish more clearly between source files meant for producing .dtb
from those meant for producing .dtbo. No functional change, as we
currently have rules for producing a foo.dtbo from either foo.dts or
foo.dtso.

Note that in the linux tree, all device tree overlay sources have been
renamed to .dtso, and the .dts->.dtbo rule is gone since v6.5 (commit
81d362732bac). So this is also a step towards staying closer to linux
with respect to both Kbuild and device tree sources.

Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Jan Kiszka <jan.kiszka@siemens.com>

arm: dts: imx8mm-cl-iot-gate: rename overlay sources to .dtso

Distinguish more clearly between source files meant for producing .dtb
from those meant for producing .dtbo. No functional change, as we
currently have rules for producing a foo.dtbo from either foo.dts or
foo.dtso.

Note that in the linux tree, all device tree overlay sources have been
renamed to .dtso, and the .dts->.dtbo rule is gone since v6.5 (commit
81d362732bac). So this is also a step towards staying closer to linux
with respect to both Kbuild and device tree sources.

Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>

arm: apple: Add initial Apple M2 Ultra support

Apple's M2 Ultra SoC are somewhat similar to the M1 Ultra but needs
a tweaked memory map as the M2 Pro/Max SoCs.  USB, NVMe, UART, WDT
and PCIe are working with the existing drivers.

Signed-off-by: Janne Grunau <j@jannau.net>
Reviewed-by: Mark Kettenis <kettenis@openbsd.org>

event: Rename rest of EVENT_SPY to EVENT_SPY_FULL or EVENT_SPY*

Fix up remaining occurances of EVENT_SPY with no suffix.

Fixes: 6c4cad7438 ("event: Rename EVENT_SPY to EVENT_SPY_FULL")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

env: Improve ENV_OFFSET help message

When reading Kconfig help messages to understand ENV_OFFSET and
ENV_OFFSET_REDUND, developers may not realise that they need to also
look at the chosen ENV_IS_IN_* options to see how the offsets will be
interpreted.

Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

driver: rng: Add DM_RNG interface for ARMv8.5 RNDR registers

The ARMv8.5 architecture extension defines architectural RNDR/RNDRRS
system registers, that provide 64 bits worth of randomness on every
read. Since it's an extension, and implementing it is optional, there is
a field in the ID_AA64ISAR0_EL1 ID register to query the availability
of those registers.

Add a UCLASS_RNG driver that returns entropy via repeated reads from
those system registers, if the extension is implemented.
The driver always binds, but checks the availability in the probe()
routine.

This helps systems which suffer from low boot entropy, since U-Boot can
provide entropy via the generic UEFI entropy gathering protocol to the OS,
at an early stage.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

tools: ensure zeroed padding in external FIT images

Padding the header of an external FIT image is achieved by truncating
the existing temporary FIT file to match the required alignment before
appending image data. Reusing an existing file this way means that the
padding will likely contain a portion of the original data not
overwritten by the new header.

Zero out any data past the end of the new header, and stop at either
the end of the desired padding, or the end of the old FIT file,
whichever comes first.

Fixes: 7946a814a319 ("Revert "mkimage: fit: Do not tail-pad fitImage with external data"")
Signed-off-by: Roman Azarenko <roman.azarenko@iopsys.eu>
Reviewed-by: Simon Glass <sjg@chromium.org>

bootstd: Drop some TODOs

The existing TODOs are done, so remove them. Add another that came up
today.

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

arm: dts: k3-am625-verdin: fix boot

A53 U-Boot proper got broken because nodes marked as 'bootph-pre-ram'
are no longer available in U-Boot proper before relocation.

Fix this by marking all nodes in u-boot.dtsi as 'bootph-all'.

Fixes: 9e644284ab812 ("dm: core: Report bootph-pre-ram/sram node as pre-reloc after relocation")
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>

malloc: Enable assertions if UNIT_TEST is enabled

dlmalloc has some sanity checks it performs on free() which can help detect
memory corruption. However, they are only enabled if DEBUG is defined before
including common.h. Define DEBUG earlier if UNIT_TEST is enabled so that
assertions are enabled in sandbox.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

arm: dts: k3-j721e-sk/common-proc-board: Fix boot

Since commit 9e644284ab81 ("dm: core: Report bootph-pre-ram/sram node
as pre-reloc after relocation") A53 u-boot proper is broken. This is
because nodes marked as 'bootph-pre-ram' are not available at u-boot
proper before relocation.

To fix this we mark all nodes in u-boot.dtsi as 'bootph-all'.

Fixes: 69b19ca67bcb ("arm: dts: k3-j721e: Sync with v6.6-rc1")
Cc: Neha Francis <n-francis@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Tested-by: Tom Rini <trini@konsulko.com> # J721E-EVM GP
Tested-by: Neha Malcom Francis <n-francis@ti.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>

arm: mach-k3: Remove secure device makefile

This is now done using binman but this file was leftover and is now
unused, remove it.

Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>

board: siemens: iot2050: Fix logical bug in PG1/PG2 detection

This caused the wrong fdtfile to be set and was failing to apply M.2
settings.

Fixes: badaa1f6a7a9 ("boards: siemens: iot2050: Unify PG1 and PG2/M.2 configurations again")
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

arm: dts: k3-am65-iot2050: Fix boot

Since commit 9e644284ab812 ("dm: core: Report bootph-pre-ram/sram node
as pre-reloc after relocation") A53 u-boot proper is broken. This is
because nodes marked as 'bootph-pre-ram' are not available at u-boot
proper before relocation.

To fix this we mark all nodes in u-boot.dtsi as 'bootph-all'.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
Reviewed-by: Nishanth Menon <nm@ti.com>

spi: mtk_spim: prevent global pll clock override

With commit 793e62301180 ("spi: mtk_spim: get spi clk rate only once") a
new system to calculate the SPI clocks has been added.

Unfortunately, the do_div macro overrides the global priv->pll_clk_rate
field. This will cause to have a reduced clock rate on each subsequent
SPI call.

Signed-off-by: Valerio 'ftp21' Mancini <ftp21@ftp21.eu>
Signed-off-by: Nicolò Veronese <nicveronese@gmail.com>

Makefile: make u-boot-initial-env target depend explicitly on scripts_basic

We're seeing sporadic errors like

  ENVC    include/generated/env.txt
  HOSTCC  scripts/basic/fixdep
  ENVP    include/generated/env.in
  ENVT    include/generated/environment.h
  HOSTCC  tools/printinitialenv
/bin/sh: 1: scripts/basic/fixdep: not found
make[1]: *** [scripts/Makefile.host:95: tools/printinitialenv] Error 127
make[1]: *** Deleting file 'tools/printinitialenv'
make: *** [Makefile:2446: u-boot-initial-env] Error 2
make: *** Waiting for unfinished jobs....

where sometimes the "fixdep: not found" is instead "fixdep: Permission
denied" and the Error 127 becomes 126.

This smells like a race condition, and indeed it is: Currently,
u-boot-initial-env is a prerequisite of the envtools target, which
also lists scripts_basic as a prerequisite:

envtools: u-boot-initial-env scripts_basic $(version_h) $(timestamp_h) tools/version.h
$(Q)$(MAKE) $(build)=tools/env

However, the u-boot-initial-env rule involves building the
printinitialenv helper, which in turn is built using an if_changed_dep
rule. That means we must ensure scripts/basic/fixdep is built and
ready before trying to build printinitialenv, i.e. the
u-boot-initial-env rule itself must depend on the phony scripts_basic
target.

Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>

board: xen: introduce virtio-blk support

Added new xenguest_arm64_virtio_defconfig which
enables support for virtio-blk using various types
of transport like virtio-pci, vrtio-mmio. Currently
supported: up to 2 PCI host bridges and 10 MMIO devices.
Note: DT parsing code was partly taken from pci-uclass.c
Limitation: All memory regions should be
below 4GB address space.

Signed-off-by: Andrii Chepurnyi <andrii_chepurnyi@epam.com>

board: synquacer: set actual gd->ram_top and gd->ram_size

Current gd->ram_size and gd->ram_top reflect only the
first DRAM bank even if the SynQuacer Developerbox could
have up to three DRAM banks.
With the commit 06d514d77c37 ("lmb: consider EFI memory map"),
the first DRAM bank indicates <4GB address, so whole >4GB memory
is marked as EFI_BOOT_SERVICES_DATA and it results that
U-Boot can not access >4GB memory.

Since 64-bits DRAM address is fully available on the SynQuacer
Developerbox, let's set the installed DIMM information to
gd->ram_top and gd->ram_size.

Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Acked-by: Jassi Brar <jaswinder.singh@linaro.org>

input: avoid NULL dereference

Before using the result of env_get("stdin") we must check if it is NULL.

Avoid #if. This resolves the -Wunused-but-set-variable issue and we don't
need a dummy assignment in the else branch. Anyway this warning is
disabled in the Makefile.

For sake of readability use an early return after the configuration check.

Checking CONFIG_SPL_BUILD is incorrect as env_get() is only defined if
CONFIG_$(SPL_TPL)ENV_SUPPORT=y.

Fixes: 985ca3945fa3 ("spl: input: Allow input in SPL and TPL")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

mkimage: allow internalization of data-position

Make it possible for data that was externalized using a static external
position (-p) to be internalized. Enables the ability to convert
existing FIT images built with -p to be converted to a FIT image where the
data is internal, to be converted to a FIT image where the data is
external relative to the end of the FIT (-E) or change the initial
static external position to a different static external position (-p).

Removing the original external-data-related properties ensures that
they're not present after conversion. Without this, they would still be
present in the resulting FIT even if the FIT has been, for example,
internalized.

Signed-off-by: Lars Feyaerts <lars@bitbiz.be>
Reviewed-by: Simon Glass <sjg@chromium.org>

checkpatch: skip fdtdec_* check for tools

Have checkpatch.pl skip warnings for use of fdtdec_* functions in
ooling; livetree isn't used there.

Signed-off-by: Lars Feyaerts <lars@bitbiz.be>
Reviewed-by: Simon Glass <sjg@chromium.org>

Merge tag 'fsl-qoirq-2023-10-10' of https://source.denx.de/u-boot/custodians/u-boot-fsl-qoriq

Drop legacy PPA secure FW support
support for MC reserved memory
reset the FLSHxCR1 registers for nxp_fspi

Merge branch '2023-10-10-blk-sandbox-support-binding-a-device-with-a-given-logical-block-size'

To quote the author:
At present on Sandbox when binding to a host backing file, the host
block device is created with a hard-coded 512 bytes block size.

Such assumption works for most cases, but for situation that with a raw
image file dump from a pre-formatted GPT partitioned disk image from a
4KiB block size device, when binding this file to a host device and mapping
this device to a blkmap, "blkmap" command like "blkmap part" won't work
correctly, due to block size mismatch during parsing the partition table.

This series updates Sandbox block driver, as well as the blkmap driver,
to get rid of the hard-coded 512 bytes block size assumption.

This series is available at u-boot-x86/blk for testing.

Test log (512 block size):

  => host bind 0 test.img
  => host info
  dev       blocks  blksz label           path
    0       262144    512 0               test.img
  => blkmap create 0
  Created "0"
  => blkmap map 0 0 40000 linear host 0 0
  Block 0x0+0x40000 mapped to block 0x0 of "host 0"
  => blkmap info
  Device 0: Vendor: U-Boot Rev: 1.0 Prod: blkmap
              Type: Hard Disk
              Capacity: 128.0 MB = 0.1 GB (262144 x 512)
  => blkmap part

  Partition Map for BLKMAP device 0  --   Partition Type: EFI

  Part    Start LBA       End LBA         Name
          Attributes
          Type GUID
          Partition GUID
    1     0x00000022      0x000000bd      "u-boot-spl"
          attrs:  0x0000000000000000
          type:   5b193300-fc78-40cd-8002-e86c45580b47
                  (5b193300-fc78-40cd-8002-e86c45580b47)
          guid:   0bb6bb6e-4aac-4c27-be03-016b01e7b941
    2     0x00000822      0x00000c84      "u-boot"
          attrs:  0x0000000000000000
          type:   2e54b353-1271-4842-806f-e436d6af6985
                  (2e54b353-1271-4842-806f-e436d6af6985)
          guid:   91d50814-8e31-4cc0-97dc-779e1dc59056
    3     0x00000c85      0x0000cc84      "rootfs"
          attrs:  0x0000000000000004
          type:   0fc63daf-8483-4772-8e79-3d69d8477de4
                  (linux)
          guid:   42799722-6e55-46e6-afa9-529e7af3f03b

Test log (4096 block size):

  => host bind 0 test.img 4096
  => host info
  dev       blocks  blksz label           path
    0        32768   4096 0               test.img
  => blkmap create 0
  Created "0"
  => blkmap map 0 0 8000 linear host 0 0
  Block 0x0+0x8000 mapped to block 0x0 of "host 0"
  => blkmap info
  Device 0: Vendor: U-Boot Rev: 1.0 Prod: blkmap
              Type: Hard Disk
              Capacity: 128.0 MB = 0.1 GB (32768 x 4096)
  => blkmap part

  Partition Map for BLKMAP device 0  --   Partition Type: EFI

  Part    Start LBA       End LBA         Name
          Attributes
          Type GUID
          Partition GUID
    1     0x00000100      0x00001fff      "primary"
          attrs:  0x0000000000000000
          type:   0fc63daf-8483-4772-8e79-3d69d8477de4
                  (linux)
          guid:   eba904d7-72c1-4dbd-bb4e-36be49cba5e3
    2     0x00002000      0x00007ffa      "primary"
          attrs:  0x0000000000000000
          type:   0fc63daf-8483-4772-8e79-3d69d8477de4
                  (linux)
          guid:   c48c360e-db47-46da-ab87-26416fad3cd3

disk: part: Handle blkmap device in print_part_header()

Print out the blkmap device type when showing partition header for
a blkmap device.

Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

disk: part: Print out the unknown device uclass id

It's helpful to output the device uclass id for unknown devices
during the debugging process.

Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

dm: blk: Drop blk_{read,write}_devnum()

blk_{read,write}_devnum() are no longer used by anywhere in the
source tree. Drop them.

Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

cmd: blk_common: Stop using hard-coded block size for Sandbox operations

commit 3d2fc7971454 ("cmd: blk: Allow generic read/write operations to work in sandbox")
used the hard-coded block size (512) for accessing the sandbox host
device. Now that we have added support for non-512 block size for both
Sandbox host device and blkmap driver, let's stop using the hard-coded
block size.

Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

dm: blk: Rename get_desc() and make it externally visible

get_desc() can be useful outside blk-uclass.c. Let's change it to
an API and make it externally visible.

Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

cmd: blk_common: Use macros for the return values

Avoid using magic number 0/1 for the command result.

Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

blk: blkmap: Support mapping to device of any block size

At present if a device to map has a block size other than 512,
the blkmap map process just fails. There is no reason why we
can't just use the block size of the mapped device.

Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

cmd: blkmap: Make map_handlers[] and its .fn static

These are only used in cmd/blkmap.c.

Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

blk: blkmap: Make bind/unbind routines static

These 2 are only used in drivers/block/blkmap.c.

Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

cmd: host: Print out the block size of the host device

It's useful if we can print out the block size of the host device
in the "host info" command.

Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

blk: host_dev: Sanity check on the size of host backing file

Since we are emulating a block device, its size should be multiple
of the configured block size.

Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

blk: host_dev: Make host_sb_detach_file() and host_sb_ops static

They are only used in drivers/block/host_dev.c.

Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

blk: sandbox: Support binding a device with a given logical block size

Allow optionally set the logical block size of the host device to
bind in the "host bind" command. If not given, defaults to 512.

Signed-off-by: Bin Meng <bmeng@tinylab.org>

cmd: host: Mandate the filename parameter in the 'bind' command

At present the host bind command does not require filename to be
provided. When it is not given NULL is passed to the host device
driver, which ends up failure afterwards.

Change to mandate the filename so that it is useful.

Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

blk: Use a macro for the typical block size

Avoid using the magic number 512 directly.

Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Simon Glass <sjg@chromium.org>