Hi drew,
On Mon, Jul 3, 2023 at 9:01 PM Andrew Jones <[email protected]> wrote:
>
>
> (This is a reply to a non-existent cover letter.)
This has been discussed many times with Ard, Please refer to :
https://patches.linaro.org/project/linux-acpi/patch/[email protected]/
> I'm not a big fan of adding yet another interface. Have you considered
> doing something like [1]?
>
> [1] https://github.com/tianocore/tianocore.github.io/wiki/UefiPayloadPkg
>
> Thanks,
> drew
Thanks,
Yunhui
On Mon, Jul 03, 2023 at 09:30:10PM +0800, 运辉崔 wrote:
> Hi drew,
>
> On Mon, Jul 3, 2023 at 9:01 PM Andrew Jones <[email protected]> wrote:
> >
> >
> > (This is a reply to a non-existent cover letter.)
>
> This has been discussed many times with Ard, Please refer to :
> https://patches.linaro.org/project/linux-acpi/patch/[email protected]/
There's nothing in that thread that convinces me this is a good idea.
Indeed, afaict from that thread, Ard nacked this. It was only when it
was suggested that arch/riscv would own the code, that he stopped
complaining about it. I wouldn't call that an endorsement.
Thanks,
drew
>
>
> > I'm not a big fan of adding yet another interface. Have you considered
> > doing something like [1]?
> >
> > [1] https://github.com/tianocore/tianocore.github.io/wiki/UefiPayloadPkg
> >
> > Thanks,
> > drew
>
> Thanks,
> Yunhui
On Mon, Jul 03, 2023 at 04:17:07PM +0200, Andrew Jones wrote:
> On Mon, Jul 03, 2023 at 09:30:10PM +0800, 运辉崔 wrote:
> > On Mon, Jul 3, 2023 at 9:01 PM Andrew Jones <[email protected]> wrote:
> > >
> > >
> > > (This is a reply to a non-existent cover letter.)
> >
> > This has been discussed many times with Ard, Please refer to :
> > https://patches.linaro.org/project/linux-acpi/patch/[email protected]/
>
> There's nothing in that thread that convinces me this is a good idea.
> Indeed, afaict from that thread, Ard nacked this. It was only when it
> was suggested that arch/riscv would own the code, that he stopped
> complaining about it. I wouldn't call that an endorsement.
In fact, he expressly said that it would then be up to the RISC-V
maintainers as to what to do:
But please check with the RISC-V maintainers
if they are up for this, and whether they want to see this mechanism
contributed to one of the pertinent specifications.
On Mon, 3 Jul 2023 at 15:33, 运辉崔 <[email protected]> wrote:
>
> Hi drew,
>
> On Mon, Jul 3, 2023 at 9:01 PM Andrew Jones <[email protected]> wrote:
> >
> >
> > (This is a reply to a non-existent cover letter.)
>
> This has been discussed many times with Ard, Please refer to :
> https://patches.linaro.org/project/linux-acpi/patch/[email protected]/
Hi Yunhui,
From that discussion it was mentioned that that arm supports 3 methods
of booting:
direct + devicetree
EFI + devicetree
EFI + ACPI
..but not
direct + ACPI
To me it isn't obvious from that or this thread, and since arm seems
to be doing fine without the 4th option I'm curious why that's
necessary on riscv?
> > I'm not a big fan of adding yet another interface. Have you considered
> > doing something like [1]?
> >
> > [1] https://github.com/tianocore/tianocore.github.io/wiki/UefiPayloadPkg
Also you didn't answer this question, which I'd also like to hear a reply to.
/Emil
> > Thanks,
> > drew
>
> Thanks,
> Yunhui
>
> _______________________________________________
> linux-riscv mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-riscv
On 3 Jul 2023, at 19:58, Emil Renner Berthing <[email protected]> wrote:
>
> On Mon, 3 Jul 2023 at 15:33, 运辉崔 <[email protected]> wrote:
>>
>> Hi drew,
>>
>> On Mon, Jul 3, 2023 at 9:01 PM Andrew Jones <[email protected]> wrote:
>>>
>>>
>>> (This is a reply to a non-existent cover letter.)
>>
>> This has been discussed many times with Ard, Please refer to :
>> https://patches.linaro.org/project/linux-acpi/patch/[email protected]/
>
> Hi Yunhui,
>
> From that discussion it was mentioned that that arm supports 3 methods
> of booting:
> direct + devicetree
> EFI + devicetree
> EFI + ACPI
> ..but not
> direct + ACPI
>
> To me it isn't obvious from that or this thread, and since arm seems
> to be doing fine without the 4th option I'm curious why that's
> necessary on riscv?
If anything we should be removing option 1, because that’s not a
cross-OS standard (though RISC-V’s SBI direct booting is at least not
tied to the OS). Any application-class platform spec is going to
mandate EFI, because, whatever your thoughts of EFI are, that is *the*
standard. And if you’re willing to pick up all the complexity of ACPI,
what’s a bit of EFI (especially if you only go for a minimal one a la
U-Boot)?
Jess
>>> I'm not a big fan of adding yet another interface. Have you considered
>>> doing something like [1]?
>>>
>>> [1] https://github.com/tianocore/tianocore.github.io/wiki/UefiPayloadPkg
>
> Also you didn't answer this question, which I'd also like to hear a reply to.
>
> /Emil
>
>>> Thanks,
>>> drew
>>
>> Thanks,
>> Yunhui
>>
>> _______________________________________________
>> linux-riscv mailing list
>> [email protected]
>> http://lists.infradead.org/mailman/listinfo/linux-riscv
>
> _______________________________________________
> linux-riscv mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-riscv
Jessica Clarke <[email protected]> writes:
> On 3 Jul 2023, at 19:58, Emil Renner Berthing <[email protected]> wrote:
>>
>> On Mon, 3 Jul 2023 at 15:33, 运辉崔 <[email protected]> wrote:
>>>
>>> Hi drew,
>>>
>>> On Mon, Jul 3, 2023 at 9:01 PM Andrew Jones <[email protected]> wrote:
>>>>
>>>>
>>>> (This is a reply to a non-existent cover letter.)
>>>
>>> This has been discussed many times with Ard, Please refer to :
>>> https://patches.linaro.org/project/linux-acpi/patch/[email protected]/
>>
>> Hi Yunhui,
>>
>> From that discussion it was mentioned that that arm supports 3 methods
>> of booting:
>> direct + devicetree
>> EFI + devicetree
>> EFI + ACPI
>> ..but not
>> direct + ACPI
>>
>> To me it isn't obvious from that or this thread, and since arm seems
>> to be doing fine without the 4th option I'm curious why that's
>> necessary on riscv?
>
> If anything we should be removing option 1, because that’s not a
> cross-OS standard (though RISC-V’s SBI direct booting is at least not
> tied to the OS). Any application-class platform spec is going to
> mandate EFI, because, whatever your thoughts of EFI are, that is *the*
> standard. And if you’re willing to pick up all the complexity of ACPI,
> what’s a bit of EFI (especially if you only go for a minimal one a la
> U-Boot)?
Well said!
Yunhui, why not simply add a minimal UEFI stub to Coreboot (like Jess
points out above)?
IMO what U-boot (or
https://github.com/cloud-hypervisor/rust-hypervisor-firmware if you're
into Rust ;-)) is doing, and just having a small UEFI shim is the way to
go.
Hi Björn,
On Wed, Jul 5, 2023 at 10:43 PM Björn Töpel <[email protected]> wrote:
>
> Jessica Clarke <[email protected]> writes:
>
> > On 3 Jul 2023, at 19:58, Emil Renner Berthing <[email protected]> wrote:
> >>
> >> On Mon, 3 Jul 2023 at 15:33, 运辉崔 <[email protected]> wrote:
> >>>
> >>> Hi drew,
> >>>
> >>> On Mon, Jul 3, 2023 at 9:01 PM Andrew Jones <[email protected]> wrote:
> >>>>
> >>>>
> >>>> (This is a reply to a non-existent cover letter.)
> >>>
> >>> This has been discussed many times with Ard, Please refer to :
> >>> https://patches.linaro.org/project/linux-acpi/patch/[email protected]/
> >>
> >> Hi Yunhui,
> >>
> >> From that discussion it was mentioned that that arm supports 3 methods
> >> of booting:
> >> direct + devicetree
> >> EFI + devicetree
> >> EFI + ACPI
> >> ..but not
> >> direct + ACPI
> >>
> >> To me it isn't obvious from that or this thread, and since arm seems
> >> to be doing fine without the 4th option I'm curious why that's
> >> necessary on riscv?
> >
> > If anything we should be removing option 1, because that’s not a
> > cross-OS standard (though RISC-V’s SBI direct booting is at least not
> > tied to the OS). Any application-class platform spec is going to
> > mandate EFI, because, whatever your thoughts of EFI are, that is *the*
> > standard. And if you’re willing to pick up all the complexity of ACPI,
> > what’s a bit of EFI (especially if you only go for a minimal one a la
> > U-Boot)?
>
> Well said!
>
> Yunhui, why not simply add a minimal UEFI stub to Coreboot (like Jess
> points out above)?
In fact, in the v1 email, Coreboot's maintainer Ron has made it clear
that Coreboot does not support EFI, and it is necessary to transmit
firmware information through DTS on RISC-V.
@Ron, can you help explain it to them?
> IMO what U-boot (or
> https://github.com/cloud-hypervisor/rust-hypervisor-firmware if you're
> into Rust ;-)) is doing, and just having a small UEFI shim is the way to
> go.
Thanks,
Yunhui
运辉崔 <[email protected]> writes:
> Hi Björn,
>
> On Wed, Jul 5, 2023 at 10:43 PM Björn Töpel <[email protected]> wrote:
>>
>> Jessica Clarke <[email protected]> writes:
>>
>> > On 3 Jul 2023, at 19:58, Emil Renner Berthing <[email protected]> wrote:
>> >>
>> >> On Mon, 3 Jul 2023 at 15:33, 运辉崔 <[email protected]> wrote:
>> >>>
>> >>> Hi drew,
>> >>>
>> >>> On Mon, Jul 3, 2023 at 9:01 PM Andrew Jones <[email protected]> wrote:
>> >>>>
>> >>>>
>> >>>> (This is a reply to a non-existent cover letter.)
>> >>>
>> >>> This has been discussed many times with Ard, Please refer to :
>> >>> https://patches.linaro.org/project/linux-acpi/patch/[email protected]/
>> >>
>> >> Hi Yunhui,
>> >>
>> >> From that discussion it was mentioned that that arm supports 3 methods
>> >> of booting:
>> >> direct + devicetree
>> >> EFI + devicetree
>> >> EFI + ACPI
>> >> ..but not
>> >> direct + ACPI
>> >>
>> >> To me it isn't obvious from that or this thread, and since arm seems
>> >> to be doing fine without the 4th option I'm curious why that's
>> >> necessary on riscv?
>> >
>> > If anything we should be removing option 1, because that’s not a
>> > cross-OS standard (though RISC-V’s SBI direct booting is at least not
>> > tied to the OS). Any application-class platform spec is going to
>> > mandate EFI, because, whatever your thoughts of EFI are, that is *the*
>> > standard. And if you’re willing to pick up all the complexity of ACPI,
>> > what’s a bit of EFI (especially if you only go for a minimal one a la
>> > U-Boot)?
>>
>> Well said!
>>
>> Yunhui, why not simply add a minimal UEFI stub to Coreboot (like Jess
>> points out above)?
>
> In fact, in the v1 email, Coreboot's maintainer Ron has made it clear
> that Coreboot does not support EFI, and it is necessary to transmit
> firmware information through DTS on RISC-V.
It clear that Coreboot doesn't support UEFI today. We're "arguing" that
it's less work/verification adding the neccesary minimal UEFI plumbing
for Coreboot, than jumping through hoops in the kernel to work around
it.
I'm getting some UEFI FUD vibes here. I also think that parts of UEFI is
kind of ugly, but it's, as Jess says, *the* spec and honestly, a bit
what's expected (Hi CXL).
UEFI is a specification, and implementing the minimal requirements for
UEFI is not that of a big deal. Look at Alex Graf's (et al) work on
u-boot UEFI. U-boot is small/lean/open *and* manage to support enough
UEFI for ACPI.
The whole "Oh, UEFI is so bad, bloated, and closed" hand-wavery is a bit
tiring. :-(
...these last four sections is more of a beer discussion. I'll take my
"my FW is better than yours" rants elsewhere. ;-)
Björn