2023-07-07 16:22:54

by Conor Dooley

[permalink] [raw]
Subject: Re: [External] Re: [PATCH v3 0/4] Obtain SMBIOS and ACPI entry from FFI

Hey,

On Fri, Jul 07, 2023 at 11:56:48PM +0800, 葛士建 wrote:
> On Fri, Jul 7, 2023 at 8:55 PM Sunil V L <[email protected]> wrote:
>
> > On Fri, Jul 07, 2023 at 08:05:48PM +0800, 葛士建 wrote:
> > > Hi Sunil,
> > >
> > > From Sunil:
> > > IMO, if the question is generic like "Is UEFI mandatory for RISC-V?",
> > > the answer will be solid "no" because we can use DT without UEFI. But if
> > > you ask whether UEFI is mandatory for ACPI support on RISC-V, then the
> > > answer will be "yes".
> > > ---- Why UEFI is mandatory for ACPI support on RISC-V? As we know, on X86,
> > > ACPI works well without UEFI. Is there any limitation on RISC-V
> > > architecture?
> > Yes, the limitation is RISC-V can not use IA-PC BIOS. Please see
> > section 5.2.5 and 15 in ACPI spec.
> >
> > I don't have much to add to Ard's reasons.
> >
> > https://lore.kernel.org/linux-riscv/CAMj1kXFZren0Q19DimwQaETCLz64D4bZQC5B2N=i3SAWHygkTQ@mail.gmail.com/
> >

> I don't think that's the limitation on RISC-V. BTW, how does OSPM find the
> RSDP on ARM systems? Does it meet 5.2.5?
>
> Here are
> 1. Purpose: purpose is to provide another option on Firmware Solution; Our
> purpose is NOT to ban UEFI.
> 2. Both ARM and RISC-V starts from UBOOT solution, and that's close to
> coreboot, so we would like to enable flexible and rich ecosystem.
> 3. We don't like to push coreboot and UEFI together, so we don't plan to
> enable UEFI in coreboot(maybe from Uboot); because that makes the solution
> complex.
> 4. I think we should fix the request and problem, banning or protecting
> something is NOT the goal of us.
>
> I think the solution is for both RISC-V and ARM, and also it works on X86
> if it's done.
> Let me know what the problem and impact is, please.

If you are going to keep arguing this, please stop sending top-posted
HTML to the mailing list. It makes it impossible for those not in the CC
list to follow along.

Thanks,
Conor.


Attachments:
(No filename) (1.94 kB)
signature.asc (235.00 B)
Download all attachments

2023-07-07 16:48:25

by 葛士建

[permalink] [raw]
Subject: Re: [External] Re: [PATCH v3 0/4] Obtain SMBIOS and ACPI entry from FFI

On Sat, Jul 8, 2023 at 12:07 AM Conor Dooley <[email protected]> wrote:
>
> Hey,
>
> On Fri, Jul 07, 2023 at 11:56:48PM +0800, 葛士建 wrote:
> > On Fri, Jul 7, 2023 at 8:55 PM Sunil V L <[email protected]> wrote:
> >
> > > On Fri, Jul 07, 2023 at 08:05:48PM +0800, 葛士建 wrote:
> > > > Hi Sunil,
> > > >
> > > > From Sunil:
> > > > IMO, if the question is generic like "Is UEFI mandatory for RISC-V?",
> > > > the answer will be solid "no" because we can use DT without UEFI. But if
> > > > you ask whether UEFI is mandatory for ACPI support on RISC-V, then the
> > > > answer will be "yes".
> > > > ---- Why UEFI is mandatory for ACPI support on RISC-V? As we know, on X86,
> > > > ACPI works well without UEFI. Is there any limitation on RISC-V
> > > > architecture?
> > > Yes, the limitation is RISC-V can not use IA-PC BIOS. Please see
> > > section 5.2.5 and 15 in ACPI spec.
> > >
> > > I don't have much to add to Ard's reasons.
> > >
> > > https://lore.kernel.org/linux-riscv/CAMj1kXFZren0Q19DimwQaETCLz64D4bZQC5B2N=i3SAWHygkTQ@mail.gmail.com/
> > >
>
> > I don't think that's the limitation on RISC-V. BTW, how does OSPM find the
> > RSDP on ARM systems? Does it meet 5.2.5?
> >
> > Here are
> > 1. Purpose: purpose is to provide another option on Firmware Solution; Our
> > purpose is NOT to ban UEFI.
> > 2. Both ARM and RISC-V starts from UBOOT solution, and that's close to
> > coreboot, so we would like to enable flexible and rich ecosystem.
> > 3. We don't like to push coreboot and UEFI together, so we don't plan to
> > enable UEFI in coreboot(maybe from Uboot); because that makes the solution
> > complex.
> > 4. I think we should fix the request and problem, banning or protecting
> > something is NOT the goal of us.
> >
> > I think the solution is for both RISC-V and ARM, and also it works on X86
> > if it's done.
> > Let me know what the problem and impact is, please.
>
> If you are going to keep arguing this, please stop sending top-posted
> HTML to the mailing list. It makes it impossible for those not in the CC
> list to follow along.

Thanks Conor, I will follow the rules.

>
>
> Thanks,
> Conor.