0:00:03.060,0:00:05.000
So, I think we are ready to start

0:00:05.020,0:00:08.770
So, next talk is from Martin, about Debian on ARM devices.

0:00:14.210,0:00:21.530
So, it's Debian on ARM devices, it's not about the Debian ARM port itself, or any of the various ARM ports

0:00:21.970,0:00:27.130
I would say it's sort of a mix of different topics

0:00:27.130,0:00:27.280
it's basically ---

0:00:27.280,0:00:29.130
I mean, basically I often get[br]it's basically ---

0:00:29.130,0:00:32.020
I mean, basically I often get

0:00:32.080,0:00:35.240
the question from users

0:00:35.530,0:00:38.930
"Well, Debian works on this particular ARM device,

0:00:39.110,0:00:42.080
I have a device which is like really really similar,

0:00:42.080,0:00:44.860
so surely Debian should work on it, right?"

0:00:44.860,0:00:48.640
And so far, the answer unfortunately was usually "no"

0:00:48.640,0:00:53.020
and - and it's really frustrating for users

0:00:53.020,0:00:55.530
because they don't see why.

0:00:55.530,0:00:58.570
You know, the device is very much the same, so why doesn't it just work.

0:00:58.570,0:01:01.310
And so, basically what I'm trying to do is

0:01:01.310,0:01:04.040
to show like a little bit behind the scenes

0:01:04.040,0:01:06.510
of how Debian on ARM works

0:01:07.040,0:01:09.620
And there has been a whole lot of progres

0:01:09.620,0:01:13.130
So I'm going to show how <i>did</i> it work,

0:01:13.130,0:01:15.130
what are the improvements, and

0:01:15.130,0:01:17.600
and how is it going to work in the future

0:01:19.930,0:01:21.880
And it's all more from a develeoper perspective

0:01:22.110,0:01:25.880
so, it's like, how do we support it in the Debian Installer

0:01:26.220,0:01:31.440
its' like a mix of stuff, and I should say,

0:01:31.680,0:01:35.110
I'm really looking at it from somebody who basically

0:01:35.110,0:01:37.510
adds support for devices in the installer

0:01:37.510,0:01:40.460
but I'm not like a kernel guy or anything, so

0:01:40.460,0:01:45.060
there are a lot of people in this room who know a bit more about the technical details

0:01:45.400,0:01:48.800
but I'm not going to really drill down really deep down anyway

0:01:48.800,0:01:51.680
But if I'm incorrect, I'm sure that

0:01:51.680,0:01:53.680
there are plenty of people that will correct me.

0:01:54.170,0:02:00.820
So, where do you find ARM? So it's pretty much everywhere these days, I mean...

0:02:01.150,0:02:05.040
Pretty much every phone has an ARM chip in it

0:02:07.480,0:02:11.950
All those "Internet of Things" gadgets are ARM-based

0:02:12.530,0:02:18.480
You have NAS devices, and that's really the area I used to focus on

0:02:19.020,0:02:22.600
those small boxes where you basically add a hard drive

0:02:22.600,0:02:26.730
and most people just use it for storage, but it's actually a

0:02:27.130,0:02:30.150
full PC where you can install Debian on it

0:02:30.640,0:02:33.930
so I always found that to be very interesting

0:02:34.280,0:02:37.310
and nowadays you have a lot of development boards

0:02:37.460,0:02:41.280
And I'm not sure whether "development boards" is the right word

0:02:41.280,0:02:45.130
Because when I hear "development boards" I think of it as really expensive,

0:02:45.640,0:02:48.110
Like 5K for boards or something

0:02:48.420,0:02:52.400
But nowadays you have those, maybe, a better board would be like bareboards

0:02:52.400,0:02:56.200
Like "Raspberry Pi", like basically it's just the board

0:02:56.200,0:02:59.820
it does not come with a case, you can buy those as well

0:02:59.820,0:03:03.060
and it's like 30 dollars or something, you can get

0:03:03.370,0:03:06.530
And that gets pretty much where most of the

0:03:06.530,0:03:10.950
excitement is going for Debian users at this moment

0:03:11.220,0:03:13.930
And that can cause a lot of frustration

0:03:16.640,0:03:20.150
And everybody says that ARM is going to be big on servers

0:03:20.150,0:03:24.020
and I think that's something we ar going to see

0:03:24.020,0:03:26.600
But right now, again, it's

0:03:26.600,0:03:28.600
a little bit frustrating

0:03:30.600,0:03:34.000
How does it work as a Deban Installer

0:03:34.000,0:03:36.000
There are basically two

0:03:36.970,0:03:40.280
ways of installing on those ARM Pi devices

0:03:41.020,0:03:44.350
So the, like, historic, that we normally

0:03:44.350,0:03:47.950
would be to install on, like, ascreen

0:03:47.950,0:03:49.950
can be a serial console,

0:03:50.310,0:03:54.550
and then you just download via the network

0:03:54.750,0:03:58.970
and then you just download via the network

0:03:58.970,0:04:00.970
from a CD image or wherever,

0:04:00.970,0:04:04.660
But the other method, which we actually use for those

0:04:04.660,0:04:07.910
net devices was a network console

0:04:07.910,0:04:11.460
where you basically ssh into the installer

0:04:11.730,0:04:14.440
and you perform the installation via ssh

0:04:15.400,0:04:19.839
and that was really the only way, because those mass devices

0:04:19.839,0:04:22.950
don't have any I/O, so I

0:04:23.200,0:04:25.370
even in there, you can

0:04:25.370,0:04:28.080
it's just a serial console, most of them

0:04:28.330,0:04:32.000
That's something we didn't want to require from the user

0:04:33.220,0:04:36.840
And the other thing that's coming through, I think that it's basically cool that was announce today,

0:04:36.840,0:04:38.840
screen support, so basically

0:04:40.020,0:04:43.330
so you can have multiple sessions with in vi,

0:04:43.330,0:04:47.110
which can be useful if you have an open shell to debug

0:04:49.110,0:04:53.500
And so, how -- And so, this is really looking back at

0:04:53.500,0:04:55.500
like running Debian on NAS devices

0:04:55.500,0:04:58.420
which is something that used to be really popular

0:04:58.420,0:05:02.500
And the way it worked was basically

0:05:02.500,0:05:05.200
that we provided an installer image

0:05:05.200,0:05:07.200
which was sort of a firmware image

0:05:07.200,0:05:09.200
as a lot of those NAS devices

0:05:09.200,0:05:12.080
have like a firmware upgrade mechanism

0:05:12.240,0:05:14.180
and so we would basically fake

0:05:14.180,0:05:17.240
we would create a firmware image

0:05:17.300,0:05:19.520
which the software would accept

0:05:19.600,0:05:22.460
but instead of a firmware update

0:05:22.540,0:05:24.840
it would actually contain the Debian installer

0:05:24.840,0:05:27.620
so you would install that upgrade

0:05:27.640,0:05:30.080
you would reboot, and

0:05:30.080,0:05:32.860
you could ssh to the installer

0:05:32.920,0:05:36.360
and obviously, in order to ssh to the installer

0:05:36.360,0:05:38.020
it needs to bring up the network

0:05:38.020,0:05:41.060
and there is a tool called oldsys-preseed

0:05:41.060,0:05:43.280
that basically reads the network configuration

0:05:43.280,0:05:45.280
from the device

0:05:45.280,0:05:47.280
and then sets up the network

0:05:47.280,0:05:51.820
and it can always recognize the DHCP

0:05:51.820,0:05:53.820
and then the user connects via ssh

0:05:53.820,0:05:57.600
again, there would be some indication, maybe

0:05:57.600,0:05:59.600
you know, there would be a "beep"

0:05:59.600,0:06:01.260
or maybe change the LED

0:06:01.260,0:06:03.260
to indicate that the installer is ready

0:06:03.260,0:06:05.260
and then, the user basically performs

0:06:05.260,0:06:07.260
a regular installation

0:06:07.260,0:06:09.260
with normal d-i; they don't have to

0:06:09.260,0:06:11.260
do anything differently.

0:06:12.320,0:06:14.520
And at the end, flash-kernel runs

0:06:14.520,0:06:17.340
to make the system bootable

