[Pkg-Mali-devel] Debian mali pckaging status

Wed Jul 18 12:08:04 BST 2018

Hi Guillaume,

On Wed, 18 Jul 2018 at 12:57, Guillaume Tucker
<guillaume.tucker at collabora.com> wrote:
>
> Hi Sumit,
>
> On 18/07/18 05:26, Sumit Garg wrote:
> > Hi Wookey,
> >
> > On Tue, 3 Jul 2018 at 11:15, Sumit Garg <sumit.garg at linaro.org> wrote:
> >>
> >> On Thu, 28 Jun 2018 at 21:54, Wookey <wookey at wookware.org> wrote:
> >>>
> >>> OK. Welcome to the (currently quite exclusive) list :-)
> >>>
> >>> Let's start with the current status and what needs doing next.
> >>>
> >>> We have
> >>>   * a midgard dkms kernel package (r16-midgard): mali-midgard
> >>>   * a midgard binary package (r16-midgard): mali-midgard-driver
> >>> Both in debian
> >>>   * a bifrost binary package (r9-bifrost): mali-bifrost-driver
> >>>   (only in git):
> >>>
> >>>   * utgard is not really catered for, but there is nothing stopping us
> >>>     packing up the mali 400 (From freeelectons/allwinner) and 450 (from
> >>>     arm) driver, and making a suitbaly vintage mali-utgard kernel driver
> >>>     (but probably with a load of patches to make it build on current kernels)
> >>>     In fact I have a mali-utgard-driver package (for 450 only) I made ages ago.
> >>>     I should check that in so we can make it match the others.
> >>>
> >>> Wiki pages:
> >>> https://wiki.debian.org/MaliGraphics
> >>> https://wiki.debian.org/MaliMidgard
> >>>
> >>> Looks like r16-midgard is the same release as r4-bifrost.
> >>>
> >>> The r16-midgard dkms package now builds on armhf (firefly) and arm64
> >>> (hilkey960), but does not build for me on arm64 (softiron) due to a
> >>> mysterious tool exec-format error. I'll mail about that separately.
> >>>
> >>> Sumit reports that the r9-bifrost userspace driver does not run on the
> >>> r16-midgard/r4-bifrost kernel driver: it needs a newer one. That makes sense.
> >>>
> >>> Because the midagard and bifrost kernel drivers are the same, and the
> >>> release team tell me they expect that to remain true, it would make
> >>> sense to use this for both midagard and bifrost. However, we can only
> >>> do that by moving all the packages forward to much newer versions, and
> >>> if we do that we lose X support. And all our actual/likely users use X
> >>> so that's a massive pain.
> >>>
> >>> Thus I propose that we upload a separate mali-bifrost (dkms) package
> >>> (which conflicts with the midgard one) with a current version of the
> >>> kernel driver. That should work with the mali-bifrost-driver userspace
> >>>
> >>> This way we can support current X midgard users for a while (next
> >>> debian stable release?) but also support newer userspace drivers.
> >>>
> >>> I guess if we are doing this the package-names are actually rather
> >>> unhelpful, and the new one should be called something to indicate that
> >>> it is newer, rather than specifically for bifrost. mali-current?
> >>>
> >>> This is all quite crap, but I don't have any better ideas for having
> >>> something vaguely useful in the distro.
> >>>
> >>> What do you think? Is this a sensible plan? Any better ideas?
> >>>
> >>> Sumit - can you update us on the current state of upstream DTB info for hikey960.
> >>
> >> Currently we don't have GPU node added in upstream DTB for hikey960. I
> >> am trying to work out with internal team to get patch [1] related to
> >> GPU node in upstream.
> >>
> >> [1] https://github.com/96boards-hikey/linux/commit/65f19abf8b64cd4a9ad7b3da723b5c84cc07163b
> >>
> >
> > We have added support for GPU node in DTB present in EDK2 [1]. With
> > this updated EDK2 firmware, I am able to run r12-bitfrost kernel
> > driver (out-of-tree) with out-of-box Debian on hikey960. So I think we
> > can move forward with mali-bitfrost-driver packaging in Debian.
>
> This device tree node is not in the upstream kernel.  It needs to
> be there in order to make a Debian package, as the Debian kernel
> is based on upstream stable kernels.  Otherwise, the .dtb file
> will not be part of the Debian packages.
>

In case of hikey960, .dtb is part of edk2 (UEFI) firmware. I don't
think we need to have it in Debian packages.

> The first thing that needs to be done in order to upstream this
> node is to add a new binding for mali-bifrost, which at the
> moment essentially is the same as mali-midgard but being a
> different architecture it needs a different binding upstream (to
> be confirmed by Rob Herring & Co, but at least that's my
> understanding).  Then upstreaming this device node as a first one
> to use it should be quite simple, with just a few tweaks to make
> it match the upstream bindings (see the mali-midgard nodes
> upstream for the reference).
>

After having conversation with people from ARM, it seems there are
quite a bit feature-wise differences among upstream bindings and
Mali-ddk bindings. Also there are platform specific bindings too in
Mali-ddk which I am not sure will be acceptable upstream. So I think
it won't be much value-add to upstream bindings until we have upstream
Mali driver as we can't control these differences in bindings.

> Even if this board can have the .dtb as part of the
> firmware (i.e. it's not technically needed to have it in Debian
> itself), it follows the out-of-tree driver dt bindings and that's
> not compatible with the package in Debian which follows the
> upstream ones.
>

AFAIK, earlier Mali packages in Debian are based on out-of-tree
Mali-ddk (eg. r16-midgard). So these packages would be following
bindings as per Mali-ddk. In similar manner out-of-tree bitfrost (eg.
r13) could be packaged with platforms aligning to corresponding
Mali-ddk bindings.

Regards,
Sumit

> Guillaume
>
> > Also to build latest EDK2 firmware for hikey960, follow this doc [2].
> >
> > [1] https://github.com/96boards-hikey/OpenPlatformPkg/commit/102978d715570827643afb04b2edee5e9f81af22
> > [2] https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/plat/hikey960.rst
> >
> > Regards,
> > Sumit
> >
> >>
> >>> anyone: can we get some other DTB info upstreamed (juno? anything else useful)
> >>>
> >>> Wookey
> >>> --
> >>> Principal hats:  Linaro, Debian, Wookware, ARM
> >>> http://wookware.org/
> >>> _______________________________________________
> >>> pkg-mali-devel mailing list
> >>> pkg-mali-devel at alioth-lists.debian.net
> >>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-mali-devel
> >
> > _______________________________________________
> > pkg-mali-devel mailing list
> > pkg-mali-devel at alioth-lists.debian.net
> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-mali-devel
> >
>