From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60489) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z80oP-0006Tk-Cg for qemu-devel@nongnu.org; Thu, 25 Jun 2015 02:39:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z80oL-0000ht-B9 for qemu-devel@nongnu.org; Thu, 25 Jun 2015 02:39:01 -0400 Received: from mail-wi0-f173.google.com ([209.85.212.173]:36607) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z80oL-0000hW-4q for qemu-devel@nongnu.org; Thu, 25 Jun 2015 02:38:57 -0400 Received: by wicnd19 with SMTP id nd19so154392702wic.1 for ; Wed, 24 Jun 2015 23:38:56 -0700 (PDT) References: <871th1ysa8.fsf@linaro.org> From: Alex =?utf-8?Q?Benn=C3=A9e?= In-reply-to: Date: Thu, 25 Jun 2015 07:39:36 +0100 Message-ID: <87lhf8xpef.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] TCG baremetal tests repo List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: mttcg@listserver.greensocs.com, Alexander Spyridakis , Mark Burton , Alvise Rigo , QEMU Developers , KONRAD =?utf-8?B?RnLDqWTDqXJpYw==?= Peter Maydell writes: > On 24 June 2015 at 17:39, Alex Bennée wrote: >> >> Alexander Spyridakis writes: >>> You can find the latest tcg atomic test payload in the following repo: >>>> git clone https://git.virtualopensystems.com/dev/tcg_baremetal_tests.git >>> >>> You also need an arm baremetal cross-compiler like arm-none-gnueabi- (arm) >>> and the usual aarch64-linux-gnu- (arm64). Due to a PSCI bug in the current >>> multithreading tcg repo, the atomic test was modified to work also on the >>> vexpress machine model. >> >> I sent a patch to fix the PSCI hang case to wake up the sleeping CPU. I >> couldn't figure out how the vexpress code was waking it's CPUs. Do they >> just start powered on? > > Yes -- our vexpress model is "like hardware", so all CPUs leap into > the boot firmware at once, and the firmware deals with putting the > secondaries into a pen to be released in a controlled manner later. > [assuming you're not using -kernel; if you are then boot.c has the > secondary pen code] Ahh good. No mystery to solve then ;-) -- Alex Bennée