0:06:17.340,0:06:20.460
flash-kernel is called that way

0:06:20.460,0:06:20.660
because it used to support[br]flash-kernel is called that way

0:06:20.660,0:06:22.660
because it used to support

0:06:22.660,0:06:25.380
like the initial device it supported

0:06:25.380,0:06:27.380
booted from flash

0:06:27.380,0:06:29.380
but it also generates bootable devices

0:06:29.380,0:06:31.380
bootable images of disk devices

0:06:34.180,0:06:36.560
so it really, flash-kernel really requires

0:06:36.560,0:06:38.560
understanding of each device

0:06:38.560,0:06:41.080
and our philosophy

0:06:41.080,0:06:43.080
in those cases, with those NAS devices

0:06:43.080,0:06:44.040
was really,

0:06:44.040,0:06:46.040
we don't touch anything

0:06:46.040,0:06:48.040
in the firmware, like

0:06:48.040,0:06:50.040
in the configuration,

0:06:50.040,0:06:52.040
so sometimes

0:06:52.040,0:06:54.700
instead of changing the root device

0:06:54.700,0:06:56.700
in the u-boot config we would actually

0:06:56.700,0:06:58.700
hard-code that in the ramdisk

0:06:58.700,0:07:02.720
just because we wanted people to go back

0:07:02.720,0:07:05.160
to the original firmware if they had to

0:07:05.160,0:07:07.700
if they had to send it in for repair or something

0:07:07.700,0:07:09.700
and

0:07:09.700,0:07:12.500
and that kind of approach really worked well

0:07:12.500,0:07:14.500
so I think we really had a lot of

0:07:14.500,0:07:16.500
people, lot of users running

0:07:16.500,0:07:18.500
in Debian in those kind of NAS devices

0:07:18.500,0:07:20.860
and it was really easy to do.

0:07:20.860,0:07:22.580
You get a firmware image,

0:07:22.580,0:07:25.380
you connect to the installer via ssh,

0:07:25.380,0:07:27.380
and it just works, it's a normal

0:07:27.380,0:07:28.620
debian-installer, the way

0:07:28.620,0:07:30.620
everybody knows it,

0:07:30.620,0:07:32.620
because some of the other distros

0:07:32.620,0:07:33.820
they basically provide, like,

0:07:33.820,0:07:35.240
tarballs and instructions

0:07:35.240,0:07:37.240
so you need to partition a disk,

0:07:37.240,0:07:39.240
need to un-tar it,

0:07:39.240,0:07:41.240
you need to change those files,

0:07:41.240,0:07:43.240
and even if it sounds simple,

0:07:43.240,0:07:45.240
it's so many steps that

0:07:45.240,0:07:47.620
you always... you often get something wrong

0:07:47.620,0:07:50.380
and then you put the drive into the

0:07:50.380,0:07:52.380
NAS device, and it doesn't boot, and you don't know why

0:07:52.380,0:07:54.800
where did you make that mistake,

0:07:54.800,0:07:56.000
which step

0:07:56.000,0:07:58.000
and you basically have to start from scratch

0:07:58.000,0:08:00.440
so Debian really provided something unique

0:08:00.440,0:08:02.440
by adding

0:08:02.440,0:08:04.440
the debian-installer support

0:08:04.440,0:08:06.440
but anyway, that's the way

0:08:06.440,0:08:08.440
it sort of used to work.

0:08:08.440,0:08:10.440
Nowadays, with a lot of those bareboard

0:08:10.440,0:08:12.440
it's much easier

0:08:12.440,0:08:14.440
I'll get to that.

0:08:15.180,0:08:18.100
So at the moment there are three different ARM ports:

0:08:18.100,0:08:20.100
There is the old armel

0:08:20.100,0:08:22.100
which used to be the "newer" ARM

0:08:22.100,0:08:24.820
and now it's old,

0:08:24.820,0:08:26.820
and one of the discussions

0:08:26.820,0:08:28.820
that we are probably going to have later today on the BoF

0:08:28.820,0:08:31.220
is about, should we remove that

0:08:31.220,0:08:33.220
after Stretch.

0:08:33.220,0:08:36.440
There is armhf and the arm64

0:08:37.640,0:08:40.539
and we get basically the question I hope to answer.

0:08:40.539,0:08:43.299
If, you know, device A works,

0:08:43.299,0:08:45.300
I have a device which is really similar,

0:08:45.300,0:08:47.300
but it doesn't work. Why is that?

0:08:49.300,0:08:51.300
So, heh,

0:08:51.300,0:08:53.300
There have been a lot of changes

0:08:53.300,0:08:58.120
in various upstream projects, specially

0:08:58.120,0:09:00.120
the kernel and U-boot

0:09:00.120,0:09:02.120
that really make things easier.

0:09:02.120,0:09:04.120
So, in the past

0:09:04.120,0:09:07.260
we basically had

0:09:07.260,0:09:09.260
a kernel image

0:09:09.260,0:09:10.780
for each platform,

0:09:10.780,0:09:12.780
where a platform is basically like

0:09:12.780,0:09:14.780
a SSE family

0:09:14.780,0:09:17.660
and there would be a different image

0:09:17.660,0:09:21.540
because ARM takes a long time

0:09:21.540,0:09:23.540
to compile, there was always some debate

0:09:23.540,0:09:26.100
about adding a new platform

0:09:26.100,0:09:28.100
because there would be a new

0:09:28.100,0:09:30.600
image flavor, which takes some time,

0:09:31.740,0:09:33.540
and that was just really like,

0:09:33.540,0:09:36.280
we couldn't just have one ARM kernel

0:09:36.280,0:09:38.280
which works everywhere.

0:09:38.280,0:09:40.280
And a lot of people didn't understand

0:09:40.280,0:09:42.280
why you had a different kernel

0:09:42.280,0:09:44.280
because different platforms,

0:09:44.280,0:09:48.040
although there has been a lot of progress upstream,

0:09:48.040,0:09:51.580
at least nowadays, with armhf

0:09:51.580,0:09:54.020
and with arm64

0:09:54.020,0:09:56.020
we just have one kernel.

0:09:57.340,0:09:59.980
And upstream basically

0:09:59.980,0:10:02.740
Maybe some of you remember the rant

0:10:02.740,0:10:04.740
by Niels about

0:10:04.740,0:10:06.740
the ARM people doing everything

0:10:06.740,0:10:08.180
in different ways,

0:10:08.180,0:10:10.180
and there has been a lot of standarization

0:10:10.180,0:10:12.180
over the years.

0:10:12.180,0:10:14.180
Basically, the other thing is

0:10:14.180,0:10:16.180
there used to be for each device

0:10:16.180,0:10:18.180
there was a board file

0:10:18.180,0:10:20.180
it was like a C file

0:10:20.180,0:10:22.580
to initialize the different components,

0:10:22.580,0:10:24.580
and the boot loader would

0:10:24.580,0:10:27.660
pass the machine ID to the kernel,

0:10:27.660,0:10:30.380
and it would load that boot file.

0:10:30.380,0:10:32.380
And nowadays,

0:10:32.380,0:10:34.380
there is basically a

0:10:34.380,0:10:36.380
device tree in the kernel,

0:10:36.380,0:10:38.380
which is a description of the hardware

0:10:40.040,0:10:41.800
and it will basically compile it

0:10:41.800,0:10:44.580
to, like, a binary blob, the .dtb.

0:10:44.580,0:10:46.580
And, so, basically you just need

0:10:46.580,0:10:48.580
the kernel image, and

0:10:48.580,0:10:51.200
the .dtb, which is hardware-specific,

0:10:51.200,0:10:53.200
and then it boots.

0:10:53.200,0:10:55.640
And obviously, for us in Debian

0:10:55.640,0:10:57.640
that makes it much much easier

0:10:57.640,0:11:00.540
to support a lot of devices.

0:11:01.960,0:11:04.560
The other thing that changed in U-boot,

0:11:06.040,0:11:09.080
when you install the Debian kernel image,

0:11:09.080,0:11:10.720
it creates

0:11:10.720,0:11:13.900
the vmlinux file

0:11:13.900,0:11:16.740
and also the RAM disk

0:11:16.740,0:11:18.740
but with U-boot,

0:11:18.740,0:11:20.740
you couldn't actually load those files

0:11:20.740,0:11:22.740
correctly. You basically

0:11:22.740,0:11:25.840
had to wrap them in a U-boot image

0:11:25.840,0:11:28.420
and it's not really hard

0:11:28.420,0:11:31.440
it's just the command initram,

0:11:31.440,0:11:33.440
but all of the different devices had

0:11:33.440,0:11:34.940
different load addresses,

0:11:34.940,0:11:36.940
and, again, that's hardware-specific knowledge

0:11:36.940,0:11:39.360
that flash-kernel needed to know.

0:11:39.360,0:11:40.820
And nowadays,

0:11:40.820,0:11:42.720
there is a command which

0:11:42.720,0:11:44.720
directly loads the kernel,

0:11:44.720,0:11:48.380
so that, again, was a step to make things easier.

0:11:48.380,0:11:52.320
And the last thing which really made

0:11:52.320,0:11:54.320
things easier is distro support

0:11:54.320,0:11:56.320
in U-boot.

0:11:56.320,0:11:58.320
So, basically, in the past

0:11:58.320,0:12:00.320
every U-boot, every

0:12:00.320,0:12:02.320
devices in U-boot,

0:12:02.320,0:12:04.320
booted in a different way,

0:12:05.240,0:12:08.700
just in terms on where would it load

0:12:08.700,0:12:10.700
the file from, or

0:12:10.700,0:12:12.700
what variables would it use, and

0:12:12.700,0:12:14.700
nowadays there is something called distro-support

0:12:14.700,0:12:16.700
which is basically a standardized way

0:12:16.700,0:12:18.700
to boot a Linux distro

0:12:19.300,0:12:21.660
with U-boot.

0:12:21.660,0:12:23.660
There are basically

0:12:23.660,0:12:25.660
two ways, either can

0:12:25.660,0:12:27.660
read a config file,

0:12:27.660,0:12:29.660
or it can basically run a

0:12:29.660,0:12:31.660
boot script, and that's what

0:12:31.660,0:12:33.660
we use in Debian, so we basically have

0:12:33.660,0:12:35.660
a generic boot script

0:12:35.660,0:12:38.100
which loads the kernel,

0:12:38.100,0:12:40.100
loads the ramdisk, the .dtb,

0:12:40.100,0:12:42.100
and boots Debian.

0:12:42.100,0:12:44.100
It can use the generic

0:12:44.100,0:12:46.100
bootscript in almost all

0:12:46.100,0:12:47.860
of the modern devices.

0:12:47.860,0:12:49.860
So nowadays, because of that,

0:12:49.860,0:12:51.860
it's much more standard, and

0:12:51.860,0:12:53.860
it's much easier to support

0:12:53.860,0:12:56.440
those devices.

0:12:56.440,0:12:59.980
So here are some examples of flash-kernel

0:12:59.980,0:13:02.800
So, basically, flash-kernel has like a database

0:13:02.800,0:13:04.800
of devices which it supports

0:13:04.800,0:13:07.580
so it's like the machine entry

0:13:07.580,0:13:09.580
in /proc/cpuinfo,

0:13:09.580,0:13:11.960
and then the kernel flavors

0:13:11.960,0:13:13.960
it can run

0:13:13.960,0:13:15.960
and, so, this one is

0:13:15.960,0:13:17.960
an old device, it still uses

0:13:17.960,0:13:19.960
a board file, and it

0:13:19.960,0:13:22.400
needs the U-boot wrapper,

0:13:22.400,0:13:24.400
So...

0:13:24.400,0:13:27.180
You are basically setting the machine ID

0:13:27.180,0:13:29.840
those are the flash partitions

0:13:29.840,0:13:31.840
where the kernel and the

0:13:31.840,0:13:33.840
ramdisk are stored, and

0:13:33.840,0:13:35.660
that's the load address for the

0:13:35.660,0:13:37.660
U-boot wrapper

0:13:39.660,0:13:43.120
And, now, that's a device

0:13:43.120,0:13:45.120
which used to have

0:13:45.120,0:13:47.120
a boot file,

0:13:47.120,0:13:49.120
and which then migrated

0:13:49.120,0:13:51.120
to a .dtb,

0:13:51.120,0:13:53.120
so basically, heh,

0:13:53.120,0:13:56.160
that was really really painful for Debian

0:13:56.160,0:13:58.800
so, basically, the kernel people said

0:13:58.800,0:14:00.800
"Oh, you are going to move to device tree,

0:14:00.800,0:14:02.060
so don't worry,

0:14:02.060,0:14:04.460
we are not gonna remove those old board files,

0:14:04.460,0:14:06.460
you can still use them."

0:14:06.460,0:14:08.800
And then, a few years later they realized

0:14:08.800,0:14:11.240
it's really hard to keep both alive,

0:14:11.240,0:14:13.760
and they got rid of the board files.

0:14:13.760,0:14:16.360
And that was really painful to us

0:14:16.360,0:14:18.820
because we had to migrate

0:14:18.820,0:14:20.820
So you can see,

0:14:20.820,0:14:23.500
here, a kernel version,

0:14:23.500,0:14:25.500
and so, from that kernel on,

0:14:25.500,0:14:27.500
you needed to use the new way.

0:14:29.060,0:14:33.240
And one of the reasons it was painful

0:14:33.240,0:14:35.780
specially on the QNAP devices

0:14:35.780,0:14:38.400
is because with

0:14:38.400,0:14:40.400
they actually have two different CPUs

0:14:40.400,0:14:42.400
so there are different barriers

0:14:42.400,0:14:44.400
and whilst the board files,

0:14:44.400,0:14:46.400
the same board file worked

0:14:46.400,0:14:48.400
regardless of the CPU,

0:14:48.400,0:14:51.240
because of the way the device tree worked

0:14:51.240,0:14:53.240
it actually needed two different device trees

0:14:53.240,0:14:55.240
depending on the CPU

0:14:55.600,0:14:59.320
so now we basically, you know, something that just worked,

0:14:59.320,0:15:01.320
you know, it used to work fine,

0:15:01.320,0:15:03.320
you just had one kernel

0:15:03.320,0:15:05.740
with the machine ID

0:15:05.740,0:15:06.920
at least would work,

0:15:06.920,0:15:09.620
and somehow with the device tree

0:15:09.620,0:15:11.620
we needed to figure out which one

0:15:11.620,0:15:13.620
we need, and so

0:15:13.620,0:15:16.960
[?] fortunately did all of that work.

0:15:16.960,0:15:18.960
So that's actually a script that runs

0:15:18.960,0:15:20.960
to figure out which device tree

0:15:20.960,0:15:22.960
that particular device needs.

0:15:26.660,0:15:29.160
So now, that's actually

0:15:29.160,0:15:31.160
the reason I want to show this is

0:15:31.160,0:15:33.160
how simpler things are these days, so

0:15:33.160,0:15:35.160
this is an example from

0:15:35.160,0:15:38.600
[?] platform, which uses distro-support,

0:15:38.600,0:15:40.960
and the only thing you really need is

0:15:40.960,0:15:42.960
a machine entry with the name,

0:15:42.960,0:15:44.960
and then

0:15:44.960,0:15:46.960
like the kernel-flavor,

0:15:46.960,0:15:48.960
but that's the same for...

0:15:48.960,0:15:50.960
you know, there is only one kernel flavor.

0:15:52.740,0:15:55.380
And then, the device tree ID

0:15:56.480,0:15:58.360
and, again, all of that stuff is generic,

0:15:58.360,0:16:00.760
so it just uses the generic bootscript,

0:16:02.180,0:16:03.780
and the generic boot path,

0:16:03.780,0:16:05.780
so basically

0:16:05.780,0:16:07.780
all it pretty much needs for

0:16:07.780,0:16:09.780
a new device is, like,

0:16:09.780,0:16:11.780
you know,

0:16:11.780,0:16:13.780
these two entries,

0:16:13.780,0:16:15.780
it's really really simple.

0:16:18.780,0:16:21.260
So here, I just wanted to

0:16:21.260,0:16:23.260
tell about the different ARM ports and...

