We have recently developed and now maintain the meta-morello Yocto layer for ARM’s Morello board which has now became part of the official software stack. The layer is capable of providing the firmware image that goes on the SD card and a bootable image with Linux that goes on the USB stick, these two images combined result in a running Linux distribution on the board. This blog post provides an overview on how to use the layer.
The meta-morello layer depends on the fine work done at meta-arm but one does not need to worry about downloading the dependencies. The meta-morello layer is utilising the kas build system to checkout all of its dependencies and to handle the image build, hence our first step on the glorious path of Morello Linux enlightenment is to get ‘kas’. We can do this using ‘pip’:
$ pip3 install kasNow we can checkout the actual meta-morello repo and 'cd‘ into it to run the build:
$ git clone -b release-1.5 https://git.morello-project.org/morello/meta-morello meta-morello
$ cd meta-morello
$ kas build ./kas/morello-soc.ymlNote that you should always try to base your work on the release branch. By the virtue of utilising ‘kas’ the whole Yocto-fetch-and-build-process is being reduced to a single line and we like that, no more writing out manifest files, much win. You can learn more about ‘kas’ from Jon Mason’s great presentation, we are already using ‘kas’ in other projects and plan to do so in the future.
The build itself might take a while however…so make sure you have other useful things to do and preferably on a different machine for the next hour or so. The images can then be found in the ‘build/tmp-soc/deploy/images/morello-soc’ folder. With images built and ready, we use 'dd‘ to place them on our removable disks:
$ cd build/tmp-soc/deploy/images/morello-soc
$ dd if=morello-linux-image-c64-glibc.img of=/dev/disk/usb conv=fsync bs=8M status=progress
$ sync
$ dd if=board-firmware-sd-image.img of=/dev/disk/sd conv=fsync bs=8M status=progress
$ sync
Do not forget to sync and flush those buffers ! We explicitly mention this triviality as some users had issues by skipping this very step, indeed it is sometimes very easy to forget about the basics. Now armed with the said images you can plug the removable disks into your Morello board and that is it, the board is ready to run. The next action one needs to execute is to press the ESC key during the boot process and choose the USB stick as the booting media in the ‘Boot Manager’ section. If your drive is not listed there then either the Morello board does not recognise your USB stick or the image transfer was erroneous. However if all goes according to plan then one should have been presented with the following options in GRUB:
The first aspect to take note of is that all of the available options will have the Linux kernel with transitional kernel-user ABI on board, thus the security features inferred by the capability data type are not enforced on the boundary and the implementation is limited to a few number of syscalls.
The first and second GRUB options will provide the default Yocto ‘core-minimal-image’ as the system rootfs, with the GNU C library and nearly all of the software running in the A64 mode. There is a sysroot located at ‘usr/lib/aarch64-linux-musl_purecap’ for applications that were compiled using Morello LLVM and that will use the ‘purecap‘ musl C library instead. One can find a symbolic link located at ‘lib/ld-musl-aarch64_purecap.so.1’ that links into ‘/usr/lib/aarch64-linux-musl_purecap/usr/lib/libc.so’ which is required at runtime by ‘purecap’ applications – it is their dynamic linker. In a ‘musl’ system the dynamic linker is merged with the C library itself. We do explain what C64 and A64 entail a bit in our previous blog post.
Moving on, the Yocto layer provides a simple framework for adding more C64 applications to get you started, just follow what has been done here. This application can be found in the 'pure-cap-apps‘ folder on the target and is the very same that we have used in our previous blog post on Android. The rootfs image also contains a capability aware gdb and the LLVM toolchain itself, so one can use ‘llvm-objdump’ and other niceties to aid the development process.
The third GRUB option will boot into an initramfs with a pure C64 environment where ‘musl’ is the only lib C, one will get a ‘purecap’ version of Busybox but also gdb, LLVM and the demo application as in the previous two options.
Upon a successful boot of the Morello board one can finally get to the login screen which should manifest itself in the following form as depicted here:
If you do not happen to have the hardware then do not worry as not all hope is lost – the meta-morello layer has got you covered, you can just use the FVP model instead. To enable that feature one needs to run the following build command:
$ kas build ./kas/morello-fvp.ymlThe images tailored towards FVP can be found in the ‘build/tmp-fvp/deploy/images/morello-fvp’ folder. The ‘morello-fvp’ machine inherits the ‘fvpboot’ class provided with the ‘met-arm’ layer, the functionality embedded in that class will download the FVP model and also write out a configuration file in ‘.fvpconf’ format (which is a ‘json’ file) based on Yocto variables defined within the ‘morello-fvp’ machine configuration. The said configuration file is then parsed by a Python script and fed to the FVP executable, it is highly recommended to go over the detailed instructions. To find all available parameters the FVP model can support, issue the following command:
$ ./build/tmp-fvp/sysroots-components/x86_64/fvp-morello-native/usr/bin/FVP_Morello -lFinally to run the Linux image on the Morello FVP model just run:
$ cd poky
$ . oe-init-build-env ../build
$ ./../meta-arm/scripts/runfvp --console tmp-fvp/deploy/images/morello-fvp/rootfs-morello-fvp.fvpconfYou should be faced with the familiar terminal output from the AP UART and be able to observe the usual boot log following up to the highly anticipated login screen:
There are few limitations on what is available as at this point in time there are no commonly used user-space libraries ported to C64 yet, this will be done in the future when ‘purecap’ GNU toolchain and GNU C library will arrive later on this year. There is plethora of libraries that were already ported to CHERI BSD and this can be used as your starting point if necessary.
To conclude we went over on how to use the layer and shallowly went over some of its features, hopefully this is enough to get you started, good luck.
We welcome contributions through the mailing list found at:
https://op-lists.linaro.org/mailman3/lists/linux-morello-distros.op-lists.linaro.org