From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:58071) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RnX4g-0000so-0r for qemu-devel@nongnu.org; Wed, 18 Jan 2012 10:05:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RnX4a-0003vj-5k for qemu-devel@nongnu.org; Wed, 18 Jan 2012 10:05:17 -0500 Received: from smtp121.dfw.emailsrvr.com ([67.192.241.121]:42620) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RnX4Z-0003vd-VE for qemu-devel@nongnu.org; Wed, 18 Jan 2012 10:05:12 -0500 Message-ID: <4F16DF93.5070709@calxeda.com> Date: Wed, 18 Jan 2012 09:04:51 -0600 From: Mark Langsdorf MIME-Version: 1.0 References: <1326213943-878-1-git-send-email-mark.langsdorf@calxeda.com> <1326808231-32545-1-git-send-email-mark.langsdorf@calxeda.com> <1326808231-32545-5-git-send-email-mark.langsdorf@calxeda.com> <4F16D8AA.6020307@calxeda.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v10 4/5] arm: SoC model for Calxeda Highbank List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: "i.mitsyanko@gmail.com" , "edgar.iglesias@gmail.com" , "qemu-devel@nongnu.org" , Rob Herring , "afaerber@suse.de" On 01/18/2012 08:53 AM, Peter Maydell wrote: > On 18 January 2012 14:35, Mark Langsdorf wrote: >> Is there a good example of how to write secondary smp boot >> code other than arm_boot.c? Should I just expect to pull >> most of arm_boot.c into highbank and adjust from there? I >> don't want to duplicate code like that, but I need more >> flexibility than I can easily add to arm_boot.c. > > Nope, I'm afraid you're the first one to run into this. > arm_boot.c started off as just implementing the realview > secondary boot protocol, and exynos4 and vexpress have > been close enough to piggyback on it. So highbank is the > first board that's different enough to need its own code. > > A big chunk of arm_boot.c is the primary CPU boot code, > which should be standard for all arm platforms, so that > shouldn't need to change. So we just need a reasonably > clean solution for a platform to provide its own secondary > boot code. I'm vaguely thinking about providing a hook > function for 'write secondary boot code' and one for > 'post-cpu-reset hook for secondary cpus', which would go > in the "if (info->nb_cpus > 1) {...}" condition in > arm_load_kernel() and in the else-clause of "if (env == > first_cpu) in do_cpu_reset(). > > Can you try something along those lines? I think so. I was worried about accessing some of the arm_boot static variables but it doesn't look like I'll need to do that. I'll do a quick refactor RFC of arm_boot.c and then get into the gory bits of getting something to work for Highbank. --Mark Langsdorf Calxeda, Inc.