0:16:24.200,0:16:26.940
So, for me it was really hard to structure this, because

0:16:26.940,0:16:29.460
those changes in the kernel

0:16:29.460,0:16:31.460
and U-boot

0:16:31.460,0:16:34.640
you know, happen independent of our ARM ports,

0:16:36.100,0:16:37.720
But at the same time, because

0:16:37.720,0:16:40.340
because the armhf world is much newer,

0:16:40.340,0:16:42.340
it works in a different way.

0:16:42.340,0:16:45.200
So, basically, the armel

0:16:45.200,0:16:49.480
we still have different flavors

0:16:49.480,0:16:54.000
but we have already combined the orion and the kirkwood

0:16:54.000,0:16:56.000
into one marvell flavor,

0:16:56.000,0:16:59.060
and we have the versatile one.

0:17:00.860,0:17:03.760
So one of the problems we have in armel is that

0:17:03.760,0:17:05.760
a lot of those NAS devices

0:17:05.760,0:17:07.760
boot from flash

0:17:07.760,0:17:10.180
and they only have, some of them,

0:17:10.180,0:17:12.180
3MB for the kernel,

0:17:12.180,0:17:15.119
which used to be a lot of space

0:17:15.119,0:17:16.660
but nowadays it's not.

0:17:16.720,0:17:19.380
So that really puts a lot of restrictions

0:17:19.380,0:17:21.380
so basically we disable some stuff

0:17:21.380,0:17:23.380
from armel

0:17:23.380,0:17:27.180
but I think that armel is really really widely used

0:17:27.180,0:17:29.180
because of those NAS devices,

0:17:29.180,0:17:31.180
but I think they are slowly getting old,

0:17:31.180,0:17:33.680
but there are still a lot of people that use them.

0:17:33.680,0:17:37.220
Like I said, it requires the U-boot image

0:17:37.700,0:17:40.380
Originally, we used board files

0:17:40.380,0:17:43.360
and device tree, most of them

0:17:43.360,0:17:45.940
have switched over to device tree

0:17:45.940,0:17:48.580
even if some of them still use board files

0:17:48.580,0:17:51.540
and adding a new device requires

0:17:51.540,0:17:54.200
a number of changes in the installer.

0:17:54.200,0:17:57.100
So basically, you needed to map

0:17:57.100,0:17:59.100
the device to

0:17:59.100,0:18:01.100
the complete image

0:18:01.100,0:18:04.200
and there are just there a couple of

0:18:04.200,0:18:06.260
things, so basically, any one device

0:18:06.280,0:18:08.200
you have to change like five different

0:18:08.200,0:18:10.200
places in the installer.

0:18:10.200,0:18:12.200
And it was quite confusing for people who wanted

0:18:12.200,0:18:14.200
to add new devices

0:18:14.200,0:18:17.080
Because it isn't really documented very well

0:18:18.480,0:18:21.400
So some examples are a list of three people

0:18:21.400,0:18:23.400
who are involved in that port

0:18:23.400,0:18:25.400
So, Roger is someone

0:18:25.400,0:18:27.400
who is quite new, and who really got

0:18:27.400,0:18:29.920
involved into porting those old devices.

0:18:31.440,0:18:34.560
And so, armhf is much nicer,

0:18:34.560,0:18:36.560
so the majority of

0:18:36.560,0:18:39.140
devices support distro-support.

0:18:40.440,0:18:42.700
And the other thing we do

0:18:44.700,0:18:47.040
is, for some of the devices

0:18:47.040,0:18:49.040
we provide SD card images,

0:18:49.040,0:18:51.040
which contain

0:18:51.040,0:18:55.160
U-boot and the Debian installer

0:18:55.160,0:18:57.160
So basically Vagrant

0:18:57.160,0:18:59.960
maintains U-boot in Debian, and

0:18:59.960,0:19:01.960
a lot of those devices are supported

0:19:01.960,0:19:03.960
in U-boot in Debian.

0:19:03.960,0:19:05.960
So we just

0:19:05.960,0:19:07.960
provide an SD image, so you can just

0:19:07.960,0:19:10.480
store it in the SD card, you put it in

0:19:10.480,0:19:12.940
and, because of the distro-support,

0:19:12.940,0:19:14.940
it just loads debian-installer,

0:19:14.940,0:19:17.840
you do the installation, reboot,

0:19:17.840,0:19:19.840
and things just work.

0:19:19.840,0:19:21.840
So I think it really has gone

0:19:21.840,0:19:25.200
...Come a long way.

0:19:27.200,0:19:29.820
So nowadays,

0:19:29.820,0:19:31.820
adding a new device

0:19:31.820,0:19:34.140
requires much fewer changes

0:19:34.140,0:19:36.140
than it used to be.

0:19:36.140,0:19:40.980
Because as everything uses the same, like, one kernel flavor,

0:19:40.980,0:19:43.900
you don't need to patch all those different places anymore,

0:19:45.020,0:19:47.740
and because of distro-support, it just works.

0:19:47.740,0:19:52.280
You can pretty much use the generic bootscript.

0:19:54.140,0:19:56.140
So, arm64.

0:19:56.140,0:19:58.300
So, the problem until recently

0:19:58.300,0:20:00.300
is that there simply wasn't any hardware

0:20:00.300,0:20:02.300
that people could buy.

0:20:02.300,0:20:04.300
And that's changing rapidly now

0:20:05.640,0:20:07.540
[?]

0:20:07.540,0:20:10.280
We have for example the Raspberry Pi 3

0:20:10.280,0:20:13.960
which uses a 64 bit CPU

0:20:13.960,0:20:16.620
but the software it ships is only 32 bits,

0:20:16.620,0:20:18.620
but most of the work

0:20:18.620,0:20:20.620
is now

0:20:20.620,0:20:23.680
upstreamed to run 64 bit on it

0:20:25.000,0:20:27.600
and there are a lot of

0:20:28.120,0:20:31.500
devices which sort of work but not quite

0:20:31.960,0:20:35.660
but anyway, so the idea for arm64

0:20:35.660,0:20:37.660
is that a lot of the

0:20:37.660,0:20:39.660
new hardware

0:20:39.660,0:20:41.660
specially on the server side

0:20:41.660,0:20:43.660
will use UEFI,

0:20:43.660,0:20:45.660
and so you basically just

0:20:46.380,0:20:48.100
it just works like a PC.

0:20:48.100,0:20:50.100
So you have Grub,

0:20:50.100,0:20:53.020
you can run debian-installer from Grub

0:20:53.020,0:20:54.900
and you get Grub afterwards.

0:20:54.920,0:20:56.480
And just boots like a PC,

0:20:56.480,0:20:59.860
and Steve has done a lot of work in that area,

0:20:59.860,0:21:01.860
And in theory,

0:21:01.860,0:21:03.860
it should just work out of the box.

0:21:03.860,0:21:06.220
So, if it uses

0:21:06.220,0:21:08.220
UEFI, we don't need to add anything.

0:21:08.220,0:21:10.220
It just works.

0:21:10.220,0:21:12.220
There's nothing to do.

0:21:13.400,0:21:15.300
At least, that's the theory.

0:21:15.300,0:21:17.300
So, what I found is

0:21:17.300,0:21:19.300
...I made a disclaimer, so

0:21:19.300,0:21:21.300
...Assuming the kernel

0:21:21.300,0:21:23.300
you know, kernel support and stuff...

0:21:23.300,0:21:25.300
...To be honest,

0:21:25.300,0:21:28.160
right now, that's a big assumption.

0:21:28.160,0:21:30.160
So I've been playing with a few

0:21:30.160,0:21:33.200
64 bit ARM boards

0:21:33.200,0:21:36.580
and basically, what I found is

0:21:36.580,0:21:39.420
there is some support upstream,

0:21:39.420,0:21:41.420
so I can boot a kernel,

0:21:41.420,0:21:43.700
but, oh! There is no USB support!

0:21:43.700,0:21:45.280
there is no Wifi support!

0:21:45.280,0:21:48.060
So I cannot actually do anything with it.

0:21:48.060,0:21:51.580
But I can get to something that

0:21:51.580,0:21:54.980
because arm64 is still farily new.

