Re: [OSSTEST PATCH] README.hardware-acquisition

[Stefano Stabellini <stefano.stabellini@xilinx.com>]

On Tue, 30 Oct 2018, Julien Grall wrote:
> Hi Ian,
> 
> On 10/30/18 4:13 PM, Ian Jackson wrote:
> > +Compatibility with Xen and Linux - requirements
> > +-----------------------------------------------
> > +
> > +(Normally these issues are not a problem for x86, except perhaps for
> > +the network and storage controllers - see MASS STORAGE and NETWORKING,
> > +above.)
> > +
> > + * [1] Xen: The CPU and other hardware must be supported by current
> > +   versions of xen-unstable, at the very least.
> > +
> > + * [2] Linux: The CPU and other hardware must be supported by existing
> > +   widely available versions of Linux.  There are two principal
> > +   requirements:
> > +
> > +   + Baremetal boot from Debian stable or stable-backports:
> > +
> > +     A suitable Linux kernel binary which can boot baremetal on the
> > +     proposed hardware must be available from Debian (at least
> > +     `stable', or, if that is not possible `stable-backports').  It is
> > +     not OK to require a patched version of Linux, or a version of
> > +     Linux built from a particular git branch, or some such.  If the
> > +     required kernel is not available in Debian, the vendor should
> > +     first work with the Debian project to ensure and validate that
> > +     the Debian stable-backports kernel binaries boot on the proposed
> > +     hardware.
> 
> While I understand this point, I think this is going to limit us a lot on the
> choice of hardware for Arm. While Debian is quite famous on the Server world,
> this is less the case on the automotive/embedded world where they tend to have
> there custom distribution.

That's right, it's a Yocto world around here. That's also what EPAM
uses.


> Most of the time, the issue to boot Debian is related to the kernel. Yet, the
> price might be too high for some of the vendors to donate the hardware.
> Furthermore, at the moment Osstest is stuck on Jessie. This version does not
> support Thunder-X (stealing power and heating data for the past year and
> half...) and hardwares that will be donated in the next few months (i.e
> Renesas R-Car, and Xilinx MPSoc).
>
> I still want to encourage vendor to work upstream but I would relax the
> requirements here to "Xen Arm kernel branch".

+1

Xilinx MPSoC support is upstream in vanilla Linux (defconfig), and the
MPSoC is fully supported in Yocto. We did issue a ticket in the Debian
system to add support for the Xilinx MPSoC in their kernel but is hasn't
happened yet. (The fact that Debian support hasn't come up as an issue
up until now tells us that embedded folks tend to use other distros.)

In general, I think vanilla Linux kernel support would be a rather
strict requirement for many embedded boards (especially the sub 100$
ones), but it would still be better than asking for Debian kernel
support.

Overall, Julien's suggestion to require "Xen Arm kernel branch" is best.



> > +
> > +   + Boot under Xen with Linux kernel built from source code.
> > +
> > +     For x86, recent Linux LTS or mainline kernel source code must be
> > +     able to boot under Xen, on the proposed hardware.
> > +
> > +     For ARM, there is a special Xen ARM kernel branch.  It must be
> > +     able to boot under Xen, on the proposed hardware.
> 
> I still want to keep that branch very close to Linux upstream. So it might be
> worth to say we have the liberty to not accept there patch...
> 
> > +
> > + * Board-specific Linux and Xen versions are not acceptable.
> 
> ... That will avoid a vendor to try to workaround this by asking to merge
> hundreds of patch in "Xen Arm kernel" branch.

Yes, good idea. We don't want to deviate the "Xen Arm kernel" branch
significantly.


> > +
> > + * Hardware vendor offering a "board support package" is a red flag.
> > +   We will not be using a "board support package".  If we are offered
> > +   one we will need explicit confirmation, and perhaps verification,
> > +   of the points above.
> > +
> > + * For ARM systems using Device Tree: xxx what to write here ?
> IIRC we are using the DT from the Linux tree. This was to workaround broken
> backward compatibility on the cubieboard. Am I correct?
> 
> I would write: "The firmware should provide a Device-Tree working for all
> version of Linux or provide a mechanisms to load a different Device-Tree at
> boot."

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel