This blog post details how you can build and flash the ST Linux system to a SD Card.
Pre-requisites
Make sure you have the repo
tool installed. It wasn’t on my Manjaro Linux distribution of the host PC
and it isn’t available via an easy sudo apt-get install repo for Ubuntu
yet (because it wasn’t converted to Python 3 yet).
- Repo is a tool built on top of Git. Repo helps manage many Git repositories, does the uploads to revision control systems, and automates parts of the development workflow. Repo is not meant to replace Git, only to make it easier to work with Git. The repo command is an executable Python script that you can put anywhere in your path.
In the end, I installed repo on the host PC (because that was the easiest
for me). But that means, I will have to execute the repo commands from a
terminal of the host PC as well.
Building the ST distribution
I’m going to assume you followed the previous blog post about building a minimal Linux image and have its Docker container already and have it started up.
1. Cloning the openSTLinux repo
Assuming you stand in the /data/yocto-labs directory (the yocto-labs
directory was created earlier in the first blog post and is located in
the shared directory). Issue the following commands:
mkdir openstlinux-5.10-dunfell-mp1-21-03-31
cd openstlinux-5.10-dunfell-mp1-21-03-31
To download the actual openstlinux-5.10-dunfell-mp1-21-03-31 repo, issue
these commands (remember to issue these repo commands from the host PC in
case it’s installed there and not in your docker image!):
repo init -u https://github.com/STMicroelectronics/oe-manifest.git -b refs/tags/openstlinux-5.10-dunfell-mp1-21-03-31
repo sync
This will take a while.
My yocto-labs directory now contain these directories:
build
meta-openembedded
meta-st-stm32mp
openstlinux-5.10-dunfell-mp1-21-03-31
poky
The openstlinux-5.10-dunfell-mp1-21-03-31 directory is the repo you just
cloned. The other 4 directories were created during the previous blog post
and are not really needed to create a ST Linux image. You can delete these
4 directories if you feel you will not work with the minimal Linux system
setup anymore and reclaim a lot of valuable GBytes on your hard disk.
2. Initializing the OpenEmbedded build environment
Just like for a minimal Linux system build, we need to set up the build environment. This OpenEmbedded environment setup script must be run once in each new working docker terminal in which you use the BitBake or devtool tools. Be aware, this is a different script than the one we used for the minimal Linux system and is found at a different location. Use the following commands to set up the build environment (it will ask to read and accept the EULA’s as well):
cd /data/yocto-labs/openstlinux-5.10-dunfell-mp1-21-03-31
DISTRO=openstlinux-weston MACHINE=stm32mp1 source layers/meta-st/scripts/envsetup.sh
Among other things, the environment setup script creates the build directory
named build-openstlinuxweston-stm32mp1 directory. After the script has
finished, the current working directory is set to this build directory. Later,
when the build completes, it contains all the files/images created during the
build.
The local configuration file (build-openstlinuxweston-stm32mp1/conf/local.conf)
contains all local user settings. The layers configuration file
(build-openstlinuxweston-stm32mp1/conf/bblayers.conf) tells BitBake what layers
must be considered during the build.
This is the output after the setup script has run:
$ DISTRO=openstlinux-weston MACHINE=stm32mp1 source layers/meta-st/scripts/envsetup.sh
[HOST DISTRIB check]
Linux Distrib: Ubuntu
Linux Release: 20.04
Required packages for Linux Distrib:
build-essential chrpath cpio debianutils diffstat gawk gcc-multilib git iputils-ping libegl1-mesa libgmp-dev libmpc-dev libsdl1.2-dev libssl-dev pylint python3 python3-git python3-jinja2 python3-pexpect python3-pip socat texinfo unzip wget xterm xz-utils
Check OK: all required packages are installed on host.
[source layers/openembedded-core/oe-init-build-env][from nothing]
[EULA configuration]
...
Do you accept the EULA you just read? (y/n) y
EULA has been accepted.
[Configure *.conf files]
[INFO] No 'site.conf.sample' file available at /data/yocto-labs/openstlinux-5.10-dunfell-mp1-21-03-31/layers/meta-st/scripts. Create default one...
===========================================================================
Configuration files have been created for the following configuration:
DISTRO : openstlinux-weston
DISTRO_CODENAME : dunfell
MACHINE : stm32mp1
BB_NUMBER_THREADS : <no-custom-config-set>
PARALLEL_MAKE : <no-custom-config-set>
BUILDDIR : build-openstlinuxweston-stm32mp1
DOWNLOAD_DIR : <disable>
SSTATE_DIR : <disable>
SOURCE_MIRROR_URL : <no-custom-config-set>
SSTATE_MIRRORS : <disable>
WITH_EULA_ACCEPTED: YES
===========================================================================
Available images for OpenSTLinux layers are:
- Official OpenSTLinux images:
st-image-weston - OpenSTLinux weston image with basic Wayland support (if enable in distro)
- Other OpenSTLinux images:
- Supported images:
st-image-core - OpenSTLinux core image
You can now run 'bitbake <image>'
You should now be standing in this path:
/data/yocto-labs/openstlinux-5.10-dunfell-mp1-21-03-31/build-openstlinuxweston-stm32mp1
3. Building the OpenSTLinux distribution
Make sure the above environment setup script has been run!
The bitbake image command is used to build the image. image specifies the
targeted image which is st-image-weston (Weston image for OpenSTLinux with
basic Wayland support) for our purposes.
bitbake st-image-weston
Now you have to wait a long time since over 9.000 tasks need to be performed.
Creating the final image for the SD Card
I’m going to deviate from the STM advised way
which involves using STM32CubeProgrammer and fiddling with the boot switches
on the board itself. I found it easier to just flash the SD Card using dd
as in my previous blog post.
All created images in the previous step are stored in the .../yocto-labs/openstlinux-5.10-dunfell-mp1-21-03-31/build-openstlinuxweston-stm32mp1/tmp-glibc/deploy/images/stm32mp1
directory. This directory also contains a scripts subdirectory containing the
create_sdcard_from_flashlayout.sh script to create the final image to be flashed.
Again, just like the previous blog post, make sure you’re in the scripts directory
(in your docker terminal) and execute this command (I choose to use the extensible
flash layout):
cd /data/yocto-labs/openstlinux-5.10-dunfell-mp1-21-03-31/build-openstlinuxweston-stm32mp1/tmp-glibc/deploy/images/stm32mp1/scripts
./create_sdcard_from_flashlayout.sh ../flashlayout_st-image-weston/extensible/FlashLayout_sdcard_stm32mp157f-dk2-extensible.tsv
We get this output:
$ ./create_sdcard_from_flashlayout.sh ../flashlayout_st-image-weston/extensible/FlashLayout_sdcard_stm32mp157f-dk2-extensible.tsv
Create Raw empty image: ../flashlayout_st-image-weston/extensible/../../FlashLayout_sdcard_stm32mp157f-dk2-extensible.raw of 1536MB
Create partition table:
[CREATED] part 1: fsbl1 [partition size 256.0 KiB]
[CREATED] part 2: fsbl2 [partition size 256.0 KiB]
[CREATED] part 3: fip [partition size 4.0 MiB]
[CREATED] part 4: boot [partition size 64.0 MiB]
[CREATED] part 5: vendorfs [partition size 16.0 MiB]
[CREATED] part 6: rootfs [partition size 1.4 GiB]
Partition table from ../flashlayout_st-image-weston/extensible/../../FlashLayout_sdcard_stm32mp157f-dk2-extensible.raw
Populate raw image with image content:
[ FILLED ] part 1: fsbl1, image: arm-trusted-firmware/tf-a-stm32mp157f-dk2-sdcard.stm32
[ FILLED ] part 2: fsbl2, image: arm-trusted-firmware/tf-a-stm32mp157f-dk2-sdcard.stm32
[ FILLED ] part 3: fip, image: fip/fip-stm32mp157f-dk2-trusted.bin
[ FILLED ] part 4: boot, image: st-image-bootfs-openstlinux-weston-stm32mp1.ext4
[ FILLED ] part 5: vendorfs, image: st-image-vendorfs-openstlinux-weston-stm32mp1.ext4
[ FILLED ] part 6: rootfs, image: st-image-weston-openstlinux-weston-stm32mp1.ext4
###########################################################################
###########################################################################
RAW IMAGE generated: ../flashlayout_st-image-weston/extensible/../../FlashLayout_sdcard_stm32mp157f-dk2-extensible.raw
WARNING: before to use the command dd, please umount all the partitions
associated to SDCARD.
sudo umount `lsblk --list | grep mmcblk0 | grep part | gawk '{ print $7 }' | tr '\n' ' '`
To put this raw image on sdcard:
sudo dd if=../flashlayout_st-image-weston/extensible/../../FlashLayout_sdcard_stm32mp157f-dk2-extensible.raw of=/dev/mmcblk0 bs=8M conv=fdatasync status=progress
(mmcblk0 can be replaced by:
sdX if it's a device dedicated to receive the raw image
(where X can be a, b, c, d, e)
###########################################################################
###########################################################################
Flashing the image to the SD Card
These 2 files have been created in the /data/yocto-labs/openstlinux-5.10-dunfell-mp1-21-03-31/build-openstlinuxweston-stm32mp1/tmp-glibc/deploy/images/stm32mp1/
directory:
FlashLayout_sdcard_stm32mp157f-dk2-extensible.how_to_update.txtFlashLayout_sdcard_stm32mp157f-dk2-extensible.raw
The FlashLayout_sdcard_stm32mp157f-dk2-extensible.raw file is the one we need to
flash to the SD Card.
I do the un-mounting and the flashing of the SD Card in the terminal of the host PC.
So, make sure you’re in the
.../yocto-labs/openstlinux-5.10-dunfell-mp1-21-03-31/build-openstlinuxweston-stm32mp1/tmp-glibc/deploy/images/stm32mp1/scripts to have access to the images with the relative paths
I use below.
Again, just like in the previous blog post, we need to unmount our SD Card (in my
case, my SD Card is mounted on /dev/sdc):
sudo umount `lsblk --list | grep sdc | grep part | gawk '{ print $7 }' | tr '\n' ' '`
And the actual flashing with:
sudo dd if=../flashlayout_st-image-weston/extensible/../../FlashLayout_sdcard_stm32mp157f-dk2-extensible.raw of=/dev/sdc bs=8M conv=fdatasync status=progress oflag=direct
And be patient again till it’s finished (1.6 GByte will be written to the SD Card).
Testing the image
Insert the SD Card into its slot. Make sure you have a micro USB cable connected
to the CN11/ST-LINK connector of the board and use you favourite terminal
program to listen at 115.200 baud on device /dev/ttyACM0. E.g:
$ picocom -b 115200 /dev/ttyACM0
...
NOTICE: CPU: STM32MP157FAC Rev.Z
NOTICE: Model: STMicroelectronics STM32MP157F-DK2 Discovery Board
NOTICE: Board: MB1272 Var4.0 Rev.C-02
INFO: Reset reason (0x15):
INFO: Power-on Reset (rst_por)
INFO: PMIC version = 0x20
INFO: FCONF: Reading TB_FW firmware configuration file from: 0x2ffe3000
INFO: FCONF: Reading firmware configuration information for: stm32mp_io
INFO: Using SDMMC
INFO: Instance 1
INFO: Boot used partition fsbl1
...
U-Boot 2020.10-stm32mp-r1 (Oct 05 2020 - 15:15:32 +0000)
CPU: STM32MP157FAC Rev.Z
Model: STMicroelectronics STM32MP157F-DK2 Discovery Board
Board: stm32mp1 in trusted mode (st,stm32mp157f-dk2)
Board: MB1272 Var4.0 Rev.C-02
DRAM: 512 MiB
Clocks:
- MPU : 800 MHz
- MCU : 208.878 MHz
- AXI : 266.500 MHz
- PER : 24 MHz
- DDR : 533 MHz
WDT: Started with servicing (32s timeout)
NAND: 0 MiB
MMC: STM32 SD/MMC: 0, STM32 SD/MMC: 1
...
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 5.10.10 (oe-user@oe-host) (arm-ostl-linux-gnueabi-gcc (GCC) 9.3.0, GNU ld (GNU Binutils) 2.34.0.20200220) #1 SMP PREEMPT Sat Jan 23 15:04:06 UTC 2021
[ 0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
[ 0.000000] CPU: div instructions available: patching division code
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] OF: fdt: Machine model: STMicroelectronics STM32MP157F-DK2 Discovery Board
...
ST OpenSTLinux - Weston - (A Yocto Project Based Distro) 3.1-snapshot stm32mp1 ttySTM0
stm32mp1 login: root (automatic login)
Last login: Sun Sep 20 10:44:17 UTC 2020 on tty7
root@stm32mp1:~#
Adding build tools (including GCC and Nano) to the Linux system
This happens in a similar way as in the previous blog post as well. The
local.conf file to be modified is located here:
.../yocto-labs/openstlinux-5.10-dunfell-mp1-21-03-31/build-openstlinuxweston-stm32mp1/conf/
and add these lines (doesn’t seem to matter where but the space before the package name seems to be important!):
EXTRA_IMAGE_FEATURES += "tools-sdk tools-debug"
IMAGE_INSTALL_append += " nano"
The first line will append the typical GCC build tools. The second line will
add the Nano editor (in case you prefer not to work with the VI editor that is
part of the minimal Linux system).
Now rebuild the Linux system and flash it to an SD Card. If all went well, you
can now use GCC and the Nano editor natively on the STM32MP157F-DK2 board.
