Re: xen: arm: beginning the removal of mode_switch.S

[Andre Przywara <andre.przywara@linaro.org>]

On 08/16/2013 05:04 PM, Ian Campbell wrote:
> On Fri, 2013-08-16 at 11:12 +0100, Julien Grall wrote:
>> 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.
>
> Excellent, so you are going to send a patch to nuke the relevant bits of
> mode_switch.S?
>
>> Otherwise I will give a try to the bootwrapper on the Versatile Express.
>
> Andre seemed to suggest he had fixed (or was fixing) vexpress's u-boot
> too, which only really leaves the models. I'd love to be able to run
> u-boot there too simply for consistency...

I managed to start Xen on the VExpress via my HYP-u-boot before. Only 
today I couldn't reproduce it with the latest bits...
Will see if I find the culprit.

> I'd be happy if bootwrapper died before it even left the starting
> line ;-) So long as we can nuke mode_switch.S...

ACK!

Andre.