0:21:54.980,0:21:57.640
And there is a lot of work going on upstream

0:21:57.640,0:22:00.000
to support the various platforms.

0:22:00.000,0:22:03.300
So, I think over time that's really going to be much better.

0:22:05.300,0:22:09.440
Even though that UEFI idea is there

0:22:09.440,0:22:11.200
in reality,

0:22:11.200,0:22:13.200
we are going to see different solutions

0:22:13.200,0:22:15.200
for arm64.

0:22:15.200,0:22:18.240
So we are going to see UEFI, in particular on servers,

0:22:18.240,0:22:20.240
but we will also see U-boot.

0:22:20.240,0:22:22.700
So a lot of those bare boards

0:22:22.700,0:22:24.700
they have U-boot.

0:22:24.700,0:22:26.700
And, so, right now

0:22:26.700,0:22:28.700
we can use the distro support

0:22:28.700,0:22:31.980
and I think that it works pretty well.

0:22:31.980,0:22:34.320
But one thing that SuSE has done

0:22:34.320,0:22:36.320
so, they just had the same issue,

0:22:36.320,0:22:38.320
they want to support all those devices

0:22:38.320,0:22:41.240
but they just want to use the same mechanism everywhere,

0:22:41.240,0:22:43.420
so they have actually implemented

0:22:43.420,0:22:46.020
UEFI on top of U-boot,

0:22:46.020,0:22:49.240
so you can basically use U-boot to load Grub

0:22:49.240,0:22:51.720
and then you have Grub

0:22:51.720,0:22:54.320
so I think that's something we need to figure out;

0:22:54.320,0:22:56.840
do we want to stay with distro-support?

0:22:56.840,0:22:58.840
do we want to use

0:22:58.840,0:23:01.140
UEFI on top of U-boot?

0:23:01.140,0:23:03.140
is that something we want to

0:23:03.140,0:23:05.140
give users the option?

0:23:05.140,0:23:08.020
And then, Fastboot

0:23:08.020,0:23:10.140
is something used

0:23:10.140,0:23:12.140
in the Android world

0:23:12.140,0:23:14.760
and a lot of those, like, I see a lot of

0:23:14.760,0:23:17.800
both bare boards, but also

0:23:17.800,0:23:19.940
game consoles and stuff, which

0:23:19.940,0:23:21.940
which are sort of Android-oriented,

0:23:21.940,0:23:23.940
but which can also run normal Linux,

0:23:23.940,0:23:26.840
and they will use like Fastboot or something.

0:23:26.840,0:23:30.120
And there are tons of other bootloaders out there

0:23:30.120,0:23:32.540
But I would definitively say, like, the good ones

0:23:32.540,0:23:34.540
are UEFI and U-boot

0:23:36.540,0:23:40.320
So, I gave a similar talk a few weeks ago

0:23:40.320,0:23:43.060
and turns out, a lot of non-free

0:23:43.060,0:23:45.060
firmware, like, "can I

0:23:45.060,0:23:46.920
run that stuff, you know,

0:23:46.920,0:23:48.920
purely with free software?"

0:23:48.920,0:23:51.260
...And...

0:23:51.260,0:23:52.980
So, the thing with ARM is that

0:23:52.980,0:23:54.980
there are a lot of different platforms

0:23:54.980,0:23:56.980
I'm not sure about all of them,

0:23:56.980,0:23:59.460
but some of the platforms

0:23:59.460,0:24:01.960
I looked at, yes, you

0:24:01.960,0:24:05.320
do need some... There is always something propietary.

0:24:06.460,0:24:08.420
So in a lot of cases

0:24:08.420,0:24:10.420
I see where you have

0:24:10.420,0:24:13.580
you use the proprietary first-stage boot loader,

0:24:13.580,0:24:16.160
so the Raspberry Pi is an example,

0:24:16.160,0:24:18.540
so, I don't actually have a Raspberry Pi, but

0:24:18.540,0:24:20.540
the way I understand it is

0:24:20.540,0:24:23.060
you basically put some boot files

0:24:23.060,0:24:25.060
in an SD card,

0:24:25.060,0:24:27.060
and they are proprietary, and

0:24:27.060,0:24:29.060
then they load the kernel.

0:24:29.060,0:24:31.500
Or in case of [?]

0:24:31.500,0:24:33.500
supported in Debian,

0:24:33.500,0:24:35.500
the first stage boot loader would basically

0:24:35.500,0:24:37.820
be used to run U-boot,

0:24:37.820,0:24:40.140
and then we could use U-boot, and

0:24:40.140,0:24:43.880
the U-boot support all of it is free software,

0:24:43.880,0:24:46.440
but the first stage boot loader isn't.

0:24:46.440,0:24:49.820
I have had, there are some people

0:24:49.820,0:24:51.820
working on a free replacement for

0:24:51.820,0:24:53.820
the Raspberry Pi, though.

0:24:53.820,0:24:55.820
With nVidia Tegra,

0:24:55.820,0:24:57.640
which is

0:24:57.640,0:24:59.640
something I'm working on at the moment

0:24:59.640,0:25:03.040
you also have a tiny first stage boot loader,

0:25:03.040,0:25:05.940
but then again, you have U-boot, which is free,

0:25:05.940,0:25:08.980
and in that case, you also have some firmware

0:25:08.980,0:25:10.980
images for the GPU

0:25:10.980,0:25:13.320
and for other stuff.

0:25:13.320,0:25:15.980
For the Dragon board,

0:25:15.980,0:25:18.980
The Dragon board sounded really interesting

0:25:18.980,0:25:20.820
because it actually has a

0:25:20.820,0:25:22.820
a graphics chip

0:25:22.820,0:25:25.120
which can be used with free software,

0:25:25.120,0:25:27.920
so that sounded pretty cool,

0:25:27.920,0:25:30.340
but again, it has a

0:25:30.340,0:25:32.460
proprietary first

0:25:32.460,0:25:34.460
stage boot loader,

0:25:34.460,0:25:36.460
and then there is a second stage boot loader

0:25:36.460,0:25:38.460
which is actually open source

0:25:38.460,0:25:41.520
and then there's actually a U-boot of that,

0:25:41.520,0:25:44.600
and then you have some

0:25:44.600,0:25:46.600
binary blobs which

0:25:46.600,0:25:49.900
also need to be installed in flash to work properly

0:25:49.900,0:25:51.900
On the Marvell side, I'm

0:25:51.900,0:25:53.900
not really aware of anything.

0:25:53.900,0:25:55.900
I have never needed to flash anything

0:25:55.900,0:25:57.900
proprietary, but

0:25:57.900,0:25:59.900
I'm not sure how U-boot gets started

0:25:59.900,0:26:01.900
on Marvell, so maybe there is something.

0:26:04.380,0:26:08.180
So the future is all... So NAS devices are

0:26:08.180,0:26:09.800
like I said, that's something that's

0:26:09.800,0:26:11.800
really been popular in Debian.

0:26:11.800,0:26:15.480
Specially on the QNAP devices,

0:26:15.480,0:26:17.480
but the problem is, so, QNAP...

0:26:17.480,0:26:19.480
so the devices we currently support

0:26:19.480,0:26:21.480
are pretty old

0:26:21.480,0:26:23.480
nowadays,

0:26:23.480,0:26:25.480
and they have some newer devices,

0:26:25.480,0:26:27.740
but they are not properly supported

0:26:27.740,0:26:29.740
in the upstream kernel.

0:26:29.740,0:26:31.740
So, I have no plans

0:26:31.740,0:26:33.740
to support Debian on those.

0:26:33.740,0:26:36.920
I recently did some work on

0:26:36.920,0:26:38.920
Seagate NAS devices

0:26:38.920,0:26:42.500
which are actually pretty interesting

0:26:42.500,0:26:44.500
but again, they will go out of date

0:26:44.500,0:26:46.500
already,

0:26:46.500,0:26:48.500
and then there's the whole 64 bit ARM

0:26:48.500,0:26:50.500
so I think people are really waiting

0:26:50.500,0:26:52.500
for arm64 servers

0:26:52.500,0:26:54.720
I think there's going to be a whole lot of

