[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:
https://osdn.net/projects/qmiga/ticket/38949
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.
Regards,
BALATON Zoltan