A tour of the ARM architecture and its Linux support

a session of the day please join me in welcoming Thomas Peters Oni who's going to talk about a tour of the arm architecture and its lineage support thank you for the introduction good afternoon everyone so I'm Thomas and I will indeed share some thoughts about the ARM architecture and try to give an overview of kind of how it works and how its Learning Support is organized so afterwards about me I work at free elections it's a embedded Linux consulting company were located in France this is why I'm speaking that weirdly we do embedded Linux stuff a lot of bootloader and Linux kernel development and a little bit of build system work as well most of our work is focused on arm platform so we helped arm vendors bring support for their processors in the mainland kano and we help embedded system makers bring Linux to their platforms which mainly are our arm base so we do contribute quite significantly to the Linux kernel in terms of support for arm platforms and a number of our engineers are maintained errs of our use arm sub architectures or driver subsystems on a more personal side I've been working on the support for Marvel processors in the kale since about four or five years now and battery is running is ready ok and I also work on a project called bit root which is a build system for embedded Linux platforms and I happen to come from Toulouse in the southwest of France so quite a far trip from here it's my second time at LCA and I'm really glad to be here again to share another talk with you so arm is everywhere I guess everyone in the Linux community has heard or even possibly used arm platforms it's in your phone it's in your TV in your router in your set-top box in your car in your a IOT device in your favorite Obie's development platform it's pretty much everywhere and through this talk and we're but it gave me the idea of this talk is that a lot of people come from an exit to see background and don't necessarily understand what are the differences with arm in terms of oh it's the architecture is organized what it means in terms of lending support in terms of software support around it they're on a number of differences and if you try to think x86 when doing arm work you might misunderstand a number of things so when I will try to clarify these as much as I can of course so I talk first about the hardware aspects what is arm from the the architectures perspective all the way to a given hunter platform and then talk a little bit about the software level so arm is a company in UK it's been recently purchased by another bigger company but it's still originated from from the UK and this company first Wright's architecture specifications so basically these are documents that specify our CPU works it defines an instruction set including possibly some multimedia DSP instructions it describes our memory management unit works it describes our interrupt exceptions are handled our caches are working our virtualization can be accelerated in that kind of things but it's really just a specification so it's a document that they call the ARM arm which is the ARM architecture reference manual and it's but as you can imagine if early voluminous documentation but that's only documentation it's over time they've made this architecture evolve so we've got arm V file for army 5r v 6 r7 arm v8 which is the latest the latest one but again it's really just a specification on our CPU and can work based on that based on this specification arm develops IP cores so IP cores is for the people doing hardware developments the kind of the similar thing to a software library in the software world it's kind of a fuzzy metaphor but it's probably the easiest thing you can think of an IP core if you are of a software developer so it's a a piece of hardware logic that describes how hardware signals are converted into other our signals to produce an interesting outcome and you can use that to create complex hardware logic such as processor cores so based on their specifications arm create IP cards and that implement do specifications so for example arm nine to six is a given implementation our MV five or cortex a15 is a given implementation arm three seven a our cortex a53 is a given implementation our MV eight a so we already have two levels of thinking we have the ARM architecture which is a specification and then we have the arm core which is an implementation of a given specification we can have multiple possible implementations for the same architecture specification so it means that you have you can have two ARM cores that actually behave excellently the same way but internally are implemented differently for example we have cortex a five seven eight nine twelve fifteen that mostly behave the same way they actually have some of them are go to extensions of some other improvements but in essence they are implement the same instructions at the same MMU the same exception handling and so on it's just an internally they are different and they are different in mainly performance versus power trade-offs so cortex a15 is for example a very poor performance oriented implantation so it has a very deep pipeline lots of out of order execution logic lots of complicated logic to improve the performance but that requires more transistors we get a bigger CPU which consumes more power and the other side of the spectrum something like cortex a5 is much more limited in its in its performance but also consumes less power but they implement the same specification so they can run the same code this is not Hardware right this is only the design of a hardware so arm does not sell processors they only sell IP cores that other entities can purchase who ultimately produce actual hardware that you can buy and you can see in your embedded device so the next kind of layer is arm system on chip so if you've got a sip new core that's it can execute instructions that produce a result from input data but taken alone it doesn't do much you must likely need memory you need peripherals to make a useful system out of it so in the arm world we have this concept of SOC system ownership where the idea is you integrate into a single chip essentially all of the components that you need to make a computer system so not only the CPU as I said but also peripherals memory controller it in the controller USB controller other best controllers display controllers audio and sometimes some very specialized peripherals for accelerating and crypto operation or other aspects and you integrate all that into a single chip so that people who make systems out of it don't have too many other components to integrate they put that chip on their system and almost everything is there so the arm ecosystem is made of many companies that we call associate vendors that purchase cores from arm so that purchase a license from arm and the code of those arm cores they integrate it they integrate around and this CPU core a number of other IP cores for the different peripherals and they produce actual processors out of that so there's a very very large spectrum of our message available to address numerous markets you will not use the same SOC for a high-end phone or for a very low-power iot sensor it will be a completely different SOC with completely different peripherals so there's a wide variety of Association associate vendors in the arm ecosystem so to take an example here is the block diagram of the freescale dynamic six associate is a pretty popular one in the automotive market in this real market so if you look up here in the middle we have the cortex a9 so that's the actual arm core and we can have up to four of them so it's up to a quad core SOC here at the top we have the the memory controller so we can attach some DRAM to this SOC here we have some clock and resent in Ling so that it's clocking all the other hardware blocks in that in this SOC so this big block here is what is your little chip on the on your development board or in your phone or in your car so that's all fits into a single physical chip you've got lots of iOS PWM GPIO s can bus controllers internet controllers things like that we get some GPU in there we have image processing to output some pictures on displays and we've got lots and lots of other peripherals so as I said there's a very large spectrum of associates that will make different combination of peripherals some will have more UART controllers than others some will have display capabilities some nuts etc etc so this very very wide range of ISO sees all these Hardware blocks are programmable and they have registers that you have to read and write to to actually make the hardware perform something useful and so they need a Linux device drivers in an operating system but we're mostly interested in the next in in this discussion so that was the kind of the third step and the last step to bring you an actual useful system is what I would call the hardware platform so even though an SOC is a system ownership it's actually not self-sufficient it needs additional things around it most of the time you need at least Ram you need some storage NAND flash or emmc or other types of storage you need some ports it's circuitry to provide power and to the SOC so that it can operate properly in some cases you may need the display panel and touch screen may need Wi-Fi and Bluetooth chip if it's not built into the SOC some of them have built in Wi-Fi bluetooth some of them require external chips you might need files for your internet controllers you bang it an HDMI transceiver if it's not the built-in functionality you might need a can transceiver you need connectors and so on and so forth so your SOC is going to be connected to a variety of peripherals to a number of buses on a PCB so on a on a on a board and to make the system work so we've got schematics so these are the schematics for the nine dollar computer called chip from from next thing in the that was on Kickstarter a year a year ago and is still shipping so it's a little board based on an arm SOC that has a number of peripherals around it mainly bran flash Wi-Fi Bluetooth power secretary and other connectors so we really have four levels to think about when we talk about arm platforms we've got the ARM architecture specification I am armed v5 arm v7 r v8 then we have the arm core itself I am using arm nine to six arm cortex a8 cortex a15 etc which system-on-chip I'm using and I'm using an Atmel system-on-chip allwinner freescale Ti Marvel and there are plenty plenty of other associate vendors and which specific hardware platform I'm using am I'm using Raspberry Pi chip this given phone or this given TV of this given car that integrates an infotainment system so let's take a few example of boards and the Raspberry Pi one to its board that's the last thing here and I'm just going back the SOC that it contains is a Broadcom 2835 it's this SOC itself contains an arm core called our 1176 j set F which itself implement the arm v6 architecture specification and all those information are important to understand what is the Linux support for this platform the Raspberry Pi 2 as a different SOC the 2836 which differs just by one digit but uses actually a different arm core the cortex a7 which itself implements our different ARM architecture arm v7 a that's quite important because it means that code that you can run on the Raspberry Pi to compile code compiled binary code will not run on the Raspberry Pi one they don't implement the same instruction set so somewhat compatible in some ways but it's not entirely compatible so you can run armed v6 code and armed visa on arm7 but not the opposite the chip which I just mentioned earlier is based on an all winner SOC which implements which contains a cortex a8 core which itself implement the RMV 7a architecture so these two ones implement the same ARM architecture so they can run the same user space code the espresso bean another platform that that is relatively cheap based on a marvel SOC it's the marvel Armada 3700 it uses a dual core cortex a53 which itself is an implementation of the arm v8 a architecture specification so as you can see each time we have the architecture specification the core of the SOC and the actual hardware platform so sometimes I've been hearing especially as part of my work on Bill route I do support lots of newcomers in the arm and embedded world and they ask like is there support for arm in Linux or is the support for arm inbuilt root or is the support for arm and this or that doesn't make a lot of sense because you have to be much more specific than that which SOC are you talking about which actually born are you talking about so we need all these information to know the level of software support that is available for your given hand war platform the arm core the SOC and the board are all important information so asking is there Linux is there support for arm in Linux doesn't make a lot of sense it's more is there support for this specific hardware block of that specific SOC in the Linux kernel that is a question that makes sense so all three levels are needed to support a given hundred form and the next thing is that it's not only does it support it but does it support that specific functionally that I need as you can see again in that block diagram a SOC contains a tremendous amount of IP blocks and it's very unlikely that any given system will support all of those IP blocks and all of the possible features that they are so linux may have support for a certain fraction of those IP blocks but not necessarily all of them so it might be a good fit depending on your specific target application and linux may also not necessarily make use of all the possibilities of all those 100 blocks hundred developers are very creatives they add lots of functionalities to a hardware which operating systems sometimes you sometimes don't use so arm v7 itself has a number of variants and there is the arm v7a which is the one you're most likely most likely the one to encounter in your projects it's the application variant of arm v7 so it's designed to run full-featured operating systems such as Linux that require a memory management unit caches it supports two instruction set called arm and some two of them two provides higher code density it has a VFP which is vector floating-point operation and in skin of optional but you can have neon instructions which are simply instruction to accelerate multimedia related operations for export cortex a8 or cortex a15 are implementations of arm v7 a there's also arm v7m where M stands for microcontroller and for example cortex m3 m4 and seven are implementations of arm v7m so it's a it's a smaller variant it's more it's doesn't have any memory management unit there are no cashes in m3 and m4 it was added in m7 and it supports only thumb - it is indeed lower performance but also a lower power so Linux can run on this arm v7m but requires external RAM and flash so our arm v7m is really microcontroller oriented so we'll find lots of arm b7m associates that have built-in RAM and built-in flash and the idea is that you don't have to have external RAM external flash on your system to lower the cost over the pork consumption but they have two little RAM and two little flash to run a full-blown Linux kernel currently so there are a few M 3 M 4 and 7 platforms that have enough external RAM external flash to run an actual Linux system so some people use it this way but a belief must of do's soch so no RAM and flash to run either bare metal code or smaller real-time operating system free our toes or other things like that there's another variant that's less widely known and one less widely used at least in the in the visible and our market I would say it's armed v7r where it stands for real-time and it's focused on deterministic response so there are lots of features in the CPU core to ensure that you can write code in a way that is as deterministic as possible so things like no not necessarily a pipeline or out of order execution that kind of things that makes the execution time and non-deterministic is are not used and it's typically used in storage devices so your typical SSD controller make use of arm v7r based SOC s and so these are totally different variants the one you may encounter are really a and M for a number of projects more recently I would say bit is still a few years back arm v8 was introduced and the main big feature of arm ba is obviously the introduction of a arch 64 which is a new 64-bit instruction set it's actually optional so you can have an arm v8 SOC that doesn't support 64-bit but that also arm v8 also introduces a number of other improvements but our 64 is the main one they kept another mode called a arch 32 which offers backward compatibility with arm v7 a this allows to run arm v7 32 bits application on arm v8 or even a full 32 bit system on on arm v8 so there are a number of arm v8 cars like a 32 a 53 a 57 a 72 which is which are currently clanking of the hi hand and arm course that you can find so over the years and our has made the specification evolve with gradually more and more features so that should diagram from the arm website itself so from arm v5 they've moved to arm v6 bringing vfp v2 which is which are vector floating-point operations before arm v6 you did not necessarily add a floating-point unit in in hardware so that was added in arm v6 and Giselle was an extension to accelerate Java Virtual Machines I'm not sure how far it's it's actually being used but that's it's there in arm v7 they added some too so this alternate instruction set that allows for a higher density instead of being all instructions and coding on 32 bits you can mix 32 bits instruction and 16-bit instructions in the same code flow so it increases code density trustzone which is a security related functionality and cyndi which is for as I said earlier accelerating multimedia operations and then they brought arm v8 with mainly the 64 bit instruction set and a number of other features so it's progressively evolving over time there is another concept in the ecosystem the concept of architecture licenses so most of the SOC vendors by ARM cores from arm so they buy an and already made implementation of an arm core and they only only work on the peripherals around it it's already a huge amount of work but some associate vendors designed to take a different route and instead they purchase an architectural license so they purchase from arm the right to implement from scratch another CPU that complies with the same specification so they don't buy the core they just buy the right to implement another core that complies with the same instruction set same memory management unit and so on and so forth so a few examples are below Marvel did that in the number of products Qualcomm does that a lot in their in their products Apple is doing that as well so for impo Apple Swift is an implementation re7 a which is used in the Apple a6 which itself is using some of the iPhones Nvidia does that as well kavion Broadcom applying micro Samsung does it so a number of vendors decide to not purchase the the core from arm but implement their own because they think they can push things in more interesting directions in terms of power or performance or other reasons so here is an example Apple doesn't purchase the the arm implementation of armv7 a core but instead implements its own which is using isn't its own system on chip which is used in its own phone so moving progressively towards the the software support one aspect of arm is that there's very little standardization the instruction set itself is standardized by the arm specification so from the user space code point of view arm v7 platforms are mostly compatible there are a few tricks with like neon op instructions being optional so this means that you can generally take a Linux distribution build for mb7 and run it on any arm v7 based SOC but for the other hardware components around there is essentially no standardization at all so from one SOC to the other the celluloid controller may be different so it's not because you have support working on your board a that is going to work on your board P unless of course they use the same SOC but if it's different SOC you may need a different driver because it's a different circuit board controller also in must arm SOC is the hardware inside the chip is memory mapped so it's by doing memory read memory write that you talk to the different peripherals and there is no dynamic enumeration or discovery mechanism so you cannot ask the hardware what who you are what are you capable of and and that you have to know that in advance for nearly that there's lots of hardware we use so the cores are CPU cores are reused across SOC vendors but even for the other adware blocks around SOC windows very often purchase IP blocks from other vendors companies like arm CAD and synopsis Mentor Graphics imagination technologies make their business out of amongst other things selling IP blocks you can go to arm and say eh and I see you have this malli GPU I'm interested in bringing a GPU on my system can I purchase a license to bring this GPU into my SOC you can go to cadence and say eh I see you have this internet controller that's available in a purchase license and bring it into my system and when associate vendors do that then we've we end up with the same IP block in completely different associate entually from different vendors and since they are the same IP blocks they are programming model their set of registers their behavior is the same and we can reuse the same driver in terms of Linux channel or bootloader support and vendors also reuse massively IP blocks across generations of their processors so they change their SOC line every year or two years or three years depending on the vendors and their target market but when they do so they very often reuse IP blocks for things that are not very innovative as an example Marvel is using an SPI controller IP block and which is that's been the same for the last ten or fifteen years so we've written a Linux driver for that 15 years ago and it's still working fine for the latest arm v8 as you see that if that they dev release just because doesn't make a lot of sense to invest more time in something as I would say as trivial as an SPI controller so this allows from a software support to massively reuse drivers but sometimes it's not easy to figure out out of the data sheets of the SOC is that actually it's the same IP block so we've I've seen several cases where someone writes a brand new driver for what appears to be a new IP block and then the maintainer of that subsystem in the kennel once the driver gets submitted says this is weird it looks really really like this other driver and then you realize yeah indeed to the exception of like to register offset and two bits masks or things like that it's actually exact the same ip block so it's been reused in one way or another so we for example discovered that the I square site controller used in Marvel associate is exactly the same as the one using all wiener SS es to the exception of the layout of the register which are completely mixed for some reason but it's the same driver is used in Linux BIOS so if you're using x86 you're used to having something like a bios as a firmware we don't have anything like that on an arm at least as of today at least not in a standardized form each arm SOC contains a little bit of rum that is a directly part of the chip itself and it implements the boot strategy so each family of ARM processor has a different way of booting in general it kind of as a behavior that is more or less the same between different ARM processors it kind of scans for different storage devices try to find a bootloader somewhere loaded somewhere into memory but the details are very very specific to each processor so we should look at our and our mx6 from freescale boots and now I don't know an all winner processor boot it's completely different usually what they do is that they try to find a bootloader with some like signature or marker and some storage location and load it into an internal memory in the processor because that's this stage the external memory is not yet initialized not yet available so we have it usually a two stage booting process with a small first stage that just initializes the memory and loads the second stage often this ROM code also provide a recovery method so if there's no code at all on the platform it's kind of a break and this room code offers a way of recovering from that situation in terms of boot runners we don't really use that often grab grab to on arm platforms you boot is kind of the de facto standard so it's a completely different boot loader project it's also GPL license but it's a different project it has support for many architectures not only arm but for PC MIPS and many other more thankee architectures bear box is also quite popular though a lot less than then you boot by far they have also a lot of companies making their own boot errors especially in areas where security and or grm related aspects are are involved so your average set-top box or phone or things like that typically use kind of a more homegrown bootloader their grub is gaining some traction especially with arm 64 entering the server space a lot of people are trying to bring the same technologies as the one used on on Intel to the ARM architecture such as the same boot rogers or even at the BIOS level with UEFI and things like that raspberry pi if you're using that it's kind of a very weird special case with the firmware running on the GPU it's by far not at the common the common way of booting arm exercise so we've got a first stage bootloader as I've seen in some cases it's a separate project principle on at male associate a provide a separate project that provides just the first stage and then then the second stage you can use you boot or bear box or whatever second stage you prefer and for some other platforms let's say freescale or TI platforms it's do boot or bear box itself that compiles itself twice once in the first stage that is very small to fit the constraints of the platform and the second stage it is much bigger and provide more functionality typically those boot orders we interact with them over the CL part so we know necessarily have a screen or a keyboard or things like that regularly have to help people starting up with with embedded and after talking to them for 20 minutes worth now we realized but do you have do you have a sail port access I don't know I'm just using a keyboard on a screen okay so you really need a serial port to interface with anything low-level in embedded system based on arm so the boot process looks really like this the rom code so that's part of the SOC itself there's nothing you can change in there it's fixed in stone and it's stored in the SOC in ROM when you pour up the soc it runs it locates the first edge bootloader typically in n flash or spy flash or USB SD anything like that and loads it into an internal memory internal SRAM and runs it and that's the point where you get control at the software level so this from this stage you can change links in most cases we use that first stage to load the second stage which provides mail functionality you have a prompt and which provide commands you can load KML images you can load other things run tests ran like diagnostics and and stuff like that and that second stage is typically used to load a Linux kernel image and run it so moving on to the chaos support I need to get back on on to this hardware discoverability thing on x86 most of the hardware can be discovered at runtime most of the hardware is on PCI or USB which are buses that provide dynamic enumeration you can ask your PCI bus who is on the bus who are you a I'm an Nvidia graphics card I can do this on that hey I'm an Intel it in that controller I can do this on that for the rest a CPI provides additional hardware description so thanks to this the kaenel doesn't need to know in advance what hardware it's gonna it's going to find when it boots it will during its boot process query the hardware and the handle will tell the system what's there on arm there is no such mechanism that exists on the hardware level and so we have to find another way so in the old days the way it was done is that the kernel code itself would hard code the description of what's on your hardware platform so the the boot order passed the Kaenel a number that uniquely identifies the hardware platform your booting on and the Canaan's looks at this number and said oh okay you're booting on platform 1 2 3 4 so platform 1 2 3 4 I know it's a free scale imx6 bays development board which has this and this and this and this and this peripherals and this was all hard coded in C code in 2010-2011 I'm not sure exactly when that D effort started but that's about that that time frame the keynote developers of the arm community decided to switch to a different solution to presents the hardware called the device tree and I'm going to spend a few slides on that and this effort was done together with another effort called multi-platform about which I'm going to see a few words as well so the device stream is a tree of nodes that describe non discoverable hardware things that you can discover like PCI USB devices you don't need to represent that in the device tree only things that cannot be discovered it provides information such as where are the registers to program the hardware without interrupts lines the DMA channels with type 1 hardware that is and lots of other non discoverable information and it's provided by the framework to the operating system so it's not a Linux specific technology at all and actually originates from the PowerPC world where it has been used for many many many years when we're more than then when it was used on on arm and so the idea is that your firmware can be a bios can be the bootloader can be anything below the operating system contains the hardware description and provides it to the operating system which can then read it at boot time and this way know what's in the system its source format called DTS which gets compiled into a binary format called DTB to be more efficient in reading from the operating system point of view so I'm not going to get into the details of device reads just to show you what it looks like more or less so it's a tree of nodes that contains properties that disclaim hardware and this node describes a 1u our controller gives the addresses of registers give the young the the corresponding driver in the operating system this gives another register and the corresponding driver so we've got here two Hardware blocks which are which is the same compatible string so they use the same driver in the kennel and but different register addresses so it's a SOC where we have two instances of your controller so we have to UART controllers that behave the same so they have the same programming models the same registers we can use the same driver only the interrupts is going to be different and the registers are going to be different we have two instances of the same to same device and here we can see a case of a reuse of IP blocks so that son 5e is a ol winner based SOC and they use for their you are controller synopsis IP block so they actually the purchase from synopsis the right to use their IP block to implement an a ure controller so we have a single Linux driver that is used across many associates this file here described the SOC itself so the processor and it gets included into another file that describes a board so that's one specific board that uses that SOC and which specifies the additional hardware information so it says what is the name of the bar that we have an LED connected on this specific pin that we have the first yard controller that is enabled with some additional properties so we describe all the hardware what are the different components how they are connected with each other this gets compiled into a binary form and we pass that to the K'naan with that can read this information and ask the different drivers to basically manage these devices so it's no used for almost all arm platforms there are a few ones that haven't been converted but the vast majority of the popular ones have been converted arm 64 mandates the use of the device stream so it's all of them are device free and compliant I would say it's used by the channel itself of course but it's also in some platforms used by the boot router so the do bootloader doesn't need to repeat the hardware description it's in terms of source code it's currently stored in the Linux kernel tree so it's supposed to be a Linux independent technology but it is currently in fact very tied to the Linux kernel and they are even stored inside the Linux kernel source tree there was at some point a plan for a separate repository but that that has never occurred so far it's supposed to be OS agnostic so FreeBSD and other operating systems can potentially and use a device tree so it doesn't contain ilanic specific information in practice it is not that easy to make it completely OS agnostic and backward-compatible but people are really trying hard in this direction and the idea is that when you start up your system your bootloader loads the kaenel image into memory and next to that it loads the device tree image and it passes the address of the device tree to the kennel when it boots and this way the kale can read the device tree find out what is the description of the platform and trigger what what's necessary in the different device drivers at the KO level we have support for the ARM core this is generally done by the arm engineers themselves support nib for things like the MMU the caches the virtualization stuff it's in our charm and arch arm 64 and it's generally available in Linux upstream even before any arm SOC is available with this arm core so they use lots of emulation to test their Linux support before we have even an actual chip on your on your desk so that's directly done by arm there's usually not much to worry about so point when the arm SOC and the hunter platform is very different story it requires drivers for each and every hardware block that you've seen on the block diagram and you multiply that by the number of SOC s that's a massive amount of drivers that are needed to support all of those associates so it requires drivers it requires also device three descriptions for the different SOC s and different boards so that's a lot lot of work so sometimes it's available upstream sometimes it's available only in vendor forks and if you've been to Jonathan Corbett's talk earlier today he mentioned that's that aspect as well so not everything is supported in the in the upstream kernel so typically what do you have to support arm system-on-chip you've got a bunch of what I call core drivers so drivers for peripherals that are not really like visible to the outside but are really important to make other Hardware blocks operate prep them things like clock drivers reset controller drivers pin muxing like controllers interrupt controllers timer controllers GPIO controllers these are really the base of the young SOC support thank you there are peripheral drivers then to support everything that allows to communicate with the outside world buses display controllers internet controllers and so on and sometimes there's a little bit of platform code in our charm Mac and the name of the SOC family for things like poor management SMP support but this is gradually being phased away in favor of more device drivers and that was part of the multi-platform effort to move a lot of platform-specific code and add code into proper driver subsystems on arm 64 there's no platform code at all poor management and the same activities are handled by making calls to the frame we're using as an arm specific say protocol called the PSC I'm so most vendors what they do to add support for their process ARM processor they fork the Linux kernel they add all the drivers that they need and as Janet and say hello today that can be millions of lines of code and then they ship that to people so if you get that then it means you're essentially locked into using that specific key known version you cannot upgrade you cannot change the canno version because there's so much a difference between where you are and upstream there there's no lock you can move to a newer version generally this support from vendor is not effects line quality it depends they are they're better ones than others but in many cases it's not that great at least it's not in par with extreme accept expectations internal code quality and situation god I would say somewhat worse with Android because what happens with Android is essentially you've got the mainline Linux Channel Google takes a version of it adds the Android stuff on top of it then this gets taken by a SUSE vendor that adds support for their SOC in there and then this gets taken by handset or tablet vendors that add the support for their platform and that what you get at the end so like for UPS or three UPS actually away from from mainline and that's usually millions of lines of code fortunately more and more vendors engage with the upstream Linux community and submit patches then they start and you're sending that it's actually better for them will cost them less money down the road rather than having to upgrade all their their stuff once in a while to provide newer Kindle versions and the community is also making a lot of effort in this direction so in cases where vendors are not very cooperative Oh beasts or other developers or companies were interested in some of these associates work on supporting them in the upstream Indian channel so for example all winner is the support in main line is fully community contributed there's no involvement from from the vendor even though there is actually pretty good supporting main line NOAA days going multi-platform yep I'll be there only two more slides so originally when you were building an arm in channel image it could only boot on one given platform or a few platforms that use the same processor there was no way you could build a single channel image that could boot on a free scale base platform and on a Texas Instruments based platform you had to build two separate channel image so if you want to make your 1x distribution that that installs on all arm platforms it was a nightmare you had to build like tens of different key images not manageable so there was a wish to have a behavior that is more similar to what you expected you have on x86 where you build a single binary cannon which might be a little bit big because it is like well fairly significant number of features and drivers but at least this single channel image boots on every platform so together with the switch to the divine stream a lot of work has been undergone to move to multi platform where the idea is that a single channel image can support a wide range of arm platforms so essentially it's moving from the mindset of everything is decided at combined time to the mindset of everything is decided at runtime so this led to the creation of numerous driver subsystems clinging up lots of code moving things around there's been a lot of work but know that work is done and almost all of the armed platforms are a multi-platform compatible and this means you can build a single channel that puts on all armed platforms so it's actually a little bit more sceptile than that you can build a single channel that boots on armed v4 and v5 platforms on one side one that builds for armed v6 and v7 platforms on another side and finally another one that builds and that boots on or armed v8 platform on the final side so it's still not all of the armed platforms because there's too many differences in the instruction set and MMU and stuff like that to make something that works across the board but it's much much better than than it was so for example you can do make arch our milky v7 def config that's the default configuration that builds a channel that support all arm v7 platform that they can support and it actually works to conclude let's talk a little bit about the root filesystem aspect you can use a regular desktop distribution that's what lots of people do Debian Ubuntu raspbian fedora you can use that unarmed the support the ARM architecture of course there are lots of specialized systems for embedded Android being famous Tizen and many other systems but I wanted to mention that in the more deeply embedded world lots of people companies use embedded Linux build system to produce more customized system and then what general purpose will needs distribution provides so tools like the Yocto project open embedded built route open wrt that it's kind of tools provide a more stripped-down and customized system that you can use on arm or other platforms and I'm Way over time so I think I have maybe time for one or two questions not even so if there are any questions I'll be around in the old way after my talk thanks a lot for attending [Applause]

Channel: linux conf au 2017 - Hobart, Australia

Views: 87,875

Rating: 4.9289174 out of 5

Keywords: lca, lca2017, ThomasPetazzoni

Id: NNol7fRGo2E

Length: 46min 34sec (2794 seconds)

Published: Wed Jan 18 2017