On integrating LoongArch EDK2 firmware into QEMU build process

On integrating LoongArch EDK2 firmware into QEMU build process

[WANG Xuerui]

Hi,

Recently there are reportedly increased general interest in trying out 
LoongArch on top of QEMU, among both end users and organizations; and 
the EDK2 firmware port is fully upstreamed since the stable202211 
version, and a build suitable for QEMU is already possible with 
Platform/Loongson/LoongArchQemuPkg in edk2-platforms. I think providing 
pre-built LoongArch firmware would make it much easier to dabble in 
system emulation, helping those users. (They currently have to pull a 
blob from yangxiaojuan/qemu-binary, and remember to pair certain version 
of QEMU with certain revision of the firmware blob. I'm also one of the 
users who can't remember which version to use, but I can always build my 
own; imagine the difficulty an end user would face!)

So I tried to add a LoongArch build to the list stored in roms/, but 
discovered that edk2-platforms seems not included, because all other 
platforms' EDK2 packages are directly under the main edk2 repo.

The question is: is integrating a platform package from edk2-platforms 
okay under the current build system, so we can arrange to provide 
edk2-platforms also as a submodule and go ahead? Or do we (the LoongArch 
firmware community) have to change the code organization to make 
necessary parts available in the main edk2 repo?

CC-ing target/loongarch maintainers from Loongson too as you may have 
more information.

Re: On integrating LoongArch EDK2 firmware into QEMU build process

[maobibo]

Xuerui,

Thanks for your mail, it is a good suggestion. Now we are planing to move LoongArch uefi bios from edk2-platform to edk2 repo, so that uefi bios supporting LoongArch can be auto compiled and uploaded to qemu repo. Only that process is somwhat slow since lacking of hands, however we are doing this.

Regards
Bibo, Mao

在 2023/3/30 22:06, WANG Xuerui 写道:
> Hi,
> 
> Recently there are reportedly increased general interest in trying out LoongArch on top of QEMU, among both end users and organizations; and the EDK2 firmware port is fully upstreamed since the stable202211 version, and a build suitable for QEMU is already possible with Platform/Loongson/LoongArchQemuPkg in edk2-platforms. I think providing pre-built LoongArch firmware would make it much easier to dabble in system emulation, helping those users. (They currently have to pull a blob from yangxiaojuan/qemu-binary, and remember to pair certain version of QEMU with certain revision of the firmware blob. I'm also one of the users who can't remember which version to use, but I can always build my own; imagine the difficulty an end user would face!)
> 
> So I tried to add a LoongArch build to the list stored in roms/, but discovered that edk2-platforms seems not included, because all other platforms' EDK2 packages are directly under the main edk2 repo.
> 
> The question is: is integrating a platform package from edk2-platforms okay under the current build system, so we can arrange to provide edk2-platforms also as a submodule and go ahead? Or do we (the LoongArch firmware community) have to change the code organization to make necessary parts available in the main edk2 repo?
> 
> CC-ing target/loongarch maintainers from Loongson too as you may have more information.

Re: On integrating LoongArch EDK2 firmware into QEMU build process

[Gerd Hoffmann]

On Fri, Mar 31, 2023 at 08:54:16AM +0800, maobibo wrote:
> Xuerui,
> 
> Thanks for your mail, it is a good suggestion. Now we are planing to
> move LoongArch uefi bios from edk2-platform to edk2 repo, so that uefi
> bios supporting LoongArch can be auto compiled and uploaded to qemu
> repo. Only that process is somwhat slow since lacking of hands,
> however we are doing this.

Good, so I think it makes sense for qemu to just wait for that to
happen.

Related question:  What are the requirements to build the firmware?
Fedora 38 ships cross compiler packages ...

  binutils-loongarch64-linux-gnu-2.39-3.fc38.x86_64
  gcc-loongarch64-linux-gnu-12.2.1-5.fc38.x86_64

... but when trying to use them to compile the loongarch firmware gcc
throws errors:

loongarch64-linux-gnu-gcc: error: unrecognized command-line option ‘-mno-explicit-relocs’

I suspect gcc-12 is just too old?

take care,
  Gerd

Re: On integrating LoongArch EDK2 firmware into QEMU build process

[gaosong]

