Zynq7000 UART clock reset initialization

Bug #1905297 reported by Michael Peter
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
QEMU
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_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

Revision history for this message
Michael Peter (michaelpeter) wrote :
Revision history for this message
Philippe Mathieu-Daudé (philmd) wrote : Re: [Bug 1905297] [NEW] Zynq7000 UART clock reset initialization

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.

Revision history for this message
Michael Peter (michaelpeter) wrote :

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

Revision history for this message
Thomas Huth (th-huth) wrote :

Has this been fixed in QEMU v6.0?

Changed in qemu:
status: New → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for QEMU because there has been no activity for 60 days.]

Changed in qemu:
status: Incomplete → Expired
Revision history for this message
Floyd42 (axelheider) wrote :

Any update?

Changed in qemu:
status: Expired → Incomplete
Revision history for this message
Thomas Huth (th-huth) wrote :

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
Revision history for this message
Thomas Huth (th-huth) wrote : Moved bug report

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

Revision history for this message
Philippe Mathieu-Daudé (philmd) wrote :

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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.