Add dump trace command which dump all trace
buffer content in a much more readable fashion
than md.
Signed-off-by: Ramon Fried <ramon.fried@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from. So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry. Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.
In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.
This commit changes all instances where we have a single declared
license in the tag as both the before and after are identical in tag
contents. There's also a few places where I found we did not have a tag
and have introduced one.
Signed-off-by: Tom Rini <trini@konsulko.com>
Now that they are in their own directory, we can remove this prefix.
This makes it easier to find a file since the prefix does not get in the
way.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Acked-by: Stefan Roese <sr@denx.de>
Acked-by: Przemyslaw Marczak <p.marczak@samsung.com>
There are a lot of unrelated files in common, including all of the commands.
Moving them into their own directory makes them easier to find and is more
logical.
Some commands include non-command code, such as cmd_scsi.c. This should be
sorted out at some point so that the function can be enabled with or without
the associated command.
Unfortunately, with m68k I get this error:
m68k: + M5329AFEE
+arch/m68k/cpu/mcf532x/start.o: In function `_start':
+arch/m68k/cpu/mcf532x/start.S:159:(.text+0x452): relocation truncated to fit: R_68K_PC16 against symbol `board_init_f' defined in .text.board_init_f section in common/built-in.o
I hope someone can shed some light on what this means. I hope it isn't
depending on the position of code in the image.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Acked-by: Stefan Roese <sr@denx.de>
Acked-by: Przemyslaw Marczak <p.marczak@samsung.com>
When debugging drivers it is useful to see what I/O accesses were done
and in what order.
Even if the individual accesses are of little interest it can be useful to
verify that the access pattern is consistent each time an operation is
performed. In this case a checksum can be used to characterise the operation
of a driver. The checksum can be compared across different runs of the
operation to verify that the driver is working properly.
In particular, when performing major refactoring of the driver, where the
access pattern should not change, the checksum provides assurance that the
refactoring work has not broken the driver.
Add an I/O tracing feature and associated commands to provide this facility.
It works by sneaking into the io.h heder for an architecture and redirecting
I/O accesses through its tracing mechanism.
For now no commands are provided to examine the trace buffer. The format is
fairly simple, so 'md' is a reasonable substitute.
Note: The checksum feature is only useful for I/O regions where the contents
do not change outside of software control. Where this is not suitable you can
fall back to manually comparing the addresses. It might be useful to enhance
tracing to only checksum the accesses and not the data read/written.
Signed-off-by: Simon Glass <sjg@chromium.org>
Ramon Fried
Tom Rini
Simon Glass