 So in this section we're now going to have a look at the boot chain and how the security of the device is maintained with respect to segmenting things for secure execution, segmenting things so that the Cortex M4 has sole use of parts of the system. So we're going to have a look at all of those little elements that make up the security section. So the first thing we're going to have a look at is the boot chain. We can consider the boot chain as our picture stays there as a rocket. So we have our ROM code, which is hard coded inside the device, which is 128K. That will then load our first stage boot loader, which will sit in the embedded RAM, which is 256K. Then that will then load our second stage boot loader, our kernel and our processes, which will then sit in the external DDR memory that we have on board the device. So the ROM code does basic clock tree initialization to get the device up and functional for internal RAM, things like that. And it will also initialize the particular boot methods we have available for the ETM32MP1, so be it EMMC, serial link, SD card, things like that. So that's what's programmed inside our ROM code so that we can then launch our first stage boot loader. So our first stage boot loader is then loaded through whichever method, so in the case of our board, which is the SD card, it's loaded into the embedded RAM inside the chip and this particular piece of code will then do our complete clock tree setup. So the reason it has to do the complete clock tree setup, it's got to set up all the clocks so that we can run DDR. It then has to also initialize that DDR, so all the DDR controller information is also executed from this first stage boot loader and then you might change to have a different storage device for your second stage boot loader. So again, you might want to change what boot device is going to load in your second stage boot loader as well. So this software has to be limited inside, remember you've only got 256K of an embedded RAM and it has to achieve all of these functions, so clock tree, DDR setup, any other external boot source setup so that you can run the second stage boot loader. So your second stage boot loader is now going to load in all the different file systems that we've got inside the system. So it's going to load mainly in the boot.fs file system, so it'll then pull in all the different informations for the kernel itself. This can be pulled from it again at a different storage, so it can be pulled in from Ethernet, so you can download the kernel off an Ethernet link if you need to and it's pulling in the rest of the device trees, so all the other features that aren't already set up in the first stage boot loader. The Linux kernel will then get loaded in and initialized, so that'll load all the device drivers that it needs and it'll create the root file system and then load all its initialization processes and then once the kernel is up and running it'll then generate the user fs or the user space and actually then launch all the different applications that are going to be running on the SDM32 MP1. So this is a flow diagram of what actually happens. So your ROM code will launch your first stage boot loader, depending on if you're using a secure element you'll go off and launch the secure monitor as well. Then you load your second stage boot loader and again, depending on your application, you can either then load in the Cortex M4 to launch or you can load the Linux kernel and let the Linux kernel load the Cortex M4 and then after your kernel is loaded then you go into the user space and start launching your applications. So that you can develop the Cortex M4 without having the Linux present, we have a dedicated mode you can put the device into which is called engineering boot chain and it's controlled by, if you look in the bottom left-hand corner, boot pins being set to 1-0-0 and this will launch the ROM code and put the dual egg 7s into an infinite loop and that will then give you the ability to use the JTAG or SWD to download your firmware into the RAM of the device so that you can play around and use your Cortex M4 and develop your application. This is fine as long as you're not doing any interaction with your Linux side, remember there's no Linux running at this point so if you've got data that's coming into the M4 that you want the Linux side to process then you can't actually do that in this particular mode and with the control of the clocks being done by the Cortex A side you will need to address the clocks and the GPIO alternate function separately because your normal code in your M4 will not be doing this, remember the power, the clocks and the GPIO alternate functions are all controlled by the Cortex A side so therefore they won't exist in your normal Cortex M firmware so you will have to directly address each of those registers as you're playing around in the Cortex M side. So when you configure the bootchain you normally used to have inside the kernel all the different hardware descriptions for each device that you had so therefore if you changed devices or a new device came out you had to change your kernel. That's now changed so it's separated out so the device tree is now the hardware description part and it works with the kernel. So this is now called a device tree blob and there's a nice link there for documentation on device tree which is device tree for dummies which is a really good link and it gets you understanding what the device trees do. We've made this easy so our Cubemax tool that is from our Cortex M world will now create the device tree source file so a DTS and this means you can then convert that to a DTB which you can then load directly into your device. We're having a play with that later on in the day so we'll have a play around with the device trees for that but separating it out makes your life a lot easier it makes changing around and you don't have to keep redoing things into the Linux kernel. The device tree source which is on the right hand side is made up of a user file so a usart.c file and then some device tree source includes and one of the includes is for the device to give you all the information of where UART is sat and located in the peripheral registers and then you've also got a pin control so that you know exactly which GPIO pins are mapped in the case of the example there UART number 4 so you can see exactly where it's mapped. In the source includes the status of the device is always set to disabled it's only when you progress into the DTS on the right hand side where you get status as being okay that means the device is now alive for UART number 4 in that case and then you can convert that DTS into the DTB for your software to run as I was saying earlier we can boot from different sources for the main device or you can put the device into the engineering mode this is the options that you have for our ROM code the ROM code is programmed by ST in the factory you can't change this but you can put configuration information in to define what it's happening so our device at the moment is set for the middle line here which is boot pins being 101 which means we have got our OTP words for primary and secondary are empty our boot source number one is our SD card if it fails to boot from the SD card it'll then try and boot from the serial port so you've got quite a good selection here of where to boot from so you've got serial QSP I know EMMC FMC NAND you got the engineering mode there which is no boot SD card or you can then configure specifically using your OTP words what your primary and secondary sources are going to be and therefore you don't need the pins at that point once you've configured your OTPs always bear in mind though Tampa has the highest priority so the Tampa system will have the highest priority inside there and it will default to force it to go to serial port only we have a dedicated article on the wiki for all this the ROM code overview and there's a nice application note to get you open getting started with the hardware for the STM32 MP15 series of devices so the memory mapping what do we have so we have our first stage boot loader which has to sit in the embedded RAM so this is normally TFA so the arm trusted firmware and the TFA will have its device tree blob because it needs to know all about the DDR because it has to set up the DDR interface the FSB bear in mind it says 256k there but there are a few other things that have to sit in the RAM so your first stage boot loader payload or the size of the actual software is limited to 247 kilobytes second stage boot loader sits in external memory size isn't so much of a constraint so normally it's about one meg again this will have its device tree blob as well associated with it because it might need to configure specific peripherals to be configured so that it can load the kernel from say Ethernet as an example so the second stage boot loader has to have its own device tree blob then boot FS which is the boot file system it contains the kernel device tree few bits of information for the file system running the external RAM mounting the root FS things like that loading the splash screen image things like that so all of that appears in boot FS then we have the Linux root file system which contains all the executable and all the libraries and all the kernel modules for the Linux system itself and then the remaining area is the user file system which contains all your user data so that takes up whatever you've assigned as your DDR memory on the device so if we have a look at what we've got on rsd card so you can see all these partitions so you've got FSB boot loader one and two there are two versions of it to make sure that you don't corrupt your first stage boot loader then you've got your second stage boot loader then you've got your opti partitions for includes executables and I can't remember what D is off the top of my head then we've got boot FS which is on a format of ext4 vendor FS which is where you've got the licensing fingers if you've got anything that's gplv free you might have some vendor information stored in there and then you've got your other two partitions which is your root FS and your user FS so security so we did mention that we'll have a look at security but it's not going to be the security of the whole system that's a completely separate topic and potentially a completely separate workshop so we're now going to look at the mechanisms of protecting what goes on in the application so it's more integrity of the application so we can do MCU hardware isolation so this means that the a7 cannot corrupt anything that your m4 is doing and also we have the isolation for the arm trust zone so the secure context as we call it we've got that isolation as well so that's how you secure your m4 to work separately and your secure side of your a7 to work separately so what you have to think of is you've got the three different contexts so we have the secure a context we have the non-secure a context and we have the cortex m which is a non-secure context so each of the cortex a cores can run either the secure or non-secure context so don't think that if you're on the SDM 32 MP 151 which is a single a7 and an m4 because you've only got a single a7 you might think in that oh I can only rather run secure or non-secure you can't each core can run either of those two contexts at any time so the context look like this on the right hand side you've got your cortex m which is optional you might use that you might not want to use it on the left hand side you've got your secure which is your ROM first stage bootloader and then into secure and your first stage bootloader will then launch the non-secure which is the second stage bootloader Linux kernel space and the main applications so if you look back to our flow diagram we showed earlier on about the boot process and we now link that to our diagram here on the right you can see the flow will I have a go ROM code TFA then from TFA it'll launch U-boot or you can launch opti and ask opti to launch U-boot and then run your Linux and your main applications and then depending on what you're doing if you're using the M4 either your U-boot or your Linux can launch the firmware into the M4 this is the typical flow of what would happen depending on how secure a booting system you're running within your application peripheral assignment is one of the key features of the security you can either assign exclusively to one of the hardware context or you can share an IP block between two or all three of the execution context if you assign the court an IP to the cortex secure it means it is then not available by the M4 or the non-secure part of the a7 if you assign an IP to the cortex M the a7 be it secure or non-secure cannot access it if you assign it to be a non-secure it means then all three of the context can access it if it's allowed to so you have a sign it so it's a secure so with a cortex M or if you don't need it to be assigned specifically to either of those two and you assign it to the cortex a non-secure so there's the different context color coded and if you look in the the key in the top left you can see either assigned or shared depending on if it's a diagonal or a vertical so you can see there that some of the analog stuff is assigned to either can be assigned to either M4 or a7 some of the crypto stuff is specifically assigned to the M4 and you'll find items like the extended trust zone is specifically assigned to the a7 secure so different peripherals have the ability to be assigned in different locations depending on what they they're needed for so it's quite flexible you can play around with this and how you assign that is inside the cuba mechs and the cuba mechs is going to generate your device tree so this is where you actually assign what's going to be connected so you can see there you start one is currently being assigned to the secure and the other usurps are assigned to non-secure and you start number three is assigned to cortex M4 and you can see that the boot ROMs are coming from you start number six as your predefined serial port that's available for you so all of the device trees and the assignments of which peripherals and which areas have done it are all controlled peripheral by peripheral inside the cuba mechs tool so we'll have a play with this later on so we'll be assigning a timer later on in one of the labs and you'll be assigning it to the a7 non-secure because we will be asking the cortex M4 to do something with that timer and in another lab we'll be wanting the a7 to do something with that timer so we'll assign it to a7 non-secure and therefore that peripheral is now available to be shared by which of the context it needs to share