1
00:00:03,060 --> 00:00:05,000
So, I think we are ready to start

2
00:00:05,020 --> 00:00:08,770
So, next talk is from Martin, about Debian on ARM devices.

3
00:00:14,210 --> 00: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

4
00:00:21,970 --> 00:00:27,130
I would say it's sort of a mix of different topics

5
00:00:27,130 --> 00:00:27,280
it's basically ---

6
00:00:27,280 --> 00:00:29,130
I mean, basically I often get
it's basically ---

7
00:00:29,130 --> 00:00:32,020
I mean, basically I often get

8
00:00:32,080 --> 00:00:35,240
the question from users

9
00:00:35,530 --> 00:00:38,930
"Well, Debian works on this particular ARM device,

10
00:00:39,110 --> 00:00:42,080
I have a device which is like really really similar,

11
00:00:42,080 --> 00:00:44,860
so surely Debian should work on it, right?"

12
00:00:44,860 --> 00:00:48,640
And so far, the answer unfortunately was usually "no"

13
00:00:48,640 --> 00:00:53,020
and - and it's really frustrating for users

14
00:00:53,020 --> 00:00:55,530
because they don't see why.

15
00:00:55,530 --> 00:00:58,570
You know, the device is very much the same, so why doesn't it just work.

16
00:00:58,570 --> 00:01:01,310
And so, basically what I'm trying to do is

17
00:01:01,310 --> 00:01:04,040
to show like a little bit behind the scenes

18
00:01:04,040 --> 00:01:06,510
of how Debian on ARM works

19
00:01:07,040 --> 00:01:09,620
And there has been a whole lot of progres

20
00:01:09,620 --> 00:01:13,130
So I'm going to show how <i>did</i> it work,

21
00:01:13,130 --> 00:01:15,130
what are the improvements, and

22
00:01:15,130 --> 00:01:17,600
and how is it going to work in the future

23
00:01:19,930 --> 00:01:21,880
And it's all more from a develeoper perspective

24
00:01:22,110 --> 00:01:25,880
so, it's like, how do we support it in the Debian Installer

25
00:01:26,220 --> 00:01:31,440
its' like a mix of stuff, and I should say,

26
00:01:31,680 --> 00:01:35,110
I'm really looking at it from somebody who basically

27
00:01:35,110 --> 00:01:37,510
adds support for devices in the installer

28
00:01:37,510 --> 00:01:40,460
but I'm not like a kernel guy or anything, so

29
00:01:40,460 --> 00:01:45,060
there are a lot of people in this room who know a bit more about the technical details

30
00:01:45,400 --> 00:01:48,800
but I'm not going to really drill down really deep down anyway

31
00:01:48,800 --> 00:01:51,680
But if I'm incorrect, I'm sure that

32
00:01:51,680 --> 00:01:53,680
there are plenty of people that will correct me.

33
00:01:54,170 --> 00:02:00,820
So, where do you find ARM? So it's pretty much everywhere these days, I mean...

34
00:02:01,150 --> 00:02:05,040
Pretty much every phone has an ARM chip in it

35
00:02:07,480 --> 00:02:11,950
All those "Internet of Things" gadgets are ARM-based

36
00:02:12,530 --> 00:02:18,480
You have NAS devices, and that's really the area I used to focus on

37
00:02:19,020 --> 00:02:22,600
those small boxes where you basically add a hard drive

38
00:02:22,600 --> 00:02:26,730
and most people just use it for storage, but it's actually a

39
00:02:27,130 --> 00:02:30,150
full PC where you can install Debian on it

40
00:02:30,640 --> 00:02:33,930
so I always found that to be very interesting

41
00:02:34,280 --> 00:02:37,310
and nowadays you have a lot of development boards

42
00:02:37,460 --> 00:02:41,280
And I'm not sure whether "development boards" is the right word

43
00:02:41,280 --> 00:02:45,130
Because when I hear "development boards" I think of it as really expensive,

44
00:02:45,640 --> 00:02:48,110
Like 5K for boards or something

45
00:02:48,420 --> 00:02:52,400
But nowadays you have those, maybe, a better board would be like bareboards

46
00:02:52,400 --> 00:02:56,200
Like "Raspberry Pi", like basically it's just the board

47
00:02:56,200 --> 00:02:59,820
it does not come with a case, you can buy those as well

48
00:02:59,820 --> 00:03:03,060
and it's like 30 dollars or something, you can get

49
00:03:03,370 --> 00:03:06,530
And that gets pretty much where most of the

50
00:03:06,530 --> 00:03:10,950
excitement is going for Debian users at this moment

51
00:03:11,220 --> 00:03:13,930
And that can cause a lot of frustration

52
00:03:16,640 --> 00:03:20,150
And everybody says that ARM is going to be big on servers

53
00:03:20,150 --> 00:03:24,020
and I think that's something we ar going to see

54
00:03:24,020 --> 00:03:26,600
But right now, again, it's

55
00:03:26,600 --> 00:03:28,600
a little bit frustrating

56
00:03:30,600 --> 00:03:34,000
How does it work as a Deban Installer

57
00:03:34,000 --> 00:03:36,000
There are basically two

58
00:03:36,970 --> 00:03:40,280
ways of installing on those ARM Pi devices

59
00:03:41,020 --> 00:03:44,350
So the, like, historic, that we normally

60
00:03:44,350 --> 00:03:47,950
would be to install on, like, ascreen

61
00:03:47,950 --> 00:03:49,950
can be a serial console,

62
00:03:50,310 --> 00:03:54,550
and then you just download via the network

63
00:03:54,750 --> 00:03:58,970
and then you just download via the network

64
00:03:58,970 --> 00:04:00,970
from a CD image or wherever,

65
00:04:00,970 --> 00:04:04,660
But the other method, which we actually use for those

66
00:04:04,660 --> 00:04:07,910
net devices was a network console

67
00:04:07,910 --> 00:04:11,460
where you basically ssh into the installer

68
00:04:11,730 --> 00:04:14,440
and you perform the installation via ssh

69
00:04:15,400 --> 00:04:19,839
and that was really the only way, because those mass devices

70
00:04:19,839 --> 00:04:22,950
don't have any I/O, so I

71
00:04:23,200 --> 00:04:25,370
even in there, you can

72
00:04:25,370 --> 00:04:28,080
it's just a serial console, most of them

73
00:04:28,330 --> 00:04:32,000
That's something we didn't want to require from the user

74
00:04:33,220 --> 00:04:36,840
And the other thing that's coming through, I think that it's basically cool that was announce today,

75
00:04:36,840 --> 00:04:38,840
screen support, so basically

76
00:04:40,020 --> 00:04:43,330
so you can have multiple sessions with in vi,

77
00:04:43,330 --> 00:04:47,110
which can be useful if you have an open shell to debug

78
00:04:49,110 --> 00:04:53,500
And so, how -- And so, this is really looking back at

79
00:04:53,500 --> 00:04:55,500
like running Debian on NAS devices

80
00:04:55,500 --> 00:04:58,420
which is something that used to be really popular

81
00:04:58,420 --> 00:05:02,500
And the way it worked was basically

82
00:05:02,500 --> 00:05:05,200
that we provided an installer image

83
00:05:05,200 --> 00:05:07,200
which was sort of a firmware image

84
00:05:07,200 --> 00:05:09,200
as a lot of those NAS devices

85
00:05:09,200 --> 00:05:12,080
have like a firmware upgrade mechanism

86
00:05:12,240 --> 00:05:14,180
and so we would basically fake

87
00:05:14,180 --> 00:05:17,240
we would create a firmware image

88
00:05:17,300 --> 00:05:19,520
which the software would accept

89
00:05:19,600 --> 00:05:22,460
but instead of a firmware update

90
00:05:22,540 --> 00:05:24,840
it would actually contain the Debian installer

91
00:05:24,840 --> 00:05:27,620
so you would install that upgrade

92
00:05:27,640 --> 00:05:30,080
you would reboot, and

93
00:05:30,080 --> 00:05:32,860
you could ssh to the installer

94
00:05:32,920 --> 00:05:36,360
and obviously, in order to ssh to the installer

95
00:05:36,360 --> 00:05:38,020
it needs to bring up the network

96
00:05:38,020 --> 00:05:41,060
and there is a tool called oldsys-preseed

97
00:05:41,060 --> 00:05:43,280
that basically reads the network configuration

98
00:05:43,280 --> 00:05:45,280
from the device

99
00:05:45,280 --> 00:05:47,280
and then sets up the network

100
00:05:47,280 --> 00:05:51,820
and it can always recognize the DHCP

101
00:05:51,820 --> 00:05:53,820
and then the user connects via ssh

102
00:05:53,820 --> 00:05:57,600
again, there would be some indication, maybe

103
00:05:57,600 --> 00:05:59,600
you know, there would be a "beep"

104
00:05:59,600 --> 00:06:01,260
or maybe change the LED

105
00:06:01,260 --> 00:06:03,260
to indicate that the installer is ready

106
00:06:03,260 --> 00:06:05,260
and then, the user basically performs

107
00:06:05,260 --> 00:06:07,260
a regular installation

108
00:06:07,260 --> 00:06:09,260
with normal d-i; they don't have to

109
00:06:09,260 --> 00:06:11,260
do anything differently.

110
00:06:12,320 --> 00:06:14,520
And at the end, flash-kernel runs

111
00:06:14,520 --> 00:06:17,340
to make the system bootable

112
00:06:17,340 --> 00:06:20,460
flash-kernel is called that way

113
00:06:20,460 --> 00:06:20,660
because it used to support
flash-kernel is called that way

114
00:06:20,660 --> 00:06:22,660
because it used to support

