Mirrors/u-boot
2
0
Fork 0
mirror of https://github.com/AsahiLinux/u-boot synced 2024-11-05 12:45:42 +00:00
Code Issues Projects Releases Packages Wiki Activity
u-boot/common/iotrace.c

184 lines
3.8 KiB
C
Raw Normal View History

SPDX: Convert all of our single license tags to Linux Kernel style 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>
2018-05-06 21:58:06 +00:00
// SPDX-License-Identifier: GPL-2.0+
Add an I/O tracing feature 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>
2014-06-12 05:29:41 +00:00
/*
* Copyright (c) 2014 Google, Inc.
*/
#define IOTRACE_IMPL
#include <common.h>
common: Make sure arch-specific map_sysmem() is defined In the case where the arch defines a custom map_sysmem(), make sure that including just mapmem.h is sufficient to have these functions as they are when the arch does not override it. Also split the non-arch specific functions out of common.h Signed-off-by: Joe Hershberger <joe.hershberger@ni.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2015-03-22 22:08:59 +00:00
#include <mapmem.h>
common: Move get_ticks() function out of common.h This function belongs in time.h so move it over and add a comment. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2019-11-14 19:57:30 +00:00
#include <time.h>
Add an I/O tracing feature 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>
2014-06-12 05:29:41 +00:00
#include <asm/io.h>
common: Drop linux/bug.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-05-10 17:40:08 +00:00
#include <linux/bug.h>
crc32: Use the crc.h header for crc functions Drop inclusion of crc.h in common.h and use the correct header directly instead. With this we can drop the conflicting definition in fw_env.h and rely on the crc.h header, which is already included. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2019-11-14 19:57:16 +00:00
#include <u-boot/crc.h>
Add an I/O tracing feature 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>
2014-06-12 05:29:41 +00:00
DECLARE_GLOBAL_DATA_PTR;
/**
* struct iotrace - current trace status and checksum
*
* @start: Start address of iotrace buffer
iotrace: fix behaviour when buffer is full Don't continue updating the offset when buffer is full. When the buffer size exhausts and there's no space left to write warn the user and update only the needed size and not both the offset and needed size. Add needed buffer size information in the iotrace command. Signed-off-by: Ramon Fried <ramon.fried@gmail.com>
2018-06-08 17:53:27 +00:00
* @size: Actual size of iotrace buffer in bytes
* @needed_size: Needed of iotrace buffer in bytes
Add an I/O tracing feature 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>
2014-06-12 05:29:41 +00:00
* @offset: Current write offset into iotrace buffer
iotrace: add IO region limit When dealing with a lot of IO regions, sometimes it makes sense only to trace a specific one. This patch adds support for region limits. If region is not set, the iotrace works the same as it was. If region is set, the iotrace only logs io operation that falls in the defined region. Signed-off-by: Ramon Fried <ramon.fried@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-05-30 20:09:58 +00:00
* @region_start: Address of IO region to trace
* @region_size: Size of region to trace. if 0 will trace all address space
Add an I/O tracing feature 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>
2014-06-12 05:29:41 +00:00
* @crc32: Current value of CRC chceksum of trace records
* @enabled: true if enabled, false if disabled
*/
static struct iotrace {
ulong start;
ulong size;
iotrace: fix behaviour when buffer is full Don't continue updating the offset when buffer is full. When the buffer size exhausts and there's no space left to write warn the user and update only the needed size and not both the offset and needed size. Add needed buffer size information in the iotrace command. Signed-off-by: Ramon Fried <ramon.fried@gmail.com>
2018-06-08 17:53:27 +00:00
ulong needed_size;
Add an I/O tracing feature 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>
2014-06-12 05:29:41 +00:00
ulong offset;
iotrace: add IO region limit When dealing with a lot of IO regions, sometimes it makes sense only to trace a specific one. This patch adds support for region limits. If region is not set, the iotrace works the same as it was. If region is set, the iotrace only logs io operation that falls in the defined region. Signed-off-by: Ramon Fried <ramon.fried@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-05-30 20:09:58 +00:00
ulong region_start;
ulong region_size;
Add an I/O tracing feature 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>
2014-06-12 05:29:41 +00:00
u32 crc32;
bool enabled;
} iotrace;
static void add_record(int flags, const void *ptr, ulong value)
{
struct iotrace_record srec, *rec = &srec;
/*
* We don't support iotrace before relocation. Since the trace buffer
* is set up by a command, it can't be enabled at present. To change
* this we would need to set the iotrace buffer at build-time. See
* lib/trace.c for how this might be done if you are interested.
*/
if (!(gd->flags & GD_FLG_RELOC) || !iotrace.enabled)
return;
iotrace: add IO region limit When dealing with a lot of IO regions, sometimes it makes sense only to trace a specific one. This patch adds support for region limits. If region is not set, the iotrace works the same as it was. If region is set, the iotrace only logs io operation that falls in the defined region. Signed-off-by: Ramon Fried <ramon.fried@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-05-30 20:09:58 +00:00
if (iotrace.region_size)
if ((ulong)ptr < iotrace.region_start ||
(ulong)ptr > iotrace.region_start + iotrace.region_size)
return;
Add an I/O tracing feature 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>
2014-06-12 05:29:41 +00:00
/* Store it if there is room */
if (iotrace.offset + sizeof(*rec) < iotrace.size) {
rec = (struct iotrace_record *)map_sysmem(
iotrace.start + iotrace.offset,
sizeof(value));
iotrace: fix behaviour when buffer is full Don't continue updating the offset when buffer is full. When the buffer size exhausts and there's no space left to write warn the user and update only the needed size and not both the offset and needed size. Add needed buffer size information in the iotrace command. Signed-off-by: Ramon Fried <ramon.fried@gmail.com>
2018-06-08 17:53:27 +00:00
} else {
WARN_ONCE(1, "WARNING: iotrace buffer exhausted, please check needed length using \"iotrace stats\"\n");
iotrace.needed_size += sizeof(struct iotrace_record);
return;
Add an I/O tracing feature 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>
2014-06-12 05:29:41 +00:00
}
iotrace: fix behaviour when buffer is full Don't continue updating the offset when buffer is full. When the buffer size exhausts and there's no space left to write warn the user and update only the needed size and not both the offset and needed size. Add needed buffer size information in the iotrace command. Signed-off-by: Ramon Fried <ramon.fried@gmail.com>
2018-06-08 17:53:27 +00:00
common: iotrace: add timestamp to iotrace records Add timestamp to each iotrace record to aid in debugging of IO timing access bugs. Signed-off-by: Ramon Fried <ramon.fried@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-05-30 20:09:59 +00:00
rec->timestamp = timer_get_us();
Add an I/O tracing feature 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>
2014-06-12 05:29:41 +00:00
rec->flags = flags;
rec->addr = map_to_sysmem(ptr);
rec->value = value;
/* Update our checksum */
iotrace.crc32 = crc32(iotrace.crc32, (unsigned char *)rec,
sizeof(*rec));
iotrace: fix behaviour when buffer is full Don't continue updating the offset when buffer is full. When the buffer size exhausts and there's no space left to write warn the user and update only the needed size and not both the offset and needed size. Add needed buffer size information in the iotrace command. Signed-off-by: Ramon Fried <ramon.fried@gmail.com>
2018-06-08 17:53:27 +00:00
iotrace.needed_size += sizeof(struct iotrace_record);
Add an I/O tracing feature 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>
2014-06-12 05:29:41 +00:00
iotrace.offset += sizeof(struct iotrace_record);
}
u32 iotrace_readl(const void *ptr)
{
u32 v;
v = readl(ptr);
add_record(IOT_32 | IOT_READ, ptr, v);
return v;
}
trace: Remove the const from write functions The write functions do actually change the contents of memory so it is not correct to use 'const'. Remove it. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-09-25 14:56:57 +00:00
void iotrace_writel(ulong value, void *ptr)
Add an I/O tracing feature 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>
2014-06-12 05:29:41 +00:00
{
add_record(IOT_32 | IOT_WRITE, ptr, value);
writel(value, ptr);
}
u16 iotrace_readw(const void *ptr)
{
u32 v;
v = readw(ptr);
add_record(IOT_16 | IOT_READ, ptr, v);
return v;
}
trace: Remove the const from write functions The write functions do actually change the contents of memory so it is not correct to use 'const'. Remove it. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-09-25 14:56:57 +00:00
void iotrace_writew(ulong value, void *ptr)
Add an I/O tracing feature 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>
2014-06-12 05:29:41 +00:00
{
add_record(IOT_16 | IOT_WRITE, ptr, value);
writew(value, ptr);
}
u8 iotrace_readb(const void *ptr)
{
u32 v;
v = readb(ptr);
add_record(IOT_8 | IOT_READ, ptr, v);
return v;
}
trace: Remove the const from write functions The write functions do actually change the contents of memory so it is not correct to use 'const'. Remove it. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-09-25 14:56:57 +00:00
void iotrace_writeb(ulong value, void *ptr)
Add an I/O tracing feature 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>
2014-06-12 05:29:41 +00:00
{
add_record(IOT_8 | IOT_WRITE, ptr, value);
writeb(value, ptr);
}
void iotrace_reset_checksum(void)
{
iotrace.crc32 = 0;
}
u32 iotrace_get_checksum(void)
{
return iotrace.crc32;
}
iotrace: add IO region limit When dealing with a lot of IO regions, sometimes it makes sense only to trace a specific one. This patch adds support for region limits. If region is not set, the iotrace works the same as it was. If region is set, the iotrace only logs io operation that falls in the defined region. Signed-off-by: Ramon Fried <ramon.fried@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-05-30 20:09:58 +00:00
void iotrace_set_region(ulong start, ulong size)
{
iotrace.region_start = start;
iotrace.region_size = size;
}
void iotrace_reset_region(void)
{
iotrace.region_start = 0;
iotrace.region_size = 0;
}
void iotrace_get_region(ulong *start, ulong *size)
{
*start = iotrace.region_start;
*size = iotrace.region_size;
}
Add an I/O tracing feature 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>
2014-06-12 05:29:41 +00:00
void iotrace_set_enabled(int enable)
{
iotrace.enabled = enable;
}
int iotrace_get_enabled(void)
{
return iotrace.enabled;
}
void iotrace_set_buffer(ulong start, ulong size)
{
iotrace.start = start;
iotrace.size = size;
iotrace.offset = 0;
iotrace.crc32 = 0;
}
iotrace: fix behaviour when buffer is full Don't continue updating the offset when buffer is full. When the buffer size exhausts and there's no space left to write warn the user and update only the needed size and not both the offset and needed size. Add needed buffer size information in the iotrace command. Signed-off-by: Ramon Fried <ramon.fried@gmail.com>
2018-06-08 17:53:27 +00:00
void iotrace_get_buffer(ulong *start, ulong *size, ulong *needed_size, ulong *offset, ulong *count)
Add an I/O tracing feature 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>
2014-06-12 05:29:41 +00:00
{
*start = iotrace.start;
*size = iotrace.size;
iotrace: fix behaviour when buffer is full Don't continue updating the offset when buffer is full. When the buffer size exhausts and there's no space left to write warn the user and update only the needed size and not both the offset and needed size. Add needed buffer size information in the iotrace command. Signed-off-by: Ramon Fried <ramon.fried@gmail.com>
2018-06-08 17:53:27 +00:00
*needed_size = iotrace.needed_size;
Add an I/O tracing feature 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>
2014-06-12 05:29:41 +00:00
*offset = iotrace.offset;
*count = iotrace.offset / sizeof(struct iotrace_record);
}
Reference in a new issue Copy permalink