Re: [RFC PATCH 26/31] test: lmb: run lmb tests only manually

2024-06-07 Thread Heinrich Schuchardt

On 6/7/24 20:52, Sughosh Ganu wrote:

The LMB code has been changed so that the memory reservations and
allocations are now persistent and global. With this change, the
design of the LMB tests needs to be changed accordingly. For now, mark
the LMB tests to be run only manually. The tests won't be run as part
of the unit test suite, and thus would not interfere with the running
of the rest of the tests.


We should run important tests in the CI.

You could trigger the 'manual' test from a Python test and reboot the
system to get into an initial state.

Best regards

Heinrich



Signed-off-by: Sughosh Ganu 
---
  test/lib/lmb.c | 49 -
  1 file changed, 24 insertions(+), 25 deletions(-)

diff --git a/test/lib/lmb.c b/test/lib/lmb.c
index 67a6be5bc3..813f7e3100 100644
--- a/test/lib/lmb.c
+++ b/test/lib/lmb.c
@@ -195,7 +195,7 @@ static int test_multi_alloc_512mb_x2(struct unit_test_state 
*uts,
  }

  /* Create a memory region with one reserved region and allocate */
-static int lib_test_lmb_simple(struct unit_test_state *uts)
+static int lib_test_lmb_simple_norun(struct unit_test_state *uts)
  {
int ret;

@@ -207,10 +207,10 @@ static int lib_test_lmb_simple(struct unit_test_state 
*uts)
/* simulate 512 MiB RAM beginning at 1.5GiB */
return test_multi_alloc_512mb(uts, 0xE000);
  }
-LIB_TEST(lib_test_lmb_simple, 0);
+LIB_TEST(lib_test_lmb_simple_norun, UT_TESTF_MANUAL);

  /* Create two memory regions with one reserved region and allocate */
-static int lib_test_lmb_simple_x2(struct unit_test_state *uts)
+static int lib_test_lmb_simple_x2_norun(struct unit_test_state *uts)
  {
int ret;

@@ -222,7 +222,7 @@ static int lib_test_lmb_simple_x2(struct unit_test_state 
*uts)
/* simulate 512 MiB RAM beginning at 3.5GiB and 1 GiB */
return test_multi_alloc_512mb_x2(uts, 0xE000, 0x4000);
  }
-LIB_TEST(lib_test_lmb_simple_x2, 0);
+LIB_TEST(lib_test_lmb_simple_x2_norun, UT_TESTF_MANUAL);

  /* Simulate 512 MiB RAM, allocate some blocks that fit/don't fit */
  static int test_bigblock(struct unit_test_state *uts, const phys_addr_t ram)
@@ -275,7 +275,7 @@ static int test_bigblock(struct unit_test_state *uts, const 
phys_addr_t ram)
return 0;
  }

-static int lib_test_lmb_big(struct unit_test_state *uts)
+static int lib_test_lmb_big_norun(struct unit_test_state *uts)
  {
int ret;

@@ -287,7 +287,7 @@ static int lib_test_lmb_big(struct unit_test_state *uts)
/* simulate 512 MiB RAM beginning at 1.5GiB */
return test_bigblock(uts, 0xE000);
  }