115
00:06:22,660 --> 00:06:25,380
like the initial device it supported

116
00:06:25,380 --> 00:06:27,380
booted from flash

117
00:06:27,380 --> 00:06:29,380
but it also generates bootable devices

118
00:06:29,380 --> 00:06:31,380
bootable images of disk devices

119
00:06:34,180 --> 00:06:36,560
so it really, flash-kernel really requires

120
00:06:36,560 --> 00:06:38,560
understanding of each device

121
00:06:38,560 --> 00:06:41,080
and our philosophy

122
00:06:41,080 --> 00:06:43,080
in those cases, with those NAS devices

123
00:06:43,080 --> 00:06:44,040
was really,

124
00:06:44,040 --> 00:06:46,040
we don't touch anything

125
00:06:46,040 --> 00:06:48,040
in the firmware, like

126
00:06:48,040 --> 00:06:50,040
in the configuration,

127
00:06:50,040 --> 00:06:52,040
so sometimes

128
00:06:52,040 --> 00:06:54,700
instead of changing the root device

129
00:06:54,700 --> 00:06:56,700
in the u-boot config we would actually

130
00:06:56,700 --> 00:06:58,700
hard-code that in the ramdisk

131
00:06:58,700 --> 00:07:02,720
just because we wanted people to go back

132
00:07:02,720 --> 00:07:05,160
to the original firmware if they had to

133
00:07:05,160 --> 00:07:07,700
if they had to send it in for repair or something

134
00:07:07,700 --> 00:07:09,700
and

135
00:07:09,700 --> 00:07:12,500
and that kind of approach really worked well

136
00:07:12,500 --> 00:07:14,500
so I think we really had a lot of

137
00:07:14,500 --> 00:07:16,500
people, lot of users running

138
00:07:16,500 --> 00:07:18,500
in Debian in those kind of NAS devices

139
00:07:18,500 --> 00:07:20,860
and it was really easy to do.

140
00:07:20,860 --> 00:07:22,580
You get a firmware image,

141
00:07:22,580 --> 00:07:25,380
you connect to the installer via ssh,

142
00:07:25,380 --> 00:07:27,380
and it just works, it's a normal

143
00:07:27,380 --> 00:07:28,620
debian-installer, the way

144
00:07:28,620 --> 00:07:30,620
everybody knows it,

145
00:07:30,620 --> 00:07:32,620
because some of the other distros

146
00:07:32,620 --> 00:07:33,820
they basically provide, like,

147
00:07:33,820 --> 00:07:35,240
tarballs and instructions

148
00:07:35,240 --> 00:07:37,240
so you need to partition a disk,

149
00:07:37,240 --> 00:07:39,240
need to un-tar it,

150
00:07:39,240 --> 00:07:41,240
you need to change those files,

151
00:07:41,240 --> 00:07:43,240
and even if it sounds simple,

152
00:07:43,240 --> 00:07:45,240
it's so many steps that

153
00:07:45,240 --> 00:07:47,620
you always... you often get something wrong

154
00:07:47,620 --> 00:07:50,380
and then you put the drive into the

155
00:07:50,380 --> 00:07:52,380
NAS device, and it doesn't boot, and you don't know why

156
00:07:52,380 --> 00:07:54,800
where did you make that mistake,

157
00:07:54,800 --> 00:07:56,000
which step

158
00:07:56,000 --> 00:07:58,000
and you basically have to start from scratch

159
00:07:58,000 --> 00:08:00,440
so Debian really provided something unique

160
00:08:00,440 --> 00:08:02,440
by adding

161
00:08:02,440 --> 00:08:04,440
the debian-installer support

162
00:08:04,440 --> 00:08:06,440
but anyway, that's the way

163
00:08:06,440 --> 00:08:08,440
it sort of used to work.

164
00:08:08,440 --> 00:08:10,440
Nowadays, with a lot of those bareboard

165
00:08:10,440 --> 00:08:12,440
it's much easier

166
00:08:12,440 --> 00:08:14,440
I'll get to that.

167
00:08:15,180 --> 00:08:18,100
So at the moment there are three different ARM ports:

168
00:08:18,100 --> 00:08:20,100
There is the old armel

169
00:08:20,100 --> 00:08:22,100
which used to be the "newer" ARM

170
00:08:22,100 --> 00:08:24,820
and now it's old,

171
00:08:24,820 --> 00:08:26,820
and one of the discussions

172
00:08:26,820 --> 00:08:28,820
that we are probably going to have later today on the BoF

173
00:08:28,820 --> 00:08:31,220
is about, should we remove that

174
00:08:31,220 --> 00:08:33,220
after Stretch.

175
00:08:33,220 --> 00:08:36,440
There is armhf and the arm64

176
00:08:37,640 --> 00:08:40,539
and we get basically the question I hope to answer.

177
00:08:40,539 --> 00:08:43,299
If, you know, device A works,

178
00:08:43,299 --> 00:08:45,300
I have a device which is really similar,

179
00:08:45,300 --> 00:08:47,300
but it doesn't work. Why is that?

180
00:08:49,300 --> 00:08:51,300
So, heh,

181
00:08:51,300 --> 00:08:53,300
There have been a lot of changes

182
00:08:53,300 --> 00:08:58,120
in various upstream projects, specially

183
00:08:58,120 --> 00:09:00,120
the kernel and U-boot

184
00:09:00,120 --> 00:09:02,120
that really make things easier.

185
00:09:02,120 --> 00:09:04,120
So, in the past

186
00:09:04,120 --> 00:09:07,260
we basically had

187
00:09:07,260 --> 00:09:09,260
a kernel image

188
00:09:09,260 --> 00:09:10,780
for each platform,

189
00:09:10,780 --> 00:09:12,780
where a platform is basically like

190
00:09:12,780 --> 00:09:14,780
a SSE family

191
00:09:14,780 --> 00:09:17,660
and there would be a different image

192
00:09:17,660 --> 00:09:21,540
because ARM takes a long time

193
00:09:21,540 --> 00:09:23,540
to compile, there was always some debate

194
00:09:23,540 --> 00:09:26,100
about adding a new platform

195
00:09:26,100 --> 00:09:28,100
because there would be a new

196
00:09:28,100 --> 00:09:30,600
image flavor, which takes some time,

197
00:09:31,740 --> 00:09:33,540
and that was just really like,

198
00:09:33,540 --> 00:09:36,280
we couldn't just have one ARM kernel

199
00:09:36,280 --> 00:09:38,280
which works everywhere.

200
00:09:38,280 --> 00:09:40,280
And a lot of people didn't understand

201
00:09:40,280 --> 00:09:42,280
why you had a different kernel

202
00:09:42,280 --> 00:09:44,280
because different platforms,

203
00:09:44,280 --> 00:09:48,040
although there has been a lot of progress upstream,

204
00:09:48,040 --> 00:09:51,580
at least nowadays, with armhf

205
00:09:51,580 --> 00:09:54,020
and with arm64

206
00:09:54,020 --> 00:09:56,020
we just have one kernel.

207
00:09:57,340 --> 00:09:59,980
And upstream basically

208
00:09:59,980 --> 00:10:02,740
Maybe some of you remember the rant

209
00:10:02,740 --> 00:10:04,740
by Niels about

210
00:10:04,740 --> 00:10:06,740
the ARM people doing everything

211
00:10:06,740 --> 00:10:08,180
in different ways,

212
00:10:08,180 --> 00:10:10,180
and there has been a lot of standarization

213
00:10:10,180 --> 00:10:12,180
over the years.

214
00:10:12,180 --> 00:10:14,180
Basically, the other thing is

215
00:10:14,180 --> 00:10:16,180
there used to be for each device

216
00:10:16,180 --> 00:10:18,180
there was a board file

217
00:10:18,180 --> 00:10:20,180
it was like a C file

218
00:10:20,180 --> 00:10:22,580
to initialize the different components,

219
00:10:22,580 --> 00:10:24,580
and the boot loader would

220
00:10:24,580 --> 00:10:27,660
pass the machine ID to the kernel,

221
00:10:27,660 --> 00:10:30,380
and it would load that boot file.

222
00:10:30,380 --> 00:10:32,380
And nowadays,

223
00:10:32,380 --> 00:10:34,380
there is basically a

224
00:10:34,380 --> 00:10:36,380
device tree in the kernel,

225
00:10:36,380 --> 00:10:38,380
which is a description of the hardware

226
00:10:40,040 --> 00:10:41,800
and it will basically compile it

227
00:10:41,800 --> 00:10:44,580
to, like, a binary blob, the .dtb.

228
00:10:44,580 --> 00:10:46,580
And, so, basically you just need

229
00:10:46,580 --> 00:10:48,580
the kernel image, and

230
00:10:48,580 --> 00:10:51,200
the .dtb, which is hardware-specific,

231
00:10:51,200 --> 00:10:53,200
and then it boots.

232
00:10:53,200 --> 00:10:55,640
And obviously, for us in Debian

233
00:10:55,640 --> 00:10:57,640
that makes it much much easier

234
00:10:57,640 --> 00:11:00,540
to support a lot of devices.

235
00:11:01,960 --> 00:11:04,560
The other thing that changed in U-boot,

236
00:11:06,040 --> 00:11:09,080
when you install the Debian kernel image,

237
00:11:09,080 --> 00:11:10,720
it creates

238
00:11:10,720 --> 00:11:13,900
the vmlinux file

239
00:11:13,900 --> 00:11:16,740
and also the RAM disk

240
00:11:16,740 --> 00:11:18,740
but with U-boot,

241
00:11:18,740 --> 00:11:20,740
you couldn't actually load those files

