Yocto U-Boot 4.1.15 features

U-Boot features

New features introduced in Variscite U-Boot 2015.04:

Splash Screen

A splash screen is enabled by default, and is shown on the LVDS LCD.
To disable the splash screen, enter the following in the U-Boot command line interface:

=> run disable_splash
=> saveenv && reset

And to re-enable it:

=> run enable_splash
=> saveenv && reset

The splash image is taken from /boot/splash.bmp in the root file system.

Automatic Splash source selection

The splash image will be taken from whichever rootfs that is going to be mounted later at boot. To enable the automatic selection (already enabled by default):

$ setenv splashsourceauto yes
$ saveenv

To disable the automatic selection:

$ setenv splashsourceauto no
$ setenv splashsource YOUR_SELECTION
$ saveenv

YOUR_SELECTION should be one of {sd, emmc, nand} (nand means UBIFS)

Note:

• In case the rootfs is a UBIFS, mounting it in order to load the splash file will add ~1.8 seconds to the boot time.

Using your own LCD screen

There is support for the 800x480 LCD screen that Variscite uses.
If you want to add support for a different LCD that is not currently supported, you need to edit the displays[] array in the U-Boot source code, according to your LCD parameters.

USB Mass Storage gadget

You can use the board as a USB Mass Storage device:
You will be able to access all the partitions of any block device that is on the board or connected to it, from your host PC - You will see them as /dev/sdXX, just like connecting a regular USB storage to your PC, and you'll be able to mount them, and have full read/write access to them. You can even use it to flash a new U-Boot, re-partition the storage, re-format it, etc.
This is especially useful for updating the internal eMMC.

To do this you need to connect a USB cable between the USB Client port of the board and a regular USB Host port on your PC, and use U-Boot's ums command.

General ums usage is:

ums <USB_controller> [<devtype>] <devnum>  e.g. ums 0 mmc 0
    devtype defaults to mmc

devtype can be any block device (e.g. mmc, usb)

To mount the eMMC:

=> ums 0 mmc 1

To mount an SD card:

=> ums 0 mmc 0

Depending on your host PC, it may automatically mount it or not. If not, you can use dmesg to see the names of the device and its partitions (it should be in the form of /dev/sdXX) and mount them yourself.
To exit the ums command and disconnect the USB device press ctrl+c.

Note: You should use a Linux PC host as Windows can't naturally read ext file systems.

USB Ethernet Gadget

The USB Ethernet gadget allows you to make the board act as a USB Ethernet device when connecting its USB Client port to a host PC using a USB cable.
Basically, it allows for "Ethernet over USB".
This is especially useful if you build a custom board without an Ethernet interface and you want to boot via network using TFTP.

This feature is disabled by default. To enable it, you need to un-comment the defines of the following configs in in the U-Boot source code:
CONFIG_USB_ETHER
CONFIG_USB_ETH_CDC

Now you should have a new Ethernet interface called usb_ether.

Before actually using it you should get to know the following environment variables:
Variables specific to this gadget:

usbnet_devaddr  - The virtual MAC address of the device (the board side).
usbnet_hostaddr - The virtual MAC address of the host (the PC side).

General network variables:

ethprime - Sets the primary Ethernet interface. This is the interface that will be tried first.
ethact   - Sets the currently active Ethernet interface. Normally, it is modified by the Ethernet driver, but you can change it if you want to override.
ipaddr   - IP address of the device - needed for tftp command.
netmask  - Subnet Mask.
serverip - TFTP server IP address - needed for tftp command.

So, for example: => setenv usbnet_devaddr f8:dc:7a:00:00:02

=> setenv usbnet_hostaddr f8:dc:7a:00:00:01
=> setenv ethact usb_ether
=> setenv ipaddr 192.168.0.100
=> setenv netmask 255.255.255.0
=> setenv serverip 192.168.0.101

And now your are ready to use tftpboot over the usb_ether interface.

Notes:

• Once you run a network command, e.g. tftpboot, the gadget will be connected to your host PC and a new network adapter will be added to it, for the duration of the network interaction.
• Note that you may need to configure your host PC to use the new network adapter properly - this configuration is OS dependent.
  
  

Other Variscite U-Boot features

Automatic Device Tree selection

Yocto Build Release

General U-Boot commands

List all supported commands and their description/usage (help command)

List all supported commands with a brief description for each one:

=> help

Print the description and usage of 'command':

=> help command

Environment handling commands

Print the values of all environment variables:

=> printenv

Print value of environment variable 'name':

=> printenv name

Set environment variable 'name' to 'value ...':

=> setenv name value ...

Delete environment variable 'name':

=> setenv name

Reset default environment:

=> env default -a

Save environment variables to persistent storage:

=> saveenv

File System access

List files in a directory (default /):

=> ls <interface> [<dev[:part]>] [directory]

For example:

List files in the BOOT partition of our NAND/eMMC Recovery SD card (after booting from it):
=> ls mmc 0:1

List files in directory /opt/images/Yocto in the rootfs partition of our NAND/eMMC Recovery SD card (after booting from it):
=> ls mmc 0:2 /opt/images/Yocto

Load binary file 'filename' from a partition to RAM address 'addr':

