Zynq7000 UART clock reset initialization
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
QEMU |
Expired
|
Undecided
|
Unassigned |
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_
[2] 38867cb7ec90.
[3] commit 5b49a34c6800d0c
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: reset_init( Object *obj, ResetType type) R_UART_ CLK_CTRL] = 0x00003F03; .5b49a34c6800 b917f959d8e75e5 775f0fac3f (refs/bisect/bad) e-Zynq7000- UART-clocks- on-reset. patch" /bugs.launchpad .net/bugs/ 1905297/ +attachment/ 5437267/ +files/ 0001-Initialize -Zynq7000- UART-clocks- on-reset. patch
> 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_
> s->regs[
> [2] 38867cb7ec90.
> [3] commit 5b49a34c6800d0c
> Author: Damien Hedde <email address hidden>
> Date: Mon Apr 6 15:52:50 2020 +0200
>
> ** Affects: qemu
> Importance: Undecided
> Status: New
>
> ** Patch added: "0001-Initializ
> https:/
>
Can you post your patch to the mailing list /wiki.qemu. org/Contribute/ SubmitAPatch# Do_not_ send_as_ an_attachment
please? See:
https:/
Note, you must sign your patch with a Signed-off-by: /wiki.qemu. org/Contribute/ SubmitAPatch# Patch_emails_ must_include_ a_Signed- off-by: _line
line, see:
https:/
Regards,
Phil.