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

[Julien Grall <julien.grall@xxxxxxx>]

Hi Ian,

On 10/31/18 2:44 PM, Ian Jackson wrote:
> 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.
I don't have the knowledge to help on the Debian side, but I am happy to 
help testing the series on Thunder-X.
> > > +   + 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 ?
This sounds good to me.

> > > + * 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 ?
U-boot and Grub provides a  way to load a different device-tree. Looking 
at the osstest logs, we already use it on U-boot.
For Grub, we rely on the DT provided by the firmware.

What I want to make sure is the DT can be loaded and be updated (i.e 
adding more nodes) via U-boot command line. Although, IHMO, that would 
be a broken firmware...
> 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.)
Device Tree are already board specific. Even worst, some of them are 
even depending on the version of the kernel. We should have some runes 
today to deal with that.
Cheers,

--
Julien Grall

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