On 11/03/2019 19:51, BALATON Zoltan wrote:
> On Mon, 11 Mar 2019, Markus Armbruster wrote:
>> Gerd Hoffmann <kra...@redhat.com> writes:
>>> From: BALATON Zoltan <bala...@eik.bme.hu>
>>>
>>> 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 <bala...@eik.bme.hu>
>>> Acked-by: Aleksandar Markovic <amarko...@wavecomp.com>
>>> Tested-by: Andrew Randrianasulu <randrianas...@gmail.com>
>>> Tested-by: Howard Spoelstra <hsp.c...@gmail.com>
>>> Message-id:
>>> 0b1b7c22873a6e37627261b04fb687412b25ff4f.1552152100.git.bala...@eik.bme.hu
>>> Signed-off-by: Gerd Hoffmann <kra...@redhat.com>
>> [...]
>>> 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 = "%d@%d " + 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.
