[PATCH 1/1] examples: use QEMU compatible LOAD_ADDR on 32-bit ARM
On many 32-bit ARM boards including QEMU memory starts at 0x40000000.
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com --- 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
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 heinrich.schuchardt@canonical.com
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?
Tom Rini trini@konsulko.com 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 heinrich.schuchardt@canonical.com
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.
Best regards
Heinrich
-- Tom
On Sat, Nov 23, 2024 at 07:23:35PM +0100, Heinrich Schuchardt wrote:
Tom Rini trini@konsulko.com 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 heinrich.schuchardt@canonical.com
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 from adding that and instead adding EFI support, the patches are in patchwork somewhere).
On 11/23/24 23:55, Tom Rini wrote:
On Sat, Nov 23, 2024 at 07:23:35PM +0100, Heinrich Schuchardt wrote:
Tom Rini trini@konsulko.com 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 heinrich.schuchardt@canonical.com
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/20241123084754.59182-2-hein...
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).
On Sat, Nov 23, 2024 at 11:59:36PM +0100, Heinrich Schuchardt wrote:
On 11/23/24 23:55, Tom Rini wrote:
On Sat, Nov 23, 2024 at 07:23:35PM +0100, Heinrich Schuchardt wrote:
Tom Rini trini@konsulko.com 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 heinrich.schuchardt@canonical.com
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/20241123084754.59182-2-hein...
provides api_platform.c for RISC-V. This patch is only about ARM.
Yeah. For everyone we need to move this to Kconfig and it should likely be STANDALONE_LOAD_ADDR being re-used and not a new symbol. Hard coded might-work addresses are a leftover of pre-Kconfig days.
On 11/24/24 00:14, Tom Rini wrote:
On Sat, Nov 23, 2024 at 11:59:36PM +0100, Heinrich Schuchardt wrote:
On 11/23/24 23:55, Tom Rini wrote:
On Sat, Nov 23, 2024 at 07:23:35PM +0100, Heinrich Schuchardt wrote:
Tom Rini trini@konsulko.com 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 heinrich.schuchardt@canonical.com
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/20241123084754.59182-2-hein...
provides api_platform.c for RISC-V. This patch is only about ARM.
Yeah. For everyone we need to move this to Kconfig and it should likely be STANDALONE_LOAD_ADDR being re-used and not a new symbol. Hard coded might-work addresses are a leftover of pre-Kconfig days.
The following seems to work in the Makefile:
LOAD_ADDR:=${shell printf 0x%X $$(( $(CONFIG_SYS_LOAD_ADDR) + 0x3000000 ))}
I just need to check which offset to use.
Best regards
Heinrich
participants (2)
-
Heinrich Schuchardt -
Tom Rini