242
00:11:20,740 --> 00:11:22,740
correctly. You basically

243
00:11:22,740 --> 00:11:25,840
had to wrap them in a U-boot image

244
00:11:25,840 --> 00:11:28,420
and it's not really hard

245
00:11:28,420 --> 00:11:31,440
it's just the command initram,

246
00:11:31,440 --> 00:11:33,440
but all of the different devices had

247
00:11:33,440 --> 00:11:34,940
different load addresses,

248
00:11:34,940 --> 00:11:36,940
and, again, that's hardware-specific knowledge

249
00:11:36,940 --> 00:11:39,360
that flash-kernel needed to know.

250
00:11:39,360 --> 00:11:40,820
And nowadays,

251
00:11:40,820 --> 00:11:42,720
there is a command which

252
00:11:42,720 --> 00:11:44,720
directly loads the kernel,

253
00:11:44,720 --> 00:11:48,380
so that, again, was a step to make things easier.

254
00:11:48,380 --> 00:11:52,320
And the last thing which really made

255
00:11:52,320 --> 00:11:54,320
things easier is distro support

256
00:11:54,320 --> 00:11:56,320
in U-boot.

257
00:11:56,320 --> 00:11:58,320
So, basically, in the past

258
00:11:58,320 --> 00:12:00,320
every U-boot, every

259
00:12:00,320 --> 00:12:02,320
devices in U-boot,

260
00:12:02,320 --> 00:12:04,320
booted in a different way,

261
00:12:05,240 --> 00:12:08,700
just in terms on where would it load

262
00:12:08,700 --> 00:12:10,700
the file from, or

263
00:12:10,700 --> 00:12:12,700
what variables would it use, and

264
00:12:12,700 --> 00:12:14,700
nowadays there is something called distro-support

265
00:12:14,700 --> 00:12:16,700
which is basically a standardized way

266
00:12:16,700 --> 00:12:18,700
to boot a Linux distro

267
00:12:19,300 --> 00:12:21,660
with U-boot.

268
00:12:21,660 --> 00:12:23,660
There are basically

269
00:12:23,660 --> 00:12:25,660
two ways, either can

270
00:12:25,660 --> 00:12:27,660
read a config file,

271
00:12:27,660 --> 00:12:29,660
or it can basically run a

272
00:12:29,660 --> 00:12:31,660
boot script, and that's what

273
00:12:31,660 --> 00:12:33,660
we use in Debian, so we basically have

274
00:12:33,660 --> 00:12:35,660
a generic boot script

275
00:12:35,660 --> 00:12:38,100
which loads the kernel,

276
00:12:38,100 --> 00:12:40,100
loads the ramdisk, the .dtb,

277
00:12:40,100 --> 00:12:42,100
and boots Debian.

278
00:12:42,100 --> 00:12:44,100
It can use the generic

279
00:12:44,100 --> 00:12:46,100
bootscript in almost all

280
00:12:46,100 --> 00:12:47,860
of the modern devices.

281
00:12:47,860 --> 00:12:49,860
So nowadays, because of that,

282
00:12:49,860 --> 00:12:51,860
it's much more standard, and

283
00:12:51,860 --> 00:12:53,860
it's much easier to support

284
00:12:53,860 --> 00:12:56,440
those devices.

285
00:12:56,440 --> 00:12:59,980
So here are some examples of flash-kernel

286
00:12:59,980 --> 00:13:02,800
So, basically, flash-kernel has like a database

287
00:13:02,800 --> 00:13:04,800
of devices which it supports

288
00:13:04,800 --> 00:13:07,580
so it's like the machine entry

289
00:13:07,580 --> 00:13:09,580
in /proc/cpuinfo,

290
00:13:09,580 --> 00:13:11,960
and then the kernel flavors

291
00:13:11,960 --> 00:13:13,960
it can run

292
00:13:13,960 --> 00:13:15,960
and, so, this one is

293
00:13:15,960 --> 00:13:17,960
an old device, it still uses

294
00:13:17,960 --> 00:13:19,960
a board file, and it

295
00:13:19,960 --> 00:13:22,400
needs the U-boot wrapper,

296
00:13:22,400 --> 00:13:24,400
So...

297
00:13:24,400 --> 00:13:27,180
You are basically setting the machine ID

298
00:13:27,180 --> 00:13:29,840
those are the flash partitions

299
00:13:29,840 --> 00:13:31,840
where the kernel and the

300
00:13:31,840 --> 00:13:33,840
ramdisk are stored, and

301
00:13:33,840 --> 00:13:35,660
that's the load address for the

302
00:13:35,660 --> 00:13:37,660
U-boot wrapper

303
00:13:39,660 --> 00:13:43,120
And, now, that's a device

304
00:13:43,120 --> 00:13:45,120
which used to have

305
00:13:45,120 --> 00:13:47,120
a boot file,

306
00:13:47,120 --> 00:13:49,120
and which then migrated

307
00:13:49,120 --> 00:13:51,120
to a .dtb,

308
00:13:51,120 --> 00:13:53,120
so basically, heh,

309
00:13:53,120 --> 00:13:56,160
that was really really painful for Debian

310
00:13:56,160 --> 00:13:58,800
so, basically, the kernel people said

311
00:13:58,800 --> 00:14:00,800
"Oh, you are going to move to device tree,

312
00:14:00,800 --> 00:14:02,060
so don't worry,

313
00:14:02,060 --> 00:14:04,460
we are not gonna remove those old board files,

314
00:14:04,460 --> 00:14:06,460
you can still use them."

315
00:14:06,460 --> 00:14:08,800
And then, a few years later they realized

316
00:14:08,800 --> 00:14:11,240
it's really hard to keep both alive,

317
00:14:11,240 --> 00:14:13,760
and they got rid of the board files.

318
00:14:13,760 --> 00:14:16,360
And that was really painful to us

319
00:14:16,360 --> 00:14:18,820
because we had to migrate

320
00:14:18,820 --> 00:14:20,820
So you can see,

321
00:14:20,820 --> 00:14:23,500
here, a kernel version,

322
00:14:23,500 --> 00:14:25,500
and so, from that kernel on,

323
00:14:25,500 --> 00:14:27,500
you needed to use the new way.

324
00:14:29,060 --> 00:14:33,240
And one of the reasons it was painful

325
00:14:33,240 --> 00:14:35,780
specially on the QNAP devices

326
00:14:35,780 --> 00:14:38,400
is because with

327
00:14:38,400 --> 00:14:40,400
they actually have two different CPUs

328
00:14:40,400 --> 00:14:42,400
so there are different barriers

329
00:14:42,400 --> 00:14:44,400
and whilst the board files,

330
00:14:44,400 --> 00:14:46,400
the same board file worked

331
00:14:46,400 --> 00:14:48,400
regardless of the CPU,

332
00:14:48,400 --> 00:14:51,240
because of the way the device tree worked

333
00:14:51,240 --> 00:14:53,240
it actually needed two different device trees

334
00:14:53,240 --> 00:14:55,240
depending on the CPU

335
00:14:55,600 --> 00:14:59,320
so now we basically, you know, something that just worked,

336
00:14:59,320 --> 00:15:01,320
you know, it used to work fine,

337
00:15:01,320 --> 00:15:03,320
you just had one kernel

338
00:15:03,320 --> 00:15:05,740
with the machine ID

339
00:15:05,740 --> 00:15:06,920
at least would work,

340
00:15:06,920 --> 00:15:09,620
and somehow with the device tree

341
00:15:09,620 --> 00:15:11,620
we needed to figure out which one

342
00:15:11,620 --> 00:15:13,620
we need, and so

343
00:15:13,620 --> 00:15:16,960
[?] fortunately did all of that work.

344
00:15:16,960 --> 00:15:18,960
So that's actually a script that runs

345
00:15:18,960 --> 00:15:20,960
to figure out which device tree

346
00:15:20,960 --> 00:15:22,960
that particular device needs.

347
00:15:26,660 --> 00:15:29,160
So now, that's actually

348
00:15:29,160 --> 00:15:31,160
the reason I want to show this is

349
00:15:31,160 --> 00:15:33,160
how simpler things are these days, so

350
00:15:33,160 --> 00:15:35,160
this is an example from

351
00:15:35,160 --> 00:15:38,600
[?] platform, which uses distro-support,

352
00:15:38,600 --> 00:15:40,960
and the only thing you really need is

353
00:15:40,960 --> 00:15:42,960
a machine entry with the name,

354
00:15:42,960 --> 00:15:44,960
and then

355
00:15:44,960 --> 00:15:46,960
like the kernel-flavor,

356
00:15:46,960 --> 00:15:48,960
but that's the same for...

357
00:15:48,960 --> 00:15:50,960
you know, there is only one kernel flavor.

358
00:15:52,740 --> 00:15:55,380
And then, the device tree ID

359
00:15:56,480 --> 00:15:58,360
and, again, all of that stuff is generic,

360
00:15:58,360 --> 00:16:00,760
so it just uses the generic bootscript,

361
00:16:02,180 --> 00:16:03,780
and the generic boot path,

362
00:16:03,780 --> 00:16:05,780
so basically

363
00:16:05,780 --> 00:16:07,780
all it pretty much needs for

364
00:16:07,780 --> 00:16:09,780
a new device is, like,

365
00:16:09,780 --> 00:16:11,780
you know,

366
00:16:11,780 --> 00:16:13,780
these two entries,

367
00:16:13,780 --> 00:16:15,780
it's really really simple.

368
00:16:18,780 --> 00:16:21,260
So here, I just wanted to

369
00:16:21,260 --> 00:16:23,260
tell about the different ARM ports and...

370
00:16:24,200 --> 00:16:26,940
So, for me it was really hard to structure this, because

