hi team,

The ITS file looks something like the following, and the kernel is not a 
standard Linux kernel:
```
/dts-v1/;

/ {
    ...
    images {
        kernel {
            type = "kernel";
            arch = "riscv";
            os = "elf";
            ...
        };

        fdt {
            type = "flat_dt";
            arch = "riscv";
            ...
        };
    };
    ...
};
```

To handle this scenario, we need to:

  1.
Access the values of the `type`, os, and arch fields stored in 
bootm_headers->image_info to determine the current context.
  2.
Access the boot_hart and ft_addr stored in the gd variable to update argc and 
argv.

Not sure whether accessing the bootm_headers and gd variables in lib/elf.c is 
allowed or safe.

BR,
zhihong
________________________________
发件人: Heinrich Schuchardt <xypron.g...@gmx.de>
发送时间: 2025年5月24日 12:29
收件人: Tom Rini <tr...@konsulko.com>
抄送: Simon Glass <s...@chromium.org>; 牛 志宏 <zone.ni...@hotmail.com>; 
u-boot@lists.denx.de <u-boot@lists.denx.de>; Leo Yu-Chi Liang 
<ycli...@andestech.com>; Rick Chen <r...@andestech.com>
主题: Re: [PATCH] bootm: Pass SMP core ID and DTB address for ELF-formatted 
kernels

On 5/24/25 00:29, Tom Rini wrote:
> On Fri, May 23, 2025 at 07:04:46PM +0200, Heinrich Schuchardt wrote:
>> Am 23. Mai 2025 18:41:45 MESZ schrieb Simon Glass <s...@chromium.org>:
>>> +Heinrich Schuchardt
>>>
>>> Hi,
>>>
>>> On Tue, 13 May 2025 at 13:28, 牛 志宏 <zone.ni...@hotmail.com> wrote:
>>>>
>>>> When booting RISC-V ELF-formatted kernel images (IH_TYPE_KERNEL + 
>>>> IH_OS_ELF),
>>>> explicitly pass SMP core/hart ID and DTB address to comply with modern
>>>> SMP-enabled kernels' boot protocol requirements.
>>>>
>>>> Signed-off-by: Zone.N <zone.ni...@hotmail.com>
>>>> ---
>>>>   boot/bootm_os.c | 5 +++++
>>>>   1 file changed, 5 insertions(+)
>>>>
>>>> diff --git a/boot/bootm_os.c b/boot/bootm_os.c
>>>> index a3c7cb5332e..a0f310b1359 100644
>>>> --- a/boot/bootm_os.c
>>>> +++ b/boot/bootm_os.c
>>>> @@ -402,6 +402,11 @@ static int do_bootm_elf(int flag, struct bootm_info 
>>>> *bmi)
>>>>          if (flag != BOOTM_STATE_OS_GO)
>>>>                  return 0;
>>>>
>>>> +#if defined(CONFIG_RISCV)
>>>> +       bmi->argc = gd->arch.boot_hart;
>>>> +       bmi->argv = (char **)bmi->images->ft_addr;
>>>> +#endif
>>>
>>> If this is a kernel, it should really be using a FIT.  The Elf entry
>>> is for general ELF files, not Linux. Perhaps RISC-V is special in some
>>> way?
>>
>> A defconfig kernel is booted via the booti command or via its EFI stub.
>>
>> Why would you use an ELF formatted kernel? What kernel configuration are you 
>> using to get such a kernel?
>
> This is I assume a non-Linux OS kernel being booted. So the question is,
> does anyone externally have some standard defined here which should be
> used?
>

https://docs.kernel.org/arch/riscv/boot.html describes the requirements:

"The RISC-V kernel expects:

         $a0 to contain the hartid of the current core.

         $a1 to contain the address of the devicetree in memory."

Both the bootm command and the bootelf command end up calling
bootelf_exec(). So the correction should probably be made in lib/elf.c
and not in /boot/bootm_os.c.

a0 and a1 are the the first and second arguments in the RISC-V calling
convention.

Using a0 and a1 as required by the kernel is completely incompatible
with the current design of the bootelf command where you can pass
arbitrary string arguments to an ELF binary.

CONFIG_CMD_ELF_FDT_SETUP allows to pass a device-tree address string as
argv[0].

It is unclear to me if there are use cases where we want to execute ELF
binaries that are not OS kernels via the bootelf or bootm command.

The RISC-V maintainers should review any change for RISC-V in the
handling of ELF binaries.

Best regards

Heinrich

Reply via email to