Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition

[Julien Grall <julien.grall@xxxxxxx>]

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.
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".
> +
> +   + 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.
> +
> + * 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."
Cheers,

--
Julien Grall

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