<feed xmlns='http://www.w3.org/2005/Atom'>
<title>qemu/docs/system/arm, branch master</title>
<subtitle>QEMU development tree</subtitle>
<id>https://git.zx2c4.com/qemu/atom/docs/system/arm?h=master</id>
<link rel='self' href='https://git.zx2c4.com/qemu/atom/docs/system/arm?h=master'/>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/qemu/'/>
<updated>2024-07-21T05:46:38Z</updated>
<entry>
<title>aspeed: Introduce a 'boot-emmc' machine option</title>
<updated>2024-07-21T05:46:38Z</updated>
<author>
<name>Cédric Le Goater</name>
<email>clg@kaod.org</email>
</author>
<published>2024-07-17T06:30:22Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/qemu/commit/?id=056b779eaf10ab84e8ca9d02662a975f4de3d3b1'/>
<id>urn:sha1:056b779eaf10ab84e8ca9d02662a975f4de3d3b1</id>
<content type='text'>
The default behavior of some Aspeed machines is to boot from the eMMC
device, like the rainier-bmc. Others like ast2600-evb could also boot
from eMMC if the HW strapping boot-from-eMMC bit was set. Add a
property to set or unset this bit. This is useful to test boot images.

For now, only activate this property on the ast2600-evb and rainier-bmc
machines for which eMMC images are available or can be built.

Signed-off-by: Cédric Le Goater &lt;clg@kaod.org&gt;
Reviewed-by: Andrew Jeffery &lt;andrew@codeconstruct.com.au&gt;
Tested-by: Andrew Jeffery &lt;andrew@codeconstruct.com.au&gt;
Tested-by: Philippe Mathieu-Daudé &lt;philmd@linaro.org&gt;
</content>
</entry>
<entry>
<title>docs/system/arm: Add a doc for zynq board</title>
<updated>2024-07-01T14:40:54Z</updated>
<author>
<name>Sai Pavan Boddu</name>
<email>sai.pavan.boddu@amd.com</email>
</author>
<published>2024-06-21T12:59:06Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/qemu/commit/?id=2d30506d065743008184a3b0269529bd9159560e'/>
<id>urn:sha1:2d30506d065743008184a3b0269529bd9159560e</id>
<content type='text'>
Added the supported device list and an example command.

Signed-off-by: Sai Pavan Boddu &lt;sai.pavan.boddu@amd.com&gt;
Reviewed-by: Edgar E. Iglesias &lt;edgar.iglesias@amd.com&gt;
Reviewed-by: Francisco Iglesias &lt;francisco.iglesias@amd.com&gt;
Message-id: 20240621125906.1300995-4-sai.pavan.boddu@amd.com
Signed-off-by: Peter Maydell &lt;peter.maydell@linaro.org&gt;
</content>
</entry>
<entry>
<title>target/arm: Enable FEAT_Debugv8p8 for -cpu max</title>
<updated>2024-07-01T14:40:53Z</updated>
<author>
<name>Gustavo Romero</name>
<email>gustavo.romero@linaro.org</email>
</author>
<published>2024-06-24T18:09:15Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/qemu/commit/?id=02ff2add77099f9deb7d6a18c9b4110572771f6a'/>
<id>urn:sha1:02ff2add77099f9deb7d6a18c9b4110572771f6a</id>
<content type='text'>
Enable FEAT_Debugv8p8 for max CPU. This feature is out of scope for QEMU
since it concerns the external debug interface for JTAG, but is
mandatory in Armv8.8 implementations, hence it is reported as supported
in the ID registers.

Signed-off-by: Gustavo Romero &lt;gustavo.romero@linaro.org&gt;
Reviewed-by: Richard Henderson &lt;richard.henderson@linaro.org&gt;
Message-id: 20240624180915.4528-4-gustavo.romero@linaro.org
Signed-off-by: Peter Maydell &lt;peter.maydell@linaro.org&gt;
</content>
</entry>
<entry>
<title>hw/arm/sbsa-ref: Enable CPU cluster on ARM sbsa machine</title>
<updated>2024-06-21T15:24:46Z</updated>
<author>
<name>Xiong Yining</name>
<email>xiongyining1480@phytium.com.cn</email>
</author>
<published>2024-06-07T10:38:25Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/qemu/commit/?id=3b36cead6ecc0e40edb8b2f3e253baa01ebc1e9a'/>
<id>urn:sha1:3b36cead6ecc0e40edb8b2f3e253baa01ebc1e9a</id>
<content type='text'>
Enable CPU cluster support on SbsaQemu platform, so that users can
specify a 4-level CPU hierarchy sockets/clusters/cores/threads. And
this topology can be passed to the firmware through /cpus/topology
Device Tree.

