-
Notifications
You must be signed in to change notification settings - Fork 13
Uboot HSDK Command Reference
The U-Boot bootloader is a powerful and flexible tool for loading an executable from different sources and running it on the target platform.
The U-Boot implementation for the ARC HSDK was further extended with additional functionality that allows users to better manage the broad configurability of the ARC HSDK.
This command reference provides description and basic usage information for newly introduced function in U-Boot for ARC HSDK.
The HSDK board internally uses a number of PLLs that clock the main components of the ARC core as well as all data buses and peripherals. The following commands are introduced to set and display various clock values.
Manage clocks on HSDK.
The following sub-commands are available:
Set clocks frequencies to values specified in environment variables or in command line arguments.
Set clock from axi_freq, cpu_freq and tun_freq environment variables (all values are in MHz):
hsdk_clock set
Set clock from axi_freq, cpu_freq and tun_freq command line arguments (All values are in MHz):
hsdk_clock set tun_freq 125 axi_freq 600 cpu_freq 400
Save clock frequencies to axi_freq, cpu_freq and tun_freq environment variables
hsdk_clock get
Show CPU, AXI, DDR and TUNNEL current clock frequencies.
hsdk_clock print
Sample output of hsdk_clock print command:
hsdk# hsdk_clock print
HSDK: clock 'cpu-clk' rate 500 MHz
HSDK: clock 'tun-clk' rate 50 MHz
HSDK: clock 'axi-clk' rate 400 MHz
HSDK: clock 'ddr-clk' rate 334 MHz
Show all currently used clock frequencies.
hsdk_clock print_all
Typical output of hsdk_clock print_all command:
hsdk# hsdk_clock print_all
HSDK: clock 'cpu-pll' rate 500 MHz
HSDK: clock 'cpu-clk' rate 500 MHz
HSDK: clock 'sys-pll' rate 400 MHz
HSDK: clock 'apb-clk' rate 200 MHz
HSDK: clock 'axi-clk' rate 400 MHz
HSDK: clock 'eth-clk' rate 400 MHz
HSDK: clock 'usb-clk' rate 400 MHz
HSDK: clock 'sdio-clk' rate 400 MHz
HSDK: clock 'gfx-core-clk' rate 400 MHz
HSDK: clock 'gfx-dma-clk' rate 400 MHz
HSDK: clock 'gfx-cfg-clk' rate 200 MHz
HSDK: clock 'dmac-core-clk' rate 400 MHz
HSDK: clock 'dmac-cfg-clk' rate 200 MHz
HSDK: clock 'sdio-ref-clk' rate 100 MHz
HSDK: clock 'spi-clk' rate 34 MHz
HSDK: clock 'i2c-clk' rate 200 MHz
HSDK: clock 'uart-clk' rate 34 MHz
HSDK: clock 'ddr-clk' rate 334 MHz
HSDK: clock 'tun-pll' rate 150 MHz
HSDK: clock 'tun-clk' rate 50 MHz
HSDK: clock 'rom-clk' rate 150 MHz
HSDK: clock 'pwm-clk' rate 75 MHz
HSDK U-Boot contains a special implementation of the bootm command.
HSDK bootm command launches Linux kernel only on selected CPUs, based on the value of the core_mask environment variable.
When an external Linux device tree blob (for example hsdk.dtb) is provided, bootm will also patch the status property of each CPU node according to the value of the core_mask environment variable.
Below is an example launching Linux on 3 out of 4 cores. Linux image (uImage) and Linux device tree blob (hsdk.dtb) are read from the first FAT partition of SD card. core_mask is implicitly set to 0x7 by the hsdk_hs38x3 script command.
fatload mmc 0:1 0x82000000 uImage
fatload mmc 0:1 0x81000000 hsdk.dtb
run hsdk_hs38x3;
bootm 0x82000000 - 0x81000000
HSDK U-Boot contains several configuration patterns which can be used to
setup HSDK hardware in. Each configuration pattern contains information about instruction and data caches
state (enabled/disabled), iccm and dccm mappings, non_volatile_limit value and CPU mask (core_mask variable) value.
As of today HSDK U-Boot contains next configuration patterns:
hsdk_hs34
hsdk_hs36
hsdk_hs36_ccm
hsdk_hs38
hsdk_hs38_ccm
hsdk_hs38x2
hsdk_hs38x3
hsdk_hs38x4
To choose a configuration use run command with configuration pattern name:
run hsdk_hs38x2
To setup the HSDK hardware use hsdk_init command:
hsdk_init
hsdk_init command output:
hsdk# hsdk_init
CPU start mask is 0x3
To launch a baremetal application on HSDK you need to setup entry points for all
used cpus, load application binary to DDR, configure HW with hsdk_init command
and run application with hsdk_go command:
fatload mmc 0:1 0x90000000 app.bin
run hsdk_hs38x2;
setenv core_entry_0 0x90000000;
setenv core_entry_1 0x90000000;
hsdk_init
hsdk_go
hsdk_go is command to jump each CPU chosen by CPU mask (core_mask variable) to its entry point (core_entry_X variable). All CPUs which aren't chosen by CPU mask will be halted.
hsdk_go can be used with halt option to halt all CPUs before jump to entry points:
hsdk_go halt
CPUs can be start manually with debugger.
You can test hsdk_init and hsdk_go commands with simple demo app.
You can use pebuild demo application binary or build it yourself with next commands:
- for GNU toolchain:
arc-linux-gcc -mcpu=hs -nostdlib -e _start -Wl,-Ttext=0x90000000 -o app.elf demo-app.S
arc-linux-objcopy -O binary app.elf app.bin
- for MetaWare toolchain:
ccac -arcv2hs -Bbase=0x90000000 -g -Hnoivt -Hnolib -Hnocrt demo-app.S -o app.elf
elf2bin app.elf app.bin
Demo app has next functionality:
write 0x12345678 to (0xD0000000 + CPU_ID * 128)
write ARC_IDENTITY to (0xD000004 + CPU_ID * 128)
flush d$
halt cpu
Before test launching please deploy the most recent sdcard.img to your micro SD-card that will be used with HSDK and copy demo application binary to first SD-card partition. Check ARC HSDK Buildroot release page page for instructions on how to deploy sdcard.img to micro SD-card.
There is an example of launching demo application on hsdk_hs38x4 (quard core) configuration:
fatload mmc 0:1 0x90000000 app.bin
run hsdk_hs38x4;
setenv core_entry_0 0x90000000;
setenv core_entry_1 0x90000000;
setenv core_entry_2 0x90000000;
setenv core_entry_3 0x90000000;
hsdk_init
hsdk_go
To check demo app execution result simply read 0xD0000XXX addresses with MDB or restart u-boot (by pressing "Reset" button) and read memory with next u-boot command:
md 0xd0000000 64
Check 0xd0000000, 0xd0000080, 0xd0000100 and 0xd0000180 addresses in MDB "Memory" palette or in md u-boot command output. You will see next pattern:
d0000000: 12345678 00000052 XXXXXXXX XXXXXXXX
d0000080: 12345678 00000152 XXXXXXXX XXXXXXXX
d0000100: 12345678 00000252 XXXXXXXX XXXXXXXX
d0000180: 12345678 00000352 XXXXXXXX XXXXXXXX
It is possible to update the U-Boot image that is automatically started by boot-ROM with a newer image using the upgrade command provided in the default U-Boot environment:
run upgrade
upgrade command output:
hsdk# run upgrade
reading u-boot.head
355204 bytes read in 25 ms (13.5 MiB/s)
SF: Detected sst26wf016 with page size 256 Bytes, erase size 4 KiB, total 2 MiB
SF: 393216 bytes @ 0x0 Erased: OK
device 0 offset 0x0, size 0x60000
SF: 393216 bytes @ 0x0 Written: OK
u-boot update: OK
If U-boot image in on-board SPI-flash is damaged it is possible to recover it by sideloading new U-Boot executable in DDR of HSDK via JTAG with subsequent writing of binary image into SPI-flash.
But before sideloading U-Boot executable to HSDK's DDR please deploy the most recent sdcard.img to your micro SD-card that will be used with HSDK. Check ARC HSDK Buildroot release page page for instructions on how to deploy sdcard.img to micro SD-card.
Once micro SD-card is prepared and inserted into HSDK make sure DIP-switches in the corner of the board are in their default positions: BIM in 1:on, 2:on state while both BMC and BCS should be in 1: on, 2:on state.
Now reset the HSDK board by pressing "Reset" button and load U-Boot Elf (download u-boot file from ARC HSDK Buildroot release page) using MDB:
mdb -digilent -cl -run u-boot
Once U-Boot on HSDK boots into command prompt just issue the following command:
run upgrade
The help command (short: h or ?) prints online help. Without any arguments, it prints a list of all U-Boot commands that are available in your configuration of U-Boot. You can get detailed information for a specific command by typing its name as argument to the help command:
hsdk# help sleep
sleep - delay execution for some time
Usage:
sleep N
- delay execution for N seconds (N is _decimal_ and can be
fractional)
- Every application being loaded and executed by U-Boot must invalidate all caches (including L1 instruction and data caches as well as SLC) as the first thing on start. This is required to make sure no stale entries were left from the previously executed U-Boot. Even though U-Boot flushes and invalidates all caches before passing control to another application there's still a possibility a couple of cache lines might contain instructions and data used right after cache flush and invalidation.