September 21st, 2020 tools Creating an STM32MP1 Linux platform with Ac6 System Workbench for Linux
Abstract
Ac6 System Workbench for Linux is an integrated development environment for Linux embedded systems development. It provides a unified environment for the whole Linux‐based embedded system development process. Of course there are a few other solutions, some of them open‐source, but they need to combine independent tools, some command line based, some with a graphical user interface. System Workbench for Linux is the only one to integrate the whole process in a single tool. Furthermore it can be integrated with most microcontroller IDEs based on Eclipse, like System Workbench for STM32 or CubeIDE, to support development of asymmetric multicore systems combining the real‐time capacities of a microcontroller running a bare‐metal or RTOS‐based applications and the flexibility of a Linux‐ based application.
Open Source Solutions
Various free solutions exist on the market to support some of these different steps. Independent tools exist for application development, configuration management, platform building, etc. However, no global solution takes care of the whole embedded system development; moreover existing partial solutions for platform development have various pros and cons, as developed below. Buildroot o Relatively friendly tool which can build a cross‐toolchain and a Linux platform. o The platform configuration is menu‐driven into a terminal‐like interface (menuconfig). o It doesn’t manage the Linux kernel modifications, without manually changing the kernel configuration data provided by buildroot. o It cannot simply store a complete configuration, without manual manipulations to save and restore it. o Adding new packages to buildroot require modifying the buildroot tool itself, editing and modifying script files. o It doesn’t manage applications development. o It generates an “empty” platform without the applications which, later, requires manual integration.
Assistance Conseil Systèmes SAS au capital de 138600€ ‐ SIRET 449 597 103 00026 ‐ RCS Nanterre ‐ NAF 6202A 21, rue Pierre Curie ‐ 92400 Courbevoie ‐ Tél : 01.41.16.80.10 ‐ Fax : 01.41.16.07.78 http://www.ac6‐tools.com Yocto o As buildroot, yocto build the toolchain and the Linux platform to be embedded. o Creating a new platform or adding new packages requires scripts edition in a specific language (bitbake). o It cannot simply store a complete configuration, without manual manipulations to save and restore it. o Yocto generates an “empty” platform without the applications which, later, requires manual integration. o There is an Eclipse plugin for application development targeting an existing Yocto platform. The main drawbacks of these solutions are they need to be complemented by additional tools that do not fit nicely in their architecture and do not provide an Integrated Development Enviroment but are mostly command line oriented. Furthermore they are needing quite a lot of specific Linux packages to be pre‐installed, with a complex installation procedure.
System Workbench for Linux
Ac6 System Workbench for Linux is an Integrated Development Environment that assists the developer in all steps of an embedded system realization: Kernel configuration and specific drivers development o Even when using a standard board, it is often needed to adapt the kernel configuration. o You will thus need to tailor the device‐tree, that System Workbench for Linux will automatically compile and deploy. o System Workbench for Linux also allows you to edit the default kernel configuration to fit your needs Choice of applicative packages to integrate in the system image. Building packages o These packages can use various build mechanisms (eg auto‐tools, make, cmake…), which are managed and automated. Development, test and validation of your application o To build a full system, System Worknech for Linux assists the development team in developing and debugging the application. o Being based on Eclipse, with automatic cross‐development adaptation, you may benefit of all the Eclipse ecosystem (Source Code Management Systems, syntactic editing, static code analysis, unit and integration tests…). 2) Support of asymmetric multicore environments Building the final image o Depending on the hardware platform, various options must be provided for deployment on diskless systems (NOR or NAND flashes, SD cards, eMMC…). o Update mechanisms are also supported by System Workbench for Linux. Configuration management of your embedded system o Embedded systems are often tailored for each specific customer o Configuration tools are included to be able to manage several variants of a base configuration
Creating a Linux-based Embedded System with System Workbench for Linux:
Ac6 System Workbench for Linux provides, in a single tool, all features needed for developing a Linux‐based embedded system. We will see here how to create a Linux platform and develop a simple application.
Page 2 sur 14 Installing System Workbench for Linux Installing System Workbench for Linux is very simple and has a very small set of prerequisites: You must have a basic Linux development workstation, with a few tools available: o The GCC compiler, for C and C++ (provided by build‐essential on Ubuntu) o Pkg‐config o Git o Curl o Gawk o Fakeroot o Python You must download the System Workbench for Linux (sw4l in short) installer (may ask for sudo privileges if it needs to install packages): https://www.ac6‐tools.com/download.php?file=sw4l‐install.sh Then execute it (you may have to set the executable attribute by “chmod a+x installer” or execute it through bash) o By default it will propose to install SW4L in the directory $HOME/Ac6, but you may choose another one. o Be careful that you must have write permission in this directory o If the directory already exist, you will be asked if you want to install there, in which case you may replace an existing SW4L installation. You may then have to type your password for sudo, if some required packages are missing. If you don’t have sudo privilege, you should arrange for your system administrator to install the required packages. Then the installation should proceed unattended and, on gnome‐based desktops, should create a nice System Workbench for Linux launcher icon. By clicking this icon, you will start System Workbench for Linux and will be asked to select a workspace, in which you will develop all the elements attached to a given platform: the platform itself (only one per workspace), the linux kernel(s) and root file‐system(s); you may have several of these, for various product configurations for example.
Page 3 sur 14 System Workbench for Linux license To be able to use System Workbench for Linux you will need a license. You can obtain an evaluation license by sending us an email with the MAC address of the machine on which you would like to evaluate System Workbench for Linux. The simplest way to get the proper MAC address is to start System Workbench for Linux then open the Preferences dialog, go to the System Workbench for Linux License tab and select the Ethernet interface to use:
Once you get the license file, just reopen the same dialog and select the received file.
Creating a basic platform The first thing to do to work under System Workbench for Linux will be to create a platform for your board. Here we will target an STM32MP1 evaluation board, the STM32MP157‐dk2 board: This board is a simple yet complete board supporting Linux on a dual Cortex‐A7 based System on Chip from STMicroelectronics. We will create an operational platform on this board and use it to develop a simple application (the ubiquitous “Hello World” application). This board includes a high resolution LCD screen and System Workbench for Linux supports the various Linux multimedia components, like gstreamer, as well as the most popular GUI toolkits like Qt. To create a platform, the simplest way to go is to import one of the predefined platforms and, if needed, to tailor it to your needs:
Once the platform is created you may open the project and the ac6_platform_manifest.xml file:
Page 4 sur 14
The Package Tree tab (pictured above) is the heart of System Workbench for Linux; apart from a few global actions most work will be done from this tab. Here you find all defined packages that may be included in root filesystems, with a tree representation of their dependencies; you can then build individual packages (and all those they depend upon if they were not yet built); here you can also add new packages, either from a library (as we will see later) or from a tarball obtained by exporting a package from another workspace). Then you may explore the various tabs of the platform project; apart from the the most interesting tab is the Linux Kernel and Rootfs tab:
Here you can see that the default platform provides a single Linux kernel (a platform may propose several kernels, usually of various versions or configurations) and four root filesystems:
Page 5 sur 14 minimal‐rootfs, which is a small filesystem, with just the most basic tools (provided by busybox) and the required watchdog daemon (to avoid spurious resets when due to the watchdog expiring), as well as the various tools and configuration needed to be able to debug application programs on the target. multimedia‐rootfs, containing also graphic multimedia packages: o gstreamer: the standard Linux multimedia handling framework o openCV: for image analysis, pattern recognition… o Qt5: the Graphical User Interface toolkit o tslib: the touch‐screen management library o Weston and Wayland for managing the graphical screen demo‐rootfs, a version of the multimedia rootfs supporting audio and including various demo programs for gstreamer, opencv and Weston full‐rootfs, a rootfilesystem including most non‐conflicting packages of the platform (at the notable exception of X11 as it also is based on Weston/Wayland) The other tabs allow to select the target board and build tool Configurations (Configurations) or edit the Platform Properties. The most often modified field here is, in Platform Properties, the Download directory field; all downloaded files will be placed here. The default is to save all downloads in the sources directory of the current workspace but it is quite common to share this directory between all your System Workbench fo Linux workspaces to save network bandwidth and delays. This directory can be shared by several workspaces, even used by different users; it can even be shared on a local area network.
Building a platform Building the platform can be done in various ways; the most common is to select a root filesystem and build it by right‐clicking on it and selecting Build (or typing the F8 key):
After a while, the duration will depend on your system configuration, the build will finish with a task completion message:
Page 6 sur 14
The generated image will be located in the rootfs project (here minimal‐rootfs_1.1.0‐r0). Kernel images (Image, uImage and vmlinux) will be in output/boot while root filesystem images will be in output/images (here minimal‐rootfs_1.1.0‐r0‐rootfs‐STM32MP157C‐DK2‐20200919210210.tar.bz2, where the figure string at the end provides the date at which rootfs generation was started, with a symbolic link to the latest rootfs generated in minimal‐rootfs_1.1.0‐r0‐rootfs‐STM32MP157C‐DK2‐latest.tar.bz2). Be careful: the output/rootfs directory is an image of the generated root filesystem; however it is an incomplete image, as files does not have the proper owner/group and permissions. This directory was generated in a fakeroot environment which simulate root privileges by recording, in an overlay file, what actions were required and what effect they should have had on the real files so that, later on, when reading this directory in the same fakeroot environment you see the proper file permissions. However, if you make any modification outside the fakeroot environment, you will break the whole thing and may get bizarre behaviours, like files having the wrong permissions or even the wrong content. You can choose the format of the generated images by opening the rootfs manifest (ac6_rootfs_manifest). There you can choose (in tab File System Skeleton) which files you need, for example in /etc, which separate filesystems you want to generate (in tab Fstab Editor), or in which format you will want to have the root filesystem (and separate filesystems if needed) generated.
It is also simple to build all the defined root filesystems or, by the way, all kernels or all packages, by opening the Platform Properties tab of the platform project manifest, opening the Global Build Steps section at the bottom by clicking its label (it is closed by default) then select Build All Rootfs and click on Execute:
Page 7 sur 14
Extending the platform There are several reasons to extend a platform: integrating your own application programs or adding existing open‐source packages. Both possibilities are supported by System Workbench for Linux; here we will explore integrating your own application, developed on Eclipse. For this you must first create an application using Eclipse CDT by selecting File New Project… (you may also right‐click in the Project Explorer pane), then select C Project and click Next For this example we will create the ubiquitous Hello world program; you should choose a name for your project (here hello) and choose a project Type (here to simplify we choose Hello World ANSI C Project).
Page 8 sur 14
Once you clicked on Next you will have to provide the characteristics of the project: you should fill the Author field but may leave everything else unchanged (keep the Cross GCC toolchain), clicking Next until you get the Cross GCC configuration page that you must leave empty (it will be filled automatically when added to the platform) then click Finish. When proposed to switch to the C/C++ perspective keep the Ac6 Platform perspective as we will have to interact with System Workbench for Linux to integrate your program in the platform to compile it using the installed cross‐compiler. You may then edit your program, but do not compile it now, as it will be compiled as a native program (you do not yet link it to your platform).
To integrate your new program in the platform you have to create a new System Workbench for Linux package: For this select again the platform manifest editor the right‐click in the Package Tree and select Add Package Import Package From workspace :
This will bring a project selector showing all projects in the current workspace which are not already part of your platform (here there is only your newly‐created hello project); select it and click OK.
Page 9 sur 14
You will then have to provide a few characteristics of your package; you may leave all these unchanged as the values are appropriate here; for a real program you may have to adjust the version of your package (that is the version of the code of your package) or the revision of the package recipe (if you create a new package recipe for the same package version, adding patches for example or changing the build step scripts). Then you may again click OK to create the package hello in the platform, allowing you to compile it by right‐ clicking it and select Build from the contextual menu…
Integrating your application in your root filesystem Once your application is compiled, you may test it on the platform by using the debugging features of System Workbench for Linux that will be described in detail in another white paper (These are using extensively the CDT debugging features, so if you are used to them you will feel comfortable developing under System Workbench for Linux). However, your program is not yet available in your root file‐system. To deploy it automatically you will have to modify slightly your root file‐system by adding your program to the list of programs required in the file‐system. For this you must select the Linux Kernel and Rootfs tab of the platform manifest and double‐click (or select Properties from its contextual menu) the minimal‐rootfs that we already built (or any other filesystem that fits your needs) ; this will open the root file‐system properties dialog that allows you to choose which features from the platform should be placed in the file‐system.
Page 10 sur 14 Here we are interested mainly in the Rootfs pane where you should check the packages that you really need in your system; here busybox, minimal‐ image, tools‐debug and watchdogd are already selected. You must check your hello package and click OK. Note that all dependencies for the checked items will also be included in the file‐system image created; some were defined when creating the package (mainly dependencies on other programs), some are automatically discovered when building a package (that is the case for all shared libraries used by a program). Then you may build again your root file‐system (right‐click and Build); this will check that all needed packages are up‐to‐date (this should be the case) and rebuild the root file‐system images.
Deploying and testing the generated images over the network We will deploy the created image using TFTP and NFS from our Linux box; such a setup is very convenient when developing an embedding system. This will need a few steps (the first one only has to be done once): 1) Setup the TFTP and NFS servers, to export from /tftpboot You must provide a Ethernet connection direct to your target board (typically using an USB dongle) and program it to use IP address 192.168.233.1 For TFTP, set it according to its documentation to have it export the /tftpboot tree in secure mode (that is by doing a chroot to /tftpboot) Ensure you can write in /tftpboot For NFS, you must add the following line in the /etc/exports file /tftpboot *(rm,sync,no_subtree_check,no_root_squash) Force the NFS server to re‐read the configuration file: $ sudo exportfs -r 2) Deploy the kernel and the device tree Go to the minimal‐rootfs directory in the System Workbench for Linux workspace: $ cp output/boot/uImage /tftpboot/uImage-stm32mp157c-dk2 $ cp output/boot/stm32mp157c-dk2.dtb /tftpboot/uImage-stm32mp157c-dk2.dtb 3) Deploy the root file‐system image Still from the minimal‐rootfs extract the generated filesystem in /tftpboot: o The sudo call below is mandatory; if you forget it Linux will not boot correctly on the target board as files will have neither the proper owner (root) not the proper permissions $ mkdir -p /tftpboot/rootfs-stm32mp157c-dk2 $ sudo tar xf output/images/minimal-rootfs_1.1.0-r0-rootfs-STM32MP157C-DK2- latest.tar.bz2 -C /tftpboot/rootfs-stm32mp157c-dk2 4) Set the u‐boot environment to boot from the network Open a gtkterm virtual terminal and go to Configuration Port
Page 11 sur 14 o Select the debug serial line of the board (should be /dev/ttyACM0) o Set it at 115200 bauds, 8 bits, no parity o Go to the Advanced Configuration Options of the Serial Port configuration and set a 50 milliseconds End of line delay (this is needed as u‐boot manages the serial line by polling and must have time to execute the previous command before you send the next one). o You may save the configuration by Configuration Save configuration Create a file (for example ~/Ac6/uboot_stm32mp157c-dk2.env) and fill it with the following data: setenv initrd_addr '0x43800000' setenv ipaddr '192.168.233.129' setenv serverip '192.168.233.1' setenv gatewayip '192.168.233.1' setenv netmask '255.255.255.0' setenv image 'uImage' setenv boardname 'stm32mp157c-dk2' setenv bootdelay '3' setenv s_bootfile 'setenv bootfile ${image}-${boardname}' setenv s_fdt_file 'setenv fdt_file ${image}-${boardname}.dtb' setenv loadaddr '0xC1000000' setenv fdt_addr '0xC4000000' setenv s_nfsroot 'setenv nfsroot /tftpboot/rootfs-${boardname}' setenv ipargs 'setenv bootargs ${bootargs} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${boardname}:eth0:off' setenv nfsargs 'run s_nfsroot; setenv bootargs ${bootargs} root=/dev/nfs rw nfsroot=${nfsroot},vers=3' setenv bootwithdtb 'bootm ${loadaddr} - ${fdt_addr}' setenv bootwithinitrd 'bootm ${loadaddr} ${initrd_addr} ${fdt_addr}' setenv tftpwithdtb 'run s_bootfile s_fdt_file; tftp ${loadaddr} ${bootfile}; tftp ${fdt_addr} ${fdt_file}' setenv nfsload 'run tftpwithdtb ipargs nfsargs' setenv bootcmd 'run nfsload; run bootwithdtb' setenv fitload 'run s_bootfile s_fdt_file ipargs nfsargs; tftp ${loadaddr} ${fitimage_file}' setenv fitbootcmd 'run fitload; bootm ${loadaddr}' setenv splashimage ‘0xc0800000’ setenv splashpos 'm,m' setenv splashsource 'mmc0' run bootcmd Then, after having stopped the u‐boot automatic boot by typing any key during the boot process, send the file by using the menu command File Send Raw File and selecting the file above Ideally we should save this environment using the saveenv u‐boot command o However, on this board, the saveenv command is not implemented, as there is no space where to save the environment o We must then send again the environment at each reboot… 5) Look the system boot your image and check that your hello program was automatically installed in /usr/bin (that may be changed if needed by parameterizing the hello package we have created):
Page 12 sur 14
Extend platform from the library Suppose we want to add a new function to our platform, for example we want to create an IoT edge device, so need support fro IoT protocols, like MQTT and the like. For this we can import new packages from the package library; Here we will just right click somewhere in the Package Tree Editor and select Add Package >> Import Package >> From Library; this will open a package selection dialog where you can either browse the whole set of packages compatible with the platform’s architecture, or select a specific category. Here as there is not IoT‐devoted category we will look in the Unclassified category where you find all packages that do not fit in one of the predefined categories, where we will select the iot‐server‐image package group Then, as there are a few ambiguous dependencies (that may be satisfied by several packages), the tool ask us to choose which one we want to install (here we choose texinfo‐native for example).
Then the required package, and all the packages it was depending upon, will be imported in the platform:
All that remains to do is to add the iot‐server‐image package group to the desired roots and rebuild it.
Page 13 sur 14 Deploy on an SDcard Although deploying on the network is convenient in development, final deployment will often use some sort of local storage, which is often an SDcard or an eMMC (which is a soldered MMC card) as these devices offer high capacities in a small form factor using cost‐effective devices. To deploy on an SDCard, we create a specific rootfs project, named minimal‐rootfs‐sdcard in this example, and ask to generate an SDCard image. Don’t forget to insert your fancy new HelloWorld program. Then you can define the properties and the layout of the SDCard by using the SDCard Layout Editor, which propose two main editing windows, the SDCard Properties editor and the SDCard Partition editor. Note that there are two FSBL (First Stage Boot Loader) partitions defined for STM32MP1 chips; by default they have the same content but, when implementing a safe boot process (that we will describe in detail in a coming white paper), the first one will hold the trusted firmware and the second one the non‐secure first stage bootloader.
The ssbl is the Second‐Stage BootLoader (typically u‐boot) then the bootfs partition will hold the boot files (linux kernel and DTB) and the rootfs the root filesystem itself (that do not need to contain the boot files). Then you just build the rootfs‐project from the platform Linux Kernel and Rootfs pane. The generated SDCard image will then be available at the root of the rootfs project in file stm32mp1dx2.sdcard. This is a 2GB file (the size defined for the SDCard) that you can flash to the SDCard by a simple dd command: sudo dd if=stm32mp1dx2.sdcard of=/dev/sdb bs=1M assuming your sdcard was mounted on a device named /dev/sdb on your Linux PC (WARNING: be careful and check twice this is the right name for your SDCard drive, otherwise you may crash your development workstation!...); the sudo prefix is needed as accessing raw block devices is usually reserved to the super user. Then you just can plug the SDCard in your SDCard slot on the evaluation board and it will boot your newly developed Linux system, including your HelloWorld program (if you insert it in the image before building it).
Page 14 sur 14