Simon Glass <sjg@chromium.org> says:
When the SPL build-phase was first created it was designed to solve a
particular problem (the need to init SDRAM so that U-Boot proper could
be loaded). It has since expanded to become an important part of U-Boot,
with three phases now present: TPL, VPL and SPL
Due to this history, the term 'SPL' is used to mean both a particular
phase (the one before U-Boot proper) and all the non-proper phases.
This has become confusing.
For a similar reason CONFIG_SPL_BUILD is set to 'y' for all 'SPL'
phases, not just SPL. So code which can only be compiled for actual SPL,
for example, must use something like this:
#if defined(CONFIG_SPL_BUILD) && !defined(CONFIG_TPL_BUILD)
In Makefiles we have similar issues. SPL_ has been used as a variable
which expands to either SPL_ or nothing, to chose between options like
CONFIG_BLK and CONFIG_SPL_BLK. When TPL appeared, a new SPL_TPL variable
was created which expanded to 'SPL_', 'TPL_' or nothing. Later it was
updated to support 'VPL_' as well.
This series starts a change in terminology and usage to resolve the
above issues:
- The word 'xPL' is used instead of 'SPL' to mean a non-proper build
- A new CONFIG_XPL_BUILD define indicates that the current build is an
'xPL' build
- The existing CONFIG_SPL_BUILD is changed to mean SPL; it is not now
defined for TPL and VPL phases
- The existing SPL_ Makefile variable is renamed to SPL_
- The existing SPL_TPL Makefile variable is renamed to PHASE_
It should be noted that xpl_phase() can generally be used instead of
the above CONFIGs without a code-space or run-time penalty.
This series does not attempt to convert all of U-Boot to use this new
terminology but it makes a start. In particular, renaming spl.h and
common/spl seems like a bridge too far at this point.
The series is fully bisectable. It has also been checked to ensure there
are no code-size changes on any commit.
Use PHASE_ as the symbol to select a particular XPL build. This means
that SPL_TPL_ is no-longer set.
Update the comment in bootstage to refer to this symbol, instead of
SPL_
Signed-off-by: Simon Glass <sjg@chromium.org>
Christian Marangi <ansuelsmth@gmail.com> says:
This series is a reworked version of the previous seried:
misc: introduce STATUS LED activity function
This series port and expand the legacy concept of LED boot from
the legacy Status LED API to new LED API.
One thing that many device need is a way to communicate to the
user that the device is actually doing something.
This is especially useful for recovery steps where an
user (for example) insert an USB drive, keep a button pressed
and the device autorecover.
There is currently no way to signal the user externally that
the bootloader is processing/recoverying aside from setting
a LED on.
A solid LED on is not enough and won't actually signal any
kind of progress.
Solution is the good old blinking LED but uboot doesn't
suggest (and support) interrupts and almost all the LED
are usually GPIO LED that doesn't support HW blink.
Additional Kconfg are also introduced to set the LED boot and
activity. Those are referenced by label.
A documentation for old and these new LED API is created.
Implement ofnode_options helpers to read options in /options/u-boot to
adapt to the new way to declare options as described in [1].
[1] dtschema/schemas/options/u-boot.yaml
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Enabling CONFIG_DM_SEQ_ALIAS enables code which relies on
`trailing_strtol()` - which is only linked in SPL when CONFIG_SPL_STRTO
is enabled.
CONFIG_SPL_STRTO is not enabled by default - to ensure this function is
available in SPL, CONFIG_SPL_DM_SEQ_ALIAS should select
CONFIG_SPL_STRTO.
Signed-off-by: Oliver Gaskell <Oliver.Gaskell@analog.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Jonas Karlman <jonas@kwiboo.se> says:
Use of fdt_parent_offset() is very expensive as detailed by the function
documentation:
NOTE: This function is expensive, as it must scan the device tree
structure from the start to nodeoffset, *twice*.
This series remove multiple calls to fdt_parent_offset() or
ofnode_get_parent() when instead a single call can be made and the
returned value can be reused.
This series help reduce boot time by around:
- ~137ms on a Radxa ROCK Pi 4 (RK3399)
- ~33ms on a Radxa ZERO 3W (RK3566)
Until a live tree is used in U-Boot proper after relocation, use of
ofnode_get_parent() will trigger a call to the very expensive
fdt_parent_offset(), as detailed by the function documentation:
NOTE: This function is expensive, as it must scan the device tree
structure from the start to nodeoffset, *twice*.
Re-use the returned value from a single call instead of having to make
multiple calls for same node.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Simon Glass <sjg@chromium.org>
Until a live tree is used in U-Boot proper after relocation, use of
ofnode_get_parent() will trigger a call to the very expensive
fdt_parent_offset() as detailed by the function documentation:
NOTE: This function is expensive, as it must scan the device tree
structure from the start to nodeoffset, *twice*.
Re-use the returned value from a single call instead of having to make
multiple calls for same node.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Simon Glass <sjg@chromium.org>
Use of fdt_parent_offset() is very expensive as detailed by the function
documentation:
NOTE: This function is expensive, as it must scan the device tree
structure from the start to nodeoffset, *twice*.
Re-use the returned value from a single call instead of having to make
multiple calls for same nodeoffset.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Simon Glass <sjg@chromium.org>
Currently uclass index is shown in DM tree dump which ignores alias
sequence numbering. The result could be confusing since these 2 numbers
could be different. Show device sequence number instead as it's more
meaningful.
Also update documentation to use sequence number.
Signed-off-by: Zixun LI <admin@hifiphile.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The linux kernel has the list_count_nodes() API functions which is
used for counting nodes of a list. This has now been imported in
U-Boot as part of an earlier commit. Use this function and drop the
list_count_items().
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Prior to that, seeing the debug() messages required to enable DM_DEBUG
which defines DEBUG (and then _DEBUG) which in turn makes failing
assert() calls reset U-Boot which isn't necessarily what is desired.
Instead, let's migrate to dm_warn which is using log_debug when unset or
log_warn when set.
While at it, reword the DM_DEBUG symbol in Kconfig to explain what it
now actually does.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
outp always point to an unsigned type in ofnode_read_u* functions but
the format specifier is currently always using signed type.
This is an issue since the signed type can only contain half of the
unsigned type values above 0.
However, this now breaks another usecase. Indeed,
ofnode_read_s32_default is actually passing an s32 but it'll be printed
as a u32 instead. But since the function is called u32, it makes more
sense to have it print an unsigned value.
This was discovered because arm,smc-id = <0x82000010>; on RK3588S is
above the max signed value and therefore would return a negative signed
decimal value instead of its proper unsigned one.
Fixes: fa12dfa08a ("dm: core: support reading a single indexed u64 value")
Fixes: 4bb7075c83 ("dm: core: support reading a single indexed u32 value")
Fixes: 7e5196c409 ("dm: core: Add ofnode function to read a 64-bit int")
Fixes: 9e51204527 ("dm: core: Add operations on device tree references")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
A driver can have multiple compatible. When the id->compatible matches
for that driver, the first compatible supported by the driver is
currently returned, which gives the following confusing message:
- found match at 'rk3588_syscon': 'rockchip,rk3588-sys-grf' matches 'rockchip,rk3588-pmugrf'
Considering that the compatible passed in argument is necessarily the
one that exactly matched to enter this code path, there's no need to do
some elaborate logic, just print the driver name and the compatible
passed in argument.
Fixes: d3e773613b ("dm: core: Use U-Boot logging instead of pr_debug()")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
As part of bringing the master branch back in to next, we need to allow
for all of these changes to exist here.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.
This reverts commit c8ffd1356d, reversing
changes made to 2ee6f3a5f7.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
During address translation #address/size-cells props are expected to
apply to child nodes. However, devfdt_get_addr_index() incorrectly use
the parent offset of the udevice parent instead of getting the offset of
the node parent. This will work in most cases when there is only one
udevice tied to a node.
On e.g. an Orange Pi R1 Plus TLS board the dwc3-generic (parent) and
dwc3-generic-host (child) udevice is tied to the same node.
In that case both the offset and parent values end up being the same.
As a result, the #address/size-cells props intended for child nodes
incorrectly gets applied to the node itself resulting in wrong addr
being returned, 0x0 instead of 0xff600000.
The following can be seen on console:
dwc3-generic-host usb@ff600000: this is not a DesignWare USB3 DRD Core
dwc3-generic-host usb@ff600000: failed to initialize core
Fix this by using the offset of the parent node and not the offset to
the node the parent udevice is tied to.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Check the header before starting to use it, since this could provide
very confusing later, when ofnode calls start to fail.
Signed-off-by: Simon Glass <sjg@chromium.org>
CONFIG_DM_WARN has a text indicating that these messages should only
provided when debugging. This implies that the setting must be default no.
We should still create debug messages.
Reported-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The baudrate configured in .config is taken by default by serial. If
change of baudrate is required then the .config needs to changed and
u-boot recompilation is required or the u-boot environment needs to be
updated.
To avoid this, support is added to fetch the baudrate directly from the
device tree file and update.
The serial, prints the log with the configured baudrate in the dtb.
The commit c4df0f6f31 ("arm: mvebu: Espressobin: Set default value for
$fdtfile env variable") is taken as reference for changing the default
environment variable.
The default environment stores the default baudrate value, When default
baudrate and dtb baudrate are not same glitches are seen on the serial.
So, the environment also needs to be updated with the dtb baudrate to
avoid the glitches on the serial.
Also add test to cover this new function.
Signed-off-by: Algapally Santosh Sagar <santoshsagar.algapally@amd.com>
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Link: https://lore.kernel.org/r/20230921112043.3144726-3-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
lib/acpi/acpigen.o is only compiled into SPL when SPL_ACPIGEN is enabled.
Update several files which reference these functions accordingly.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Sandbox unit tests in U-Boot proper load a test device tree to have some
devices to work with. In order to do the same in SPL, we must enable
SPL_OF_REAL. However, we already have SPL_OF_PLATDATA enabled. When
generating platdata from a devicetree, it is expected that we will not need
devicetree access functions (even though SPL_OF_CONTROL is enabled). This
expectation does not hold for sandbox, so allow user control of
SPL_OF_REAL.
There are several places in the tree where conditions involving OF_PLATDATA
or OF_REAL no longer function correctly when both of these options can be
selected at the same time. Adjust these conditions accordingly.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Same as dev_read_addr_name[_size](), but returns a pointer, cast
through map_sysmem().
Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Checking for the error cast to fdt_addr_t is rather awkward - IS_ERR()
can be used, but it's not really made to be used on fdt_addr_t, which
may not even be the same size as a native pointer.
Most places in U-Boot only check for FDT_ADDR_T_NONE; let's adjust the
error return to match the expectation.
Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The PCI helpers read only the base address for a PCI region. In some cases
the size is needed as well, e.g. to pass along to a driver which needs to
know the size of its register area.
Update the functions to allow the size to be returned. For serial, record
the information and provided it with the serial_info() call.
A limitation still exists in that the size is not available when OF_LIVE
is enabled, so take account of that in the tests.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add support for writing a single 64-bit value into a property.
Repurpose the existing tests to handle this case too.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add functions to write a boolean property. This involves deleting it if
the value is false.
Add a new ofnode_has_property() as well. Add a comment about the behaviour
of of_read_property() when the property value is empty.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a way to flatten a devicetree into binary form. For livetree this
involves generating the devicetree using fdt_property() and other calls.
For flattree it simply involves providing the buffer containing the tree.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a function to copy a node to another place under a new name. This is
useful at least for testing, since copying a test node with existing
properties is easier than writing the code to generate it all afresh.
Signed-off-by: Simon Glass <sjg@chromium.org>
We like to put the SPL first so it is clear that it relates to SPL. Rename
various malloc-related options which have crept in, to stick to this
convention.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Reviewed-by: Martyn Welch <martyn.welch@collabora.com>
Reviewed-by: Svyatoslav Ryhel <clamor95@gmail.com>
This old patch was marked as deferred. Bring it back to life, to continue
towards the removal of common.h
Move this out of the common header and include it only where needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
The output from "dm tree" or "dm uclass" is a bit annoying
if the number of devices available on the system is huge.
(This is especially true on sandbox when I debug some DM code.)
With this patch, we can specify the uclass name or the device
name that we are interested in in order to limit the output.
For instance,
=> dm uclass usb
uclass 121: usb
0 usb@1 @ 0bcff8b0, seq 1
uclass 124: usb
=> dm tree usb:usb@1
Class Index Probed Driver Name
-----------------------------------------------------------
usb 0 [ ] usb_sandbox usb@1
usb_hub 0 [ ] usb_hub `-- hub
usb_emul 0 [ ] usb_sandbox_hub `-- hub-emul
usb_emul 1 [ ] usb_sandbox_flash |-- flash-stick@0
usb_emul 2 [ ] usb_sandbox_flash |-- flash-stick@1
usb_emul 3 [ ] usb_sandbox_flash |-- flash-stick@2
usb_emul 4 [ ] usb_sandbox_keyb `-- keyb@3
If you want forward-matching against a uclass or udevice name,
you can specify "-e" option.
=> dm uclass -e usb
uclass 15: usb_emul
0 hub-emul @ 0bcffb00, seq 0
1 flash-stick@0 @ 0bcffc30, seq 1
2 flash-stick@1 @ 0bcffdc0, seq 2
3 flash-stick@2 @ 0bcfff50, seq 3
4 keyb@3 @ 0bd000e0, seq 4
uclass 64: usb_mass_storage
uclass 121: usb
0 usb@1 @ 0bcff8b0, seq 1
uclass 122: usb_dev_generic
uclass 123: usb_hub
0 hub @ 0bcff9b0, seq 0
uclass 124: usb
=> dm tree -e usb
Class Index Probed Driver Name
-----------------------------------------------------------
usb 0 [ ] usb_sandbox usb@1
usb_hub 0 [ ] usb_hub `-- hub
usb_emul 0 [ ] usb_sandbox_hub `-- hub-emul
usb_emul 1 [ ] usb_sandbox_flash |-- flash-stick@0
usb_emul 2 [ ] usb_sandbox_flash |-- flash-stick@1
usb_emul 3 [ ] usb_sandbox_flash |-- flash-stick@2
usb_emul 4 [ ] usb_sandbox_keyb `-- keyb@3
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
