Re: [Xen-devel] xen: arm: beginning the removal of mode_switch.S

[Julien Grall <julien.grall@xxxxxxxxxx>]

On 08/15/2013 09:51 PM, Ian Campbell wrote:
> On Thu, 2013-08-15 at 18:05 +0100, Julien Grall wrote:
>> Adding Andre.
> 
> 
> I think Andre's platform should be able to avoid bootwrapper completely,
> they do sensible things with cpu bringup, boot in NS HYP mode with
> everything setup sensibly etc. This is the ideal situation of course,
> with bootwrapper just being a last resort type thing.
> 
>> On 08/15/2013 12:51 PM, Ian Campbell wrote:
>>> I did some hacking on boot-wrapper.git on the train to debconf and made
>>> it support building a zImage container encapsulating Xen+Linux+initramfs
>>> +fdt. Xen is optional so it can be used to boot natively too.
>>>
>>> You can find the code in the multiplatform branch of
>>> http://xenbits.xen.org/gitweb/?p=people/ianc/boot-wrapper.git
>>>
>>> It has build time (Kconfig driven) options to support:
>>>       * cubieboard2 (boots native ok, weird issue under Xen)
>>>       * arndale (code taken from existing mode switch.S, untested)
>>>       * vexpress and fastmodel (untested)
>>>
>>> The code is pretty hacked up from the original (which only really
>>> supported fastmodels, and had limited configurability) and it could
>>> certainly be structured to be quite a bit cleaner (plus I think I got a
>>> bit carried away with using Kconfig for everything). I'd rather have
>>> some skanky hacked up code here than in Xen though, so I think this is
>>> an acceptable level of hackedupness. 
>>>
>>> At the moment it is sufficient to allow us to do away with the
>>> enter_hyp_mode bits and the clock frequency, gic setup etc, along the
>>> lines of the patch below.
>>>
>>> It doesn't yet allow us to get rid of the kick_cpus stuff. My plan for
>>> platforms which don't do the right thing here would be to add a
>>> mechanism to use dtb /memreserve/ (and teach Xen about that construct)
>>> to carve out a little bit of memory which secondary CPUs could safely be
>>> left spinning in. The platform code would expose its normal interface
>>> (e.g. SYS_FLAGS on vexpress and fastmodel), eventually maybe we'd do
>>> PSCI too (which might let us skip reserving some memory since 2ndary
>>> cpus would be in secure mode and could use the special ram regions
>>> reserved for that)
>>>
>>> I might have time for this on the train on the way home, but since my
>>> cubieboard2 can't do SMP yet (even on native Linux, bringup looks
>>> complex) I suppose that means I need to test and debug the fastmodel
>>> support first...
>>>
>>> As we add new platforms I think we should first push back on the vendors
>>> to fix their firmware but when that turns out to not be possible we
>>> should move to patching this code with platform hacks instead of adding
>>> more stuff to mode_switch.S, IMO the only blocker to this is the
>>> kick_cpu support.
>>>
>>> What does everyone think?
>>
>> I'm not sure it's related... does this patch series
>> (https://lists.cs.columbia.edu/pipermail/kvmarm/2013-April/005581.html)
>> can avoid the bootwrapper code?
> 
> Yes, in cases where users can update u-boot or where vendors are
> motivated to ship a system which works properly. Bootwrapper is only a
> workaround for cases where this isn't possible
> 
> It is my intention that bootwrapper become a thing which you expect to
> have to use with Xen always -- we should always strive to make the
> firmware Just Work and only fallback to bootwrapper  where that isn't
> possible for some reason.

Thanks for your answer !
The bootwrapper can be avoid for the Arndale. I have noticed that if
kick cpus is moved later, the secondary cpu will boot in HYP mode.

Otherwise I will give a try to the bootwrapper on the Versatile Express.

Cheers,


-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel