[Pkg-Mali-devel] Debian mali pckaging status

[Guillaume Tucker]

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.

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

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.

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
>