This external buildroot layer provides a basic support package for the SMARC-sAL28 board. It is an extenstion to buildroot which is provided outside of the standard buildroot tree.
The Kontron SMARC-sAL28 board is an upcoming product not yet available. This layer does not provide the full functionality of the board. Instead its intention is to be used to create a small footprint filesystem image as well as to be easy to use.
Esp. this layer lacks the following functionalities:
- 3D GPU support
- KEAPI
If you need the full functionality it is recommanded to use the Yocto Project layer provided together with the board.
The external is tested on Debian 10. The following system build dependencies are required (by buildroot itself).
apt install which sed make binutils build-essential gcc g++ \
bash patch gzip bzip2 perl tar cpio python unzip rsync file \
bc wget libncurses5-dev git subversion
This layer was tested on buildroot version 2020.08.
You have to clone buildroot and this layer. When building, use the
appropriate defconfig in the buildroot-external-smarc-sal28/configs
directory.
git clone git://git.busybox.net/buildroot -b 2021.02
git clone https://github.com/kontron/buildroot-external-smarc-sal28.git
mkdir build
cd build
make -C ../buildroot BR2_EXTERNAL=../buildroot-external-smarc-sal28 O=`pwd` kontron_smarc_sal28_defconfig
make
The resulting bootloader, kernel, root filesystem and SPI flash image will
be put in the build/images directory.
After building, there will be three images. The images/spi-flash.img is a
complete flash image which can be programmed into SPI flash. Please note,
that the first half of the SPI flash is usually write protected and can not
be programmed. Just write the second half of the image. This section will
contain the standard bootloader which is started by default. Alternatively,
you can program the whole image; in this case the programming of the first
half will silently fail u-boot, because it is write-protected by Kontron.
The images/sdcard-emmc.img contains an image which can be transferred to the
eMMC on the board as well as to an SD card. It contains two partitions, one
which holds the kernel and device trees and one for the root filesystem.
Additionally, there is a reset configuration word (RCW) as well as a
bootloader. These are loaded during SDHC boot (see next paragraph) or
during eMMC boot. For normal SPI boot these two components are not needed.
The boot partition also contains a boot.cmd script which is started
automatically by the bootloader. The behaviour of the script can be
influenced by environment variables stored in the bootloader. See
here for details.
This image can also be used for SDHC boot. Use the SMARC test mode to enable it. This is a last resort booting mechanism which does not depend on any other flash content on the board and works in every case.
The images/spi-flash-updater.img is an update image which can be
flashed to any block device which is supported as a boot device by the
board. For example, you can put it on an USB thumb drive. If the board is
configured to boot from USB, it will automatically load the updater. It
will update the user-writeable part of the SPI flash, ie. the bootloader.
Please note, that this is fail-safe as there is always a second,
write-protected bootloader. You can switch of the interactive behaviour of
the script by setting the environment variable non_interactive_update to
a non-empty value. Be careful with that!
The images/spi-flash-updater.zip contains the same files as the
corresponding image. Only difference is that you can extract the files
directly onto a pre-formatted storage device like an USB thumb drive. The
files have to be put into the root folder of the drive.
For further details about the processor's boot process see the documentation of the board in u-boot and the documentation of the rcw.
This external supports the concept of Generic Distribution Boot of the
u-boot bootloader. In a nutshell, the bootloader will search storage media
for a script with a specific name (by default boot.cmd) and run it. The
user can define a search order. All in all, it mimicks the behaviour of a
PC bios.
The boot script provided with this external loads the device trees, device
tree overlays, sets the root filesystem device (root= kernel parameter)
and finally loads and executes the kernel. Which device tree overlay is
loaded depends on u-boot environment variables.
First the device tree overlay for the board variant is loaded by looking at
the variant environment variable. This variable is set automatically be
the bootloader. After that, if there is a carrier variable set, it loads
the corresponding overlay. Finally, there is a generic overlays variable,
where you can store any additional overlays names. They are loaded in the
order of appearance. All overlays have to be in the overlays/ directory
of the same storage device where the boot.cmd is stored. See the table
below for more details.
| Variable | Description |
|---|---|
| variant | Loads sl28-variant${variant}.dtbo |
| carrier | If exists, loads carrier-${carrier}.dtbo |
| overlays | Space separated list of additional overlays to load |
| extrabootargs | Additional command line parameters appended to bootargs |
You can find the source at board/kontron/smarc-sal28/boot.cmd.
This project is licensed under the GPLv2 or later with exceptions. See
the COPYING file for more information. Buildroot is licensed under the
GPLv2 or later with exceptions.