Signed-off-by: Xiong Yining &lt;xiongyining1480@phytium.com.cn&gt;
Reviewed-by: Marcin Juszkiewicz &lt;marcin.juszkiewicz@linaro.org&gt;
Reviewed-by: Leif Lindholm &lt;quic_llindhol@quicinc.com&gt;
Message-id: 20240607103825.1295328-2-xiongyining1480@phytium.com.cn
Tested-by: Marcin Juszkiewicz &lt;marcin.juszkiewicz@linaro.org&gt;
Signed-off-by: Peter Maydell &lt;peter.maydell@linaro.org&gt;
</content>
</entry>
<entry>
<title>hw/arm/virt: allow creation of a second NonSecure UART</title>
<updated>2024-06-21T13:01:59Z</updated>
<author>
<name>Peter Maydell</name>
<email>peter.maydell@linaro.org</email>
</author>
<published>2024-06-10T16:23:43Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/qemu/commit/?id=e7100972f2df313d1e47a0714aed968991437e86'/>
<id>urn:sha1:e7100972f2df313d1e47a0714aed968991437e86</id>
<content type='text'>
For some use-cases, it is helpful to have more than one UART
available to the guest.  If the second UART slot is not already used
for a TrustZone Secure-World-only UART, create it as a NonSecure UART
only when the user provides a serial backend (e.g.  via a second
-serial command line option).

This avoids problems where existing guest software only expects a
single UART, and gets confused by the second UART in the DTB.  The
major example of this is older EDK2 firmware, which will send the
GRUB bootloader output to UART1 and the guest serial output to UART0.
Users who want to use both UARTs with a guest setup including EDK2
are advised to update to EDK2 release edk2-stable202311 or newer.
(The prebuilt EDK2 blobs QEMU upstream provides are new enough.)
The relevant EDK2 changes are the ones described here:
https://bugzilla.tianocore.org/show_bug.cgi?id=4577

Inspired-by: Axel Heider &lt;axel.heider@hensoldt.net&gt;
Signed-off-by: Peter Maydell &lt;peter.maydell@linaro.org&gt;
Tested-by: Laszlo Ersek &lt;lersek@redhat.com&gt;
Reviewed-by: Philippe Mathieu-Daudé &lt;philmd@linaro.org&gt;
Message-id: 20240610162343.2131524-4-peter.maydell@linaro.org
</content>
</entry>
<entry>
<title>docs:aspeed: Add AST2700 Evaluation board</title>
<updated>2024-06-16T19:08:54Z</updated>
<author>
<name>Jamin Lin</name>
<email>jamin_lin@aspeedtech.com</email>
</author>
<published>2024-06-04T05:44:38Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/qemu/commit/?id=b3e8223e48f4a8981232a17ebf48c198829ce191'/>
<id>urn:sha1:b3e8223e48f4a8981232a17ebf48c198829ce191</id>
<content type='text'>
Add AST2700 Evaluation board and its boot command.

Signed-off-by: Troy Lee &lt;troy_lee@aspeedtech.com&gt;
Signed-off-by: Jamin Lin &lt;jamin_lin@aspeedtech.com&gt;
Reviewed-by: Cédric Le Goater &lt;clg@kaod.org&gt;
</content>
</entry>
<entry>
<title>target/arm: Implement FEAT WFxT and enable for '-cpu max'</title>
<updated>2024-05-30T15:35:17Z</updated>
<author>
<name>Peter Maydell</name>
<email>peter.maydell@linaro.org</email>
</author>
<published>2024-04-30T14:00:35Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/qemu/commit/?id=a96edb687e76a44b554b7975d9deda522c2c4302'/>
<id>urn:sha1:a96edb687e76a44b554b7975d9deda522c2c4302</id>
<content type='text'>
FEAT_WFxT introduces new instructions WFIT and WFET, which are like
the existing WFI and WFE but allow the guest to pass a timeout value
in a register.  The instructions will wait for an interrupt/event as
usual, but will also stop waiting when the value of CNTVCT_EL0 is
greater than or equal to the specified timeout value.

