1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
|
permissions: 0.975
peripherals: 0.974
register: 0.972
virtual: 0.972
hypervisor: 0.972
debug: 0.971
VMM: 0.970
assembly: 0.968
graphic: 0.968
semantic: 0.967
socket: 0.966
vnc: 0.966
arm: 0.964
performance: 0.962
architecture: 0.962
device: 0.962
KVM: 0.961
PID: 0.961
files: 0.960
kernel: 0.959
ppc: 0.954
boot: 0.952
TCG: 0.951
network: 0.947
x86: 0.945
user-level: 0.943
risc-v: 0.941
mistranslation: 0.936
i386: 0.925
Zynq7000 UART clock reset initialization
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
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.
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
Has this been fixed in QEMU v6.0?
[Expired for QEMU because there has been no activity for 60 days.]
Any update?
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...
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
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.
|