TLDR: Jupiter Nano comes with the ability to make a Debian image. In their documentation section for Yocto image support, Starcat mentions that the Jupiter Nano is a like a miniature SAMA5D2 Xplained board. However, to really do more with the board, you need a dedicated Yocto machine support – in this post, I will take you through how I enabled Yocto support for this open-source hardware board.
This is part 3 in a series that I am writing about the Jupiter Nano board. I love this board primarily because it is a microcontroller kit AND a linux kit in a tiny form-factor! In other words, you can choose to boot linux or you can choose to use it as a microcontroller.
You can check out parts 1 and 2 at the below locations.
It is very easy to start off with the Jupiter Nano as it comes with a convenient Debian image support. However, most embedded linux developers prefer Yocto as the option to generate images and SDKs tightly coupled to their hardware. What is Yocto, you ask? Check out this primer about what Yocto is and how it can help you become a better embedded linux engineer.
According to the makers of Jupiter Nano, you can use the SAMA5D2 Xplained as the Yocto machine. However, I differ slightly in this regard. Although the processor is the same on both boards, the DDRAM on both boards is different, the clock source on both boards is different and most importantly – the device tree also varies greatly!
In order to be able to do stuff with it in the future, I decided to enable proper Yocto support for this board – this post talks about the process I followed for this.
Hope you enjoy the read!
The Big Picture
For us to be able to generate a Yocto image for any general machine, we need a machine configuration to be in place. A machine configuration tells the build system what kind of image we want, the names of the bootloaders, the providers for the various components like linux kernel, any special software needed to be loaded (eg: secure OS like OP-TEE), and much more.
You also need various other items in place like the linux kernel recipes, bootloader recipes, image recipes and so on. Specifically for the Jupiter Nano, the below diagram explains what components are needed to be added or modified in the meta-atmel layer in order to successfully build a Yocto image.
Modification #1 – AT91Bootstrap
The AT91Bootstrap is modified to add support for the Jupiter Nano. A new board configuration is added using the SAMA5D27-WLSOM1-EK as the base configuration. The new configuration is written to load the u-boot binary named u-boot.bin into the LPDDR2 after configuring the clocks, serial console output and of course, the LPDDR2 itself!
This modified at91bootstrap can be found here.
Modification #2 – U-boot
The U-boot is modified to add support for the Jupiter Nano. A new board configuration and C source is added that implements functions for configuring the LPDDR2, the LED to be turned on, etc. Also, various modifications are done to the Kconfig menu and related Makefiles that will allow selection of the Jupiter Nano board. Also, a bare minimum device tree is added.
The modified u-boot can be found here.
Modification #3 – Linux Kernel
The linux kernel is modified to add support for the Jupiter Nano. A new device tree is added that configures UART, SPI and I2C peripherals on the Jupiter Nano. Refer the device tree for exact pins configured to behave so. Also, modification is done to mach-at91 Makefile to facilitate a successful build when the Jupiter Nano device tree is selected.
The modified linux kernel can be found here.
Modification #4 – Meta-atmel (bitbake layer)
As shown in the diagram above, a new machine configuration file is added for the Jupiter Nano machine. This machine configuration specifies the names of the at91bootstrap configuration, the u-boot configuration, the device tree files to be used with the linux kernel, etc. These configurations are already added as commits to the corresponding repos linked above.
Other than the machine configuration file, the at91bootstrap, u-boot and linux kernel recipes are modified to tell bitbake to find the software at the modified repos i.e. at GitHub/sckulkarni246.
The modified meta-atmel can be found here.
Time To Bake Our Image!
We now have all the moving parts needed to create a Yocto image! It is a good idea to start off with a bare minimum image that lets us check if the build works for us – the core-image-minimal is the perfect candidate for this!
To build the core-image-minimal image, we will first set up our build environment using the oe-init-build-env script inside poky. Then, we modify the local.conf to set the MACHINE variable to sama5d27-jupiter-nano-sd (support added in meta-atmel as discussed above). We are now ready to bake the core-image-minimal image for this machine.
In a nutshell, we do the below.
$ source oe-init-build-env <your build directory name>
$ vim conf/local.conf
<< set MACHINE ??= "sama5d27-jupiter-nano-sd" >>
$ bitbake core-image-minimal --runall=fetch
$ bitbake core-image-minimalSummary
In this rather long post, we successfully enabled Yocto support for the awesome Jupiter Nano board. How did we go about this task?
Adding Yocto support for any board requires one to create a machine configuration file. Other than this, we need the necessary modifications to be in place for the various boot components involved in generating a working image. In this case, these were the at91bootstrap, u-boot and linux kernel. In the activity described above, we worked with repositories that are forked from Microchip’s official repositories. All commits on the forked repos are safe to be merged as most of these commits are additive in nature.
In the next post, we will try to explore the Jupiter Nano and its capabilities a bit more. Now that we have a working Yocto image, we will continue to use this image and play with the board. See you!
Good work , kudos for your knowledge .
Thank you so much 🙂