[Qemu-devel] Keeping a secondary CPU in reset

[Qemu-devel] Keeping a secondary CPU in reset

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 912 bytes --]

Hi,

I've been toying around with adding NVIDIA Tegra support to QEMU. While
adding SMP support I came across a problem: on Tegra, the secondary CPU
is kept in reset by the clock-and-reset controller (CRC). When bringing
up the secondary CPU, the OS writes a given register in the CRC to
release the CPU, after which it starts running. Other hardware blocks
can also be reset by writing other registers in the CRC.

QEMU however seems to assume that all CPUs can immediately be run, so I
solved this by providing some SMP boot code that basically just executes
the wfi (wait for interrupt) instruction and raise an interrupt after
the CRC register has been written to emulate this behaviour. This is at
best kludgy, so I wonder if QEMU provides functionality that I could use
to model this properly. I didn't find any, so I wonder if it might be a
good idea to add some kind of generic reset framework.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [Qemu-devel] Keeping a secondary CPU in reset

[Andreas Färber]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Thierry,

Am 17.07.2012 17:46, schrieb Thierry Reding:
> I've been toying around with adding NVIDIA Tegra support to QEMU.
> While adding SMP support I came across a problem: on Tegra, the
> secondary CPU is kept in reset by the clock-and-reset controller
> (CRC). When bringing up the secondary CPU, the OS writes a given
> register in the CRC to release the CPU, after which it starts
> running. Other hardware blocks can also be reset by writing other
> registers in the CRC.
[snip]

Please take a look at the Tegra feature page on the Wiki, which has a
link to my repository where I've been rebasing an older series by
Vincent Palatin.

http://wiki.qemu.org/Features/Tegra2

It does not use the generic arm_boot iirc but its own implementation.
There's a tegra_clocks device that probably corresponds to the CRC.

What's still missing on my branch is the actual machine that
instantiates the devices I've been working on.
A big TODO where I could use some help is refactoring EHCI so that we
can have the current PCIDevice plus a new SysBus device (or
DeviceState?) for Tegra.

Regards,
Andreas

- -- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iQIcBAEBAgAGBQJQCBp0AAoJEPou0S0+fgE/xkUP/RK5/0Ye7Bsd7yx0Q9cTATUz
wgdN2amH52Fbq2UG8kqokyp3u+ohkz4hyAdMCXPimQzkCdIjPUx9Smi+q++1auD1
CCMkDwpgrFgECglkixa5FVS9mokpJDVhLMt5QPlduHEa9/I1e59wbh2eDPpnSOoz
Ddh+0ZwcR9cHe+h9Xsgf7qmWKyUetKqQw5MLxukfSf7tnzUWrMn7cbZud7W3HlQR
XVSr8iGWf4zkD9nX43IbrQOR4W8n+Wk1w95yiIq59uq2Zei96YJhL9ZUvqVIQ3m2
GF4S0K3Y8Qjd6JVpRUv53mTTjEz5+FTqVz8Q538QJ+zhJ+z3lAqGx6XObk8bqoX7
Ojl2GjUL8W4Gddtu8OrKoECkkixuLhgmQ/ScCLSoSVSY+8hhQ88fcx3aWxK+nSpQ
RVsUqR9bds995W+yb4rI8NfbcSD/x4ucrsDhBKKoIUnT663VuGGxXJVu9K8ATC8Z
46ZFDh2zrPPoucGzHBC6Nm/SygTX7cmDUf7pHTI4Uzc9uTnPLVzHg7+JfH0nyNvJ
Zm/DcfWiToauIf5CQq4X5chAFtRBzeP0FntwhD1hWYaOzgUe5DwIKGZljchO7lH3
2SJDiUBz9wSy7hqurFKF7lFCIlenR5BADRMGvAKdQ0IX1P/vUNC+bI30jyz8P777
hGbTENc9RYXFtjwNV6b0
=Bojw
-----END PGP SIGNATURE-----

[Qemu-devel] Keeping a secondary CPU in reset

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 912 bytes --]

Hi,

I've been toying around with adding NVIDIA Tegra support to QEMU. While
adding SMP support I came across a problem: on Tegra, the secondary CPU
is kept in reset by the clock-and-reset controller (CRC). When bringing
up the secondary CPU, the OS writes a given register in the CRC to
release the CPU, after which it starts running. Other hardware blocks
can also be reset by writing other registers in the CRC.

QEMU however seems to assume that all CPUs can immediately be run, so I
solved this by providing some SMP boot code that basically just executes
the wfi (wait for interrupt) instruction and raise an interrupt after
the CRC register has been written to emulate this behaviour. This is at
best kludgy, so I wonder if QEMU provides functionality that I could use
to model this properly. I didn't find any, so I wonder if it might be a
good idea to add some kind of generic reset framework.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]