qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v11 2/3] hw/riscv/boot.c: consolidate all kernel init in risc


From: Alistair Francis
Subject: Re: [PATCH v11 2/3] hw/riscv/boot.c: consolidate all kernel init in riscv_load_kernel()
Date: Tue, 7 Feb 2023 08:54:38 +1000

On Tue, Feb 7, 2023 at 6:19 AM Daniel Henrique Barboza
<dbarboza@ventanamicro.com> wrote:
>
>
>
> On 2/6/23 16:54, Richard Henderson wrote:
> > On 2/6/23 04:00, Daniel Henrique Barboza wrote:
> >> To not change the behavior of boards that aren't calling
> >> riscv_load_init(), add an 'load_initrd' flag to riscv_load_kernel() and
> >> allow these boards to opt out from initrd loading.
> >
> > Surely this is simply a bug for those boards.
> >
> > I cannot believe, for instance, that sifive_u should allow initrd and 
> > sifive_e must not.
> >
> > Backward compatible behaviour is had simply by not providing the 
> > command-line argument.
>
> That makes sense but the question here is whether the sifive_e board supports
> -initrd if the option is provided. I tend to believe that it does, and the 
> current
> code state is mostly an oversight (we forgot to add load_initrd() support for 
> the
> board) rather than an intentional design choice, but since I'm not sure about
> it I opted for playing it safe.
>
> If someone can guarantee that the sifive_e and the opentitan boards are 
> capable of
> -initrd loading I can re-send this patch without the 'load_initrd' flag.

Those boards can only boot small scale RTOS-like OSes or baremetal
code. Which is why they don't support the -initrd option.

I guess there isn't much harm in allowing an initrd, although I'm not
really sure when it would be used.

Alistair

>
>
> Thanks,
>
> Daniel
>
> >
> >
> > r~
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]