| Message ID | 20241123084853.59252-1-heinrich.schuchardt@canonical.com |
|---|---|
| State | New |
| Delegated to: | Heinrich Schuchardt |
| Headers | show |
| Series | [1/1] examples: use QEMU compatible LOAD_ADDR on 32-bit ARM | expand |
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-heinrich.schuchardt@canonical.com/ 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-heinrich.schuchardt@canonical.com/ > > 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-heinrich.schuchardt@canonical.com/ >> >> 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
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 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(-)