On 11/23/24 23:55, Tom Rini wrote:
On Sat, Nov 23, 2024 at 07:23:35PM +0100, Heinrich Schuchardt wrote:
Tom Rini <[email protected]> schrieb am Sa., 23. Nov. 2024, 16:24:
On Sat, Nov 23, 2024 at 09:48:53AM +0100, Heinrich Schuchardt wrote:
On many 32-bit ARM boards including QEMU memory starts at 0x40000000.
Signed-off-by: Heinrich Schuchardt <[email protected]>
---
examples/api/Makefile | 4 ----
1 file changed, 4 deletions(-)
diff --git a/examples/api/Makefile b/examples/api/Makefile
index 722c7e45904..f0f107562f1 100644
--- a/examples/api/Makefile
+++ b/examples/api/Makefile
@@ -9,11 +9,7 @@ ifeq ($(ARCH),powerpc)
LOAD_ADDR = 0x40000
endif
ifeq ($(ARCH),arm)
-ifdef CONFIG_64BIT
LOAD_ADDR = 0x40400000
-else
-LOAD_ADDR = 0x1000000
-endif
endif
ifeq ($(ARCH),mips)
ifdef CONFIG_64BIT
If we're going to start cleaning this area up and expecting it to work
more broadly, is there a reason we can't use CONFIG_SYS_LOAD_ADDR or
CONFIG_STANDALONE_LOAD_ADDR here?
loadaddr == CONFIG_SYS_LOAD_ADDR on RISC-V QEMU. Command bootelf did not
work for me, if the ELF binary had been loaded to its LOAD_ADDR.
I did not investigate yet why bootelf fails in this case.
The examples, broadly speaking, do not run out of the box since they
assume an address to be loaded in to memory at and run from, rather than
a Kconfig entry. The next problem for RISC-V is that, well, there's no
api/api_platform-riscv.c file (and forever ago I steered people away
https://patchwork.ozlabs.org/project/uboot/patch/[email protected]/
provides api_platform.c for RISC-V. This patch is only about ARM.
Best regards
Heinrich
from adding that and instead adding EFI support, the patches are in
patchwork somewhere).
