[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |