So, I think we are ready to start
So, next talk is from Martin, about Debian on ARM devices.
So, it's Debian on ARM devices, it's not about the Debian ARM port itself, or any of the various ARM ports
I would say it's sort of a mix of different topics
it's basically ---
I mean, basically I often get it's basically ---
I mean, basically I often get
the question from users
"Well, Debian works on this particular ARM device,
I have a device which is like really really similar,
so surely Debian should work on it, right?"
And so far, the answer unfortunately was usually "no"
and - and it's really frustrating for users
because they don't see why.
You know, the device is very much the same, so why doesn't it just work.
And so, basically what I'm trying to do is
to show like a little bit behind the scenes
of how Debian on ARM works
And there has been a whole lot of progres
So I'm going to show how did it work,
what are the improvements, and
and how is it going to work in the future
And it's all more from a develeoper perspective
so, it's like, how do we support it in the Debian Installer
its' like a mix of stuff, and I should say,
I'm really looking at it from somebody who basically
adds support for devices in the installer
but I'm not like a kernel guy or anything, so
there are a lot of people in this room who know a bit more about the technical details
but I'm not going to really drill down really deep down anyway
But if I'm incorrect, I'm sure that
there are plenty of people that will correct me.
So, where do you find ARM? So it's pretty much everywhere these days, I mean...
Pretty much every phone has an ARM chip in it
All those "Internet of Things" gadgets are ARM-based
You have NAS devices, and that's really the area I used to focus on
those small boxes where you basically add a hard drive
and most people just use it for storage, but it's actually a
full PC where you can install Debian on it
so I always found that to be very interesting
and nowadays you have a lot of development boards
And I'm not sure whether "development boards" is the right word
Because when I hear "development boards" I think of it as really expensive,
Like 5K for boards or something
But nowadays you have those, maybe, a better board would be like bareboards
Like "Raspberry Pi", like basically it's just the board
it does not come with a case, you can buy those as well
and it's like 30 dollars or something, you can get
And that gets pretty much where most of the
excitement is going for Debian users at this moment
And that can cause a lot of frustration
And everybody says that ARM is going to be big on servers
and I think that's something we ar going to see
But right now, again, it's
a little bit frustrating
How does it work as a Deban Installer
There are basically two
ways of installing on those ARM Pi devices
So the, like, historic, that we normally
would be to install on, like, ascreen
can be a serial console,
and then you just download via the network
from a CD image or wherever,
But the other method, which we actually use for those
net devices was a network console
where you basically ssh into the installer
and you perform the installation via ssh
and that was really the only way, because those mass devices
don't have any I/O, so I
even in there, you can
it's just a serial console, most of them
That's something we didn't want to require from the user
And the other thing that's coming through, I think that it's basically cool that was announce today,
screen support, so basically
so you can have multiple sessions with in vi,
which can be useful if you have an open shell to debug
And so, how -- And so, this is really looking back at
like running Debian on NAS devices
which is something that used to be really popular
And the way it worked was basically
that we provided an installer image
which was sort of a firmware image
as a lot of those NAS devices
have like a firmware upgrade mechanism
and so we would basically fake
we would create a firmware image
which the software would accept
but instead of a firmware update
it would actually contain the Debian installer
so you would install that upgrade
you would reboot, and
you could ssh to the installer
and obviously, in order to ssh to the installer
it needs to bring up the network
and there is a tool called oldsys-preseed
that basically reads the network configuration
from the device
and then sets up the network
and it can always recognize the DHCP
and then the user connects via ssh
again, there would be some indication, maybe
you know, there would be a "beep"
or maybe change the LED
to indicate that the installer is ready
and then, the user basically performs
a regular installation
with normal d-i; they don't have to
do anything differently.
And at the end, flash-kernel runs
to make the system bootable
flash-kernel is called that way
because it used to support flash-kernel is called that way
because it used to support
like the initial device it supported
booted from flash
but it also generates bootable devices
bootable images of disk devices
so it really, flash-kernel really requires
understanding of each device
and our philosophy
in those cases, with those NAS devices
was really,
we don't touch anything
in the firmware, like
in the configuration,
so sometimes
instead of changing the root device
in the u-boot config we would actually
hard-code that in the ramdisk
just because we wanted people to go back
to the original firmware if they had to
if they had to send it in for repair or something
and
and that kind of approach really worked well
so I think we really had a lot of
people, lot of users running
in Debian in those kind of NAS devices
and it was really easy to do.
You get a firmware image,
you connect to the installer via ssh,
and it just works, it's a normal
debian-installer, the way
everybody knows it,
because some of the other distros
they basically provide, like,
tarballs and instructions
so you need to partition a disk,
need to un-tar it,
you need to change those files,
and even if it sounds simple,
it's so many steps that
you always... you often get something wrong
and then you put the drive into the
NAS device, and it doesn't boot, and you don't know why
where did you make that mistake,
which step
and you basically have to start from scratch
so Debian really provided something unique
by adding
the debian-installer support
but anyway, that's the way
it sort of used to work.
Nowadays, with a lot of those bareboard
it's much easier
I'll get to that.
So at the moment there are three different ARM ports:
There is the old armel
which used to be the "newer" ARM
and now it's old,
and one of the discussions
that we are probably going to have later today on the BoF
is about, should we remove that
after Stretch.
There is armhf and the arm64
and we get basically the question I hope to answer.
If, you know, device A works,
I have a device which is really similar,
but it doesn't work. Why is that?
So, heh,
There have been a lot of changes
in various upstream projects, specially
the kernel and U-boot
that really make things easier.
So, in the past
we basically had
a kernel image
for each platform,
where a platform is basically like
a SSE family
and there would be a different image
because ARM takes a long time
to compile, there was always some debate
about adding a new platform
because there would be a new
image flavor, which takes some time,
and that was just really like,
we couldn't just have one ARM kernel
which works everywhere.
And a lot of people didn't understand
why you had a different kernel
because different platforms,
although there has been a lot of progress upstream,
at least nowadays, with armhf
and with arm64
we just have one kernel.
And upstream basically
Maybe some of you remember the rant
by Niels about
the ARM people doing everything
in different ways,
and there has been a lot of standarization
over the years.
Basically, the other thing is
there used to be for each device
there was a board file
it was like a C file
to initialize the different components,
and the boot loader would
pass the machine ID to the kernel,
and it would load that boot file.
And nowadays,
there is basically a
device tree in the kernel,
which is a description of the hardware
and it will basically compile it
to, like, a binary blob, the .dtb.
And, so, basically you just need
the kernel image, and
the .dtb, which is hardware-specific,
and then it boots.
And obviously, for us in Debian
that makes it much much easier
to support a lot of devices.
The other thing that changed in U-boot,
when you install the Debian kernel image,
it creates
the vmlinux file
and also the RAM disk
but with U-boot,
you couldn't actually load those files
correctly. You basically
had to wrap them in a U-boot image
and it's not really hard
it's just the command initram,
but all of the different devices had
different load addresses,
and, again, that's hardware-specific knowledge
that flash-kernel needed to know.
And nowadays,
there is a command which
directly loads the kernel,
so that, again, was a step to make things easier.
And the last thing which really made
things easier is distro support
in U-boot.
So, basically, in the past
every U-boot, every
devices in U-boot,
booted in a different way,
just in terms on where would it load
the file from, or
what variables would it use, and
nowadays there is something called distro-support
which is basically a standardized way
to boot a Linux distro
with U-boot.
There are basically
two ways, either can
read a config file,
or it can basically run a
boot script, and that's what
we use in Debian, so we basically have
a generic boot script
which loads the kernel,
loads the ramdisk, the .dtb,
and boots Debian.
It can use the generic
bootscript in almost all
of the modern devices.
So nowadays, because of that,
it's much more standard, and
it's much easier to support
those devices.
So here are some examples of flash-kernel
So, basically, flash-kernel has like a database
of devices which it supports
so it's like the machine entry
in /proc/cpuinfo,
and then the kernel flavors
it can run
and, so, this one is
an old device, it still uses
a board file, and it
needs the U-boot wrapper,
So...
You are basically setting the machine ID
those are the flash partitions
where the kernel and the
ramdisk are stored, and
that's the load address for the
U-boot wrapper
And, now, that's a device
which used to have
a boot file,
and which then migrated
to a .dtb,
so basically, heh,
that was really really painful for Debian
so, basically, the kernel people said
"Oh, you are going to move to device tree,
so don't worry,
we are not gonna remove those old board files,
you can still use them."
And then, a few years later they realized
it's really hard to keep both alive,
and they got rid of the board files.
And that was really painful to us
because we had to migrate
So you can see,
here, a kernel version,
and so, from that kernel on,
you needed to use the new way.
And one of the reasons it was painful
specially on the QNAP devices
is because with
they actually have two different CPUs
so there are different barriers
and whilst the board files,
the same board file worked
regardless of the CPU,
because of the way the device tree worked
it actually needed two different device trees
depending on the CPU
so now we basically, you know, something that just worked,
you know, it used to work fine,
you just had one kernel
with the machine ID
at least would work,
and somehow with the device tree
we needed to figure out which one
we need, and so
[?] fortunately did all of that work.
So that's actually a script that runs
to figure out which device tree
that particular device needs.
So now, that's actually
the reason I want to show this is
how simpler things are these days, so
this is an example from
[?] platform, which uses distro-support,
and the only thing you really need is
a machine entry with the name,
and then
like the kernel-flavor,
but that's the same for...
you know, there is only one kernel flavor.
And then, the device tree ID
and, again, all of that stuff is generic,
so it just uses the generic bootscript,
and the generic boot path,
so basically
all it pretty much needs for
a new device is, like,
you know,
these two entries,
it's really really simple.
So here, I just wanted to
tell about the different ARM ports and...
So, for me it was really hard to structure this, because
those changes in the kernel
and U-boot
you know, happen independent of our ARM ports,
But at the same time, because
because the armhf world is much newer,
it works in a different way.
So, basically, the armel
we still have different flavors
but we have already combined the orion and the kirkwood
into one marvell flavor,
and we have the versatile one.
So one of the problems we have in armel is that
a lot of those NAS devices
boot from flash
and they only have, some of them,
3MB for the kernel,
which used to be a lot of space
but nowadays it's not.
So that really puts a lot of restrictions
so basically we disable some stuff
from armel
but I think that armel is really really widely used
because of those NAS devices,
but I think they are slowly getting old,
but there are still a lot of people that use them.
Like I said, it requires the U-boot image
Originally, we used board files
and device tree, most of them
have switched over to device tree
even if some of them still use board files
and adding a new device requires
a number of changes in the installer.
So basically, you needed to map
the device to
the complete image
and there are just there a couple of
things, so basically, any one device
you have to change like five different
places in the installer.
And it was quite confusing for people who wanted
to add new devices
Because it isn't really documented very well
So some examples are a list of three people
who are involved in that port
So, Roger is someone
who is quite new, and who really got
involved into porting those old devices.
And so, armhf is much nicer,
so the majority of
devices support distro-support.
And the other thing we do
is, for some of the devices
we provide SD card images,
which contain
U-boot and the Debian installer
So basically Vagrant
maintains U-boot in Debian, and
a lot of those devices are supported
in U-boot in Debian.
So we just
provide an SD image, so you can just
store it in the SD card, you put it in
and, because of the distro-support,
it just loads debian-installer,
you do the installation, reboot,
and things just work.
So I think it really has gone
...Come a long way.
So nowadays,
adding a new device
requires much fewer changes
than it used to be.
Because as everything uses the same, like, one kernel flavor,
you don't need to patch all those different places anymore,
and because of distro-support, it just works.
You can pretty much use the generic bootscript.
So, arm64.
So, the problem until recently
is that there simply wasn't any hardware
that people could buy.
And that's changing rapidly now
[?]
We have for example the Raspberry Pi 3
which uses a 64 bit CPU
but the software it ships is only 32 bits,
but most of the work
is now
upstreamed to run 64 bit on it
and there are a lot of
devices which sort of work but not quite
but anyway, so the idea for arm64
is that a lot of the
new hardware
specially on the server side
will use UEFI,
and so you basically just
it just works like a PC.
So you have Grub,
you can run debian-installer from Grub
and you get Grub afterwards.
And just boots like a PC,
and Steve has done a lot of work in that area,
And in theory,
it should just work out of the box.
So, if it uses
UEFI, we don't need to add anything.
It just works.
There's nothing to do.
At least, that's the theory.
So, what I found is
...I made a disclaimer, so
...Assuming the kernel
you know, kernel support and stuff...
...To be honest,
right now, that's a big assumption.
So I've been playing with a few
64 bit ARM boards
and basically, what I found is
there is some support upstream,
so I can boot a kernel,
but, oh! There is no USB support!
there is no Wifi support!
So I cannot actually do anything with it.
But I can get to something that
because arm64 is still farily new.
And there is a lot of work going on upstream
to support the various platforms.
So, I think over time that's really going to be much better.
Even though that UEFI idea is there
in reality,
we are going to see different solutions
for arm64.
So we are going to see UEFI, in particular on servers,
but we will also see U-boot.
So a lot of those bare boards
they have U-boot.
And, so, right now
we can use the distro support
and I think that it works pretty well.
But one thing that SuSE has done
so, they just had the same issue,
they want to support all those devices
but they just want to use the same mechanism everywhere,
so they have actually implemented
UEFI on top of U-boot,
so you can basically use U-boot to load Grub
and then you have Grub
so I think that's something we need to figure out;
do we want to stay with distro-support?
do we want to use
UEFI on top of U-boot?
is that something we want to
give users the option?
And then, Fastboot
is something used
in the Android world
and a lot of those, like, I see a lot of
both bare boards, but also
game consoles and stuff, which
which are sort of Android-oriented,
but which can also run normal Linux,
and they will use like Fastboot or something.
And there are tons of other bootloaders out there
But I would definitively say, like, the good ones
are UEFI and U-boot
So, I gave a similar talk a few weeks ago
and turns out, a lot of non-free
firmware, like, "can I
run that stuff, you know,
purely with free software?"
...And...
So, the thing with ARM is that
there are a lot of different platforms
I'm not sure about all of them,
but some of the platforms
I looked at, yes, you
do need some... There is always something propietary.
So in a lot of cases
I see where you have
you use the proprietary first-stage boot loader,
so the Raspberry Pi is an example,
so, I don't actually have a Raspberry Pi, but
the way I understand it is
you basically put some boot files
in an SD card,
and they are proprietary, and
then they load the kernel.
Or in case of [?]
supported in Debian,
the first stage boot loader would basically
be used to run U-boot,
and then we could use U-boot, and
the U-boot support all of it is free software,
but the first stage boot loader isn't.
I have had, there are some people
working on a free replacement for
the Raspberry Pi, though.
With nVidia Tegra,
which is
something I'm working on at the moment
you also have a tiny first stage boot loader,
but then again, you have U-boot, which is free,
and in that case, you also have some firmware
images for the GPU
and for other stuff.
For the Dragon board,
The Dragon board sounded really interesting
because it actually has a
a graphics chip
which can be used with free software,
so that sounded pretty cool,
but again, it has a
proprietary first
stage boot loader,
and then there is a second stage boot loader
which is actually open source
and then there's actually a U-boot of that,
and then you have some
binary blobs which
also need to be installed in flash to work properly
On the Marvell side, I'm
not really aware of anything.
I have never needed to flash anything
proprietary, but
I'm not sure how U-boot gets started
on Marvell, so maybe there is something.
So the future is all... So NAS devices are
like I said, that's something that's
really been popular in Debian.
Specially on the QNAP devices,
but the problem is, so, QNAP...
so the devices we currently support
are pretty old
nowadays,
and they have some newer devices,
but they are not properly supported
in the upstream kernel.
So, I have no plans
to support Debian on those.
I recently did some work on
Seagate NAS devices
which are actually pretty interesting
but again, they will go out of date
already,
and then there's the whole 64 bit ARM
so I think people are really waiting
for arm64 servers
I think there's going to be a whole lot of
work on that area.
And then, there are all of those development boards
Raspberry Pi,
Pine64,
Allwinder,
Basically, all of them
sound exciting, but if you
look at them, all of them
have some upstream issues, so it's...
It is really quite frustrating at the moment.
But I think things are really
moving [?]
And then there's this 96Board initiative,
which is actually done by Linaro,
and, so, Linaro supports
Linux on ARM, so you'd think, "wow,
there are some really nice boards coming out!"
and they differentiated
between the consumer edition and the enterprise edition
beside, I bought some consumer-edition boards,
and it's really horrible.
So first of all, I had to spend like half a day
just putting the components
because it uses, like, a nonstandard power supply,
a nonstandard serial console,
so finally I found
all the pieces I needed, and then
I was expecting, well, it's from Linaro!
Surely everything just works upstream!
But it doesn't. It's like
yes, I can boot the Linux kernel,
but there's no USB, there's no
Wifi, no nothing...
So, yes, that's a little bit frustrating.
On the enterprise edition,
I think that looks more interesting.
You know, that's more standardized.
But again, there have been some delays.
[audience; unintellegible]
Yes, OK.
So that would be interesting to see.
So, the questions that I actually have nowadays
is, so...
Because of those changes,
because of having, you know,
a mode of U-boot, most of those
new devices having a U-boot
with distro-support,
having a kernel which, you know,
one kernel image that works on all of those
devices which are supported,
it's really easy to support
a new device?
As long as it's supported by the kernel.
But, at the same time, I think it's a big
challenge for Debian.
Because right now, if you look at armhf,
we basically say, well,
hint the installer,
and if there's a device tree,
it's probably going to work.
But, what does that mean, right?
And...
which really work, which means,
so, we have Vagrant
having U-boot support
in Debian, we have
people testing debian-installer,
testing the Debian kernel, so we have
devices which really work, well supported,
and then we have some devices
on the other hand where, well, yes,
there is a device tree, but no one
has ever tried it. And
at the moment, we have no way
for users to differentiate
those use case... Those
support levels.
So I'm wondering if we need
like a table,
somewhere where maybe
some support levels, like green, yellow...
red?
Where green is, "yes, we have Debian
people who have
testing that stuff",
yellow would be, "well, we have heard some report
that it might work", and
green is, you know, doesn't work,
or we haven't tried that it works.
Maybe we need something like that.
But right now,
I see from users
"I want to run Debian on my ARM device", and
they don't know if it's going to work.
Yes, then...
[audience; unintellegible]
Yes, so Ben is saying we also need
to track what the earliest and the latest
kernel versions that there have been tested.
So I think we really need to
come up with some criteria
to have, you know, define those kernel support levels that indicate that
And yes, the other question is related
to, with all those boards,
how do we actually test them?
So, I keep --
it's really... remember [?]
which is great, but also acknowledge
those boards, they are so cheap!
so it's like, "oh, there's a new board!
It's £30! I'll just get it!"
And then we have, like, those piles of boards
and realize, well, I don't have time
for testing all of that stuff!
I think that's going to be a real challenge.
hundreds -- I don't know,
it's really hundreds of boards coming out.
How do we support all of that?
So, I think that's the question I wanted to raise,
and maybe something we can talk about in the BoF
But yes, I'm obviously
open for questions now.
[James / purpleidea:] Hello.
So, don't quote me exactly,
so, I believe
RedHat has this problem as well, obviously,
I mean, they are obviously more interested in the
ARM64-only server stuff,
but I believe the way they are going about it
maybe it's something could collaborate on
is, they are trying to make sure and push
all the vendors to be standardized
because, as you pointed out,
it's just not, it's crazy
with all the different device tree differences and so on,
so I believe their strategy is to
work with the vendors, and
require everything to be upstreamed, and
no device tree
specifically, to push everything to just boot
with one kernel, and so on.
So maybe that could be
sacrifice a few of the
shitty boards, but work with the vendors
that make the ones that are upstreamed.
[Martin:] Yes, so I may be mistaken, but
as far as I know, RedHat
basically says, "we only support
UEFI and ACPI"
and that's fair enough,
and I think that works for them, because
it's just the server world they care about,
but I think in the case of Debian
there are so many boards out there which
don't need those specs,
and we sort of live, like, in the "real world"
so I don't think we can
Well -- I know it's different. I mean,
if RedHat wants to target
the server people, like, the people
which give money
that's fair enough, that makes sense for them
but Debian, we run everywhere
so I think we need to support
all those weird
cases as well.
And maybe if it gets too weird,
I mean,
I put in some work in the Dragonboard,
and then I realized,
am I actually spending the time because
no one, like, I have heard
from no one that they have
that board, I mean, like [?]
for the Raspberry Pi, but I have heard
like, pretty much no one has the
Dragonboard, so maybe,
...it's not worth my while,
but if there's a board
that people want to use it,
I think we should support it in Debian.
And we do have the infrastructure
so we, you know, it doesn't have to be
UEFI and ACPI,
we can support other devices, because
we have done it before.
But I definitively agree with
the point about getting more standardization
and that stuff, so
I agree, yes.
And the whole distro-support
in U-boot, that has really made things easier for us.
[Phil:] I may begin to say some of the same things Steve has, anyway.
Steve]: So, yes, on the
ACPI versus DT thing,
it's more a question
of the quality of the implementation of the
of the firmware,
and the upstream support that is...
DT isn't fundamentally
worse for upstream support
than ACPI is,
RedHat are
have some reasons
[?] of sensibility,
but then, it's not
fundamentally, it doesn't fundamentally stop it
people supporting it, specially
a community distro like Debian.
I was also going to ask Martin,
have you talked to
people like kernel CI
about testing and coverage stuff?
[Martin:] Yes, not really, but
I think there are some things we should look into.
[Steve:] Yes, because the whole --
Obviously, making sure the kernel boots
on random hardware
stuff, is exactly what that's doing
and there's at least infrastructure there that might be
nice to play with.
[Martin:] Yes. I think that's a good idea.
[sledge:] So, on the whole 96Boards thing,
sorry!
Most of the engineers involved
are totally aware of
how [?] it really is.
We tried to tell management
they would --
They don't want to listen.
Umm.. So,
there has been a huge amount of pushback
saying, you know, "we're Linaro
we should make sure this is all upstreamed".
[Martin:] Well, I am aware
it's just, Linaro
has a really good brand,
so people expect, you know, when I saw
96Boards it's Linaro,
obviously that stuff it's going to work!
and that's why I was really disappointed.
[Steve:] One positive thing there
is that the first DE board
the SoC does basically work upstream
already with current upstream kernel
it's not like there's some patches still
to go in. Apart from the PCI, it should basically
work... So, hopefully,
hopefully, that's going to be a much
less spectacular
story than the
consumer-edition boards have been.
As they are unfortunate.
[Sledge:] The first EE board
the [?]board, is due to start shipping
really soon now.
There are examples already out there
with engineers for validation.
Literally, we are talking the next couple of weeks
is what I have been told.
That's the first 96Boards I would
actually spend any time on at all personally,
the CE boards are a joke.
I forgot what else I was going to say. Oh!
Yes! Then...
I guess we will go through a lot of this again
in the ARM BoF later on
in terms of
which things we support.
We will carry on with the discussion.
[Vagrant:] Um... Is this working?
Yes, so...
We have got all this great support for
distro-boot command and U-boot, and
now we are starting to get
to UEFI emulation
in U-boot, so even for boards
that don't have UEFI emulation--
UEFI support, if they support
U-boot, it might work
although that means all the standarization
we worked towards, we throw it away.,
Meh!
[Martin:] Yes, I think that's something we need to figure out,
which one do we want to standardize on,
or is that something we want to
leave up to the user.
but yes,
I mean, I think one
I mean, I guess it was
so confusing, because there are like
all those different ways, but
what I really wanted to show is that
things are getting much more
standardized and much better.
So, it used to be really
pretty horrible, and nowadays,
you know, if a platform
uses a modern
U-boot, if it has
upstream support, then it is
actually pretty trivial to add
Debian support, and
I think that wasn't the case
in the past.
I think Ben had another one?
[Ben:] So, I'm
[laughs]
I'm interested to know how much
how much interest there is among the ARM porters
in graphics support.
GPU support, rather
than settling for dumb framebuffers.
How many...
How many of these boards...
Quite a lot of these boards do have HDMI
and I don't know
to what degree they are actually supported.
Are any current projected work
which definitively is using the
GPU on ARM system, and
what's in Debian,
is the Debian base system
does Debian... What's in Debian does not
support GPU.
[Martin:] So, I can't speak for Vagrant...
I have personally done some work
on the Tegra recently,
and nVidia is actually
working upstream on [?]
so I'm really interested in it
but I think that a lot of
the board used, there's money
GPUs I'm not sure would be
...you can get a [laughs]
can we get a microphone for Steve?
[Sledge:] So, on the Mali front,
there has been a lot of haste where we
have been scared of releasing any of this
in any way, shape or form,
without huge
[?]-relays and all that kind of stuff.
So it's not really distributable.
Even, at all.
We are a long way of it being releasable free,
There are packages coming that we
should be getting shippable in non-free
at least if you want to get full acceleration
on your Mali stuff.
Hopefully, that will solve some of the problems
There is a lot, there are a lot of people
in [?] who are very very keen on
supporting it properly, free and upstreamed.
It's a long fight.
It will take a while.
I mean, most of the Mali driver developers
themselves I have spoken to, would love to
make it free. It just comes down
to legal people
being scared.
[Tobi:] Are there some questions left?
[Martin:] Well, thanks for coming!
And there is going to be the ARM BoF
later today, and
Vagrant is also going to talk about his experience
about running a build network
on armhf boards..
Thanks!
[audience clapping]