WEBVTT 00:00:03.060 --> 00:00:05.000 So, I think we are ready to start 00:00:05.020 --> 00:00:08.770 So, next talk is from Martin, about Debian on ARM devices. 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 00:00:21.970 --> 00:00:27.130 I would say it's sort of a mix of different topics 00:00:27.130 --> 00:00:27.280 it's basically --- 00:00:27.280 --> 00:00:29.130 I mean, basically I often get it's basically --- 00:00:29.130 --> 00:00:32.020 I mean, basically I often get 00:00:32.080 --> 00:00:35.240 the question from users 00:00:35.530 --> 00:00:38.930 "Well, Debian works on this particular ARM device, 00:00:39.110 --> 00:00:42.080 I have a device which is like really really similar, 00:00:42.080 --> 00:00:44.860 so surely Debian should work on it, right?" 00:00:44.860 --> 00:00:48.640 And so far, the answer unfortunately was usually "no" 00:00:48.640 --> 00:00:53.020 and - and it's really frustrating for users 00:00:53.020 --> 00:00:55.530 because they don't see why. 00:00:55.530 --> 00:00:58.570 You know, the device is very much the same, so why doesn't it just work. 00:00:58.570 --> 00:01:01.310 And so, basically what I'm trying to do is 00:01:01.310 --> 00:01:04.040 to show like a little bit behind the scenes 00:01:04.040 --> 00:01:06.510 of how Debian on ARM works 00:01:07.040 --> 00:01:09.620 And there has been a whole lot of progres 00:01:09.620 --> 00:01:13.130 So I'm going to show how did it work, 00:01:13.130 --> 00:01:15.130 what are the improvements, and 00:01:15.130 --> 00:01:17.600 and how is it going to work in the future 00:01:19.930 --> 00:01:21.880 And it's all more from a develeoper perspective 00:01:22.110 --> 00:01:25.880 so, it's like, how do we support it in the Debian Installer 00:01:26.220 --> 00:01:31.440 its' like a mix of stuff, and I should say, 00:01:31.680 --> 00:01:35.110 I'm really looking at it from somebody who basically 00:01:35.110 --> 00:01:37.510 adds support for devices in the installer 00:01:37.510 --> 00:01:40.460 but I'm not like a kernel guy or anything, so 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 00:01:45.400 --> 00:01:48.800 but I'm not going to really drill down really deep down anyway 00:01:48.800 --> 00:01:51.680 But if I'm incorrect, I'm sure that 00:01:51.680 --> 00:01:53.680 there are plenty of people that will correct me. 00:01:54.170 --> 00:02:00.820 So, where do you find ARM? So it's pretty much everywhere these days, I mean... 00:02:01.150 --> 00:02:05.040 Pretty much every phone has an ARM chip in it 00:02:07.480 --> 00:02:11.950 All those "Internet of Things" gadgets are ARM-based 00:02:12.530 --> 00:02:18.480 You have NAS devices, and that's really the area I used to focus on 00:02:19.020 --> 00:02:22.600 those small boxes where you basically add a hard drive 00:02:22.600 --> 00:02:26.730 and most people just use it for storage, but it's actually a 00:02:27.130 --> 00:02:30.150 full PC where you can install Debian on it 00:02:30.640 --> 00:02:33.930 so I always found that to be very interesting 00:02:34.280 --> 00:02:37.310 and nowadays you have a lot of development boards 00:02:37.460 --> 00:02:41.280 And I'm not sure whether "development boards" is the right word 00:02:41.280 --> 00:02:45.130 Because when I hear "development boards" I think of it as really expensive, 00:02:45.640 --> 00:02:48.110 Like 5K for boards or something 00:02:48.420 --> 00:02:52.400 But nowadays you have those, maybe, a better board would be like bareboards 00:02:52.400 --> 00:02:56.200 Like "Raspberry Pi", like basically it's just the board 00:02:56.200 --> 00:02:59.820 it does not come with a case, you can buy those as well 00:02:59.820 --> 00:03:03.060 and it's like 30 dollars or something, you can get 00:03:03.370 --> 00:03:06.530 And that gets pretty much where most of the 00:03:06.530 --> 00:03:10.950 excitement is going for Debian users at this moment 00:03:11.220 --> 00:03:13.930 And that can cause a lot of frustration 00:03:16.640 --> 00:03:20.150 And everybody says that ARM is going to be big on servers 00:03:20.150 --> 00:03:24.020 and I think that's something we ar going to see 00:03:24.020 --> 00:03:26.600 But right now, again, it's 00:03:26.600 --> 00:03:28.600 a little bit frustrating 00:03:30.600 --> 00:03:34.000 How does it work as a Deban Installer 00:03:34.000 --> 00:03:36.000 There are basically two 00:03:36.970 --> 00:03:40.280 ways of installing on those ARM Pi devices 00:03:41.020 --> 00:03:44.350 So the, like, historic, that we normally 00:03:44.350 --> 00:03:47.950 would be to install on, like, ascreen 00:03:47.950 --> 00:03:49.950 can be a serial console, 00:03:50.310 --> 00:03:54.550 and then you just download via the network 00:03:54.750 --> 00:03:58.970 and then you just download via the network 00:03:58.970 --> 00:04:00.970 from a CD image or wherever, 00:04:00.970 --> 00:04:04.660 But the other method, which we actually use for those 00:04:04.660 --> 00:04:07.910 net devices was a network console 00:04:07.910 --> 00:04:11.460 where you basically ssh into the installer 00:04:11.730 --> 00:04:14.440 and you perform the installation via ssh 00:04:15.400 --> 00:04:19.839 and that was really the only way, because those mass devices 00:04:19.839 --> 00:04:22.950 don't have any I/O, so I 00:04:23.200 --> 00:04:25.370 even in there, you can 00:04:25.370 --> 00:04:28.080 it's just a serial console, most of them 00:04:28.330 --> 00:04:32.000 That's something we didn't want to require from the user 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, 00:04:36.840 --> 00:04:38.840 screen support, so basically 00:04:40.020 --> 00:04:43.330 so you can have multiple sessions with in vi, 00:04:43.330 --> 00:04:47.110 which can be useful if you have an open shell to debug 00:04:49.110 --> 00:04:53.500 And so, how -- And so, this is really looking back at 00:04:53.500 --> 00:04:55.500 like running Debian on NAS devices 00:04:55.500 --> 00:04:58.420 which is something that used to be really popular 00:04:58.420 --> 00:05:02.500 And the way it worked was basically 00:05:02.500 --> 00:05:05.200 that we provided an installer image 00:05:05.200 --> 00:05:07.200 which was sort of a firmware image 00:05:07.200 --> 00:05:09.200 as a lot of those NAS devices 00:05:09.200 --> 00:05:12.080 have like a firmware upgrade mechanism 00:05:12.240 --> 00:05:14.180 and so we would basically fake 00:05:14.180 --> 00:05:17.240 we would create a firmware image 00:05:17.300 --> 00:05:19.520 which the software would accept 00:05:19.600 --> 00:05:22.460 but instead of a firmware update 00:05:22.540 --> 00:05:24.840 it would actually contain the Debian installer 00:05:24.840 --> 00:05:27.620 so you would install that upgrade 00:05:27.640 --> 00:05:30.080 you would reboot, and 00:05:30.080 --> 00:05:32.860 you could ssh to the installer 00:05:32.920 --> 00:05:36.360 and obviously, in order to ssh to the installer 00:05:36.360 --> 00:05:38.020 it needs to bring up the network 00:05:38.020 --> 00:05:41.060 and there is a tool called oldsys-preseed 00:05:41.060 --> 00:05:43.280 that basically reads the network configuration 00:05:43.280 --> 00:05:45.280 from the device 00:05:45.280 --> 00:05:47.280 and then sets up the network 00:05:47.280 --> 00:05:51.820 and it can always recognize the DHCP 00:05:51.820 --> 00:05:53.820 and then the user connects via ssh 00:05:53.820 --> 00:05:57.600 again, there would be some indication, maybe 00:05:57.600 --> 00:05:59.600 you know, there would be a "beep" 00:05:59.600 --> 00:06:01.260 or maybe change the LED 00:06:01.260 --> 00:06:03.260 to indicate that the installer is ready 00:06:03.260 --> 00:06:05.260 and then, the user basically performs 00:06:05.260 --> 00:06:07.260 a regular installation 00:06:07.260 --> 00:06:09.260 with normal d-i; they don't have to 00:06:09.260 --> 00:06:11.260 do anything differently. 00:06:12.320 --> 00:06:14.520 And at the end, flash-kernel runs 00:06:14.520 --> 00:06:17.340 to make the system bootable 00:06:17.340 --> 00:06:20.460 flash-kernel is called that way 00:06:20.460 --> 00:06:20.660 because it used to support flash-kernel is called that way 00:06:20.660 --> 00:06:22.660 because it used to support 00:06:22.660 --> 00:06:25.380 like the initial device it supported 00:06:25.380 --> 00:06:27.380 booted from flash 00:06:27.380 --> 00:06:29.380 but it also generates bootable devices 00:06:29.380 --> 00:06:31.380 bootable images of disk devices 00:06:34.180 --> 00:06:36.560 so it really, flash-kernel really requires 00:06:36.560 --> 00:06:38.560 understanding of each device 00:06:38.560 --> 00:06:41.080 and our philosophy 00:06:41.080 --> 00:06:43.080 in those cases, with those NAS devices 00:06:43.080 --> 00:06:44.040 was really, 00:06:44.040 --> 00:06:46.040 we don't touch anything 00:06:46.040 --> 00:06:48.040 in the firmware, like 00:06:48.040 --> 00:06:50.040 in the configuration, 00:06:50.040 --> 00:06:52.040 so sometimes 00:06:52.040 --> 00:06:54.700 instead of changing the root device 00:06:54.700 --> 00:06:56.700 in the u-boot config we would actually 00:06:56.700 --> 00:06:58.700 hard-code that in the ramdisk 00:06:58.700 --> 00:07:02.720 just because we wanted people to go back 00:07:02.720 --> 00:07:05.160 to the original firmware if they had to 00:07:05.160 --> 00:07:07.700 if they had to send it in for repair or something 00:07:07.700 --> 00:07:09.700 and 00:07:09.700 --> 00:07:12.500 and that kind of approach really worked well 00:07:12.500 --> 00:07:14.500 so I think we really had a lot of 00:07:14.500 --> 00:07:16.500 people, lot of users running 00:07:16.500 --> 00:07:18.500 in Debian in those kind of NAS devices 00:07:18.500 --> 00:07:20.860 and it was really easy to do. 00:07:20.860 --> 00:07:22.580 You get a firmware image, 00:07:22.580 --> 00:07:25.380 you connect to the installer via ssh, 00:07:25.380 --> 00:07:27.380 and it just works, it's a normal 00:07:27.380 --> 00:07:28.620 debian-installer, the way 00:07:28.620 --> 00:07:30.620 everybody knows it, 00:07:30.620 --> 00:07:32.620 because some of the other distros 00:07:32.620 --> 00:07:33.820 they basically provide, like, 00:07:33.820 --> 00:07:35.240 tarballs and instructions 00:07:35.240 --> 00:07:37.240 so you need to partition a disk, 00:07:37.240 --> 00:07:39.240 need to un-tar it, 00:07:39.240 --> 00:07:41.240 you need to change those files, 00:07:41.240 --> 00:07:43.240 and even if it sounds simple, 00:07:43.240 --> 00:07:45.240 it's so many steps that 00:07:45.240 --> 00:07:47.620 you always... you often get something wrong 00:07:47.620 --> 00:07:50.380 and then you put the drive into the 00:07:50.380 --> 00:07:52.380 NAS device, and it doesn't boot, and you don't know why 00:07:52.380 --> 00:07:54.800 where did you make that mistake, 00:07:54.800 --> 00:07:56.000 which step 00:07:56.000 --> 00:07:58.000 and you basically have to start from scratch 00:07:58.000 --> 00:08:00.440 so Debian really provided something unique 00:08:00.440 --> 00:08:02.440 by adding 00:08:02.440 --> 00:08:04.440 the debian-installer support 00:08:04.440 --> 00:08:06.440 but anyway, that's the way 00:08:06.440 --> 00:08:08.440 it sort of used to work. 00:08:08.440 --> 00:08:10.440 Nowadays, with a lot of those bareboard 00:08:10.440 --> 00:08:12.440 it's much easier 00:08:12.440 --> 00:08:14.440 I'll get to that. 00:08:15.180 --> 00:08:18.100 So at the moment there are three different ARM ports: 00:08:18.100 --> 00:08:20.100 There is the old armel 00:08:20.100 --> 00:08:22.100 which used to be the "newer" ARM 00:08:22.100 --> 00:08:24.820 and now it's old, 00:08:24.820 --> 00:08:26.820 and one of the discussions 00:08:26.820 --> 00:08:28.820 that we are probably going to have later today on the BoF 00:08:28.820 --> 00:08:31.220 is about, should we remove that 00:08:31.220 --> 00:08:33.220 after Stretch. 00:08:33.220 --> 00:08:36.440 There is armhf and the arm64 00:08:37.640 --> 00:08:40.539 and we get basically the question I hope to answer. 00:08:40.539 --> 00:08:43.299 If, you know, device A works, 00:08:43.299 --> 00:08:45.300 I have a device which is really similar, 00:08:45.300 --> 00:08:47.300 but it doesn't work. Why is that? 00:08:49.300 --> 00:08:51.300 So, heh, 00:08:51.300 --> 00:08:53.300 There have been a lot of changes 00:08:53.300 --> 00:08:58.120 in various upstream projects, specially 00:08:58.120 --> 00:09:00.120 the kernel and U-boot 00:09:00.120 --> 00:09:02.120 that really make things easier. 00:09:02.120 --> 00:09:04.120 So, in the past 00:09:04.120 --> 00:09:07.260 we basically had 00:09:07.260 --> 00:09:09.260 a kernel image 00:09:09.260 --> 00:09:10.780 for each platform, 00:09:10.780 --> 00:09:12.780 where a platform is basically like 00:09:12.780 --> 00:09:14.780 a SSE family 00:09:14.780 --> 00:09:17.660 and there would be a different image 00:09:17.660 --> 00:09:21.540 because ARM takes a long time 00:09:21.540 --> 00:09:23.540 to compile, there was always some debate 00:09:23.540 --> 00:09:26.100 about adding a new platform 00:09:26.100 --> 00:09:28.100 because there would be a new 00:09:28.100 --> 00:09:30.600 image flavor, which takes some time, 00:09:31.740 --> 00:09:33.540 and that was just really like, 00:09:33.540 --> 00:09:36.280 we couldn't just have one ARM kernel 00:09:36.280 --> 00:09:38.280 which works everywhere. 00:09:38.280 --> 00:09:40.280 And a lot of people didn't understand 00:09:40.280 --> 00:09:42.280 why you had a different kernel 00:09:42.280 --> 00:09:44.280 because different platforms, 00:09:44.280 --> 00:09:48.040 although there has been a lot of progress upstream, 00:09:48.040 --> 00:09:51.580 at least nowadays, with armhf 00:09:51.580 --> 00:09:54.020 and with arm64 00:09:54.020 --> 00:09:56.020 we just have one kernel. 00:09:57.340 --> 00:09:59.980 And upstream basically 00:09:59.980 --> 00:10:02.740 Maybe some of you remember the rant 00:10:02.740 --> 00:10:04.740 by Niels about 00:10:04.740 --> 00:10:06.740 the ARM people doing everything 00:10:06.740 --> 00:10:08.180 in different ways, 00:10:08.180 --> 00:10:10.180 and there has been a lot of standarization 00:10:10.180 --> 00:10:12.180 over the years. 00:10:12.180 --> 00:10:14.180 Basically, the other thing is 00:10:14.180 --> 00:10:16.180 there used to be for each device 00:10:16.180 --> 00:10:18.180 there was a board file 00:10:18.180 --> 00:10:20.180 it was like a C file 00:10:20.180 --> 00:10:22.580 to initialize the different components, 00:10:22.580 --> 00:10:24.580 and the boot loader would 00:10:24.580 --> 00:10:27.660 pass the machine ID to the kernel, 00:10:27.660 --> 00:10:30.380 and it would load that boot file. 00:10:30.380 --> 00:10:32.380 And nowadays, 00:10:32.380 --> 00:10:34.380 there is basically a 00:10:34.380 --> 00:10:36.380 device tree in the kernel, 00:10:36.380 --> 00:10:38.380 which is a description of the hardware 00:10:40.040 --> 00:10:41.800 and it will basically compile it 00:10:41.800 --> 00:10:44.580 to, like, a binary blob, the .dtb. 00:10:44.580 --> 00:10:46.580 And, so, basically you just need 00:10:46.580 --> 00:10:48.580 the kernel image, and 00:10:48.580 --> 00:10:51.200 the .dtb, which is hardware-specific, 00:10:51.200 --> 00:10:53.200 and then it boots. 00:10:53.200 --> 00:10:55.640 And obviously, for us in Debian 00:10:55.640 --> 00:10:57.640 that makes it much much easier 00:10:57.640 --> 00:11:00.540 to support a lot of devices. 00:11:01.960 --> 00:11:04.560 The other thing that changed in U-boot, 00:11:06.040 --> 00:11:09.080 when you install the Debian kernel image, 00:11:09.080 --> 00:11:10.720 it creates 00:11:10.720 --> 00:11:13.900 the vmlinux file 00:11:13.900 --> 00:11:16.740 and also the RAM disk 00:11:16.740 --> 00:11:18.740 but with U-boot, 00:11:18.740 --> 00:11:20.740 you couldn't actually load those files 00:11:20.740 --> 00:11:22.740 correctly. You basically 00:11:22.740 --> 00:11:25.840 had to wrap them in a U-boot image 00:11:25.840 --> 00:11:28.420 and it's not really hard 00:11:28.420 --> 00:11:31.440 it's just the command initram, 00:11:31.440 --> 00:11:33.440 but all of the different devices had 00:11:33.440 --> 00:11:34.940 different load addresses, 00:11:34.940 --> 00:11:36.940 and, again, that's hardware-specific knowledge 00:11:36.940 --> 00:11:39.360 that flash-kernel needed to know. 00:11:39.360 --> 00:11:40.820 And nowadays, 00:11:40.820 --> 00:11:42.720 there is a command which 00:11:42.720 --> 00:11:44.720 directly loads the kernel, 00:11:44.720 --> 00:11:48.380 so that, again, was a step to make things easier. 00:11:48.380 --> 00:11:52.320 And the last thing which really made 00:11:52.320 --> 00:11:54.320 things easier is distro support 00:11:54.320 --> 00:11:56.320 in U-boot. 00:11:56.320 --> 00:11:58.320 So, basically, in the past 00:11:58.320 --> 00:12:00.320 every U-boot, every 00:12:00.320 --> 00:12:02.320 devices in U-boot, 00:12:02.320 --> 00:12:04.320 booted in a different way, 00:12:05.240 --> 00:12:08.700 just in terms on where would it load 00:12:08.700 --> 00:12:10.700 the file from, or 00:12:10.700 --> 00:12:12.700 what variables would it use, and 00:12:12.700 --> 00:12:14.700 nowadays there is something called distro-support 00:12:14.700 --> 00:12:16.700 which is basically a standardized way 00:12:16.700 --> 00:12:18.700 to boot a Linux distro 00:12:19.300 --> 00:12:21.660 with U-boot. 00:12:21.660 --> 00:12:23.660 There are basically 00:12:23.660 --> 00:12:25.660 two ways, either can 00:12:25.660 --> 00:12:27.660 read a config file, 00:12:27.660 --> 00:12:29.660 or it can basically run a 00:12:29.660 --> 00:12:31.660 boot script, and that's what 00:12:31.660 --> 00:12:33.660 we use in Debian, so we basically have 00:12:33.660 --> 00:12:35.660 a generic boot script 00:12:35.660 --> 00:12:38.100 which loads the kernel, 00:12:38.100 --> 00:12:40.100 loads the ramdisk, the .dtb, 00:12:40.100 --> 00:12:42.100 and boots Debian. 00:12:42.100 --> 00:12:44.100 It can use the generic 00:12:44.100 --> 00:12:46.100 bootscript in almost all 00:12:46.100 --> 00:12:47.860 of the modern devices. 00:12:47.860 --> 00:12:49.860 So nowadays, because of that, 00:12:49.860 --> 00:12:51.860 it's much more standard, and 00:12:51.860 --> 00:12:53.860 it's much easier to support 00:12:53.860 --> 00:12:56.440 those devices. 00:12:56.440 --> 00:12:59.980 So here are some examples of flash-kernel 00:12:59.980 --> 00:13:02.800 So, basically, flash-kernel has like a database 00:13:02.800 --> 00:13:04.800 of devices which it supports 00:13:04.800 --> 00:13:07.580 so it's like the machine entry 00:13:07.580 --> 00:13:09.580 in /proc/cpuinfo, 00:13:09.580 --> 00:13:11.960 and then the kernel flavors 00:13:11.960 --> 00:13:13.960 it can run 00:13:13.960 --> 00:13:15.960 and, so, this one is 00:13:15.960 --> 00:13:17.960 an old device, it still uses 00:13:17.960 --> 00:13:19.960 a board file, and it 00:13:19.960 --> 00:13:22.400 needs the U-boot wrapper, 00:13:22.400 --> 00:13:24.400 So... 00:13:24.400 --> 00:13:27.180 You are basically setting the machine ID 00:13:27.180 --> 00:13:29.840 those are the flash partitions 00:13:29.840 --> 00:13:31.840 where the kernel and the 00:13:31.840 --> 00:13:33.840 ramdisk are stored, and 00:13:33.840 --> 00:13:35.660 that's the load address for the 00:13:35.660 --> 00:13:37.660 U-boot wrapper 00:13:39.660 --> 00:13:43.120 And, now, that's a device 00:13:43.120 --> 00:13:45.120 which used to have 00:13:45.120 --> 00:13:47.120 a boot file, 00:13:47.120 --> 00:13:49.120 and which then migrated 00:13:49.120 --> 00:13:51.120 to a .dtb, 00:13:51.120 --> 00:13:53.120 so basically, heh, 00:13:53.120 --> 00:13:56.160 that was really really painful for Debian 00:13:56.160 --> 00:13:58.800 so, basically, the kernel people said 00:13:58.800 --> 00:14:00.800 "Oh, you are going to move to device tree, 00:14:00.800 --> 00:14:02.060 so don't worry, 00:14:02.060 --> 00:14:04.460 we are not gonna remove those old board files, 00:14:04.460 --> 00:14:06.460 you can still use them." 00:14:06.460 --> 00:14:08.800 And then, a few years later they realized 00:14:08.800 --> 00:14:11.240 it's really hard to keep both alive, 00:14:11.240 --> 00:14:13.760 and they got rid of the board files. 00:14:13.760 --> 00:14:16.360 And that was really painful to us 00:14:16.360 --> 00:14:18.820 because we had to migrate 00:14:18.820 --> 00:14:20.820 So you can see, 00:14:20.820 --> 00:14:23.500 here, a kernel version, 00:14:23.500 --> 00:14:25.500 and so, from that kernel on, 00:14:25.500 --> 00:14:27.500 you needed to use the new way. 00:14:29.060 --> 00:14:33.240 And one of the reasons it was painful 00:14:33.240 --> 00:14:35.780 specially on the QNAP devices 00:14:35.780 --> 00:14:38.400 is because with 00:14:38.400 --> 00:14:40.400 they actually have two different CPUs 00:14:40.400 --> 00:14:42.400 so there are different barriers 00:14:42.400 --> 00:14:44.400 and whilst the board files, 00:14:44.400 --> 00:14:46.400 the same board file worked 00:14:46.400 --> 00:14:48.400 regardless of the CPU, 00:14:48.400 --> 00:14:51.240 because of the way the device tree worked 00:14:51.240 --> 00:14:53.240 it actually needed two different device trees 00:14:53.240 --> 00:14:55.240 depending on the CPU 00:14:55.600 --> 00:14:59.320 so now we basically, you know, something that just worked, 00:14:59.320 --> 00:15:01.320 you know, it used to work fine, 00:15:01.320 --> 00:15:03.320 you just had one kernel 00:15:03.320 --> 00:15:05.740 with the machine ID 00:15:05.740 --> 00:15:06.920 at least would work, 00:15:06.920 --> 00:15:09.620 and somehow with the device tree 00:15:09.620 --> 00:15:11.620 we needed to figure out which one 00:15:11.620 --> 00:15:13.620 we need, and so 00:15:13.620 --> 00:15:16.960 [?] fortunately did all of that work. 00:15:16.960 --> 00:15:18.960 So that's actually a script that runs 00:15:18.960 --> 00:15:20.960 to figure out which device tree 00:15:20.960 --> 00:15:22.960 that particular device needs. 00:15:26.660 --> 00:15:29.160 So now, that's actually 00:15:29.160 --> 00:15:31.160 the reason I want to show this is 00:15:31.160 --> 00:15:33.160 how simpler things are these days, so 00:15:33.160 --> 00:15:35.160 this is an example from 00:15:35.160 --> 00:15:38.600 [?] platform, which uses distro-support, 00:15:38.600 --> 00:15:40.960 and the only thing you really need is 00:15:40.960 --> 00:15:42.960 a machine entry with the name, 00:15:42.960 --> 00:15:44.960 and then 00:15:44.960 --> 00:15:46.960 like the kernel-flavor, 00:15:46.960 --> 00:15:48.960 but that's the same for... 00:15:48.960 --> 00:15:50.960 you know, there is only one kernel flavor. 00:15:52.740 --> 00:15:55.380 And then, the device tree ID 00:15:56.480 --> 00:15:58.360 and, again, all of that stuff is generic, 00:15:58.360 --> 00:16:00.760 so it just uses the generic bootscript, 00:16:02.180 --> 00:16:03.780 and the generic boot path, 00:16:03.780 --> 00:16:05.780 so basically 00:16:05.780 --> 00:16:07.780 all it pretty much needs for 00:16:07.780 --> 00:16:09.780 a new device is, like, 00:16:09.780 --> 00:16:11.780 you know, 00:16:11.780 --> 00:16:13.780 these two entries, 00:16:13.780 --> 00:16:15.780 it's really really simple. 00:16:18.780 --> 00:16:21.260 So here, I just wanted to 00:16:21.260 --> 00:16:23.260 tell about the different ARM ports and... 00:16:24.200 --> 00:16:26.940 So, for me it was really hard to structure this, because 00:16:26.940 --> 00:16:29.460 those changes in the kernel 00:16:29.460 --> 00:16:31.460 and U-boot 00:16:31.460 --> 00:16:34.640 you know, happen independent of our ARM ports, 00:16:36.100 --> 00:16:37.720 But at the same time, because 00:16:37.720 --> 00:16:40.340 because the armhf world is much newer, 00:16:40.340 --> 00:16:42.340 it works in a different way. 00:16:42.340 --> 00:16:45.200 So, basically, the armel 00:16:45.200 --> 00:16:49.480 we still have different flavors 00:16:49.480 --> 00:16:54.000 but we have already combined the orion and the kirkwood 00:16:54.000 --> 00:16:56.000 into one marvell flavor, 00:16:56.000 --> 00:16:59.060 and we have the versatile one. 00:17:00.860 --> 00:17:03.760 So one of the problems we have in armel is that 00:17:03.760 --> 00:17:05.760 a lot of those NAS devices 00:17:05.760 --> 00:17:07.760 boot from flash 00:17:07.760 --> 00:17:10.180 and they only have, some of them, 00:17:10.180 --> 00:17:12.180 3MB for the kernel, 00:17:12.180 --> 00:17:15.119 which used to be a lot of space 00:17:15.119 --> 00:17:16.660 but nowadays it's not. 00:17:16.720 --> 00:17:19.380 So that really puts a lot of restrictions 00:17:19.380 --> 00:17:21.380 so basically we disable some stuff 00:17:21.380 --> 00:17:23.380 from armel 00:17:23.380 --> 00:17:27.180 but I think that armel is really really widely used 00:17:27.180 --> 00:17:29.180 because of those NAS devices, 00:17:29.180 --> 00:17:31.180 but I think they are slowly getting old, 00:17:31.180 --> 00:17:33.680 but there are still a lot of people that use them. 00:17:33.680 --> 00:17:37.220 Like I said, it requires the U-boot image 00:17:37.700 --> 00:17:40.380 Originally, we used board files 00:17:40.380 --> 00:17:43.360 and device tree, most of them 00:17:43.360 --> 00:17:45.940 have switched over to device tree 00:17:45.940 --> 00:17:48.580 even if some of them still use board files 00:17:48.580 --> 00:17:51.540 and adding a new device requires 00:17:51.540 --> 00:17:54.200 a number of changes in the installer. 00:17:54.200 --> 00:17:57.100 So basically, you needed to map 00:17:57.100 --> 00:17:59.100 the device to 00:17:59.100 --> 00:18:01.100 the complete image 00:18:01.100 --> 00:18:04.200 and there are just there a couple of 00:18:04.200 --> 00:18:06.260 things, so basically, any one device 00:18:06.280 --> 00:18:08.200 you have to change like five different 00:18:08.200 --> 00:18:10.200 places in the installer. 00:18:10.200 --> 00:18:12.200 And it was quite confusing for people who wanted 00:18:12.200 --> 00:18:14.200 to add new devices 00:18:14.200 --> 00:18:17.080 Because it isn't really documented very well 00:18:18.480 --> 00:18:21.400 So some examples are a list of three people 00:18:21.400 --> 00:18:23.400 who are involved in that port 00:18:23.400 --> 00:18:25.400 So, Roger is someone 00:18:25.400 --> 00:18:27.400 who is quite new, and who really got 00:18:27.400 --> 00:18:29.920 involved into porting those old devices. 00:18:31.440 --> 00:18:34.560 And so, armhf is much nicer, 00:18:34.560 --> 00:18:36.560 so the majority of 00:18:36.560 --> 00:18:39.140 devices support distro-support. 00:18:40.440 --> 00:18:42.700 And the other thing we do 00:18:44.700 --> 00:18:47.040 is, for some of the devices 00:18:47.040 --> 00:18:49.040 we provide SD card images, 00:18:49.040 --> 00:18:51.040 which contain 00:18:51.040 --> 00:18:55.160 U-boot and the Debian installer 00:18:55.160 --> 00:18:57.160 So basically Vagrant 00:18:57.160 --> 00:18:59.960 maintains U-boot in Debian, and 00:18:59.960 --> 00:19:01.960 a lot of those devices are supported 00:19:01.960 --> 00:19:03.960 in U-boot in Debian. 00:19:03.960 --> 00:19:05.960 So we just 00:19:05.960 --> 00:19:07.960 provide an SD image, so you can just 00:19:07.960 --> 00:19:10.480 store it in the SD card, you put it in 00:19:10.480 --> 00:19:12.940 and, because of the distro-support, 00:19:12.940 --> 00:19:14.940 it just loads debian-installer, 00:19:14.940 --> 00:19:17.840 you do the installation, reboot, 00:19:17.840 --> 00:19:19.840 and things just work. 00:19:19.840 --> 00:19:21.840 So I think it really has gone 00:19:21.840 --> 00:19:25.200 ...Come a long way. 00:19:27.200 --> 00:19:29.820 So nowadays, 00:19:29.820 --> 00:19:31.820 adding a new device 00:19:31.820 --> 00:19:34.140 requires much fewer changes 00:19:34.140 --> 00:19:36.140 than it used to be. 00:19:36.140 --> 00:19:40.980 Because as everything uses the same, like, one kernel flavor, 00:19:40.980 --> 00:19:43.900 you don't need to patch all those different places anymore, 00:19:45.020 --> 00:19:47.740 and because of distro-support, it just works. 00:19:47.740 --> 00:19:52.280 You can pretty much use the generic bootscript. 00:19:54.140 --> 00:19:56.140 So, arm64. 00:19:56.140 --> 00:19:58.300 So, the problem until recently 00:19:58.300 --> 00:20:00.300 is that there simply wasn't any hardware 00:20:00.300 --> 00:20:02.300 that people could buy. 00:20:02.300 --> 00:20:04.300 And that's changing rapidly now 00:20:05.640 --> 00:20:07.540 [?] 00:20:07.540 --> 00:20:10.280 We have for example the Raspberry Pi 3 00:20:10.280 --> 00:20:13.960 which uses a 64 bit CPU 00:20:13.960 --> 00:20:16.620 but the software it ships is only 32 bits, 00:20:16.620 --> 00:20:18.620 but most of the work 00:20:18.620 --> 00:20:20.620 is now 00:20:20.620 --> 00:20:23.680 upstreamed to run 64 bit on it 00:20:25.000 --> 00:20:27.600 and there are a lot of 00:20:28.120 --> 00:20:31.500 devices which sort of work but not quite 00:20:31.960 --> 00:20:35.660 but anyway, so the idea for arm64 00:20:35.660 --> 00:20:37.660 is that a lot of the 00:20:37.660 --> 00:20:39.660 new hardware 00:20:39.660 --> 00:20:41.660 specially on the server side 00:20:41.660 --> 00:20:43.660 will use UEFI, 00:20:43.660 --> 00:20:45.660 and so you basically just 00:20:46.380 --> 00:20:48.100 it just works like a PC. 00:20:48.100 --> 00:20:50.100 So you have Grub, 00:20:50.100 --> 00:20:53.020 you can run debian-installer from Grub 00:20:53.020 --> 00:20:54.900 and you get Grub afterwards. 00:20:54.920 --> 00:20:56.480 And just boots like a PC, 00:20:56.480 --> 00:20:59.860 and Steve has done a lot of work in that area, 00:20:59.860 --> 00:21:01.860 And in theory, 00:21:01.860 --> 00:21:03.860 it should just work out of the box. 00:21:03.860 --> 00:21:06.220 So, if it uses 00:21:06.220 --> 00:21:08.220 UEFI, we don't need to add anything. 00:21:08.220 --> 00:21:10.220 It just works. 00:21:10.220 --> 00:21:12.220 There's nothing to do. 00:21:13.400 --> 00:21:15.300 At least, that's the theory. 00:21:15.300 --> 00:21:17.300 So, what I found is 00:21:17.300 --> 00:21:19.300 ...I made a disclaimer, so 00:21:19.300 --> 00:21:21.300 ...Assuming the kernel 00:21:21.300 --> 00:21:23.300 you know, kernel support and stuff... 00:21:23.300 --> 00:21:25.300 ...To be honest, 00:21:25.300 --> 00:21:28.160 right now, that's a big assumption. 00:21:28.160 --> 00:21:30.160 So I've been playing with a few 00:21:30.160 --> 00:21:33.200 64 bit ARM boards 00:21:33.200 --> 00:21:36.580 and basically, what I found is 00:21:36.580 --> 00:21:39.420 there is some support upstream, 00:21:39.420 --> 00:21:41.420 so I can boot a kernel, 00:21:41.420 --> 00:21:43.700 but, oh! There is no USB support! 00:21:43.700 --> 00:21:45.280 there is no Wifi support! 00:21:45.280 --> 00:21:48.060 So I cannot actually do anything with it. 00:21:48.060 --> 00:21:51.580 But I can get to something that 00:21:51.580 --> 00:21:54.980 because arm64 is still farily new. 00:21:54.980 --> 00:21:57.640 And there is a lot of work going on upstream 00:21:57.640 --> 00:22:00.000 to support the various platforms. 00:22:00.000 --> 00:22:03.300 So, I think over time that's really going to be much better. 00:22:05.300 --> 00:22:09.440 Even though that UEFI idea is there 00:22:09.440 --> 00:22:11.200 in reality, 00:22:11.200 --> 00:22:13.200 we are going to see different solutions 00:22:13.200 --> 00:22:15.200 for arm64. 00:22:15.200 --> 00:22:18.240 So we are going to see UEFI, in particular on servers, 00:22:18.240 --> 00:22:20.240 but we will also see U-boot. 00:22:20.240 --> 00:22:22.700 So a lot of those bare boards 00:22:22.700 --> 00:22:24.700 they have U-boot. 00:22:24.700 --> 00:22:26.700 And, so, right now 00:22:26.700 --> 00:22:28.700 we can use the distro support 00:22:28.700 --> 00:22:31.980 and I think that it works pretty well. 00:22:31.980 --> 00:22:34.320 But one thing that SuSE has done 00:22:34.320 --> 00:22:36.320 so, they just had the same issue, 00:22:36.320 --> 00:22:38.320 they want to support all those devices 00:22:38.320 --> 00:22:41.240 but they just want to use the same mechanism everywhere, 00:22:41.240 --> 00:22:43.420 so they have actually implemented 00:22:43.420 --> 00:22:46.020 UEFI on top of U-boot, 00:22:46.020 --> 00:22:49.240 so you can basically use U-boot to load Grub 00:22:49.240 --> 00:22:51.720 and then you have Grub 00:22:51.720 --> 00:22:54.320 so I think that's something we need to figure out; 00:22:54.320 --> 00:22:56.840 do we want to stay with distro-support? 00:22:56.840 --> 00:22:58.840 do we want to use 00:22:58.840 --> 00:23:01.140 UEFI on top of U-boot? 00:23:01.140 --> 00:23:03.140 is that something we want to 00:23:03.140 --> 00:23:05.140 give users the option? 00:23:05.140 --> 00:23:08.020 And then, Fastboot 00:23:08.020 --> 00:23:10.140 is something used 00:23:10.140 --> 00:23:12.140 in the Android world 00:23:12.140 --> 00:23:14.760 and a lot of those, like, I see a lot of 00:23:14.760 --> 00:23:17.800 both bare boards, but also 00:23:17.800 --> 00:23:19.940 game consoles and stuff, which 00:23:19.940 --> 00:23:21.940 which are sort of Android-oriented, 00:23:21.940 --> 00:23:23.940 but which can also run normal Linux, 00:23:23.940 --> 00:23:26.840 and they will use like Fastboot or something. 00:23:26.840 --> 00:23:30.120 And there are tons of other bootloaders out there 00:23:30.120 --> 00:23:32.540 But I would definitively say, like, the good ones 00:23:32.540 --> 00:23:34.540 are UEFI and U-boot 00:23:36.540 --> 00:23:40.320 So, I gave a similar talk a few weeks ago 00:23:40.320 --> 00:23:43.060 and turns out, a lot of non-free 00:23:43.060 --> 00:23:45.060 firmware, like, "can I 00:23:45.060 --> 00:23:46.920 run that stuff, you know, 00:23:46.920 --> 00:23:48.920 purely with free software?" 00:23:48.920 --> 00:23:51.260 ...And... 00:23:51.260 --> 00:23:52.980 So, the thing with ARM is that 00:23:52.980 --> 00:23:54.980 there are a lot of different platforms 00:23:54.980 --> 00:23:56.980 I'm not sure about all of them, 00:23:56.980 --> 00:23:59.460 but some of the platforms 00:23:59.460 --> 00:24:01.960 I looked at, yes, you 00:24:01.960 --> 00:24:05.320 do need some... There is always something propietary. 00:24:06.460 --> 00:24:08.420 So in a lot of cases 00:24:08.420 --> 00:24:10.420 I see where you have 00:24:10.420 --> 00:24:13.580 you use the proprietary first-stage boot loader, 00:24:13.580 --> 00:24:16.160 so the Raspberry Pi is an example, 00:24:16.160 --> 00:24:18.540 so, I don't actually have a Raspberry Pi, but 00:24:18.540 --> 00:24:20.540 the way I understand it is 00:24:20.540 --> 00:24:23.060 you basically put some boot files 00:24:23.060 --> 00:24:25.060 in an SD card, 00:24:25.060 --> 00:24:27.060 and they are proprietary, and 00:24:27.060 --> 00:24:29.060 then they load the kernel. 00:24:29.060 --> 00:24:31.500 Or in case of [?] 00:24:31.500 --> 00:24:33.500 supported in Debian, 00:24:33.500 --> 00:24:35.500 the first stage boot loader would basically 00:24:35.500 --> 00:24:37.820 be used to run U-boot, 00:24:37.820 --> 00:24:40.140 and then we could use U-boot, and 00:24:40.140 --> 00:24:43.880 the U-boot support all of it is free software, 00:24:43.880 --> 00:24:46.440 but the first stage boot loader isn't. 00:24:46.440 --> 00:24:49.820 I have had, there are some people 00:24:49.820 --> 00:24:51.820 working on a free replacement for 00:24:51.820 --> 00:24:53.820 the Raspberry Pi, though. 00:24:53.820 --> 00:24:55.820 With nVidia Tegra, 00:24:55.820 --> 00:24:57.640 which is 00:24:57.640 --> 00:24:59.640 something I'm working on at the moment 00:24:59.640 --> 00:25:03.040 you also have a tiny first stage boot loader, 00:25:03.040 --> 00:25:05.940 but then again, you have U-boot, which is free, 00:25:05.940 --> 00:25:08.980 and in that case, you also have some firmware 00:25:08.980 --> 00:25:10.980 images for the GPU 00:25:10.980 --> 00:25:13.320 and for other stuff. 00:25:13.320 --> 00:25:15.980 For the Dragon board, 00:25:15.980 --> 00:25:18.980 The Dragon board sounded really interesting 00:25:18.980 --> 00:25:20.820 because it actually has a 00:25:20.820 --> 00:25:22.820 a graphics chip 00:25:22.820 --> 00:25:25.120 which can be used with free software, 00:25:25.120 --> 00:25:27.920 so that sounded pretty cool, 00:25:27.920 --> 00:25:30.340 but again, it has a 00:25:30.340 --> 00:25:32.460 proprietary first 00:25:32.460 --> 00:25:34.460 stage boot loader, 00:25:34.460 --> 00:25:36.460 and then there is a second stage boot loader 00:25:36.460 --> 00:25:38.460 which is actually open source 00:25:38.460 --> 00:25:41.520 and then there's actually a U-boot of that, 00:25:41.520 --> 00:25:44.600 and then you have some 00:25:44.600 --> 00:25:46.600 binary blobs which 00:25:46.600 --> 00:25:49.900 also need to be installed in flash to work properly 00:25:49.900 --> 00:25:51.900 On the Marvell side, I'm 00:25:51.900 --> 00:25:53.900 not really aware of anything. 00:25:53.900 --> 00:25:55.900 I have never needed to flash anything 00:25:55.900 --> 00:25:57.900 proprietary, but 00:25:57.900 --> 00:25:59.900 I'm not sure how U-boot gets started 00:25:59.900 --> 00:26:01.900 on Marvell, so maybe there is something. 00:26:04.380 --> 00:26:08.180 So the future is all... So NAS devices are 00:26:08.180 --> 00:26:09.800 like I said, that's something that's 00:26:09.800 --> 00:26:11.800 really been popular in Debian. 00:26:11.800 --> 00:26:15.480 Specially on the QNAP devices, 00:26:15.480 --> 00:26:17.480 but the problem is, so, QNAP... 00:26:17.480 --> 00:26:19.480 so the devices we currently support 00:26:19.480 --> 00:26:21.480 are pretty old 00:26:21.480 --> 00:26:23.480 nowadays, 00:26:23.480 --> 00:26:25.480 and they have some newer devices, 00:26:25.480 --> 00:26:27.740 but they are not properly supported 00:26:27.740 --> 00:26:29.740 in the upstream kernel. 00:26:29.740 --> 00:26:31.740 So, I have no plans 00:26:31.740 --> 00:26:33.740 to support Debian on those. 00:26:33.740 --> 00:26:36.920 I recently did some work on 00:26:36.920 --> 00:26:38.920 Seagate NAS devices 00:26:38.920 --> 00:26:42.500 which are actually pretty interesting 00:26:42.500 --> 00:26:44.500 but again, they will go out of date 00:26:44.500 --> 00:26:46.500 already, 00:26:46.500 --> 00:26:48.500 and then there's the whole 64 bit ARM 00:26:48.500 --> 00:26:50.500 so I think people are really waiting 00:26:50.500 --> 00:26:52.500 for arm64 servers 00:26:52.500 --> 00:26:54.720 I think there's going to be a whole lot of 00:26:54.720 --> 00:26:56.720 work on that area. 00:26:56.720 --> 00:26:59.460 And then, there are all of those development boards 00:26:59.460 --> 00:27:01.460 Raspberry Pi, 00:27:01.460 --> 00:27:03.460 Pine64, 00:27:03.460 --> 00:27:06.200 Allwinder, 00:27:06.200 --> 00:27:08.900 Basically, all of them 00:27:08.900 --> 00:27:10.900 sound exciting, but if you 00:27:10.900 --> 00:27:12.700 look at them, all of them 00:27:12.700 --> 00:27:14.700 have some upstream issues, so it's... 00:27:14.700 --> 00:27:18.340 It is really quite frustrating at the moment. 00:27:18.340 --> 00:27:20.340 But I think things are really 00:27:20.340 --> 00:27:22.800 moving [?] 00:27:22.800 --> 00:27:25.880 And then there's this 96Board initiative, 00:27:26.060 --> 00:27:28.540 which is actually done by Linaro, 00:27:28.540 --> 00:27:30.700 and, so, Linaro supports 00:27:30.700 --> 00:27:32.880 Linux on ARM, so you'd think, "wow, 00:27:32.880 --> 00:27:34.880 there are some really nice boards coming out!" 00:27:34.880 --> 00:27:37.340 and they differentiated 00:27:37.340 --> 00:27:39.940 between the consumer edition and the enterprise edition 00:27:39.940 --> 00:27:42.880 beside, I bought some consumer-edition boards, 00:27:42.880 --> 00:27:45.540 and it's really horrible. 00:27:45.540 --> 00:27:48.220 So first of all, I had to spend like half a day 00:27:48.220 --> 00:27:50.220 just putting the components 00:27:50.660 --> 00:27:53.100 because it uses, like, a nonstandard power supply, 00:27:53.100 --> 00:27:55.100 a nonstandard serial console, 00:27:55.100 --> 00:27:57.820 so finally I found 00:27:57.820 --> 00:28:00.280 all the pieces I needed, and then 00:28:00.280 --> 00:28:02.820 I was expecting, well, it's from Linaro! 00:28:02.820 --> 00:28:05.140 Surely everything just works upstream! 00:28:05.140 --> 00:28:07.600 But it doesn't. It's like 00:28:07.600 --> 00:28:09.600 yes, I can boot the Linux kernel, 00:28:09.600 --> 00:28:11.600 but there's no USB, there's no 00:28:11.600 --> 00:28:13.600 Wifi, no nothing... 00:28:15.080 --> 00:28:17.080 So, yes, that's a little bit frustrating. 00:28:17.080 --> 00:28:19.140 On the enterprise edition, 00:28:19.140 --> 00:28:21.140 I think that looks more interesting. 00:28:21.140 --> 00:28:23.140 You know, that's more standardized. 00:28:23.140 --> 00:28:26.620 But again, there have been some delays. 00:28:28.620 --> 00:28:32.620 [audience; unintellegible] 00:28:32.620 --> 00:28:34.620 Yes, OK. 00:28:34.620 --> 00:28:36.620 So that would be interesting to see. 00:28:36.620 --> 00:28:39.420 So, the questions that I actually have nowadays 00:28:39.420 --> 00:28:41.420 is, so... 00:28:41.420 --> 00:28:43.420 Because of those changes, 00:28:43.420 --> 00:28:45.420 because of having, you know, 00:28:45.420 --> 00:28:47.420 a mode of U-boot, most of those 00:28:47.420 --> 00:28:49.420 new devices having a U-boot 00:28:49.420 --> 00:28:50.880 with distro-support, 00:28:50.880 --> 00:28:53.040 having a kernel which, you know, 00:28:53.040 --> 00:28:55.040 one kernel image that works on all of those 00:28:55.040 --> 00:28:57.040 devices which are supported, 00:28:57.040 --> 00:28:59.560 it's really easy to support 00:28:59.560 --> 00:29:01.560 a new device? 00:29:01.560 --> 00:29:04.100 As long as it's supported by the kernel. 00:29:04.100 --> 00:29:06.360 But, at the same time, I think it's a big 00:29:06.360 --> 00:29:07.740 challenge for Debian. 00:29:07.740 --> 00:29:10.280 Because right now, if you look at armhf, 00:29:10.280 --> 00:29:12.220 we basically say, well, 00:29:12.220 --> 00:29:14.220 hint the installer, 00:29:14.220 --> 00:29:16.220 and if there's a device tree, 00:29:16.220 --> 00:29:18.220 it's probably going to work. 00:29:18.220 --> 00:29:21.180 But, what does that mean, right? 00:29:23.180 --> 00:29:25.180 And... 00:29:25.180 --> 00:29:28.140 which really work, which means, 00:29:28.140 --> 00:29:29.880 so, we have Vagrant 00:29:29.880 --> 00:29:31.880 having U-boot support 00:29:31.880 --> 00:29:33.880 in Debian, we have 00:29:33.880 --> 00:29:36.240 people testing debian-installer, 00:29:36.240 --> 00:29:38.240 testing the Debian kernel, so we have 00:29:38.240 --> 00:29:40.820 devices which really work, well supported, 00:29:40.820 --> 00:29:43.280 and then we have some devices 00:29:43.280 --> 00:29:45.580 on the other hand where, well, yes, 00:29:45.580 --> 00:29:47.580 there is a device tree, but no one 00:29:47.580 --> 00:29:49.580 has ever tried it. And 00:29:49.580 --> 00:29:51.580 at the moment, we have no way 00:29:51.580 --> 00:29:54.140 for users to differentiate 00:29:54.140 --> 00:29:56.540 those use case... Those 00:29:56.540 --> 00:29:58.540 support levels. 00:29:58.540 --> 00:30:00.540 So I'm wondering if we need 00:30:00.540 --> 00:30:02.540 like a table, 00:30:02.540 --> 00:30:04.540 somewhere where maybe 00:30:04.540 --> 00:30:06.540 some support levels, like green, yellow... 00:30:06.540 --> 00:30:08.120 red? 00:30:08.120 --> 00:30:10.120 Where green is, "yes, we have Debian 00:30:10.120 --> 00:30:12.120 people who have 00:30:12.120 --> 00:30:14.120 testing that stuff", 00:30:14.120 --> 00:30:16.120 yellow would be, "well, we have heard some report 00:30:16.120 --> 00:30:18.120 that it might work", and 00:30:18.120 --> 00:30:20.120 green is, you know, doesn't work, 00:30:20.120 --> 00:30:22.120 or we haven't tried that it works. 00:30:22.120 --> 00:30:24.120 Maybe we need something like that. 00:30:24.120 --> 00:30:26.360 But right now, 00:30:26.360 --> 00:30:28.360 I see from users 00:30:30.360 --> 00:30:32.360 "I want to run Debian on my ARM device", and 00:30:32.360 --> 00:30:35.380 they don't know if it's going to work. 00:30:35.380 --> 00:30:37.380 Yes, then... 00:30:37.380 --> 00:30:43.400 [audience; unintellegible] 00:30:43.400 --> 00:30:45.400 Yes, so Ben is saying we also need 00:30:45.400 --> 00:30:47.400 to track what the earliest and the latest 00:30:47.400 --> 00:30:49.620 kernel versions that there have been tested. 00:30:49.620 --> 00:30:51.800 So I think we really need to 00:30:51.800 --> 00:30:53.800 come up with some criteria 00:30:53.800 --> 00:30:58.920 to have, you know, define those kernel support levels that indicate that 00:30:58.920 --> 00:31:01.920 And yes, the other question is related 00:31:01.920 --> 00:31:03.260 to, with all those boards, 00:31:03.260 --> 00:31:05.260 how do we actually test them? 00:31:05.260 --> 00:31:07.000 So, I keep -- 00:31:07.000 --> 00:31:10.100 it's really... remember [?] 00:31:10.100 --> 00:31:12.100 which is great, but also acknowledge 00:31:12.100 --> 00:31:14.100 those boards, they are so cheap! 00:31:14.100 --> 00:31:16.100 so it's like, "oh, there's a new board! 00:31:16.100 --> 00:31:18.100 It's £30! I'll just get it!" 00:31:18.100 --> 00:31:21.020 And then we have, like, those piles of boards 00:31:21.020 --> 00:31:23.020 and realize, well, I don't have time 00:31:23.020 --> 00:31:25.020 for testing all of that stuff! 00:31:25.020 --> 00:31:27.200 I think that's going to be a real challenge. 00:31:27.200 --> 00:31:29.320 hundreds -- I don't know, 00:31:29.320 --> 00:31:31.320 it's really hundreds of boards coming out. 00:31:31.320 --> 00:31:33.900 How do we support all of that? 00:31:35.460 --> 00:31:38.420 So, I think that's the question I wanted to raise, 00:31:38.420 --> 00:31:41.160 and maybe something we can talk about in the BoF 00:31:41.160 --> 00:31:43.380 But yes, I'm obviously 00:31:43.380 --> 00:31:45.380 open for questions now. 00:31:55.520 --> 00:31:57.520 [James / purpleidea:] Hello. 00:31:57.520 --> 00:32:00.200 So, don't quote me exactly, 00:32:00.200 --> 00:32:02.200 so, I believe 00:32:02.200 --> 00:32:04.200 RedHat has this problem as well, obviously, 00:32:04.200 --> 00:32:06.200 I mean, they are obviously more interested in the 00:32:06.200 --> 00:32:08.580 ARM64-only server stuff, 00:32:08.580 --> 00:32:10.580 but I believe the way they are going about it 00:32:10.580 --> 00:32:12.880 maybe it's something could collaborate on 00:32:12.880 --> 00:32:15.080 is, they are trying to make sure and push 00:32:15.080 --> 00:32:17.080 all the vendors to be standardized 00:32:17.080 --> 00:32:19.260 because, as you pointed out, 00:32:19.260 --> 00:32:21.540 it's just not, it's crazy 00:32:21.540 --> 00:32:24.540 with all the different device tree differences and so on, 00:32:24.540 --> 00:32:26.540 so I believe their strategy is to 00:32:26.540 --> 00:32:28.840 work with the vendors, and 00:32:28.840 --> 00:32:30.840 require everything to be upstreamed, and 00:32:30.840 --> 00:32:32.840 no device tree 00:32:32.840 --> 00:32:34.840 specifically, to push everything to just boot 00:32:34.840 --> 00:32:36.840 with one kernel, and so on. 00:32:36.840 --> 00:32:38.840 So maybe that could be 00:32:38.840 --> 00:32:40.840 sacrifice a few of the 00:32:40.840 --> 00:32:42.840 shitty boards, but work with the vendors 00:32:42.840 --> 00:32:45.820 that make the ones that are upstreamed. 00:32:45.820 --> 00:32:47.820 [Martin:] Yes, so I may be mistaken, but 00:32:47.820 --> 00:32:49.820 as far as I know, RedHat 00:32:49.820 --> 00:32:51.620 basically says, "we only support 00:32:51.620 --> 00:32:53.620 UEFI and ACPI" 00:32:53.620 --> 00:32:55.620 and that's fair enough, 00:32:55.620 --> 00:32:57.620 and I think that works for them, because 00:32:57.620 --> 00:32:59.900 it's just the server world they care about, 00:32:59.900 --> 00:33:01.900 but I think in the case of Debian 00:33:01.900 --> 00:33:03.900 there are so many boards out there which 00:33:03.900 --> 00:33:05.900 don't need those specs, 00:33:05.900 --> 00:33:08.600 and we sort of live, like, in the "real world" 00:33:08.600 --> 00:33:10.980 so I don't think we can 00:33:10.980 --> 00:33:12.980 Well -- I know it's different. I mean, 00:33:12.980 --> 00:33:14.980 if RedHat wants to target 00:33:14.980 --> 00:33:16.980 the server people, like, the people 00:33:16.980 --> 00:33:18.980 which give money 00:33:18.980 --> 00:33:20.980 that's fair enough, that makes sense for them 00:33:20.980 --> 00:33:22.980 but Debian, we run everywhere 00:33:22.980 --> 00:33:24.980 so I think we need to support 00:33:24.980 --> 00:33:26.980 all those weird 00:33:26.980 --> 00:33:28.980 cases as well. 00:33:28.980 --> 00:33:30.980 And maybe if it gets too weird, 00:33:30.980 --> 00:33:32.980 I mean, 00:33:32.980 --> 00:33:35.360 I put in some work in the Dragonboard, 00:33:35.360 --> 00:33:37.360 and then I realized, 00:33:37.360 --> 00:33:39.360 am I actually spending the time because 00:33:39.360 --> 00:33:41.360 no one, like, I have heard 00:33:41.360 --> 00:33:43.360 from no one that they have 00:33:43.360 --> 00:33:45.360 that board, I mean, like [?] 00:33:45.360 --> 00:33:47.360 for the Raspberry Pi, but I have heard 00:33:47.360 --> 00:33:49.360 like, pretty much no one has the 00:33:49.360 --> 00:33:51.360 Dragonboard, so maybe, 00:33:51.360 --> 00:33:53.920 ...it's not worth my while, 00:33:53.920 --> 00:33:55.920 but if there's a board 00:33:55.920 --> 00:33:57.920 that people want to use it, 00:33:57.920 --> 00:34:00.340 I think we should support it in Debian. 00:34:00.340 --> 00:34:02.340 And we do have the infrastructure 00:34:02.340 --> 00:34:04.340 so we, you know, it doesn't have to be 00:34:04.340 --> 00:34:06.340 UEFI and ACPI, 00:34:06.340 --> 00:34:08.340 we can support other devices, because 00:34:08.340 --> 00:34:10.340 we have done it before. 00:34:10.340 --> 00:34:12.340 But I definitively agree with 00:34:12.340 --> 00:34:14.960 the point about getting more standardization 00:34:14.960 --> 00:34:16.960 and that stuff, so 00:34:16.960 --> 00:34:18.960 I agree, yes. 00:34:20.360 --> 00:34:22.920 And the whole distro-support 00:34:22.920 --> 00:34:25.600 in U-boot, that has really made things easier for us. 00:34:33.219 --> 00:34:35.880 [Phil:] I may begin to say some of the same things Steve has, anyway. 00:34:35.880 --> 00:34:38.500 Steve]: So, yes, on the 00:34:38.500 --> 00:34:41.219 ACPI versus DT thing, 00:34:41.219 --> 00:34:43.219 it's more a question 00:34:43.219 --> 00:34:45.980 of the quality of the implementation of the 00:34:45.980 --> 00:34:48.800 of the firmware, 00:34:48.800 --> 00:34:50.800 and the upstream support that is... 00:34:50.800 --> 00:34:52.800 DT isn't fundamentally 00:34:52.800 --> 00:34:55.260 worse for upstream support 00:34:55.260 --> 00:34:57.780 than ACPI is, 00:34:57.780 --> 00:35:00.980 RedHat are 00:35:00.980 --> 00:35:02.980 have some reasons 00:35:02.980 --> 00:35:04.980 [?] of sensibility, 00:35:04.980 --> 00:35:06.980 but then, it's not 00:35:06.980 --> 00:35:09.380 fundamentally, it doesn't fundamentally stop it 00:35:09.380 --> 00:35:11.380 people supporting it, specially 00:35:11.380 --> 00:35:13.380 a community distro like Debian. 00:35:13.380 --> 00:35:16.340 I was also going to ask Martin, 00:35:16.340 --> 00:35:18.340 have you talked to 00:35:18.340 --> 00:35:20.560 people like kernel CI 00:35:20.560 --> 00:35:24.660 about testing and coverage stuff? 00:35:24.660 --> 00:35:26.660 [Martin:] Yes, not really, but 00:35:26.660 --> 00:35:29.740 I think there are some things we should look into. 00:35:29.740 --> 00:35:31.740 [Steve:] Yes, because the whole -- 00:35:31.740 --> 00:35:33.740 Obviously, making sure the kernel boots 00:35:33.740 --> 00:35:35.740 on random hardware 00:35:35.740 --> 00:35:38.080 stuff, is exactly what that's doing 00:35:39.740 --> 00:35:42.360 and there's at least infrastructure there that might be 00:35:42.360 --> 00:35:44.740 nice to play with. 00:35:46.480 --> 00:35:48.480 [Martin:] Yes. I think that's a good idea. 00:35:50.480 --> 00:35:52.480 [sledge:] So, on the whole 96Boards thing, 00:35:52.480 --> 00:35:54.480 sorry! 00:35:54.480 --> 00:35:56.480 Most of the engineers involved 00:35:56.480 --> 00:35:58.480 are totally aware of 00:35:58.480 --> 00:36:00.480 how [?] it really is. 00:36:00.480 --> 00:36:02.480 We tried to tell management 00:36:02.480 --> 00:36:04.480 they would -- 00:36:04.480 --> 00:36:06.480 They don't want to listen. 00:36:06.480 --> 00:36:08.480 Umm.. So, 00:36:08.480 --> 00:36:10.480 there has been a huge amount of pushback 00:36:10.480 --> 00:36:13.000 saying, you know, "we're Linaro 00:36:13.000 --> 00:36:15.380 we should make sure this is all upstreamed". 00:36:17.380 --> 00:36:19.380 [Martin:] Well, I am aware 00:36:19.380 --> 00:36:21.380 it's just, Linaro 00:36:21.380 --> 00:36:23.380 has a really good brand, 00:36:23.380 --> 00:36:25.380 so people expect, you know, when I saw 00:36:25.380 --> 00:36:27.380 96Boards it's Linaro, 00:36:27.380 --> 00:36:29.800 obviously that stuff it's going to work! 00:36:29.800 --> 00:36:31.800 and that's why I was really disappointed. 00:36:31.800 --> 00:36:33.800 [Steve:] One positive thing there 00:36:33.800 --> 00:36:35.800 is that the first DE board 00:36:35.800 --> 00:36:38.300 the SoC does basically work upstream 00:36:38.300 --> 00:36:40.440 already with current upstream kernel 00:36:40.440 --> 00:36:42.440 it's not like there's some patches still 00:36:42.440 --> 00:36:44.440 to go in. Apart from the PCI, it should basically 00:36:44.440 --> 00:36:47.400 work... So, hopefully, 00:36:47.400 --> 00:36:49.820 hopefully, that's going to be a much 00:36:49.820 --> 00:36:51.820 less spectacular 00:36:51.820 --> 00:36:53.820 story than the 00:36:53.820 --> 00:36:55.820 consumer-edition boards have been. 00:36:55.820 --> 00:36:57.820 As they are unfortunate. 00:37:01.860 --> 00:37:03.860 [Sledge:] The first EE board 00:37:03.860 --> 00:37:05.860 the [?]board, is due to start shipping 00:37:05.860 --> 00:37:07.860 really soon now. 00:37:07.860 --> 00:37:09.860 There are examples already out there 00:37:09.860 --> 00:37:11.860 with engineers for validation. 00:37:11.860 --> 00:37:14.300 Literally, we are talking the next couple of weeks 00:37:14.300 --> 00:37:16.300 is what I have been told. 00:37:16.300 --> 00:37:18.700 That's the first 96Boards I would 00:37:18.700 --> 00:37:20.700 actually spend any time on at all personally, 00:37:20.700 --> 00:37:23.240 the CE boards are a joke. 00:37:29.020 --> 00:37:31.020 I forgot what else I was going to say. Oh! 00:37:31.020 --> 00:37:33.020 Yes! Then... 00:37:33.020 --> 00:37:35.380 I guess we will go through a lot of this again 00:37:35.380 --> 00:37:37.380 in the ARM BoF later on 00:37:37.380 --> 00:37:39.480 in terms of 00:37:39.480 --> 00:37:41.480 which things we support. 00:37:44.660 --> 00:37:46.660 We will carry on with the discussion. 00:37:54.720 --> 00:37:57.560 [Vagrant:] Um... Is this working? 00:37:57.560 --> 00:37:59.560 Yes, so... 00:37:59.560 --> 00:38:01.560 We have got all this great support for 00:38:01.560 --> 00:38:03.560 distro-boot command and U-boot, and 00:38:03.560 --> 00:38:05.560 now we are starting to get 00:38:05.560 --> 00:38:07.560 to UEFI emulation 00:38:07.560 --> 00:38:09.560 in U-boot, so even for boards 00:38:09.560 --> 00:38:11.560 that don't have UEFI emulation-- 00:38:11.560 --> 00:38:13.560 UEFI support, if they support 00:38:13.560 --> 00:38:15.560 U-boot, it might work 00:38:15.560 --> 00:38:17.560 although that means all the standarization 00:38:17.560 --> 00:38:19.560 we worked towards, we throw it away., 00:38:19.560 --> 00:38:21.560 Meh! 00:38:23.560 --> 00:38:26.300 [Martin:] Yes, I think that's something we need to figure out, 00:38:26.300 --> 00:38:29.240 which one do we want to standardize on, 00:38:29.240 --> 00:38:31.240 or is that something we want to 00:38:31.240 --> 00:38:33.240 leave up to the user. 00:38:33.240 --> 00:38:35.480 but yes, 00:38:35.480 --> 00:38:37.560 I mean, I think one 00:38:37.560 --> 00:38:39.560 I mean, I guess it was 00:38:39.560 --> 00:38:41.560 so confusing, because there are like 00:38:41.560 --> 00:38:43.560 all those different ways, but 00:38:44.920 --> 00:38:46.920 what I really wanted to show is that 00:38:46.920 --> 00:38:48.920 things are getting much more 00:38:48.920 --> 00:38:51.100 standardized and much better. 00:38:51.100 --> 00:38:53.560 So, it used to be really 00:38:53.560 --> 00:38:55.560 pretty horrible, and nowadays, 00:38:55.560 --> 00:38:57.560 you know, if a platform 00:38:57.560 --> 00:38:59.560 uses a modern 00:38:59.560 --> 00:39:01.560 U-boot, if it has 00:39:01.560 --> 00:39:03.560 upstream support, then it is 00:39:03.560 --> 00:39:05.560 actually pretty trivial to add 00:39:05.560 --> 00:39:07.560 Debian support, and 00:39:07.560 --> 00:39:09.560 I think that wasn't the case 00:39:09.560 --> 00:39:10.660 in the past. 00:39:10.660 --> 00:39:12.660 I think Ben had another one? 00:39:20.800 --> 00:39:23.580 [Ben:] So, I'm 00:39:26.540 --> 00:39:29.960 [laughs] 00:39:29.960 --> 00:39:33.280 I'm interested to know how much 00:39:33.280 --> 00:39:36.080 how much interest there is among the ARM porters 00:39:36.080 --> 00:39:38.500 in graphics support. 00:39:38.500 --> 00:39:40.380 GPU support, rather 00:39:40.380 --> 00:39:42.380 than settling for dumb framebuffers. 00:39:42.380 --> 00:39:44.380 How many... 00:39:44.380 --> 00:39:46.380 How many of these boards... 00:39:46.380 --> 00:39:48.380 Quite a lot of these boards do have HDMI 00:39:48.380 --> 00:39:50.380 and I don't know 00:39:50.380 --> 00:39:52.780 to what degree they are actually supported. 00:39:52.780 --> 00:39:56.380 Are any current projected work 00:39:56.380 --> 00:40:00.280 which definitively is using the 00:40:00.280 --> 00:40:04.700 GPU on ARM system, and 00:40:04.700 --> 00:40:07.320 what's in Debian, 00:40:07.320 --> 00:40:09.520 is the Debian base system 00:40:09.780 --> 00:40:12.480 does Debian... What's in Debian does not 00:40:12.480 --> 00:40:14.480 support GPU. 00:40:14.480 --> 00:40:17.980 [Martin:] So, I can't speak for Vagrant... 00:40:17.980 --> 00:40:19.980 I have personally done some work 00:40:19.980 --> 00:40:21.980 on the Tegra recently, 00:40:21.980 --> 00:40:23.980 and nVidia is actually 00:40:23.980 --> 00:40:27.120 working upstream on [?] 00:40:27.120 --> 00:40:29.640 so I'm really interested in it 00:40:29.640 --> 00:40:31.640 but I think that a lot of 00:40:31.640 --> 00:40:33.640 the board used, there's money 00:40:33.640 --> 00:40:37.160 GPUs I'm not sure would be 00:40:37.160 --> 00:40:40.380 ...you can get a [laughs] 00:40:40.380 --> 00:40:43.760 can we get a microphone for Steve? 00:40:51.780 --> 00:40:53.780 [Sledge:] So, on the Mali front, 00:40:53.780 --> 00:40:55.240 there has been a lot of haste where we 00:40:55.240 --> 00:40:57.240 have been scared of releasing any of this 00:40:57.240 --> 00:40:59.880 in any way, shape or form, 00:40:59.880 --> 00:41:01.880 without huge 00:41:01.880 --> 00:41:04.580 [?]-relays and all that kind of stuff. 00:41:04.580 --> 00:41:06.880 So it's not really distributable. 00:41:06.880 --> 00:41:08.880 Even, at all. 00:41:08.880 --> 00:41:12.300 We are a long way of it being releasable free, 00:41:12.300 --> 00:41:15.640 There are packages coming that we 00:41:15.640 --> 00:41:17.640 should be getting shippable in non-free 00:41:17.640 --> 00:41:19.640 at least if you want to get full acceleration 00:41:19.640 --> 00:41:21.640 on your Mali stuff. 00:41:23.640 --> 00:41:25.640 Hopefully, that will solve some of the problems 00:41:25.640 --> 00:41:27.640 There is a lot, there are a lot of people 00:41:27.640 --> 00:41:29.640 in [?] who are very very keen on 00:41:29.640 --> 00:41:32.180 supporting it properly, free and upstreamed. 00:41:32.180 --> 00:41:34.620 It's a long fight. 00:41:34.620 --> 00:41:35.940 It will take a while. 00:41:35.940 --> 00:41:39.040 I mean, most of the Mali driver developers 00:41:39.040 --> 00:41:41.040 themselves I have spoken to, would love to 00:41:41.040 --> 00:41:43.040 make it free. It just comes down 00:41:43.040 --> 00:41:45.040 to legal people 00:41:45.040 --> 00:41:47.040 being scared. 00:41:53.040 --> 00:41:55.040 [Tobi:] Are there some questions left? 00:41:58.780 --> 00:42:00.080 [Martin:] Well, thanks for coming! 00:42:00.080 --> 00:42:02.080 And there is going to be the ARM BoF 00:42:02.080 --> 00:42:04.080 later today, and 00:42:04.080 --> 00:42:06.080 Vagrant is also going to talk about his experience 00:42:06.080 --> 00:42:09.760 about running a build network 00:42:09.760 --> 00:42:11.760 on armhf boards.. 00:42:11.760 --> 00:42:13.160 Thanks! 00:42:18.060 --> 00:42:20.060 [audience clapping]