diff options
Diffstat (limited to 'results/classifier/118/all/1905297')
| -rw-r--r-- | results/classifier/118/all/1905297 | 148 |
1 files changed, 148 insertions, 0 deletions
diff --git a/results/classifier/118/all/1905297 b/results/classifier/118/all/1905297 new file mode 100644 index 000000000..2f245221d --- /dev/null +++ b/results/classifier/118/all/1905297 @@ -0,0 +1,148 @@ +permissions: 0.975 +peripherals: 0.974 +register: 0.972 +virtual: 0.972 +hypervisor: 0.972 +debug: 0.971 +VMM: 0.970 +assembly: 0.968 +graphic: 0.968 +semantic: 0.967 +socket: 0.966 +vnc: 0.966 +arm: 0.964 +performance: 0.962 +architecture: 0.962 +device: 0.962 +KVM: 0.961 +PID: 0.961 +files: 0.960 +kernel: 0.959 +ppc: 0.954 +boot: 0.952 +TCG: 0.951 +network: 0.947 +x86: 0.945 +user-level: 0.943 +risc-v: 0.941 +mistranslation: 0.936 +i386: 0.925 + +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 + + + +Hi Michael, + +On 11/23/20 5:41 PM, Michael Peter wrote: +> Public bug reported: +> +> 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 +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> ** Patch added: "0001-Initialize-Zynq7000-UART-clocks-on-reset.patch" +> https://bugs.launchpad.net/bugs/1905297/+attachment/5437267/+files/0001-Initialize-Zynq7000-UART-clocks-on-reset.patch +> + +Can you post your patch to the mailing list +please? See: +https://wiki.qemu.org/Contribute/SubmitAPatch#Do_not_send_as_an_attachment + +Note, you must sign your patch with a Signed-off-by: +line, see: +https://wiki.qemu.org/Contribute/SubmitAPatch#Patch_emails_must_include_a_Signed-off-by:_line + +Regards, + +Phil. + + +Hi Phil, + +thanks for your advise and patience. + +I created a new patch (this time with a sign-off) and sent it to <email address hidden>. + +Since I have to use a corporate email system, I hope that the formatting is not gone. + +Best regards, + +Michael + +Has this been fixed in QEMU v6.0? + +[Expired for QEMU because there has been no activity for 60 days.] + +Any update? + +I guess the patch has never been sent to the qemu-devel mailing list and thus was never considered for inclusion. Anyway, let's move this ticket over to the new bug tracker at gitlab.com, maybe it gets more attention there... + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/468 + + +Michael your patch is still missing your Signed-off-tag. Can you re-attach it including it? +You can also use https://sr.ht/ to send the patch directly to the list. + |