Has this been fixed in QEMU v6.0?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1905297
Title:
Zynq7000 UART clock reset initialization
Status in QEMU:
Incomplete
Bug description:
Hello,
we have come across a strange behavior in the Zynq7000 model of Qemu
that seems to have been introduced between 5.0.0 and 5.1.0.
The reset values of the SLCR register, in particular those for UART_CLK_CTRL,
are such that
the UARTs should find functional clocks. Up to 5.0.0 this was also the
behavior that was
implemented in QEMU.
Starting in 5.1.0, we found that - despite correct reset values [1] - the
UARTs are non-functional
upon reset. Some investigation revealed that the cause for that is that the
corresponding
clocks are not properly initialized.
Between 5.0.0 and 5.1.0, there are three commits that touch the Zynq
UART clocks [2]. The last of them [3] triggers the faulty behavior.
Attached is a patch that applies 5.2.0-rc2 and yields a functional UART. We
surmise that the
underlying device release issue runs much deeper, so it is only meant to
identify the issue.
[1] hw/misc/zynq_slcr.c
static void zynq_slcr_reset_init(Object *obj, ResetType type)
s->regs[R_UART_CLK_CTRL] = 0x00003F03;
[2] 38867cb7ec90..5b49a34c6800
[3] commit 5b49a34c6800d0cb917f959d8e75e5775f0fac3f (refs/bisect/bad)
Author: Damien Hedde <damien.he...@greensocs.com>
Date: Mon Apr 6 15:52:50 2020 +0200
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1905297/+subscriptions
