[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

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
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

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...



Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.