0:26:54.720,0:26:56.720
work on that area.

0:26:56.720,0:26:59.460
And then, there are all of those development boards

0:26:59.460,0:27:01.460
Raspberry Pi,

0:27:01.460,0:27:03.460
Pine64,

0:27:03.460,0:27:06.200
Allwinder,

0:27:06.200,0:27:08.900
Basically, all of them

0:27:08.900,0:27:10.900
sound exciting, but if you

0:27:10.900,0:27:12.700
look at them, all of them

0:27:12.700,0:27:14.700
have some upstream issues, so it's...

0:27:14.700,0:27:18.340
It is really quite frustrating at the moment.

0:27:18.340,0:27:20.340
But I think things are really

0:27:20.340,0:27:22.800
moving [?]

0:27:22.800,0:27:25.880
And then there's this 96Board initiative,

0:27:26.060,0:27:28.540
which is actually done by Linaro,

0:27:28.540,0:27:30.700
and, so, Linaro supports

0:27:30.700,0:27:32.880
Linux on ARM, so you'd think, "wow,

0:27:32.880,0:27:34.880
there are some really nice boards coming out!"

0:27:34.880,0:27:37.340
and they differentiated

0:27:37.340,0:27:39.940
between the consumer edition and the enterprise edition

0:27:39.940,0:27:42.880
beside, I bought some consumer-edition boards,

0:27:42.880,0:27:45.540
and it's really horrible.

0:27:45.540,0:27:48.220
So first of all, I had to spend like half a day

0:27:48.220,0:27:50.220
just putting the components

0:27:50.660,0:27:53.100
because it uses, like, a nonstandard power supply,

0:27:53.100,0:27:55.100
a nonstandard serial console,

0:27:55.100,0:27:57.820
so finally I found

0:27:57.820,0:28:00.280
all the pieces I needed, and then

0:28:00.280,0:28:02.820
I was expecting, well, it's from Linaro!

0:28:02.820,0:28:05.140
Surely everything just works upstream!

0:28:05.140,0:28:07.600
But it doesn't. It's like

0:28:07.600,0:28:09.600
yes, I can boot the Linux kernel,

0:28:09.600,0:28:11.600
but there's no USB, there's no

0:28:11.600,0:28:13.600
Wifi, no nothing...

0:28:15.080,0:28:17.080
So, yes, that's a little bit frustrating.

0:28:17.080,0:28:19.140
On the enterprise edition,

0:28:19.140,0:28:21.140
I think that looks more interesting.

0:28:21.140,0:28:23.140
You know, that's more standardized.

0:28:23.140,0:28:26.620
But again, there have been some delays.

0:28:28.620,0:28:32.620
[audience; unintellegible]

0:28:32.620,0:28:34.620
Yes, OK.

0:28:34.620,0:28:36.620
So that would be interesting to see.

0:28:36.620,0:28:39.420
So, the questions that I actually have nowadays

0:28:39.420,0:28:41.420
is, so...

0:28:41.420,0:28:43.420
Because of those changes,

0:28:43.420,0:28:45.420
because of having, you know,

0:28:45.420,0:28:47.420
a mode of U-boot, most of those

0:28:47.420,0:28:49.420
new devices having a U-boot

0:28:49.420,0:28:50.880
with distro-support,

0:28:50.880,0:28:53.040
having a kernel which, you know,

0:28:53.040,0:28:55.040
one kernel image that works on all of those

0:28:55.040,0:28:57.040
devices which are supported,

0:28:57.040,0:28:59.560
it's really easy to support

0:28:59.560,0:29:01.560
a new device?

0:29:01.560,0:29:04.100
As long as it's supported by the kernel.

0:29:04.100,0:29:06.360
But, at the same time, I think it's a big

0:29:06.360,0:29:07.740
challenge for Debian.

0:29:07.740,0:29:10.280
Because right now, if you look at armhf,

0:29:10.280,0:29:12.220
we basically say, well,

0:29:12.220,0:29:14.220
hint the installer,

0:29:14.220,0:29:16.220
and if there's a device tree,

0:29:16.220,0:29:18.220
it's probably going to work.

0:29:18.220,0:29:21.180
But, what does that mean, right?

0:29:23.180,0:29:25.180
And...

0:29:25.180,0:29:28.140
which really work, which means,

0:29:28.140,0:29:29.880
so, we have Vagrant

0:29:29.880,0:29:31.880
having U-boot support

0:29:31.880,0:29:33.880
in Debian, we have

0:29:33.880,0:29:36.240
people testing debian-installer,

0:29:36.240,0:29:38.240
testing the Debian kernel, so we have

0:29:38.240,0:29:40.820
devices which really work, well supported,

0:29:40.820,0:29:43.280
and then we have some devices

0:29:43.280,0:29:45.580
on the other hand where, well, yes,

0:29:45.580,0:29:47.580
there is a device tree, but no one

0:29:47.580,0:29:49.580
has ever tried it. And

0:29:49.580,0:29:51.580
at the moment, we have no way

0:29:51.580,0:29:54.140
for users to differentiate

0:29:54.140,0:29:56.540
those use case... Those

0:29:56.540,0:29:58.540
support levels.

0:29:58.540,0:30:00.540
So I'm wondering if we need

0:30:00.540,0:30:02.540
like a table,

0:30:02.540,0:30:04.540
somewhere where maybe

0:30:04.540,0:30:06.540
some support levels, like green, yellow...

0:30:06.540,0:30:08.120
red?

0:30:08.120,0:30:10.120
Where green is, "yes, we have Debian

0:30:10.120,0:30:12.120
people who have

0:30:12.120,0:30:14.120
testing that stuff",

0:30:14.120,0:30:16.120
yellow would be, "well, we have heard some report

0:30:16.120,0:30:18.120
that it might work", and

0:30:18.120,0:30:20.120
green is, you know, doesn't work,

0:30:20.120,0:30:22.120
or we haven't tried that it works.

0:30:22.120,0:30:24.120
Maybe we need something like that.

0:30:24.120,0:30:26.360
But right now,

0:30:26.360,0:30:28.360
I see from users

0:30:30.360,0:30:32.360
"I want to run Debian on my ARM device", and

0:30:32.360,0:30:35.380
they don't know if it's going to work.

0:30:35.380,0:30:37.380
Yes, then...

0:30:37.380,0:30:43.400
[audience; unintellegible]

0:30:43.400,0:30:45.400
Yes, so Ben is saying we also need

0:30:45.400,0:30:47.400
to track what the earliest and the latest

0:30:47.400,0:30:49.620
kernel versions that there have been tested.

0:30:49.620,0:30:51.800
So I think we really need to

0:30:51.800,0:30:53.800
come up with some criteria

0:30:53.800,0:30:58.920
to have, you know, define those kernel support levels that indicate that

0:30:58.920,0:31:01.920
And yes, the other question is related

0:31:01.920,0:31:03.260
to, with all those boards,

0:31:03.260,0:31:05.260
how do we actually test them?

0:31:05.260,0:31:07.000
So, I keep --

0:31:07.000,0:31:10.100
it's really... remember [?]

0:31:10.100,0:31:12.100
which is great, but also acknowledge

0:31:12.100,0:31:14.100
those boards, they are so cheap!

0:31:14.100,0:31:16.100
so it's like, "oh, there's a new board!

0:31:16.100,0:31:18.100
It's £30! I'll just get it!"

0:31:18.100,0:31:21.020
And then we have, like, those piles of boards

0:31:21.020,0:31:23.020
and realize, well, I don't have time

0:31:23.020,0:31:25.020
for testing all of that stuff!

0:31:25.020,0:31:27.200
I think that's going to be a real challenge.

0:31:27.200,0:31:29.320
hundreds -- I don't know,

0:31:29.320,0:31:31.320
it's really hundreds of boards coming out.

0:31:31.320,0:31:33.900
How do we support all of that?

0:31:35.460,0:31:38.420
So, I think that's the question I wanted to raise,

0:31:38.420,0:31:41.160
and maybe something we can talk about in the BoF

0:31:41.160,0:31:43.380
But yes, I'm obviously

0:31:43.380,0:31:45.380
open for questions now.