-LIB_TEST(lib_test_lmb_big, 0);
+LIB_TEST(lib_test_lmb_big_norun, UT_TESTF_MANUAL);

  /* Simulate 512 MiB RAM, allocate a block without previous reservation */
  static int test_noreserved(struct unit_test_state *uts, const phys_addr_t ram,
@@ -348,7 +348,7 @@ static int test_noreserved(struct unit_test_state *uts, 
const phys_addr_t ram,
return 0;
  }

-static int lib_test_lmb_noreserved(struct unit_test_state *uts)
+static int lib_test_lmb_noreserved_norun(struct unit_test_state *uts)
  {
int ret;

@@ -360,10 +360,9 @@ static int lib_test_lmb_noreserved(struct unit_test_state 
*uts)
/* simulate 512 MiB RAM beginning at 1.5GiB */
return test_noreserved(uts, 0xE000, 4, 1);
  }
+LIB_TEST(lib_test_lmb_noreserved_norun, UT_TESTF_MANUAL);

-LIB_TEST(lib_test_lmb_noreserved, 0);
-
-static int lib_test_lmb_unaligned_size(struct unit_test_state *uts)
+static int lib_test_lmb_unaligned_size_norun(struct unit_test_state *uts)
  {
int ret;

@@ -375,13 +374,13 @@ static int lib_test_lmb_unaligned_size(struct 
unit_test_state *uts)
/* simulate 512 MiB RAM beginning at 1.5GiB */
return test_noreserved(uts, 0xE000, 5, 8);
  }
-LIB_TEST(lib_test_lmb_unaligned_size, 0);
+LIB_TEST(lib_test_lmb_unaligned_size_norun, UT_TESTF_MANUAL);

  /*
   * Simulate a RAM that starts at 0 and allocate down to address 0, which must
   * fail as '0' means failure for the lmb_alloc functions.
   */
-static int lib_test_lmb_at_0(struct unit_test_state *uts)
+static int lib_test_lmb_at_0_norun(struct unit_test_state *uts)
  {
const phys_addr_t ram = 0;
const phys_size_t ram_size = 0x2000;
@@ -417,9 +416,9 @@ static int lib_test_lmb_at_0(struct unit_test_state *uts)

return 0;
  }
-LIB_TEST(lib_test_lmb_at_0, 0);
+LIB_TEST(lib_test_lmb_at_0_norun, UT_TESTF_MANUAL);

-static int lib_test_lmb_overlapping_add(struct unit_test_state *uts)
+static int lib_test_lmb_overlapping_add_norun(struct unit_test_state *uts)
  {
const phys_addr_t ram = 0x4000;
const phys_size_t ram_size = 0x2000;
@@ -433,10 +432,10 @@ static int lib_test_lmb_overlapping_add(struct 
unit_test_state *uts)

return 0;
  }
-LIB_TEST(lib_test_lmb_overlapping_add, 0);
+LIB_TEST(lib_test_lmb_overlapping_add_norun, UT_TESTF_MANUAL);

  /* Check that calling lmb_reserve with overlapping regions 

Re: [RFC PATCH 11/31] lib: Kconfig: add a config symbol for getting memory map updates

2024-06-07 Thread Heinrich Schuchardt

On 6/8/24 05:53, Heinrich Schuchardt wrote:



Am 7. Juni 2024 20:52:20 MESZ schrieb Sughosh Ganu :

Add a Kconfig symbol to enable getting updates on any memory map
changes that might be done by some other module. This notification
mechanism can then be used to have a synchronous view of allocated and
free memory.

Signed-off-by: Sughosh Ganu 
---
lib/Kconfig | 9 +
1 file changed, 9 insertions(+)

diff --git a/lib/Kconfig b/lib/Kconfig
index 189e6eb31a..9ea02ae006 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -74,6 +74,15 @@ config HAVE_PRIVATE_LIBGCC
config LIB_UUID
bool

+config MEM_MAP_UPDATE_NOTIFY
+   bool "Get notified of any changes to the memory map"


Looking at later patches it seems you are sending memory map events from
different memory maps: LMB and EFI.

%s/to the memory map/to a memory map/



To the "LMB memory map"?


+   default y if EVENT && LMB && EFI_LOADER


I am missing 'depends on EVENT && LMB' here. This should allow to simplify the 
'default' statement. But why not use select?


Sending messaging makes only sense if two memory management systems are
present. How about:

depends on EVENT && LMB && EFI_LOADER
default y



Best regards

Heinrich




+   help
+ Enable this option to get notification on any changes to the
+ memory that is allocated or freed. This will allow different
+ modules that allocate memory to have a synchronous view of available
+ and allocated memory.


Mentioning LMB and EFI here would be helpful:

help
  U-Boot manages memory allocation in multiple modules: LMB and EFI.
  To keep them synchronized memory change messages are used.
  Enable this symbol to ensure synchronization.

Best regards

Heinrich


+
config RANDOM_UUID
bool "GPT Random UUID generation"
select LIB_UUID




[PATCH 1/1] dm: typo prbing

2024-06-07 Thread Heinrich Schuchardt
%s/prbing/probing/

Signed-off-by: Heinrich Schuchardt 
---
 drivers/core/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/core/Kconfig b/drivers/core/Kconfig
index 1081d61fcf0..754649f091e 100644
--- a/drivers/core/Kconfig
+++ b/drivers/core/Kconfig
@@ -113,7 +113,7 @@ config DM_EVENT
select EVENT
help
  This enables support for generating events related to driver model
- operations, such as prbing or removing a device. Subsystems can
+ operations, such as probing or removing a device. Subsystems can
  register a 'spy' function that is called when the event occurs. Such
  subsystems must select this option.
 
-- 
2.43.0



Re: [RFC PATCH 28/31] cmd: bdinfo: only dump the current LMB memory

2024-06-07 Thread Heinrich Schuchardt



Am 7. Juni 2024 20:52:37 MESZ schrieb Sughosh Ganu :
>The LMB memory map is now persistent and global. There is therefore no
>need to add memory to the LMB memory map as part of the bdinfo
>command. Only dump the current available and reserved memory as part
>of the bdinfo command.

Would it make sense to move printing lmb memory to a separate command instead?

Best regards

Heinrich

>
>Signed-off-by: Sughosh Ganu 
>---
> cmd/bdinfo.c | 1 -
> 1 file changed, 1 deletion(-)
>
>diff --git a/cmd/bdinfo.c b/cmd/bdinfo.c
>index fc408e9820..0f343203ef 100644
>--- a/cmd/bdinfo.c
>+++ b/cmd/bdinfo.c
>@@ -163,7 +163,6 @@ static int bdinfo_print_all(struct bd_info *bd)
>   bdinfo_print_num_l("multi_dtb_fit", (ulong)gd->multi_dtb_fit);
> #endif
>   if (IS_ENABLED(CONFIG_LMB) && gd->fdt_blob) {
>-  lmb_add_memory(gd->bd);
>   lmb_dump_all_force();
>   if (IS_ENABLED(CONFIG_OF_REAL))
>   printf("devicetree  = %s\n", fdtdec_get_srcname());


Re: [RFC PATCH 11/31] lib: Kconfig: add a config symbol for getting memory map updates

2024-06-07 Thread Heinrich Schuchardt



Am 7. Juni 2024 20:52:20 MESZ schrieb Sughosh Ganu :
>Add a Kconfig symbol to enable getting updates on any memory map
>changes that might be done by some other module. This notification
>mechanism can then be used to have a synchronous view of allocated and
>free memory.
>
>Signed-off-by: Sughosh Ganu 
>---
> lib/Kconfig | 9 +
> 1 file changed, 9 insertions(+)
>
>diff --git a/lib/Kconfig b/lib/Kconfig
>index 189e6eb31a..9ea02ae006 100644
>--- a/lib/Kconfig
>+++ b/lib/Kconfig
>@@ -74,6 +74,15 @@ config HAVE_PRIVATE_LIBGCC
> config LIB_UUID
>   bool
> 
>+config MEM_MAP_UPDATE_NOTIFY
>+  bool "Get notified of any changes to the memory map"

To the "LMB memory map"?

>+  default y if EVENT && LMB && EFI_LOADER

I am missing 'depends on EVENT && LMB' here. This should allow to simplify the 
'default' statement. But why not use select?

Best regards

Heinrich



>+  help
>+Enable this option to get notification on any changes to the
>+memory that is allocated or freed. This will allow different
>+modules that allocate memory to have a synchronous view of available
>+and allocated memory.
>+
> config RANDOM_UUID
>   bool "GPT Random UUID generation"
>   select LIB_UUID


Re: [RFC PATCH 30/31] temp: cmd: efi_mem: add a command to test efi alloc/free

2024-06-07 Thread Heinrich Schuchardt



Am 7. Juni 2024 20:52:39 MESZ schrieb Sughosh Ganu :
>Not for committing.

Best put "DON'T MERGE" into the title to avoid mishaps in future versions.

In the final series we should have unit test covering all relevant aspects of 
the memory system.

Best regards

Heinrich

>
>Signed-off-by: Sughosh Ganu 
>---
> cmd/Makefile |   1 +
> cmd/efi_memory.c | 155 +++
> 2 files changed, 156 insertions(+)
> create mode 100644 cmd/efi_memory.c
>
>diff --git a/cmd/Makefile b/cmd/Makefile
>index 87133cc27a..35fcc4af5a 100644
>--- a/cmd/Makefile
>+++ b/cmd/Makefile
>@@ -10,6 +10,7 @@ obj-$(CONFIG_CMD_BOOTM) += bootm.o
> obj-y += help.o
> obj-y += panic.o
> obj-y += version.o
>+obj-y += efi_memory.o
> 
> # command
> obj-$(CONFIG_CMD_ARMFFA) += armffa.o
>diff --git a/cmd/efi_memory.c b/cmd/efi_memory.c
>new file mode 100644
>index 00..52ddcb7146
>--- /dev/null
>+++ b/cmd/efi_memory.c
>@@ -0,0 +1,155 @@
>+// SPDX-License-Identifier: GPL-2.0+
>+/*
>+ *  Allocate and Free EFI memory
>+ *
>+ *  Copyright (c) 2024 Linaro Limited
>+ */
>+
>+#include 
>+#include 
>+#include 
>+#include 
>+
>+#include 
>+
>+static int do_efi_mem_free(struct cmd_tbl *cmdtp, int flag, int argc,
>+ char * const argv[])
>+{
>+  uint64_t addr = 0, size = 0;
>+  efi_uintn_t pages;
>+  efi_status_t status;
>+
>+  if (argc != 3)
>+  return CMD_RET_USAGE;
>+
>+  argc--; argv++;
>+
>+  size = simple_strtoul(argv[0], NULL, 16);
>+  if (!size) {
>+  printf("Enter valid size for free in Hex\n");
>+  return CMD_RET_USAGE;
>+  }
>+
>+  
>+  addr = simple_strtoul(argv[1], NULL, 16);
>+  if (!addr) {
>+  printf("Enter a valid address in Hex\n");
>+  return CMD_RET_USAGE;
>+  }
>+
>+  pages = efi_size_in_pages(size + (addr & EFI_PAGE_MASK));
>+
>+  status = efi_free_pages(addr, pages);
>+  if (status != EFI_SUCCESS) {
>+  printf("Unable to free memory, error (%#lx)\n", status);
>+  return CMD_RET_FAILURE;
>+  }
>+
>+  return CMD_RET_SUCCESS;
>+}
>+
>+static int do_efi_mem_alloc(struct cmd_tbl *cmdtp, int flag, int argc,
>+  char * const argv[])
>+{
>+  enum efi_allocate_type type;
>+  uint64_t addr = 0, size = 0;
>+  efi_uintn_t pages;
>+  efi_status_t status;
>+  bool max = false;
>+
>+  if (argc < 2)
>+  return CMD_RET_USAGE;
>+
>+  argc--; argv++;
>+
>+  if (!strcmp("max", argv[0])) {
>+  if (argc != 3)
>+  return CMD_RET_USAGE;
>+
>+  max = true;
>+  argv++;
>+  argc--;
>+  }
>+
>+  size = simple_strtoul(argv[0], NULL, 16);
>+  if (!size) {
>+  printf("Enter valid size for allocation in Hex\n");
>+  return CMD_RET_USAGE;
>+  }
>+
>+  if (max || argc == 2) {
>+  addr = simple_strtoul(argv[1], NULL, 16);
>+  if (!addr) {
>+  printf("Enter a valid address in Hex\n");
>+  return CMD_RET_USAGE;
>+  }
>+  }
>+
>+  if (max)
>+  type = EFI_ALLOCATE_MAX_ADDRESS;
>+  else if (addr)
>+  type = EFI_ALLOCATE_ADDRESS;
>+  else
>+  type = EFI_ALLOCATE_ANY_PAGES;
>+
>+  pages = efi_size_in_pages(size + (addr & EFI_PAGE_MASK));
>+  status = efi_allocate_pages(type, EFI_BOOT_SERVICES_DATA, pages,
>+  );
>+  if (status != EFI_SUCCESS) {
>+  printf("efi_allocate_pages failed %lx\n", status);
>+  return CMD_RET_FAILURE;
>+  } else {
>+  printf("Address returned %#llx\n", addr);
>+  }
>+
>+  return CMD_RET_SUCCESS;
>+}
>+
>+static struct cmd_tbl cmd_efi_mem_sub[] = {
>+  U_BOOT_CMD_MKENT(alloc, 3, 0, do_efi_mem_alloc,
>+  "", ""),
>+  U_BOOT_CMD_MKENT(free, 2, 0, do_efi_mem_free,
>+  "", ""),
>+};
>+
>+static int do_efi_mem(struct cmd_tbl *cmdtp, int flag, int argc,
>+char *const argv[])
>+{
>+  struct cmd_tbl *cp;
>+  efi_status_t r;
>+
>+  if (argc < 3)
>+  return CMD_RET_USAGE;
>+
>+  argc--; argv++;
>+
>+  /* Initialize UEFI subsystem */
>+  r = efi_init_obj_list();
>+  if (r != EFI_SUCCESS) {
>+  printf("Error: Cannot initialize UEFI sub-system, r = %lu\n",
>+ r & ~EFI_ERROR_MASK);
>+  return CMD_RET_FAILURE;
>+  }
>+
>+  cp = find_cmd_tbl(argv[0], cmd_efi_mem_sub,
>+ARRAY_SIZE(cmd_efi_mem_sub));
>+  if (!cp)
>+  return CMD_RET_USAGE;
>+
>+  return cp->cmd(cmdtp, flag, argc, argv);
>+}
>+
>+U_BOOT_LONGHELP(efi_mem,
>+  "Functions to allocate and free memory\n"
>+  "\n"
>+  "efi_mem alloc  [addr]\n"
>+  "efi_mem alloc max  \n"
>+  "efi_mem free  \n"

Re: [RFC PATCH 31/31] temp: cmd: efi: add a command to dump EFI memory map

2024-06-07 Thread Heinrich Schuchardt



Am 7. Juni 2024 20:52:40 MESZ schrieb Sughosh Ganu :
>Add a command to dump the EFI memory map.

What are you missing in 'efidebug memmap'?

Best regards

Heinrich

>
>Not for committing.
>
>Signed-off-by: Sughosh Ganu 
>---
> cmd/Makefile|  1 +
> cmd/efi_map_dump.c  | 28 
> include/efi_loader.h|  2 ++
> lib/efi_loader/efi_memory.c | 32 
> 4 files changed, 63 insertions(+)
> create mode 100644 cmd/efi_map_dump.c
>
>diff --git a/cmd/Makefile b/cmd/Makefile
>index 35fcc4af5a..315046def6 100644
>--- a/cmd/Makefile
>+++ b/cmd/Makefile
>@@ -11,6 +11,7 @@ obj-y += help.o
> obj-y += panic.o
> obj-y += version.o
> obj-y += efi_memory.o
>+obj-y += efi_map_dump.o
> 
> # command
> obj-$(CONFIG_CMD_ARMFFA) += armffa.o
>diff --git a/cmd/efi_map_dump.c b/cmd/efi_map_dump.c
>new file mode 100644
>index 00..f2a5932767
>--- /dev/null
>+++ b/cmd/efi_map_dump.c
>@@ -0,0 +1,28 @@
>+// SPDX-License-Identifier: GPL-2.0+
>+/*
>+ *  Allocate and Free EFI memory
>+ *
>+ *  Copyright (c) 2024 Linaro Limited
>+ */
>+
>+#include 
>+#include 
>+
>+static int do_efi_map_dump(struct cmd_tbl *cmdtp, int flag, int argc,
>+ char *const argv[])
>+{
>+//printf("%s: argc => %d\n", __func__, argc);
>+
>+  if (argc != 1)
>+  return CMD_RET_USAGE;
>+
>+  dump_efi_memory_map();
>+
>+  return CMD_RET_SUCCESS;
>+}
>+
>+U_BOOT_CMD(
>+  efi_map_dump, 1, 0, do_efi_map_dump,
>+  "Dump the EFI memory map",
>+  ""
>+);
>diff --git a/include/efi_loader.h b/include/efi_loader.h
>index 9600941aa3..40f894f182 100644
>--- a/include/efi_loader.h
>+++ b/include/efi_loader.h
>@@ -791,6 +791,8 @@ efi_status_t efi_get_memory_map(efi_uintn_t 
>*memory_map_size,
>   uint32_t *descriptor_version);
> /* Adds a range into the EFI memory map */
> efi_status_t efi_add_memory_map(u64 start, u64 size, int memory_type);
>+/* Dump the contents of the EFI memory map */
>+void dump_efi_memory_map(void);
> /* Adds a conventional range into the EFI memory map */
> efi_status_t efi_add_conventional_memory_map(u64 ram_start, u64 ram_end,
>u64 ram_top);
>diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
>index 93244161b0..7ab1b86140 100644
>--- a/lib/efi_loader/efi_memory.c
>+++ b/lib/efi_loader/efi_memory.c
>@@ -47,6 +47,8 @@ static LIST_HEAD(efi_mem);
> void *efi_bounce_buffer;
> #endif
> 
>+static uint64_t desc_get_end(struct efi_mem_desc *desc);
>+
> /**
>  * struct efi_pool_allocation - memory block allocated from pool
>  *
>@@ -118,6 +120,36 @@ static int lmb_mem_map_update_sync(void *ctx, struct 
>event *event)
> EVENT_SPY_FULL(EVT_LMB_MAP_UPDATE, lmb_mem_map_update_sync);
> #endif /* MEM_MAP_UPDATE_NOTIFY */
> 
>+static void dump_efi_mem_desc(struct efi_mem_desc *desc)
>+{
>+  u64 end;
>+
>+  end = desc_get_end(desc);
>+
>+  printf("---\n");
>+  printf("Memory Range   [0x%llx - 0x%llx]\n",
>+ desc->physical_start, end);
>+  printf("Num Pages  [0x%llx]\n", desc->num_pages);
>+  printf("Memory Type[0x%x]\n", desc->type);
>+  printf("Attribute  [0x%llx]\n", desc->attribute);
>+  printf("---\n");
>+}
>+
>+void dump_efi_memory_map(void)
>+{
>+  struct list_head *lhandle;
>+
>+  list_for_each(lhandle, _mem) {
>+  struct efi_mem_list *lmem;
>+  struct efi_mem_desc *desc;
>+
>+  lmem = list_entry(lhandle, struct efi_mem_list, link);
>+  desc = >desc;
>+
>+  dump_efi_mem_desc(desc);
>+  }
>+}
>+
> /**
>  * checksum() - calculate checksum for memory allocated from pool
>  *


[PATCH] configs: k3: Enable capsule authentication

2024-06-07 Thread Jonathan Humphreys
Enable EFI capsule authentication and set the capsule public key
certificate file in the base TI K3 EFI Capsule config.

This will enable EFI capsule authentication on all boards that
include the base TI K3 EFI Capsule config file.

This patch is built upon the series enabling EFI capsule TI boards [0] as
well as using capsule certificates directly [1].

[0] https://lore.kernel.org/r/20240607223858.1971290-1-j-humphr...@ti.com
[1] https://lore.kernel.org/r/20240607225915.1985514-1-j-humphr...@ti.com

Signed-off-by: Jonathan Humphreys 
---
 configs/k3_efi_capsule.config | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/k3_efi_capsule.config b/configs/k3_efi_capsule.config
index e31cea37269..8f8f63f672e 100644
--- a/configs/k3_efi_capsule.config
+++ b/configs/k3_efi_capsule.config
@@ -1,2 +1,4 @@
 CONFIG_EFI_CAPSULE_ON_DISK=y
 CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
+CONFIG_EFI_CAPSULE_AUTHENTICATE=y
+CONFIG_EFI_CAPSULE_CRT_FILE="arch/arm/mach-k3/keys/custMpk.crt"
-- 
2.34.1



[PATCH] efi: capsule: Improve capsule update porting to new boards

2024-06-07 Thread Jonathan Humphreys
Add to the capsule update porting documentation that when capsule
authentication is enabled (via EFI_CAPSULE_AUTHENTICATE), a public key
certificate corresponding to the capsule signing key must be specified.

Also add a config (EFI_CAPSULE_BOARD_INSECURE) that is set by default and
causes a warning (info level) alerting a developer to consult this porting
section to ensure the capsule update capability is secure for the platform.
Once this section has been reviewed and confidence is established in the
security of the capsule update implementation for this board, deselecting
the EFI_CAPSULE_BOARD_INSECURE config will remove the warning.

This config is to balance the desire to provide a reference implementation
in upstream for capsule authentication but also provide some safeguards
to prevent developers from overlooking the need to properly secure their
implementation.

Signed-off-by: Jonathan Humphreys 
---
 doc/develop/uefi/uefi.rst| 30 +++---
 lib/efi_loader/Kconfig   | 13 +
 lib/efi_loader/efi_capsule.c |  5 +
 3 files changed, 41 insertions(+), 7 deletions(-)

diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
index 985956ab85c..1c98c6e4ab4 100644
--- a/doc/develop/uefi/uefi.rst
+++ b/doc/develop/uefi/uefi.rst
@@ -526,6 +526,7 @@ following command can be issued
   --guid c1b629f1-ce0e-4894-82bf-f0a38387e630 \
   optee.bin optee.capsule
 
+.. _Enabling Capsule Authentication:
 
 Enabling Capsule Authentication
 ***
@@ -631,17 +632,32 @@ where version.dtso looks like::
 The properties of image-type-id and image-index must match the value
 defined in the efi_fw_image array as image_type_id and image_index.
 
-Porting Capsule Updates to new boards
-*
+Porting Capsule Update to new boards
+
 
 It is important, when using a reference board as a starting point for a custom
 board, that certain steps are taken to properly support Capsule Updates.
 
-Capsule GUIDs need to be unique for each firmware and board. That is, if two
-firmwares are built from the same source but result in different binaries
-because they are built for different boards, they should have different GUIDs.
-Therefore it is important when creating support for a new board, new GUIDs are
-defined in the board's header file.  *DO NOT* reuse capsule GUIDs.
+Capsule GUIDs need to be unique for each firmware and board. That is, even
+if two firmwares are built from the same source but result in different
+binaries because they are built for different boards, they should have
+different GUIDs. Therefore it is important when creating support for a new
+board, new GUIDs are defined in the board's header file. *DO NOT* reuse
+capsule GUIDs.
+
+When capsule authentication is enabled (via EFI_CAPSULE_AUTHENTICATE), it
+is also very important to set the public key certificate corresponding to
+the capsule signing key. See :ref:`Enabling Capsule Authentication` for
+more information on signing capsules. *DO NOT* reuse the certificate file
+from the reference board, which usually would be based on the development
+board keys.
+
+By default, the EFI_CAPSULE_BOARD_INSECURE config is set to true and causes
+a warning (info level) alerting a developer to consult this section to
+ensure the capsule update capability is secure for the platform. Once this
+section has been reviewed and confidence is established in the security of
+the capsule update implementation for this board, deselecting
+EFI_CAPSULE_BOARD_INSECURE config will remove the warning.
 
 Executing the boot manager
 ~~
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index 23079a5709d..f4b1a20ee40 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -236,6 +236,19 @@ config EFI_CAPSULE_ON_DISK_EARLY
  executed as part of U-Boot initialisation so that they will
  surely take place whatever is set to distro_bootcmd.
 
+config EFI_CAPSULE_BOARD_INSECURE
+   bool "Permit insecure capsule-on-disk support"
+   depends on EFI_HAVE_CAPSULE_SUPPORT
+   default y
+   help
+ Permit insecure capsule update support and emit a warning (info level)
+ when applying capsule updates, indicating that the configuration is
+ insecure and including a link to the capsule update porting guide in
+ U-Boot docs. Disabling this option removes the warning. A developer
+ configuration doesn't need to be secure, but before making a product
+ from the configuration, the intent is to developers alert of steps 
that
+ must be taken.
+
 config EFI_CAPSULE_FIRMWARE
bool
 
diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
index 0937800e588..76ade2809d9 100644
--- a/lib/efi_loader/efi_capsule.c
+++ b/lib/efi_loader/efi_capsule.c
@@ -1329,6 +1329,11 @@ efi_status_t efi_launch_capsules(void)
   

Re: [PATCH] arm: mvebu: Enable bootstd and other modernization for Synology DS414 (Armada XP) board

2024-06-07 Thread Tony Dinh
Hi Phil,

On Fri, Jun 7, 2024 at 6:45 AM Phil Sutter  wrote:
>
> Hi Tony,
>
> On Thu, Jun 06, 2024 at 04:44:36PM -0700, Tony Dinh wrote:
> > - Switch to standard boot (in include/configs/ds414.h and
> > configs/ds414_defconfig)
> > - Implement board_late_init() to ensure successful enumeration
> > of USB3 devices
>
> Oh, this makes the rear USB3 ports usable? I had failed to get there
> when working on DS414 support.

Yes! There have been a lot of updates in the PCIe MVEBU area. So it
could have been a different reason why it did not work when you added
support for this board.

Still, without this board_late_init(), we would need to run "pci enum"
and then "usb start" or "usb reset" to bring up the USB3 ports. The
USB3 controller is on the PCIe bus, and MVEBU PCIe drivers don't
initialize everything when it comes up.

>
> > - Remove unnecessary misc_init_r(), since NET_RANDOM_ETHADDR is now
> > configured in
>
> So u-boot will assign random MAC addresses to the NICs instead of the
> real ones? Won't this potentially break PXE boot setups?

I did not see any problem using a random MAC address in my test using
bootstd. Is there a setup where this board MAC address must be known
when we boot with PXE? my impression is that only ipaddr and serverip
are needed, and the MAC address could be whatever we define for the
board.

>
> > - Remove unnecessary checkboard()
> > - Updated IDENT_STRING to indicate this u-boot supports both Synology
> > DS414 and DS214+ boards
> > - Add SYS_THUMB_BUILD to reduce binary size
> > - Add NET_RANDOM_ETHADDR
> > - Add CONFIG_LBA48 and CONFIG_SYS_64BIT_LBA to support >2TB HDD/SDD
> >
> > Signed-off-by: Tony Dinh 
> > ---
> >
> >  board/Synology/ds414/ds414.c | 15 +++
> >  configs/ds414_defconfig  | 20 ++
> >  include/configs/ds414.h  | 51 ++--
> >  3 files changed, 42 insertions(+), 44 deletions(-)
> >
> > diff --git a/board/Synology/ds414/ds414.c b/board/Synology/ds414/ds414.c
> > index abe6f9eb5e..f0b55fa095 100644
> > --- a/board/Synology/ds414/ds414.c
> > +++ b/board/Synology/ds414/ds414.c
> > @@ -181,18 +181,9 @@ int board_init(void)
> >   return 0;
> >  }
> >
> > -int misc_init_r(void)
> > +int board_late_init(void)
> >  {
> > - if (!env_get("ethaddr")) {
> > - puts("Incomplete environment, populating from SPI flash\n");
> > - do_syno_populate(0, NULL);
> > - }
> > - return 0;
> > -}
>
> This is useful for first boot of flashed vanilla u-boot. Can this be
> retained somehow?

We could, but with NET_RANDOM_ETHADDR configured in, this routine will
do nothing. Perhaps the fact that the envs will show CRC errors in the
1st boot should be an indicator that it needs to be populated?

With standard boot enabled in this patch, the default envs can be
scripted in /boot/boot.scr or /boot.scr on the rootfs disk storage, or
on some flash location, or on the network . So we don't even need the
full envs on SPI flash like we used to. It might still be useful but
not necessary.

>
> [...]
> > diff --git a/include/configs/ds414.h b/include/configs/ds414.h
> > index 9446acba79..bbefe632e0 100644
> > --- a/include/configs/ds414.h
> > +++ b/include/configs/ds414.h
> [...]
> > @@ -38,23 +34,38 @@
> >   * L2 cache thus cannot be used.
> >   */
> >
> > -/* SPL */
> > -/* Defines for SPL */
> > +/* Keep device tree and initrd in lower memory so the kernel can access 
> > them */
> > +#define RELOCATION_LIMITS_ENV_SETTINGS  \
> > + "fdt_high=0x1000\0" \
> > + "initrd_high=0x1000\0"
> > +
> > +/*
> > + * mv-common.h should be defined after CMD configs since it used them
> > + * to enable certain macros
> > + */
> > +#include "mv-common.h"
> > +
> > +#ifndef CONFIG_SPL_BUILD
> >
> > -/* Default Environment */
> > +#define KERNEL_ADDR_R__stringify(0x100)
> > +#define FDT_ADDR_R   __stringify(0x200)
> > +#define RAMDISK_ADDR_R   __stringify(0x220)
> > +#define SCRIPT_ADDR_R__stringify(0x180)
> > +#define PXEFILE_ADDR_R   __stringify(0x190)
> >
> > -#define CFG_EXTRA_ENV_SETTINGS   \
> > - "initrd_high=0x\0"  \
> > - "ramdisk_addr_r=0x800\0"\
> > - "usb0Mode=host\0usb1Mode=host\0usb2Mode=device\0"   \
> > - "ethmtu=1500\0eth1mtu=1500\0"   \
> > - "update_uboot=sf probe; dhcp; " \
> > - "mw.b ${loadaddr} 0x0 0xd; "\
> > - "tftpboot ${loadaddr} u-boot-with-spl.kwb; "\
> > - "sf update ${loadaddr} 0x0 0xd\0"
>
> Are these dropped or am I missing a generic spot which adds them? IIRC,
> the usb*mode and eth*mtu settings are required, is that wrong? Lastly,

MTU is default to 1500 in mvneta.c. So the eth*mtu env is no longer necessary.

Also, I believe usb*mode is no longer necessary with the USB driver
model. I have 

[PATCH] scripts/Makefile.lib: EFI: Use capsule CRT instead of ESL file

2024-06-07 Thread Jonathan Humphreys
The EFI Capsule ESL file (EFI Signature List File) used for authentication
is a binary generated from the EFI Capsule public key certificate. Instead
of including it in the source repo, automatically generate it from the
certificate file during the build process.

Currently, sandbox is the only device using this, so removed its ESL file
and set the (new) CONFIG_EFI_CAPSULE_CRT_FILE config to point to its public
key certificate.

Signed-off-by: Jonathan Humphreys 
---
 board/sandbox/capsule_pub_esl_good.esl | Bin 831 -> 0 bytes
 configs/sandbox_defconfig  |   2 +-
 configs/sandbox_flattree_defconfig |   2 +-
 doc/develop/uefi/uefi.rst  |   8 
 lib/efi_loader/Kconfig |  12 +++-
 scripts/Makefile.lib   |  17 +
 6 files changed, 22 insertions(+), 19 deletions(-)
 delete mode 100644 board/sandbox/capsule_pub_esl_good.esl

diff --git a/board/sandbox/capsule_pub_esl_good.esl 
b/board/sandbox/capsule_pub_esl_good.esl
deleted file mode 100644
index 
f8cc272309b2f80113c29e22bc9fdd5c767b4667..
GIT binary patch
literal 0
HcmV?d1

literal 831
zcmZ1^?2Da*aux2_hA(f&|m&&@%1|1@gOCPI%=`vTjNcb9GchtTi3D3+YdNud
z!N;6d=3f<$i4vT_x7NA^t?#f
z>a)U0PLquF6_u8?^dHul+F@6qxB0YdssF`W?=n<3b^P4dmiKI#^@p}E)#B;%RW0;Z
z-#n?@Et9eDfUQTgV*{b|~VRC6NVv@WS%&0hbnAnbMH)s>mjlOWk4kw?f2&||$2#il@?9KqESXN5
zbz2wTe>RVi?d~3_cT1K9oDaUDRd@aM1GkLbi{)Ma(#i_ui5G`j(PuTIhpoN
z73DslYiZhJ`RkA&6EhzH
z-bULy5-~dZsg>zZPS-w(zNM;c<#N4ar|5@t2FY2AoF7{4IWYI(=HR-Vl;VtSQGM$z
zG|ez&@#LeqJ9NJDsL
xX})Fc$L0Fj-|CD!3Bu=aCF 
$(depfile)
 
+capsule_esl_input_file=$(srctree)/lib/efi_loader/capsule_esl.dtsi.in
+capsule_crt_file=$(subst $(quote),,$(CONFIG_EFI_CAPSULE_CRT_FILE))
+capsule_esl_dtsi=.capsule_esl.dtsi
+
 quiet_cmd_capsule_esl_gen = CAPSULE_ESL_GEN $@
 cmd_capsule_esl_gen = \
-   $(shell sed "s:ESL_BIN_FILE:$(capsule_esl_path):" 
$(capsule_esl_input_file) > $@)
+   cert-to-efi-sig-list $< $(obj)/capsule_esl_file \
+   $(shell sed "s:ESL_BIN_FILE:$(abspath $(obj)/capsule_esl_file):" 
$(capsule_esl_input_file) > $@)
 
-$(obj)/.capsule_esl.dtsi: FORCE
-ifeq ($(CONFIG_EFI_CAPSULE_ESL_FILE),"")
-   $(error "CONFIG_EFI_CAPSULE_ESL_FILE is empty, EFI capsule 
authentication \
+$(obj)/$(capsule_esl_dtsi): $(capsule_crt_file) FORCE
+ifeq ($(CONFIG_EFI_CAPSULE_CRT_FILE),"")
+   $(error "CONFIG_EFI_CAPSULE_CRT_FILE is empty, EFI capsule 
authentication \
public key must be specified when CONFIG_EFI_CAPSULE_AUTHENTICATE is 
enabled")
 else
$(call cmd_capsule_esl_gen)
 endif
 
-capsule_esl_input_file=$(srctree)/lib/efi_loader/capsule_esl.dtsi.in
-capsule_esl_dtsi = .capsule_esl.dtsi
-capsule_esl_path=$(abspath $(srctree)/$(subst 
$(quote),,$(CONFIG_EFI_CAPSULE_ESL_FILE)))
-
 dtsi_include_list_deps := $(addprefix $(u_boot_dtsi_loc),$(subst 
$(quote),,$(dtsi_include_list)))
 
 ifdef CONFIG_EFI_CAPSULE_AUTHENTICATE
-- 
2.34.1



[PATCH v6 09/24] doc: board: ti: j721e: document OSPI layout

2024-06-07 Thread Jonathan Humphreys
Updated OSPI flash layout diagram.

Signed-off-by: Jonathan Humphreys 
---
 doc/board/ti/img/ospi_sysfw.svg | 1464 +--
 doc/board/ti/j721e_evm.rst  |   58 +-
 2 files changed, 847 insertions(+), 675 deletions(-)

diff --git a/doc/board/ti/img/ospi_sysfw.svg b/doc/board/ti/img/ospi_sysfw.svg
index 648f6fd03e5..2a2fd3f4863 100644
--- a/doc/board/ti/img/ospi_sysfw.svg
+++ b/doc/board/ti/img/ospi_sysfw.svg
@@ -1,725 +1,897 @@
 
 
 

[PATCH v6 24/24] doc: board: ti: j784s4: document OSPI NOR layout

2024-06-07 Thread Jonathan Humphreys
Added OSPI NOR flash layout diagram, as well as example commands to flash
firmware to it.  Added OSPI boot mode pin setting.

Signed-off-by: Jonathan Humphreys 
---
 doc/board/ti/img/ospi_sysfw3.svg | 802 +++
 doc/board/ti/j784s4_evm.rst  |  28 ++
 2 files changed, 830 insertions(+)
 create mode 100644 doc/board/ti/img/ospi_sysfw3.svg

diff --git a/doc/board/ti/img/ospi_sysfw3.svg b/doc/board/ti/img/ospi_sysfw3.svg
new file mode 100644
index 000..382867c6f4f
--- /dev/null
+++ b/doc/board/ti/img/ospi_sysfw3.svg
@@ -0,0 +1,802 @@
+
+
+

[PATCH v6 16/24] board: am62px: Define capsule update firmware info

2024-06-07 Thread Jonathan Humphreys
Define the firmware components updatable via EFI capsule update, including
defining capsule GUIDs for the various firmware components for the AM62px
SK.

Signed-off-by: Jonathan Humphreys 
---
 board/ti/am62px/evm.c| 34 ++
 include/configs/am62px_evm.h | 24 
 2 files changed, 58 insertions(+)

diff --git a/board/ti/am62px/evm.c b/board/ti/am62px/evm.c
index 97a95ce8cc2..1a2c46c462b 100644
--- a/board/ti/am62px/evm.c
+++ b/board/ti/am62px/evm.c
@@ -6,6 +6,7 @@
  *
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -13,6 +14,39 @@
 #include 
 #include 
 
+struct efi_fw_image fw_images[] = {
+   {
+   .image_type_id = AM62PX_SK_TIBOOT3_IMAGE_GUID,
+   .fw_name = u"AM62PX_SK_TIBOOT3",
+   .image_index = 1,
+   },
+   {
+   .image_type_id = AM62PX_SK_SPL_IMAGE_GUID,
+   .fw_name = u"AM62PX_SK_SPL",
+   .image_index = 2,
+   },
+   {
+   .image_type_id = AM62PX_SK_UBOOT_IMAGE_GUID,
+   .fw_name = u"AM62PX_SK_UBOOT",
+   .image_index = 3,
+   }
+};
+
+struct efi_capsule_update_info update_info = {
+   .dfu_string = "sf 0:0=tiboot3.bin raw 0 8;"
+   "tispl.bin raw 8 20;u-boot.img raw 28 40",
+   .num_images = ARRAY_SIZE(fw_images),
+   .images = fw_images,
+};
+
+#if IS_ENABLED(CONFIG_SET_DFU_ALT_INFO)
+void set_dfu_alt_info(char *interface, char *devstr)
+{
+   if (IS_ENABLED(CONFIG_EFI_HAVE_CAPSULE_SUPPORT))
+   env_set("dfu_alt_info", update_info.dfu_string);
+}
+#endif
+
 int board_init(void)
 {
return 0;
diff --git a/include/configs/am62px_evm.h b/include/configs/am62px_evm.h
index 06b12860e21..57a1ba9dc3c 100644
--- a/include/configs/am62px_evm.h
+++ b/include/configs/am62px_evm.h
@@ -8,6 +8,30 @@
 #ifndef __CONFIG_AM62PX_EVM_H
 #define __CONFIG_AM62PX_EVM_H
 
+/**
+ * define AM62PX_SK_TIBOOT3_IMAGE_GUID - firmware GUID for AM62PX sk 
tiboot3.bin
+ * define AM62PX_SK_SPL_IMAGE_GUID - firmware GUID for AM62PX sk SPL
+ * define AM62PX_SK_UBOOT_IMAGE_GUID   - firmware GUID for AM62PX sk UBOOT
+ *
+ * These GUIDs are used in capsules updates to identify the corresponding
+ * firmware object.
+ *
+ * Board developers using this as a starting reference should
+ * define their own GUIDs to ensure that firmware repositories (like
+ * LVFS) do not confuse them.
+ */
+#define AM62PX_SK_TIBOOT3_IMAGE_GUID \
+   EFI_GUID(0xb08471b7, 0xbe2d, 0x4489, 0x87, 0xa1, \
+   0xca, 0xb2, 0x8a, 0x0c, 0xf7, 0x43)
+
+#define AM62PX_SK_SPL_IMAGE_GUID \
+   EFI_GUID(0xd02ed781, 0x6d71, 0x4c1a, 0xa9, 0x99, \
+   0x3c, 0x6a, 0x41, 0xc3, 0x63, 0x24)
+
+#define AM62PX_SK_UBOOT_IMAGE_GUID \
+   EFI_GUID(0x7e6aea51, 0x965c, 0x44ab, 0xb3, 0x88, \
+   0xda, 0xeb, 0x03, 0xb5, 0x4f, 0x66)
+
 /* Now for the remaining common defines */
 #include 
 
-- 
2.34.1



[PATCH v6 06/24] doc: board: ti: am64x: document OSPI layout

2024-06-07 Thread Jonathan Humphreys
Added OSPI flash layout diagram, as well as example commands to flash
firmware to it.

Signed-off-by: Jonathan Humphreys 
---
 doc/board/ti/am64x_evm.rst   |  24 +
 doc/board/ti/img/ospi_sysfw-am64.svg | 802 +++
 2 files changed, 826 insertions(+)
 create mode 100644 doc/board/ti/img/ospi_sysfw-am64.svg

diff --git a/doc/board/ti/am64x_evm.rst b/doc/board/ti/am64x_evm.rst
index 6ae35b3fee3..88997b6a283 100644
--- a/doc/board/ti/am64x_evm.rst
+++ b/doc/board/ti/am64x_evm.rst
@@ -140,6 +140,30 @@ Image formats:
 .. image:: img/nodm_tispl.bin.svg
   :alt: tispl.bin image format
 
+OSPI:
+-
+ROM supports booting from OSPI from offset 0x0.
+
+Flashing images to OSPI:
+
+Below commands can be used to download tiboot3.bin, tispl.bin, and u-boot.img,
+over tftp and then flash those to OSPI at their respective addresses.
+
+.. prompt:: bash =>
+
+  sf probe
+  tftp ${loadaddr} tiboot3.bin
+  sf update $loadaddr 0x0 $filesize
+  tftp ${loadaddr} tispl.bin
+  sf update $loadaddr 0x10 $filesize
+  tftp ${loadaddr} u-boot.img
+  sf update $loadaddr 0x30 $filesize
+
+Flash layout for OSPI:
+
+.. image:: img/ospi_sysfw-am64.svg
+  :alt: OSPI flash partition layout
+
 Switch Setting for Boot Mode
 
 
diff --git a/doc/board/ti/img/ospi_sysfw-am64.svg 
b/doc/board/ti/img/ospi_sysfw-am64.svg
new file mode 100644
index 000..f6244dce596
--- /dev/null
+++ b/doc/board/ti/img/ospi_sysfw-am64.svg
@@ -0,0 +1,802 @@
+
+
+

[PATCH v6 05/24] configs: am64x: Enable EFI capsule update

2024-06-07 Thread Jonathan Humphreys
Enable on disk, raw capsule update.

Signed-off-by: Jonathan Humphreys 
---
 configs/am64x_evm_a53_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/am64x_evm_a53_defconfig b/configs/am64x_evm_a53_defconfig
index e000549d6d0..44c22458ab2 100644
--- a/configs/am64x_evm_a53_defconfig
+++ b/configs/am64x_evm_a53_defconfig
@@ -178,3 +178,5 @@ CONFIG_USB_FUNCTION_MASS_STORAGE=y
 CONFIG_SPL_DFU=y
 CONFIG_FS_FAT_MAX_CLUSTSIZE=16384
 CONFIG_EFI_SET_TIME=y
+
+#include 
-- 
2.34.1



[PATCH v6 19/24] board: beagleboneai64: Define capsule update firmware info

2024-06-07 Thread Jonathan Humphreys
Define the firmware components updatable via EFI capsule update, including
defining capsule GUIDs for the various firmware components for the
BeagleBoneAI64.

Note this involved creating BeagleBoneAI64's own beagleboneai64.h board
header file instead of reusing j721e_evm's.

Signed-off-by: Jonathan Humphreys 
---
 board/beagle/beagleboneai64/Kconfig  |  4 +-
 board/beagle/beagleboneai64/beagleboneai64.c | 39 ++
 include/configs/beagleboneai64.h | 55 
 3 files changed, 96 insertions(+), 2 deletions(-)
 create mode 100644 include/configs/beagleboneai64.h

diff --git a/board/beagle/beagleboneai64/Kconfig 
b/board/beagle/beagleboneai64/Kconfig
index 7cfccf9baf0..0f21582614d 100644
--- a/board/beagle/beagleboneai64/Kconfig
+++ b/board/beagle/beagleboneai64/Kconfig
@@ -37,7 +37,7 @@ config SYS_VENDOR
default "beagle"
 
 config SYS_CONFIG_NAME
-   default "j721e_evm"
+   default "beagleboneai64"
 
 source "board/ti/common/Kconfig"
 
@@ -52,7 +52,7 @@ config SYS_VENDOR
default "beagle"
 
 config SYS_CONFIG_NAME
-   default "j721e_evm"
+   default "beagleboneai64"
 
 source "board/ti/common/Kconfig"
 
diff --git a/board/beagle/beagleboneai64/beagleboneai64.c 
b/board/beagle/beagleboneai64/beagleboneai64.c
index c5b4ff7df47..1e43d1c1bd2 100644
--- a/board/beagle/beagleboneai64/beagleboneai64.c
+++ b/board/beagle/beagleboneai64/beagleboneai64.c
@@ -7,6 +7,7 @@
  * Copyright (C) 2022-2023 Robert Nelson, BeagleBoard.org Foundation
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -14,6 +15,44 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+struct efi_fw_image fw_images[] = {
+   {
+   .image_type_id = BEAGLEBONEAI64_TIBOOT3_IMAGE_GUID,
+   .fw_name = u"BEAGLEBONEAI64_TIBOOT3",
+   .image_index = 1,
+   },
+   {
+   .image_type_id = BEAGLEBONEAI64_SPL_IMAGE_GUID,
+   .fw_name = u"BEAGLEBONEAI64_SPL",
+   .image_index = 2,
+   },
+   {
+   .image_type_id = BEAGLEBONEAI64_UBOOT_IMAGE_GUID,
+   .fw_name = u"BEAGLEBONEAI64_UBOOT",
+   .image_index = 3,
+   },
+   {
+   .image_type_id = BEAGLEBONEAI64_SYSFW_IMAGE_GUID,
+   .fw_name = u"BEAGLEBONEAI64_SYSFW",
+   .image_index = 4,
+   }
+};
+
+struct efi_capsule_update_info update_info = {
+   .dfu_string = "mmc 0=tiboot3.bin raw 0 2000 mmcpart 1;"
+   "tispl.bin fat 0 1;u-boot.img fat 0 1; sysfw.itb fat 0 1",
+   .num_images = ARRAY_SIZE(fw_images),
+   .images = fw_images,
+};
+
+#if IS_ENABLED(CONFIG_SET_DFU_ALT_INFO)
+void set_dfu_alt_info(char *interface, char *devstr)
+{
+   if (IS_ENABLED(CONFIG_EFI_HAVE_CAPSULE_SUPPORT))
+   env_set("dfu_alt_info", update_info.dfu_string);
+}
+#endif
+
 int board_init(void)
 {
return 0;
diff --git a/include/configs/beagleboneai64.h b/include/configs/beagleboneai64.h
new file mode 100644
index 000..85d57248bb6
--- /dev/null
+++ b/include/configs/beagleboneai64.h
@@ -0,0 +1,55 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Configuration header file for BeagleBoneAI64
+ *
+ * https://beagleboard.org/ai-64
+ *
+ * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#ifndef __CONFIG_BEAGLEBONEAI64_H
+#define __CONFIG_BEAGLEBONEAI64_H
+
+/* FLASH Configuration */
+#define CFG_SYS_FLASH_BASE 0x0
+
+/* SPL Loader Configuration */
+#define CFG_SYS_UBOOT_BASE 0x5008
+
+/**
+ * define BEAGLEBONEAI64_TIBOOT3_IMAGE_GUID - firmware GUID for BeagleBoneAI64
+ *tiboot3.bin
+ * define BEAGLEBONEAI64_SPL_IMAGE_GUID - firmware GUID for BeagleBoneAI64
+ *SPL
+ * define BEAGLEBONEAI64_UBOOT_IMAGE_GUID   - firmware GUID for BeagleBoneAI64
+ *UBOOT
+ * define BEAGLEBONEAI64_SYSFW_IMAGE_GUID   - firmware GUID for BeagleBoneAI64
+ *SYSFW
+ *
+ * These GUIDs are used in capsules updates to identify the corresponding
+ * firmware object.
+ *
+ * Board developers using this as a starting reference should
+ * define their own GUIDs to ensure that firmware repositories (like
+ * LVFS) do not confuse them.
+ */
+#define BEAGLEBONEAI64_TIBOOT3_IMAGE_GUID \
+   EFI_GUID(0x772a4810, 0x2194, 0x4923, 0x87, 0x54, \
+   0x01, 0x15, 0x87, 0x0e, 0xf3, 0x67)
+
+#define BEAGLEBONEAI64_SPL_IMAGE_GUID \
+   EFI_GUID(0x83447222, 0x1e26, 0x40cd, 0xa3, 0x95, \
+   0xb7, 0xde, 0x09, 0x57, 0xe8, 0x75)
+
+#define BEAGLEBONEAI64_UBOOT_IMAGE_GUID \
+   EFI_GUID(0x4249ff77, 0xc17d, 0x4eb7, 0xa1, 0xdb, \
+   0x45, 0xaa, 0x98, 0x87, 0xd4, 0x9e)
+
+#define BEAGLEBONEAI64_SYSFW_IMAGE_GUID \
+   EFI_GUID(0xdfc9c683, 0x49b7, 0x46bd, 0xb3, 0xc1, \
+   0x3a, 0x3b, 0x2f, 0xdb, 0x13, 0x5b)
+
+/* 

[PATCH v6 04/24] board: am64x: Define capsule update firmware info

2024-06-07 Thread Jonathan Humphreys
Define the firmware components updatable via EFI capsule update, including
defining capsule GUIDs for the various firmware components for the AM64x
SK.

Signed-off-by: Jonathan Humphreys 
---
 board/ti/am64x/evm.c| 34 ++
 include/configs/am64x_evm.h | 24 
 2 files changed, 58 insertions(+)

diff --git a/board/ti/am64x/evm.c b/board/ti/am64x/evm.c
index b8de69da06c..609e5cf6d51 100644
--- a/board/ti/am64x/evm.c
+++ b/board/ti/am64x/evm.c
@@ -7,6 +7,7 @@
  *
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -27,6 +28,39 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+struct efi_fw_image fw_images[] = {
+   {
+   .image_type_id = AM64X_SK_TIBOOT3_IMAGE_GUID,
+   .fw_name = u"AM64X_SK_TIBOOT3",
+   .image_index = 1,
+   },
+   {
+   .image_type_id = AM64X_SK_SPL_IMAGE_GUID,
+   .fw_name = u"AM64X_SK_SPL",
+   .image_index = 2,
+   },
+   {
+   .image_type_id = AM64X_SK_UBOOT_IMAGE_GUID,
+   .fw_name = u"AM64X_SK_UBOOT",
+   .image_index = 3,
+   }
+};
+
+struct efi_capsule_update_info update_info = {
+   .dfu_string = "sf 0:0=tiboot3.bin raw 0 10;"
+   "tispl.bin raw 10 20;u-boot.img raw 30 40",
+   .num_images = ARRAY_SIZE(fw_images),
+   .images = fw_images,
+};
+
+#if IS_ENABLED(CONFIG_SET_DFU_ALT_INFO)
+void set_dfu_alt_info(char *interface, char *devstr)
+{
+   if (IS_ENABLED(CONFIG_EFI_HAVE_CAPSULE_SUPPORT))
+   env_set("dfu_alt_info", update_info.dfu_string);
+}
+#endif
+
 int board_init(void)
 {
return 0;
diff --git a/include/configs/am64x_evm.h b/include/configs/am64x_evm.h
index f9f8c7bc2f6..9db83621ea8 100644
--- a/include/configs/am64x_evm.h
+++ b/include/configs/am64x_evm.h
@@ -9,6 +9,30 @@
 #ifndef __CONFIG_AM642_EVM_H
 #define __CONFIG_AM642_EVM_H
 
+/**
+ * define AM64X_SK_TIBOOT3_IMAGE_GUID - firmware GUID for AM64X sk tiboot3.bin
+ * define AM64X_SK_SPL_IMAGE_GUID - firmware GUID for AM64X sk SPL
+ * define AM64X_SK_UBOOT_IMAGE_GUID   - firmware GUID for AM64X sk UBOOT
+ *
+ * These GUIDs are used in capsules updates to identify the corresponding
+ * firmware object.
+ *
+ * Board developers using this as a starting reference should
+ * define their own GUIDs to ensure that firmware repositories (like
+ * LVFS) do not confuse them.
+ */
+#define AM64X_SK_TIBOOT3_IMAGE_GUID \
+   EFI_GUID(0xede0a0d5, 0x9116, 0x4bfb, 0xaa, 0x54, \
+   0x09, 0xe9, 0x7b, 0x5a, 0xfe, 0x1a)
+
+#define AM64X_SK_SPL_IMAGE_GUID \
+   EFI_GUID(0x77678f5c, 0x64d4, 0x4910, 0xad, 0x75, \
+   0x52, 0xc9, 0xd9, 0x5c, 0xdb, 0x1d)
+
+#define AM64X_SK_UBOOT_IMAGE_GUID \
+   EFI_GUID(0xc6ad43a9, 0x7d31, 0x4f5d, 0x83, 0xe9, \
+   0xb8, 0xef, 0xec, 0xae, 0x05, 0xbf)
+
 /* Now for the remaining common defines */
 #include 
 
-- 
2.34.1



[PATCH v6 03/24] configs: ti: Create base EFI capsule configs for TI K3 devices

2024-06-07 Thread Jonathan Humphreys
To better scale with the number of boards, separate TI K3 EFI capsule
configs into its own file that can be shared across TI K3 boards.  This
will allow any platform level config changes to be done once.

Signed-off-by: Jonathan Humphreys 
---
 configs/k3_efi_capsule.config | 2 ++
 1 file changed, 2 insertions(+)
 create mode 100644 configs/k3_efi_capsule.config

diff --git a/configs/k3_efi_capsule.config b/configs/k3_efi_capsule.config
new file mode 100644
index 000..e31cea37269
--- /dev/null
+++ b/configs/k3_efi_capsule.config
@@ -0,0 +1,2 @@
+CONFIG_EFI_CAPSULE_ON_DISK=y
+CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
-- 
2.34.1



[PATCH v6 13/24] board: am62x: Define capsule update firmware info

2024-06-07 Thread Jonathan Humphreys
Define the firmware components updatable via EFI capsule update, including
defining capsule GUIDs for the various firmware components for the AM62x
SK.

Signed-off-by: Jonathan Humphreys 
---
 board/ti/am62x/evm.c| 34 ++
 include/configs/am62x_evm.h | 24 
 2 files changed, 58 insertions(+)

diff --git a/board/ti/am62x/evm.c b/board/ti/am62x/evm.c
index b3e8680dfab..9bdd0223cdb 100644
--- a/board/ti/am62x/evm.c
+++ b/board/ti/am62x/evm.c
@@ -7,6 +7,7 @@
  *
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -46,6 +47,39 @@ int splash_screen_prepare(void)
 }
 #endif
 
+struct efi_fw_image fw_images[] = {
+   {
+   .image_type_id = AM62X_SK_TIBOOT3_IMAGE_GUID,
+   .fw_name = u"AM62X_SK_TIBOOT3",
+   .image_index = 1,
+   },
+   {
+   .image_type_id = AM62X_SK_SPL_IMAGE_GUID,
+   .fw_name = u"AM62X_SK_SPL",
+   .image_index = 2,
+   },
+   {
+   .image_type_id = AM62X_SK_UBOOT_IMAGE_GUID,
+   .fw_name = u"AM62X_SK_UBOOT",
+   .image_index = 3,
+   }
+};
+
+struct efi_capsule_update_info update_info = {
+   .dfu_string = "sf 0:0=tiboot3.bin raw 0 8;"
+   "tispl.bin raw 8 20;u-boot.img raw 28 40",
+   .num_images = ARRAY_SIZE(fw_images),
+   .images = fw_images,
+};
+
+#if IS_ENABLED(CONFIG_SET_DFU_ALT_INFO)
+void set_dfu_alt_info(char *interface, char *devstr)
+{
+   if (IS_ENABLED(CONFIG_EFI_HAVE_CAPSULE_SUPPORT))
+   env_set("dfu_alt_info", update_info.dfu_string);
+}
+#endif
+
 int board_init(void)
 {
return 0;
diff --git a/include/configs/am62x_evm.h b/include/configs/am62x_evm.h
index c8fe59b7531..0d98f14a4bc 100644
--- a/include/configs/am62x_evm.h
+++ b/include/configs/am62x_evm.h
@@ -9,6 +9,30 @@
 #ifndef __CONFIG_AM625_EVM_H
 #define __CONFIG_AM625_EVM_H
 
+/**
+ * define AM62X_SK_TIBOOT3_IMAGE_GUID - firmware GUID for AM62X sk tiboot3.bin
+ * define AM62X_SK_SPL_IMAGE_GUID - firmware GUID for AM62X sk SPL
+ * define AM62X_SK_UBOOT_IMAGE_GUID   - firmware GUID for AM62X sk UBOOT
+ *
+ * These GUIDs are used in capsules updates to identify the corresponding
+ * firmware object.
+ *
+ * Board developers using this as a starting reference should
+ * define their own GUIDs to ensure that firmware repositories (like
+ * LVFS) do not confuse them.
+ */
+#define AM62X_SK_TIBOOT3_IMAGE_GUID \
+   EFI_GUID(0xabcb83d2, 0x9cb6, 0x4351, 0xb8, 0xf1, \
+   0x64, 0x94, 0xbb, 0xe3, 0x70, 0x0a)
+
+#define AM62X_SK_SPL_IMAGE_GUID \
+   EFI_GUID(0xaee355fc, 0xbf97, 0x4264, 0x8c, 0x82, \
+   0x43, 0x72, 0x55, 0xef, 0xdc, 0x1d)
+
+#define AM62X_SK_UBOOT_IMAGE_GUID \
+   EFI_GUID(0x28ab8c6c, 0xfca8, 0x41d3, 0x8e, 0xa1, \
+   0x5f, 0x17, 0x1b, 0x7d, 0x29, 0x29)
+
 /* Now for the remaining common defines */
 #include 
 
-- 
2.34.1



[PATCH v6 22/24] board: sk-am69: Define capsule update firmware info

2024-06-07 Thread Jonathan Humphreys
Define the firmware components updatable via EFI capsule update, including
defining capsule GUIDs for the various firmware components for the AM69
SK.

TODO: possibly make the struct's sk specific.
TODO: add doc commit (and make sure doc is sk/NOR specific, and add OSIP
boot mode)
TODO: update doc to show sk defconfig when building

Signed-off-by: Jonathan Humphreys 
---
 board/ti/j784s4/evm.c| 34 ++
 include/configs/j784s4_evm.h | 24 
 2 files changed, 58 insertions(+)

diff --git a/board/ti/j784s4/evm.c b/board/ti/j784s4/evm.c
index aed0ea5b949..548dbd5925d 100644
--- a/board/ti/j784s4/evm.c
+++ b/board/ti/j784s4/evm.c
@@ -7,12 +7,46 @@
  *
  */
 
+#include 
 #include 
 #include 
 #include "../common/fdt_ops.h"
 
 DECLARE_GLOBAL_DATA_PTR;
 
+struct efi_fw_image fw_images[] = {
+   {
+   .image_type_id = AM69_SK_TIBOOT3_IMAGE_GUID,
+   .fw_name = u"AM69_SK_TIBOOT3",
+   .image_index = 1,
+   },
+   {
+   .image_type_id = AM69_SK_SPL_IMAGE_GUID,
+   .fw_name = u"AM69_SK_SPL",
+   .image_index = 2,
+   },
+   {
+   .image_type_id = AM69_SK_UBOOT_IMAGE_GUID,
+   .fw_name = u"AM69_SK_UBOOT",
+   .image_index = 3,
+   }
+};
+
+struct efi_capsule_update_info update_info = {
+   .dfu_string = "sf 0:0=tiboot3.bin raw 0 8;"
+   "tispl.bin raw 8 20;u-boot.img raw 28 40",
+   .num_images = ARRAY_SIZE(fw_images),
+   .images = fw_images,
+};
+
+#if IS_ENABLED(CONFIG_SET_DFU_ALT_INFO)
+void set_dfu_alt_info(char *interface, char *devstr)
+{
+   if (IS_ENABLED(CONFIG_EFI_HAVE_CAPSULE_SUPPORT))
+   env_set("dfu_alt_info", update_info.dfu_string);
+}
+#endif
+
 int board_init(void)
 {
return 0;
diff --git a/include/configs/j784s4_evm.h b/include/configs/j784s4_evm.h
index 4a2ccdce144..53eb2bff221 100644
--- a/include/configs/j784s4_evm.h
+++ b/include/configs/j784s4_evm.h
@@ -9,6 +9,30 @@
 #ifndef __CONFIG_J784S4_EVM_H
 #define __CONFIG_J784S4_EVM_H
 
+/**
+ * define AM69_SK_TIBOOT3_IMAGE_GUID - firmware GUID for AM69 SK tiboot3.bin
+ * define AM69_SK_SPL_IMAGE_GUID - firmware GUID for AM69 SK SPL
+ * define AM69_SK_UBOOT_IMAGE_GUID   - firmware GUID for AM69 SK UBOOT
+ *
+ * These GUIDs are used in capsules updates to identify the corresponding
+ * firmware object.
+ *
+ * Board developers using this as a starting reference should
+ * define their own GUIDs to ensure that firmware repositories (like
+ * LVFS) do not confuse them.
+ */
+#define AM69_SK_TIBOOT3_IMAGE_GUID \
+   EFI_GUID(0xadf49ec5, 0x61bb, 0x4dbe, 0x8b, 0x8d,\
+0x39, 0xdf, 0x4d, 0x7e, 0xbf, 0x46)
+
+#define AM69_SK_SPL_IMAGE_GUID \
+   EFI_GUID(0x787f0059, 0x63a1, 0x461c, 0xa1, 0x8e, \
+0x9d, 0x83, 0x83, 0x45, 0xfe, 0x8e)
+
+#define AM69_SK_UBOOT_IMAGE_GUID \
+   EFI_GUID(0x9300505d, 0x6ec5, 0x4ff8, 0x99, 0xe4, \
+0x54, 0x59, 0xa0, 0x4b, 0xe6, 0x17)
+
 /* Now for the remaining common defines */
 #include 
 
-- 
2.34.1



[PATCH v6 15/24] doc: board: ti: am62x: document OSPI layout

2024-06-07 Thread Jonathan Humphreys
Added OSPI flash layout diagram, as well as example commands to flash
firmware to it.

Signed-off-by: Jonathan Humphreys 
---
 doc/board/ti/am62x_sk.rst|  24 +
 doc/board/ti/img/ospi_sysfw2.svg | 802 +++
 2 files changed, 826 insertions(+)
 create mode 100644 doc/board/ti/img/ospi_sysfw2.svg

diff --git a/doc/board/ti/am62x_sk.rst b/doc/board/ti/am62x_sk.rst
index d5f7fe3b036..2a25e84f6c9 100644
--- a/doc/board/ti/am62x_sk.rst
+++ b/doc/board/ti/am62x_sk.rst
@@ -164,6 +164,30 @@ Image formats:
 .. image:: img/dm_tispl.bin.svg
   :alt: tispl.bin image format
 
+OSPI:
+-
+ROM supports booting from OSPI from offset 0x0.
+
+Flashing images to OSPI:
+
+Below commands can be used to download tiboot3.bin, tispl.bin, and u-boot.img,
+over tftp and then flash those to OSPI at their respective addresses.
+
+.. prompt:: bash =>
+
+  sf probe
+  tftp ${loadaddr} tiboot3.bin
+  sf update $loadaddr 0x0 $filesize
+  tftp ${loadaddr} tispl.bin
+  sf update $loadaddr 0x8 $filesize
+  tftp ${loadaddr} u-boot.img
+  sf update $loadaddr 0x28 $filesize
+
+Flash layout for OSPI:
+
+.. image:: img/ospi_sysfw2.svg
+  :alt: OSPI flash partition layout
+
 A53 SPL DDR Memory Layout
 -
 
diff --git a/doc/board/ti/img/ospi_sysfw2.svg b/doc/board/ti/img/ospi_sysfw2.svg
new file mode 100644
index 000..06711df4117
--- /dev/null
+++ b/doc/board/ti/img/ospi_sysfw2.svg
@@ -0,0 +1,802 @@
+
+
+

[PATCH v6 12/24] configs: beagleplay: Enable EFI capsule update

2024-06-07 Thread Jonathan Humphreys
Enable on disk, raw capsule update.

Signed-off-by: Jonathan Humphreys 
---
 configs/am62x_beagleplay_a53_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/am62x_beagleplay_a53_defconfig 
b/configs/am62x_beagleplay_a53_defconfig
index dbdbaf98348..18f6f8865b5 100644
--- a/configs/am62x_beagleplay_a53_defconfig
+++ b/configs/am62x_beagleplay_a53_defconfig
@@ -125,4 +125,5 @@ CONFIG_FS_FAT_MAX_CLUSTSIZE=16384
 CONFIG_LZO=y
 CONFIG_EFI_SET_TIME=y
 
+#include 
 #include 
-- 
2.34.1



[PATCH v6 08/24] configs: j721e: Enable EFI capsule update

2024-06-07 Thread Jonathan Humphreys
Enable on disk, raw capsule update.

Signed-off-by: Jonathan Humphreys 
---
 configs/j721e_evm_a72_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/j721e_evm_a72_defconfig b/configs/j721e_evm_a72_defconfig
index 3d8e9391987..c15e11b554f 100644
--- a/configs/j721e_evm_a72_defconfig
+++ b/configs/j721e_evm_a72_defconfig
@@ -210,3 +210,5 @@ CONFIG_UFS=y
 CONFIG_CADENCE_UFS=y
 CONFIG_TI_J721E_UFS=y
 CONFIG_EFI_SET_TIME=y
+
+#include 
-- 
2.34.1



[PATCH v6 10/24] board: beagleplay: Define capsule update firmware info

2024-06-07 Thread Jonathan Humphreys
Define the firmware components updatable via EFI capsule update, including
defining capsule GUIDs for the various firmware components for the
BeaglePlay.

Note this involved creating BeaglePlay's own beagleplay.h board header file
instead of reusing am62_evm's.

Signed-off-by: Jonathan Humphreys 
---
 board/beagle/beagleplay/Kconfig  |  4 +--
 board/beagle/beagleplay/beagleplay.c | 34 +++
 include/configs/beagleplay.h | 41 
 3 files changed, 77 insertions(+), 2 deletions(-)
 create mode 100644 include/configs/beagleplay.h

diff --git a/board/beagle/beagleplay/Kconfig b/board/beagle/beagleplay/Kconfig
index 7dbd833acb4..b0e67dc8ef3 100644
--- a/board/beagle/beagleplay/Kconfig
+++ b/board/beagle/beagleplay/Kconfig
@@ -35,7 +35,7 @@ config SYS_VENDOR
default "beagle"
 
 config SYS_CONFIG_NAME
-   default "am62x_evm"
+   default "beagleplay"
 
 source "board/ti/common/Kconfig"
 
@@ -50,7 +50,7 @@ config SYS_VENDOR
default "beagle"
 
 config SYS_CONFIG_NAME
-   default "am62x_evm"
+   default "beagleplay"
 
 config SPL_LDSCRIPT
default "arch/arm/mach-omap2/u-boot-spl.lds"
diff --git a/board/beagle/beagleplay/beagleplay.c 
b/board/beagle/beagleplay/beagleplay.c
index af36439e2e2..a21f09e3122 100644
--- a/board/beagle/beagleplay/beagleplay.c
+++ b/board/beagle/beagleplay/beagleplay.c
@@ -6,6 +6,7 @@
  * Copyright (C) 2022-2023 Robert Nelson, BeagleBoard.org Foundation
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -15,6 +16,39 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+struct efi_fw_image fw_images[] = {
+   {
+   .image_type_id = BEAGLEPLAY_TIBOOT3_IMAGE_GUID,
+   .fw_name = u"BEAGLEPLAY_TIBOOT3",
+   .image_index = 1,
+   },
+   {
+   .image_type_id = BEAGLEPLAY_SPL_IMAGE_GUID,
+   .fw_name = u"BEAGLEPLAY_SPL",
+   .image_index = 2,
+   },
+   {
+   .image_type_id = BEAGLEPLAY_UBOOT_IMAGE_GUID,
+   .fw_name = u"BEAGLEPLAY_UBOOT",
+   .image_index = 3,
+   }
+};
+
+struct efi_capsule_update_info update_info = {
+   .dfu_string = "mmc 0=tiboot3.bin raw 0 2000 mmcpart 1;"
+   "tispl.bin fat 0 1;u-boot.img fat 0 1",
+   .num_images = ARRAY_SIZE(fw_images),
+   .images = fw_images,
+};
+
+#if IS_ENABLED(CONFIG_SET_DFU_ALT_INFO)
+void set_dfu_alt_info(char *interface, char *devstr)
+{
+   if (IS_ENABLED(CONFIG_EFI_HAVE_CAPSULE_SUPPORT))
+   env_set("dfu_alt_info", update_info.dfu_string);
+}
+#endif
+
 int board_init(void)
 {
return 0;
diff --git a/include/configs/beagleplay.h b/include/configs/beagleplay.h
new file mode 100644
index 000..4baeab664af
--- /dev/null
+++ b/include/configs/beagleplay.h
@@ -0,0 +1,41 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Configuration header file for BeaglePlay
+ *
+ * https://beagleplay.org/
+ *
+ * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#ifndef __CONFIG_BEAGLEPLAY_H
+#define __CONFIG_BEAGLEPLAY_H
+
+/**
+ * define BEAGLEPLAY_TIBOOT3_IMAGE_GUID - firmware GUID for BeaglePlay
+ *tiboot3.bin
+ * define BEAGLEPLAY_SPL_IMAGE_GUID - firmware GUID for BeaglePlay SPL
+ * define BEAGLEPLAY_UBOOT_IMAGE_GUID   - firmware GUID for BeaglePlay UBOOT
+ *
+ * These GUIDs are used in capsules updates to identify the corresponding
+ * firmware object.
+ *
+ * Board developers using this as a starting reference should
+ * define their own GUIDs to ensure that firmware repositories (like
+ * LVFS) do not confuse them.
+ */
+#define BEAGLEPLAY_TIBOOT3_IMAGE_GUID \
+   EFI_GUID(0x0e225a09, 0xf720, 0x4d57, 0x91, 0x20, \
+   0xe2, 0x8f, 0x73, 0x7f, 0x5a, 0x5e)
+
+#define BEAGLEPLAY_SPL_IMAGE_GUID \
+   EFI_GUID(0xb2e7cc49, 0x1a5a, 0x4036, 0xae, 0x01, \
+   0x33, 0x87, 0xc3, 0xbe, 0xf6, 0x57)
+
+#define BEAGLEPLAY_UBOOT_IMAGE_GUID \
+   EFI_GUID(0x92c92b11, 0xa7ee, 0x486f, 0xaa, 0xa2, \
+   0x71, 0x3d, 0x84, 0x42, 0x5b, 0x0e)
+
+/* Now for the remaining common defines */
+#include 
+
+#endif /* __CONFIG_BEAGLEPLAY_H */
-- 
2.34.1



[PATCH v6 18/24] doc: board: ti: am62px: document OSPI layout

2024-06-07 Thread Jonathan Humphreys
Added OSPI flash layout diagram, as well as example commands to flash
firmware to it.

Signed-off-by: Jonathan Humphreys 
---
 doc/board/ti/am62px_sk.rst | 24 
 1 file changed, 24 insertions(+)

diff --git a/doc/board/ti/am62px_sk.rst b/doc/board/ti/am62px_sk.rst
index 1f2982c36f9..c80b5068117 100644
--- a/doc/board/ti/am62px_sk.rst
+++ b/doc/board/ti/am62px_sk.rst
@@ -156,6 +156,30 @@ Image formats:
 .. image:: img/dm_tispl.bin.svg
   :alt: tispl.bin image format
 
+OSPI:
+-
+ROM supports booting from OSPI from offset 0x0.
+
+Flashing images to OSPI:
+
+Below commands can be used to download tiboot3.bin, tispl.bin, and u-boot.img,
+over tftp and then flash those to OSPI at their respective addresses.
+
+.. prompt:: bash =>
+
+  sf probe
+  tftp ${loadaddr} tiboot3.bin
+  sf update $loadaddr 0x0 $filesize
+  tftp ${loadaddr} tispl.bin
+  sf update $loadaddr 0x8 $filesize
+  tftp ${loadaddr} u-boot.img
+  sf update $loadaddr 0x28 $filesize
+
+Flash layout for OSPI:
+
+.. image:: img/ospi_sysfw2.svg
+  :alt: OSPI flash partition layout
+
 A53 SPL DDR Memory Layout
 -
 
-- 
2.34.1



[PATCH v6 23/24] configs: j784s4: Enable EFI capsule update

2024-06-07 Thread Jonathan Humphreys
Enable on disk, raw capsule update.

Signed-off-by: Jonathan Humphreys 
---
 configs/j784s4_evm_a72_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/j784s4_evm_a72_defconfig b/configs/j784s4_evm_a72_defconfig
index d7709f554fd..c14765163f8 100644
--- a/configs/j784s4_evm_a72_defconfig
+++ b/configs/j784s4_evm_a72_defconfig
@@ -158,3 +158,5 @@ CONFIG_SPL_SYSRESET=y
 CONFIG_SYSRESET_TI_SCI=y
 CONFIG_DM_THERMAL=y
 CONFIG_EFI_SET_TIME=y
+
+#include 
-- 
2.34.1



[PATCH v6 17/24] configs: am62px: Enable EFI capsule update

2024-06-07 Thread Jonathan Humphreys
Enable on disk, raw capsule update.

Signed-off-by: Jonathan Humphreys 
---
 configs/am62px_evm_a53_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/am62px_evm_a53_defconfig b/configs/am62px_evm_a53_defconfig
index 9f40c9a0b3c..e1c9c8535e4 100644
--- a/configs/am62px_evm_a53_defconfig
+++ b/configs/am62px_evm_a53_defconfig
@@ -179,3 +179,5 @@ CONFIG_USB_GADGET_PRODUCT_NUM=0x6165
 CONFIG_SPL_DFU=y
 CONFIG_FS_FAT_MAX_CLUSTSIZE=16384
 CONFIG_EFI_SET_TIME=y
+
+#include 
-- 
2.34.1



[PATCH v6 20/24] configs: beagleboneai64: Enable EFI capsule update

2024-06-07 Thread Jonathan Humphreys
Enable on disk, raw capsule update.

Signed-off-by: Jonathan Humphreys 
---
 configs/j721e_beagleboneai64_a72_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/j721e_beagleboneai64_a72_defconfig 
b/configs/j721e_beagleboneai64_a72_defconfig
index a354876f8c2..86c565a9211 100644
--- a/configs/j721e_beagleboneai64_a72_defconfig
+++ b/configs/j721e_beagleboneai64_a72_defconfig
@@ -172,3 +172,5 @@ CONFIG_USB_GADGET_PRODUCT_NUM=0x6163
 CONFIG_SPL_DFU=y
 CONFIG_LZO=y
 CONFIG_EFI_SET_TIME=y
+
+#include 
-- 
2.34.1



[PATCH v6 14/24] configs: am62x: Enable EFI capsule update

2024-06-07 Thread Jonathan Humphreys
Enable on disk, raw capsule update.

Signed-off-by: Jonathan Humphreys 
---
 configs/am62x_evm_a53_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig
index 16294a6a794..aea9aa205c9 100644
--- a/configs/am62x_evm_a53_defconfig
+++ b/configs/am62x_evm_a53_defconfig
@@ -113,4 +113,5 @@ CONFIG_SYSRESET_TI_SCI=y
 CONFIG_FS_FAT_MAX_CLUSTSIZE=16384
 CONFIG_EFI_SET_TIME=y
 
+#include 
 #include 
-- 
2.34.1



[PATCH v6 21/24] configs: j784s4_evm: Enable serial flash DFU support

2024-06-07 Thread Jonathan Humphreys
Enable serial flash DFU support for capsule update of firmware.

Signed-off-by: Jonathan Humphreys 
---
 configs/j784s4_evm_a72_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configs/j784s4_evm_a72_defconfig b/configs/j784s4_evm_a72_defconfig
index e999a25319d..d7709f554fd 100644
--- a/configs/j784s4_evm_a72_defconfig
+++ b/configs/j784s4_evm_a72_defconfig
@@ -84,6 +84,9 @@ CONFIG_CLK=y
 CONFIG_SPL_CLK=y
 CONFIG_CLK_CCF=y
 CONFIG_CLK_TI_SCI=y
+CONFIG_DFU_SF=y
+CONFIG_SYS_DFU_DATA_BUF_SIZE=0x4
+CONFIG_SYS_DFU_MAX_FILE_SIZE=0x80
 CONFIG_DMA_CHANNELS=y
 CONFIG_TI_K3_NAVSS_UDMA=y
 CONFIG_TI_SCI_PROTOCOL=y
-- 
2.34.1



[PATCH v6 07/24] board: j721e: Define capsule update firmware info

2024-06-07 Thread Jonathan Humphreys
Define the firmware components updatable via EFI capsule update, including
defining capsule GUIDs for the various firmware components for the
SK-TDA4VM.

Signed-off-by: Jonathan Humphreys 
---
 board/ti/j721e/evm.c| 40 +
 include/configs/j721e_evm.h | 29 +++
 2 files changed, 69 insertions(+)

diff --git a/board/ti/j721e/evm.c b/board/ti/j721e/evm.c
index 539eaf47186..f3452ff0a8f 100644
--- a/board/ti/j721e/evm.c
+++ b/board/ti/j721e/evm.c
@@ -7,6 +7,7 @@
  *
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -32,6 +33,45 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+struct efi_fw_image fw_images[] = {
+   {
+   .image_type_id = J721E_SK_TIBOOT3_IMAGE_GUID,
+   .fw_name = u"J721E_SK_TIBOOT3",
+   .image_index = 1,
+   },
+   {
+   .image_type_id = J721E_SK_SPL_IMAGE_GUID,
+   .fw_name = u"J721E_SK_SPL",
+   .image_index = 2,
+   },
+   {
+   .image_type_id = J721E_SK_UBOOT_IMAGE_GUID,
+   .fw_name = u"J721E_SK_UBOOT",
+   .image_index = 3,
+   },
+   {
+   .image_type_id = J721E_SK_SYSFW_IMAGE_GUID,
+   .fw_name = u"J721E_SK_SYSFW",
+   .image_index = 4,
+   }
+};
+
+struct efi_capsule_update_info update_info = {
+   .dfu_string = "sf 0:0=tiboot3.bin raw 0 8;"
+   "tispl.bin raw 8 20;u-boot.img raw 28 40;"
+   "sysfw.itb raw 6C 10",
+   .num_images = ARRAY_SIZE(fw_images),
+   .images = fw_images,
+};
+
+#if IS_ENABLED(CONFIG_SET_DFU_ALT_INFO)
+void set_dfu_alt_info(char *interface, char *devstr)
+{
+   if (IS_ENABLED(CONFIG_EFI_HAVE_CAPSULE_SUPPORT))
+   env_set("dfu_alt_info", update_info.dfu_string);
+}
+#endif
+
 int board_init(void)
 {
return 0;
diff --git a/include/configs/j721e_evm.h b/include/configs/j721e_evm.h
index c26438c8684..a5140ea6a11 100644
--- a/include/configs/j721e_evm.h
+++ b/include/configs/j721e_evm.h
@@ -22,6 +22,35 @@
 #define CFG_SYS_UBOOT_BASE 0x5008
 #endif
 
+/**
+ * define J721E_SK_TIBOOT3_IMAGE_GUID - firmware GUID for J721e sk tiboot3.bin
+ * define J721E_SK_SPL_IMAGE_GUID - firmware GUID for J721e sk SPL
+ * define J721E_SK_UBOOT_IMAGE_GUID   - firmware GUID for J721e sk UBOOT
+ * define J721E_SK_SYSFW_IMAGE_GUID   - firmware GUID for J721e sk SYSFW
+ *
+ * These GUIDs are used in capsules updates to identify the corresponding
+ * firmware object.
+ *
+ * Board developers using this as a starting reference should
+ * define their own GUIDs to ensure that firmware repositories (like
+ * LVFS) do not confuse them.
+ */
+#define J721E_SK_TIBOOT3_IMAGE_GUID \
+   EFI_GUID(0xe672b518, 0x7cd7, 0x4014, 0xbd, 0x8d, \
+0x40, 0x72, 0x4d, 0x0a, 0xd4, 0xdc)
+
+#define J721E_SK_SPL_IMAGE_GUID \
+   EFI_GUID(0x86f710ad, 0x10cf, 0x46ea, 0xac, 0x67, \
+0x85, 0x6a, 0xe0, 0x6e, 0xfa, 0xd2)
+
+#define J721E_SK_UBOOT_IMAGE_GUID \
+   EFI_GUID(0x81b58fb0, 0x3b00, 0x4add, 0xa2, 0x0a, \
+0xc1, 0x85, 0xbb, 0xac, 0xa1, 0xed)
+
+#define J721E_SK_SYSFW_IMAGE_GUID \
+   EFI_GUID(0x6fd10680, 0x361b, 0x431f, 0x80, 0xaa, \
+0x89, 0x94, 0x55, 0x81, 0x9e, 0x11)
+
 /* Now for the remaining common defines */
 #include 
 
-- 
2.34.1



[PATCH v6 01/24] doc: uefi: capsules: Add Capsule Update porting section

2024-06-07 Thread Jonathan Humphreys
Created a capsule update porting section in the documentation that outlines
the steps a board developer must do when porting from an existing reference
board implementation.

In particular, added a big warning that new capsule GUID's need to be
defined.

Signed-off-by: Jonathan Humphreys 
---
 doc/develop/uefi/uefi.rst | 12 
 1 file changed, 12 insertions(+)

diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
index 0389b269c01..36ac75278fa 100644
--- a/doc/develop/uefi/uefi.rst
+++ b/doc/develop/uefi/uefi.rst
@@ -631,6 +631,18 @@ where version.dtso looks like::
 The properties of image-type-id and image-index must match the value
 defined in the efi_fw_image array as image_type_id and image_index.
 
+Porting Capsule Updates to new boards
+*
+
+It is important, when using a reference board as a starting point for a custom
+board, that certain steps are taken to properly support Capsule Updates.
+
+Capsule GUIDs need to be unique for each firmware and board. That is, if two
+firmwares are built from the same source but result in different binaries
+because they are built for different boards, they should have different GUIDs.
+Therefore it is important when creating support for a new board, new GUIDs are
+defined in the board's header file.  *DO NOT* reuse capsule GUIDs.
+
 Executing the boot manager
 ~~
 
-- 
2.34.1



[PATCH v6 11/24] configs: beagleplay: Enable DFU for MMC

2024-06-07 Thread Jonathan Humphreys
MMC DFU is required for capsule updates.

Signed-off-by: Jonathan Humphreys 
---
 configs/am62x_beagleplay_a53_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configs/am62x_beagleplay_a53_defconfig 
b/configs/am62x_beagleplay_a53_defconfig
index ec62670d55d..dbdbaf98348 100644
--- a/configs/am62x_beagleplay_a53_defconfig
+++ b/configs/am62x_beagleplay_a53_defconfig
@@ -70,6 +70,9 @@ CONFIG_SPL_OF_TRANSLATE=y
 CONFIG_CLK=y
 CONFIG_SPL_CLK=y
 CONFIG_CLK_TI_SCI=y
+CONFIG_DFU_MMC=y
+CONFIG_SYS_DFU_DATA_BUF_SIZE=0x4
+CONFIG_SYS_DFU_MAX_FILE_SIZE=0x18
 CONFIG_DMA_CHANNELS=y
 CONFIG_TI_K3_NAVSS_UDMA=y
 CONFIG_TI_SCI_PROTOCOL=y
-- 
2.34.1



[PATCH v6 00/24] EFI: ti: Enable EFI capsule updates

2024-06-07 Thread Jonathan Humphreys
Enable on disk capsule updates, which includes defining the firmware
components (tiboot3, spl, u-boot) and enabling processing of raw capsule
updates.

This is enabled for several TI SoC based platforms: AM64, AM62, AM62p,
AM69, BeaglePlay, J7, and BeagleboneAI. The configs to enable this are in a
single base config file. This will make it more scalable to add additional
EFI capsule features (like authentication) across all TI boards that have
capsules enabled.

This series also includes enabling serial flash DFU for AM62 and MMC DFU
for beagleplay.

Changes from v1:
- Added sysfw.itb capsule definition to beagleboneai64
- removed extra commas in structure definitions

Changes from v2:
- Added documentation on OSPI flash layouts
- Improved comments for capsule GUIDs definitions
- Defined board unique capsule GUIDs and put definitions in board specific
  files
- Added a Capsule Update porting section to the documentation

Changes from v3:
- Added better commit messages based upon checkpatch warnings.
- Remove conditional inclusion of capsule update firmware info
- Converted OSPI layout diagram to svg format
Link to v3: https://lore.kernel.org/r/20240419205701.163821-1-j-humphr...@ti.com

Changes from v4:
- Added am69 SK board
- Corrected a few spelling mistakes and clarity improvements in k3 docs
  section
- Added CONFIG_SET_DFU_ALT_INFO guard around set_dfu_alt_info()
Link to v4: 
https://lore.kernel.org/r/20240509164123.1753050-1-j-humphr...@ti.com

Changes from v5:
- Created an EFI capsule base config for TI boards, making adding
  additional capsule features on TI boards more scalable.
Link to v5: 
https://lore.kernel.org/r/20240531222118.2618041-1-j-humphr...@ti.com

Jonathan Humphreys (24):
  doc: uefi: capsules: Add Capsule Update porting section
  doc: ti: k3: Correct spelling mistakes and improve clarity
  configs: ti: Create base EFI capsule configs for TI K3 devices
  board: am64x: Define capsule update firmware info
  configs: am64x: Enable EFI capsule update
  doc: board: ti: am64x: document OSPI layout
  board: j721e: Define capsule update firmware info
  configs: j721e: Enable EFI capsule update
  doc: board: ti: j721e: document OSPI layout
  board: beagleplay: Define capsule update firmware info
  configs: beagleplay: Enable DFU for MMC
  configs: beagleplay: Enable EFI capsule update
  board: am62x: Define capsule update firmware info
  configs: am62x: Enable EFI capsule update
  doc: board: ti: am62x: document OSPI layout
  board: am62px: Define capsule update firmware info
  configs: am62px: Enable EFI capsule update
  doc: board: ti: am62px: document OSPI layout
  board: beagleboneai64: Define capsule update firmware info
  configs: beagleboneai64: Enable EFI capsule update
  configs: j784s4_evm: Enable serial flash DFU support
  board: sk-am69: Define capsule update firmware info
  configs: j784s4: Enable EFI capsule update
  doc: board: ti: j784s4: document OSPI NOR layout

 board/beagle/beagleboneai64/Kconfig  |4 +-
 board/beagle/beagleboneai64/beagleboneai64.c |   39 +
 board/beagle/beagleplay/Kconfig  |4 +-
 board/beagle/beagleplay/beagleplay.c |   34 +
 board/ti/am62px/evm.c|   34 +
 board/ti/am62x/evm.c |   34 +
 board/ti/am64x/evm.c |   34 +
 board/ti/j721e/evm.c |   40 +
 board/ti/j784s4/evm.c|   34 +
 configs/am62px_evm_a53_defconfig |2 +
 configs/am62x_beagleplay_a53_defconfig   |4 +
 configs/am62x_evm_a53_defconfig  |1 +
 configs/am64x_evm_a53_defconfig  |2 +
 configs/j721e_beagleboneai64_a72_defconfig   |2 +
 configs/j721e_evm_a72_defconfig  |2 +
 configs/j784s4_evm_a72_defconfig |5 +
 configs/k3_efi_capsule.config|2 +
 doc/board/ti/am62px_sk.rst   |   24 +
 doc/board/ti/am62x_sk.rst|   24 +
 doc/board/ti/am64x_evm.rst   |   24 +
 doc/board/ti/img/ospi_sysfw-am64.svg |  802 ++
 doc/board/ti/img/ospi_sysfw.svg  | 1464 ++
 doc/board/ti/img/ospi_sysfw2.svg |  802 ++
 doc/board/ti/img/ospi_sysfw3.svg |  802 ++
 doc/board/ti/j721e_evm.rst   |   58 +-
 doc/board/ti/j784s4_evm.rst  |   28 +
 doc/board/ti/k3.rst  |   10 +-
 doc/develop/uefi/uefi.rst|   12 +
 include/configs/am62px_evm.h |   24 +
 include/configs/am62x_evm.h  |   24 +
 include/configs/am64x_evm.h  |   24 +
 include/configs/beagleboneai64.h |   55 +
 include/configs/beagleplay.h |   41 +
 include/configs/j721e_evm.h  |   29 +
 include/configs/j784s4_evm.h |   24 +
 35 files changed, 3864 insertions(+), 684 deletions(-)
 create mode 100644 

[PATCH v6 02/24] doc: ti: k3: Correct spelling mistakes and improve clarity

2024-06-07 Thread Jonathan Humphreys
Few cosmetic fixes for clarity and spelling mistakes.

Signed-off-by: Jonathan Humphreys 
---
 doc/board/ti/k3.rst | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/doc/board/ti/k3.rst b/doc/board/ti/k3.rst
index a1c01d1cf02..927f3976d34 100644
--- a/doc/board/ti/k3.rst
+++ b/doc/board/ti/k3.rst
@@ -51,14 +51,14 @@ For all K3 SoCs the first core started will be inside the 
Security
 Management Subsystem (SMS) which will secure the device and start a core
 in the wakeup domain to run the ROM code. ROM will then initialize the
 boot media needed to load the binaries packaged inside `tiboot3.bin`,
-including a 32bit U-Boot SPL, (called the wakup SPL) that ROM will jump
+including a 32bit U-Boot SPL, (called the wakeup SPL) that ROM will jump
 to after it has finished loading everything into internal SRAM.
 
 .. image:: img/boot_flow_01.svg
   :alt: Boot flow up to wakeup domain SPL
 
 The wakeup SPL, running on a wakeup domain core, will initialize DDR and
-any peripherals needed load the larger binaries inside the `tispl.bin`
+any peripherals needed to load the larger binaries inside the `tispl.bin`
 into DDR.  Once loaded the wakeup SPL will start one of the 'big'
 application cores inside the main domain to initialize the main domain,
 starting with Trusted Firmware-A (TF-A), before moving on to start
@@ -94,7 +94,7 @@ essentially 4 unique but very similar flows:
 * Combined binary with a split firmware: (eg: AM62)
 
 For devices that utilize the split binary approach, ROM is not capable
-of loading the firmware into the SoC requiring the wakeup domain's
+of loading the firmware into the SoC, requiring the wakeup domain's
 U-Boot SPL to load the firmware.
 
 Devices with a split firmware will have two firmwares loaded into the
@@ -114,8 +114,8 @@ K3 HS-SE (High Security - Security Enforced) devices 
enforce an
 authenticated boot flow for secure boot. HS-FS (High Security - Field
 Securable) is the state of a K3 device before it has been eFused with
 customer security keys.  In the HS-FS state the authentication still can
-function as in HS-SE but as there are no customer keys to verify the
-signatures against the authentication will pass for certificates signed
+function as in HS-SE, but as there are no customer keys to verify the
+signatures against, the authentication will pass for certificates signed
 with any key.
 
 Chain of trust
-- 
2.34.1



[PATCH v4 1/2] arm: dts: add U-Boot dtbs for the am625-lp-sk

2024-06-07 Thread Bryan Brattlof
From: Nitin Yadav 

Add the U-Boot device tree overrides for the am62x-lp-sk reference
board.

Signed-off-by: Nitin Yadav 
Reviewed-by: Dhruva Gole 
Signed-off-by: Bryan Brattlof 
---
 arch/arm/dts/k3-am62-lp-sk-binman.dtsi   |   21 +
 arch/arm/dts/k3-am62-lp-sk-u-boot.dtsi   |   17 +
 arch/arm/dts/k3-am62-lp4-50-800-800.dtsi | 2190 ++
 arch/arm/dts/k3-am62-r5-lp-sk.dts|   82 ++
 4 files changed, 2310 insertions(+)

diff --git a/arch/arm/dts/k3-am62-lp-sk-binman.dtsi 
b/arch/arm/dts/k3-am62-lp-sk-binman.dtsi
new file mode 100644
index 0..18341d0d3f2e7
--- /dev/null
+++ b/arch/arm/dts/k3-am62-lp-sk-binman.dtsi
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include "k3-binman.dtsi"
+#include "k3-am625-sk-binman.dtsi"
+
+#ifdef CONFIG_TARGET_AM625_A53_EVM
+
+#define SPL_AM62_LP_SK_DTB "spl/dts/ti/k3-am62-lp-sk.dtb"
+
+_am625_sk_dtb {
+   filename = SPL_AM62_LP_SK_DTB;
+};
+
+_am625_sk_dtb_unsigned {
+   filename = SPL_AM62_LP_SK_DTB;
+};
+
+#endif
diff --git a/arch/arm/dts/k3-am62-lp-sk-u-boot.dtsi 
b/arch/arm/dts/k3-am62-lp-sk-u-boot.dtsi
new file mode 100644
index 0..cbcc7f3bb45cb
--- /dev/null
+++ b/arch/arm/dts/k3-am62-lp-sk-u-boot.dtsi
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * AM62x LP SK dts file for SPLs
+ * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include "k3-am62-lp-sk-binman.dtsi"
+
+/ {
+   chosen {
+   tick-timer = _timer0;
+   };
+};
+
+_timer0 {
+   clock-frequency = <2500>;
+};
diff --git a/arch/arm/dts/k3-am62-lp4-50-800-800.dtsi 
b/arch/arm/dts/k3-am62-lp4-50-800-800.dtsi
new file mode 100644
index 0..c255ae6530f5b
--- /dev/null
+++ b/arch/arm/dts/k3-am62-lp4-50-800-800.dtsi
@@ -0,0 +1,2190 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * This file was generated with the
+ * AM62x SysConfig DDR Subsystem Register Configuration Tool v0.09.07
+ * Wed Mar 01 2023 17:52:11 GMT-0600 (Central Standard Time)
+ * DDR Type: LPDDR4
+ * F0 = 50MHzF1 = NA F2 = 800MHz
+ * Density (per channel): 16Gb
+ * Write DBI: Enable
+ * Number of Ranks: 1
+ */
+
+#define DDRSS_PLL_FHS_CNT 3
+#define DDRSS_PLL_FREQUENCY_1 4
+#define DDRSS_PLL_FREQUENCY_2 4
+
+#define DDRSS_CTL_0_DATA 0x0B00
+#define DDRSS_CTL_1_DATA 0x
+#define DDRSS_CTL_2_DATA 0x
+#define DDRSS_CTL_3_DATA 0x
+#define DDRSS_CTL_4_DATA 0x
+#define DDRSS_CTL_5_DATA 0x
+#define DDRSS_CTL_6_DATA 0x
+#define DDRSS_CTL_7_DATA 0x2710
+#define DDRSS_CTL_8_DATA 0x000186A0
+#define DDRSS_CTL_9_DATA 0x0005
+#define DDRSS_CTL_10_DATA 0x0064
+#define DDRSS_CTL_11_DATA 0x00027100
+#define DDRSS_CTL_12_DATA 0x00186A00
+#define DDRSS_CTL_13_DATA 0x0005
+#define DDRSS_CTL_14_DATA 0x0640
+#define DDRSS_CTL_15_DATA 0x00027100
+#define DDRSS_CTL_16_DATA 0x00186A00
+#define DDRSS_CTL_17_DATA 0x0005
+#define DDRSS_CTL_18_DATA 0x0640
+#define DDRSS_CTL_19_DATA 0x01010100
+#define DDRSS_CTL_20_DATA 0x01010100
+#define DDRSS_CTL_21_DATA 0x01000110
+#define DDRSS_CTL_22_DATA 0x02010002
+#define DDRSS_CTL_23_DATA 0x000A
+#define DDRSS_CTL_24_DATA 0x000186A0
+#define DDRSS_CTL_25_DATA 0x
+#define DDRSS_CTL_26_DATA 0x
+#define DDRSS_CTL_27_DATA 0x
+#define DDRSS_CTL_28_DATA 0x
+#define DDRSS_CTL_29_DATA 0x00020200
+#define DDRSS_CTL_30_DATA 0x
+#define DDRSS_CTL_31_DATA 0x
+#define DDRSS_CTL_32_DATA 0x
+#define DDRSS_CTL_33_DATA 0x
+#define DDRSS_CTL_34_DATA 0x0810
+#define DDRSS_CTL_35_DATA 0x2020
+#define DDRSS_CTL_36_DATA 0x
+#define DDRSS_CTL_37_DATA 0x
+#define DDRSS_CTL_38_DATA 0x040C
+#define DDRSS_CTL_39_DATA 0x
+#define DDRSS_CTL_40_DATA 0x081C
+#define DDRSS_CTL_41_DATA 0x
+#define DDRSS_CTL_42_DATA 0x081C
+#define DDRSS_CTL_43_DATA 0x
+#define DDRSS_CTL_44_DATA 0x05000804
+#define DDRSS_CTL_45_DATA 0x0700
+#define DDRSS_CTL_46_DATA 0x09090004
+#define DDRSS_CTL_47_DATA 0x0203
+#define DDRSS_CTL_48_DATA 0x00320007
+#define DDRSS_CTL_49_DATA 0x09090023
+#define DDRSS_CTL_50_DATA 0x190F
+#define DDRSS_CTL_51_DATA 0x00320007
+#define DDRSS_CTL_52_DATA 0x09090023
+#define DDRSS_CTL_53_DATA 0x0900190F
+#define DDRSS_CTL_54_DATA 0x000A0A09
+#define DDRSS_CTL_55_DATA 0x040006DB
+#define DDRSS_CTL_56_DATA 0x09092004
+#define DDRSS_CTL_57_DATA 0x0C0A
+#define DDRSS_CTL_58_DATA 0x06006DB0
+#define DDRSS_CTL_59_DATA 0x09092006
+#define DDRSS_CTL_60_DATA 0x0C0A
+#define DDRSS_CTL_61_DATA 0x06006DB0
+#define DDRSS_CTL_62_DATA 0x03042006
+#define DDRSS_CTL_63_DATA 0x04050002
+#define DDRSS_CTL_64_DATA 0x100F100F
+#define DDRSS_CTL_65_DATA 0x01010008
+#define DDRSS_CTL_66_DATA 0x041F1F07
+#define DDRSS_CTL_67_DATA 0x0303
+#define DDRSS_CTL_68_DATA 0x
+#define 

[PATCH v4 0/2] introduce basic support for TI's am625-lp-sk

2024-06-07 Thread Bryan Brattlof
Hello Again Everyone!

The am625-lp-sk is a variant of the am625-sk showcasing the low-power
features of the am625 SoC Family. Because it's essentially a board and
package spin of the am625-sk I've inherited the am625 configuration and
overridden what was needed.

This is a new spin of Nitin's original work which has been updated
significantly since October 2023

  https://lore.kernel.org/u-boot/20231030110138.1347603-1-n-ya...@ti.com/

For those of us interested here is proof of life using buildroot:

   https://paste.sr.ht/~bryanb/40f7787f7760bee383aa8fbc342a29e8544dbdab

This also works around a buildman issue not following #include 
directives. To get around this I've redefined the variables it's looking 
for inside the lp-sk defconfig to keep it happy for now. I made a pull 
request on github and everything seems like it's happy

   https://dev.azure.com/u-boot/u-boot/_build/results?buildId=8634=results

Thank you for reviewing
~Bryan

Cc: u-boot@lists.denx.de
To: Tom Rini 
Signed-off-by: Bryan Brattlof 

Changes in v4:
- change the defconfig name to match previous older versions
- include needed CONFIG arguments for buildman
- added a MAINTAINERS entry for the board
- Link to v3: 
https://lore.kernel.org/r/20240429-am62q-wip-v3-0-17dcfdb10...@ti.com

Changes in v3:
- actually update the copyright year
- Link to v2: 
https://lore.kernel.org/r/20240429-am62q-wip-v2-0-e78f09174...@ti.com

Changes in v2:
- updated copyright year
- Link to v1: 
https://lore.kernel.org/r/20240429-am62q-wip-v1-0-927fd2e0a...@ti.com

---
Bryan Brattlof (1):
  configs: add defconfigs for the am625-lp-sk

Nitin Yadav (1):
  arm: dts: add U-Boot dtbs for the am625-lp-sk

 arch/arm/dts/k3-am62-lp-sk-binman.dtsi   |   21 +
 arch/arm/dts/k3-am62-lp-sk-u-boot.dtsi   |   17 +
 arch/arm/dts/k3-am62-lp4-50-800-800.dtsi | 2190 ++
 arch/arm/dts/k3-am62-r5-lp-sk.dts|   82 ++
 board/ti/am62x/MAINTAINERS   |4 +-
 configs/am62x_lpsk_a53_defconfig |8 +
 configs/am62x_lpsk_r5_defconfig  |7 +
 7 files changed, 2328 insertions(+), 1 deletion(-)
---
base-commit: 227be29df37545f74243a98c12a4a33c4160e3cd
change-id: 20240429-am62q-wip-f3453de038fb

Best regards,
-- 
Bryan Brattlof 



[PATCH v4 2/2] configs: add defconfigs for the am625-lp-sk

2024-06-07 Thread Bryan Brattlof
The am62x-lp-sk is a package and reference board spin of the am62x-sk to
showcase the low-power features of the am62x SoC family. Because it so
closely resembles the am62x-sk board, use the preprocessor to inherit
its configuration making the needed changes for this board where
necessary.

Reviewed-by: Dhruva Gole 
Signed-off-by: Bryan Brattlof 
---
 board/ti/am62x/MAINTAINERS   | 4 +++-
 configs/am62x_lpsk_a53_defconfig | 8 
 configs/am62x_lpsk_r5_defconfig  | 7 +++
 3 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/board/ti/am62x/MAINTAINERS b/board/ti/am62x/MAINTAINERS
index 105e741995ed9..562a5c676690d 100644
--- a/board/ti/am62x/MAINTAINERS
+++ b/board/ti/am62x/MAINTAINERS
@@ -1,8 +1,10 @@
 AM62x BOARD
-M: Dave Gerlach 
+M: Bryan Brattlof 
 M: Tom Rini 
 S: Maintained
 F: board/ti/am62x/
 F: include/configs/am62x_evm.h
 F: configs/am62x_evm_r5_defconfig
 F: configs/am62x_evm_a53_defconfig
+F: configs/am62x_lpsk_r5_defconfig
+F: configs/am62x_lpsk_a53_defconfig
diff --git a/configs/am62x_lpsk_a53_defconfig b/configs/am62x_lpsk_a53_defconfig
new file mode 100644
index 0..a86bfb5a761bf
--- /dev/null
+++ b/configs/am62x_lpsk_a53_defconfig
@@ -0,0 +1,8 @@
+#include 
+
+CONFIG_ARM=y
+CONFIG_ARCH_K3=y
+CONFIG_DEFAULT_DEVICE_TREE="ti/k3-am62-lp-sk"
+CONFIG_OF_UPSTREAM=y
+CONFIG_SOC_K3_AM625=y
+CONFIG_TARGET_AM625_A53_EVM=y
diff --git a/configs/am62x_lpsk_r5_defconfig b/configs/am62x_lpsk_r5_defconfig
new file mode 100644
index 0..9112bc2cba7cc
--- /dev/null
+++ b/configs/am62x_lpsk_r5_defconfig
@@ -0,0 +1,7 @@
+#include 
+
+CONFIG_ARM=y
+CONFIG_ARCH_K3=y
+CONFIG_DEFAULT_DEVICE_TREE="k3-am62-r5-lp-sk"
+CONFIG_SOC_K3_AM625=y
+CONFIG_TARGET_AM625_R5_EVM=y

-- 
2.45.1



Re: [PATCH] memory: ti-gpmc: use printf to dump settings/timings

2024-06-07 Thread Tom Rini
On Wed, 15 May 2024 15:20:08 +0300, Roger Quadros wrote:

> pr_info() depends on CONFIG_LOGLEVEL > 6. If user has
> enabled CONFIG_TI_GPMC_DEBUG then we should print the
> GPMC settings/timings regardless of CONFIG_LOGLEVEL.
> 
> So use printf() instead of pr_info().
> 
> 
> [...]

Applied to u-boot/next, thanks!

-- 
Tom




Re: [PATCH] include: extension_board: Increase overlay file name size

2024-06-07 Thread Tom Rini
On Wed, 22 May 2024 00:21:00 -0700, Daniel Schultz wrote:

> Upstream overlays like the ARM64 TI
> k3-am625-beagleplay-csi2-tevi-ov5640.dtso can easily have more then
> 32 characters. Increase the overlay length to 64 characters to
> apply overlays with longer names.
> 
> 

Applied to u-boot/next, thanks!

-- 
Tom




Re: [PATCH v2 0/5] *** phyCORE-AM62x: DDR detection / Inject DDR timing deltas ***

2024-06-07 Thread Tom Rini
On Wed, 22 May 2024 09:55:00 +0200, Wadim Egorov wrote:

> Changes in v2:
>   - Reabse to current next
>   - Add Tested-by: John Ma 
>   - Add Kconfig option to select RAM size statically
>   - Make board/phytec/common/k3 always compile for CONFIG_ARCH_K3
> 
> v1: https://lists.denx.de/pipermail/u-boot/2024-May/553057.html
> 
> [...]

Applied to u-boot/next, thanks!

-- 
Tom




Re: [PATCH 0/6] PHYTEC SOM Detection API v3

2024-06-07 Thread Tom Rini
On Tue, 21 May 2024 23:18:21 -0700, Daniel Schultz wrote:

> This patch series adds support for the EEPROM v3 API.
> 
> V3 is backwards compatible to V2 and therefore, the V2 image still
> exists at the beginning. Only the API version changed from 2 to 3.
> 
> V3 is a block-based memory layout organized as singled-linked list
> with different types of blocks. This is a more flexible approach and
> allows us to extend it by more block types in the future.
> 
> [...]

Applied to u-boot/next, thanks!

-- 
Tom




Re: [PATCH 0/2] Add remoteproc support for J784S4 SoCs

2024-06-07 Thread Tom Rini
On Wed, 22 May 2024 10:23:29 +0530, Beleswar Padhi wrote:

> This series adds remoteproc support for TI's J784S4 SoCs. The K3 J784S4
> SoCs have four dual-core R5F subsystems and four C71x DSP subsystems.
> Enable the remoteproc drivers in defconfig and set the rproc firmware
> names to add remoteproc support.
> 
> Note: No driver changes are required as J784S4 SoCs have the same data
> as J721S2 SoCs. Thus, utilize the existing compatible string for driver
> probe.
> 
> [...]

Applied to u-boot/next, thanks!

-- 
Tom




Re: [PATCH 0/4] Adding support to load secure firmware for HS devices

2024-06-07 Thread Tom Rini
On Tue, 21 May 2024 16:26:44 +0530, Udit Kumar wrote:

> Some use case needs rproc firmware to be loaded at u-boot stage,
> using following commands at u-boot shell, firmware could be loaded
> 
> => setenv dorprocboot 1
> => run boot_rprocs
> 
> For Secure devices, secure version of rproc firmware should be loaded,
> which is appended by sec keyword[0].
> but currently non-secure firmware is loaded even for secure devices.
> So adding support for loading secure firmware on Secured devices.
> 
> [...]

Applied to u-boot/next, thanks!

-- 
Tom




Re: [PATCH 0/3] k3-j721e: Enable OF_UPSTREAM for J721E

2024-06-07 Thread Tom Rini
On Mon, 20 May 2024 15:29:13 +0530, Neha Malcom Francis wrote:

> This series was plucked out from the larger series [1] that did some
> templating reformatting and also enabled OF_UPSTREAM for J721E. The
> former has been kept aside till all the platforms affected have moved to
> using OF_UPSTREAM to have less conflicts while merging.
> 
> Patches split J721E EVM and J721E SK to using separate builds, as well
> as enable OF_UPSTREAM for both the platforms.
> 
> [...]

Applied to u-boot/next, thanks!

-- 
Tom




Re: [PATCH v1 0/2] arm: dts: k3-am625-verdin: Enable LPDDR4 WDQS control

2024-06-07 Thread Tom Rini
On Wed, 15 May 2024 10:00:56 +0200, Emanuele Ghidoli wrote:

> From: Emanuele Ghidoli 
> 
> Manually, since SysConfig tool do not have the relevant option,
> set PHY_LP4_WDQS_OE_EXTEND to 1.
> Since WDQS control mode is required on our modules LPDDR4,
> this enables WDQS control mode 1.
> 
> [...]

Applied to u-boot/next, thanks!

-- 
Tom




Re: [PATCH v2 3/3] doc: arch: arm64: describe pagetable debugging

2024-06-07 Thread Tom Rini
On Fri, Jun 07, 2024 at 10:42:51PM +0200, Caleb Connolly wrote:
> Add some brief documentation on using dump_pagetables() to print out
> U-Boot's pagetables during boot.
> 
> Signed-off-by: Caleb Connolly 
> ---
>  doc/arch/arm64.rst | 37 +
>  1 file changed, 37 insertions(+)
> 
> diff --git a/doc/arch/arm64.rst b/doc/arch/arm64.rst
> index 7c0713504c47..0c851304aad4 100644
> --- a/doc/arch/arm64.rst
> +++ b/doc/arch/arm64.rst
> @@ -47,8 +47,45 @@ Notes
>  
>  6. CONFIG_ARM64 instead of CONFIG_ARMV8 is used to distinguish aarch64 and
> aarch32 specific codes.
>  
> +MMU
> +---
> +
> +U-Boot uses a simple page table for MMU setup. It uses the smallest number 
> of bits
> +possible for the virtual address based on the maximum memory address (see 
> the logic
> +in ``get_tcr()``).
> +
> +As with all platforms, U-Boot on ARM64 uses a 1:1 mapping of virtual to 
> physical addresses.
> +In general, the memory map is expected to remain static once the MMU is 
> enabled.
> +
> +It is possible to debug the pagetable generated by U-Boot with the built in
> +``dump_pagetable()`` and ``walk_pagetable()`` functions (the former being a 
> simple
> +wrapper for the latter). For example the following can be added to 
> ``setup_all_pgtables()``
> +after the first call to ``setup_pgtables()``:
> +
> +.. code-block:: c
> +
> +dump_pagetable(gd->arch.tlb_addr, get_tcr(NULL, NULL));
> +
> +This will result in a print like the following:
> +
> +.. code-block:: text
> +
> +Walking pagetable at 00017df9, va_bits: 36. Using 3 levels
> +[0x17df91000]   |  Table |   |
> +  [0x17df92000] |  Table |   |
> +[0x01000 - 0x00020] |  Pages | Device-nGnRnE | Non-shareable
> +  [0x00020 - 0x04000]   |  Block | Device-nGnRnE | Non-shareable
> +[0x04000 - 0x08000] |  Block | Device-nGnRnE | Non-shareable
> +[0x08000 - 0x14000] |  Block | Normal| 
> Inner-shareable
> +[0x17df93000]   |  Table |   |
> +  [0x14000 - 0x17de0]   |  Block | Normal| 
> Inner-shareable
> +  [0x17df94000] |  Table |   |
> +[0x17de0 - 0x17dfa] |  Pages | Normal| 
> Inner-shareable
> +
> +For more information, please refer to the function documentation in
> +``arch/arm/include/asm/armv8/mmu.h``.

Since the function comments are kernel-doc style, can you please rework
this to leverage "kernel-doc::" and make sure it renders nicely? And
this may show we should be putting some function comments in 2/3 of this
series as well.

-- 
Tom


signature.asc
Description: PGP signature


[PATCH v2 3/3] doc: arch: arm64: describe pagetable debugging

2024-06-07 Thread Caleb Connolly
Add some brief documentation on using dump_pagetables() to print out
U-Boot's pagetables during boot.

Signed-off-by: Caleb Connolly 
---
 doc/arch/arm64.rst | 37 +
 1 file changed, 37 insertions(+)

diff --git a/doc/arch/arm64.rst b/doc/arch/arm64.rst
index 7c0713504c47..0c851304aad4 100644
--- a/doc/arch/arm64.rst
+++ b/doc/arch/arm64.rst
@@ -47,8 +47,45 @@ Notes
 
 6. CONFIG_ARM64 instead of CONFIG_ARMV8 is used to distinguish aarch64 and
aarch32 specific codes.
 
+MMU
+---
+
+U-Boot uses a simple page table for MMU setup. It uses the smallest number of 
bits
+possible for the virtual address based on the maximum memory address (see the 
logic
+in ``get_tcr()``).
+
+As with all platforms, U-Boot on ARM64 uses a 1:1 mapping of virtual to 
physical addresses.
+In general, the memory map is expected to remain static once the MMU is 
enabled.
+
+It is possible to debug the pagetable generated by U-Boot with the built in
+``dump_pagetable()`` and ``walk_pagetable()`` functions (the former being a 
simple
+wrapper for the latter). For example the following can be added to 
``setup_all_pgtables()``
+after the first call to ``setup_pgtables()``:
+
+.. code-block:: c
+
+dump_pagetable(gd->arch.tlb_addr, get_tcr(NULL, NULL));
+
+This will result in a print like the following:
+
+.. code-block:: text
+
+Walking pagetable at 00017df9, va_bits: 36. Using 3 levels
+[0x17df91000]   |  Table |   |
+  [0x17df92000] |  Table |   |
+[0x01000 - 0x00020] |  Pages | Device-nGnRnE | Non-shareable
+  [0x00020 - 0x04000]   |  Block | Device-nGnRnE | Non-shareable
+[0x04000 - 0x08000] |  Block | Device-nGnRnE | Non-shareable
+[0x08000 - 0x14000] |  Block | Normal| Inner-shareable
+[0x17df93000]   |  Table |   |
+  [0x14000 - 0x17de0]   |  Block | Normal| Inner-shareable
+  [0x17df94000] |  Table |   |
+[0x17de0 - 0x17dfa] |  Pages | Normal| Inner-shareable
+
+For more information, please refer to the function documentation in
+``arch/arm/include/asm/armv8/mmu.h``.
 
 Contributors
 
* Tom Rini

-- 
2.45.0



[PATCH v2 2/3] arm64: add software pagetable walker

2024-06-07 Thread Caleb Connolly
Add a basic software implementation of the ARM64 pagetable walker. This
can be used for debugging U-Boot's pagetable, as well as dumping the
pagetable from the previous bootloader stage if it used one (by reading
out the ttbr address).

One can either call dump_pagetable() to print the pagetable to the
console with the default formatter, or implement their own pagetable
handler using walke_pagetable() with a custom pte_walker_cb_t callback.

All of the added code is discarded when unused, hence there is no need
to add an additional Kconfig option for this.

Signed-off-by: Caleb Connolly 
---
 arch/arm/cpu/armv8/cache_v8.c| 202 +++
 arch/arm/include/asm/armv8/mmu.h |  55 +++
 2 files changed, 257 insertions(+)

diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
index d4c64f2d60d9..cb7c0e61ba70 100644
--- a/arch/arm/cpu/armv8/cache_v8.c
+++ b/arch/arm/cpu/armv8/cache_v8.c
@@ -395,8 +395,210 @@ static int count_ranges(void)
 
return count;
 }
 
+#define ALL_ATTRS (3 << 8 | PMD_ATTRINDX_MASK)
+#define PTE_IS_TABLE(pte, level) (pte_type(&(pte)) == PTE_TYPE_TABLE && 
(level) < 3)
+
+enum walker_state {
+   WALKER_STATE_START = 0,
+   WALKER_STATE_TABLE,
+   WALKER_STATE_REGION, /* block or page, depending on level */
+};
+
+static void __pagetable_walk(u64 addr, u64 tcr, int level, pte_walker_cb_t cb, 
void *priv)
+{
+   u64 *table = (u64 *)addr;
+   u64 attrs, last_attrs = 0, last_addr = 0, entry_start = 0;
+   int i;
+   u64 va_bits = 64 - (tcr & (BIT(6) - 1));
+   static enum walker_state state[4] = { 0 };
+   static bool exit;
+
+   if (!level) {
+   exit = false;
+   if (va_bits < 39)
+   level = 1;
+   }
+
+   state[level] = WALKER_STATE_START;
+
+   /* Walk through the table entries */
+   for (i = 0; i < MAX_PTE_ENTRIES; i++) {
+   u64 pte = table[i];
+   u64 _addr = pte & GENMASK_ULL(va_bits, PAGE_SHIFT);
+
+   if (exit)
+   return;
+
+   if (pte_type() == PTE_TYPE_FAULT)
+   continue;
+
+   attrs = pte & ALL_ATTRS;
+   /* If we're currently inside a block or set of pages */
+   if (state[level] > WALKER_STATE_START && state[level] != 
WALKER_STATE_TABLE) {
+   /*
+* Continue walking if this entry has the same 
attributes as the last and
+* is one page/block away -- it's a contiguous region.
+*/
+   if (attrs == last_attrs && _addr == last_addr + (1 << 
level2shift(level))) {
+   last_attrs = attrs;
+   last_addr = _addr;
+   continue;
+   } else {
+   /* We either hit a table or a new region */
+   exit = cb(entry_start, last_addr + (1 << 
level2shift(level)),
+ va_bits, level, priv);
+   if (exit)
+   return;
+   state[level] = WALKER_STATE_START;
+   }
+   }
+   last_attrs = attrs;
+   last_addr = _addr;
+
+   if (PTE_IS_TABLE(pte, level)) {
+   /* After the end of the table might be corrupted data */
+   if (!_addr || (pte & 0xfff) > 0x3ff)
+   return;
+   state[level] = WALKER_STATE_TABLE;
+   /* Signify the start of a table */
+   exit = cb(pte, 0, va_bits, level, priv);
+   if (exit)
+   return;
+
+   /* Go down a level */
+   __pagetable_walk(_addr, tcr, level + 1, cb, priv);
+   state[level] = WALKER_STATE_START;
+   } else if (pte_type() == PTE_TYPE_BLOCK || pte_type() 
== PTE_TYPE_PAGE) {
+   /* We foud a block or page, start walking */
+   entry_start = pte;
+   state[level] = WALKER_STATE_REGION;
+   }
+   }
+
+   if (state[level] > WALKER_STATE_START)
+   exit = cb(entry_start, last_addr + (1 << level2shift(level)), 
va_bits, level, priv);
+}
+
+static void pretty_print_pte_type(u64 pte)
+{
+   switch (pte_type()) {
+   case PTE_TYPE_FAULT:
+   printf(" %-5s", "Fault");
+   break;
+   case PTE_TYPE_BLOCK:
+   printf(" %-5s", "Block");
+   break;
+   case PTE_TYPE_PAGE:
+   printf(" %-5s", "Pages");
+   break;
+   default:
+   printf(" %-5s", "Unk");
+   }
+}
+
+static void 

[PATCH v2 1/3] arm64: mmu.h: fix PTE_TABLE_AP

2024-06-07 Thread Caleb Connolly
The APTable attribute is two bits wide according to the ARMv8-A
architecture reference manual. Fix the macro accordingly.

Signed-off-by: Caleb Connolly 
---
 arch/arm/include/asm/armv8/mmu.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/armv8/mmu.h b/arch/arm/include/asm/armv8/mmu.h
index ce655ce7a952..52cb18b9ed5e 100644
--- a/arch/arm/include/asm/armv8/mmu.h
+++ b/arch/arm/include/asm/armv8/mmu.h
@@ -50,9 +50,9 @@
 #define PTE_TYPE_VALID (1 << 0)
 
 #define PTE_TABLE_PXN  (1UL << 59)
 #define PTE_TABLE_XN   (1UL << 60)
-#define PTE_TABLE_AP   (1UL << 61)
+#define PTE_TABLE_AP   (3UL << 61)
 #define PTE_TABLE_NS   (1UL << 63)
 
 /*
  * Block

-- 
2.45.0



[PATCH v2 0/3] arm64: add a software pagetable walker

2024-06-07 Thread Caleb Connolly
MMU issues are some of the most frustrating to debug. To make this
slightly less unbearable, introduce a software pagetable walker for
ARMv8. This can be called to dump a pagetable with the default
formatter, or a custom callback can be provided to implement more
complicated parsing.

This can also be useful to dump the pagetable used by a previous
bootloader stage (by reading out the ttbr register).

Here is an example of the output when walking U-Boot's own memory map
on a Qualcomm RB3 board:

Walking pagetable at 00017df9, va_bits: 36. Using 3 levels
[0x17df91000]   |  Table |   |
  [0x17df92000] |  Table |   |
[0x01000 - 0x00020] |  Pages | Device-nGnRnE | Non-shareable
  [0x00020 - 0x04000]   |  Block | Device-nGnRnE | Non-shareable
[0x04000 - 0x08000] |  Block | Device-nGnRnE | Non-shareable
[0x08000 - 0x14000] |  Block | Normal| Inner-shareable
[0x17df93000]   |  Table |   |
  [0x14000 - 0x17de0]   |  Block | Normal| Inner-shareable
  [0x17df94000] |  Table |   |
[0x17de0 - 0x17dfa] |  Pages | Normal| Inner-shareable

---
Changes in v2:
- Document the MMU debugging features in doc/arch/arm64.rst
- Mention that functions are stripped out when unused.
- Link to v1: 
https://lore.kernel.org/r/20240607-caleb-upstreaming-v1-0-99094dabb...@linaro.org

---
Caleb Connolly (3):
  arm64: mmu.h: fix PTE_TABLE_AP
  arm64: add software pagetable walker
  doc: arch: arm64: describe pagetable debugging

 arch/arm/cpu/armv8/cache_v8.c| 202 +++
 arch/arm/include/asm/armv8/mmu.h |  57 ++-
 doc/arch/arm64.rst   |  37 +++
 3 files changed, 295 insertions(+), 1 deletion(-)
---
change-id: 20240607-caleb-upstreaming-82744a2786b3
base-commit: 22ca7e13dc02be83c29450aeadd8e150ebdd

// Caleb (they/them)



[PATCH v2 1/2] board: rockchip: Add FriendlyElec NanoPi R6C

2024-06-07 Thread Sebastian Kropatsch
The NanoPi R6C is a SBC by FriendlyElec based on the Rockchip RK3588s.
It comes with 4GB or 8GB of RAM, a microSD card slot, optional 32GB eMMC
storage, one M.2 M-Key connector, one RTL8211F 1GbE and one RTL8125
2.5GbE Ethernet port, one USB 2.0 Type-A and one USB 3.0 Type-A port, a
HDMI port, a 30-pin GPIO header as well as multiple buttons and LEDs.

Add initial support for this board using the upstream devicetree sources.

Tests in U-Boot proper:
- Booting from eMMC works
- 1GbE Ethernet works using the eth_eqos driver (tested by ping)
- 2.5GbE Ethernet works using the eth_rtl8169 driver (tested by ping),
  but the status LEDs on this specific port currently aren't working
- NVMe SSD in M.2 socket does get recognized (tested with `nvme scan`
  followed by `nvme details`)

Kernel commit:
d5f1d7437451 ("arm64: dts: rockchip: Add support for NanoPi R6C")

Signed-off-by: Sebastian Kropatsch 
Reviewed-by: Quentin Schulz 
---

Changes v1 -> v2:

- Add missing 'S' to 'RK3588S' symbols
- Add similar board NanoPi R6S (new patch)
- Collect r-b tag from Quentin Schulz for patch 1
- Link to v1: 
https://lore.kernel.org/u-boot/20240605155413.226629-1-seb-...@mail.de/

Hello!

The Ethernet status LEDs which sit directly on the 2.5GbE port using the
RTL8169 driver don't light up when connected and I couldn't figure out
why. The other port with a RTL8211F has no problems with the LEDs.
Have there been occurrences like this in combination with the RTL8125?
I'm trying to figure out if this is something that could be solved in
the devicetree or if this is a potential driver bug.

Secondly, the default active network device in U-Boot is the 1GbE one.
I believe it would make sense to make the 2.5GbE device the default
active one since this one is labeled "LAN", whereas the 1GbE is labeled
"WAN". However, since the 2.5GbE device is PCIe-based, it only shows up
in U-Boot proper after using the `pci enum` command (shows up as in gets
listed in `net list` and `dm tree`).
Do you have any tips on the preferred approach to handle this switch of
the default active net device? Is this even a sensible thing to include
in U-Boot in your opinion?

Thanks for your feedback!

Cheers,
Sebastian

---
 arch/arm/dts/rk3588s-nanopi-r6c-u-boot.dtsi   |  3 +
 arch/arm/mach-rockchip/rk3588/Kconfig | 13 +++
 board/friendlyelec/nanopi-r6c-rk3588s/Kconfig | 12 +++
 .../nanopi-r6c-rk3588s/MAINTAINERS|  7 ++
 configs/nanopi-r6c-rk3588s_defconfig  | 83 +++
 doc/board/rockchip/rockchip.rst   |  1 +
 include/configs/nanopi-r6c-rk3588s.h  | 12 +++
 7 files changed, 131 insertions(+)
 create mode 100644 arch/arm/dts/rk3588s-nanopi-r6c-u-boot.dtsi
 create mode 100644 board/friendlyelec/nanopi-r6c-rk3588s/Kconfig
 create mode 100644 board/friendlyelec/nanopi-r6c-rk3588s/MAINTAINERS
 create mode 100644 configs/nanopi-r6c-rk3588s_defconfig
 create mode 100644 include/configs/nanopi-r6c-rk3588s.h

diff --git a/arch/arm/dts/rk3588s-nanopi-r6c-u-boot.dtsi 
b/arch/arm/dts/rk3588s-nanopi-r6c-u-boot.dtsi
new file mode 100644
index 00..853ed58cfe
--- /dev/null
+++ b/arch/arm/dts/rk3588s-nanopi-r6c-u-boot.dtsi
@@ -0,0 +1,3 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include "rk3588s-u-boot.dtsi"
diff --git a/arch/arm/mach-rockchip/rk3588/Kconfig 
b/arch/arm/mach-rockchip/rk3588/Kconfig
index 820e979abb..4b7d751c6f 100644
--- a/arch/arm/mach-rockchip/rk3588/Kconfig
+++ b/arch/arm/mach-rockchip/rk3588/Kconfig
@@ -78,6 +78,18 @@ config TARGET_NANOPCT6_RK3588
  Power: 5.5*2.1mm DC Jack, 12VDC input
  Dimensions: 110x80x1.6mm (without case) / 86x114.5x30mm (with case)
 
+config TARGET_NANOPI_R6C_RK3588S
+   bool "FriendlyElec NanoPi R6C"
+   select BOARD_LATE_INIT
+   help
+ The NanoPi R6C is a SBC by FriendlyElec based on the Rockchip
+ RK3588s.
+ It comes with 4GB or 8GB of RAM, a microSD card slot, optional 32GB
+ eMMC storage, one M.2 M-Key connector, one RTL8211F 1GbE and one
+ RTL8125 2.5GbE Ethernet port, one USB 2.0 Type-A and one USB 3.0
+ Type-A port, a HDMI port, a 30-pin GPIO header as well as some
+ buttons and LEDs.
+
 config TARGET_NOVA_RK3588
bool "Indiedroid Nova RK3588"
select BOARD_LATE_INIT
@@ -232,6 +244,7 @@ config TEXT_BASE
 
 source "board/edgeble/neural-compute-module-6/Kconfig"
 source "board/friendlyelec/nanopc-t6-rk3588/Kconfig"
+source "board/friendlyelec/nanopi-r6c-rk3588s/Kconfig"
 source "board/indiedroid/nova/Kconfig"
 source "board/pine64/quartzpro64-rk3588/Kconfig"
 source "board/turing/turing-rk1-rk3588/Kconfig"
diff --git a/board/friendlyelec/nanopi-r6c-rk3588s/Kconfig 
b/board/friendlyelec/nanopi-r6c-rk3588s/Kconfig
new file mode 100644
index 00..2d8acbf62f
--- /dev/null
+++ b/board/friendlyelec/nanopi-r6c-rk3588s/Kconfig
@@ -0,0 +1,12 @@
+if TARGET_NANOPI_R6C_RK3588S
+
+config SYS_BOARD
+   default "nanopi-r6c-rk3588s"
+
+config SYS_VENDOR
+  

[PATCH v2 2/2] board: rockchip: Add FriendlyElec NanoPi R6S

2024-06-07 Thread Sebastian Kropatsch
The NanoPi R6S is a SBC by FriendlyElec based on the Rockchip RK3588s.
It comes with 4GB or 8GB of RAM, a microSD card slot, 32GB eMMC storage,
one RTL8211F 1GbE and two RTL8125 2.5GbE Ethernet ports, one USB 2.0
Type-A and one USB 3.0 Type-A port, a HDMI port, a 12-pin GPIO FPC
connector, a fan connector, IR receiver as well as some buttons and LEDs.

Add initial support for this board using the upstream devicetree sources.

Kernel commit:
f1b11f43b3e9 ("arm64: dts: rockchip: Add support for NanoPi R6S")

Signed-off-by: Sebastian Kropatsch 
---

The R6S is very similar to the R6C, the major difference being that
instead of the M.2 NVMe socket on the R6C, the R6S has a second RTL8125BG
Ethernet chip, which uses the same PCIe lanes that the R6C uses for its
M.2 socket. Other minor differences include:
- 12-pin GPIO FPC instead of 30-pin header
- IR receiver (pwm-based)
- 5V fan connector
Other than that, they are the same, which is why the difference in
U-Boot is only the missing NVME config option in the R6S defconfig.

Please note that I was not able to test this device. I only chose to
add it due to it being a very similar implementation to the R6C, like the
NanoPi R5C and R5S are similar. It should however boot just fine and even
both RTL8125 Ethernet ports should work in U-Boot since RTL8125 is the
same chip used in the R6C, using the rtl8169 driver.

If this is not how things should be done in U-Boot, please disregard
and drop this patch :) Thanks!

---
 arch/arm/dts/rk3588s-nanopi-r6s-u-boot.dtsi   |  3 +
 arch/arm/mach-rockchip/rk3588/Kconfig | 12 +++
 board/friendlyelec/nanopi-r6s-rk3588s/Kconfig | 12 +++
 .../nanopi-r6s-rk3588s/MAINTAINERS|  7 ++
 configs/nanopi-r6s-rk3588s_defconfig  | 82 +++
 doc/board/rockchip/rockchip.rst   |  1 +
 include/configs/nanopi-r6s-rk3588s.h  | 12 +++
 7 files changed, 129 insertions(+)
 create mode 100644 arch/arm/dts/rk3588s-nanopi-r6s-u-boot.dtsi
 create mode 100644 board/friendlyelec/nanopi-r6s-rk3588s/Kconfig
 create mode 100644 board/friendlyelec/nanopi-r6s-rk3588s/MAINTAINERS
 create mode 100644 configs/nanopi-r6s-rk3588s_defconfig
 create mode 100644 include/configs/nanopi-r6s-rk3588s.h

diff --git a/arch/arm/dts/rk3588s-nanopi-r6s-u-boot.dtsi 
b/arch/arm/dts/rk3588s-nanopi-r6s-u-boot.dtsi
new file mode 100644
index 00..853ed58cfe
--- /dev/null
+++ b/arch/arm/dts/rk3588s-nanopi-r6s-u-boot.dtsi
@@ -0,0 +1,3 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include "rk3588s-u-boot.dtsi"
diff --git a/arch/arm/mach-rockchip/rk3588/Kconfig 
b/arch/arm/mach-rockchip/rk3588/Kconfig
index 4b7d751c6f..a9e400861a 100644
--- a/arch/arm/mach-rockchip/rk3588/Kconfig
+++ b/arch/arm/mach-rockchip/rk3588/Kconfig
@@ -90,6 +90,18 @@ config TARGET_NANOPI_R6C_RK3588S
  Type-A port, a HDMI port, a 30-pin GPIO header as well as some
  buttons and LEDs.
 
+config TARGET_NANOPI_R6S_RK3588S
+   bool "FriendlyElec NanoPi R6S"
+   select BOARD_LATE_INIT
+   help
+ The NanoPi R6S is a SBC by FriendlyElec based on the Rockchip
+ RK3588s.
+ It comes with 4GB or 8GB of RAM, a microSD card slot, 32GB eMMC
+ storage, one RTL8211F 1GbE and two RTL8125 2.5GbE Ethernet ports,
+ one USB 2.0 Type-A and one USB 3.0 Type-A port, a HDMI port, a
+ 12-pin GPIO FPC connector, a fan connector, IR receiver as well
+ as some buttons and LEDs.
+
 config TARGET_NOVA_RK3588
bool "Indiedroid Nova RK3588"
select BOARD_LATE_INIT
diff --git a/board/friendlyelec/nanopi-r6s-rk3588s/Kconfig 
b/board/friendlyelec/nanopi-r6s-rk3588s/Kconfig
new file mode 100644
index 00..4d579816b1
--- /dev/null
+++ b/board/friendlyelec/nanopi-r6s-rk3588s/Kconfig
@@ -0,0 +1,12 @@
+if TARGET_NANOPI_R6S_RK3588S
+
+config SYS_BOARD
+   default "nanopi-r6s-rk3588s"
+
+config SYS_VENDOR
+   default "friendlyelec"
+
+config SYS_CONFIG_NAME
+   default "nanopi-r6s-rk3588s"
+
+endif
diff --git a/board/friendlyelec/nanopi-r6s-rk3588s/MAINTAINERS 
b/board/friendlyelec/nanopi-r6s-rk3588s/MAINTAINERS
new file mode 100644
index 00..76288b4320
--- /dev/null
+++ b/board/friendlyelec/nanopi-r6s-rk3588s/MAINTAINERS
@@ -0,0 +1,7 @@
+NANOPI-R6S
+M: Sebastian Kropatsch 
+S: Maintained
+F: arch/arm/dts/rk3588s-nanopi-r6s-u-boot.dtsi
+F: board/friendlyelec/nanopi-r6s-rk3588s
+F: configs/nanopi-r6s-rk3588s_defconfig
+F: include/configs/nanopi-r6s-rk3588s.h
diff --git a/configs/nanopi-r6s-rk3588s_defconfig 
b/configs/nanopi-r6s-rk3588s_defconfig
new file mode 100644
index 00..f7b364655f
--- /dev/null
+++ b/configs/nanopi-r6s-rk3588s_defconfig
@@ -0,0 +1,82 @@
+CONFIG_ARM=y
+CONFIG_SKIP_LOWLEVEL_INIT=y
+CONFIG_SYS_HAS_NONCACHED_MEMORY=y
+CONFIG_COUNTER_FREQUENCY=2400
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3588s-nanopi-r6s"
+CONFIG_ROCKCHIP_RK3588=y
+CONFIG_SPL_SERIAL=y

Re: [PATCH 2/2] arm64: add software pagetable walker

2024-06-07 Thread Caleb Connolly




On 07/06/2024 19:00, Tom Rini wrote:

On Fri, Jun 07, 2024 at 06:51:20PM +0200, Caleb Connolly wrote:


Add a basic software implementation of the ARM64 pagetable walker. This
can be used for debugging U-Boot's pagetable, as well as dumping the
pagetable from the previous bootloader stage if it used one (by reading
out the ttbr address).

One can either call dump_pagetable() to print the pagetable to the
console with the default formatter, or implement their own pagetable
handler using walke_pagetable() with a custom pte_walker_cb_t callback.

Signed-off-by: Caleb Connolly 
---
  arch/arm/cpu/armv8/cache_v8.c| 202 +++
  arch/arm/include/asm/armv8/mmu.h |  55 +++
  2 files changed, 257 insertions(+)


So, I assume that by default, all of this gets discarded as unused code
and that's why it's not behind a Kconfig. Next, please add something


Yes, a basic "strings" check on the U-Boot binary suggests this is the case.

under maybe doc/arch/ or doc/develop (I'm honestly not sure which is
best) that documents all of this. Thanks!


Sure, will try and find a suitable place for it.




--
// Caleb (they/them)


Re: [PATCH 00/11] 'eeprom' command improvements

2024-06-07 Thread Tom Rini
On Tue, 21 May 2024 09:13:24 +0200, Marek Behún wrote:

> this series contains improvements for the 'eeprom' command:
> - refactors
> - fixes
> - improvements
> - ability to use driver model EEPROMs (uclass UCLASS_I2C_EEPROM)
> - more flexible EEPROM layout support
> 
> [...]

Applied to u-boot/next, thanks!

-- 
Tom




[RFC PATCH 31/31] temp: cmd: efi: add a command to dump EFI memory map

2024-06-07 Thread Sughosh Ganu
Add a command to dump the EFI memory map.

Not for committing.

Signed-off-by: Sughosh Ganu 
---
 cmd/Makefile|  1 +
 cmd/efi_map_dump.c  | 28 
 include/efi_loader.h|  2 ++
 lib/efi_loader/efi_memory.c | 32 
 4 files changed, 63 insertions(+)
 create mode 100644 cmd/efi_map_dump.c

diff --git a/cmd/Makefile b/cmd/Makefile
index 35fcc4af5a..315046def6 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -11,6 +11,7 @@ obj-y += help.o
 obj-y += panic.o
 obj-y += version.o
 obj-y += efi_memory.o
+obj-y += efi_map_dump.o
 
 # command
 obj-$(CONFIG_CMD_ARMFFA) += armffa.o
diff --git a/cmd/efi_map_dump.c b/cmd/efi_map_dump.c
new file mode 100644
index 00..f2a5932767
--- /dev/null
+++ b/cmd/efi_map_dump.c
@@ -0,0 +1,28 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ *  Allocate and Free EFI memory
+ *
+ *  Copyright (c) 2024 Linaro Limited
+ */
+
+#include 
+#include 
+
+static int do_efi_map_dump(struct cmd_tbl *cmdtp, int flag, int argc,
+  char *const argv[])
+{
+// printf("%s: argc => %d\n", __func__, argc);
+
+   if (argc != 1)
+   return CMD_RET_USAGE;
+
+   dump_efi_memory_map();
+
+   return CMD_RET_SUCCESS;
+}
+
+U_BOOT_CMD(
+   efi_map_dump, 1, 0, do_efi_map_dump,
+   "Dump the EFI memory map",
+   ""
+);
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 9600941aa3..40f894f182 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -791,6 +791,8 @@ efi_status_t efi_get_memory_map(efi_uintn_t 
*memory_map_size,
uint32_t *descriptor_version);
 /* Adds a range into the EFI memory map */
 efi_status_t efi_add_memory_map(u64 start, u64 size, int memory_type);
+/* Dump the contents of the EFI memory map */
+void dump_efi_memory_map(void);
 /* Adds a conventional range into the EFI memory map */
 efi_status_t efi_add_conventional_memory_map(u64 ram_start, u64 ram_end,
 u64 ram_top);
diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index 93244161b0..7ab1b86140 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -47,6 +47,8 @@ static LIST_HEAD(efi_mem);
 void *efi_bounce_buffer;
 #endif
 
+static uint64_t desc_get_end(struct efi_mem_desc *desc);
+
 /**
  * struct efi_pool_allocation - memory block allocated from pool
  *
@@ -118,6 +120,36 @@ static int lmb_mem_map_update_sync(void *ctx, struct event 
*event)
 EVENT_SPY_FULL(EVT_LMB_MAP_UPDATE, lmb_mem_map_update_sync);
 #endif /* MEM_MAP_UPDATE_NOTIFY */
 
+static void dump_efi_mem_desc(struct efi_mem_desc *desc)
+{
+   u64 end;
+
+   end = desc_get_end(desc);
+
+   printf("---\n");
+   printf("Memory Range   [0x%llx - 0x%llx]\n",
+  desc->physical_start, end);
+   printf("Num Pages  [0x%llx]\n", desc->num_pages);
+   printf("Memory Type[0x%x]\n", desc->type);
+   printf("Attribute  [0x%llx]\n", desc->attribute);
+   printf("---\n");
+}
+
+void dump_efi_memory_map(void)
+{
+   struct list_head *lhandle;
+
+   list_for_each(lhandle, _mem) {
+   struct efi_mem_list *lmem;
+   struct efi_mem_desc *desc;
+
+   lmem = list_entry(lhandle, struct efi_mem_list, link);
+   desc = >desc;
+
+   dump_efi_mem_desc(desc);
+   }
+}
+
 /**
  * checksum() - calculate checksum for memory allocated from pool
  *
-- 
2.34.1



[RFC PATCH 30/31] temp: cmd: efi_mem: add a command to test efi alloc/free

2024-06-07 Thread Sughosh Ganu
Not for committing.

Signed-off-by: Sughosh Ganu 
---
 cmd/Makefile |   1 +
 cmd/efi_memory.c | 155 +++
 2 files changed, 156 insertions(+)
 create mode 100644 cmd/efi_memory.c

diff --git a/cmd/Makefile b/cmd/Makefile
index 87133cc27a..35fcc4af5a 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_CMD_BOOTM) += bootm.o
 obj-y += help.o
 obj-y += panic.o
 obj-y += version.o
+obj-y += efi_memory.o
 
 # command
 obj-$(CONFIG_CMD_ARMFFA) += armffa.o
diff --git a/cmd/efi_memory.c b/cmd/efi_memory.c
new file mode 100644
index 00..52ddcb7146
--- /dev/null
+++ b/cmd/efi_memory.c
@@ -0,0 +1,155 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ *  Allocate and Free EFI memory
+ *
+ *  Copyright (c) 2024 Linaro Limited
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+static int do_efi_mem_free(struct cmd_tbl *cmdtp, int flag, int argc,
+  char * const argv[])
+{
+   uint64_t addr = 0, size = 0;
+   efi_uintn_t pages;
+   efi_status_t status;
+
+   if (argc != 3)
+   return CMD_RET_USAGE;
+
+   argc--; argv++;
+
+   size = simple_strtoul(argv[0], NULL, 16);
+   if (!size) {
+   printf("Enter valid size for free in Hex\n");
+   return CMD_RET_USAGE;
+   }
+
+   
+   addr = simple_strtoul(argv[1], NULL, 16);
+   if (!addr) {
+   printf("Enter a valid address in Hex\n");
+   return CMD_RET_USAGE;
+   }
+
+   pages = efi_size_in_pages(size + (addr & EFI_PAGE_MASK));
+
+   status = efi_free_pages(addr, pages);
+   if (status != EFI_SUCCESS) {
+   printf("Unable to free memory, error (%#lx)\n", status);
+   return CMD_RET_FAILURE;
+   }
+
+   return CMD_RET_SUCCESS;
+}
+
+static int do_efi_mem_alloc(struct cmd_tbl *cmdtp, int flag, int argc,
+   char * const argv[])
+{
+   enum efi_allocate_type type;
+   uint64_t addr = 0, size = 0;
+   efi_uintn_t pages;
+   efi_status_t status;
+   bool max = false;
+
+   if (argc < 2)
+   return CMD_RET_USAGE;
+
+   argc--; argv++;
+
+   if (!strcmp("max", argv[0])) {
+   if (argc != 3)
+   return CMD_RET_USAGE;
+
+   max = true;
+   argv++;
+   argc--;
+   }
+
+   size = simple_strtoul(argv[0], NULL, 16);
+   if (!size) {
+   printf("Enter valid size for allocation in Hex\n");
+   return CMD_RET_USAGE;
+   }
+
+   if (max || argc == 2) {
+   addr = simple_strtoul(argv[1], NULL, 16);
+   if (!addr) {
+   printf("Enter a valid address in Hex\n");
+   return CMD_RET_USAGE;
+   }
+   }
+
+   if (max)
+   type = EFI_ALLOCATE_MAX_ADDRESS;
+   else if (addr)
+   type = EFI_ALLOCATE_ADDRESS;
+   else
+   type = EFI_ALLOCATE_ANY_PAGES;
+
+   pages = efi_size_in_pages(size + (addr & EFI_PAGE_MASK));
+   status = efi_allocate_pages(type, EFI_BOOT_SERVICES_DATA, pages,
+   );
+   if (status != EFI_SUCCESS) {
+   printf("efi_allocate_pages failed %lx\n", status);
+   return CMD_RET_FAILURE;
+   } else {
+   printf("Address returned %#llx\n", addr);
+   }
+
+   return CMD_RET_SUCCESS;
+}
+
+static struct cmd_tbl cmd_efi_mem_sub[] = {
+   U_BOOT_CMD_MKENT(alloc, 3, 0, do_efi_mem_alloc,
+   "", ""),
+   U_BOOT_CMD_MKENT(free, 2, 0, do_efi_mem_free,
+   "", ""),
+};
+
+static int do_efi_mem(struct cmd_tbl *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+   struct cmd_tbl *cp;
+   efi_status_t r;
+
+   if (argc < 3)
+   return CMD_RET_USAGE;
+
+   argc--; argv++;
+
+   /* Initialize UEFI subsystem */
+   r = efi_init_obj_list();
+   if (r != EFI_SUCCESS) {
+   printf("Error: Cannot initialize UEFI sub-system, r = %lu\n",
+  r & ~EFI_ERROR_MASK);
+   return CMD_RET_FAILURE;
+   }
+
+   cp = find_cmd_tbl(argv[0], cmd_efi_mem_sub,
+ ARRAY_SIZE(cmd_efi_mem_sub));
+   if (!cp)
+   return CMD_RET_USAGE;
+
+   return cp->cmd(cmdtp, flag, argc, argv);
+}
+
+U_BOOT_LONGHELP(efi_mem,
+   "Functions to allocate and free memory\n"
+   "\n"
+   "efi_mem alloc  [addr]\n"
+   "efi_mem alloc max  \n"
+   "efi_mem free  \n"
+   "\n"
+);
+
+U_BOOT_CMD(
+   efi_mem, CONFIG_SYS_MAXARGS, 0, do_efi_mem,
+   "Allocate and free EFI memory",
+   efi_mem_help_text
+);
-- 
2.34.1



[RFC PATCH 29/31] temp: mx6sabresd: bump up the size limit of the board

2024-06-07 Thread Sughosh Ganu
With the changes to add notifications for any changes to the LMB map,
the size of the image exceeds the limit set. Bump up the image size
limit for now to get the platform to build.

This is not for committing.

Signed-off-by: Sughosh Ganu 
---
Note: @Fabio Estevam, please check if it would be okay to increase the
board size limit. Else other ways to reduce image size will have to be
checked.

 configs/mx6sabresd_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configs/mx6sabresd_defconfig b/configs/mx6sabresd_defconfig
index 868f6b1551..7308ae2ec6 100644
--- a/configs/mx6sabresd_defconfig
+++ b/configs/mx6sabresd_defconfig
@@ -23,7 +23,7 @@ CONFIG_SPL_LIBDISK_SUPPORT=y
 CONFIG_PCI=y
 CONFIG_LTO=y
 CONFIG_HAS_BOARD_SIZE_LIMIT=y
-CONFIG_BOARD_SIZE_LIMIT=715766
+CONFIG_BOARD_SIZE_LIMIT=718108
 CONFIG_FIT=y
 CONFIG_SPL_FIT_PRINT=y
 CONFIG_SPL_LOAD_FIT=y
-- 
2.34.1



[RFC PATCH 28/31] cmd: bdinfo: only dump the current LMB memory

2024-06-07 Thread Sughosh Ganu
The LMB memory map is now persistent and global. There is therefore no
need to add memory to the LMB memory map as part of the bdinfo
command. Only dump the current available and reserved memory as part
of the bdinfo command.

Signed-off-by: Sughosh Ganu 
---
 cmd/bdinfo.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/cmd/bdinfo.c b/cmd/bdinfo.c
index fc408e9820..0f343203ef 100644
--- a/cmd/bdinfo.c
+++ b/cmd/bdinfo.c
@@ -163,7 +163,6 @@ static int bdinfo_print_all(struct bd_info *bd)
bdinfo_print_num_l("multi_dtb_fit", (ulong)gd->multi_dtb_fit);
 #endif
if (IS_ENABLED(CONFIG_LMB) && gd->fdt_blob) {
-   lmb_add_memory(gd->bd);
lmb_dump_all_force();
if (IS_ENABLED(CONFIG_OF_REAL))
printf("devicetree  = %s\n", fdtdec_get_srcname());
-- 
2.34.1



Re: [PATCH 1/3] arm: dts: k3-am642-evm-u-boot: Add remoteproc-name for PRU cores

2024-06-07 Thread Andrew Davis

On 5/23/24 1:33 AM, Anwar, Md Danish wrote:

Hi Andrew,

On 5/22/2024 9:38 PM, Andrew Davis wrote:

On 5/22/24 1:36 AM, MD Danish Anwar wrote:

Add remoteproc-name property for PRU cores.

Signed-off-by: MD Danish Anwar 
---
   arch/arm/dts/k3-am642-evm-u-boot.dtsi | 44 +++
   1 file changed, 44 insertions(+)

diff --git a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
index 705b3baa81..25ddace74e 100644
--- a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
+++ b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
@@ -11,6 +11,50 @@
   };
   };
   +_0 {
+    remoteproc-name = "pru0_0";


Why do we need all these? Looks like we fallback to using `dev->name` if
these are not set, does that not work for us here?



Yes we will fallback to `dev->name` if `remoteproc-name` is not set but
in our case two different PRU cores will have same `dev->name`. As a
result the API rproc_name_is_unique() will return false and as a result
the probe will fail for the PRU cores.



If `dev->name` is not unique, then combine it with something that is, or
remove the requirement for the name to be unique. Right now this looks
like just a hack around a framework requirement and a driver problem.

If you really think this is something that should be solved in DT then
go convince the DT maintainers and get it into the kernel DT. We should
be reducing the deltas we carry in -u-boot.dtsi files, not adding more
workarounds.

Andrew


Example: In k3-am64-main.dtsi, both pru0_0 [1] and pru1_0 [2] will have
dev->name as "pru@34000" same goes for rtu and txpru as well.

pru0_0: pru@34000 {
compatible = "ti,am642-pru";
reg = <0x34000 0x3000>,
  <0x22000 0x100>,
  <0x22400 0x100>;
reg-names = "iram", "control", "debug";
firmware-name = "am64x-pru0_0-fw";
};

pru1_0: pru@34000 {
compatible = "ti,am642-pru";
reg = <0x34000 0x4000>,
  <0x22000 0x100>,
  <0x22400 0x100>;
reg-names = "iram", "control", "debug";
firmware-name = "am64x-pru1_0-fw";
};

To avoid this, we are setting the "remoteproc-name" property in
-u-boot.dtsi. Same is done for AM65x as well [3].

[1]
https://elixir.bootlin.com/u-boot/v2024.07-rc3/source/dts/upstream/src/arm64/ti/k3-am64-main.dtsi#L1276
[2]
https://elixir.bootlin.com/u-boot/v2024.07-rc3/source/dts/upstream/src/arm64/ti/k3-am64-main.dtsi#L1417
[3]
https://elixir.bootlin.com/u-boot/v2024.07-rc3/source/arch/arm/dts/k3-am654-base-board-u-boot.dtsi#L168


Andrew


+};
+
+_0 {
+    remoteproc-name = "rtu0_0";
+};
+
+_pru0_0 {
+    remoteproc-name = "tx_pru0_0";
+};
+
+_1 {
+    remoteproc-name = "pru0_1";
+};
+
+_1 {
+    remoteproc-name = "rtu0_1";
+};
+
+_pru0_1 {
+    remoteproc-name = "tx_pru0_1";
+};
+
+_0 {
+    remoteproc-name = "pru1_0";
+};
+
+_0 {
+    remoteproc-name = "rtu1_0";
+};
+
+_pru1_0 {
+    remoteproc-name = "tx_pru1_0";
+};
+
+_1 {
+    remoteproc-name = "pru1_1";
+};
+
+_1 {
+    remoteproc-name = "rtu1_1";
+};
+
   _timer0 {
   clock-frequency = <2>;
   };




[RFC PATCH 27/31] test: bdinfo: dump the global LMB memory map

2024-06-07 Thread Sughosh Ganu
The LMB code has been changed to make the memory reservations
persistent and global. Make corresponding change the the
lmb_test_dump_all() function to print the global LMB added and
reserved memory.

Signed-off-by: Sughosh Ganu 
---
 test/cmd/bdinfo.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/test/cmd/bdinfo.c b/test/cmd/bdinfo.c
index 8ba785fc31..2f90c04b70 100644
--- a/test/cmd/bdinfo.c
+++ b/test/cmd/bdinfo.c
@@ -25,6 +25,8 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+extern struct lmb lmb;
+
 /* Declare a new bdinfo test */
 #define BDINFO_TEST(_name, _flags) UNIT_TEST(_name, _flags, bdinfo_test)
 
@@ -125,11 +127,11 @@ static int lmb_test_dump_region(struct unit_test_state 
*uts,
return 0;
 }
 
-static int lmb_test_dump_all(struct unit_test_state *uts, struct lmb *lmb)
+static int lmb_test_dump_all(struct unit_test_state *uts)
 {
ut_assert_nextline("lmb_dump_all:");
-   ut_assertok(lmb_test_dump_region(uts, >memory, "memory"));
-   ut_assertok(lmb_test_dump_region(uts, >reserved, "reserved"));
+   ut_assertok(lmb_test_dump_region(uts, , "memory"));
+   ut_assertok(lmb_test_dump_region(uts, , "reserved"));
 
return 0;
 }
@@ -191,10 +193,8 @@ static int bdinfo_test_all(struct unit_test_state *uts)
 #endif
 
if (IS_ENABLED(CONFIG_LMB) && gd->fdt_blob) {
-   struct lmb lmb;
-
lmb_add_memory(gd->bd);
-   ut_assertok(lmb_test_dump_all(uts, ));
+   ut_assertok(lmb_test_dump_all(uts));
if (IS_ENABLED(CONFIG_OF_REAL))
ut_assert_nextline("devicetree  = %s", 
fdtdec_get_srcname());
}
-- 
2.34.1



[RFC PATCH 26/31] test: lmb: run lmb tests only manually

2024-06-07 Thread Sughosh Ganu
The LMB code has been changed so that the memory reservations and
allocations are now persistent and global. With this change, the
design of the LMB tests needs to be changed accordingly. For now, mark
the LMB tests to be run only manually. The tests won't be run as part
of the unit test suite, and thus would not interfere with the running
of the rest of the tests.

Signed-off-by: Sughosh Ganu 
---
 test/lib/lmb.c | 49 -
 1 file changed, 24 insertions(+), 25 deletions(-)

diff --git a/test/lib/lmb.c b/test/lib/lmb.c
index 67a6be5bc3..813f7e3100 100644
--- a/test/lib/lmb.c
+++ b/test/lib/lmb.c
@@ -195,7 +195,7 @@ static int test_multi_alloc_512mb_x2(struct unit_test_state 
*uts,
 }
 
 /* Create a memory region with one reserved region and allocate */
-static int lib_test_lmb_simple(struct unit_test_state *uts)
+static int lib_test_lmb_simple_norun(struct unit_test_state *uts)
 {
int ret;
 
@@ -207,10 +207,10 @@ static int lib_test_lmb_simple(struct unit_test_state 
*uts)
/* simulate 512 MiB RAM beginning at 1.5GiB */
return test_multi_alloc_512mb(uts, 0xE000);
 }
-LIB_TEST(lib_test_lmb_simple, 0);
+LIB_TEST(lib_test_lmb_simple_norun, UT_TESTF_MANUAL);
 
 /* Create two memory regions with one reserved region and allocate */
-static int lib_test_lmb_simple_x2(struct unit_test_state *uts)
+static int lib_test_lmb_simple_x2_norun(struct unit_test_state *uts)
 {
int ret;
 
@@ -222,7 +222,7 @@ static int lib_test_lmb_simple_x2(struct unit_test_state 
*uts)
/* simulate 512 MiB RAM beginning at 3.5GiB and 1 GiB */
return test_multi_alloc_512mb_x2(uts, 0xE000, 0x4000);
 }
-LIB_TEST(lib_test_lmb_simple_x2, 0);
+LIB_TEST(lib_test_lmb_simple_x2_norun, UT_TESTF_MANUAL);
 
 /* Simulate 512 MiB RAM, allocate some blocks that fit/don't fit */
 static int test_bigblock(struct unit_test_state *uts, const phys_addr_t ram)
@@ -275,7 +275,7 @@ static int test_bigblock(struct unit_test_state *uts, const 
phys_addr_t ram)
return 0;
 }
 
-static int lib_test_lmb_big(struct unit_test_state *uts)
+static int lib_test_lmb_big_norun(struct unit_test_state *uts)
 {
int ret;
 
@@ -287,7 +287,7 @@ static int lib_test_lmb_big(struct unit_test_state *uts)
/* simulate 512 MiB RAM beginning at 1.5GiB */
return test_bigblock(uts, 0xE000);
 }
-LIB_TEST(lib_test_lmb_big, 0);
+LIB_TEST(lib_test_lmb_big_norun, UT_TESTF_MANUAL);
 
 /* Simulate 512 MiB RAM, allocate a block without previous reservation */
 static int test_noreserved(struct unit_test_state *uts, const phys_addr_t ram,
@@ -348,7 +348,7 @@ static int test_noreserved(struct unit_test_state *uts, 
const phys_addr_t ram,
return 0;
 }
 
-static int lib_test_lmb_noreserved(struct unit_test_state *uts)
+static int lib_test_lmb_noreserved_norun(struct unit_test_state *uts)
 {
int ret;
 
@@ -360,10 +360,9 @@ static int lib_test_lmb_noreserved(struct unit_test_state 
*uts)
/* simulate 512 MiB RAM beginning at 1.5GiB */
return test_noreserved(uts, 0xE000, 4, 1);
 }
+LIB_TEST(lib_test_lmb_noreserved_norun, UT_TESTF_MANUAL);
 
-LIB_TEST(lib_test_lmb_noreserved, 0);
-
-static int lib_test_lmb_unaligned_size(struct unit_test_state *uts)
+static int lib_test_lmb_unaligned_size_norun(struct unit_test_state *uts)
 {
int ret;
 
@@ -375,13 +374,13 @@ static int lib_test_lmb_unaligned_size(struct 
unit_test_state *uts)
/* simulate 512 MiB RAM beginning at 1.5GiB */
return test_noreserved(uts, 0xE000, 5, 8);
 }
-LIB_TEST(lib_test_lmb_unaligned_size, 0);
+LIB_TEST(lib_test_lmb_unaligned_size_norun, UT_TESTF_MANUAL);
 
 /*
  * Simulate a RAM that starts at 0 and allocate down to address 0, which must
  * fail as '0' means failure for the lmb_alloc functions.
  */
-static int lib_test_lmb_at_0(struct unit_test_state *uts)
+static int lib_test_lmb_at_0_norun(struct unit_test_state *uts)
 {
const phys_addr_t ram = 0;
const phys_size_t ram_size = 0x2000;
@@ -417,9 +416,9 @@ static int lib_test_lmb_at_0(struct unit_test_state *uts)
 
return 0;
 }
-LIB_TEST(lib_test_lmb_at_0, 0);
+LIB_TEST(lib_test_lmb_at_0_norun, UT_TESTF_MANUAL);
 
-static int lib_test_lmb_overlapping_add(struct unit_test_state *uts)
+static int lib_test_lmb_overlapping_add_norun(struct unit_test_state *uts)
 {
const phys_addr_t ram = 0x4000;
const phys_size_t ram_size = 0x2000;
@@ -433,10 +432,10 @@ static int lib_test_lmb_overlapping_add(struct 
unit_test_state *uts)
 
return 0;
 }
-LIB_TEST(lib_test_lmb_overlapping_add, 0);
+LIB_TEST(lib_test_lmb_overlapping_add_norun, UT_TESTF_MANUAL);
 
 /* Check that calling lmb_reserve with overlapping regions fails. */
-static int lib_test_lmb_overlapping_reserve(struct unit_test_state *uts)
+static int lib_test_lmb_overlapping_reserve_norun(struct unit_test_state *uts)
 {
const phys_addr_t ram = 0x4000;
const 

[RFC PATCH 25/31] test: lmb: adjust the test case to handle overlapping regions

2024-06-07 Thread Sughosh Ganu
The LMB code can now accept reserving and adding overlapping regions
of memory. Adjust the test for checking the reservation of overlapping
memory regions to work with this corresponding change in the LMB code.

Signed-off-by: Sughosh Ganu 
---
 test/lib/lmb.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/test/lib/lmb.c b/test/lib/lmb.c
index 9b0e023b67..67a6be5bc3 100644
--- a/test/lib/lmb.c
+++ b/test/lib/lmb.c
@@ -451,15 +451,15 @@ static int lib_test_lmb_overlapping_reserve(struct 
unit_test_state *uts)
ut_asserteq(ret, 0);
ASSERT_LMB(, ram, ram_size, 1, 0x4001, 0x1,
   0, 0, 0, 0);
-   /* allocate overlapping region should fail */
+   /* allocate overlapping region should return the coalesced count */
ret = lmb_reserve(0x40011000, 0x1);
-   ut_asserteq(ret, -1);
-   ASSERT_LMB(, ram, ram_size, 1, 0x4001, 0x1,
+   ut_asserteq(ret, 1);
+   ASSERT_LMB(, ram, ram_size, 1, 0x4001, 0x11000,
   0, 0, 0, 0);
/* allocate 3nd region */
ret = lmb_reserve(0x4003, 0x1);
ut_asserteq(ret, 0);
-   ASSERT_LMB(, ram, ram_size, 2, 0x4001, 0x1,
+   ASSERT_LMB(, ram, ram_size, 2, 0x4001, 0x11000,
   0x4003, 0x1, 0, 0);
/* allocate 2nd region , This should coalesced all region into one */
ret = lmb_reserve(0x4002, 0x1);
-- 
2.34.1



[RFC PATCH 24/31] test: lmb: add a test case for checking overlapping region add

2024-06-07 Thread Sughosh Ganu
Memory managed by LMB is now persistent and global. With that, it
could be possible for multiple callers to try to add memory that has
already been added. Add a test case to check that the LMB module
handles it as expected.

Signed-off-by: Sughosh Ganu 
---
 test/lib/lmb.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/test/lib/lmb.c b/test/lib/lmb.c
index 260ebcfcd3..9b0e023b67 100644
--- a/test/lib/lmb.c
+++ b/test/lib/lmb.c
@@ -419,6 +419,22 @@ static int lib_test_lmb_at_0(struct unit_test_state *uts)
 }
 LIB_TEST(lib_test_lmb_at_0, 0);
 
+static int lib_test_lmb_overlapping_add(struct unit_test_state *uts)
+{
+   const phys_addr_t ram = 0x4000;
+   const phys_size_t ram_size = 0x2000;
+   long ret;
+
+   ret = lmb_add(ram, ram_size);
+   ut_asserteq(ret, 0);
+
+   ret = lmb_add(ram, ram_size);
+   ut_asserteq(ret, 0);
+
+   return 0;
+}
+LIB_TEST(lib_test_lmb_overlapping_add, 0);
+
 /* Check that calling lmb_reserve with overlapping regions fails. */
 static int lib_test_lmb_overlapping_reserve(struct unit_test_state *uts)
 {
-- 
2.34.1



[RFC PATCH 23/31] test: lmb: initialise the lmb structure before tests

2024-06-07 Thread Sughosh Ganu
The LMB allocations are now persistent and global, and with that all
the local instances of the structure variable have been removed. Every
LMB test cases that are run require a clean slate of the structure --
facilitate that by adding an initialisation function which gets called
at the start of every test.

Signed-off-by: Sughosh Ganu 
---
 include/lmb.h  |  4 
 lib/lmb.c  | 17 +
 test/lib/lmb.c | 18 ++
 3 files changed, 39 insertions(+)

diff --git a/include/lmb.h b/include/lmb.h
index 1d4cd255d2..08ece0a90b 100644
--- a/include/lmb.h
+++ b/include/lmb.h
@@ -148,6 +148,10 @@ void arch_lmb_reserve_generic(ulong sp, ulong end, ulong 
align);
  */
 void lmb_reserve_common(void *fdt_blob);
 
+#if defined(CONFIG_SANDBOX)
+void lmb_init(void);
+#endif /* CONFIG_SANDBOX */
+
 #endif /* __KERNEL__ */
 
 #endif /* _LINUX_LMB_H */
diff --git a/lib/lmb.c b/lib/lmb.c
index c9f6ca692e..2798ce0989 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -718,3 +718,20 @@ static int efi_mem_map_update_sync(void *ctx, struct event 
*event)
 }
 EVENT_SPY_FULL(EVT_EFI_MEM_MAP_UPDATE, efi_mem_map_update_sync);
 #endif /* MEM_MAP_UPDATE_NOTIFY */
+
+#if CONFIG_IS_ENABLED(SANDBOX)
+void lmb_init(void)
+{
+#if IS_ENABLED(CONFIG_LMB_USE_MAX_REGIONS)
+   lmb.memory.max = CONFIG_LMB_MAX_REGIONS;
+   lmb.reserved.max = CONFIG_LMB_MAX_REGIONS;
+#else
+   lmb.memory.max = CONFIG_LMB_MEMORY_REGIONS;
+   lmb.reserved.max = CONFIG_LMB_RESERVED_REGIONS;
+   lmb.memory.region = memory_regions;
+   lmb.reserved.region = reserved_regions;
+#endif
+   lmb.memory.cnt = 0;
+   lmb.reserved.cnt = 0;
+}
+#endif /* SANDBOX */
diff --git a/test/lib/lmb.c b/test/lib/lmb.c
index ace1ddf4e4..260ebcfcd3 100644
--- a/test/lib/lmb.c
+++ b/test/lib/lmb.c
@@ -77,6 +77,8 @@ static int test_multi_alloc(struct unit_test_state *uts, 
const phys_addr_t ram,
ut_assert(alloc_64k_addr >= ram + 8);
ut_assert(alloc_64k_end <= ram_end - 8);
 
+   lmb_init();
+
if (ram0_size) {
ret = lmb_add(ram0, ram0_size);
ut_asserteq(ret, 0);
@@ -235,6 +237,8 @@ static int test_bigblock(struct unit_test_state *uts, const 
phys_addr_t ram)
/* check for overflow */
ut_assert(ram_end == 0 || ram_end > ram);
 
+   lmb_init();
+
ret = lmb_add(ram, ram_size);
ut_asserteq(ret, 0);
 
@@ -299,6 +303,8 @@ static int test_noreserved(struct unit_test_state *uts, 
const phys_addr_t ram,
/* check for overflow */
ut_assert(ram_end == 0 || ram_end > ram);
 
+   lmb_init();
+
ret = lmb_add(ram, ram_size);
ut_asserteq(ret, 0);
ASSERT_LMB(, ram, ram_size, 0, 0, 0, 0, 0, 0, 0);
@@ -382,6 +388,8 @@ static int lib_test_lmb_at_0(struct unit_test_state *uts)
long ret;
phys_addr_t a, b;
 
+   lmb_init();
+
ret = lmb_add(ram, ram_size);
ut_asserteq(ret, 0);
 
@@ -418,6 +426,8 @@ static int lib_test_lmb_overlapping_reserve(struct 
unit_test_state *uts)
const phys_size_t ram_size = 0x2000;
long ret;
 
+   lmb_init();
+
ret = lmb_add(ram, ram_size);
ut_asserteq(ret, 0);
 
@@ -473,6 +483,8 @@ static int test_alloc_addr(struct unit_test_state *uts, 
const phys_addr_t ram)
/* check for overflow */
ut_assert(ram_end == 0 || ram_end > ram);
 
+   lmb_init();
+
ret = lmb_add(ram, ram_size);
ut_asserteq(ret, 0);
 
@@ -597,6 +609,8 @@ static int test_get_unreserved_size(struct unit_test_state 
*uts,
/* check for overflow */
ut_assert(ram_end == 0 || ram_end > ram);
 
+   lmb_init();
+
ret = lmb_add(ram, ram_size);
ut_asserteq(ret, 0);
 
@@ -664,6 +678,8 @@ static int lib_test_lmb_max_regions(struct unit_test_state 
*uts)
phys_addr_t offset;
int ret, i;
 
+   lmb_init();
+
ut_asserteq(lmb.memory.cnt, 0);
ut_asserteq(lmb.memory.max, CONFIG_LMB_MAX_REGIONS);
ut_asserteq(lmb.reserved.cnt, 0);
@@ -722,6 +738,8 @@ static int lib_test_lmb_flags(struct unit_test_state *uts)
const phys_size_t ram_size = 0x2000;
long ret;
 
+   lmb_init();
+
ret = lmb_add(ram, ram_size);
ut_asserteq(ret, 0);
 
-- 
2.34.1



[RFC PATCH 22/31] test: lmb: run the LMB tests only on sandbox

2024-06-07 Thread Sughosh Ganu
The LMB memory map is now persistent and global. Running the tests for
the LMB module will result in the memory map getting reset, and this
will have side-effects on the rest of the working of the platform. Run
the LMB tests only on the sandbox platform, which is meant for running
such kinds of tests.

Signed-off-by: Sughosh Ganu 
---
 test/lib/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/test/lib/Makefile b/test/lib/Makefile
index e75a263e6a..9154e07993 100644
--- a/test/lib/Makefile
+++ b/test/lib/Makefile
@@ -9,7 +9,7 @@ obj-$(CONFIG_EFI_LOADER) += efi_device_path.o
 obj-$(CONFIG_EFI_SECURE_BOOT) += efi_image_region.o
 obj-y += hexdump.o
 obj-$(CONFIG_SANDBOX) += kconfig.o
-obj-y += lmb.o
+obj-$(CONFIG_SANDBOX) += lmb.o
 obj-y += longjmp.o
 obj-$(CONFIG_CONSOLE_RECORD) += test_print.o
 obj-$(CONFIG_SSCANF) += sscanf.o
-- 
2.34.1



[RFC PATCH 21/31] test: event: update the expected event dump output

2024-06-07 Thread Sughosh Ganu
With the addition of two events for notification of any changes to
memory that is occupied and is free, the output of the event_dump.py
script has changed. Update the expected event log to incorporate this
change.

Signed-off-by: Sughosh Ganu 
---
 test/py/tests/test_event_dump.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/test/py/tests/test_event_dump.py b/test/py/tests/test_event_dump.py
index e282c67335..b14e098895 100644
--- a/test/py/tests/test_event_dump.py
+++ b/test/py/tests/test_event_dump.py
@@ -16,9 +16,11 @@ def test_event_dump(u_boot_console):
 out = util.run_and_log(cons, ['scripts/event_dump.py', sandbox])
 expect = '''.*Event typeId  Source 
location
   --  
--
+EVT_EFI_MEM_MAP_UPDATE  efi_mem_map_update_sync   .*lib/lmb.c:.*
 EVT_FT_FIXUP  bootmeth_vbe_ft_fixup   .*boot/vbe_request.c:.*
 EVT_FT_FIXUP  bootmeth_vbe_simple_ft_fixup.*boot/vbe_simple_os.c:.*
 EVT_LAST_STAGE_INIT   install_smbios_table
.*lib/efi_loader/efi_smbios.c:.*
+EVT_LMB_MAP_UPDATElmb_mem_map_update_sync 
.*lib/efi_loader/efi_memory.c:.*
 EVT_MISC_INIT_F   sandbox_early_getopt_check  
.*arch/sandbox/cpu/start.c:.*
 EVT_TEST  h_adder_simple  .*test/common/event.c:'''
 assert re.match(expect, out, re.MULTILINE) is not None
-- 
2.34.1



[RFC PATCH 20/31] test: cedit: use allocated address for reading file

2024-06-07 Thread Sughosh Ganu
Instead of a randomly selected address, use an LMB allocated one for
reading the file into memory. With the LMB map now being persistent
and global, the address used for reading the file might be already
allocated as non-overwritable, resulting in a failure. Get a valid
address from LMB and then read the file to that address.

Signed-off-by: Sughosh Ganu 
---
 test/boot/cedit.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/test/boot/cedit.c b/test/boot/cedit.c
index aa41719048..1f4147da89 100644
--- a/test/boot/cedit.c
+++ b/test/boot/cedit.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -62,7 +63,7 @@ static int cedit_fdt(struct unit_test_state *uts)
struct video_priv *vid_priv;
extern struct expo *cur_exp;
struct scene_obj_menu *menu;
-   ulong addr = 0x1000;
+   ulong addr;
struct ofprop prop;
struct scene *scn;
oftree tree;
@@ -87,6 +88,8 @@ static int cedit_fdt(struct unit_test_state *uts)
str = abuf_data(>buf);
strcpy(str, "my-machine");
 
+   addr = lmb_alloc(1024, 1024);
+   ut_asserteq(!!addr, !0);
ut_assertok(run_command("cedit write_fdt hostfs - settings.dtb", 0));
ut_assertok(run_commandf("load hostfs - %lx settings.dtb", addr));
ut_assert_nextlinen("1024 bytes read");
-- 
2.34.1



[RFC PATCH 19/31] zynq: lmb: do not add to lmb map before relocation

2024-06-07 Thread Sughosh Ganu
The LMB memory is typically not needed very early in the platform's
boot. Do not add memory to the LMB map before relocation. Reservation
of common areas and adding of memory is done after relocation.

Signed-off-by: Sughosh Ganu 
---
 board/xilinx/common/board.c | 31 ---
 1 file changed, 31 deletions(-)

diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c
index 7be1b6e511..38967fc705 100644
--- a/board/xilinx/common/board.c
+++ b/board/xilinx/common/board.c
@@ -13,7 +13,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -666,36 +665,6 @@ int embedded_dtb_select(void)
 }
 #endif
 
-#if defined(CONFIG_LMB)
-
-#ifndef MMU_SECTION_SIZE
-#define MMU_SECTION_SIZE(1 * 1024 * 1024)
-#endif
-
-phys_addr_t board_get_usable_ram_top(phys_size_t total_size)
-{
-   phys_size_t size;
-   phys_addr_t reg;
-
-   if (!total_size)
-   return gd->ram_top;
-
-   if (!IS_ALIGNED((ulong)gd->fdt_blob, 0x8))
-   panic("Not 64bit aligned DT location: %p\n", gd->fdt_blob);
-
-   /* found enough not-reserved memory to relocated U-Boot */
-   lmb_add(gd->ram_base, gd->ram_size);
-   boot_fdt_add_mem_rsv_regions((void *)gd->fdt_blob);
-   size = ALIGN(CONFIG_SYS_MALLOC_LEN + total_size, MMU_SECTION_SIZE);
-   reg = lmb_alloc(size, MMU_SECTION_SIZE);
-
-   if (!reg)
-   reg = gd->ram_top - size;
-
-   return reg + size;
-}
-#endif
-
 #ifdef CONFIG_OF_BOARD_SETUP
 #define MAX_RAND_SIZE 8
 int ft_board_setup(void *blob, struct bd_info *bd)
-- 
2.34.1



[RFC PATCH 18/31] sandbox: iommu: remove lmb allocation in the driver

2024-06-07 Thread Sughosh Ganu
The sandbox iommu driver uses the LMB module to allocate a particular
range of memory for the device virtual address(DVA). This used to work
earlier since the LMB memory map was caller specific and not
global. But with the change to make the LMB allocations global and
persistent, adding this memory range has other side effects. On the
other hand, the sandbox iommu test expects to see this particular
value of the DVA. Use the DVA address directly, instead of mapping it
in the LMB memory map, and then have it allocated.

Signed-off-by: Sughosh Ganu 
---
 drivers/iommu/sandbox_iommu.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/iommu/sandbox_iommu.c b/drivers/iommu/sandbox_iommu.c
index c5bb88d299..67293e20f4 100644
--- a/drivers/iommu/sandbox_iommu.c
+++ b/drivers/iommu/sandbox_iommu.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 
+#define DVA_ADDR   0x89abc000
 #define IOMMU_PAGE_SIZESZ_4K
 
 static dma_addr_t sandbox_iommu_map(struct udevice *dev, void *addr,
@@ -22,7 +23,7 @@ static dma_addr_t sandbox_iommu_map(struct udevice *dev, void 
*addr,
off = virt_to_phys(addr) - paddr;
psize = ALIGN(size + off, IOMMU_PAGE_SIZE);
 
-   dva = lmb_alloc(psize, IOMMU_PAGE_SIZE);
+   dva = (phys_addr_t)DVA_ADDR;
 
return dva + off;
 }
@@ -36,8 +37,6 @@ static void sandbox_iommu_unmap(struct udevice *dev, 
dma_addr_t addr,
dva = ALIGN_DOWN(addr, IOMMU_PAGE_SIZE);
psize = size + (addr - dva);
psize = ALIGN(psize, IOMMU_PAGE_SIZE);
-
-   lmb_free(dva, psize);
 }
 
 static struct iommu_ops sandbox_iommu_ops = {
@@ -47,8 +46,6 @@ static struct iommu_ops sandbox_iommu_ops = {
 
 static int sandbox_iommu_probe(struct udevice *dev)
 {
-   lmb_add(0x89abc000, SZ_16K);
-
return 0;
 }
 
-- 
2.34.1



[RFC PATCH 17/31] lmb: remove call to efi_lmb_reserve()

2024-06-07 Thread Sughosh Ganu
The changes in the EFI memory map are now notified to the LMB
module. There is therefore no need to explicitly get the efi memory
map and set aside the EFI allocated memory.

Signed-off-by: Sughosh Ganu 
---
 lib/lmb.c | 35 ---
 1 file changed, 35 deletions(-)

diff --git a/lib/lmb.c b/lib/lmb.c
index 3059609aea..c9f6ca692e 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -204,38 +204,6 @@ void arch_lmb_reserve_generic(ulong sp, ulong end, ulong 
align)
}
 }
 
-/**
- * efi_lmb_reserve() - add reservations for EFI memory
- *
- * Add reservations for all EFI memory areas that are not
- * EFI_CONVENTIONAL_MEMORY.
- *
- * Return: 0 on success, 1 on failure
- */
-static __maybe_unused int efi_lmb_reserve(void)
-{
-   struct efi_mem_desc *memmap = NULL, *map;
-   efi_uintn_t i, map_size = 0;
-   efi_status_t ret;
-
-   ret = efi_get_memory_map_alloc(_size, );
-   if (ret != EFI_SUCCESS)
-   return 1;
-
-   for (i = 0, map = memmap; i < map_size / sizeof(*map); ++map, ++i) {
-   if (map->type != EFI_CONVENTIONAL_MEMORY) {
-   lmb_reserve_flags(map_to_sysmem((void *)(uintptr_t)
-   map->physical_start),
- map->num_pages * EFI_PAGE_SIZE,
- map->type == EFI_RESERVED_MEMORY_TYPE
- ? LMB_NOMAP : LMB_NONE);
-   }
-   }
-   efi_free_pool(memmap);
-
-   return 0;
-}
-
 /**
  * lmb_reserve_common() - Reserve memory region occupied by U-Boot image
  * @fdt_blob: pointer to the FDT blob
@@ -255,9 +223,6 @@ void lmb_reserve_common(void *fdt_blob)
 
if (CONFIG_IS_ENABLED(OF_LIBFDT) && fdt_blob)
boot_fdt_add_mem_rsv_regions(fdt_blob);
-
-   if (CONFIG_IS_ENABLED(EFI_LOADER))
-   efi_lmb_reserve();
 }
 
 /**
-- 
2.34.1



[RFC PATCH 16/31] lmb: add an event handler to update memory map

2024-06-07 Thread Sughosh Ganu
There are events that would be used to notify other interested modules
of any changes in available and occupied memory. This would happen
when a module allocates or reserves memory, or frees up memory. These
changes in memory map should be notified to other interested modules
so that the allocated memory does not get overwritten. Add an event
handler in the LMB module to update it's memory map accordingly when
such changes happen. As a consequence, any subsequent memory request
would honour the updated memory map and allocations would only happen
from available memory.

Signed-off-by: Sughosh Ganu 
---
 lib/Kconfig |  1 +
 lib/lmb.c   | 34 ++
 2 files changed, 35 insertions(+)

diff --git a/lib/Kconfig b/lib/Kconfig
index 9ea02ae006..9e465a748b 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -,6 +,7 @@ config LMB
bool "Enable the logical memory blocks library (lmb)"
default y if ARC || ARM || M68K || MICROBLAZE || MIPS || \
 NIOS2 || PPC || RISCV || SANDBOX || SH || X86 || XTENSA
+   select EVENT
help
  Support the library logical memory blocks.
 
diff --git a/lib/lmb.c b/lib/lmb.c
index 313735dbe3..3059609aea 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -16,6 +16,7 @@
 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -719,3 +720,36 @@ __weak void arch_lmb_reserve(void)
 {
/* please define platform specific arch_lmb_reserve() */
 }
+
+#if CONFIG_IS_ENABLED(MEM_MAP_UPDATE_NOTIFY)
+static long lmb_reserve_nooverwrite(phys_addr_t base, phys_size_t size)
+{
+   struct lmb_region *_rgn = 
+
+   return lmb_add_region_flags(_rgn, base, size, LMB_NOOVERWRITE);
+}
+
+static int efi_mem_map_update_sync(void *ctx, struct event *event)
+{
+   u8 op;
+   long ret;
+   phys_addr_t addr;
+   phys_size_t size;
+   struct event_efi_mem_map_update *efi_map = >data.efi_mem_map;
+
+   addr = virt_to_phys((void *)(uintptr_t)efi_map->base);
+   size = efi_map->size;
+   op = efi_map->op;
+
+   if (op != MAP_OP_RESERVE && op != MAP_OP_FREE) {
+   log_debug("Invalid map update op received (%d)\n", op);
+   return -1;
+   }
+
+   ret = op == MAP_OP_RESERVE ? lmb_reserve_nooverwrite(addr, size) :
+   __lmb_free(addr, size);
+
+   return !ret ? 0 : -1;
+}
+EVENT_SPY_FULL(EVT_EFI_MEM_MAP_UPDATE, efi_mem_map_update_sync);
+#endif /* MEM_MAP_UPDATE_NOTIFY */
-- 
2.34.1



[RFC PATCH 15/31] efi_memory: add an event handler to update memory map

2024-06-07 Thread Sughosh Ganu
There are events that would be used to notify other interested modules
of any changes in available and occupied memory. This would happen
when a module allocates or reserves memory, or frees up memory. These
changes in memory map should be notified to other interested modules
so that the allocated memory does not get overwritten. Add an event
handler in the EFI memory module to update the EFI memory map
accordingly when such changes happen. As a consequence, any subsequent
memory request would honour the updated memory map and only available
memory would be allocated from.

Signed-off-by: Sughosh Ganu 
---
 lib/efi_loader/efi_memory.c | 70 ++---
 1 file changed, 58 insertions(+), 12 deletions(-)

diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index 435e580fb3..93244161b0 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -73,6 +73,10 @@ struct efi_pool_allocation {
 #if CONFIG_IS_ENABLED(MEM_MAP_UPDATE_NOTIFY)
 extern bool is_addr_in_ram(uintptr_t addr);
 
+static efi_status_t __efi_add_memory_map_pg(u64 start, u64 pages,
+   int memory_type,
+   bool overlap_only_ram);
+
 static void efi_map_update_notify(u64 addr, u64 size, u8 op)
 {
struct event_efi_mem_map_update efi_map = {0};
@@ -84,6 +88,34 @@ static void efi_map_update_notify(u64 addr, u64 size, u8 op)
if (is_addr_in_ram((uintptr_t)addr))
event_notify(EVT_EFI_MEM_MAP_UPDATE, _map, sizeof(efi_map));
 }
+
+static int lmb_mem_map_update_sync(void *ctx, struct event *event)
+{
+   u8 op;
+   u64 addr;
+   u64 pages;
+   efi_status_t status;
+   struct event_lmb_map_update *lmb_map = >data.lmb_map;
+
+   addr = (uintptr_t)map_sysmem(lmb_map->base, 0);
+   pages = efi_size_in_pages(lmb_map->size + (addr & EFI_PAGE_MASK));
+   op = lmb_map->op;
+   addr &= ~EFI_PAGE_MASK;
+
+   if (op != MAP_OP_RESERVE && op != MAP_OP_FREE) {
+   log_debug("Invalid map update op received (%d)\n", op);
+   return -1;
+   }
+
+   status = __efi_add_memory_map_pg(addr, pages,
+op == MAP_OP_FREE ?
+EFI_CONVENTIONAL_MEMORY :
+EFI_BOOT_SERVICES_DATA,
+true);
+
+   return status == EFI_SUCCESS ? 0 : -1;
+}
+EVENT_SPY_FULL(EVT_LMB_MAP_UPDATE, lmb_mem_map_update_sync);
 #endif /* MEM_MAP_UPDATE_NOTIFY */
 
 /**
@@ -275,18 +307,9 @@ static s64 efi_mem_carve_out(struct efi_mem_list *map,
return EFI_CARVE_LOOP_AGAIN;
 }
 
-/**
- * efi_add_memory_map_pg() - add pages to the memory map
- *
- * @start: start address, must be a multiple of EFI_PAGE_SIZE
- * @pages: number of pages to add
- * @memory_type:   type of memory added
- * @overlap_only_ram:  region may only overlap RAM
- * Return: status code
- */
-static efi_status_t efi_add_memory_map_pg(u64 start, u64 pages,
- int memory_type,
- bool overlap_only_ram)
+static efi_status_t __efi_add_memory_map_pg(u64 start, u64 pages,
+   int memory_type,
+   bool overlap_only_ram)
 {
struct list_head *lhandle;
struct efi_mem_list *newlist;
@@ -395,6 +418,29 @@ static efi_status_t efi_add_memory_map_pg(u64 start, u64 
pages,
}
}
 
+   return EFI_SUCCESS;
+}
+
+/**
+ * efi_add_memory_map_pg() - add pages to the memory map
+ *
+ * @start: start address, must be a multiple of EFI_PAGE_SIZE
+ * @pages: number of pages to add
+ * @memory_type:   type of memory added
+ * @overlap_only_ram:  region may only overlap RAM
+ * Return: status code
+ */
+static efi_status_t efi_add_memory_map_pg(u64 start, u64 pages,
+ int memory_type,
+ bool overlap_only_ram)
+{
+   efi_status_t status;
+
+   status = __efi_add_memory_map_pg(start, pages, memory_type,
+overlap_only_ram);
+   if (status != EFI_SUCCESS)
+   return status;
+
if (CONFIG_IS_ENABLED(MEM_MAP_UPDATE_NOTIFY))
efi_map_update_notify(start, pages << EFI_PAGE_SHIFT,
  memory_type == EFI_CONVENTIONAL_MEMORY ?
-- 
2.34.1



[RFC PATCH 14/31] lmb: notify of any changes to the LMB memory map

2024-06-07 Thread Sughosh Ganu
In U-Boot, LMB and EFI are two primary modules who provide memory
allocation and reservation API's. Both these modules operate with the
same regions of memory for allocations. Use the LMB memory map update
event to notify other interested listeners about a change in it's
memory map. This can then be used by the other module to allocate
memory only from available regions, instead of overwriting already
allocated memory.

Signed-off-by: Sughosh Ganu 
---
 lib/lmb.c | 49 +++--
 1 file changed, 47 insertions(+), 2 deletions(-)

diff --git a/lib/lmb.c b/lib/lmb.c
index 0a4f3d5bcd..313735dbe3 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -7,6 +7,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -18,8 +19,13 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+#define MAP_OP_RESERVE (u8)0x1
+#define MAP_OP_FREE(u8)0x2
+
 #define LMB_ALLOC_ANYWHERE 0
 
+extern bool is_addr_in_ram(uintptr_t addr);
+
 #if !IS_ENABLED(CONFIG_LMB_USE_MAX_REGIONS)
 struct lmb_property memory_regions[CONFIG_LMB_MEMORY_REGIONS];
 struct lmb_property reserved_regions[CONFIG_LMB_RESERVED_REGIONS];
@@ -39,6 +45,19 @@ struct lmb lmb = {
.reserved.cnt = 0,
 };
 
+static void lmb_map_update_notify(phys_addr_t addr, phys_size_t size,
+ u8 op)
+{
+   struct event_lmb_map_update lmb_map = {0};
+
+   lmb_map.base = addr;
+   lmb_map.size = size;
+   lmb_map.op = op;
+
+   if (is_addr_in_ram((uintptr_t)addr))
+   event_notify(EVT_LMB_MAP_UPDATE, _map, sizeof(lmb_map));
+}
+
 static void lmb_dump_region(struct lmb_region *rgn, char *name)
 {
unsigned long long base, size, end;
@@ -450,7 +469,7 @@ long lmb_add(phys_addr_t base, phys_size_t size)
return lmb_add_region(_rgn, base, size);
 }
 
-long lmb_free(phys_addr_t base, phys_size_t size)
+static long __lmb_free(phys_addr_t base, phys_size_t size)
 {
struct lmb_region *rgn = 
phys_addr_t rgnbegin, rgnend;
@@ -500,11 +519,33 @@ long lmb_free(phys_addr_t base, phys_size_t size)
rgn->region[i].flags);
 }
 
+long lmb_free(phys_addr_t base, phys_size_t size)
+{
+   long ret;
+
+   ret = __lmb_free(base, size);
+   if (ret < 0)
+   return ret;
+
+   if (CONFIG_IS_ENABLED(MEM_MAP_UPDATE_NOTIFY))
+   lmb_map_update_notify(base, size, MAP_OP_FREE);
+
+   return 0;
+}
+
 long lmb_reserve_flags(phys_addr_t base, phys_size_t size, enum lmb_flags 
flags)
 {
+   long ret = 0;
struct lmb_region *_rgn = 
 
-   return lmb_add_region_flags(_rgn, base, size, flags);
+   ret = lmb_add_region_flags(_rgn, base, size, flags);
+   if (ret < 0)
+   return -1;
+
+   if (CONFIG_IS_ENABLED(MEM_MAP_UPDATE_NOTIFY))
+   lmb_map_update_notify(base, size, MAP_OP_RESERVE);
+
+   return ret;
 }
 
 long lmb_reserve(phys_addr_t base, phys_size_t size)
@@ -563,6 +604,10 @@ static phys_addr_t __lmb_alloc_base(phys_size_t size, 
ulong align,
if (lmb_add_region(, base,
   size) < 0)
return 0;
+
+   if (CONFIG_IS_ENABLED(MEM_MAP_UPDATE_NOTIFY))
+   lmb_map_update_notify(base, size,
+ MAP_OP_RESERVE);
return base;
}
res_base = lmb.reserved.region[rgn].base;
-- 
2.34.1



[RFC PATCH 13/31] efi_memory: notify of any changes to the EFI memory map

2024-06-07 Thread Sughosh Ganu
In U-Boot, LMB and EFI are two primary modules who provide memory
allocation and reservation API's. Both these modules operate with the
same regions of memory for allocations. Use the EFI memory map update
event to notify other interested listeners about a change in the EFI
memory map. This can then be used by the other module to allocate
memory only from available regions, instead of overwriting already
allocated memory.

Signed-off-by: Sughosh Ganu 
---
 lib/efi_loader/efi_memory.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index 12cf23fa3f..435e580fb3 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -8,6 +8,7 @@
 #define LOG_CATEGORY LOGC_EFI
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -36,6 +37,9 @@ struct efi_mem_list {
 #define EFI_CARVE_OVERLAPS_NONRAM  -3
 #define EFI_CARVE_OUT_OF_RESOURCES -4
 
+#define MAP_OP_RESERVE (u8)0x1
+#define MAP_OP_FREE(u8)0x2
+
 /* This list contains all memory map items */
 static LIST_HEAD(efi_mem);
 
@@ -66,6 +70,22 @@ struct efi_pool_allocation {
char data[] __aligned(ARCH_DMA_MINALIGN);
 };
 
+#if CONFIG_IS_ENABLED(MEM_MAP_UPDATE_NOTIFY)
+extern bool is_addr_in_ram(uintptr_t addr);
+
+static void efi_map_update_notify(u64 addr, u64 size, u8 op)
+{
+   struct event_efi_mem_map_update efi_map = {0};
+
+   efi_map.base = addr;
+   efi_map.size = size;
+   efi_map.op = op;
+
+   if (is_addr_in_ram((uintptr_t)addr))
+   event_notify(EVT_EFI_MEM_MAP_UPDATE, _map, sizeof(efi_map));
+}
+#endif /* MEM_MAP_UPDATE_NOTIFY */
+
 /**
  * checksum() - calculate checksum for memory allocated from pool
  *
@@ -375,6 +395,11 @@ static efi_status_t efi_add_memory_map_pg(u64 start, u64 
pages,
}
}
 
+   if (CONFIG_IS_ENABLED(MEM_MAP_UPDATE_NOTIFY))
+   efi_map_update_notify(start, pages << EFI_PAGE_SHIFT,
+ memory_type == EFI_CONVENTIONAL_MEMORY ?
+ MAP_OP_FREE : MAP_OP_RESERVE);
+
return EFI_SUCCESS;
 }
 
-- 
2.34.1



[RFC PATCH 12/31] add a function to check if an address is in RAM memory

2024-06-07 Thread Sughosh Ganu
Add a function to check if a given address falls within the RAM
address used by U-Boot. This will be used to notify other modules if
the address gets allocated, so as to not get re-allocated by some
other module.

Signed-off-by: Sughosh Ganu 
---
 arch/sandbox/cpu/cpu.c | 5 +
 common/board_r.c   | 5 +
 2 files changed, 10 insertions(+)

diff --git a/arch/sandbox/cpu/cpu.c b/arch/sandbox/cpu/cpu.c
index 0ed85b354c..d7a0176497 100644
--- a/arch/sandbox/cpu/cpu.c
+++ b/arch/sandbox/cpu/cpu.c
@@ -413,3 +413,8 @@ int sandbox_load_other_fdt(void **fdtp, int *sizep)
 
return 0;
 }
+
+bool __maybe_unused is_addr_in_ram(uintptr_t addr)
+{
+   return is_in_sandbox_mem((const void *)addr);
+}
diff --git a/common/board_r.c b/common/board_r.c
index a9f0b0cec1..aabc0cdf26 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -72,6 +72,11 @@ DECLARE_GLOBAL_DATA_PTR;
 
 ulong monitor_flash_len;
 
+__weak bool __maybe_unused is_addr_in_ram(uintptr_t addr)
+{
+   return addr >= gd->ram_base && addr <= gd->ram_top;
+}
+
 __weak int board_flash_wp_on(void)
 {
/*
-- 
2.34.1



[RFC PATCH 11/31] lib: Kconfig: add a config symbol for getting memory map updates

2024-06-07 Thread Sughosh Ganu
Add a Kconfig symbol to enable getting updates on any memory map
changes that might be done by some other module. This notification
mechanism can then be used to have a synchronous view of allocated and
free memory.

Signed-off-by: Sughosh Ganu 
---
 lib/Kconfig | 9 +
 1 file changed, 9 insertions(+)

diff --git a/lib/Kconfig b/lib/Kconfig
index 189e6eb31a..9ea02ae006 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -74,6 +74,15 @@ config HAVE_PRIVATE_LIBGCC
 config LIB_UUID
bool
 
+config MEM_MAP_UPDATE_NOTIFY
+   bool "Get notified of any changes to the memory map"
+   default y if EVENT && LMB && EFI_LOADER
+   help
+ Enable this option to get notification on any changes to the
+ memory that is allocated or freed. This will allow different
+ modules that allocate memory to have a synchronous view of available
+ and allocated memory.
+
 config RANDOM_UUID
bool "GPT Random UUID generation"
select LIB_UUID
-- 
2.34.1



[RFC PATCH 10/31] event: add events to notify memory map changes

2024-06-07 Thread Sughosh Ganu
Add events which would be used for notifying changes in the respective
modules' memory map. This is to be used for having a synchronous view
of the memory that is currently in use, and that is available for
allocations.

Signed-off-by: Sughosh Ganu 
---
 common/event.c  |  4 
 include/event.h | 28 
 2 files changed, 32 insertions(+)

diff --git a/common/event.c b/common/event.c
index 16c2ba6cc9..067ee9ee4e 100644
--- a/common/event.c
+++ b/common/event.c
@@ -48,6 +48,10 @@ const char *const type_name[] = {
 
/* main loop events */
"main_loop",
+
+   "lmb_map_update",
+
+   "efi_map_update",
 };
 
 _Static_assert(ARRAY_SIZE(type_name) == EVT_COUNT, "event type_name size");
diff --git a/include/event.h b/include/event.h
index fb353ad623..9d8be7a103 100644
--- a/include/event.h
+++ b/include/event.h
@@ -153,6 +153,22 @@ enum event_t {
 */
EVT_MAIN_LOOP,
 
+   /**
+* @EVT_LMB_MAP_UPDATE:
+* This event is triggered on an update to the LMB reserved memory
+* region. This can be used to notify about any LMB memory allocation
+* or freeing of memory having occurred.
+*/
+   EVT_LMB_MAP_UPDATE,
+
+   /**
+* @EVT_EFI_MEM_MAP_UPDATE:
+* This event is triggered on an update to the EFI  memory map.
+* This can be used to notify about any EFI memory allocation
+* or freeing of memory having occurred.
+*/
+   EVT_EFI_MEM_MAP_UPDATE,
+
/**
 * @EVT_COUNT:
 * This constants holds the maximum event number + 1 and is used when
@@ -203,6 +219,18 @@ union event_data {
oftree tree;
struct bootm_headers *images;
} ft_fixup;
+
+   struct event_lmb_map_update {
+   u64 base;
+   u64 size;
+   u8 op;
+   } lmb_map;
+
+   struct event_efi_mem_map_update {
+   u64 base;
+   u64 size;
+   u8  op;
+   } efi_mem_map;
 };
 
 /**
-- 
2.34.1



[RFC PATCH 09/31] lmb: allow for resizing lmb regions

2024-06-07 Thread Sughosh Ganu
Allow for resizing of LMB regions if the region attributes match. The
current code returns a failure status on detecting an overlapping
address. This worked up until now since the LMB calls were not
persistent and global -- the LMB memory map was specific and private
to a given caller of the LMB API's.

With the change in the LMB code to make the LMB reservations
persistent, there needs to be a check on whether the memory region can
be resized, and then do it if so. To distinguish between memory that
cannot be resized, add a new flag, LMB_NOOVERWRITE. Reserving a region
of memory with this attribute would indicate that the region cannot be
resized.

Signed-off-by: Sughosh Ganu 
---
 include/lmb.h |   1 +
 lib/lmb.c | 120 --
 2 files changed, 107 insertions(+), 14 deletions(-)

diff --git a/include/lmb.h b/include/lmb.h
index 03bce2a50c..1d4cd255d2 100644
--- a/include/lmb.h
+++ b/include/lmb.h
@@ -20,6 +20,7 @@
 enum lmb_flags {
LMB_NONE= 0x0,
LMB_NOMAP   = 0x4,
+   LMB_NOOVERWRITE = 0x8,
 };
 
 /**
diff --git a/lib/lmb.c b/lib/lmb.c
index de5a2cf23b..0a4f3d5bcd 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -260,12 +260,88 @@ void lmb_add_memory(struct bd_info *bd)
}
 }
 
+static bool lmb_region_flags_match(struct lmb_region *rgn, unsigned long r1,
+  enum lmb_flags flags)
+{
+   return rgn->region[r1].flags == flags;
+}
+
+static long lmb_merge_overlap_regions(struct lmb_region *rgn, unsigned long i,
+ phys_addr_t base, phys_size_t size,
+ enum lmb_flags flags)
+{
+   phys_size_t rgnsize;
+   unsigned long rgn_cnt, idx;
+   phys_addr_t rgnbase, rgnend;
+   phys_addr_t mergebase, mergeend;
+
+   rgn_cnt = 0;
+   idx = i;
+   /*
+* First thing to do is to identify how many regions does
+* the requested region overlap.
+* If the flags match, combine all these overlapping
+* regions into a single region, and remove the merged
+* regions.
+*/
+   while (idx < rgn->cnt - 1) {
+   rgnbase = rgn->region[idx].base;
+   rgnsize = rgn->region[idx].size;
+
+   if (lmb_addrs_overlap(base, size, rgnbase,
+ rgnsize)) {
+   if (!lmb_region_flags_match(rgn, idx, flags))
+   return -1;
+   rgn_cnt++;
+   idx++;
+   }
+   }
+
+   /* The merged region's base and size */
+   rgnbase = rgn->region[i].base;
+   mergebase = min(base, rgnbase);
+   rgnend = rgn->region[idx].base + rgn->region[idx].size;
+   mergeend = max(rgnend, (base + size));
+
+   rgn->region[i].base = mergebase;
+   rgn->region[i].size = mergeend - mergebase;
+
+   /* Now remove the merged regions */
+   while (--rgn_cnt)
+   lmb_remove_region(rgn, i + 1);
+
+   return 0;
+}
+
+static long lmb_resize_regions(struct lmb_region *rgn, unsigned long i,
+  phys_addr_t base, phys_size_t size,
+  enum lmb_flags flags)
+{
+   long ret = 0;
+   phys_addr_t rgnend;
+
+   if (i == rgn->cnt - 1 ||
+   base + size < rgn->region[i + 1].base) {
+   if (!lmb_region_flags_match(rgn, i, flags))
+   return -1;
+
+   rgnend = rgn->region[i].base + rgn->region[i].size;
+   rgn->region[i].base = min(base, rgn->region[i].base);
+   rgnend = max(base + size, rgnend);
+   rgn->region[i].size = rgnend - rgn->region[i].base;
+   } else {
+   ret = lmb_merge_overlap_regions(rgn, i, base, size, flags);
+   }
+
+   return ret;
+}
+
 /* This routine called with relocation disabled. */
 static long lmb_add_region_flags(struct lmb_region *rgn, phys_addr_t base,
 phys_size_t size, enum lmb_flags flags)
 {
unsigned long coalesced = 0;
-   long adjacent, i;
+   long ret, i;
 
if (rgn->cnt == 0) {
rgn->region[0].base = base;
@@ -290,23 +366,32 @@ static long lmb_add_region_flags(struct lmb_region *rgn, 
phys_addr_t base,
return -1; /* regions with new flags */
}
 
-   adjacent = lmb_addrs_adjacent(base, size, rgnbase, rgnsize);
-   if (adjacent > 0) {
+   ret = lmb_addrs_adjacent(base, size, rgnbase, rgnsize);
+   if (ret > 0) {
if (flags != rgnflags)
break;
rgn->region[i].base -= size;
rgn->region[i].size += size;
coalesced++;
break;
-   } else if (adjacent < 0) {
+

[RFC PATCH 08/31] lmb: replcace the lmb_init_and_reserve() function

2024-06-07 Thread Sughosh Ganu
With the changes to make the Logical Memory Block(LMB) allocations
persistent and with the common memory regions being reserved during
board init, the lmb_init_and_reserve() API can be removed and replaced
with a lmb_add_memory() API, which adds all the available memory to
the LMB pool.

Signed-off-by: Sughosh Ganu 
---
 arch/arm/mach-apple/board.c  |  2 +-
 arch/arm/mach-snapdragon/board.c |  2 +-
 arch/arm/mach-stm32mp/stm32mp1/cpu.c |  2 +-
 cmd/bdinfo.c |  2 +-
 cmd/load.c   |  2 +-
 fs/fs.c  |  2 +-
 include/lmb.h| 12 +++-
 lib/lmb.c| 15 +++
 net/tftp.c   |  2 +-
 net/wget.c   |  2 +-
 test/cmd/bdinfo.c| 10 +-
 11 files changed, 31 insertions(+), 22 deletions(-)

diff --git a/arch/arm/mach-apple/board.c b/arch/arm/mach-apple/board.c
index c877c7b94c..2e72d03edd 100644
--- a/arch/arm/mach-apple/board.c
+++ b/arch/arm/mach-apple/board.c
@@ -776,7 +776,7 @@ int board_late_init(void)
 {
u32 status = 0;
 
-   lmb_init_and_reserve(gd->bd, (void *)gd->fdt_blob);
+   lmb_add_memory(gd->bd);
 
/* somewhat based on the Linux Kernel boot requirements:
 * align by 2M and maximal FDT size 2M
diff --git a/arch/arm/mach-snapdragon/board.c b/arch/arm/mach-snapdragon/board.c
index a63c8bec45..b3c9a21419 100644
--- a/arch/arm/mach-snapdragon/board.c
+++ b/arch/arm/mach-snapdragon/board.c
@@ -282,7 +282,7 @@ int board_late_init(void)
 {
u32 status = 0;
 
-   lmb_init_and_reserve(gd->bd, (void *)gd->fdt_blob);
+   lmb_add_memory(gd->bd);
 
/* We need to be fairly conservative here as we support boards with 
just 1G of TOTAL RAM */
status |= env_set_hex("kernel_addr_r", addr_alloc(SZ_128M));
diff --git a/arch/arm/mach-stm32mp/stm32mp1/cpu.c 
b/arch/arm/mach-stm32mp/stm32mp1/cpu.c
index a223297034..8e3f001f74 100644
--- a/arch/arm/mach-stm32mp/stm32mp1/cpu.c
+++ b/arch/arm/mach-stm32mp/stm32mp1/cpu.c
@@ -143,7 +143,7 @@ int mach_cpu_init(void)
 void enable_caches(void)
 {
/* parse device tree when data cache is still activated */
-   lmb_init_and_reserve(gd->bd, (void *)gd->fdt_blob);
+   lmb_add_memory(gd->bd);
 
/* I-cache is already enabled in start.S: icache_enable() not needed */
 
diff --git a/cmd/bdinfo.c b/cmd/bdinfo.c
index e08d3e2cf3..fc408e9820 100644
--- a/cmd/bdinfo.c
+++ b/cmd/bdinfo.c
@@ -163,7 +163,7 @@ static int bdinfo_print_all(struct bd_info *bd)
bdinfo_print_num_l("multi_dtb_fit", (ulong)gd->multi_dtb_fit);
 #endif
if (IS_ENABLED(CONFIG_LMB) && gd->fdt_blob) {
-   lmb_init_and_reserve(gd->bd, (void *)gd->fdt_blob);
+   lmb_add_memory(gd->bd);
lmb_dump_all_force();
if (IS_ENABLED(CONFIG_OF_REAL))
printf("devicetree  = %s\n", fdtdec_get_srcname());
diff --git a/cmd/load.c b/cmd/load.c
index f019111991..9918523806 100644
--- a/cmd/load.c
+++ b/cmd/load.c
@@ -154,7 +154,7 @@ static ulong load_serial(long offset)
int line_count =  0;
long ret;
 
-   lmb_init_and_reserve(gd->bd, (void *)gd->fdt_blob);
+   lmb_add_memory(gd->bd);
 
while (read_record(record, SREC_MAXRECLEN + 1) >= 0) {
type = srec_decode(record, , , binbuf);
diff --git a/fs/fs.c b/fs/fs.c
index 3c54eaa366..f72d3962d1 100644
--- a/fs/fs.c
+++ b/fs/fs.c
@@ -549,7 +549,7 @@ static int fs_read_lmb_check(const char *filename, ulong 
addr, loff_t offset,
if (len && len < read_len)
read_len = len;
 
-   lmb_init_and_reserve(gd->bd, (void *)gd->fdt_blob);
+   lmb_add_memory(gd->bd);
lmb_dump_all();
 
if (lmb_alloc_addr(addr, read_len) == addr)
diff --git a/include/lmb.h b/include/lmb.h
index f3e3f716e5..03bce2a50c 100644
--- a/include/lmb.h
+++ b/include/lmb.h
@@ -84,7 +84,17 @@ struct lmb {
struct lmb_region reserved;
 };
 
-void lmb_init_and_reserve(struct bd_info *bd, void *fdt_blob);
+/**
+ * lmb_add_memory() - Add memory range for LMB allocations
+ * @bd: pointer to board info structure
+ *
+ * Add the entire available memory range to the pool of memory that
+ * can be used by the LMB module for allocations.
+ *
+ * Return: None
+ *
+ */
+void lmb_add_memory(struct bd_info *bd);
 long lmb_add(phys_addr_t base, phys_size_t size);
 long lmb_reserve(phys_addr_t base, phys_size_t size);
 /**
diff --git a/lib/lmb.c b/lib/lmb.c
index 5c056800c3..de5a2cf23b 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -240,8 +240,17 @@ void lmb_reserve_common(void *fdt_blob)
efi_lmb_reserve();
 }
 
-/* Initialize the struct, add memory and call arch/board reserve functions */
-void lmb_init_and_reserve(struct bd_info *bd, void *fdt_blob)
+/**
+ * lmb_add_memory() - Add memory range for LMB allocations
+ * @bd: pointer to board info 

[RFC PATCH 07/31] lmb: remove lmb_init_and_reserve_range() function

2024-06-07 Thread Sughosh Ganu
With the move to make the LMB allocations persistent and the common
memory regions being reserved during board init, the
lmb_init_and_reserve_range() API can be replaced with a simple
lmb_add() call.

Signed-off-by: Sughosh Ganu 
---
 boot/bootm.c  | 2 +-
 include/lmb.h | 2 --
 lib/lmb.c | 8 
 3 files changed, 1 insertion(+), 11 deletions(-)

diff --git a/boot/bootm.c b/boot/bootm.c
index cd1003120c..73e72a710d 100644
--- a/boot/bootm.c
+++ b/boot/bootm.c
@@ -248,7 +248,7 @@ static void boot_start_lmb(void)
mem_start = env_get_bootm_low();
mem_size = env_get_bootm_size();
 
-   lmb_init_and_reserve_range(mem_start, mem_size, NULL);
+   lmb_add(mem_start, mem_size);
 }
 #else
 #define lmb_reserve(base, size)
diff --git a/include/lmb.h b/include/lmb.h
index d2b829ace1..f3e3f716e5 100644
--- a/include/lmb.h
+++ b/include/lmb.h
@@ -85,8 +85,6 @@ struct lmb {
 };
 
 void lmb_init_and_reserve(struct bd_info *bd, void *fdt_blob);
-void lmb_init_and_reserve_range(phys_addr_t base, phys_size_t size,
-   void *fdt_blob);
 long lmb_add(phys_addr_t base, phys_size_t size);
 long lmb_reserve(phys_addr_t base, phys_size_t size);
 /**
diff --git a/lib/lmb.c b/lib/lmb.c
index 8003aae6f7..5c056800c3 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -253,14 +253,6 @@ void lmb_init_and_reserve(struct bd_info *bd, void 
*fdt_blob)
lmb_reserve_common(fdt_blob);
 }
 
-/* Initialize the struct, add memory and call arch/board reserve functions */
-void lmb_init_and_reserve_range(phys_addr_t base, phys_size_t size,
-   void *fdt_blob)
-{
-   lmb_add(base, size);
-   lmb_reserve_common(fdt_blob);
-}
-
 /* This routine called with relocation disabled. */
 static long lmb_add_region_flags(struct lmb_region *rgn, phys_addr_t base,
 phys_size_t size, enum lmb_flags flags)
-- 
2.34.1



[RFC PATCH 06/31] lmb: reserve and add common memory regions post relocation

2024-06-07 Thread Sughosh Ganu
The LMB module provides API's for allocating chunks of memory. The LMB
module should not be allocating memory regions that are in use, or
that might be occupied by the U-Boot image. Prevent allocations of
memory areas used by the U-Boot image by reserving these regions once
U-Boot has been relocated. Also add the rest of the memory that is
available for allocations to the LMB's memory map.

Signed-off-by: Sughosh Ganu 
---
 common/board_r.c | 15 +++
 include/lmb.h| 14 ++
 lib/lmb.c| 14 +-
 3 files changed, 42 insertions(+), 1 deletion(-)

diff --git a/common/board_r.c b/common/board_r.c
index da0b80f24f..a9f0b0cec1 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -555,6 +556,17 @@ static int run_main_loop(void)
return 0;
 }
 
+#if defined(CONFIG_LMB)
+static int initr_lmb(void)
+{
+   lmb_reserve_common((void *)gd->fdt_blob);
+
+   lmb_add_memory(gd->bd);
+
+   return 0;
+}
+#endif
+
 /*
  * Over time we hope to remove these functions with code fragments and
  * stub functions, and instead call the relevant function directly.
@@ -613,6 +625,9 @@ static init_fnc_t init_sequence_r[] = {
 #endif
 #ifdef CONFIG_EFI_LOADER
efi_memory_init,
+#endif
+#if defined(CONFIG_LMB)
+   initr_lmb,
 #endif
initr_binman,
 #ifdef CONFIG_FSP_VERSION2
diff --git a/include/lmb.h b/include/lmb.h
index 8f8a32c2ca..d2b829ace1 100644
--- a/include/lmb.h
+++ b/include/lmb.h
@@ -125,6 +125,20 @@ void board_lmb_reserve(void);
 void arch_lmb_reserve(void);
 void arch_lmb_reserve_generic(ulong sp, ulong end, ulong align);
 
+/**
+ * lmb_reserve_common() - Reserve memory region occupied by U-Boot image
+ * @fdt_blob: pointer to the FDT blob
+ *
+ * Reserve common areas of memory that are occupied by the U-Boot image.
+ * This function gets called once U-Boot has been relocated, so that any
+ * request for memory allocations would not touch memory region occupied
+ * by the U-Boot image, heap, bss etc.
+ *
+ * Return: None
+ *
+ */
+void lmb_reserve_common(void *fdt_blob);
+
 #endif /* __KERNEL__ */
 
 #endif /* _LINUX_LMB_H */
diff --git a/lib/lmb.c b/lib/lmb.c
index b0c9e2ef30..8003aae6f7 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -216,7 +216,19 @@ static __maybe_unused int efi_lmb_reserve(void)
return 0;
 }
 
-static void lmb_reserve_common(void *fdt_blob)
+/**
+ * lmb_reserve_common() - Reserve memory region occupied by U-Boot image
+ * @fdt_blob: pointer to the FDT blob
+ *
+ * Reserve common areas of memory that are occupied by the U-Boot image.
+ * This function gets called once U-Boot has been relocated, so that any
+ * request for memory allocations would not touch memory region occupied
+ * by the U-Boot image, heap, bss etc.
+ *
+ * Return: None
+ *
+ */
+void lmb_reserve_common(void *fdt_blob)
 {
arch_lmb_reserve();
board_lmb_reserve();
-- 
2.34.1



[RFC PATCH 04/31] lmb: remove local instances of the lmb structure variable

2024-06-07 Thread Sughosh Ganu
With the move of the LMB structure to a persistent state, there is no
need to declare the variable locally, and pass it as part of the LMB
API's. Remove all local variable instances and change the API's
correspondingly.

Signed-off-by: Sughosh Ganu 
---
 arch/arc/lib/cache.c |   4 +-
 arch/arm/lib/stack.c |   4 +-
 arch/arm/mach-apple/board.c  |  17 ++-
 arch/arm/mach-snapdragon/board.c |  17 ++-
 arch/arm/mach-stm32mp/dram_init.c|   7 +-
 arch/arm/mach-stm32mp/stm32mp1/cpu.c |   6 +-
 arch/m68k/lib/bootm.c|   7 +-
 arch/microblaze/lib/bootm.c  |   4 +-
 arch/mips/lib/bootm.c|   9 +-
 arch/nios2/lib/bootm.c   |   4 +-
 arch/powerpc/cpu/mpc85xx/mp.c|   4 +-
 arch/powerpc/include/asm/mp.h|   4 +-
 arch/powerpc/lib/bootm.c |  14 +-
 arch/riscv/lib/bootm.c   |   4 +-
 arch/sh/lib/bootm.c  |   4 +-
 arch/x86/lib/bootm.c |   4 +-
 arch/xtensa/lib/bootm.c  |   4 +-
 board/xilinx/common/board.c  |   7 +-
 boot/bootm.c |  26 ++--
 boot/bootm_os.c  |   5 +-
 boot/image-board.c   |  32 ++---
 boot/image-fdt.c |  29 ++---
 cmd/bdinfo.c |   6 +-
 cmd/booti.c  |   2 +-
 cmd/bootz.c  |   2 +-
 cmd/load.c   |   7 +-
 drivers/iommu/apple_dart.c   |   7 +-
 drivers/iommu/sandbox_iommu.c|  15 +--
 fs/fs.c  |   7 +-
 include/image.h  |  22 +---
 include/lmb.h|  39 +++---
 lib/lmb.c|  81 ++--
 net/tftp.c   |   5 +-
 net/wget.c   |   5 +-
 test/cmd/bdinfo.c|   2 +-
 test/lib/lmb.c   | 187 +--
 36 files changed, 270 insertions(+), 333 deletions(-)

diff --git a/arch/arc/lib/cache.c b/arch/arc/lib/cache.c
index 22e748868a..5151af917a 100644
--- a/arch/arc/lib/cache.c
+++ b/arch/arc/lib/cache.c
@@ -829,7 +829,7 @@ static ulong get_sp(void)
return ret;
 }
 
-void arch_lmb_reserve(struct lmb *lmb)
+void arch_lmb_reserve(void)
 {
-   arch_lmb_reserve_generic(lmb, get_sp(), gd->ram_top, 4096);
+   arch_lmb_reserve_generic(get_sp(), gd->ram_top, 4096);
 }
diff --git a/arch/arm/lib/stack.c b/arch/arm/lib/stack.c
index 656084c7e5..9e41c5d91e 100644
--- a/arch/arm/lib/stack.c
+++ b/arch/arm/lib/stack.c
@@ -43,7 +43,7 @@ static ulong get_sp(void)
return ret;
 }
 
-void arch_lmb_reserve(struct lmb *lmb)
+void arch_lmb_reserve(void)
 {
-   arch_lmb_reserve_generic(lmb, get_sp(), gd->ram_top, 16384);
+   arch_lmb_reserve_generic(get_sp(), gd->ram_top, 16384);
 }
diff --git a/arch/arm/mach-apple/board.c b/arch/arm/mach-apple/board.c
index 7a6151a972..c877c7b94c 100644
--- a/arch/arm/mach-apple/board.c
+++ b/arch/arm/mach-apple/board.c
@@ -774,23 +774,22 @@ u64 get_page_table_size(void)
 
 int board_late_init(void)
 {
-   struct lmb lmb;
u32 status = 0;
 
-   lmb_init_and_reserve(, gd->bd, (void *)gd->fdt_blob);
+   lmb_init_and_reserve(gd->bd, (void *)gd->fdt_blob);
 
/* somewhat based on the Linux Kernel boot requirements:
 * align by 2M and maximal FDT size 2M
 */
-   status |= env_set_hex("loadaddr", lmb_alloc(, SZ_1G, SZ_2M));
-   status |= env_set_hex("fdt_addr_r", lmb_alloc(, SZ_2M, SZ_2M));
-   status |= env_set_hex("kernel_addr_r", lmb_alloc(, SZ_128M, SZ_2M));
-   status |= env_set_hex("ramdisk_addr_r", lmb_alloc(, SZ_1G, SZ_2M));
+   status |= env_set_hex("loadaddr", lmb_alloc(SZ_1G, SZ_2M));
+   status |= env_set_hex("fdt_addr_r", lmb_alloc(SZ_2M, SZ_2M));
+   status |= env_set_hex("kernel_addr_r", lmb_alloc(SZ_128M, SZ_2M));
+   status |= env_set_hex("ramdisk_addr_r", lmb_alloc(SZ_1G, SZ_2M));
status |= env_set_hex("kernel_comp_addr_r",
- lmb_alloc(, KERNEL_COMP_SIZE, SZ_2M));
+ lmb_alloc(KERNEL_COMP_SIZE, SZ_2M));
status |= env_set_hex("kernel_comp_size", KERNEL_COMP_SIZE);
-   status |= env_set_hex("scriptaddr", lmb_alloc(, SZ_4M, SZ_2M));
-   status |= env_set_hex("pxefile_addr_r", lmb_alloc(, SZ_4M, SZ_2M));
+   status |= env_set_hex("scriptaddr", lmb_alloc(SZ_4M, SZ_2M));
+   status |= env_set_hex("pxefile_addr_r", lmb_alloc(SZ_4M, SZ_2M));
 
if (status)
log_warning("late_init: Failed to set run time variables\n");
diff --git a/arch/arm/mach-snapdragon/board.c b/arch/arm/mach-snapdragon/board.c
index b439a19ec7..a63c8bec45 100644
--- a/arch/arm/mach-snapdragon/board.c
+++ b/arch/arm/mach-snapdragon/board.c
@@ -275,24 +275,23 @@ void __weak qcom_late_init(void)
 
 #define KERNEL_COMP_SIZE   SZ_64M
 
-#define 

[RFC PATCH 05/31] lmb: pass a flag to image_setup_libfdt() for lmb reservations

2024-06-07 Thread Sughosh Ganu
The image_setup_libfdt() function optionally calls the LMB API to
reserve the region of memory occupied by the FDT blob. This was
earlier determined through the presence of the pointer to the lmb
structure, which is no longer present. Pass a flag to the
image_setup_libfdt() function to indicate if the region occupied by
the FDT blob is to be marked as reserved by the LMB module.

Signed-off-by: Sughosh Ganu 
---
 arch/mips/lib/bootm.c | 2 +-
 boot/image-board.c| 2 +-
 boot/image-fdt.c  | 7 +++
 cmd/elf.c | 2 +-
 include/image.h   | 5 ++---
 lib/efi_loader/efi_dt_fixup.c | 2 +-
 lib/efi_loader/efi_helper.c   | 2 +-
 7 files changed, 10 insertions(+), 12 deletions(-)

diff --git a/arch/mips/lib/bootm.c b/arch/mips/lib/bootm.c
index 54d89e9cca..e4fc2e589d 100644
--- a/arch/mips/lib/bootm.c
+++ b/arch/mips/lib/bootm.c
@@ -247,7 +247,7 @@ static int boot_setup_fdt(struct bootm_headers *images)
images->initrd_start = virt_to_phys((void *)images->initrd_start);
images->initrd_end = virt_to_phys((void *)images->initrd_end);
 
-   return image_setup_libfdt(images, images->ft_addr, >lmb);
+   return image_setup_libfdt(images, images->ft_addr, 0);
 }
 
 static void boot_prep_linux(struct bootm_headers *images)
diff --git a/boot/image-board.c b/boot/image-board.c
index 89ccf80066..481b333b4c 100644
--- a/boot/image-board.c
+++ b/boot/image-board.c
@@ -897,7 +897,7 @@ int image_setup_linux(struct bootm_headers *images)
}
 
if (CONFIG_IS_ENABLED(OF_LIBFDT) && of_size) {
-   ret = image_setup_libfdt(images, *of_flat_tree, lmb);
+   ret = image_setup_libfdt(images, *of_flat_tree, 1);
if (ret)
return ret;
}
diff --git a/boot/image-fdt.c b/boot/image-fdt.c
index 08afde203c..4daced9e99 100644
--- a/boot/image-fdt.c
+++ b/boot/image-fdt.c
@@ -567,8 +567,7 @@ __weak int arch_fixup_fdt(void *blob)
return 0;
 }
 
-int image_setup_libfdt(struct bootm_headers *images, void *blob,
-  struct lmb *lmb)
+int image_setup_libfdt(struct bootm_headers *images, void *blob, bool lmb)
 {
ulong *initrd_start = >initrd_start;
ulong *initrd_end = >initrd_end;
@@ -668,7 +667,7 @@ int image_setup_libfdt(struct bootm_headers *images, void 
*blob,
}
 
/* Delete the old LMB reservation */
-   if (lmb)
+   if (CONFIG_IS_ENABLED(LMB) && lmb)
lmb_free(map_to_sysmem(blob), fdt_totalsize(blob));
 
ret = fdt_shrink_to_minimum(blob, 0);
@@ -677,7 +676,7 @@ int image_setup_libfdt(struct bootm_headers *images, void 
*blob,
of_size = ret;
 
/* Create a new LMB reservation */
-   if (lmb)
+   if (CONFIG_IS_ENABLED(LMB) && lmb)
lmb_reserve(map_to_sysmem(blob), of_size);
 
 #if defined(CONFIG_ARCH_KEYSTONE)
diff --git a/cmd/elf.c b/cmd/elf.c
index df4354d374..00879de22b 100644
--- a/cmd/elf.c
+++ b/cmd/elf.c
@@ -89,7 +89,7 @@ int do_bootelf(struct cmd_tbl *cmdtp, int flag, int argc, 
char *const argv[])
printf("## Setting up FDT at 0x%08lx ...\n", fdt_addr);
flush();
 
-   if (image_setup_libfdt(, (void *)fdt_addr, NULL))
+   if (image_setup_libfdt(, (void *)fdt_addr, 0))
return 1;
}
 #endif
diff --git a/include/image.h b/include/image.h
index 8c619030ee..92ebe25548 100644
--- a/include/image.h
+++ b/include/image.h
@@ -1018,11 +1018,10 @@ int image_decomp(int comp, ulong load, ulong 
image_start, int type,
  *
  * @images:Images information
  * @blob:  FDT to update
- * @lmb:   Points to logical memory block structure
+ * @lmb:   Flag indicating use of lmb for reserving FDT memory region
  * Return: 0 if ok, <0 on failure
  */
-int image_setup_libfdt(struct bootm_headers *images, void *blob,
-  struct lmb *lmb);
+int image_setup_libfdt(struct bootm_headers *images, void *blob, bool lmb);
 
 /**
  * Set up the FDT to use for booting a kernel
diff --git a/lib/efi_loader/efi_dt_fixup.c b/lib/efi_loader/efi_dt_fixup.c
index 9886e6897c..4d50246c8f 100644
--- a/lib/efi_loader/efi_dt_fixup.c
+++ b/lib/efi_loader/efi_dt_fixup.c
@@ -172,7 +172,7 @@ efi_dt_fixup(struct efi_dt_fixup_protocol *this, void *dtb,
}
 
fdt_set_totalsize(dtb, *buffer_size);
-   if (image_setup_libfdt(, dtb, NULL)) {
+   if (image_setup_libfdt(, dtb, 0)) {
log_err("failed to process device tree\n");
ret = EFI_INVALID_PARAMETER;
goto out;
diff --git a/lib/efi_loader/efi_helper.c b/lib/efi_loader/efi_helper.c
index 73d0279e84..2d91f0edc3 100644
--- a/lib/efi_loader/efi_helper.c
+++ b/lib/efi_loader/efi_helper.c
@@ -469,7 +469,7 @@ efi_status_t efi_install_fdt(void *fdt)
return EFI_OUT_OF_RESOURCES;
}
 
-   if 

[RFC PATCH 03/31] lmb: make the lmb reservations persistent

2024-06-07 Thread Sughosh Ganu
The current LMB API's for allocating and reserving memory use a
per-caller based memory view. Memory allocated by a caller can then be
overwritten by another caller. Make these allocations and reservations
persistent. With this, memory allocated or reserved will not be
overwritten.

Signed-off-by: Sughosh Ganu 
---

Note: @Mark Kettenis, please review the changes made in the apple dart
driver. I have removed the driver-local LMB instance, but I am not
sure if the current logic makes sense. I would think that it would be
possible to simply use memory region allocated by the LMB module(maybe
using the max address argument), instead of adding specific memory
region with lmb_add().

 arch/arm/mach-stm32mp/dram_init.c |  1 -
 board/xilinx/common/board.c   |  1 -
 drivers/iommu/apple_dart.c|  1 -
 drivers/iommu/sandbox_iommu.c |  1 -
 include/lmb.h | 17 ++
 lib/lmb.c | 91 ---
 test/lib/lmb.c| 18 --
 7 files changed, 50 insertions(+), 80 deletions(-)

diff --git a/arch/arm/mach-stm32mp/dram_init.c 
b/arch/arm/mach-stm32mp/dram_init.c
index fb1208fc5d..86d6577b35 100644
--- a/arch/arm/mach-stm32mp/dram_init.c
+++ b/arch/arm/mach-stm32mp/dram_init.c
@@ -59,7 +59,6 @@ phys_addr_t board_get_usable_ram_top(phys_size_t total_size)
gd->ram_top = clamp_val(gd->ram_top, 0, SZ_4G - 1);
 
/* found enough not-reserved memory to relocated U-Boot */
-   lmb_init();
lmb_add(, gd->ram_base, gd->ram_top - gd->ram_base);
boot_fdt_add_mem_rsv_regions(, (void *)gd->fdt_blob);
/* add 8M for reserved memory for display, fdt, gd,... */
diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c
index b47d2d23f9..ebe57da7f8 100644
--- a/board/xilinx/common/board.c
+++ b/board/xilinx/common/board.c
@@ -685,7 +685,6 @@ phys_addr_t board_get_usable_ram_top(phys_size_t total_size)
panic("Not 64bit aligned DT location: %p\n", gd->fdt_blob);
 
/* found enough not-reserved memory to relocated U-Boot */
-   lmb_init();
lmb_add(, gd->ram_base, gd->ram_size);
boot_fdt_add_mem_rsv_regions(, (void *)gd->fdt_blob);
size = ALIGN(CONFIG_SYS_MALLOC_LEN + total_size, MMU_SECTION_SIZE);
diff --git a/drivers/iommu/apple_dart.c b/drivers/iommu/apple_dart.c
index 6ecd84303b..ef385d9c9f 100644
--- a/drivers/iommu/apple_dart.c
+++ b/drivers/iommu/apple_dart.c
@@ -214,7 +214,6 @@ static int apple_dart_probe(struct udevice *dev)
priv->dvabase = DART_PAGE_SIZE;
priv->dvaend = SZ_4G - DART_PAGE_SIZE;
 
-   lmb_init(>lmb);
lmb_add(>lmb, priv->dvabase, priv->dvaend - priv->dvabase);
 
/* Disable translations. */
diff --git a/drivers/iommu/sandbox_iommu.c b/drivers/iommu/sandbox_iommu.c
index 6ceb7fd5ec..31ce91345c 100644
--- a/drivers/iommu/sandbox_iommu.c
+++ b/drivers/iommu/sandbox_iommu.c
@@ -55,7 +55,6 @@ static int sandbox_iommu_probe(struct udevice *dev)
 {
struct sandbox_iommu_priv *priv = dev_get_priv(dev);
 
-   lmb_init(>lmb);
lmb_add(>lmb, 0x89abc000, SZ_16K);
 
return 0;
diff --git a/include/lmb.h b/include/lmb.h
index 7b87181b9e..bbe1c5299c 100644
--- a/include/lmb.h
+++ b/include/lmb.h
@@ -49,8 +49,7 @@ struct lmb_property {
  * => CONFIG_LMB_MEMORY_REGIONS: struct lmb.memory_regions
  * => CONFIG_LMB_RESERVED_REGIONS: struct lmb.reserved_regions
  * lmb_region.region is only a pointer to the correct buffer,
- * initialized in lmb_init(). This configuration is useful to manage
- * more reserved memory regions with CONFIG_LMB_RESERVED_REGIONS.
+ * initialized with these values.
  */
 
 /**
@@ -73,26 +72,18 @@ struct lmb_region {
 /**
  * struct lmb - Logical memory block handle.
  *
- * Clients provide storage for Logical memory block (lmb) handles.
- * The content of the structure is managed by the lmb library.
- * A lmb struct is  initialized by lmb_init() functions.
- * The lmb struct is passed to all other lmb APIs.
+ * The Logical Memory Block structure which is used to keep track
+ * of available memory which can be used for stuff like loading
+ * images(kernel, initrd, fdt).
  *
  * @memory: Description of memory regions.
  * @reserved: Description of reserved regions.
- * @memory_regions: Array of the memory regions (statically allocated)
- * @reserved_regions: Array of the reserved regions (statically allocated)
  */
 struct lmb {
struct lmb_region memory;
struct lmb_region reserved;
-#if !IS_ENABLED(CONFIG_LMB_USE_MAX_REGIONS)
-   struct lmb_property memory_regions[CONFIG_LMB_MEMORY_REGIONS];
-   struct lmb_property reserved_regions[CONFIG_LMB_RESERVED_REGIONS];
-#endif
 };
 
-void lmb_init(struct lmb *lmb);
 void lmb_init_and_reserve(struct lmb *lmb, struct bd_info *bd, void *fdt_blob);
 void lmb_init_and_reserve_range(struct lmb *lmb, phys_addr_t base,

[RFC PATCH 02/31] lmb: staticize __lmb_alloc_base()

2024-06-07 Thread Sughosh Ganu
The __lmb_alloc_base() function is only called from within the lmb
module. Moreover, the lmb_alloc() and lmb_alloc_base() API's are good
enough for the allocation API calls. Make the __lmb_alloc_base()
function static.

Signed-off-by: Sughosh Ganu 
---
 include/lmb.h |  2 --
 lib/lmb.c | 39 ---
 2 files changed, 20 insertions(+), 21 deletions(-)

diff --git a/include/lmb.h b/include/lmb.h
index 6c50d93e83..7b87181b9e 100644
--- a/include/lmb.h
+++ b/include/lmb.h
@@ -112,8 +112,6 @@ long lmb_reserve_flags(struct lmb *lmb, phys_addr_t base,
 phys_addr_t lmb_alloc(struct lmb *lmb, phys_size_t size, ulong align);
 phys_addr_t lmb_alloc_base(struct lmb *lmb, phys_size_t size, ulong align,
   phys_addr_t max_addr);
-phys_addr_t __lmb_alloc_base(struct lmb *lmb, phys_size_t size, ulong align,
-phys_addr_t max_addr);
 phys_addr_t lmb_alloc_addr(struct lmb *lmb, phys_addr_t base, phys_size_t 
size);
 phys_size_t lmb_get_free_size(struct lmb *lmb, phys_addr_t addr);
 
diff --git a/lib/lmb.c b/lib/lmb.c
index adc3abd5b4..4d39c0d1f9 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -435,30 +435,13 @@ static long lmb_overlaps_region(struct lmb_region *rgn, 
phys_addr_t base,
return (i < rgn->cnt) ? i : -1;
 }
 
-phys_addr_t lmb_alloc(struct lmb *lmb, phys_size_t size, ulong align)
-{
-   return lmb_alloc_base(lmb, size, align, LMB_ALLOC_ANYWHERE);
-}
-
-phys_addr_t lmb_alloc_base(struct lmb *lmb, phys_size_t size, ulong align, 
phys_addr_t max_addr)
-{
-   phys_addr_t alloc;
-
-   alloc = __lmb_alloc_base(lmb, size, align, max_addr);
-
-   if (alloc == 0)
-   printf("ERROR: Failed to allocate 0x%lx bytes below 0x%lx.\n",
-  (ulong)size, (ulong)max_addr);
-
-   return alloc;
-}
-
 static phys_addr_t lmb_align_down(phys_addr_t addr, phys_size_t size)
 {
return addr & ~(size - 1);
 }
 
-phys_addr_t __lmb_alloc_base(struct lmb *lmb, phys_size_t size, ulong align, 
phys_addr_t max_addr)
+static phys_addr_t __lmb_alloc_base(struct lmb *lmb, phys_size_t size,
+   ulong align, phys_addr_t max_addr)
 {
long i, rgn;
phys_addr_t base = 0;
@@ -499,6 +482,24 @@ phys_addr_t __lmb_alloc_base(struct lmb *lmb, phys_size_t 
size, ulong align, phy
return 0;
 }
 
+phys_addr_t lmb_alloc(struct lmb *lmb, phys_size_t size, ulong align)
+{
+   return lmb_alloc_base(lmb, size, align, LMB_ALLOC_ANYWHERE);
+}
+
+phys_addr_t lmb_alloc_base(struct lmb *lmb, phys_size_t size, ulong align, 
phys_addr_t max_addr)
+{
+   phys_addr_t alloc;
+
+   alloc = __lmb_alloc_base(lmb, size, align, max_addr);
+
+   if (alloc == 0)
+   printf("ERROR: Failed to allocate 0x%lx bytes below 0x%lx.\n",
+  (ulong)size, (ulong)max_addr);
+
+   return alloc;
+}
+
 /*
  * Try to allocate a specific address range: must be in defined memory but not
  * reserved
-- 
2.34.1



[RFC PATCH 01/31] lmb: remove the unused lmb_is_reserved() function

2024-06-07 Thread Sughosh Ganu
The lmb_is_reserved() API is not used. There is another API,
lmb_is_reserved_flags() which can be used to check if a particular
memory region is reserved. Remove the unused API.

Signed-off-by: Sughosh Ganu 
---
 include/lmb.h | 11 ---
 lib/lmb.c |  5 -
 2 files changed, 16 deletions(-)

diff --git a/include/lmb.h b/include/lmb.h
index 231b68b27d..6c50d93e83 100644
--- a/include/lmb.h
+++ b/include/lmb.h
@@ -117,17 +117,6 @@ phys_addr_t __lmb_alloc_base(struct lmb *lmb, phys_size_t 
size, ulong align,
 phys_addr_t lmb_alloc_addr(struct lmb *lmb, phys_addr_t base, phys_size_t 
size);
 phys_size_t lmb_get_free_size(struct lmb *lmb, phys_addr_t addr);
 
-/**
- * lmb_is_reserved() - test if address is in reserved region
- *
- * The function checks if a reserved region comprising @addr exists.
- *
- * @lmb:   the logical memory block struct
- * @addr:  address to be tested
- * Return: 1 if reservation exists, 0 otherwise
- */
-int lmb_is_reserved(struct lmb *lmb, phys_addr_t addr);
-
 /**
  * lmb_is_reserved_flags() - test if address is in reserved region with flag 
bits set
  *
diff --git a/lib/lmb.c b/lib/lmb.c
index 44f9820531..adc3abd5b4 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -565,11 +565,6 @@ int lmb_is_reserved_flags(struct lmb *lmb, phys_addr_t 
addr, int flags)
return 0;
 }
 
-int lmb_is_reserved(struct lmb *lmb, phys_addr_t addr)
-{
-   return lmb_is_reserved_flags(lmb, addr, LMB_NONE);
-}
-
 __weak void board_lmb_reserve(struct lmb *lmb)
 {
/* please define platform specific board_lmb_reserve() */
-- 
2.34.1



[RFC PATCH 00/31] Make U-Boot memory reservations coherent

2024-06-07 Thread Sughosh Ganu


The aim of this patch series is to fix the current state of
incoherence between modules when it comes to memory usage. The primary
issue that this series is trying to fix is that the EFI memory module
which is responsible for allocating and freeing memory, does not have
any visibility of the memory that is being used by the LMB
module. This is further complicated by the fact that the LMB
allocations are caller specific -- the LMB memory map is not global
nor persistent. This means that the memory "allocated" by the LMB
module might be relevant only for a given function. Hence one of the
requirements for making the memory usage visible across modules is to
make LMB allocations persistent and global, and then have means to
communicate the use of memory across modules.

The first set of patches in this series work on making the LMB memory
map persistent and global. This is being done keeping in mind the
usage of LMB memory by platforms where the same memory region can be
used to load multiple different images. What is not allowed is to
overwrite memory that has been allocated by the other module,
currently the EFI memory module. This is being achieved by introducing
a new flag, LMB_NOOVERWRITE, which represents memory which cannot be
re-requested once allocated.

The second set of patches are then introducing a notification
mechanism to indicate any changes to a respective module's memory
map. This way, any memory allocation/reservation by a module gets
notified to any interested listners, who then update their memory map
accordingly, thus keeping memory usage coherent.

Todo's
--
I have run these patches through CI, but the LMB unit tests need an
overhaul. I have currently marked these tests for manual run, as
running these would obviously tamper the LMB memory map, thus
affecting subsequent tests. The current set of LMB tests are written
with the assumption of local LMB memory maps. This needs to be
reworked.

Secondly, there needs to be a test written for testing the various
scenarios of memory being allocated and freed by different modules,
namely LMB and EFI. I have written a couple of commands for testing
the changes that I have made -- I have also included these temporary
commands to assist anyone who might want to test these changes. But I
will be working on adding a more comprehensive test.

Lastly, as the series touches common code, there is obviously an
increase in the size of the image, moreover since the LMB memory is
now persistent, and the variables do not reside on the stack. I want
to check if there can be ways of decreasing the size impact of the
changes.


Sughosh Ganu (31):
  lmb: remove the unused lmb_is_reserved() function
  lmb: staticize __lmb_alloc_base()
  lmb: make the lmb reservations persistent
  lmb: remove local instances of the lmb structure variable
  lmb: pass a flag to image_setup_libfdt() for lmb reservations
  lmb: reserve and add common memory regions post relocation
  lmb: remove lmb_init_and_reserve_range() function
  lmb: replcace the lmb_init_and_reserve() function
  lmb: allow for resizing lmb regions
  event: add events to notify memory map changes
  lib: Kconfig: add a config symbol for getting memory map updates
  add a function to check if an address is in RAM memory
  efi_memory: notify of any changes to the EFI memory map
  lmb: notify of any changes to the LMB memory map
  efi_memory: add an event handler to update memory map
  lmb: add an event handler to update memory map
  lmb: remove call to efi_lmb_reserve()
  sandbox: iommu: remove lmb allocation in the driver
  zynq: lmb: do not add to lmb map before relocation
  test: cedit: use allocated address for reading file
  test: event: update the expected event dump output
  test: lmb: run the LMB tests only on sandbox
  test: lmb: initialise the lmb structure before tests
  test: lmb: add a test case for checking overlapping region add
  test: lmb: adjust the test case to handle overlapping regions
  test: lmb: run lmb tests only manually
  test: bdinfo: dump the global LMB memory map
  cmd: bdinfo: only dump the current LMB memory
  temp: mx6sabresd: bump up the size limit of the board
  temp: cmd: efi_mem: add a command to test efi alloc/free
  temp: cmd: efi: add a command to dump EFI memory map

 arch/arc/lib/cache.c |   4 +-
 arch/arm/lib/stack.c |   4 +-
 arch/arm/mach-apple/board.c  |  17 +-
 arch/arm/mach-snapdragon/board.c |  17 +-
 arch/arm/mach-stm32mp/dram_init.c|   8 +-
 arch/arm/mach-stm32mp/stm32mp1/cpu.c |   6 +-
 arch/m68k/lib/bootm.c|   7 +-
 arch/microblaze/lib/bootm.c  |   4 +-
 arch/mips/lib/bootm.c|  11 +-
 arch/nios2/lib/bootm.c   |   4 +-
 arch/powerpc/cpu/mpc85xx/mp.c|   4 +-
 arch/powerpc/include/asm/mp.h|   4 +-
 arch/powerpc/lib/bootm.c |  14 +-
 arch/riscv/lib/bootm.c   |   4 +-
 arch/sandbox/cpu/cpu.c   |   5 +
 

Re: [PATCH] doc: Add UEFI supplement document

2024-06-07 Thread Heinrich Schuchardt

On 29.05.24 15:36, Jiaxun Yang wrote:

Add UEFI supplement document to define some behaviours
on architectures not covered by the original specification.

Signed-off-by: Jiaxun Yang 
---
Hi all,

This document is in response to discussion at [1]. It is produced
based on my attempt to port U-Boot UEFI to MIPS and Xtensa. I also
plan to try m68k.

Please review

Thanks
[1]: 
https://lore.kernel.org/u-boot/cac_iwjlby6+fauyqw2zv5y5bycnxrhxfzvrff1dmyjx+anp...@mail.gmail.com/
---
  doc/develop/uefi/index.rst   |  1 +
  doc/develop/uefi/uefi_supplement.rst | 73 
  2 files changed, 74 insertions(+)

diff --git a/doc/develop/uefi/index.rst b/doc/develop/uefi/index.rst
index e26b1fbe05c5..a274fff88754 100644
--- a/doc/develop/uefi/index.rst
+++ b/doc/develop/uefi/index.rst
@@ -11,6 +11,7 @@ can be run an UEFI payload.
 :maxdepth: 2

 uefi.rst
+   uefi_supplement.rst
 u-boot_on_efi.rst
 iscsi.rst
 fwu_updates.rst
diff --git a/doc/develop/uefi/uefi_supplement.rst 
b/doc/develop/uefi/uefi_supplement.rst
new file mode 100644
index ..cb20cd290912
--- /dev/null
+++ b/doc/develop/uefi/uefi_supplement.rst
@@ -0,0 +1,73 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. Copyright (c) 2024 Jiaxun Yang 
+
+U-Boot Supplement to UEFI Specifications
+
+
+Motivation
+--
+
+The UEFI specifications are designed to be platform-independent, enabling the
+implementation of UEFI-like API support across various architectures. However,
+some platform-dependent aspects and constraints remain. This document provides
+a supplement to the UEFI specifications for U-Boot, clarifying these platform
+dependent details for architectures not covered by the original specifications.


This does not explain why we should bother about any non-UEFI
architecture. It does not list relevant architectures and does not
provide any evidence that this more than an academic endeavor.

All git repositories you mentioned in you MIPS series have not seen any
update in the last four years.

If any company were sincerely interested in using UEFI on such
architectures, wouldn't they contribute to the specification like has
been done for LoongArch and RISC-V?

It does not make sense to define UEFI for non-UEFI architectures in
U-Boot. Isn't there any existing documentation for UEFI on MIPS?


+
+Architectural Conventions
+-
+
+The UEFI specifications cover IA32, X64, ARM, AARCH64, RISC-V, LoongArch, and


There is only one UEFI specification.

%s/specifications cover/specification covers/


+Itanium architectures. This document extends the UEFI specifications to include
+all architectures supported by U-Boot.
+
+The following conventions are used for these architectures:
+
+- For architectures with multiple ABIs, we adhere to the calling conventions
+  used by the Linux kernel for the same architecture.
+
+- Optional CPU registers (floating-point, SIMD) are excluded from calling
+  conventions. However, the UEFI payload should be able to utilize them if
+  available.
+
+- Control is handed over to the UEFI payload at the privilege level used
+  by the Linux kernel for the same architecture.


This does not provide enough detail. The Linux kernel can run at
different privilege levels on the same architecture, e.g. in S-mode or
M-mode on RISC-V.


+
+- Identity mapping (i.e., VA == PA mapping) is preferred for UEFI. However,
+  this may not be possible for some architectures. In such cases, if the
+  processor supports a default linear translation, it should be used.
+
+- Endianness: UEFI specifications enforce little-endian architectures.
+  However, U-Boot supports both little-endian and big-endian architectures.
+  For big-endian architectures, UEFI data structures should be stored in
+  native endianness, with exceptions explicitly specified.


Why do you bother about big-endian systems? MIPS supports low-endian.
Linux distros like Debian have dropped big-endian MIPS support.

If found https://www.ventoy.net/en/doc_mips64el.html (MIPS64EL UEFI) but
nothing describing big-endian usage of UEFI.


+
+UEFI Images
+---
+
+The UEFI specifications define the PE/COFF image format for UEFI applications.
+U-Boot extends this format as follows:


The UEFI specification does not define the PE/COFF image format. It
prescribes its usage.


+
+- **PE32+ Machine Type**: UEFI specifications define machine types for 
supported
+  architectures. For machines not covered by UEFI specifications, we use the
+  machine type defined by the Microsoft PE/COFF specification if possible.
+  Otherwise, we use the ``IMAGE_FILE_MACHINE_UNKNOWN`` (0) machine type.
+  U-Boot should always accept ``IMAGE_FILE_MACHINE_UNKNOWN`` as a valid
+  machine type.


We should not accept IMAGE_FILE_MACHINE_UNKNOWN on an architecture that
has a machine type defined in the PE-COFF specification.

Which MIPS machine type are you missing?


+
+- **Header 

Re: [PATCH 0/7] MIPS: Enable EFI support

2024-06-07 Thread Heinrich Schuchardt

On 17.05.24 18:32, Jiaxun Yang wrote:

Hi all,

This series enabled EFI support to MIPS platform.

Although MIPS is not defined by UEFI specification, there are
quite a few firmware implementations available, including
MIPS-EFI[1] for Loongson-2F, Lemote's proprietary EDK2 implementation
on Loongson-3[2], Kunlun firmware for Loongson-3[3], efiffy[4]
for MIPS Creator CI20 and another mystery EDK implementation shipped
with some Creator CI20 board.

Available applications including gnu-efi, Loongson's GRUB fork[5],
Ventoy[6].

My implementation in U-Boot is aiming to follow conventions made
by other implementations for architecture stuff and remain
compliance with spec for general aspects.

bootefi hello and selftest passed on both 32 and 64 bit system,
gnu-efi, grub and ventoy are tested on mips64el with my pending
platform works. mips32el efi executable from efiffy is tested
as well.

Please review.
Thanks

[1]: https://github.com/kontais/EFI-MIPS


Last commit 8 years ago.


[2]: https://github.com/loongson-community/firmware-nonfree


Last commit 4 years ago.


[3]: http://www.kunluntech.com.cn/klbiosxl
[4]: https://sourceforge.net/projects/efify/


Last commit 2018.


[5]: https://github.com/loongson-community/grub


Last commit 5 year ago.

This looks like riding a dead horse.

Best regards

Heinrich



[6]: https://www.ventoy.net/en/index.html

Signed-off-by: Jiaxun Yang 
---
Jiaxun Yang (7):
   MIPS: Implement setjmp
   efi: Allow runtime relocate to be disabled
   Makefile.lib: Preserve .rodata section for EFI file
   Makefile.lib: Enforce EFI CFLAGS/AFLAGS
   MIPS: Add smbios_start to arch_global_data
   MIPS: Define MIPS EFI related bits everywhere
   MIPS: Implement EFI supporting stuff

  Makefile  |   3 +
  arch/mips/config.mk   |   9 +
  arch/mips/include/asm/global_data.h   |   3 +
  arch/mips/include/asm/setjmp.h|  36 
  arch/mips/lib/Makefile|  15 ++
  arch/mips/lib/crt0_mips_efi.S | 239 ++
  arch/mips/lib/elf_mips_efi.lds| 113 ++
  arch/mips/lib/reloc_mips_efi.c|  99 +
  arch/mips/lib/setjmp32.S  |  51 +
  arch/mips/lib/setjmp64.S  |  56 +
  include/asm-generic/pe.h  |   5 +
  include/config_distro_bootcmd.h   |   6 +
  include/efi_default_filename.h|   8 +
  include/efi_loader.h  |  26 ++-
  include/elf.h |   8 +
  lib/efi_loader/Kconfig|  12 +-
  lib/efi_loader/efi_image_loader.c |  18 ++
  lib/efi_loader/efi_memory.c   |  14 +-
  lib/efi_loader/efi_runtime.c  |  11 +-
  lib/efi_loader/efi_var_mem.c  |   6 +-
  lib/efi_selftest/Makefile |   2 +-
  lib/efi_selftest/efi_selftest_miniapp_exception.c |   2 +
  scripts/Makefile.lib  |  10 +-
  23 files changed, 734 insertions(+), 18 deletions(-)
---
base-commit: ad7dce5abd49ef3b5c93da5303e15449c8c162b4
change-id: 20240517-mips-efi-c9a1ad819c2d

Best regards,




Re: [PATCH 2/2] arm64: add software pagetable walker

2024-06-07 Thread Tom Rini
On Fri, Jun 07, 2024 at 06:51:20PM +0200, Caleb Connolly wrote:

> Add a basic software implementation of the ARM64 pagetable walker. This
> can be used for debugging U-Boot's pagetable, as well as dumping the
> pagetable from the previous bootloader stage if it used one (by reading
> out the ttbr address).
> 
> One can either call dump_pagetable() to print the pagetable to the
> console with the default formatter, or implement their own pagetable
> handler using walke_pagetable() with a custom pte_walker_cb_t callback.
> 
> Signed-off-by: Caleb Connolly 
> ---
>  arch/arm/cpu/armv8/cache_v8.c| 202 
> +++
>  arch/arm/include/asm/armv8/mmu.h |  55 +++
>  2 files changed, 257 insertions(+)

So, I assume that by default, all of this gets discarded as unused code
and that's why it's not behind a Kconfig. Next, please add something
under maybe doc/arch/ or doc/develop (I'm honestly not sure which is
best) that documents all of this. Thanks!

-- 
Tom


signature.asc
Description: PGP signature


[PATCH 2/2] arm64: add software pagetable walker

2024-06-07 Thread Caleb Connolly
Add a basic software implementation of the ARM64 pagetable walker. This
can be used for debugging U-Boot's pagetable, as well as dumping the
pagetable from the previous bootloader stage if it used one (by reading
out the ttbr address).

One can either call dump_pagetable() to print the pagetable to the
console with the default formatter, or implement their own pagetable
handler using walke_pagetable() with a custom pte_walker_cb_t callback.

Signed-off-by: Caleb Connolly 
---
 arch/arm/cpu/armv8/cache_v8.c| 202 +++
 arch/arm/include/asm/armv8/mmu.h |  55 +++
 2 files changed, 257 insertions(+)

diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
index d4c64f2d60d9..cb7c0e61ba70 100644
--- a/arch/arm/cpu/armv8/cache_v8.c
+++ b/arch/arm/cpu/armv8/cache_v8.c
@@ -395,8 +395,210 @@ static int count_ranges(void)
 
return count;
 }
 
+#define ALL_ATTRS (3 << 8 | PMD_ATTRINDX_MASK)
+#define PTE_IS_TABLE(pte, level) (pte_type(&(pte)) == PTE_TYPE_TABLE && 
(level) < 3)
+
+enum walker_state {
+   WALKER_STATE_START = 0,
+   WALKER_STATE_TABLE,
+   WALKER_STATE_REGION, /* block or page, depending on level */
+};
+
+static void __pagetable_walk(u64 addr, u64 tcr, int level, pte_walker_cb_t cb, 
void *priv)
+{
+   u64 *table = (u64 *)addr;
+   u64 attrs, last_attrs = 0, last_addr = 0, entry_start = 0;
+   int i;
+   u64 va_bits = 64 - (tcr & (BIT(6) - 1));
+   static enum walker_state state[4] = { 0 };
+   static bool exit;
+
+   if (!level) {
+   exit = false;
+   if (va_bits < 39)
+   level = 1;
+   }
+
+   state[level] = WALKER_STATE_START;
+
+   /* Walk through the table entries */
+   for (i = 0; i < MAX_PTE_ENTRIES; i++) {
+   u64 pte = table[i];
+   u64 _addr = pte & GENMASK_ULL(va_bits, PAGE_SHIFT);
+
+   if (exit)
+   return;
+
+   if (pte_type() == PTE_TYPE_FAULT)
+   continue;
+
+   attrs = pte & ALL_ATTRS;
+   /* If we're currently inside a block or set of pages */
+   if (state[level] > WALKER_STATE_START && state[level] != 
WALKER_STATE_TABLE) {
+   /*
+* Continue walking if this entry has the same 
attributes as the last and
+* is one page/block away -- it's a contiguous region.
+*/
+   if (attrs == last_attrs && _addr == last_addr + (1 << 
level2shift(level))) {
+   last_attrs = attrs;
+   last_addr = _addr;
+   continue;
+   } else {
+   /* We either hit a table or a new region */
+   exit = cb(entry_start, last_addr + (1 << 
level2shift(level)),
+ va_bits, level, priv);
+   if (exit)
+   return;
+   state[level] = WALKER_STATE_START;
+   }
+   }
+   last_attrs = attrs;
+   last_addr = _addr;
+
+   if (PTE_IS_TABLE(pte, level)) {
+   /* After the end of the table might be corrupted data */
+   if (!_addr || (pte & 0xfff) > 0x3ff)
+   return;
+   state[level] = WALKER_STATE_TABLE;
+   /* Signify the start of a table */
+   exit = cb(pte, 0, va_bits, level, priv);
+   if (exit)
+   return;
+
+   /* Go down a level */
+   __pagetable_walk(_addr, tcr, level + 1, cb, priv);
+   state[level] = WALKER_STATE_START;
+   } else if (pte_type() == PTE_TYPE_BLOCK || pte_type() 
== PTE_TYPE_PAGE) {
+   /* We foud a block or page, start walking */
+   entry_start = pte;
+   state[level] = WALKER_STATE_REGION;
+   }
+   }
+
+   if (state[level] > WALKER_STATE_START)
+   exit = cb(entry_start, last_addr + (1 << level2shift(level)), 
va_bits, level, priv);
+}
+
+static void pretty_print_pte_type(u64 pte)
+{
+   switch (pte_type()) {
+   case PTE_TYPE_FAULT:
+   printf(" %-5s", "Fault");
+   break;
+   case PTE_TYPE_BLOCK:
+   printf(" %-5s", "Block");
+   break;
+   case PTE_TYPE_PAGE:
+   printf(" %-5s", "Pages");
+   break;
+   default:
+   printf(" %-5s", "Unk");
+   }
+}
+
+static void pretty_print_table_attrs(u64 pte)
+{
+   int ap = (pte & PTE_TABLE_AP) >> 61;
+
+   printf(" | %2s %10s",
+  (ap 

[PATCH 1/2] arm64: mmu.h: fix PTE_TABLE_AP

2024-06-07 Thread Caleb Connolly
The APTable attribute is two bits wide according to the ARMv8-A
architecture reference manual. Fix the macro accordingly.

Signed-off-by: Caleb Connolly 
---
 arch/arm/include/asm/armv8/mmu.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/armv8/mmu.h b/arch/arm/include/asm/armv8/mmu.h
index ce655ce7a952..52cb18b9ed5e 100644
--- a/arch/arm/include/asm/armv8/mmu.h
+++ b/arch/arm/include/asm/armv8/mmu.h
@@ -50,9 +50,9 @@
 #define PTE_TYPE_VALID (1 << 0)
 
 #define PTE_TABLE_PXN  (1UL << 59)
 #define PTE_TABLE_XN   (1UL << 60)
-#define PTE_TABLE_AP   (1UL << 61)
+#define PTE_TABLE_AP   (3UL << 61)
 #define PTE_TABLE_NS   (1UL << 63)
 
 /*
  * Block

-- 
2.45.0



[PATCH 0/2] arm64: add a software pagetable walker

2024-06-07 Thread Caleb Connolly
MMU issues are some of the most frustrating to debug. To make this
slightly less unbearable, introduce a software pagetable walker for
ARMv8. This can be called to dump a pagetable with the default
formatter, or a custom callback can be provided to implement more
complicated parsing.

This can also be useful to dump the pagetable used by a previous
bootloader stage (by reading out the ttbr register).

Here is an example of the output when walking U-Boot's own memory map
on a Qualcomm RB3 board:

Walking pagetable at 00017df9, va_bits: 36. Using 3 levels
[0x17df91000]   |  Table |   |
  [0x17df92000] |  Table |   |
[0x01000 - 0x00020] |  Pages | Device-nGnRnE | Non-shareable
  [0x00020 - 0x04000]   |  Block | Device-nGnRnE | Non-shareable
[0x04000 - 0x08000] |  Block | Device-nGnRnE | Non-shareable
[0x08000 - 0x14000] |  Block | Normal| Inner-shareable
[0x17df93000]   |  Table |   |
  [0x14000 - 0x17de0]   |  Block | Normal| Inner-shareable
  [0x17df94000] |  Table |   |
[0x17de0 - 0x17dfa] |  Pages | Normal| Inner-shareable

---
Caleb Connolly (2):
  arm64: mmu.h: fix PTE_TABLE_AP
  arm64: add software pagetable walker

 arch/arm/cpu/armv8/cache_v8.c| 202 +++
 arch/arm/include/asm/armv8/mmu.h |  57 ++-
 2 files changed, 258 insertions(+), 1 deletion(-)
---
change-id: 20240607-caleb-upstreaming-82744a2786b3
base-commit: 22ca7e13dc02be83c29450aeadd8e150ebdd

// Caleb (they/them)



Re: [PATCH] doc: board: sophgo: milkv_duo: Update Milk-V Duo documentation

2024-06-07 Thread Heinrich Schuchardt

On 23.05.24 08:40, Kongyang Liu wrote:

Add detailed steps for compiling U-Boot and OpenSBI, generating the
firmware package with fiptool, and booting the board.

Signed-off-by: Kongyang Liu 
---

  doc/board/sophgo/milkv_duo.rst | 41 +-
  1 file changed, 30 insertions(+), 11 deletions(-)

diff --git a/doc/board/sophgo/milkv_duo.rst b/doc/board/sophgo/milkv_duo.rst
index cb2ed1ad98..a88db5b903 100644
--- a/doc/board/sophgo/milkv_duo.rst
+++ b/doc/board/sophgo/milkv_duo.rst
@@ -20,31 +20,50 @@ Building
  .. code-block:: console


There are is a 64 MiB version of the Milk-V Duo with the CF1800B, a 256 
MiB version with the SG2002 and a Milk-V Duo S with the SG2000.


This may confuse U-Boot users. Should we mention explicitly that only 
the CF1800B based board is supported?


  
 export CROSS_COMPILE=

+
+3. Compile U-Boot
+
+.. code-block:: console
+
 cd 
 make milkv_duo_defconfig
 make
  
-This will generate u-boot-dtb.bin

+This will generate u-boot.bin and u-boot.dtb
  
-Booting

-~~~
-Currently, we rely on vendor FSBL(First Stage Boot Loader) to initialize the
-clock and load the u-boot image, then bootup from it.
+4. Compile OpenSBI
+
+.. code-block:: console
  
-Alternatively, to run u-boot-dtb.bin on top of FSBL, follow these steps:

+   cd 
+   make PLATFORM=generic FW_FDT_PATH=/u-boot.dtb
  
-1. Use the vendor-provided tool to create a unified fip.bin file containing

-   FSBL, OpenSBI, and U-Boot.
+This will generate fw_dynamic.bin
  
-2. Place the generated fip.bin file into the FAT partition of the SD card.

+4. Generate firmware image package
  
-3. Insert the SD card into the board and power it on.

+Fiptool(https://github.com/sophgo/fiptool) is used to generate fip file.
+
+.. code-block:: console
+
+   git clone https://github.com/sophgo/fiptool
+   cd fiptool
+   ./fiptool \
+  --fsbl data/fsbl/cv180x.bin \


Where do we get this file from?


+  --opensbi /fw_dynamic.bin \
+  --uboot /u-boot.bin \
+
+This will generate fip.bin


Should we let binman do this in future?


+
+Booting
+~~~
+1. Place the generated fip.bin file into the FAT partition of the SD card.


This information is insufficient to set up a new SD-card.

Should the SD card be MBR or GPT partitioned?

On an SD card there are typically are multiple partitions. All of these 
may be FAT partioned. Does the boot ROM use a fixed partition number, a 
partition type, or a start sector to identify the relevant partition?


It is left unclear if fip.bin is to be copied by dd to the partition or 
into a FAT file system on the partition.




I just downloaded the vendor milkv-duo-v1.1.1-2024-0528.img.zip file.

Here I found an MBR partition table with the following partitions:

Device  Boot   Start End Sectors  Size Id Type
milkv-duo-v1.1.1-2024-0528.img1 *  1  262144  262144  128M  c 
W95 FAT32 (LBA)

milkv-duo-v1.1.1-2024-0528.img2   262145 1835008 1572864  768M 83 Linux
milkv-duo-v1.1.1-2024-0528.img3  1835009 2359296  524288  256M  0 Empty

Partition 1 was FAT16 partitioned and contained file fip.bin in the root 
directory. But I still don't know how the relevant partition is identified.


Best regards

Heinrich


+2. Insert the SD card into the board and power it on.
  
  The board will automatically execute the FSBL from the fip.bin file.

  Subsequently, it will transition to OpenSBI, and finally, OpenSBI will invoke
  U-Boot.
  
-

  Sample boot log from Milk-V Duo board
  ~
  .. code-block:: none




Re: [PATCH] spmi: msm: disable read/write log

2024-06-07 Thread Neil Armstrong

On 07/06/2024 16:22, Caleb Connolly wrote:

Most devices have buttons exposed via the PMIC, the button polling
therefore triggers a log spam if debug logging is enabled.

Someone would only ever want to log SPMI read/writes to debug very
specific issues, they can then uncomment these debug logs.


My bad sorry...



Signed-off-by: Caleb Connolly 
---
  drivers/spmi/spmi-msm.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/spmi/spmi-msm.c b/drivers/spmi/spmi-msm.c
index b0d6226041e5..58c676423f40 100644
--- a/drivers/spmi/spmi-msm.c
+++ b/drivers/spmi/spmi-msm.c
@@ -118,9 +118,9 @@ static int msm_spmi_write(struct udevice *dev, int usid, 
int pid, int off,
return -EPERM;
  
  	channel = priv->channel_map[usid][pid] & SPMI_CHANNEL_MASK;
  
-	dev_dbg(dev, "[%d:%d] %s: channel %d\n", usid, pid, __func__, channel);

+   //dev_dbg(dev, "[%d:%d] %s: channel %d\n", usid, pid, __func__, 
channel);


Perhaps dev_vdbg would be better ?

  
  	switch (priv->arb_ver) {

case V1:
ch_offset = SPMI_CH_OFFSET(channel);
@@ -185,9 +185,9 @@ static int msm_spmi_read(struct udevice *dev, int usid, int 
pid, int off)
return -EIO;
  
  	channel = priv->channel_map[usid][pid] & SPMI_CHANNEL_MASK;
  
-	dev_dbg(dev, "[%d:%d] %s: channel %d\n", usid, pid, __func__, channel);

+   //dev_dbg(dev, "[%d:%d] %s: channel %d\n", usid, pid, __func__, 
channel);
  
  	switch (priv->arb_ver) {

case V1:
ch_offset = SPMI_CH_OFFSET(channel);




[PATCH] spmi: msm: disable read/write log

2024-06-07 Thread Caleb Connolly
Most devices have buttons exposed via the PMIC, the button polling
therefore triggers a log spam if debug logging is enabled.

Someone would only ever want to log SPMI read/writes to debug very
specific issues, they can then uncomment these debug logs.

Signed-off-by: Caleb Connolly 
---
 drivers/spmi/spmi-msm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/spmi/spmi-msm.c b/drivers/spmi/spmi-msm.c
index b0d6226041e5..58c676423f40 100644
--- a/drivers/spmi/spmi-msm.c
+++ b/drivers/spmi/spmi-msm.c
@@ -118,9 +118,9 @@ static int msm_spmi_write(struct udevice *dev, int usid, 
int pid, int off,
return -EPERM;
 
channel = priv->channel_map[usid][pid] & SPMI_CHANNEL_MASK;
 
-   dev_dbg(dev, "[%d:%d] %s: channel %d\n", usid, pid, __func__, channel);
+   //dev_dbg(dev, "[%d:%d] %s: channel %d\n", usid, pid, __func__, 
channel);
 
switch (priv->arb_ver) {
case V1:
ch_offset = SPMI_CH_OFFSET(channel);
@@ -185,9 +185,9 @@ static int msm_spmi_read(struct udevice *dev, int usid, int 
pid, int off)
return -EIO;
 
channel = priv->channel_map[usid][pid] & SPMI_CHANNEL_MASK;
 
-   dev_dbg(dev, "[%d:%d] %s: channel %d\n", usid, pid, __func__, channel);
+   //dev_dbg(dev, "[%d:%d] %s: channel %d\n", usid, pid, __func__, 
channel);
 
switch (priv->arb_ver) {
case V1:
ch_offset = SPMI_CH_OFFSET(channel);
-- 
2.45.0



Re: [PATCH v3 00/12] Introduce the lwIP network stack

2024-06-07 Thread Tom Rini
On Fri, Jun 07, 2024 at 11:11:49AM +0200, Jerome Forissier wrote:
> 
> 
> On 6/6/24 18:56, Tom Rini wrote:
> > On Thu, Jun 06, 2024 at 03:35:55PM +0200, Jerome Forissier wrote:
> > 
> >> This is a rework of a patch series by Maxim Uvarov: "net/lwip: add lwip
> >> library for the network stack" [1]. The goal is to introduce the lwIP 
> >> TCP/IP
> >> stack [2] [3] as an alternative to the current implementation in net/,
> >> selectable with Kconfig, and ultimately keep only lwIP if possible. Some
> >> reasons for doing so are:
> >> - Make the support of HTTPS in the wget command easier. Javier T. (CC'd)
> >> has some additional lwIP and Mbed TLS patches to do so. With that it
> >> becomes possible to fetch and launch a distro installer such as Debian
> >> etc. using a secure, authenticated connection directly from the U-Boot
> >> shell. Several use cases:
> >>   * Authentication: prevent MITM attack (third party replacing the
> >> binary with a different one)
> >>   * Confidentiality: prevent third parties from grabbing a copy of the
> >> image as it is being downloaded
> >>   * Allow connection to servers that do not support plain HTTP anymore
> >> (this is becoming more and more common on the Internet these days)
> >> - Possibly benefit from additional features implemented in lwIP
> >> - Less code to maintain in U-Boot
> > 
> > Alright, on Pi 3, I think we have more "output changed, test fails"
> > problems:
> > == FAILURES 
> > ===
> > _ test_efi_fit_launch 
> > _
> > test/py/tests/test_efi_fit.py:452: in test_efi_fit_launch
> > launch_efi(False, False)
> > test/py/tests/test_efi_fit.py:394: in launch_efi
> > net_set_up = net_dhcp()
> > test/py/tests/test_efi_fit.py:178: in net_dhcp
> > assert 'DHCP client bound to address ' in output
> > E   AssertionError: assert 'DHCP client bound to address ' in 'Waiting for 
> > Ethernet connection... done.\r\neth0: smsc95xx_eth b8:27:eb:fc:64:a6 active'
> >  Captured stdout call 
> > -
> > U-Boot> usb start
> > U-Boot> U-Boot> setenv autoload no
> > U-Boot> U-Boot> dhcp
> > Waiting for Ethernet connection... done.
> > eth0: smsc95xx_eth b8:27:eb:fc:64:a6 active
> > U-Boot>
> > === short test summary info 
> > ===
> > 
> > I'm going to skip that set of tests and see how far we get but I suspect
> > it'll keep failing on DHCP output being different.
> 
> As discussed offline with Ilias it might be a timeout issue, although 2000 ms
> for DHCP_TIMEOUT_MS seems a large value to me, it might not be enough in your
> environment. Can you please try to increase it? NET effectively has a timeout
> of 28 seconds if we take the retries into account.

I increased it to 2 ms and no change.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] arm: mvebu: Enable bootstd and other modernization for Synology DS414 (Armada XP) board

2024-06-07 Thread Phil Sutter
Hi Tony,

On Thu, Jun 06, 2024 at 04:44:36PM -0700, Tony Dinh wrote:
> - Switch to standard boot (in include/configs/ds414.h and
> configs/ds414_defconfig)
> - Implement board_late_init() to ensure successful enumeration
> of USB3 devices

Oh, this makes the rear USB3 ports usable? I had failed to get there
when working on DS414 support.

> - Remove unnecessary misc_init_r(), since NET_RANDOM_ETHADDR is now
> configured in

So u-boot will assign random MAC addresses to the NICs instead of the
real ones? Won't this potentially break PXE boot setups?

> - Remove unnecessary checkboard()
> - Updated IDENT_STRING to indicate this u-boot supports both Synology
> DS414 and DS214+ boards
> - Add SYS_THUMB_BUILD to reduce binary size
> - Add NET_RANDOM_ETHADDR
> - Add CONFIG_LBA48 and CONFIG_SYS_64BIT_LBA to support >2TB HDD/SDD
> 
> Signed-off-by: Tony Dinh 
> ---
> 
>  board/Synology/ds414/ds414.c | 15 +++
>  configs/ds414_defconfig  | 20 ++
>  include/configs/ds414.h  | 51 ++--
>  3 files changed, 42 insertions(+), 44 deletions(-)
> 
> diff --git a/board/Synology/ds414/ds414.c b/board/Synology/ds414/ds414.c
> index abe6f9eb5e..f0b55fa095 100644
> --- a/board/Synology/ds414/ds414.c
> +++ b/board/Synology/ds414/ds414.c
> @@ -181,18 +181,9 @@ int board_init(void)
>   return 0;
>  }
>  
> -int misc_init_r(void)
> +int board_late_init(void)
>  {
> - if (!env_get("ethaddr")) {
> - puts("Incomplete environment, populating from SPI flash\n");
> - do_syno_populate(0, NULL);
> - }
> - return 0;
> -}

This is useful for first boot of flashed vanilla u-boot. Can this be
retained somehow?

[...]
> diff --git a/include/configs/ds414.h b/include/configs/ds414.h
> index 9446acba79..bbefe632e0 100644
> --- a/include/configs/ds414.h
> +++ b/include/configs/ds414.h
[...]
> @@ -38,23 +34,38 @@
>   * L2 cache thus cannot be used.
>   */
>  
> -/* SPL */
> -/* Defines for SPL */
> +/* Keep device tree and initrd in lower memory so the kernel can access them 
> */
> +#define RELOCATION_LIMITS_ENV_SETTINGS  \
> + "fdt_high=0x1000\0" \
> + "initrd_high=0x1000\0"
> +
> +/*
> + * mv-common.h should be defined after CMD configs since it used them
> + * to enable certain macros
> + */
> +#include "mv-common.h"
> +
> +#ifndef CONFIG_SPL_BUILD
>  
> -/* Default Environment */
> +#define KERNEL_ADDR_R__stringify(0x100)
> +#define FDT_ADDR_R   __stringify(0x200)
> +#define RAMDISK_ADDR_R   __stringify(0x220)
> +#define SCRIPT_ADDR_R__stringify(0x180)
> +#define PXEFILE_ADDR_R   __stringify(0x190)
>  
> -#define CFG_EXTRA_ENV_SETTINGS   \
> - "initrd_high=0x\0"  \
> - "ramdisk_addr_r=0x800\0"\
> - "usb0Mode=host\0usb1Mode=host\0usb2Mode=device\0"   \
> - "ethmtu=1500\0eth1mtu=1500\0"   \
> - "update_uboot=sf probe; dhcp; " \
> - "mw.b ${loadaddr} 0x0 0xd; "\
> - "tftpboot ${loadaddr} u-boot-with-spl.kwb; "\
> - "sf update ${loadaddr} 0x0 0xd\0"

Are these dropped or am I missing a generic spot which adds them? IIRC,
the usb*mode and eth*mtu settings are required, is that wrong? Lastly,
that update_uboot macro at least helps preventing people from writing
into wrong spots. What's the cause for dropping it?

Thanks, Phil


  1   2   >