371
00:16:26,940 --> 00:16:29,460
those changes in the kernel

372
00:16:29,460 --> 00:16:31,460
and U-boot

373
00:16:31,460 --> 00:16:34,640
you know, happen independent of our ARM ports,

374
00:16:36,100 --> 00:16:37,720
But at the same time, because

375
00:16:37,720 --> 00:16:40,340
because the armhf world is much newer,

376
00:16:40,340 --> 00:16:42,340
it works in a different way.

377
00:16:42,340 --> 00:16:45,200
So, basically, the armel

378
00:16:45,200 --> 00:16:49,480
we still have different flavors

379
00:16:49,480 --> 00:16:54,000
but we have already combined the orion and the kirkwood

380
00:16:54,000 --> 00:16:56,000
into one marvell flavor,

381
00:16:56,000 --> 00:16:59,060
and we have the versatile one.

382
00:17:00,860 --> 00:17:03,760
So one of the problems we have in armel is that

383
00:17:03,760 --> 00:17:05,760
a lot of those NAS devices

384
00:17:05,760 --> 00:17:07,760
boot from flash

385
00:17:07,760 --> 00:17:10,180
and they only have, some of them,

386
00:17:10,180 --> 00:17:12,180
3MB for the kernel,

387
00:17:12,180 --> 00:17:15,119
which used to be a lot of space

388
00:17:15,119 --> 00:17:16,660
but nowadays it's not.

389
00:17:16,720 --> 00:17:19,380
So that really puts a lot of restrictions

390
00:17:19,380 --> 00:17:21,380
so basically we disable some stuff

391
00:17:21,380 --> 00:17:23,380
from armel

392
00:17:23,380 --> 00:17:27,180
but I think that armel is really really widely used

393
00:17:27,180 --> 00:17:29,180
because of those NAS devices,

394
00:17:29,180 --> 00:17:31,180
but I think they are slowly getting old,

395
00:17:31,180 --> 00:17:33,680
but there are still a lot of people that use them.

396
00:17:33,680 --> 00:17:37,220
Like I said, it requires the U-boot image

397
00:17:37,700 --> 00:17:40,380
Originally, we used board files

398
00:17:40,380 --> 00:17:43,360
and device tree, most of them

399
00:17:43,360 --> 00:17:45,940
have switched over to device tree

400
00:17:45,940 --> 00:17:48,580
even if some of them still use board files

401
00:17:48,580 --> 00:17:51,540
and adding a new device requires

402
00:17:51,540 --> 00:17:54,200
a number of changes in the installer.

403
00:17:54,200 --> 00:17:57,100
So basically, you needed to map

404
00:17:57,100 --> 00:17:59,100
the device to

405
00:17:59,100 --> 00:18:01,100
the complete image

406
00:18:01,100 --> 00:18:04,200
and there are just there a couple of

407
00:18:04,200 --> 00:18:06,260
things, so basically, any one device

408
00:18:06,280 --> 00:18:08,200
you have to change like five different

409
00:18:08,200 --> 00:18:10,200
places in the installer.

410
00:18:10,200 --> 00:18:12,200
And it was quite confusing for people who wanted

411
00:18:12,200 --> 00:18:14,200
to add new devices

412
00:18:14,200 --> 00:18:17,080
Because it isn't really documented very well

413
00:18:18,480 --> 00:18:21,400
So some examples are a list of three people

414
00:18:21,400 --> 00:18:23,400
who are involved in that port

415
00:18:23,400 --> 00:18:25,400
So, Roger is someone

416
00:18:25,400 --> 00:18:27,400
who is quite new, and who really got

417
00:18:27,400 --> 00:18:29,920
involved into porting those old devices.

418
00:18:31,440 --> 00:18:34,560
And so, armhf is much nicer,

419
00:18:34,560 --> 00:18:36,560
so the majority of

420
00:18:36,560 --> 00:18:39,140
devices support distro-support.

421
00:18:40,440 --> 00:18:42,700
And the other thing we do

422
00:18:44,700 --> 00:18:47,040
is, for some of the devices

423
00:18:47,040 --> 00:18:49,040
we provide SD card images,

424
00:18:49,040 --> 00:18:51,040
which contain

425
00:18:51,040 --> 00:18:55,160
U-boot and the Debian installer

426
00:18:55,160 --> 00:18:57,160
So basically Vagrant

427
00:18:57,160 --> 00:18:59,960
maintains U-boot in Debian, and

428
00:18:59,960 --> 00:19:01,960
a lot of those devices are supported

429
00:19:01,960 --> 00:19:03,960
in U-boot in Debian.

430
00:19:03,960 --> 00:19:05,960
So we just

431
00:19:05,960 --> 00:19:07,960
provide an SD image, so you can just

432
00:19:07,960 --> 00:19:10,480
store it in the SD card, you put it in

433
00:19:10,480 --> 00:19:12,940
and, because of the distro-support,

434
00:19:12,940 --> 00:19:14,940
it just loads debian-installer,

435
00:19:14,940 --> 00:19:17,840
you do the installation, reboot,

436
00:19:17,840 --> 00:19:19,840
and things just work.

437
00:19:19,840 --> 00:19:21,840
So I think it really has gone

438
00:19:21,840 --> 00:19:25,200
...Come a long way.

439
00:19:27,200 --> 00:19:29,820
So nowadays,

440
00:19:29,820 --> 00:19:31,820
adding a new device

441
00:19:31,820 --> 00:19:34,140
requires much fewer changes

442
00:19:34,140 --> 00:19:36,140
than it used to be.

443
00:19:36,140 --> 00:19:40,980
Because as everything uses the same, like, one kernel flavor,

444
00:19:40,980 --> 00:19:43,900
you don't need to patch all those different places anymore,

445
00:19:45,020 --> 00:19:47,740
and because of distro-support, it just works.

446
00:19:47,740 --> 00:19:52,280
You can pretty much use the generic bootscript.

447
00:19:54,140 --> 00:19:56,140
So, arm64.

448
00:19:56,140 --> 00:19:58,300
So, the problem until recently

449
00:19:58,300 --> 00:20:00,300
is that there simply wasn't any hardware

450
00:20:00,300 --> 00:20:02,300
that people could buy.

451
00:20:02,300 --> 00:20:04,300
And that's changing rapidly now

452
00:20:05,640 --> 00:20:07,540
[?]

453
00:20:07,540 --> 00:20:10,280
We have for example the Raspberry Pi 3

454
00:20:10,280 --> 00:20:13,960
which uses a 64 bit CPU

455
00:20:13,960 --> 00:20:16,620
but the software it ships is only 32 bits,

456
00:20:16,620 --> 00:20:18,620
but most of the work

457
00:20:18,620 --> 00:20:20,620
is now

458
00:20:20,620 --> 00:20:23,680
upstreamed to run 64 bit on it

459
00:20:25,000 --> 00:20:27,600
and there are a lot of

460
00:20:28,120 --> 00:20:31,500
devices which sort of work but not quite

461
00:20:31,960 --> 00:20:35,660
but anyway, so the idea for arm64

462
00:20:35,660 --> 00:20:37,660
is that a lot of the

463
00:20:37,660 --> 00:20:39,660
new hardware

464
00:20:39,660 --> 00:20:41,660
specially on the server side

465
00:20:41,660 --> 00:20:43,660
will use UEFI,

466
00:20:43,660 --> 00:20:45,660
and so you basically just

467
00:20:46,380 --> 00:20:48,100
it just works like a PC.

468
00:20:48,100 --> 00:20:50,100
So you have Grub,

469
00:20:50,100 --> 00:20:53,020
you can run debian-installer from Grub

470
00:20:53,020 --> 00:20:54,900
and you get Grub afterwards.

471
00:20:54,920 --> 00:20:56,480
And just boots like a PC,

472
00:20:56,480 --> 00:20:59,860
and Steve has done a lot of work in that area,

473
00:20:59,860 --> 00:21:01,860
And in theory,

474
00:21:01,860 --> 00:21:03,860
it should just work out of the box.

475
00:21:03,860 --> 00:21:06,220
So, if it uses

476
00:21:06,220 --> 00:21:08,220
UEFI, we don't need to add anything.

477
00:21:08,220 --> 00:21:10,220
It just works.

478
00:21:10,220 --> 00:21:12,220
There's nothing to do.

479
00:21:13,400 --> 00:21:15,300
At least, that's the theory.

480
00:21:15,300 --> 00:21:17,300
So, what I found is

481
00:21:17,300 --> 00:21:19,300
...I made a disclaimer, so

482
00:21:19,300 --> 00:21:21,300
...Assuming the kernel

483
00:21:21,300 --> 00:21:23,300
you know, kernel support and stuff...

484
00:21:23,300 --> 00:21:25,300
...To be honest,

485
00:21:25,300 --> 00:21:28,160
right now, that's a big assumption.

486
00:21:28,160 --> 00:21:30,160
So I've been playing with a few

487
00:21:30,160 --> 00:21:33,200
64 bit ARM boards

488
00:21:33,200 --> 00:21:36,580
and basically, what I found is

489
00:21:36,580 --> 00:21:39,420
there is some support upstream,

490
00:21:39,420 --> 00:21:41,420
so I can boot a kernel,

491
00:21:41,420 --> 00:21:43,700
but, oh! There is no USB support!

492
00:21:43,700 --> 00:21:45,280
there is no Wifi support!

493
00:21:45,280 --> 00:21:48,060
So I cannot actually do anything with it.

494
00:21:48,060 --> 00:21:51,580
But I can get to something that

495
00:21:51,580 --> 00:21:54,980
because arm64 is still farily new.

