 Hy, mae hyn yn dreun gyda cyfle o rob gnwysau Cyflwy Markington. FACFORLOR mae'n cael ei ddweud, ychydig i'n cael ei ddweud. Felly, dyna'r ffordd o'r cyfnod o'r cyfnod o'r fideo, mae'n cael ei ddweud, ychydig i'n cael ei ddweud. Felly, ydw i'n cael ei ddweud. Felly, y dyfodd o'r gweithio ar gyfer y Debyn mae'r Armel. Rwy'n gweithio'n Lenni. Mae'n gweithio ar y pwynt. Mae'n gofynu'r EABI soft float for a minimum architecture version of what V4, on V4T. Are people aware of what V4T means? Is anybody not? Right, okay. On has a whole range of different architectures out there. Basically, as we move on, similarly to the, I guess the more well-known, I386, I486 and so on, new instructions are added and old instructions are removed as you go later on up the series. Version 4 is now really quite old, and the T on the end means that as well as running the normal 32-bit ARM instruction set, it will also run the smaller size thumb instruction set. So, for what we have already in RML, you can use a mix of ARM and thumb instructions. To be honest, most people just tend to use ARM as far as I'm aware, but there's always people who do different. The reason that we're still targeting V4T with RML is it's still needed for older hardware. Anybody here with an open moco? Woo! I mean, the really old hardware, the old strong arms won't go with this anymore. The open moco, I believe, is the only thing out there that people still care about that must have V4. It is an open question as to how long we're going to support those for. If anyone wants to comment on that now is a good time. Cool, okay, we can go for V5. It's still supported upstream. The tool chain still works. The kernel still works. Most upstream software, in as much as it ever cares, will happily work on V4T. We get the odd complaint from people who have to think harder about what they support, say the JavaScript folks who are doing the Java engines in Chrome and Firefox, typically complain all the bloody time, oh my God, why are you only supporting such an old version? But it's something that's open, and I'd like to talk about that more later. The more recent port of RML. On that point. Yes, Wookie, go. No one has yet persuaded me that V5 is any faster. From Debbie's point of view, we don't care unless it's actually hard to support. My understanding is that it basically makes no difference. It's not from software that simply doesn't build anymore. I don't think we care. I know from tool chain people at ARM how to keep on telling me otherwise, but I've yet to see any benchmarks that say one way or the other. You and I should go and beat Richard up until he actually gives us some useful numbers, I guess. Sorry, Wookie and I both work at ARM and the tool chain team sit roughly in between us. It's easy for us to go and beat them up until they help. ARM HF is the newest of the ARM ports in Debian. We started on this a couple of years ago. All of the heavy lifting for the bootstrapping was done by Constantinos Margaritas, who can't be here today. He devoted a good year of his life to bootstrapping ARM HF because he thought it was the right thing to do. The difference from ARM YL to ARM HF is that ARM HF targets much, much, much newer hardware. V7 is the latest released version of the ARM family and we expect to be using V7 using the hard float variant of the ABI and using a specific minimum variant of the VFP, the vector floating point unit that comes with V7. ARM has a colourful history with floating point. Back in the day, the very first ARM port in Debian, just called ARM, used to require hardware floating point. The problem with that was that at that point approximately no ARM hardware ever had floating point. So at the moment you did any floating point work, the system would have to trap on an illegal instruction and unwind in kernel back to the point before that instruction started, emulate the instruction, fix everything up again and return to user land. So it worked, but instead of a floating point operation taking two, three, four cycles, it could take thousands. So it worked, it was crap, we moved on. The EABI, which was where we started with RML, the difference is it actually assumed that you did not have hardware floating point. So even on hardware that did, you would always use library versions of floating point ops. You could, if you had the right hardware, use hardware floating point and that started to become more and more common with v7 definitely it is expected that everything will always have hardware floating point. So the reason that we've shifted ABI again is again for performance reasons initially. The problem with assuming that you don't have hardware floating point is when you want to do floating point instructions you have to copy all of your floating point arguments into the integer registers, call your floating point function, copy them out again, do the work on them, copy them back again and then in the calling function copy them back into the floating point register where they started in the first place. So that's four copies for every single floating point argument going through, which is horrendous. As we now actually expect to have always hardware floating point we thought fine, let's use it. Benchmarks on this very hugely in terms of showing what benefits you get. The best type of contrived benchmark will show that you can get like a factor of two performance improvement using RMHF. That's places where you're doing lots and lots and lots of floating point calculations but also way down a deep recursive stack. So at that point you're spending more time just copying arguments in RME L than actually doing any wheel work. In terms of wheel software, in terms of some of the other benchmarks, RMHF frankly is just the same as RME L because for integer ops it's a no op. For anything that is floating point heavy you might see a 5% improvement, you might see 10% depending on exactly how heavy it is. If you're unlucky you don't see anything but equally you don't lose anything. So the main reason that we've actually stuck with RMHF is it is the new agreed standard for ARM Linux distributions. So that means Debian is doing an RMHF with this specification. Ubuntu is doing an RMHF with this specification. OpenSuser is doing RMHF with this spec. Fedora almost are. I'll tell you more about that soon. There's been some fun that we had defining a new linker path. The one thing that must be different if you're going to have working multiarch between multiple different flavours, multiple different CPUs is the location of the runtime linker, LD.so. If that clashes with two of your architectures you just lose, you cannot work around this because obviously that is the path that's embedded in the header of all of your elf objects. The kernel elf interpreter looks at that and runs that program to start your program. If there are several different architectures that share the same linker path, the kernel has no idea whether you want to run this as a Spark binary or as a MIPS binary or whatever. This is where fun comes in. So we had to define a new linker path for RMHF which is different to that for RML. Again, that would cause some controversy in the wider community. We now have a solution. If anybody wants to know the details, ask me later. I'm not going to go into all of it now. RMHF is well supported by most people now. It's the default in Ubuntu for ARM. In Debian we're working on it, everybody else is. In most cases, of course, the compiler does all the work. We need to worry about it. For places where you do need to worry, places like Jets, people are already doing the work here. So it's fine. There are bits and pieces that we'd like to finish. Mono at the moment does not do floating point usefully in an ARM context. Mono is capable of doing floating point, but it's awkward. There is still some work to be done to have it. So Shields, one of Debian's main mono guys, has been pestering people, me included, for a long time to say, please come and do the work. Libffi has issues as well. One of the issues with the ARM HFABI actually pointed out a bug in Libffi. Libffi, for those people who don't know, is a library that is used for talking between different languages and sharing data structures. If you're going to do different data structures across languages, if you're going to be passing around function definitions and everything, it kind of helps if your ABI is supported. ARM HF is the first one, I believe, where you pass floating point arguments in registers unless they're in variadic functions and then they go on the stack. This causes Libffi to essentially explode. But fingers crossed, almost no one has actually found a place where anyone does variadic with floating point in Libffi. We've looked at Python, we've looked at Haskell. I asked for help on this many weeks ago and I dug through to find a place where Libffi might break things. It seems that in those places that we did find, nobody cares. Be aware of this, Libffi with variadic is scary broken. It's not ARM HF, it's Libffi. This graph hasn't come out as well as I hoped. If we go have a look at the last quarter in the WN archive, there are many, many lines here. The ones to look at, ARM HF is the red dotted line that is typically up around 96%. We had a little drop here when we had problems with buildies and it came back again very quickly. ARM EL is basically keeping up at about the same point. This graph would be much easier to read because it would be much more spread out if it wasn't for the herd crap at the bottom here where they're not keeping up at all in any way. Sorry, I shouldn't be pejorative about herd. I just don't see the point. The next version is basically more detailed. When I did these slides about 10 days ago, it was just showing for the last two weeks and you can see ARM HF, ARM EL, despite the fact we have some of the slowest build machines these days are keeping well up with everything else. The turquoise line in the middle is IA64, which is keeping up in terms of hardware but is struggling a bit more for other reasons. Talking about buildies, the big issue we have is we don't have our proper ARM servers. Nobody really makes ARM servers yet that we can actually just plug into a rack and leave to churn for a few years at a time. We end up using development boards instead. The ones we're using for ARM EL are mostly hosted at ARM and those are the Marvell For Ocean CPU, which is a V5. That's fine running the V4T stuff. They're reasonably specced. They have a gig and a half of memory typically. They work very well. Obviously, we would always like faster. For ARM HF, we have the free scale IMEX 53, which is a V7 board. That's a Cutex A8, which means it's not the fastest build machine in the world. It's single core. It's got a gig of memory, but it does have native data as does the Marvell board. In terms of buildy performance, far and away, the biggest issues are you want lots of CPU, you want lots of IO depending on the build, and you really, really want huge amounts of RAM if you're going to be building some of the bigger packages. If you're trying to build something like Ice Weasel or Open Office, I think WebKit has shown this in the past as well, linking in swap hurts. Don't ever do it if you can avoid it. Unfortunately on these machines, we don't have enough RAM, so we can't avoid it. It's painful to see that the build itself might take two hours and then take 12 to do the final link stage. Ow, it's not much we can do. For newer hardware, we're hoping for real servers. One of the nice things that's coming up in the ARM world is bigger vendors doing proper servers based on ARM. The Calzada folks, hopefully people might have heard of them, are people who are doing a very, very densely packed cluster-in-a-box style ARM server where you can have a little quad-core Cortex-A9, four gigs of RAM, many, many gigabit, or 10 gig ethernet connections to it on something that's not much bigger than, say, a typical dim to go in a server box. For five watts, you end up with actually quite a capable machine. If you put loads of those into a 2U or 3U rack-mount box, then that's it. That's your build form in one go, and it's all neat and tidy and really nice. I know that Dell are working on... There's a recently announced copper server, which is Dell's variation on that. That's using more VLV7 CPUs. Again, it's all about getting high identity and better throughput. So if you want to get many, many servers, you have a set of ARM blades drawing almost no power but doing everything you need. Fingers crossed, I'm trying to get hold of examples of both of these to see how well it works, because I'm sick and tired of going and rebooting dev boards because, frankly, they're not designed for 24-7 stress. Proper servers would be lovely. If any people here have contacts or friends in Dell, HP, Calzada, or anybody else who we know is doing ARM servers, please help. So, quick summary of what's going on elsewhere in the ARM Linux world. Does everybody here know what a Raspberry Pi is? Does anybody want me to explain what a Raspberry Pi is? Hector's got one here to show if you want to have a look. It's a very, very cheap little single-board computer which runs Linux. Not huge spec, but for the price, it's very, very difficult to beat. The big issue that we have in Debian and in all the other distros is that the CPU that Broadcom used to go on the Raspberry Pi or gave to go on the Raspberry Pi doesn't do on V7. It is on V6. If only they'd gone for V7, life would be so much easier, so much better, because we'd be able to use our best highest performance software on it. The fact that it's V6 means we can't. So, Raspbian is an attempt by a couple of Debian guys actually doing an unofficial port using the V6 ABI and the hard float version, which is forwards-compatible with what we're doing with ARM HF so you can happily run any of their binaries on a V7 board. No problem. It's awesome community work. We're not going to make it an official Debian port. If I even suggested that we were, the FTP masters would probably come and murder me. It's a quiet shame. There's going to be lots of these machines out there, but it's just too targeted. It's too focused on one particular computer, which, to be honest, in maybe two years' time, will be replaced by V7 stuff anyway. It's not worth our time doing it. Having said that, of course, we're going to give help and advice to these guys as much as they need, because they've done some very good work. Ubuntu have an Army L port that used to be V7 soft float, because that was what they were targeting for a number of reasons and I don't pretend to know them all. Since we've now done RMHF in Debian and Ubuntu, frankly, keeping a V7 soft float is utterly pointless. Ubuntu have quietly, until I started talking about it loudly today, started doing a soft float, a V5 rebuild of Army L. Given time and uploads, eventually it will all fall back, which then means, of course, Ubuntu then have software that works on the pie just like we do. RMHF in Ubuntu was the first ARM long-term stable release, which just happened in April, so there's been quite a lot of publicity about the fact that Ubuntu are now supporting ARM for the long-term, which is really good. Sousa had never really got involved with ARM until quite recently, there'd been some very small amounts of unofficial work, but as we started talking about V7 hard float, I think it peaked some interest, and they've started alongside too. They are working very much on V7, as though they're going to have it as a primary architecture soon. They also have a lower priority V5 port, which, again, is for all of those old guru plugs, dream plugs, whatever, that still need V5, but there is not necessarily going to be any major official work for it. If people are interested, they can help out, I'm told. What Sousa are hoping for is an official 12.2 ARM release. In fact, there's a guy from OpenSousa just started working in ARM, who, in fact, helped to tell me about all this. He wanted to give me several slides worth, but I wasn't that interested. Finally, Fedora. Again, they're focusing on a V7 hard float port. They have just released Fedora 17. Again, they're doing a lower priority V5 port, which is best effort, and, frankly, they're probably not going to keep round for very long. Going back to what I mentioned earlier about the linker path, this is where we have problems. We've had some major discussions between the distro folks in the ARM community multiple times over the last couple of years. We thought we had agreement over what the description of V7 hard float was, and then, apparently, other people thought otherwise. We had agreed, in theory, a standard triplet, to describe V7 hard float, because it's important that we have a standard triplet if we're going to be sending patches upstream for various software packages. Again, people disagreed with that. Fine, we can live with it. They're just going to have to deal with their own patches. The biggest problem, as I mentioned earlier, was the linker path. We had defined in an agreed phone call between all of the distros and the upstream ARM people, upstream G-Libsy people, upstream GCC folks, and we'd all got together on a conference call arranged a fairly short notice to say, we must have a single standard linker path, and everyone said yes, and then Fedora didn't actually implement what we agreed. I'm still quite bitter about this. You may pick up on this. What I will say is, basically, Fedora 17 claims to have ARM. Please, for the love of God, don't use it. If you do use it, I mean, to be honest, I'm talking to the wrong crowd anyway for people who are likely to use it, let's be honest. If you are tempted to use it, be very, very careful. Anything you build there will break as soon as you try and run it on any other distro. All of the other distros worked on this and got everything right, so we have compatible binaries across all the distros. This is useful in the point where we're expecting that we're going to get proprietary software. We're going to want to all be able to run it. Don't do Fedora. So, even further, Majaea have done some ARM work. It's not quite clear exactly where they're up to at the moment. There was some discussion. We weren't very keen on the V7 hard float. We're talking about V5, but we're doing some things that we didn't agree with. Gentoo, of course, have done ARM stuff for ages, but it doesn't really matter too much. They've gone for a hard float linker path, like everybody else, but it actually doesn't really matter. You don't expect to be able to run pre-built binaries on Gentoo. If you are, why are you using Gentoo? The Chrome OS folks have, literally in the last few weeks, switched over to using hard float by default. Again, they were convinced by the fact everybody else has gone this way. It's silly not to. Finally, Android. Probably at the moment, maybe the most common single OS running on ARM. Again, the Android people are mostly doing hard float at this point. Whatever extra performance they can get out on anything they do, they'll take for free. New stuff. Paravoid, Mike? Hang on, hang on. What about Red Hat and the Pride Alliance? Red Hat are going to end up doing it more than likely doing an ARM release. Part of the point of Fedor were getting involved in ARM is Red Hat are interested. I have spoken to multiple Red Hat people who are convinced that Red Hat will do an ARM release, maybe with the next release of Well, maybe not. Fedora are currently going through some very difficult discussions to work out whether or not ARM should be considered a primary architecture in Fedora. Until that has happened, I can't see Red Hat ever releasing on ARM. If they're not going to be supported fully in Fedora, it's clearly not going to happen in Red Hat. The latest versions of hardware that is available real soon now, in fact I think available to buy right now, at least in dev board form, is we have the Cortex A15, is far on the way the biggest, most powerful version of ARM v7. That is bringing with it some extra virtualisation features. Again, this is considered useful for people wanting to do ARM servers. Even more importantly, probably, is it's also going to do LPAE. It's still fundamentally going to be a 32-bit architecture, but it will have support for the large physical address extension, very similar to what Intel did ages back on I386. You will be able to have an ARM box with 32GB of RAM in, but obviously you're still going to be limited in any single process to your normal 3GB, 4GB memory. The other thing that is being pushed for in the ARM world right now is standard boot architecture. At the moment we have, I wouldn't even know what to hazard a guess exactly how many. There are dozens of different boot loaders for ARM. There are as many different boot configurations and setups as there are ARM renders, and there are hundreds of those. If we want ARM, if we, if ARM in general is going to succeed as an architecture for servers and more general purpose computers, U-boot and all the others just aren't going to cut it. UEFI and Device Tree and maybe even ACPI are all coming to the ARM world, so you can actually get to the point where you will have a standard kernel that should boot everywhere and do the right thing. It's been a long time coming, we're not there yet. We will get the, I hope, I trust. So, we even have even more bigger, faster, newer stuff coming. Envi8 has been announced. You might have noticed on the schedule I have another talk straight after this one. Guess what that is? Please stay if you're interested. So, what else? We are always looking for more porters, always. The Debian ARM team is actually probably the biggest ports team in Debian at this point. I'm not aware of any others that have more. We have lots of interested folks. I can see at least half a dozen folks here who are intimately involved. We hang out and hash Debian ARM. We're on the Debian ARM list. You can talk to us, we're friendly, we don't bite. So, thanks obviously to ARM. ARM is currently employing several Debian developers to do free software. This is really, really nice. It would be even nicer if ARM legal were happy for us to share patches more readily. Leno is a non-profit consortium of ARM and a number of its partners explicitly working on more free software. Kernel, GCC, and a whole bunch of other stuff. I'm working for ARM, but seconded into Leno, which means I get to do a lot of free software stuff on work time, and that's really cool. And obviously, thanks to everyone who's worked on this stuff. There's loads of people out there. Thank you, everyone. So, bloody hell. I've been spouting at you guys for most of half an hour, which is really not what I planned. Talk at me, tell me. What have I done wrong? What should we be doing next? Is there anything people would like me to answer questions about? Is anyone alive? Can you say anything about Graphics Acceleration? Yes, it's lovely when it works. And food drivers. In the ARM world, Graphics Acceleration is a touchy subject, as you well know. Although we're starting to see things improving, well, they're happening much more so in the x86 world, where there are a smallish number of vendors, and most of them are starting to open up. AMD are giving specs out for what used to be ATI cards. They're working with things. Intel typically are giving out enough specs and are even employing free software people to work on their drivers. Nvidia aren't. In fact, Nvidia have a whole bunch of good free software developers working for them doing Linux kernel patches and stuff, but Nvidia see their graphics hardware as their crown jewels. We may be waiting a long time for them to ever open up. In the ARM world, things are less good, and I wish I knew a good reason why. Again, most of the players see their special sources so special that they can't share it with anyone. ARM itself has the Mali graphics hardware. A number of us inside ARM have been pestering to say, look, why can't we just open this up? It's not happened yet. There's stuff from Qualcomm, the stuff from Budcom, IMG obviously are one of the most common with the PowerVR and the SGX stuff that's out there already. We're working on it. There are people with us engineering these things, but you're going to need binary blobs essentially forever, and I wish it was otherwise. It's all patent incumbents, and they're all scared of each other. In fact, not so much scared of each other as scared of the trolls, who the moment that they see any source code for anything will make it that much easier for them to tie people up in court. Lawyers, I wish we didn't need them. I have here Hercules Icafie, and this is ARM V7, and I want to know if you try to put Damian on it, and if you know someone, it's playing with this, so I would like to have contact. Which laptop exactly? Icafie, Hercules Icafie. I honestly don't know. I've never heard... Is it an Afika? Is it Genesi? No, it's some of the strange box. It says cafe on the back. Cafe, okay. Somebody type it into Google. Yeah, that's the best thing. Put details into Google. Again, the problem is with lots of these things, there's such a long history of so many varied bits of ARM hardware out there, but absolutely the core stuff on the machine will just work, but you need to be able to get to that core hardware. Actually finding out how to put Linux on something and put Debian on it should not be hard, but it's often harder than it should be. Take the microphone back with you. So I have good luck because this device has a hardware switch, it's dual bootable, so you can choose it's booting from the built-in flash or from the SD card. So I already put Debian on it. Oh, awesome. Yeah, well, but not properly, so it's still Wi-Fi not working and some stuff, but I would like to get in contact with someone playing with this, but I don't know. Talk to me and some of the other ARM guys afterwards. Definitely come on to the RC channel and talk about it. I mean, whatever information we can find, it's great to get these things working. In fact, Hector seems interested. Just Constantinos on IRC, you see the Erculeci cafe has an IMX5. It should be similar to the Genesi one, to the Efica, which is supported in Debian. So it should work. It's similar to the Efica. To the Efica. Okay, cool. All right, and again in the middle. So we've had three official ports now, and one an official RMEV, and you're planning another port now for RMEV8. Yes. And it seems to me that you're doing a lot of work, but I wonder if this will keep going forever replacing ports with newer? I'm hoping not. We have good justifications for the ones we have already. We're already limiting. We're not going to take on the ARM V6 hard float. It's common across all the distros now that they're doing the V5 port soft float, the V7 port hard float, basically so they cover the two dominant groups of users. V5, we're still going to want for all those people who are running the freedom boxes, the shiva plug, the guru plug, the dream plug, a lot of the other old machines, they're going to want support on V5 for a very long time. We're not going to do anything about that. The V7 hard float is very, very much what's needed if we want to get good performance out of current and forthcoming ARM hardware in 32-bit. The 64-bit ARM port that we're going to be wanting to do for ARM V8 hopefully will stay around for quite a long time and we're not going to need a replacement for that. Touchwood, I don't know for definite, but we're not planning one. So yes, being greedy, we're going to want three ports in the archive. We'll support them well, it's fine. So the point is that ARM spent 20 years being an embedded provider where the idea was hardware and you built all your software for it and they're only just slowly getting out of that mindset into a world where it's like real computers and the software comes from big archives out on the internet and needs to be compatible between different machines. So it's taken a long time to get to a world where they kind of realised they need to make stuff that expects to get standard software in standard formats with standard ABIs that aren't going to change every three years. And I think we are now at that point. We shouldn't change again every three years. We should get at least a decade before we have to change it again, I hope. Yeah. Right. Anything else? I guess not. Well, thank you all for coming. I said if you're more interested more in ARM V8, the new future 64-bit world, I'll see you again in about 20 minutes. Thank you.