[PATCH 0/6] Allow showing the memory map

This little series adds a new 'memmap' command, intended to show the layout of memory within U-Boot and how much memory is available for loading images.
Simon Glass (6): common: Fix up malloc() comment in reserve_noncached() common: Tidy up how malloc() is inited am65x: Use map_to_sysmem() to convert from pointer global_data: Add some more accessors bootstage: Allow counting memory without strings cmd: Add a command to show the memory map
arch/arm/mach-k3/am65x/am654_init.c | 11 +-- cmd/Kconfig | 10 +++ cmd/Makefile | 1 + cmd/memmap.c | 66 +++++++++++++++ common/board_f.c | 8 +- common/board_r.c | 3 +- common/bootstage.c | 16 ++-- common/dlmalloc.c | 8 +- common/spl/spl.c | 4 +- doc/usage/cmd/memmap.rst | 123 ++++++++++++++++++++++++++++ doc/usage/index.rst | 1 + include/asm-generic/global_data.h | 30 +++++++ include/bootstage.h | 5 +- include/malloc.h | 8 ++ test/cmd/Makefile | 3 +- test/cmd/memmap.c | 35 ++++++++ 16 files changed, 305 insertions(+), 27 deletions(-) create mode 100644 cmd/memmap.c create mode 100644 doc/usage/cmd/memmap.rst create mode 100644 test/cmd/memmap.c

