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

[Ian Jackson <ian.jackson@xxxxxxxxxx>]

I'm going to reply to this email twice.  This email is about what seem
to be the noncontentious issues: everything *except* the requirement
in my document that the board is supported by Debian -backports
kernels, at least.


Julien Grall writes ("Re: [OSSTEST PATCH] README.hardware-acquisition"):
>   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).

This is indeed a serious nuisance and is getting quite high on my
priority list.


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

My wording was unclear.  I should have written something like this:

       For ARM, there is a special Xen ARM kernel branch. The proposed
       hardware must be able to boot that version of Linux under Xen.

       If the Xen ARM Linux branch does not support the proposed
       hardware yet, the hardware should not be accepted until that is
       remedied.  Where this involves adding kernel patches to that
       branch this is subject to the approval of its maintainers,
       considering the need to keep it very close to upstream.

What do you think ?


> > + * 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 looked at mg-debian-installer-update.  It seems that where we use a
Debian -backports kernel we are using the dt from the backports kernel
package.

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

I take it that if a vendor comes up with a novel "mechanisms to load a
different Device-Tree at boot" the work to teach osstest about it will
be simple ?

But, I was more concerned about the possible need for a board-specific
device tree file.  Is that likely ?  There doesn't seem to be any code
in osstest right now to handle such a thing.  (I say `doesn't seem'
because it wasn't me that did the osstest ARM support.)


Thanks,
Ian.

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