[Pkg-Mali-devel] Debian mali pckaging status

[Sumit Garg]

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.

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