在 2023/3/31 下午8:12, Gerd Hoffmann 写道:
> On Fri, Mar 31, 2023 at 08:54:16AM +0800, maobibo wrote:
>> Xuerui,
>>
>> Thanks for your mail, it is a good suggestion. Now we are planing to
>> move LoongArch uefi bios from edk2-platform to edk2 repo, so that uefi
>> bios supporting LoongArch can be auto compiled and uploaded to qemu
>> repo. Only that process is somwhat slow since lacking of hands,
>> however we are doing this.
> Good, so I think it makes sense for qemu to just wait for that to
> happen.
>
> Related question:  What are the requirements to build the firmware?
> Fedora 38 ships cross compiler packages ...
>
>    binutils-loongarch64-linux-gnu-2.39-3.fc38.x86_64
>    gcc-loongarch64-linux-gnu-12.2.1-5.fc38.x86_64
>
> ... but when trying to use them to compile the loongarch firmware gcc
> throws errors:
>
> loongarch64-linux-gnu-gcc: error: unrecognized command-line option ‘-mno-explicit-relocs’
>
> I suspect gcc-12 is just too old?
Yes.

[gaosong@kvm-dev1 BIOS]$ loongarch64-unknown-linux-gnu-gcc --version
loongarch64-unknown-linux-gnu-gcc (GCC) 13.0.0 20220906 (experimental)

See:
https://github.com/tianocore/edk2-platforms/tree/master/Platform/Loongson/LoongArchQemuPkg#readme
or
docs/system/loongarch/virt.rst

Thanks.
Song Gao

Re: On integrating LoongArch EDK2 firmware into QEMU build process

[maobibo]

On 2023/3/31 20:12, Gerd Hoffmann wrote:
> On Fri, Mar 31, 2023 at 08:54:16AM +0800, maobibo wrote:
>> Xuerui,
>>
>> Thanks for your mail, it is a good suggestion. Now we are planing to
>> move LoongArch uefi bios from edk2-platform to edk2 repo, so that uefi
>> bios supporting LoongArch can be auto compiled and uploaded to qemu
>> repo. Only that process is somwhat slow since lacking of hands,
>> however we are doing this.
> 
> Good, so I think it makes sense for qemu to just wait for that to
> happen.
> 
> Related question:  What are the requirements to build the firmware?
> Fedora 38 ships cross compiler packages ...
> 
>    binutils-loongarch64-linux-gnu-2.39-3.fc38.x86_64
>    gcc-loongarch64-linux-gnu-12.2.1-5.fc38.x86_64
> 
> ... but when trying to use them to compile the loongarch firmware gcc
> throws errors:
> 
> loongarch64-linux-gnu-gcc: error: unrecognized command-line option ‘-mno-explicit-relocs’
> 
> I suspect gcc-12 is just too old?
There is a little different about relocation between gcc-12 and gcc-13 
on LoongArch, gcc-13 is required for edk2 compiler now.

However I think it is actually is one issue if gcc-12 can not be used 
and gcc-12 is popular latest compiler for all architectures. We will 
solve this problem.

Regards
Bibo, Mao


> 
> take care,
>    Gerd
> 

Re: On integrating LoongArch EDK2 firmware into QEMU build process

[maobibo]

Cc to Chao Li who is maintainer of edk2 about LoongArch support.

Hi Chao, 

Fedora38 is used to build edk2 binary in qemu CI, cross gcc-12 is
integrated on Fedora38. There is one issue when gcc-12 is used to
build edk2 loongarch like this:
> ... but when trying to use them to compile the loongarch firmware gcc
> throws errors:
>
> loongarch64-linux-gnu-gcc: error: unrecognized command-line option ‘-mno-explicit-reloc

what is your option about this issue?

Regards
Bibo, Mao

