[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] What should a virtual board emulate?

From: BALATON Zoltan
Subject: Re: [Qemu-devel] What should a virtual board emulate?
Date: Sun, 5 Jan 2020 11:59:25 +0100 (CET)
User-agent: Alpine 2.21.99999 (BSF 352 2019-06-22)

On Sat, 4 Jan 2020, Philippe Mathieu-Daudé wrote:
I insist this patch is incorrect for the particular case of the Fuloong2e board. I plan to revert it when I post the test.

I can only repeat my comment from when it last came up:

On Wed, 20 Mar 2019, BALATON Zoltan wrote:
Thanks, I did not know about this variable. Although the real hardware has the GPU soldered on the mainboard it makes sense to allow it to be disabled in QEMU especially at this stage when Linux kernel has some problem with it so this is a good idea.

I think the option is useful to boot Linux now until we improve rv100 emulation enough to work with the Linux DRM driver so either way you'll have a problem: with -vga none not disabling soldered chip you can't boot normal Linux CDs without patching them, with -vga none obeyed you can't use PMON. But since PMON is not bundled in QEMU (we don't have the source of the actual board firmware, only a binary) it may be less of a problem than Linux install CDs not working. After install you could change Linux to use radeon framebuffer driver which probably works better. (Although I'm not sure if anyone actually tried to do that.)

But I don't really mind either way, go with what you prefer. I only care about the chip emulations used by this board not going away as I plan to use them for pegasos2 emulation but not the fulong board itself apart from using it for cross checking changes. I know about one problem with the via-ide part that I could reproduce with both:


but I'm still not sure it's not missing irq emulation in my Marvel Discovery II emulation that's causing problem on pegasos2.

Reviewed-by: BALATON Zoltan <address@hidden>

When changing it you could also replace the -1 in pci_create with PCI_DEVFN(FULONG2E_ATI_SLOT, 0) to match the address the board has or should that be a separate patch?

Looks like this above comment was not considered last time, maybe if you change it now this could be fixed as well.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]