[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 Mon, 2013-08-19 at 10:46 -0700, Christoffer Dall wrote:
> FWIW, I second Andre's position; the boot-wrapper was simply a hack
> before we had any proper bootloader support (like U-boot) on development
> boards like the versatile express and it has been (ab)used for models as
> well.  I'm not sure if boot-wrapper could be completely abandoned at
> this point or if it is still needed for some cases (models, big.little,
> ...).  But surely anything we can reasonably do to leverage existing
> U-boot work and do things the proper way will set the right example for
> users and other implementors.

I absolutely agree, as I said to Andre the use of bootwrapper should be
an absolute last resort. I'd be more than happy to reject bootwrapper
patches for platforms which do this stuff properly. Or if I get told
"platform A has been fixed, here is how to run Xen on it without
bootwrapper" then I will delete support for platform A in a microsecond.
If this turns out to be all the platforms then even better.

> The latter perspective is especially important for Linaro as the whole
> point of the organization is to work upstream and make things work
> across many platforms.

I'm not really worried about the Linaro Supported platforms, you guys
are clearly doing the right things and getting fixed u-boot etc into
upstreams and as I've said this is my preference for supporting Xen too.

However I would like Xen to support a wider variety of platforms than
that, in particular the super el-cheapo boards like the cubieboard2,
popular hobbyist platforms like the pandaboard and random consumer
hardware (e.g. the MELE android set top boxes have Cortex-A7s in them).
Having something easily available for reasonably low prices is important
for the hobbyist/non-commercially supported developer segment IMHO. 

The vendors of those sort of boards don't always work so closely with
upstreams, so getting a u-boot which does hyp mode, or even one where
Andre's patches can be backported is not necessarily always going to be
possible. Likewise many of these systems don't have easy access to JTAG
or some fallback when reflashing u-boot goes wrong, or the hobbyists
don't have JTAG hardware etc. Under those circumstances people are
understandably reticent to reflash their bootloader.

cubieboard2 is not really a good example here, since the linux-sunxi
community have taken up the baton and upstream u-boot support is pretty
good and the hardware is pretty much unbrickable due to the FEL mode
fallback.

Perhaps the panda5 is a better example -- I don't know how good upstream
u-boot, but AFAIK the platform is no longer supported by the vendor.
Chen, a hobbyist, was posting patches to add more stuff to
mode_switch.S. I don't think it is reasonable to ask him to go and get
panda5 support into upstream u-boot. So I started hacking on bootwrapper
mainly to give him somewhere he could put his boot time hacks which was
outside the Xen source tree and which prevented the addition of new
hacks Xen's mode_switch.S.

Ultimately what I really care about is deleting mode_switch.S from Xen,
it is a hack with no place in the Xen tree. bootwrapper is also a hack
but it's not in the Xen tree.

Ian.


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


 


Rackspace

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