 Hey, I'm Peter Robinson. I'm here to talk about basically the state of Fidora on our Sorry, yeah, so I'm I'm going to be covering Both V7 and a art 64. I'm going to run fairly quickly through most of this If anyone has any questions feel free to ask as we go and The slides are fairly basic, so there'll be a bunch of other information as I go Yeah, so so I mean overall both on V7 and a art 64 are now pretty damn boring pretty much Everything is supported in the user space everything builds And everything just continues to roll along In the server and cloud space so docker base image Cloud images server installers various other bits and pieces All relatively straightforward all looks exactly like x86 all operates exactly as expected pretty much nicely boring and In Fidora 27 Adam Miller has been working on the multi-arch stuff And the modularity team has been working to a degree on the multi-arch stuff So for f27 when modularities happens You know, it'll be there for the arm architectures as well exactly as you would expect for x86 the current plan is to promote Server for art 64 in F28 timeframe, I've spoken to a bunch of people about it. I need to get around to filing Changes and fesco tickets and various other bits and pieces relinch tickets Because I've got vast amounts of work to do like flipping bits for locations of Output and various other bits and pieces, but overall it's it's all there and it works exactly as you would expect Workstation and in particular accelerated GPU support is starting to get quite interesting Going back a few years. We literally had nothing That was open accelerated Drivers for arm and the ecosystem there as a whole was fairly terrible now. We have a handful of Different fully accelerated so at the vid on like the IMX 6 and a few other secs the Tegra Stuff in the more modern GPUs is all supported by the Nuvo driver out of the box Rob Clark has been working on the Fridrino driver and will have a Couple of devices or at least one device That that works on out of the box 64 bit 96 boards dragon board For fedora 26 you should be able to run a fully accelerated workstation out of the box And of course, there's a Raspberry Pi with their open driver where we've supported Accelerated drivers on workstation since fedora 25 and will be bringing that to 64 bit as well in F 27 so Overall the GPU support has been looking quite good and and there's some other interesting stuff coming along there as well so Media acceleration and offload so similar to the way you sort of Android phone can do Like full-screen and video without using huge amounts of CPU and battery We'll be able to do similar sort of stuff on arm. So there's some interesting stuff coming in there Which will make things like media centers and other related things quite interesting on fedora because we'll be able to do fully accelerated offload of Things like h.264 without actually having to ship any codecs and stuff because all just happen in hardware basically and finally 64 bit single board computers such as the Raspberry Pi Will finally support in fedora 27 I was going to hopefully do a demo But it wasn't working and the demo gods weren't with me and the fedora compose process wasn't quite with me But so the way we're working For things like the pine 64 and the raspberry pi and some of the 96 board stuff But basically any of the arm 64 bit single board computers will be UEFI and grub boot So basically it will look exactly like an x86 laptop. You'll get a grub menu. It'll boot Work exactly as you would expect. I mean some of the advantage of that is we get single code paths across SPS a compliant servers and like SBCs and things like that and basically Everything is just nice and simple and works as expected. So there'll be So a couple of those 64 device bit devices like the raspberry pi 3 and the dragon board You'll be able to do fully accelerated workstation on Tiny little sort of boards and and stuff like that so I've been asked for ages when are we going to support that sort of stuff and I've been working on it for ages and we're finally sort of aligned and got all the bits needed into the right places With huge help from people like Rob Clark and mr. Jones and various other upstream Maintainers, you know, it's in a nice position and you know if you find me tomorrow You should be I should be able to demo it for you if you're interested. So so there's a bunch of stuff there where You know finally we're basically becoming normal and boring and everything just works exactly as it would on any other device And the other thing that people ask me about is things like network and storage and stuff like that There's a bunch of cheap single-board computers and similar that can do Some interesting network stuff with network switches and things like that and we're slowly getting some support upstream and Speaking with some vendors and getting them to do some work and various other bits and pieces around things like network functional network function virtualization With things like open v-switch and stuff And like those sort of devices of things like the espresso bin and the macchiato bin and other sort of devices Like that where we end up being able to do some interesting sort of use case and testing around Like storage networking various other embedded use cases that a lot of people are interested in so I mean ultimately the arm stuff now is Nicely boring and basically just works and so Rather than chasing our tail Fixing like user space compile problems and various other bits and pieces like that. We're now looking at sort of Where the arm stuff is cool where we can sort of value add so IOT related stuff is obviously my day job and we're looking at a bunch of things around That and I'm speaking to a bunch of vendors and partners that are interested in doing things around that and actively contributing into fedora I think in fedora 26 We've had engagement from maybe 12 different arm vendors where they're actively hanging out on the IRC channel They're actively testing and fixing bugs and contributing patches and features into fedora And it's taken us a long time to get there, but it's kind of cool seeing, you know, various different arm SAC vendors sort of contributing straight into fedora stuff and You know, I'm getting to the point where there's some things that I previously had to do all myself and People are just like arm vendors are coming in and going hey, we're seeing you need that so We're just going to get on and do it and I didn't actually put it on the slide because I didn't think of it at the time but But Shortly we should be able to start to provide copper for arm 64 as well Actually have the hardware on its way or may even be sitting in the data center already And we just basically need Power and network and a few other bits and pieces Which are being worked on so that we can Enable copper because I think the 64 bit Single board computers and copper are probably the two biggest questions. I get asked around 64 so I'm looking forward to similarly when I added support for the Raspberry Pi I'm looking forward to be able to say hey, it's done. It's over there. Just go and use it. So I Think that's about it. Has anyone got any questions? It is so basically we use you boot and Initially, it was implemented by Susie and that was sort of just enough UEFI and then Rob Clark and Another guy, which I can't remember his name who I think is part of the Debian project and a couple of other individuals have done a bunch of functionality where basically you boot emulates UEFI To enable us to basically run grub and and various other bits and pieces There was a patch set that came through on the list a few weeks ago Which implements all the UEFI network services so you can run things like iPixie and stuff like that on them and so basically so in some cases The devices have tianocore, which is the I suppose you'd say the upstream Yeah reference implementation of UEFI and and so that just works as if it was like but in some cases that is a large complex beefs and Companies coming from the embedded side where they've dealt with you boot a lot Suddenly like oh well if we can do this within you or UEFI within you boot It gives us a way of supporting that plus our old-style boot methods with a single code base so and then so that's now and We don't have it all everything's not quite upstream, but we're not far from it and I'm speaking to vendors like board manufacturers and things like that saying we want SPI flash on these devices and We want you to either put tianocore on that flash or we want you to put you boot With the UEFI support on that flash so that we can just plug in a fedora SD card And it just boosts or you can plug in a Debian or you can plug in a Susie SD card and it'll just work and so these are conversations which Three four years ago. I would never have with vendors and now vendors are coming to me How can we make this easier? What do we need to do to enable this and so it's Interesting because suddenly we're getting to a point where stuff just works like I got an email from Evan Upton the creator of the Raspberry Pi going hey, I've heard you're Doing 64 bit with UEFI and grabbing that on the pie Can you demo it to me? And it's like that's an email. I never thought I would get so so you know It's been a bit of a long haul But that there's some really cool stuff happening and then on top of that We're starting to do things like machine learning and AI and stuff like that. So, you know rather than doing bare metal does this board work The vendors are starting to take over that and I'm slowly starting to be able to like Do IOT things on top and stuff like that which is ultimately what I wanted to do when I first started to scratch the arm It's seven or eight years ago So people would call me a little persistent or you know Any more questions? What do you mean by the problems between servers and SBCs? So there has been a few trade-offs we've had to make So the Enterprise OS supports 64k page sizes We've had to go with 4k page sizes because we need CMA and CMA with 64k page sizes Takes up half a gig of RAM which basically makes say the Pi 3 unusable So there's but that ends up being a trade-off Not really between server and workstation although it may end up being for super large like Multi terabyte size servers But I mean I don't think it's going to change that much because I mean ultimately even on x86 We have monster server HPC cluster versus Like laptops and other such devices and you know there's compromises that have to be made there And I don't see that that's any different on you know on arm versus x86 Maybe the SP like the single board computers and that are smaller specs than you would generally see on say an x86 laptop But there's sort of still similar sort of Trade-offs that need to happen there. So I don't think it would get any worse Certainly, there's probably use cases that are slightly different that might have more of an impact, but you know I Don't I haven't generally seen any sort of major sort of alarm bells that have been ringing anyone else Jared So yes in some cases for Dora does run slower the Raspberry Pi is a case in point and part of that is we use pure upstream and There's reasons for that One maintain a ship. I don't have the time or the interest in maintaining 30 different vendor branches One of the advantages we get of that is we don't get things like Vendor included backdoors and other such things That was saying like a bunch of the all-winner code that other distributions just blanket shipped and That but like in so in the Raspberry Pi case in Fedora 25. It was pretty goddamn slow In Fedora 26, I did a bunch of work and we went from I Think about 8 megabytes a second on a class 10 SD card to 26 28 megabytes a second Which made things a whole lot faster There was a combination of stuff. There was some bugs and in the process of enabling so The Raspberry Pi is kind of interesting in that most armed SBCs will include like three to five or eight MMC Controllers on board to drive different things and they will all be the same IP running the same driver The Raspberry Pi for some reason has two completely different sets of IP for the two MMC controllers that are on board one of the cool things with a bunch of the arm hardware is that you can basically reconfigure how the work Hardware works by adjusting the pinmuxing and so one of the things that happen is when The driver for the Wi-Fi like for the MMC controller that the Wi-Fi is connected to when upstream That one's actually faster So we flipped the pinmuxes which meant basically the SD card got one controller That's a lot faster and it gave us more IO and there was a issue Around the DMA driver where we got a bug fixed upstream and we weren't including it in the in at RD So when the MMC can so like so that fixed a whole bunch of stuff The one big remaining problem with speed on the Raspberry Pi is there's not an upstream CPU frequency driver So it's running at 600 megahertz not the potential 1200 megahertz and yeah, so and That's the case along across a number of different stuff if you ship the vendor kernel they have some optimised ations for it and we're Shipping the upstream kernel and like similarly With the vendor kernel in some cases you can get like the proprietary GPU binaries working and obviously that's not stuff. We're interested in and so like a bunch but like so the orange pie stuff for example people have told me that Actually the fedora stuff runs much faster than some of the vendor stuff because there's been optimisations upstream so it swings and roundabouts and you know sometimes we're not quite as fully featured on some of the devices simply because the code's not upstream and I Don't want to and I don't think the rest of the fedora kernel team wants like a million lines of patch code in there Because that's just not pleasant for anyone And so, you know, there are some devices like the orange pie stuff Which at the moment is great for IOT and servery stuff because it doesn't have the display And you know people ask me what is the best arm device to buy full fedora? And the first thing I reply is what do you want to do with it? Because obviously different tools for different jobs right if you want fast network throughput the Raspberry Pi is not it So, yeah, it's it's complex basically Any more questions cool. Thank you