Re: 回复: 回复: [PATCH] bootm: Pass SMP core ID and DTB address for ELF-formatted kernels

[Yao Zi <ziyao@disroot.org>]

On Thu, Jun 05, 2025 at 08:04:28AM +0000, 牛 志宏 wrote:
> Yes, this is a new OS currently being developed with plans to support Linux compatibility.
> Registers a0 and a1 pass the boot core ID and DTB address respectively, following a de facto standard shared by both the SBI (RISC-V Supervisor Binary Interface) specification and the Linux implementation.
> My rationale is: if U-Boot supports the combination of kernel + ELF loading, why shouldn't we implement this capability as well?

Do you mean passing arguments according to the convention of Linux even
when booting ELF stuff?

TBH, it should be easy to turn your ELF into an Linux-style Image...

> 
> ________________________________
> 发件人: Tom Rini
> 已发送: 2025 年 5 月 29 日 星期四 23:49
> 收件人: 牛 志宏
> 抄送: Heinrich Schuchardt; Simon Glass; u-boot@lists.denx.de; Leo Yu-Chi Liang; Rick Chen
> 主题: Re: 回复: [PATCH] bootm: Pass SMP core ID and DTB address for ELF-formatted kernels
> 
> On Thu, May 29, 2025 at 09:33:56AM +0000, 牛 志宏 wrote:
> > 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.
> So this is why I was asking if there's some more generalized
> specification we can reference. Is the OS you're using something
> pre-existing and so we need to do what it already expect from some other
> loader? Or is it something you're also creating and if so, why not
> follow the linux kernel convention for compatibility?
> 
> --
> Tom

Regards,
Yao Zi