 Hi, my name's Karsten. Some people may have heard of me before. You may not. I work at ARM. ARM are these people who design CPUs. We also design GPUs. And we're basically everywhere. So I live in the UK. I actually recently moved there about six months ago. And I'm in Cambridge, so no one else from Cambridge? No, okay. So I'm going to talk about ARM dev boards. I've been using these for a long time. The first one I had was a Bigel board. This was back in 2008, I think. That was really cool. And that opened my eyes up to a lot of what these newer ARM chips could actually really do. They no longer just power a phone. You could power entire proper screens at decent resolutions and getting quite fast. Unfortunately, that board died after my cat decided to sleep on it and drool. And I learned the lesson, never get a board without a case. So my hint first, you get these in? Get a case. Yes, it costs more. Save it. Your cat will destroy it. So I'm going to talk about these things. I've got some of my newer ones here. One of them's on the blink. It's not doing too well at the moment. It's one of my oldest ones. So let's get on with that. There we go. So I'm Carsten. Some people know me as Rasta, a Rastaman. I have been doing open source for more than 20 years now. More than 20 years. 23. I don't know. I lost count. Somewhere along the way. I am a director at ARM. So to some extent, I'm actually allowed to tell you things if I feel like it. I may not feel like it. I have lived in many countries around the world. I was actually born in Nigeria, as you can tell. I'm totally African. I've also lived in Australia, Japan, Taiwan, South Korea, and I'm now in the UK. I have written a fair amount of open source software. Currently, the main projects which I work on, Enlightenment EFL, Enlightenment is about, I don't know, 300,000 odd lines of code. And EFL is like 1.3 million. So they're fairly big exercises in C. I've also written video players. I wrote a terminal emulator, terminology. It's about 20,000 lines of code. Decided to do that on a holiday in Thailand. That's what holidays in Thailand are for, writing terminal emulators. I have worked on GTK before. I worked on Tizen. I worked at Samsung for 10 years. And basically, pretty much every smart TV they've shipped since, what, 2015? All their watches, actually a bunch of phones in India, I think Indonesia too and other places. Washing machines, fridges. I lost count. Either way, I think about two odd years ago, the count was 130 million devices shipped that. And I wrote the software stack for basically the whole graphics thing, the winter manager compositor, UI toolkit, rendering layers, blah, blah, blah, all that kind of thing. So I've done a bit of this stuff. I've got a little bit of experience in building devices at big scale. Before this, I worked at OpenMoCo. We were one of the first people to release a Linux phone. In fact, we've released the first Linux phone that actually ran a proper Linux stack. It was open embedded, had bash, like a busy box, you could add bash. It ran X, et cetera, et cetera. So that was small scale. That was about 10K. We actually did a 10K unit run. So I've done it at a small end, and that's where I know about problems of sourcing and those things back then. And I know on the large end as well. So I've done a fair bit here. And I've found these ARM boards to be very, very useful for many things. So I'm going to talk a bit about this when I get there. So first of all, some people get very confused about who ARM is. ARM is not another Intel. We are not the same. We are very, very fundamentally different. We are massively smaller. We have massively less revenue because we are, for all intents and purposes, the best description I have is imagine you took the design and a bit of the support department of someone like Intel, the engineering department, and you put them in a separate company. That's basically who we are. So there is that restricts us in certain ways we can work and what we can do. Often we can't answer questions because, like, we didn't make it. We just sold them a design and then they're modified and add other things and ask them. So we don't do everything. We do a small subset. So our partners, for example, Qualcomm, Apple, Samsung, LG, Huawei, Rockchip, Allwinner, AMLogic, and there's a whole bunch more. They actually make the chips. They also add a whole bunch of IP into it. Other cores and bits of circuitry and things that do other stuff. And sometimes they don't use everything we have. They only use one or two things and they add a lot of their own. So that's why you almost always have to talk to them because they're the ones who are making the chip. We just didn't put on Twitter. What ARM really is, is we create the designs. We also define the instruction set architecture. And there is a big document. It's called the ARM ARM. The ARM architecture reference manual. So wonderful. We double-arm it. And we currently do chips. Well, we actually we have a 16-bit instruction set but with a 32-bit address space. But mostly it's 32-bit, which is the old stuff now. And the new stuff, which is all 64-bit, Arch64. That's where we actually got to do some really clean, neat stuff. So what on earth is that doing there? Go away. So the 64-bit instructions are new stuff. Believe it or not, we actually have microcontrollers coming up that use a 64-bit instruction set and 64-bit memory address space. So we have some Cortex-M things that do that. Yes, it sounds insane, but we're there. It is a bit cleaner and nicer if you do that, though. We also happen to design GPUs. Please don't ask me questions about our GPUs, please. Please. That's a topic all on its own. And just remember that the chips do use lots of other components that are not from us. They may not even use our GPUs. But they may use other components we do, and most of it's invisible, except for pretty much the CPU, sometimes the GPU, ignoring that. And the fact that there is good compiler support, that there is good other binutils and other support is these days largely due to the fact that we work on it. So we, in fact, work on it to the point where we announce a new feature. The feature will be coming out in silicon, maybe in one to three years' time. And the patch goes into that. So we're relatively ahead of the curve these days in providing support. So you get to see things coming before they actually come. So most of the same between ARM CPUs is in fact that they're very, very low power, given the kind of performance you get. We scale all the way down to small microcontrollers, which I'm kind of ignoring here. Other talks here are covering a lot of that kind of space. I'm moving next level up. So we kind of, the M, Cortex-M things are the embedded space like microcontrollers, and the A level processors are the more powerful ones. So I'll be talking about those. And the interesting thing where people really began to discover how good the design was in terms of power consumption, the very first ARM chip worked and they didn't connect the power. They literally had it not connected, they forgot about it. And it worked, but it was working through leakage from the debug circuitry. So that was actually pretty impressive. And so it's one of the reasons why people like to use ARM, because you have a battery, power consumption matters. It really matters. So not only that, we don't, so if you buy a chip from Intel or AMD, or the big names you know, you get that chip, you get everything with it to that. We don't do that. We license the intellectual property and then someone can make a chip, a custom chip that does all sorts of weird things, and they don't have to go design a CPU themselves. Some of our customers have actually done this. They built their own CPUs. They did their own instruction sets and even did their own binutils and GCC and other support. And the one that some might have heard of, swear off ever doing it again, because it cost them so much engineering time and effort and the performance was actually much lower than they could get. So that's why they come to us. Unfortunately, that is not open source. There are good business reasons for that, because if we did make it open source, we wouldn't exist as the company in the ecosystem would not exist. Of course, the kinds of customers we have are big enough. They will just take it and build it themselves. It's a different area. If the average person here was a chip designer who could stab chips, it will be different, because the barrier of entry is very low. The thing is the barrier of entry to build chips is chips that are modern and competitive with other things out there at that same level is tens or hundreds of millions or billions of dollars to do a chip run. And most people don't have it. So that's our customer base for that. It's different. But a lot of the users of this architecture are open source. In fact, we pretty much exist because of open source. So it's very important to us. Now, our customers like this because they can go and take just one piece and do everything else they want. They can build the things they care about. Things are important to them. And then just have a controlling unit attached to it. It makes their lives really easy. And they generally tend to have much lower costs as a result of this. So they're all really happy about that. So one of the boards everyone knows about, Raspberry Pi. Who has not heard about the Raspberry Pi? Oh, shut up, Hamish. Okay. You've all heard about that. The latest one is Raspberry Pi 3 or Raspberry Pi 3B Plus, I think now. The one I have, which is a bit old Raspberry Pi 3 is it's not a bad device. Not exactly fast, but it's not bad. You get like a quad core 1.2 gigahertz. It is A53. Now a lot of people get mystified by this A53, A71, A9, A11, A15, A7. Trust me, I do too. No one really totally understands it properly. But the A53 is a relatively old core, which means the number of instructions per CPU cycle is not as high as the new one. So the A72 is nearest to A73 will get a fair more instruction per clock. So it's an oldest slower design. But still not bad. It's fairly decent. So you get that you get now Bluetooth and Wi-Fi on board with the Raspberry Pi 3s, et cetera, et cetera, a bunch of GPIOs, you get an ethernet port that claims to be gigabit theoretically, but it's hooked up by USB 2. So that was a really great idea. But no, you won't get gigabit out of it. But it's better than 100 megabit. So you might get 200, maybe 300 megabit. So, but all of it, not bad for 35 bucks. Oh, that's US dollars. Sorry, not Singapore dollars. 60? Wow. You can actually get it for less than that outside. I feel sorry for you guys. But it's still the cheapest. The others are going to cost more. This is actually one of the real cheap ones. It's 13 bucks. Now, realistically, when you get down to this level, you can go and get yourself an MCU and a board with a microcontroller on it. It's going to cost you about the same at the end of the day when you get to this level. The question is, do you really want to have incredibly low power and you have no compute requirements? MCU is good. That's exactly what you want. The moment you start having a pretty reasonable amount of compute requirements, you've got to go up. What the hell? Oh, I know what I did. There we go. No, it's no, it's my, I'm using my mouse and my mouse would have gone to the edge of my screen, which was my edge screen flip. So this would be probably one of those boards. There's a few in the same ballpark as this, where you can get and what we call an A class level of processor. So it's reasonable. It can actually, it's kind of maybe a PC from 10 years ago kind of thing. And it can do a fair bit of stuff. And it's only 13 bucks and it's small. That's pretty cool. You could get like something like Raspberry Pi zero five bucks. This is actually not realistic. It's five bucks because they get a lot of components for free. And that is why it's so cheap. But if you want to build something and you don't need a lot of compute, it's also a single core. Compute is okay. It's still on V six, which is not as good as on V seven. There was a big leap from version six of our instruction set to version seven, especially with things like views and neon, et cetera, et cetera, which is the SIMD MMX SSC kind of thing. And this is pretty good. So for five bucks, you can't go wrong if you're trying to build robots or random stuff where you just need a compute thing and not a lot of it. And you want to stuff something in something like that for five bucks. It's pretty good. You can make commercial products in small volumes with this. So yeah, the low end, this is all low power or relatively low power, relatively low compute. You can get a decent number of deployments out of it. And they're generally physically fairly small from credit card size down. So not too bad. Now we can get up to the slightly higher end. At about $500, which is about a PC, you can get one of these babies. One of these babies has in fact, actually, I think that's not gigabit. It's not, it's actually two and a half gigabit and several 10 gigabit ports. They want to do networking stuff. This is the baby. These are SFP things. They're fiber, fiber port things. So if you want to have something really powerful, that's pretty good. And that's a quad-core a 73 that would be drastically more powerful in the Raspberry Pi quad, quad core, and it's clocked much higher. You can stick normal PC RAM into it by dim, put it in DDR4, just stick it in. So I have one of these at my desk at work. It's got 16 gigabytes of memory in it. You just buy a mini ITX case, a normal ATX power supply or whatever comes with that. Plug it in, go ahead and you have one of these devices. The cool thing is you can lock it away in a cabinet and it actually doesn't consume that much power and you could do a lot of network fun stuff with that. That's got some, it's got three SATA ports on it. So you can make a big fat file server out of it, et cetera, et cetera. It's not too bad. And performance is pretty reasonable. In this kind of ballpark, it's probably getting around the same performance as Intel for a similar price. Considering you've got CPU board and all that networking stuff on board, try and get an Ethernet, like a PCI Ethernet card with all those features on it for an Intel box and you probably end up paying more by the time you get the motherboard and CPU and all the other bits and pieces. So that's pretty good. That's something to the high end. We're at the really, really, really, really high end. I've got one of these at my desk tour work. You get 256 cores in it. You will get the one I have has 32 gigabytes, but I know other people have it with like 128, 256, 512 gigabytes of memory, et cetera, et cetera. In fact, one of the top 500 supercomputers is built out of these. They are not bad. They're pretty tough. They have an absolute ridiculous number of PCIe ports and lanes. It is a full-on top-end Xeon-level server chip and it's ARM architecture. But it's the same thing that runs on your phone, architecture-wise, the same software can run, and even below that, even to little small babies that cost that inbox or less or so. It's like, got you with this. Doesn't run through to bit ARM on instruction sets. Only 64 bit. So you can't run the old one to recompile it. So that's pretty good. But generally, the range I'm going to be looking at is the $30 to $100 range approximately, where you can get something that is relatively speedy. So unless you have a very demanding task, you don't have to ever worry about having enough compute or memory, et cetera, et cetera, et cetera. There are low-end PCs which are in fact slower than a lot of these boards and more expensive and use more memory. You can get RAM. Most of the chips at these levels are limited to four gig of memory. It's by design because just adding more memory lanes, like lines literally just cost more money in terms of more transistors, more complexity, or cost more money, more die space to build the thing, et cetera, et cetera. Most of them support some form of fast storage except the Raspberry Pi. It's only got the SD card. Yeah, many of them support EMMC chips. They've got little plug-on ones or even come with one on board. What else? So yeah, oh, and you can get the Pinebook. We're talking about this early just before we started, which is a full laptop with this in. The old Pinebook, which has two gig of RAM and it's going to all win at 64, is $99. It was last time I looked. So for under $100, US dollars outside of Singapore. And there's a new one coming, which is Pinebook Pro, which will be $199. And that'll have an upgraded chip, basically, with four gig of RAM. So it is interesting. And some of them even have PCIe. So my ThunderX server at work has a radio card stuck in it. Like I use it just like a desktop. It literally uses the open source drivers. So for a little bit more than the baseline, you get like the really low end. You get a bit more. And the more you pay, the more you get. So you just have to look around and see what you want. So these are the three boards I'm mostly going to be looking at here. The Raspberry Pi 3, which everyone knows. So it's a baseline which you can be familiar with. The Odroid XU4, which is actually almost pretty much dead. They're kind of finished. In fact, I actually have an Odroid XU3 here, which is the, it's exactly the same chip and everything else. It just has less ports attached. It was a more expensive version of it, which came out before the XU4. And the Rock Pro 64, which is an interesting one. There are an absolute ton of boards coming out right now, which have the RockChip 3399, which is their top level chip. This actually shipped in a bunch of Chromebooks last year and I think a year before too. So this is actually pretty decent. And that one is six cores. You can do up to four gig of RAM. That board actually has four. There's a two gig version available. The S4 is the MMC. The usual Micro SD. The usual GPIOs, as you all know. It'll do 4K. The other two boards above will only do 1080p. So you can do 4K on that. I don't actually run it at 4K. I run it at 1440p at home. And it has a PCIe slot, which I have yet to use actually. But I have used them on other devices. And it's got a Mali GPU, which we will not talk about much. And a whole bunch of IO, lots of USB stuff on it. It's got USB-C and another three USB ports as well. I think one of the USB ports is USB 3, or of course USB-C is USB 3, whatever, 3.1, I don't know. And two USB 2 ports. And it's got Gigabit Ethernet that actually works as Gigabit Ethernet, yay. So in terms of performance, these are some numbers from some of the systems I have. I was using Sysbench here. A simple thing. It just really sees how you see for you guys. And of course, Raspberry Pi 3 is at the bottom there with 93. But interestingly enough, Intel Atom is getting 800 to 74 there. Mind you, the Intel Atom, that's a quad core. And Raspberry Pi 3 is a quad core. So the Intel Atom, that's one of the top end Atoms. In fact, it's the same one Amish as in your little box there that you have in front of you. So it gets about 874. And of course, you've got the higher-end Intel's and i7, 850, i8 by 50, and a 770K, which is the desktop. And of course, they do better. You start looking at the boards. The Odroid XU4, yeah, it's a lot faster than the Raspberry Pi 3. Interestingly enough, the CPU on that is older, much older design. It's an A7 plus A15. But it has eight cores instead of four. So it's got four A15 for A7. The Odroid is using a Samsung Exynos chip. And one of the reasons it's faster is Samsung simply just does a better job of integrating it with memory bus and everything else. If you didn't know, the Raspberry Pi 3's Broadcom chip was not designed to be a chip to go and put into products or even phones or anything like that. It was a test chip. It started life as a test chip for their GPU. So it has had a lot less effort put into it. That's one of the reasons why it doesn't perform as well. And the Rock Pro 64 is actually, that's actually a head of, like, the highest-end ATOM Intel chip is by now in terms of our CPU growth. And of course, the Thunder X2 is the head of all curve. Of course, it's a full workstation thing. But the range of performance can vary quite wildly depending on what you pick. So of course, the less you pay, the less you get. The more you pay, the more you get. Go pick. But they are getting comparable to Intel systems, low- to mid-range Intel systems. They're about the same. And you don't pay that much if you get a boardwalk. So, okay, we'll just get into that. So they're about the same ballpark as low- to mid-range Intel systems. So if you can do what you do on maybe a laptop that's a year or two old or three old, if it's not a top-of-line thing, like a mid-range thing, you'd probably get that out of the boards these days. So, yeah, the server chip is much further ahead. One thing you need to remember about this tend to be heavier in core count, traditionally. Asterix, Intel have finally started changing their ways and adding a lot more cores these days. That's a new trend for them. But if you're going to write any code, definitely consider making it heavily multi-threaded because that's the way you're going to get the most performance out of it. And the thing that the 256 cores of my Thunder X2 is the kind of thing that makes you reconsider this very heavily. You go, oh, 256, how am I going to use that? You start wondering. It's very hard. Some of these actually you can use as a full desktop. They are fast enough for day-to-day use. So the Rock Pro 64 probably could be used as a desktop. The others are really low-end, minimal ones. It definitely can work. And you can drive 4K streams, as I said before. You can run all the normal debug tools. You can use Valgrind if you're doing native stuff. Python, it doesn't matter. GDB, compile, and everything runs. So treat it just like any other machine. So, yeah, you can use these for pretty much anything in life. Anything from a workstation, a server, small server running your home through to running some little project of yours, robots or whatever. They run regular links distributions. So as long as you're happy with Linux, you're good. If you want free BSD or something like that, you might have a much more limited choice. I didn't even bother looking because it's really that limited. So I wouldn't be surprised that there is a free BSD for the Raspberry Pi by now. But, yeah, all the regular stuff is there. You want to add software to it? Cocoa. Apps get installed. Or Pac-Man might assess whatever. Yum. No, yum is being replaced by something else now, whatever it is. DNF, that was it. That keeps changing all the time. Can't keep up. So, you do compile stuff on these devices for them. It's really, really easy. Just be aware. There are certain projects. So if you sit there and go, yeah, let's run Gen 2 on this. Let me build a workstation out of it. That will eventually at some point go, oh, let me build webkit slash Chrome before then fail. Of course, at best, you probably only have four gigabytes of memory on your board. And these things need a lot more than four gigabytes just to link something. Be very, very careful. The one you really run into, even if it's a normal project that can compile, is you have four or six or eight cores, and it goes, especially if you do make minus J8, or you use Ninja. So using MISON, where Ninja auto looks at the number of cores you have and does that parallel. The problem with that is, then it uses that much more memory. So it's end time. So if eight cores is eight times as much memory to do the same compile, theoretically eight times as fast. But that's when you run out of RAM. So be careful about that. You can force it to use less cores. So if your builds mysteriously fail and the middle just goes, build failed with no error message at all, it's probably because of that. Or you can use the higher end devices where you can stick much more memory on to do that as well. Oh, what are we going? That was backwards. There we go. So in terms of OS support, the Raspberry Pi is by far the best. He gets five bull stars. That's very well. The Odroid, because it's relatively old, like the Raspberry Pi as well. But it was quite popular, as it was one of the much more powerful boards at the time. It actually has pretty good support. And the Rock Pro 64 is not as good these days as the others. It's also much newer. But it does have a reasonable number. So there's Debian other. There's at least Debian. There was, I think, an Ubuntu. Almost the same thing. The Archive guys are working on something, working on a port at the moment. And there's a few others. But there's a list on the page if you google for it. So it's pretty good. In terms of hardware support, that means all of the hardware, the drivers are there and everything works. The Raspberry Pi is generally straight ahead of everyone. Everything works. The GPU works. Because they finally made it work. They didn't actually really release specs on how to power the GPU. That's what really happens is you have four CPU cores in the Raspberry Pi. You have another ARM core sitting next to the GPU, which you never see in Yukon Access. And that's running a bunch of firmware, which is then driving the GPU on that side. So really it's your four ARM core thing that runs your Linux system, talking IPC-ing over to another ARM core, which controls the GPU cluster over there. So from the point of view of Linux and user space in the kernel space there, it looks like you're driving a GPU. But you're actually not. You're just driving another machine over there, which actually doesn't. But it works. And it works reasonably well. The Odroid is not as good. A lot of hardware does work. But the GPU does not, unless you get the binary drivers. And I'll come over this more. Or you start looking at Panfrost. Panfrost is the new reverse engineered driver for Mali things above the 400. So the 600, 700, 800 range. They're called Midgard. And then beyond that's actually Bifrost. Yes, we have all these weird code names of GPUs, don't ask. They come from Norse mythology. And that's reverse engineering. And it's not ready for primetime yet. But it is beginning to work. So in future, there may actually be open source driver support for that. And the ROC64 is actually not dissimilar to the Odroid in this regard. The GPU also, you need binary blobs. ROC chip have released some. The Odroid hard kernel people have released some binary blobs, too. But it limits you in your kernel upgrades. And it kind of makes your system a bit of a mess to make sure they're there and work. But most of the other IOs, so network, EMMC, blah, blah, blah, a lot of that actually does work. So they're pretty good. So depending how much of the peripherals you want working and how much performance you want, figure it out. So the question that we get asked a lot is about GPUs. And that's why I don't want to talk about it earlier, because I just want to cover it here. We licensed the GPU to this SOC vendor. And the SOC vendor actually then needs the software support from us, which we also licensed to them. They actually may make changes to it. And it's the SOC vendor's job to release those drivers, not us. They have to do it. As if the SOC vendor, the person who makes the CPU, the chip on there, doesn't do that, then we can't go release drivers for you. They have to do it, because it has to integrate to bits of their SOC. Yes, they're closed drivers. That's primarily a result of history, because that's just how it is. And the fact that 99.999999999999999999999999999999999% of our customer base are happy with binary drivers. I basically phones, tablets, etc. etc. They're not screaming for something different. So that's why we do it. But some SOC vendors will actually use different GPUs. So the Raspberry Pi uses a different one. There are SOCs like the IMX uses a Vivante GPU, and there are reverse engineered drivers for that now that work pretty well, the EtnaViv things. There used to be ones with image tech GPUs. There are basically no drivers for those, effectively. Unless it's already on Android somewhere. That's all you'll get, so you'll have to use that. There's also the Qualcomm things. They build their own GPU themselves. It's Snapdragon. On the Snapdragon it's the Adreno GPU, and there are, in fact, open source drivers, FreeDreno that work on that. And in fact, actually the latest Pixel 3 phones are using the kernel portions of the open source driver, not the proprietary stuff. So products actually ship with it. So it's getting to the point where they're comfortable with it enough to do that. Yep, so I think it covered all of that. Now, for GPU performance, this is measuring the binary blobs in this case, because antfrost isn't really measurable yet with GLMark, because it fails and doesn't do things correctly. The performance here is not quite as good as your decent graphics card. Admittedly, I'm comparing that to, at least on the ThunderX, that's a discrete card, and on the i7-Z, that's a discrete card there. But even the Intel graphics on the i7-850, that's embedded, does actually pretty well. At least in GLMark performance. This isn't necessarily game performance, which might be much more complicated. GLMark's pretty simple. But the GPU is not bad for day-to-day stuff. You can run a desktop and do all those things, and simple games can work. So it's not too bad. So how to do development. The normal way is set up a cross-compile environment. You were talking about this in many ways. You have to install the SDK cross-compile thing, and then you go and flash it and get it across there, use your PC, then go use a special ID they give you, Android Studio, Xcode, blah, blah, blah, et cetera, et cetera. And some of the IDs hide this for you. They do all the bits and pieces and the offerings and the other in. That's the standard workflow. Don't do that. That's just wasted your time. It takes much more time to do it that way than just use it as if it's another PC. Install all your development tools on it, just install all your compiles on it, install your debug tools on it, app to get installed or whatever you want to use. You can share files with the PC you have. NFS is a good thing. I actually end up using Async. So what I do if I start doing some stuff on a board, I Async everything to the board. Now I work there, when I'm done, I Async it back. So I have my results. Async is an awesome tool. Look at it, learn it. There are other file systems network share things you can use. I'm covering really big, fat common ones here. Yeah, Tridge. Tridge, good. Andrew Trigel made Async. He's a good man. So Async is really awesome. If you're not using it, use it. It's a great way also if you have multiple laptops, multiple PCs, desktop, go to work, come back. You just send all your work to and from everything you do, just Async it all and it just follows you wherever you go. And you can disconnect from the network, sit on a plane and still work. You don't need it. That's the awesome bit about it. So treat the dev board the same way. Compile on the dev board, arm it'll produce you. Native arm buyers run them. It's just as if it's an Intel machine. It just happens to be a different architecture at all. The faster boards are not that dissimilar to slower PCs to compile, build, run, debug, et cetera, et cetera. So it's pretty good. But be careful of C++. C++ is bad for one reason. It tends to use a lot of memory compiling and the make minus J thing becomes really, really bad with C++ stuff. So you might have to be careful of that. That's all. Just remember that. And there are standard things and print if debugging still works. As we all know, our favorite form of debugging. So the point, just treat it like a regular thing. Do a regular box. Do a box. So why use them? They're cheap. They're small. From credit card size up to slightly bigger or maybe even smaller. They've got relatively good IO. A lot of them have really good IO. So from SATA ports through to a lot of USB, et cetera, et cetera. They tend to use a fairly low amount of power, but in one to 10 watts, at least these boards I'm talking about, a set of three here. And it's just lots of fun to play with. They're really good for prototyping. I was actually having a discussion last night where some people were thinking about doing custom hardware. And one way of doing this, instead of going making your hardware first to see if it works, is go buy a board for less than 100 bucks with everything included. All of the bits and pieces and peripherals and case and so on. And then you can actually see does what you want to do perform reasonably well on that class of chip or literally on that SOC. Some people have actually been doing things like using Raspberry Pis in their products. They literally sell products with a Raspberry Pi in it. And they just add something around it. Add let's say a door to board, like something attached to the GPIOs or even just to the USB stick in a plastic box and sell that with the software pre-done. So you can use it for like building small run products or kind of cool and prototype products where you might actually make several hundred or several thousand, but it's not full in production yet. They're great for media centers. People do this all the time. They run Kodi, Raspberry Pis, and the higher end things will do it all at 4K. They'll work pretty well. Sometimes the video decode end code but mostly decode units may or may not be supported very well. On the Rock Pro 64, they're not supported very well. As I discovered about three frames a second. The CPU can decode at about 30. The hardware does three. Someone's done something wrong and I have to figure out what it is. You can use them as workstations, NAS boxes, you stick in a cupboard and never have to know about a care again. So that's what a lot of people use it for. So, oh yes, oh wait. So we'll do Q&A in a bit. I happened to brought three of my boards here. I'm gonna just go and have a look at one. I plugged in it a little bit earlier. Nope. So what I've done here is I have actually, no, that's me. You don't wanna look at me. You want to look at this. So what we have here is we actually have a board I booted a bit earlier. That's good. And all it is, it just looks like your average PC. This is the Rock Pro 64. So, yes I did. There we go. And you just get your regular prompt. So everything works as normal. My favorite test is to just run a desk, run a compositor, their Wayland thing. Since getting a desktop to work is kind of nice. You just run it and Presto, that is it happily running a regular desktop. That's a Wayland one in this case. And it does all work as normal. So, wow, this cloth is not good. There we go. So all the regular things work. Whoops. What's that? Oh, wait, wait, why am I looking up there? I can look at my screen here because it's mirroring by default. Whoops, oh, wait, no. And the usual stuff works. By the way, I'm looking at this using a HDMI capture USB thing on my PC and hint, they're insanely useful because having a monitor and having to switch inputs all the time really, really sucks. They're slow and yeah, it's just a pain. So, get yourself one of these if you're gonna use these boards because then you can go and look at a board in a window and just use one of your normal video viewing things. Let me change font to something much bigger. I don't know, that'll do. Oh, oh, look at that. The drivers are broken. I don't know, there we go. There we go, now you guys should be able to see that. What? Alrighty, then it's like crashed actually. So there, everything working and that's actually using the proprietary drivers. I think it may have crashed because we use the proprietary of the OpenGL to render the actual terminal itself. So, that's why. But anyway, it all works. The other boards work basically the same. You put them up, you can get a prompt, you can have a boot straight in X if you want, you can have a boot into something else. They all pretty much look exactly the same in this regard. So, yeah, they work. So anyway, questions now, at the back. So the question was, are people using these dev boards if they're targeting the ARM cloud instances? I do not know because ARM cloud stuff is so new. Okay, I will roll that back. Scaleway, which is a French cloud outfit have been offering ARM VMs for two, three years now for several years. No one knows about them, never goes in the press, no one knows. The moment Amazon do it, it's like, ah! So, it's so new, no one's really doing it. I don't know of people doing it at the moment. But it is actually a valid way of doing this. If you run a 64-bit distribution on this, it will be the same as the things in the cloud. It might be a bit slower because Amazon has specifically designed their own chips themselves. They bought a company that was designing stuff and they built them themselves, they fabbed their own chips because they have the money to do it. And that makes it very, very cheap for them compared to buying Intel or AMD hardware. So, yes, more, yeah, oh, next. So, at the same month, so you can skip through if you want, we can take it up a hundred notes at the time. So, the first one is, is there any ways that you didn't recommend it, like in Beaglevo or iBix computer? Number two is downloading new software from package, but it is good, but only when someone has packaged something for you. So, if not, then maybe like a compiling security or an ARM-based board should be quite a tight-knit, a tight-knit source can be cross-compilational, I think. So, how long do you think we will be there that we can do entire, say, your pro and entire build route on the ARM? And number three is, for a very long time, there has always been Intel versus ARM. Do you think it's time it should be ARM versus RISC-5? The last one we're not going to talk about. You're not allowed to skip that one. The first one, oh, I'll tell you, oh, you lost something. Okay, the first one, what was the first one again? That was simple. Oh, no, of course, I simply don't have any of those boards to show you, I just don't have them, I have no personal experience with them, can't say, so I'm neutral on that. The middle one, I have run various distributions on my boards, I've never had to compile something for a package, it's already pre-compiled pre-packaged. Debian unstable maintain an exact copy of the Intel unstable, they recompile it for ARM, and it's just there, when they update something, the Intel, it's updated for ARM too, it gets rebuilt. So everything is there, everything's up to date, you don't have to do these things. Now, in principle, could you compile something like Qt? I bet you could, I haven't personally tried, it is C++, they thought it was going to use a lot more. I actually compile EFL, and on something like the RockPro 64 here, with four gig of RAM, I never run out of RAM, I can use all the cores, and it takes, I think about 15, 20 minutes, and it's compiled all of it. I don't have to recompile a system from scratch, if I had to recompile a system from scratch, like open embedded, I would generally argue, you're doing something really weird or wrong, but you don't generally have to go rebuild everything yourself, because it's already pre-built. So it's a rare day, you have to do that. If you did, there are lots of higher end ARM systems like a PC, a higher end thing, you can get to do the same in native compile as well. Or you can do the cross compile, you can do that too, it's just a bit more painful. So yes, we have a question over here. Oh, neural nets, okay, I do not know about that, I know that we are doing a neural net processor, an NPU thing at ARM, we have a specific thing for that, we have a whole group of people who are continuously optimizing algorithms and things for that plus CPU, plus GPU, I do not know any of the details, I'm sorry, it's not a field which is my thing, I do know it exists. Does the ARM architecture suffer from the same spectrum of execution attacks that x86 does? Newer ones do, older ones don't. So if you get one of the older, not out of order things, it doesn't suffer from it at all. I can't remember now exactly which thing it was, it may have been A53 doesn't suffer or earlier, but it also partly might depend on the SOC maker. So Qualcomm in the past sometimes licensed our RTL, the design of the actual circuitry inside the chip, other times they designed their own and they just licensed the ISA, the ISA itself doesn't have this built in, it's the implementation that's the problem. And so some of our new implementations actually does do have the problem and I'll happily admit, for us it was like a shock of like, oh my God, no one even thought about this and no one did, Intel didn't, no one thought this was the thing and everyone got a shock out of it and all was going, well, we're never making that mistake again and we literally, no one is going to do it, they're going to be really careful about anything that is not basically straightforward, anything that's tricky, like speculative execution or anything like that, we're being very, very careful about. In fact, we're really, really obsessed by security these days. We've been adding features to our chip, so P-auth is a new one for authenticating pointers built into hardware. The idea is to stop buffer overflows on the stack so we authenticate the return pointer, the compiler just automatically does this for you, you build for it and it means you basically can't do the buffer overflows on the stack and have it jump somewhere else anymore. It, okay, you could, there are a certain number of bits of basically hashing of that thing. You theoretically could but it'll be incredibly hard to do because they'll be based on address and stake in memory. We are actually adding new stuff as well that makes it even more paranoid when it comes to checking on memory. You'll hear about them in the future. Unfortunately, it'll be a couple of years away before they hit silicon, but we do take security in these things very seriously, especially these days. So we think about it. So we hope that we don't make the same mistakes again. Yes. The ESOCs that have the technical architecture have been found in making poor scheduling decisions with where to place responses or is it always worth? Yes, I have. Especially on my Thunder X2, it's made very poor scheduling decisions to the point where my desktop really frees for half a second at a time. Like, if I do a compile and a compile and hammer all my 256 cores with a compiler, yes, things get slower. The kernel is doing bad things, but is the big but. I noticed recently on even my i7 with eight cores, it's doing the same thing. It's beginning to look really bad in scheduling. Yeah, I'm actually, I agree. Do you concur that there should be a framework that allows us to, in the kernel, specify there should be a low-energy process or like a high-group of tasks? C-groups. Every time that question comes up, the answer is always C-groups. Then you can do it and you can have a C-group which literally pin. So even Intel now is doing a big, little thing. They literally have recently announced they're gonna be releasing a big Intel core with a little atom thing built into it. I don't know how many. After years of saying ARM is bad, this is horrible, you don't do that, they're not copying us. And it's a rare day which is like, wait, we're ahead, they're copying us now? Yes! So they're doing that and they will need, in fact, interestingly enough, they now are using the infrastructure we put in for power management and support into the kernel for ARM for their thing. So we're actually converging to be in the same space, which is actually good. Then we won't be fighting with each other, we're actually working with each other to achieve the same goal of better power management, running on the right core at the right time, et cetera, et cetera. Yes? It's not a question just to add to the slide that you mentioned. Anyone who goes home and wants to try out any, like doing that, so storage solutions, don't do a Raspberry Pi if you can find a Rockchip-based device that's much better. I have learned that the hardware last years, for example, as a speaker for a spreadsheet, like that other Rockchip is a IO pretty well. Yep. Yeah. You're right because the IO would be by USB then, and it's only USB two on the Raspberry Pi, and that bandwidth is shared between the network and the disk. So you end up having pretty bad results. So yes, the Raspberry Pi is in the low end, but it's cheap. So you get what you pay for. Yes. Okay, I use the Rockchip-based 64, but what I did is I took their Debian, their Debian seven dot whatever stretch thing, and I just changed the app, whatever source things to go to unstable, just at get disk upgrade and done, and now I'm in latest and greatest. So that's all it was needed. It didn't come as an image already. I had to go and swizzle the app stuff to point instead of to what they had set up to testing, but Presto, it just worked. Yeah. Sorry that I'm... Oh, thank you. Yep, we are already five minutes over time. Let's thank the speaker and complete the discussion. Thank you.