2.4.6 Configure at91bootstrap to Load a Custom Bare Metal Application from an SD Card

In this section, we will customize at91bootstrap to load and execute a Harmony3 bare-metal application directly from an SD card or e.MMC instead of U-Boot. By default, at91bootstrap is configured to load U-Boot as the second-stage bootloader, but in this scenario, we will modify sam9x60_curiositysd_uboot_defconfig or sam9x60_curiositysd1_uboot_defconfig to load the custom bare-metal application. This requires adjustments to the next software type and image storage setup to ensure that at91bootstrap correctly loads the Harmony3 bare-metal application from the storage media.

To configure at91bootstrap to load a Harmony3-based application from SD card memory into external volatile memory (DDRAM), proceed as follows:

  1. Go to Project→ Properties→ Kconfig→ Load→ Harmony3→ at91bootstrap→ configs→ sam9x60_curiositysd_uboot_defconfig or sam9x60_curiositysd1_uboot_defconfig→ Open.
    Figure 2-7. Load at91bootstrap SD Card Boot Configuration

    or

  2. Perform the following changes:
    • SD Card Host Controller: Select SDHC0 or SDHC1, based on which card interface is used.
    • Next Software Type: Load 4 MB into the start of the DDRAM.
    • Demo Application Image Storage Setup:
      1. External DDRAM Address to Load Demo-App Image: This should match the bare-metal application entry point address or the code section start address as specified in the linker script file.
      2. Next Software Image File Name: Name of the user application binary file. For this application note, use harmony.bin.
  3. Click Apply, then OK.

This completes the at91bootstrap configuration for loading a bare-metal application from an SD card.

An example configuration for the SAM9X60-Curiosity board is shown below.

Figure 2-8. Load at91bootstrap Custom Boot Configuration
Note: While in the previous case (Configure at91bootstrap to Load a Custom Bare-Metal Application from NAND Flash Memory) we provided a size and an offset to specify the bare-metal application parameters, in this case we only provide a file name. The reason is that NAND Flash devices and SD cards are organized differently internally. For NAND Flash memory, access is done at the page level and to raw data; there is no abstraction level such as a memory block or a file system. SD cards, on the other hand, implement software partitioning. This eases the support for file systems and makes it possible to provide a file name as a parameter to identify the bare-metal application for an SD card that is partitioned and formatted with a FAT16 or 32 file system.