{{ImportantMessage|text=For the sake of simplicity, this document does not address the reliability of the partitioning schemes described. This matter is beyond the scope of this document and should take into account several factors such as the intrinsic reliability of NOR/NAND flashes, the estimated usage in terms of read/write operations, etc. For more information related to this subject, please contact [mailto:support-bora@dave.eu the technical support].}}
== History ==
|March 2019
|Added use case #2
|-
|2.0.1
|March 2019
|Added warning about realiability<br>
Added images of case #1's partitioning scheme
|-
|{{oldid|9151|2.0.2}}
|June 2019
|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
**bootrom header and FSBL (or header+U-Boot SPL)
**U-Boot
**U-Boot redundant environment
**Even though these images are not strictly required to boot the system, the NOR flash also contains:***The Linux kernel image***The Linux Device Tree Blob (DTB)***The bitstream file for the Programmable Logic (PL).*The NAND flash contains the a partition devoted to a read/write UBIFS root filesystem (read/write). The resulting flash memory layout is illustrated in the following pictures. [[File:BELK-NOR-flash-partitioning-case1.png|thumb|center|600px|NOR flash partitioning scheme]] [[File:BELK-NAND-flash-partitioning-case1.png|thumb|center|600px|NAND flash partitioning scheme]]
*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)
**This partition is associated with the device file <code>/dev/mtd2</code>
*An auxiliary read/write filesystem used by the user-space applications for several purposes such as data logging.**This partition is associated with the device file <code>/dev/mtd3</code>.
The resulting bootstrap sequence is like the following:
#Finally, the Linux kernel mounts the root filesystem from the SDRAM memory and starts user-space applications and daemons.
It is worth remembering that <code>mtd0</code>,<code>mtd1</code>, and <code>mtd2</code> are used as raw partitions while <code>mtd3</code> is associated with a block device in order to mount a filesystem, specifically ''UBIFS''. To handle such filesystem, the Linux kernel must be built with the UBI/UBIFS support enabled and the root filesystem must include the <code>mtd-utils-ubifs</code> package (see the following image).
To setup this 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]].
[[File:PetaLinux-mtd-utils-ubifs.png|thumb|center|600px|Selecting the <code>mtd-utils-ubifs</code> package in PataLinux root filesystem configuration]] 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*Carrier board: EVBBX0000C0R*Software: BXELK 4.0.0 + PetaLinux 2017.1 ====Storing the images onto the raw partitions of the NAND memory====Before storing the images onto into the NAND flash, the bitstrem 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]]:
Once the U-Boot console is available, the binary files to be stored onto into the NAND flash can be downloaded via TFTP. The size of the partitions illustrated in the previous image determine the offsets to be used use with the <code>nand erase/write</code> commands. The following box shows the full procedure:.
The first file to be stored is <code>uImage</code>:
Downloading and flashing of the bitstream file:
<pre class="board-terminal">
Bora> tftpboot ${loadaddr} borax/bitstream.bitbin
Using ethernet@e000b000 device
TFTP from server 192.168.0.13; our IP address is 192.168.0.81
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:
Another important variable that needs to be changed is <code>mtdparts</code>. It must be set like this in order to tell the kernel how the NAND flash is partitioned:
Similarly, other variables need to be created such as <code>loadunand</code> and <code>loadfdtnand</code>. The resulting environment should look like this:
<pre class="board-terminal">
</pre>
===Formatting the fourth partition of the NAND memory (<code>mtd3</code>)===
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.
Once the system has completed the bootstrap procedure, it is possible to format the <code>mtd3</code> partition in order to store a ''UBIFS'' filesystem.
First of all, check that the NAND's partitions are defined properly:
[ 6634.571363] UBIFS (ubi0:0): media format: w4/r0 (latest is w4/r0), UUID 8B1F86F2-F2C3-4292-845F-77D3BF3E212A, small LPT model
</pre>
It is now possible to verify that the filesystem was mounted properly:
<pre class="board-terminal">
root@bora-ubi:~# mount
rootfs on / type rootfs (rw)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=000)
ubi0_0 on /mnt/data3 type ubifs (rw,relatime)
</pre>
As expected, the available space on the <code>ubi0_0</code> is less than the raw size of the partition:
<pre class="board-terminal">
root@bora-ubi:~# df
Filesystem 1K-blocks Used Available Use% Mounted on
</pre>
====Full bootstrap procedure====For the reader's convenience, the following box shows the full bootstrap procedure (please, click on the "Expand" link):
====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, however, U-Boot was configured to read the whole partitions. Obviously, these affect the overall boot time negatively. To optimize it, (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 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 it is mountedtime the system boots, the directory <code>/mnt/data3</code> must be createdbefore mounting the ''UBIFS'' file system stored in the NAND flash.<section end=BTELK/>