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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.