qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Philippe Mathieu-Daudé" <1905297@bugs.launchpad.net>
To: qemu-devel@nongnu.org
Subject: Re: [Bug 1905297] [NEW] Zynq7000 UART clock reset initialization
Date: Mon, 23 Nov 2020 16:55:33 -0000	[thread overview]
Message-ID: <85b90548-75d2-4402-674a-cabd1a517e2a@amsat.org> (raw)
Message-ID: <20201123165533.2rJcYjjqHMwE2iNYuPHhSOU5KFvsxZlzGNzt21tNUxc@z> (raw)
In-Reply-To: 160614967524.17013.9714069541645314856.malonedeb@wampee.canonical.com

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


  reply	other threads:[~2020-11-23 17:06 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-23 16:41 [Bug 1905297] [NEW] Zynq7000 UART clock reset initialization Michael Peter
2020-11-23 16:55 ` Philippe Mathieu-Daudé [this message]
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é

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=85b90548-75d2-4402-674a-cabd1a517e2a@amsat.org \
    --to=1905297@bugs.launchpad.net \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).