[Bug 1905297] Re: Zynq7000 UART clock reset initialization
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. -- 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: Expired 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] = 0x3F03; [2] 38867cb7ec90..5b49a34c6800 [3] commit 5b49a34c6800d0cb917f959d8e75e5775f0fac3f (refs/bisect/bad) Author: Damien Hedde 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
[Bug 1905297] Re: Zynq7000 UART clock reset initialization
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... ** Changed in: qemu Status: Incomplete => Expired ** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #468 https://gitlab.com/qemu-project/qemu/-/issues/468 -- 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: Expired 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] = 0x3F03; [2] 38867cb7ec90..5b49a34c6800 [3] commit 5b49a34c6800d0cb917f959d8e75e5775f0fac3f (refs/bisect/bad) Author: Damien Hedde 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
[Bug 1905297] Re: Zynq7000 UART clock reset initialization
Any update? ** Changed in: qemu Status: Expired => 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] = 0x3F03; [2] 38867cb7ec90..5b49a34c6800 [3] commit 5b49a34c6800d0cb917f959d8e75e5775f0fac3f (refs/bisect/bad) Author: Damien Hedde 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
[Bug 1905297] Re: Zynq7000 UART clock reset initialization
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- 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: Expired 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] = 0x3F03; [2] 38867cb7ec90..5b49a34c6800 [3] commit 5b49a34c6800d0cb917f959d8e75e5775f0fac3f (refs/bisect/bad) Author: Damien Hedde 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
[Bug 1905297] Re: Zynq7000 UART clock reset initialization
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] = 0x3F03; [2] 38867cb7ec90..5b49a34c6800 [3] commit 5b49a34c6800d0cb917f959d8e75e5775f0fac3f (refs/bisect/bad) Author: Damien Hedde 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
[Bug 1905297] Re: Zynq7000 UART clock reset initialization
Hi Phil, thanks for your advise and patience. I created a new patch (this time with a sign-off) and sent it to qemu- de...@nongnu.org. Since I have to use a corporate email system, I hope that the formatting is not gone. Best regards, Michael -- 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: New 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] = 0x3F03; [2] 38867cb7ec90..5b49a34c6800 [3] commit 5b49a34c6800d0cb917f959d8e75e5775f0fac3f (refs/bisect/bad) Author: Damien Hedde 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
