Add a CONFIG option to deal with this automatically, printing a warning
when U-Boot starts up. This can be useful if the device tree comes from
another project.
We will maintain this through the 2023.07 release, providing 6 months
for people to notice.
Signed-off-by: Simon Glass <sjg@chromium.org>
Version 4:
Acked-by: Michal Simek <michal.simek@amd.com>
U-Boot has some particular challenges with device tree and devices:
- U-Boot has multiple build phases, such as a Secondary Program Loader
(SPL) phase which typically runs in a pre-SDRAM environment where code
and data space are limited. In particular, there may not be enough
space for the full device tree blob. U-Boot uses various automated
techniques to reduce the size from perhaps 40KB to 3KB. It is not
always possible to handle these tags entirely at build time, since
U-Boot proper must have the full device tree, even though we do not
want it to process all nodes until after relocation.
- Some U-Boot phases needs to run before the clocks are properly set up,
where the CPU may be running very slowly. Therefore it is important to
bind only those devices which are actually needed in that phase
- U-Boot uses lazy initialisation for its devices, with 'bind' and
'probe' being separate steps. Even if a device is bound, it is not
actually probed until it is used. This is necessary to keep the boot
time reasonable, e.g. to under a second
The phases of U-Boot in order are: TPL, VPL, SPL, U-Boot (first
pre-relocation, then post-relocation). ALl but the last two are optional.
For the above reasons, U-Boot only includes the full device tree in the
final 'U-Boot proper' build. Even then, before relocation U-Boot only
processes nodes which are marked as being needed.
For this to work, U-Boot's driver model[1] provides a way to mark device
tree nodes as applicable for a particular phase. This works by adding a
tag to the node, e.g.:
cru: clock-controller@ff760000 {
bootph-all;
compatible = "rockchip,rk3399-cru";
reg = <0x0 0xff760000 0x0 0x1000>;
rockchip,grf = <&grf>;
#clock-cells = <1>;
#reset-cells = <1>;
...
};
Here the "bootph-all" tag indicates that the node must be present in all
phases, since the clock driver is required.
There has been discussion over the years about whether this could be done
in a property instead, e.g.
options {
bootph-all = <&cru> <&gpio_a> ...;
...
};
Some problems with this:
- we need to be able to merge several such tags from different .dtsi files
since many boards have their own specific requirements
- it is hard to find and cross-reference the affected nodes
- it is more error-prone
- it requires significant tool rework in U-Boot, including fdtgrep and
the build system
- is harder (slower, more code) to process since it involves scanning
another node/property to find out what to do with a particular node
- we don't want to add phandle arguments to the above since we are
referring, e.g., to the clock device as a whole, not a paricular clock
- the of-platdata feature[2], which converts device tree to C for even
more constrained environments, would need to become aware of the
/options node
There is also the question about whether this needs to be U-Boot-specific,
or whether the tags could be generic. From what I can tell, U-Boot is the
only bootloader which seriously attempts to use a runtime device tree in
all cases. For this version, an attempt is made to name the phases in a
generic manner.
It should also be noted that the approach provided here has stood the test
of time, used in U-Boot for 8 years so far.
So add the schema for this. This will allow a major class of schema
exceptions to be dropped from the U-Boot source tree.
This has been applied upstream[3]
[1] https://u-boot.readthedocs.io/en/latest/develop/driver-model/index.html
[2] https://u-boot.readthedocs.io/en/latest/develop/driver-model/of-plat.html
[3] https://github.com/devicetree-org/dt-schema/commit/63bd847
Signed-off-by: Simon Glass <sjg@chromium.org>
i2c updates for v2023.04
- add new i2c driver ast2600 from Ryan Chen
- i2c-cdns: make read fifo-depth configurable through device tree
from Pei Yue Ho
- mxc i2c driver: print base address in hex, not in decimal
from Fabio
- mvebu: Support for 2 new Armada 385 boards (Tony)
- mvebu: Minor misc board enhancements (Tony)
- kirkwood: Serial driver fixes (Kconfig & dtsi) (Tony)
- cmd: return code when tlv_eeprom incorrectly called (Heinrich)
When DM_SERIAL is enabled, the device-tree tag u-boot,dm-pre-reloc is
required for this board to boot over UART with kwboot. Enable this in
kirkwood-pogoplug-series-4-u-boot.dtsi.
Added by Stefan while applying:
Please note that it's not fully understood, why this property really
is needed. Here a link to the discussion about this:
https://lore.kernel.org/r/20230201080210.ypz4nrj4y2igwxz3@pali/
Signed-off-by: Tony Dinh <mibodhi@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Synology DS116 is a NAS based on Marvell Armada 385 SoC.
Board Specification:
- Marvel MV88F6820 Dual Core at 1.8GHz
- 1 GiB DDR3 RAM
- 8MB Macronix mx25l6405d SPI flash
- I2C
- 2x USB 3.0
- 1x GBE LAN port (PHY: Marvell 88E1510)
- 1x SATA (6 Gbps)
- 3x LED
- PIC16F1829 (connected to uart1)
- GPIO fan
- serial console
Note that this patch depends on the add-support for Thecus N2350 patch:
https://patchwork.ozlabs.org/project/uboot/patch/20230201231306.7010-1-mibodhi@gmail.com/
Signed-off-by: Tony Dinh <mibodhi@gmail.com>
Currently, only the 1st SATA port is powered up (by GPIO1 12).
Add GPIO1 13 in board initialization to power up the 2nd SATA port.
Note that this patch depends on the initial add-support patch:
https://patchwork.ozlabs.org/project/uboot/patch/20230201231306.7010-1-mibodhi@gmail.com/
Signed-off-by: Tony Dinh <mibodhi@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Sheevaplug board has 512K CONFIG_BOARD_SIZE_LIMIT. Recently, DM_SERIAL has
pushed the image size a few hundred bytes over that limit. So explicitly
deselect some configs that are unrelated to this board
(and gain back a bit over 2K).
Signed-off-by: Tony Dinh <mibodhi@gmail.com>
CONFIG_SYS_NS16550 is required when DM_SERIAL is enabled for
Kirkwood boards.
Signed-off-by: Tony Dinh <mibodhi@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Stefan Roese <sr@denx.de>
A command called with incorrect parameters should set $? to 1 (false).
Instead of calling cmd_usage(cmdtp) and then returning 0 just return
CMD_RET_FAILURE.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Acked-by: Baruch Siach <baruch@tkos.co.il>
Reviewed-by: Stefan Roese <sr@denx.de>
Enable driver to fetch the optional parameter (fifo-depth) from device
tree. If the parameter is not found in the device tree, it will use
the default value declared in the driver.
Signed-off-by: Pei Yue Ho <peiyue.ho@starfivetech.com>
Reviewed-by: Wei Liang Lim <weiliang.lim@starfivetech.com>
Reviewed-by: Eng Lee Teh <englee.teh@starfivetech.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Add description for fifo-depth parameter that can be used
in the device tree.
Signed-off-by: Pei Yue Ho <peiyue.ho@starfivetech.com>
Reviewed-by: Wei Liang Lim <weiliang.lim@starfivetech.com>
Reviewed-by: Eng Lee Teh <englee.teh@starfivetech.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
The i2c driver have global register that i2c bus use
ofnode_get_parent to get parent register address.
Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Add i2c new register mode driver to support AST2600 i2c
new register mode. AST2600 i2c controller have legacy and
new register mode. The new register mode have global register
support 4 base clock for scl clock selection, and new clock
divider mode.
Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Printing the I2C controller base address in decimal notation
is not helpful.
Change it to hex notation, which is the standard format found
in the Reference Manual and devicetree.
Signed-off-by: Fabio Estevam <festevam@denx.de>
Acked-by: Dhruva Gole <d-gole@ti.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
At the moment every subcommand of "fdt", except "addr" itself, requires
the DT address to be set first. We explicitly check for that before even
comparing against the subcommands' string.
This early bailout also affects the "move" subcommand, even though that
does not require or rely on a previous call to "fdt addr". In fact it
even sets the FDT address to the target of the move command, so is a
perfect beginning for a sequence of fdt commands.
Move the check for a previously set FDT address to after we handle the
"move" command also, so we don't need a dummy call to "fdt addr" first,
before being able to move the devicetree.
This skips one pointless "fdt addr" call in scripts which aim to alter
the control DT, but need to copy it to a safe location first (for
instance to $fdt_addr_r).
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The "fdt move" subcommand was using the provided DTB addresses directly,
without trying to "map" them into U-Boot's address space. This happened
to work since on the vast majority of "real" platforms there is a simple
1:1 mapping of VA to PAs, so either value works fine.
However this is not true on the sandbox, so the "fdt move" command fails
there miserably:
=> fdt addr $fdtcontroladdr
=> cp.l $fdtcontroladdr $fdt_addr_r 40 # simple memcpy works
=> fdt move $fdtcontroladdr $fdt_addr_r
Segmentation fault
Use the proper "map_sysmem" call to convert PAs to VAs, to make this
more robust in general and to enable operation in the sandbox.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
At present we show 'main section' as the top-level section name. It may
be more helpful to show the actual image name. This is tricky because
Image is a parent class of Entry_section, so there is no distinction
between an image and a section.
Update it to show the image name.
Signed-off-by: Simon Glass <sjg@chromium.org>
Previously, the TX LED would flash but nothing would appear on the
serial port, and the board would appear dead with a build of the
socfpga_cyclone5_defconfig. I have verified that adding the frequency to
the uart will fix the serial console on my board.
Thanks to @ehoffman on the Rocketboards forum:
https://forum.rocketboards.org/t/cyclonev-programming-fpga-from-u-boot/2230/30
Signed-off-by: Jade Lovelace <lists@jade.fyi>
Reviewed-by: Marek Vasut <marex@denx.de>
This contains various fixes and small features. I've included a reset patch as
well since it was in the same series as a clock patch.
-----BEGIN PGP SIGNATURE-----
iQGTBAABCgB9FiEEkGEdW86NSNID6GAoPuiP7LShEG4FAmPpRBJfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDkw
NjExRDVCQ0U4RDQ4RDIwM0U4NjAyODNFRTg4RkVDQjRBMTEwNkUACgkQPuiP7LSh
EG6fgggAo6vMZZw1RPCDiI25s2mGnnKXe1MZDruTipeVFUaBCJZDVKzF94oarKZK
BhQyzZ/0WkWH8BbEn/mOiW/M4MpZjif6cEnB/uLg8kqvIEz/NbOLLCkpAq6bccm5
0l9ycdhvXzwhLR+hsx8WlzatIE79TqR4hXc8kFfYXbJAITbWsqhh6g+0ILbYuajm
Uz1Hvjn1SGptgL7pfTb5NiiTjDrKv4Fr+F11KCqpgIwu81a8Sfv0kQ29W3qCDEj/
r3jov9PSf3g/MZmL+R0qVhcsPQeqf7/KdcDvn0Py++jqi3zfBialpFUQV3MLPqEP
82dPV5ObgjD6a5u6TPkG0roNpmpUVA==
=+n5i
-----END PGP SIGNATURE-----
Merge tag 'clk-2023.04-rc1' of https://source.denx.de/u-boot/custodians/u-boot-clk
Clock changes for 2023.04-rc1
This contains various fixes and small features. I've included a reset patch as
well since it was in the same series as a clock patch.
- A fix for a long standing bug that has been exposed by commit
50128aeb0f ("cyclic: get rid of cyclic_init()") preventing 8xx boards
from booting since u-boot 2023.01
- A GPIO driver for powerpc 8xx chip
- Fixup for powerpc 8xx SPI driver
- A new powerpc 8xx board
- The two devices having that board.
This allows devm_reset_control_get(dev, NULL) to work and get the first
reset control, which is common in code ported from Linux.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Link: https://lore.kernel.org/r/20230122000252.53642-2-samuel@sholland.org
This allows devm_clock_get(dev, NULL) to work and get the first clock,
which is common in code ported from Linux.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Link: https://lore.kernel.org/r/20230122000252.53642-1-samuel@sholland.org
The clock UCLASS need to be probed to allow availability of the
private data (struct clk *), get in show_clks() with dev_get_clk_ptr()
before use them.
Without this patch the clock dump can cause crash because all the
private data are not available before calling the API clk_get_rate().
It is the case for the SCMI clocks, priv->channel is needed for
scmi_clk_get_rate() and it is initialized only in scmi_clk_probe().
This issue causes a crash for "clk dump" command on STM32MP135F-DK board
for SCMI clock not yet probed.
Fixes: 1a725e2290 ("clk: fix clock tree dump to properly dump out every registered clock")
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Sean Anderson <seanga2@gmail.com>
Link: https://lore.kernel.org/r/20221213145708.v2.1.Ia0bc6b272f1e2e3f37873c61d79138c2663c4055@changeid
[backport from linux commit bedcf9d1dcf88ed38731f0ac9620e5a421e1e9d6]
Unlike audio_pll1 and audio_pll2, there is no video_pll2. Further, the
name used in the RM is video_pll. So, let's rename "video_pll1" to
"video_pll" to be consistent with the RM and avoid misunderstandings.
No functional changes intended.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Acked-by: Sean Anderson <seanga2@gmail.com>
Link: https://lore.kernel.org/r/20221219113127.528282-3-dario.binacchi@amarulasolutions.com
[backport from linux commit a429c60baefd95ab43a2ce7f25d5b2d7a2e431df]
The IMX8MN platform does not have any video processing unit (VPU), and
indeed in the reference manual (document IMX8MNRM Rev 2, 07/2022) there
is no occurrence of its pll. From an analysis of the code and the RM
itself, I think vpu pll is used instead of m7 alternate pll, probably
for copy and paste of code taken from modules of similar architectures.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Acked-by: Sean Anderson <seanga2@gmail.com>
Link: https://lore.kernel.org/r/20221219113127.528282-2-dario.binacchi@amarulasolutions.com
In various cases logical memory blocks are coalesced; As a result doing
a strict check whether memory blocks are the same doesn't necessarily
work as a previous addition of a given block might have been merged into
a bigger block.
Fix this by considering a block is already registered if it's a pure
subset of one of the existing blocks.
Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
To quote the author:
Since U-Boot's tracing feature was originally written, quite a few changes
have taken place in this domain. The original text format used by tracing
is still emitted by Linux, but a new trace-cmd tool has invented a binary
format which is now used by new tools, such as kernelshark.
With recent distributions and the move to Python 3, the old pybootchart
tool does not build or run. Unfortunately there is no 1:1 replacement for
the features that were provided by pybootchart, or at least it is not
obvious. Still, it makes sense to keep with the times.
This series updates proftool to use the new binary format, adding support
for function and funcgraph tracing, so that U-Boot's trace records can be
examined by trace-cmd and kernelshark.
This series also adds support for a flamegraph, which provides a visual
way to see which functions are called a lot, as well as which ones consume
the most time.
Some minor updates to the trace implementation within U-Boot are included,
to provide a little more information and to fix a few problems.
No unit tests are provided by proftool, but a functional test ensures that
sandbox can emit traces which can be processed by proftool, then parsed by
trace-cmd and that the timing of the various formats looks consistent.
Revamp the documentation for the new features, including a description of
the new features and documentation for the trace command.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a test which runs sandbox, collects a trace and makes sure it can
be processed by trace-cmd. This should ensure that this feature continues
to work as U-Boot and trace-cmd evolve.
Signed-off-by: Simon Glass <sjg@chromium.org>
Build trace-cmd as part of the docker image, so that trace tests can be
used. Unfortunately the version provided by distributions is a little old
and has bugs. It also does not support specifying the time base for the
trace, which is required to convert microseconds to nanaseconds.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a second variant of the flame graph that shows records in terms of the
number of microseconds used by each call stack. This is a useful way of
seeing where time is going within the execution of U-Boot.
This requires a call stack that records the start time of each function,
as well as a way of subtracting all time consumed by child functions, so
that this time is not counted twice by the flamegraph. The time values in
the output are just for the function itself, not for its children.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is useful to see how many times each function is called, particularly
in the context of its callers. A flamegraph is a way of showing this.
Support output in this format which can be used by the flamegraph.pl
script, to generate an SVG image for browsing.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add support for writing ftrace records in the 'funcgraph' format, which
shows function entry and exit points as well as the time taken by each
function.
Signed-off-by: Simon Glass <sjg@chromium.org>
Use the information in the trace header instead of reading it from the
trace records. Add debugging to check that System.map and the trace header
agree on this value.
Signed-off-by: Simon Glass <sjg@chromium.org>
The old text format is not much used anymore. Instead a new trace-cmd tool
has introduced a binary format for trace records.
Add support for generating this format. This involves removing the old
text format, adding various helpers for the new format and adjusting the
code to use an output file instead of stdout.
Signed-off-by: Simon Glass <sjg@chromium.org>
The current use of 'profile' in some places is confusing. Update the code
to use the word 'trace' consistently. Change the flags to better match
their meaning and add some more comments.
Signed-off-by: Simon Glass <sjg@chromium.org>
If something is wrong with a board's timer function such that it calls
functions not marked with notrace, U-Boot will hang.
Detect this, print a message and disable the trace.
Signed-off-by: Simon Glass <sjg@chromium.org>
When the early trace buffer overflows it leaves a gap in the trace buffer
between where the actual data finished and where it would have finished if
there were enough buffer space. This results in corrupted output.
Adjust the logic to resolve this and add a message when the buffer
overflows.
Signed-off-by: Simon Glass <sjg@chromium.org>
The trace does not necessarily start at the top level, so we can see it
go negative. Track this so that we can show an accurate value for the
stack depth.
Signed-off-by: Simon Glass <sjg@chromium.org>
Given that the compiler adds two function calls into each function, the
current spacing is overkill. Drop it down to 16 bytes per function, which
is still plenty. This saves some space in the trace buffer.
Also move the calculation into a function, so it is common code. Add a
check for gd->mon_len being unset, which breaks tracing.
Signed-off-by: Simon Glass <sjg@chromium.org>
