在2024年6月7日六月 下午7:11，Heinrich Schuchardt写道：
[...]
>
> This does not explain why we should bother about any non-UEFI
> architecture. It does not list relevant architectures and does not
> provide any evidence that this more than an academic endeavor.
Hi Heinrich,
As per discussion made at [1] it can be next generation of U-Boot's
API facing to bare-metal software.
I admit it's more or less an academic endeavour to me, but isn't
U-Boot a great place for such thing? Do we have to be bound by
commercial interest?
>
> All git repositories you mentioned in you MIPS series have not seen any
> update in the last four years.
Everything is working well, so nobody is willing to touch them.
>
> If any company were sincerely interested in using UEFI on such
> architectures, wouldn't they contribute to the specification like has
> been done for LoongArch and RISC-V?
Some architectures are dead in commercial point of view (m68k, xtensa)
etc, so I think nobody is going to represent them in commercial world.
Loongson tried to push UEFI spec for MIPS to UEFI forum a couple of years
ago but was trapped by a good deal of commercial stuff. Now they
lost interest on it.
>
> It does not make sense to define UEFI for non-UEFI architectures in
> U-Boot. Isn't there any existing documentation for UEFI on MIPS?
Yes, from Loongson, in Chinese.
But I'd like to make a cross-arch document to help with other ports.
>
>> +
>> +Architectural Conventions
>> +-------------------------
>> +
>> +The UEFI specifications cover IA32, X64, ARM, AARCH64, RISC-V, LoongArch,
>> and
>
> There is only one UEFI specification.
>
> %s/specifications cover/specification covers/
>
>> +Itanium architectures. This document extends the UEFI specifications to
>> include
>> +all architectures supported by U-Boot.
>> +
>> +The following conventions are used for these architectures:
>> +
>> +- For architectures with multiple ABIs, we adhere to the calling conventions
>> + used by the Linux kernel for the same architecture.
>> +
>> +- Optional CPU registers (floating-point, SIMD) are excluded from calling
>> + conventions. However, the UEFI payload should be able to utilize them if
>> + available.
>> +
>> +- Control is handed over to the UEFI payload at the privilege level used
>> + by the Linux kernel for the same architecture.
>
> This does not provide enough detail. The Linux kernel can run at
> different privilege levels on the same architecture, e.g. in S-mode or
> M-mode on RISC-V.
I think it's only the case of RISC-V and AArch64 to have multiple privilege
levels. MIPS, m68k, xtensa, power, nios2 all have only one level for kernel.
But I'm happy to add some architecture specific wording here.
>
>> +
>> +- Identity mapping (i.e., VA == PA mapping) is preferred for UEFI. However,
>> + this may not be possible for some architectures. In such cases, if the
>> + processor supports a default linear translation, it should be used.
>> +
>> +- Endianness: UEFI specifications enforce little-endian architectures.
>> + However, U-Boot supports both little-endian and big-endian architectures.
>> + For big-endian architectures, UEFI data structures should be stored in
>> + native endianness, with exceptions explicitly specified.
>
> Why do you bother about big-endian systems? MIPS supports low-endian.
> Linux distros like Debian have dropped big-endian MIPS support.
>
> If found https://www.ventoy.net/en/doc_mips64el.html (MIPS64EL UEFI) but
> nothing describing big-endian usage of UEFI.
Yes there is no such usage so far, but Big Endian is still widely used
in network devices (cavium octeon, even aarch64_be from ZXIC etc) and I don't
want
to left it over.
>
>> +
>> +UEFI Images
>> +-----------
>> +
>> +The UEFI specifications define the PE/COFF image format for UEFI
>> applications.
>> +U-Boot extends this format as follows:
>
> The UEFI specification does not define the PE/COFF image format. It
> prescribes its usage.
>
>> +
>> +- **PE32+ Machine Type**: UEFI specifications define machine types for
>> supported
>> + architectures. For machines not covered by UEFI specifications, we use the
>> + machine type defined by the Microsoft PE/COFF specification if possible.
>> + Otherwise, we use the ``IMAGE_FILE_MACHINE_UNKNOWN`` (0) machine type.
>> + U-Boot should always accept ``IMAGE_FILE_MACHINE_UNKNOWN`` as a valid
>> + machine type.
>
> We should not accept IMAGE_FILE_MACHINE_UNKNOWN on an architecture that
> has a machine type defined in the PE-COFF specification.
>
> Which MIPS machine type are you missing?
Not for MIPS, but we don't have onr for m68k and xtensa.
>
>> +
>> +- **Header Endianness**: PE/COFF header data fields are always stored as
>> + little-endian, regardless of the target architecture's endianness.
>> +
>> +- **DOS Stub**: To accommodate various boot image formats, we relax the
>> requirement
>> + for a DOS stub in the UEFI image. U-Boot should accept UEFI images
>> without a DOS
>> + stub and MZ signature. However, U-Boot still expects the PE/COFF header
>> at the
>> + file offset specified at offset 0x3C.
>
> Why would anybody create such an invalid file and expect it to be
> interpreted as EFI?
There is no such usage so far, but I noticed that for m68k "MZ" is not a valid
stub opcode, it might be a problem for EFISTUB kernel. Thus I came up with this
idea.
But it can be worked out if we define another booting header format for m68k.
What's your opinion?
>
> Shouldn't you fix the software creating such invalid files?
>
> This topic is related to the question of which specification has been
> used to create UEFI implementations like
> https://github.com/kontais/EFI-MIPS.
>
>> +
>> +I/O Device Access
>> +-----------------
>> +
>> +UEFI specifications define the EFI_DEVICE_IO_PROTOCOL and
>> EFI_PCI_IO_PROTOCOL
>> +for accessing I/O devices. U-Boot extends these specifications as follows:
>
> These protocols are not used in U-Boot, yet.
Yes, I had a glance on the specification and noticed that issue, so I
write it here in case we are going to support them in future.
>
> Best regards
>
> Heinrich
>
>> +
>> +- All I/O access is performed using the CPU's native endianness.
>> + For big-endian architectures, U-Boot should convert data to/from
>> little-endian
>> + before/after accessing I/O devices.
>>
>> ---
>> base-commit: 46ff00bea5dd2dd247d5e2fdadbf5dcf8653cd9a
>> change-id: 20240529-efi-spec-0ea657985272
>>
>> Best regards,
[1]:
https://lore.kernel.org/u-boot/cac_iwjlby6+fauyqw2zv5y5bycnxrhxfzvrff1dmyjx+anp...@mail.gmail.com/
Thanks
--
- Jiaxun