0:31:55.520,0:31:57.520
[James / purpleidea:] Hello.

0:31:57.520,0:32:00.200
So, don't quote me exactly,

0:32:00.200,0:32:02.200
so, I believe

0:32:02.200,0:32:04.200
RedHat has this problem as well, obviously,

0:32:04.200,0:32:06.200
I mean, they are obviously more interested in the

0:32:06.200,0:32:08.580
ARM64-only server stuff,

0:32:08.580,0:32:10.580
but I believe the way they are going about it

0:32:10.580,0:32:12.880
maybe it's something could collaborate on

0:32:12.880,0:32:15.080
is, they are trying to make sure and push

0:32:15.080,0:32:17.080
all the vendors to be standardized

0:32:17.080,0:32:19.260
because, as you pointed out,

0:32:19.260,0:32:21.540
it's just not, it's crazy

0:32:21.540,0:32:24.540
with all the different device tree differences and so on,

0:32:24.540,0:32:26.540
so I believe their strategy is to

0:32:26.540,0:32:28.840
work with the vendors, and

0:32:28.840,0:32:30.840
require everything to be upstreamed, and

0:32:30.840,0:32:32.840
no device tree

0:32:32.840,0:32:34.840
specifically, to push everything to just boot

0:32:34.840,0:32:36.840
with one kernel, and so on.

0:32:36.840,0:32:38.840
So maybe that could be

0:32:38.840,0:32:40.840
sacrifice a few of the

0:32:40.840,0:32:42.840
shitty boards, but work with the vendors

0:32:42.840,0:32:45.820
that make the ones that are upstreamed.

0:32:45.820,0:32:47.820
[Martin:] Yes, so I may be mistaken, but

0:32:47.820,0:32:49.820
as far as I know, RedHat

0:32:49.820,0:32:51.620
basically says, "we only support

0:32:51.620,0:32:53.620
UEFI and ACPI"

0:32:53.620,0:32:55.620
and that's fair enough,

0:32:55.620,0:32:57.620
and I think that works for them, because

0:32:57.620,0:32:59.900
it's just the server world they care about,

0:32:59.900,0:33:01.900
but I think in the case of Debian

0:33:01.900,0:33:03.900
there are so many boards out there which

0:33:03.900,0:33:05.900
don't need those specs,

0:33:05.900,0:33:08.600
and we sort of live, like, in the "real world"

0:33:08.600,0:33:10.980
so I don't think we can

0:33:10.980,0:33:12.980
Well -- I know it's different. I mean,

0:33:12.980,0:33:14.980
if RedHat wants to target

0:33:14.980,0:33:16.980
the server people, like, the people

0:33:16.980,0:33:18.980
which give money

0:33:18.980,0:33:20.980
that's fair enough, that makes sense for them

0:33:20.980,0:33:22.980
but Debian, we run everywhere

0:33:22.980,0:33:24.980
so I think we need to support

0:33:24.980,0:33:26.980
all those weird

0:33:26.980,0:33:28.980
cases as well.

0:33:28.980,0:33:30.980
And maybe if it gets too weird,

0:33:30.980,0:33:32.980
I mean,

0:33:32.980,0:33:35.360
I put in some work in the Dragonboard,

0:33:35.360,0:33:37.360
and then I realized,

0:33:37.360,0:33:39.360
am I actually spending the time because

0:33:39.360,0:33:41.360
no one, like, I have heard

0:33:41.360,0:33:43.360
from no one that they have

0:33:43.360,0:33:45.360
that board, I mean, like [?]

0:33:45.360,0:33:47.360
for the Raspberry Pi, but I have heard

0:33:47.360,0:33:49.360
like, pretty much no one has the

0:33:49.360,0:33:51.360
Dragonboard, so maybe,

0:33:51.360,0:33:53.920
...it's not worth my while,

0:33:53.920,0:33:55.920
but if there's a board

0:33:55.920,0:33:57.920
that people want to use it,

0:33:57.920,0:34:00.340
I think we should support it in Debian.

0:34:00.340,0:34:02.340
And we do have the infrastructure

0:34:02.340,0:34:04.340
so we, you know, it doesn't have to be

0:34:04.340,0:34:06.340
UEFI and ACPI,

0:34:06.340,0:34:08.340
we can support other devices, because

0:34:08.340,0:34:10.340
we have done it before.

0:34:10.340,0:34:12.340
But I definitively agree with

0:34:12.340,0:34:14.960
the point about getting more standardization

0:34:14.960,0:34:16.960
and that stuff, so

0:34:16.960,0:34:18.960
I agree, yes.

0:34:20.360,0:34:22.920
And the whole distro-support

0:34:22.920,0:34:25.600
in U-boot, that has really made things easier for us.

0:34:33.219,0:34:35.880
[Phil:] I may begin to say some of the same things Steve has, anyway.

0:34:35.880,0:34:38.500
Steve]: So, yes, on the

0:34:38.500,0:34:41.219
ACPI versus DT thing,

0:34:41.219,0:34:43.219
it's more a question

0:34:43.219,0:34:45.980
of the quality of the implementation of the

0:34:45.980,0:34:48.800
of the firmware,

0:34:48.800,0:34:50.800
and the upstream support that is...

0:34:50.800,0:34:52.800
DT isn't fundamentally

0:34:52.800,0:34:55.260
worse for upstream support

0:34:55.260,0:34:57.780
than ACPI is,

0:34:57.780,0:35:00.980
RedHat are

0:35:00.980,0:35:02.980
have some reasons

0:35:02.980,0:35:04.980
[?] of sensibility,

0:35:04.980,0:35:06.980
but then, it's not

0:35:06.980,0:35:09.380
fundamentally, it doesn't fundamentally stop it

0:35:09.380,0:35:11.380
people supporting it, specially

0:35:11.380,0:35:13.380
a community distro like Debian.

0:35:13.380,0:35:16.340
I was also going to ask Martin,

0:35:16.340,0:35:18.340
have you talked to

0:35:18.340,0:35:20.560
people like kernel CI

0:35:20.560,0:35:24.660
about testing and coverage stuff?

0:35:24.660,0:35:26.660
[Martin:] Yes, not really, but

0:35:26.660,0:35:29.740
I think there are some things we should look into.

0:35:29.740,0:35:31.740
[Steve:] Yes, because the whole --

0:35:31.740,0:35:33.740
Obviously, making sure the kernel boots

0:35:33.740,0:35:35.740
on random hardware

0:35:35.740,0:35:38.080
stuff, is exactly what that's doing

0:35:39.740,0:35:42.360
and there's at least infrastructure there that might be

0:35:42.360,0:35:44.740
nice to play with.

0:35:46.480,0:35:48.480
[Martin:] Yes. I think that's a good idea.

0:35:50.480,0:35:52.480
[sledge:] So, on the whole 96Boards thing,

0:35:52.480,0:35:54.480
sorry!

0:35:54.480,0:35:56.480
Most of the engineers involved

0:35:56.480,0:35:58.480
are totally aware of

0:35:58.480,0:36:00.480
how [?] it really is.

0:36:00.480,0:36:02.480
We tried to tell management

0:36:02.480,0:36:04.480
they would --

0:36:04.480,0:36:06.480
They don't want to listen.

0:36:06.480,0:36:08.480
Umm.. So,

0:36:08.480,0:36:10.480
there has been a huge amount of pushback

0:36:10.480,0:36:13.000
saying, you know, "we're Linaro

0:36:13.000,0:36:15.380
we should make sure this is all upstreamed".

0:36:17.380,0:36:19.380
[Martin:] Well, I am aware

0:36:19.380,0:36:21.380
it's just, Linaro

0:36:21.380,0:36:23.380
has a really good brand,

0:36:23.380,0:36:25.380
so people expect, you know, when I saw

0:36:25.380,0:36:27.380
96Boards it's Linaro,

0:36:27.380,0:36:29.800
obviously that stuff it's going to work!

0:36:29.800,0:36:31.800
and that's why I was really disappointed.

0:36:31.800,0:36:33.800
[Steve:] One positive thing there

0:36:33.800,0:36:35.800
is that the first DE board

0:36:35.800,0:36:38.300
the SoC does basically work upstream