496
00:21:54,980 --> 00:21:57,640
And there is a lot of work going on upstream

497
00:21:57,640 --> 00:22:00,000
to support the various platforms.

498
00:22:00,000 --> 00:22:03,300
So, I think over time that's really going to be much better.

499
00:22:05,300 --> 00:22:09,440
Even though that UEFI idea is there

500
00:22:09,440 --> 00:22:11,200
in reality,

501
00:22:11,200 --> 00:22:13,200
we are going to see different solutions

502
00:22:13,200 --> 00:22:15,200
for arm64.

503
00:22:15,200 --> 00:22:18,240
So we are going to see UEFI, in particular on servers,

504
00:22:18,240 --> 00:22:20,240
but we will also see U-boot.

505
00:22:20,240 --> 00:22:22,700
So a lot of those bare boards

506
00:22:22,700 --> 00:22:24,700
they have U-boot.

507
00:22:24,700 --> 00:22:26,700
And, so, right now

508
00:22:26,700 --> 00:22:28,700
we can use the distro support

509
00:22:28,700 --> 00:22:31,980
and I think that it works pretty well.

510
00:22:31,980 --> 00:22:34,320
But one thing that SuSE has done

511
00:22:34,320 --> 00:22:36,320
so, they just had the same issue,

512
00:22:36,320 --> 00:22:38,320
they want to support all those devices

513
00:22:38,320 --> 00:22:41,240
but they just want to use the same mechanism everywhere,

514
00:22:41,240 --> 00:22:43,420
so they have actually implemented

515
00:22:43,420 --> 00:22:46,020
UEFI on top of U-boot,

516
00:22:46,020 --> 00:22:49,240
so you can basically use U-boot to load Grub

517
00:22:49,240 --> 00:22:51,720
and then you have Grub

518
00:22:51,720 --> 00:22:54,320
so I think that's something we need to figure out;

519
00:22:54,320 --> 00:22:56,840
do we want to stay with distro-support?

520
00:22:56,840 --> 00:22:58,840
do we want to use

521
00:22:58,840 --> 00:23:01,140
UEFI on top of U-boot?

522
00:23:01,140 --> 00:23:03,140
is that something we want to

523
00:23:03,140 --> 00:23:05,140
give users the option?

524
00:23:05,140 --> 00:23:08,020
And then, Fastboot

525
00:23:08,020 --> 00:23:10,140
is something used

526
00:23:10,140 --> 00:23:12,140
in the Android world

527
00:23:12,140 --> 00:23:14,760
and a lot of those, like, I see a lot of

528
00:23:14,760 --> 00:23:17,800
both bare boards, but also

529
00:23:17,800 --> 00:23:19,940
game consoles and stuff, which

530
00:23:19,940 --> 00:23:21,940
which are sort of Android-oriented,

531
00:23:21,940 --> 00:23:23,940
but which can also run normal Linux,

532
00:23:23,940 --> 00:23:26,840
and they will use like Fastboot or something.

533
00:23:26,840 --> 00:23:30,120
And there are tons of other bootloaders out there

534
00:23:30,120 --> 00:23:32,540
But I would definitively say, like, the good ones

535
00:23:32,540 --> 00:23:34,540
are UEFI and U-boot

536
00:23:36,540 --> 00:23:40,320
So, I gave a similar talk a few weeks ago

537
00:23:40,320 --> 00:23:43,060
and turns out, a lot of non-free

538
00:23:43,060 --> 00:23:45,060
firmware, like, "can I

539
00:23:45,060 --> 00:23:46,920
run that stuff, you know,

540
00:23:46,920 --> 00:23:48,920
purely with free software?"

541
00:23:48,920 --> 00:23:51,260
...And...

542
00:23:51,260 --> 00:23:52,980
So, the thing with ARM is that

543
00:23:52,980 --> 00:23:54,980
there are a lot of different platforms

544
00:23:54,980 --> 00:23:56,980
I'm not sure about all of them,

545
00:23:56,980 --> 00:23:59,460
but some of the platforms

546
00:23:59,460 --> 00:24:01,960
I looked at, yes, you

547
00:24:01,960 --> 00:24:05,320
do need some... There is always something propietary.

548
00:24:06,460 --> 00:24:08,420
So in a lot of cases

549
00:24:08,420 --> 00:24:10,420
I see where you have

550
00:24:10,420 --> 00:24:13,580
you use the proprietary first-stage boot loader,

551
00:24:13,580 --> 00:24:16,160
so the Raspberry Pi is an example,

552
00:24:16,160 --> 00:24:18,540
so, I don't actually have a Raspberry Pi, but

553
00:24:18,540 --> 00:24:20,540
the way I understand it is

554
00:24:20,540 --> 00:24:23,060
you basically put some boot files

555
00:24:23,060 --> 00:24:25,060
in an SD card,

556
00:24:25,060 --> 00:24:27,060
and they are proprietary, and

557
00:24:27,060 --> 00:24:29,060
then they load the kernel.

558
00:24:29,060 --> 00:24:31,500
Or in case of [?]

559
00:24:31,500 --> 00:24:33,500
supported in Debian,

560
00:24:33,500 --> 00:24:35,500
the first stage boot loader would basically

561
00:24:35,500 --> 00:24:37,820
be used to run U-boot,

562
00:24:37,820 --> 00:24:40,140
and then we could use U-boot, and

563
00:24:40,140 --> 00:24:43,880
the U-boot support all of it is free software,

564
00:24:43,880 --> 00:24:46,440
but the first stage boot loader isn't.

565
00:24:46,440 --> 00:24:49,820
I have had, there are some people

566
00:24:49,820 --> 00:24:51,820
working on a free replacement for

567
00:24:51,820 --> 00:24:53,820
the Raspberry Pi, though.

568
00:24:53,820 --> 00:24:55,820
With nVidia Tegra,

569
00:24:55,820 --> 00:24:57,640
which is

570
00:24:57,640 --> 00:24:59,640
something I'm working on at the moment

571
00:24:59,640 --> 00:25:03,040
you also have a tiny first stage boot loader,

572
00:25:03,040 --> 00:25:05,940
but then again, you have U-boot, which is free,

573
00:25:05,940 --> 00:25:08,980
and in that case, you also have some firmware

574
00:25:08,980 --> 00:25:10,980
images for the GPU

575
00:25:10,980 --> 00:25:13,320
and for other stuff.

576
00:25:13,320 --> 00:25:15,980
For the Dragon board,

577
00:25:15,980 --> 00:25:18,980
The Dragon board sounded really interesting

578
00:25:18,980 --> 00:25:20,820
because it actually has a

579
00:25:20,820 --> 00:25:22,820
a graphics chip

580
00:25:22,820 --> 00:25:25,120
which can be used with free software,

581
00:25:25,120 --> 00:25:27,920
so that sounded pretty cool,

582
00:25:27,920 --> 00:25:30,340
but again, it has a

583
00:25:30,340 --> 00:25:32,460
proprietary first

584
00:25:32,460 --> 00:25:34,460
stage boot loader,

585
00:25:34,460 --> 00:25:36,460
and then there is a second stage boot loader

586
00:25:36,460 --> 00:25:38,460
which is actually open source

587
00:25:38,460 --> 00:25:41,520
and then there's actually a U-boot of that,

588
00:25:41,520 --> 00:25:44,600
and then you have some

589
00:25:44,600 --> 00:25:46,600
binary blobs which

590
00:25:46,600 --> 00:25:49,900
also need to be installed in flash to work properly

591
00:25:49,900 --> 00:25:51,900
On the Marvell side, I'm

592
00:25:51,900 --> 00:25:53,900
not really aware of anything.

593
00:25:53,900 --> 00:25:55,900
I have never needed to flash anything

594
00:25:55,900 --> 00:25:57,900
proprietary, but

595
00:25:57,900 --> 00:25:59,900
I'm not sure how U-boot gets started

596
00:25:59,900 --> 00:26:01,900
on Marvell, so maybe there is something.

597
00:26:04,380 --> 00:26:08,180
So the future is all... So NAS devices are

598
00:26:08,180 --> 00:26:09,800
like I said, that's something that's

599
00:26:09,800 --> 00:26:11,800
really been popular in Debian.

600
00:26:11,800 --> 00:26:15,480
Specially on the QNAP devices,

601
00:26:15,480 --> 00:26:17,480
but the problem is, so, QNAP...

602
00:26:17,480 --> 00:26:19,480
so the devices we currently support

603
00:26:19,480 --> 00:26:21,480
are pretty old

604
00:26:21,480 --> 00:26:23,480
nowadays,

605
00:26:23,480 --> 00:26:25,480
and they have some newer devices,

606
00:26:25,480 --> 00:26:27,740
but they are not properly supported

607
00:26:27,740 --> 00:26:29,740
in the upstream kernel.

608
00:26:29,740 --> 00:26:31,740
So, I have no plans

609
00:26:31,740 --> 00:26:33,740
to support Debian on those.

610
00:26:33,740 --> 00:26:36,920
I recently did some work on

611
00:26:36,920 --> 00:26:38,920
Seagate NAS devices

612
00:26:38,920 --> 00:26:42,500
which are actually pretty interesting

613
00:26:42,500 --> 00:26:44,500
but again, they will go out of date

614
00:26:44,500 --> 00:26:46,500
already,

615
00:26:46,500 --> 00:26:48,500
and then there's the whole 64 bit ARM

616
00:26:48,500 --> 00:26:50,500
so I think people are really waiting

617
00:26:50,500 --> 00:26:52,500
for arm64 servers

618
00:26:52,500 --> 00:26:54,720
I think there's going to be a whole lot of

619
00:26:54,720 --> 00:26:56,720
work on that area.