The function name has changed, so update it.
Signed-off-by: Simon Glass sjg@chromium.org ---
common/board_f.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/common/board_f.c b/common/board_f.c index 154675d0e40..2e04a47b546 100644 --- a/common/board_f.c +++ b/common/board_f.c @@ -501,9 +501,9 @@ static unsigned long reserve_stack_aligned(size_t size) static int reserve_noncached(void) { /* - * The value of gd->start_addr_sp must match the value of malloc_start - * calculated in board_r.c:initr_malloc(), which is passed to - * dlmalloc.c:mem_malloc_init() and then used by + * The value of gd->start_addr_sp must match the value of + * mem_malloc_start calculated in board_r.c:initr_malloc(), which is + * passed to dlmalloc.c:mem_malloc_init() and then used by * cache.c:noncached_init() * * These calculations must match the code in cache.c:noncached_init()

On Wed, 9 Oct 2024 at 04:50, Simon Glass sjg@chromium.org wrote:
The function name has changed, so update it.
Signed-off-by: Simon Glass sjg@chromium.org
common/board_f.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/common/board_f.c b/common/board_f.c index 154675d0e40..2e04a47b546 100644 --- a/common/board_f.c +++ b/common/board_f.c @@ -501,9 +501,9 @@ static unsigned long reserve_stack_aligned(size_t size) static int reserve_noncached(void) { /*
* The value of gd->start_addr_sp must match the value of malloc_start
* calculated in board_r.c:initr_malloc(), which is passed to
* dlmalloc.c:mem_malloc_init() and then used by
* The value of gd->start_addr_sp must match the value of
* mem_malloc_start calculated in board_r.c:initr_malloc(), which is
* passed to dlmalloc.c:mem_malloc_init() and then used by * cache.c:noncached_init() * * These calculations must match the code in cache.c:noncached_init()
-- 2.43.0
Acked-by: Ilias Apalodimas ilias.apalodimas@linaro.org

The call to malloc() is a bit strange. The naming of the arguments suggests that an address is passed, but in fact it is a pointer, at least in the board_init_r() function and SPL equivalent.
Update it to work as described. Add a function comment as well.
Note that this does adjustment does not extend into the malloc() implementation itself, apart from changing mem_malloc_init(), since there are lots of casts and pointers and integers are used interchangeably.
Signed-off-by: Simon Glass sjg@chromium.org ---
common/board_r.c | 3 +-- common/dlmalloc.c | 8 +++++--- common/spl/spl.c | 4 +--- include/malloc.h | 8 ++++++++ 4 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/common/board_r.c b/common/board_r.c index 4faaa202421..fbb10fea494 100644 --- a/common/board_r.c +++ b/common/board_r.c @@ -203,8 +203,7 @@ static int initr_malloc(void) */ start = gd->relocaddr - TOTAL_MALLOC_LEN; gd_set_malloc_start(start); - mem_malloc_init((ulong)map_sysmem(start, TOTAL_MALLOC_LEN), - TOTAL_MALLOC_LEN); + mem_malloc_init(start, TOTAL_MALLOC_LEN); return 0; }
diff --git a/common/dlmalloc.c b/common/dlmalloc.c index 1ac7ce3f43c..cc4d3a0a028 100644 --- a/common/dlmalloc.c +++ b/common/dlmalloc.c @@ -16,6 +16,8 @@ #include <asm/global_data.h>
#include <malloc.h> +#include <mapmem.h> +#include <string.h> #include <asm/io.h> #include <valgrind/memcheck.h>
@@ -598,9 +600,9 @@ void *sbrk(ptrdiff_t increment)
void mem_malloc_init(ulong start, ulong size) { - mem_malloc_start = start; - mem_malloc_end = start + size; - mem_malloc_brk = start; + mem_malloc_start = (ulong)map_sysmem(start, size); + mem_malloc_end = mem_malloc_start + size; + mem_malloc_brk = mem_malloc_start;
#ifdef CONFIG_SYS_MALLOC_DEFAULT_TO_INIT malloc_init(); diff --git a/common/spl/spl.c b/common/spl/spl.c index c13b2b8f714..fc8b38862e8 100644 --- a/common/spl/spl.c +++ b/common/spl/spl.c @@ -679,9 +679,7 @@ void board_init_r(gd_t *dummy1, ulong dummy2) spl_set_bd();
if (IS_ENABLED(CONFIG_SPL_SYS_MALLOC)) { - mem_malloc_init((ulong)map_sysmem(SPL_SYS_MALLOC_START, - SPL_SYS_MALLOC_SIZE), - SPL_SYS_MALLOC_SIZE); + mem_malloc_init(SPL_SYS_MALLOC_START, SPL_SYS_MALLOC_SIZE); gd->flags |= GD_FLG_FULL_MALLOC_INIT; } if (!(gd->flags & GD_FLG_SPL_INIT)) { diff --git a/include/malloc.h b/include/malloc.h index 07d3e90a855..9e0be482416 100644 --- a/include/malloc.h +++ b/include/malloc.h @@ -981,6 +981,14 @@ extern ulong mem_malloc_start; extern ulong mem_malloc_end; extern ulong mem_malloc_brk;
+/** + * mem_malloc_init() - Set up the malloc() pool + * + * Sets the region of memory to be used for all future calls to malloc(), etc. + * + * @start: Start address + * @size: Size in bytes + */ void mem_malloc_init(ulong start, ulong size);
#ifdef __cplusplus

Hi Simon,
On Wed, 9 Oct 2024 at 04:50, Simon Glass sjg@chromium.org wrote:
The call to malloc() is a bit strange. The naming of the arguments suggests that an address is passed, but in fact it is a pointer, at least in the board_init_r() function and SPL equivalent.
Update it to work as described. Add a function comment as well.
Note that this does adjustment does not extend into the malloc() implementation itself, apart from changing mem_malloc_init(), since there are lots of casts and pointers and integers are used interchangeably.
Signed-off-by: Simon Glass sjg@chromium.org
common/board_r.c | 3 +-- common/dlmalloc.c | 8 +++++--- common/spl/spl.c | 4 +--- include/malloc.h | 8 ++++++++ 4 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/common/board_r.c b/common/board_r.c index 4faaa202421..fbb10fea494 100644 --- a/common/board_r.c +++ b/common/board_r.c @@ -203,8 +203,7 @@ static int initr_malloc(void) */ start = gd->relocaddr - TOTAL_MALLOC_LEN; gd_set_malloc_start(start);
mem_malloc_init((ulong)map_sysmem(start, TOTAL_MALLOC_LEN),
TOTAL_MALLOC_LEN);
mem_malloc_init(start, TOTAL_MALLOC_LEN); return 0;
}
diff --git a/common/dlmalloc.c b/common/dlmalloc.c index 1ac7ce3f43c..cc4d3a0a028 100644 --- a/common/dlmalloc.c +++ b/common/dlmalloc.c @@ -16,6 +16,8 @@ #include <asm/global_data.h>
#include <malloc.h> +#include <mapmem.h> +#include <string.h> #include <asm/io.h> #include <valgrind/memcheck.h>
@@ -598,9 +600,9 @@ void *sbrk(ptrdiff_t increment)
void mem_malloc_init(ulong start, ulong size) {
mem_malloc_start = start;
mem_malloc_end = start + size;
mem_malloc_brk = start;
mem_malloc_start = (ulong)map_sysmem(start, size);
mem_malloc_end = mem_malloc_start + size;
mem_malloc_brk = mem_malloc_start;
#ifdef CONFIG_SYS_MALLOC_DEFAULT_TO_INIT malloc_init(); diff --git a/common/spl/spl.c b/common/spl/spl.c index c13b2b8f714..fc8b38862e8 100644 --- a/common/spl/spl.c +++ b/common/spl/spl.c @@ -679,9 +679,7 @@ void board_init_r(gd_t *dummy1, ulong dummy2) spl_set_bd();
if (IS_ENABLED(CONFIG_SPL_SYS_MALLOC)) {
mem_malloc_init((ulong)map_sysmem(SPL_SYS_MALLOC_START,
SPL_SYS_MALLOC_SIZE),
SPL_SYS_MALLOC_SIZE);
mem_malloc_init(SPL_SYS_MALLOC_START, SPL_SYS_MALLOC_SIZE); gd->flags |= GD_FLG_FULL_MALLOC_INIT; } if (!(gd->flags & GD_FLG_SPL_INIT)) {
diff --git a/include/malloc.h b/include/malloc.h index 07d3e90a855..9e0be482416 100644 --- a/include/malloc.h +++ b/include/malloc.h @@ -981,6 +981,14 @@ extern ulong mem_malloc_start; extern ulong mem_malloc_end; extern ulong mem_malloc_brk;
+/**
- mem_malloc_init() - Set up the malloc() pool
- Sets the region of memory to be used for all future calls to malloc(), etc.
- @start: Start address
- @size: Size in bytes
- */
void mem_malloc_init(ulong start, ulong size);
#ifdef __cplusplus
2.43.0
This looks ok as long as map_sysmem() is a 1:1 mapping for non-sandbox archs. NXP seems to be calling these with an address already. I guess since we only define an alternative map_sysmem() for sandbox this is ok
Reviewed-by: Ilias Apalodimas ilias.apalodimas@linaro.org

Hi Ilias,
On Wed, 9 Oct 2024 at 04:38, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi Simon,
On Wed, 9 Oct 2024 at 04:50, Simon Glass sjg@chromium.org wrote:
The call to malloc() is a bit strange. The naming of the arguments suggests that an address is passed, but in fact it is a pointer, at least in the board_init_r() function and SPL equivalent.
Update it to work as described. Add a function comment as well.
Note that this does adjustment does not extend into the malloc() implementation itself, apart from changing mem_malloc_init(), since there are lots of casts and pointers and integers are used interchangeably.
Signed-off-by: Simon Glass sjg@chromium.org
common/board_r.c | 3 +-- common/dlmalloc.c | 8 +++++--- common/spl/spl.c | 4 +--- include/malloc.h | 8 ++++++++ 4 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/common/board_r.c b/common/board_r.c index 4faaa202421..fbb10fea494 100644 --- a/common/board_r.c +++ b/common/board_r.c @@ -203,8 +203,7 @@ static int initr_malloc(void) */ start = gd->relocaddr - TOTAL_MALLOC_LEN; gd_set_malloc_start(start);
mem_malloc_init((ulong)map_sysmem(start, TOTAL_MALLOC_LEN),
TOTAL_MALLOC_LEN);
mem_malloc_init(start, TOTAL_MALLOC_LEN); return 0;
}
diff --git a/common/dlmalloc.c b/common/dlmalloc.c index 1ac7ce3f43c..cc4d3a0a028 100644 --- a/common/dlmalloc.c +++ b/common/dlmalloc.c @@ -16,6 +16,8 @@ #include <asm/global_data.h>
#include <malloc.h> +#include <mapmem.h> +#include <string.h> #include <asm/io.h> #include <valgrind/memcheck.h>
@@ -598,9 +600,9 @@ void *sbrk(ptrdiff_t increment)
void mem_malloc_init(ulong start, ulong size) {
mem_malloc_start = start;
mem_malloc_end = start + size;
mem_malloc_brk = start;
mem_malloc_start = (ulong)map_sysmem(start, size);
mem_malloc_end = mem_malloc_start + size;
mem_malloc_brk = mem_malloc_start;
#ifdef CONFIG_SYS_MALLOC_DEFAULT_TO_INIT malloc_init(); diff --git a/common/spl/spl.c b/common/spl/spl.c index c13b2b8f714..fc8b38862e8 100644 --- a/common/spl/spl.c +++ b/common/spl/spl.c @@ -679,9 +679,7 @@ void board_init_r(gd_t *dummy1, ulong dummy2) spl_set_bd();
if (IS_ENABLED(CONFIG_SPL_SYS_MALLOC)) {
mem_malloc_init((ulong)map_sysmem(SPL_SYS_MALLOC_START,
SPL_SYS_MALLOC_SIZE),
SPL_SYS_MALLOC_SIZE);
mem_malloc_init(SPL_SYS_MALLOC_START, SPL_SYS_MALLOC_SIZE); gd->flags |= GD_FLG_FULL_MALLOC_INIT; } if (!(gd->flags & GD_FLG_SPL_INIT)) {
diff --git a/include/malloc.h b/include/malloc.h index 07d3e90a855..9e0be482416 100644 --- a/include/malloc.h +++ b/include/malloc.h @@ -981,6 +981,14 @@ extern ulong mem_malloc_start; extern ulong mem_malloc_end; extern ulong mem_malloc_brk;
+/**
- mem_malloc_init() - Set up the malloc() pool
- Sets the region of memory to be used for all future calls to malloc(), etc.
- @start: Start address
- @size: Size in bytes
- */
void mem_malloc_init(ulong start, ulong size);
#ifdef __cplusplus
2.43.0
This looks ok as long as map_sysmem() is a 1:1 mapping for non-sandbox archs. NXP seems to be calling these with an address already.
Yes it is
I guess since we only define an alternative map_sysmem() for sandbox this is ok
Reviewed-by: Ilias Apalodimas ilias.apalodimas@linaro.org
Thanks.
Regards, Simon

The board_init_f() function for am65x is a bit confusing, since it uses the variable name 'pool_addr' to hold a pointer. It then casts it to an address to pass to mem_alloc_init()
Rename the variable and use mapmem to convert to an address.
Signed-off-by: Simon Glass sjg@chromium.org ---
arch/arm/mach-k3/am65x/am654_init.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-k3/am65x/am654_init.c b/arch/arm/mach-k3/am65x/am654_init.c index a4f038029d7..ddcc1355210 100644 --- a/arch/arm/mach-k3/am65x/am654_init.c +++ b/arch/arm/mach-k3/am65x/am654_init.c @@ -8,6 +8,7 @@
#include <fdt_support.h> #include <init.h> +#include <mapmem.h> #include <asm/global_data.h> #include <asm/io.h> #include <spl.h> @@ -165,7 +166,7 @@ void board_init_f(ulong dummy) #if defined(CONFIG_K3_LOAD_SYSFW) || defined(CONFIG_K3_AM654_DDRSS) struct udevice *dev; size_t pool_size; - void *pool_addr; + void *pool; int ret; #endif /* @@ -204,14 +205,14 @@ void board_init_f(ulong dummy) * malloc pool of which we use all that's left. */ pool_size = CONFIG_VAL(SYS_MALLOC_F_LEN) - gd->malloc_ptr; - pool_addr = malloc(pool_size); - if (!pool_addr) + pool = malloc(pool_size); + if (!pool) panic("ERROR: Can't allocate full malloc pool!\n");
- mem_malloc_init((ulong)pool_addr, (ulong)pool_size); + mem_malloc_init(map_to_sysmem(pool), (ulong)pool_size); gd->flags |= GD_FLG_FULL_MALLOC_INIT; debug("%s: initialized an early full malloc pool at 0x%08lx of 0x%lx bytes\n", - __func__, (unsigned long)pool_addr, (unsigned long)pool_size); + __func__, (unsigned long)pool, (unsigned long)pool_size); /* * Process pinctrl for the serial0 a.k.a. WKUP_UART0 module and continue * regardless of the result of pinctrl. Do this without probing the

Add accessors for bloblist, bootstage, trace and video to avoid needing more #ifdefs in the C code.
Signed-off-by: Simon Glass sjg@chromium.org ---
include/asm-generic/global_data.h | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+)
diff --git a/include/asm-generic/global_data.h b/include/asm-generic/global_data.h index d6c15e2c406..fcf9fa27117 100644 --- a/include/asm-generic/global_data.h +++ b/include/asm-generic/global_data.h @@ -544,6 +544,36 @@ static_assert(sizeof(struct global_data) == GD_SIZE); #define gd_set_upl(val) #endif
+#if CONFIG_IS_ENABLED(BLOBLIST) +#define gd_bloblist() gd->bloblist +#else +#define gd_bloblist() NULL +#endif + +#if CONFIG_IS_ENABLED(BOOTSTAGE) +#define gd_bootstage() gd->bootstage +#else +#define gd_bootstage() NULL +#endif + +#if CONFIG_IS_ENABLED(TRACE) +#define gd_trace_buff() gd->trace_buff +#define gd_trace_size() CONFIG_TRACE_BUFFER_SIZE +#else +#define gd_trace_buff() NULL +#define gd_trace_size() 0 +#endif + +#if CONFIG_IS_ENABLED(VIDEO) +#define gd_video_top() gd->video_top +#define gd_video_bottom() gd->video_bottom +#define gd_video_size() (gd->video_top - gd->video_bottom) +#else +#define gd_video_top() 0 +#define gd_video_bottom() 0 +#define gd_video_size() 0 +#endif + /** * enum gd_flags - global data flags *

The bootstage array includes pointers to strings but not the strings themselves. The strings are added when stashing, but including them in the size calculation gives an inflated view of the amount of space used by the array.
Update this function so it can return the amount of memory used by the bootstage structures themselves, without the strings which they point to.
Signed-off-by: Simon Glass sjg@chromium.org ---
common/board_f.c | 2 +- common/bootstage.c | 16 +++++++++------- include/bootstage.h | 5 +++-- 3 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/common/board_f.c b/common/board_f.c index 2e04a47b546..bf4252784a4 100644 --- a/common/board_f.c +++ b/common/board_f.c @@ -582,7 +582,7 @@ static int reserve_fdt(void) static int reserve_bootstage(void) { #ifdef CONFIG_BOOTSTAGE - int size = bootstage_get_size(); + int size = bootstage_get_size(true);
gd->start_addr_sp = reserve_stack_aligned(size); gd->boardf->new_bootstage = map_sysmem(gd->start_addr_sp, size); diff --git a/common/bootstage.c b/common/bootstage.c index 49acc9078a6..b1506120f9d 100644 --- a/common/bootstage.c +++ b/common/bootstage.c @@ -520,17 +520,19 @@ int _bootstage_unstash_default(void) } #endif
-int bootstage_get_size(void) +int bootstage_get_size(bool add_strings) { - struct bootstage_data *data = gd->bootstage; - struct bootstage_record *rec; int size; - int i;
size = sizeof(struct bootstage_data); - for (rec = data->record, i = 0; i < data->rec_count; - i++, rec++) - size += strlen(rec->name) + 1; + if (add_strings) { + struct bootstage_data *data = gd->bootstage; + struct bootstage_record *rec; + int i; + + for (rec = data->record, i = 0; i < data->rec_count; i++, rec++) + size += strlen(rec->name) + 1; + }
return size; } diff --git a/include/bootstage.h b/include/bootstage.h index 57792648c49..3300ca0248a 100644 --- a/include/bootstage.h +++ b/include/bootstage.h @@ -371,9 +371,10 @@ int bootstage_unstash(const void *base, int size); /** * bootstage_get_size() - Get the size of the bootstage data * + * @add_strings: true to add the size of attached strings (for stashing) * Return: size of boostage data in bytes */ -int bootstage_get_size(void); +int bootstage_get_size(bool add_strings);
/** * bootstage_init() - Prepare bootstage for use @@ -444,7 +445,7 @@ static inline int bootstage_unstash(const void *base, int size) return 0; /* Pretend to succeed */ }
-static inline int bootstage_get_size(void) +static inline int bootstage_get_size(bool add_strings) { return 0; }

U-Boot has a fairly rigid memory map which is normally not visible unless debugging is enabled in board_f.c
Add a 'memmap' command which shows it. This command does not cover arch-specific pieces but gives a good overview of where things are.
Signed-off-by: Simon Glass sjg@chromium.org ---
cmd/Kconfig | 10 ++++ cmd/Makefile | 1 + cmd/memmap.c | 66 +++++++++++++++++++++ doc/usage/cmd/memmap.rst | 123 +++++++++++++++++++++++++++++++++++++++ doc/usage/index.rst | 1 + test/cmd/Makefile | 3 +- test/cmd/memmap.c | 35 +++++++++++ 7 files changed, 238 insertions(+), 1 deletion(-) create mode 100644 cmd/memmap.c create mode 100644 doc/usage/cmd/memmap.rst create mode 100644 test/cmd/memmap.c
diff --git a/cmd/Kconfig b/cmd/Kconfig index dd33266cec7..d4a29217323 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -921,6 +921,16 @@ config CMD_MEM_SEARCH pressing return will show the next 10 matches. Environment variables are set for use with scripting (memmatches, memaddr, mempos).
+config CMD_MEMMAP + bool "memmap - Memory map" + default y if SANDBOX + help + memmap command + + This shows the location of areas of memory used by U-Boot. This includes + the malloc() region, U-Boot's code and data, bloblist and anything else + that prevents a particular region being used for loading images. + config CMD_MX_CYCLIC bool "Enable cyclic md/mw commands" depends on CMD_MEMORY diff --git a/cmd/Makefile b/cmd/Makefile index 91227f1249c..4f05dafaaad 100644 --- a/cmd/Makefile +++ b/cmd/Makefile @@ -109,6 +109,7 @@ obj-y += load.o obj-$(CONFIG_CMD_LOG) += log.o obj-$(CONFIG_CMD_LSBLK) += lsblk.o obj-$(CONFIG_CMD_MD5SUM) += md5sum.o +obj-$(CONFIG_CMD_MEMMAP) += memmap.o obj-$(CONFIG_CMD_MEMORY) += mem.o obj-$(CONFIG_CMD_IO) += io.o obj-$(CONFIG_CMD_MII) += mii.o diff --git a/cmd/memmap.c b/cmd/memmap.c new file mode 100644 index 00000000000..d83c04467e9 --- /dev/null +++ b/cmd/memmap.c @@ -0,0 +1,66 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright 2024 Google LLC + * Written by Simon Glass sjg@chromium.org + */ + +#include <bloblist.h> +#include <bootstage.h> +#include <command.h> +#include <malloc.h> +#include <mapmem.h> +#include <asm/global_data.h> + +DECLARE_GLOBAL_DATA_PTR; + +static void print_region(const char *name, ulong base, ulong size, ulong *uptop) +{ + ulong end = base + size; + + printf("%-12s %8lx %8lx %8lx", name, base, size, end); + if (*uptop) + printf(" %8lx", *uptop - end); + putc('\n'); + *uptop = base; +} + +static int do_memmap(struct cmd_tbl *cmdtp, int flag, int argc, + char *const argv[]) +{ + ulong upto, stk_bot; + + printf("%-12s %8s %8s %8s %8s\n", "Region", "Base", "Size", "End", + "Gap"); + printf("------------------------------------------------\n"); + upto = 0; + if (IS_ENABLED(CONFIG_VIDEO)) + print_region("video", gd_video_bottom(), + gd_video_size(), &upto); + if (IS_ENABLED(CONFIG_TRACE)) + print_region("trace", map_to_sysmem(gd_trace_buff()), + gd_trace_size(), &upto); + print_region("code", gd->relocaddr, gd->mon_len, &upto); + print_region("malloc", mem_malloc_start, + mem_malloc_end - mem_malloc_start, &upto); + print_region("board_info", map_to_sysmem(gd->bd), + sizeof(struct bd_info), &upto); + print_region("global_data", map_to_sysmem(gd), + sizeof(struct global_data), &upto); + print_region("devicetree", map_to_sysmem(gd->fdt_blob), + fdt_totalsize(gd->fdt_blob), &upto); + if (IS_ENABLED(CONFIG_BOOTSTAGE)) + print_region("bootstage", map_to_sysmem(gd_bootstage()), + bootstage_get_size(false), &upto); + if (IS_ENABLED(CONFIG_BLOBLIST)) + print_region("bloblist", map_to_sysmem(gd_bloblist()), + bloblist_get_total_size(), &upto); + stk_bot = gd->start_addr_sp - CONFIG_STACK_SIZE; + print_region("stack", stk_bot, CONFIG_STACK_SIZE, &upto); + print_region("free", gd->ram_base, stk_bot, &upto); + + return 0; +} + +U_BOOT_CMD( + memmap, 1, 1, do_memmap, "Show a map of U-Boot's memory usage", "" +); diff --git a/doc/usage/cmd/memmap.rst b/doc/usage/cmd/memmap.rst new file mode 100644 index 00000000000..2f0888a9691 --- /dev/null +++ b/doc/usage/cmd/memmap.rst @@ -0,0 +1,123 @@ +.. SPDX-License-Identifier: GPL-2.0+: + +.. index:: + single: memmap (command) + +memmap command +============== + +Synopsis +-------- + +:: + + memmap + +Description +----------- + +The memmap command shows the layout of memory used by U-Boot and the region +which is free for use by images. + +The layout of memory is set up before relocation, within the init sequence in +``board_init_f()``, specifically the various ``reserve_...()`` functions. This +'reservation' of memory starts from the top of RAM and proceeds downwards, +ending with the stack. This results in the maximum possible amount of memory +being left free for image-loading. + +The memmap command writes its outputs in 5 columns: + +Region + Name of the region + +Base + Base address of the region, i.e. where it starts in memory + +Size + Size of the region, which may be a little smaller than the actual size + reserved, e.g. due to alignment + +End + End of the region. The last byte of the region is one lower than the address + shown here + +Gap + Gap between the end of this region and the base of the one above + +Regions shown are: + +video + Memory reserved for video framebuffers. This reservation happens in the + bind() methods of all video drivers which are present before relocation, + so the size depends on that maximum amount of memory which all such drivers + want to reserve. This may be significantly greater than the amount actually + needed, if the display is ultimately set to a smaller resolution or colour + depth than the maximum supported. + +code + U-Boot's code and Block-Starting Symbol (BSS) region. Before relocation, + U-Boot copies its code to a high region and sets up a BSS immediately after + that. The size of this region is generally therefore ``__bss_end`` - + ``__image_copy_start`` + +malloc + Contains the malloc() heap. The size of this is set by + ``CONFIG_SYS_MALLOC_LEN``. + +board_info + Contains the ``bd_info`` structure, with some information about the current + board. + +global_data + Contains the global-data structure, pointed to by ``gd``. This includes + various pointers, values and flags which control U-Boot. + +devicetree + Contains the flatted devicetree blob (FDT) being used by U-Boot to configure + itself and its devices. + +bootstage + Contains the bootstage records, which keep track of boot time as U-Boot + executes. The size of this is determined by + ``CONFIG_BOOTSTAGE_RECORD_COUNT``, with each record taking approximately + 32 bytes. + +bloblist + Contains the bloblist, which is a list of tables and other data created by + U-Boot while executed. The size of this is determined by + ``CONFIG_BLOBLIST_SIZE``. + +stack + Contains U-Boot's stack, growing downwards from the top. The nominal size of + this region is set by ``CONFIG_STACK_SIZE`` but there is no actual limit + enforced, so the stack can grow behind that. Images should be loaded lower + in memory to avoid any conflict. + +free + Free memory, which is available for loading images. The base address of + this is ``gd->ram_base`` which is generally set by ``CFG_SYS_SDRAM_BASE``. + +Example +------- + +:: + + => memmap + Region Base Size End Gap + ------------------------------------------------ + video f000000 1000000 10000000 + code ec3a000 3c5d28 efffd28 2d8 + malloc 8c38000 6002000 ec3a000 0 + board_info 8c37f90 68 8c37ff8 8 + global_data 8c37d80 208 8c37f88 8 + devicetree 8c33000 4d7d 8c37d7d 3 + bootstage 8c32c20 3c8 8c32fe8 18 + bloblist 8c32000 400 8c32400 820 + stack 7c31ff0 1000000 8c31ff0 10 + free 0 7c31ff0 7c31ff0 0 + + +Return value +------------ + +The return value $? is always 0 (true). diff --git a/doc/usage/index.rst b/doc/usage/index.rst index 70563374899..dd2b5807a4f 100644 --- a/doc/usage/index.rst +++ b/doc/usage/index.rst @@ -83,6 +83,7 @@ Shell commands cmd/loads cmd/loadx cmd/loady + cmd/memmap cmd/mbr cmd/md cmd/mmc diff --git a/test/cmd/Makefile b/test/cmd/Makefile index 8f2134998ad..3f6ae59f3d4 100644 --- a/test/cmd/Makefile +++ b/test/cmd/Makefile @@ -18,8 +18,9 @@ obj-$(CONFIG_CMD_FDT) += fdt.o obj-$(CONFIG_CONSOLE_TRUETYPE) += font.o obj-$(CONFIG_CMD_HISTORY) += history.o obj-$(CONFIG_CMD_LOADM) += loadm.o -obj-$(CONFIG_CMD_MEM_SEARCH) += mem_search.o +obj-$(CONFIG_CMD_MEMMAP) += memmap.o obj-$(CONFIG_CMD_MEMORY) += mem_copy.o +obj-$(CONFIG_CMD_MEM_SEARCH) += mem_search.o ifdef CONFIG_CMD_PCI obj-$(CONFIG_CMD_PCI_MPS) += pci_mps.o endif diff --git a/test/cmd/memmap.c b/test/cmd/memmap.c new file mode 100644 index 00000000000..f12d7174838 --- /dev/null +++ b/test/cmd/memmap.c @@ -0,0 +1,35 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Test for 'memmap' command + * + * Copyright 2024 Google LLC + * Written by Simon Glass sjg@chromium.org + */ + +#include <dm/test.h> +#include <test/cmd.h> +#include <test/ut.h> + +/* Test 'memmap' command */ +static int cmd_test_memmap(struct unit_test_state *uts) +{ + ut_assertok(run_command("memmap", 0)); + ut_assert_nextline("Region Base Size End Gap"); + ut_assert_nextlinen("-"); + + /* For now we don't worry about checking the values */ + ut_assert_nextlinen("video"); + ut_assert_nextlinen("code"); + ut_assert_nextlinen("malloc"); + ut_assert_nextlinen("board_info"); + ut_assert_nextlinen("global_data"); + ut_assert_nextlinen("devicetree"); + ut_assert_nextlinen("bootstage"); + ut_assert_nextlinen("bloblist"); + ut_assert_nextlinen("stack"); + ut_assert_nextlinen("free"); + ut_assert_console_end(); + + return 0; +} +CMD_TEST(cmd_test_memmap, UTF_CONSOLE);

Hi Simon,
We already have a mem info command, which is pretty useless. Can't we reuse that ?
Thanks /Ilias
On Wed, 9 Oct 2024 at 04:50, Simon Glass sjg@chromium.org wrote:
U-Boot has a fairly rigid memory map which is normally not visible unless debugging is enabled in board_f.c
Add a 'memmap' command which shows it. This command does not cover arch-specific pieces but gives a good overview of where things are.
Signed-off-by: Simon Glass sjg@chromium.org
cmd/Kconfig | 10 ++++ cmd/Makefile | 1 + cmd/memmap.c | 66 +++++++++++++++++++++ doc/usage/cmd/memmap.rst | 123 +++++++++++++++++++++++++++++++++++++++ doc/usage/index.rst | 1 + test/cmd/Makefile | 3 +- test/cmd/memmap.c | 35 +++++++++++ 7 files changed, 238 insertions(+), 1 deletion(-) create mode 100644 cmd/memmap.c create mode 100644 doc/usage/cmd/memmap.rst create mode 100644 test/cmd/memmap.c
diff --git a/cmd/Kconfig b/cmd/Kconfig index dd33266cec7..d4a29217323 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -921,6 +921,16 @@ config CMD_MEM_SEARCH pressing return will show the next 10 matches. Environment variables are set for use with scripting (memmatches, memaddr, mempos).
+config CMD_MEMMAP
bool "memmap - Memory map"
default y if SANDBOX
help
memmap command
This shows the location of areas of memory used by U-Boot. This includes
the malloc() region, U-Boot's code and data, bloblist and anything else
that prevents a particular region being used for loading images.
config CMD_MX_CYCLIC bool "Enable cyclic md/mw commands" depends on CMD_MEMORY diff --git a/cmd/Makefile b/cmd/Makefile index 91227f1249c..4f05dafaaad 100644 --- a/cmd/Makefile +++ b/cmd/Makefile @@ -109,6 +109,7 @@ obj-y += load.o obj-$(CONFIG_CMD_LOG) += log.o obj-$(CONFIG_CMD_LSBLK) += lsblk.o obj-$(CONFIG_CMD_MD5SUM) += md5sum.o +obj-$(CONFIG_CMD_MEMMAP) += memmap.o obj-$(CONFIG_CMD_MEMORY) += mem.o obj-$(CONFIG_CMD_IO) += io.o obj-$(CONFIG_CMD_MII) += mii.o diff --git a/cmd/memmap.c b/cmd/memmap.c new file mode 100644 index 00000000000..d83c04467e9 --- /dev/null +++ b/cmd/memmap.c @@ -0,0 +1,66 @@ +// SPDX-License-Identifier: GPL-2.0+ +/*
- Copyright 2024 Google LLC
- Written by Simon Glass sjg@chromium.org
- */
+#include <bloblist.h> +#include <bootstage.h> +#include <command.h> +#include <malloc.h> +#include <mapmem.h> +#include <asm/global_data.h>
+DECLARE_GLOBAL_DATA_PTR;
+static void print_region(const char *name, ulong base, ulong size, ulong *uptop) +{
ulong end = base + size;
printf("%-12s %8lx %8lx %8lx", name, base, size, end);
if (*uptop)
printf(" %8lx", *uptop - end);
putc('\n');
*uptop = base;
+}
+static int do_memmap(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
+{
ulong upto, stk_bot;
printf("%-12s %8s %8s %8s %8s\n", "Region", "Base", "Size", "End",
"Gap");
printf("------------------------------------------------\n");
upto = 0;
if (IS_ENABLED(CONFIG_VIDEO))
print_region("video", gd_video_bottom(),
gd_video_size(), &upto);
if (IS_ENABLED(CONFIG_TRACE))
print_region("trace", map_to_sysmem(gd_trace_buff()),
gd_trace_size(), &upto);
print_region("code", gd->relocaddr, gd->mon_len, &upto);
print_region("malloc", mem_malloc_start,
mem_malloc_end - mem_malloc_start, &upto);
print_region("board_info", map_to_sysmem(gd->bd),
sizeof(struct bd_info), &upto);
print_region("global_data", map_to_sysmem(gd),
sizeof(struct global_data), &upto);
print_region("devicetree", map_to_sysmem(gd->fdt_blob),
fdt_totalsize(gd->fdt_blob), &upto);
if (IS_ENABLED(CONFIG_BOOTSTAGE))
print_region("bootstage", map_to_sysmem(gd_bootstage()),
bootstage_get_size(false), &upto);
if (IS_ENABLED(CONFIG_BLOBLIST))
print_region("bloblist", map_to_sysmem(gd_bloblist()),
bloblist_get_total_size(), &upto);
stk_bot = gd->start_addr_sp - CONFIG_STACK_SIZE;
print_region("stack", stk_bot, CONFIG_STACK_SIZE, &upto);
print_region("free", gd->ram_base, stk_bot, &upto);
return 0;
+}
+U_BOOT_CMD(
memmap, 1, 1, do_memmap, "Show a map of U-Boot's memory usage", ""
+); diff --git a/doc/usage/cmd/memmap.rst b/doc/usage/cmd/memmap.rst new file mode 100644 index 00000000000..2f0888a9691 --- /dev/null +++ b/doc/usage/cmd/memmap.rst @@ -0,0 +1,123 @@ +.. SPDX-License-Identifier: GPL-2.0+:
+.. index::
- single: memmap (command)
+memmap command +==============
+Synopsis +--------
+::
- memmap
+Description +-----------
+The memmap command shows the layout of memory used by U-Boot and the region +which is free for use by images.
+The layout of memory is set up before relocation, within the init sequence in +``board_init_f()``, specifically the various ``reserve_...()`` functions. This +'reservation' of memory starts from the top of RAM and proceeds downwards, +ending with the stack. This results in the maximum possible amount of memory +being left free for image-loading.
+The memmap command writes its outputs in 5 columns:
+Region
- Name of the region
+Base
- Base address of the region, i.e. where it starts in memory
+Size
- Size of the region, which may be a little smaller than the actual size
- reserved, e.g. due to alignment
+End
- End of the region. The last byte of the region is one lower than the address
- shown here
+Gap
- Gap between the end of this region and the base of the one above
+Regions shown are:
+video
- Memory reserved for video framebuffers. This reservation happens in the
- bind() methods of all video drivers which are present before relocation,
- so the size depends on that maximum amount of memory which all such drivers
- want to reserve. This may be significantly greater than the amount actually
- needed, if the display is ultimately set to a smaller resolution or colour
- depth than the maximum supported.
+code
- U-Boot's code and Block-Starting Symbol (BSS) region. Before relocation,
- U-Boot copies its code to a high region and sets up a BSS immediately after
- that. The size of this region is generally therefore ``__bss_end`` -
- ``__image_copy_start``
+malloc
- Contains the malloc() heap. The size of this is set by
- ``CONFIG_SYS_MALLOC_LEN``.
+board_info
- Contains the ``bd_info`` structure, with some information about the current
- board.
+global_data
- Contains the global-data structure, pointed to by ``gd``. This includes
- various pointers, values and flags which control U-Boot.
+devicetree
- Contains the flatted devicetree blob (FDT) being used by U-Boot to configure
- itself and its devices.
+bootstage
- Contains the bootstage records, which keep track of boot time as U-Boot
- executes. The size of this is determined by
- ``CONFIG_BOOTSTAGE_RECORD_COUNT``, with each record taking approximately
- 32 bytes.
+bloblist
- Contains the bloblist, which is a list of tables and other data created by
- U-Boot while executed. The size of this is determined by
- ``CONFIG_BLOBLIST_SIZE``.
+stack
- Contains U-Boot's stack, growing downwards from the top. The nominal size of
- this region is set by ``CONFIG_STACK_SIZE`` but there is no actual limit
- enforced, so the stack can grow behind that. Images should be loaded lower
- in memory to avoid any conflict.
+free
- Free memory, which is available for loading images. The base address of
- this is ``gd->ram_base`` which is generally set by ``CFG_SYS_SDRAM_BASE``.
+Example +-------
+::
- => memmap
- Region Base Size End Gap
- video f000000 1000000 10000000
- code ec3a000 3c5d28 efffd28 2d8
- malloc 8c38000 6002000 ec3a000 0
- board_info 8c37f90 68 8c37ff8 8
- global_data 8c37d80 208 8c37f88 8
- devicetree 8c33000 4d7d 8c37d7d 3
- bootstage 8c32c20 3c8 8c32fe8 18
- bloblist 8c32000 400 8c32400 820
- stack 7c31ff0 1000000 8c31ff0 10
- free 0 7c31ff0 7c31ff0 0
+Return value +------------
+The return value $? is always 0 (true). diff --git a/doc/usage/index.rst b/doc/usage/index.rst index 70563374899..dd2b5807a4f 100644 --- a/doc/usage/index.rst +++ b/doc/usage/index.rst @@ -83,6 +83,7 @@ Shell commands cmd/loads cmd/loadx cmd/loady
- cmd/memmap cmd/mbr cmd/md cmd/mmc
diff --git a/test/cmd/Makefile b/test/cmd/Makefile index 8f2134998ad..3f6ae59f3d4 100644 --- a/test/cmd/Makefile +++ b/test/cmd/Makefile @@ -18,8 +18,9 @@ obj-$(CONFIG_CMD_FDT) += fdt.o obj-$(CONFIG_CONSOLE_TRUETYPE) += font.o obj-$(CONFIG_CMD_HISTORY) += history.o obj-$(CONFIG_CMD_LOADM) += loadm.o -obj-$(CONFIG_CMD_MEM_SEARCH) += mem_search.o +obj-$(CONFIG_CMD_MEMMAP) += memmap.o obj-$(CONFIG_CMD_MEMORY) += mem_copy.o +obj-$(CONFIG_CMD_MEM_SEARCH) += mem_search.o ifdef CONFIG_CMD_PCI obj-$(CONFIG_CMD_PCI_MPS) += pci_mps.o endif diff --git a/test/cmd/memmap.c b/test/cmd/memmap.c new file mode 100644 index 00000000000..f12d7174838 --- /dev/null +++ b/test/cmd/memmap.c @@ -0,0 +1,35 @@ +// SPDX-License-Identifier: GPL-2.0+ +/*
- Test for 'memmap' command
- Copyright 2024 Google LLC
- Written by Simon Glass sjg@chromium.org
- */
+#include <dm/test.h> +#include <test/cmd.h> +#include <test/ut.h>
+/* Test 'memmap' command */ +static int cmd_test_memmap(struct unit_test_state *uts) +{
ut_assertok(run_command("memmap", 0));
ut_assert_nextline("Region Base Size End Gap");
ut_assert_nextlinen("-");
/* For now we don't worry about checking the values */
ut_assert_nextlinen("video");
ut_assert_nextlinen("code");
ut_assert_nextlinen("malloc");
ut_assert_nextlinen("board_info");
ut_assert_nextlinen("global_data");
ut_assert_nextlinen("devicetree");
ut_assert_nextlinen("bootstage");
ut_assert_nextlinen("bloblist");
ut_assert_nextlinen("stack");
ut_assert_nextlinen("free");
ut_assert_console_end();
return 0;
+}
+CMD_TEST(cmd_test_memmap, UTF_CONSOLE);
2.43.0

Hi Ilias,
On Wed, 9 Oct 2024 at 04:41, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi Simon,
We already have a mem info command, which is pretty useless. Can't we reuse that ?
I am not too keen on using that as 'info' is pretty vague. We could perhaps create a 'mem' command with 'info' as one subcommand and 'map' as another?
[..]
Regards, Simon

On Wed, Oct 09, 2024 at 03:14:25PM -0600, Simon Glass wrote:
Hi Ilias,
On Wed, 9 Oct 2024 at 04:41, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi Simon,
We already have a mem info command, which is pretty useless. Can't we reuse that ?
I am not too keen on using that as 'info' is pretty vague. We could perhaps create a 'mem' command with 'info' as one subcommand and 'map' as another?
Are we talking about "meminfo" which literally only prints gd->ram_size? If so, I don't think it's worth worrying about enhancing that.

On Thu, 10 Oct 2024 at 01:39, Tom Rini trini@konsulko.com wrote:
On Wed, Oct 09, 2024 at 03:14:25PM -0600, Simon Glass wrote:
Hi Ilias,
On Wed, 9 Oct 2024 at 04:41, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi Simon,
We already have a mem info command, which is pretty useless. Can't we reuse that ?
I am not too keen on using that as 'info' is pretty vague. We could perhaps create a 'mem' command with 'info' as one subcommand and 'map' as another?
Are we talking about "meminfo" which literally only prints gd->ram_size? If so, I don't think it's worth worrying about enhancing that.
Yes, that's the one
Thanks /Ilias
-- Tom

Hi,
On Thu, 10 Oct 2024 at 06:02, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
On Thu, 10 Oct 2024 at 01:39, Tom Rini trini@konsulko.com wrote:
On Wed, Oct 09, 2024 at 03:14:25PM -0600, Simon Glass wrote:
Hi Ilias,
On Wed, 9 Oct 2024 at 04:41, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi Simon,
We already have a mem info command, which is pretty useless. Can't we reuse that ?
I am not too keen on using that as 'info' is pretty vague. We could perhaps create a 'mem' command with 'info' as one subcommand and 'map' as another?
Are we talking about "meminfo" which literally only prints gd->ram_size? If so, I don't think it's worth worrying about enhancing that.
Yes, that's the one
So, you mean to just delete that command and make it show the memory map instead? Or show the memory size at the top, before the memory map?
Regards, Simon

Hi Simon,
On Thu, 10 Oct 2024 at 18:10, Simon Glass sjg@chromium.org wrote:
Hi,
On Thu, 10 Oct 2024 at 06:02, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
On Thu, 10 Oct 2024 at 01:39, Tom Rini trini@konsulko.com wrote:
On Wed, Oct 09, 2024 at 03:14:25PM -0600, Simon Glass wrote:
Hi Ilias,
On Wed, 9 Oct 2024 at 04:41, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi Simon,
We already have a mem info command, which is pretty useless. Can't we reuse that ?
I am not too keen on using that as 'info' is pretty vague. We could perhaps create a 'mem' command with 'info' as one subcommand and 'map' as another?
Are we talking about "meminfo" which literally only prints gd->ram_size? If so, I don't think it's worth worrying about enhancing that.
Yes, that's the one
So, you mean to just delete that command and make it show the memory map instead? Or show the memory size at the top, before the memory map?
I meant the latter, but if you and Tom agree that we should leave it as is, I don't mind adding a new command. I assume that the list above is non exhaustive, so in the future we could expand it with lmb reservations etc?
Thanks /Ilias
Regards, Simon

Hi Ilias,
On Thu, 10 Oct 2024 at 09:27, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi Simon,
On Thu, 10 Oct 2024 at 18:10, Simon Glass sjg@chromium.org wrote:
Hi,
On Thu, 10 Oct 2024 at 06:02, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
On Thu, 10 Oct 2024 at 01:39, Tom Rini trini@konsulko.com wrote:
On Wed, Oct 09, 2024 at 03:14:25PM -0600, Simon Glass wrote:
Hi Ilias,
On Wed, 9 Oct 2024 at 04:41, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi Simon,
We already have a mem info command, which is pretty useless. Can't we reuse that ?
I am not too keen on using that as 'info' is pretty vague. We could perhaps create a 'mem' command with 'info' as one subcommand and 'map' as another?
Are we talking about "meminfo" which literally only prints gd->ram_size? If so, I don't think it's worth worrying about enhancing that.
Yes, that's the one
So, you mean to just delete that command and make it show the memory map instead? Or show the memory size at the top, before the memory map?
I meant the latter, but if you and Tom agree that we should leave it as is, I don't mind adding a new command. I assume that the list above is non exhaustive, so in the future we could expand it with lmb reservations etc?
I sent v2 with that done. The lmb reservations aren't that useful as there are no names attached.
Regards, Simon

On Mon, Oct 14, 2024 at 01:13:25PM -0600, Simon Glass wrote:
Hi Ilias,
On Thu, 10 Oct 2024 at 09:27, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi Simon,
On Thu, 10 Oct 2024 at 18:10, Simon Glass sjg@chromium.org wrote:
Hi,
On Thu, 10 Oct 2024 at 06:02, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
On Thu, 10 Oct 2024 at 01:39, Tom Rini trini@konsulko.com wrote:
On Wed, Oct 09, 2024 at 03:14:25PM -0600, Simon Glass wrote:
Hi Ilias,
On Wed, 9 Oct 2024 at 04:41, Ilias Apalodimas ilias.apalodimas@linaro.org wrote: > > Hi Simon, > > We already have a mem info command, which is pretty useless. Can't we > reuse that ?
I am not too keen on using that as 'info' is pretty vague. We could perhaps create a 'mem' command with 'info' as one subcommand and 'map' as another?
Are we talking about "meminfo" which literally only prints gd->ram_size? If so, I don't think it's worth worrying about enhancing that.
Yes, that's the one
So, you mean to just delete that command and make it show the memory map instead? Or show the memory size at the top, before the memory map?
I meant the latter, but if you and Tom agree that we should leave it as is, I don't mind adding a new command. I assume that the list above is non exhaustive, so in the future we could expand it with lmb reservations etc?
I sent v2 with that done. The lmb reservations aren't that useful as there are no names attached.
I disagree with names being needed to be useful in this dump.

On Tue, 15 Oct 2024 at 00:07, Tom Rini trini@konsulko.com wrote:
On Mon, Oct 14, 2024 at 01:13:25PM -0600, Simon Glass wrote:
Hi Ilias,
On Thu, 10 Oct 2024 at 09:27, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi Simon,
On Thu, 10 Oct 2024 at 18:10, Simon Glass sjg@chromium.org wrote:
Hi,
On Thu, 10 Oct 2024 at 06:02, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
On Thu, 10 Oct 2024 at 01:39, Tom Rini trini@konsulko.com wrote:
On Wed, Oct 09, 2024 at 03:14:25PM -0600, Simon Glass wrote: > Hi Ilias, > > On Wed, 9 Oct 2024 at 04:41, Ilias Apalodimas > ilias.apalodimas@linaro.org wrote: > > > > Hi Simon, > > > > We already have a mem info command, which is pretty useless. Can't we > > reuse that ? > > I am not too keen on using that as 'info' is pretty vague. We could > perhaps create a 'mem' command with 'info' as one subcommand and 'map' > as another?
Are we talking about "meminfo" which literally only prints gd->ram_size? If so, I don't think it's worth worrying about enhancing that.
Yes, that's the one
So, you mean to just delete that command and make it show the memory map instead? Or show the memory size at the top, before the memory map?
I meant the latter, but if you and Tom agree that we should leave it as is, I don't mind adding a new command. I assume that the list above is non exhaustive, so in the future we could expand it with lmb reservations etc?
I sent v2 with that done. The lmb reservations aren't that useful as there are no names attached.
I disagree with names being needed to be useful in this dump.
Yes, +1 here.
-- Tom

Hi Tom,
On Mon, 14 Oct 2024 at 15:07, Tom Rini trini@konsulko.com wrote:
On Mon, Oct 14, 2024 at 01:13:25PM -0600, Simon Glass wrote:
Hi Ilias,
On Thu, 10 Oct 2024 at 09:27, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi Simon,
On Thu, 10 Oct 2024 at 18:10, Simon Glass sjg@chromium.org wrote:
Hi,
On Thu, 10 Oct 2024 at 06:02, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
On Thu, 10 Oct 2024 at 01:39, Tom Rini trini@konsulko.com wrote:
On Wed, Oct 09, 2024 at 03:14:25PM -0600, Simon Glass wrote: > Hi Ilias, > > On Wed, 9 Oct 2024 at 04:41, Ilias Apalodimas > ilias.apalodimas@linaro.org wrote: > > > > Hi Simon, > > > > We already have a mem info command, which is pretty useless. Can't we > > reuse that ? > > I am not too keen on using that as 'info' is pretty vague. We could > perhaps create a 'mem' command with 'info' as one subcommand and 'map' > as another?
Are we talking about "meminfo" which literally only prints gd->ram_size? If so, I don't think it's worth worrying about enhancing that.
Yes, that's the one
So, you mean to just delete that command and make it show the memory map instead? Or show the memory size at the top, before the memory map?
I meant the latter, but if you and Tom agree that we should leave it as is, I don't mind adding a new command. I assume that the list above is non exhaustive, so in the future we could expand it with lmb reservations etc?
I sent v2 with that done. The lmb reservations aren't that useful as there are no names attached.
I disagree with names being needed to be useful in this dump.
I'd like to show where the kernel, FDT and ramdisk are, with actual names for them.
Regards, Simon
-- Tom

On Tue, Oct 15, 2024 at 06:49:00AM -0600, Simon Glass wrote:
Hi Tom,
On Mon, 14 Oct 2024 at 15:07, Tom Rini trini@konsulko.com wrote:
On Mon, Oct 14, 2024 at 01:13:25PM -0600, Simon Glass wrote:
Hi Ilias,
On Thu, 10 Oct 2024 at 09:27, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi Simon,
On Thu, 10 Oct 2024 at 18:10, Simon Glass sjg@chromium.org wrote:
Hi,
On Thu, 10 Oct 2024 at 06:02, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
On Thu, 10 Oct 2024 at 01:39, Tom Rini trini@konsulko.com wrote: > > On Wed, Oct 09, 2024 at 03:14:25PM -0600, Simon Glass wrote: > > Hi Ilias, > > > > On Wed, 9 Oct 2024 at 04:41, Ilias Apalodimas > > ilias.apalodimas@linaro.org wrote: > > > > > > Hi Simon, > > > > > > We already have a mem info command, which is pretty useless. Can't we > > > reuse that ? > > > > I am not too keen on using that as 'info' is pretty vague. We could > > perhaps create a 'mem' command with 'info' as one subcommand and 'map' > > as another? > > Are we talking about "meminfo" which literally only prints gd->ram_size? > If so, I don't think it's worth worrying about enhancing that.
Yes, that's the one
So, you mean to just delete that command and make it show the memory map instead? Or show the memory size at the top, before the memory map?
I meant the latter, but if you and Tom agree that we should leave it as is, I don't mind adding a new command. I assume that the list above is non exhaustive, so in the future we could expand it with lmb reservations etc?
I sent v2 with that done. The lmb reservations aren't that useful as there are no names attached.
I disagree with names being needed to be useful in this dump.
I'd like to show where the kernel, FDT and ramdisk are, with actual names for them.
That's fine, but I don't see what that has to do with showing the LMBs that we know of as a starting point. Again, an LMB is not an image.
participants (3)
-
Ilias Apalodimas
-
Simon Glass
-
Tom Rini