[Pkg-Mali-devel] mali-400 usespace drivers

Maxime Ripard maxime.ripard at bootlin.com
Fri Jun 29 08:32:00 BST 2018


Hi!

On Thu, Jun 28, 2018 at 06:35:34PM +0100, Wookey wrote:
> I am the maintainer of the debian mali packages, both free kernel
> drivers and non-free userspace drivers.

Nice mail-meeting you :)

> I saw your announcement for mali-400 binaries from allwinner, and
> wondered about putting them in the mali-utgard-driver debian package
> (in preparation). 
> 
> However, grabing the files from
> https://github.com/free-electrons/mali-blobs I see that the allwinner
> licence does not seem to allow general redistribution, only
> redistribution by customers, via a specific github URL. Is that your
> understanding?
> 
> It also seems to restrict use and copying to 'users of github' which
> is a rather bizarre restriction.
> 
> If this is the case then I don't thnk Debian can put these binaries in
> a package, which is a pain.
> 
> I note that the mali-450 r6p1 drivers are available from ARM with
> the new licence:
> https://developer.arm.com/-/media/Files/downloads/mali-drivers/user-space/hikey/mali450r6p001rel0linux1armhftar.gz
> which suggests that this vintage of driver _could_ be licenced to
> allow redistribution. We could try pestering some lawyers to get
> this fixed, but it's always an incredibly slow purpose.

Allwinner has been helpful on this in the past, so I guess we could
try to ask them to clarify. But it might take a while yeah.

> I suppose the only alternative is a 'downloading' package which grabs
> the files from the specified location on installation. 
> 
> We can still do testing to make sure the packaged kernel driver works
> with these binaries. I see you got mali DTB info upstreamed for A23
> and A33. Which kernel version did that go into? Ideally we'd be able
> to have DTB info for Hikey (mali-450) and A23/A33 in mainline kernels,
> so one packaged out-of-tree dkms module should work for both. Is that
> plausible?

I guess a more fundamental issue for Debian would be that:

 - As far as my understanding goes, you need to have a blob for your
   particular SoC family. I'm not really sure what the details are
   anymore, but I recall that it was related to the formats being
   supported by the GPU vs the one supported in the scanout engine. So
   you probably cannot have a package for all the SoCs using a Mali.

 - This is further complicated by the fact that you need to have the
   kernel and user-space versions in sync. Which means that you won't
   be able to use our blobs (r6p2 or r8p1) on the Hikey that seems to
   have an r6p1 kernel driver. Or the other way around, you wouldn't
   be able to run an r6p1 blob on top of an r6p2 or r8p1 driver (but
   this one is easier to address, since we have the code and it's
   quite easy to support a new version).

So I'm not really sure how you could do a driver + blob package(s)
that would support all SoCs out there in Debian. But my debian
packaging skills are basics, at most :)

For your DTB question, the node for the A23/A33 was added in 4.11. On
the A20 and the H3, it was added in 4.17.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-mali-devel/attachments/20180629/dc5a638e/attachment.sig>


More information about the pkg-mali-devel mailing list