0:36:38.300,0:36:40.440
already with current upstream kernel

0:36:40.440,0:36:42.440
it's not like there's some patches still

0:36:42.440,0:36:44.440
to go in. Apart from the PCI, it should basically

0:36:44.440,0:36:47.400
work... So, hopefully,

0:36:47.400,0:36:49.820
hopefully, that's going to be a much

0:36:49.820,0:36:51.820
less spectacular

0:36:51.820,0:36:53.820
story than the

0:36:53.820,0:36:55.820
consumer-edition boards have been.

0:36:55.820,0:36:57.820
As they are unfortunate.

0:37:01.860,0:37:03.860
[Sledge:] The first EE board

0:37:03.860,0:37:05.860
the [?]board, is due to start shipping

0:37:05.860,0:37:07.860
really soon now.

0:37:07.860,0:37:09.860
There are examples already out there

0:37:09.860,0:37:11.860
with engineers for validation.

0:37:11.860,0:37:14.300
Literally, we are talking the next couple of weeks

0:37:14.300,0:37:16.300
is what I have been told.

0:37:16.300,0:37:18.700
That's the first 96Boards I would

0:37:18.700,0:37:20.700
actually spend any time on at all personally,

0:37:20.700,0:37:23.240
the CE boards are a joke.

0:37:29.020,0:37:31.020
I forgot what else I was going to say. Oh!

0:37:31.020,0:37:33.020
Yes! Then...

0:37:33.020,0:37:35.380
I guess we will go through a lot of this again

0:37:35.380,0:37:37.380
in the ARM BoF later on

0:37:37.380,0:37:39.480
in terms of

0:37:39.480,0:37:41.480
which things we support.

0:37:44.660,0:37:46.660
We will carry on with the discussion.

0:37:54.720,0:37:57.560
[Vagrant:] Um... Is this working?

0:37:57.560,0:37:59.560
Yes, so...

0:37:59.560,0:38:01.560
We have got all this great support for

0:38:01.560,0:38:03.560
distro-boot command and U-boot, and

0:38:03.560,0:38:05.560
now we are starting to get

0:38:05.560,0:38:07.560
to UEFI emulation

0:38:07.560,0:38:09.560
in U-boot, so even for boards

0:38:09.560,0:38:11.560
that don't have UEFI emulation--

0:38:11.560,0:38:13.560
UEFI support, if they support

0:38:13.560,0:38:15.560
U-boot, it might work

0:38:15.560,0:38:17.560
although that means all the standarization

0:38:17.560,0:38:19.560
we worked towards, we throw it away.,

0:38:19.560,0:38:21.560
Meh!

0:38:23.560,0:38:26.300
[Martin:] Yes, I think that's something we need to figure out,

0:38:26.300,0:38:29.240
which one do we want to standardize on,

0:38:29.240,0:38:31.240
or is that something we want to

0:38:31.240,0:38:33.240
leave up to the user.

0:38:33.240,0:38:35.480
but yes,

0:38:35.480,0:38:37.560
I mean, I think one

0:38:37.560,0:38:39.560
I mean, I guess it was

0:38:39.560,0:38:41.560
so confusing, because there are like

0:38:41.560,0:38:43.560
all those different ways, but

0:38:44.920,0:38:46.920
what I really wanted to show is that

0:38:46.920,0:38:48.920
things are getting much more

0:38:48.920,0:38:51.100
standardized and much better.

0:38:51.100,0:38:53.560
So, it used to be really

0:38:53.560,0:38:55.560
pretty horrible, and nowadays,

0:38:55.560,0:38:57.560
you know, if a platform

0:38:57.560,0:38:59.560
uses a modern

0:38:59.560,0:39:01.560
U-boot, if it has

0:39:01.560,0:39:03.560
upstream support, then it is

0:39:03.560,0:39:05.560
actually pretty trivial to add

0:39:05.560,0:39:07.560
Debian support, and

0:39:07.560,0:39:09.560
I think that wasn't the case

0:39:09.560,0:39:10.660
in the past.

0:39:10.660,0:39:12.660
I think Ben had another one?

0:39:20.800,0:39:23.580
[Ben:] So, I'm

0:39:26.540,0:39:29.960
[laughs]

0:39:29.960,0:39:33.280
I'm interested to know how much

0:39:33.280,0:39:36.080
how much interest there is among the ARM porters

0:39:36.080,0:39:38.500
in graphics support.

0:39:38.500,0:39:40.380
GPU support, rather

0:39:40.380,0:39:42.380
than settling for dumb framebuffers.

0:39:42.380,0:39:44.380
How many...

0:39:44.380,0:39:46.380
How many of these boards...

0:39:46.380,0:39:48.380
Quite a lot of these boards do have HDMI

0:39:48.380,0:39:50.380
and I don't know

0:39:50.380,0:39:52.780
to what degree they are actually supported.

0:39:52.780,0:39:56.380
Are any current projected work

0:39:56.380,0:40:00.280
which definitively is using the

0:40:00.280,0:40:04.700
GPU on ARM system, and

0:40:04.700,0:40:07.320
what's in Debian,

0:40:07.320,0:40:09.520
is the Debian base system

0:40:09.780,0:40:12.480
does Debian... What's in Debian does not

0:40:12.480,0:40:14.480
support GPU.

0:40:14.480,0:40:17.980
[Martin:] So, I can't speak for Vagrant...

0:40:17.980,0:40:19.980
I have personally done some work

0:40:19.980,0:40:21.980
on the Tegra recently,

0:40:21.980,0:40:23.980
and nVidia is actually

0:40:23.980,0:40:27.120
working upstream on [?]

0:40:27.120,0:40:29.640
so I'm really interested in it

0:40:29.640,0:40:31.640
but I think that a lot of

0:40:31.640,0:40:33.640
the board used, there's money

0:40:33.640,0:40:37.160
GPUs I'm not sure would be

0:40:37.160,0:40:40.380
...you can get a [laughs]

0:40:40.380,0:40:43.760
can we get a microphone for Steve?

0:40:51.780,0:40:53.780
[Sledge:] So, on the Mali front,

0:40:53.780,0:40:55.240
there has been a lot of haste where we

0:40:55.240,0:40:57.240
have been scared of releasing any of this

0:40:57.240,0:40:59.880
in any way, shape or form,

0:40:59.880,0:41:01.880
without huge

0:41:01.880,0:41:04.580
[?]-relays and all that kind of stuff.

0:41:04.580,0:41:06.880
So it's not really distributable.

0:41:06.880,0:41:08.880
Even, at all.

0:41:08.880,0:41:12.300
We are a long way of it being releasable free,

0:41:12.300,0:41:15.640
There are packages coming that we

0:41:15.640,0:41:17.640
should be getting shippable in non-free

0:41:17.640,0:41:19.640
at least if you want to get full acceleration

0:41:19.640,0:41:21.640
on your Mali stuff.

0:41:23.640,0:41:25.640
Hopefully, that will solve some of the problems

0:41:25.640,0:41:27.640
There is a lot, there are a lot of people

0:41:27.640,0:41:29.640
in [?] who are very very keen on

0:41:29.640,0:41:32.180
supporting it properly, free and upstreamed.

0:41:32.180,0:41:34.620
It's a long fight.

0:41:34.620,0:41:35.940
It will take a while.

0:41:35.940,0:41:39.040
I mean, most of the Mali driver developers

0:41:39.040,0:41:41.040
themselves I have spoken to, would love to

0:41:41.040,0:41:43.040
make it free. It just comes down

0:41:43.040,0:41:45.040
to legal people

0:41:45.040,0:41:47.040
being scared.

0:41:53.040,0:41:55.040
[Tobi:] Are there some questions left?

0:41:58.780,0:42:00.080
[Martin:] Well, thanks for coming!

0:42:00.080,0:42:02.080
And there is going to be the ARM BoF

0:42:02.080,0:42:04.080
later today, and

0:42:04.080,0:42:06.080
Vagrant is also going to talk about his experience

0:42:06.080,0:42:09.760
about running a build network

0:42:09.760,0:42:11.760
on armhf boards..

0:42:11.760,0:42:13.160
Thanks!

0:42:18.060,0:42:20.060
[audience clapping]