在 2023/4/1 13:11, maobibo 写道:
> 
> 
> On 2023/3/31 20:12, Gerd Hoffmann wrote:
>> On Fri, Mar 31, 2023 at 08:54:16AM +0800, maobibo wrote:
>>> Xuerui,
>>>
>>> Thanks for your mail, it is a good suggestion. Now we are planing to
>>> move LoongArch uefi bios from edk2-platform to edk2 repo, so that uefi
>>> bios supporting LoongArch can be auto compiled and uploaded to qemu
>>> repo. Only that process is somwhat slow since lacking of hands,
>>> however we are doing this.
>>
>> Good, so I think it makes sense for qemu to just wait for that to
>> happen.
>>
>> Related question:  What are the requirements to build the firmware?
>> Fedora 38 ships cross compiler packages ...
>>
>>    binutils-loongarch64-linux-gnu-2.39-3.fc38.x86_64
>>    gcc-loongarch64-linux-gnu-12.2.1-5.fc38.x86_64
>>
>> ... but when trying to use them to compile the loongarch firmware gcc
>> throws errors:
>>
>> loongarch64-linux-gnu-gcc: error: unrecognized command-line option ‘-mno-explicit-relocs’
>>
>> I suspect gcc-12 is just too old?
> There is a little different about relocation between gcc-12 and gcc-13 on LoongArch, gcc-13 is required for edk2 compiler now.
> 
> However I think it is actually is one issue if gcc-12 can not be used and gcc-12 is popular latest compiler for all architectures. We will solve this problem.
> 
> Regards
> Bibo, Mao
> 
> 
>>
>> take care,
>>    Gerd
>>
> 

Re: [edk2-devel] On integrating LoongArch EDK2 firmware into QEMU build process

[Chao Li]

