|Fixed definition of <code>nandboot2</code> variable<br>
Fixed dump related to the download of the bitstream file
|-
|3.0.0
|Jan 2020
|Update for BELK/BXELK 4.1.0
|}
<section begin=BTELK/>== Introduction Standalone boot==This document shows some examples related to configuring Bora/BoraX /BoraLite for standalone operativity.
We'll explain how to program and configure a [[:Category:BoraX|BoraX]]-based system to boot in standalone mode, without the need of a system microSD card or an NFS server. Only the flash memories available on the SoM itself will be used to store persistently all the software required.
The examples here documented are valid for [[:Category:Bora|Bora]] and for [[:Category:BoraLite|BoraLite]] as well. {{ImportantMessage|text=It is worth remembering that the examples shown in this article don't make use of any image script. This technique is used by the bootable microSD card delivered along with the kit, instead. For more details, please refer to [[Working_with_the_Yocto_build_system#bootscript|this section]].}}
===Use case #1=======Introduction====
This configuration makes use of one of the most common partitioning schemes, that is:
*The NOR flash acts as boot memory; as such, it contains
*Once started, the Linux kernel mount the root filesystem from a NAND partition.
=====Testbed=====
This configuration was tested with the following testbed:
==== Program the root filesystem in NAND flash ====
This is a common step for both booting options.
* Boot the system via SD or NFS as described into the [[System_boot_and_recovery_via_microSD_card_(BELK/BXELK)|System boot and recovery via microSD card]] and [[Booting_the_system_via_NFS_(BELK/BXELK)|Booting the system via NFS]]
* By default, the NAND is already partitioned to allow booting from NAND-only (see next section) and, thus, some partitions are reserved for FSBL, U-boot and kernel images. Here we won't modify this default configuration. The [[Memory Tecnology Device (MTD)|MTD]] partitions can be dumped with <code>/proc/mtd</code> (the partition's name should be self-explanatory)
To setup the desired standalone configuration, several operations need to be carried out. They are detailed in the following sections. It is assumed that the SOM can boot from the NOR flash. If not, please see [[Restoring_U-Boot_on_SPI_NOR_flash_(BELK/BXELK)|this page]].
=====Testbed=====
The testbed used to test this configuration consists of the following boards:
*SOM: DBXD4110S2R
*Software: BXELK 4.0.0 + PetaLinux 2017.1
====Storing the images onto the raw partitions of the NAND memory====Before storing the images into the NAND flash, the bitstream must be converted. For more details, please refer to [[BELK-AN-008:_Programming_FPGA_Bitstream_with_UProgramming the FPGA Bitstream with U-Boot|this page]]:
In order to boot the system as desired, the U-Boot environment must be configured properly. The most important variable is <code>nandboot2</code> that can be created as follows:
Please note that the variable <code>bootcmd</code> is set to run the desired boot sequence (<code>nandboot2</code>).
====Formatting the fourth partition of the NAND memory (<code>mtd3</code>)====
After setting up the U-Boot environment, it is possible to start a full bootstrap sequence by issuing the <code>boot</code> command. Please refer to [[#Full bootstrap procedure|this section]] to see the dump of the serial console during the full bootstrap sequence.
</pre>
====Full bootstrap procedure====
For the reader's convenience, the following box shows the full bootstrap procedure (please, click on the "Expand" link):
</pre>
====Additional notes====
*<code>mtd0</code>, <code>mtd1</code>, and <code>mtd2</code> are significantly larger than the files they store used in this example. This allows having a spare room to store larger images. For the sake of simplicity, U-Boot was configured to read the whole partitions (see how the <code>loadunand</code>, <code>loadfdtnand</code>, and <code>loadfpga2</code> variables are defined). Obviously, this affect the overall boot time negatively. To optimize it, these variables have to be changed in order to read just the required amount of data according to the size of the actual stored files.
*As stated previously, the root filesystem is <code>initramfs</code> and thus not persistent. Consequently, every time the system boots, the directory <code>/mnt/data3</code> must be created before mounting the ''UBIFS'' file system stored in the NAND flash.