* Re: qemu direct kernel boot on LoongArch [not found] <1738d60a-df3a-4102-b1da-d16a29b6e06a@t-8ch.de> @ 2023-10-10 1:12 ` maobibo 2024-09-05 3:12 ` Jason A. Donenfeld 0 siblings, 1 reply; 27+ messages in thread From: maobibo @ 2023-10-10 1:12 UTC (permalink / raw) To: Thomas Weißschuh; +Cc: loongarch, qemu-devel Thomas, Thanks for reporting this issue. It is the problem of QEMU for LoongArch system, QEMU does not support booting vmlinux with elf format without UEFI bios now. We will add support to boot vmlinux directly on QEMU LoongArch side. Regards Bibo Mao 在 2023/10/10 上午4:13, Thomas Weißschuh 写道: > Hi, > > I'm trying to boot a LoongArch Linux via the direct kernel mode of qemu. > ( qemu -kernel vmlinux -append "verbose" ) > This doesn't work so well. > > A few problems I encoutered: > > * Linux reads the cmdline from $a1 during boot, but qemu doesn't place it there. > * Qemu puts a FDT at 1MiB but Linux doesn't use it. > * Qemu does not put the cmdline into the FDT. > * Linux panics in memory_present() because memblock_init() in > arch/loongarch/kernel/mem.c did not set up any memblocks. > * Qemu has no support for initrds in direct kernel mode on LoongArch. > > (All observations based on current git versions) > > For the other architectures I'm using Linux/qemu with the direct kernel > mode works nicely including cmdline and initrds. > > Are these restrictions by design/intentional or is it just for somebody > to do the necessary legwork? > > The direct kernel mode is nice because it does not require the > installation of the additional EFI binary. > > > Thanks, > Thomas > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: qemu direct kernel boot on LoongArch 2023-10-10 1:12 ` qemu direct kernel boot on LoongArch maobibo @ 2024-09-05 3:12 ` Jason A. Donenfeld 2024-09-05 3:45 ` maobibo 0 siblings, 1 reply; 27+ messages in thread From: Jason A. Donenfeld @ 2024-09-05 3:12 UTC (permalink / raw) To: maobibo; +Cc: Thomas Weißschuh, loongarch, qemu-devel, xry111 On Tue, Oct 10, 2023 at 09:12:46AM +0800, maobibo wrote: > Thomas, > > Thanks for reporting this issue. > > It is the problem of QEMU for LoongArch system, QEMU does not support > booting vmlinux with elf format without UEFI bios now. We will add > support to boot vmlinux directly on QEMU LoongArch side. I ran into this same issue when trying to boot my test kernel for Ruoyao's recent vDSO getrandom work. Is this something that was ever addressed on the QEMU side? Jason ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: qemu direct kernel boot on LoongArch 2024-09-05 3:12 ` Jason A. Donenfeld @ 2024-09-05 3:45 ` maobibo 2024-09-05 4:04 ` Jason A. Donenfeld 0 siblings, 1 reply; 27+ messages in thread From: maobibo @ 2024-09-05 3:45 UTC (permalink / raw) To: Jason A. Donenfeld; +Cc: Thomas Weißschuh, loongarch, qemu-devel, xry111 Jason, With the latest qemu 9.1 version, elf format booting is supported. Qemu 9.0 does not support it still, here is example command line. ./qemu-system-loongarch64 -m 4G -smp 2 --cpu la464 --machine virt -serial stdio -monitor telnet:localhost:4495,server,nowait -kernel /root/linux_larch/vmlinux -initrd ramdisk -append "root=/dev/ram rdinit=/sbin/init console=ttyS0,115200" --nographic Regards Bibo Mao On 2024/9/5 上午11:12, Jason A. Donenfeld wrote: > On Tue, Oct 10, 2023 at 09:12:46AM +0800, maobibo wrote: >> Thomas, >> >> Thanks for reporting this issue. >> >> It is the problem of QEMU for LoongArch system, QEMU does not support >> booting vmlinux with elf format without UEFI bios now. We will add >> support to boot vmlinux directly on QEMU LoongArch side. > > I ran into this same issue when trying to boot my test kernel for > Ruoyao's recent vDSO getrandom work. Is this something that was ever > addressed on the QEMU side? > > Jason > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: qemu direct kernel boot on LoongArch 2024-09-05 3:45 ` maobibo @ 2024-09-05 4:04 ` Jason A. Donenfeld 2024-09-05 5:25 ` Thomas Weißschuh 0 siblings, 1 reply; 27+ messages in thread From: Jason A. Donenfeld @ 2024-09-05 4:04 UTC (permalink / raw) To: maobibo; +Cc: Thomas Weißschuh, loongarch, qemu-devel, xry111 On Thu, Sep 5, 2024 at 5:45 AM maobibo <maobibo@loongson.cn> wrote: > > Jason, > > With the latest qemu 9.1 version, elf format booting is supported. Thanks, I just figured this out too, about 4 minutes ago. Excellent. And the 1G minimum ram limit is gone too. Now working on how to trigger resets. Jason ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: qemu direct kernel boot on LoongArch 2024-09-05 4:04 ` Jason A. Donenfeld @ 2024-09-05 5:25 ` Thomas Weißschuh 2024-09-05 6:11 ` maobibo 2024-09-05 14:53 ` Jason A. Donenfeld 0 siblings, 2 replies; 27+ messages in thread From: Thomas Weißschuh @ 2024-09-05 5:25 UTC (permalink / raw) To: Jason A. Donenfeld; +Cc: maobibo, loongarch, qemu-devel, xry111 On 2024-09-05 06:04:12+0000, Jason A. Donenfeld wrote: > On Thu, Sep 5, 2024 at 5:45 AM maobibo <maobibo@loongson.cn> wrote: > > > > Jason, > > > > With the latest qemu 9.1 version, elf format booting is supported. > > Thanks, I just figured this out too, about 4 minutes ago. Excellent. > And the 1G minimum ram limit is gone too. > > Now working on how to trigger resets. With "reset" do you mean normal (non-panic) system shutdown/poweroff? Since QEMU 9.1 and a recent kernel you can use the pvpanic device for that in a cross-architecture way. Thomas ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: qemu direct kernel boot on LoongArch 2024-09-05 5:25 ` Thomas Weißschuh @ 2024-09-05 6:11 ` maobibo 2024-09-05 14:54 ` Jason A. Donenfeld 2024-09-05 14:53 ` Jason A. Donenfeld 1 sibling, 1 reply; 27+ messages in thread From: maobibo @ 2024-09-05 6:11 UTC (permalink / raw) To: Thomas Weißschuh, Jason A. Donenfeld; +Cc: loongarch, qemu-devel, xry111 On 2024/9/5 下午1:25, Thomas Weißschuh wrote: > On 2024-09-05 06:04:12+0000, Jason A. Donenfeld wrote: >> On Thu, Sep 5, 2024 at 5:45 AM maobibo <maobibo@loongson.cn> wrote: >>> >>> Jason, >>> >>> With the latest qemu 9.1 version, elf format booting is supported. >> >> Thanks, I just figured this out too, about 4 minutes ago. Excellent. >> And the 1G minimum ram limit is gone too. >> >> Now working on how to trigger resets. > > With "reset" do you mean normal (non-panic) system shutdown/poweroff? > Since QEMU 9.1 and a recent kernel you can use the pvpanic device for > that in a cross-architecture way. LoongArch uses acpi GED device to reboot machine. Now there is no FDT table description and FDT driver for acpi GED device :( We will investigate pvpanic method. Regards Bibo Mao > > > Thomas > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: qemu direct kernel boot on LoongArch 2024-09-05 6:11 ` maobibo @ 2024-09-05 14:54 ` Jason A. Donenfeld 2024-09-05 15:49 ` Jason A. Donenfeld 0 siblings, 1 reply; 27+ messages in thread From: Jason A. Donenfeld @ 2024-09-05 14:54 UTC (permalink / raw) To: maobibo; +Cc: Thomas Weißschuh, loongarch, qemu-devel, xry111 On Thu, Sep 05, 2024 at 02:11:32PM +0800, maobibo wrote: > > > On 2024/9/5 下午1:25, Thomas Weißschuh wrote: > > On 2024-09-05 06:04:12+0000, Jason A. Donenfeld wrote: > >> On Thu, Sep 5, 2024 at 5:45 AM maobibo <maobibo@loongson.cn> wrote: > >>> > >>> Jason, > >>> > >>> With the latest qemu 9.1 version, elf format booting is supported. > >> > >> Thanks, I just figured this out too, about 4 minutes ago. Excellent. > >> And the 1G minimum ram limit is gone too. > >> > >> Now working on how to trigger resets. > > > > With "reset" do you mean normal (non-panic) system shutdown/poweroff? > > Since QEMU 9.1 and a recent kernel you can use the pvpanic device for > > that in a cross-architecture way. > LoongArch uses acpi GED device to reboot machine. Now there is no FDT > table description and FDT driver for acpi GED device :( So you mean that QEMU exposes it via ACPI, but not via FDT, and the kernel doesn't know how to recognize it, even with ACPI? ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: qemu direct kernel boot on LoongArch 2024-09-05 14:54 ` Jason A. Donenfeld @ 2024-09-05 15:49 ` Jason A. Donenfeld 2024-09-06 1:09 ` maobibo 0 siblings, 1 reply; 27+ messages in thread From: Jason A. Donenfeld @ 2024-09-05 15:49 UTC (permalink / raw) To: maobibo; +Cc: Thomas Weißschuh, loongarch, qemu-devel, xry111 On Thu, Sep 05, 2024 at 04:54:41PM +0200, Jason A. Donenfeld wrote: > On Thu, Sep 05, 2024 at 02:11:32PM +0800, maobibo wrote: > > > > > > On 2024/9/5 下午1:25, Thomas Weißschuh wrote: > > > On 2024-09-05 06:04:12+0000, Jason A. Donenfeld wrote: > > >> On Thu, Sep 5, 2024 at 5:45 AM maobibo <maobibo@loongson.cn> wrote: > > >>> > > >>> Jason, > > >>> > > >>> With the latest qemu 9.1 version, elf format booting is supported. > > >> > > >> Thanks, I just figured this out too, about 4 minutes ago. Excellent. > > >> And the 1G minimum ram limit is gone too. > > >> > > >> Now working on how to trigger resets. > > > > > > With "reset" do you mean normal (non-panic) system shutdown/poweroff? > > > Since QEMU 9.1 and a recent kernel you can use the pvpanic device for > > > that in a cross-architecture way. > > LoongArch uses acpi GED device to reboot machine. Now there is no FDT > > table description and FDT driver for acpi GED device :( > > So you mean that QEMU exposes it via ACPI, but not via FDT, and the > kernel doesn't know how to recognize it, even with ACPI? Ahh, it looks like QEMU exposes it via ACPI, but ACPI is broken (?) when booting directly from ELF. So it needs to be exposed via FDT instead? Or ACPI needs to be fixed with direct ELF boot? ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: qemu direct kernel boot on LoongArch 2024-09-05 15:49 ` Jason A. Donenfeld @ 2024-09-06 1:09 ` maobibo 0 siblings, 0 replies; 27+ messages in thread From: maobibo @ 2024-09-06 1:09 UTC (permalink / raw) To: Jason A. Donenfeld; +Cc: Thomas Weißschuh, loongarch, qemu-devel, xry111 On 2024/9/5 下午11:49, Jason A. Donenfeld wrote: > On Thu, Sep 05, 2024 at 04:54:41PM +0200, Jason A. Donenfeld wrote: >> On Thu, Sep 05, 2024 at 02:11:32PM +0800, maobibo wrote: >>> >>> >>> On 2024/9/5 下午1:25, Thomas Weißschuh wrote: >>>> On 2024-09-05 06:04:12+0000, Jason A. Donenfeld wrote: >>>>> On Thu, Sep 5, 2024 at 5:45 AM maobibo <maobibo@loongson.cn> wrote: >>>>>> >>>>>> Jason, >>>>>> >>>>>> With the latest qemu 9.1 version, elf format booting is supported. >>>>> >>>>> Thanks, I just figured this out too, about 4 minutes ago. Excellent. >>>>> And the 1G minimum ram limit is gone too. >>>>> >>>>> Now working on how to trigger resets. >>>> >>>> With "reset" do you mean normal (non-panic) system shutdown/poweroff? >>>> Since QEMU 9.1 and a recent kernel you can use the pvpanic device for >>>> that in a cross-architecture way. >>> LoongArch uses acpi GED device to reboot machine. Now there is no FDT >>> table description and FDT driver for acpi GED device :( >> >> So you mean that QEMU exposes it via ACPI, but not via FDT, and the >> kernel doesn't know how to recognize it, even with ACPI? > > Ahh, it looks like QEMU exposes it via ACPI, but ACPI is broken (?) when > booting directly from ELF. So it needs to be exposed via FDT instead? Or > ACPI needs to be fixed with direct ELF boot? We plant to expose ACPI GED via FDT interface with syscon method, and the reboot driver in linux kernel side is drivers/power/reset/syscon-reboot.c. The only difference is that ACPI GED register is accessed with byte-mode, it seems that it works well with draft version. Regards Bibo Mao > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: qemu direct kernel boot on LoongArch 2024-09-05 5:25 ` Thomas Weißschuh 2024-09-05 6:11 ` maobibo @ 2024-09-05 14:53 ` Jason A. Donenfeld 2024-09-05 15:05 ` Thomas Weißschuh 1 sibling, 1 reply; 27+ messages in thread From: Jason A. Donenfeld @ 2024-09-05 14:53 UTC (permalink / raw) To: Thomas Weißschuh; +Cc: maobibo, loongarch, qemu-devel, xry111 On Thu, Sep 05, 2024 at 07:25:05AM +0200, Thomas Weißschuh wrote: > On 2024-09-05 06:04:12+0000, Jason A. Donenfeld wrote: > > On Thu, Sep 5, 2024 at 5:45 AM maobibo <maobibo@loongson.cn> wrote: > > > > > > Jason, > > > > > > With the latest qemu 9.1 version, elf format booting is supported. > > > > Thanks, I just figured this out too, about 4 minutes ago. Excellent. > > And the 1G minimum ram limit is gone too. > > > > Now working on how to trigger resets. > > With "reset" do you mean normal (non-panic) system shutdown/poweroff? > Since QEMU 9.1 and a recent kernel you can use the pvpanic device for > that in a cross-architecture way. What I mean is that I need for userspace calling `reboot(RB_AUTOBOOT);` to actually result in QEMU being told to reboot the system. Sounds like that's not possible (yet?) in 9.1? The last hurdle I'm having, in addition to that one, is getting the second serial port working. The kernel test suite that I'm running in CI for /dev/urandom development and wireguard development does `-serial stdio -serial chardev:result`, where the first serial is the normal output for logging, and the second one is the test result, so I can get that from the VM via a clean channel. This works well on other architectures, but on loongarch, it's failing to open /dev/ttyS1 the same way that it can open /dev/ttyS0. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: qemu direct kernel boot on LoongArch 2024-09-05 14:53 ` Jason A. Donenfeld @ 2024-09-05 15:05 ` Thomas Weißschuh 2024-09-05 15:07 ` Jason A. Donenfeld 0 siblings, 1 reply; 27+ messages in thread From: Thomas Weißschuh @ 2024-09-05 15:05 UTC (permalink / raw) To: Jason A. Donenfeld; +Cc: maobibo, loongarch, qemu-devel, xry111 On 2024-09-05 16:53:55+0000, Jason A. Donenfeld wrote: > On Thu, Sep 05, 2024 at 07:25:05AM +0200, Thomas Weißschuh wrote: > > On 2024-09-05 06:04:12+0000, Jason A. Donenfeld wrote: > > > On Thu, Sep 5, 2024 at 5:45 AM maobibo <maobibo@loongson.cn> wrote: > > > > > > > > Jason, > > > > > > > > With the latest qemu 9.1 version, elf format booting is supported. > > > > > > Thanks, I just figured this out too, about 4 minutes ago. Excellent. > > > And the 1G minimum ram limit is gone too. > > > > > > Now working on how to trigger resets. > > > > With "reset" do you mean normal (non-panic) system shutdown/poweroff? > > Since QEMU 9.1 and a recent kernel you can use the pvpanic device for > > that in a cross-architecture way. > > What I mean is that I need for userspace calling `reboot(RB_AUTOBOOT);` > to actually result in QEMU being told to reboot the system. Sounds like > that's not possible (yet?) in 9.1? With reboot(RB_POWER_OFF) this is indeed the exact usecase for pvpanic shutdown support. Reboot is not supported, but maybe -action shutdown=reboot works and is enough. It would also be trivial to extend pvpanic for reboot support. Use -device pvpanic-pci for QEMU and CONFIG_PVPANIC_PCI=y for Linux. (That should work for most architectures) ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: qemu direct kernel boot on LoongArch 2024-09-05 15:05 ` Thomas Weißschuh @ 2024-09-05 15:07 ` Jason A. Donenfeld 2024-09-05 15:16 ` Thomas Weißschuh 0 siblings, 1 reply; 27+ messages in thread From: Jason A. Donenfeld @ 2024-09-05 15:07 UTC (permalink / raw) To: Thomas Weißschuh; +Cc: maobibo, loongarch, qemu-devel, xry111 On Thu, Sep 5, 2024 at 5:05 PM Thomas Weißschuh <thomas@t-8ch.de> wrote: > > On 2024-09-05 16:53:55+0000, Jason A. Donenfeld wrote: > > On Thu, Sep 05, 2024 at 07:25:05AM +0200, Thomas Weißschuh wrote: > > > On 2024-09-05 06:04:12+0000, Jason A. Donenfeld wrote: > > > > On Thu, Sep 5, 2024 at 5:45 AM maobibo <maobibo@loongson.cn> wrote: > > > > > > > > > > Jason, > > > > > > > > > > With the latest qemu 9.1 version, elf format booting is supported. > > > > > > > > Thanks, I just figured this out too, about 4 minutes ago. Excellent. > > > > And the 1G minimum ram limit is gone too. > > > > > > > > Now working on how to trigger resets. > > > > > > With "reset" do you mean normal (non-panic) system shutdown/poweroff? > > > Since QEMU 9.1 and a recent kernel you can use the pvpanic device for > > > that in a cross-architecture way. > > > > What I mean is that I need for userspace calling `reboot(RB_AUTOBOOT);` > > to actually result in QEMU being told to reboot the system. Sounds like > > that's not possible (yet?) in 9.1? > > With reboot(RB_POWER_OFF) this is indeed the exact usecase for pvpanic I'm actually using reboot(RB_AUTOBOOT) wth QEMU's -no-reboot, because that tends to be far more compatible with a greater number of platforms, for example, x86 without acpi. Shucks. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: qemu direct kernel boot on LoongArch 2024-09-05 15:07 ` Jason A. Donenfeld @ 2024-09-05 15:16 ` Thomas Weißschuh 2024-09-05 15:18 ` Jason A. Donenfeld 0 siblings, 1 reply; 27+ messages in thread From: Thomas Weißschuh @ 2024-09-05 15:16 UTC (permalink / raw) To: Jason A. Donenfeld; +Cc: maobibo, loongarch, qemu-devel, xry111 On 2024-09-05 17:07:22+0000, Jason A. Donenfeld wrote: > On Thu, Sep 5, 2024 at 5:05 PM Thomas Weißschuh <thomas@t-8ch.de> wrote: > > > > On 2024-09-05 16:53:55+0000, Jason A. Donenfeld wrote: > > > On Thu, Sep 05, 2024 at 07:25:05AM +0200, Thomas Weißschuh wrote: > > > > On 2024-09-05 06:04:12+0000, Jason A. Donenfeld wrote: > > > > > On Thu, Sep 5, 2024 at 5:45 AM maobibo <maobibo@loongson.cn> wrote: > > > > > > > > > > > > Jason, > > > > > > > > > > > > With the latest qemu 9.1 version, elf format booting is supported. > > > > > > > > > > Thanks, I just figured this out too, about 4 minutes ago. Excellent. > > > > > And the 1G minimum ram limit is gone too. > > > > > > > > > > Now working on how to trigger resets. > > > > > > > > With "reset" do you mean normal (non-panic) system shutdown/poweroff? > > > > Since QEMU 9.1 and a recent kernel you can use the pvpanic device for > > > > that in a cross-architecture way. > > > > > > What I mean is that I need for userspace calling `reboot(RB_AUTOBOOT);` > > > to actually result in QEMU being told to reboot the system. Sounds like > > > that's not possible (yet?) in 9.1? > > > > With reboot(RB_POWER_OFF) this is indeed the exact usecase for pvpanic > > I'm actually using reboot(RB_AUTOBOOT) wth QEMU's -no-reboot, because > that tends to be far more compatible with a greater number of > platforms, for example, x86 without acpi. Shucks. You can check that both QEMU and the kernel support pvpanic shutdown through sysfs and if so use reboot(RB_POWER_OFF); and reboot(RB_AUTOBOOT) otherwise. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: qemu direct kernel boot on LoongArch 2024-09-05 15:16 ` Thomas Weißschuh @ 2024-09-05 15:18 ` Jason A. Donenfeld 2024-09-05 16:03 ` Thomas Weißschuh 0 siblings, 1 reply; 27+ messages in thread From: Jason A. Donenfeld @ 2024-09-05 15:18 UTC (permalink / raw) To: Thomas Weißschuh; +Cc: maobibo, loongarch, qemu-devel, xry111 On Thu, Sep 5, 2024 at 5:16 PM Thomas Weißschuh <thomas@t-8ch.de> wrote: > > On 2024-09-05 17:07:22+0000, Jason A. Donenfeld wrote: > > On Thu, Sep 5, 2024 at 5:05 PM Thomas Weißschuh <thomas@t-8ch.de> wrote: > > > > > > On 2024-09-05 16:53:55+0000, Jason A. Donenfeld wrote: > > > > On Thu, Sep 05, 2024 at 07:25:05AM +0200, Thomas Weißschuh wrote: > > > > > On 2024-09-05 06:04:12+0000, Jason A. Donenfeld wrote: > > > > > > On Thu, Sep 5, 2024 at 5:45 AM maobibo <maobibo@loongson.cn> wrote: > > > > > > > > > > > > > > Jason, > > > > > > > > > > > > > > With the latest qemu 9.1 version, elf format booting is supported. > > > > > > > > > > > > Thanks, I just figured this out too, about 4 minutes ago. Excellent. > > > > > > And the 1G minimum ram limit is gone too. > > > > > > > > > > > > Now working on how to trigger resets. > > > > > > > > > > With "reset" do you mean normal (non-panic) system shutdown/poweroff? > > > > > Since QEMU 9.1 and a recent kernel you can use the pvpanic device for > > > > > that in a cross-architecture way. > > > > > > > > What I mean is that I need for userspace calling `reboot(RB_AUTOBOOT);` > > > > to actually result in QEMU being told to reboot the system. Sounds like > > > > that's not possible (yet?) in 9.1? > > > > > > With reboot(RB_POWER_OFF) this is indeed the exact usecase for pvpanic > > > > I'm actually using reboot(RB_AUTOBOOT) wth QEMU's -no-reboot, because > > that tends to be far more compatible with a greater number of > > platforms, for example, x86 without acpi. Shucks. > > You can check that both QEMU and the kernel support pvpanic shutdown > through sysfs and if so use reboot(RB_POWER_OFF); and > reboot(RB_AUTOBOOT) otherwise. I guess. But the whole idea is to bloat the code as little as possible and use one interface for everything. Pushing that all up into userspace is pretty icky. It sounds like LoongArch already supports this via ACPI GED, but there's some plumbing that needs to be done still. So maybe I'll just wait for that. Meanwhile, any idea about adding a second serial to the platform? I've been futzing with it for a bit now to no avail. Jason ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: qemu direct kernel boot on LoongArch 2024-09-05 15:18 ` Jason A. Donenfeld @ 2024-09-05 16:03 ` Thomas Weißschuh 2024-09-06 1:14 ` maobibo 0 siblings, 1 reply; 27+ messages in thread From: Thomas Weißschuh @ 2024-09-05 16:03 UTC (permalink / raw) To: Jason A. Donenfeld; +Cc: maobibo, loongarch, qemu-devel, xry111 On 2024-09-05 17:18:07+0000, Jason A. Donenfeld wrote: > On Thu, Sep 5, 2024 at 5:16 PM Thomas Weißschuh <thomas@t-8ch.de> wrote: > > > > On 2024-09-05 17:07:22+0000, Jason A. Donenfeld wrote: > > > On Thu, Sep 5, 2024 at 5:05 PM Thomas Weißschuh <thomas@t-8ch.de> wrote: > > > > > > > > On 2024-09-05 16:53:55+0000, Jason A. Donenfeld wrote: > > > > > On Thu, Sep 05, 2024 at 07:25:05AM +0200, Thomas Weißschuh wrote: > > > > > > On 2024-09-05 06:04:12+0000, Jason A. Donenfeld wrote: > > > > > > > On Thu, Sep 5, 2024 at 5:45 AM maobibo <maobibo@loongson.cn> wrote: > > > > > > > > > > > > > > > > Jason, > > > > > > > > > > > > > > > > With the latest qemu 9.1 version, elf format booting is supported. > > > > > > > > > > > > > > Thanks, I just figured this out too, about 4 minutes ago. Excellent. > > > > > > > And the 1G minimum ram limit is gone too. > > > > > > > > > > > > > > Now working on how to trigger resets. > > > > > > > > > > > > With "reset" do you mean normal (non-panic) system shutdown/poweroff? > > > > > > Since QEMU 9.1 and a recent kernel you can use the pvpanic device for > > > > > > that in a cross-architecture way. > > > > > > > > > > What I mean is that I need for userspace calling `reboot(RB_AUTOBOOT);` > > > > > to actually result in QEMU being told to reboot the system. Sounds like > > > > > that's not possible (yet?) in 9.1? > > > > > > > > With reboot(RB_POWER_OFF) this is indeed the exact usecase for pvpanic > > > > > > I'm actually using reboot(RB_AUTOBOOT) wth QEMU's -no-reboot, because > > > that tends to be far more compatible with a greater number of > > > platforms, for example, x86 without acpi. Shucks. > > > > You can check that both QEMU and the kernel support pvpanic shutdown > > through sysfs and if so use reboot(RB_POWER_OFF); and > > reboot(RB_AUTOBOOT) otherwise. > > I guess. But the whole idea is to bloat the code as little as possible > and use one interface for everything. Pushing that all up into > userspace is pretty icky. If it works through ACPI everywhere then sure. > It sounds like LoongArch already supports this via ACPI GED, but > there's some plumbing that needs to be done still. So maybe I'll just > wait for that. Also sounds reasonable. > Meanwhile, any idea about adding a second serial to the platform? I've > been futzing with it for a bit now to no avail. No idea, sorry. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: qemu direct kernel boot on LoongArch 2024-09-05 16:03 ` Thomas Weißschuh @ 2024-09-06 1:14 ` maobibo 2024-09-06 4:04 ` Jason A. Donenfeld 0 siblings, 1 reply; 27+ messages in thread From: maobibo @ 2024-09-06 1:14 UTC (permalink / raw) To: Thomas Weißschuh, Jason A. Donenfeld; +Cc: loongarch, qemu-devel, xry111 On 2024/9/6 上午12:03, Thomas Weißschuh wrote: > On 2024-09-05 17:18:07+0000, Jason A. Donenfeld wrote: >> On Thu, Sep 5, 2024 at 5:16 PM Thomas Weißschuh <thomas@t-8ch.de> wrote: >>> >>> On 2024-09-05 17:07:22+0000, Jason A. Donenfeld wrote: >>>> On Thu, Sep 5, 2024 at 5:05 PM Thomas Weißschuh <thomas@t-8ch.de> wrote: >>>>> >>>>> On 2024-09-05 16:53:55+0000, Jason A. Donenfeld wrote: >>>>>> On Thu, Sep 05, 2024 at 07:25:05AM +0200, Thomas Weißschuh wrote: >>>>>>> On 2024-09-05 06:04:12+0000, Jason A. Donenfeld wrote: >>>>>>>> On Thu, Sep 5, 2024 at 5:45 AM maobibo <maobibo@loongson.cn> wrote: >>>>>>>>> >>>>>>>>> Jason, >>>>>>>>> >>>>>>>>> With the latest qemu 9.1 version, elf format booting is supported. >>>>>>>> >>>>>>>> Thanks, I just figured this out too, about 4 minutes ago. Excellent. >>>>>>>> And the 1G minimum ram limit is gone too. >>>>>>>> >>>>>>>> Now working on how to trigger resets. >>>>>>> >>>>>>> With "reset" do you mean normal (non-panic) system shutdown/poweroff? >>>>>>> Since QEMU 9.1 and a recent kernel you can use the pvpanic device for >>>>>>> that in a cross-architecture way. >>>>>> >>>>>> What I mean is that I need for userspace calling `reboot(RB_AUTOBOOT);` >>>>>> to actually result in QEMU being told to reboot the system. Sounds like >>>>>> that's not possible (yet?) in 9.1? >>>>> >>>>> With reboot(RB_POWER_OFF) this is indeed the exact usecase for pvpanic >>>> >>>> I'm actually using reboot(RB_AUTOBOOT) wth QEMU's -no-reboot, because >>>> that tends to be far more compatible with a greater number of >>>> platforms, for example, x86 without acpi. Shucks. >>> >>> You can check that both QEMU and the kernel support pvpanic shutdown >>> through sysfs and if so use reboot(RB_POWER_OFF); and >>> reboot(RB_AUTOBOOT) otherwise. >> >> I guess. But the whole idea is to bloat the code as little as possible >> and use one interface for everything. Pushing that all up into >> userspace is pretty icky. > > If it works through ACPI everywhere then sure. > >> It sounds like LoongArch already supports this via ACPI GED, but >> there's some plumbing that needs to be done still. So maybe I'll just >> wait for that. > > Also sounds reasonable. yeap, will submit a patch to expose ACPI GED pm interface with FDT method. > >> Meanwhile, any idea about adding a second serial to the platform? I've >> been futzing with it for a bit now to no avail. > > No idea, sorry. Will investigate the second serial method. Regards Bibo Mao ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: qemu direct kernel boot on LoongArch 2024-09-06 1:14 ` maobibo @ 2024-09-06 4:04 ` Jason A. Donenfeld 2024-09-06 4:48 ` Jason A. Donenfeld 0 siblings, 1 reply; 27+ messages in thread From: Jason A. Donenfeld @ 2024-09-06 4:04 UTC (permalink / raw) To: maobibo; +Cc: Thomas Weißschuh, loongarch, qemu-devel, xry111 On Fri, Sep 6, 2024 at 3:14 AM maobibo <maobibo@loongson.cn> wrote: > yeap, will submit a patch to expose ACPI GED pm interface with FDT method. Clever trick. Works well. > > > > >> Meanwhile, any idea about adding a second serial to the platform? I've > >> been futzing with it for a bit now to no avail. > > > > No idea, sorry. > Will investigate the second serial method. Thank you very much. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: qemu direct kernel boot on LoongArch 2024-09-06 4:04 ` Jason A. Donenfeld @ 2024-09-06 4:48 ` Jason A. Donenfeld 2024-09-06 4:49 ` [PATCH] hw/loongarch: virt: support up to 4 serial ports Jason A. Donenfeld 0 siblings, 1 reply; 27+ messages in thread From: Jason A. Donenfeld @ 2024-09-06 4:48 UTC (permalink / raw) To: maobibo; +Cc: Thomas Weißschuh, loongarch, qemu-devel, xry111 On Fri, Sep 06, 2024 at 06:04:25AM +0200, Jason A. Donenfeld wrote: > On Fri, Sep 6, 2024 at 3:14 AM maobibo <maobibo@loongson.cn> wrote: > > yeap, will submit a patch to expose ACPI GED pm interface with FDT method. > > Clever trick. Works well. > > > > > > > > >> Meanwhile, any idea about adding a second serial to the platform? I've > > >> been futzing with it for a bit now to no avail. > > > > > > No idea, sorry. > > Will investigate the second serial method. > > Thank you very much. I did it. I'll send a patch. ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH] hw/loongarch: virt: support up to 4 serial ports 2024-09-06 4:48 ` Jason A. Donenfeld @ 2024-09-06 4:49 ` Jason A. Donenfeld 2024-09-06 8:34 ` maobibo 0 siblings, 1 reply; 27+ messages in thread From: Jason A. Donenfeld @ 2024-09-06 4:49 UTC (permalink / raw) To: gaosong, jiaxun.yang, qemu-devel, thomas, xry111, maobibo Cc: Jason A. Donenfeld In order to support additional channels of communication using `-serial`, add several serial ports, up to the standard 4 generally supported by the 8250 driver. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> --- hw/loongarch/virt.c | 24 ++++++++++++++---------- include/hw/pci-host/ls7a.h | 9 +++++---- 2 files changed, 19 insertions(+), 14 deletions(-) diff --git a/hw/loongarch/virt.c b/hw/loongarch/virt.c index 4151fc5e0c..155678b684 100644 --- a/hw/loongarch/virt.c +++ b/hw/loongarch/virt.c @@ -319,10 +319,10 @@ static void fdt_add_ged_reset(LoongArchVirtMachineState *lvms) } static void fdt_add_uart_node(LoongArchVirtMachineState *lvms, - uint32_t *pch_pic_phandle) + uint32_t *pch_pic_phandle, hwaddr base, + int irq, bool chosen) { char *nodename; - hwaddr base = VIRT_UART_BASE; hwaddr size = VIRT_UART_SIZE; MachineState *ms = MACHINE(lvms); @@ -331,9 +331,9 @@ static void fdt_add_uart_node(LoongArchVirtMachineState *lvms, qemu_fdt_setprop_string(ms->fdt, nodename, "compatible", "ns16550a"); qemu_fdt_setprop_cells(ms->fdt, nodename, "reg", 0x0, base, 0x0, size); qemu_fdt_setprop_cell(ms->fdt, nodename, "clock-frequency", 100000000); - qemu_fdt_setprop_string(ms->fdt, "/chosen", "stdout-path", nodename); - qemu_fdt_setprop_cells(ms->fdt, nodename, "interrupts", - VIRT_UART_IRQ - VIRT_GSI_BASE, 0x4); + if (chosen) + qemu_fdt_setprop_string(ms->fdt, "/chosen", "stdout-path", nodename); + qemu_fdt_setprop_cells(ms->fdt, nodename, "interrupts", irq, 0x4); qemu_fdt_setprop_cell(ms->fdt, nodename, "interrupt-parent", *pch_pic_phandle); g_free(nodename); @@ -750,11 +750,15 @@ static void virt_devices_init(DeviceState *pch_pic, /* Add pcie node */ fdt_add_pcie_node(lvms, pch_pic_phandle, pch_msi_phandle); - serial_mm_init(get_system_memory(), VIRT_UART_BASE, 0, - qdev_get_gpio_in(pch_pic, - VIRT_UART_IRQ - VIRT_GSI_BASE), - 115200, serial_hd(0), DEVICE_LITTLE_ENDIAN); - fdt_add_uart_node(lvms, pch_pic_phandle); + for (i = 0; i < VIRT_UART_COUNT; ++i) { + hwaddr base = VIRT_UART_BASE + i * VIRT_UART_SIZE; + int irq = VIRT_UART_IRQ + i - VIRT_GSI_BASE; + serial_mm_init(get_system_memory(), base, 0, + qdev_get_gpio_in(pch_pic, irq), + 115200, serial_hd(VIRT_UART_COUNT - 1 - i), + DEVICE_LITTLE_ENDIAN); + fdt_add_uart_node(lvms, pch_pic_phandle, base, irq, i == 0); + } /* Network init */ pci_init_nic_devices(pci_bus, mc->default_nic); diff --git a/include/hw/pci-host/ls7a.h b/include/hw/pci-host/ls7a.h index cd7c9ec7bc..79d4ea8501 100644 --- a/include/hw/pci-host/ls7a.h +++ b/include/hw/pci-host/ls7a.h @@ -36,17 +36,18 @@ #define VIRT_PCH_PIC_IRQ_NUM 32 #define VIRT_GSI_BASE 64 #define VIRT_DEVICE_IRQS 16 +#define VIRT_UART_COUNT 4 #define VIRT_UART_IRQ (VIRT_GSI_BASE + 2) #define VIRT_UART_BASE 0x1fe001e0 -#define VIRT_UART_SIZE 0X100 -#define VIRT_RTC_IRQ (VIRT_GSI_BASE + 3) +#define VIRT_UART_SIZE 0x100 +#define VIRT_RTC_IRQ (VIRT_GSI_BASE + 6) #define VIRT_MISC_REG_BASE (VIRT_PCH_REG_BASE + 0x00080000) #define VIRT_RTC_REG_BASE (VIRT_MISC_REG_BASE + 0x00050100) #define VIRT_RTC_LEN 0x100 -#define VIRT_SCI_IRQ (VIRT_GSI_BASE + 4) +#define VIRT_SCI_IRQ (VIRT_GSI_BASE + 7) #define VIRT_PLATFORM_BUS_BASEADDRESS 0x16000000 #define VIRT_PLATFORM_BUS_SIZE 0x2000000 #define VIRT_PLATFORM_BUS_NUM_IRQS 2 -#define VIRT_PLATFORM_BUS_IRQ (VIRT_GSI_BASE + 5) +#define VIRT_PLATFORM_BUS_IRQ (VIRT_GSI_BASE + 8) #endif -- 2.46.0 ^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: [PATCH] hw/loongarch: virt: support up to 4 serial ports 2024-09-06 4:49 ` [PATCH] hw/loongarch: virt: support up to 4 serial ports Jason A. Donenfeld @ 2024-09-06 8:34 ` maobibo 2024-09-06 14:30 ` Jason A. Donenfeld 0 siblings, 1 reply; 27+ messages in thread From: maobibo @ 2024-09-06 8:34 UTC (permalink / raw) To: Jason A. Donenfeld, gaosong, jiaxun.yang, qemu-devel, thomas, xry111 On 2024/9/6 下午12:49, Jason A. Donenfeld wrote: > In order to support additional channels of communication using > `-serial`, add several serial ports, up to the standard 4 generally > supported by the 8250 driver. > > Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> > --- > hw/loongarch/virt.c | 24 ++++++++++++++---------- > include/hw/pci-host/ls7a.h | 9 +++++---- > 2 files changed, 19 insertions(+), 14 deletions(-) > > diff --git a/hw/loongarch/virt.c b/hw/loongarch/virt.c > index 4151fc5e0c..155678b684 100644 > --- a/hw/loongarch/virt.c > +++ b/hw/loongarch/virt.c > @@ -319,10 +319,10 @@ static void fdt_add_ged_reset(LoongArchVirtMachineState *lvms) > } > > static void fdt_add_uart_node(LoongArchVirtMachineState *lvms, > - uint32_t *pch_pic_phandle) > + uint32_t *pch_pic_phandle, hwaddr base, > + int irq, bool chosen) > { > char *nodename; > - hwaddr base = VIRT_UART_BASE; > hwaddr size = VIRT_UART_SIZE; > MachineState *ms = MACHINE(lvms); > > @@ -331,9 +331,9 @@ static void fdt_add_uart_node(LoongArchVirtMachineState *lvms, > qemu_fdt_setprop_string(ms->fdt, nodename, "compatible", "ns16550a"); > qemu_fdt_setprop_cells(ms->fdt, nodename, "reg", 0x0, base, 0x0, size); > qemu_fdt_setprop_cell(ms->fdt, nodename, "clock-frequency", 100000000); > - qemu_fdt_setprop_string(ms->fdt, "/chosen", "stdout-path", nodename); > - qemu_fdt_setprop_cells(ms->fdt, nodename, "interrupts", > - VIRT_UART_IRQ - VIRT_GSI_BASE, 0x4); > + if (chosen) > + qemu_fdt_setprop_string(ms->fdt, "/chosen", "stdout-path", nodename); > + qemu_fdt_setprop_cells(ms->fdt, nodename, "interrupts", irq, 0x4); > qemu_fdt_setprop_cell(ms->fdt, nodename, "interrupt-parent", > *pch_pic_phandle); > g_free(nodename); > @@ -750,11 +750,15 @@ static void virt_devices_init(DeviceState *pch_pic, > /* Add pcie node */ > fdt_add_pcie_node(lvms, pch_pic_phandle, pch_msi_phandle); > > - serial_mm_init(get_system_memory(), VIRT_UART_BASE, 0, > - qdev_get_gpio_in(pch_pic, > - VIRT_UART_IRQ - VIRT_GSI_BASE), > - 115200, serial_hd(0), DEVICE_LITTLE_ENDIAN); > - fdt_add_uart_node(lvms, pch_pic_phandle); > + for (i = 0; i < VIRT_UART_COUNT; ++i) { How about adding serial_hd(i) checking here, such as for (i = 0; (i < VIRT_UART_COUNT) && serial_hd(i); ++i) { > + hwaddr base = VIRT_UART_BASE + i * VIRT_UART_SIZE; > + int irq = VIRT_UART_IRQ + i - VIRT_GSI_BASE; > + serial_mm_init(get_system_memory(), base, 0, > + qdev_get_gpio_in(pch_pic, irq), > + 115200, serial_hd(VIRT_UART_COUNT - 1 - i), is it serial_hd(i) here rather than serial_hd(VIRT_UART_COUNT - 1 - i)? In general serial_hd(0) is default serial. > + DEVICE_LITTLE_ENDIAN); > + fdt_add_uart_node(lvms, pch_pic_phandle, base, irq, i == 0); > + } > > /* Network init */ > pci_init_nic_devices(pci_bus, mc->default_nic); > diff --git a/include/hw/pci-host/ls7a.h b/include/hw/pci-host/ls7a.h > index cd7c9ec7bc..79d4ea8501 100644 > --- a/include/hw/pci-host/ls7a.h > +++ b/include/hw/pci-host/ls7a.h > @@ -36,17 +36,18 @@ > #define VIRT_PCH_PIC_IRQ_NUM 32 > #define VIRT_GSI_BASE 64 > #define VIRT_DEVICE_IRQS 16 > +#define VIRT_UART_COUNT 4 > #define VIRT_UART_IRQ (VIRT_GSI_BASE + 2) > #define VIRT_UART_BASE 0x1fe001e0 > -#define VIRT_UART_SIZE 0X100 > -#define VIRT_RTC_IRQ (VIRT_GSI_BASE + 3) > +#define VIRT_UART_SIZE 0x100 > +#define VIRT_RTC_IRQ (VIRT_GSI_BASE + 6) > #define VIRT_MISC_REG_BASE (VIRT_PCH_REG_BASE + 0x00080000) > #define VIRT_RTC_REG_BASE (VIRT_MISC_REG_BASE + 0x00050100) > #define VIRT_RTC_LEN 0x100 > -#define VIRT_SCI_IRQ (VIRT_GSI_BASE + 4) > +#define VIRT_SCI_IRQ (VIRT_GSI_BASE + 7) > > #define VIRT_PLATFORM_BUS_BASEADDRESS 0x16000000 > #define VIRT_PLATFORM_BUS_SIZE 0x2000000 > #define VIRT_PLATFORM_BUS_NUM_IRQS 2 > -#define VIRT_PLATFORM_BUS_IRQ (VIRT_GSI_BASE + 5) > +#define VIRT_PLATFORM_BUS_IRQ (VIRT_GSI_BASE + 8) > #endif > By the way, serial port for acpi table should be refreshed also, such as diff --git a/hw/loongarch/acpi-build.c b/hw/loongarch/acpi-build.c index 2638f87434..5bd2a9beaa 100644 --- a/hw/loongarch/acpi-build.c +++ b/hw/loongarch/acpi-build.c @@ -31,6 +31,7 @@ #include "hw/acpi/generic_event_device.h" #include "hw/pci-host/gpex.h" +#include "sysemu/sysemu.h" #include "sysemu/tpm.h" #include "hw/platform-bus.h" #include "hw/acpi/aml-build.h" @@ -252,23 +253,26 @@ struct AcpiBuildState { MemoryRegion *linker_mr; } AcpiBuildState; -static void build_uart_device_aml(Aml *table) +static void build_uart_device_aml(Aml *table, int index) { Aml *dev; Aml *crs; Aml *pkg0, *pkg1, *pkg2; - uint32_t uart_irq = VIRT_UART_IRQ; + uint32_t uart_irq; + uint64_t base; + uart_irq = VIRT_UART_IRQ + index; + base = VIRT_UART_BASE + index * VIRT_UART_SIZE; Aml *scope = aml_scope("_SB"); - dev = aml_device("COMA"); + dev = aml_device("COM%d", index); aml_append(dev, aml_name_decl("_HID", aml_string("PNP0501"))); - aml_append(dev, aml_name_decl("_UID", aml_int(0))); + aml_append(dev, aml_name_decl("_UID", aml_int(index))); aml_append(dev, aml_name_decl("_CCA", aml_int(1))); crs = aml_resource_template(); aml_append(crs, aml_qword_memory(AML_POS_DECODE, AML_MIN_FIXED, AML_MAX_FIXED, AML_NON_CACHEABLE, AML_READ_WRITE, - 0, VIRT_UART_BASE, VIRT_UART_BASE + VIRT_UART_SIZE - 1, + 0, base, base + VIRT_UART_SIZE - 1, 0, VIRT_UART_SIZE)); aml_append(crs, aml_interrupt(AML_CONSUMER, AML_LEVEL, AML_ACTIVE_HIGH, AML_SHARED, &uart_irq, 1)); @@ -405,10 +409,13 @@ build_dsdt(GArray *table_data, BIOSLinker *linker, MachineState *machine) LoongArchVirtMachineState *lvms = LOONGARCH_VIRT_MACHINE(machine); AcpiTable table = { .sig = "DSDT", .rev = 1, .oem_id = lvms->oem_id, .oem_table_id = lvms->oem_table_id }; + int i; acpi_table_begin(&table, table_data); dsdt = init_aml_allocator(); - build_uart_device_aml(dsdt); + for (i = 0; (i < VIRT_UART_COUNT) && serial_hd(i); i++) { + build_uart_device_aml(dsdt, i); + } build_pci_device_aml(dsdt, lvms); build_la_ged_aml(dsdt, machine); build_flash_aml(dsdt, lvms); Regards Bibo Mao ^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: [PATCH] hw/loongarch: virt: support up to 4 serial ports 2024-09-06 8:34 ` maobibo @ 2024-09-06 14:30 ` Jason A. Donenfeld 2024-09-06 14:31 ` [PATCH v2] " Jason A. Donenfeld 0 siblings, 1 reply; 27+ messages in thread From: Jason A. Donenfeld @ 2024-09-06 14:30 UTC (permalink / raw) To: maobibo; +Cc: gaosong, jiaxun.yang, qemu-devel, thomas, xry111 On Fri, Sep 06, 2024 at 04:34:53PM +0800, maobibo wrote: > > + for (i = 0; i < VIRT_UART_COUNT; ++i) { > How about adding serial_hd(i) checking here, such as > for (i = 0; (i < VIRT_UART_COUNT) && serial_hd(i); ++i) { That doesn't seem to do anything, unfortunately. > > > + hwaddr base = VIRT_UART_BASE + i * VIRT_UART_SIZE; > > + int irq = VIRT_UART_IRQ + i - VIRT_GSI_BASE; > > + serial_mm_init(get_system_memory(), base, 0, > > + qdev_get_gpio_in(pch_pic, irq), > > + 115200, serial_hd(VIRT_UART_COUNT - 1 - i), > is it serial_hd(i) here rather than serial_hd(VIRT_UART_COUNT - 1 - i)? > In general serial_hd(0) is default serial. They've got to be added in reverse order. The chosen calculation needed to be fixed though, in the line below: > > + fdt_add_uart_node(lvms, pch_pic_phandle, base, irq, i == 0); That now checks for the last index. > By the way, serial port for acpi table should be refreshed also, such as Thanks. Will send you a v2. Jason ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH v2] hw/loongarch: virt: support up to 4 serial ports 2024-09-06 14:30 ` Jason A. Donenfeld @ 2024-09-06 14:31 ` Jason A. Donenfeld 2024-09-07 3:37 ` maobibo 2024-09-07 14:34 ` [PATCH v3] " Jason A. Donenfeld 0 siblings, 2 replies; 27+ messages in thread From: Jason A. Donenfeld @ 2024-09-06 14:31 UTC (permalink / raw) To: maobibo, gaosong, jiaxun.yang, qemu-devel, thomas, xry111 Cc: Jason A. Donenfeld In order to support additional channels of communication using `-serial`, add several serial ports, up to the standard 4 generally supported by the 8250 driver. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> --- As I don't use ACPI, I haven't tested the ACPI part of this, which Maobibo wrote. hw/loongarch/acpi-build.c | 23 +++++++++++++++-------- hw/loongarch/virt.c | 24 ++++++++++++++---------- include/hw/pci-host/ls7a.h | 9 +++++---- 3 files changed, 34 insertions(+), 22 deletions(-) diff --git a/hw/loongarch/acpi-build.c b/hw/loongarch/acpi-build.c index 2638f87434..2750c6e858 100644 --- a/hw/loongarch/acpi-build.c +++ b/hw/loongarch/acpi-build.c @@ -31,6 +31,7 @@ #include "hw/acpi/generic_event_device.h" #include "hw/pci-host/gpex.h" +#include "sysemu/sysemu.h" #include "sysemu/tpm.h" #include "hw/platform-bus.h" #include "hw/acpi/aml-build.h" @@ -252,23 +253,27 @@ struct AcpiBuildState { MemoryRegion *linker_mr; } AcpiBuildState; -static void build_uart_device_aml(Aml *table) +static void build_uart_device_aml(Aml *table, int index) { Aml *dev; Aml *crs; Aml *pkg0, *pkg1, *pkg2; - uint32_t uart_irq = VIRT_UART_IRQ; - - Aml *scope = aml_scope("_SB"); - dev = aml_device("COMA"); + Aml *scope; + uint32_t uart_irq; + uint64_t base; + + uart_irq = VIRT_UART_IRQ + index; + base = VIRT_UART_BASE + index * VIRT_UART_SIZE; + scope = aml_scope("_SB"); + dev = aml_device("COM%d", VIRT_UART_COUNT - 1 - index); aml_append(dev, aml_name_decl("_HID", aml_string("PNP0501"))); - aml_append(dev, aml_name_decl("_UID", aml_int(0))); + aml_append(dev, aml_name_decl("_UID", aml_int(VIRT_UART_COUNT - 1 - index))); aml_append(dev, aml_name_decl("_CCA", aml_int(1))); crs = aml_resource_template(); aml_append(crs, aml_qword_memory(AML_POS_DECODE, AML_MIN_FIXED, AML_MAX_FIXED, AML_NON_CACHEABLE, AML_READ_WRITE, - 0, VIRT_UART_BASE, VIRT_UART_BASE + VIRT_UART_SIZE - 1, + 0, base, base + VIRT_UART_SIZE - 1, 0, VIRT_UART_SIZE)); aml_append(crs, aml_interrupt(AML_CONSUMER, AML_LEVEL, AML_ACTIVE_HIGH, AML_SHARED, &uart_irq, 1)); @@ -401,6 +406,7 @@ static void acpi_dsdt_add_tpm(Aml *scope, LoongArchVirtMachineState *vms) static void build_dsdt(GArray *table_data, BIOSLinker *linker, MachineState *machine) { + int i; Aml *dsdt, *scope, *pkg; LoongArchVirtMachineState *lvms = LOONGARCH_VIRT_MACHINE(machine); AcpiTable table = { .sig = "DSDT", .rev = 1, .oem_id = lvms->oem_id, @@ -408,7 +414,8 @@ build_dsdt(GArray *table_data, BIOSLinker *linker, MachineState *machine) acpi_table_begin(&table, table_data); dsdt = init_aml_allocator(); - build_uart_device_aml(dsdt); + for (i = 0; i < VIRT_UART_COUNT; ++i) + build_uart_device_aml(dsdt, i); build_pci_device_aml(dsdt, lvms); build_la_ged_aml(dsdt, machine); build_flash_aml(dsdt, lvms); diff --git a/hw/loongarch/virt.c b/hw/loongarch/virt.c index 4151fc5e0c..6e8608874c 100644 --- a/hw/loongarch/virt.c +++ b/hw/loongarch/virt.c @@ -319,10 +319,10 @@ static void fdt_add_ged_reset(LoongArchVirtMachineState *lvms) } static void fdt_add_uart_node(LoongArchVirtMachineState *lvms, - uint32_t *pch_pic_phandle) + uint32_t *pch_pic_phandle, hwaddr base, + int irq, bool chosen) { char *nodename; - hwaddr base = VIRT_UART_BASE; hwaddr size = VIRT_UART_SIZE; MachineState *ms = MACHINE(lvms); @@ -331,9 +331,9 @@ static void fdt_add_uart_node(LoongArchVirtMachineState *lvms, qemu_fdt_setprop_string(ms->fdt, nodename, "compatible", "ns16550a"); qemu_fdt_setprop_cells(ms->fdt, nodename, "reg", 0x0, base, 0x0, size); qemu_fdt_setprop_cell(ms->fdt, nodename, "clock-frequency", 100000000); - qemu_fdt_setprop_string(ms->fdt, "/chosen", "stdout-path", nodename); - qemu_fdt_setprop_cells(ms->fdt, nodename, "interrupts", - VIRT_UART_IRQ - VIRT_GSI_BASE, 0x4); + if (chosen) + qemu_fdt_setprop_string(ms->fdt, "/chosen", "stdout-path", nodename); + qemu_fdt_setprop_cells(ms->fdt, nodename, "interrupts", irq, 0x4); qemu_fdt_setprop_cell(ms->fdt, nodename, "interrupt-parent", *pch_pic_phandle); g_free(nodename); @@ -750,11 +750,15 @@ static void virt_devices_init(DeviceState *pch_pic, /* Add pcie node */ fdt_add_pcie_node(lvms, pch_pic_phandle, pch_msi_phandle); - serial_mm_init(get_system_memory(), VIRT_UART_BASE, 0, - qdev_get_gpio_in(pch_pic, - VIRT_UART_IRQ - VIRT_GSI_BASE), - 115200, serial_hd(0), DEVICE_LITTLE_ENDIAN); - fdt_add_uart_node(lvms, pch_pic_phandle); + for (i = 0; i < VIRT_UART_COUNT; ++i) { + hwaddr base = VIRT_UART_BASE + i * VIRT_UART_SIZE; + int irq = VIRT_UART_IRQ + i - VIRT_GSI_BASE; + serial_mm_init(get_system_memory(), base, 0, + qdev_get_gpio_in(pch_pic, irq), + 115200, serial_hd(VIRT_UART_COUNT - 1 - i), + DEVICE_LITTLE_ENDIAN); + fdt_add_uart_node(lvms, pch_pic_phandle, base, irq, i == VIRT_UART_COUNT - 1 - i); + } /* Network init */ pci_init_nic_devices(pci_bus, mc->default_nic); diff --git a/include/hw/pci-host/ls7a.h b/include/hw/pci-host/ls7a.h index cd7c9ec7bc..79d4ea8501 100644 --- a/include/hw/pci-host/ls7a.h +++ b/include/hw/pci-host/ls7a.h @@ -36,17 +36,18 @@ #define VIRT_PCH_PIC_IRQ_NUM 32 #define VIRT_GSI_BASE 64 #define VIRT_DEVICE_IRQS 16 +#define VIRT_UART_COUNT 4 #define VIRT_UART_IRQ (VIRT_GSI_BASE + 2) #define VIRT_UART_BASE 0x1fe001e0 -#define VIRT_UART_SIZE 0X100 -#define VIRT_RTC_IRQ (VIRT_GSI_BASE + 3) +#define VIRT_UART_SIZE 0x100 +#define VIRT_RTC_IRQ (VIRT_GSI_BASE + 6) #define VIRT_MISC_REG_BASE (VIRT_PCH_REG_BASE + 0x00080000) #define VIRT_RTC_REG_BASE (VIRT_MISC_REG_BASE + 0x00050100) #define VIRT_RTC_LEN 0x100 -#define VIRT_SCI_IRQ (VIRT_GSI_BASE + 4) +#define VIRT_SCI_IRQ (VIRT_GSI_BASE + 7) #define VIRT_PLATFORM_BUS_BASEADDRESS 0x16000000 #define VIRT_PLATFORM_BUS_SIZE 0x2000000 #define VIRT_PLATFORM_BUS_NUM_IRQS 2 -#define VIRT_PLATFORM_BUS_IRQ (VIRT_GSI_BASE + 5) +#define VIRT_PLATFORM_BUS_IRQ (VIRT_GSI_BASE + 8) #endif -- 2.46.0 ^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: [PATCH v2] hw/loongarch: virt: support up to 4 serial ports 2024-09-06 14:31 ` [PATCH v2] " Jason A. Donenfeld @ 2024-09-07 3:37 ` maobibo 2024-09-07 14:44 ` Jason A. Donenfeld 2024-09-07 14:34 ` [PATCH v3] " Jason A. Donenfeld 1 sibling, 1 reply; 27+ messages in thread From: maobibo @ 2024-09-07 3:37 UTC (permalink / raw) To: Jason A. Donenfeld, gaosong, jiaxun.yang, qemu-devel, thomas, xry111 Hi Jason, It works well with ELF kernel, however it fails to boot with UEFI BIOS. Maybe it is problem of UEFI BIOS, can we create UART in reverse order? so that it can work well on both ELF kernel and UEFI BIOS. Also for develops they usually use as earlycon with command line -serial stdio --append "... earlycon=uart,mmio,0x1fe001e0", this requires to uart with address 0x1fe001e0 as the first serial port. Just small code base your patch like this: - for (i = 0; i < VIRT_UART_COUNT; ++i) { + for (i = VIRT_UART_COUNT - 1; i >= 0; i--) { hwaddr base = VIRT_UART_BASE + i * VIRT_UART_SIZE; int irq = VIRT_UART_IRQ + i - VIRT_GSI_BASE; serial_mm_init(get_system_memory(), base, 0, qdev_get_gpio_in(pch_pic, irq), - 115200, serial_hd(VIRT_UART_COUNT - 1 - i), + 115200, serial_hd(i), DEVICE_LITTLE_ENDIAN); - fdt_add_uart_node(lvms, pch_pic_phandle, base, irq, i == VIRT_UART_COUNT - 1 - i); + fdt_add_uart_node(lvms, pch_pic_phandle, base, irq, i == 0); } Regards Bibo Mao On 2024/9/6 下午10:31, Jason A. Donenfeld wrote: > In order to support additional channels of communication using > `-serial`, add several serial ports, up to the standard 4 generally > supported by the 8250 driver. > > Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> > --- > As I don't use ACPI, I haven't tested the ACPI part of this, which > Maobibo wrote. > > hw/loongarch/acpi-build.c | 23 +++++++++++++++-------- > hw/loongarch/virt.c | 24 ++++++++++++++---------- > include/hw/pci-host/ls7a.h | 9 +++++---- > 3 files changed, 34 insertions(+), 22 deletions(-) > > diff --git a/hw/loongarch/acpi-build.c b/hw/loongarch/acpi-build.c > index 2638f87434..2750c6e858 100644 > --- a/hw/loongarch/acpi-build.c > +++ b/hw/loongarch/acpi-build.c > @@ -31,6 +31,7 @@ > > #include "hw/acpi/generic_event_device.h" > #include "hw/pci-host/gpex.h" > +#include "sysemu/sysemu.h" > #include "sysemu/tpm.h" > #include "hw/platform-bus.h" > #include "hw/acpi/aml-build.h" > @@ -252,23 +253,27 @@ struct AcpiBuildState { > MemoryRegion *linker_mr; > } AcpiBuildState; > > -static void build_uart_device_aml(Aml *table) > +static void build_uart_device_aml(Aml *table, int index) > { > Aml *dev; > Aml *crs; > Aml *pkg0, *pkg1, *pkg2; > - uint32_t uart_irq = VIRT_UART_IRQ; > - > - Aml *scope = aml_scope("_SB"); > - dev = aml_device("COMA"); > + Aml *scope; > + uint32_t uart_irq; > + uint64_t base; > + > + uart_irq = VIRT_UART_IRQ + index; > + base = VIRT_UART_BASE + index * VIRT_UART_SIZE; > + scope = aml_scope("_SB"); > + dev = aml_device("COM%d", VIRT_UART_COUNT - 1 - index); > aml_append(dev, aml_name_decl("_HID", aml_string("PNP0501"))); > - aml_append(dev, aml_name_decl("_UID", aml_int(0))); > + aml_append(dev, aml_name_decl("_UID", aml_int(VIRT_UART_COUNT - 1 - index))); > aml_append(dev, aml_name_decl("_CCA", aml_int(1))); > crs = aml_resource_template(); > aml_append(crs, > aml_qword_memory(AML_POS_DECODE, AML_MIN_FIXED, AML_MAX_FIXED, > AML_NON_CACHEABLE, AML_READ_WRITE, > - 0, VIRT_UART_BASE, VIRT_UART_BASE + VIRT_UART_SIZE - 1, > + 0, base, base + VIRT_UART_SIZE - 1, > 0, VIRT_UART_SIZE)); > aml_append(crs, aml_interrupt(AML_CONSUMER, AML_LEVEL, AML_ACTIVE_HIGH, > AML_SHARED, &uart_irq, 1)); > @@ -401,6 +406,7 @@ static void acpi_dsdt_add_tpm(Aml *scope, LoongArchVirtMachineState *vms) > static void > build_dsdt(GArray *table_data, BIOSLinker *linker, MachineState *machine) > { > + int i; > Aml *dsdt, *scope, *pkg; > LoongArchVirtMachineState *lvms = LOONGARCH_VIRT_MACHINE(machine); > AcpiTable table = { .sig = "DSDT", .rev = 1, .oem_id = lvms->oem_id, > @@ -408,7 +414,8 @@ build_dsdt(GArray *table_data, BIOSLinker *linker, MachineState *machine) > > acpi_table_begin(&table, table_data); > dsdt = init_aml_allocator(); > - build_uart_device_aml(dsdt); > + for (i = 0; i < VIRT_UART_COUNT; ++i) > + build_uart_device_aml(dsdt, i); > build_pci_device_aml(dsdt, lvms); > build_la_ged_aml(dsdt, machine); > build_flash_aml(dsdt, lvms); > diff --git a/hw/loongarch/virt.c b/hw/loongarch/virt.c > index 4151fc5e0c..6e8608874c 100644 > --- a/hw/loongarch/virt.c > +++ b/hw/loongarch/virt.c > @@ -319,10 +319,10 @@ static void fdt_add_ged_reset(LoongArchVirtMachineState *lvms) > } > > static void fdt_add_uart_node(LoongArchVirtMachineState *lvms, > - uint32_t *pch_pic_phandle) > + uint32_t *pch_pic_phandle, hwaddr base, > + int irq, bool chosen) > { > char *nodename; > - hwaddr base = VIRT_UART_BASE; > hwaddr size = VIRT_UART_SIZE; > MachineState *ms = MACHINE(lvms); > > @@ -331,9 +331,9 @@ static void fdt_add_uart_node(LoongArchVirtMachineState *lvms, > qemu_fdt_setprop_string(ms->fdt, nodename, "compatible", "ns16550a"); > qemu_fdt_setprop_cells(ms->fdt, nodename, "reg", 0x0, base, 0x0, size); > qemu_fdt_setprop_cell(ms->fdt, nodename, "clock-frequency", 100000000); > - qemu_fdt_setprop_string(ms->fdt, "/chosen", "stdout-path", nodename); > - qemu_fdt_setprop_cells(ms->fdt, nodename, "interrupts", > - VIRT_UART_IRQ - VIRT_GSI_BASE, 0x4); > + if (chosen) > + qemu_fdt_setprop_string(ms->fdt, "/chosen", "stdout-path", nodename); > + qemu_fdt_setprop_cells(ms->fdt, nodename, "interrupts", irq, 0x4); > qemu_fdt_setprop_cell(ms->fdt, nodename, "interrupt-parent", > *pch_pic_phandle); > g_free(nodename); > @@ -750,11 +750,15 @@ static void virt_devices_init(DeviceState *pch_pic, > /* Add pcie node */ > fdt_add_pcie_node(lvms, pch_pic_phandle, pch_msi_phandle); > > - serial_mm_init(get_system_memory(), VIRT_UART_BASE, 0, > - qdev_get_gpio_in(pch_pic, > - VIRT_UART_IRQ - VIRT_GSI_BASE), > - 115200, serial_hd(0), DEVICE_LITTLE_ENDIAN); > - fdt_add_uart_node(lvms, pch_pic_phandle); > + for (i = 0; i < VIRT_UART_COUNT; ++i) { > + hwaddr base = VIRT_UART_BASE + i * VIRT_UART_SIZE; > + int irq = VIRT_UART_IRQ + i - VIRT_GSI_BASE; > + serial_mm_init(get_system_memory(), base, 0, > + qdev_get_gpio_in(pch_pic, irq), > + 115200, serial_hd(VIRT_UART_COUNT - 1 - i), > + DEVICE_LITTLE_ENDIAN); > + fdt_add_uart_node(lvms, pch_pic_phandle, base, irq, i == VIRT_UART_COUNT - 1 - i); > + } > > /* Network init */ > pci_init_nic_devices(pci_bus, mc->default_nic); > diff --git a/include/hw/pci-host/ls7a.h b/include/hw/pci-host/ls7a.h > index cd7c9ec7bc..79d4ea8501 100644 > --- a/include/hw/pci-host/ls7a.h > +++ b/include/hw/pci-host/ls7a.h > @@ -36,17 +36,18 @@ > #define VIRT_PCH_PIC_IRQ_NUM 32 > #define VIRT_GSI_BASE 64 > #define VIRT_DEVICE_IRQS 16 > +#define VIRT_UART_COUNT 4 > #define VIRT_UART_IRQ (VIRT_GSI_BASE + 2) > #define VIRT_UART_BASE 0x1fe001e0 > -#define VIRT_UART_SIZE 0X100 > -#define VIRT_RTC_IRQ (VIRT_GSI_BASE + 3) > +#define VIRT_UART_SIZE 0x100 > +#define VIRT_RTC_IRQ (VIRT_GSI_BASE + 6) > #define VIRT_MISC_REG_BASE (VIRT_PCH_REG_BASE + 0x00080000) > #define VIRT_RTC_REG_BASE (VIRT_MISC_REG_BASE + 0x00050100) > #define VIRT_RTC_LEN 0x100 > -#define VIRT_SCI_IRQ (VIRT_GSI_BASE + 4) > +#define VIRT_SCI_IRQ (VIRT_GSI_BASE + 7) > > #define VIRT_PLATFORM_BUS_BASEADDRESS 0x16000000 > #define VIRT_PLATFORM_BUS_SIZE 0x2000000 > #define VIRT_PLATFORM_BUS_NUM_IRQS 2 > -#define VIRT_PLATFORM_BUS_IRQ (VIRT_GSI_BASE + 5) > +#define VIRT_PLATFORM_BUS_IRQ (VIRT_GSI_BASE + 8) > #endif > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v2] hw/loongarch: virt: support up to 4 serial ports 2024-09-07 3:37 ` maobibo @ 2024-09-07 14:44 ` Jason A. Donenfeld 2024-09-07 14:57 ` Jason A. Donenfeld 0 siblings, 1 reply; 27+ messages in thread From: Jason A. Donenfeld @ 2024-09-07 14:44 UTC (permalink / raw) To: maobibo; +Cc: gaosong, jiaxun.yang, qemu-devel, thomas, xry111 On Sat, Sep 07, 2024 at 11:37:09AM +0800, maobibo wrote: > Hi Jason, > > It works well with ELF kernel, however it fails to boot with UEFI BIOS. > Maybe it is problem of UEFI BIOS, can we create UART in reverse order? > so that it can work well on both ELF kernel and UEFI BIOS. > > Also for develops they usually use as earlycon with command line > -serial stdio --append "... earlycon=uart,mmio,0x1fe001e0", this > requires to uart with address 0x1fe001e0 as the first serial port. > > Just small code base your patch like this: > > - for (i = 0; i < VIRT_UART_COUNT; ++i) { > + for (i = VIRT_UART_COUNT - 1; i >= 0; i--) { > hwaddr base = VIRT_UART_BASE + i * VIRT_UART_SIZE; > int irq = VIRT_UART_IRQ + i - VIRT_GSI_BASE; > serial_mm_init(get_system_memory(), base, 0, > qdev_get_gpio_in(pch_pic, irq), > - 115200, serial_hd(VIRT_UART_COUNT - 1 - i), > + 115200, serial_hd(i), > DEVICE_LITTLE_ENDIAN); > - fdt_add_uart_node(lvms, pch_pic_phandle, base, irq, i == > VIRT_UART_COUNT - 1 - i); > + fdt_add_uart_node(lvms, pch_pic_phandle, base, irq, i == 0); > } Fixed: https://lore.kernel.org/all/20240907143439.2792924-1-Jason@zx2c4.com/ ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v2] hw/loongarch: virt: support up to 4 serial ports 2024-09-07 14:44 ` Jason A. Donenfeld @ 2024-09-07 14:57 ` Jason A. Donenfeld 0 siblings, 0 replies; 27+ messages in thread From: Jason A. Donenfeld @ 2024-09-07 14:57 UTC (permalink / raw) To: maobibo; +Cc: gaosong, jiaxun.yang, qemu-devel, thomas, xry111 On Sat, Sep 07, 2024 at 04:44:45PM +0200, Jason A. Donenfeld wrote: > On Sat, Sep 07, 2024 at 11:37:09AM +0800, maobibo wrote: > > Hi Jason, > > > > It works well with ELF kernel, however it fails to boot with UEFI BIOS. > > Maybe it is problem of UEFI BIOS, can we create UART in reverse order? > > so that it can work well on both ELF kernel and UEFI BIOS. > > > > Also for develops they usually use as earlycon with command line > > -serial stdio --append "... earlycon=uart,mmio,0x1fe001e0", this > > requires to uart with address 0x1fe001e0 as the first serial port. > > > > Just small code base your patch like this: > > > > - for (i = 0; i < VIRT_UART_COUNT; ++i) { > > + for (i = VIRT_UART_COUNT - 1; i >= 0; i--) { > > hwaddr base = VIRT_UART_BASE + i * VIRT_UART_SIZE; > > int irq = VIRT_UART_IRQ + i - VIRT_GSI_BASE; > > serial_mm_init(get_system_memory(), base, 0, > > qdev_get_gpio_in(pch_pic, irq), > > - 115200, serial_hd(VIRT_UART_COUNT - 1 - i), > > + 115200, serial_hd(i), > > DEVICE_LITTLE_ENDIAN); > > - fdt_add_uart_node(lvms, pch_pic_phandle, base, irq, i == > > VIRT_UART_COUNT - 1 - i); > > + fdt_add_uart_node(lvms, pch_pic_phandle, base, irq, i == 0); > > } > > Fixed: https://lore.kernel.org/all/20240907143439.2792924-1-Jason@zx2c4.com/ By the way, I don't know who is picking patches into which development tree from the list, but this is starting to be kind of a lot of patches, so I've queued them all up here: https://git.zx2c4.com/qemu/log/?h=loongarch64 In case that makes it easier for whoever the maintainer is to pick them. ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH v3] hw/loongarch: virt: support up to 4 serial ports 2024-09-06 14:31 ` [PATCH v2] " Jason A. Donenfeld 2024-09-07 3:37 ` maobibo @ 2024-09-07 14:34 ` Jason A. Donenfeld 2024-09-09 1:22 ` maobibo 1 sibling, 1 reply; 27+ messages in thread From: Jason A. Donenfeld @ 2024-09-07 14:34 UTC (permalink / raw) To: maobibo, gaosong, jiaxun.yang, qemu-devel, thomas, xry111 Cc: Jason A. Donenfeld In order to support additional channels of communication using `-serial`, add several serial ports, up to the standard 4 generally supported by the 8250 driver. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> --- hw/loongarch/acpi-build.c | 23 +++++++++++++++-------- hw/loongarch/virt.c | 23 +++++++++++++---------- include/hw/pci-host/ls7a.h | 9 +++++---- 3 files changed, 33 insertions(+), 22 deletions(-) diff --git a/hw/loongarch/acpi-build.c b/hw/loongarch/acpi-build.c index 3912c8d307..459d2b5f84 100644 --- a/hw/loongarch/acpi-build.c +++ b/hw/loongarch/acpi-build.c @@ -31,6 +31,7 @@ #include "hw/acpi/generic_event_device.h" #include "hw/pci-host/gpex.h" +#include "sysemu/sysemu.h" #include "sysemu/tpm.h" #include "hw/platform-bus.h" #include "hw/acpi/aml-build.h" @@ -290,23 +291,27 @@ struct AcpiBuildState { MemoryRegion *linker_mr; } AcpiBuildState; -static void build_uart_device_aml(Aml *table) +static void build_uart_device_aml(Aml *table, int index) { Aml *dev; Aml *crs; Aml *pkg0, *pkg1, *pkg2; - uint32_t uart_irq = VIRT_UART_IRQ; - - Aml *scope = aml_scope("_SB"); - dev = aml_device("COMA"); + Aml *scope; + uint32_t uart_irq; + uint64_t base; + + uart_irq = VIRT_UART_IRQ + index; + base = VIRT_UART_BASE + index * VIRT_UART_SIZE; + scope = aml_scope("_SB"); + dev = aml_device("COM%d", index); aml_append(dev, aml_name_decl("_HID", aml_string("PNP0501"))); - aml_append(dev, aml_name_decl("_UID", aml_int(0))); + aml_append(dev, aml_name_decl("_UID", aml_int(index))); aml_append(dev, aml_name_decl("_CCA", aml_int(1))); crs = aml_resource_template(); aml_append(crs, aml_qword_memory(AML_POS_DECODE, AML_MIN_FIXED, AML_MAX_FIXED, AML_NON_CACHEABLE, AML_READ_WRITE, - 0, VIRT_UART_BASE, VIRT_UART_BASE + VIRT_UART_SIZE - 1, + 0, base, base + VIRT_UART_SIZE - 1, 0, VIRT_UART_SIZE)); aml_append(crs, aml_interrupt(AML_CONSUMER, AML_LEVEL, AML_ACTIVE_HIGH, AML_SHARED, &uart_irq, 1)); @@ -439,6 +444,7 @@ static void acpi_dsdt_add_tpm(Aml *scope, LoongArchVirtMachineState *vms) static void build_dsdt(GArray *table_data, BIOSLinker *linker, MachineState *machine) { + int i; Aml *dsdt, *scope, *pkg; LoongArchVirtMachineState *lvms = LOONGARCH_VIRT_MACHINE(machine); AcpiTable table = { .sig = "DSDT", .rev = 1, .oem_id = lvms->oem_id, @@ -446,7 +452,8 @@ build_dsdt(GArray *table_data, BIOSLinker *linker, MachineState *machine) acpi_table_begin(&table, table_data); dsdt = init_aml_allocator(); - build_uart_device_aml(dsdt); + for (i = VIRT_UART_COUNT; i --> 0;) + build_uart_device_aml(dsdt, i); build_pci_device_aml(dsdt, lvms); build_la_ged_aml(dsdt, machine); build_flash_aml(dsdt, lvms); diff --git a/hw/loongarch/virt.c b/hw/loongarch/virt.c index 4151fc5e0c..b9bd88d3f4 100644 --- a/hw/loongarch/virt.c +++ b/hw/loongarch/virt.c @@ -319,10 +319,10 @@ static void fdt_add_ged_reset(LoongArchVirtMachineState *lvms) } static void fdt_add_uart_node(LoongArchVirtMachineState *lvms, - uint32_t *pch_pic_phandle) + uint32_t *pch_pic_phandle, hwaddr base, + int irq, bool chosen) { char *nodename; - hwaddr base = VIRT_UART_BASE; hwaddr size = VIRT_UART_SIZE; MachineState *ms = MACHINE(lvms); @@ -331,9 +331,9 @@ static void fdt_add_uart_node(LoongArchVirtMachineState *lvms, qemu_fdt_setprop_string(ms->fdt, nodename, "compatible", "ns16550a"); qemu_fdt_setprop_cells(ms->fdt, nodename, "reg", 0x0, base, 0x0, size); qemu_fdt_setprop_cell(ms->fdt, nodename, "clock-frequency", 100000000); - qemu_fdt_setprop_string(ms->fdt, "/chosen", "stdout-path", nodename); - qemu_fdt_setprop_cells(ms->fdt, nodename, "interrupts", - VIRT_UART_IRQ - VIRT_GSI_BASE, 0x4); + if (chosen) + qemu_fdt_setprop_string(ms->fdt, "/chosen", "stdout-path", nodename); + qemu_fdt_setprop_cells(ms->fdt, nodename, "interrupts", irq, 0x4); qemu_fdt_setprop_cell(ms->fdt, nodename, "interrupt-parent", *pch_pic_phandle); g_free(nodename); @@ -750,11 +750,14 @@ static void virt_devices_init(DeviceState *pch_pic, /* Add pcie node */ fdt_add_pcie_node(lvms, pch_pic_phandle, pch_msi_phandle); - serial_mm_init(get_system_memory(), VIRT_UART_BASE, 0, - qdev_get_gpio_in(pch_pic, - VIRT_UART_IRQ - VIRT_GSI_BASE), - 115200, serial_hd(0), DEVICE_LITTLE_ENDIAN); - fdt_add_uart_node(lvms, pch_pic_phandle); + for (i = VIRT_UART_COUNT; i --> 0;) { + hwaddr base = VIRT_UART_BASE + i * VIRT_UART_SIZE; + int irq = VIRT_UART_IRQ + i - VIRT_GSI_BASE; + serial_mm_init(get_system_memory(), base, 0, + qdev_get_gpio_in(pch_pic, irq), + 115200, serial_hd(i), DEVICE_LITTLE_ENDIAN); + fdt_add_uart_node(lvms, pch_pic_phandle, base, irq, i == 0); + } /* Network init */ pci_init_nic_devices(pci_bus, mc->default_nic); diff --git a/include/hw/pci-host/ls7a.h b/include/hw/pci-host/ls7a.h index cd7c9ec7bc..79d4ea8501 100644 --- a/include/hw/pci-host/ls7a.h +++ b/include/hw/pci-host/ls7a.h @@ -36,17 +36,18 @@ #define VIRT_PCH_PIC_IRQ_NUM 32 #define VIRT_GSI_BASE 64 #define VIRT_DEVICE_IRQS 16 +#define VIRT_UART_COUNT 4 #define VIRT_UART_IRQ (VIRT_GSI_BASE + 2) #define VIRT_UART_BASE 0x1fe001e0 -#define VIRT_UART_SIZE 0X100 -#define VIRT_RTC_IRQ (VIRT_GSI_BASE + 3) +#define VIRT_UART_SIZE 0x100 +#define VIRT_RTC_IRQ (VIRT_GSI_BASE + 6) #define VIRT_MISC_REG_BASE (VIRT_PCH_REG_BASE + 0x00080000) #define VIRT_RTC_REG_BASE (VIRT_MISC_REG_BASE + 0x00050100) #define VIRT_RTC_LEN 0x100 -#define VIRT_SCI_IRQ (VIRT_GSI_BASE + 4) +#define VIRT_SCI_IRQ (VIRT_GSI_BASE + 7) #define VIRT_PLATFORM_BUS_BASEADDRESS 0x16000000 #define VIRT_PLATFORM_BUS_SIZE 0x2000000 #define VIRT_PLATFORM_BUS_NUM_IRQS 2 -#define VIRT_PLATFORM_BUS_IRQ (VIRT_GSI_BASE + 5) +#define VIRT_PLATFORM_BUS_IRQ (VIRT_GSI_BASE + 8) #endif -- 2.46.0 ^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: [PATCH v3] hw/loongarch: virt: support up to 4 serial ports 2024-09-07 14:34 ` [PATCH v3] " Jason A. Donenfeld @ 2024-09-09 1:22 ` maobibo 0 siblings, 0 replies; 27+ messages in thread From: maobibo @ 2024-09-09 1:22 UTC (permalink / raw) To: Jason A. Donenfeld, gaosong, jiaxun.yang, qemu-devel, thomas, xry111 On 2024/9/7 下午10:34, Jason A. Donenfeld wrote: > In order to support additional channels of communication using > `-serial`, add several serial ports, up to the standard 4 generally > supported by the 8250 driver. > > Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> > --- > hw/loongarch/acpi-build.c | 23 +++++++++++++++-------- > hw/loongarch/virt.c | 23 +++++++++++++---------- > include/hw/pci-host/ls7a.h | 9 +++++---- > 3 files changed, 33 insertions(+), 22 deletions(-) > > diff --git a/hw/loongarch/acpi-build.c b/hw/loongarch/acpi-build.c > index 3912c8d307..459d2b5f84 100644 > --- a/hw/loongarch/acpi-build.c > +++ b/hw/loongarch/acpi-build.c > @@ -31,6 +31,7 @@ > > #include "hw/acpi/generic_event_device.h" > #include "hw/pci-host/gpex.h" > +#include "sysemu/sysemu.h" > #include "sysemu/tpm.h" > #include "hw/platform-bus.h" > #include "hw/acpi/aml-build.h" > @@ -290,23 +291,27 @@ struct AcpiBuildState { > MemoryRegion *linker_mr; > } AcpiBuildState; > > -static void build_uart_device_aml(Aml *table) > +static void build_uart_device_aml(Aml *table, int index) > { > Aml *dev; > Aml *crs; > Aml *pkg0, *pkg1, *pkg2; > - uint32_t uart_irq = VIRT_UART_IRQ; > - > - Aml *scope = aml_scope("_SB"); > - dev = aml_device("COMA"); > + Aml *scope; > + uint32_t uart_irq; > + uint64_t base; > + > + uart_irq = VIRT_UART_IRQ + index; > + base = VIRT_UART_BASE + index * VIRT_UART_SIZE; > + scope = aml_scope("_SB"); > + dev = aml_device("COM%d", index); > aml_append(dev, aml_name_decl("_HID", aml_string("PNP0501"))); > - aml_append(dev, aml_name_decl("_UID", aml_int(0))); > + aml_append(dev, aml_name_decl("_UID", aml_int(index))); > aml_append(dev, aml_name_decl("_CCA", aml_int(1))); > crs = aml_resource_template(); > aml_append(crs, > aml_qword_memory(AML_POS_DECODE, AML_MIN_FIXED, AML_MAX_FIXED, > AML_NON_CACHEABLE, AML_READ_WRITE, > - 0, VIRT_UART_BASE, VIRT_UART_BASE + VIRT_UART_SIZE - 1, > + 0, base, base + VIRT_UART_SIZE - 1, > 0, VIRT_UART_SIZE)); > aml_append(crs, aml_interrupt(AML_CONSUMER, AML_LEVEL, AML_ACTIVE_HIGH, > AML_SHARED, &uart_irq, 1)); > @@ -439,6 +444,7 @@ static void acpi_dsdt_add_tpm(Aml *scope, LoongArchVirtMachineState *vms) > static void > build_dsdt(GArray *table_data, BIOSLinker *linker, MachineState *machine) > { > + int i; > Aml *dsdt, *scope, *pkg; > LoongArchVirtMachineState *lvms = LOONGARCH_VIRT_MACHINE(machine); > AcpiTable table = { .sig = "DSDT", .rev = 1, .oem_id = lvms->oem_id, > @@ -446,7 +452,8 @@ build_dsdt(GArray *table_data, BIOSLinker *linker, MachineState *machine) > > acpi_table_begin(&table, table_data); > dsdt = init_aml_allocator(); > - build_uart_device_aml(dsdt); > + for (i = VIRT_UART_COUNT; i --> 0;) > + build_uart_device_aml(dsdt, i); > build_pci_device_aml(dsdt, lvms); > build_la_ged_aml(dsdt, machine); > build_flash_aml(dsdt, lvms); > diff --git a/hw/loongarch/virt.c b/hw/loongarch/virt.c > index 4151fc5e0c..b9bd88d3f4 100644 > --- a/hw/loongarch/virt.c > +++ b/hw/loongarch/virt.c > @@ -319,10 +319,10 @@ static void fdt_add_ged_reset(LoongArchVirtMachineState *lvms) > } > > static void fdt_add_uart_node(LoongArchVirtMachineState *lvms, > - uint32_t *pch_pic_phandle) > + uint32_t *pch_pic_phandle, hwaddr base, > + int irq, bool chosen) > { > char *nodename; > - hwaddr base = VIRT_UART_BASE; > hwaddr size = VIRT_UART_SIZE; > MachineState *ms = MACHINE(lvms); > > @@ -331,9 +331,9 @@ static void fdt_add_uart_node(LoongArchVirtMachineState *lvms, > qemu_fdt_setprop_string(ms->fdt, nodename, "compatible", "ns16550a"); > qemu_fdt_setprop_cells(ms->fdt, nodename, "reg", 0x0, base, 0x0, size); > qemu_fdt_setprop_cell(ms->fdt, nodename, "clock-frequency", 100000000); > - qemu_fdt_setprop_string(ms->fdt, "/chosen", "stdout-path", nodename); > - qemu_fdt_setprop_cells(ms->fdt, nodename, "interrupts", > - VIRT_UART_IRQ - VIRT_GSI_BASE, 0x4); > + if (chosen) > + qemu_fdt_setprop_string(ms->fdt, "/chosen", "stdout-path", nodename); > + qemu_fdt_setprop_cells(ms->fdt, nodename, "interrupts", irq, 0x4); > qemu_fdt_setprop_cell(ms->fdt, nodename, "interrupt-parent", > *pch_pic_phandle); > g_free(nodename); > @@ -750,11 +750,14 @@ static void virt_devices_init(DeviceState *pch_pic, > /* Add pcie node */ > fdt_add_pcie_node(lvms, pch_pic_phandle, pch_msi_phandle); > > - serial_mm_init(get_system_memory(), VIRT_UART_BASE, 0, > - qdev_get_gpio_in(pch_pic, > - VIRT_UART_IRQ - VIRT_GSI_BASE), > - 115200, serial_hd(0), DEVICE_LITTLE_ENDIAN); > - fdt_add_uart_node(lvms, pch_pic_phandle); > + for (i = VIRT_UART_COUNT; i --> 0;) { > + hwaddr base = VIRT_UART_BASE + i * VIRT_UART_SIZE; > + int irq = VIRT_UART_IRQ + i - VIRT_GSI_BASE; > + serial_mm_init(get_system_memory(), base, 0, > + qdev_get_gpio_in(pch_pic, irq), > + 115200, serial_hd(i), DEVICE_LITTLE_ENDIAN); > + fdt_add_uart_node(lvms, pch_pic_phandle, base, irq, i == 0); > + } > > /* Network init */ > pci_init_nic_devices(pci_bus, mc->default_nic); > diff --git a/include/hw/pci-host/ls7a.h b/include/hw/pci-host/ls7a.h > index cd7c9ec7bc..79d4ea8501 100644 > --- a/include/hw/pci-host/ls7a.h > +++ b/include/hw/pci-host/ls7a.h > @@ -36,17 +36,18 @@ > #define VIRT_PCH_PIC_IRQ_NUM 32 > #define VIRT_GSI_BASE 64 > #define VIRT_DEVICE_IRQS 16 > +#define VIRT_UART_COUNT 4 > #define VIRT_UART_IRQ (VIRT_GSI_BASE + 2) > #define VIRT_UART_BASE 0x1fe001e0 > -#define VIRT_UART_SIZE 0X100 > -#define VIRT_RTC_IRQ (VIRT_GSI_BASE + 3) > +#define VIRT_UART_SIZE 0x100 > +#define VIRT_RTC_IRQ (VIRT_GSI_BASE + 6) > #define VIRT_MISC_REG_BASE (VIRT_PCH_REG_BASE + 0x00080000) > #define VIRT_RTC_REG_BASE (VIRT_MISC_REG_BASE + 0x00050100) > #define VIRT_RTC_LEN 0x100 > -#define VIRT_SCI_IRQ (VIRT_GSI_BASE + 4) > +#define VIRT_SCI_IRQ (VIRT_GSI_BASE + 7) > > #define VIRT_PLATFORM_BUS_BASEADDRESS 0x16000000 > #define VIRT_PLATFORM_BUS_SIZE 0x2000000 > #define VIRT_PLATFORM_BUS_NUM_IRQS 2 > -#define VIRT_PLATFORM_BUS_IRQ (VIRT_GSI_BASE + 5) > +#define VIRT_PLATFORM_BUS_IRQ (VIRT_GSI_BASE + 8) > #endif > Tested-by: Bibo Mao <maobibo@loongson.cn> ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2024-09-09 1:24 UTC | newest]
Thread overview: 27+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <1738d60a-df3a-4102-b1da-d16a29b6e06a@t-8ch.de>
2023-10-10 1:12 ` qemu direct kernel boot on LoongArch maobibo
2024-09-05 3:12 ` Jason A. Donenfeld
2024-09-05 3:45 ` maobibo
2024-09-05 4:04 ` Jason A. Donenfeld
2024-09-05 5:25 ` Thomas Weißschuh
2024-09-05 6:11 ` maobibo
2024-09-05 14:54 ` Jason A. Donenfeld
2024-09-05 15:49 ` Jason A. Donenfeld
2024-09-06 1:09 ` maobibo
2024-09-05 14:53 ` Jason A. Donenfeld
2024-09-05 15:05 ` Thomas Weißschuh
2024-09-05 15:07 ` Jason A. Donenfeld
2024-09-05 15:16 ` Thomas Weißschuh
2024-09-05 15:18 ` Jason A. Donenfeld
2024-09-05 16:03 ` Thomas Weißschuh
2024-09-06 1:14 ` maobibo
2024-09-06 4:04 ` Jason A. Donenfeld
2024-09-06 4:48 ` Jason A. Donenfeld
2024-09-06 4:49 ` [PATCH] hw/loongarch: virt: support up to 4 serial ports Jason A. Donenfeld
2024-09-06 8:34 ` maobibo
2024-09-06 14:30 ` Jason A. Donenfeld
2024-09-06 14:31 ` [PATCH v2] " Jason A. Donenfeld
2024-09-07 3:37 ` maobibo
2024-09-07 14:44 ` Jason A. Donenfeld
2024-09-07 14:57 ` Jason A. Donenfeld
2024-09-07 14:34 ` [PATCH v3] " Jason A. Donenfeld
2024-09-09 1:22 ` maobibo
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).