diff options
Diffstat (limited to 'results/scraper/launchpad-without-comments/1905297')
| -rw-r--r-- | results/scraper/launchpad-without-comments/1905297 | 29 |
1 files changed, 29 insertions, 0 deletions
diff --git a/results/scraper/launchpad-without-comments/1905297 b/results/scraper/launchpad-without-comments/1905297 new file mode 100644 index 000000000..61c2ddadd --- /dev/null +++ b/results/scraper/launchpad-without-comments/1905297 @@ -0,0 +1,29 @@ +Zynq7000 UART clock reset initialization + +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 <email address hidden> + Date: Mon Apr 6 15:52:50 2020 +0200 \ No newline at end of file |