From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57946) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sr9yb-0004ed-GJ for qemu-devel@nongnu.org; Tue, 17 Jul 2012 11:46:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sr9yX-0001CU-Fp for qemu-devel@nongnu.org; Tue, 17 Jul 2012 11:46:17 -0400 Received: from moutng.kundenserver.de ([212.227.17.10]:60831) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sr9yX-0001CL-4u for qemu-devel@nongnu.org; Tue, 17 Jul 2012 11:46:13 -0400 Received: from localhost (localhost [127.0.0.1]) by mailbox.adnet.avionic-design.de (Postfix) with ESMTP id 79F592A2830D for ; Tue, 17 Jul 2012 17:46:11 +0200 (CEST) Received: from mailbox.adnet.avionic-design.de ([127.0.0.1]) by localhost (mailbox.avionic-design.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5BAMtrgAo0C for ; Tue, 17 Jul 2012 17:46:10 +0200 (CEST) Received: from localhost (avionic-0098.adnet.avionic-design.de [172.20.31.233]) (Authenticated sender: thierry.reding) by mailbox.adnet.avionic-design.de (Postfix) with ESMTPA id 9A3852A280E2 for ; Tue, 17 Jul 2012 17:46:10 +0200 (CEST) Date: Tue, 17 Jul 2012 17:46:09 +0200 From: Thierry Reding Message-ID: <20120717154609.GA16640@avionic-0098.mockup.avionic-design.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline Subject: [Qemu-devel] Keeping a secondary CPU in reset List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 --azLHFNyN32YCQGCU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJQBYjBAAoJEN0jrNd/PrOhny4P/2MVSut8EUvwXmqWWpiJ8vXM /NkHvWVQeDnFdlthua4eBmYCrkWs0PrTo9nozWqznyKAXellsb0y2/mcGKgQWSMN NPs4azIgv5L0ckZTyoxXd2eZ4H+mDFwxRBznU+GdgsEAh6lnkhIIuHzo1iYx/NEA M5yhzDDsH6GWPF9B+bzW2oiugVgPouLGUhwA8ViEphXumwgExL7J6jTQAcaVjJfv V9CJ//RRHDc/thosLg56AYTZ4m5614b8XwwYtwatzZMfn8UDe1qORHbU7gBZbXec X6yQnVFMZHqSBsauJBTUTmDkjDX1FS4vGE8eGIzlZ/LuHORuX4c7sjKKrDF0xNR6 ovJFTnzRiRaGk+NIEJhx3VSPfdRY5hnOgMMezR/+XDUPAxFlxoSR61Hk/cLLxwRk F95hrJEwuh+0dfvoicOSP4L5uL3/TSi2hO42/Vih7D43mdLGOlP6WpB1H/FRX1RY BRU56WJjRcc2Q0h57j6fj9IcFTrARRPm0kVc3Z+rr6rkUGxdR1gtFQ6P32RRkpDX 8qfyiRgqKQLrpST/j3/xcrnGGAnaBW+gQM57cX8akGYzr+NjZ2vnPrkf4YEGL9+O m4o36m0qz52CuyUa7LEq0/WCvzra3z2Eufx+T/VNilHVMaTO6XJN2yneh+4JCOHn 0wZFfWPVvvXjMP6kQXAQ =WHIw -----END PGP SIGNATURE----- --azLHFNyN32YCQGCU--