* [Bug 1905297] [NEW] Zynq7000 UART clock reset initialization
@ 2020-11-23 16:41 Michael Peter
2020-11-23 16:55 ` Philippe Mathieu-Daudé
` (7 more replies)
0 siblings, 8 replies; 10+ messages in thread
From: Michael Peter @ 2020-11-23 16:41 UTC (permalink / raw)
To: qemu-devel
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 <damien.hedde@greensocs.com>
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
--
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] = 0x00003F03;
[2] 38867cb7ec90..5b49a34c6800
[3] commit 5b49a34c6800d0cb917f959d8e75e5775f0fac3f (refs/bisect/bad)
Author: Damien Hedde <damien.hedde@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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bug 1905297] [NEW] Zynq7000 UART clock reset initialization
2020-11-23 16:41 [Bug 1905297] [NEW] Zynq7000 UART clock reset initialization Michael Peter
@ 2020-11-23 16:55 ` Philippe Mathieu-Daudé
2020-11-23 16:55 ` Philippe Mathieu-Daudé
2020-11-24 16:59 ` [Bug 1905297] " Michael Peter
` (6 subsequent siblings)
7 siblings, 1 reply; 10+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-11-23 16:55 UTC (permalink / raw)
To: qemu-devel, Michael Peter, Damien Hedde; +Cc: Bug 1905297, qemu-arm
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 <damien.hedde@greensocs.com>
> 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bug 1905297] [NEW] Zynq7000 UART clock reset initialization
2020-11-23 16:55 ` Philippe Mathieu-Daudé
@ 2020-11-23 16:55 ` Philippe Mathieu-Daudé
0 siblings, 0 replies; 10+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-11-23 16:55 UTC (permalink / raw)
To: qemu-devel
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 <damien.hedde@greensocs.com>
> 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.
--
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] = 0x00003F03;
[2] 38867cb7ec90..5b49a34c6800
[3] commit 5b49a34c6800d0cb917f959d8e75e5775f0fac3f (refs/bisect/bad)
Author: Damien Hedde <damien.hedde@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
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug 1905297] Re: Zynq7000 UART clock reset initialization
2020-11-23 16:41 [Bug 1905297] [NEW] Zynq7000 UART clock reset initialization Michael Peter
2020-11-23 16:55 ` Philippe Mathieu-Daudé
@ 2020-11-24 16:59 ` Michael Peter
2021-05-10 4:41 ` Thomas Huth
` (5 subsequent siblings)
7 siblings, 0 replies; 10+ messages in thread
From: Michael Peter @ 2020-11-24 16:59 UTC (permalink / raw)
To: qemu-devel
Hi Phil,
thanks for your advise and patience.
I created a new patch (this time with a sign-off) and sent it to qemu-
devel@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] = 0x00003F03;
[2] 38867cb7ec90..5b49a34c6800
[3] commit 5b49a34c6800d0cb917f959d8e75e5775f0fac3f (refs/bisect/bad)
Author: Damien Hedde <damien.hedde@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
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug 1905297] Re: Zynq7000 UART clock reset initialization
2020-11-23 16:41 [Bug 1905297] [NEW] Zynq7000 UART clock reset initialization Michael Peter
2020-11-23 16:55 ` Philippe Mathieu-Daudé
2020-11-24 16:59 ` [Bug 1905297] " Michael Peter
@ 2021-05-10 4:41 ` Thomas Huth
2021-07-10 4:17 ` Launchpad Bug Tracker
` (4 subsequent siblings)
7 siblings, 0 replies; 10+ messages in thread
From: Thomas Huth @ 2021-05-10 4:41 UTC (permalink / raw)
To: qemu-devel
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.hedde@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
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug 1905297] Re: Zynq7000 UART clock reset initialization
2020-11-23 16:41 [Bug 1905297] [NEW] Zynq7000 UART clock reset initialization Michael Peter
` (2 preceding siblings ...)
2021-05-10 4:41 ` Thomas Huth
@ 2021-07-10 4:17 ` Launchpad Bug Tracker
2021-07-10 15:57 ` Floyd42
` (3 subsequent siblings)
7 siblings, 0 replies; 10+ messages in thread
From: Launchpad Bug Tracker @ 2021-07-10 4:17 UTC (permalink / raw)
To: qemu-devel
[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] = 0x00003F03;
[2] 38867cb7ec90..5b49a34c6800
[3] commit 5b49a34c6800d0cb917f959d8e75e5775f0fac3f (refs/bisect/bad)
Author: Damien Hedde <damien.hedde@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
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug 1905297] Re: Zynq7000 UART clock reset initialization
2020-11-23 16:41 [Bug 1905297] [NEW] Zynq7000 UART clock reset initialization Michael Peter
` (3 preceding siblings ...)
2021-07-10 4:17 ` Launchpad Bug Tracker
@ 2021-07-10 15:57 ` Floyd42
2021-07-11 5:46 ` Thomas Huth
` (2 subsequent siblings)
7 siblings, 0 replies; 10+ messages in thread
From: Floyd42 @ 2021-07-10 15:57 UTC (permalink / raw)
To: qemu-devel
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] = 0x00003F03;
[2] 38867cb7ec90..5b49a34c6800
[3] commit 5b49a34c6800d0cb917f959d8e75e5775f0fac3f (refs/bisect/bad)
Author: Damien Hedde <damien.hedde@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
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug 1905297] Re: Zynq7000 UART clock reset initialization
2020-11-23 16:41 [Bug 1905297] [NEW] Zynq7000 UART clock reset initialization Michael Peter
` (4 preceding siblings ...)
2021-07-10 15:57 ` Floyd42
@ 2021-07-11 5:46 ` Thomas Huth
2021-07-11 5:48 ` [Bug 1905297] Moved bug report Thomas Huth
2021-08-05 6:56 ` [Bug 1905297] Re: Zynq7000 UART clock reset initialization Philippe Mathieu-Daudé
7 siblings, 0 replies; 10+ messages in thread
From: Thomas Huth @ 2021-07-11 5:46 UTC (permalink / raw)
To: qemu-devel
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] = 0x00003F03;
[2] 38867cb7ec90..5b49a34c6800
[3] commit 5b49a34c6800d0cb917f959d8e75e5775f0fac3f (refs/bisect/bad)
Author: Damien Hedde <damien.hedde@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
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug 1905297] Moved bug report
2020-11-23 16:41 [Bug 1905297] [NEW] Zynq7000 UART clock reset initialization Michael Peter
` (5 preceding siblings ...)
2021-07-11 5:46 ` Thomas Huth
@ 2021-07-11 5:48 ` Thomas Huth
2021-08-05 6:56 ` [Bug 1905297] Re: Zynq7000 UART clock reset initialization Philippe Mathieu-Daudé
7 siblings, 0 replies; 10+ messages in thread
From: Thomas Huth @ 2021-07-11 5:48 UTC (permalink / raw)
To: qemu-devel
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
--
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] = 0x00003F03;
[2] 38867cb7ec90..5b49a34c6800
[3] commit 5b49a34c6800d0cb917f959d8e75e5775f0fac3f (refs/bisect/bad)
Author: Damien Hedde <damien.hedde@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
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug 1905297] Re: Zynq7000 UART clock reset initialization
2020-11-23 16:41 [Bug 1905297] [NEW] Zynq7000 UART clock reset initialization Michael Peter
` (6 preceding siblings ...)
2021-07-11 5:48 ` [Bug 1905297] Moved bug report Thomas Huth
@ 2021-08-05 6:56 ` Philippe Mathieu-Daudé
7 siblings, 0 replies; 10+ messages in thread
From: Philippe Mathieu-Daudé @ 2021-08-05 6:56 UTC (permalink / raw)
To: qemu-devel
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] = 0x00003F03;
[2] 38867cb7ec90..5b49a34c6800
[3] commit 5b49a34c6800d0cb917f959d8e75e5775f0fac3f (refs/bisect/bad)
Author: Damien Hedde <damien.hedde@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
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2021-08-05 7:08 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-23 16:41 [Bug 1905297] [NEW] Zynq7000 UART clock reset initialization Michael Peter
2020-11-23 16:55 ` Philippe Mathieu-Daudé
2020-11-23 16:55 ` Philippe Mathieu-Daudé
2020-11-24 16:59 ` [Bug 1905297] " Michael Peter
2021-05-10 4:41 ` Thomas Huth
2021-07-10 4:17 ` Launchpad Bug Tracker
2021-07-10 15:57 ` Floyd42
2021-07-11 5:46 ` Thomas Huth
2021-07-11 5:48 ` [Bug 1905297] Moved bug report Thomas Huth
2021-08-05 6:56 ` [Bug 1905297] Re: Zynq7000 UART clock reset initialization Philippe Mathieu-Daudé
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).