Get Help

Got a YouTube account?

New: enable viewer-created translations and captions on your YouTube channel!

English subtitles

← Debian_on_ARM_devices_2.webm

Get Embed Code
1 Language

Showing Revision 1 created 07/28/2016 by Gunnar Wolf.

  1. So, I think we are ready to start

  2. So, next talk is from Martin, about Debian on ARM devices.
  3. So, it's Debian on ARM devices, it's not about the Debian ARM port itself, or any of the various ARM ports
  4. I would say it's sort of a mix of different topics
  5. it's basically ---
  6. I mean, basically I often get
    it's basically ---
  7. I mean, basically I often get
  8. the question from users
  9. "Well, Debian works on this particular ARM device,
  10. I have a device which is like really really similar,
  11. so surely Debian should work on it, right?"
  12. And so far, the answer unfortunately was usually "no"
  13. and - and it's really frustrating for users
  14. because they don't see why.
  15. You know, the device is very much the same, so why doesn't it just work.
  16. And so, basically what I'm trying to do is
  17. to show like a little bit behind the scenes
  18. of how Debian on ARM works
  19. And there has been a whole lot of progres
  20. So I'm going to show how did it work,
  21. what are the improvements, and
  22. and how is it going to work in the future
  23. And it's all more from a develeoper perspective
  24. so, it's like, how do we support it in the Debian Installer
  25. its' like a mix of stuff, and I should say,
  26. I'm really looking at it from somebody who basically
  27. adds support for devices in the installer
  28. but I'm not like a kernel guy or anything, so
  29. there are a lot of people in this room who know a bit more about the technical details
  30. but I'm not going to really drill down really deep down anyway
  31. But if I'm incorrect, I'm sure that
  32. there are plenty of people that will correct me.
  33. So, where do you find ARM? So it's pretty much everywhere these days, I mean...
  34. Pretty much every phone has an ARM chip in it
  35. All those "Internet of Things" gadgets are ARM-based
  36. You have NAS devices, and that's really the area I used to focus on
  37. those small boxes where you basically add a hard drive
  38. and most people just use it for storage, but it's actually a
  39. full PC where you can install Debian on it
  40. so I always found that to be very interesting
  41. and nowadays you have a lot of development boards
  42. And I'm not sure whether "development boards" is the right word
  43. Because when I hear "development boards" I think of it as really expensive,
  44. Like 5K for boards or something
  45. But nowadays you have those, maybe, a better board would be like bareboards
  46. Like "Raspberry Pi", like basically it's just the board
  47. it does not come with a case, you can buy those as well
  48. and it's like 30 dollars or something, you can get
  49. And that gets pretty much where most of the
  50. excitement is going for Debian users at this moment
  51. And that can cause a lot of frustration
  52. And everybody says that ARM is going to be big on servers
  53. and I think that's something we ar going to see
  54. But right now, again, it's
  55. a little bit frustrating
  56. How does it work as a Deban Installer
  57. There are basically two
  58. ways of installing on those ARM Pi devices
  59. So the, like, historic, that we normally
  60. would be to install on, like, ascreen
  61. can be a serial console,
  62. and then you just download via the network
  63. and then you just download via the network
  64. from a CD image or wherever,
  65. But the other method, which we actually use for those
  66. net devices was a network console
  67. where you basically ssh into the installer
  68. and you perform the installation via ssh
  69. and that was really the only way, because those mass devices
  70. don't have any I/O, so I
  71. even in there, you can
  72. it's just a serial console, most of them
  73. That's something we didn't want to require from the user
  74. And the other thing that's coming through, I think that it's basically cool that was announce today,
  75. screen support, so basically
  76. so you can have multiple sessions with in vi,
  77. which can be useful if you have an open shell to debug
  78. And so, how -- And so, this is really looking back at
  79. like running Debian on NAS devices
  80. which is something that used to be really popular
  81. And the way it worked was basically
  82. that we provided an installer image
  83. which was sort of a firmware image
  84. as a lot of those NAS devices
  85. have like a firmware upgrade mechanism
  86. and so we would basically fake
  87. we would create a firmware image
  88. which the software would accept
  89. but instead of a firmware update
  90. it would actually contain the Debian installer
  91. so you would install that upgrade
  92. you would reboot, and
  93. you could ssh to the installer
  94. and obviously, in order to ssh to the installer
  95. it needs to bring up the network
  96. and there is a tool called oldsys-preseed
  97. that basically reads the network configuration
  98. from the device
  99. and then sets up the network
  100. and it can always recognize the DHCP
  101. and then the user connects via ssh
  102. again, there would be some indication, maybe
  103. you know, there would be a "beep"
  104. or maybe change the LED
  105. to indicate that the installer is ready
  106. and then, the user basically performs
  107. a regular installation
  108. with normal d-i; they don't have to
  109. do anything differently.
  110. And at the end, flash-kernel runs
  111. to make the system bootable
  112. flash-kernel is called that way
  113. because it used to support
    flash-kernel is called that way
  114. because it used to support
  115. like the initial device it supported
  116. booted from flash
  117. but it also generates bootable devices
  118. bootable images of disk devices
  119. so it really, flash-kernel really requires
  120. understanding of each device
  121. and our philosophy
  122. in those cases, with those NAS devices
  123. was really,
  124. we don't touch anything
  125. in the firmware, like
  126. in the configuration,
  127. so sometimes
  128. instead of changing the root device
  129. in the u-boot config we would actually
  130. hard-code that in the ramdisk
  131. just because we wanted people to go back
  132. to the original firmware if they had to
  133. if they had to send it in for repair or something
  134. and
  135. and that kind of approach really worked well
  136. so I think we really had a lot of
  137. people, lot of users running
  138. in Debian in those kind of NAS devices
  139. and it was really easy to do.
  140. You get a firmware image,
  141. you connect to the installer via ssh,
  142. and it just works, it's a normal
  143. debian-installer, the way
  144. everybody knows it,
  145. because some of the other distros
  146. they basically provide, like,
  147. tarballs and instructions
  148. so you need to partition a disk,
  149. need to un-tar it,
  150. you need to change those files,
  151. and even if it sounds simple,
  152. it's so many steps that
  153. you always... you often get something wrong
  154. and then you put the drive into the
  155. NAS device, and it doesn't boot, and you don't know why
  156. where did you make that mistake,
  157. which step
  158. and you basically have to start from scratch
  159. so Debian really provided something unique
  160. by adding
  161. the debian-installer support
  162. but anyway, that's the way
  163. it sort of used to work.
  164. Nowadays, with a lot of those bareboard
  165. it's much easier
  166. I'll get to that.
  167. So at the moment there are three different ARM ports:
  168. There is the old armel
  169. which used to be the "newer" ARM
  170. and now it's old,
  171. and one of the discussions
  172. that we are probably going to have later today on the BoF
  173. is about, should we remove that
  174. after Stretch.
  175. There is armhf and the arm64
  176. and we get basically the question I hope to answer.
  177. If, you know, device A works,
  178. I have a device which is really similar,
  179. but it doesn't work. Why is that?
  180. So, heh,
  181. There have been a lot of changes
  182. in various upstream projects, specially
  183. the kernel and U-boot
  184. that really make things easier.
  185. So, in the past
  186. we basically had
  187. a kernel image
  188. for each platform,
  189. where a platform is basically like
  190. a SSE family
  191. and there would be a different image
  192. because ARM takes a long time
  193. to compile, there was always some debate
  194. about adding a new platform
  195. because there would be a new
  196. image flavor, which takes some time,
  197. and that was just really like,
  198. we couldn't just have one ARM kernel
  199. which works everywhere.
  200. And a lot of people didn't understand
  201. why you had a different kernel
  202. because different platforms,
  203. although there has been a lot of progress upstream,
  204. at least nowadays, with armhf
  205. and with arm64
  206. we just have one kernel.
  207. And upstream basically
  208. Maybe some of you remember the rant
  209. by Niels about
  210. the ARM people doing everything
  211. in different ways,
  212. and there has been a lot of standarization
  213. over the years.
  214. Basically, the other thing is
  215. there used to be for each device
  216. there was a board file
  217. it was like a C file
  218. to initialize the different components,
  219. and the boot loader would
  220. pass the machine ID to the kernel,
  221. and it would load that boot file.
  222. And nowadays,
  223. there is basically a
  224. device tree in the kernel,
  225. which is a description of the hardware
  226. and it will basically compile it
  227. to, like, a binary blob, the .dtb.
  228. And, so, basically you just need
  229. the kernel image, and
  230. the .dtb, which is hardware-specific,
  231. and then it boots.
  232. And obviously, for us in Debian
  233. that makes it much much easier
  234. to support a lot of devices.
  235. The other thing that changed in U-boot,
  236. when you install the Debian kernel image,
  237. it creates
  238. the vmlinux file
  239. and also the RAM disk
  240. but with U-boot,
  241. you couldn't actually load those files
  242. correctly. You basically
  243. had to wrap them in a U-boot image
  244. and it's not really hard
  245. it's just the command initram,
  246. but all of the different devices had
  247. different load addresses,
  248. and, again, that's hardware-specific knowledge
  249. that flash-kernel needed to know.
  250. And nowadays,
  251. there is a command which
  252. directly loads the kernel,
  253. so that, again, was a step to make things easier.
  254. And the last thing which really made
  255. things easier is distro support
  256. in U-boot.
  257. So, basically, in the past
  258. every U-boot, every
  259. devices in U-boot,
  260. booted in a different way,
  261. just in terms on where would it load
  262. the file from, or
  263. what variables would it use, and
  264. nowadays there is something called distro-support
  265. which is basically a standardized way
  266. to boot a Linux distro
  267. with U-boot.
  268. There are basically
  269. two ways, either can
  270. read a config file,
  271. or it can basically run a
  272. boot script, and that's what
  273. we use in Debian, so we basically have
  274. a generic boot script
  275. which loads the kernel,
  276. loads the ramdisk, the .dtb,
  277. and boots Debian.
  278. It can use the generic
  279. bootscript in almost all
  280. of the modern devices.
  281. So nowadays, because of that,
  282. it's much more standard, and
  283. it's much easier to support
  284. those devices.
  285. So here are some examples of flash-kernel
  286. So, basically, flash-kernel has like a database
  287. of devices which it supports
  288. so it's like the machine entry
  289. in /proc/cpuinfo,
  290. and then the kernel flavors
  291. it can run
  292. and, so, this one is
  293. an old device, it still uses
  294. a board file, and it
  295. needs the U-boot wrapper,
  296. So...
  297. You are basically setting the machine ID
  298. those are the flash partitions
  299. where the kernel and the
  300. ramdisk are stored, and
  301. that's the load address for the
  302. U-boot wrapper
  303. And, now, that's a device
  304. which used to have
  305. a boot file,
  306. and which then migrated
  307. to a .dtb,
  308. so basically, heh,
  309. that was really really painful for Debian
  310. so, basically, the kernel people said
  311. "Oh, you are going to move to device tree,
  312. so don't worry,
  313. we are not gonna remove those old board files,
  314. you can still use them."
  315. And then, a few years later they realized
  316. it's really hard to keep both alive,
  317. and they got rid of the board files.
  318. And that was really painful to us
  319. because we had to migrate
  320. So you can see,
  321. here, a kernel version,
  322. and so, from that kernel on,
  323. you needed to use the new way.
  324. And one of the reasons it was painful
  325. specially on the QNAP devices
  326. is because with
  327. they actually have two different CPUs
  328. so there are different barriers
  329. and whilst the board files,
  330. the same board file worked
  331. regardless of the CPU,
  332. because of the way the device tree worked
  333. it actually needed two different device trees
  334. depending on the CPU
  335. so now we basically, you know, something that just worked,
  336. you know, it used to work fine,
  337. you just had one kernel
  338. with the machine ID
  339. at least would work,
  340. and somehow with the device tree
  341. we needed to figure out which one
  342. we need, and so
  343. [?] fortunately did all of that work.
  344. So that's actually a script that runs
  345. to figure out which device tree
  346. that particular device needs.
  347. So now, that's actually
  348. the reason I want to show this is
  349. how simpler things are these days, so
  350. this is an example from
  351. [?] platform, which uses distro-support,
  352. and the only thing you really need is
  353. a machine entry with the name,
  354. and then
  355. like the kernel-flavor,
  356. but that's the same for...
  357. you know, there is only one kernel flavor.
  358. And then, the device tree ID
  359. and, again, all of that stuff is generic,
  360. so it just uses the generic bootscript,
  361. and the generic boot path,
  362. so basically
  363. all it pretty much needs for
  364. a new device is, like,
  365. you know,
  366. these two entries,
  367. it's really really simple.
  368. So here, I just wanted to
  369. tell about the different ARM ports and...
  370. So, for me it was really hard to structure this, because
  371. those changes in the kernel
  372. and U-boot
  373. you know, happen independent of our ARM ports,
  374. But at the same time, because
  375. because the armhf world is much newer,
  376. it works in a different way.
  377. So, basically, the armel
  378. we still have different flavors
  379. but we have already combined the orion and the kirkwood
  380. into one marvell flavor,
  381. and we have the versatile one.
  382. So one of the problems we have in armel is that
  383. a lot of those NAS devices
  384. boot from flash
  385. and they only have, some of them,
  386. 3MB for the kernel,
  387. which used to be a lot of space
  388. but nowadays it's not.
  389. So that really puts a lot of restrictions
  390. so basically we disable some stuff
  391. from armel
  392. but I think that armel is really really widely used
  393. because of those NAS devices,
  394. but I think they are slowly getting old,
  395. but there are still a lot of people that use them.
  396. Like I said, it requires the U-boot image
  397. Originally, we used board files
  398. and device tree, most of them
  399. have switched over to device tree
  400. even if some of them still use board files
  401. and adding a new device requires
  402. a number of changes in the installer.
  403. So basically, you needed to map
  404. the device to
  405. the complete image
  406. and there are just there a couple of
  407. things, so basically, any one device
  408. you have to change like five different
  409. places in the installer.
  410. And it was quite confusing for people who wanted
  411. to add new devices
  412. Because it isn't really documented very well
  413. So some examples are a list of three people
  414. who are involved in that port
  415. So, Roger is someone
  416. who is quite new, and who really got
  417. involved into porting those old devices.
  418. And so, armhf is much nicer,
  419. so the majority of
  420. devices support distro-support.
  421. And the other thing we do
  422. is, for some of the devices
  423. we provide SD card images,
  424. which contain
  425. U-boot and the Debian installer
  426. So basically Vagrant
  427. maintains U-boot in Debian, and
  428. a lot of those devices are supported
  429. in U-boot in Debian.
  430. So we just
  431. provide an SD image, so you can just
  432. store it in the SD card, you put it in
  433. and, because of the distro-support,
  434. it just loads debian-installer,
  435. you do the installation, reboot,
  436. and things just work.
  437. So I think it really has gone
  438. ...Come a long way.
  439. So nowadays,
  440. adding a new device
  441. requires much fewer changes
  442. than it used to be.
  443. Because as everything uses the same, like, one kernel flavor,
  444. you don't need to patch all those different places anymore,
  445. and because of distro-support, it just works.
  446. You can pretty much use the generic bootscript.
  447. So, arm64.
  448. So, the problem until recently
  449. is that there simply wasn't any hardware
  450. that people could buy.
  451. And that's changing rapidly now
  452. [?]
  453. We have for example the Raspberry Pi 3
  454. which uses a 64 bit CPU
  455. but the software it ships is only 32 bits,
  456. but most of the work
  457. is now
  458. upstreamed to run 64 bit on it
  459. and there are a lot of
  460. devices which sort of work but not quite
  461. but anyway, so the idea for arm64
  462. is that a lot of the
  463. new hardware
  464. specially on the server side
  465. will use UEFI,
  466. and so you basically just
  467. it just works like a PC.
  468. So you have Grub,
  469. you can run debian-installer from Grub
  470. and you get Grub afterwards.
  471. And just boots like a PC,
  472. and Steve has done a lot of work in that area,
  473. And in theory,
  474. it should just work out of the box.
  475. So, if it uses
  476. UEFI, we don't need to add anything.
  477. It just works.
  478. There's nothing to do.
  479. At least, that's the theory.
  480. So, what I found is
  481. ...I made a disclaimer, so
  482. ...Assuming the kernel
  483. you know, kernel support and stuff...
  484. ...To be honest,
  485. right now, that's a big assumption.
  486. So I've been playing with a few
  487. 64 bit ARM boards
  488. and basically, what I found is
  489. there is some support upstream,
  490. so I can boot a kernel,
  491. but, oh! There is no USB support!
  492. there is no Wifi support!
  493. So I cannot actually do anything with it.
  494. But I can get to something that
  495. because arm64 is still farily new.
  496. And there is a lot of work going on upstream
  497. to support the various platforms.
  498. So, I think over time that's really going to be much better.
  499. Even though that UEFI idea is there
  500. in reality,
  501. we are going to see different solutions
  502. for arm64.
  503. So we are going to see UEFI, in particular on servers,
  504. but we will also see U-boot.
  505. So a lot of those bare boards
  506. they have U-boot.
  507. And, so, right now
  508. we can use the distro support
  509. and I think that it works pretty well.
  510. But one thing that SuSE has done
  511. so, they just had the same issue,
  512. they want to support all those devices
  513. but they just want to use the same mechanism everywhere,
  514. so they have actually implemented
  515. UEFI on top of U-boot,
  516. so you can basically use U-boot to load Grub
  517. and then you have Grub
  518. so I think that's something we need to figure out;
  519. do we want to stay with distro-support?
  520. do we want to use
  521. UEFI on top of U-boot?
  522. is that something we want to
  523. give users the option?
  524. And then, Fastboot
  525. is something used
  526. in the Android world
  527. and a lot of those, like, I see a lot of
  528. both bare boards, but also
  529. game consoles and stuff, which
  530. which are sort of Android-oriented,
  531. but which can also run normal Linux,
  532. and they will use like Fastboot or something.
  533. And there are tons of other bootloaders out there
  534. But I would definitively say, like, the good ones
  535. are UEFI and U-boot
  536. So, I gave a similar talk a few weeks ago
  537. and turns out, a lot of non-free
  538. firmware, like, "can I
  539. run that stuff, you know,
  540. purely with free software?"
  541. ...And...
  542. So, the thing with ARM is that
  543. there are a lot of different platforms
  544. I'm not sure about all of them,
  545. but some of the platforms
  546. I looked at, yes, you
  547. do need some... There is always something propietary.
  548. So in a lot of cases
  549. I see where you have
  550. you use the proprietary first-stage boot loader,
  551. so the Raspberry Pi is an example,
  552. so, I don't actually have a Raspberry Pi, but
  553. the way I understand it is
  554. you basically put some boot files
  555. in an SD card,
  556. and they are proprietary, and
  557. then they load the kernel.
  558. Or in case of [?]
  559. supported in Debian,
  560. the first stage boot loader would basically
  561. be used to run U-boot,
  562. and then we could use U-boot, and
  563. the U-boot support all of it is free software,
  564. but the first stage boot loader isn't.
  565. I have had, there are some people
  566. working on a free replacement for
  567. the Raspberry Pi, though.
  568. With nVidia Tegra,
  569. which is
  570. something I'm working on at the moment
  571. you also have a tiny first stage boot loader,
  572. but then again, you have U-boot, which is free,
  573. and in that case, you also have some firmware
  574. images for the GPU
  575. and for other stuff.
  576. For the Dragon board,
  577. The Dragon board sounded really interesting
  578. because it actually has a
  579. a graphics chip
  580. which can be used with free software,
  581. so that sounded pretty cool,
  582. but again, it has a
  583. proprietary first
  584. stage boot loader,
  585. and then there is a second stage boot loader
  586. which is actually open source
  587. and then there's actually a U-boot of that,
  588. and then you have some
  589. binary blobs which
  590. also need to be installed in flash to work properly
  591. On the Marvell side, I'm
  592. not really aware of anything.
  593. I have never needed to flash anything
  594. proprietary, but
  595. I'm not sure how U-boot gets started
  596. on Marvell, so maybe there is something.
  597. So the future is all... So NAS devices are
  598. like I said, that's something that's
  599. really been popular in Debian.
  600. Specially on the QNAP devices,
  601. but the problem is, so, QNAP...
  602. so the devices we currently support
  603. are pretty old
  604. nowadays,
  605. and they have some newer devices,
  606. but they are not properly supported
  607. in the upstream kernel.
  608. So, I have no plans
  609. to support Debian on those.
  610. I recently did some work on
  611. Seagate NAS devices
  612. which are actually pretty interesting
  613. but again, they will go out of date
  614. already,
  615. and then there's the whole 64 bit ARM
  616. so I think people are really waiting
  617. for arm64 servers
  618. I think there's going to be a whole lot of
  619. work on that area.
  620. And then, there are all of those development boards
  621. Raspberry Pi,
  622. Pine64,
  623. Allwinder,
  624. Basically, all of them
  625. sound exciting, but if you
  626. look at them, all of them
  627. have some upstream issues, so it's...
  628. It is really quite frustrating at the moment.
  629. But I think things are really
  630. moving [?]
  631. And then there's this 96Board initiative,
  632. which is actually done by Linaro,
  633. and, so, Linaro supports
  634. Linux on ARM, so you'd think, "wow,
  635. there are some really nice boards coming out!"
  636. and they differentiated
  637. between the consumer edition and the enterprise edition
  638. beside, I bought some consumer-edition boards,
  639. and it's really horrible.
  640. So first of all, I had to spend like half a day
  641. just putting the components
  642. because it uses, like, a nonstandard power supply,
  643. a nonstandard serial console,
  644. so finally I found
  645. all the pieces I needed, and then
  646. I was expecting, well, it's from Linaro!
  647. Surely everything just works upstream!
  648. But it doesn't. It's like
  649. yes, I can boot the Linux kernel,
  650. but there's no USB, there's no
  651. Wifi, no nothing...
  652. So, yes, that's a little bit frustrating.
  653. On the enterprise edition,
  654. I think that looks more interesting.
  655. You know, that's more standardized.
  656. But again, there have been some delays.
  657. [audience; unintellegible]
  658. Yes, OK.
  659. So that would be interesting to see.
  660. So, the questions that I actually have nowadays
  661. is, so...
  662. Because of those changes,
  663. because of having, you know,
  664. a mode of U-boot, most of those
  665. new devices having a U-boot
  666. with distro-support,
  667. having a kernel which, you know,
  668. one kernel image that works on all of those
  669. devices which are supported,
  670. it's really easy to support
  671. a new device?
  672. As long as it's supported by the kernel.
  673. But, at the same time, I think it's a big
  674. challenge for Debian.
  675. Because right now, if you look at armhf,
  676. we basically say, well,
  677. hint the installer,
  678. and if there's a device tree,
  679. it's probably going to work.
  680. But, what does that mean, right?
  681. And...
  682. which really work, which means,
  683. so, we have Vagrant
  684. having U-boot support
  685. in Debian, we have
  686. people testing debian-installer,
  687. testing the Debian kernel, so we have
  688. devices which really work, well supported,
  689. and then we have some devices
  690. on the other hand where, well, yes,
  691. there is a device tree, but no one
  692. has ever tried it. And
  693. at the moment, we have no way
  694. for users to differentiate
  695. those use case... Those
  696. support levels.
  697. So I'm wondering if we need
  698. like a table,
  699. somewhere where maybe
  700. some support levels, like green, yellow...
  701. red?
  702. Where green is, "yes, we have Debian
  703. people who have
  704. testing that stuff",
  705. yellow would be, "well, we have heard some report
  706. that it might work", and
  707. green is, you know, doesn't work,
  708. or we haven't tried that it works.
  709. Maybe we need something like that.
  710. But right now,
  711. I see from users
  712. "I want to run Debian on my ARM device", and
  713. they don't know if it's going to work.
  714. Yes, then...
  715. [audience; unintellegible]
  716. Yes, so Ben is saying we also need
  717. to track what the earliest and the latest
  718. kernel versions that there have been tested.
  719. So I think we really need to
  720. come up with some criteria
  721. to have, you know, define those kernel support levels that indicate that
  722. And yes, the other question is related
  723. to, with all those boards,
  724. how do we actually test them?
  725. So, I keep --
  726. it's really... remember [?]
  727. which is great, but also acknowledge
  728. those boards, they are so cheap!
  729. so it's like, "oh, there's a new board!
  730. It's £30! I'll just get it!"
  731. And then we have, like, those piles of boards
  732. and realize, well, I don't have time
  733. for testing all of that stuff!
  734. I think that's going to be a real challenge.
  735. hundreds -- I don't know,
  736. it's really hundreds of boards coming out.
  737. How do we support all of that?
  738. So, I think that's the question I wanted to raise,
  739. and maybe something we can talk about in the BoF
  740. But yes, I'm obviously
  741. open for questions now.
  742. [James / purpleidea:] Hello.
  743. So, don't quote me exactly,
  744. so, I believe
  745. RedHat has this problem as well, obviously,
  746. I mean, they are obviously more interested in the
  747. ARM64-only server stuff,
  748. but I believe the way they are going about it
  749. maybe it's something could collaborate on
  750. is, they are trying to make sure and push
  751. all the vendors to be standardized
  752. because, as you pointed out,
  753. it's just not, it's crazy
  754. with all the different device tree differences and so on,
  755. so I believe their strategy is to
  756. work with the vendors, and
  757. require everything to be upstreamed, and
  758. no device tree
  759. specifically, to push everything to just boot
  760. with one kernel, and so on.
  761. So maybe that could be
  762. sacrifice a few of the
  763. shitty boards, but work with the vendors
  764. that make the ones that are upstreamed.
  765. [Martin:] Yes, so I may be mistaken, but
  766. as far as I know, RedHat
  767. basically says, "we only support
  768. UEFI and ACPI"
  769. and that's fair enough,
  770. and I think that works for them, because
  771. it's just the server world they care about,
  772. but I think in the case of Debian
  773. there are so many boards out there which
  774. don't need those specs,
  775. and we sort of live, like, in the "real world"
  776. so I don't think we can
  777. Well -- I know it's different. I mean,
  778. if RedHat wants to target
  779. the server people, like, the people
  780. which give money
  781. that's fair enough, that makes sense for them
  782. but Debian, we run everywhere
  783. so I think we need to support
  784. all those weird
  785. cases as well.
  786. And maybe if it gets too weird,
  787. I mean,
  788. I put in some work in the Dragonboard,
  789. and then I realized,
  790. am I actually spending the time because
  791. no one, like, I have heard
  792. from no one that they have
  793. that board, I mean, like [?]
  794. for the Raspberry Pi, but I have heard
  795. like, pretty much no one has the
  796. Dragonboard, so maybe,
  797.'s not worth my while,
  798. but if there's a board
  799. that people want to use it,
  800. I think we should support it in Debian.
  801. And we do have the infrastructure
  802. so we, you know, it doesn't have to be
  803. UEFI and ACPI,
  804. we can support other devices, because
  805. we have done it before.
  806. But I definitively agree with
  807. the point about getting more standardization
  808. and that stuff, so
  809. I agree, yes.
  810. And the whole distro-support
  811. in U-boot, that has really made things easier for us.
  812. [Phil:] I may begin to say some of the same things Steve has, anyway.
  813. Steve]: So, yes, on the
  814. ACPI versus DT thing,
  815. it's more a question
  816. of the quality of the implementation of the
  817. of the firmware,
  818. and the upstream support that is...
  819. DT isn't fundamentally
  820. worse for upstream support
  821. than ACPI is,
  822. RedHat are
  823. have some reasons
  824. [?] of sensibility,
  825. but then, it's not
  826. fundamentally, it doesn't fundamentally stop it
  827. people supporting it, specially
  828. a community distro like Debian.
  829. I was also going to ask Martin,
  830. have you talked to
  831. people like kernel CI
  832. about testing and coverage stuff?
  833. [Martin:] Yes, not really, but
  834. I think there are some things we should look into.
  835. [Steve:] Yes, because the whole --
  836. Obviously, making sure the kernel boots
  837. on random hardware
  838. stuff, is exactly what that's doing
  839. and there's at least infrastructure there that might be
  840. nice to play with.
  841. [Martin:] Yes. I think that's a good idea.
  842. [sledge:] So, on the whole 96Boards thing,
  843. sorry!
  844. Most of the engineers involved
  845. are totally aware of
  846. how [?] it really is.
  847. We tried to tell management
  848. they would --
  849. They don't want to listen.
  850. Umm.. So,
  851. there has been a huge amount of pushback
  852. saying, you know, "we're Linaro
  853. we should make sure this is all upstreamed".
  854. [Martin:] Well, I am aware
  855. it's just, Linaro
  856. has a really good brand,
  857. so people expect, you know, when I saw
  858. 96Boards it's Linaro,
  859. obviously that stuff it's going to work!
  860. and that's why I was really disappointed.
  861. [Steve:] One positive thing there
  862. is that the first DE board
  863. the SoC does basically work upstream
  864. already with current upstream kernel
  865. it's not like there's some patches still
  866. to go in. Apart from the PCI, it should basically
  867. work... So, hopefully,
  868. hopefully, that's going to be a much
  869. less spectacular
  870. story than the
  871. consumer-edition boards have been.
  872. As they are unfortunate.
  873. [Sledge:] The first EE board
  874. the [?]board, is due to start shipping
  875. really soon now.
  876. There are examples already out there
  877. with engineers for validation.
  878. Literally, we are talking the next couple of weeks
  879. is what I have been told.
  880. That's the first 96Boards I would
  881. actually spend any time on at all personally,
  882. the CE boards are a joke.
  883. I forgot what else I was going to say. Oh!
  884. Yes! Then...
  885. I guess we will go through a lot of this again
  886. in the ARM BoF later on
  887. in terms of
  888. which things we support.
  889. We will carry on with the discussion.
  890. [Vagrant:] Um... Is this working?
  891. Yes, so...
  892. We have got all this great support for
  893. distro-boot command and U-boot, and
  894. now we are starting to get
  895. to UEFI emulation
  896. in U-boot, so even for boards
  897. that don't have UEFI emulation--
  898. UEFI support, if they support
  899. U-boot, it might work
  900. although that means all the standarization
  901. we worked towards, we throw it away.,
  902. Meh!
  903. [Martin:] Yes, I think that's something we need to figure out,
  904. which one do we want to standardize on,
  905. or is that something we want to
  906. leave up to the user.
  907. but yes,
  908. I mean, I think one
  909. I mean, I guess it was
  910. so confusing, because there are like
  911. all those different ways, but
  912. what I really wanted to show is that
  913. things are getting much more
  914. standardized and much better.
  915. So, it used to be really
  916. pretty horrible, and nowadays,
  917. you know, if a platform
  918. uses a modern
  919. U-boot, if it has
  920. upstream support, then it is
  921. actually pretty trivial to add
  922. Debian support, and
  923. I think that wasn't the case
  924. in the past.
  925. I think Ben had another one?
  926. [Ben:] So, I'm
  927. [laughs]
  928. I'm interested to know how much
  929. how much interest there is among the ARM porters
  930. in graphics support.
  931. GPU support, rather
  932. than settling for dumb framebuffers.
  933. How many...
  934. How many of these boards...
  935. Quite a lot of these boards do have HDMI
  936. and I don't know
  937. to what degree they are actually supported.
  938. Are any current projected work
  939. which definitively is using the
  940. GPU on ARM system, and
  941. what's in Debian,
  942. is the Debian base system
  943. does Debian... What's in Debian does not
  944. support GPU.
  945. [Martin:] So, I can't speak for Vagrant...
  946. I have personally done some work
  947. on the Tegra recently,
  948. and nVidia is actually
  949. working upstream on [?]
  950. so I'm really interested in it
  951. but I think that a lot of
  952. the board used, there's money
  953. GPUs I'm not sure would be
  954. can get a [laughs]
  955. can we get a microphone for Steve?
  956. [Sledge:] So, on the Mali front,
  957. there has been a lot of haste where we
  958. have been scared of releasing any of this
  959. in any way, shape or form,
  960. without huge
  961. [?]-relays and all that kind of stuff.
  962. So it's not really distributable.
  963. Even, at all.
  964. We are a long way of it being releasable free,
  965. There are packages coming that we
  966. should be getting shippable in non-free
  967. at least if you want to get full acceleration
  968. on your Mali stuff.
  969. Hopefully, that will solve some of the problems
  970. There is a lot, there are a lot of people
  971. in [?] who are very very keen on
  972. supporting it properly, free and upstreamed.
  973. It's a long fight.
  974. It will take a while.
  975. I mean, most of the Mali driver developers
  976. themselves I have spoken to, would love to
  977. make it free. It just comes down
  978. to legal people
  979. being scared.
  980. [Tobi:] Are there some questions left?
  981. [Martin:] Well, thanks for coming!
  982. And there is going to be the ARM BoF
  983. later today, and
  984. Vagrant is also going to talk about his experience
  985. about running a build network
  986. on armhf boards..
  987. Thanks!
  988. [audience clapping]