=> load <interface> [<dev[:part]> [<addr> [<filename> [bytes [pos]]]]]

For example:

Load /boot/splash.bmp from the rootfs partition of our NAND/eMMC Recovery SD card (after booting from it) to RAM address :
=> load mmc 0:2  /boot/splash.bmp

UBI File System

This is the FS we use on our NAND flash.
UBIFS is very different to any traditional file system - it does not work on top of block devices (like hard drives, MMC/SD cards, USB flash drives, SSDs, etc).
UBIFS was designed to work on top of raw flash.

The usage is a little different than using FAT/ext.
Before you can access the UBIFS you need to mount it first:

=> ubi part rootfs
=> ubifsmount ubi0:rootfs

Now you can access the UBIFS with the regular commands above.
The <interface> in this case is 'ubi', <dev> can be anything (the value is ignored) and part is not necessary.
For example:

List files in directory /home/root on the mounted UBI file system:
=> ls ubi 0 /home/root

When finished accessing it, unmount the FS:

=> ubifsumount

USB sub-system

To use the USB as host (connect a USB Storage or Ethernet Device to the board), you need to use the usb command.
Usage:

usb start - start (scan) USB controller
usb reset - reset (rescan) USB controller
usb stop [f] - stop USB [f]=force stop
usb tree - show USB device tree
usb info [dev] - show available USB devices
usb test [dev] [port] [mode] - set USB 2.0 test mode
    (specify port 0 to indicate the device's upstream port)
    Available modes: J, K, S[E0_NAK], P[acket], F[orce_Enable]
usb storage - show details of USB storage devices
usb dev [dev] - show or set current USB storage device
usb part [dev] - print partition table of one or all USB storage    devices
usb read addr blk# cnt - read `cnt' blocks starting at block `blk#'
    to memory address `addr'
usb write addr blk# cnt - write `cnt' blocks starting at block `blk#'
    from memory address `addr'

First, connect your device to a USB port on the board.
After the device is connected, start the USB controller:

=> usb start

If you connect/disconnect devices after that, before you can access them you need to rescan the USB controller:

=> usb reset

Using a USB Storage Device

Once you connected the device and stated the USB controller, you can now use the regular File System commands mentioned above with it.
The <interface> in this case is 'usb'.

Flashing NAND using U-Boot

Flashing U-Boot to NAND

Assuming you are reading the U-Boot image from our Recovery SD card:

=> mw.b  0xff  				# Write 0xFF to RAM in order to pad the image and align it to the NAND erase block size
=> load mmc 0:2  /opt/images/Yocto/u-boot.img		# Load the U-Boot image from the SD card to RAM
=> nand erase 0x200000 					# Erase the part of the NAND saved for the U-Boot image 
=> nand write  0x200000 			# Write the U-Boot image from RAM to NAND

Flashing the Linux kernel to NAND

Assuming you are reading the kernel image from our Recovery SD card:

=> mw.b  0xff 					# Write 0xFF to RAM in order to pad the image and align it to the NAND erase block size
=> load mmc 0:2  /opt/images/Yocto/			# Load the Linux kernel image from the SD card to RAM
=> nand erase  						# Erase the 'kernel' MTD partition
=> nand write   				# Write the Linux kernel image from RAM to MTD partition 'kernel'

Flashing the Linux device tree to NAND

Assuming you are reading the .dtb file from our Recovery SD card:

=> mw.b  0xff 0x20000						# Write 0xFF to RAM in order to pad the image and align it to the NAND erase block size (128KiB)
=> load mmc 0:2  /opt/images/Yocto/<DEVICE_TREE_FILE>		# Load the dtb from the SD card to RAM - Change to the correct .dtb filename for your setup
=> nand erase  0x20000						# Erase the part of the NAND saved for the device tree
=> nand write   0x20000				# Write the device tree from RAM to NAND

Flashing UBIFS to NAND

The best way to flash a UBI image is by using ubiformat (which is a part of mtd-utils) under Linux, as it preserves erase counters (our Recovery SD card scripts are using ubiformat).
But if you flash the UBIFS for the first time, then it doesn't matter because there are no erase counters to preserve.

Assuming you are reading the UBI image from our Recovery SD card:

=> load mmc 0:2  /opt/images/Yocto/rootfs.ubi			# Load the UBI image from the SD card to RAM
=> nand erase.part rootfs								# Erase the 'rootfs' MTD partition
=> nand write.trimffs  rootfs $filesize			# Write the UBI image from RAM to MTD partition 'rootfs'

Note:
There is another method to do this using U-Boot, that preserves erase counters, using the higher level ubi command, but you need a UBIFS image for it (which Yocto also creates, but we do not put on our Recovery SD card by default):

=> load mmc 0:2 {{#var:RAM_LOAD_ADDRESS}} /opt/images/Yocto/rootfs.ubifs		# Load the UBIFS image from an SD card to RAM
=> ubi part rootfs									# Set current MTD partition to 'rootfs'
=> ubi remove rootfs									# Remove the 'rootfs' UBI volume (if already exists)
=> ubi create rootfs									# Create a new dynamic UBI volume (read/write) with max size, and name it 'rootfs'
=> ubi write {{#var:RAM_LOAD_ADDRESS}} rootfs $filesize					# Write the volume from RAM