Sparx5

The behavior of the Sparx5 CPU system after reset is determined by four strapping pins that are overlaid on GPIO pins. The value of these GPIOs is sampled shortly after releasing reset to the device.

This allows the Sparx5 system to decide the boot mode:

In the first listed mode Sparx5 can boot from an external boot media such as SPI NOR flash and load a boot loader image such as UBoot.

UBoot can then load drivers for other external media such as SPI NAND or eMMC and continue the boot process after having loaded final images from these media.

It is also possible to load all images from SPI NOR flash, but this is not as fast as using SPI NAND or eMMC.

During boot Sparx5s PCIe controller will also be enabled in device mode.

This document will focus on the Sparx5 SoCs, but to fully explain the boot process and boot facilities, it is also necessary to consider the flash memories available on the board. The section will briefly describe the boot media supported by the Sparx5, and then describe which of these media is available on the Sparx5 evaluation boards offered by Microchip.

There are currently two Sparx5 evaluation boards available:

The two boards can be mounted with either SPI NAND or eMMC enabled (but not both).

To utilize the Main CPU of the Sparx5, the correct boot mode must be selected and a SPI NOR device with a boot image must be available at the SPI NOR memory address found in the memory map below:

Figure 1: Sparx5 Boot Mode memory map.

The bootloader will switch the Sparx5 from Boot mode to Normal mode which will remap the DDR memory down to address 0.

Reset the board and eventually press any key to stop autoboot in order to get a U-Boot prompt.

First make sure that the following environment variables are defined as shown:

Figure 6: SPI NAND UBoot default environment

Some of these environment variables are command macros that can be used to simplify the boot process.

If there is a difference you should reset the environment, save it and restart the board to use the default environment.

This can be done with these 3 commands:

During development, it is often advantageous to load and execute the image via DHCP instead of loading it from flash. The ramboot setting above supports that, if you have a FIT image on the TFTP server.

Here are the commands to run to load a fit-sparx5.itb file from the root of the TFTP server:

When this works satisfactorily you can commit this to the SPI NAND memory and update UBoot to use this media for booting.

As UBoot expects a UBIFS image in the SPI NAND partition Boot0 (or Boot1) you need to produce a UBIFS image file and place it in your TFTP server.

If you have the Linux kernel, the device tree binary files and the rootfile system file then you can create a UBIFS image file for a PCB134 evaluation board by running the imggen.rb script like this:

Note that the device tree configuration is renamed by adding a ,pcb134 element to the device tree binary file references.

Also note that the resulting file is generated in the /tftproot folder (used by the TFTP server in this case) and has the name new so that the folder will contain the file new.ubifs which is what the UBoot environment macros expect by default.

Now you can load the image and write it to SPI NAND with this command:

With the image in Boot0 time has now come to boot this image. This involve loading the Image.itb file from the UBIFS image and booting this as a FIT image containing a Linux kernel and a device tree.

Note that the UBoot environment expects a device tree configuration with the name found in the pcb environment variable. This was the reason for adding the ,pcb134 to the imggen.rb scripts device tree reference.

As mentioned above the UBoot FIT image does not contain a root filesystem, so the root filesystem is mounted as the content of the Boot0 partition.

Now boot the image with this command:

The kernel boots and show the Linux command shell. Now you are ready to use your system.

If this works as expected you can change the UBoot bootcmd setting to use the run nand_boot command permanently.

Reset the board and press any key to stop autoboot in order to get a U-Boot prompt.

First make sure that the following environment variables are defined as shown:

Figure 7: eMMC UBoot default environment

As in the SPI NAND case some of these environment variables are command macros that can be used to simplify the eMMC boot process.

If you do not see the above environment you have either used the UBoot image when flashing, or you need to reset the environment.

Resetting the UBoot environment is done with the following commands:

Like described in the SPI NAND boot section of this document it is recommended to do a network boot of your images before writing the image to the eMMC device.

Start by formatting the eMMC device with a GPT partition. You only need to do this once before writing images to the eMMC.

Use the mmc_format command:

This creates a mmc_guid setting in the UBoot environment for the eMMC device, that is used in the GUID Partition Table.

As UBoot expects an EXT4 image in the eMCC partition Boot0 (or Boot1) you need to produce a EXT4 image file and place it in your TFTP server.

If you have the Linux kernel, the device tree binary files and the rootfile system file then you can create a EXT4 image file for a PCB134 evaluation board by running the imggen.rb script like this:

Note that the device tree configuration is renamed by adding a ,pcb134_emmc element to the device tree binary file references.

Also note that the resulting file is generated in the /tftproot folder (used by the TFTP server in this case) and has the name new so that the folder will contain the file new.ext4.gz which is what the UBoot environment macros expect by default.

Now you can load the image and write it to eMMC with this command:

Before you can boot the eMMC disk image, you need to make two small changes in the UBoot environment.

First delete the rootargs setting

Next change the mmc_tryboot environment variable to use the root argument instead of the next_root argument and to wait 1s for the eMMC filesystem to be mounted.

This is done fairly easy by using the editenv command like this:

When the setting looks like this:

you can save the changes that you have made permanently with the command:

You can now boot the system with the run mmc_boot command.

If this works as expected you can change the bootcmd setting to use the run mmc_boot command permanently.

As the first step you should reset the environment, save it and restart the board to use the initialized environment.

This can be done with these 3 commands:

Now switch the to the SPI NOR only partition configuration with this command:

The SPI NOR flash is partitioned like this:

As you can see there are two 20MB Linux partitions (a main and a backup) that can be used to store a UBoot FIT image.

The UBoot environment settings that begin with nor_ allows you to store and load images in these partitions.

When using the SPI NOR boot method the FIT image that you provide must have both the Linux Kernel, device trees and the root file system.

To generate that you can use the imggen.rb tool like this:

Note that the device tree configuration is renamed by adding a ,pcb134_emmc element to the device tree binary file references. Here you need to choose the one that fits with your evaluation board and more specifically the pcb setting in the UBoot environment.

Also note that the resulting file is generated in the /tftproot folder (used by the TFTP server in this case) and has the name new so that the folder will contain the file new.itb which is what the UBoot environment nor_ macros expect by default.

Now you can load the image and write it to SPI NOR with this command:

You can now boot the system with the run nor_boot command.

If this works as expected you can change the bootcmd setting to use the run nor_boot command permanently.