From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail05.groups.io (mail05.groups.io [45.79.224.7]) by spool.mail.gandi.net (Postfix) with ESMTPS id 39193940CFE for ; Tue, 7 May 2024 02:25:22 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=iCFgEQIaQePoFn52rjab8iUBD8lv4Q9SZjIaHRpRDYQ=; c=relaxed/simple; d=groups.io; h=Message-ID:Date:MIME-Version:User-Agent:Subject:To:Cc:References:From:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Resent-Date:Resent-From:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type; s=20240206; t=1715048720; v=1; b=3FDWIL7NGBzWWPdx9Q5xUq6jvjp71zJiYbLnl7urhBZUZXWYaeqqgd1V054NjRPiFfs4E3D0 xOO/icpxxnF7HfVn3SfCzU5BT5Rs+o7RuLVXN/sqJ5QOlrVkogisNpKYWXRJR2gX5J/n7qzCKxq 1SLufqVEAoEnE0hLoXPCy65eqAAii8TnaPOlWroD+eC5r9m2uTnR/a+Qp0GNZ8HvlbzWKj9mU6s 1AsL8ZJNQ+ngrXveXcSGL/Gouh3b8RztonPH0YA89FIsSVGqfC0Ndr7xTyeYFSAdlDHe7yVlpc1 3yYbKtmN8ITzjb59ApdKgig+uFh9tbB+DV8rpPNOb6RZg== X-Received: by 127.0.0.2 with SMTP id zQhkYY7687511x7XYVkiceA1; Mon, 06 May 2024 19:25:20 -0700 X-Received: from mail.loongson.cn (mail.loongson.cn [114.242.206.163]) by mx.groups.io with SMTP id smtpd.web11.2375.1715048718672565432 for ; Mon, 06 May 2024 19:25:19 -0700 X-Received: from loongson.cn (unknown [10.40.24.149]) by gateway (Coremail) with SMTP id _____8DxfesIkTlm0qUIAA--.19483S3; Tue, 07 May 2024 10:25:12 +0800 (CST) X-Received: from [10.40.24.149] (unknown [10.40.24.149]) by localhost.localdomain (Coremail) with SMTP id AQAAf8BxkFUEkTlm9HoTAA--.21836S3; Tue, 07 May 2024 10:25:09 +0800 (CST) Message-ID: <949970a2-f9fa-45aa-ad78-8860b8176a11@loongson.cn> Date: Tue, 7 May 2024 10:25:08 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [edk2-devel] [PATCH v1 20/26] OvmfPkg/LoongArchVirt: Add NorFlashQemuLib To: devel@edk2.groups.io, ardb@kernel.org Cc: Gerd Hoffmann , lixianglai , Ard Biesheuvel , Jiewen Yao , Jordan Justen , Bibo Mao , Dongyan Qian References: <20240311093631.1251466-1-lichao@loongson.cn> <20240311093919.1254515-1-lichao@loongson.cn> <7nqe7k3oi3cph7mhqc4t5ea7qair3u2i7dy6oli6wurovyaoqa@apkw6d7gneam> <51c896fa-60bb-127f-c346-dc69179d288f@loongson.cn> From: "Chao Li" In-Reply-To: X-CM-TRANSID: AQAAf8BxkFUEkTlm9HoTAA--.21836S3 X-CM-SenderInfo: xolfxt3r6o00pqjv00gofq/1tbiAQAKCGY4RRQJAwABsH X-Coremail-Antispam: 1Uk129KBjDUn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7KY7 ZEXasCq-sGcSsGvfJ3UbIjqfuFe4nvWSU5nxnvy29KBjDU0xBIdaVrnUUvcSsGvfC2Kfnx nUUI43ZEXa7xR_UUUUUUUUU== Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Resent-Date: Mon, 06 May 2024 19:25:19 -0700 Resent-From: lichao@loongson.cn Reply-To: devel@edk2.groups.io,lichao@loongson.cn List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: TNz2ME3uRysUFg53itap80dcx7686176AA= Content-Type: multipart/alternative; boundary="------------XA0Itwm6L8a0beedzq0jlLYe" X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20240206 header.b=3FDWIL7N; dmarc=none; spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 45.79.224.7 as permitted sender) smtp.mailfrom=bounce@groups.io --------------XA0Itwm6L8a0beedzq0jlLYe Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Ard, Thanks, Chao On 2024/5/6 18:24, Ard Biesheuvel wrote: > On Mon, 6 May 2024 at 12:02, Chao Li wrote: >> Hi Gerd, >> >> >> Thanks, >> Chao >> On 2024/3/19 16:03, Gerd Hoffmann wrote: >> >> Hi, >> >> I can't tell the implementation scheme of the current lib and existing >> lib implementation scheme which one is better, Could you give we some >> advice? >> >> I'd suggest to merge your code as OvmfPkg/Library/FdtNorFlashQemuLib as >> it is not really loongarch-specific. >> >> If you want try switch aarch64 to use the same code that'll be great, >> but sorting that out later is also fine with me. >> >> If you think this design is looks better, then I'm prepare to commit thi= s >> change under the OvmfPkg/Library as a public library. And I will enable = it >> in aarch64 after merging this change, because I think it may be tweaked = and >> validated in aarch64 for many platforms. Do you think that is good? >> >> The VirtNorFlashDxe is optimized for qemu-emulated pflash. It tries to >> avoid switching between read and write mode much, because that operation >> has a significant overhead in virtualization. So it's really only used >> by ArmVirtPkg and not lots of other arm platforms. >> >> I'm moving the ARM version of the library to OvmfPkg and adding the set = PCD method, I have verified successfully on ArmVirtQemu.dsc(both -bios and = pflash), but I found that the ArmVirtQemuKernel.dsc also depends this libra= ry, so what's the difference between the two platforms? >> >> When I try to verify on ArmVirtQemuKernel.dsc that it works based on -bi= os option, I use the command line "qemu-system-aarch64 -M virt -cpu cortex= -a57 -bios LA_Virt_FW/AARCH64/QEMU_EFI.fd -net none -serial stdio -hdb /hom= e/lichao/Software/Qemu/SctPkg/share.imag -device ramfb -device nec-usb-xhci= -device usb-mouse -device usb-kbd", and it tells me "Could not open option= rom 'vgabios-ramfb.bin': No such file or directory", I tried removing the = option "-device ramfb", it looks like can't work. >> >> How does ArmVirtQemuKernel.dsc work? >> > It uses the -kernel QEMU command line argument, not the -bios one. > > This uses the Linux/arm64 kernel boot protocol (and runs the firmware > entirely from RAM) rather than booting from NOR flash. Alright, I got it. Does this mean that after this change, I just verify that the -kernel=20 command line can boot the OS and that it can load/store some variables=20 via the Linux OS? If so, I have some plans: 1. Port the ARM version to OvmfPkg and add the setting PCD method. *Done*. 2. Enable the new library on ArmVirtQemu.dsc and remove the hardcode in=20 INC file, verify this platform. *Done*. 3. Enable the new library on ArmVirtQemuKernel.dsc and verify this=20 platform. *Just verfiy booting OS and load/store some variables via=20 Linux kernel. In progress.* 4. Remove the ARM NorFlashQemuLib. *Pending.* Is the plans mentioned above possible? > > >=20 > -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#118625): https://edk2.groups.io/g/devel/message/118625 Mute This Topic: https://groups.io/mt/104859896/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- --------------XA0Itwm6L8a0beedzq0jlLYe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Ard,


