diff options
Diffstat (limited to 'results/classifier/deepseek-2-tmp/output/device/1905297')
| -rw-r--r-- | results/classifier/deepseek-2-tmp/output/device/1905297 | 30 |
1 files changed, 0 insertions, 30 deletions
diff --git a/results/classifier/deepseek-2-tmp/output/device/1905297 b/results/classifier/deepseek-2-tmp/output/device/1905297 deleted file mode 100644 index 7d21a61f..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1905297 +++ /dev/null @@ -1,30 +0,0 @@ - -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 |