Overview LSI Axxia Systems use a 3 stage boot process to initialize the system and allow an operating system to be loaded. 1. The first stage is part of the asic and loads the Secondary Program Loader (SPL) into the asic’s local memory. If the secure boot feature is available, it will optionally verify and decrypt the SPL before transferring control to it. As the first stage is not based on U-Boot, and cannnot be modified, it is not discussed here. 2. After control is transferred to the SPL, system memory is initialized and U-Boot is loaded into it. 3. Once control is transferred to U-Boot, a prompt is available on uart0.
Local Builds and Modifications Build Environment It is assumed that a Linux host is used to build and that tools are avilable to target ARM A15. The cross compilation tools, mentioned above, should be in the PATH and CROSS_COMPILE should contain the proper prefix. SYSROOT should point to the tools sysroot for arm. ARCH should be set to arm.
A Clone of the LSI U-Boot Repository To get a local copy of the LSI U-Boot source tree, do the following. $ git clone https://github.com/axxia/axxia_u-boot.git $ cd axxia_u-boot $ git checkout --track -b lsi-v2013.01.01 origin/lsi-v2013.01.01 When updates or available, $ git checkout lsi-v2013.01.01 $ git pull Specific Releases [Optional] If you want a previously released version of LSI U-Boot, based on a commit or a tag, do the following. 1
Determine the Tag Name or Commit Number To list the available tags, $ git tag | grep lsi To list commits. git log Create the Branch following.
To create a branch based on a tag or commit, do the
$ git checkout lsi-v2013.01.01 $ git branch $ git checkout
Build make _config make Where is either axxia-55xx-sim-mmc, axxia-55xx-sim-virtio, axxia-55xx-emu, or axxia-55xx. u-boot.bin or u-boot.img is U-Boot. spl/u-boot-spl.bin is the SPL. Note that if the redundant boot feature is enabled, u-boot.img is required. A version string can be added with AXXIA_VERSION=. For example, in a clone of the git repository, AXXIA_VERSION=“git describe --dirty” will display the tag and any further changes.
Updating the SPL and U-Boot Simulation The SPL is not used in simulation, simply copy u-boot.bin to the simulation directory. If the topology file specifies a name other than u-boot.bin, rename it.
Emulation or Hardware Using the External Host to Update Serial Flash The SPL and U-Boot can be written to serial flash from the external host. First load the RTE on the external host, then do the following. ncpBootMem -a write -r prom -o 0 ncpBootMem -a write -r prom -o 0x40000 ncpBootMem -a write -r prom -o 0x100000 Using U-Boot If you can get to the U-Boot prompt, update the SPL, parameters, and U-Boot as follows. Note that getting images into memory could be accomplished using the network interface (dhcp, tftp), an external host, or a JTAG debugger. => sf => sf sf => sf sf => sf sf
probe 0 erase 0 40000 the SPL binary into memory at $(loadaddr)> write $(loadaddr) 0 40000 erase 40000 10000 the binary parameter file into memory at $(loadaddr)> write $(loadaddr) 40000 10000 erase 100000 200000 the U-Boot binary into memory at $(loadaddr)> write $(loadaddr) 100000 200000
Using DS-5 For new systems, or systems that will not get to the U-Boot prompt, it is possible to use the ARM DS-5 debugger. The steps are as follows. 1. 2. 3. 4.
Erase at least the first sector of serial flash. Reset the system. Using a suitable target configuration in DS-5, connect and stop the core. Copy spl/u-boot-spl, spl/u-boot.spl.bin, and u-boot.bin to the DS-5 workspace. 5. Import the following script into DS-5 and run it. restore "u-boot-spl.bin" binary S:0x20000000 set var $pc = 0x20000000 file "u-boot-spl" 3
restore "parameters" binary S:0x2003f000 hbreak -p spl_spi_load_image continue wait delete 1 set var $pc = reset_cpu_fabric restore "u-boot.bin" binary S:0x40000000 continue After running the script, stop at the U-Boot prompt on UART0 and update the SPL and U-Boot as described above.
Booting a Linux Image
Creating a Linux image is described in the lsi_axxia_yocto_public wiki, “NonYocto Build Instructions” [https://github.com/axxia/lsi_axxia_yocto_public/wiki/NonYoctoBuildInstructions]. linux.fit from the above will have to be placed in memory at the load address. In this case, 0x04000000. This can be accomplished using the network, a copy from serial flash, etc. It is possible to use the data path instead of the FEMAC as a network interface. This is described below in “Using EIOA as a Network Interface”. Once linux.fit is in memory, “bootm 4000000” will start Linux.
Appendices Parameters and the U-Boot Environment Unless mentioned here, there are no changes to the meaning of U-Boot environment variables. U-Boot documentation is avaible at http://www.denx.de/wiki/UBoot/Documentation. Not all compile time options are enabled, and the list of enabled options varies by target, board, and instance. Some input is required by the SPL to, for example, set the voltage, clocks, initialize system memory, etc. All such input is stored in a parameter file. The parameter file is generated by the ASE. It is stored in serial flash. In some cases, baud rate for example, there are compile time settings, a parameter, and an environment setting. When that is the case, the following sequence and precedence holds. Until the parameter file is available, the compile time setting is used. Once the parameter file is available, the value in it us used. Finally, if the environment contains a setting, that is used.
Baud Rate In the header file for each target, CONFIG_BAUDRATE sets the initial baud rate used by the SPL. If there are errors reading the parameter file, they will be sent to the console at this speed. If the baud rate parameter value is 0x80000000, indicating that there should be no change, nothing will change, otherwise, the baud rate will be changed to the value indicated. Since it is possible to start the boot process with U-Boot, skipping the SPL, U-Boot will follow the same sequence. It will begin with CONFIG_BAUDRATE, read the parameter file and switch to it. Finally, there is the U-Boot environment. Note that once “baudrate” is set, it cannot be deleted. If “baudrate” is set, U-Boot will use that value once the environment is available. A Sample U-Boot Environment Following is an example U-Boot environment that is used by LSI to verify U-Boot releases. setenv setenv setenv setenv setenv setenv setenv setenv setenv setenv setenv
ad_value 0x61 baudrate 115200 bootargs root=/dev/nfs rw mem=1024M console=ttyAMA0 ip=dhcp bootcmd dhcp ; bootm bootdelay 5 bootm_high 0x20000000 bootm_low 0x10000000 ethact LSI_FEMAC ethaddr fdt_high 0xffffffff loadaddr 4000000
Using EIOA as a Network Interface U-Boot can use Ethernet ports in EIOA for network connectivity. Any of the GMAC and XGMAC ports can be used. Following speeds are supported - GMAC: 10M/100M Half/Full, 1G. XGMAC: 10G. U-boot Environment U-boot environment to setup gmac18 to 1G.
setenv setenv setenv setenv
ethact LSI_EIOA eioaport gmac18 macspeed 1G phymedia fiber
Possible Values eioaport gmac[0-4,16-20,32,33,48,49,64,65,80,81,96,97,112,113]. xgmac[0,1,16,17,32,33,48,49,64,65,80,81,96,97,112,113]. rx-gmac, rx-xgmac: All ports are configured with same macspeed and phymedia. The first port that receives the packet is used for further communication. macspeed 10MH, 10MF, 100MH, 100MF, 1G, 10G. When variable is not defined, auto negotiation is used. phymedia fiber, copper phy_address Value of phy address when phymedia is copper. ad_value
Bits 5-8 of MII register 4 will be set to this value when phymedia is copper and auto negoti ge_ad_value
Bits 8,9 of MII register 9 will be set to this value when phymedia is copper and auto negoti