=
Thanks,
Chao
On 2024/5/6 18:24, Ard Biesheuvel wrote:
On Mon, 6 May 2024 at 12:02, C=
hao Li <lichao@loongson.cn> wrote:

Hi Gerd,


Thanks,
Chao
On 2024/3/19 16:03, Gerd Hoffmann wrote:

  Hi,

I can't tell the implementation scheme of the current lib and existing
lib implementation scheme which one is better, Could you give we some
advice?

I'd suggest to merge your code as OvmfPkg/Library/FdtNorFlashQemuLib as
it is not really loongarch-specific.

If you want try switch aarch64 to use the same code that'll be great,
but sorting that out later is also fine with me.

If you think this design is looks better, then I'm prepare to commit this
change under the OvmfPkg/Library as a public library. And I will enable it
in aarch64 after merging this change, because I think it may be tweaked and
validated in aarch64 for many platforms. Do you think that is good?

The VirtNorFlashDxe is optimized for qemu-emulated pflash.  It tries to
avoid switching between read and write mode much, because that operation
has a significant overhead in virtualization.  So it's really only used
by ArmVirtPkg and not lots of other arm platforms.

I'm moving the ARM version of the library to OvmfPkg and adding the set PCD=
 method, I have verified successfully on ArmVirtQemu.dsc(both -bios and pfl=
ash), but I found that the ArmVirtQemuKernel.dsc also depends this library,=
 so what's the difference between the two platforms?

When I try to verify on ArmVirtQemuKernel.dsc that it works based on -bios =
option,  I use the command line "qemu-system-aarch64 -M virt -cpu cortex-a5=
7 -bios LA_Virt_FW/AARCH64/QEMU_EFI.fd -net none -serial stdio -hdb /home/l=
ichao/Software/Qemu/SctPkg/share.imag -device ramfb -device nec-usb-xhci -d=
evice usb-mouse -device usb-kbd", and it tells me "Could not open option ro=
m 'vgabios-ramfb.bin': No such file or directory", I tried removing the opt=
ion "-device ramfb", it looks like can't work.

How does ArmVirtQemuKernel.dsc work?


It uses the -kernel QEMU command line argument, not the -bios one.

This uses the Linux/arm64 kernel boot protocol (and runs the firmware
entirely from RAM) rather than booting from NOR flash.

Alright, I got it.

Does this mean that after this change, I just verify that the -kernel command line can boot the OS and that it can load/store some variables via the Linux OS?

If so, I have some plans:

1. Port the ARM version to OvmfPkg and add the setting PCD method. Done.

2. Enable the new library on ArmVirtQemu.dsc and remove the hardcode in INC file, verify this platform. Done.

3. Enable the new library on ArmVirtQemuKernel.dsc and verify this platform. Just verfiy booting OS and load/store some variables via Linux kernel. In progress.

4. Remove the ARM NorFlashQemuLib. Pending.

Is the plans mentioned above possible?
_._,_._,_
Groups.io Links:

=20 You receive all messages sent to this group. =20 =20

View/Reply Online (#118625) | =20 | Mute= This Topic | New Topic
Your Subscriptio= n | Contact Group Owner | Unsubscribe [rebecca@openfw.io]

_._,_._,_
--------------XA0Itwm6L8a0beedzq0jlLYe--