Re: qemu-xhci: no interrupts with 2.6.32.11 kernel [SOLVED]
On 07.02.2024 23:10, Christian Gudrian wrote: Is the kernel too old for the XHCI emulator or am I missing something else? The ancient kernel wasn't honoring bits 4:7 in register hcs_params2 (max. number of event ring segments) and tried to allocate 2 segments while QEMU only supports 1. That kills QEMU XHCI driver very early during initialization. I've patched the kernel appropriately (by replacing all occurences of ERST_NUM_SEGS with the computed allowed maximum number). XHCI is working now. Christian
Re: Linux AMBA-CLCD driver no longer works with Qemu versatilepb target. What to do?
On Fri, Feb 9, 2024 at 5:18 PM Peter Maydell wrote: > Are we talking something other than drivers/gpu/drm/pl111/ ? > > This is the older fbdev driver that used to live at drivers/video/fbdev/amba-clcd.c but was removed in Linux 6.8. I actually haven't tested if the DRM driver works since it isn't really relevant to my use case. > Generally QEMU goes with "behave as the hardware does", though > for these old boards that gets kind of tricky. My gut feeling is > "this is a guest kernel bug that should be fixed in the guest > kernel". > I guess it was a long shot getting some sort of command line switch accepted for probably just one user. I'm guessing the kernel driver only ever really got tested with vexpress boards or something, so maybe it never even worked on real versatilepb hardware. The fact that the switch is there at all though suggests someone at one point ran it on something with a PL110. I guess there's not much to be done but create my own private kernel patchset.
Re: Linux AMBA-CLCD driver no longer works with Qemu versatilepb target. What to do?
On Fri, 9 Feb 2024 at 16:53, Christopher Davies
wrote:
> I've been down a bit of a rabbit hole trying to get the Linux AMBA-CLCD
> driver for versatilepb target's graphics to work with modern Linux kernels.
> After a good deal of reading of both the Linux kernel code and the qemu code,
> I discovered why it won't work and why it probably has never worked since the
> transition to devicetree in the kernel about a decade ago.
>
> The driver chooses between PL110 and PL111 mode by taking the identifier from
> the AMBA bus:
>
> if (amba_manf(fb->dev) == 0x41 && amba_part(fb->dev) == 0x111) {
> fb->off_ienb = CLCD_PL111_IENB;
> fb->off_cntl = CLCD_PL111_CNTL;
> } else {
> fb->off_ienb = CLCD_PL110_IENB;
> fb->off_cntl = CLCD_PL110_CNTL;
> }
This indeed doesn't sound right -- it ought to use a
dtb compatible property to indicate that it's the weird versatilepb
variant.
> While Qemu thinks that the PL110_versatile ought to have the PL110 device ID,
> but the PL111 behaviour.
>
> static const unsigned char *idregs[] = {
> pl110_id,
> /* The ARM documentation (DDI0224C) says the CLCDC on the Versatile board
> * has a different ID (0x93, 0x10, 0x04, 0x00, ...). However the hardware
> * itself has the same ID values as a stock PL110, and guests (in
> * particular Linux) rely on this. We emulate what the hardware does,
> * rather than what the docs claim it ought to do.
> */
> pl110_id,
> pl111_id
> };
>
> So the Linux driver writes the wrong control register and the device is never
> enabled.
>
> I'm at a loss to know what to do about this. This hardware emulation worked
> with pre-devicetree kernels, and possibly making this change will break that,
> I really don't know. I also don't own the real hardware so I can't observe
> what the real behaviour is.
The real hardware is almost all going to be in landfill at this
point, I'm pretty sure. But I'm fairly sure that back when I wrote
that comment I would have had access to a real board and I think
I would have tested its behaviour. In fact, checking my email archive
I found the patch email I originally sent:
https://lore.kernel.org/qemu-devel/1378399437-17615-1-git-send-email-peter.mayd...@linaro.org/
and there I said:
# I happened to have to check the h/w behaviour in this area today
# during a discussion about some kernel pl11x patches, so I thought
# I might as well record the info and clean up the #if-0 in the
# process.
which seems like pretty good evidence that QEMU here is
behaving like the hardware.
> I'm possibly the only person to actually care about this in about a decade,
> and the CLCD driver has recently been removed from Linux.
Are we talking something other than drivers/gpu/drm/pl111/ ?
> I'm happy to write a patch for Qemu if anyone can suggest an approach
> to fixing this, anyone have any ideas?
Generally QEMU goes with "behave as the hardware does", though
for these old boards that gets kind of tricky. My gut feeling is
"this is a guest kernel bug that should be fixed in the guest
kernel".
-- PMM
Linux AMBA-CLCD driver no longer works with Qemu versatilepb target. What to do?
I've been down a bit of a rabbit hole trying to get the Linux AMBA-CLCD
driver for versatilepb target's graphics to work with modern Linux kernels.
After a good deal of reading of both the Linux kernel code and the qemu
code, I discovered why it won't work and why it probably has never worked
since the transition to devicetree in the kernel about a decade ago.
The driver chooses between PL110 and PL111 mode by taking the identifier
from the AMBA bus:
if (amba_manf(fb->dev) == 0x41 && amba_part(fb->dev) == 0x111) {
fb->off_ienb = CLCD_PL111_IENB;
fb->off_cntl = CLCD_PL111_CNTL;
} else {
fb->off_ienb = CLCD_PL110_IENB;
fb->off_cntl = CLCD_PL110_CNTL;
}
While Qemu thinks that the PL110_versatile ought to have the PL110 device
ID, but the PL111 behaviour.
static const unsigned char *idregs[] = {
pl110_id,
/* The ARM documentation (DDI0224C) says the CLCDC on the Versatile
board
* has a different ID (0x93, 0x10, 0x04, 0x00, ...). However the
hardware
* itself has the same ID values as a stock PL110, and guests (in
* particular Linux) rely on this. We emulate what the hardware does,
* rather than what the docs claim it ought to do.
*/
pl110_id,
pl111_id
};
So the Linux driver writes the wrong control register and the device is
never enabled.
I'm at a loss to know what to do about this. This hardware emulation worked
with pre-devicetree kernels, and possibly making this change will break
that, I really don't know. I also don't own the real hardware so I can't
observe what the real behaviour is.
I'm possibly the only person to actually care about this in about a decade,
and the CLCD driver has recently been removed from Linux. I only care about
it because I'm trying to run some old software unmodified.
I'm happy to write a patch for Qemu if anyone can suggest an approach to
fixing this, anyone have any ideas?
