Booting Linux Kernel

Info Box Applies to Linux Applies to Naon Applies to Maya Applies to Dido Applies to Lizard Applies to Diva Applies to Bora Applies to BORA Xpress Applies to BORA Lite Applies to Axel Ultra Applies to Axel Lite Applies to AXEL ESATTA Applies to SBC Lynx Applies to AXEL ULite

---

	THIS PAGE IS OBSOLETE, DON'T USE IT AS REFERENCE
The new documentation is available here: DESK-MX6-L/General/Booting_from_NFS

---

	THIS PAGE IS OBSOLETE, DON'T USE IT AS REFERENCE
The new documentation is available here: BORA_SOM/BELK-L/General/Release_Notes

Boot configurations

U-Boot is used to boot the Linux kernel and by setting some environment variables it's possible to select how to perform the boot process. The default U-boot environment provides two boot configurations that are explained in more detail in the following sections.

Configuration flash_self

This configuration is conceived for standalone operation. Both the kernel and the root file system are retrieved from Flash. Once U-Boot has transferred the control to Linux, its job is completed. From now on Linux kernel has the control of the hardware. At the end of Linux boot process, the user can interact with the system with the typical Unix-like shell through the same serial connection used for U-Boot. To run this configuration just issue the command

run flash_self

Ethernet interface will be enabled by default. To disable it, just remove addip variable from the flash_self variable.

Configuration net_nfs

This configuration is very helpful during the software development (both for kernel and applications). The kernel image is downloaded via TFTP while the root file system is remotely mounted via NFS from the host. It is assumed that the development host:

• is connected with the target host board through an Ethernet LAN
• exports the directory containing the root file system for the target through the NFS server
• runs a TFTP server.
• has a proper subnet IP address

If your system does not match this configuration, just change the necessary variables and store them permanently with the u-boot setenv/saveenv commands. To do that, from the U-boot shell, please check the following parameters and set them accordingly with your host and target configuration:

1. serverip - IP address of the host machine running the tftp/nfs server
2. ipaddr - IP address of the target
3. ethaddr - MAC address of the target
4. netmask - Netmask of the target
5. gateway - IP address of the gateway
6. netdev - Ethernet device name
7. rootpath - Path to the NFS-exported directory
8. bootfile - Path to the kernel binary image on the tftp server
9. fdtfile - Path to the device tree binary image on the tftp server
10. nfsargs - Kernel command line with parameters for loading the root file system through NFS

To run this configuration just issue the command

run net_nfs

Booting from SD/MMC

When a bootable SD/microSD/MMC is available and the carrier board provides a SD/microSD/MMC slot, the system can boot from the card.

Assuming that:

• the first (if more that one is available) partition of MMC is formatted as FAT12/16 or FAT32, is marked as primary and is active
• the first partition contains, besides the MLO (U-Boot 1st stage) and u-boot.bin (U-Boot 2nd stage) files, the uImage file (which is the kernel image)
• the second partition is formatted as ext3 and contains a plain root file system

the following commands can be used to start the system reading the kernel from the card boot partition and mounting the root file system stored in the second partition (/dev/mmcblk0p2):

mmc rescan 0
fatload mmc 0 81000000 uImage
setenv mmcargs 'setenv bootargs root=/dev/mmcblk0p2 rw'
run mmcargs addip addcons addmem
bootm 81000000

Automatic boot

If you wish Lizard system to automatically boot with one of the above configurations, just set up and store the

bootcmd

variable. For example, for the flash_self configuration, issue the following commands:

setenv setenv bootcmd ${flash_self}
saveenv

Next time the system boots, U-Boot will wait for three seconds (to stop the wait just press any key in the console) before executing the commands stored in the

bootcmd

variable. This time can be changed by setting the

bootdelay

variable. Generally speaking the whole boot process can be further and heavily customized. For more details please refer to the doc/README.autoboot file in the U-Boot sources.