620
00:26:56,720 --> 00:26:59,460
And then, there are all of those development boards

621
00:26:59,460 --> 00:27:01,460
Raspberry Pi,

622
00:27:01,460 --> 00:27:03,460
Pine64,

623
00:27:03,460 --> 00:27:06,200
Allwinder,

624
00:27:06,200 --> 00:27:08,900
Basically, all of them

625
00:27:08,900 --> 00:27:10,900
sound exciting, but if you

626
00:27:10,900 --> 00:27:12,700
look at them, all of them

627
00:27:12,700 --> 00:27:14,700
have some upstream issues, so it's...

628
00:27:14,700 --> 00:27:18,340
It is really quite frustrating at the moment.

629
00:27:18,340 --> 00:27:20,340
But I think things are really

630
00:27:20,340 --> 00:27:22,800
moving [?]

631
00:27:22,800 --> 00:27:25,880
And then there's this 96Board initiative,

632
00:27:26,060 --> 00:27:28,540
which is actually done by Linaro,

633
00:27:28,540 --> 00:27:30,700
and, so, Linaro supports

634
00:27:30,700 --> 00:27:32,880
Linux on ARM, so you'd think, "wow,

635
00:27:32,880 --> 00:27:34,880
there are some really nice boards coming out!"

636
00:27:34,880 --> 00:27:37,340
and they differentiated

637
00:27:37,340 --> 00:27:39,940
between the consumer edition and the enterprise edition

638
00:27:39,940 --> 00:27:42,880
beside, I bought some consumer-edition boards,

639
00:27:42,880 --> 00:27:45,540
and it's really horrible.

640
00:27:45,540 --> 00:27:48,220
So first of all, I had to spend like half a day

641
00:27:48,220 --> 00:27:50,220
just putting the components

642
00:27:50,660 --> 00:27:53,100
because it uses, like, a nonstandard power supply,

643
00:27:53,100 --> 00:27:55,100
a nonstandard serial console,

644
00:27:55,100 --> 00:27:57,820
so finally I found

645
00:27:57,820 --> 00:28:00,280
all the pieces I needed, and then

646
00:28:00,280 --> 00:28:02,820
I was expecting, well, it's from Linaro!

647
00:28:02,820 --> 00:28:05,140
Surely everything just works upstream!

648
00:28:05,140 --> 00:28:07,600
But it doesn't. It's like

649
00:28:07,600 --> 00:28:09,600
yes, I can boot the Linux kernel,

650
00:28:09,600 --> 00:28:11,600
but there's no USB, there's no

651
00:28:11,600 --> 00:28:13,600
Wifi, no nothing...

652
00:28:15,080 --> 00:28:17,080
So, yes, that's a little bit frustrating.

653
00:28:17,080 --> 00:28:19,140
On the enterprise edition,

654
00:28:19,140 --> 00:28:21,140
I think that looks more interesting.

655
00:28:21,140 --> 00:28:23,140
You know, that's more standardized.

656
00:28:23,140 --> 00:28:26,620
But again, there have been some delays.

657
00:28:28,620 --> 00:28:32,620
[audience; unintellegible]

658
00:28:32,620 --> 00:28:34,620
Yes, OK.

659
00:28:34,620 --> 00:28:36,620
So that would be interesting to see.

660
00:28:36,620 --> 00:28:39,420
So, the questions that I actually have nowadays

661
00:28:39,420 --> 00:28:41,420
is, so...

662
00:28:41,420 --> 00:28:43,420
Because of those changes,

663
00:28:43,420 --> 00:28:45,420
because of having, you know,

664
00:28:45,420 --> 00:28:47,420
a mode of U-boot, most of those

665
00:28:47,420 --> 00:28:49,420
new devices having a U-boot

666
00:28:49,420 --> 00:28:50,880
with distro-support,

667
00:28:50,880 --> 00:28:53,040
having a kernel which, you know,

668
00:28:53,040 --> 00:28:55,040
one kernel image that works on all of those

669
00:28:55,040 --> 00:28:57,040
devices which are supported,

670
00:28:57,040 --> 00:28:59,560
it's really easy to support

671
00:28:59,560 --> 00:29:01,560
a new device?

672
00:29:01,560 --> 00:29:04,100
As long as it's supported by the kernel.

673
00:29:04,100 --> 00:29:06,360
But, at the same time, I think it's a big

674
00:29:06,360 --> 00:29:07,740
challenge for Debian.

675
00:29:07,740 --> 00:29:10,280
Because right now, if you look at armhf,

676
00:29:10,280 --> 00:29:12,220
we basically say, well,

677
00:29:12,220 --> 00:29:14,220
hint the installer,

678
00:29:14,220 --> 00:29:16,220
and if there's a device tree,

679
00:29:16,220 --> 00:29:18,220
it's probably going to work.

680
00:29:18,220 --> 00:29:21,180
But, what does that mean, right?

681
00:29:23,180 --> 00:29:25,180
And...

682
00:29:25,180 --> 00:29:28,140
which really work, which means,

683
00:29:28,140 --> 00:29:29,880
so, we have Vagrant

684
00:29:29,880 --> 00:29:31,880
having U-boot support

685
00:29:31,880 --> 00:29:33,880
in Debian, we have

686
00:29:33,880 --> 00:29:36,240
people testing debian-installer,

687
00:29:36,240 --> 00:29:38,240
testing the Debian kernel, so we have

688
00:29:38,240 --> 00:29:40,820
devices which really work, well supported,

689
00:29:40,820 --> 00:29:43,280
and then we have some devices

690
00:29:43,280 --> 00:29:45,580
on the other hand where, well, yes,

691
00:29:45,580 --> 00:29:47,580
there is a device tree, but no one

692
00:29:47,580 --> 00:29:49,580
has ever tried it. And

693
00:29:49,580 --> 00:29:51,580
at the moment, we have no way

694
00:29:51,580 --> 00:29:54,140
for users to differentiate

695
00:29:54,140 --> 00:29:56,540
those use case... Those

696
00:29:56,540 --> 00:29:58,540
support levels.

697
00:29:58,540 --> 00:30:00,540
So I'm wondering if we need

698
00:30:00,540 --> 00:30:02,540
like a table,

699
00:30:02,540 --> 00:30:04,540
somewhere where maybe

700
00:30:04,540 --> 00:30:06,540
some support levels, like green, yellow...

701
00:30:06,540 --> 00:30:08,120
red?

702
00:30:08,120 --> 00:30:10,120
Where green is, "yes, we have Debian

703
00:30:10,120 --> 00:30:12,120
people who have

704
00:30:12,120 --> 00:30:14,120
testing that stuff",

705
00:30:14,120 --> 00:30:16,120
yellow would be, "well, we have heard some report

706
00:30:16,120 --> 00:30:18,120
that it might work", and

707
00:30:18,120 --> 00:30:20,120
green is, you know, doesn't work,

708
00:30:20,120 --> 00:30:22,120
or we haven't tried that it works.

709
00:30:22,120 --> 00:30:24,120
Maybe we need something like that.

710
00:30:24,120 --> 00:30:26,360
But right now,

711
00:30:26,360 --> 00:30:28,360
I see from users

712
00:30:30,360 --> 00:30:32,360
"I want to run Debian on my ARM device", and

713
00:30:32,360 --> 00:30:35,380
they don't know if it's going to work.

714
00:30:35,380 --> 00:30:37,380
Yes, then...

715
00:30:37,380 --> 00:30:43,400
[audience; unintellegible]

716
00:30:43,400 --> 00:30:45,400
Yes, so Ben is saying we also need

717
00:30:45,400 --> 00:30:47,400
to track what the earliest and the latest

718
00:30:47,400 --> 00:30:49,620
kernel versions that there have been tested.

719
00:30:49,620 --> 00:30:51,800
So I think we really need to

720
00:30:51,800 --> 00:30:53,800
come up with some criteria

721
00:30:53,800 --> 00:30:58,920
to have, you know, define those kernel support levels that indicate that

722
00:30:58,920 --> 00:31:01,920
And yes, the other question is related

723
00:31:01,920 --> 00:31:03,260
to, with all those boards,

724
00:31:03,260 --> 00:31:05,260
how do we actually test them?

725
00:31:05,260 --> 00:31:07,000
So, I keep --

726
00:31:07,000 --> 00:31:10,100
it's really... remember [?]

727
00:31:10,100 --> 00:31:12,100
which is great, but also acknowledge

728
00:31:12,100 --> 00:31:14,100
those boards, they are so cheap!

729
00:31:14,100 --> 00:31:16,100
so it's like, "oh, there's a new board!

730
00:31:16,100 --> 00:31:18,100
It's £30! I'll just get it!"

731
00:31:18,100 --> 00:31:21,020
And then we have, like, those piles of boards

732
00:31:21,020 --> 00:31:23,020
and realize, well, I don't have time

733
00:31:23,020 --> 00:31:25,020
for testing all of that stuff!

734
00:31:25,020 --> 00:31:27,200
I think that's going to be a real challenge.

735
00:31:27,200 --> 00:31:29,320
hundreds -- I don't know,

736
00:31:29,320 --> 00:31:31,320
it's really hundreds of boards coming out.

737
00:31:31,320 --> 00:31:33,900
How do we support all of that?

738
00:31:35,460 --> 00:31:38,420
So, I think that's the question I wanted to raise,

739
00:31:38,420 --> 00:31:41,160
and maybe something we can talk about in the BoF

740
00:31:41,160 --> 00:31:43,380
But yes, I'm obviously

741
00:31:43,380 --> 00:31:45,380
open for questions now.

742
00:31:55,520 --> 00:31:57,520
[James / purpleidea:] Hello.

