From: "Andreas Färber" <afaerber@suse.de>
To: Thierry Reding <thierry.reding@avionic-design.de>
Cc: Vincent Palatin <vpalatin@chromium.org>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Keeping a secondary CPU in reset
Date: Thu, 19 Jul 2012 16:32:20 +0200 [thread overview]
Message-ID: <50081A74.2050102@suse.de> (raw)
In-Reply-To: <20120717154609.GA16640@avionic-0098.mockup.avionic-design.de>
-----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-----
next prev parent reply other threads:[~2012-07-19 14:32 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-17 15:46 [Qemu-devel] Keeping a secondary CPU in reset Thierry Reding
2012-07-19 14:32 ` Andreas Färber [this message]
-- strict thread matches above, loose matches on Subject: below --
2012-07-17 5:15 Thierry Reding
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=50081A74.2050102@suse.de \
--to=afaerber@suse.de \
--cc=qemu-devel@nongnu.org \
--cc=thierry.reding@avionic-design.de \
--cc=vpalatin@chromium.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).