 OK, roedda'n gweld lle'r cyflwyno cyffredig I MP. Dwi'n llawer yw'r software sy'n gweithio yn ystod â'r MP I. Rydw i'r cyflwno gwneud o ff sadgwysgol i gŵr ynghylch ar y cyflwyno eich L-1. Rwy'n sgwrdd yw'n sgwrdd cyflwyno cyflwyno cys idiw diogel. Rydw i'n gwiswch ar y dyn Meter Launcher i'r ffordd heddiw yw'r ysgrifau llun o'r cyflwyno cyflwyno. ST mainlining, so ST's been mainlining all our drivers so I'll show you more information about that. I have a slide from the third parties which I think you've already seen from the marketing presentation so I have a bit more detail about that. Then we'll have a look at the distribution delivery, so the items that make up the whole of the distributed package that you download as the SDK. Licensing terms, so always worth remembering that it's all software so there is licensing rules and regulations most are open but some of them aren't so you need to understand other licensing terms and then the wiki itself so we keep mentioning the wiki I'll show you a bit more detail about what's on the wiki and the type of information you're going to find on the wiki. So the software components, so we have the two components so we have the part that looks after the Cortex-A which is the open ST Linux distribution and we have the part that looks after the Cortex-M which is the cube and all the related ecosystem that has been around for the STM32 family for many many years. So on the Cortex-A side you have the two contexts so you have the secure context and the non-secure context. Each of them are completely separate you boot usually through the secure side first and then launch the non-secure side again it will depend on what you're doing in your application how you use each of those contexts during the actual application. We do phrase it as open ST Linux distribution this isn't customised it's just our way so that you know it is the one that's got all the extra drivers inside for the MP1 device but they're all open drivers so everything's out there in the community you can download any of those drivers so even though we've called it open ST Linux it's not being customised at all. So what do we have inside the architecture so at the top you've got your trusted applications which are running in your secure context and then you've got your general Linux applications which are running in the non-secure context so each of those applications you write and they will then talk to the open ST Linux distribution which is all connected to the framework and the board support package so there's two different modules that make up that as I said even though we call it open ST Linux we've mainlined 95% now of our code or drivers or anything that's related to the product so it's all out there in the community the few remaining 5% are either to do with debug or security or the graphics modules you'll see which isn't ST's IP block so so that 5% is small everything else is out there available for you. To build our distribution we've used community tools so we're using the Yocto community tools to do our building of our distribution package and the solution has also been adopted by Lenaro as well so for the secure side we're using the Lenaro devices. So if we have a look inside the distribution package we have in the application framework so underneath your trusted application we have the secure monitor and opti which is the running of the trusted application execution and then you've got the normal Linux middleware in the user space which will be running all the open sourced Linux applications like ALSA, G-Streamer, Wail and Western for graphics things like that. Each of these application frameworks will then talk to something in the open ST Linux board support package so in the case of the secure side it'll be coming up from the trusted firmware which is the first stage boot loader and the boot chain to launch that and in the general or non-secure side your second stage boot loader so you boot will be then launching your Linux kernel and all the drivers that are part of the Linux kernel so that you can run your Linux middleware applications and then on the side of that you have the code processor or the Cortex M4 this is completely separate to your Linux side and this is everything that you've ever generated with the STM32 cube you can still use operating systems in this side so things like FreeRTOS can be used to run whatever application you want to run on the Cortex M side so the open ST Linux distribution components so what do we have so this is a breakdown of a generic driver so you have your Linux application which you will be writing or you'll be sourcing from wherever that will be communicating into the Linux middlewares or the sub modules which are generic applications to do various tasks like the graphics the audio the modem comms things like that all of that happens in your user space then these Linux middlewares will talk to the kernel space and the framework that goes with each of those drivers some drivers will have sub frameworks as well and again these frameworks again are all generic community based drivers and they will then physically go and talk to the st hardware which has the driver that's provided by ST which is what we've mainlined on the community so we've opened up the access to all our drivers and in the case of graphics the green box here on the bottom right is the GC nano so it's the graphics driver it's not an ST block we've purchased it in so that one is a third party block so it's not actually controlled by ST so if you now look at all the peripheral drivers so you can see the free context at the bottom so over on the far left hand side we have the secure context where you've got opti core running secure monitor things like that and up in the user space at the top left you've got your trusted applications talking to that then in the large section in the middle you've got your nonsecure so your cortex a nonsecure where your general Linux applications will be calling all the general middle layer blocks and they will be then going into the kernel space calling the various items to do things so tty which will then call the usart driver for your communications interface suspend will be calling some of the power and reset drivers usb host will be talking to the usb peripherals rp rock will be doing all the messaging system so that you can talk to the co-processor so all of these drivers will have an st component which is driving the hardware and it'll have a community component which is providing the interface between the linux middlewares and the st physical hardware then finally on the right hand side you will have your real-time applications running on your cortex n they can be using free artists if you choose to you don't have to then you've got all the st middlewares that you'd have used in the past so if your real-time application needs to use usb so the st usb drivers will be used open amps in there so that you can communicate with the cortex a side and then you'll all have the standard howl drivers that if you've played with st m 32 before you should be familiar with the hardware abstract layer that we use for all of the st m 32 devices so if you move to the top side of that diagram now so this is now the linux middlewares which sits between all those kernel drivers you saw earlier on on the previous slide and your linux application which is right at the top so here you now have all the community based drivers like whale and western for graphical interfaces g streamer for doing the gooey alfa for your audio a few of the other ones are in there so gdb server for doing debug python for doing some core bash things like that so they're all standard applications that you've got in there which are all yocto compatible and open embedded compatible so again you're using standard drivers but this is all part of the open st linux distribution they're all standard drivers that we've taken for the ip block that's not st's ip so it's the gc nano so it's the the vanty graphical driver that we have inside the mp1 it's done by very silicon so it's the third party that we've used it's not st and all the libraries are provided in the open st linux distribution source code is available but you will have to sign an nda directly with very silicon to get the source code if not you will use binaries inside the open st linux distribution and this library pack can do open gles 1.1 and 2.0 and open vg 1.1 as well so you can get the source code in the kernel space but in the user space if you want the source code you have to sign that nda as i say there's no charge you just need to sign the nda for the cortex m side of the mp1 so the cortex m4 here you've got no restrictions you can fully reuse any stm32 mcu code you've written for cortex m4 using the how all of that can be reused so the hardware abstraction layer or low layer peripheral drivers are exactly the same if you use the middleware components like the usb the free art off lightweight ip fat ffs you can use all that when you install stm32 cube you've got hundreds of examples to show you how to use different peripherals in different ways and all of that code and examples that we produce is always going through a continual quality cycle so we're always checking getting feedback from customers for errors fixing them republishing it back on the internet so that you can download again and all our stm32 cortex m4 type software is business friendly licensed so you don't have to worry about any of the licenses and reusing any of that code as a starting point for part of your application so if we look at what you get within the cortex m world so you've got your legacies framework from all stm32 devices you have the how or the low layer api is talking directly to the hardware you have those middleware components i mentioned so lightweight ip free art off communicating either to the how or those low layer drivers if you've got add-on shields like the x nucleus so you've got the arduino connectors on the bottom of the board you can use any of the board support drivers that we've written for them so most of our devices have got board support packages so if you're using a mem sensor you'll want the driver for that mem sensor to communicate through spi or something like that so all of those softwares available and then your existing user code will be talking through a defined set of instructions or apis so any user code you've written can all be reused again inside the cortex mp1 so you've already had a look at the demo launcher so this is what we saw first thing this morning so this is the default software that should come inside the board here we've got an inbuilt application where you press on each of the icons so the camera preview you saw demonstrated earlier the ai the 3d cube the bluetooth speaker in that each of these applications uses a slightly different set of frameworks be it user space frameworks kernel space frameworks to talk to the different parts of the hardware needed to do the demonstration so we have our graphical display our application to display that is calling the dreastreamer application which is calling the wail and western drivers that's talking down into the kernel space to talk to the graphics element to use the graphics processor and it's also then driving the hardware be it hdmi or the dsi display as well to give you the image that you're seeing on the display when you run the video you get some audio so that's then calling the outer plug-in which is then using the various framework so you got the outer framework then the sub framework that goes with that which is then calling the codec driver to go on talk to the audio codec and play in the audio out either through the headphone jack or through a connected bluetooth speaker so you can see the flow there of what's going on inside the standard video playback part of the application if we look at the ai application so this is the one where we're using the cortex m side as well so we have our ai application running on our display which is asking you to enter a character so you then use the touchscreen which is in the bottom touchscreen is then communicating through an i2c driver through a kernel space driver called tsc so touchscreen control the driver into the application it's then using the gstreamer and wail and western and the graphics driver to display on the screen the character that you have just drawn on the touch pad as well as displaying that driver on the screen the application is then also using remote message to send that link with the information it's received over the ipcc and the mcu ram so it stores the information in the mcu ram communicates to the cortex mcore through the ipcc then on the cortex m side the ipcc will signify to the cortex mcore we've got a message the open amp application which is the community application will then take that message from the mcu ram through the virtual howl uart into the application which is the ai application running on the cortex m to do the analysis to decide exactly what character you have just drawn on the screen once it's decided it'll then send the message back through the virtual howl uart the open amp write the information into the mcu ram tell the ipcc to notify the cortex a side that we have information that'll come back up through the remote messaging back into the ai application running on the cortex a side to decide exactly what action you're now going to take based on the character that the ai cortex m side has decided it has just received from the touchscreen panel so mainlining so what do we mean by mainlining st has been working in the backgrounds now for the last three to four years with this mp1 device so we are over in the bottom left hand corner with a new silicon and a new board and we've been writing our drivers so we've been upstreaming those drivers into the community for people to check the quality the rules regulations of an open source driver they've then been feeding that information back to us as st and we've been modifying our drivers and then going around that loop until everybody's happy st is happy and the community's happy that all the rules and regulations have been followed and we're not generating any spurious errors into code that we've generated so linux community's been working on that with us over the last three to four years then you've got what goes on in the bottom right hand corner which is we've got no silicon and we've launching a new board so when we're launching our discovery board that you're playing with today we will then have to potentially modify some of those drivers to use the additional components that are on the main discovery boards or the eval board and again we go through that loop of modifying the drivers letting the linux community sort it out make sure we followed all the rules regulations and that and then we go around that loop for a while until everybody's happy and all our drivers are robust they're not going to cause any crashes everybody's tested things multiple times on different versions of hardware eval boards things like that to make sure there's no errors so all the information that you're downloading from the community is reliable it's been well tested and it's not going to cause you any major issues for using it so that's what main lining is it's us as st uploading it and working with the linux community to make sure everything's there and working correctly so advantages for you as a customer so it means because we've tested it all the qualities there so lots of people it's not just us as st testing it lots of people out in the community have already done tests on it so we know that there's a lot of quality control going on with running this particular process so it means it reduces a lot of risks for you because you know you're not the first person to come and test this particular driver someone else has probably tested it in that way two or three times out in the community also because we're following all these rules and regulations when we transition from one version of kernel to another and you change different platforms and port stuff scalability is always there so again you know that the transition from one version to a newer version or updating a driver from an old project to a newer project means that it's fairly seamless the process because again everybody's out there been doing all of this and because you're not having to write all the software from scratch there is a cost incentive to this so it makes good sense for you because you're relying on all these well tested drivers giving you portability and you're not having to sit down and write them all yourselves so there's a big cost incentive for you so it's mainlining process has a lot of benefits for you as a customer so how do we manage the different deliveries so we're currently over on the top left so we're currently on kernel 4.19 today that will run for the next 12 months where we will keep doing software updates evolutions fixes and modifications at the end of that 12 months we will then launch the newer core so we'll move on to the next kernel release but from that point we'll then stop doing any evolutions on kernel 4.19 but we'll keep doing fixes so we'll keep maintaining that existing kernel for at least another 12 months with the new kernel we will then go back to doing the same thing so we'll be doing evolutions and fixes for that new kernel for the first 12 months and then for the second 12 months of the newer kernel we'll then potentially upgrade kernels again and we'll carry on with just doing fixes on that previous kernel so this is I think is a standard linux timeframe diagram that you will see it's one year of evolution and fixes then one year of fixes and then you'll migrate to a slightly newer kernel and again the process will start again for support inside st we have the R&D team who've been developing all this and generating all these drivers and then mainlining them so they're all there level two support is what we call our competent centres so in the case of Europe it's based here in Prague and they've got specialised people who will talk to the R&D people if they find any issues and resolve the issue for you the customer on the far left hand side sitting between those two support centres and the designers you've got the st community so it's all the web forums and online support and you've got people like myself the fe's who are there visiting you dropping in to see how things are going and helping you getting your code up and running to get access to either the fe team or the community you either go through the forums to get into the community or you enter the ticket through the online support system so they're all web-based processes you've also got fairly small here on the diagram the partners so sat between the customer requests and the collaborative spaces there are lots of st partners out there that are certified who may be able to help you based on specific sections of code that you're using things like that and the partners are feeding directly into the st communities and sorting out issues for us and compatibility problems things like that and for downloading information we've also got the github as well so in the collaborative spaces you can pull different drivers and that down from the github so inside st is all the items in the blue and then outside you've got all the community items and this third party support people there so the ecosystem so we've already seen this from the marketing slides earlier today as well as what st is generating there are lots of say partners out there generating different things so we've got people doing trainings engineering services embedded software so you've got crank for graphics and you've got hardware tools software tools or kyle ac6 and then if you choose not to design with a chip level solution yourself you can then go to some of our components and module manufacturers they're all partners with us where you can get the DRAM the micro the power management on a little module you then attach that to your board and then you build the rest of your design so you don't have to worry about the high speed layouts parts and that so as I say there's lots of different partners out there all doing different things we have our partner services description link there on the website so you can click on that link on the slide and it'll jump you off to the at the web page to go and see what partners are out there and what they do and their exact services you saw earlier we've got different distribution packages we have three different packages available we all come together but they're different available so the starter package which is what you have running in your discovery board it's really there for evaluation purposes for you to play around the development package that's when you really want to develop your own applications modify the kernel board support items like that and then when you've done all the developing and that then you'll want to release your own distribution package so you'll then go through all customizing what you're going to release as part of your distribution package so the starter package is designed for evaluation so you can run scripts on there like bash python you can download binaries either through s copy or usb keys which we'll be doing during the day and it's got an st western image so that's our image that we've used which is a western wailing image doing the graphics it's got the default secure boot loader as the first stage boot loader then you boot as the second stage boot loader and that's all part of our starter package the developer package this is where you do most of your work when you want to write applications so you'll be able to develop any application you want using the developer package you'll be able to play around with the device trees so you can change what peripherals are in use on the target board if you want your bootchain to be optimised or different you can play around with that if you want to do more secure elements you can start adding more for the opti side and you can even start modifying the kernel itself if that's what you need to do in your application so everything's in there we provide all the images as binaries we've got all the make files available and all the source code for the modules that we're using for the kernel the u-boot and the cube m4 side so the cortex m side and then when you want to generate your distribution package we have that one so we have a distribution package it's all done with yokto in the case of us so we've run all the yokto tools on it you can run whatever bit bake and all the yokto recipes that you need to do to generate your end application and the distribution package so your distribution package will then generate a nice new developers package and a nice new starter package for you when you run that so we're not going to tell you much about yokto but we provide two different yokto layers we've got one that supports all the different boards that we've got for the mp ones and then we've got one that actually supports the actual device itself so you've got the items that are common to all boards the board support package and then things that are specific to boards like the evals got a bigger display it's got extra peripherals it's got more connectors on it and then you've got the actual Linux applications as well itself so the open st Linux applications so we've already provided all these for the yokto system so if you've got yokto tools then it should be fairly straightforward for you to generate your distribution package licensing terms each of the different elements of code will have a slightly different licensing rules and regulations and restrictions on what you can do with it the gnu.org is a great place to go and have a look for some of the more open licensing information but most of what we as st provide will be under the the bsd type licenses so you can use it without constraints there are certain items that are gplv2 the ones you probably want to be more avoiding is probably gplv3 and this is where you may have to provide your entire source code to the community if someone wanted to request it so you have to pay attention to the different licenses for each of the different software modules you're intending on pulling into your application so our general application is sla 048 it's a standard license that we have all of our components i say are fairly easy to work with the one that's probably more proprietary with a gc nano as i say it is open source but if you want the source code for that one you just have to sign an nda with um very silicon the bluetooth and the wi-fi they're a module from cyprus so they will be able to generate they can provide you with a source code for that but again it's a separate license most of the drivers i say we provide is under bsd level two or gpl version two sorry or bsd um but as i say some items are on v3 most of those are to do with um debug features and things like that so you just got to pay attention to what you're bundling inside your package and is it going to require a license so for licensing you can get more information on the wiki so there's lots of um there's actually a dedicated full dedicated section for licensing as i highlighted the wi-fi bluetooth one it's not ours so it's a mirror item module based on cyprus but it is fully open source um you just got to see what the licensing agreements are with that one and mainly it's the the graphics one you have to pay attention to so the video for that side of things but all the other codecs are open source and it's all part of the open st linux so the wiki so we keep mentioning this wiki we keep giving you links to different pages so here's a few shots of what actually the the wiki is so here we've got the the main landing page wiki.st.com you've got your main headers which is the welcome the reading tips the getting started guide for what you'll be using most it'll be in the development zone so the development zone obviously you've got things about the embedded software the tools the device itself getting started is where you select which board you're on and it gives you a quick up and running with the getting started development zone has got a lot more information obviously the prerequisites that you need for your environment your host environment you can see release notes about the ecosystem the open st linux package any of the cube programmer packages that you might need to program the device you can get all the information that we've just seen on the slides about the starter package developer package distribution package more detail about what you can and can't do in each of those different packages you can have a look into the embedded softwares for either the cube side or the open st linux side so again you've got both sides in there you can drop down into the open st linux distribution have a look at the different layers and images that we've got you can drop down all the way into the drivers for the framework drivers the user space drivers the actual physical hardware drivers for the howl or the low layer all the other different components that make up the embedded software so the links for those you can go into the operating system itself so you can actually go and have a look at the things like the analog and have a look at the different subsystems that we've got into the linux operating system and then you can even dive straight into say an i2t overview of what parts are doing what and either the user space or the kernel space and things like that and have a look at the api descriptions for each of those i2t commands as that slide is showing there same again with the middlewares so that's the outer overview there so you can have a look at them even after the middlewares rather than the specific drivers as well then finally when you get round to doing tracing debug there's a chapter on that inside the wiki as well so you can have a look at the debugging tools monitoring tools and different tracing tools how to debug for tfa how to debug for uboot how to debug for opti gdb server commands things like that so you've got lots of information inside here in the wiki so what actually do we have again just to summarize for the embedded software section we've made code generation easy so all the drivers have been mainland you can download them from the web as i said we call it open st linux it's not customized everything is being pulled directly from the web based on information that we've already sent up to the web again because it's mainline you can ensure that the quality is there you know that there's a community out there that's doing all the testing of our drivers that we're doing you can implement things fairly easy if something updates you can migrate across really easily if you're playing around with the cortex m4 side any of the code that you've previously done on another project for m4 can be reused inside there and when it comes to building your whole application we're using community tools like yokto and that to actually generate the actual distribution packages so you can see that there's lots out there that can make your life fairly easy and fairly fast to get started with the stm32 mp1