[-- Attachment #1: Type: text/plain, Size: 3499 bytes --]

Hi Bibo,

Thanks for Cc to me.


Hi Gerd,

This problem is because the gcc-12 does not yet to support the option 
'mno-explicit-reloc', this option is used to open the new reloaction 
type for LoongArch, this new feature is very important for LoongArch, 
because it can reduce the binary size and improve code execution 
efficiency, so we turn it on when submitting the code to the EDK2 repo.

gcc-13 will support this new feature, so we expect this issue to be 
resolved when using gcc-13, which may be released at this month.

If Fedora38 does not plan to use gcc-13 now, I suggest that CI can 
download a LoongArch cross gcc-13 when creating a docker image, just 
like EDK2 CI process. You can refer following link for more information: 
https://github.com/tianocore/containers/blob/main/Fedora-37/Dockerfile . 
EDK2 CI uses Fedora35 and Fedora37 docker images for LoongArch,  they 
will download a LoongArch cross gcc-13 when the CI targets is LoongArch.

We are really sorry about that, I think this solution will make more 
work for you, but I think it is the best way for now, and I believe it 
will be solved when Fedora uses gcc-13 in the future.


Thanks,
Chao
在 2023/4/3 16:51, maobibo 写道:
> Cc to Chao Li who is maintainer of edk2 about LoongArch support.
>
> Hi Chao,
>
> Fedora38 is used to build edk2 binary in qemu CI, cross gcc-12 is
> integrated on Fedora38. There is one issue when gcc-12 is used to
> build edk2 loongarch like this:
>> ... but when trying to use them to compile the loongarch firmware gcc
>> throws errors:
>>
>> loongarch64-linux-gnu-gcc: error: unrecognized command-line option ‘-mno-explicit-reloc
> what is your option about this issue?
>
> Regards
> Bibo, Mao
>
> 在 2023/4/1 13:11, maobibo 写道:
>>
>> On 2023/3/31 20:12, Gerd Hoffmann wrote:
>>> On Fri, Mar 31, 2023 at 08:54:16AM +0800, maobibo wrote:
>>>> Xuerui,
>>>>
>>>> Thanks for your mail, it is a good suggestion. Now we are planing to
>>>> move LoongArch uefi bios from edk2-platform to edk2 repo, so that uefi
>>>> bios supporting LoongArch can be auto compiled and uploaded to qemu
>>>> repo. Only that process is somwhat slow since lacking of hands,
>>>> however we are doing this.
>>> Good, so I think it makes sense for qemu to just wait for that to
>>> happen.
>>>
>>> Related question:  What are the requirements to build the firmware?
>>> Fedora 38 ships cross compiler packages ...
>>>
>>>     binutils-loongarch64-linux-gnu-2.39-3.fc38.x86_64
>>>     gcc-loongarch64-linux-gnu-12.2.1-5.fc38.x86_64
>>>
>>> ... but when trying to use them to compile the loongarch firmware gcc
>>> throws errors:
>>>
>>> loongarch64-linux-gnu-gcc: error: unrecognized command-line option ‘-mno-explicit-relocs’
>>>
>>> I suspect gcc-12 is just too old?
>> There is a little different about relocation between gcc-12 and gcc-13 on LoongArch, gcc-13 is required for edk2 compiler now.
>>
>> However I think it is actually is one issue if gcc-12 can not be used and gcc-12 is popular latest compiler for all architectures. We will solve this problem.
>>
>> Regards
>> Bibo, Mao
>>
>>
>>> take care,
>>>     Gerd
>>>
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Groups.io Links: You receive all messages sent to this group.
> View/Reply Online (#102377):https://edk2.groups.io/g/devel/message/102377
> Mute This Topic:https://groups.io/mt/98030924/6496846
> Group Owner:devel+owner@edk2.groups.io
> Unsubscribe:https://edk2.groups.io/g/devel/unsub  [lichao@loongson.cn]
> -=-=-=-=-=-=-=-=-=-=-=-
>

[-- Attachment #2: Type: text/html, Size: 5624 bytes --]

Re: [edk2-devel] On integrating LoongArch EDK2 firmware into QEMU build process

[Michael Brown]

On 03/04/2023 11:13, Chao Li wrote:
> This problem is because the gcc-12 does not yet to support the option 
> 'mno-explicit-reloc', this option is used to open the new reloaction 
> type for LoongArch, this new feature is very important for LoongArch, 
> because it can reduce the binary size and improve code execution 
> efficiency, so we turn it on when submitting the code to the EDK2 repo.

Is it possible to produce a _functional_ LoongArch64 EDK2 binary without 
this option, even if the resulting binary is less efficient?

(I'm the person who updated Fedora's binutils and cross-gcc packages to 
ensure that LoongArch64 was supported in Fedora 38, and this 
-mno-explicit-relocs issue is also currently blocking me from merging 
LoongArch64 support into iPXE.)

Thanks,

Michael

Re: [edk2-devel] On integrating LoongArch EDK2 firmware into QEMU build process

[Gerd Hoffmann]

On Mon, Apr 03, 2023 at 06:13:41PM +0800, Chao Li wrote:
> Hi Bibo,
> 
> gcc-13 will support this new feature, so we expect this issue to be resolved
> when using gcc-13, which may be released at this month.
> 
> If Fedora38 does not plan to use gcc-13 now, I suggest that CI can download
> a LoongArch cross gcc-13 when creating a docker image, just like EDK2 CI
> process. You can refer following link for more information:

The non-cross gcc already is at 13.  Fedora builds the distro with
pre-release gcc so gcc gets some serious real-world testing before
release.

The cross compilers lagging behind a bit, not sure whenever there is
some actual problem or whenever maintainers are just waiting for the
final gcc-13 release.

> https://github.com/tianocore/containers/blob/main/Fedora-37/Dockerfile .
> EDK2 CI uses Fedora35 and Fedora37 docker images for LoongArch,  they will
> download a LoongArch cross gcc-13 when the CI targets is LoongArch.

While that works as temporary stopgap for edk2 CI it is a non-starter
for fedora distro builds.  Any builds must be done using compilers
shipped by fedora.  So, fedora shipping edk2-loongarch (or
ipxe-loongarch) packages is blocked by this.

> We are really sorry about that, I think this solution will make more work
> for you, but I think it is the best way for now, and I believe it will be
> solved when Fedora uses gcc-13 in the future.

I'll go just wait for gcc-13 cross compilers land in fedora then.

take care,
  Gerd

Re: [edk2-devel] On integrating LoongArch EDK2 firmware into QEMU build process

[Gerd Hoffmann]

On Mon, Apr 03, 2023 at 10:29:52AM +0000, Michael Brown wrote:
> On 03/04/2023 11:13, Chao Li wrote:
> > This problem is because the gcc-12 does not yet to support the option
> > 'mno-explicit-reloc', this option is used to open the new reloaction
> > type for LoongArch, this new feature is very important for LoongArch,
> > because it can reduce the binary size and improve code execution
> > efficiency, so we turn it on when submitting the code to the EDK2 repo.
> 
> Is it possible to produce a _functional_ LoongArch64 EDK2 binary without
> this option, even if the resulting binary is less efficient?

MdePkg/Include/IndustryStandard/PeImage.h lists a single loongarch
relocation type only, which I expect being the new type.  So I suspect
the answer is "no" because the edk2 pe loader isn't able to handle the
old relocation type(s).

take care,
  Gerd

Re: [edk2-devel] On integrating LoongArch EDK2 firmware into QEMU build process

[Chao Li]

[-- Attachment #1: Type: text/plain, Size: 2898 bytes --]

在 2023/4/3 19:04, Gerd Hoffmann 写道:

> On Mon, Apr 03, 2023 at 10:29:52AM +0000, Michael Brown wrote:
>> On 03/04/2023 11:13, Chao Li wrote:
>>> This problem is because the gcc-12 does not yet to support the option
>>> 'mno-explicit-reloc', this option is used to open the new reloaction
>>> type for LoongArch, this new feature is very important for LoongArch,
>>> because it can reduce the binary size and improve code execution
>>> efficiency, so we turn it on when submitting the code to the EDK2 repo.
>> Is it possible to produce a _functional_ LoongArch64 EDK2 binary without
>> this option, even if the resulting binary is less efficient?
> MdePkg/Include/IndustryStandard/PeImage.h lists a single loongarch
> relocation type only, which I expect being the new type.  So I suspect
> the answer is "no" because the edk2 pe loader isn't able to handle the
> old relocation type(s).

Yes, the answer is "no", but the opposite is ture, the 
MdePkg/Include/IndustryStandard/PeImage.h LoongArch relocation type is 
older, this type appears in this list for compatiblility with binaries 
using the old reloaction type. If you use this type, you have to turn on 
the option '-mla-global-with-abs' in gcc,all global symbols will be 
created as "mark la" type, PE loader will use this rule to handle them. 
This option is mutually exclusive with 'mno-explicit-reloc',  new 
reloaction type(s) doesn't require special type(s) to be expressed in 
PeImage.h, PE loader doesn't need to do anything about relocation, all 
of reloaction process is done in BaseTools/Source/C/GenFw/Elf64Convert.c.


Thanks,
Chao
在 2023/4/3 19:04, Gerd Hoffmann 写道:
> On Mon, Apr 03, 2023 at 10:29:52AM +0000, Michael Brown wrote:
>> On 03/04/2023 11:13, Chao Li wrote:
>>> This problem is because the gcc-12 does not yet to support the option
>>> 'mno-explicit-reloc', this option is used to open the new reloaction
>>> type for LoongArch, this new feature is very important for LoongArch,
>>> because it can reduce the binary size and improve code execution
>>> efficiency, so we turn it on when submitting the code to the EDK2 repo.
>> Is it possible to produce a _functional_ LoongArch64 EDK2 binary without
>> this option, even if the resulting binary is less efficient?
> MdePkg/Include/IndustryStandard/PeImage.h lists a single loongarch
> relocation type only, which I expect being the new type.  So I suspect
> the answer is "no" because the edk2 pe loader isn't able to handle the
> old relocation type(s).
>
> take care,
>    Gerd
>
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Groups.io Links: You receive all messages sent to this group.
> View/Reply Online (#102384):https://edk2.groups.io/g/devel/message/102384
> Mute This Topic:https://groups.io/mt/98030924/6496846
> Group Owner:devel+owner@edk2.groups.io
> Unsubscribe:https://edk2.groups.io/g/devel/unsub  [lichao@loongson.cn]
> -=-=-=-=-=-=-=-=-=-=-=-
>

[-- Attachment #2: Type: text/html, Size: 4803 bytes --]

Re: On integrating LoongArch EDK2 firmware into QEMU build process

[WANG Xuerui]

On 3/31/23 08:54, maobibo wrote:
> Xuerui,
> 
> Thanks for your mail, it is a good suggestion. Now we are planing to move LoongArch uefi bios from edk2-platform to edk2 repo, so that uefi bios supporting LoongArch can be auto compiled and uploaded to qemu repo. Only that process is somwhat slow since lacking of hands, however we are doing this.

Pinging: a few months have passed, and it seems this work is stalled? 
Given the LoongArch Linux KVM support is about to land in v6.7, it may 
be time to prepare the firmware and QEMU side of things, so users would 
no longer have to manually acquire the firmware blobs whenever they fire 
up their VMs.

> 
> Regards
> Bibo, Mao
> 
> 在 2023/3/30 22:06, WANG Xuerui 写道:
>> Hi,
>>
>> Recently there are reportedly increased general interest in trying out LoongArch on top of QEMU, among both end users and organizations; and the EDK2 firmware port is fully upstreamed since the stable202211 version, and a build suitable for QEMU is already possible with Platform/Loongson/LoongArchQemuPkg in edk2-platforms. I think providing pre-built LoongArch firmware would make it much easier to dabble in system emulation, helping those users. (They currently have to pull a blob from yangxiaojuan/qemu-binary, and remember to pair certain version of QEMU with certain revision of the firmware blob. I'm also one of the users who can't remember which version to use, but I can always build my own; imagine the difficulty an end user would face!)
>>
>> So I tried to add a LoongArch build to the list stored in roms/, but discovered that edk2-platforms seems not included, because all other platforms' EDK2 packages are directly under the main edk2 repo.
>>
>> The question is: is integrating a platform package from edk2-platforms okay under the current build system, so we can arrange to provide edk2-platforms also as a submodule and go ahead? Or do we (the LoongArch firmware community) have to change the code organization to make necessary parts available in the main edk2 repo?
>>
>> CC-ing target/loongarch maintainers from Loongson too as you may have more information.
> 

Re: On integrating LoongArch EDK2 firmware into QEMU build process

[Chao Li]

[-- Attachment #1: Type: text/plain, Size: 2665 bytes --]

Hi Xuerui,

     Sorry for late reply. In fact the EDK2 repo is ready for submit, in 
a few days I will commit the patch set in kilaterlee/edk2 repo and 
execute the EDK2 CI testing. I will notify some people to review them, 
you are also welcome to review the patch set. And then, I'll submit the 
formal version patch to the EDK2 devel community.


Thanks,
Chao
在 2023/10/1 04:16, WANG Xuerui 写道:
> On 3/31/23 08:54, maobibo wrote:
>> Xuerui,
>>
>> Thanks for your mail, it is a good suggestion. Now we are planing to 
>> move LoongArch uefi bios from edk2-platform to edk2 repo, so that 
>> uefi bios supporting LoongArch can be auto compiled and uploaded to 
>> qemu repo. Only that process is somwhat slow since lacking of hands, 
>> however we are doing this.
>
> Pinging: a few months have passed, and it seems this work is stalled? 
> Given the LoongArch Linux KVM support is about to land in v6.7, it may 
> be time to prepare the firmware and QEMU side of things, so users 
> would no longer have to manually acquire the firmware blobs whenever 
> they fire up their VMs.
>
>>
>> Regards
>> Bibo, Mao
>>
>> 在 2023/3/30 22:06, WANG Xuerui 写道:
>>> Hi,
>>>
>>> Recently there are reportedly increased general interest in trying 
>>> out LoongArch on top of QEMU, among both end users and 
>>> organizations; and the EDK2 firmware port is fully upstreamed since 
>>> the stable202211 version, and a build suitable for QEMU is already 
>>> possible with Platform/Loongson/LoongArchQemuPkg in edk2-platforms. 
>>> I think providing pre-built LoongArch firmware would make it much 
>>> easier to dabble in system emulation, helping those users. (They 
>>> currently have to pull a blob from yangxiaojuan/qemu-binary, and 
>>> remember to pair certain version of QEMU with certain revision of 
>>> the firmware blob. I'm also one of the users who can't remember 
>>> which version to use, but I can always build my own; imagine the 
>>> difficulty an end user would face!)
>>>
>>> So I tried to add a LoongArch build to the list stored in roms/, but 
>>> discovered that edk2-platforms seems not included, because all other 
>>> platforms' EDK2 packages are directly under the main edk2 repo.
>>>
>>> The question is: is integrating a platform package from 
>>> edk2-platforms okay under the current build system, so we can 
>>> arrange to provide edk2-platforms also as a submodule and go ahead? 
>>> Or do we (the LoongArch firmware community) have to change the code 
>>> organization to make necessary parts available in the main edk2 repo?
>>>
>>> CC-ing target/loongarch maintainers from Loongson too as you may 
>>> have more information.
>>

[-- Attachment #2: Type: text/html, Size: 3945 bytes --]