743
00:31:57,520 --> 00:32:00,200
So, don't quote me exactly,

744
00:32:00,200 --> 00:32:02,200
so, I believe

745
00:32:02,200 --> 00:32:04,200
RedHat has this problem as well, obviously,

746
00:32:04,200 --> 00:32:06,200
I mean, they are obviously more interested in the

747
00:32:06,200 --> 00:32:08,580
ARM64-only server stuff,

748
00:32:08,580 --> 00:32:10,580
but I believe the way they are going about it

749
00:32:10,580 --> 00:32:12,880
maybe it's something could collaborate on

750
00:32:12,880 --> 00:32:15,080
is, they are trying to make sure and push

751
00:32:15,080 --> 00:32:17,080
all the vendors to be standardized

752
00:32:17,080 --> 00:32:19,260
because, as you pointed out,

753
00:32:19,260 --> 00:32:21,540
it's just not, it's crazy

754
00:32:21,540 --> 00:32:24,540
with all the different device tree differences and so on,

755
00:32:24,540 --> 00:32:26,540
so I believe their strategy is to

756
00:32:26,540 --> 00:32:28,840
work with the vendors, and

757
00:32:28,840 --> 00:32:30,840
require everything to be upstreamed, and

758
00:32:30,840 --> 00:32:32,840
no device tree

759
00:32:32,840 --> 00:32:34,840
specifically, to push everything to just boot

760
00:32:34,840 --> 00:32:36,840
with one kernel, and so on.

761
00:32:36,840 --> 00:32:38,840
So maybe that could be

762
00:32:38,840 --> 00:32:40,840
sacrifice a few of the

763
00:32:40,840 --> 00:32:42,840
shitty boards, but work with the vendors

764
00:32:42,840 --> 00:32:45,820
that make the ones that are upstreamed.

765
00:32:45,820 --> 00:32:47,820
[Martin:] Yes, so I may be mistaken, but

766
00:32:47,820 --> 00:32:49,820
as far as I know, RedHat

767
00:32:49,820 --> 00:32:51,620
basically says, "we only support

768
00:32:51,620 --> 00:32:53,620
UEFI and ACPI"

769
00:32:53,620 --> 00:32:55,620
and that's fair enough,

770
00:32:55,620 --> 00:32:57,620
and I think that works for them, because

771
00:32:57,620 --> 00:32:59,900
it's just the server world they care about,

772
00:32:59,900 --> 00:33:01,900
but I think in the case of Debian

773
00:33:01,900 --> 00:33:03,900
there are so many boards out there which

774
00:33:03,900 --> 00:33:05,900
don't need those specs,

775
00:33:05,900 --> 00:33:08,600
and we sort of live, like, in the "real world"

776
00:33:08,600 --> 00:33:10,980
so I don't think we can

777
00:33:10,980 --> 00:33:12,980
Well -- I know it's different. I mean,

778
00:33:12,980 --> 00:33:14,980
if RedHat wants to target

779
00:33:14,980 --> 00:33:16,980
the server people, like, the people

780
00:33:16,980 --> 00:33:18,980
which give money

781
00:33:18,980 --> 00:33:20,980
that's fair enough, that makes sense for them

782
00:33:20,980 --> 00:33:22,980
but Debian, we run everywhere

783
00:33:22,980 --> 00:33:24,980
so I think we need to support

784
00:33:24,980 --> 00:33:26,980
all those weird

785
00:33:26,980 --> 00:33:28,980
cases as well.

786
00:33:28,980 --> 00:33:30,980
And maybe if it gets too weird,

787
00:33:30,980 --> 00:33:32,980
I mean,

788
00:33:32,980 --> 00:33:35,360
I put in some work in the Dragonboard,

789
00:33:35,360 --> 00:33:37,360
and then I realized,

790
00:33:37,360 --> 00:33:39,360
am I actually spending the time because

791
00:33:39,360 --> 00:33:41,360
no one, like, I have heard

792
00:33:41,360 --> 00:33:43,360
from no one that they have

793
00:33:43,360 --> 00:33:45,360
that board, I mean, like [?]

794
00:33:45,360 --> 00:33:47,360
for the Raspberry Pi, but I have heard

795
00:33:47,360 --> 00:33:49,360
like, pretty much no one has the

796
00:33:49,360 --> 00:33:51,360
Dragonboard, so maybe,

797
00:33:51,360 --> 00:33:53,920
...it's not worth my while,

798
00:33:53,920 --> 00:33:55,920
but if there's a board

799
00:33:55,920 --> 00:33:57,920
that people want to use it,

800
00:33:57,920 --> 00:34:00,340
I think we should support it in Debian.

801
00:34:00,340 --> 00:34:02,340
And we do have the infrastructure

802
00:34:02,340 --> 00:34:04,340
so we, you know, it doesn't have to be

803
00:34:04,340 --> 00:34:06,340
UEFI and ACPI,

804
00:34:06,340 --> 00:34:08,340
we can support other devices, because

805
00:34:08,340 --> 00:34:10,340
we have done it before.

806
00:34:10,340 --> 00:34:12,340
But I definitively agree with

807
00:34:12,340 --> 00:34:14,960
the point about getting more standardization

808
00:34:14,960 --> 00:34:16,960
and that stuff, so

809
00:34:16,960 --> 00:34:18,960
I agree, yes.

810
00:34:20,360 --> 00:34:22,920
And the whole distro-support

811
00:34:22,920 --> 00:34:25,600
in U-boot, that has really made things easier for us.

812
00:34:33,219 --> 00:34:35,880
[Phil:] I may begin to say some of the same things Steve has, anyway.

813
00:34:35,880 --> 00:34:38,500
Steve]: So, yes, on the

814
00:34:38,500 --> 00:34:41,219
ACPI versus DT thing,

815
00:34:41,219 --> 00:34:43,219
it's more a question

816
00:34:43,219 --> 00:34:45,980
of the quality of the implementation of the

817
00:34:45,980 --> 00:34:48,800
of the firmware,

818
00:34:48,800 --> 00:34:50,800
and the upstream support that is...

819
00:34:50,800 --> 00:34:52,800
DT isn't fundamentally

820
00:34:52,800 --> 00:34:55,260
worse for upstream support

821
00:34:55,260 --> 00:34:57,780
than ACPI is,

822
00:34:57,780 --> 00:35:00,980
RedHat are

823
00:35:00,980 --> 00:35:02,980
have some reasons

824
00:35:02,980 --> 00:35:04,980
[?] of sensibility,

825
00:35:04,980 --> 00:35:06,980
but then, it's not

826
00:35:06,980 --> 00:35:09,380
fundamentally, it doesn't fundamentally stop it

827
00:35:09,380 --> 00:35:11,380
people supporting it, specially

828
00:35:11,380 --> 00:35:13,380
a community distro like Debian.

829
00:35:13,380 --> 00:35:16,340
I was also going to ask Martin,

830
00:35:16,340 --> 00:35:18,340
have you talked to

831
00:35:18,340 --> 00:35:20,560
people like kernel CI

832
00:35:20,560 --> 00:35:24,660
about testing and coverage stuff?

833
00:35:24,660 --> 00:35:26,660
[Martin:] Yes, not really, but

834
00:35:26,660 --> 00:35:29,740
I think there are some things we should look into.

835
00:35:29,740 --> 00:35:31,740
[Steve:] Yes, because the whole --

836
00:35:31,740 --> 00:35:33,740
Obviously, making sure the kernel boots

837
00:35:33,740 --> 00:35:35,740
on random hardware

838
00:35:35,740 --> 00:35:38,080
stuff, is exactly what that's doing

839
00:35:39,740 --> 00:35:42,360
and there's at least infrastructure there that might be

840
00:35:42,360 --> 00:35:44,740
nice to play with.

841
00:35:46,480 --> 00:35:48,480
[Martin:] Yes. I think that's a good idea.

842
00:35:50,480 --> 00:35:52,480
[sledge:] So, on the whole 96Boards thing,

843
00:35:52,480 --> 00:35:54,480
sorry!

844
00:35:54,480 --> 00:35:56,480
Most of the engineers involved

845
00:35:56,480 --> 00:35:58,480
are totally aware of

846
00:35:58,480 --> 00:36:00,480
how [?] it really is.

847
00:36:00,480 --> 00:36:02,480
We tried to tell management

848
00:36:02,480 --> 00:36:04,480
they would --

849
00:36:04,480 --> 00:36:06,480
They don't want to listen.

850
00:36:06,480 --> 00:36:08,480
Umm.. So,

851
00:36:08,480 --> 00:36:10,480
there has been a huge amount of pushback

852
00:36:10,480 --> 00:36:13,000
saying, you know, "we're Linaro

853
00:36:13,000 --> 00:36:15,380
we should make sure this is all upstreamed".

854
00:36:17,380 --> 00:36:19,380
[Martin:] Well, I am aware

855
00:36:19,380 --> 00:36:21,380
it's just, Linaro

856
00:36:21,380 --> 00:36:23,380
has a really good brand,

857
00:36:23,380 --> 00:36:25,380
so people expect, you know, when I saw

858
00:36:25,380 --> 00:36:27,380
96Boards it's Linaro,

859
00:36:27,380 --> 00:36:29,800
obviously that stuff it's going to work!

860
00:36:29,800 --> 00:36:31,800
and that's why I was really disappointed.

861
00:36:31,800 --> 00:36:33,800
[Steve:] One positive thing there

862
00:36:33,800 --> 00:36:35,800
is that the first DE board

863
00:36:35,800 --> 00:36:38,300
the SoC does basically work upstream

864
00:36:38,300 --> 00:36:40,440
already with current upstream kernel

