 Hi, my name is Vitale Wol. Hi there, Seattle from Sweden, Malmo City, and today I'm going to be delivering a talk about how to build a low-key RISC-5 system that deploys XIP with Linux, and we're going to talk what RISC-5 represents and what XIP is specifically for Linux and how to fit them together for the mutual benefit. A few words about me. First, I have been doing Embedded Linux since 2003, that time being in Moscow, Russia working in the Offshore Development Center for Monavista. Monavista is a well-known pioneer in deploying Embedded Linux commercially. For the 12 years I'm living in Sweden, that being southern Sweden close to Copenhagen and I'm a staff engineer at Consulco Group and a managing director at Consulco A.V., a subsidiary of Consulco Group doing operations in the Nordic region of Europe. Now you can see a picture to the right me and my family. It actually lacks the smallest member, so this is another old picture so I probably need to take another one. But that will be for the next presentation, I guess. So again, in this presentation we're going to talk a little bit about RISC-5 architecture. We're going to talk more about XIP and specifically Linux XIP and even more specifically Linux XIP on RISC-5 and why it's actually a good combination and how to bring them together and what's been done already and what has to be done for this solution to become more comprehensive. We're going to have a little demo and then we'll jump to conclusions. RISC-5 I'm not going to spend too much time and your valuable attention stating the obvious. So this is just a recap slide. RISC-5 is an instruction set architecture. It's not a CPU implementation. It's not a company. It's once again a hardware instruction set architecture and the main thing about it is that it's completely open source. It's royalty free for any chip manufacturer and therefore it can be deployed in very low cost designs because you don't have to pay your royalties. It's been developed by UC Berkeley and here this is the V postfix is coming from. It's the fifth UC Berkeley RISC design and then again it's probably pretty obvious where RISC comes from because it's a RISC architecture, so it's a reduced instruction set and therefore all in all it comes to RISC-5 and now it's a standard maintained by non-profit RISC-5 foundation. We are speaking about RISC-5 in embedded and so far there's a total domination of ARM designs in the embedded world. So it's pretty obvious that anyone who's getting acquainted with RISC-5 wants to compare it with ARM to get a back to picture on where RISC-5 stands compared to the main leader and as a matter of fact, you can see that technology-wise RISC-5 and ARM are very similar in a nutshell. So it's both RISC instructions set, load store architectures, both can be 32 and 64 bit. RISC-5 can theoretically be 128 but I personally haven't seen anything of a kind. The differences come later because RISC-5 is an open and royalty free instruction set architecture and ARM is proprietary and licensed and you have to pay fees to deploy it. On the other hand, ARM as a leading architecture has a well-established community that can help you should you run into any troubles with your ARM design as opposed to RISC-5 where it's harder to guarantee because the community is emerging and the architecture is relatively new. So there may be some questions that you'll be having trouble finding new answers for even though it's getting better and better you know pretty much as we speak because more and more people, more and more companies are interested in RISC-5 including the very huge tech giants. Well, you know what I'm talking about. And finally there's one more thing that unites RISC-5 and ARM and that is they both have a support for XIP in Linux. But what is XIP? XIP stands for Execute in Place. That is a technology that allows the code to be executed directly from persistent storage. Now let's say that it's most likely in Orflash either a legacy one or a rather new and fast QSPI based one. And when we talk Linux there are two types of XIP basically that is XIP kernel. Kernel does being executed from where it was written to from the Norflash not from RAM and in this case such an option should be selected compile time and the other thing is XIP uses space so the user space can also be XIP. The application can also be run directly from Flash but it requires a certain support from a file system. So file system should be somewhat special. Most likely even though being a legacy one it would be CRMFS also XFS is capable of doing this and there are some attempts successful but not accepted widely to build up squashFS support for XIP as well. So for the first case where we only have XIP Linux kernel the graph of the overall system architecture from the XIP point of view will be looking as on this picture. So we have bootloader and kernel in a QSPI Norflash and they're both executed directly from it. And we have application file system and data residing on an NAND flash even though it can be for instance micro SD. So we only have kernel XIP and not the user space XIP in this particular scenario. In the more advanced one we can have application file system also residing in the QSPI flash. What's changing is that we obviously have a stricter or stronger requirement for a QSPI flash size. So it has to be bigger. It has to be big enough to have a kernel and application file system. And then we only have data on the NAND. This design may be more expensive but we also save on RAM because we don't have to copy applications to RAM before executing them. And that is the primary XIP advantage. We don't have to have much RAM. We can actually be quite okay with a lot less RAM in a Linux XIP file system compared to the traditional Linux system. All in all we can have up to 10 times smaller requirements on RAM. And in some cases we can get away with no RAM at all if there is S-RAM. And in this particular case the power consumption in idle mode can be close to zero. And that is very important for some IoT design running on battery because some IoT designs may have a requirement of half a year running on battery or almost a year running on battery. And this you just cannot achieve if you have huge power consumption. Well, relatively huge power consumption even in idle mode. Another advantage is that you usually get short of boot time because you don't have to copy the kernel and probably init-ram of S from your persistent storage to RAM before booting. And faster execution in case the QSPI flash is fast enough. Well there are not only roses of course because otherwise XIP would have taken the world. So there are also some obstacles and these obstacles namely are well first of all you cannot write to flash and execute from it at the same time. So that means that you cannot use nor flash or almost cannot use nor flash being used by XIP for some read write data. You essentially have it for read only data. There are some tricks that enable writing to flash while executing Linux XIP when you have copied or executed from RAM code. But there are so many hardships associated with that that this technology is almost unused at this point. Another problem is that if you're running something directly from storage you cannot compress it. So XIP requires more space on flash storage because at least the executable code cannot be compressed. And finally you have to define all addresses at compile time which may be a security issue. Well let's not talk about it right now. This is something that obviously can be a separate talk. There is a lot to say about XIP and security and let's make it another presentation. And having said that let's try to figure what makes XIP and RISC 5 a really nice combination. What makes them play together so well. So one of the specific features of most RISC 5 designs I have come across and I guess I've seen many is that there is QSPI nor flash in those. It exists in pretty much all the RISC 5 designs out there. So since this is the primary requirement to be able to build an XIP system it means that most of the existing RISC 5 designs have a capability of running Linux XIP. Another thing is we have just mentioned that XIP opens up some doors for Linux to be used on IoT devices and many cheaper RISC 5 boards target IoT specifically. So this is a very interesting combination isn't it. Finally RISC 5 has a specific boot firmware, SBI firmware which actually doesn't care that much about some specific boot loader. So in fact instead of using Uboot as a boot loader we can use an XIP kernel as a boot loader. So we're getting away without any specific boot loader just a firmware, an XIP kernel and that saves space and that saves boot up time. Isn't it nice. And finally many cheaper RISC 5 boards have small RAM and in this case Linux may be quite a problem to run on those if we don't use XIP but if we do then suddenly RAM becomes enough. Isn't it nice. And as a matter of fact some huge steps towards implementing all those nice features that we can get if we do XIP on RISC 5 are already done. So there is Linux XIP support for RISC 5 and it's in the mainline starting from 5.13. There are certain limitations but they're not set in stone. It's just the things that are already implemented and these are only 64 bit RISC 5 designs are supported and only MMU-enabled targets are supported and on the other hand even though this is a certain big limitation still RISC 5 is on the edge because before that it was only 32 bit ARM that supported XIP and not many people are interested in 32 bit ARM nowadays as opposed to 64 bit RISC 5. This is very interesting. Many people are interested in XIP on this but we do need to extend support to the boards that actually need XIP as opposed to ones that were used for convenience and development of XIP as such. It was developed and tested mostly on Polar Fire and also verified to work on C5 and Beagle V. We'll talk about Beagle V a little more later but all in all all those three are not exactly the boards that will run XIP in production most likely and here we come to RISC 5 and XIP work to be done for this combination not to be nice but to work perfectly and first thing the highest priority and this is something that we're already doing is to have support for MMU less RISC 5 boards. Boards like Kandrite, K210 and similar because these are the main targets for XIP. Cheaper designs, less RAM, less computational power, still relatively big nor flash to put all the stuff in there. The second thing priority-wise in our opinion is to have compression for data and static data sections within the kernel that will leave more space for XIP user space and this is important as we have already told. Finally we do want to have support for 32-bit RISC 5 designs but this is lower on our list because we don't see that much of a desire to deploy those out there on the market. Finally there are some things to be optimized with regard to address translations in the XIP code because the current implementation the one that we have done is heavily using branching to figure if an address is in the nor flash or it's in RAM and this branching slows down things and finally we do want to test the more boards and have feedback but it's not only up to us. Okay now we're going to pass over to a demo and this demo will be held on Beagle v or to be completely precise it was planned to be run on Beagle v but i managed to screw my Beagle v up and i don't have another one and so i'll be using a simulator a really nice one and i'll be giving a few words about it a little later but first what's Beagle v as you most likely know a Beagle v is a somewhat Raspberry Pi like board but with a 64-bit RISC 5 CPU designed by Beagle board foundation and it's incorporating two core c5 u94 cpu which is roughly on par with ARM Corelix a55 it has AG DDR ROM it has 32 megabyte qsp nor flash it also has micro sd interface hdmi ethernet audio and USB ports and many more and it's out there so it's live but not booting sorry about that so i will not be able to demonstrate things on this one maybe i managed to kill it before it's because it's a pre-release board as you might guess by looking at a huge fan on top of the cpu maybe it's something else i haven't really figured what went wrong but anyway we're gonna have a demo on the simulator but first of all it's a software to be built for Beagle v the one that i'm using and the one that i believe most people are using out there is based on build route and there's a complete linux build for build route how-to on the boot lin site and you can see the link on your screen this build is using the kernel 5 10 and that kernel does not support xap on RISC 5 out of the box so i dug up a yearly version of my xap patch for RISC 5 and this patch is also available on demand even though not available in the mainline and after some very short tweaking i was able to make it run most of the tweaking was in fact changing the configuration that is turning off strict rwx configuration items adjusting a little bit qsp flash address and selecting sparse mem memory model well apart from that i don't remember anything substantial to be changed out there and then we pass over to demo the demo will be out uh using a specific simulator a very nice one as i've said and the name of the simulator is renote i'm not sure uh if you're familiar with it or not but it's a nice one really so let's try it running with xip okay and there we have it not very fast but alive as opposed to the real one okay okay now we can try to load something from the nor flash let's make sure we have the right amount of zeros and so it boots and while it is booting it's not gonna be fast that's not a problem of xip that's a problem of this specific simulation and the computer on running this on so while it is booting we can continue a little bit on the xip stuff and even try to jump to the conclusions because you can see it's going further it actually does work so let's go to the conclusions first and then we see what happened to the demo so the conclusion number one is xip execute in place is not a yesterday's technology it's not something only applicable to some random real-time operating system it can be deployed in linux and it actually goes very well with what risk five design have to offer this work is underway and some important additions and extra implementations are to be done to get the best out of the combo of xip and risk five on the other hand uh it's also up to the risk five designs themselves and the manufacturers to mature and to be more appropriate for xip as such because these two things together can actually be a very nice combination can bring a lot of new stuff new applications into the linux world for the benefit of the community and the ecosystem and that was it thanks a lot for your attention and let's try to go back to the demo and see where it went okay what do we have here it's still initializing well i guess we can wait a few more minutes now i guess we shouldn't let's rather save the time for questions which i hope will be made thanks again for your attention