Re: [Qemu-devel] [PULL 4/5] hw/display: Add basic ATI VGA emulation

[Mark Cave-Ayland]

On 11/03/2019 19:51, BALATON Zoltan wrote:

> On Mon, 11 Mar 2019, Markus Armbruster wrote:
>> Gerd Hoffmann <address@hidden> writes:
>>> From: BALATON Zoltan <address@hidden>
>>>
>>> At least two machines, the PPC mac99 and MIPS fulong2e, have an ATI
>>> gfx chip by default (Rage 128 Pro and M6/RV100 respectively) and
>>> guests running on these and the PMON2000 firmware of the fulong2e
>>> expect this to be available. Fortunately these are very similar chips
>>> so they can be mostly emulated in the same device model. This patch
>>> adds basic emulation of these ATI VGA chips.
>>>
>>> While this is incomplete and currently only enough to run the MIPS
>>> firmware and get framebuffer output with Linux, it allows the fulong2e
>>> board to work more like the real hardware and having it in QEMU in
>>> this state provides a way to experiment with it and allows others to
>>> contribute to improve it. It is compiled for all archs but only the
>>> fulong2e (which currently has no display output at all) is set to use
>>> it by default (in a separate patch).
>>>
>>> Signed-off-by: BALATON Zoltan <address@hidden>
>>> Acked-by: Aleksandar Markovic <address@hidden>
>>> Tested-by: Andrew Randrianasulu <address@hidden>
>>> Tested-by: Howard Spoelstra <address@hidden>
>>> Message-id:
>>> address@hidden
>>> Signed-off-by: Gerd Hoffmann <address@hidden>
>> [...]
>>> diff --git a/hw/display/trace-events b/hw/display/trace-events
>>> index 37d3264bb2e6..80993cc4d913 100644
>>> --- a/hw/display/trace-events
>>> +++ b/hw/display/trace-events
>>> @@ -138,3 +138,7 @@ vga_cirrus_write_blt(uint32_t offset, uint32_t val) 
>>> "offset
>>> 0x%x, val 0x%x"
>>>  sii9022_read_reg(uint8_t addr, uint8_t val) "addr 0x%02x, val 0x%02x"
>>>  sii9022_write_reg(uint8_t addr, uint8_t val) "addr 0x%02x, val 0x%02x"
>>>  sii9022_switch_mode(const char *mode) "mode: %s"
>>> +
>>> +# hw/display/ati*.c
>>> +ati_mm_read(unsigned int size, uint64_t addr, const char *name, uint64_t 
>>> val) "%u
>>> 0x%"HWADDR_PRIx " %s -> 0x%"PRIx64
>>> +ati_mm_write(unsigned int size, uint64_t addr, const char *name, uint64_t 
>>> val)
>>> "%u 0x%"HWADDR_PRIx " %s <- 0x%"PRIx64
>>
>> Blows up for me:
>>
>> Traceback (most recent call last):
>>  File "/work/armbru/qemu/scripts/tracetool.py", line 152, in <module>
>>    main(sys.argv)
>>  File "/work/armbru/qemu/scripts/tracetool.py", line 147, in main
>>    binary=binary, probe_prefix=probe_prefix)
>>  File "/work/armbru/qemu/scripts/tracetool/__init__.py", line 472, in 
>> generate
>>    tracetool.format.generate(events, format, backend, group)
>>  File "/work/armbru/qemu/scripts/tracetool/format/__init__.py", line 85, in 
>> generate
>>    func(events, backend, group)
>>  File "/work/armbru/qemu/scripts/tracetool/format/log_stap.py", line 121, in 
>> generate
>>    fmt_str = "address@hidden " + e.name + " " + c_fmt_to_stap(e.fmt) + "\\n"
>>  File "/work/armbru/qemu/scripts/tracetool/format/log_stap.py", line 64, in
>> c_fmt_to_stap
>>    bits.append(c_macro_to_format(macro))
>>  File "/work/armbru/qemu/scripts/tracetool/format/log_stap.py", line 36, in
>> c_macro_to_format
>>    raise Exception("Unhandled macro '%s'" % macro)
>> Exception: Unhandled macro 'HWADDR_PRIx'
> 
> No idea. Nobody else reported a problem with this yet and the above error 
> makes no
> sense to me. Cc'd some tracetool related people who hopefully can hint what 
> might be
> wrong. Do you get error during build? What trace backend do you use?

You can't use HWADDR_PRIx in trace-events because other non-qemu-based trace 
backends
have no awareness of it (as I also found out). For HWADDR_PRIx you need to use 
PRIx64
instead. I have a vague recollection of someone posting a patch for checkpatch 
to
detect this - does it pass a local checkpatch run?


ATB,

Mark.