865
00:36:40,440 --> 00:36:42,440
it's not like there's some patches still

866
00:36:42,440 --> 00:36:44,440
to go in. Apart from the PCI, it should basically

867
00:36:44,440 --> 00:36:47,400
work... So, hopefully,

868
00:36:47,400 --> 00:36:49,820
hopefully, that's going to be a much

869
00:36:49,820 --> 00:36:51,820
less spectacular

870
00:36:51,820 --> 00:36:53,820
story than the

871
00:36:53,820 --> 00:36:55,820
consumer-edition boards have been.

872
00:36:55,820 --> 00:36:57,820
As they are unfortunate.

873
00:37:01,860 --> 00:37:03,860
[Sledge:] The first EE board

874
00:37:03,860 --> 00:37:05,860
the [?]board, is due to start shipping

875
00:37:05,860 --> 00:37:07,860
really soon now.

876
00:37:07,860 --> 00:37:09,860
There are examples already out there

877
00:37:09,860 --> 00:37:11,860
with engineers for validation.

878
00:37:11,860 --> 00:37:14,300
Literally, we are talking the next couple of weeks

879
00:37:14,300 --> 00:37:16,300
is what I have been told.

880
00:37:16,300 --> 00:37:18,700
That's the first 96Boards I would

881
00:37:18,700 --> 00:37:20,700
actually spend any time on at all personally,

882
00:37:20,700 --> 00:37:23,240
the CE boards are a joke.

883
00:37:29,020 --> 00:37:31,020
I forgot what else I was going to say. Oh!

884
00:37:31,020 --> 00:37:33,020
Yes! Then...

885
00:37:33,020 --> 00:37:35,380
I guess we will go through a lot of this again

886
00:37:35,380 --> 00:37:37,380
in the ARM BoF later on

887
00:37:37,380 --> 00:37:39,480
in terms of

888
00:37:39,480 --> 00:37:41,480
which things we support.

889
00:37:44,660 --> 00:37:46,660
We will carry on with the discussion.

890
00:37:54,720 --> 00:37:57,560
[Vagrant:] Um... Is this working?

891
00:37:57,560 --> 00:37:59,560
Yes, so...

892
00:37:59,560 --> 00:38:01,560
We have got all this great support for

893
00:38:01,560 --> 00:38:03,560
distro-boot command and U-boot, and

894
00:38:03,560 --> 00:38:05,560
now we are starting to get

895
00:38:05,560 --> 00:38:07,560
to UEFI emulation

896
00:38:07,560 --> 00:38:09,560
in U-boot, so even for boards

897
00:38:09,560 --> 00:38:11,560
that don't have UEFI emulation--

898
00:38:11,560 --> 00:38:13,560
UEFI support, if they support

899
00:38:13,560 --> 00:38:15,560
U-boot, it might work

900
00:38:15,560 --> 00:38:17,560
although that means all the standarization

901
00:38:17,560 --> 00:38:19,560
we worked towards, we throw it away.,

902
00:38:19,560 --> 00:38:21,560
Meh!

903
00:38:23,560 --> 00:38:26,300
[Martin:] Yes, I think that's something we need to figure out,

904
00:38:26,300 --> 00:38:29,240
which one do we want to standardize on,

905
00:38:29,240 --> 00:38:31,240
or is that something we want to

906
00:38:31,240 --> 00:38:33,240
leave up to the user.

907
00:38:33,240 --> 00:38:35,480
but yes,

908
00:38:35,480 --> 00:38:37,560
I mean, I think one

909
00:38:37,560 --> 00:38:39,560
I mean, I guess it was

910
00:38:39,560 --> 00:38:41,560
so confusing, because there are like

911
00:38:41,560 --> 00:38:43,560
all those different ways, but

912
00:38:44,920 --> 00:38:46,920
what I really wanted to show is that

913
00:38:46,920 --> 00:38:48,920
things are getting much more

914
00:38:48,920 --> 00:38:51,100
standardized and much better.

915
00:38:51,100 --> 00:38:53,560
So, it used to be really

916
00:38:53,560 --> 00:38:55,560
pretty horrible, and nowadays,

917
00:38:55,560 --> 00:38:57,560
you know, if a platform

918
00:38:57,560 --> 00:38:59,560
uses a modern

919
00:38:59,560 --> 00:39:01,560
U-boot, if it has

920
00:39:01,560 --> 00:39:03,560
upstream support, then it is

921
00:39:03,560 --> 00:39:05,560
actually pretty trivial to add

922
00:39:05,560 --> 00:39:07,560
Debian support, and

923
00:39:07,560 --> 00:39:09,560
I think that wasn't the case

924
00:39:09,560 --> 00:39:10,660
in the past.

925
00:39:10,660 --> 00:39:12,660
I think Ben had another one?

926
00:39:20,800 --> 00:39:23,580
[Ben:] So, I'm

927
00:39:26,540 --> 00:39:29,960
[laughs]

928
00:39:29,960 --> 00:39:33,280
I'm interested to know how much

929
00:39:33,280 --> 00:39:36,080
how much interest there is among the ARM porters

930
00:39:36,080 --> 00:39:38,500
in graphics support.

931
00:39:38,500 --> 00:39:40,380
GPU support, rather

932
00:39:40,380 --> 00:39:42,380
than settling for dumb framebuffers.

933
00:39:42,380 --> 00:39:44,380
How many...

934
00:39:44,380 --> 00:39:46,380
How many of these boards...

935
00:39:46,380 --> 00:39:48,380
Quite a lot of these boards do have HDMI

936
00:39:48,380 --> 00:39:50,380
and I don't know

937
00:39:50,380 --> 00:39:52,780
to what degree they are actually supported.

938
00:39:52,780 --> 00:39:56,380
Are any current projected work

939
00:39:56,380 --> 00:40:00,280
which definitively is using the

940
00:40:00,280 --> 00:40:04,700
GPU on ARM system, and

941
00:40:04,700 --> 00:40:07,320
what's in Debian,

942
00:40:07,320 --> 00:40:09,520
is the Debian base system

943
00:40:09,780 --> 00:40:12,480
does Debian... What's in Debian does not

944
00:40:12,480 --> 00:40:14,480
support GPU.

945
00:40:14,480 --> 00:40:17,980
[Martin:] So, I can't speak for Vagrant...

946
00:40:17,980 --> 00:40:19,980
I have personally done some work

947
00:40:19,980 --> 00:40:21,980
on the Tegra recently,

948
00:40:21,980 --> 00:40:23,980
and nVidia is actually

949
00:40:23,980 --> 00:40:27,120
working upstream on [?]

950
00:40:27,120 --> 00:40:29,640
so I'm really interested in it

951
00:40:29,640 --> 00:40:31,640
but I think that a lot of

952
00:40:31,640 --> 00:40:33,640
the board used, there's money

953
00:40:33,640 --> 00:40:37,160
GPUs I'm not sure would be

954
00:40:37,160 --> 00:40:40,380
...you can get a [laughs]

955
00:40:40,380 --> 00:40:43,760
can we get a microphone for Steve?

956
00:40:51,780 --> 00:40:53,780
[Sledge:] So, on the Mali front,

957
00:40:53,780 --> 00:40:55,240
there has been a lot of haste where we

958
00:40:55,240 --> 00:40:57,240
have been scared of releasing any of this

959
00:40:57,240 --> 00:40:59,880
in any way, shape or form,

960
00:40:59,880 --> 00:41:01,880
without huge

961
00:41:01,880 --> 00:41:04,580
[?]-relays and all that kind of stuff.

962
00:41:04,580 --> 00:41:06,880
So it's not really distributable.

963
00:41:06,880 --> 00:41:08,880
Even, at all.

964
00:41:08,880 --> 00:41:12,300
We are a long way of it being releasable free,

965
00:41:12,300 --> 00:41:15,640
There are packages coming that we

966
00:41:15,640 --> 00:41:17,640
should be getting shippable in non-free

967
00:41:17,640 --> 00:41:19,640
at least if you want to get full acceleration

968
00:41:19,640 --> 00:41:21,640
on your Mali stuff.

969
00:41:23,640 --> 00:41:25,640
Hopefully, that will solve some of the problems

970
00:41:25,640 --> 00:41:27,640
There is a lot, there are a lot of people

971
00:41:27,640 --> 00:41:29,640
in [?] who are very very keen on

972
00:41:29,640 --> 00:41:32,180
supporting it properly, free and upstreamed.

973
00:41:32,180 --> 00:41:34,620
It's a long fight.

974
00:41:34,620 --> 00:41:35,940
It will take a while.

975
00:41:35,940 --> 00:41:39,040
I mean, most of the Mali driver developers

976
00:41:39,040 --> 00:41:41,040
themselves I have spoken to, would love to

977
00:41:41,040 --> 00:41:43,040
make it free. It just comes down

978
00:41:43,040 --> 00:41:45,040
to legal people

979
00:41:45,040 --> 00:41:47,040
being scared.

980
00:41:53,040 --> 00:41:55,040
[Tobi:] Are there some questions left?

981
00:41:58,780 --> 00:42:00,080
[Martin:] Well, thanks for coming!

982
00:42:00,080 --> 00:42:02,080
And there is going to be the ARM BoF

983
00:42:02,080 --> 00:42:04,080
later today, and

984
00:42:04,080 --> 00:42:06,080
Vagrant is also going to talk about his experience

985
00:42:06,080 --> 00:42:09,760
about running a build network

986
00:42:09,760 --> 00:42:11,760
on armhf boards..

987
00:42:11,760 --> 00:42:13,160
Thanks!

988
00:42:18,060 --> 00:42:20,060
[audience clapping]