Panic booting qemu-system-sparc64 with bochs_drm

[Sam Ravnborg]

Hi Mark.

On Sat, Jul 04, 2020 at 02:09:38PM +0100, Mark Cave-Ayland wrote:
> On 04/07/2020 12:11, Mark Cave-Ayland wrote:
> 
> > According to gdbstub the destination address in $g3 looks like this:
> > 
> > Breakpoint 1, 0x00000000007ad8e4 in cfb_imageblit ()
> > (gdb) i r $g3
> > g3             0x100220000      4297195520
> > 
> > 
> > The 0x100220000 address still isn't right. On sun4u the PCI address space is mapped
> > at physical address 0x1fe00000000 and adding these two together gives 0x1ff00220000
> > which seems closer, but still not the correct framebuffer address 0x1ff22000000 which
> > is reported at boot:
> > 
> > [    9.007161] [drm] Found bochs VGA, ID 0xb0c5.
> > [    9.007840] [drm] Framebuffer size 16384 kB @ 0x1ff22000000, mmio @ 0x1ff23000000.
> 
> As a comparison, I took the last known good commit 7a0483ac4ffc~1: "drm/bochs: add
> basic prime support" and added some debug in cfb_imageblit() to allow me to pick out
> p->screen_base:
> 
> (gdb) i r $o1
> o1             0x1ff22000000    2195298713600
> 
> When running git master with your patch in the same way I get a completely different
> value:
> 
> (gdb) i r $o1
> o1             0x100050000      4295294976
> 
> Does p->screen_base need to be initialised differently when using the cfb helpers?

I think what is happening is that the bochs driver request a shadow copy
for the frambuffer. And with the change to fbops we now use the cfb_
functions to write to the shadow framebuffer - which is not in any IO
space. So this does not work.

So maybe all we need is the fix in drm_fb_helper_dirty_blit_real().
If you try to undo the change so fbops is set to &drm_fbdev_fb_ops,
but keep the fix in drm_fb_helper_dirty_blit_real() how does it then
behave?

I did not find time to follow your instructions to test this myself with
qemu - sorry.

	Sam


> 
> 
> ATB,
> 
> Mark.