[PATCH 1/1] examples: use QEMU compatible LOAD_ADDR on 32-bit ARM

Heinrich Schuchardt heinrich.schuchardt at canonical.com
Sat Nov 23 23:59:36 CET 2024


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 at 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 at 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).
> 



More information about the U-Boot mailing list