We implement WFIT by setting up a timer to expire at the right
point; when the timer expires it sets the EXITTB interrupt, which
will cause the CPU to leave the halted state. If we come out of
halt for some other reason, we unset the pending timer.

We implement WFET as a nop, which is architecturally permitted and
matches the way we currently make WFE a nop.

Signed-off-by: Peter Maydell &lt;peter.maydell@linaro.org&gt;
Reviewed-by: Richard Henderson &lt;richard.henderson@linaro.org&gt;
Message-id: 20240430140035.3889879-3-peter.maydell@linaro.org
</content>
</entry>
<entry>
<title>docs/system: Remove ADC from raspi documentation</title>
<updated>2024-05-28T13:20:48Z</updated>
<author>
<name>Rayhan Faizel</name>
<email>rayhan.faizel@gmail.com</email>
</author>
<published>2024-05-23T15:06:21Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/qemu/commit/?id=2fda0e776ae5360910f3521ec2608b535f338d90'/>
<id>urn:sha1:2fda0e776ae5360910f3521ec2608b535f338d90</id>
<content type='text'>
None of the RPi boards have ADC on-board. In real life, an external ADC chip
is required to operate on analog signals.

Signed-off-by: Rayhan Faizel &lt;rayhan.faizel@gmail.com&gt;
Reviewed-by: Philippe Mathieu-Daudé &lt;philmd@linaro.org&gt;
Message-id: 20240512085716.222326-1-rayhan.faizel@gmail.com
Signed-off-by: Peter Maydell &lt;peter.maydell@linaro.org&gt;
</content>
</entry>
<entry>
<title>hw/display : Add device DM163</title>
<updated>2024-04-30T15:02:43Z</updated>
<author>
<name>Inès Varhol</name>
<email>ines.varhol@telecom-paris.fr</email>
</author>
<published>2024-04-24T20:06:51Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/qemu/commit/?id=c771f883f2e6db3acd7cbed0fde273bfc6cc580e'/>
<id>urn:sha1:c771f883f2e6db3acd7cbed0fde273bfc6cc580e</id>
<content type='text'>
This device implements the IM120417002 colors shield v1.1 for Arduino
(which relies on the DM163 8x3-channel led driving logic) and features
a simple display of an 8x8 RGB matrix. The columns of the matrix are
driven by the DM163 and the rows are driven externally.

Acked-by: Alistair Francis &lt;alistair.francis@wdc.com&gt;
Signed-off-by: Arnaud Minier &lt;arnaud.minier@telecom-paris.fr&gt;
Signed-off-by: Inès Varhol &lt;ines.varhol@telecom-paris.fr&gt;
Reviewed-by: Philippe Mathieu-Daudé &lt;philmd@linaro.org&gt;
Message-id: 20240424200929.240921-2-ines.varhol@telecom-paris.fr
[PMM: updated to new reset hold method prototype]
Signed-off-by: Peter Maydell &lt;peter.maydell@linaro.org&gt;
</content>
</entry>
<entry>
<title>target/arm: Enable FEAT_Spec_FPACC for -cpu max</title>
<updated>2024-04-30T14:01:07Z</updated>
<author>
<name>Peter Maydell</name>
<email>peter.maydell@linaro.org</email>
</author>
<published>2024-04-18T15:20:04Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/qemu/commit/?id=663163f00785805e61f524ef744914029b2b6a87'/>
<id>urn:sha1:663163f00785805e61f524ef744914029b2b6a87</id>
<content type='text'>
FEAT_Spec_FPACC is a feature describing speculative behaviour in the
event of a PAC authontication failure when FEAT_FPACCOMBINE is
implemented.  FEAT_Spec_FPACC means that the speculative use of
pointers processed by a PAC Authentication is not materially
different in terms of the impact on cached microarchitectural state
(caches, TLBs, etc) between passing and failing of the PAC
Authentication.

QEMU doesn't do speculative execution, so we can advertise
this feature.

Signed-off-by: Peter Maydell &lt;peter.maydell@linaro.org&gt;
Reviewed-by: Richard Henderson &lt;richard.henderson@linaro.org&gt;
Reviewed-by: Philippe Mathieu-Daudé &lt;philmd@linaro.org&gt;
Message-id: 20240418152004.2106516-6-peter.maydell@linaro.org
</content>
</entry>
</feed>
