README.440-DDR-performance
1 AMCC suggested to set the PMU bit to 0 for best performace on the 2 PPC440 DDR controller. The 440er common DDR setup files (sdram.c & 3 spd_sdram.c) are changed accordingly. So all 440er boards using 4 these setup routines will automatically receive this performance 5 increase. 6 7 Please see below some benchmarks done by AMCC to demonstrate this 8 performance changes: 9 10 11 ---------------------------------------- 12 SDRAM0_CFG0[PMU] = 1 (U-Boot default for Bamboo, Yosemite and Yellowstone) 13 ---------------------------------------- 14 Stream benchmark results 15 ------------------------------------------------------------- 16 This system uses 8 bytes per DOUBLE PRECISION word. 17 ------------------------------------------------------------- 18 Array size = 2000000, Offset = 0 19 Total memory required = 45.8 MB. 20 Each test is run 10 times, but only 21 the *best* time for each is used. 22 ------------------------------------------------------------- 23 Your clock granularity/precision appears to be 1 microseconds. 24 Each test below will take on the order of 112345 microseconds. 25 (= 112345 clock ticks) 26 Increase the size of the arrays if this shows that you are not getting 27 at least 20 clock ticks per test. 28 ------------------------------------------------------------- 29 WARNING -- The above is only a rough guideline. 30 For best results, please be sure you know the precision of your system 31 timer. 32 ------------------------------------------------------------- 33 Function Rate (MB/s) RMS time Min time Max time 34 Copy: 256.7683 0.1248 0.1246 0.1250 35 Scale: 246.0157 0.1302 0.1301 0.1302 36 Add: 255.0316 0.1883 0.1882 0.1885 37 Triad: 253.1245 0.1897 0.1896 0.1899 38 39 40 TTCP Benchmark Results 41 ttcp-t: socket 42 ttcp-t: connect 43 ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5000 tcp -> 44 localhost 45 ttcp-t: 16777216 bytes in 0.28 real seconds = 454.29 Mbit/sec +++ 46 ttcp-t: 2048 I/O calls, msec/call = 0.14, calls/sec = 7268.57 47 ttcp-t: 0.0user 0.1sys 0:00real 60% 0i+0d 0maxrss 0+2pf 3+1506csw 48 49 ---------------------------------------- 50 SDRAM0_CFG0[PMU] = 0 (Suggested modification) 51 Setting PMU = 0 provides a noticeable performance improvement *2% to 52 5% improvement in memory performance. 53 *Improves the Mbit/sec for TTCP benchmark by almost 76%. 54 ---------------------------------------- 55 Stream benchmark results 56 ------------------------------------------------------------- 57 This system uses 8 bytes per DOUBLE PRECISION word. 58 ------------------------------------------------------------- 59 Array size = 2000000, Offset = 0 60 Total memory required = 45.8 MB. 61 Each test is run 10 times, but only 62 the *best* time for each is used. 63 ------------------------------------------------------------- 64 Your clock granularity/precision appears to be 1 microseconds. 65 Each test below will take on the order of 120066 microseconds. 66 (= 120066 clock ticks) 67 Increase the size of the arrays if this shows that you are not getting 68 at least 20 clock ticks per test. 69 ------------------------------------------------------------- 70 WARNING -- The above is only a rough guideline. 71 For best results, please be sure you know the precision of your system 72 timer. 73 ------------------------------------------------------------- 74 Function Rate (MB/s) RMS time Min time Max time 75 Copy: 262.5167 0.1221 0.1219 0.1223 76 Scale: 258.4856 0.1238 0.1238 0.1240 77 Add: 262.5404 0.1829 0.1828 0.1831 78 Triad: 266.8594 0.1800 0.1799 0.1802 79 80 TTCP Benchmark Results 81 ttcp-t: socket 82 ttcp-t: connect 83 ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5000 tcp -> 84 localhost 85 ttcp-t: 16777216 bytes in 0.16 real seconds = 804.06 Mbit/sec +++ 86 ttcp-t: 2048 I/O calls, msec/call = 0.08, calls/sec = 12864.89 87 ttcp-t: 0.0user 0.0sys 0:00real 46% 0i+0d 0maxrss 0+2pf 120+1csw 88 89 90 2006-07-28, Stefan Roese <sr (a] denx.de> 91
README.ae350
1 Andes Technology SoC AE350 2 =========================== 3 4 AE350 is the mainline SoC produced by Andes Technology using AX25 CPU core 5 base on RISC-V architecture. 6 7 AE350 has integrated both AHB and APB bus and many periphals for application 8 and product development. 9 10 AX25-AE350 11 ========= 12 13 AX25-AE350 is the SoC with AE350 hardcore CPU. 14 15 Configurations 16 ============== 17 18 CONFIG_SKIP_LOWLEVEL_INIT: 19 If you want to boot this system from SPI ROM and bypass e-bios (the 20 other boot loader on ROM). You should undefine CONFIG_SKIP_LOWLEVEL_INIT 21 in "include/configs/ax25-ae350.h". 22 23 Build and boot steps 24 ==================== 25 26 build: 27 1. Prepare the toolchains and make sure the $PATH to toolchains is correct. 28 2. Use `make ax25-ae350_defconfig` in u-boot root to build the image. 29 30 Verification 31 ==================== 32 33 Target 34 ==================== 35 1. startup 36 2. relocation 37 3. timer driver 38 4. uart driver 39 5. mac driver 40 6. mmc driver 41 7. spi driver 42 43 Steps 44 ==================== 45 1. Define CONFIG_SKIP_LOWLEVEL_INIT to build u-boot which is loaded via gdb from ram. 46 2. Undefine CONFIG_SKIP_LOWLEVEL_INIT to build u-boot which is booted from spi rom. 47 3. Ping a server by mac driver 48 4. Scan sd card and copy u-boot image which is booted from flash to ram by sd driver. 49 5. Burn this u-boot image to spi rom by spi driver 50 6. Re-boot u-boot from spi flash with power off and power on. 51 52 Messages of U-Boot boot on AE350 board 53 ====================================== 54 U-Boot 2018.01-rc2-00033-g824f89a (Dec 21 2017 - 16:51:26 +0800) 55 56 DRAM: 1 GiB 57 MMC: mmc@f0e00000: 0 58 SF: Detected mx25u1635e with page size 256 Bytes, erase size 4 KiB, total 2 MiB 59 In: serial@f0300000 60 Out: serial@f0300000 61 Err: serial@f0300000 62 Net: 63 Warning: mac@e0100000 (eth0) using random MAC address - be:dd:d7:e4:e8:10 64 eth0: mac@e0100000 65 66 RISC-V # version 67 U-Boot 2018.01-rc2-00033-gb265b91-dirty (Dec 22 2017 - 13:54:21 +0800) 68 69 riscv32-unknown-linux-gnu-gcc (GCC) 7.2.0 70 GNU ld (GNU Binutils) 2.29 71 72 RISC-V # setenv ipaddr 10.0.4.200 ; 73 RISC-V # setenv serverip 10.0.4.97 ; 74 RISC-V # ping 10.0.4.97 ; 75 Using mac@e0100000 device 76 host 10.0.4.97 is alive 77 78 RISC-V # mmc rescan 79 RISC-V # fatls mmc 0:1 80 318907 u-boot-ae350-64.bin 81 1252 hello_world_ae350_32.bin 82 328787 u-boot-ae350-32.bin 83 84 3 file(s), 0 dir(s) 85 86 RISC-V # sf probe 0:0 50000000 0 87 SF: Detected mx25u1635e with page size 256 Bytes, erase size 4 KiB, total 2 MiB 88 89 RISC-V # sf test 0x100000 0x1000 90 SPI flash test: 91 0 erase: 36 ticks, 111 KiB/s 0.888 Mbps 92 1 check: 29 ticks, 137 KiB/s 1.096 Mbps 93 2 write: 40 ticks, 100 KiB/s 0.800 Mbps 94 3 read: 20 ticks, 200 KiB/s 1.600 Mbps 95 Test passed 96 0 erase: 36 ticks, 111 KiB/s 0.888 Mbps 97 1 check: 29 ticks, 137 KiB/s 1.096 Mbps 98 2 write: 40 ticks, 100 KiB/s 0.800 Mbps 99 3 read: 20 ticks, 200 KiB/s 1.600 Mbps 100 101 RISC-V # fatload mmc 0:1 0x600000 u-boot-ae350-32.bin 102 reading u-boot-ae350-32.bin 103 328787 bytes read in 324 ms (990.2 KiB/s) 104 105 RISC-V # sf erase 0x0 0x51000 106 SF: 331776 bytes @ 0x0 Erased: OK 107 108 RISC-V # sf write 0x600000 0x0 0x50453 109 device 0 offset 0x0, size 0x50453 110 SF: 328787 bytes @ 0x0 Written: OK 111 112 RISC-V # crc32 0x600000 0x50453 113 crc32 for 00600000 ... 00650452 ==> 692dc44a 114 115 RISC-V # crc32 0x80000000 0x50453 116 crc32 for 80000000 ... 80050452 ==> 692dc44a 117 RISC-V # 118 119 *** power-off and power-on, this U-Boot is booted from spi flash *** 120 121 U-Boot 2018.01-rc2-00032-gf67dd47-dirty (Dec 21 2017 - 13:56:03 +0800) 122 123 DRAM: 1 GiB 124 MMC: mmc@f0e00000: 0 125 SF: Detected mx25u1635e with page size 256 Bytes, erase size 4 KiB, total 2 MiB 126 In: serial@f0300000 127 Out: serial@f0300000 128 Err: serial@f0300000 129 Net: 130 Warning: mac@e0100000 (eth0) using random MAC address - ee:4c:58:29:32:f5 131 eth0: mac@e0100000 132 RISC-V # 133 134 135 Boot bbl and riscv-linux via U-Boot on QEMU 136 =========================================== 137 1. Build riscv-linux 138 2. Build bbl and riscv-linux with --with-payload 139 3. Prepare ae350.dtb 140 4. Creating OS-kernel images 141 ./mkimage -A riscv -O linux -T kernel -C none -a 0x0000 -e 0x0000 -d bbl.bin bootmImage-bbl.bin 142 Image Name: 143 Created: Tue Mar 13 10:06:42 2018 144 Image Type: RISC-V Linux Kernel Image (uncompressed) 145 Data Size: 17901204 Bytes = 17481.64 KiB = 17.07 MiB 146 Load Address: 00000000 147 Entry Point: 00000000 148 149 4. Copy bootmImage-bbl.bin and ae350.dtb to qemu sd card image 150 5. Message of booting riscv-linux from bbl via u-boot on qemu 151 152 U-Boot 2018.03-rc4-00031-g2631273 (Mar 13 2018 - 15:02:55 +0800) 153 154 DRAM: 1 GiB 155 main-loop: WARNING: I/O thread spun for 1000 iterations 156 MMC: mmc@f0e00000: 0 157 Loading Environment from SPI Flash... *** Warning - spi_flash_probe_bus_cs() failed, using default environment 158 159 Failed (-22) 160 In: serial@f0300000 161 Out: serial@f0300000 162 Err: serial@f0300000 163 Net: 164 Warning: mac@e0100000 (eth0) using random MAC address - 02:00:00:00:00:00 165 eth0: mac@e0100000 166 RISC-V # mmc rescan 167 RISC-V # mmc part 168 169 Partition Map for MMC device 0 -- Partition Type: DOS 170 171 Part Start Sector Num Sectors UUID Type 172 RISC-V # fatls mmc 0:0 173 17901268 bootmImage-bbl.bin 174 1954 ae2xx.dtb 175 176 2 file(s), 0 dir(s) 177 178 RISC-V # fatload mmc 0:0 0x00600000 bootmImage-bbl.bin 179 17901268 bytes read in 4642 ms (3.7 MiB/s) 180 RISC-V # fatload mmc 0:0 0x2000000 ae350.dtb 181 1954 bytes read in 1 ms (1.9 MiB/s) 182 RISC-V # setenv bootm_size 0x2000000 183 RISC-V # setenv fdt_high 0x1f00000 184 RISC-V # bootm 0x00600000 - 0x2000000 185 ## Booting kernel from Legacy Image at 00600000 ... 186 Image Name: 187 Image Type: RISC-V Linux Kernel Image (uncompressed) 188 Data Size: 17901204 Bytes = 17.1 MiB 189 Load Address: 00000000 190 Entry Point: 00000000 191 Verifying Checksum ... OK 192 ## Flattened Device Tree blob at 02000000 193 Booting using the fdt blob at 0x2000000 194 Loading Kernel Image ... OK 195 Loading Device Tree to 0000000001efc000, end 0000000001eff7a1 ... OK 196 [ 0.000000] OF: fdt: Ignoring memory range 0x0 - 0x200000 197 [ 0.000000] Linux version 4.14.0-00046-gf3e439f-dirty (rick@atcsqa06) (gcc version 7.1.1 20170509 (GCC)) #1 Tue Jan 9 16:34:25 CST 2018 198 [ 0.000000] bootconsole [early0] enabled 199 [ 0.000000] Initial ramdisk at: 0xffffffe000016a98 (12267008 bytes) 200 [ 0.000000] Zone ranges: 201 [ 0.000000] DMA [mem 0x0000000000200000-0x000000007fffffff] 202 [ 0.000000] Normal empty 203 [ 0.000000] Movable zone start for each node 204 [ 0.000000] Early memory node ranges 205 [ 0.000000] node 0: [mem 0x0000000000200000-0x000000007fffffff] 206 [ 0.000000] Initmem setup node 0 [mem 0x0000000000200000-0x000000007fffffff] 207 [ 0.000000] elf_hwcap is 0x112d 208 [ 0.000000] random: fast init done 209 [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 516615 210 [ 0.000000] Kernel command line: console=ttyS0,38400n8 earlyprintk=uart8250-32bit,0xf0300000 debug loglevel=7 211 [ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes) 212 [ 0.000000] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) 213 [ 0.000000] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) 214 [ 0.000000] Sorting __ex_table... 215 [ 0.000000] Memory: 2047832K/2095104K available (1856K kernel code, 204K rwdata, 532K rodata, 12076K init, 756K bss, 47272K reserved, 0K cma-reserved) 216 [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 217 [ 0.000000] NR_IRQS: 0, nr_irqs: 0, preallocated irqs: 0 218 [ 0.000000] riscv,cpu_intc,0: 64 local interrupts mapped 219 [ 0.000000] riscv,plic0,e4000000: mapped 31 interrupts to 1/2 handlers 220 [ 0.000000] clocksource: riscv_clocksource: mask: 0xffffffffffffffff max_cycles: 0x24e6a1710, max_idle_ns: 440795202120 ns 221 [ 0.000000] Calibrating delay loop (skipped), value calculated using timer frequency.. 20.00 BogoMIPS (lpj=40000) 222 [ 0.000000] pid_max: default: 32768 minimum: 301 223 [ 0.004000] Mount-cache hash table entries: 4096 (order: 3, 32768 bytes) 224 [ 0.004000] Mountpoint-cache hash table entries: 4096 (order: 3, 32768 bytes) 225 [ 0.056000] devtmpfs: initialized 226 [ 0.060000] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns 227 [ 0.064000] futex hash table entries: 256 (order: 0, 6144 bytes) 228 [ 0.068000] NET: Registered protocol family 16 229 [ 0.080000] vgaarb: loaded 230 [ 0.084000] clocksource: Switched to clocksource riscv_clocksource 231 [ 0.088000] NET: Registered protocol family 2 232 [ 0.092000] TCP established hash table entries: 16384 (order: 5, 131072 bytes) 233 [ 0.096000] TCP bind hash table entries: 16384 (order: 5, 131072 bytes) 234 [ 0.096000] TCP: Hash tables configured (established 16384 bind 16384) 235 [ 0.100000] UDP hash table entries: 1024 (order: 3, 32768 bytes) 236 [ 0.100000] UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes) 237 [ 0.104000] NET: Registered protocol family 1 238 [ 0.616000] Unpacking initramfs... 239 [ 1.220000] workingset: timestamp_bits=62 max_order=19 bucket_order=0 240 [ 1.244000] io scheduler noop registered 241 [ 1.244000] io scheduler cfq registered (default) 242 [ 1.244000] io scheduler mq-deadline registered 243 [ 1.248000] io scheduler kyber registered 244 [ 1.360000] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled 245 [ 1.368000] console [ttyS0] disabled 246 [ 1.372000] f0300000.serial: ttyS0 at MMIO 0xf0300020 (irq = 10, base_baud = 1228800) is a 16550A 247 [ 1.392000] console [ttyS0] enabled 248 [ 1.392000] ftmac100: Loading version 0.2 ... 249 [ 1.396000] ftmac100 e0100000.mac eth0: irq 8, mapped at ffffffd002005000 250 [ 1.400000] ftmac100 e0100000.mac eth0: generated random MAC address 6e:ac:c3:92:36:c0 251 [ 1.404000] IR NEC protocol handler initialized 252 [ 1.404000] IR RC5(x/sz) protocol handler initialized 253 [ 1.404000] IR RC6 protocol handler initialized 254 [ 1.404000] IR JVC protocol handler initialized 255 [ 1.408000] IR Sony protocol handler initialized 256 [ 1.408000] IR SANYO protocol handler initialized 257 [ 1.408000] IR Sharp protocol handler initialized 258 [ 1.408000] IR MCE Keyboard/mouse protocol handler initialized 259 [ 1.412000] IR XMP protocol handler initialized 260 [ 1.456000] ftsdc010 f0e00000.mmc: mmc0 - using hw SDIO IRQ 261 [ 1.464000] bootconsole [early0] uses init memory and must be disabled even before the real one is ready 262 [ 1.464000] bootconsole [early0] disabled 263 [ 1.508000] Freeing unused kernel memory: 12076K 264 [ 1.512000] This architecture does not have kernel memory protection. 265 [ 1.520000] mmc0: new SD card at address 4567 266 [ 1.524000] mmcblk0: mmc0:4567 QEMU! 20.0 MiB 267 [ 1.844000] mmcblk0: 268 Wed Dec 1 10:00:00 CST 2010 269 / # 270 271 272 273 TODO 274 ================================================== 275 Boot bbl and riscv-linux via U-Boot on AE350 board 276
README.ag101p
1 Andes Technology SoC AG101P 2 =========================== 3 4 AG101P is the mainline SoC produced by Andes Technology using N1213 CPU core 5 with FPU and DDR contoller support. 6 AG101P has integrated both AHB and APB bus and many periphals for application 7 and product development. 8 9 ADP-AG101P 10 ========= 11 12 ADP-AG101P is the SoC with AG101 hardcore CPU. 13 14 Configurations 15 ============== 16 17 CONFIG_MEM_REMAP: 18 Doing memory remap is essential for preparing some non-OS or RTOS 19 applications. 20 21 CONFIG_SKIP_LOWLEVEL_INIT: 22 If you want to boot this system from SPI ROM and bypass e-bios (the 23 other boot loader on ROM). You should undefine CONFIG_SKIP_LOWLEVEL_INIT 24 in "include/configs/adp-ag101p.h". 25 26 Build and boot steps 27 ==================== 28 29 build: 30 1. Prepare the toolchains and make sure the $PATH to toolchains is correct. 31 2. Use `make adp-ag101p_defconfig` in u-boot root to build the image. 32 33 Burn u-boot to SPI ROM: 34 ==================== 35 36 This section will be added later. 37
README.AMCC-eval-boards-cleanup
1 --------------------------------------------------------------------- 2 Cleanup of AMCC eval boards (Walnut/Sycamore, Bubinga, Ebony, Ocotea) 3 --------------------------------------------------------------------- 4 5 Changes to all AMCC eval boards: 6 -------------------------------- 7 8 o Changed u-boot image size to 256 kBytes instead of 512 kBytes on most 9 boards. 10 11 o Use 115200 baud as default console baudrate. 12 13 o Added config option to use redundant environment in flash. This is also 14 the default setting. Option for environment in nvram is still available 15 for backward compatibility. 16 17 o Merged board specific flash drivers to common flash driver: 18 board/amcc/common/flash.c 19 20 21 Sycamore/Walnut (one port supporting both eval boards): 22 ------------------------------------------------------- 23 24 o Cleanup to allow easier "cloning" for different (custom) boards: 25 26 o Moved EBC configuration from board specific asm-file "init.S" 27 using defines in board configuration file. No board specific 28 asm file needed anymore. 29 30 31 August 01 2005, Stefan Roese <sr (a] denx.de> 32
README.android-fastboot
1 ================ 2 Android Fastboot 3 ================ 4 5 Overview 6 ======== 7 8 The protocol that is used over USB and UDP is described in the 9 ``README.android-fastboot-protocol`` file in the same directory. 10 11 The current implementation supports the following standard commands: 12 13 - ``boot`` 14 - ``continue`` 15 - ``download`` 16 - ``erase`` (if enabled) 17 - ``flash`` (if enabled) 18 - ``getvar`` 19 - ``reboot`` 20 - ``reboot-bootloader`` 21 - ``set_active`` (only a stub implementation which always succeeds) 22 23 The following OEM commands are supported (if enabled): 24 25 - oem format - this executes ``gpt write mmc %x $partitions`` 26 27 Support for both eMMC and NAND devices is included. 28 29 Client installation 30 =================== 31 32 The counterpart to this is the fastboot client which can be found in 33 Android's ``platform/system/core`` repository in the fastboot 34 folder. It runs on Windows, Linux and OSX. The fastboot client is 35 part of the Android SDK Platform-Tools and can be downloaded from: 36 37 https://developer.android.com/studio/releases/platform-tools 38 39 Board specific 40 ============== 41 42 USB configuration 43 ----------------- 44 45 The fastboot gadget relies on the USB download gadget, so the following 46 options must be configured: 47 48 :: 49 50 CONFIG_USB_GADGET_DOWNLOAD 51 CONFIG_USB_GADGET_VENDOR_NUM 52 CONFIG_USB_GADGET_PRODUCT_NUM 53 CONFIG_USB_GADGET_MANUFACTURER 54 55 NOTE: The ``CONFIG_USB_GADGET_VENDOR_NUM`` must be one of the numbers 56 supported by the fastboot client. The list of vendor IDs supported can 57 be found in the fastboot client source code. 58 59 General configuration 60 --------------------- 61 62 The fastboot protocol requires a large memory buffer for 63 downloads. This buffer should be as large as possible for a 64 platform. The location of the buffer and size are set with 65 ``CONFIG_FASTBOOT_BUF_ADDR`` and ``CONFIG_FASTBOOT_BUF_SIZE``. These 66 may be overridden on the fastboot command line using ``-l`` and 67 ``-s``. 68 69 Fastboot environment variables 70 ============================== 71 72 Partition aliases 73 ----------------- 74 75 Fastboot partition aliases can also be defined for devices where GPT 76 limitations prevent user-friendly partition names such as "boot", "system" 77 and "cache". Or, where the actual partition name doesn't match a standard 78 partition name used commonly with fastboot. 79 80 The current implementation checks aliases when accessing partitions by 81 name (flash_write and erase functions). To define a partition alias 82 add an environment variable similar to: 83 84 ``fastboot_partition_alias_<alias partition name>=<actual partition name>`` 85 86 for example: 87 88 ``fastboot_partition_alias_boot=LNX`` 89 90 Variable overrides 91 ------------------ 92 93 Variables retrived through ``getvar`` can be overridden by defining 94 environment variables of the form ``fastboot.<variable>``. These are 95 looked up first so can be used to override values which would 96 otherwise be returned. Using this mechanism you can also return types 97 for NAND filesystems, as the fully parameterised variable is looked 98 up, e.g. 99 100 ``fastboot.partition-type:boot=jffs2`` 101 102 Boot command 103 ------------ 104 105 When executing the fastboot ``boot`` command, if ``fastboot_bootcmd`` is set then 106 that will be executed in place of ``bootm <CONFIG_FASTBOOT_BUF_ADDR>``. 107 108 Partition Names 109 =============== 110 111 The Fastboot implementation in U-Boot allows to write images into disk 112 partitions. Target partitions are referred on the host computer by 113 their names. 114 115 For GPT/EFI the respective partition name is used. 116 117 For MBR the partitions are referred by generic names according to the 118 following schema: 119 120 <device type><device index letter><partition index> 121 122 Example: ``hda3``, ``sdb1``, ``usbda1`` 123 124 The device type is as follows: 125 126 * IDE, ATAPI and SATA disks: ``hd`` 127 * SCSI disks: ``sd`` 128 * USB media: ``usbd`` 129 * MMC and SD cards: ``mmcsd`` 130 * Disk on chip: ``docd`` 131 * other: ``xx`` 132 133 The device index starts from ``a`` and refers to the interface (e.g. USB 134 controller, SD/MMC controller) or disk index. The partition index starts 135 from ``1`` and describes the partition number on the particular device. 136 137 Writing Partition Table 138 ======================= 139 140 Fastboot also allows to write the partition table to the media. This can be 141 done by writing the respective partition table image to a special target 142 "gpt" or "mbr". These names can be customized by defining the following 143 configuration options: 144 145 :: 146 147 CONFIG_FASTBOOT_GPT_NAME 148 CONFIG_FASTBOOT_MBR_NAME 149 150 In Action 151 ========= 152 153 Enter into fastboot by executing the fastboot command in U-Boot for either USB: 154 155 :: 156 157 => fastboot usb 0 158 159 or UDP: 160 161 :: 162 163 => fastboot udp 164 link up on port 0, speed 100, full duplex 165 Using ethernet@4a100000 device 166 Listening for fastboot command on 192.168.0.102 167 168 On the client side you can fetch the bootloader version for instance: 169 170 :: 171 172 $ fastboot getvar bootloader-version 173 bootloader-version: U-Boot 2014.04-00005-gd24cabc 174 finished. total time: 0.000s 175 176 or initiate a reboot: 177 178 :: 179 180 $ fastboot reboot 181 182 and once the client comes back, the board should reset. 183 184 You can also specify a kernel image to boot. You have to either specify 185 the an image in Android format *or* pass a binary kernel and let the 186 fastboot client wrap the Android suite around it. On OMAP for instance you 187 take zImage kernel and pass it to the fastboot client: 188 189 :: 190 191 $ fastboot -b 0x80000000 -c "console=ttyO2 earlyprintk root=/dev/ram0 mem=128M" boot zImage 192 creating boot image... 193 creating boot image - 1847296 bytes 194 downloading 'boot.img'... 195 OKAY [ 2.766s] 196 booting... 197 OKAY [ -0.000s] 198 finished. total time: 2.766s 199 200 and on the U-Boot side you should see: 201 202 :: 203 204 Starting download of 1847296 bytes 205 ........................................................ 206 downloading of 1847296 bytes finished 207 Booting kernel.. 208 ## Booting Android Image at 0x81000000 ... 209 Kernel load addr 0x80008000 size 1801 KiB 210 Kernel command line: console=ttyO2 earlyprintk root=/dev/ram0 mem=128M 211 Loading Kernel Image ... OK 212 OK 213 214 Starting kernel ... 215
README.android-fastboot-protocol
1 FastBoot Version 0.4 2 ---------------------- 3 4 The fastboot protocol is a mechanism for communicating with bootloaders 5 over USB. It is designed to be very straightforward to implement, to 6 allow it to be used across a wide range of devices and from hosts running 7 Linux, Windows, or OSX. 8 9 10 Basic Requirements 11 ------------------ 12 13 * Two bulk endpoints (in, out) are required 14 * Max packet size must be 64 bytes for full-speed and 512 bytes for 15 high-speed USB 16 * The protocol is entirely host-driven and synchronous (unlike the 17 multi-channel, bi-directional, asynchronous ADB protocol) 18 19 20 Transport and Framing 21 --------------------- 22 23 1. Host sends a command, which is an ascii string in a single 24 packet no greater than 64 bytes. 25 26 2. Client response with a single packet no greater than 64 bytes. 27 The first four bytes of the response are "OKAY", "FAIL", "DATA", 28 or "INFO". Additional bytes may contain an (ascii) informative 29 message. 30 31 a. INFO -> the remaining 60 bytes are an informative message 32 (providing progress or diagnostic messages). They should 33 be displayed and then step #2 repeats 34 35 b. FAIL -> the requested command failed. The remaining 60 bytes 36 of the response (if present) provide a textual failure message 37 to present to the user. Stop. 38 39 c. OKAY -> the requested command completed successfully. Go to #5 40 41 d. DATA -> the requested command is ready for the data phase. 42 A DATA response packet will be 12 bytes long, in the form of 43 DATA00000000 where the 8 digit hexidecimal number represents 44 the total data size to transfer. 45 46 3. Data phase. Depending on the command, the host or client will 47 send the indicated amount of data. Short packets are always 48 acceptable and zero-length packets are ignored. This phase continues 49 until the client has sent or received the number of bytes indicated 50 in the "DATA" response above. 51 52 4. Client responds with a single packet no greater than 64 bytes. 53 The first four bytes of the response are "OKAY", "FAIL", or "INFO". 54 Similar to #2: 55 56 a. INFO -> display the remaining 60 bytes and return to #4 57 58 b. FAIL -> display the remaining 60 bytes (if present) as a failure 59 reason and consider the command failed. Stop. 60 61 c. OKAY -> success. Go to #5 62 63 5. Success. Stop. 64 65 66 Example Session 67 --------------- 68 69 Host: "getvar:version" request version variable 70 71 Client: "OKAY0.4" return version "0.4" 72 73 Host: "getvar:nonexistant" request some undefined variable 74 75 Client: "OKAY" return value "" 76 77 Host: "download:00001234" request to send 0x1234 bytes of data 78 79 Client: "DATA00001234" ready to accept data 80 81 Host: < 0x1234 bytes > send data 82 83 Client: "OKAY" success 84 85 Host: "flash:bootloader" request to flash the data to the bootloader 86 87 Client: "INFOerasing flash" indicate status / progress 88 "INFOwriting flash" 89 "OKAY" indicate success 90 91 Host: "powerdown" send a command 92 93 Client: "FAILunknown command" indicate failure 94 95 96 Command Reference 97 ----------------- 98 99 * Command parameters are indicated by printf-style escape sequences. 100 101 * Commands are ascii strings and sent without the quotes (which are 102 for illustration only here) and without a trailing 0 byte. 103 104 * Commands that begin with a lowercase letter are reserved for this 105 specification. OEM-specific commands should not begin with a 106 lowercase letter, to prevent incompatibilities with future specs. 107 108 "getvar:%s" Read a config/version variable from the bootloader. 109 The variable contents will be returned after the 110 OKAY response. 111 112 "download:%08x" Write data to memory which will be later used 113 by "boot", "ramdisk", "flash", etc. The client 114 will reply with "DATA%08x" if it has enough 115 space in RAM or "FAIL" if not. The size of 116 the download is remembered. 117 118 "verify:%08x" Send a digital signature to verify the downloaded 119 data. Required if the bootloader is "secure" 120 otherwise "flash" and "boot" will be ignored. 121 122 "flash:%s" Write the previously downloaded image to the 123 named partition (if possible). 124 125 "erase:%s" Erase the indicated partition (clear to 0xFFs) 126 127 "boot" The previously downloaded data is a boot.img 128 and should be booted according to the normal 129 procedure for a boot.img 130 131 "continue" Continue booting as normal (if possible) 132 133 "reboot" Reboot the device. 134 135 "reboot-bootloader" Reboot back into the bootloader. 136 Useful for upgrade processes that require upgrading 137 the bootloader and then upgrading other partitions 138 using the new bootloader. 139 140 "powerdown" Power off the device. 141 142 143 144 Client Variables 145 ---------------- 146 147 The "getvar:%s" command is used to read client variables which 148 represent various information about the device and the software 149 on it. 150 151 The various currently defined names are: 152 153 version Version of FastBoot protocol supported. 154 It should be "0.3" for this document. 155 156 version-bootloader Version string for the Bootloader. 157 158 version-baseband Version string of the Baseband Software 159 160 product Name of the product 161 162 serialno Product serial number 163 164 secure If the value is "yes", this is a secure 165 bootloader requiring a signature before 166 it will install or boot images. 167 168 Names starting with a lowercase character are reserved by this 169 specification. OEM-specific names should not start with lowercase 170 characters. 171
README.ARC
1 Synopsys' DesignWare(r) ARC(r) Processors are a family of 32-bit CPUs 2 that SoC designers can optimize for a wide range of uses, from deeply embedded 3 to high-performance host applications. 4 5 More information on ARC cores avaialble here: 6 http://www.synopsys.com/IP/ProcessorIP/ARCProcessors/Pages/default.aspx 7 8 Designers can differentiate their products by using patented configuration 9 technology to tailor each ARC processor instance to meet specific performance, 10 power and area requirements. 11 12 The DesignWare ARC processors are also extendable, allowing designers to add 13 their own custom instructions that dramatically increase performance. 14 15 Synopsys' ARC processors have been used by over 170 customers worldwide who 16 collectively ship more than 1 billion ARC-based chips annually. 17 18 All DesignWare ARC processors utilize a 16-/32-bit ISA that provides excellent 19 performance and code density for embedded and host SoC applications. 20 21 The RISC microprocessors are synthesizable and can be implemented in any foundry 22 or process, and are supported by a complete suite of development tools. 23 24 The ARC GNU toolchain with support for all ARC Processors can be downloaded 25 from here (available pre-built toolchains as well): 26 27 https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases 28
README.arm-caches
1 Disabling I-cache: 2 - Set CONFIG_SYS_ICACHE_OFF 3 4 Disabling D-cache: 5 - Set CONFIG_SYS_DCACHE_OFF 6 7 Enabling I-cache: 8 - Make sure CONFIG_SYS_ICACHE_OFF is not set and call icache_enable(). 9 10 Enabling D-cache: 11 - Make sure CONFIG_SYS_DCACHE_OFF is not set and call dcache_enable(). 12 13 Enabling Caches at System Startup: 14 - Implement enable_caches() for your platform and enable the I-cache and 15 D-cache from this function. This function is called immediately 16 after relocation. 17 18 Guidelines for Working with D-cache: 19 20 Memory to Peripheral DMA: 21 - Flush the buffer after the MPU writes the data and before the DMA is 22 initiated. 23 24 Peripheral to Memory DMA: 25 - Invalidate the buffer before starting the DMA. In case there are any dirty 26 lines from the DMA buffer in the cache, subsequent cache-line replacements 27 may corrupt the buffer in memory while the DMA is still going on. Cache-line 28 replacement can happen if the CPU tries to bring some other memory locations 29 into the cache while the DMA is going on. 30 - Invalidate the buffer after the DMA is complete and before the MPU reads 31 it. This may be needed in addition to the invalidation before the DMA 32 mentioned above, because in some processors memory contents can spontaneously 33 come to the cache due to speculative memory access by the CPU. If this 34 happens with the DMA buffer while DMA is going on we have a coherency problem. 35 36 Buffer Requirements: 37 - Any buffer that is invalidated(that is, typically the peripheral to 38 memory DMA buffer) should be aligned to cache-line boundary both at 39 at the beginning and at the end of the buffer. 40 - If the buffer is not cache-line aligned invalidation will be restricted 41 to the aligned part. That is, one cache-line at the respective boundary 42 may be left out while doing invalidation. 43 - A suitable buffer can be alloced on the stack using the 44 ALLOC_CACHE_ALIGN_BUFFER macro. 45 46 Cleanup Before Linux: 47 - cleanup_before_linux() should flush the D-cache, invalidate I-cache, and 48 disable MMU and caches. 49 - The following sequence is advisable while disabling d-cache: 50 1. dcache_disable() - flushes and disables d-cache 51 2. invalidate_dcache_all() - invalid any entry that came to the cache 52 in the short period after the cache was flushed but before the 53 cache got disabled. 54
README.ARM-memory-map
1 Subject: Re: [PATCH][CFT] bring ARM memory layout in line with the documented behaviour 2 From: "Anders Larsen" <alarsen (a] rea.de> 3 Date: Thu, 18 Sep 2003 14:15:21 +0200 4 To: Wolfgang Denk <wd (a] denx.de> 5 6 ... 7 >I still see references to _armboot_start, _armboot_end_data, and 8 >_armboot_end - which role do these play now? Can we get rid of them? 9 > 10 >How are they (should they be) set in your memory map above? 11 12 _armboot_start contains the value of CONFIG_SYS_TEXT_BASE (0xA07E0000); it seems 13 CONFIG_SYS_TEXT_BASE and _armboot_start are both used for the same purpose in 14 different parts of the (ARM) code. 15 Furthermore, the startup code (cpu/<arm>/start.S) internally uses 16 another variable (_TEXT_BASE) with the same content as _armboot_start. 17 I agree that this mess should be cleaned up. 18
README.arm-relocation
1 To make relocation on arm working, the following changes are done: 2 3 At arch level: add linker flag -pie 4 5 This causes the linker to generate fixup tables .rel.dyn and .dynsym, 6 which must be applied to the relocated image before transferring 7 control to it. 8 9 These fixups are described in the ARM ELF documentation as type 23 10 (program-base-relative) and 2 (symbol-relative) 11 12 At cpu level: modify linker file and add a relocation and fixup loop 13 14 the linker file must be modified to include the .rel.dyn and .dynsym 15 tables in the binary image, and to provide symbols for the relocation 16 code to access these tables 17 18 The relocation and fixup loop must be executed after executing 19 board_init_f at initial location and before executing board_init_r 20 at final location. 21 22 At board level: 23 24 dram_init(): bd pointer is now at this point not accessible, so only 25 detect the real dramsize, and store it in gd->ram_size. Bst detected 26 with get_ram_size(). 27 28 TODO: move also dram initialization there on boards where it is possible. 29 30 Setup of the the bd_t dram bank info is done in the new function 31 dram_init_banksize() called after bd is accessible. 32 33 At lib level: 34 35 Board.c code is adapted from ppc code 36 37 * WARNING ** WARNING ** WARNING ** WARNING ** WARNING ** WARNING ** WARNING * 38 39 Boards which are not fixed to support relocation will be REMOVED! 40 41 ----------------------------------------------------------------------------- 42 43 For boards which boot from spl, it is possible to save one copy 44 if CONFIG_SYS_TEXT_BASE == relocation address! This prevents that uboot code 45 is copied again in relocate_code(). 46 47 example for the tx25 board booting from NAND Flash: 48 49 a) cpu starts 50 b) it copies the first page in nand to internal ram 51 (spl code) 52 c) end executes this code 53 d) this initialize CPU, RAM, ... and copy itself to RAM 54 (this bin must fit in one page, so board_init_f() 55 don;t fit in it ... ) 56 e) there it copy u-boot to CONFIG_SYS_NAND_U_BOOT_DST and 57 starts this image @ CONFIG_SYS_NAND_U_BOOT_START 58 f) u-boot code steps through board_init_f() and calculates 59 the relocation address and copy itself to it 60 61 If CONFIG_SYS_TEXT_BASE == relocation address, the copying of u-boot 62 in f) could be saved. 63 64 ----------------------------------------------------------------------------- 65 66 TODO 67 68 - fill in bd_t infos (check) 69 - adapt all boards 70 71 - maybe adapt CONFIG_SYS_TEXT_BASE (this must be checked from board maintainers) 72 This *must* be done for boards, which boot from NOR flash 73 74 on other boards if CONFIG_SYS_TEXT_BASE = relocation baseaddr, this saves 75 one copying from u-boot code. 76 77 - new function dram_init_banksize() is actual board specific. Maybe 78 we make a weak default function in arch/arm/lib/board.c ? 79 80 ----------------------------------------------------------------------------- 81 82 Relocation with SPL (example for the tx25 booting from NAND Flash): 83 84 - cpu copies the first page from NAND to 0xbb000000 (IMX_NFC_BASE) 85 and start with code execution on this address. 86 87 - The First page contains u-boot code from drivers/mtd/nand/mxc_nand_spl.c 88 which inits the dram, cpu registers, reloacte itself to CONFIG_SPL_TEXT_BASE and loads 89 the "real" u-boot to CONFIG_SYS_NAND_U_BOOT_DST and starts execution 90 @CONFIG_SYS_NAND_U_BOOT_START 91 92 - This u-boot does no RAM init, nor CPU register setup. Just look 93 where it has to copy and relocate itself to this address. If 94 relocate address = CONFIG_SYS_TEXT_BASE (not the same, as the 95 CONFIG_SPL_TEXT_BASE from the spl code), then there is no need 96 to copy, just go on with bss clear and jump to board_init_r. 97 98 ----------------------------------------------------------------------------- 99 100 How ELF relocations 23 and 2 work. 101 102 TBC 103 104 ------------------------------------------------------------------------------------- 105 106 Debugging u-boot in RAM: 107 (example on the qong board) 108 109 ----------------- 110 111 a) start debugger 112 113 arm-linux-gdb u-boot 114 115 [hs@pollux u-boot]$ arm-linux-gdb u-boot 116 GNU gdb Red Hat Linux (6.7-2rh) 117 Copyright (C) 2007 Free Software Foundation, Inc. 118 License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> 119 This is free software: you are free to change and redistribute it. 120 There is NO WARRANTY, to the extent permitted by law. Type "show copying" 121 and "show warranty" for details. 122 This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-linux". 123 The target architecture is set automatically (currently arm) 124 .. 125 (gdb) 126 127 ----------------- 128 129 b) connect to target 130 131 target remote bdi10:2001 132 133 (gdb) target remote bdi10:2001 134 Remote debugging using bdi10:2001 135 0x8ff17f10 in ?? () 136 (gdb) 137 138 ----------------- 139 140 c) discard symbol-file 141 142 (gdb) symbol-file 143 Discard symbol table from `/home/hs/celf/u-boot/u-boot'? (y or n) y 144 No symbol file now. 145 (gdb) 146 147 ----------------- 148 149 d) load new symbol table: 150 151 (gdb) add-symbol-file u-boot 0x8ff08000 152 add symbol table from file "u-boot" at 153 .text_addr = 0x8ff08000 154 (y or n) y 155 Reading symbols from /home/hs/celf/u-boot/u-boot...done. 156 (gdb) c 157 Continuing. 158 ^C 159 Program received signal SIGSTOP, Stopped (signal). 160 0x8ff17f18 in serial_getc () at serial_mxc.c:192 161 192 while (__REG(UART_PHYS + UTS) & UTS_RXEMPTY); 162 (gdb) 163 164 add-symbol-file u-boot 0x8ff08000 165 ^^^^^^^^^^ 166 get this address from u-boot bdinfo command 167 or get it from gd->relocaddr in gdb 168 169 => bdinfo 170 rch_number = XXXXXXXXXX 171 boot_params = XXXXXXXXXX 172 DRAM bank = XXXXXXXXXX 173 -> start = XXXXXXXXXX 174 -> size = XXXXXXXXXX 175 ethaddr = XXXXXXXXXX 176 ip_addr = XXXXXXXXXX 177 baudrate = XXXXXXXXXX 178 TLB addr = XXXXXXXXXX 179 relocaddr = 0x8ff08000 180 ^^^^^^^^^^ 181 reloc off = XXXXXXXXXX 182 irq_sp = XXXXXXXXXX 183 sp start = XXXXXXXXXX 184 FB base = XXXXXXXXXX 185 186 or interrupt execution by any means and re-load the symbols at the location 187 specified by gd->relocaddr -- this is only valid after board_init_f. 188 189 (gdb) set $s = gd->relocaddr 190 (gdb) symbol-file 191 (gdb) add-symbol-file u-boot $s 192 193 Now you can use gdb as usual :-) 194
README.arm64
1 U-Boot for arm64 2 3 Summary 4 ======= 5 The initial arm64 U-Boot port was developed before hardware was available, 6 so the first supported platforms were the Foundation and Fast Model for ARMv8. 7 These days U-Boot runs on a variety of 64-bit capable ARM hardware, from 8 embedded development boards to servers. 9 10 Notes 11 ===== 12 13 1. U-Boot can run at any exception level it is entered in, it is 14 recommened to enter it in EL3 if U-Boot takes some responsibilities of a 15 classical firmware (like initial hardware setup, CPU errata workarounds 16 or SMP bringup). U-Boot can be entered in EL2 when its main purpose is 17 that of a boot loader. It can drop to lower exception levels before 18 entering the OS. 19 20 2. U-Boot for arm64 is compiled with AArch64-gcc. AArch64-gcc 21 use rela relocation format, a tool(tools/relocate-rela) by Scott Wood 22 is used to encode the initial addend of rela to u-boot.bin. After running, 23 the U-Boot will be relocated to destination again. 24 25 3. Earlier Linux kernel versions required the FDT to be placed at a 26 2 MB boundary and within the same 512 MB section as the kernel image, 27 resulting in fdt_high to be defined specially. 28 Since kernel version 4.2 Linux is more relaxed about the DT location, so it 29 can be placed anywhere in memory. 30 Please reference linux/Documentation/arm64/booting.txt for detail. 31 32 4. Spin-table is used to wake up secondary processors. One location 33 (or per processor location) is defined to hold the kernel entry point 34 for secondary processors. It must be ensured that the location is 35 accessible and zero immediately after secondary processor 36 enter slave_cpu branch execution in start.S. The location address 37 is encoded in cpu node of DTS. Linux kernel store the entry point 38 of secondary processors to it and send event to wakeup secondary 39 processors. 40 Please reference linux/Documentation/arm64/booting.txt for detail. 41 42 5. Generic board is supported. 43 44 6. CONFIG_ARM64 instead of CONFIG_ARMV8 is used to distinguish aarch64 and 45 aarch32 specific codes. 46 47 48 Contributors 49 ============ 50 Tom Rini <trini (a] ti.com> 51 Scott Wood <scottwood (a] freescale.com> 52 York Sun <yorksun (a] freescale.com> 53 Simon Glass <sjg (a] chromium.org> 54 Sharma Bhupesh <bhupesh.sharma (a] freescale.com> 55 Rob Herring <robherring2 (a] gmail.com> 56 Sergey Temerkhanov <s.temerkhanov (a] gmail.com> 57
README.armada-secureboot
1 The trusted boot framework on Marvell Armada 38x 2 ================================================ 3 4 Contents: 5 6 1. Overview of the trusted boot 7 2. Terminology 8 3. Boot image layout 9 4. The secured header 10 5. The secured boot flow 11 6. Usage example 12 7. Work to be done 13 8. Bibliography 14 15 1. Overview of the trusted boot 16 ------------------------------- 17 18 The Armada's trusted boot framework enables the SoC to cryptographically verify 19 a specially prepared boot image. This can be used to establish a chain of trust 20 from the boot firmware all the way to the OS. 21 22 To achieve this, the Armada SoC requires a specially prepared boot image, which 23 contains the relevant cryptographic data, as well as other information 24 pertaining to the boot process. Furthermore, a eFuse structure (a 25 one-time-writeable memory) need to be configured in the correct way. 26 27 Roughly, the secure boot process works as follows: 28 29 * Load the header block of the boot image, extract a special "root" public RSA 30 key from it, and verify its SHA-256 hash against a SHA-256 stored in a eFuse 31 field. 32 * Load an array of code signing public RSA keys from the header block, and 33 verify its RSA signature (contained in the header block as well) using the 34 "root" RSA key. 35 * Choose a code signing key, and use it to verify the header block (excluding 36 the key array). 37 * Verify the binary image's signature (contained in the header block) using the 38 code signing key. 39 * If all checks pass successfully, boot the image. 40 41 The chain of trust is thus as follows: 42 43 * The SHA-256 value in the eFuse field verifies the "root" public key. 44 * The "root" public key verifies the code signing key array. 45 * The selected code signing key verifies the header block and the binary image. 46 47 In the special case of building a boot image containing U-Boot as the binary 48 image, which employs this trusted boot framework, the following tasks need to 49 be addressed: 50 51 1. Creation of the needed cryptographic key material. 52 2. Creation of a conforming boot image containing the U-Boot image as binary 53 image. 54 3. Burning the necessary eFuse values. 55 56 (1) will be addressed later, (2) will be taken care of by U-Boot's build 57 system (some user configuration is required, though), and for (3) the necessary 58 data (essentially a series of U-Boot commands to be entered at the U-Boot 59 command prompt) will be created by the build system as well. 60 61 The documentation of the trusted boot mode is contained in part 1, chapter 62 7.2.5 in the functional specification [1], and in application note [2]. 63 64 2. Terminology 65 -------------- 66 67 CSK - Code Signing Key(s): An array of RSA key pairs, which 68 are used to sign and verify the secured header and the 69 boot loader image. 70 KAK - Key Authentication Key: A RSA key pair, which is used 71 to sign and verify the array of CSKs. 72 Header block - The first part of the boot image, which contains the 73 image's headers (also known as "headers block", "boot 74 header", and "image header") 75 eFuse - A one-time-writeable memory. 76 BootROM - The Armada's built-in boot firmware, which is 77 responsible for verifying and starting secure images. 78 Boot image - The complete image the SoC's boot firmware loads 79 (contains the header block and the binary image) 80 Main header - The header in the header block containing information 81 and data pertaining to the boot process (used for both 82 the regular and secured boot processes) 83 Binary image - The binary code payload of the boot image; in this 84 case the U-Boot's code (also known as "source image", 85 or just "image") 86 Secured header - The specialized header in the header block that 87 contains information and data pertaining to the 88 trusted boot (also known as "security header") 89 Secured boot mode - A special boot mode of the Armada SoC in which secured 90 images are verified (non-secure images won't boot); 91 the mode is activated by setting a eFuse field. 92 Trusted debug mode - A special mode for the trusted boot that allows 93 debugging of devices employing the trusted boot 94 framework in a secure manner (untested in the current 95 implementation). 96 Trusted boot framework - The ARMADA SoC's implementation of a secure verified 97 boot process. 98 99 3. Boot image layout 100 -------------------- 101 102 +-- Boot image --------------------------------------------+ 103 | | 104 | +-- Header block --------------------------------------+ | 105 | | Main header | | 106 | +------------------------------------------------------+ | 107 | | Secured header | | 108 | +------------------------------------------------------+ | 109 | | BIN header(s) | | 110 | +------------------------------------------------------+ | 111 | | REG header(s) | | 112 | +------------------------------------------------------+ | 113 | | Padding | | 114 | +------------------------------------------------------+ | 115 | | 116 | +------------------------------------------------------+ | 117 | | Binary image + checksum | | 118 | +------------------------------------------------------+ | 119 +----------------------------------------------------------+ 120 121 4. The secured header 122 --------------------- 123 124 For the trusted boot framework, a additional header is added to the boot image. 125 The following data are relevant for the secure boot: 126 127 KAK: The KAK is contained in the secured header in the form 128 of a RSA-2048 public key in DER format with a length of 129 524 bytes. 130 Header block signature: The RSA signature of the header block (excluding the 131 CSK array), created using the selected CSK. 132 Binary image signature: The RSA signature of the binary image, created using 133 the selected CSK. 134 CSK array: The array of the 16 CSKs as RSA-2048 public keys in DER 135 format with a length of 8384 = 16 * 524 bytes. 136 CSK block signature: The RSA signature of the CSK array, created using the 137 KAK. 138 139 NOTE: The JTAG delay, Box ID, and Flash ID header fields do play a role in the 140 trusted boot process to enable and configure secure debugging, but they were 141 not tested in the current implementation of the trusted boot in U-Boot. 142 143 5. The secured boot flow 144 ------------------------ 145 146 The steps in the boot flow that are relevant for the trusted boot framework 147 proceed as follows: 148 149 1) Check if trusted boot is enabled, and perform regular boot if it is not. 150 2) Load the secured header, and verify its checksum. 151 3) Select the lowest valid CSK from CSK0 to CSK15. 152 4) Verify the SHA-256 hash of the KAK embedded in the secured header. 153 5) Verify the RSA signature of the CSK block from the secured header with the 154 KAK. 155 6) Verify the header block signature (which excludes the CSK block) from the 156 secured header with the selected CSK. 157 7) Load the binary image to the main memory and verify its checksum. 158 8) Verify the binary image's RSA signature from the secured header with the 159 selected CSK. 160 9) Continue the boot process as in the case of the regular boot. 161 162 NOTE: All RSA signatures are verified according to the PKCS #1 v2.1 standard 163 described in [3]. 164 165 NOTE: The Box ID and Flash ID are checked after step 6, and the trusted debug 166 mode may be entered there, but since this mode is untested in the current 167 implementation, it is not described further. 168 169 6. Usage example 170 ---------------- 171 172 ### Create key material 173 174 To employ the trusted boot framework, cryptographic key material needs to be 175 created. In the current implementation, two keys are needed to build a valid 176 secured boot image: The KAK private key and a CSK private key (both have to be 177 2048 bit RSA keys in PEM format). Note that the usage of more than one CSK is 178 currently not supported. 179 180 NOTE: Since the public key can be generated from the private key, it is 181 sufficient to store the private key for each key pair. 182 183 OpenSSL can be used to generate the needed files kwb_kak.key and kwb_csk.key 184 (the names of these files have to be configured, see the next section on 185 kwbimage.cfg settings): 186 187 openssl genrsa -out kwb_kak.key 2048 188 openssl genrsa -out kwb_csk.key 2048 189 190 The generated files have to be placed in the U-Boot root directory. 191 192 Alternatively, instead of copying the files, symlinks to the private keys can 193 be placed in the U-Boot root directory. 194 195 WARNING: Knowledge of the KAK or CSK private key would enable an attacker to 196 generate secured boot images containing arbitrary code. Hence, the private keys 197 should be carefully guarded. 198 199 ### Create/Modifiy kwbimage.cfg 200 201 The Kirkwook architecture in U-Boot employs a special board-specific 202 configuration file (kwbimage.cfg), which controls various boot image settings 203 that are interpreted by the BootROM, such as the boot medium. The support the 204 trusted boot framework, several new options were added to faciliate 205 configuration of the secured boot. 206 207 The configuration file's layout has been retained, only the following new 208 options were added: 209 210 KAK - The name of the KAK RSA private key file in the U-Boot 211 root directory, without the trailing extension of ".key". 212 CSK - The name of the (active) CSK RSA private key file in the 213 U-Boot root directory, without the trailing extension of 214 ".key". 215 BOX_ID - The BoxID to be used for trusted debugging (a integer 216 value). 217 FLASH_ID - The FlashID to be used for trusted debugging (a integer 218 value). 219 JTAG_DELAY - The JTAG delay to be used for trusted debugging (a 220 integer value). 221 CSK_INDEX - The index of the active CSK (a integer value). 222 SEC_SPECIALIZED_IMG - Flag to indicate whether to include the BoxID and FlashID 223 in the image (that is, whether to use the trusted debug 224 mode or not); no parameters. 225 SEC_BOOT_DEV - The boot device from which the trusted boot is allowed to 226 proceed, identified via a numeric ID. The tested values 227 are 0x34 = NOR flash, 0x31 = SDIO/MMC card; for 228 additional ID values, consult the documentation in [1]. 229 SEC_FUSE_DUMP - Dump the "fuse prog" commands necessary for writing the 230 correct eFuse values to a text file in the U-Boot root 231 directory. The parameter is the architecture for which to 232 dump the commands (currently only "a38x" is supported). 233 234 The parameter values may be hardcoded into the file, but it is also possible to 235 employ a dynamic approach of creating a Autoconf-like kwbimage.cfg.in, then 236 reading configuration values from Kconfig options or from the board config 237 file, and generating the actual kwbimage.cfg from this template using Makefile 238 mechanisms (see board/gdsys/a38x/Makefile as an example for this approach). 239 240 ### Set config options 241 242 To enable the generation of trusted boot images, the corresponding support 243 needs to be activated, and a index for the active CSK needs to be selected as 244 well. 245 246 Furthermore, eFuse writing support has to be activated in order to burn the 247 eFuse structure's values (this option is just needed for programming the eFuse 248 structure; production boot images may disable it). 249 250 ARM architecture 251 -> [*] Build image for trusted boot 252 (0) Index of active CSK 253 -> [*] Enable eFuse support 254 [ ] Fake eFuse access (dry run) 255 256 ### Build and test boot image 257 258 The creation of the boot image is done via the usual invocation of make (with a 259 suitably set CROSS_COMPILE environment variable, of course). The resulting boot 260 image u-boot-spl.kwb can then be tested, if so desired. The hdrparser from [5] 261 can be used for this purpose. To build the tool, invoke make in the 262 'tools/marvell/doimage_mv' directory of [5], which builds a stand-alone 263 hdrparser executable. A test can be conducted by calling hdrparser with the 264 produced boot image and the following (mandatory) parameters: 265 266 ./hdrparser -k 0 -t u-boot-spl.kwb 267 268 Here we assume that the CSK index is 0 and the boot image file resides in the 269 same directory (adapt accordingly if needed). The tool should report that all 270 checksums are valid ("GOOD"), that all signature verifications succeed 271 ("PASSED"), and, finally, that the overall test was successful 272 ("T E S T S U C C E E D E D" in the last line of output). 273 274 ### Burn eFuse structure 275 276 +----------------------------------------------------------+ 277 | WARNING: Burning the eFuse structure is a irreversible | 278 | operation! Should wrong or corrupted values be used, the | 279 | board won't boot anymore, and recovery is likely | 280 | impossible! | 281 +----------------------------------------------------------+ 282 283 After the build process has finished, and the SEC_FUSE_DUMP option was set in 284 the kwbimage.cfg was set, a text file kwb_fuses_a38x.txt should be present in 285 the U-Boot top-level directory. It contains all the necessary commands to set 286 the eFuse structure to the values needed for the used KAK digest, as well as 287 the CSK index, Flash ID and Box ID that were selected in kwbimage.cfg. 288 289 Sequentially executing the commands in this file at the U-Boot command prompt 290 will write these values to the eFuse structure. 291 292 If the SEC_FUSE_DUMP option was not set, the commands needed to burn the fuses 293 have to be crafted by hand. The needed fuse lines can be looked up in [1]; a 294 rough overview of the process is: 295 296 * Burn the KAK public key hash. The hash itself can be found in the file 297 pub_kak_hash.txt in the U-Boot top-level directory; be careful to account for 298 the endianness! 299 * Burn the CSK selection, BoxID, and FlashID 300 * Enable trusted boot by burning the corresponding fuse (WARNING: this must be 301 the last fuse line written!) 302 * Lock the unused fuse lines 303 304 The command to employ is the "fuse prog" command previously enabled by setting 305 the corresponding configuration option. 306 307 For the trusted boot, the fuse prog command has a special syntax, since the 308 ARMADA SoC demands that whole fuse lines (64 bit values) have to be written as 309 a whole. The fuse prog command itself allows lists of 32 bit words to be 310 written at a time, but this is translated to a series of single 32 bit write 311 operations to the fuse line, where the individual 32 bit words are identified 312 by a "word" counter that is increased for each write. 313 314 To work around this restriction, we interpret each line to have three "words" 315 (0-2): The first and second words are the values to be written to the fuse 316 line, and the third is a lock flag, which is supposed to lock the fuse line 317 when set to 1. Writes to the first and second words are memoized between 318 function calls, and the fuse line is only really written and locked (on writing 319 the third word) if both words were previously set, so that "incomplete" writes 320 are prevented. An exception to this is a single write to the third word (index 321 2) without previously writing neither the first nor the second word, which 322 locks the fuse line without setting any value; this is needed to lock the 323 unused fuse lines. 324 325 As an example, to write the value 0011223344556677 to fuse line 10, we would 326 use the following command: 327 328 fuse prog -y 10 0 00112233 44556677 1 329 330 Here 10 is the fuse line number, 0 is the index of the first word to be 331 written, 00112233 and 44556677 are the values to be written to the fuse line 332 (first and second word) and the trailing 1 is the value for the third word 333 responsible for locking the line. 334 335 A "lock-only" command would look like this: 336 337 fuse prog -y 11 2 1 338 339 Here 11 is the fuse number, 2 is the index of the first word to be written 340 (notice that we only write to word 2 here; the third word for fuse line 341 locking), and the 1 is the value for the word we are writing to. 342 343 WARNING: According to application note [4], the VHV pin of the SoC must be 344 connected to a 1.8V source during eFuse programming, but *must* be disconnected 345 for normal operation. The AN [4] describes a software-controlled circuit (based 346 on a N-channel or P-channel FET and a free GPIO pin of the SoC) to achieve 347 this, but a jumper-based circuit should suffice as well. Regardless of the 348 chosen circuit, the issue needs to be addressed accordingly! 349 350 7. Work to be done 351 ------------------ 352 353 * Add the ability to populate more than one CSK 354 * Test secure debug 355 * Test on Armada XP 356 357 8. Bibliography 358 --------------- 359 360 [1] ARMADA(R) 38x Family High-Performance Single/Dual CPU System on Chip 361 Functional Specification; MV-S109094-00, Rev. C; August 2, 2015, 362 Preliminary 363 [2] AN-383: ARMADA(R) 38x Families Secure Boot Mode Support; MV-S302501-00 364 Rev. A; March 11, 2015, Preliminary 365 [3] Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography 366 Specifications Version 2.1; February 2003; 367 https://www.ietf.org/rfc/rfc3447.txt 368 [4] AN-389: ARMADA(R) VHV Power; MV-S302545-00 Rev. B; January 28, 2016, 369 Released 370 [5] Marvell Armada 38x U-Boot support; November 25, 2015; 371 https://github.com/MarvellEmbeddedProcessors/u-boot-marvell 372 373 2017-01-05, Mario Six <mario.six (a] gdsys.cc> 374
README.at91
1 Atmel AT91 Evaluation kits 2 3 Index 4 - I. Board mapping & boot media 5 - II. NAND partition table 6 - III. watchdog support 7 8 I. Board mapping & boot media 9 ------------------------------------------------------------------------------ 10 AT91SAM9260EK, AT91SAM9G20EK & AT91SAM9XEEK 11 ------------------------------------------------------------------------------ 12 13 Memory map 14 0x20000000 - 23FFFFFF SDRAM (64 MB) 15 0xC0000000 - Cxxxxxxx Atmel Dataflash card (J13) 16 0xD0000000 - D07FFFFF Soldered Atmel Dataflash (AT45DB642) 17 18 Environment variables 19 20 U-Boot environment variables can be stored at different places: 21 - Dataflash on SPI chip select 1 (default) 22 - Dataflash on SPI chip select 0 (dataflash card) 23 - Nand flash. 24 25 You can choose your storage location at config step (here for at91sam9260ek) : 26 make at91sam9260ek_nandflash_config - use nand flash 27 make at91sam9260ek_dataflash_cs0_config - use data flash (spi cs0) 28 make at91sam9260ek_dataflash_cs1_config - use data flash (spi cs1) 29 30 31 ------------------------------------------------------------------------------ 32 AT91SAM9261EK, AT91SAM9G10EK 33 ------------------------------------------------------------------------------ 34 35 Memory map 36 0x20000000 - 23FFFFFF SDRAM (64 MB) 37 0xC0000000 - C07FFFFF Soldered Atmel Dataflash (AT45DB642) 38 0xD0000000 - Dxxxxxxx Atmel Dataflash card (J22) 39 40 Environment variables 41 42 U-Boot environment variables can be stored at different places: 43 - Dataflash on SPI chip select 0 (default) 44 - Dataflash on SPI chip select 3 (dataflash card) 45 - Nand flash. 46 47 You can choose your storage location at config step (here for at91sam9260ek) : 48 make at91sam9261ek_nandflash_config - use nand flash 49 make at91sam9261ek_dataflash_cs0_config - use data flash (spi cs0) 50 make at91sam9261ek_dataflash_cs3_config - use data flash (spi cs3) 51 52 53 ------------------------------------------------------------------------------ 54 AT91SAM9263EK 55 ------------------------------------------------------------------------------ 56 57 Memory map 58 0x20000000 - 23FFFFFF SDRAM (64 MB) 59 0xC0000000 - Cxxxxxxx Atmel Dataflash card (J9) 60 61 Environment variables 62 63 U-Boot environment variables can be stored at different places: 64 - Dataflash on SPI chip select 0 (dataflash card) 65 - Nand flash. 66 - Nor flash (not populate by default) 67 68 You can choose your storage location at config step (here for at91sam9260ek) : 69 make at91sam9263ek_nandflash_config - use nand flash 70 make at91sam9263ek_dataflash_cs0_config - use data flash (spi cs0) 71 make at91sam9263ek_norflash_config - use nor flash 72 73 You can choose to boot directly from U-Boot at config step 74 make at91sam9263ek_norflash_boot_config - boot from nor flash 75 76 77 ------------------------------------------------------------------------------ 78 AT91SAM9M10G45EK 79 ------------------------------------------------------------------------------ 80 81 Memory map 82 0x70000000 - 77FFFFFF SDRAM (128 MB) 83 84 Environment variables 85 86 U-Boot environment variables can be stored at different places: 87 - Nand flash. 88 89 You can choose your storage location at config step (here for at91sam9m10g45ek) : 90 make at91sam9m10g45ek_nandflash_config - use nand flash 91 92 93 ------------------------------------------------------------------------------ 94 AT91SAM9RLEK 95 ------------------------------------------------------------------------------ 96 97 Memory map 98 0x20000000 - 23FFFFFF SDRAM (64 MB) 99 0xC0000000 - C07FFFFF Soldered Atmel Dataflash (AT45DB642) 100 101 Environment variables 102 103 U-Boot environment variables can be stored at different places: 104 - Dataflash on SPI chip select 0 105 - Nand flash. 106 107 You can choose your storage location at config step (here for at91sam9rlek) : 108 make at91sam9rlek_nandflash_config - use nand flash 109 110 111 ------------------------------------------------------------------------------ 112 AT91SAM9N12EK, AT91SAM9X5EK 113 ------------------------------------------------------------------------------ 114 115 Memory map 116 0x20000000 - 27FFFFFF SDRAM (128 MB) 117 118 Environment variables 119 120 U-Boot environment variables can be stored at different places: 121 - Nand flash. 122 - SD/MMC card 123 - Serialflash/Dataflash on SPI chip select 0 124 125 You can choose your storage location at config step (here for at91sam9x5ek) : 126 make at91sam9x5ek_dataflash_config - use data flash 127 make at91sam9x5ek_mmc_config - use sd/mmc card 128 make at91sam9x5ek_nandflash_config - use nand flash 129 make at91sam9x5ek_spiflash_config - use serial flash 130 131 132 ------------------------------------------------------------------------------ 133 SAMA5D3XEK 134 ------------------------------------------------------------------------------ 135 136 Memory map 137 0x20000000 - 3FFFFFFF SDRAM (512 MB) 138 139 Environment variables 140 141 U-Boot environment variables can be stored at different places: 142 - Nand flash. 143 - SD/MMC card 144 - Serialflash on SPI chip select 0 145 146 You can choose your storage location at config step (here for sama5d3xek) : 147 make sama5d3xek_mmc_config - use SD/MMC card 148 make sama5d3xek_nandflash_config - use nand flash 149 make sama5d3xek_serialflash_config - use serial flash 150 151 152 II. NAND partition table 153 154 All the board support boot from NAND flash will use the following NAND 155 partition table 156 157 0x00000000 - 0x0003FFFF bootstrap (256 KiB) 158 0x00040000 - 0x000BFFFF u-boot (512 KiB) 159 0x000C0000 - 0x000FFFFF env (256 KiB) 160 0x00100000 - 0x0013FFFF env_redundant (256 KiB) 161 0x00140000 - 0x0017FFFF spare (256 KiB) 162 0x00180000 - 0x001FFFFF dtb (512 KiB) 163 0x00200000 - 0x007FFFFF kernel (6 MiB) 164 0x00800000 - 0xxxxxxxxx rootfs (All left) 165 166 III. Watchdog support 167 168 For security reasons, the at91 watchdog is running at boot time and, 169 if deactivated, cannot be used anymore. 170 If you want to use the watchdog, you will need to keep it running in 171 your code (make sure not to disable it in AT91Bootstrap for instance). 172 173 In the U-Boot configuration, the AT91 watchdog support is enabled using 174 the CONFIG_AT91SAM9_WATCHDOG and CONFIG_HW_WATCHDOG options. 175
README.atmel_mci
1 How to use SD/MMC cards with Atmel SoCs having MCI hardware 2 ----------------------------------------------------------- 3 2010-08-16 Reinhard Meyer <reinhard.meyer (a] emk-elektronik.de> 4 5 This is a new approach to use Atmel MCI hardware with the 6 general MMC framework. Therefore it benefits from that 7 framework's abilities to handle SDHC Cards and the ability 8 to write blocks. 9 10 - AT91SAM9XE512 (tested, will definitely work with XE128 and XE256) 11 - AT91SAM9260 (not tested, but MCI is to AT91SAM9XE) 12 - AT91SAM9G20 (not tested, should work) 13 14 It should work with all other ATMEL devices that have MCI. 15 16 The generic driver does NOT assign port pins to the MCI block 17 nor does it start the MCI clock. This has to be handled in a 18 board/SoC specific manner before the driver is initialized: 19 20 example: this is added to at91sam9260_devices.c: 21 22 #if defined(CONFIG_GENERIC_ATMEL_MCI) 23 void at91_mci_hw_init(void) 24 { 25 at91_set_a_periph(AT91_PIO_PORTA, 8, PUP); /* MCCK */ 26 #if defined(CONFIG_ATMEL_MCI_PORTB) 27 at91_set_b_periph(AT91_PIO_PORTA, 1, PUP); /* MCCDB */ 28 at91_set_b_periph(AT91_PIO_PORTA, 0, PUP); /* MCDB0 */ 29 at91_set_b_periph(AT91_PIO_PORTA, 5, PUP); /* MCDB1 */ 30 at91_set_b_periph(AT91_PIO_PORTA, 4, PUP); /* MCDB2 */ 31 at91_set_b_periph(AT91_PIO_PORTA, 3, PUP); /* MCDB3 */ 32 #else 33 at91_set_a_periph(AT91_PIO_PORTA, 7, PUP); /* MCCDA */ 34 at91_set_a_periph(AT91_PIO_PORTA, 6, PUP); /* MCDA0 */ 35 at91_set_a_periph(AT91_PIO_PORTA, 9, PUP); /* MCDA1 */ 36 at91_set_a_periph(AT91_PIO_PORTA, 10, PUP); /* MCDA2 */ 37 at91_set_a_periph(AT91_PIO_PORTA, 11, PUP); /* MCDA3 */ 38 #endif 39 } 40 #endif 41 42 the board specific file need added: 43 ... 44 #ifdef CONFIG_GENERIC_ATMEL_MCI 45 # include <mmc.h> 46 #endif 47 ... 48 #ifdef CONFIG_GENERIC_ATMEL_MCI 49 /* this is a weak define that we are overriding */ 50 int board_mmc_init(bd_t *bd) 51 { 52 /* Enable clock */ 53 at91_sys_write(AT91_PMC_PCER, 1 << AT91SAM9260_ID_MCI); 54 at91_mci_hw_init(); 55 56 /* This calls the atmel_mci_init in gen_atmel_mci.c */ 57 return atmel_mci_init((void *)AT91_BASE_MCI); 58 } 59 60 /* this is a weak define that we are overriding */ 61 int board_mmc_getcd(struct mmc *mmc) 62 { 63 return !at91_get_gpio_value(CONFIG_SYS_MMC_CD_PIN); 64 } 65 66 #endif 67 68 and the board definition files needs: 69 70 /* SD/MMC card */ 71 #define CONFIG_GENERIC_ATMEL_MCI 1 72 #define CONFIG_ATMEL_MCI_PORTB 1 /* Atmel XE-EK uses port B */ 73 #define CONFIG_SYS_MMC_CD_PIN AT91_PIN_PC9 74 #define CONFIG_CMD_MMC 1 75
README.atmel_pmecc
1 How to enable PMECC(Programmable Multibit ECC) for nand on Atmel SoCs 2 ----------------------------------------------------------- 3 2012-08-22 Josh Wu <josh.wu (a] atmel.com> 4 5 The Programmable Multibit ECC (PMECC) controller is a programmable binary 6 BCH(Bose, Chaudhuri and Hocquenghem) encoder and decoder. This controller 7 can be used to support both SLC and MLC NAND Flash devices. It supports to 8 generate ECC to correct 2, 4, 8, 12 or 24 bits of error per sector (512 or 9 1024 bytes) of data. 10 11 Following Atmel AT91 products support PMECC. 12 - AT91SAM9X25, X35, G25, G15, G35 (tested) 13 - AT91SAM9N12 (not tested, Should work) 14 15 As soon as your nand flash software ECC works, you can enable PMECC. 16 17 To use PMECC in this driver, the user needs to set: 18 1. the PMECC correction error bits capability: CONFIG_PMECC_CAP. 19 It can be 2, 4, 8, 12 or 24. 20 2. The PMECC sector size: CONFIG_PMECC_SECTOR_SIZE. 21 It only can be 512 or 1024. 22 23 Take AT91SAM9X5EK as an example, the board definition file likes: 24 25 /* PMECC & PMERRLOC */ 26 #define CONFIG_ATMEL_NAND_HWECC 1 27 #define CONFIG_ATMEL_NAND_HW_PMECC 1 28 #define CONFIG_PMECC_CAP 2 29 #define CONFIG_PMECC_SECTOR_SIZE 512 30 31 How to enable PMECC header for direct programmable boot.bin 32 ----------------------------------------------------------- 33 2014-05-19 Andreas Biemann <andreas (a] biessmann.org> 34 35 The usual way to program SPL into NAND flash is to use the SAM-BA Atmel tool. 36 This however is often not usable when doing field updates. To be able to 37 program a SPL binary into NAND flash we need to add the PMECC header to the 38 binary before. Chapter '12.4.4.1 NAND Flash Boot: NAND Flash Detection' in 39 sama5d3 SoC spec (as of 03. April 2014) defines how this PMECC header has to 40 look like. In order to do so we have a new image type added to mkimage to 41 generate this PMECC header and integrated this into the build process of SPL. 42 43 To enable the generation of atmel PMECC header for SPL one need to define 44 CONFIG_SPL_GENERATE_ATMEL_PMECC_HEADER. The required parameters are taken from 45 board configuration and compiled into the host tools atmel_pmecc_params. This 46 tool will be called in build process to parametrize mkimage for atmelimage 47 type. The mkimage tool has intentionally _not_ compiled in those parameters. 48 49 The mkimage image type atmelimage also set the 6'th interrupt vector to the 50 correct value. This feature can also be used to setup a boot.bin for MMC boot. 51
README.autoboot
1 SPDX-License-Identifier: GPL-2.0+ 2 /* 3 * (C) Copyright 2001 4 * Dave Ellis, SIXNET, dge (a] sixnetio.com 5 * 6 */ 7 8 Using autoboot configuration options 9 ==================================== 10 11 The basic autoboot configuration options are documented in the main 12 U-Boot README. See it for details. They are: 13 14 bootdelay 15 bootcmd 16 CONFIG_BOOTDELAY 17 CONFIG_BOOTCOMMAND 18 19 Some additional options that make autoboot safer in a production 20 product are documented here. 21 22 Why use them? 23 ------------- 24 25 The basic autoboot feature allows a system to automatically boot to 26 the real application (such as Linux) without a user having to enter 27 any commands. If any key is pressed before the boot delay time 28 expires, U-Boot stops the autoboot process, gives a U-Boot prompt 29 and waits forever for a command. That's a good thing if you pressed a 30 key because you wanted to get the prompt. 31 32 It's not so good if the key press was a stray character on the 33 console serial port, say because a user who knows nothing about 34 U-Boot pressed a key before the system had time to boot. It's even 35 worse on an embedded product that doesn't have a console during 36 normal use. The modem plugged into that console port sends a 37 character at the wrong time and the system hangs, with no clue as to 38 why it isn't working. 39 40 You might want the system to autoboot to recover after an external 41 configuration program stops autoboot. If the configuration program 42 dies or loses its connection (modems can disconnect at the worst 43 time) U-Boot will patiently wait forever for it to finish. 44 45 These additional configuration options can help provide a system that 46 boots when it should, but still allows access to U-Boot. 47 48 What they do 49 ------------ 50 51 CONFIG_BOOT_RETRY_TIME 52 CONFIG_BOOT_RETRY_MIN 53 54 "bootretry" environment variable 55 56 These options determine what happens after autoboot is 57 stopped and U-Boot is waiting for commands. 58 59 CONFIG_BOOT_RETRY_TIME must be defined to enable the boot 60 retry feature. If the environment variable "bootretry" is 61 found then its value is used, otherwise the retry timeout is 62 CONFIG_BOOT_RETRY_TIME. CONFIG_BOOT_RETRY_MIN is optional and 63 defaults to CONFIG_BOOT_RETRY_TIME. All times are in seconds. 64 65 If the retry timeout is negative, the U-Boot command prompt 66 never times out. Otherwise it is forced to be at least 67 CONFIG_BOOT_RETRY_MIN seconds. If no valid U-Boot command is 68 entered before the specified time the boot delay sequence is 69 restarted. Each command that U-Boot executes restarts the 70 timeout. 71 72 If CONFIG_BOOT_RETRY_TIME < 0 the feature is there, but 73 doesn't do anything unless the environment variable 74 "bootretry" is >= 0. 75 76 CONFIG_AUTOBOOT_KEYED 77 CONFIG_AUTOBOOT_KEYED_CTRLC 78 CONFIG_AUTOBOOT_PROMPT 79 CONFIG_AUTOBOOT_DELAY_STR 80 CONFIG_AUTOBOOT_STOP_STR 81 82 "bootdelaykey" environment variable 83 "bootstopkey" environment variable 84 85 These options give more control over stopping autoboot. When 86 they are used a specific character or string is required to 87 stop or delay autoboot. 88 89 Define CONFIG_AUTOBOOT_KEYED (no value required) to enable 90 this group of options. CONFIG_AUTOBOOT_DELAY_STR, 91 CONFIG_AUTOBOOT_STOP_STR or both should be specified (or 92 specified by the corresponding environment variable), 93 otherwise there is no way to stop autoboot. 94 95 CONFIG_AUTOBOOT_PROMPT is displayed before the boot delay 96 selected by CONFIG_BOOTDELAY starts. If it is not defined 97 there is no output indicating that autoboot is in progress. 98 99 Note that CONFIG_AUTOBOOT_PROMPT is used as the (only) 100 argument to a printf() call, so it may contain '%' format 101 specifications, provided that it also includes, sepearated by 102 commas exactly like in a printf statement, the required 103 arguments. It is the responsibility of the user to select only 104 such arguments that are valid in the given context. A 105 reasonable prompt could be defined as 106 107 #define CONFIG_AUTOBOOT_PROMPT \ 108 "autoboot in %d seconds\n",bootdelay 109 110 If CONFIG_AUTOBOOT_DELAY_STR or "bootdelaykey" is specified 111 and this string is received from console input before 112 autoboot starts booting, U-Boot gives a command prompt. The 113 U-Boot prompt will time out if CONFIG_BOOT_RETRY_TIME is 114 used, otherwise it never times out. 115 116 If CONFIG_AUTOBOOT_STOP_STR or "bootstopkey" is specified and 117 this string is received from console input before autoboot 118 starts booting, U-Boot gives a command prompt. The U-Boot 119 prompt never times out, even if CONFIG_BOOT_RETRY_TIME is 120 used. 121 122 The string recognition is not very sophisticated. If a 123 partial match is detected, the first non-matching character 124 is checked to see if starts a new match. There is no check 125 for a shorter partial match, so it's best if the first 126 character of a key string does not appear in the rest of the 127 string. 128 129 The CONFIG_AUTOBOOT_KEYED_CTRLC #define allows for the boot 130 sequence to be interrupted by ctrl-c, in addition to the 131 "bootdelaykey" and "bootstopkey". Setting this variable 132 provides an escape sequence from the limited "password" 133 strings. 134 135 CONFIG_RESET_TO_RETRY 136 137 (Only effective when CONFIG_BOOT_RETRY_TIME is also set) 138 After the countdown timed out, the board will be reset to restart 139 again. 140
README.avb2
1 Android Verified Boot 2.0 2 3 This file contains information about the current support of Android Verified 4 Boot 2.0 in U-boot 5 6 1. OVERVIEW 7 --------------------------------- 8 Verified Boot establishes a chain of trust from the bootloader to system images 9 * Provides integrity checking for: 10 - Android Boot image: Linux kernel + ramdisk. RAW hashing of the whole 11 partition is done and the hash is compared with the one stored in 12 the VBMeta image 13 - system/vendor partitions: verifying root hash of dm-verity hashtrees. 14 * Provides capabilities for rollback protection. 15 16 Integrity of the bootloader (U-boot BLOB and environment) is out of scope. 17 18 For additional details check: 19 https://android.googlesource.com/platform/external/avb/+/master/README.md 20 21 22 2. AVB 2.0 U-BOOT SHELL COMMANDS 23 ----------------------------------- 24 Provides CLI interface to invoke AVB 2.0 verification + misc. commands for 25 different testing purposes: 26 27 avb init <dev> - initialize avb 2.0 for <dev> 28 avb verify - run verification process using hash data from vbmeta structure 29 avb read_rb <num> - read rollback index at location <num> 30 avb write_rb <num> <rb> - write rollback index <rb> to <num> 31 avb is_unlocked - returns unlock status of the device 32 avb get_uuid <partname> - read and print uuid of partition <partname> 33 avb read_part <partname> <offset> <num> <addr> - read <num> bytes from 34 partition <partname> to buffer <addr> 35 avb write_part <partname> <offset> <num> <addr> - write <num> bytes to 36 <partname> by <offset> using data from <addr> 37 38 39 3. PARTITIONS TAMPERING (EXAMPLE) 40 ----------------------------------- 41 Boot or system/vendor (dm-verity metadata section) is tampered: 42 => avb init 1 43 => avb verify 44 avb_slot_verify.c:175: ERROR: boot: Hash of data does not match digest in 45 descriptor. 46 Slot verification result: ERROR_IO 47 48 Vbmeta partition is tampered: 49 => avb init 1 50 => avb verify 51 avb_vbmeta_image.c:206: ERROR: Hash does not match! 52 avb_slot_verify.c:388: ERROR: vbmeta: Error verifying vbmeta image: 53 HASH_MISMATCH 54 Slot verification result: ERROR_IO 55 56 57 4. ENABLE ON YOUR BOARD 58 ----------------------------------- 59 The following options must be enabled: 60 CONFIG_LIBAVB=y 61 CONFIG_CMD_AVB=y 62 63 64 Then add `avb verify` invocation to your android boot sequence of commands, 65 e.g.: 66 67 => avb_verify=avb init $mmcdev; avb verify; 68 => if run avb_verify; then \ 69 echo AVB verification OK. Continue boot; \ 70 set bootargs $bootargs $avb_bootargs; \ 71 else \ 72 echo AVB verification failed; \ 73 exit; \ 74 fi; \ 75 76 => emmc_android_boot= \ 77 echo Trying to boot Android from eMMC ...; \ 78 ... \ 79 run avb_verify; \ 80 mmc read ${fdtaddr} ${fdt_start} ${fdt_size}; \ 81 mmc read ${loadaddr} ${boot_start} ${boot_size}; \ 82 bootm $loadaddr $loadaddr $fdtaddr; \ 83 84 85 To switch on automatic generation of vbmeta partition in AOSP build, add these 86 lines to device configuration mk file: 87 88 BOARD_AVB_ENABLE := true 89 BOARD_AVB_ALGORITHM := SHA512_RSA4096 90 BOARD_BOOTIMAGE_PARTITION_SIZE := <boot partition size> 91 92 After flashing U-boot don't forget to update environment and write new 93 partition table: 94 => env default -f -a 95 => setenv partitions $partitions_android 96 => env save 97 => gpt write mmc 1 $partitions_android 98
README.AX25
1 AX25 is Andes CPU IP to adopt RISC-V architecture. 2 3 Features 4 ======== 5 6 CPU Core 7 - 5-stage in-order execution pipeline 8 - Hardware Multiplier 9 - radix-2/radix-4/radix-16/radix-256/fast 10 - Hardware Divider 11 - Optional branch prediction 12 - Machine mode and optional user mode 13 - Optional performance monitoring 14 15 ISA 16 - RV64I base integer instructions 17 - RVC for 16-bit compressed instructions 18 - RVM for multiplication and division instructions 19 20 Memory subsystem 21 - I & D local memory 22 - Size: 4KB to 16MB 23 - Memory subsyetem soft-error protection 24 - Protection scheme: parity-checking or error-checking-and-correction (ECC) 25 - Automatic hardware error correction 26 27 Bus 28 - Interface Protocol 29 - Synchronous AHB (32-bit/64-bit data-width), or 30 - Synchronous AXI4 (64-bit data-width) 31 32 Power management 33 - Wait for interrupt (WFI) mode 34 35 Debug 36 - Configurable number of breakpoints: 2/4/8 37 - External Debug Module 38 - AHB slave port 39 - External JTAG debug transport module 40 41 Platform Level Interrupt Controller (PLIC) 42 - AHB slave port 43 - Configurable number of interrupts: 1-1023 44 - Configurable number of interrupt priorities: 3/7/15/63/127/255 45 - Configurable number of targets: 1-16 46 - Preempted interrupt priority stack 47
README.b4860qds
1 Overview 2 -------- 3 The B4860QDS is a Freescale reference board that hosts the B4860 SoC (and variants). 4 5 B4860 Overview 6 ------------- 7 The B4860 QorIQ Qonverge device is a Freescale high-end, multicore SoC based on 8 StarCore and Power Architecture cores. It targets the broadband wireless 9 infrastructure and builds upon the proven success of the existing multicore 10 DSPs and Power CPUs. It is designed to bolster the rapidly changing and 11 expanding wireless markets, such as 3GLTE (FDD and TDD), LTE-Advanced, and UMTS. 12 13 The B4860 is a highly-integrated StarCore and Power Architecture processor that 14 contains: 15 . Six fully-programmable StarCore SC3900 FVP subsystems, divided into three 16 clusters-each core runs up to 1.2 GHz, with an architecture highly optimized for 17 wireless base station applications 18 . Four dual-thread e6500 Power Architecture processors organized in one cluster-each 19 core runs up to 1.8 GHz 20 . Two DDR3/3L controllers for high-speed, industry-standard memory interface each 21 runs at up to 1866.67 MHz 22 . MAPLE-B3 hardware acceleration-for forward error correction schemes including 23 Turbo or Viterbi decoding, Turbo encoding and rate matching, MIMO MMSE 24 equalization scheme, matrix operations, CRC insertion and check, DFT/iDFT and 25 FFT/iFFT calculations, PUSCH/PDSCH acceleration, and UMTS chip rate 26 acceleration 27 . CoreNet fabric that fully supports coherency using MESI protocol between the 28 e6500 cores, SC3900 FVP cores, memories and external interfaces. 29 CoreNet fabric interconnect runs at 667 MHz and supports coherent and 30 non-coherent out of order transactions with prioritization and bandwidth 31 allocation amongst CoreNet endpoints. 32 . Data Path Acceleration Architecture, which includes the following: 33 . Frame Manager (FMan), which supports in-line packet parsing and general 34 classification to enable policing and QoS-based packet distribution 35 . Queue Manager (QMan) and Buffer Manager (BMan), which allow offloading 36 of queue management, task management, load distribution, flow ordering, buffer 37 management, and allocation tasks from the cores 38 . Security engine (SEC 5.3)-crypto-acceleration for protocols such as IPsec, 39 SSL, and 802.16 40 . RapidIO manager (RMAN) - Support SRIO types 8, 9, 10, and 11 (inbound and 41 outbound). Supports types 5, 6 (outbound only) 42 . Large internal cache memory with snooping and stashing capabilities for 43 bandwidth saving and high utilization of processor elements. The 9856-Kbyte 44 internal memory space includes the following: 45 . 32 Kbyte L1 ICache per e6500/SC3900 core 46 . 32 Kbyte L1 DCache per e6500/SC3900 core 47 . 2048 Kbyte unified L2 cache for each SC3900 FVP cluster 48 . 2048 Kbyte unified L2 cache for the e6500 cluster 49 . Two 512 Kbyte shared L3 CoreNet platform caches (CPC) 50 . Sixteen 10-GHz SerDes lanes serving: 51 . Two Serial RapidIO interfaces. 52 - Each supports up to 4 lanes and a total of up to 8 lanes 53 . Up to 8-lanes Common Public Radio Interface (CPRI) controller for glue-less 54 antenna connection 55 . Two 10-Gbit Ethernet controllers (10GEC) 56 . Six 1G/2.5-Gbit Ethernet controllers for network communications 57 . PCI Express controller 58 . Debug (Aurora) 59 . Two OCeaN DMAs 60 . Various system peripherals 61 . 182 32-bit timers 62 63 B4860QDS Overview 64 ------------------ 65 - DDRC1: Ten separate DDR3 parts of 16-bit to support 72-bit (ECC) at 1866MT/s, ECC, 4 GB 66 of memory in two ranks of 2 GB. 67 - DDRC2: Five separate DDR3 parts of 16-bit to support 72-bit (ECC) at 1866MT/s, ECC, 2 GB 68 of memory. Single rank. 69 - SerDes 1 multiplexing: Two Vitesse (transmit and receive path) cross-point 16x16 switch 70 VSC3316 71 - SerDes 2 multiplexing: Two Vitesse (transmit and receive path) cross-point 8x8 switch VSC3308 72 - USB 2.0 ULPI PHY USB3315 by SMSC supports USB port in host mode. 73 B4860 UART port is available over USB-to-UART translator USB2SER or over RS232 flat cable. 74 - A Vitesse dual SGMII phy VSC8662 links the B4860 SGMII lines to 2xRJ-45 copper connectors 75 for Stand-alone mode and to the 1000Base-X over AMC MicroTCA connector ports 0 and 2 for 76 AMC mode. 77 - The B4860 configuration may be loaded from nine bits coded reset configuration reset source. The 78 RCW source is set by appropriate DIP-switches: 79 - 16-bit NOR Flash / PROMJet 80 - QIXIS 8-bit NOR Flash Emulator 81 - 8-bit NAND Flash 82 - 24-bit SPI Flash 83 - Long address I2C EEPROM 84 - Available debug interfaces are: 85 - On-board eCWTAP controller with ETH and USB I/F 86 - JTAG/COP 16-pin header for any external TAP controller 87 - External JTAG source over AMC to support B2B configuration 88 - 70-pin Aurora debug connector 89 - QIXIS (FPGA) logic: 90 - 2 KB internal memory space including 91 - IDT840NT4 clock synthesizer provides B4860 essential clocks : SYSCLK, DDRCLK1,2 and 92 RTCCLK. 93 - Two 8T49N222A SerDes ref clock devices support two SerDes port clock frequency - total four 94 refclk, including CPRI clock scheme. 95 96 B4420 Personality 97 -------------------- 98 99 B4420 Personality 100 -------------------- 101 B4420 is a reduced personality of B4860 with less core/clusters(both SC3900 and e6500), less DDR 102 controllers, less serdes lanes, less SGMII interfaces and reduced target frequencies. 103 104 Key differences between B4860 and B4420 105 ---------------------------------------- 106 107 B4420 has: 108 1. Less e6500 cores: 1 cluster with 2 e6500 cores 109 2. Less SC3900 cores/clusters: 1 cluster with 2 SC3900 cores per cluster. 110 3. Single DDRC 111 4. 2X 4 lane serdes 112 5. 3 SGMII interfaces 113 6. no sRIO 114 7. no 10G 115 116 B4860QDS Default Settings 117 ------------------------- 118 119 Switch Settings 120 ---------------- 121 122 SW1 OFF [0] OFF [0] OFF [0] OFF [0] OFF [0] OFF [0] OFF [0] OFF [0] 123 SW2 ON ON ON ON ON ON OFF OFF 124 SW3 OFF OFF OFF ON OFF OFF ON OFF 125 SW5 OFF OFF OFF OFF OFF OFF ON ON 126 127 Note: PCIe slots modes: All the PCIe devices work as Root Complex. 128 Note: Boot location: NOR flash. 129 130 SysClk/Core(e6500)/CCB/DDR/FMan/DDRCLK/StarCore/CPRI-Maple/eTVPE-Maple/ULB-Maple 131 66MHz/1.6GHz/667MHz/1.6GHz data rate/667MHz/133MHz/1200MHz/500MHz/800MHz/667MHz 132 133 a) NAND boot 134 SW1 [1.1] = 0 135 SW2 [1.1] = 1 136 SW3 [1:4] = 0001 137 b) NOR boot 138 SW1 [1.1] = 1 139 SW2 [1.1] = 0 140 SW3 [1:4] = 1000. 141 142 B4420QDS Default Settings 143 ------------------------- 144 145 Switch Settings 146 ---------------- 147 SW1 OFF[0] OFF [0] OFF [0] OFF [0] OFF [0] OFF [0] OFF [0] OFF [0] 148 SW2 ON OFF ON OFF ON ON OFF OFF 149 SW3 OFF OFF OFF ON OFF OFF ON OFF 150 SW5 OFF OFF OFF OFF OFF OFF ON ON 151 152 Note: PCIe slots modes: All the PCIe devices work as Root Complex. 153 Note: Boot location: NOR flash. 154 155 SysClk/Core(e6500)/CCB/DDR/FMan/DDRCLK/StarCore/CPRI-Maple/eTVPE-Maple/ULB-Maple 156 66MHz/1.6GHz/667MHz/1.6GHz data rate/667MHz/133MHz/1200MHz/500MHz/800MHz/667MHz 157 158 a) NAND boot 159 SW1 [1.1] = 0 160 SW2 [1.1] = 1 161 SW3 [1:4] = 0001 162 b) NOR boot 163 SW1 [1.1] = 1 164 SW2 [1.1] = 0 165 SW3 [1:4] = 1000. 166 167 Memory map on B4860QDS 168 ---------------------- 169 The addresses in brackets are physical addresses. 170 171 Start Address End Address Description Size 172 0xF_FFDF_1000 0xF_FFFF_FFFF Free 2 MB 173 0xF_FFDF_0000 0xF_FFDF_0FFF IFC - FPGA 4 KB 174 0xF_FF81_0000 0xF_FFDE_FFFF Free 5 MB 175 0xF_FF80_0000 0xF_FF80_FFFF IFC NAND Flash 64 KB 176 0xF_FF00_0000 0xF_FF7F_FFFF Free 8 MB 177 0xF_FE00_0000 0xF_FEFF_FFFF CCSRBAR 16 MB 178 0xF_F801_0000 0xF_FDFF_FFFF Free 95 MB 179 0xF_F800_0000 0xF_F800_FFFF PCIe I/O Space 64 KB 180 0xF_F600_0000 0xF_F7FF_FFFF QMAN s/w portal 32 MB 181 0xF_F400_0000 0xF_F5FF_FFFF BMAN s/w portal 32 MB 182 0xF_F000_0000 0xF_F3FF_FFFF Free 64 MB 183 0xF_E800_0000 0xF_EFFF_FFFF IFC NOR Flash 128 MB 184 0xF_E000_0000 0xF_E7FF_FFFF Promjet 128 MB 185 0xF_A0C0_0000 0xF_DFFF_FFFF Free 1012 MB 186 0xF_A000_0000 0xF_A0BF_FFFF MAPLE0/1/2 12 MB 187 0xF_0040_0000 0xF_9FFF_FFFF Free 12 GB 188 0xF_0000_0000 0xF_01FF_FFFF DCSR 32 MB 189 0xC_4000_0000 0xE_FFFF_FFFF Free 11 GB 190 0xC_3000_0000 0xC_3FFF_FFFF sRIO-2 I/O 256 MB 191 0xC_2000_0000 0xC_2FFF_FFFF sRIO-1 I/O 256 MB 192 0xC_0000_0000 0xC_1FFF_FFFF PCIe Mem Space 512 MB 193 0x1_0000_0000 0xB_FFFF_FFFF Free 44 GB 194 0x0_8000_0000 0x0_FFFF_FFFF DDRC1 2 GB 195 0x0_0000_0000 0x0_7FFF_FFFF DDRC2 2 GB 196 197 Memory map on B4420QDS 198 ---------------------- 199 The addresses in brackets are physical addresses. 200 201 Start Address End Address Description Size 202 0xF_FFDF_1000 0xF_FFFF_FFFF Free 2 MB 203 0xF_FFDF_0000 0xF_FFDF_0FFF IFC - FPGA 4 KB 204 0xF_FF81_0000 0xF_FFDE_FFFF Free 5 MB 205 0xF_FF80_0000 0xF_FF80_FFFF IFC NAND Flash 64 KB 206 0xF_FF00_0000 0xF_FF7F_FFFF Free 8 MB 207 0xF_FE00_0000 0xF_FEFF_FFFF CCSRBAR 16 MB 208 0xF_F801_0000 0xF_FDFF_FFFF Free 95 MB 209 0xF_F800_0000 0xF_F800_FFFF PCIe I/O Space 64 KB 210 0xF_F600_0000 0xF_F7FF_FFFF QMAN s/w portal 32 MB 211 0xF_F400_0000 0xF_F5FF_FFFF BMAN s/w portal 32 MB 212 0xF_F000_0000 0xF_F3FF_FFFF Free 64 MB 213 0xF_E800_0000 0xF_EFFF_FFFF IFC NOR Flash 128 MB 214 0xF_E000_0000 0xF_E7FF_FFFF Promjet 128 MB 215 0xF_A0C0_0000 0xF_DFFF_FFFF Free 1012 MB 216 0xF_A000_0000 0xF_A0BF_FFFF MAPLE0/1/2 12 MB 217 0xF_0040_0000 0xF_9FFF_FFFF Free 12 GB 218 0xF_0000_0000 0xF_01FF_FFFF DCSR 32 MB 219 0xC_4000_0000 0xE_FFFF_FFFF Free 11 GB 220 0xC_3000_0000 0xC_3FFF_FFFF sRIO-2 I/O 256 MB 221 0xC_2000_0000 0xC_2FFF_FFFF sRIO-1 I/O 256 MB 222 0xC_0000_0000 0xC_1FFF_FFFF PCIe Mem Space 512 MB 223 0x1_0000_0000 0xB_FFFF_FFFF Free 44 GB 224 0x0_0000_0000 0x0_FFFF_FFFF DDRC1 4 GB 225 226 227 NOR Flash memory Map on B4860 and B4420QDS 228 ------------------------------------------ 229 Start End Definition Size 230 0xEFF40000 0xEFFFFFFF U-Boot (current bank) 768KB 231 0xEFF20000 0xEFF3FFFF U-Boot env (current bank) 128KB 232 0xEFF00000 0xEFF1FFFF FMAN Ucode (current bank) 128KB 233 0xEF300000 0xEFEFFFFF rootfs (alternate bank) 12MB 234 0xEE800000 0xEE8FFFFF device tree (alternate bank) 1MB 235 0xEE020000 0xEE6FFFFF Linux.uImage (alternate bank) 6MB+896KB 236 0xEE000000 0xEE01FFFF RCW (alternate bank) 128KB 237 0xEDF40000 0xEDFFFFFF U-Boot (alternate bank) 768KB 238 0xEDF20000 0xEDF3FFFF U-Boot env (alternate bank) 128KB 239 0xEDF00000 0xEDF1FFFF FMAN ucode (alternate bank) 128KB 240 0xED300000 0xEDEFFFFF rootfs (current bank) 12MB 241 0xEC800000 0xEC8FFFFF device tree (current bank) 1MB 242 0xEC020000 0xEC6FFFFF Linux.uImage (current bank) 6MB+896KB 243 0xEC000000 0xEC01FFFF RCW (current bank) 128KB 244 245 Various Software configurations/environment variables/commands 246 -------------------------------------------------------------- 247 The below commands apply to both B4860QDS and B4420QDS. 248 249 1. U-Boot environment variable hwconfig 250 The default hwconfig is: 251 hwconfig=fsl_ddr:ctlr_intlv=null,bank_intlv=cs0_cs1;usb1: 252 dr_mode=host,phy_type=ulpi 253 Note: For USB gadget set "dr_mode=peripheral" 254 255 2. FMAN Ucode versions 256 fsl_fman_ucode_B4860_106_3_6.bin 257 258 3. Switching to alternate bank 259 Commands for switching to alternate bank. 260 261 1. To change from vbank0 to vbank2 262 => qixis_reset altbank (it will boot using vbank2) 263 264 2.To change from vbank2 to vbank0 265 => qixis reset (it will boot using vbank0) 266 267 4. To change personality of board 268 For changing personality from B4860 to B4420 269 1)Boot from vbank0 270 2)Flash vbank2 with b4420 rcw and U-Boot 271 3)Give following commands to uboot prompt 272 => mw.b ffdf0040 0x30; 273 => mw.b ffdf0010 0x00; 274 => mw.b ffdf0062 0x02; 275 => mw.b ffdf0050 0x02; 276 => mw.b ffdf0010 0x30; 277 => reset 278 279 Note: Power off cycle will lead to default switch settings. 280 Note: 0xffdf0000 is the address of the QIXIS FPGA. 281 282 5. Switching between NOR and NAND boot(RCW src changed from NOR <-> NAND) 283 284 To change from NOR to NAND boot give following command on uboot prompt 285 => mw.b ffdf0040 0x30 286 => mw.b ffdf0010 0x00 287 => mw.b 0xffdf0050 0x08 288 => mw.b 0xffdf0060 0x82 289 => mw.b ffdf0061 0x00 290 => mw.b ffdf0010 0x30 291 => reset 292 293 To change from NAND to NOR boot give following command on uboot prompt: 294 => mw.b ffdf0040 0x30 295 => mw.b ffdf0010 0x00 296 => mw.b 0xffdf0050 0x00(for vbank0) or (mw.b 0xffdf0050 0x02 for vbank2) 297 => mw.b 0xffdf0060 0x12 298 => mw.b ffdf0061 0x01 299 => mw.b ffdf0010 0x30 300 => reset 301 302 Note: Power off cycle will lead to default switch settings. 303 Note: 0xffdf0000 is the address of the QIXIS FPGA. 304 305 6. Ethernet interfaces for B4860QDS 306 Serdes protocosl tested: 307 0x2a, 0x8d (serdes1, serdes2) [DEFAULT] 308 0x2a, 0xb2 (serdes1, serdes2) 309 310 When using [DEFAULT] RCW, which including 2 * 1G SGMII on board and 2 * 1G 311 SGMII on SGMII riser card. 312 Under U-Boot these network interfaces are recognized as: 313 FM1@DTSEC3, FM1@DTSEC4, FM1@DTSEC5 and FM1@DTSEC6. 314 315 On Linux the interfaces are renamed as: 316 . eth2 -> fm1-gb2 317 . eth3 -> fm1-gb3 318 . eth4 -> fm1-gb4 319 . eth5 -> fm1-gb5 320 321 7. RCW and Ethernet interfaces for B4420QDS 322 Serdes protocosl tested: 323 0x18, 0x9e (serdes1, serdes2) 324 325 Under U-Boot these network interfaces are recognized as: 326 FM1@DTSEC3, FM1@DTSEC4 and e1000#0. 327 328 On Linux the interfaces are renamed as: 329 . eth2 -> fm1-gb2 330 . eth3 -> fm1-gb3 331 332 NAND boot with 2 Stage boot loader 333 ---------------------------------- 334 PBL initialise the internal SRAM and copy SPL(160KB) in SRAM. 335 SPL further initialise DDR using SPD and environment variables and copy 336 U-Boot(768 KB) from flash to DDR. 337 Finally SPL transer control to U-Boot for futher booting. 338 339 SPL has following features: 340 - Executes within 256K 341 - No relocation required 342 343 Run time view of SPL framework during boot :- 344 ----------------------------------------------- 345 Area | Address | 346 ----------------------------------------------- 347 Secure boot | 0xFFFC0000 (32KB) | 348 headers | | 349 ----------------------------------------------- 350 GD, BD | 0xFFFC8000 (4KB) | 351 ----------------------------------------------- 352 ENV | 0xFFFC9000 (8KB) | 353 ----------------------------------------------- 354 HEAP | 0xFFFCB000 (30KB) | 355 ----------------------------------------------- 356 STACK | 0xFFFD8000 (22KB) | 357 ----------------------------------------------- 358 U-Boot SPL | 0xFFFD8000 (160KB) | 359 ----------------------------------------------- 360 361 NAND Flash memory Map on B4860 and B4420QDS 362 ------------------------------------------ 363 Start End Definition Size 364 0x000000 0x0FFFFF U-Boot 1MB 365 0x140000 0x15FFFF U-Boot env 128KB 366 0x1A0000 0x1BFFFF FMAN Ucode 128KB 367
README.bedbug
1 BEDBUG Support for U-Boot 2 -------------------------- 3 4 These changes implement the bedbug (emBEDded deBUGger) debugger in U-Boot. 5 A specific implementation is made for the AMCC 405 processor but other flavors 6 can be easily implemented. 7 8 ##################### 9 ### Modifications ### 10 ##################### 11 12 ./common/Makefile 13 Included cmd_bedbug.c and bedbug.c in the Makefile. 14 15 ./common/command.c 16 Added bedbug commands to command table. 17 18 ./common/board.c 19 Added call to initialize debugger on startup. 20 21 ./arch/powerpc/cpu/ppc4xx/Makefile 22 Added bedbug_405.c to the Makefile. 23 24 ./arch/powerpc/cpu/ppc4xx/start.S 25 Added code to handle the debug exception (0x2000) on the 405. 26 Also added code to handle critical exceptions since the debug 27 is treated as critical on the 405. 28 29 ./arch/powerpc/cpu/ppc4xx/traps.c 30 Added more detailed output for the program exception to tell 31 if it is an illegal instruction, privileged instruction or 32 a trap. Also added debug trap handler. 33 34 ./include/ppc_asm.tmpl 35 Added code to handle critical exceptions 36 37 ################# 38 ### New Stuff ### 39 ################# 40 41 ./include/bedbug/ppc.h 42 ./include/bedbug/regs.h 43 ./include/bedbug/bedbug.h 44 ./include/bedbug/elf.h [obsoleted by new include/elf.h] 45 ./include/bedbug/tables.h 46 ./include/cmd_bedbug.h 47 ./common/cmd_bedbug.c 48 ./common/bedbug.c 49 Bedbug library includes code for assembling and disassembling 50 PowerPC instructions to/from memory as well as handling 51 hardware breakpoints and stepping through code. These 52 routines are common to all PowerPC processors. 53 54 ./arch/powerpc/cpu/ppc4xx/bedbug_405.c 55 AMCC PPC405 specific debugger routines. 56 57 58 Bedbug support for the MPC860 59 ----------------------------- 60 61 Changes: 62 63 common/cmd_bedbug.c 64 Added call to initialize 860 debugger. 65 66 arch/powerpc/cpu/mpc8xx/Makefile 67 Added new file "bedbug_860.c" to the makefile 68 69 arch/powerpc/cpu/mpc8xx/start.S 70 Added handler for InstructionBreakpoint (0xfd00) 71 72 arch/powerpc/cpu/mpc8xx/traps.c 73 Added new routine DebugException() 74 75 New Files: 76 77 arch/powerpc/cpu/mpc8xx/bedbug_860.c 78 CPU-specific routines for 860 debug registers. 79
README.bitbangMII
1 This patch rewrites the miiphybb ( Bit-banged MII bus driver ) in order to 2 support an arbitrary number of mii buses. This feature is useful when your 3 board uses different mii buses for different phys and all (or a part) of these 4 buses are implemented via bit-banging mode. 5 6 The driver requires that the following macros should be defined into the board 7 configuration file: 8 9 CONFIG_BITBANGMII - Enable the miiphybb driver 10 CONFIG_BITBANGMII_MULTI - Enable the multi bus support 11 12 If the CONFIG_BITBANGMII_MULTI is not defined, the board's config file needs 13 to define at least the following macros: 14 15 MII_INIT - Generic code to enable the MII bus (optional) 16 MDIO_DECLARE - Declaration needed to access to the MDIO pin (optional) 17 MDIO_ACTIVE - Activate the MDIO pin as out pin 18 MDIO_TRISTATE - Activate the MDIO pin as input/tristate pin 19 MDIO_READ - Read the MDIO pin 20 MDIO(v) - Write v on the MDIO pin 21 MDC_DECLARE - Declaration needed to access to the MDC pin (optional) 22 MDC(v) - Write v on the MDC pin 23 24 The previous macros make the driver compatible with the previous version 25 (that didn't support the multi-bus). 26 27 When the CONFIG_BITBANGMII_MULTI is also defined, the board code needs to fill 28 the bb_miiphy_buses[] array with a record for each required bus and declare 29 the bb_miiphy_buses_num variable with the number of mii buses. 30 The record (struct bb_miiphy_bus) has the following fields/callbacks (see 31 miiphy.h for details): 32 33 char name[] - The symbolic name that must be equal to the MII bus 34 registered name 35 int (*init)() - Initialization function called at startup time (just 36 before the Ethernet initialization) 37 int (*mdio_active)() - Activate the MDIO pin as output 38 int (*mdio_tristate)() - Activate the MDIO pin as input/tristate pin 39 int (*set_mdio)() - Write the MDIO pin 40 int (*get_mdio)() - Read the MDIO pin 41 int (*set_mdc)() - Write the MDC pin 42 int (*delay)() - Delay function 43 void *priv - Private data used by board specific code 44 45 The board code will look like: 46 47 struct bb_miiphy_bus bb_miiphy_buses[] = { 48 { .name = "miibus#1", .init = b1_init, .mdio_active = b1_mdio_active, ... }, 49 { .name = "miibus#2", .init = b2_init, .mdio_active = b2_mdio_active, ... }, 50 ... 51 }; 52 int bb_miiphy_buses_num = sizeof(bb_miiphy_buses) / 53 sizeof(bb_miiphy_buses[0]); 54 55 2009 Industrie Dial Face S.p.A. 56 Luigi 'Comio' Mantellini <luigi.mantellini (a] idf-hit.com> 57
README.blackfin
1 Notes for the Blackfin architecture port of Das U-Boot 2 3 ========= 4 ! ABOUT ! 5 ========= 6 7 <marketing blurb> 8 Blackfin Processors embody a new breed of 16/32-bit embedded processor, ideally 9 suited for products where a convergence of capabilities are necessary - 10 multi-format audio, video, voice and image processing; multi-mode baseband and 11 packet processing; control processing; and real-time security. The Blackfin's 12 unique combination of software flexibility and scalability has gained it 13 widespread adoption in convergent applications. 14 </marketing blurb> 15 16 The Blackfin processor is wholly developed by Analog Devices Inc. 17 18 =========== 19 ! SUPPORT ! 20 =========== 21 22 All open source code for the Blackfin processors are being handled via our 23 collaborative website: 24 http://blackfin.uclinux.org/ 25 26 In particular, bug reports, feature requests, help etc... for Das U-Boot are 27 handled in the Das U-Boot sub project: 28 http://blackfin.uclinux.org/gf/project/u-boot 29 30 This website is backed both by an open source community as well as a dedicated 31 team from Analog Devices Inc. 32 33 ============= 34 ! TOOLCHAIN ! 35 ============= 36 37 To compile the Blackfin aspects, you'll need the GNU toolchain configured for 38 the Blackfin processor. You can obtain such a cross-compiler here: 39 http://blackfin.uclinux.org/gf/project/toolchain 40 41 ================= 42 ! DOCUMENTATION ! 43 ================= 44 45 For Blackfin specific documentation, you can visit our dedicated doc wiki: 46 http://docs.blackfin.uclinux.org/doku.php?id=bootloaders:u-boot 47
README.bootmenu
1 SPDX-License-Identifier: GPL-2.0+ 2 /* 3 * (C) Copyright 2011-2012 Pali Rohr <pali.rohar (a] gmail.com> 4 */ 5 6 ANSI terminal bootmenu command 7 8 The "bootmenu" command uses U-Boot menu interfaces and provides 9 a simple mechanism for creating menus with different boot items. 10 The cursor keys "Up" and "Down" are used for navigation through 11 the items. Current active menu item is highlighted and can be 12 selected using the "Enter" key. The selection of the highlighted 13 menu entry invokes an U-Boot command (or a list of commands) 14 associated with this menu entry. 15 16 The "bootmenu" command interprets ANSI escape sequencies, so 17 an ANSI terminal is required for proper menu rendering and item 18 selection. 19 20 The assembling of the menu is done via a set of environment variables 21 "bootmenu_<num>" and "bootmenu_delay", i.e.: 22 23 bootmenu_delay=<delay> 24 bootmenu_<num>="<title>=<commands>" 25 26 <delay> is the autoboot delay in seconds, after which the first 27 menu entry will be selected automatically 28 29 <num> is the boot menu entry number, starting from zero 30 31 <title> is the text of the menu entry shown on the console 32 or on the boot screen 33 34 <commands> are commands which will be executed when a menu 35 entry is selected 36 37 (title and commands are separated by first appearance of '=' 38 character in the environment variable) 39 40 First (optional) argument of the "bootmenu" command is a delay specifier 41 and it overrides the delay value defined by "bootmenu_delay" environment 42 variable. If the environment variable "bootmenu_delay" is not set or if 43 the argument of the "bootmenu" command is not specified, the default delay 44 will be CONFIG_BOOTDELAY. If delay is 0, no menu entries will be shown on 45 the console (or on the screen) and the command of the first menu entry will 46 be called immediately. If delay is less then 0, bootmenu will be shown and 47 autoboot will be disabled. 48 49 Bootmenu always adds menu entry "U-Boot console" at the end of all menu 50 entries specified by environment variables. When selecting this entry 51 the bootmenu terminates and the usual U-Boot command prompt is presented 52 to the user. 53 54 Example environment: 55 56 setenv bootmenu_0 Boot 1. kernel=bootm 0x82000000 # Set first menu entry 57 setenv bootmenu_1 Boot 2. kernel=bootm 0x83000000 # Set second menu entry 58 setenv bootmenu_2 Reset board=reset # Set third menu entry 59 setenv bootmenu_3 U-Boot boot order=boot # Set fourth menu entry 60 bootmenu 20 # Run bootmenu with autoboot delay 20s 61 62 63 The above example will be rendered as below 64 (without decorating rectangle): 65 66 67 68 *** U-Boot Boot Menu *** 69 70 Boot 1. kernel 71 Boot 2. kernel 72 Reset board 73 U-Boot boot order 74 U-Boot console 75 76 Hit any key to stop autoboot: 20 77 Press UP/DOWN to move, ENTER to select 78 79 80 81 Selected menu entry will be highlighted - it will have inverted 82 background and text colors. 83 84 To enable the "bootmenu" command add following definitions to the 85 board config file: 86 87 #define CONFIG_CMD_BOOTMENU 88 #define CONFIG_MENU 89 90 To run the bootmenu at startup add these additional definitions: 91 92 #define CONFIG_AUTOBOOT_KEYED 93 #define CONFIG_BOOTDELAY 30 94 #define CONFIG_MENU_SHOW 95 96 When you intend to use the bootmenu on color frame buffer console, 97 make sure to additionally define CONFIG_CFB_CONSOLE_ANSI in the 98 board config file. 99
README.boston
1 MIPS Boston Development Board 2 3 --------- 4 About 5 --------- 6 7 The MIPS Boston development board is built around an FPGA & 3 PCIe controllers, 8 one of which is connected to an Intel EG20T Platform Controller Hub which 9 provides most connectivity to the board. It is used during the development & 10 testing of both new CPUs and the software support for them. It is essentially 11 the successor of the older MIPS Malta board. 12 13 -------- 14 QEMU 15 -------- 16 17 U-Boot can be run on a currently out-of-tree branch of QEMU with support for 18 the Boston board added. This QEMU code can currently be found in the "boston" 19 branch of git://git.linux-mips.org/pub/scm/paul/qemu.git and used like so: 20 21 $ git clone git://git.linux-mips.org/pub/scm/paul/qemu.git -b boston 22 $ cd qemu 23 $ ./configure --target-list=mips64el-softmmu 24 $ make 25 $ ./mips64el-softmmu/qemu-system-mips64el -M boston -m 2G \ 26 -bios u-boot.bin -serial stdio 27 28 Please note that QEMU will default to emulating the I6400 CPU which implements 29 the MIPS64r6 ISA, and at the time of writing doesn't implement any earlier CPUs 30 with support for the CPS features the Boston board relies upon. You will 31 therefore need to configure U-Boot to build for MIPSr6 in order to obtain a 32 binary that will work in QEMU. 33 34 ------------- 35 Toolchain 36 ------------- 37 38 If building for MIPSr6 then you will need a toolchain including GCC 5.x or 39 newer, or the Codescape toolchain available for download from Imagination 40 Technologies: 41 42 http://codescape-mips-sdk.imgtec.com/components/toolchain/2015.06-05/ 43 44 The "IMG GNU Linux Toolchain" is capable of building for all current MIPS ISAs, 45 architecture revisions & both endiannesses. 46 47 -------- 48 TODO 49 -------- 50 51 - AHCI support 52 - CPU driver 53 - Exception handling (+UHI?) 54 - Flash support 55 - IOCU support 56 - L2 cache support 57 - More general LCD display driver 58 - Multi-arch-variant multi-endian fat binary 59
README.bus_vcxk
1 SPDX-License-Identifier: GPL-2.0+ 2 /* 3 * (C) Copyright 2008-2009 4 * BuS Elektronik GmbH & Co. KG <www.bus-elektronik.de> 5 * Jens Scharsig <esw (a] bus-elektronik.de> 6 */ 7 8 U-Boot vcxk video controller driver 9 ====================================== 10 11 By defining CONFIG_VIDEO_VCXK this driver can be used with VC2K, VC4K and 12 VC8K devices on following boards: 13 14 board | ARCH | Vendor 15 ----------------------------------------------------------------------- 16 EB+CPU5282-T1 | MCF5282 | BuS Elektronik GmbH & Co. KG 17 EB+MCF-EVB123 | MCF5282 | BuS Elektronik GmbH & Co. KG 18 EB+CPUx9K2 | AT91RM9200 | BuS Elektronik GmbH & Co. KG 19 ZLSA | AT91RM9200 | Ruf Telematik AG 20 21 Driver configuration 22 -------------------- 23 24 The driver needs some defines to describe the target hardware: 25 26 CONFIG_SYS_VCXK_BASE 27 28 base address of VCxK hardware memory 29 30 CONFIG_SYS_VCXK_DEFAULT_LINEALIGN 31 32 defines the physical alignment of a pixel row 33 34 CONFIG_SYS_VCXK_DOUBLEBUFFERED 35 36 some boards that use vcxk prevent read from framebuffer memory. 37 define this option to enable double buffering (needs 16KiB RAM) 38 39 CONFIG_SYS_VCXK_<xxxx>_PIN 40 41 defines the number of the I/O line PIN in the port 42 valid values for <xxxx> are: 43 44 ACKNOWLEDGE 45 describes the acknowledge line from vcxk hardware 46 47 ENABLE 48 describes the enable line to vcxk hardware 49 50 INVERT 51 describes the invert line to vcxk hardware 52 53 RESET 54 describes the reset line to vcxk hardware 55 56 REQUEST 57 describes the request line to vcxk hardware 58 59 CONFIG_SYS_VCXK_<xxxx>_PORT 60 61 defines the I/O port which is connected with the line 62 for valid values for <xxxx> see CONFIG_SYS_VCXK_<xxxx>_PIN 63 64 CONFIG_SYS_VCXK_<xxxx>_DDR 65 66 defines the register which configures the direction 67 for valid values for <xxxx> see CONFIG_SYS_VCXK_<xxxx>_PIN 68
README.cfi
1 The common CFI driver provides this weak default implementation for 2 flash_cmd_reset(): 3 4 static void __flash_cmd_reset(flash_info_t *info) 5 { 6 /* 7 * We do not yet know what kind of commandset to use, so we issue 8 * the reset command in both Intel and AMD variants, in the hope 9 * that AMD flash roms ignore the Intel command. 10 */ 11 flash_write_cmd(info, 0, 0, AMD_CMD_RESET); 12 udelay(1); 13 flash_write_cmd(info, 0, 0, FLASH_CMD_RESET); 14 } 15 void flash_cmd_reset(flash_info_t *info) 16 __attribute__((weak,alias("__flash_cmd_reset"))); 17 18 Some flash chips seem to have trouble with this reset sequence. 19 In this case, board-specific code can override this weak default 20 version with a board-specific function. 21 22 At the time of writing, there are two boards that define their own 23 routine for this. 24 25 First, the digsy_mtc board equipped with the M29W128GH from Numonyx 26 needs this version to function properly: 27 28 void flash_cmd_reset(flash_info_t *info) 29 { 30 flash_write_cmd(info, 0, 0, AMD_CMD_RESET); 31 } 32 33 In addition, the t3corp board defines the routine thusly: 34 35 void flash_cmd_reset(flash_info_t *info) 36 { 37 /* 38 * FLASH at address CONFIG_SYS_FLASH_BASE is a Spansion chip and 39 * needs the Spansion type reset commands. The other flash chip 40 * is located behind a FPGA (Xilinx DS617) and needs the Intel type 41 * reset command. 42 */ 43 if (info->start[0] == CONFIG_SYS_FLASH_BASE) 44 flash_write_cmd(info, 0, 0, AMD_CMD_RESET); 45 else 46 flash_write_cmd(info, 0, 0, FLASH_CMD_RESET); 47 } 48 49 see also: 50 http://www.mail-archive.com/u-boot@lists.denx.de/msg24368.html 51 52 53 Config Option 54 55 CONFIG_SYS_MAX_FLASH_SECT: Number of sectors available on Flash device 56 57 CONFIG_SYS_FLASH_CFI_WIDTH: Data-width of the flash device 58 59 CONFIG_CMD_FLASH: Enables Flash command library 60 61 CONFIG_FLASH_CFI_DRIVER: Enables CFI Flash driver 62 63 CONFIG_FLASH_CFI_MTD: Enables MTD frame work for NOR Flash devices 64
README.chromium
1 Running U-Boot from coreboot on Chromebooks 2 =========================================== 3 4 U-Boot can be used as a secondary boot loader in a few situations such as from 5 UEFI and coreboot (see README.x86). Recent Chromebooks use coreboot even on 6 ARM platforms to start up the machine. 7 8 This document aims to provide a guide to booting U-Boot on a Chromebook. It 9 is only a starting point, and there are many guides on the interwebs. But 10 placing this information in the U-Boot tree should make it easier to find for 11 those who use U-Boot habitually. 12 13 Most of these platforms are supported by U-Boot natively, but it is risky to 14 replace the ROM unless you have a servo board and cable to restore it with. 15 16 17 For all of these the standard U-Boot build instructions apply. For example on 18 ARM: 19 20 sudo apt install gcc-arm-linux-gnueabi 21 mkdir b 22 make O=b/nyan_big CROSS_COMPILE=arm-linux-gnueabi- nyan-big_defconfig all 23 24 You can obtain the vbutil_kernel utility here: 25 26 https://drive.google.com/open?id=0B7WYZbZ9zd-3dHlVVXo4VXE2T0U 27 28 29 Snow (Samsung ARM Chromebook) 30 ----------------------------- 31 32 See here: 33 34 https://www.chromium.org/chromium-os/firmware-porting-guide/using-nv-u-boot-on-the-samsung-arm-chromebook 35 36 37 Nyan-big 38 -------- 39 40 Compiled based on information here: 41 https://lists.denx.de/pipermail/u-boot/2015-March/209530.html 42 https://git.collabora.com/cgit/user/tomeu/u-boot.git/commit/?h=nyan-big 43 https://lists.denx.de/pipermail/u-boot/2017-May/289491.html 44 https://github.com/chromeos-nvidia-androidtv/gnu-linux-on-acer-chromebook-13#copy-data-to-the-sd-card 45 46 1. Build U-Boot 47 48 mkdir b 49 make -j8 O=b/nyan-big CROSS_COMPILE=arm-linux-gnueabi- nyan-big_defconfig all 50 51 52 2. Select a .its file 53 54 Select something from doc/chromium which matches your board, or create your 55 own. 56 57 Note that the device tree node is required, even though it is not actually 58 used by U-Boot. This is because the Chromebook expects to pass it to the 59 kernel, and crashes if it is not present. 60 61 62 3. Build and sign an image 63 64 ./b/nyan-big/tools/mkimage -f doc/chromium/nyan-big.its u-boot-chromium.fit 65 echo test >dummy.txt 66 vbutil_kernel --arch arm --keyblock doc/chromium/devkeys/kernel.keyblock \ 67 --signprivate doc/chromium/devkeys/kernel_data_key.vbprivk \ 68 --version 1 --config dummy.txt --vmlinuz u-boot-chromium.fit \ 69 --bootloader dummy.txt --pack u-boot.kpart 70 71 72 4. Prepare an SD card 73 74 DISK=/dev/sdc # Replace with your actual SD card device 75 sudo cgpt create $DISK 76 sudo cgpt add -b 34 -s 32768 -P 1 -S 1 -t kernel $DISK 77 sudo cgpt add -b 32802 -s 2000000 -t rootfs $DISK 78 sudo gdisk $DISK # Enter command 'w' to write a protective MBR to the disk 79 80 81 5. Write U-Boot to the SD card 82 83 sudo dd if=u-boot.kpart of=/dev/sdc1; sync 84 85 86 6. Start it up 87 88 Reboot the device in dev mode. Make sure that you have USB booting enabled. To 89 do this, login as root (via Ctrl-Alt-forward_arrow) and type 90 'enable_dev_usb_boot'. You only need to do this once. 91 92 Reboot the device with the SD card inserted. Press Clrl-U at the developer 93 mode screen. It should show something like the following on the display: 94 95 U-Boot 2017.07-00637-g242eb42-dirty (May 22 2017 - 06:14:21 -0600) 96 97 Model: Acer Chromebook 13 CB5-311 98 Board: Google/NVIDIA Nyan-big, ID: 1 99 100 Net: No ethernet found. 101 Hit any key to stop autoboot: 0 102 Tegra124 (Nyan-big) # 103 104 105 7. Known problems 106 107 On the serial console the word MMC is chopped at the start of the line: 108 109 C: sdhci@700b0000: 2, sdhci@700b0400: 1, sdhci@700b0600: 0 110 111 This is likely due to some problem with change-over of the serial driver 112 during relocation (or perhaps updating the clock setup in board_init()). 113 114 115 9. Notes 116 117 To check that you copied the u-boot.its file correctly, use these commands. 118 You should see that the data at 0x100 in u-boot-chromium.fit is the first few 119 bytes of U-Boot: 120 121 hd u-boot-chromium.fit |head -20 122 ... 123 00000100 b8 00 00 ea 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 |................| 124 125 hd b/nyan-big/u-boot.bin |head 126 00000000 b8 00 00 ea 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 |................| 127 128 129 The 'data' property of the FIT is set up to start at offset 0x100 bytes into 130 the file. The change to CONFIG_SYS_TEXT_BASE is also an offset of 0x100 bytes 131 from the load address. If this changes, you either need to modify U-Boot to be 132 fully relocatable, or expect it to hang. 133 134 135 chromebook_jerry 136 ---------------- 137 138 The instruction are similar to those for Nyan with changes as noted below: 139 140 1. Patch U-Boot 141 142 Open include/configs/rk3288_common.h 143 144 Change: 145 146 #define CONFIG_SYS_TEXT_BASE 0x00100000 147 148 to: 149 150 #define CONFIG_SYS_TEXT_BASE 0x02000100 151 152 153 154 2. Build U-Boot 155 156 mkdir b 157 make -j8 O=b/chromebook_jerry CROSS_COMPILE=arm-linux-gnueabi- \ 158 chromebook_jerry_defconfig all 159 160 161 3. See above 162 163 4. Build and sign an image 164 165 ./b/chromebook_jerry/tools/mkimage -f doc/chromium/chromebook_jerry.its \ 166 u-boot-chromium.fit 167 echo test >dummy.txt 168 vbutil_kernel --arch arm --keyblock doc/chromium/devkeys/kernel.keyblock \ 169 --signprivate doc/chromium/devkeys/kernel_data_key.vbprivk \ 170 --version 1 --config dummy.txt --vmlinuz u-boot-chromium.fit \ 171 --bootloader dummy.txt --pack u-boot.kpart 172 173 174 5. See above 175 176 6. See above 177 178 7. Start it up 179 180 Reboot the device in dev mode. Make sure that you have USB booting enabled. To 181 do this, login as root (via Ctrl-Alt-forward_arrow) and type 182 'enable_dev_usb_boot'. You only need to do this once. 183 184 Reboot the device with the SD card inserted. Press Clrl-U at the developer 185 mode screen. It should show something like the following on the display: 186 187 U-Boot 2017.05-00649-g72acdbf-dirty (May 29 2017 - 14:57:05 -0600) 188 189 Model: Google Jerry 190 Net: Net Initialization Skipped 191 No ethernet found. 192 Hit any key to stop autoboot: 0 193 194 195 8. Known problems 196 197 None as yet. 198 199 200 9. Notes 201 202 None as yet. 203 204 205 Other notes 206 =========== 207 208 flashrom 209 -------- 210 211 Used to make a backup of your firmware, or to replace it. 212 213 See: https://www.chromium.org/chromium-os/packages/cros-flashrom 214 215 216 coreboot 217 -------- 218 219 Coreboot itself is not designed to actually boot an OS. Instead, a program 220 called Depthcharge is used. This originally came out of U-Boot and was then 221 heavily hacked and modified such that is is almost unrecognisable. It does 222 include a very small part of the U-Boot command-line interface but is not 223 usable as a general-purpose boot loader. 224 225 In addition, it has a very unusual design in that it does not do device init 226 itself, but instead relies on coreboot. This is similar to (in U-Boot) having 227 a SPI driver with an empty probe() method, relying on whatever was set up 228 beforehand. It can be quite hard to figure out between these two code bases 229 what settings are actually used. When chain-loading into U-Boot we must be 230 careful to reinit anything that U-Boot expects. If not, some peripherals (or 231 the whole machine) may not work. This makes the process of chainloading more 232 complicated than it could be on some platforms. 233 234 Finally, it supports only a subset of the U-Boot's FIT format. In particular 235 it uses a fixed address to load the FIT and does not support load/exec 236 addresses. This means that U-Boot must be able to boot from whatever 237 address Depthcharge happens to use (it is the CONFIG_KERNEL_START setting 238 in Depthcharge). In practice this means that the data in the kernel@1 FIT node 239 (see above) must start at the same address as U-Boot's CONFIG_SYS_TEXT_BASE. 240
README.clang
1 The biggest problem when trying to compile U-Boot with clang is that 2 almost all archs rely on storing gd in a global register and clang user 3 manual states: "clang does not support global register variables; this 4 is unlikely to be implemented soon because it requires additional LLVM 5 backend support." 6 7 Since version 3.4 the ARM backend can be instructed to leave r9 alone. 8 Global registers themselves are not supported so some inline assembly is 9 used to get its value. This does lead to larger code then strictly 10 necessary, but at least works. 11 12 NOTE: target compilation only work for _some_ ARM boards at the moment. 13 Also AArch64 is not supported currently due to a lack of private libgcc 14 support. Boards which reassign gd in c will also fail to compile, but there is 15 in no strict reason to do so in the ARM world, since crt0.S takes care of this. 16 These assignments can be avoided by changing the init calls but this is not in 17 mainline yet. 18 19 Debian (based) 20 -------------- 21 Binary packages can be installed as usual, e.g.: 22 sudo apt-get install clang 23 24 Note that we still use binutils for some tools so we must continue to set 25 CROSS_COMPILE. To compile U-Boot with clang on linux without IAS use e.g.: 26 make HOSTCC=clang rpi_2_defconfig 27 make HOSTCC=clang CROSS_COMPILE=arm-linux-gnueabi- \ 28 CC="clang -target arm-linux-gnueabi" -j8 29 30 It can also be used to compile sandbox: 31 make HOSTCC=clang sandbox_defconfig 32 make HOSTCC=clang CC=clang -j8 33 34 FreeBSD 11 (Current): 35 -------------------- 36 Since llvm 3.4 is currently in the base system, the integrated as is 37 incapable of building U-Boot. Therefore gas from devel/arm-gnueabi-binutils 38 is used instead. It needs a symlinks to be picked up correctly though: 39 40 ln -s /usr/local/bin/arm-gnueabi-freebsd-as /usr/bin/arm-freebsd-eabi-as 41 42 # The following commands compile U-Boot using the clang xdev toolchain. 43 # NOTE: CROSS_COMPILE and target differ on purpose! 44 export CROSS_COMPILE=arm-gnueabi-freebsd- 45 gmake rpi_2_defconfig 46 gmake CC="clang -target arm-freebsd-eabi --sysroot /usr/arm-freebsd" -j8 47 48 Given that U-Boot will default to gcc, above commands can be 49 simplified with a simple wrapper script, listed below. 50 51 /usr/local/bin/arm-gnueabi-freebsd-gcc 52 --- 53 #!/bin/sh 54 55 exec clang -target arm-freebsd-eabi --sysroot /usr/arm-freebsd "$@" 56
README.coccinelle
1 .. Copyright 2010 Nicolas Palix <npalix (a] diku.dk> 2 .. Copyright 2010 Julia Lawall <julia (a] diku.dk> 3 .. Copyright 2010 Gilles Muller <Gilles.Muller (a] lip6.fr> 4 5 .. highlight:: none 6 7 Coccinelle 8 ========== 9 10 Coccinelle is a tool for pattern matching and text transformation that has 11 many uses in kernel development, including the application of complex, 12 tree-wide patches and detection of problematic programming patterns. 13 14 Getting Coccinelle 15 ------------------- 16 17 The semantic patches included in the kernel use features and options 18 which are provided by Coccinelle version 1.0.0-rc11 and above. 19 Using earlier versions will fail as the option names used by 20 the Coccinelle files and coccicheck have been updated. 21 22 Coccinelle is available through the package manager 23 of many distributions, e.g. : 24 25 - Debian 26 - Fedora 27 - Ubuntu 28 - OpenSUSE 29 - Arch Linux 30 - NetBSD 31 - FreeBSD 32 33 You can get the latest version released from the Coccinelle homepage at 34 http://coccinelle.lip6.fr/ 35 36 Information and tips about Coccinelle are also provided on the wiki 37 pages at http://cocci.ekstranet.diku.dk/wiki/doku.php 38 39 Once you have it, run the following command:: 40 41 ./configure 42 make 43 44 as a regular user, and install it with:: 45 46 sudo make install 47 48 Supplemental documentation 49 --------------------------- 50 51 For supplemental documentation refer to the wiki: 52 53 https://bottest.wiki.kernel.org/coccicheck 54 55 The wiki documentation always refers to the linux-next version of the script. 56 57 Using Coccinelle on the Linux kernel 58 ------------------------------------ 59 60 A Coccinelle-specific target is defined in the top level 61 Makefile. This target is named ``coccicheck`` and calls the ``coccicheck`` 62 front-end in the ``scripts`` directory. 63 64 Four basic modes are defined: ``patch``, ``report``, ``context``, and 65 ``org``. The mode to use is specified by setting the MODE variable with 66 ``MODE=<mode>``. 67 68 - ``patch`` proposes a fix, when possible. 69 70 - ``report`` generates a list in the following format: 71 file:line:column-column: message 72 73 - ``context`` highlights lines of interest and their context in a 74 diff-like style.Lines of interest are indicated with ``-``. 75 76 - ``org`` generates a report in the Org mode format of Emacs. 77 78 Note that not all semantic patches implement all modes. For easy use 79 of Coccinelle, the default mode is "report". 80 81 Two other modes provide some common combinations of these modes. 82 83 - ``chain`` tries the previous modes in the order above until one succeeds. 84 85 - ``rep+ctxt`` runs successively the report mode and the context mode. 86 It should be used with the C option (described later) 87 which checks the code on a file basis. 88 89 Examples 90 ~~~~~~~~ 91 92 To make a report for every semantic patch, run the following command:: 93 94 make coccicheck MODE=report 95 96 To produce patches, run:: 97 98 make coccicheck MODE=patch 99 100 101 The coccicheck target applies every semantic patch available in the 102 sub-directories of ``scripts/coccinelle`` to the entire Linux kernel. 103 104 For each semantic patch, a commit message is proposed. It gives a 105 description of the problem being checked by the semantic patch, and 106 includes a reference to Coccinelle. 107 108 As any static code analyzer, Coccinelle produces false 109 positives. Thus, reports must be carefully checked, and patches 110 reviewed. 111 112 To enable verbose messages set the V= variable, for example:: 113 114 make coccicheck MODE=report V=1 115 116 Coccinelle parallelization 117 --------------------------- 118 119 By default, coccicheck tries to run as parallel as possible. To change 120 the parallelism, set the J= variable. For example, to run across 4 CPUs:: 121 122 make coccicheck MODE=report J=4 123 124 As of Coccinelle 1.0.2 Coccinelle uses Ocaml parmap for parallelization, 125 if support for this is detected you will benefit from parmap parallelization. 126 127 When parmap is enabled coccicheck will enable dynamic load balancing by using 128 ``--chunksize 1`` argument, this ensures we keep feeding threads with work 129 one by one, so that we avoid the situation where most work gets done by only 130 a few threads. With dynamic load balancing, if a thread finishes early we keep 131 feeding it more work. 132 133 When parmap is enabled, if an error occurs in Coccinelle, this error 134 value is propagated back, the return value of the ``make coccicheck`` 135 captures this return value. 136 137 Using Coccinelle with a single semantic patch 138 --------------------------------------------- 139 140 The optional make variable COCCI can be used to check a single 141 semantic patch. In that case, the variable must be initialized with 142 the name of the semantic patch to apply. 143 144 For instance:: 145 146 make coccicheck COCCI=<my_SP.cocci> MODE=patch 147 148 or:: 149 150 make coccicheck COCCI=<my_SP.cocci> MODE=report 151 152 153 Controlling Which Files are Processed by Coccinelle 154 --------------------------------------------------- 155 156 By default the entire kernel source tree is checked. 157 158 To apply Coccinelle to a specific directory, ``M=`` can be used. 159 For example, to check drivers/net/wireless/ one may write:: 160 161 make coccicheck M=drivers/net/wireless/ 162 163 To apply Coccinelle on a file basis, instead of a directory basis, the 164 following command may be used:: 165 166 make C=1 CHECK="scripts/coccicheck" 167 168 To check only newly edited code, use the value 2 for the C flag, i.e.:: 169 170 make C=2 CHECK="scripts/coccicheck" 171 172 In these modes, which works on a file basis, there is no information 173 about semantic patches displayed, and no commit message proposed. 174 175 This runs every semantic patch in scripts/coccinelle by default. The 176 COCCI variable may additionally be used to only apply a single 177 semantic patch as shown in the previous section. 178 179 The "report" mode is the default. You can select another one with the 180 MODE variable explained above. 181 182 Debugging Coccinelle SmPL patches 183 --------------------------------- 184 185 Using coccicheck is best as it provides in the spatch command line 186 include options matching the options used when we compile the kernel. 187 You can learn what these options are by using V=1, you could then 188 manually run Coccinelle with debug options added. 189 190 Alternatively you can debug running Coccinelle against SmPL patches 191 by asking for stderr to be redirected to stderr, by default stderr 192 is redirected to /dev/null, if you'd like to capture stderr you 193 can specify the ``DEBUG_FILE="file.txt"`` option to coccicheck. For 194 instance:: 195 196 rm -f cocci.err 197 make coccicheck COCCI=scripts/coccinelle/free/kfree.cocci MODE=report DEBUG_FILE=cocci.err 198 cat cocci.err 199 200 You can use SPFLAGS to add debugging flags, for instance you may want to 201 add both --profile --show-trying to SPFLAGS when debugging. For instance 202 you may want to use:: 203 204 rm -f err.log 205 export COCCI=scripts/coccinelle/misc/irqf_oneshot.cocci 206 make coccicheck DEBUG_FILE="err.log" MODE=report SPFLAGS="--profile --show-trying" M=./drivers/mfd/arizona-irq.c 207 208 err.log will now have the profiling information, while stdout will 209 provide some progress information as Coccinelle moves forward with 210 work. 211 212 DEBUG_FILE support is only supported when using coccinelle >= 1.2. 213 214 .cocciconfig support 215 -------------------- 216 217 Coccinelle supports reading .cocciconfig for default Coccinelle options that 218 should be used every time spatch is spawned, the order of precedence for 219 variables for .cocciconfig is as follows: 220 221 - Your current user's home directory is processed first 222 - Your directory from which spatch is called is processed next 223 - The directory provided with the --dir option is processed last, if used 224 225 Since coccicheck runs through make, it naturally runs from the kernel 226 proper dir, as such the second rule above would be implied for picking up a 227 .cocciconfig when using ``make coccicheck``. 228 229 ``make coccicheck`` also supports using M= targets.If you do not supply 230 any M= target, it is assumed you want to target the entire kernel. 231 The kernel coccicheck script has:: 232 233 if [ "$KBUILD_EXTMOD" = "" ] ; then 234 OPTIONS="--dir $srctree $COCCIINCLUDE" 235 else 236 OPTIONS="--dir $KBUILD_EXTMOD $COCCIINCLUDE" 237 fi 238 239 KBUILD_EXTMOD is set when an explicit target with M= is used. For both cases 240 the spatch --dir argument is used, as such third rule applies when whether M= 241 is used or not, and when M= is used the target directory can have its own 242 .cocciconfig file. When M= is not passed as an argument to coccicheck the 243 target directory is the same as the directory from where spatch was called. 244 245 If not using the kernel's coccicheck target, keep the above precedence 246 order logic of .cocciconfig reading. If using the kernel's coccicheck target, 247 override any of the kernel's .coccicheck's settings using SPFLAGS. 248 249 We help Coccinelle when used against Linux with a set of sensible defaults 250 options for Linux with our own Linux .cocciconfig. This hints to coccinelle 251 git can be used for ``git grep`` queries over coccigrep. A timeout of 200 252 seconds should suffice for now. 253 254 The options picked up by coccinelle when reading a .cocciconfig do not appear 255 as arguments to spatch processes running on your system, to confirm what 256 options will be used by Coccinelle run:: 257 258 spatch --print-options-only 259 260 You can override with your own preferred index option by using SPFLAGS. Take 261 note that when there are conflicting options Coccinelle takes precedence for 262 the last options passed. Using .cocciconfig is possible to use idutils, however 263 given the order of precedence followed by Coccinelle, since the kernel now 264 carries its own .cocciconfig, you will need to use SPFLAGS to use idutils if 265 desired. See below section "Additional flags" for more details on how to use 266 idutils. 267 268 Additional flags 269 ---------------- 270 271 Additional flags can be passed to spatch through the SPFLAGS 272 variable. This works as Coccinelle respects the last flags 273 given to it when options are in conflict. :: 274 275 make SPFLAGS=--use-glimpse coccicheck 276 277 Coccinelle supports idutils as well but requires coccinelle >= 1.0.6. 278 When no ID file is specified coccinelle assumes your ID database file 279 is in the file .id-utils.index on the top level of the kernel, coccinelle 280 carries a script scripts/idutils_index.sh which creates the database with:: 281 282 mkid -i C --output .id-utils.index 283 284 If you have another database filename you can also just symlink with this 285 name. :: 286 287 make SPFLAGS=--use-idutils coccicheck 288 289 Alternatively you can specify the database filename explicitly, for 290 instance:: 291 292 make SPFLAGS="--use-idutils /full-path/to/ID" coccicheck 293 294 See ``spatch --help`` to learn more about spatch options. 295 296 Note that the ``--use-glimpse`` and ``--use-idutils`` options 297 require external tools for indexing the code. None of them is 298 thus active by default. However, by indexing the code with 299 one of these tools, and according to the cocci file used, 300 spatch could proceed the entire code base more quickly. 301 302 SmPL patch specific options 303 --------------------------- 304 305 SmPL patches can have their own requirements for options passed 306 to Coccinelle. SmPL patch specific options can be provided by 307 providing them at the top of the SmPL patch, for instance:: 308 309 // Options: --no-includes --include-headers 310 311 SmPL patch Coccinelle requirements 312 ---------------------------------- 313 314 As Coccinelle features get added some more advanced SmPL patches 315 may require newer versions of Coccinelle. If an SmPL patch requires 316 at least a version of Coccinelle, this can be specified as follows, 317 as an example if requiring at least Coccinelle >= 1.0.5:: 318 319 // Requires: 1.0.5 320 321 Proposing new semantic patches 322 ------------------------------- 323 324 New semantic patches can be proposed and submitted by kernel 325 developers. For sake of clarity, they should be organized in the 326 sub-directories of ``scripts/coccinelle/``. 327 328 329 Detailed description of the ``report`` mode 330 ------------------------------------------- 331 332 ``report`` generates a list in the following format:: 333 334 file:line:column-column: message 335 336 Example 337 ~~~~~~~ 338 339 Running:: 340 341 make coccicheck MODE=report COCCI=scripts/coccinelle/api/err_cast.cocci 342 343 will execute the following part of the SmPL script:: 344 345 <smpl> 346 @r depends on !context && !patch && (org || report)@ 347 expression x; 348 position p; 349 @@ 350 351 ERR_PTR@p(PTR_ERR(x)) 352 353 @script:python depends on report@ 354 p << r.p; 355 x << r.x; 356 @@ 357 358 msg="ERR_CAST can be used with %s" % (x) 359 coccilib.report.print_report(p[0], msg) 360 </smpl> 361 362 This SmPL excerpt generates entries on the standard output, as 363 illustrated below:: 364 365 /home/user/linux/crypto/ctr.c:188:9-16: ERR_CAST can be used with alg 366 /home/user/linux/crypto/authenc.c:619:9-16: ERR_CAST can be used with auth 367 /home/user/linux/crypto/xts.c:227:9-16: ERR_CAST can be used with alg 368 369 370 Detailed description of the ``patch`` mode 371 ------------------------------------------ 372 373 When the ``patch`` mode is available, it proposes a fix for each problem 374 identified. 375 376 Example 377 ~~~~~~~ 378 379 Running:: 380 381 make coccicheck MODE=patch COCCI=scripts/coccinelle/api/err_cast.cocci 382 383 will execute the following part of the SmPL script:: 384 385 <smpl> 386 @ depends on !context && patch && !org && !report @ 387 expression x; 388 @@ 389 390 - ERR_PTR(PTR_ERR(x)) 391 + ERR_CAST(x) 392 </smpl> 393 394 This SmPL excerpt generates patch hunks on the standard output, as 395 illustrated below:: 396 397 diff -u -p a/crypto/ctr.c b/crypto/ctr.c 398 --- a/crypto/ctr.c 2010-05-26 10:49:38.000000000 +0200 399 +++ b/crypto/ctr.c 2010-06-03 23:44:49.000000000 +0200 400 @@ -185,7 +185,7 @@ static struct crypto_instance *crypto_ct 401 alg = crypto_attr_alg(tb[1], CRYPTO_ALG_TYPE_CIPHER, 402 CRYPTO_ALG_TYPE_MASK); 403 if (IS_ERR(alg)) 404 - return ERR_PTR(PTR_ERR(alg)); 405 + return ERR_CAST(alg); 406 407 /* Block size must be >= 4 bytes. */ 408 err = -EINVAL; 409 410 Detailed description of the ``context`` mode 411 -------------------------------------------- 412 413 ``context`` highlights lines of interest and their context 414 in a diff-like style. 415 416 **NOTE**: The diff-like output generated is NOT an applicable patch. The 417 intent of the ``context`` mode is to highlight the important lines 418 (annotated with minus, ``-``) and gives some surrounding context 419 lines around. This output can be used with the diff mode of 420 Emacs to review the code. 421 422 Example 423 ~~~~~~~ 424 425 Running:: 426 427 make coccicheck MODE=context COCCI=scripts/coccinelle/api/err_cast.cocci 428 429 will execute the following part of the SmPL script:: 430 431 <smpl> 432 @ depends on context && !patch && !org && !report@ 433 expression x; 434 @@ 435 436 * ERR_PTR(PTR_ERR(x)) 437 </smpl> 438 439 This SmPL excerpt generates diff hunks on the standard output, as 440 illustrated below:: 441 442 diff -u -p /home/user/linux/crypto/ctr.c /tmp/nothing 443 --- /home/user/linux/crypto/ctr.c 2010-05-26 10:49:38.000000000 +0200 444 +++ /tmp/nothing 445 @@ -185,7 +185,6 @@ static struct crypto_instance *crypto_ct 446 alg = crypto_attr_alg(tb[1], CRYPTO_ALG_TYPE_CIPHER, 447 CRYPTO_ALG_TYPE_MASK); 448 if (IS_ERR(alg)) 449 - return ERR_PTR(PTR_ERR(alg)); 450 451 /* Block size must be >= 4 bytes. */ 452 err = -EINVAL; 453 454 Detailed description of the ``org`` mode 455 ---------------------------------------- 456 457 ``org`` generates a report in the Org mode format of Emacs. 458 459 Example 460 ~~~~~~~ 461 462 Running:: 463 464 make coccicheck MODE=org COCCI=scripts/coccinelle/api/err_cast.cocci 465 466 will execute the following part of the SmPL script:: 467 468 <smpl> 469 @r depends on !context && !patch && (org || report)@ 470 expression x; 471 position p; 472 @@ 473 474 ERR_PTR@p(PTR_ERR(x)) 475 476 @script:python depends on org@ 477 p << r.p; 478 x << r.x; 479 @@ 480 481 msg="ERR_CAST can be used with %s" % (x) 482 msg_safe=msg.replace("[","@(").replace("]",")") 483 coccilib.org.print_todo(p[0], msg_safe) 484 </smpl> 485 486 This SmPL excerpt generates Org entries on the standard output, as 487 illustrated below:: 488 489 * TODO [[view:/home/user/linux/crypto/ctr.c::face=ovl-face1::linb=188::colb=9::cole=16][ERR_CAST can be used with alg]] 490 * TODO [[view:/home/user/linux/crypto/authenc.c::face=ovl-face1::linb=619::colb=9::cole=16][ERR_CAST can be used with auth]] 491 * TODO [[view:/home/user/linux/crypto/xts.c::face=ovl-face1::linb=227::colb=9::cole=16][ERR_CAST can be used with alg]] 492
README.commands
1 Command definition 2 ------------------ 3 4 Commands are added to U-Boot by creating a new command structure. 5 This is done by first including command.h, then using the U_BOOT_CMD() or the 6 U_BOOT_CMD_COMPLETE macro to fill in a cmd_tbl_t struct. 7 8 U_BOOT_CMD(name, maxargs, repeatable, command, "usage", "help") 9 U_BOOT_CMD_COMPLETE(name, maxargs, repeatable, command, "usage, "help", comp) 10 11 name: The name of the command. THIS IS NOT a string. 12 13 maxargs: The maximum number of arguments this function takes including 14 the command itself. 15 16 repeatable: Either 0 or 1 to indicate if autorepeat is allowed. 17 18 command: Pointer to the command function. This is the function that is 19 called when the command is issued. 20 21 usage: Short description. This is a string. 22 23 help: Long description. This is a string. The long description is 24 only available if CONFIG_SYS_LONGHELP is defined. 25 26 comp: Pointer to the completion function. May be NULL. 27 This function is called if the user hits the TAB key while 28 entering the command arguments to complete the entry. Command 29 completion is only available if CONFIG_AUTO_COMPLETE is defined. 30 31 Command function 32 ---------------- 33 34 The commmand function pointer has to be of type 35 int (*cmd)(struct cmd_tbl_s *cmdtp, int flag, int argc, const char *argv[]); 36 37 cmdtp: Table entry describing the command (see above). 38 39 flag: A bitmap which may contain the following bit: 40 CMD_FLAG_REPEAT - The last command is repeated. 41 CMD_FLAG_BOOTD - The command is called by the bootd command. 42 CMD_FLAG_ENV - The command is called by the run command. 43 44 argc: Number of arguments including the command. 45 46 argv: Arguments. 47 48 Allowable return value are: 49 50 CMD_SUCCESS The command was successfully executed. 51 52 CMD_FAILURE The command failed. 53 54 CMD_RET_USAGE The command was called with invalid parameters. This value 55 leads to the display of the usage string. 56 57 Completion function 58 ------------------- 59 60 The completion function pointer has to be of type 61 int (*complete)(int argc, char *const argv[], char last_char, 62 int maxv, char *cmdv[]); 63 64 argc: Number of arguments including the command. 65 66 argv: Arguments. 67 68 last_char: The last character in the command line buffer. 69 70 maxv: Maximum number of possible completions that may be returned by 71 the function. 72 73 cmdv: Used to return possible values for the last argument. The last 74 possible completion must be followed by NULL. 75 76 The function returns the number of possible completions (without the terminating 77 NULL value). 78 79 Behind the scene 80 ---------------- 81 82 The structure created is named with a special prefix and placed by 83 the linker in a special section using the linker lists mechanism 84 (see include/linker_lists.h) 85 86 This makes it possible for the final link to extract all commands 87 compiled into any object code and construct a static array so the 88 command array can be iterated over using the linker lists macros. 89 90 The linker lists feature ensures that the linker does not discard 91 these symbols when linking full U-Boot even though they are not 92 referenced in the source code as such. 93 94 If a new board is defined do not forget to define the command section 95 by writing in u-boot.lds ($(srctree)/board/boardname/u-boot.lds) these 96 3 lines: 97 98 .u_boot_list : { 99 KEEP(*(SORT(.u_boot_list*))); 100 } 101
README.commands.itest
1 A slow day today so here is a revised itest command with provisional 2 support for comparing strings as well :-)) 3 4 Now table driven to allow the operators 5 -eq, -ne, -lt, -gt, -le, -ge, ==, !=, <>, <, >, <=, >= 6 7 Uses the expected command modifier for integer compares of width 1, 2 or 8 4 bytes of .b, .w, .l and the new modifer of .s for a string compare. 9 String comparison is over the length of the shorter, this hopefully 10 avoids missing terminators when using an indirect pointer. 11 12 eg. 13 if itest.l *40000 == 12345678 then; .... 14 if itest.w *40000 != 1234 then; .... 15 if itest.b *40000 >= 12 then; .... 16 if itest.s *40000 -eq hello then; .... 17
README.commands.spl
1 The spl command is used to export a boot parameter image to RAM. Later 2 it may implement more functions connected to the SPL. 3 4 SUBCOMMAND EXPORT 5 To execute the command everything has to be in place as if bootm should be 6 used. (kernel image, initrd-image, fdt-image etc.) 7 8 export has two subcommands: 9 atags: exports the ATAGS 10 fdt: exports the FDT 11 12 Call is: 13 spl export <fdt|atags> [kernel_addr] [initrd_addr] [fdt_addr if fdt] 14 15 16 TYPICAL CALL 17 18 on OMAP3: 19 nandecc hw 20 nand read 0x82000000 0x280000 0x400000 /* Read kernel image from NAND*/ 21 spl export atags /* export ATAGS */ 22 nand erase 0x680000 0x20000 /* erase - one page */ 23 nand write 0x80000100 0x680000 0x20000 /* write the image - one page */ 24 25 call with FDT: 26 nandecc hw 27 nand read 0x82000000 0x280000 0x400000 /* Read kernel image from NAND*/ 28 tftpboot 0x80000100 devkit8000.dtb /* Read fdt */ 29 spl export fdt 0x82000000 - 0x80000100 /* export FDT */ 30 nand erase 0x680000 0x20000 /* erase - one page */ 31 nand write <adress shown by spl export> 0x680000 0x20000 32
README.console
1 SPDX-License-Identifier: GPL-2.0+ 2 /* 3 * (C) Copyright 2000 4 * Paolo Scaffardi, AIRVENT SAM s.p.a - RIMINI(ITALY), arsenio (a] tin.it 5 */ 6 7 U-Boot console handling 8 ======================== 9 10 HOW THE CONSOLE WORKS? 11 ---------------------- 12 13 At system startup U-Boot initializes a serial console. When U-Boot 14 relocates itself to RAM, all console drivers are initialized (they 15 will register all detected console devices to the system for further 16 use). 17 18 If not defined in the environment, the first input device is assigned 19 to the 'stdin' file, the first output one to 'stdout' and 'stderr'. 20 21 You can use the command "coninfo" to see all registered console 22 devices and their flags. You can assign a standard file (stdin, 23 stdout or stderr) to any device you see in that list simply by 24 assigning its name to the corresponding environment variable. For 25 example: 26 27 setenv stdin serial <- To use the serial input 28 setenv stdout video <- To use the video console 29 30 Do a simple "saveenv" to save the console settings in the environment 31 and get them working on the next startup, too. 32 33 HOW CAN I USE STANDARD FILE INTO THE SOURCES? 34 --------------------------------------------- 35 36 You can use the following functions to access the console: 37 38 * STDOUT: 39 putc (to put a char to stdout) 40 puts (to put a string to stdout) 41 printf (to format and put a string to stdout) 42 43 * STDIN: 44 tstc (to test for the presence of a char in stdin) 45 getc (to get a char from stdin) 46 47 * STDERR: 48 eputc (to put a char to stderr) 49 eputs (to put a string to stderr) 50 eprintf (to format and put a string to stderr) 51 52 * FILE (can be 'stdin', 'stdout', 'stderr'): 53 fputc (like putc but redirected to a file) 54 fputs (like puts but redirected to a file) 55 fprintf (like printf but redirected to a file) 56 ftstc (like tstc but redirected to a file) 57 fgetc (like getc but redirected to a file) 58 59 Remember that all FILE-related functions CANNOT be used before 60 U-Boot relocation (done in 'board_init_r' in arch/*/lib/board.c). 61 62 HOW CAN I USE STANDARD FILE INTO APPLICATIONS? 63 ---------------------------------------------- 64 65 Use the 'bd_mon_fnc' field of the bd_t structure passed to the 66 application to do everything you want with the console. 67 68 But REMEMBER that that will work only if you have not overwritten any 69 U-Boot code while loading (or uncompressing) the image of your 70 application. 71 72 For example, you won't get the console stuff running in the Linux 73 kernel because the kernel overwrites U-Boot before running. Only 74 some parameters like the framebuffer descriptors are passed to the 75 kernel in the high memory area to let the applications (the kernel) 76 use the framebuffers initialized by U-Boot. 77 78 SUPPORTED DRIVERS 79 ----------------- 80 81 Working drivers: 82 83 serial (architecture dependent serial stuff) 84 video (mpc8xx video controller) 85 86 Work in progress: 87 88 wl_kbd (Wireless 4PPM keyboard) 89 90 Waiting for volounteers: 91 92 lcd (mpc8xx lcd controller; to ) 93 94 TESTED CONFIGURATIONS 95 --------------------- 96 97 The driver has been tested with the following configurations (see 98 CREDITS for other contact informations): 99 100 - MPC823FADS with AD7176 on a PAL TV (YCbYCr) - arsenio (a] tin.it 101
README.davinci
1 Summary 2 ======= 3 4 This README is about U-Boot support for TI's ARM 926EJS based family of SoCs. 5 These SOCs are used for cameras, video security and surveillance, DVR's, etc. 6 DaVinci SOC's comprise of DM644x, DM646x, DM35x and DM36x series of SOC's 7 Additionally there are some SOCs meant for the audio market which though have 8 an OMAP part number are very similar to the DaVinci series of SOC's 9 Additionally, some family members contain a TI DSP and/or graphics 10 co processors along with a host of other peripherals. 11 12 Currently the following boards are supported: 13 14 * TI DaVinci DM644x EVM 15 16 * TI DaVinci DM646x EVM 17 18 * TI DaVinci DM355 EVM 19 20 * TI DaVinci DM365 EVM 21 22 * TI DA830 EVM 23 24 * TI DA850 EVM 25 26 * DM355 based Leopard board 27 28 * DM644x based schmoogie board 29 30 * DM644x based sffsdr board 31 32 * DM644x based sonata board 33 34 Build 35 ===== 36 37 * TI DaVinci DM644x EVM: 38 39 make davinci_dvevm_config 40 make 41 42 * TI DaVinci DM646x EVM: 43 44 make davinci_dm6467evm_config 45 make 46 47 * TI DaVinci DM355 EVM: 48 49 make davinci_dm355evm_config 50 make 51 52 * TI DaVinci DM365 EVM: 53 54 make davinci_dm365evm_config 55 make 56 57 * TI DA830 EVM: 58 59 make da830evm_config 60 make 61 62 * TI DA850 EVM: 63 64 make da850evm_config 65 make 66 67 * DM355 based Leopard board: 68 69 make davinci_dm355leopard_config 70 make 71 72 * DM644x based schmoogie board: 73 74 make davinci_schmoogie_config 75 make 76 77 * DM644x based sffsdr board: 78 79 make davinci_sffsdr_config 80 make 81 82 * DM644x based sonata board: 83 84 make davinci_sonata_config 85 make 86 87 Bootloaders 88 =============== 89 90 The DaVinci SOC's use 2 bootloaders. The low level initialization 91 is done by a UBL(user boot loader). The UBL is written to a NAND/NOR/SPI flash 92 by a programmer. During initial bootup, the ROM Bootloader reads the UBL 93 from a storage device and loads it into the IRAM. The UBL then loads the U-Boot 94 into the RAM. 95 The programmers and UBL are always released as part of any standard TI 96 software release associated with an SOC. 97 98 Alternative boot method (DA850 EVM only): 99 For the DA850 EVM an SPL (secondary program loader, see doc/README.SPL) 100 is provided to load U-Boot directly from SPI flash. In this case, the 101 SPL does the low level initialization that is otherwise done by the SPL. 102 To build U-Boot with this SPL, do 103 make da850evm_config 104 make u-boot.ais 105 and program the resulting u-boot.ais file to the SPI flash of the DA850 EVM. 106 107 Environment Variables 108 ===================== 109 110 The DA850 EVM allows the user to specify the maximum cpu clock allowed by the 111 silicon, in Hz, via an environment variable "maxcpuclk". 112 113 The maximum clock rate allowed depends on the silicon populated on the EVM. 114 Please make sure you understand the restrictions placed on this clock in the 115 device specific datasheet before setting up this variable. This information is 116 passed to the Linux kernel using the ATAG_REVISION atag. 117 118 If "maxcpuclk" is not defined, the configuration CONFIG_DA850_EVM_MAX_CPU_CLK 119 is used to obtain this information. 120 121 Links 122 ===== 123 124 1) TI DaVinci DM355 EVM: 125 http://focus.ti.com/docs/prod/folders/print/tms320dm355.html 126 http://www.spectrumdigital.com/product_info.php?cPath=103&products_id=203&osCsid=c499af6087317f11b3da19b4e8f1af32 127 128 2) TI DaVinci DM365 EVM: 129 http://focus.ti.com/docs/prod/folders/print/tms320dm365.html?247SEM= 130 http://support.spectrumdigital.com/boards/evmdm365/revc/ 131 132 3) DaVinci DM355 based leopard board 133 http://designsomething.org/leopardboard/default.aspx 134 http://www.spectrumdigital.com/product_info.php?cPath=103&products_id=192&osCsid=67c20335668ffc57cb35727106eb24b1 135 136 4) TI DaVinci DM6467 EVM: 137 http://focus.ti.com/docs/prod/folders/print/tms320dm6467.html 138 http://support.spectrumdigital.com/boards/evmdm6467/revf/ 139 140 5) TI DaVinci DM6446 EVM: 141 http://focus.ti.com/docs/prod/folders/print/tms320dm6446.html 142 http://www.spectrumdigital.com/product_info.php?cPath=103&products_id=222 143 144 6) TI DA830 EVM 145 http://focus.ti.com/apps/docs/gencontent.tsp?appId=1&contentId=52385 146 http://www.spectrumdigital.com/product_info.php?cPath=37&products_id=214 147 148 7) TI DA850 EVM 149 http://focus.ti.com/docs/prod/folders/print/omap-l138.html 150 http://www.logicpd.com/products/development-kits/zoom-omap-l138-evm-development-kit 151 152 Davinci special defines 153 ======================= 154 155 CONFIG_SYS_DV_NOR_BOOT_CFG: AM18xx based boards, booting in NOR Boot mode 156 need a "NOR Boot Configuration Word" stored 157 in the NOR Flash. This define adds this. 158 More Info about this, see: 159 spraba5a.pdf chapter 3.1 160
README.davinci.nand_spl
1 With this approach, we don't need the UBL any more on DaVinci boards. 2 A "make boardname" will compile a u-boot.ubl, with UBL Header, which is 3 needed for the RBL to find the "UBL", which actually is a UBL-compatible 4 header, nand spl code and u-boot code. 5 6 7 As the RBL uses another read function as the "standard" u-boot, 8 we need a command, which switches between this two read/write 9 functions, so we can write the UBL header and the spl 10 code in a format, which the RBL can read. This is realize 11 (at the moment in board specific code) in the u-boot command 12 nandrbl 13 14 nandrbl without arguments returns actual mode (rbl or uboot). 15 with nandrbl mode (mode = "rbl" or "uboot") you can switch 16 between the two NAND read/write modes. 17 18 19 To set up mkimage you need a config file for mkimage, example: 20 board/ait/cam_enc_4xx/ublimage.cfg 21 22 For information about the configuration please see: 23 doc/README.ublimage 24 25 Example for the cam_enc_4xx board: 26 On the cam_enc_4xx board we have a NAND flash with blocksize = 0x20000 and 27 pagesize = 0x800, so the u-boot.ubl image (which you get with: 28 "make cam_enc_4xx") looks like this: 29 30 00000000 00 ed ac a1 20 00 00 00 06 00 00 00 05 00 00 00 |.... ...........| 31 00000010 00 00 00 00 20 00 00 00 ff ff ff ff ff ff ff ff |.... ...........| 32 00000020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| 33 * 34 00000800 14 00 00 ea 14 f0 9f e5 10 f0 9f e5 0c f0 9f e5 |................| 35 00000810 08 f0 9f e5 04 f0 9f e5 00 f0 9f e5 04 f0 1f e5 |................| 36 00000820 00 01 00 00 78 56 34 12 78 56 34 12 78 56 34 12 |....xV4.xV4.xV4.| 37 [...] 38 * 39 00001fe0 00 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff |................| 40 00001ff0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| 41 * 42 00003800 14 00 00 ea 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 |................| 43 00003810 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 |................| 44 00003820 80 01 08 81 e0 01 08 81 40 02 08 81 a0 02 08 81 |........ (a] .......| 45 46 In the first "page" of the image, we have the UBL Header, needed for 47 the RBL to find the spl code. 48 49 The spl code starts in the second "page" of the image, with a size 50 defined by: 51 52 #define CONFIG_SYS_NROF_PAGES_NAND_SPL 6 53 54 After the spl code, there comes the "real" u-boot code 55 @ (6 + 1) * pagesize = 0x3800 56 57 ------------------------------------------------------------------------ 58 Setting up spl code: 59 60 /* 61 * RBL searches from Block n (n = 1..24) 62 * so we can define, how many UBL Headers 63 * we write before the real spl code 64 */ 65 #define CONFIG_SYS_NROF_UBL_HEADER 5 66 #define CONFIG_SYS_NROF_PAGES_NAND_SPL 6 67 68 #define CONFIG_SYS_NAND_U_BOOT_OFFS ((CONFIG_SYS_NROF_UBL_HEADER * \ 69 CONFIG_SYS_NAND_BLOCK_SIZE) + \ 70 (CONFIG_SYS_NROF_PAGES_NAND_SPL) * \ 71 CONFIG_SYS_NAND_PAGE_SIZE) 72 ------------------------------------------------------------------------ 73 74 Burning into NAND: 75 76 step 1: 77 The RBL searches from Block n ( n = 1..24) on page 0 for valid UBL 78 Headers, so you have to burn the UBL header page from the u-boot.ubl 79 image to the blocks, you want to have the UBL header. 80 !! Don;t forget to switch to rbl nand read/write functions with 81 "nandrbl rbl" 82 83 step 2: 84 You need to setup in the ublimage.cfg, where the RBL can find the spl 85 code, and how big it is. 86 87 !! RBL always starts reading from page 0 !! 88 89 For the AIT board, we have: 90 PAGES 6 91 START_BLOCK 5 92 93 So we need to copy the spl code to block 5 page 0 94 !! Don;t forget to switch to rbl nand read/write functions with 95 "nandrbl rbl" 96 97 step 3: 98 You need to copy the u-boot image to the block/page 99 where the spl code reads it (CONFIG_SYS_NAND_U_BOOT_OFFS) 100 !! Don;t forget to switch to rbl nand read/write functions with 101 "nandrbl uboot", which is default. 102 103 On the cam_enc_4xx board it is: 104 #define CONFIG_SYS_NAND_U_BOOT_OFFS (0xc0000) 105 106 -> this results in following NAND usage on the cam_enc_4xx board: 107 108 addr 109 110 20000 possible UBL Header 111 40000 possible UBL Header 112 60000 possible UBL Header 113 80000 possilbe UBL Header 114 a0000 spl code 115 c0000 u-boot code 116 117 The above steps are executeed through the following environment vars: 118 (using 80000 as address for the UBL header) 119 120 pagesz=800 121 uboot=/tftpboot/cam_enc_4xx/u-boot.ubl 122 load=tftp 80000000 ${uboot} 123 writeheader nandrbl rbl;nand erase 80000 ${pagesz};nand write 80000000 80000 ${pagesz};nandrbl uboot 124 writenand_spl nandrbl rbl;nand erase a0000 3000;nand write 80000800 a0000 3000;nandrbl uboot 125 writeuboot nandrbl uboot;nand erase c0000 5d000;nand write 80003800 c0000 5d000 126 update=run load writeheader writenand_spl writeuboot 127 128 If you do a "run load update" u-boot, spl + ubl header 129 are magically updated ;-) 130 131 Note: 132 - There seem to be a bug in the RBL code (at least on my HW), 133 In the UBL block, I can set the page to values != 0, so it 134 is possible to burn step 1 and step 2 in one step into the 135 flash, but the RBL ignores the page settings, so I have to 136 burn the UBL Header to a page 0 and the spl code to 137 a page 0 ... :-( 138 - If we make the nand read/write functions in the RBL equal to 139 the functions in u-boot (as I have no RBL code, it is only 140 possible in u-boot), we could burn the complete image in 141 one step ... that would be nice ... 142
README.dfutftp
1 # SPDX-License-Identifier: GPL-2.0+ 2 # 3 # Copyright (C) 2015 4 # 5 # Lukasz Majewski <l.majewski (a] majess.pl> 6 7 Device Firmware Upgrade (DFU) - extension to use TFTP 8 ===================================================== 9 10 Why? 11 ---- 12 13 * Update TFTP (CONFIG_UPDATE_TFTP) only supports writing 14 code to NAND memory via TFTP. 15 * DFU supports writing data to the variety of mediums (NAND, 16 eMMC, SD, partitions, RAM, etc) via USB. 17 18 Combination of both solves their shortcomings! 19 20 21 Overview 22 -------- 23 24 This document briefly describes how to use DFU for 25 upgrading firmware (e.g. kernel, u-boot, rootfs, etc.) 26 via TFTP protocol. 27 28 By using Ethernet (TFTP protocol to be precise) it is 29 possible to overcome the major problem of USB based DFU - 30 the relatively low transfer speed for large files. 31 This was caused by DFU standard, which imposed utilization 32 of only EP0 for transfer. By using Ethernet we can circumvent 33 this shortcoming. 34 35 Beagle Bone Black rev. C (BBB) powered by TI's am335x CPU has 36 been used as a demo board. 37 38 To utilize this feature, one needs to first enable support 39 for USB based DFU (CONFIG_DFU_*) and DFU TFTP update 40 (CONFIG_DFU_TFTP) described in ./doc/README.update. 41 42 The "dfu" command has been extended to support transfer via TFTP - one 43 needs to type for example "dfu tftp 0 mmc 0" 44 45 This feature does not depend on "fitupd" command enabled. 46 47 As of this writing (SHA1:8d77576371381ade83de475bb639949b44941e8c v2015.10-rc2) 48 the update.c code is not enabled (CONFIG_UPDATE_TFTP) by any board in the 49 contemporary u-boot tree. 50 51 52 Environment variables 53 --------------------- 54 55 The "dfu tftp" command can be used in the "preboot" environment variable 56 (when it is enabled by defining CONFIG_PREBOOT). 57 This is the preferable way of using this command in the early boot stage 58 as opposed to legacy update_tftp() function invocation. 59 60 61 Beagle Bone Black (BBB) setup 62 ----------------------------- 63 64 1. Setup tftp env variables: 65 * select desired eth device - 'ethact' variable ["ethact=cpsw"] 66 (use "bdinfo" to check current setting) 67 * setup "serverip" and "ipaddr" variables 68 * set "loadaddr" as a fixed buffer where incoming data is placed 69 ["loadaddr=0x81000000"] 70 71 ######### 72 # BONUS # 73 ######### 74 It is possible to use USB interface to emulate ETH connection by setting 75 "ethact=usb_ether". In this way one can have very fast DFU transfer via USB. 76 77 For 33MiB test image the transfer rate was 1MiB/s for ETH over USB and 200KiB/s 78 for pure DFU USB transfer. 79 80 2. Setup update_tftp variables: 81 * set "updatefile" - the file name to be downloaded via TFTP (stored on 82 the HOST at e.g. /srv/tftp) 83 84 3. If required, to update firmware on boot, put the "dfu tftp 0 mmc 0" in the 85 "preboot" env variable. Otherwise use this command from u-boot prompt. 86 87 4. Inspect "dfu" specific variables: 88 * "dfu_alt_info" - information about available DFU entities 89 * "dfu_bufsiz" - variable to set buffer size [in bytes] - when it is not 90 possible to set large enough default buffer (8 MiB @ BBB) 91 92 93 94 FIT image format for download 95 ----------------------------- 96 97 To create FIT image for download one should follow the update tftp README file 98 (./doc/README.update) with one notable difference: 99 100 The original snippet of ./doc/uImage.FIT/update_uboot.its 101 102 images { 103 update@1 { 104 description = "U-Boot binary"; 105 106 should look like 107 108 images { 109 u-boot.bin@1 { 110 description = "U-Boot binary"; 111 112 where "u-boot.bin" is the DFU entity name to be stored. 113 114 115 116 To do 117 ----- 118 119 * Extend dfu-util command to support TFTP based transfers 120 * Upload support (via TFTP) 121
README.displaying-bmps
1 If you are experiencing hangups/data-aborts when trying to display a BMP image, 2 the following might be relevant to your situation... 3 4 Some architectures cannot handle unaligned memory accesses, and an attempt to 5 perform one will lead to a data abort. On such architectures it is necessary to 6 make sure all data is properly aligned, and in many situations simply choosing 7 a 32 bit aligned address is enough to ensure proper alignment. This is not 8 always the case when dealing with data that has an internal layout such as a 9 BMP image: 10 11 BMP images have a header that starts with 2 byte-size fields followed by mostly 12 32 bit fields. The packed struct that represents this header can be seen below: 13 14 typedef struct bmp_header { 15 /* Header */ 16 char signature[2]; 17 __u32 file_size; 18 __u32 reserved; 19 __u32 data_offset; 20 ... etc 21 } __attribute__ ((packed)) bmp_header_t; 22 23 When placed in an aligned address such as 0x80a00000, char signature offsets 24 the __u32 fields into unaligned addresses (in our example 0x80a00002, 25 0x80a00006, and so on...). When these fields are accessed by U-Boot, a 32 bit 26 access is generated at a non-32-bit-aligned address, causing a data abort. 27 The proper alignment for BMP images is therefore: 32-bit-aligned-address + 2. 28
README.distro
1 SPDX-License-Identifier: GPL-2.0+ 2 /* 3 * (C) Copyright 2014 Red Hat Inc. 4 * Copyright (c) 2014-2015, NVIDIA CORPORATION. All rights reserved. 5 * Copyright (C) 2015 K. Merker <merker (a] debian.org> 6 */ 7 8 Generic Distro Configuration Concept 9 ==================================== 10 11 Linux distributions are faced with supporting a variety of boot mechanisms, 12 environments or bootloaders (PC BIOS, EFI, U-Boot, Barebox, ...). This makes 13 life complicated. Worse, bootloaders such as U-Boot have a configurable set 14 of features, and each board chooses to enable a different set of features. 15 Hence, distros typically need to have board-specific knowledge in order to 16 set up a bootable system. 17 18 This document defines a common set of U-Boot features that are required for 19 a distro to support the board in a generic fashion. Any board wishing to 20 allow distros to install and boot in an out-of-the-box fashion should enable 21 all these features. Linux distros can then create a single set of boot 22 support/install logic that targets these features. This will allow distros 23 to install on many boards without the need for board-specific logic. 24 25 In fact, some of these features can be implemented by any bootloader, thus 26 decoupling distro install/boot logic from any knowledge of the bootloader. 27 28 This model assumes that boards will load boot configuration files from a 29 regular storage mechanism (eMMC, SD card, USB Disk, SATA disk, etc.) with 30 a standard partitioning scheme (MBR, GPT). Boards that cannot support this 31 storage model are outside the scope of this document, and may still need 32 board-specific installer/boot-configuration support in a distro. 33 34 To some extent, this model assumes that a board has a separate boot flash 35 that contains U-Boot, and that the user has somehow installed U-Boot to this 36 flash before running the distro installer. Even on boards that do not conform 37 to this aspect of the model, the extent of the board-specific support in the 38 distro installer logic would be to install a board-specific U-Boot package to 39 the boot partition during installation. This distro-supplied U-Boot can still 40 implement the same features as on any other board, and hence the distro's boot 41 configuration file generation logic can still be board-agnostic. 42 43 Locating Bootable Disks 44 ----------------------- 45 46 Typical desktop/server PCs search all (or a user-defined subset of) attached 47 storage devices for a bootable partition, then load the bootloader or boot 48 configuration files from there. A U-Boot board port that enables the features 49 mentioned in this document will search for boot configuration files in the 50 same way. 51 52 Thus, distros do not need to manipulate any kind of bootloader-specific 53 configuration data to indicate which storage device the system should boot 54 from. 55 56 Distros simply need to install the boot configuration files (see next 57 section) in an ext2/3/4 or FAT partition, mark the partition bootable (via 58 the MBR bootable flag, or GPT legacy_bios_bootable attribute), and U-Boot (or 59 any other bootloader) will find those boot files and execute them. This is 60 conceptually identical to creating a grub2 configuration file on a desktop 61 PC. 62 63 Note that in the absence of any partition that is explicitly marked bootable, 64 U-Boot falls back to searching the first valid partition of a disk for boot 65 configuration files. Other bootloaders are recommended to do the same, since 66 I believe that partition table bootable flags aren't so commonly used outside 67 the realm of x86 PCs. 68 69 U-Boot can also search for boot configuration files from a TFTP server. 70 71 Boot Configuration Files 72 ------------------------ 73 74 The standard format for boot configuration files is that of extlinux.conf, as 75 handled by U-Boot's "syslinux" (disk) or "pxe boot" (network). This is roughly 76 as specified at: 77 78 http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ 79 80 ... with the exceptions that the BootLoaderSpec document: 81 82 * Prescribes a separate configuration per boot menu option, whereas U-Boot 83 lumps all options into a single extlinux.conf file. Hence, U-Boot searches 84 for /extlinux/extlinux.conf then /boot/extlinux/extlinux.conf on disk, or 85 pxelinux.cfg/default over the network. 86 87 * Does not document the fdtdir option, which automatically selects the DTB to 88 pass to the kernel. 89 90 One example extlinux.conf generated by the Fedora installer is: 91 92 ------------------------------------------------------------ 93 # extlinux.conf generated by anaconda 94 95 ui menu.c32 96 97 menu autoboot Welcome to Fedora. Automatic boot in # second{,s}. Press a key for options. 98 menu title Fedora Boot Options. 99 menu hidden 100 101 timeout 50 102 #totaltimeout 9000 103 104 default Fedora (3.17.0-0.rc4.git2.1.fc22.armv7hl+lpae) 22 (Rawhide) 105 106 label Fedora (3.17.0-0.rc4.git2.1.fc22.armv7hl) 22 (Rawhide) 107 kernel /boot/vmlinuz-3.17.0-0.rc4.git2.1.fc22.armv7hl 108 append ro root=UUID=8eac677f-8ea8-4270-8479-d5ddbb797450 console=ttyS0,115200n8 LANG=en_US.UTF-8 drm.debug=0xf 109 fdtdir /boot/dtb-3.17.0-0.rc4.git2.1.fc22.armv7hl 110 initrd /boot/initramfs-3.17.0-0.rc4.git2.1.fc22.armv7hl.img 111 112 label Fedora (3.17.0-0.rc4.git2.1.fc22.armv7hl+lpae) 22 (Rawhide) 113 kernel /boot/vmlinuz-3.17.0-0.rc4.git2.1.fc22.armv7hl+lpae 114 append ro root=UUID=8eac677f-8ea8-4270-8479-d5ddbb797450 console=ttyS0,115200n8 LANG=en_US.UTF-8 drm.debug=0xf 115 fdtdir /boot/dtb-3.17.0-0.rc4.git2.1.fc22.armv7hl+lpae 116 initrd /boot/initramfs-3.17.0-0.rc4.git2.1.fc22.armv7hl+lpae.img 117 118 label Fedora-0-rescue-8f6ba7b039524e0eb957d2c9203f04bc (0-rescue-8f6ba7b039524e0eb957d2c9203f04bc) 119 kernel /boot/vmlinuz-0-rescue-8f6ba7b039524e0eb957d2c9203f04bc 120 initrd /boot/initramfs-0-rescue-8f6ba7b039524e0eb957d2c9203f04bc.img 121 append ro root=UUID=8eac677f-8ea8-4270-8479-d5ddbb797450 console=ttyS0,115200n8 122 fdtdir /boot/dtb-3.16.0-0.rc6.git1.1.fc22.armv7hl+lpae 123 ------------------------------------------------------------ 124 125 Another hand-crafted network boot configuration file is: 126 127 ------------------------------------------------------------ 128 TIMEOUT 100 129 130 MENU TITLE TFTP boot options 131 132 LABEL jetson-tk1-emmc 133 MENU LABEL ../zImage root on Jetson TK1 eMMC 134 LINUX ../zImage 135 FDTDIR ../ 136 APPEND console=ttyS0,115200n8 console=tty1 loglevel=8 rootwait rw earlyprintk root=PARTUUID=80a5a8e9-c744-491a-93c1-4f4194fd690b 137 138 LABEL venice2-emmc 139 MENU LABEL ../zImage root on Venice2 eMMC 140 LINUX ../zImage 141 FDTDIR ../ 142 APPEND console=ttyS0,115200n8 console=tty1 loglevel=8 rootwait rw earlyprintk root=PARTUUID=5f71e06f-be08-48ed-b1ef-ee4800cc860f 143 144 LABEL sdcard 145 MENU LABEL ../zImage, root on 2GB sdcard 146 LINUX ../zImage 147 FDTDIR ../ 148 APPEND console=ttyS0,115200n8 console=tty1 loglevel=8 rootwait rw earlyprintk root=PARTUUID=b2f82cda-2535-4779-b467-094a210fbae7 149 150 LABEL fedora-installer-fk 151 MENU LABEL Fedora installer w/ Fedora kernel 152 LINUX fedora-installer/vmlinuz 153 INITRD fedora-installer/initrd.img.orig 154 FDTDIR fedora-installer/dtb 155 APPEND loglevel=8 ip=dhcp inst.repo=http://10.0.0.2/mirrors/fedora/linux/development/rawhide/armhfp/os/ rd.shell cma=64M 156 ------------------------------------------------------------ 157 158 U-Boot Implementation 159 ===================== 160 161 Enabling the distro options 162 --------------------------- 163 164 In your board's defconfig, enable the DISTRO_DEFAULTS option by adding 165 a line with "CONFIG_DISTRO_DEFAULTS=y". If you want to enable this 166 from Kconfig itself, for e.g. all boards using a specific SoC then 167 add a "imply DISTRO_DEFAULTS" to your SoC CONFIG option. 168 169 In your board configuration file, include the following: 170 171 ------------------------------------------------------------ 172 #ifndef CONFIG_SPL_BUILD 173 #include <config_distro_bootcmd.h> 174 #endif 175 ------------------------------------------------------------ 176 177 The first of those headers primarily enables a core set of U-Boot features, 178 such as support for MBR and GPT partitions, ext* and FAT filesystems, booting 179 raw zImage and initrd (rather than FIT- or uImage-wrapped files), etc. Network 180 boot support is also enabled here, which is useful in order to boot distro 181 installers given that distros do not commonly distribute bootable install 182 media for non-PC targets at present. 183 184 Finally, a few options that are mostly relevant only when using U-Boot- 185 specific boot.scr scripts are enabled. This enables distros to generate a 186 U-Boot-specific boot.scr script rather than extlinux.conf as the boot 187 configuration file. While doing so is fully supported, and 188 CONFIG_DISTRO_DEFAULTS exposes enough parameterization to boot.scr to 189 allow for board-agnostic boot.scr content, this document recommends that 190 distros generate extlinux.conf rather than boot.scr. extlinux.conf is intended 191 to work across multiple bootloaders, whereas boot.scr will only work with 192 U-Boot. TODO: document the contract between U-Boot and boot.scr re: which 193 environment variables a generic boot.scr may rely upon. 194 195 The second of those headers sets up the default environment so that $bootcmd 196 is defined in a way that searches attached disks for boot configuration files, 197 and executes them if found. 198 199 Required Environment Variables 200 ------------------------------ 201 202 The U-Boot "syslinux" and "pxe boot" commands require a number of environment 203 variables be set. Default values for these variables are often hard-coded into 204 CONFIG_EXTRA_ENV_SETTINGS in the board's U-Boot configuration file, so that 205 the user doesn't have to configure them. 206 207 fdt_addr: 208 209 Mandatory for any system that provides the DTB in HW (e.g. ROM) and wishes 210 to pass that DTB to Linux, rather than loading a DTB from the boot 211 filesystem. Prohibited for any other system. 212 213 If specified a DTB to boot the system must be available at the given 214 address. 215 216 fdt_addr_r: 217 218 Mandatory. The location in RAM where the DTB will be loaded or copied to when 219 processing the fdtdir/devicetreedir or fdt/devicetree options in 220 extlinux.conf. 221 222 This is mandatory even when fdt_addr is provided, since extlinux.conf must 223 always be able to provide a DTB which overrides any copy provided by the HW. 224 225 A size of 1MB for the FDT/DTB seems reasonable. 226 227 ramdisk_addr_r: 228 229 Mandatory. The location in RAM where the initial ramdisk will be loaded to 230 when processing the initrd option in extlinux.conf. 231 232 It is recommended that this location be highest in RAM out of fdt_addr_, 233 kernel_addr_r, and ramdisk_addr_r, so that the RAM disk can vary in size 234 and use any available RAM. 235 236 kernel_addr_r: 237 238 Mandatory. The location in RAM where the kernel will be loaded to when 239 processing the kernel option in the extlinux.conf. 240 241 The kernel should be located within the first 128M of RAM in order for the 242 kernel CONFIG_AUTO_ZRELADDR option to work, which is likely enabled on any 243 distro kernel. Since the kernel will decompress itself to 0x8000 after the 244 start of RAM, kernel_addr_r should not overlap that area, or the kernel will 245 have to copy itself somewhere else first before decompression. 246 247 A size of 16MB for the kernel is likely adequate. 248 249 pxefile_addr_r: 250 251 Mandatory. The location in RAM where extlinux.conf will be loaded to prior 252 to processing. 253 254 A size of 1MB for extlinux.conf is more than adequate. 255 256 scriptaddr: 257 258 Mandatory, if the boot script is boot.scr rather than extlinux.conf. The 259 location in RAM where boot.scr will be loaded to prior to execution. 260 261 A size of 1MB for extlinux.conf is more than adequate. 262 263 For suggestions on memory locations for ARM systems, you must follow the 264 guidelines specified in Documentation/arm/Booting in the Linux kernel tree. 265 266 For a commented example of setting these values, please see the definition of 267 MEM_LAYOUT_ENV_SETTINGS in include/configs/tegra124-common.h. 268 269 Boot Target Configuration 270 ------------------------- 271 272 <config_distro_bootcmd.h> defines $bootcmd and many helper command variables 273 that automatically search attached disks for boot configuration files and 274 execute them. Boards must provide configure <config_distro_bootcmd.h> so that 275 it supports the correct set of possible boot device types. To provide this 276 configuration, simply define macro BOOT_TARGET_DEVICES prior to including 277 <config_distro_bootcmd.h>. For example: 278 279 ------------------------------------------------------------ 280 #ifndef CONFIG_SPL_BUILD 281 #define BOOT_TARGET_DEVICES(func) \ 282 func(MMC, mmc, 1) \ 283 func(MMC, mmc, 0) \ 284 func(USB, usb, 0) \ 285 func(PXE, pxe, na) \ 286 func(DHCP, dhcp, na) 287 #include <config_distro_bootcmd.h> 288 #endif 289 ------------------------------------------------------------ 290 291 Each entry in the macro defines a single boot device (e.g. a specific eMMC 292 device or SD card) or type of boot device (e.g. USB disk). The parameters to 293 the func macro (passed in by the internal implementation of the header) are: 294 295 - Upper-case disk type (MMC, SATA, SCSI, IDE, USB, DHCP, PXE). 296 - Lower-case disk type (same options as above). 297 - ID of the specific disk (MMC only) or ignored for other types. 298 299 User Configuration 300 ================== 301 302 Once the user has installed U-Boot, it is expected that the environment will 303 be reset to the default values in order to enable $bootcmd and friends, as set 304 up by <config_distro_bootcmd.h>. After this, various environment variables may 305 be altered to influence the boot process: 306 307 boot_targets: 308 309 The list of boot locations searched. 310 311 Example: mmc0, mmc1, usb, pxe 312 313 Entries may be removed or re-ordered in this list to affect the boot order. 314 315 boot_prefixes: 316 317 For disk-based booting, the list of directories within a partition that are 318 searched for boot configuration files (extlinux.conf, boot.scr). 319 320 Example: / /boot/ 321 322 Entries may be removed or re-ordered in this list to affect the set of 323 directories which are searched. 324 325 boot_scripts: 326 327 The name of U-Boot style boot.scr files that $bootcmd searches for. 328 329 Example: boot.scr.uimg boot.scr 330 331 (Typically we expect extlinux.conf to be used, but execution of boot.scr is 332 maintained for backwards-compatibility.) 333 334 Entries may be removed or re-ordered in this list to affect the set of 335 filenames which are supported. 336 337 scan_dev_for_extlinux: 338 339 If you want to disable extlinux.conf on all disks, set the value to something 340 innocuous, e.g. setenv scan_dev_for_extlinux true. 341 342 scan_dev_for_scripts: 343 344 If you want to disable boot.scr on all disks, set the value to something 345 innocuous, e.g. setenv scan_dev_for_scripts true. 346 347 boot_net_usb_start: 348 349 If you want to prevent USB enumeration by distro boot commands which execute 350 network operations, set the value to something innocuous, e.g. setenv 351 boot_net_usb_start true. This would be useful if you know your Ethernet 352 device is not attached to USB, and you wish to increase boot speed by 353 avoiding unnecessary actions. 354 355 boot_net_pci_enum: 356 357 If you want to prevent PCI enumeration by distro boot commands which execute 358 network operations, set the value to something innocuous, e.g. setenv 359 boot_net_pci_enum true. This would be useful if you know your Ethernet 360 device is not attached to PCI, and you wish to increase boot speed by 361 avoiding unnecessary actions. 362 363 Interactively booting from a specific device at the u-boot prompt 364 ================================================================= 365 366 For interactively booting from a user-selected device at the u-boot command 367 prompt, the environment provides predefined bootcmd_<target> variables for 368 every target defined in boot_targets, which can be run be the user. 369 370 If the target is a storage device, the format of the target is always 371 <device type><device number>, e.g. mmc0. Specifying the device number is 372 mandatory for storage devices, even if only support for a single instance 373 of the storage device is actually implemented. 374 375 For network targets (dhcp, pxe), only the device type gets specified; 376 they do not have a device number. 377 378 Examples: 379 380 - run bootcmd_usb0 381 boots from the first USB mass storage device 382 383 - run bootcmd_mmc1 384 boots from the second MMC device 385 386 - run bootcmd_pxe 387 boots by tftp using a pxelinux.cfg 388 389 The list of possible targets consists of: 390 391 - network targets 392 * dhcp 393 * pxe 394 395 - storage targets (to which a device number must be appended) 396 * mmc 397 * sata 398 * scsi 399 * ide 400 * usb 401 402 Other *boot* variables than the ones defined above are only for internal use 403 of the boot environment and are not guaranteed to exist or work in the same 404 way in future u-boot versions. In particular the <device type>_boot 405 variables (e.g. mmc_boot, usb_boot) are a strictly internal implementation 406 detail and must not be used as a public interface. 407
README.dns
1 Domain Name System 2 ------------------------------------------- 3 4 The Domain Name System (DNS) is a hierarchical naming system for computers, 5 services, or any resource participating in the Internet. It associates various 6 information with domain names assigned to each of the participants. Most 7 importantly, it translates domain names meaningful to humans into the numerical 8 (binary) identifiers associated with networking equipment for the purpose of 9 locating and addressing these devices world-wide. An often used analogy to 10 explain the Domain Name System is that it serves as the "phone book" for the 11 Internet by translating human-friendly computer hostnames into IP addresses. 12 For example, www.example.com translates to 208.77.188.166. 13 14 For more information on DNS - http://en.wikipedia.org/wiki/Domain_Name_System 15 16 U-Boot and DNS 17 ------------------------------------------ 18 19 CONFIG_CMD_DNS - controls if the 'dns' command is compiled in. If it is, it 20 will send name lookups to the dns server (env var 'dnsip') 21 Turning this option on will about abou 1k to U-Boot's size. 22 23 Example: 24 25 bfin> print dnsip 26 dnsip=192.168.0.1 27 28 bfin> dns www.google.com 29 66.102.1.104 30 31 By default, dns does nothing except print the IP number on 32 the default console - which by itself, would be pretty 33 useless. Adding a third argument to the dns command will 34 use that as the environment variable to be set. 35 36 Example: 37 38 bfin> print googleip 39 ## Error: "googleip" not defined 40 bfin> dns www.google.com googleip 41 64.233.161.104 42 bfin> print googleip 43 googleip=64.233.161.104 44 bfin> ping ${googleip} 45 Using Blackfin EMAC device 46 host 64.233.161.104 is alive 47 48 In this way, you can lookup, and set many more meaningful 49 things. 50 51 bfin> sntp 52 ntpserverip not set 53 bfin> dns pool.ntp.org ntpserverip 54 72.18.205.156 55 bfin> sntp 56 Date: 2009-07-18 Time: 4:06:57 57 58 For some helpful things that can be related to DNS in U-Boot, 59 look at the top level README for these config options: 60 CONFIG_CMD_DHCP 61 CONFIG_BOOTP_DNS 62 CONFIG_BOOTP_DNS2 63
README.drivers.eth
1 !!! WARNING !!! 2 3 This guide describes to the old way of doing things. No new Ethernet drivers 4 should be implemented this way. All new drivers should be written against the 5 U-Boot core driver model. See doc/driver-model/README.txt 6 7 ----------------------- 8 Ethernet Driver Guide 9 ----------------------- 10 11 The networking stack in Das U-Boot is designed for multiple network devices 12 to be easily added and controlled at runtime. This guide is meant for people 13 who wish to review the net driver stack with an eye towards implementing your 14 own ethernet device driver. Here we will describe a new pseudo 'APE' driver. 15 16 ------------------ 17 Driver Functions 18 ------------------ 19 20 All functions you will be implementing in this document have the return value 21 meaning of 0 for success and non-zero for failure. 22 23 ---------- 24 Register 25 ---------- 26 27 When U-Boot initializes, it will call the common function eth_initialize(). 28 This will in turn call the board-specific board_eth_init() (or if that fails, 29 the cpu-specific cpu_eth_init()). These board-specific functions can do random 30 system handling, but ultimately they will call the driver-specific register 31 function which in turn takes care of initializing that particular instance. 32 33 Keep in mind that you should code the driver to avoid storing state in global 34 data as someone might want to hook up two of the same devices to one board. 35 Any such information that is specific to an interface should be stored in a 36 private, driver-defined data structure and pointed to by eth->priv (see below). 37 38 So the call graph at this stage would look something like: 39 board_init() 40 eth_initialize() 41 board_eth_init() / cpu_eth_init() 42 driver_register() 43 initialize eth_device 44 eth_register() 45 46 At this point in time, the only thing you need to worry about is the driver's 47 register function. The pseudo code would look something like: 48 int ape_register(bd_t *bis, int iobase) 49 { 50 struct ape_priv *priv; 51 struct eth_device *dev; 52 struct mii_dev *bus; 53 54 priv = malloc(sizeof(*priv)); 55 if (priv == NULL) 56 return -ENOMEM; 57 58 dev = malloc(sizeof(*dev)); 59 if (dev == NULL) { 60 free(priv); 61 return -ENOMEM; 62 } 63 64 /* setup whatever private state you need */ 65 66 memset(dev, 0, sizeof(*dev)); 67 sprintf(dev->name, "APE"); 68 69 /* 70 * if your device has dedicated hardware storage for the 71 * MAC, read it and initialize dev->enetaddr with it 72 */ 73 ape_mac_read(dev->enetaddr); 74 75 dev->iobase = iobase; 76 dev->priv = priv; 77 dev->init = ape_init; 78 dev->halt = ape_halt; 79 dev->send = ape_send; 80 dev->recv = ape_recv; 81 dev->write_hwaddr = ape_write_hwaddr; 82 83 eth_register(dev); 84 85 #ifdef CONFIG_PHYLIB 86 bus = mdio_alloc(); 87 if (!bus) { 88 free(priv); 89 free(dev); 90 return -ENOMEM; 91 } 92 93 bus->read = ape_mii_read; 94 bus->write = ape_mii_write; 95 mdio_register(bus); 96 #endif 97 98 return 1; 99 } 100 101 The exact arguments needed to initialize your device are up to you. If you 102 need to pass more/less arguments, that's fine. You should also add the 103 prototype for your new register function to include/netdev.h. 104 105 The return value for this function should be as follows: 106 < 0 - failure (hardware failure, not probe failure) 107 >=0 - number of interfaces detected 108 109 You might notice that many drivers seem to use xxx_initialize() rather than 110 xxx_register(). This is the old naming convention and should be avoided as it 111 causes confusion with the driver-specific init function. 112 113 Other than locating the MAC address in dedicated hardware storage, you should 114 not touch the hardware in anyway. That step is handled in the driver-specific 115 init function. Remember that we are only registering the device here, we are 116 not checking its state or doing random probing. 117 118 ----------- 119 Callbacks 120 ----------- 121 122 Now that we've registered with the ethernet layer, we can start getting some 123 real work done. You will need five functions: 124 int ape_init(struct eth_device *dev, bd_t *bis); 125 int ape_send(struct eth_device *dev, volatile void *packet, int length); 126 int ape_recv(struct eth_device *dev); 127 int ape_halt(struct eth_device *dev); 128 int ape_write_hwaddr(struct eth_device *dev); 129 130 The init function checks the hardware (probing/identifying) and gets it ready 131 for send/recv operations. You often do things here such as resetting the MAC 132 and/or PHY, and waiting for the link to autonegotiate. You should also take 133 the opportunity to program the device's MAC address with the dev->enetaddr 134 member. This allows the rest of U-Boot to dynamically change the MAC address 135 and have the new settings be respected. 136 137 The send function does what you think -- transmit the specified packet whose 138 size is specified by length (in bytes). You should not return until the 139 transmission is complete, and you should leave the state such that the send 140 function can be called multiple times in a row. 141 142 The recv function should process packets as long as the hardware has them 143 readily available before returning. i.e. you should drain the hardware fifo. 144 For each packet you receive, you should call the net_process_received_packet() function on it 145 along with the packet length. The common code sets up packet buffers for you 146 already in the .bss (net_rx_packets), so there should be no need to allocate your 147 own. This doesn't mean you must use the net_rx_packets array however; you're 148 free to call the net_process_received_packet() function with any buffer you wish. So the pseudo 149 code here would look something like: 150 int ape_recv(struct eth_device *dev) 151 { 152 int length, i = 0; 153 ... 154 while (packets_are_available()) { 155 ... 156 length = ape_get_packet(&net_rx_packets[i]); 157 ... 158 net_process_received_packet(&net_rx_packets[i], length); 159 ... 160 if (++i >= PKTBUFSRX) 161 i = 0; 162 ... 163 } 164 ... 165 return 0; 166 } 167 168 The halt function should turn off / disable the hardware and place it back in 169 its reset state. It can be called at any time (before any call to the related 170 init function), so make sure it can handle this sort of thing. 171 172 The write_hwaddr function should program the MAC address stored in dev->enetaddr 173 into the Ethernet controller. 174 175 So the call graph at this stage would look something like: 176 some net operation (ping / tftp / whatever...) 177 eth_init() 178 dev->init() 179 eth_send() 180 dev->send() 181 eth_rx() 182 dev->recv() 183 eth_halt() 184 dev->halt() 185 186 -------------------------------- 187 CONFIG_PHYLIB / CONFIG_CMD_MII 188 -------------------------------- 189 190 If your device supports banging arbitrary values on the MII bus (pretty much 191 every device does), you should add support for the mii command. Doing so is 192 fairly trivial and makes debugging mii issues a lot easier at runtime. 193 194 After you have called eth_register() in your driver's register function, add 195 a call to mdio_alloc() and mdio_register() like so: 196 bus = mdio_alloc(); 197 if (!bus) { 198 free(priv); 199 free(dev); 200 return -ENOMEM; 201 } 202 203 bus->read = ape_mii_read; 204 bus->write = ape_mii_write; 205 mdio_register(bus); 206 207 And then define the mii_read and mii_write functions if you haven't already. 208 Their syntax is straightforward: 209 int mii_read(struct mii_dev *bus, int addr, int devad, int reg); 210 int mii_write(struct mii_dev *bus, int addr, int devad, int reg, 211 u16 val); 212 213 The read function should read the register 'reg' from the phy at address 'addr' 214 and return the result to its caller. The implementation for the write function 215 should logically follow. 216
README.enetaddr
1 --------------------------------- 2 Ethernet Address (MAC) Handling 3 --------------------------------- 4 5 There are a variety of places in U-Boot where the MAC address is used, parsed, 6 and stored. This document covers proper usage of each location and the moving 7 of data between them. 8 9 ----------- 10 Locations 11 ----------- 12 13 Here are the places where MAC addresses might be stored: 14 15 - board-specific location (eeprom, dedicated flash, ...) 16 Note: only used when mandatory due to hardware design etc... 17 18 - environment ("ethaddr", "eth1addr", ...) 19 Note: this is the preferred way to permanently store MAC addresses 20 21 - ethernet data (struct eth_device -> enetaddr) 22 Note: these are temporary copies of the MAC address which exist only 23 after the respective init steps have run and only to make usage 24 in other places easier (to avoid constant env lookup/parsing) 25 26 - struct bd_info and/or device tree 27 Note: these are temporary copies of the MAC address only for the 28 purpose of passing this information to an OS kernel we are about 29 to boot 30 31 Correct flow of setting up the MAC address (summarized): 32 33 1. Read from hardware in initialize() function 34 2. Read from environment in net/eth.c after initialize() 35 3. The environment variable will be compared to the driver initialized 36 struct eth_device->enetaddr. If they differ, a warning is printed, and the 37 environment variable will be used unchanged. 38 If the environment variable is not set, it will be initialized from 39 eth_device->enetaddr, and a warning will be printed. 40 If both are invalid and CONFIG_NET_RANDOM_ETHADDR is defined, a random, 41 locally-assigned MAC is written to eth_device->enetaddr. 42 4. Program the address into hardware if the following conditions are met: 43 a) The relevant driver has a 'write_addr' function 44 b) The user hasn't set an 'ethmacskip' environment variable 45 c) The address is valid (unicast, not all-zeros) 46 47 Previous behavior had the MAC address always being programmed into hardware 48 in the device's init() function. 49 50 ------- 51 Usage 52 ------- 53 54 If the hardware design mandates that the MAC address is stored in some special 55 place (like EEPROM etc...), then the board specific init code (such as the 56 board-specific misc_init_r() function) is responsible for locating the MAC 57 address(es) and initializing the respective environment variable(s) from it. 58 Note that this shall be done if, and only if, the environment does not already 59 contain these environment variables, i.e. existing variable definitions must 60 not be overwritten. 61 62 During runtime, the ethernet layer will use the environment variables to sync 63 the MAC addresses to the ethernet structures. All ethernet driver code should 64 then only use the enetaddr member of the eth_device structure. This is done 65 on every network command, so the ethernet copies will stay in sync. 66 67 Any other code that wishes to access the MAC address should query the 68 environment directly. The helper functions documented below should make 69 working with this storage much smoother. 70 71 --------- 72 Helpers 73 --------- 74 75 To assist in the management of these layers, a few helper functions exist. You 76 should use these rather than attempt to do any kind of parsing/manipulation 77 yourself as many common errors have arisen in the past. 78 79 * void eth_parse_enetaddr(const char *addr, uchar *enetaddr); 80 81 Convert a string representation of a MAC address to the binary version. 82 char *addr = "00:11:22:33:44:55"; 83 uchar enetaddr[6]; 84 eth_parse_enetaddr(addr, enetaddr); 85 /* enetaddr now equals { 0x00, 0x11, 0x22, 0x33, 0x44, 0x55 } */ 86 87 * int eth_env_get_enetaddr(char *name, uchar *enetaddr); 88 89 Look up an environment variable and convert the stored address. If the address 90 is valid, then the function returns 1. Otherwise, the function returns 0. In 91 all cases, the enetaddr memory is initialized. If the env var is not found, 92 then it is set to all zeros. The common function is_valid_ethaddr() is used 93 to determine address validity. 94 uchar enetaddr[6]; 95 if (!eth_env_get_enetaddr("ethaddr", enetaddr)) { 96 /* "ethaddr" is not set in the environment */ 97 ... try and setup "ethaddr" in the env ... 98 } 99 /* enetaddr is now set to the value stored in the ethaddr env var */ 100 101 * int eth_env_set_enetaddr(char *name, const uchar *enetaddr); 102 103 Store the MAC address into the named environment variable. The return value is 104 the same as the env_set() function. 105 uchar enetaddr[6] = { 0x00, 0x11, 0x22, 0x33, 0x44, 0x55 }; 106 eth_env_set_enetaddr("ethaddr", enetaddr); 107 /* the "ethaddr" env var should now be set to "00:11:22:33:44:55" */ 108 109 * the %pM format modifier 110 111 The %pM format modifier can be used with any standard printf function to format 112 the binary 6 byte array representation of a MAC address. 113 uchar enetaddr[6] = { 0x00, 0x11, 0x22, 0x33, 0x44, 0x55 }; 114 printf("The MAC is %pM\n", enetaddr); 115 116 char buf[20]; 117 sprintf(buf, "%pM", enetaddr); 118 /* the buf variable is now set to "00:11:22:33:44:55" */ 119
README.esbc_validate
1 SPDX-License-Identifier: GPL-2.0+ 2 /* 3 * (C) Copyright 2015 4 */ 5 6 esbc_validate command 7 ======================================== 8 9 1. esbc_validate command is meant for validating header and 10 signature of images (Boot Script and ESBC uboot client). 11 SHA-256 and RSA operations are performed using SEC block in HW. 12 This command works on both PBL based and Non PBL based Freescale 13 platforms. 14 Command usage: 15 esbc_validate img_hdr_addr [pub_key_hash] 16 esbc_validate hdr_addr <hash_val> 17 Validates signature using RSA verification. 18 $hdr_addr Address of header of the image to be validated. 19 $hash_val -Optional. It provides Hash of public/srk key to be 20 used to verify signature. 21 22 2. ESBC uboot client can be linux. Additionally, rootfs and device 23 tree blob can also be signed. 24 3. In the event of header or signature failure in validation, 25 ITS and ITF bits determine further course of action. 26 4. In case of soft failure, appropriate error is dumped on console. 27 5. In case of hard failure, SoC is issued RESET REQUEST after 28 dumping error on the console. 29 6. KEY REVOCATION Feature: 30 QorIQ platforms like B4/T4 have support of srk key table and key 31 revocation in ISBC code in Silicon. 32 The srk key table allows the user to have a key table with multiple 33 keys and revoke any key in case of particular key gets compromised. 34 In case the ISBC code uses the key revocation and srk key table to 35 verify the u-boot code, the subsequent chain of trust should also 36 use the same. 37 6. ISBC KEY EXTENSION Feature: 38 This feature allows large number of keys to be used for esbc validation 39 of images. A set of public keys is being signed and validated by ISBC 40 which can be further used for esbc validation of images. 41
README.ext4
1 U-Boot supports access of both ext2 and ext4 filesystems, either in read-only 2 mode or in read-write mode. 3 4 First, to enable support for both ext4 (and, automatically, ext2 as well), 5 but without selecting the corresponding commands, enable one of the following: 6 7 CONFIG_FS_EXT4 (for read-only) 8 CONFIG_EXT4_WRITE (for read-write) 9 10 Next, to select the ext2-related commands: 11 12 * ext2ls 13 * ext2load 14 15 or ext4-related commands: 16 17 * ext4size 18 * ext4ls 19 * ext4load 20 21 use one or both of: 22 23 CONFIG_CMD_EXT2 24 CONFIG_CMD_EXT4 25 26 Selecting either of the above automatically selects CONFIG_FS_EXT4 if it 27 wasn't enabled already. 28 29 In addition, to get the write access command "ext4write", enable: 30 31 CONFIG_CMD_EXT4_WRITE 32 33 which automatically selects CONFIG_EXT4_WRITE if it wasn't defined 34 already. 35 36 Also relevant are the generic filesystem commands, selected by: 37 38 CONFIG_CMD_FS_GENERIC 39 40 This does not automatically enable EXT4 support for you, you still need 41 to do that yourself. 42 43 Some sample commands to test ext4 support: 44 45 1. Check that the commands can be seen in the output of U-Boot help: 46 47 UBOOT #help 48 ... 49 ext4load- load binary file from a Ext4 file system 50 ext4ls - list files in a directory (default /) 51 ext4size - determine a file's size 52 ext4write- create a file in ext4 formatted partition 53 ... 54 55 2. To list the files in an ext4-formatted partition, run: 56 57 ext4ls <interface> <dev[:part]> [directory] 58 59 For example: 60 UBOOT #ext4ls mmc 0:5 /usr/lib 61 62 3. To read and load a file from an ext4-formatted partition to RAM, run: 63 64 ext4load <interface> <dev[:part]> [addr] [filename] [bytes] 65 66 For example: 67 UBOOT #ext4load mmc 2:2 0x30007fc0 uImage 68 69 4. To write a file to an ext4-formatted partition. 70 71 a) First load a file to RAM at a particular address for example 0x30007fc0. 72 Now execute ext4write command: 73 ext4write <interface> <dev[:part]> [filename] [Address] [sizebytes] 74 75 For example: 76 UBOOT #ext4write mmc 2:2 /boot/uImage 0x30007fc0 6183120 77 (here 6183120 is the size of the file to be written) 78 Note: Absolute path is required for the file to be written 79 80 References : 81 -- ext4 implementation in Linux Kernel 82 -- Uboot existing ext2 load and ls implementation 83 -- Journaling block device JBD2 implementation in linux Kernel 84
README.falcon
1 U-Boot Falcon Mode 2 ==================== 3 4 Introduction 5 ------------ 6 7 This document provides an overview of how to add support for Falcon Mode 8 to a board. 9 10 Falcon Mode is introduced to speed up the booting process, allowing 11 to boot a Linux kernel (or whatever image) without a full blown U-Boot. 12 13 Falcon Mode relies on the SPL framework. In fact, to make booting faster, 14 U-Boot is split into two parts: the SPL (Secondary Program Loader) and U-Boot 15 image. In most implementations, SPL is used to start U-Boot when booting from 16 a mass storage, such as NAND or SD-Card. SPL has now support for other media, 17 and can generally be seen as a way to start an image performing the minimum 18 required initialization. SPL mainly initializes the RAM controller, and then 19 copies U-Boot image into the memory. 20 21 The Falcon Mode extends this way allowing to start the Linux kernel directly 22 from SPL. A new command is added to U-Boot to prepare the parameters that SPL 23 must pass to the kernel, using ATAGS or Device Tree. 24 25 In normal mode, these parameters are generated each time before 26 loading the kernel, passing to Linux the address in memory where 27 the parameters can be read. 28 With Falcon Mode, this snapshot can be saved into persistent storage and SPL is 29 informed to load it before running the kernel. 30 31 To boot the kernel, these steps under a Falcon-aware U-Boot are required: 32 33 1. Boot the board into U-Boot. 34 After loading the desired legacy-format kernel image into memory (and DT as 35 well, if used), use the "spl export" command to generate the kernel parameters 36 area or the DT. U-Boot runs as when it boots the kernel, but stops before 37 passing the control to the kernel. 38 39 2. Save the prepared snapshot into persistent media. 40 The address where to save it must be configured into board configuration 41 file (CONFIG_CMD_SPL_NAND_OFS for NAND). 42 43 3. Boot the board into Falcon Mode. SPL will load the kernel and copy 44 the parameters which are saved in the persistent area to the required address. 45 If a valid uImage is not found at the defined location, U-Boot will be 46 booted instead. 47 48 It is required to implement a custom mechanism to select if SPL loads U-Boot 49 or another image. 50 51 The value of a GPIO is a simple way to operate the selection, as well as 52 reading a character from the SPL console if CONFIG_SPL_CONSOLE is set. 53 54 Falcon Mode is generally activated by setting CONFIG_SPL_OS_BOOT. This tells 55 SPL that U-Boot is not the only available image that SPL is able to start. 56 57 Configuration 58 ---------------------------- 59 CONFIG_CMD_SPL Enable the "spl export" command. 60 The command "spl export" is then available in U-Boot 61 mode 62 CONFIG_SYS_SPL_ARGS_ADDR Address in RAM where the parameters must be 63 copied by SPL. 64 In most cases, it is <start_of_ram> + 0x100 65 66 CONFIG_SYS_NAND_SPL_KERNEL_OFFS Offset in NAND where the kernel is stored 67 68 CONFIG_CMD_SPL_NAND_OFS Offset in NAND where the parameters area was saved. 69 70 CONFIG_CMD_SPL_WRITE_SIZE Size of the parameters area to be copied 71 72 CONFIG_SPL_OS_BOOT Activate Falcon Mode. 73 74 Function that a board must implement 75 ------------------------------------ 76 77 void spl_board_prepare_for_linux(void) : optional 78 Called from SPL before starting the kernel 79 80 spl_start_uboot() : required 81 Returns "0" if SPL should start the kernel, "1" if U-Boot 82 must be started. 83 84 Environment variables 85 --------------------- 86 87 A board may chose to look at the environment for decisions about falcon 88 mode. In this case the following variables may be supported: 89 90 boot_os : Set to yes/Yes/true/True/1 to enable booting to OS, 91 any other value to fall back to U-Boot (including 92 unset) 93 falcon_args_file : Filename to load as the 'args' portion of falcon mode 94 rather than the hard-coded value. 95 falcon_image_file : Filename to load as the OS image portion of falcon 96 mode rather than the hard-coded value. 97 98 Using spl command 99 ----------------- 100 101 spl - SPL configuration 102 103 Usage: 104 105 spl export <img=atags|fdt> [kernel_addr] [initrd_addr] [fdt_addr ] 106 107 img : "atags" or "fdt" 108 kernel_addr : kernel is loaded as part of the boot process, but it is not started. 109 This is the address where a kernel image is stored. 110 initrd_addr : Address of initial ramdisk 111 can be set to "-" if fdt_addr without initrd_addr is used 112 fdt_addr : in case of fdt, the address of the device tree. 113 114 The spl export command does not write to a storage media. The user is 115 responsible to transfer the gathered information (assembled ATAGS list 116 or prepared FDT) from temporary storage in RAM into persistant storage 117 after each run of 'spl export'. Unfortunately the position of temporary 118 storage can not be predicted nor provided at commandline, it depends 119 highly on your system setup and your provided data (ATAGS or FDT). 120 However at the end of an succesful 'spl export' run it will print the 121 RAM address of temporary storage. The RAM address of FDT will also be 122 set in the environment variable 'fdtargsaddr', the new length of the 123 prepared FDT will be set in the environment variable 'fdtargslen'. 124 These environment variables can be used in scripts for writing updated 125 FDT to persistent storage. 126 127 Now the user have to save the generated BLOB from that printed address 128 to the pre-defined address in persistent storage 129 (CONFIG_CMD_SPL_NAND_OFS in case of NAND). 130 The following example shows how to prepare the data for Falcon Mode on 131 twister board with ATAGS BLOB. 132 133 The "spl export" command is prepared to work with ATAGS and FDT. However, 134 using FDT is at the moment untested. The ppc port (see a3m071 example 135 later) prepares the fdt blob with the fdt command instead. 136 137 138 Usage on the twister board: 139 -------------------------------- 140 141 Using mtd names with the following (default) configuration 142 for mtdparts: 143 144 device nand0 <omap2-nand.0>, # parts = 9 145 #: name size offset mask_flags 146 0: MLO 0x00080000 0x00000000 0 147 1: u-boot 0x00100000 0x00080000 0 148 2: env1 0x00040000 0x00180000 0 149 3: env2 0x00040000 0x001c0000 0 150 4: kernel 0x00600000 0x00200000 0 151 5: bootparms 0x00040000 0x00800000 0 152 6: splashimg 0x00200000 0x00840000 0 153 7: mini 0x02800000 0x00a40000 0 154 8: rootfs 0x1cdc0000 0x03240000 0 155 156 157 twister => nand read 82000000 kernel 158 159 NAND read: device 0 offset 0x200000, size 0x600000 160 6291456 bytes read: OK 161 162 Now the kernel is in RAM at address 0x82000000 163 164 twister => spl export atags 0x82000000 165 ## Booting kernel from Legacy Image at 82000000 ... 166 Image Name: Linux-3.5.0-rc4-14089-gda0b7f4 167 Image Type: ARM Linux Kernel Image (uncompressed) 168 Data Size: 3654808 Bytes = 3.5 MiB 169 Load Address: 80008000 170 Entry Point: 80008000 171 Verifying Checksum ... OK 172 Loading Kernel Image ... OK 173 OK 174 cmdline subcommand not supported 175 bdt subcommand not supported 176 Argument image is now in RAM at: 0x80000100 177 178 The result can be checked at address 0x80000100: 179 180 twister => md 0x80000100 181 80000100: 00000005 54410001 00000000 00000000 ......AT........ 182 80000110: 00000000 00000067 54410009 746f6f72 ....g.....ATroot 183 80000120: 65642f3d 666e2f76 77722073 73666e20 =/dev/nfs rw nfs 184 185 The parameters generated with this step can be saved into NAND at the offset 186 0x800000 (value for twister for CONFIG_CMD_SPL_NAND_OFS) 187 188 nand erase.part bootparms 189 nand write 0x80000100 bootparms 0x4000 190 191 Now the parameters are stored into the NAND flash at the address 192 CONFIG_CMD_SPL_NAND_OFS (=0x800000). 193 194 Next time, the board can be started into Falcon Mode moving the 195 setting the gpio (on twister gpio 55 is used) to kernel mode. 196 197 The kernel is loaded directly by the SPL without passing through U-Boot. 198 199 Example with FDT: a3m071 board 200 ------------------------------- 201 202 To boot the Linux kernel from the SPL, the DT blob (fdt) needs to get 203 prepard/patched first. U-Boot usually inserts some dynamic values into 204 the DT binary (blob), e.g. autodetected memory size, MAC addresses, 205 clocks speeds etc. To generate this patched DT blob, you can use 206 the following command: 207 208 1. Load fdt blob to SDRAM: 209 => tftp 1800000 a3m071/a3m071.dtb 210 211 2. Set bootargs as desired for Linux booting (e.g. flash_mtd): 212 => run mtdargs addip2 addtty 213 214 3. Use "fdt" commands to patch the DT blob: 215 => fdt addr 1800000 216 => fdt boardsetup 217 => fdt chosen 218 219 4. Display patched DT blob (optional): 220 => fdt print 221 222 5. Save fdt to NOR flash: 223 => erase fc060000 fc07ffff 224 => cp.b 1800000 fc060000 10000 225 ... 226 227 228 Falcon Mode was presented at the RMLL 2012. Slides are available at: 229 230 http://schedule2012.rmll.info/IMG/pdf/LSM2012_UbootFalconMode_Babic.pdf 231
README.fdt-control
1 # SPDX-License-Identifier: GPL-2.0+ 2 # 3 # Copyright (c) 2011 The Chromium OS Authors. 4 5 Device Tree Control in U-Boot 6 ============================= 7 8 This feature provides for run-time configuration of U-Boot via a flat 9 device tree (fdt). U-Boot configuration has traditionally been done 10 using CONFIG options in the board config file. This feature aims to 11 make it possible for a single U-Boot binary to support multiple boards, 12 with the exact configuration of each board controlled by a flat device 13 tree (fdt). This is the approach recently taken by the ARM Linux kernel 14 and has been used by PowerPC for some time. 15 16 The fdt is a convenient vehicle for implementing run-time configuration 17 for three reasons. Firstly it is easy to use, being a simple text file. 18 It is extensible since it consists of nodes and properties in a nice 19 hierarchical format. 20 21 Finally, there is already excellent infrastructure for the fdt: a 22 compiler checks the text file and converts it to a compact binary 23 format, and a library is already available in U-Boot (libfdt) for 24 handling this format. 25 26 The dts directory contains a Makefile for building the device tree blob 27 and embedding it in your U-Boot image. This is useful since it allows 28 U-Boot to configure itself according to what it finds there. If you have 29 a number of similar boards with different peripherals, you can describe 30 the features of each board in the device tree file, and have a single 31 generic source base. 32 33 To enable this feature, add CONFIG_OF_CONTROL to your board config file. 34 35 36 What is a Flat Device Tree? 37 --------------------------- 38 39 An fdt can be specified in source format as a text file. To read about 40 the fdt syntax, take a look at the specification here: 41 42 https://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf 43 44 You also might find this section of the Linux kernel documentation 45 useful: (access this in the Linux kernel source code) 46 47 Documentation/devicetree/booting-without-of.txt 48 49 There is also a mailing list: 50 51 http://lists.ozlabs.org/listinfo/devicetree-discuss 52 53 In case you are wondering, OF stands for Open Firmware. 54 55 56 Tools 57 ----- 58 59 To use this feature you will need to get the device tree compiler here: 60 61 git://git.kernel.org/pub/scm/utils/dtc/dtc.git 62 63 For example: 64 65 $ git clone git://git.kernel.org/pub/scm/utils/dtc/dtc.git 66 $ cd dtc 67 $ make 68 $ sudo make install 69 70 Then run the compiler (your version will vary): 71 72 $ dtc -v 73 Version: DTC 1.2.0-g2cb4b51f 74 $ make tests 75 $ cd tests 76 $ ./run_tests.sh 77 ********** TEST SUMMARY 78 * Total testcases: 1371 79 * PASS: 1371 80 * FAIL: 0 81 * Bad configuration: 0 82 * Strange test result: 0 83 84 You will also find a useful fdtdump utility for decoding a binary file, as 85 well as fdtget/fdtput for reading and writing properties in a binary file. 86 87 88 Where do I get an fdt file for my board? 89 ---------------------------------------- 90 91 You may find that the Linux kernel has a suitable file. Look in the 92 kernel source in arch/<arch>/boot/dts. 93 94 If not you might find other boards with suitable files that you can 95 modify to your needs. Look in the board directories for files with a 96 .dts extension. 97 98 Failing that, you could write one from scratch yourself! 99 100 101 Configuration 102 ------------- 103 104 Use: 105 106 #define CONFIG_DEFAULT_DEVICE_TREE "<name>" 107 108 to set the filename of the device tree source. Then put your device tree 109 file into 110 111 board/<vendor>/dts/<name>.dts 112 113 This should include your CPU or SOC's device tree file, placed in 114 arch/<arch>/dts, and then make any adjustments required. 115 116 If CONFIG_OF_EMBED is defined, then it will be picked up and built into 117 the U-Boot image (including u-boot.bin). This is suitable for debugging 118 and development only and is not recommended for production devices. 119 120 If CONFIG_OF_SEPARATE is defined, then it will be built and placed in 121 a u-boot.dtb file alongside u-boot.bin. A common approach is then to 122 join the two: 123 124 cat u-boot.bin u-boot.dtb >image.bin 125 126 and then flash image.bin onto your board. Note that U-Boot creates 127 u-boot-dtb.bin which does the above step for you also. If you are using 128 CONFIG_SPL_FRAMEWORK, then u-boot.img will be built to include the device 129 tree binary. 130 131 If CONFIG_OF_BOARD is defined, a board-specific routine will provide the 132 device tree at runtime, for example if an earlier bootloader stage creates 133 it and passes it to U-Boot. 134 135 If CONFIG_OF_HOSTFILE is defined, then it will be read from a file on 136 startup. This is only useful for sandbox. Use the -d flag to U-Boot to 137 specify the file to read. 138 139 You cannot use more than one of these options at the same time. 140 141 To use a device tree file that you have compiled yourself, pass 142 EXT_DTB=<filename> to 'make', as in: 143 144 make EXT_DTB=boot/am335x-boneblack-pubkey.dtb 145 146 Then U-Boot will copy that file to u-boot.dtb, put it in the .img file 147 if used, and u-boot-dtb.bin. 148 149 If you wish to put the fdt at a different address in memory, you can 150 define the "fdtcontroladdr" environment variable. This is the hex 151 address of the fdt binary blob, and will override either of the options. 152 Be aware that this environment variable is checked prior to relocation, 153 when only the compiled-in environment is available. Therefore it is not 154 possible to define this variable in the saved SPI/NAND flash 155 environment, for example (it will be ignored). After relocation, this 156 variable will be set to the address of the newly relocated fdt blob. 157 It is read-only and cannot be changed. It can optionally be used to 158 control the boot process of Linux with bootm/bootz commands. 159 160 To use this, put something like this in your board header file: 161 162 #define CONFIG_EXTRA_ENV_SETTINGS "fdtcontroladdr=10000\0" 163 164 Build: 165 166 After board configuration is done, fdt supported u-boot can be build in two ways: 167 1) build the default dts which is defined from CONFIG_DEFAULT_DEVICE_TREE 168 $ make 169 2) build the user specified dts file 170 $ make DEVICE_TREE=<dts-file-name> 171 172 173 Limitations 174 ----------- 175 176 U-Boot is designed to build with a single architecture type and CPU 177 type. So for example it is not possible to build a single ARM binary 178 which runs on your AT91 and OMAP boards, relying on an fdt to configure 179 the various features. This is because you must select one of 180 the CPU families within arch/arm/cpu/arm926ejs (omap or at91) at build 181 time. Similarly you cannot build for multiple cpu types or 182 architectures. 183 184 That said the complexity reduction by using fdt to support variants of 185 boards which use the same SOC / CPU can be substantial. 186 187 It is important to understand that the fdt only selects options 188 available in the platform / drivers. It cannot add new drivers (yet). So 189 you must still have the CONFIG option to enable the driver. For example, 190 you need to define CONFIG_SYS_NS16550 to bring in the NS16550 driver, 191 but can use the fdt to specific the UART clock, peripheral address, etc. 192 In very broad terms, the CONFIG options in general control *what* driver 193 files are pulled in, and the fdt controls *how* those files work. 194 195 -- 196 Simon Glass <sjg (a] chromium.org> 197 1-Sep-11 198
README.fdt-overlays
1 U-Boot FDT Overlay usage 2 ============================================= 3 4 Overlays Syntax 5 --------------- 6 7 Overlays require slightly different syntax compared to traditional overlays. 8 Please refer to dt-object-internal.txt in the dtc sources for information 9 regarding the internal format of overlays: 10 https://git.kernel.org/pub/scm/utils/dtc/dtc.git/tree/Documentation/dt-object-internal.txt 11 12 Building Overlays 13 ----------------- 14 15 In a nutshell overlays provides a means to manipulate a symbol a previous dtb 16 or overlay has defined. It requires both the base and all the overlays 17 to be compiled with the -@ command line switch so that symbol information is 18 included. 19 20 Note support for -@ option can only be found in dtc version 1.4.4 or newer. 21 Only version 4.14 or higher of the Linux kernel includes a built in version 22 of dtc that meets this requirement. 23 24 Building an overlay follows the same process as building a traditional dtb. 25 26 For example: 27 28 base.dts 29 -------- 30 31 /dts-v1/; 32 / { 33 foo: foonode { 34 foo-property; 35 }; 36 }; 37 38 $ dtc -@ -I dts -O dtb -o base.dtb base.dts 39 40 bar.dts 41 ------- 42 43 /dts-v1/; 44 /plugin/; 45 / { 46 fragment@1 { 47 target = <&foo>; 48 __overlay__ { 49 overlay-1-property; 50 bar: barnode { 51 bar-property; 52 }; 53 }; 54 }; 55 }; 56 57 $ dtc -@ -I dts -O dtb -o bar.dtb bar.dts 58 59 Ways to Utilize Overlays in U-boot 60 ---------------------------------- 61 62 There are two ways to apply overlays in U-boot. 63 1. Include and define overlays within a FIT image and have overlays 64 automatically applied. 65 66 2. Manually load and apply overlays 67 68 The remainder of this document will discuss using overlays via the manual 69 approach. For information on using overlays as part of a FIT image please see: 70 doc/uImage.FIT/overlay-fdt-boot.txt 71 72 Manually Loading and Applying Overlays 73 -------------------------------------- 74 75 1. Figure out where to place both the base device tree blob and the 76 overlay. Make sure you have enough space to grow the base tree without 77 overlapping anything. 78 79 => setenv fdtaddr 0x87f00000 80 => setenv fdtovaddr 0x87fc0000 81 82 2. Load the base blob and overlay blobs 83 84 => load ${devtype} ${bootpart} ${fdtaddr} ${bootdir}/base.dtb 85 => load ${devtype} ${bootpart} ${fdtovaddr} ${bootdir}/overlay.dtb 86 87 3. Set it as the working fdt tree. 88 89 => fdtaddr $fdtaddr 90 91 4. Grow it enough so it can 'fit' all the applied overlays 92 93 => fdt resize 8192 94 95 5. You are now ready to apply the overlay. 96 97 => fdt apply $fdtovaddr 98 99 6. Boot system like you would do with a traditional dtb. 100 101 For bootm: 102 103 => bootm ${kerneladdr} - ${fdtaddr} 104 105 For bootz: 106 107 => bootz ${kerneladdr} - ${fdtaddr} 108 109 Please note that in case of an error, both the base and overlays are going 110 to be invalidated, so keep copies to avoid reloading. 111 112 Pantelis Antoniou 113 pantelis.antoniou (a] konsulko.com 114 11/7/2017 115
README.fec_mxc
1 U-Boot config options used in fec_mxc.c 2 3 CONFIG_FEC_MXC 4 Selects fec_mxc.c to be compiled into u-boot. Can read out the 5 ethaddr from the SoC eFuses (see below). 6 7 CONFIG_MII 8 Must be defined if CONFIG_FEC_MXC is defined. 9 10 CONFIG_FEC_XCV_TYPE 11 Defaults to MII100 for 100 Base-tx. 12 RGMII selects 1000 Base-tx reduced pin count interface. 13 RMII selects 100 Base-tx reduced pin count interface. 14 15 CONFIG_FEC_MXC_SWAP_PACKET 16 Forced on iff MX28. 17 Swaps the bytes order of all words(4 byte units) in the packet. 18 This should not be specified by a board file. It is cpu specific. 19 20 CONFIG_PHYLIB 21 fec_mxc supports PHYLIB and should be used for new boards. 22 23 CONFIG_FEC_MXC_NO_ANEG 24 Relevant only if PHYLIB not used. Skips auto-negotiation restart. 25 26 CONFIG_FEC_MXC_PHYADDR 27 Optional, selects the exact phy address that should be connected 28 and function fecmxc_initialize will try to initialize it. 29 30 CONFIG_FEC_FIXED_SPEED 31 Optional, selects a fixed speed on the MAC interface without asking some 32 phy. This is usefull if there is a direct MAC <-> MAC connection, for 33 example if the CPU is connected directly via the RGMII interface to a 34 ethernet-switch. 35 36 Reading the ethaddr from the SoC eFuses: 37 if CONFIG_FEC_MXC is defined and the U-Boot environment does not contain the 38 ethaddr variable, then its value gets read from the corresponding eFuses in 39 the SoC. See the README files of the specific SoC for details. 40
README.fsl-clk
1 Freescale system clock options 2 3 - CONFIG_SYS_FSL_CLK 4 Enable to call get_clocks() in board_init_f() for 5 non-PPC platforms. 6
README.fsl-ddr
1 Table of interleaving 2-4 controllers 2 ===================================== 3 +--------------+-----------------------------------------------------------+ 4 |Configuration | Memory Controller | 5 | | 1 2 3 4 | 6 |--------------+--------------+--------------+-----------------------------+ 7 | Two memory | Not Intlv'ed | Not Intlv'ed | | 8 | complexes +--------------+--------------+ | 9 | | 2-way Intlv'ed | | 10 |--------------+--------------+--------------+--------------+ | 11 | | Not Intlv'ed | Not Intlv'ed | Not Intlv'ed | | 12 | Three memory +--------------+--------------+--------------+ | 13 | complexes | 2-way Intlv'ed | Not Intlv'ed | | 14 | +-----------------------------+--------------+ | 15 | | 3-way Intlv'ed | | 16 +--------------+--------------+--------------+--------------+--------------+ 17 | | Not Intlv'ed | Not Intlv'ed | Not Intlv'ed | Not Intlv'ed | 18 | Four memory +--------------+--------------+--------------+--------------+ 19 | complexes | 2-way Intlv'ed | 2-way Intlv'ed | 20 | +-----------------------------+-----------------------------+ 21 | | 4-way Intlv'ed | 22 +--------------+-----------------------------------------------------------+ 23 24 25 Table of 2-way interleaving modes supported in cpu/8xxx/ddr/ 26 ====================================================== 27 +-------------+---------------------------------------------------------+ 28 | | Rank Interleaving | 29 | +--------+-----------+-----------+------------+-----------+ 30 |Memory | | | | 2x2 | 4x1 | 31 |Controller | None | 2x1 lower | 2x1 upper | {CS0+CS1}, | {CS0+CS1+ | 32 |Interleaving | | {CS0+CS1} | {CS2+CS3} | {CS2+CS3} | CS2+CS3} | 33 +-------------+--------+-----------+-----------+------------+-----------+ 34 |None | Yes | Yes | Yes | Yes | Yes | 35 +-------------+--------+-----------+-----------+------------+-----------+ 36 |Cacheline | Yes | Yes | No | No, Only(*)| Yes | 37 | |CS0 Only| | | {CS0+CS1} | | 38 +-------------+--------+-----------+-----------+------------+-----------+ 39 |Page | Yes | Yes | No | No, Only(*)| Yes | 40 | |CS0 Only| | | {CS0+CS1} | | 41 +-------------+--------+-----------+-----------+------------+-----------+ 42 |Bank | Yes | Yes | No | No, Only(*)| Yes | 43 | |CS0 Only| | | {CS0+CS1} | | 44 +-------------+--------+-----------+-----------+------------+-----------+ 45 |Superbank | No | Yes | No | No, Only(*)| Yes | 46 | | | | | {CS0+CS1} | | 47 +-------------+--------+-----------+-----------+------------+-----------+ 48 (*) Although the hardware can be configured with memory controller 49 interleaving using "2x2" rank interleaving, it only interleaves {CS0+CS1} 50 from each controller. {CS2+CS3} on each controller are only rank 51 interleaved on that controller. 52 53 For memory controller interleaving, identical DIMMs are suggested. Software 54 doesn't check the size or organization of interleaved DIMMs. 55 56 The ways to configure the ddr interleaving mode 57 ============================================== 58 1. In board header file(e.g.MPC8572DS.h), add default interleaving setting 59 under "CONFIG_EXTRA_ENV_SETTINGS", like: 60 #define CONFIG_EXTRA_ENV_SETTINGS \ 61 "hwconfig=fsl_ddr:ctlr_intlv=bank" \ 62 ...... 63 64 2. Run U-Boot "setenv" command to configure the memory interleaving mode. 65 Either numerical or string value is accepted. 66 67 # disable memory controller interleaving 68 setenv hwconfig "fsl_ddr:ctlr_intlv=null" 69 70 # cacheline interleaving 71 setenv hwconfig "fsl_ddr:ctlr_intlv=cacheline" 72 73 # page interleaving 74 setenv hwconfig "fsl_ddr:ctlr_intlv=page" 75 76 # bank interleaving 77 setenv hwconfig "fsl_ddr:ctlr_intlv=bank" 78 79 # superbank 80 setenv hwconfig "fsl_ddr:ctlr_intlv=superbank" 81 82 # 1KB 3-way interleaving 83 setenv hwconfig "fsl_ddr:ctlr_intlv=3way_1KB" 84 85 # 4KB 3-way interleaving 86 setenv hwconfig "fsl_ddr:ctlr_intlv=3way_4KB" 87 88 # 8KB 3-way interleaving 89 setenv hwconfig "fsl_ddr:ctlr_intlv=3way_8KB" 90 91 # disable bank (chip-select) interleaving 92 setenv hwconfig "fsl_ddr:bank_intlv=null" 93 94 # bank(chip-select) interleaving cs0+cs1 95 setenv hwconfig "fsl_ddr:bank_intlv=cs0_cs1" 96 97 # bank(chip-select) interleaving cs2+cs3 98 setenv hwconfig "fsl_ddr:bank_intlv=cs2_cs3" 99 100 # bank(chip-select) interleaving (cs0+cs1) and (cs2+cs3) (2x2) 101 setenv hwconfig "fsl_ddr:bank_intlv=cs0_cs1_and_cs2_cs3" 102 103 # bank(chip-select) interleaving (cs0+cs1+cs2+cs3) (4x1) 104 setenv hwconfig "fsl_ddr:bank_intlv=cs0_cs1_cs2_cs3" 105 106 # bank(chip-select) interleaving (auto) 107 setenv hwconfig "fsl_ddr:bank_intlv=auto" 108 This auto mode only select from cs0_cs1_cs2_cs3, cs0_cs1, null dependings 109 on DIMMs. 110 111 Memory controller address hashing 112 ================================== 113 If the DDR controller supports address hashing, it can be enabled by hwconfig. 114 115 Syntax is: 116 hwconfig=fsl_ddr:addr_hash=true 117 118 Memory controller ECC on/off 119 ============================ 120 If ECC is enabled in board configuratoin file, i.e. #define CONFIG_DDR_ECC, 121 ECC can be turned on/off by hwconfig. 122 123 Syntax is 124 hwconfig=fsl_ddr:ecc=off 125 126 127 Memory address parity on/off 128 ============================ 129 address parity can be turned on/off by hwconfig. 130 Syntax is: 131 hwconfig=fsl_ddr:parity=on 132 133 134 Memory testing options for mpc85xx 135 ================================== 136 1. Memory test can be done once U-Boot prompt comes up using mtest, or 137 2. Memory test can be done with Power-On-Self-Test function, activated at 138 compile time. 139 140 In order to enable the POST memory test, CONFIG_POST needs to be 141 defined in board configuraiton header file. By default, POST memory test 142 performs a fast test. A slow test can be enabled by changing the flag at 143 compiling time. To test memory bigger than 2GB, 36BIT support is needed. 144 Memory is tested within a 2GB window. TLBs are used to map the virtual 2GB 145 window to physical address so that all physical memory can be tested. 146 147 Combination of hwconfig 148 ======================= 149 Hwconfig can be combined with multiple parameters, for example, on a supported 150 platform 151 152 hwconfig=fsl_ddr:addr_hash=true,ctlr_intlv=cacheline,bank_intlv=cs0_cs1_cs2_cs3,ecc=on 153 154 155 Table for dynamic ODT for DDR3 156 ============================== 157 For single-slot system with quad-rank DIMM and dual-slot system, dynamic ODT may 158 be needed, depending on the configuration. The numbers in the following tables are 159 in Ohms. 160 161 * denotes dynamic ODT 162 163 Two slots system 164 +-----------------------+----------+---------------+-----------------------------+-----------------------------+ 165 | Configuration | |DRAM controller| Slot 1 | Slot 2 | 166 +-----------+-----------+----------+-------+-------+--------------+--------------+--------------+--------------+ 167 | | | | | | Rank 1 | Rank 2 | Rank 1 | Rank 2 | 168 + Slot 1 | Slot 2 |Write/Read| Write | Read |-------+------+-------+------+-------+------+-------+------+ 169 | | | | | | Write | Read | Write | Read | Write | Read | Write | Read | 170 +-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+ 171 | | | Slot 1 | off | 75 | 120 | off | off | off | off | off | 30 | 30 | 172 | Dual Rank | Dual Rank |----------+-------+-------+-------+------+-------+------+-------+------+-------+------+ 173 | | | Slot 2 | off | 75 | off | off | 30 | 30 | 120 | off | off | off | 174 +-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+ 175 | | | Slot 1 | off | 75 | 120 | off | off | off | 20 | 20 | | | 176 | Dual Rank |Single Rank|----------+-------+-------+-------+------+-------+------+-------+------+-------+------+ 177 | | | Slot 2 | off | 75 | off | off | 20 | 20 | 120 *| off | | | 178 +-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+ 179 | | | Slot 1 | off | 75 | 120 *| off | | | off | off | 20 | 20 | 180 |Single Rank| Dual Rank |----------+-------+-------+-------+------+-------+------+-------+------+-------+------+ 181 | | | Slot 2 | off | 75 | 20 | 20 | | | 120 | off | off | off | 182 +-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+ 183 | | | Slot 1 | off | 75 | 120 *| off | | | 30 | 30 | | | 184 |Single Rank|Single Rank|----------+-------+-------+-------+------+-------+------+-------+------+-------+------+ 185 | | | Slot 2 | off | 75 | 30 | 30 | | | 120 *| off | | | 186 +-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+ 187 | Dual Rank | Empty | Slot 1 | off | 75 | 40 | off | off | off | | | | | 188 +-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+ 189 | Empty | Dual Rank | Slot 2 | off | 75 | | | | | 40 | off | off | off | 190 +-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+ 191 |Single Rank| Empty | Slot 1 | off | 75 | 40 | off | | | | | | | 192 +-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+ 193 | Empty |Single Rank| Slot 2 | off | 75 | | | | | 40 | off | | | 194 +-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+ 195 196 Single slot system 197 +-------------+------------+---------------+-----------------------------+-----------------------------+ 198 | | |DRAM controller| Rank 1 | Rank 2 | Rank 3 | Rank 4 | 199 |Configuration| Write/Read |-------+-------+-------+------+-------+------+-------+------+-------+------+ 200 | | | Write | Read | Write | Read | Write | Read | Write | Read | Write | Read | 201 +-------------+------------+-------+-------+-------+------+-------+------+-------+------+-------+------+ 202 | | R1 | off | 75 | 120 *| off | off | off | 20 | 20 | off | off | 203 | |------------+-------+-------+-------+------+-------+------+-------+------+-------+------+ 204 | | R2 | off | 75 | off | 20 | 120 | off | 20 | 20 | off | off | 205 | Quad Rank |------------+-------+-------+-------+------+-------+------+-------+------+-------+------+ 206 | | R3 | off | 75 | 20 | 20 | off | off | 120 *| off | off | off | 207 | |------------+-------+-------+-------+------+-------+------+-------+------+-------+------+ 208 | | R4 | off | 75 | 20 | 20 | off | off | off | 20 | 120 | off | 209 +-------------+------------+-------+-------+-------+------+-------+------+-------+------+-------+------+ 210 | | R1 | off | 75 | 40 | off | off | off | 211 | Dual Rank |------------+-------+-------+-------+------+-------+------+ 212 | | R2 | off | 75 | 40 | off | off | off | 213 +-------------+------------+-------+-------+-------+------+-------+------+ 214 | Single Rank | R1 | off | 75 | 40 | off | 215 +-------------+------------+-------+-------+-------+------+ 216 217 Reference http://www.xrosstalkmag.com/mag_issues/xrosstalk_oct08_final.pdf 218 http://download.micron.com/pdf/technotes/ddr3/tn4108_ddr3_design_guide.pdf 219 220 221 Table for ODT for DDR2 222 ====================== 223 Two slots system 224 +-----------------------+----------+---------------+-----------------------------+-----------------------------+ 225 | Configuration | |DRAM controller| Slot 1 | Slot 2 | 226 +-----------+-----------+----------+-------+-------+--------------+--------------+--------------+--------------+ 227 | | | | | | Rank 1 | Rank 2 | Rank 1 | Rank 2 | 228 + Slot 1 | Slot 2 |Write/Read| Write | Read |-------+------+-------+------+-------+------+-------+------+ 229 | | | | | | Write | Read | Write | Read | Write | Read | Write | Read | 230 +-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+ 231 | | | Slot 1 | off | 150 | off | off | off | off | 75 | 75 | off | off | 232 | Dual Rank | Dual Rank |----------+-------+-------+-------+------+-------+------+-------+------+-------+------+ 233 | | | Slot 2 | off | 150 | 75 | 75 | off | off | off | off | off | off | 234 +-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+ 235 | | | Slot 1 | off | 150 | off | off | off | off | 75 | 75 | | | 236 | Dual Rank |Single Rank|----------+-------+-------+-------+------+-------+------+-------+------+-------+------+ 237 | | | Slot 2 | off | 150 | 75 | 75 | off | off | off | off | | | 238 +-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+ 239 | | | Slot 1 | off | 150 | off | off | | | 75 | 75 | off | off | 240 |Single Rank| Dual Rank |----------+-------+-------+-------+------+-------+------+-------+------+-------+------+ 241 | | | Slot 2 | off | 150 | 75 | 75 | | | off | off | off | off | 242 +-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+ 243 | | | Slot 1 | off | 150 | off | off | | | 75 | 75 | | | 244 |Single Rank|Single Rank|----------+-------+-------+-------+------+-------+------+-------+------+-------+------+ 245 | | | Slot 2 | off | 150 | 75 | 75 | | | off | off | | | 246 +-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+ 247 | Dual Rank | Empty | Slot 1 | off | 75 | 150 | off | off | off | | | | | 248 +-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+ 249 | Empty | Dual Rank | Slot 2 | off | 75 | | | | | 150 | off | off | off | 250 +-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+ 251 |Single Rank| Empty | Slot 1 | off | 75 | 150 | off | | | | | | | 252 +-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+ 253 | Empty |Single Rank| Slot 2 | off | 75 | | | | | 150 | off | | | 254 +-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+ 255 256 Single slot system 257 +-------------+------------+---------------+-----------------------------+ 258 | | |DRAM controller| Rank 1 | Rank 2 | 259 |Configuration| Write/Read |-------+-------+-------+------+-------+------+ 260 | | | Write | Read | Write | Read | Write | Read | 261 +-------------+------------+-------+-------+-------+------+-------+------+ 262 | | R1 | off | 75 | 150 | off | off | off | 263 | Dual Rank |------------+-------+-------+-------+------+-------+------+ 264 | | R2 | off | 75 | 150 | off | off | off | 265 +-------------+------------+-------+-------+-------+------+-------+------+ 266 | Single Rank | R1 | off | 75 | 150 | off | 267 +-------------+------------+-------+-------+-------+------+ 268 269 Reference http://www.samsung.com/global/business/semiconductor/products/dram/downloads/applicationnote/ddr2_odt_control_200603.pdf 270 271 272 Interactive DDR debugging 273 =========================== 274 275 For DDR parameter tuning up and debugging, the interactive DDR debugger can 276 be activated by setting the environment variable "ddr_interactive" to any 277 value. (The value of ddr_interactive may have a meaning in the future, but, 278 for now, the presence of the variable will cause the debugger to run.) Once 279 activated, U-Boot will show the prompt "FSL DDR>" before enabling the DDR 280 controller. The available commands are printed by typing "help". 281 282 Another way to enter the interactive DDR debugger without setting the 283 environment variable is to send the 'd' character early during the boot 284 process. To save booting time, no additional delay is added, so the window 285 to send the key press is very short -- basically, it is the time before the 286 memory controller code starts to run. For example, when rebooting from 287 within U-Boot, the user must press 'd' IMMEDIATELY after hitting enter to 288 initiate a 'reset' command. In case of power on/reset, the user can hold 289 down the 'd' key while applying power or hitting the board's reset button. 290 291 The example flow of using interactive debugging is 292 type command "compute" to calculate the parameters from the default 293 type command "print" with arguments to show SPD, options, registers 294 type command "edit" with arguments to change any if desired 295 type command "copy" with arguments to copy controller/dimm settings 296 type command "go" to continue calculation and enable DDR controller 297 298 Additional commands to restart the debugging are: 299 type command "reset" to reset the board 300 type command "recompute" to reload SPD and start over 301 302 Note, check "next_step" to show the flow. For example, after edit opts, the 303 next_step is STEP_ASSIGN_ADDRESSES. After editing registers, the next_step is 304 STEP_PROGRAM_REGS. Upon issuing command "go", the debugger will program the 305 DDR controller with the current setting without further calculation and then 306 exit to resume the booting of the machine. 307 308 The detail syntax for each commands are 309 310 print [c<n>] [d<n>] [spd] [dimmparms] [commonparms] [opts] [addresses] [regs] 311 c<n> - the controller number, eg. c0, c1 312 d<n> - the DIMM number, eg. d0, d1 313 spd - print SPD data 314 dimmparms - DIMM parameters, calculated from SPD 315 commonparms - lowest common parameters for all DIMMs 316 opts - options 317 addresses - address assignment (not implemented yet) 318 regs - controller registers 319 320 edit <c#> <d#> <spd|dimmparms|commonparms|opts|addresses|regs> <element> <value> 321 c<n> - the controller number, eg. c0, c1 322 d<n> - the DIMM number, eg. d0, d1 323 spd - print SPD data 324 dimmparms - DIMM parameters, calculated from SPD 325 commonparms - lowest common parameters for all DIMMs 326 opts - options 327 addresses - address assignment (not implemented yet) 328 regs - controller registers 329 <element> - name of the modified element 330 byte number if the object is SPD 331 <value> - decimal or heximal (prefixed with 0x) numbers 332 333 copy <src c#> <src d#> <spd|dimmparms|commonparms|opts|addresses|regs> <dst c#> <dst d#> 334 same as for "edit" command 335 DIMM numbers ignored for commonparms, opts, and regs 336 337 reset 338 no arguement - reset the board 339 340 recompute 341 no argument - reload SPD and start over 342 343 compute 344 no argument - recompute from current next_step 345 346 next_step 347 no argument - show current next_step 348 349 help 350 no argument - print a list of all commands 351 352 go 353 no argument - program memory controller(s) and continue with U-Boot 354 355 Examples of debugging flow 356 357 FSL DDR>compute 358 Detected UDIMM UG51U6400N8SU-ACF 359 FSL DDR>print 360 print [c<n>] [d<n>] [spd] [dimmparms] [commonparms] [opts] [addresses] [regs] 361 FSL DDR>print dimmparms 362 DIMM parameters: Controller=0 DIMM=0 363 DIMM organization parameters: 364 module part name = UG51U6400N8SU-ACF 365 rank_density = 2147483648 bytes (2048 megabytes) 366 capacity = 4294967296 bytes (4096 megabytes) 367 burst_lengths_bitmask = 0C 368 base_addresss = 0 (00000000 00000000) 369 n_ranks = 2 370 data_width = 64 371 primary_sdram_width = 64 372 ec_sdram_width = 0 373 registered_dimm = 0 374 n_row_addr = 15 375 n_col_addr = 10 376 edc_config = 0 377 n_banks_per_sdram_device = 8 378 tCKmin_X_ps = 1500 379 tCKmin_X_minus_1_ps = 0 380 tCKmin_X_minus_2_ps = 0 381 tCKmax_ps = 0 382 caslat_X = 960 383 tAA_ps = 13125 384 caslat_X_minus_1 = 0 385 caslat_X_minus_2 = 0 386 caslat_lowest_derated = 0 387 tRCD_ps = 13125 388 tRP_ps = 13125 389 tRAS_ps = 36000 390 tWR_ps = 15000 391 tWTR_ps = 7500 392 tRFC_ps = 160000 393 tRRD_ps = 6000 394 tRC_ps = 49125 395 refresh_rate_ps = 7800000 396 tIS_ps = 0 397 tIH_ps = 0 398 tDS_ps = 0 399 tDH_ps = 0 400 tRTP_ps = 7500 401 tDQSQ_max_ps = 0 402 tQHS_ps = 0 403 FSL DDR>edit c0 opts ECC_mode 0 404 FSL DDR>edit c0 regs cs0_bnds 0x000000FF 405 FSL DDR>go 406 2 GiB left unmapped 407 4 GiB (DDR3, 64-bit, CL=9, ECC off) 408 DDR Chip-Select Interleaving Mode: CS0+CS1 409 Testing 0x00000000 - 0x7fffffff 410 Testing 0x80000000 - 0xffffffff 411 Remap DDR 2 GiB left unmapped 412 413 POST memory PASSED 414 Flash: 128 MiB 415 L2: 128 KB enabled 416 Corenet Platform Cache: 1024 KB enabled 417 SERDES: timeout resetting bank 3 418 SRIO1: disabled 419 SRIO2: disabled 420 MMC: FSL_ESDHC: 0 421 EEPROM: Invalid ID (ff ff ff ff) 422 PCIe1: disabled 423 PCIe2: Root Complex, x1, regs @ 0xfe201000 424 01:00.0 - 8086:10d3 - Network controller 425 PCIe2: Bus 00 - 01 426 PCIe3: disabled 427 In: serial 428 Out: serial 429 Err: serial 430 Net: Initializing Fman 431 Fman1: Uploading microcode version 101.8.0 432 e1000: 00:1b:21:81:d2:e0 433 FM1@DTSEC1, FM1@DTSEC2, FM1@DTSEC3, FM1@DTSEC4, FM1@DTSEC5, e1000#0 [PRIME] 434 Warning: e1000#0 MAC addresses don't match: 435 Address in SROM is 00:1b:21:81:d2:e0 436 Address in environment is 00:e0:0c:00:ea:05 437 438 Hit any key to stop autoboot: 0 439 => 440
README.fsl-dpaa
1 This file documents Freescale DPAA-specific options. 2 3 FMan (Frame Manager) 4 - CONFIG_FSL_FM_10GEC_REGULAR_NOTATION 5 on SoCs T4240, T2080, LS1043A, etc, the notation between 10GEC and MAC as below: 6 10GEC1->MAC9, 10GEC2->MAC10, 10GEC3->MAC1, 10GEC4->MAC2 7 on SoCs T1024, etc, the notation between 10GEC and MAC as below: 8 10GEC1->MAC1, 10GEC2->MAC2 9 so we introduce CONFIG_FSL_FM_10GEC_REGULAR_NOTATION to identify the new SoCs on 10 which 10GEC enumeration is consistent with MAC enumeration. 11
README.fsl-esdhc
1 Freescale esdhc-specific options 2 3 - CONFIG_FSL_ESDHC_ADAPTER_IDENT 4 Support Freescale adapter card type identification. This is implemented by 5 operating Qixis FPGA relevant registers. The STAT_PRES1 register has SDHC 6 Card ID[0:2] bits showing the type of card installed in the SDHC Adapter Slot. 7 8 SDHC Card ID[0:2] Adapter Card Type 9 0b000 reserved 10 0b001 eMMC Card Rev4.5 11 0b010 SD/MMC Legacy Card 12 0b011 eMMC Card Rev4.4 13 0b100 reserved 14 0b101 MMC Card 15 0b110 SD Card Rev2.0/3.0 16 0b111 No card is present 17 - CONFIG_SYS_FSL_ESDHC_LE 18 ESDHC IP is in little-endian mode. Accessing ESDHC registers can be 19 determined by ESDHC IP's endian mode or processor's endian mode. 20 - CONFIG_SYS_FSL_ESDHC_BE 21 ESDHC IP is in big-endian mode. Accessing ESDHC registers can be determined 22 by ESDHC IP's endian mode or processor's endian mode. 23
README.fsl-hwconfig
1 Freescale-specific 'hwconfig' options. 2 3 This file documents Freescale-specific key:value pairs for the 'hwconfig' 4 option. See README.hwconfig for general information about 'hwconfig'. 5 6 audclk 7 Specific to the P1022DS reference board. 8 9 This option specifies which of the two oscillator frequencies should be 10 routed to the Wolfson WM8776 codec. The ngPIXIS can be programmed to 11 route either a 11.2896MHz or a 12.288MHz clock. The default is 12 12.288MHz. This option has two effects. First, the MUX on the board 13 will be programmed accordingly. Second, the clock-frequency property 14 in the codec node in the device tree will be updated to the correct 15 value. 16 17 'audclk:11' 18 Select the 11.2896MHz clock 19 20 'audclk:12' 21 Select the 12.288MHz clock 22 23 usb 24 Specific to boards have USB controller 25 26 This option specifies the following for a USB controller: 27 28 - which controller mode to use 29 - which USB PHY to use 30 31 This is used by generic USB device-tree fixup function to update 32 modified values of phy type and controller mode. 33 34 Also used for configuring multiple USB controllers such that 35 'usbN' (where N is 1, 2, etc. refers to controller no.) 36 37 'phy_type' 38 Select USB phy type: 'utmi' OR 'ulpi' 39 40 'dr_mode' 41 Select USB controller mode: 'host', 'peripheral' OR 'otg' 42 43 Examples: 44 usb1:dr_mode=host;usb2:dr_mode=peripheral' 45 46 usb1:dr_mode=host,phy_type=utmi;usb2:dr_mode=host' 47
README.fsl-trustzone-components
1 Freescale ARM64 SoCs like LS2080A have ARM TrustZone components like 2 TZPC-BP147 (TrustZone Protection Controller) and TZASC-400 (TrustZone 3 Address Space Controller). 4 5 While most of the configuration related programming of these peripherals 6 is left to a root-of-trust security software layer (running in EL3 7 privilege mode), but still some configurations of these peripherals 8 might be required while the bootloader is executing in EL3 privilege 9 mode. The following sections define how to turn on these features for 10 LS2080A like SoCs. 11 12 TZPC-BP147 (TrustZone Protection Controller) 13 ============================================ 14 - Depends on CONFIG_FSL_TZPC_BP147 configuration flag. 15 - Separates Secure World and Normal World on-chip RAM (OCRAM) spaces. 16 - Provides a programming model to set access control policy via the TZPC 17 TZDECPROT Registers. 18 19 TZASC-400 (TrustZone Address Space Controller) 20 ============================================== 21 - Depends on CONFIG_FSL_TZASC_400 configuration flag. 22 - Separates Secure World and Normal World external memory spaces for bus masters 23 such as processors and DMA-equipped peripherals. 24 - Supports 8 fully programmable address regions, initially inactive at reset, 25 and one base region, always active, that covers the remaining address space. 26
README.fsl_iim
1 Driver implementing the fuse API for Freescale's IC Identification Module (IIM) 2 3 This IP can be found on the following SoCs: 4 - MPC512x, 5 - i.MX25, 6 - i.MX27, 7 - i.MX31, 8 - i.MX35, 9 - i.MX51, 10 - i.MX53. 11 12 The section numbers in this file refer to the i.MX25 Reference Manual. 13 14 A fuse word contains 8 fuse bit slots, as explained in 30.4.2.2.1. 15 16 A bank contains 256 fuse word slots, as shown by the memory map in 30.3.1. 17 18 Some fuse bit or word slots may not have the corresponding fuses actually 19 implemented in the fusebox. 20 21 See the README files of the SoCs using this driver in order to know the 22 conventions used by U-Boot to store some specific data in the fuses, e.g. MAC 23 addresses. 24 25 Fuse operations: 26 27 Read 28 Read operations are implemented as read accesses to the shadow registers, 29 using "Word y of Bank x" from the register summary in 30.3.2. This is 30 explained in detail in 30.4.5.1. 31 32 Sense 33 Sense operations are implemented as explained in 30.4.5.2. 34 35 Program 36 Program operations are implemented as explained in 30.4.5.3. Following 37 this operation, the shadow registers are reloaded by the hardware (not 38 immediately, but this does not make any difference for a user reading 39 these registers). 40 41 Override 42 Override operations are implemented as write accesses to the shadow 43 registers, as explained in 30.4.5.4. 44 45 Configuration: 46 47 CONFIG_FSL_IIM 48 Define this to enable the fsl_iim driver. 49
README.fuse
1 Fuse API functions and commands 2 3 The fuse API allows to control a fusebox and how it is used by the upper 4 hardware layers. 5 6 A fuse corresponds to a single non-volatile memory bit that can be programmed 7 (i.e. blown, set to 1) only once. The programming operation is irreversible. A 8 fuse that has not been programmed reads 0. 9 10 Fuses can be used by SoCs to store various permanent configuration and data, 11 e.g. boot configuration, security configuration, MAC addresses, etc. 12 13 A fuse word is the smallest group of fuses that can be read at once from the 14 fusebox control IP registers. This is limited to 32 bits with the current API. 15 16 A fuse bank is the smallest group of fuse words having a common ID, as defined 17 by each SoC. 18 19 Upon startup, the fusebox control IP reads the fuse values and stores them to a 20 volatile shadow cache. 21 22 See the README files of the drivers implementing this API in order to know the 23 SoC- and implementation-specific details. 24 25 Functions / commands: 26 27 int fuse_read(u32 bank, u32 word, u32 *val); 28 fuse read <bank> <word> [<cnt>] 29 Read fuse words from the shadow cache. 30 31 int fuse_sense(u32 bank, u32 word, u32 *val); 32 fuse sense <bank> <word> [<cnt>] 33 Sense - i.e. read directly from the fusebox, skipping the shadow cache - 34 fuse words. This operation does not update the shadow cache. 35 36 This is useful to know the true value of fuses if an override has been 37 performed (see below). 38 39 int fuse_prog(u32 bank, u32 word, u32 val); 40 fuse prog [-y] <bank> <word> <hexval> [<hexval>...] 41 Program fuse words. This operation directly affects the fusebox and is 42 irreversible. The shadow cache is updated accordingly or not, depending on 43 each IP. 44 45 Only the bits to be programmed should be set in the input value (i.e. for 46 fuse bits that have already been programmed and hence should be left 47 unchanged by a further programming, it is preferable to clear the 48 corresponding bits in the input value in order not to perform a new 49 hardware programming operation on these fuse bits). 50 51 int fuse_override(u32 bank, u32 word, u32 val); 52 fuse override <bank> <word> <hexval> [<hexval>...] 53 Override fuse words in the shadow cache. 54 55 The fusebox is unaffected, so following this operation, the shadow cache 56 may differ from the fusebox values. Read or sense operations can then be 57 used to get the values from the shadow cache or from the fusebox. 58 59 This is useful to change the behaviors linked to some cached fuse values, 60 either because this is needed only temporarily, or because some of the 61 fuses have already been programmed or are locked (if the SoC allows to 62 override a locked fuse). 63 64 Configuration: 65 66 CONFIG_CMD_FUSE 67 Define this to enable the fuse commands. 68
README.generic-board
1 # SPDX-License-Identifier: GPL-2.0+ 2 # 3 # (C) Copyright 2014 Google, Inc 4 # Simon Glass <sjg (a] chromium.org> 5 6 Background 7 ---------- 8 9 U-Boot traditionally had a board.c file for each architecture. This introduced 10 quite a lot of duplication, with each architecture tending to do 11 initialisation slightly differently. To address this, a new 'generic board 12 init' feature was introduced in March 2013 (further motivation is 13 provided in the cover letter below). 14 15 All boards and architectures have moved to this as of mid 2016. 16 17 18 What has changed? 19 ----------------- 20 21 The main change is that the arch/<arch>/lib/board.c file is removed in 22 favour of common/board_f.c (for pre-relocation init) and common/board_r.c 23 (for post-relocation init). 24 25 Related to this, the global_data and bd_t structures now have a core set of 26 fields which are common to all architectures. Architecture-specific fields 27 have been moved to separate structures. 28 29 30 Further Background 31 ------------------ 32 33 The full text of the original generic board series is reproduced below. 34 35 --8<------------- 36 37 This series creates a generic board.c implementation which contains 38 the essential functions of the major arch/xxx/lib/board.c files. 39 40 What is the motivation for this change? 41 42 1. There is a lot of repeated code in the board.c files. Any change to 43 things like setting up the baud rate requires a change in 10 separate 44 places. 45 46 2. Since there are 10 separate files, adding a new feature which requires 47 initialisation is painful since it must be independently added in 10 48 places. 49 50 3. As time goes by the architectures naturally diverge since there is limited 51 pressure to compare features or even CONFIG options against similar things 52 in other board.c files. 53 54 4. New architectures must implement all the features all over again, and 55 sometimes in subtle different ways. This places an unfair burden on getting 56 a new architecture fully functional and running with U-Boot. 57 58 5. While it is a bit of a tricky change, I believe it is worthwhile and 59 achievable. There is no requirement that all code be common, only that 60 the code that is common should be located in common/board.c rather than 61 arch/xxx/lib/board.c. 62 63 All the functions of board_init_f() and board_init_r() are broken into 64 separate function calls so that they can easily be included or excluded 65 for a particular architecture. It also makes it easier to adopt Graeme's 66 initcall proposal when it is ready. 67 68 http://lists.denx.de/pipermail/u-boot/2012-January/114499.html 69 70 This series removes the dependency on generic relocation. So relocation 71 happens as one big chunk and is still completely arch-specific. See the 72 relocation series for a proposed solution to this for ARM: 73 74 http://lists.denx.de/pipermail/u-boot/2011-December/112928.html 75 76 or Graeme's recent x86 series v2: 77 78 http://lists.denx.de/pipermail/u-boot/2012-January/114467.html 79 80 Instead of moving over a whole architecture, this series takes the approach 81 of simply enabling generic board support for an architecture. It is then up 82 to each board to opt in by defining CONFIG_SYS_GENERIC_BOARD in the board 83 config file. If this is not done, then the code will be generated as 84 before. This allows both sets of code to co-exist until we are comfortable 85 with the generic approach, and enough boards run. 86 87 ARM is a relatively large board.c file and one which I can test, therefore 88 I think it is a good target for this series. On the other hand, x86 is 89 relatively small and simple, but different enough that it introduces a 90 few issues to be solved. So I have chosen both ARM and x86 for this series. 91 After a suggestion from Wolfgang I have added PPC also. This is the 92 largest and most feature-full board, so hopefully we have all bases 93 covered in this RFC. 94 95 A generic global_data structure is also required. This might upset a few 96 people. Here is my basic reasoning: most fields are the same, all 97 architectures include and need it, most global_data.h files already have 98 #ifdefs to select fields for a particular SOC, so it is hard to 99 see why architecures are different in this area. We can perhaps add a 100 way to put architecture-specific fields into a separate header file, but 101 for now I have judged that to be counter-productive. 102 103 Similarly we need a generic bd_info structure, since generic code will 104 be accessing it. I have done this in the same way as global_data and the 105 same comments apply. 106 107 There was dicussion on the list about passing gd_t around as a parameter 108 to pre-relocation init functions. I think this makes sense, but it can 109 be done as a separate change, and this series does not require it. 110 111 While this series needs to stand on its own (as with the link script 112 cleanup series and the generic relocation series) the goal is the 113 unification of the board init code. So I hope we can address issues with 114 this in mind, rather than focusing too narrowly on particular ARM, x86 or 115 PPC issues. 116 117 I have run-tested ARM on Tegra Seaboard only. To try it out, define 118 CONFIG_SYS_GENERIC_BOARD in your board file and rebuild. Most likely on 119 x86 and PPC at least it will hang, but if you are lucky it will print 120 something first :-) 121 122 I have run this though MAKEALL with CONFIG_SYS_GENERIC_BOARD on for all 123 ARM, PPC and x86 boards. There are a few failures due to errors in 124 the board config, which I have sent patches for. The main issue is 125 just the difference between __bss_end and __bss_end__. 126 127 Note: the first group of commits are required for this series to build, 128 but could be separated out if required. I have included them here for 129 convenience. 130 131 ------------->8-- 132 133 Simon Glass, sjg (a] chromium.org 134 March 2014 135 Updated after final removal, May 2016 136
README.generic_usb_ohci
1 Notes on the the generic USB-OHCI driver 2 ======================================== 3 4 This driver (drivers/usb/usb_ohci.[ch]) is the result of the merge of 5 various existing OHCI drivers that were basically identical beside 6 cpu/board dependant initalization. This initalization has been moved 7 into cpu/board directories and are called via the hooks below. 8 9 Configuration options 10 ---------------------- 11 12 CONFIG_USB_OHCI_NEW: enable the new OHCI driver 13 14 CONFIG_SYS_USB_OHCI_BOARD_INIT: call the board dependant hooks: 15 16 - extern int usb_board_init(void); 17 - extern int usb_board_stop(void); 18 - extern int usb_cpu_init_fail(void); 19 20 CONFIG_SYS_USB_OHCI_CPU_INIT: call the cpu dependant hooks: 21 22 - extern int usb_cpu_init(void); 23 - extern int usb_cpu_stop(void); 24 - extern int usb_cpu_init_fail(void); 25 26 CONFIG_SYS_USB_OHCI_REGS_BASE: defines the base address of the OHCI 27 registers 28 29 CONFIG_SYS_USB_OHCI_SLOT_NAME: slot name 30 31 CONFIG_SYS_USB_OHCI_MAX_ROOT_PORTS: maximal number of ports of the 32 root hub. 33 34 35 Endianness issues 36 ------------------ 37 38 The USB bus operates in little endian, but unfortunately there are 39 OHCI controllers that operate in big endian such as ppc4xx. For these the 40 config option 41 42 CONFIG_SYS_OHCI_BE_CONTROLLER 43 44 needs to be defined. 45 46 47 PCI Controllers 48 ---------------- 49 50 You'll need to define 51 52 CONFIG_PCI_OHCI 53 54 If you have several USB PCI controllers, define 55 56 CONFIG_PCI_OHCI_DEVNO: number of the OHCI device in PCI list 57 58 If undefined, the first instance found in PCI space will be used. 59 60 PCI Controllers need to do byte swapping on register accesses, so they 61 should to define: 62 63 CONFIG_SYS_OHCI_SWAP_REG_ACCESS 64
README.gpt
1 # SPDX-License-Identifier: GPL-2.0+ 2 # 3 # Copyright (C) 2012 Samsung Electronics 4 # 5 # Lukasz Majewski <l.majewski (a] samsung.com> 6 7 Glossary: 8 ======== 9 - UUID -(Universally Unique Identifier) 10 - GUID - (Globally Unique ID) 11 - EFI - (Extensible Firmware Interface) 12 - UEFI - (Unified EFI) - EFI evolution 13 - GPT (GUID Partition Table) - it is the EFI standard part 14 - partitions - lists of available partitions (defined at u-boot): 15 ./include/configs/{target}.h 16 17 Introduction: 18 ============= 19 This document describes the GPT partition table format and usage of 20 the gpt command in u-boot. 21 22 UUID introduction: 23 ==================== 24 25 GPT for marking disks/partitions is using the UUID. It is supposed to be a 26 globally unique value. A UUID is a 16-byte (128-bit) number. The number of 27 theoretically possible UUIDs is therefore about 3 x 10^38. 28 More often UUID is displayed as 32 hexadecimal digits, in 5 groups, 29 separated by hyphens, in the form 8-4-4-4-12 for a total of 36 characters 30 (32 digits and 4 hyphens) 31 32 For instance, GUID of Basic data partition: EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 33 and GUID of Linux filesystem data: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 34 35 Historically there are 5 methods to generate this number. The oldest one is 36 combining machine's MAC address and timer (epoch) value. 37 38 Successive versions are using MD5 hash, random numbers and SHA-1 hash. All major 39 OSes and programming languages are providing libraries to compute UUID (e.g. 40 uuid command line tool). 41 42 GPT brief explanation: 43 ====================== 44 45 Layout: 46 ------- 47 48 -------------------------------------------------- 49 LBA 0 |Protective MBR | 50 ---------------------------------------------------------- 51 LBA 1 |Primary GPT Header | Primary 52 -------------------------------------------------- GPT 53 LBA 2 |Entry 1|Entry 2| Entry 3| Entry 4| 54 -------------------------------------------------- 55 LBA 3 |Entries 5 - 128 | 56 | | 57 | | 58 ---------------------------------------------------------- 59 LBA 34 |Partition 1 | 60 | | 61 ----------------------------------- 62 |Partition 2 | 63 | | 64 ----------------------------------- 65 |Partition n | 66 | | 67 ---------------------------------------------------------- 68 LBA -34 |Entry 1|Entry 2| Entry 3| Entry 4| Backup 69 -------------------------------------------------- GPT 70 LBA -33 |Entries 5 - 128 | 71 | | 72 | | 73 LBA -2 | | 74 -------------------------------------------------- 75 LBA -1 |Backup GPT Header | 76 ---------------------------------------------------------- 77 78 For a legacy reasons, GPT's LBA 0 sector has a MBR structure. It is called 79 "protective MBR". 80 Its first partition entry ID has 0xEE value, and disk software, which is not 81 handling the GPT sees it as a storage device without free space. 82 83 It is possible to define 128 linearly placed partition entries. 84 85 "LBA -1" means the last addressable block (in the mmc subsystem: 86 "dev_desc->lba - 1") 87 88 Primary/Backup GPT header: 89 ---------------------------- 90 Offset Size Description 91 92 0 8 B Signature ("EFI PART", 45 46 49 20 50 41 52 54) 93 8 4 B Revision (For version 1.0, the value is 00 00 01 00) 94 12 4 B Header size (in bytes, usually 5C 00 00 00 meaning 92 bytes) 95 16 4 B CRC32 of header (0 to header size), with this field zeroed 96 during calculation 97 20 4 B Reserved (ZERO); 98 24 8 B Current LBA (location of this header copy) 99 32 8 B Backup LBA (location of the other header copy) 100 40 8 B First usable LBA for partitions (primary partition table last 101 LBA + 1) 102 48 8 B Last usable LBA (secondary partition table first LBA - 1) 103 56 16 B Disk GUID (also referred as UUID on UNIXes) 104 72 8 B Partition entries starting LBA (always 2 in primary copy) 105 80 4 B Number of partition entries 106 84 4 B Size of a partition entry (usually 128) 107 88 4 B CRC32 of partition array 108 92 * Reserved; must be ZERO (420 bytes for a 512-byte LBA) 109 110 TOTAL: 512 B 111 112 113 IMPORTANT: 114 115 GPT headers and partition entries are protected by CRC32 (the POSIX CRC32). 116 117 Primary GPT header and Backup GPT header have swapped values of "Current LBA" 118 and "Backup LBA" and therefore different CRC32 check-sum. 119 120 CRC32 for GPT headers (field "CRC of header") are calculated up till 121 "Header size" (92), NOT 512 bytes. 122 123 CRC32 for partition entries (field "CRC32 of partition array") is calculated for 124 the whole array entry ( Number_of_partition_entries * 125 sizeof(partition_entry_size (usually 128))) 126 127 Observe, how Backup GPT is placed in the memory. It is NOT a mirror reflect 128 of the Primary. 129 130 Partition Entry Format: 131 ---------------------- 132 Offset Size Description 133 134 0 16 B Partition type GUID (Big Endian) 135 16 16 B Unique partition GUID in (Big Endian) 136 32 8 B First LBA (Little Endian) 137 40 8 B Last LBA (inclusive) 138 48 8 B Attribute flags [+] 139 56 72 B Partition name (text) 140 141 Attribute flags: 142 Bit 0 - System partition 143 Bit 1 - Hide from EFI 144 Bit 2 - Legacy BIOS bootable 145 Bit 48-63 - Defined and used by the individual partition type 146 For Basic data partition : 147 Bit 60 - Read-only 148 Bit 62 - Hidden 149 Bit 63 - Not mount 150 151 Creating GPT partitions in U-Boot: 152 ============== 153 154 To restore GUID partition table one needs to: 155 1. Define partition layout in the environment. 156 Format of partitions layout: 157 "uuid_disk=...;name=u-boot,size=60MiB,uuid=...; 158 name=kernel,size=60MiB,uuid=...;" 159 or 160 "uuid_disk=${uuid_gpt_disk};name=${uboot_name}, 161 size=${uboot_size},uuid=${uboot_uuid};" 162 163 The fields 'name' and 'size' are mandatory for every partition. 164 The field 'start' is optional. 165 166 If field 'size' of the last partition is 0, the partition is extended 167 up to the end of the device. 168 169 The fields 'uuid' and 'uuid_disk' are optional if CONFIG_RANDOM_UUID is 170 enabled. A random uuid will be used if omitted or they point to an empty/ 171 non-existent environment variable. The environment variable will be set to 172 the generated UUID. The 'gpt guid' command reads the current value of the 173 uuid_disk from the GPT. 174 175 The field 'bootable' is optional, it is used to mark the GPT partition 176 bootable (set attribute flags "Legacy BIOS bootable"). 177 "name=u-boot,size=60MiB;name=boot,size=60Mib,bootable;name=rootfs,size=0" 178 It can be used to locate bootable disks with command 179 "part list <interface> <dev> -bootable <varname>", 180 please check out doc/README.distro for use. 181 182 2. Define 'CONFIG_EFI_PARTITION' and 'CONFIG_CMD_GPT' 183 184 3. From u-boot prompt type: 185 gpt write mmc 0 $partitions 186 187 Checking (validating) GPT partitions in U-Boot: 188 =============================================== 189 190 Procedure is the same as above. The only change is at point 3. 191 192 At u-boot prompt one needs to write: 193 gpt verify mmc 0 [$partitions] 194 195 where [$partitions] is an optional parameter. 196 197 When it is not provided, only basic checks based on CRC32 calculation for GPT 198 header and PTEs are performed. 199 When provided, additionally partition data - name, size and starting 200 offset (last two in LBA) - are compared with data defined in '$partitions' 201 environment variable. 202 203 After running this command, return code is set to 0 if no errors found in 204 on non-volatile medium stored GPT. 205 206 Following line can be used to assess if GPT verification has succeed: 207 208 U-BOOT> gpt verify mmc 0 $partitions 209 U-BOOT> if test $? = 0; then echo "GPT OK"; else echo "GPT ERR"; fi 210 211 Renaming GPT partitions from U-Boot: 212 ==================================== 213 214 GPT partition names are a mechanism via which userspace and U-Boot can 215 communicate about software updates and boot failure. The 'gpt guid', 216 'gpt read', 'gpt rename' and 'gpt swap' commands facilitate 217 programmatic renaming of partitions from bootscripts by generating and 218 modifying the partitions layout string. Here is an illustration of 219 employing 'swap' to exchange 'primary' and 'backup' partition names: 220 221 U-BOOT> gpt swap mmc 0 primary backup 222 223 Afterwards, all partitions previously named 'primary' will be named 224 'backup', and vice-versa. Alternatively, single partitions may be 225 renamed. In this example, mmc0's first partition will be renamed 226 'primary': 227 228 U-BOOT> gpt rename mmc 0 1 primary 229 230 The GPT functionality may be tested with the 'sandbox' board by 231 creating a disk image as described under 'Block Device Emulation' in 232 board/sandbox/README.sandbox: 233 234 =>host bind 0 ./disk.raw 235 => gpt read host 0 236 [ . . . ] 237 => gpt swap host 0 name othername 238 [ . . . ] 239 240 Partition type GUID: 241 ==================== 242 243 For created partition, the used partition type GUID is 244 PARTITION_BASIC_DATA_GUID (EBD0A0A2-B9E5-4433-87C0-68B6B72699C7). 245 246 If you define 'CONFIG_PARTITION_TYPE_GUID', a optionnal parameter 'type' 247 can specify a other partition type guid: 248 249 "uuid_disk=...;name=u-boot,size=60MiB,uuid=...; 250 name=kernel,size=60MiB,uuid=..., 251 type=0FC63DAF-8483-4772-8E79-3D69D8477DE4;" 252 253 Some strings can be also used at the place of known GUID : 254 "system" = PARTITION_SYSTEM_GUID 255 (C12A7328-F81F-11D2-BA4B-00A0C93EC93B) 256 "mbr" = LEGACY_MBR_PARTITION_GUID 257 (024DEE41-33E7-11D3-9D69-0008C781F39F) 258 "msft" = PARTITION_MSFT_RESERVED_GUID 259 (E3C9E316-0B5C-4DB8-817D-F92DF00215AE) 260 "data" = PARTITION_BASIC_DATA_GUID 261 (EBD0A0A2-B9E5-4433-87C0-68B6B72699C7) 262 "linux" = PARTITION_LINUX_FILE_SYSTEM_DATA_GUID 263 (0FC63DAF-8483-4772-8E79-3D69D8477DE4) 264 "raid" = PARTITION_LINUX_RAID_GUID 265 (A19D880F-05FC-4D3B-A006-743F0F84911E) 266 "swap" = PARTITION_LINUX_SWAP_GUID 267 (0657FD6D-A4AB-43C4-84E5-0933C84B4F4F) 268 "lvm" = PARTITION_LINUX_LVM_GUID 269 (E6D6D379-F507-44C2-A23C-238F2A3DF928) 270 271 "uuid_disk=...;name=u-boot,size=60MiB,uuid=...; 272 name=kernel,size=60MiB,uuid=...,type=linux;" 273 274 They are also used to display the type of partition in "part list" command. 275 276 277 Useful info: 278 ============ 279 280 Two programs, namely: 'gdisk' and 'parted' are recommended to work with GPT 281 recovery. Both are able to handle GUID partitions. 282 Please, pay attention at -l switch for parted. 283 284 "uuid" program is recommended to generate UUID string. Moreover it can decode 285 (-d switch) passed in UUID string. It can be used to generate partitions UUID 286 passed to u-boot environment variables. 287 If optional CONFIG_RANDOM_UUID is defined then for any partition which environment 288 uuid is unset, uuid is randomly generated and stored in correspond environment 289 variable. 290 291 note: 292 Each string block of UUID generated by program "uuid" is in big endian and it is 293 also stored in big endian in disk GPT. 294 Partitions layout can be printed by typing "mmc part". Note that each partition 295 GUID has different byte order than UUID generated before, this is because first 296 three blocks of GUID string are in Little Endian. 297
README.Heterogeneous-SoCs
1 DSP side awareness for Freescale heterogeneous multicore chips based on 2 StarCore and Power Architecture 3 =============================================================== 4 powerpc/mpc85xx code ve APIs and function to get the number, 5 configuration and frequencies of all PowerPC cores and devices 6 connected to them, but it didnt have the similar code ofr HEterogeneous 7 SC3900/DSP cores and such devices like CPRI, MAPLE, MAPLE-ULB etc. 8 9 Code for DSP side awareness provides such functionality for Freescale 10 Heterogeneous SoCs which are chasis-2 compliant like B4860 and B4420 11 12 As part of this feature, following changes have been made: 13 ========================================================== 14 15 1. Changed files: 16 ================= 17 - arch/powerpc/cpu/mpc85xx/cpu.c 18 19 Code added in this file to print the DSP cores and other device's(CPRI, 20 MAPLE etc) frequencies 21 22 - arch/powerpc/cpu/mpc85xx/speed.c 23 24 Added Defines and code to extract the frequncy information for all 25 required cores and devices from RCW and System frequency 26 27 - arch/powerpc/cpu/mpc8xxx/cpu.c 28 29 Added API to get the number of SC cores in running system and Their BIT 30 MASK, similar to the code written for PowerPC 31 32 - arch/powerpc/include/asm/config_mpc85xx.h 33 34 Added top level CONFIG to identify presence of HETEROGENUOUS clusters 35 in the system and CONFIGS for SC3900/DSP components 36 37 - arch/powerpc/include/asm/processor.h 38 - include/common.h 39 40 Added newly added Functions Declaration 41 42 - include/e500.h 43 44 Global structure updated for dsp cores and other components 45 46 2. CONFIGs ADDED 47 ================ 48 49 CONFIG_HETROGENOUS_CLUSTERS - Define for checking the presence of 50 DSP/SC3900 core clusters 51 52 CONFIG_SYS_FSL_NUM_CC_PLLS - Define for number of PLLs 53 54 Though there are only 4 PLLs in B4, but in sequence of PLLs from PLL1 - 55 PLL5, PLL3 is Reserved(as mentioned in RM), so this define contains the 56 value as 5 not 4, to iterate over all PLLs while coding 57 58 CONFIG_SYS_MAPLE - Define for MAPLE Baseband Accelerator 59 CONFIG_SYS_CPRI - Define for CPRI Interface 60 CONFIG_PPC_CLUSTER_START - Start index of ppc clusters 61 CONFIG_DSP_CLUSTER_START - Start index of dsp clusters 62 63 Following are the defines for PLL's index that provide the Clocking to 64 CPRI, ULB and ETVE components 65 66 CONFIG_SYS_CPRI_CLK - Define PLL index for CPRI clock 67 CONFIG_SYS_ULB_CLK - Define PLL index for ULB clock 68 CONFIG_SYS_ETVPE_CLK - Define PLL index for ETVPE clock 69 70 3. Changes in MPC85xx_SYS_INFO Global structure 71 =============================================== 72 73 DSP cores and other device's components have been added in this structure. 74 75 freq_processor_dsp[CONFIG_MAX_DSP_CPUS] - Array to contain the DSP core's frequencies 76 freq_cpri - To store CPRI frequency 77 freq_maple - To store MAPLE frequency 78 freq_maple_ulb - To store MAPLE-ULB frequency 79 freq_maple_etvpe - To store MAPLE-eTVPE frequency 80 81 4. U-BOOT LOGS 82 ============== 83 4.1 B4860QDS board 84 Boot from NOR flash 85 86 U-Boot 2014.07-00222-g70587a8-dirty (Aug 07 2014 - 13:15:47) 87 88 CPU0: B4860E, Version: 2.0, (0x86880020) 89 Core: e6500, Version: 2.0, (0x80400020) Clock Configuration: 90 CPU0:1600 MHz, CPU1:1600 MHz, CPU2:1600 MHz, CPU3:1600 MHz, 91 DSP CPU0:1200 MHz, DSP CPU1:1200 MHz, DSP CPU2:1200 MHz, DSP CPU3:1200 MHz, 92 DSP CPU4:1200 MHz, DSP CPU5:1200 MHz, 93 CCB:666.667 MHz, 94 DDR:933.333 MHz (1866.667 MT/s data rate) (Asynchronous), IFC:166.667 MHz 95 CPRI:600 MHz 96 MAPLE:600 MHz, MAPLE-ULB:800 MHz, MAPLE-eTVPE:1000 MHz 97 FMAN1: 666.667 MHz 98 QMAN: 333.333 MHz 99 100 CPUn - PowerPC core 101 DSP CPUn - SC3900 core 102 103 Shaveta Leekha(shaveta (a] freescale.com) 104 Created August 7, 2014 105 =========================================== 106
README.hwconfig
1 To enable this feature just define CONFIG_HWCONFIG in your board 2 config file. 3 4 This implements a simple hwconfig infrastructure: an 5 interface for software knobs to control hardware. 6 7 This a is very simple implementation, i.e. it is implemented 8 via the `hwconfig' environment variable. Later we could write 9 some "hwconfig <enable|disable|list>" commands, ncurses 10 interface for Award BIOS-like interface, and frame-buffer 11 interface for AMI GUI[1] BIOS-like interface with mouse 12 support[2]. 13 14 Current implementation details/limitations: 15 16 1. Doesn't support options dependencies and mutual exclusion. 17 We can implement this by integrating apt-get[3] into Das 18 U-Boot. But I haven't bothered yet. 19 20 2. Since we don't implement a hwconfig command, i.e. we're working 21 with the environment directly, there is no way to tell that 22 toggling a particular option will need a reboot to take 23 effect. So, for now it's advised to always reboot the 24 target after modifying the hwconfig variable. 25 26 3. We support hwconfig options with arguments. For example, 27 28 set hwconfig "dr_usb:mode=peripheral,phy_type=ulpi" 29 30 This selects three hwconfig options: 31 1. dr_usb - enable Dual-Role USB controller; 32 2. dr_usb_mode:peripheral - USB in Function mode; 33 3. dr_usb_phy_type:ulpi - USB should work with ULPI PHYs. 34 35 The purpose of this simple implementation is to refine the 36 internal API and then we can continue improving the user 37 experience by adding more mature interfaces, like a hwconfig 38 command with bells and whistles. Or not adding, if we feel 39 that the current interface fits people's needs. 40 41 [1] http://en.wikipedia.org/wiki/American_Megatrends 42 [2] Regarding ncurses and GUI with mouse support -- I'm just 43 kidding. 44 [3] The comment regarding apt-get is also a joke, meaning that 45 dependency tracking could be non-trivial. For example, for 46 enabling HW feature X we may need to disable Y, and turn Z 47 into reduced mode (like RMII-only interface for ethernet, 48 no MII). 49 50 It's quite trivial to implement simple cases though. 51
README.i2c
1 I2C Bus Arbitration 2 =================== 3 4 While I2C supports multi-master buses this is difficult to get right. 5 The implementation on the master side in software is quite complex. 6 Clock-stretching and the arbitrary time that an I2C transaction can take 7 make it difficult to share the bus fairly in the face of high traffic. 8 When one or more masters can be reset independently part-way through a 9 transaction it is hard to know the state of the bus. 10 11 U-Boot provides a scheme based on two 'claim' GPIOs, one driven by the 12 AP (Application Processor, meaning the main CPU) and one driven by the EC 13 (Embedded Controller, a small CPU aimed at handling system tasks). With 14 these they can communicate and reliably share the bus. This scheme has 15 minimal overhead and involves very little code. The scheme can survive 16 reboots by either side without difficulty. 17 18 Since U-Boot runs on the AP, the terminology used is 'our' claim GPIO, 19 meaning the AP's, and 'their' claim GPIO, meaning the EC's. This terminology 20 is used by the device tree bindings in Linux also. 21 22 The driver is implemented as an I2C mux, as it is in Linux. See 23 i2c-arb-gpio-challenge for the implementation. 24 25 GPIO lines are shared between the AP and EC to manage the bus. The AP and EC 26 each have a 'bus claim' line, which is an output that the other can see. 27 28 - AP_CLAIM: output from AP, signalling to the EC that the AP wants the bus 29 - EC_CLAIM: output from EC, signalling to the AP that the EC wants the bus 30 31 The basic algorithm is to assert your line when you want the bus, then make 32 sure that the other side doesn't want it also. A detailed explanation is best 33 done with an example. 34 35 Let's say the AP wants to claim the bus. It: 36 37 1. Asserts AP_CLAIM 38 2. Waits a little bit for the other side to notice (slew time) 39 3. Checks EC_CLAIM. If this is not asserted, then the AP has the bus, and we 40 are done 41 4. Otherwise, wait for a few milliseconds (retry time) and see if EC_CLAIM is 42 released 43 5. If not, back off, release the claim and wait for a few more milliseconds 44 (retry time again) 45 6. Go back to 1 if things don't look wedged (wait time has expired) 46 7. Panic. The other side is hung with the CLAIM line set. 47 48 The same algorithm applies on the EC. 49 50 To release the bus, just de-assert the claim line. 51 52 Typical delays are: 53 - slew time 10 us 54 - retry time 3 ms 55 - wait time - 50ms 56 57 In general the traffic is fairly light, and in particular the EC wants access 58 to the bus quite rarely (maybe every 10s or 30s to check the battery). This 59 scheme works very nicely with very low contention. There is only a 10 us 60 wait for access to the bus assuming that the other side isn't using it. 61
README.imx25
1 U-Boot for Freescale i.MX25 2 3 This file contains information for the port of U-Boot to the Freescale i.MX25 4 SoC. 5 6 1. CONVENTIONS FOR FUSE ASSIGNMENTS 7 ----------------------------------- 8 9 1.1 MAC Address: It is stored in the words 26 to 31 of fuse bank 0, using the 10 natural MAC byte order (i.e. MSB first). 11
README.imx27
1 U-Boot for Freescale i.MX27 2 3 This file contains information for the port of U-Boot to the Freescale i.MX27 4 SoC. 5 6 1. CONVENTIONS FOR FUSE ASSIGNMENTS 7 ----------------------------------- 8 9 1.1 MAC Address: It is stored in the words 4 to 9 of fuse bank 0, using the 10 reversed MAC byte order (i.e. LSB first). 11
README.imx5
1 U-Boot for Freescale i.MX5x 2 3 This file contains information for the port of U-Boot to the Freescale 4 i.MX5x SoCs. 5 6 1. CONFIGURATION OPTIONS/SETTINGS 7 --------------------------------- 8 9 1.1 CONFIG_MX51_PLL_ERRATA: Workaround for i.MX51 PLL errata. 10 This option should be enabled by all boards using the i.MX51 silicon 11 version up until (including) 3.0 running at 800MHz. 12 The PLL's in the i.MX51 processor can go out of lock due to a metastable 13 condition in an analog flip-flop when used at high frequencies. 14 This workaround implements an undocumented feature in the PLL (dither 15 mode), which causes the effect of this failure to be much lower (in terms 16 of frequency deviation), avoiding system failure, or at least decreasing 17 the likelihood of system failure. 18 19 1.2 CONFIG_SYS_MAIN_PWR_ON: Trigger MAIN_PWR_ON upon startup. 20 This option should be enabled for boards having a SYS_ON_OFF_CTL signal 21 connected to GPIO1[23] and triggering the MAIN_PWR_ON signal like in the 22 reference designs. 23 24 2. CONVENTIONS FOR FUSE ASSIGNMENTS 25 ----------------------------------- 26 27 2.1 MAC Address: It is stored in the words 9 to 14 of fuse bank 1, using the 28 natural MAC byte order (i.e. MSB first). 29 30 This is an example how to program an example MAC address 01:23:45:67:89:ab 31 into the eFuses. Assure that the programming voltage is available and then 32 execute: 33 34 => fuse prog -y 1 9 01 23 45 67 89 ab 35 36 After programming a MAC address, consider locking the MAC fuses. This is 37 done by programming the MAC_ADDR_LOCK fuse, which is bit 4 of word 0 in 38 bank 1: 39 40 => fuse prog -y 1 0 10 41
README.imx6
1 U-Boot for Freescale i.MX6 2 3 This file contains information for the port of U-Boot to the Freescale i.MX6 4 SoC. 5 6 1. CONVENTIONS FOR FUSE ASSIGNMENTS 7 ----------------------------------- 8 9 1.1 MAC Address: It is stored in fuse bank 4, with the 32 lsbs in word 2 and the 10 16 msbs in word 3[15:0]. 11 For i.MX6SX and i.MX6UL, they have two MAC addresses. The second MAC address 12 is stored in fuse bank 4, with the 16 lsb in word 3[31:16] and the 32 msbs in 13 word 4. 14 15 Example: 16 17 For reading the MAC address fuses on a MX6Q: 18 19 - The MAC address is stored in two fuse addresses (the fuse addresses are 20 described in the Fusemap Descriptions table from the mx6q Reference Manual): 21 22 0x620[31:0] - MAC_ADDR[31:0] 23 0x630[15:0] - MAC_ADDR[47:32] 24 25 In order to use the fuse API, we need to pass the bank and word values, which 26 are calculated as below: 27 28 Fuse address for the lower MAC address: 0x620 29 Base address for the fuses: 0x400 30 31 (0x620 - 0x400)/0x10 = 0x22 = 34 decimal 32 33 As the fuses are arranged in banks of 8 words: 34 35 34 / 8 = 4 and the remainder is 2, so in this case: 36 37 bank = 4 38 word = 2 39 40 And the U-Boot command would be: 41 42 => fuse read 4 2 43 Reading bank 4: 44 45 Word 0x00000002: 9f027772 46 47 Doing the same for the upper MAC address: 48 49 Fuse address for the upper MAC address: 0x630 50 Base address for the fuses: 0x400 51 52 (0x630 - 0x400)/0x10 = 0x23 = 35 decimal 53 54 As the fuses are arranged in banks of 8 words: 55 56 35 / 8 = 4 and the remainder is 3, so in this case: 57 58 bank = 4 59 word = 3 60 61 And the U-Boot command would be: 62 63 => fuse read 4 3 64 Reading bank 4: 65 66 Word 0x00000003: 00000004 67 68 ,which matches the ethaddr value: 69 => echo ${ethaddr} 70 00:04:9f:02:77:72 71 72 Some other useful hints: 73 74 - The 'bank' and 'word' numbers can be easily obtained from the mx6 Reference 75 Manual. For the mx6quad case, please check the "46.5 OCOTP Memory Map/Register 76 Definition" from the "i.MX 6Dual/6Quad Applications Processor Reference Manual, 77 Rev. 1, 04/2013" document. For example, for the MAC fuses we have: 78 79 Address: 80 21B_C620 Value of OTP Bank4 Word2 (MAC Address)(OCOTP_MAC0) 81 82 21B_C630 Value of OTP Bank4 Word3 (MAC Address)(OCOTP_MAC1) 83 84 - The command '=> fuse read 4 2 2' reads the whole MAC addresses at once: 85 86 => fuse read 4 2 2 87 Reading bank 4: 88 89 Word 0x00000002: 9f027772 00000004 90 91 2. Using imx_usb_loader for first install with SPL 92 -------------------------------------------------- 93 94 imx_usb_loader is a very nice tool by Boundary Devices that 95 allow to install U-Boot without a JTAG debugger, using 96 the USB boot mode as described in the manual. It is 97 a replacement for Freescale's MFGTOOLS. 98 99 The sources can be found here: 100 101 https://github.com/boundarydevices/imx_usb_loader.git 102 103 Booting in USB mode, the i.MX6 announces itself to the Linux Host as: 104 105 Bus 001 Device 111: ID 15a2:0061 Freescale Semiconductor, Inc. 106 107 imx_usb_loader is able to download a single file (u-boot.imx) 108 to the board. For boards without SPL support, it is enough to 109 issue the command: 110 111 sudo ../imx_usb_loader/imx_usb -v u-boot.imx 112 113 In order to load SPL and u-boot.img via imx_usb_loader tool, 114 please refer to doc/README.sdp. 115 116
README.imximage
1 --------------------------------------------- 2 Imximage Boot Image generation using mkimage 3 --------------------------------------------- 4 5 This document describes how to set up a U-Boot image that can be booted 6 by Freescale MX25, MX35, MX51, MX53 and MX6 processors via internal boot 7 mode. 8 9 These processors can boot directly from NAND, SPI flash and SD card flash 10 using its internal boot ROM support. MX6 processors additionally support 11 boot from NOR flash and SATA disks. All processors can boot from an internal 12 UART, if booting from device media fails. 13 Booting from NOR flash does not require to use this image type. 14 15 For more details refer Chapter 2 - System Boot and section 2.14 16 (flash header description) of the processor's manual. 17 18 Command syntax: 19 -------------- 20 ./tools/mkimage -l <mx u-boot_file> 21 to list the imx image file details 22 23 ./tools/mkimage -T imximage \ 24 -n <board specific configuration file> \ 25 -e <execution address> -d <u-boot binary> <output image file> 26 27 For example, for the mx51evk board: 28 ./tools/mkimage -n ./board/freescale/mx51evk/imximage.cfg \ 29 -T imximage -e 0x97800000 \ 30 -d u-boot.bin u-boot.imx 31 32 You can generate directly the image when you compile u-boot with: 33 34 $ make u-boot.imx 35 36 The output image can be flashed on the board SPI flash or on a SD card. 37 In both cases, you have to copy the image at the offset required for the 38 chosen media devices (0x400 for both SPI flash or SD card). 39 40 Please check Freescale documentation for further details. 41 42 Board specific configuration file specifications: 43 ------------------------------------------------- 44 1. This file must present in the $(BOARDDIR) and the name should be 45 imximage.cfg (since this is used in Makefile). 46 2. This file can have empty lines and lines starting with "#" as first 47 character to put comments. 48 3. This file can have configuration command lines as mentioned below, 49 any other information in this file is treated as invalid. 50 51 Configuration command line syntax: 52 --------------------------------- 53 1. Each command line is must have two strings, first one command or address 54 and second one data string 55 2. Following are the valid command strings and associated data strings:- 56 Command string data string 57 -------------- ----------- 58 IMXIMAGE_VERSION 1/2 59 1 is for mx25/mx35/mx51 compatible, 60 2 is for mx53/mx6 compatible, 61 others is invalid and error is generated. 62 This command need appear the fist before 63 other valid commands in configuration file. 64 65 BOOT_OFFSET value 66 67 This command is parallel to BOOT_FROM and 68 is preferred over BOOT_FROM. 69 70 value: Offset of the image header, this 71 value shall be set to one of the 72 values found in the file: 73 arch/arm/include/asm/\ 74 mach-imx/imximage.cfg 75 Example: 76 BOOT_OFFSET FLASH_OFFSET_STANDARD 77 78 BOOT_FROM nand/spi/sd/onenand/nor/sata 79 80 This command is parallel to BOOT_OFFSET and 81 is to be deprecated in favor of BOOT_OFFSET. 82 83 Example: 84 BOOT_FROM spi 85 86 CSF value 87 88 Total size of CSF (Command Sequence File) 89 used for Secure Boot/ High Assurance Boot 90 (HAB). 91 92 Using this command will populate the IVT 93 (Initial Vector Table) CSF pointer and adjust 94 the length fields only. The CSF itself needs 95 to be generated with Freescale tools and 96 'manually' appended to the u-boot.imx file. 97 98 The CSF is then simply concatenated 99 to the u-boot image, making a signed bootloader, 100 that the processor can verify 101 if the fuses for the keys are burned. 102 103 Further infos how to configure the SOC to verify 104 the bootloader can be found in the "High 105 Assurance Boot Version Application Programming 106 Interface Reference Manual" as part of the 107 Freescale Code Signing Tool, available on the 108 manufacturer's website. 109 110 Example: 111 CSF 0x2000 112 113 DATA type address value 114 115 type: word=4, halfword=2, byte=1 116 address: physycal register address 117 value: value to be set in register 118 All values are in in hexadecimal. 119 Example (write to IOMUXC): 120 DATA 4 0x73FA88a0 0x200 121 122 The processor support up to 60 register programming commands for IMXIMAGE_VERSION 1 123 and 220 register programming commands for IMXIMAGE_VERSION 2. 124 An error is generated if more commands are found in the configuration file. 125 126 3. All commands are optional to program. 127 128 Setup a SD Card for booting 129 -------------------------------- 130 131 The following example prepare a SD card with u-boot and a FAT partition 132 to be used to stored the kernel to be booted. 133 I will set the SD in the most compatible mode, setting it with 134 255 heads and 63 sectors, as suggested from several documentation and 135 howto on line (I took as reference the preparation of a SD Card for the 136 Beagleboard, running u-boot as bootloader). 137 138 You should start clearing the partitions table on the SD card. Because 139 the u-boot image must be stored at the offset 0x400, it must be assured 140 that there is no partition at that address. A new SD card is already 141 formatted with FAT filesystem and the partition starts from the first 142 cylinder, so we need to change it. 143 144 You can do all steps with fdisk. If the device for the SD card is 145 /dev/mmcblk0, the following commands make the job: 146 147 1. Start the fdisk utility (as superuser) 148 fdisk /dev/mmcblk0 149 150 2. Clear the actual partition 151 152 Command (m for help): o 153 154 3. Print card info: 155 156 Command (m for help): p 157 Disk /dev/mmcblk0: 1981 MB, 1981284352 bytes 158 159 In my case, I have a 2 GB card. I need the size to set later the correct value 160 for the cylinders. 161 162 4. Go to expert mode: 163 164 Command (m for help): x 165 166 5. Set card geometry 167 168 Expert command (m for help): h 169 Number of heads (1-256, default 4): 255 170 171 Expert command (m for help): s 172 Number of sectors (1-63, default 16): 63 173 Warning: setting sector offset for DOS compatiblity 174 175 We have set 255 heads, 63 sector. We have to set the cylinder. 176 The value to be set can be calculated with: 177 178 cilynder = <total size> / <heads> / <sectors> / <blocksize> 179 180 in this example, 181 1981284352 / 255 / 63 / 512 = 239.x = 239 182 183 184 Expert command (m for help): c 185 Number of cylinders (1-1048576, default 60032): 239 186 187 6. Leave the expert mode 188 Expert command (m for help): r 189 190 7. Set up a partition 191 192 Now set a partition table to store the kernel or whatever you want. Of course, 193 you can set additional partitions to store rootfs, data, etc. 194 In my example I want to set a single partition. I must take care 195 to not overwrite the space where I will put u-boot. 196 197 Command (m for help): n 198 Command action 199 e extended 200 p primary partition (1-4) 201 p 202 Partition number (1-4): 1 203 First cylinder (1-239, default 1): 3 204 Last cylinder, +cylinders or +size{K,M,G} (3-239, default 239): +100M 205 206 Command (m for help): p 207 208 Disk /dev/mmcblk0: 1967 MB, 1967128576 bytes 209 255 heads, 63 sectors/track, 239 cylinders 210 Units = cylinders of 16065 * 512 = 8225280 bytes 211 Disk identifier: 0xb712a870 212 213 Device Boot Start End Blocks Id System 214 /dev/mmcblk0p1 3 16 112455 83 Linux 215 216 I have set 100MB, leaving the first 2 sectors free. I will copy u-boot 217 there. 218 219 8. Write the partition table and exit. 220 221 Command (m for help): w 222 The partition table has been altered! 223 224 Calling ioctl() to re-read partition table. 225 226 9. Copy u-boot.imx on the SD card 227 228 I use dd: 229 230 dd if=u-boot.imx of=/dev/mmcblk0 bs=512 seek=2 231 232 This command copies the u-boot image at the address 0x400, as required 233 by the processor. 234 235 Now remove your card from the PC and go to the target. If evrything went right, 236 the u-boot prompt should come after power on. 237 238 ------------------------------------------------ 239 Author: Stefano babic <sbabic (a] denx.de> 240
README.iomux
1 SPDX-License-Identifier: GPL-2.0+ 2 /* 3 * (C) Copyright 2008 4 * Gary Jennejohn, DENX Software Engineering GmbH <garyj (a] denx.de> 5 */ 6 7 U-Boot console multiplexing 8 =========================== 9 10 HOW CONSOLE MULTIPLEXING WORKS 11 ------------------------------ 12 13 This functionality is controlled with CONFIG_CONSOLE_MUX in the board 14 configuration file. 15 16 Two new files, common/iomux.c and include/iomux.h, contain the heart 17 (iomux_doenv()) of the environment setting implementation. 18 19 iomux_doenv() is called in common/cmd_nvedit.c to handle setenv and in 20 common/console.c in console_init_r() during bootup to initialize 21 stdio_devices[]. 22 23 A user can use a comma-separated list of devices to set stdin, stdout 24 and stderr. For example: "setenv stdin serial,nc". NOTE: No spaces 25 are allowed around the comma(s)! 26 27 The length of the list is limited by malloc(), since the array used 28 is allocated and freed dynamically. 29 30 It should be possible to specify any device which console_assign() 31 finds acceptable, but the code has only been tested with serial and 32 nc. 33 34 iomux_doenv() prevents multiple use of the same device, e.g. "setenv 35 stdin nc,nc,serial" will discard the second nc. iomux_doenv() is 36 not able to modify the environment, however, so that "pri stdin" still 37 shows "nc,nc,serial". 38 39 The major change in common/console.c was to modify fgetc() to call 40 the iomux_tstc() routine in a for-loop. iomux_tstc() in turn calls 41 the tstc() routine for every registered device, but exits immediately 42 when one of them returns true. fgetc() then calls iomux_getc(), 43 which calls the corresponding getc() routine. fgetc() hangs in 44 the for-loop until iomux_tstc() returns true and the input can be 45 retrieved. 46 47 Thus, a user can type into any device registered for stdin. No effort 48 has been made to demulitplex simultaneous input from multiple stdin 49 devices. 50 51 fputc() and fputs() have been modified to call iomux_putc() and 52 iomux_puts() respectively, which call the corresponding output 53 routines for every registered device. 54 55 Thus, a user can see the ouput for any device registered for stdout 56 or stderr on all devices registered for stdout or stderr. As an 57 example, if stdin=serial,nc and stdout=serial,nc then all output 58 for serial, e.g. echos of input on serial, will appear on serial and nc. 59 60 Just as with the old console code, this statement is still true: 61 If not defined in the environment, the first input device is assigned 62 to the 'stdin' file, the first output one to 'stdout' and 'stderr'. 63 64 If CONFIG_SYS_CONSOLE_IS_IN_ENV is defined then multiple input/output 65 devices can be set at boot time if defined in the environment. 66 67 CAVEATS 68 ------- 69 70 Note that common/iomux.c calls console_assign() for every registered 71 device as it is discovered. This means that the environment settings 72 for application consoles will be set to the last device in the list. 73 74 On a slow machine, such as MPC852T clocked at 66MHz, the overhead associated 75 with calling tstc() and then getc() means that copy&paste will normally not 76 work, even when stdin=stdout=stderr=serial. 77 On a faster machine, such as a sequoia, cut&paste of longer (about 80 78 characters) lines works fine when serial is the only device used. 79 80 Using nc as a stdin device results in even more overhead because nc_tstc() 81 is quite slow. Even on a sequoia cut&paste does not work on the serial 82 interface when nc is added to stdin, although there is no character loss using 83 the ethernet interface for input. In this test case stdin=serial,nc and 84 stdout=serial. 85 86 In addition, the overhead associated with sending to two devices, when one of 87 them is nc, also causes problems. Even on a sequoia cut&paste does not work 88 on the serial interface (stdin=serial) when nc is added to stdout (stdout= 89 serial,nc). 90
README.iscsi
1 # iSCSI booting with U-Boot and iPXE 2 3 ## Motivation 4 5 U-Boot has only a reduced set of supported network protocols. The focus for 6 network booting has been on UDP based protocols. A TCP stack and HTTP support 7 are expected to be integrated in 2018 together with a wget command. 8 9 For booting a diskless computer this leaves us with BOOTP or DHCP to get the 10 address of a boot script. TFTP or NFS can be used to load the boot script, the 11 operating system kernel and the initial file system (initrd). 12 13 These protocols are insecure. The client cannot validate the authenticity 14 of the contacted servers. And the server cannot verify the identity of the 15 client. 16 17 Furthermore the services providing the operating system loader or kernel are 18 not the ones that the operating system typically will use. Especially in a SAN 19 environment this makes updating the operating system a hassle. After installing 20 a new kernel version the boot files have to be copied to the TFTP server 21 directory. 22 23 The HTTPS protocol provides certificate based validation of servers. Sensitive 24 data like passwords can be securely transmitted. 25 26 The iSCSI protocol is used for connecting storage attached networks. It 27 provides mutual authentication using the CHAP protocol. It typically runs on 28 a TCP transport. 29 30 Thus a better solution than DHCP/TFTP/NFS boot would be to load a boot script 31 via HTTPS and to download any other files needed for booting via iSCSI from the 32 same target where the operating system is installed. 33 34 An alternative to implementing these protocols in U-Boot is to use an existing 35 software that can run on top of U-Boot. iPXE is the "swiss army knife" of 36 network booting. It supports both HTTPS and iSCSI. It has a scripting engine for 37 fine grained control of the boot process and can provide a command shell. 38 39 iPXE can be built as an EFI application (named snp.efi) which can be loaded and 40 run by U-Boot. 41 42 ## Boot sequence 43 44 U-Boot loads the EFI application iPXE snp.efi using the bootefi command. This 45 application has network access via the simple network protocol offered by 46 U-Boot. 47 48 iPXE executes its internal script. This script may optionally chain load a 49 secondary boot script via HTTPS or open a shell. 50 51 For the further boot process iPXE connects to the iSCSI server. This includes 52 the mutual authentication using the CHAP protocol. After the authentication iPXE 53 has access to the iSCSI targets. 54 55 For a selected iSCSI target iPXE sets up a handle with the block IO protocol. It 56 uses the ConnectController boot service of U-Boot to request U-Boot to connect a 57 file system driver. U-Boot reads from the iSCSI drive via the block IO protocol 58 offered by iPXE. It creates the partition handles and installs the simple file 59 protocol. Now iPXE can call the simple file protocol to load Grub. U-Boot uses 60 the block IO protocol offered by iPXE to fulfill the request. 61 62 Once Grub is started it uses the same block IO protocol to load Linux. Via 63 the EFI stub Linux is called as an EFI application. 64 65 ``` 66 +--------+ +--------+ 67 | | Runs | | 68 | U-Boot |=========>| iPXE | 69 | EFI | | snp.efi| 70 +--------+ | | DHCP | | 71 | |<====|********|<=========| | 72 | DHCP | | | Get IP | | 73 | Server | | | Address | | 74 | |====>|********|=========>| | 75 +--------+ | | Response | | 76 | | | | 77 | | | | 78 +--------+ | | HTTPS | | 79 | |<====|********|<=========| | 80 | HTTPS | | | Load | | 81 | Server | | | Script | | 82 | |====>|********|=========>| | 83 +--------+ | | | | 84 | | | | 85 | | | | 86 +--------+ | | iSCSI | | 87 | |<====|********|<=========| | 88 | iSCSI | | | Auth | | 89 | Server |====>|********|=========>| | 90 | | | | | | 91 | | | | Loads | | 92 | |<====|********|<=========| | +--------+ 93 | | | | Grub | | Runs | | 94 | |====>|********|=========>| |=======>| Grub | 95 | | | | | | | | 96 | | | | | | | | 97 | | | | | | Loads | | 98 | |<====|********|<=========|********|<=======| | +--------+ 99 | | | | | | Linux | | Runs | | 100 | |====>|********|=========>|********|=======>| |=====>| Linux | 101 | | | | | | | | | | 102 +--------+ +--------+ +--------+ +--------+ | | 103 | | 104 | | 105 | ~ ~ ~ ~| 106 ``` 107 108 ## Security 109 110 The iSCSI protocol is not encrypted. The traffic could be secured using IPsec 111 but neither U-Boot nor iPXE does support this. So we should at least separate 112 the iSCSI traffic from all other network traffic. This can be achieved using a 113 virtual local area network (VLAN). 114 115 ## Configuration 116 117 ### iPXE 118 119 For running iPXE on arm64 the bin-arm64-efi/snp.efi build target is needed. 120 121 git clone http://git.ipxe.org/ipxe.git 122 cd ipxe/src 123 make bin-arm64-efi/snp.efi -j6 EMBED=myscript.ipxe 124 125 The available commands for the boot script are documented at: 126 127 http://ipxe.org/cmd 128 129 Credentials are managed as environment variables. These are described here: 130 131 http://ipxe.org/cfg 132 133 iPXE by default will put the CPU to rest when waiting for input. U-Boot does 134 not wake it up due to missing interrupt support. To avoid this behavior create 135 file src/config/local/nap.h. 136 137 /* nap.h */ 138 #undef NAP_EFIX86 139 #undef NAP_EFIARM 140 #define NAP_NULL 141 142 The supported commands in iPXE are controlled by an include, too. Putting the 143 following into src/config/local/general.h is sufficient for most use cases. 144 145 /* general.h */ 146 #define NSLOOKUP_CMD /* Name resolution command */ 147 #define PING_CMD /* Ping command */ 148 #define NTP_CMD /* NTP commands */ 149 #define VLAN_CMD /* VLAN commands */ 150 #define IMAGE_EFI /* EFI image support */ 151 #define DOWNLOAD_PROTO_HTTPS /* Secure Hypertext Transfer Protocol */ 152 #define DOWNLOAD_PROTO_FTP /* File Transfer Protocol */ 153 #define DOWNLOAD_PROTO_NFS /* Network File System Protocol */ 154 #define DOWNLOAD_PROTO_FILE /* Local file system access */ 155 156 ## Links 157 158 * https://ipxe.org - iPXE open source boot firmware 159 * https://www.gnu.org/software/grub/ - GNU Grub (Grand Unified Bootloader) 160
README.JFFS2
1 JFFS2 options and usage. 2 ----------------------- 3 4 JFFS2 in U-Boot is a read only implementation of the file system in 5 Linux with the same name. To use JFFS2 define CONFIG_CMD_JFFS2. 6 7 The module adds three new commands. 8 fsload - load binary file from a file system image 9 fsinfo - print information about file systems 10 ls - list files in a directory 11 chpart - change active partition 12 13 If you do now need the commands, you can enable the filesystem separately 14 with CONFIG_FS_JFFS2 and call the jffs2 functions yourself. 15 16 If you boot from a partition which is mounted writable, and you 17 update your boot environment by replacing single files on that 18 partition, you should also define CONFIG_SYS_JFFS2_SORT_FRAGMENTS. Scanning 19 the JFFS2 filesystem takes *much* longer with this feature, though. 20 Sorting is done while inserting into the fragment list, which is 21 more or less a bubble sort. That algorithm is known to be O(n^2), 22 thus you should really consider if you can avoid it! 23 24 25 There only one way for JFFS2 to find the disk. It uses the flash_info 26 structure to find the start of a JFFS2 disk (called partition in the code) 27 and you can change where the partition is with two defines. 28 29 CONFIG_SYS_JFFS2_FIRST_BANK 30 defined the first flash bank to use 31 32 CONFIG_SYS_JFFS2_FIRST_SECTOR 33 defines the first sector to use 34 --- 35 36 TODO. 37 38 Remove the assumption that JFFS can dereference a pointer 39 into the disk. The current code do not work with memory holes 40 or hardware with a sliding window (PCMCIA). 41
README.JFFS2_NAND
1 JFFS2 NAND support: 2 3 To enable, use the following #define in the board configuration file: 4 5 #define CONFIG_JFFS2_NAND 6 7 Configuration of partitions is similar to how this is done in U-Boot 8 for JFFS2 on top NOR flash. 9
README.kconfig
1 Kconfig in U-Boot 2 ================= 3 4 This document describes the configuration infrastructure of U-Boot. 5 6 The conventional configuration was replaced by Kconfig at v2014.10-rc1 release. 7 8 9 Language Specification 10 ---------------------- 11 12 Kconfig originates in Linux Kernel. 13 See the file "Documentation/kbuild/kconfig*.txt" in your Linux Kernel 14 source directory for a basic specification of Kconfig. 15 16 17 Difference from Linux's Kconfig 18 ------------------------------- 19 20 Here are some worth-mentioning configuration targets. 21 22 - silentoldconfig 23 24 This target updates .config, include/generated/autoconf.h and 25 include/configs/* as in Linux. In U-Boot, it also does the following 26 for the compatibility with the old configuration system: 27 28 * create a symbolic link "arch/${ARCH}/include/asm/arch" pointing to 29 the SoC/CPU specific header directory 30 * create include/config.h 31 * create include/autoconf.mk 32 * create spl/include/autoconf.mk (SPL and TPL only) 33 * create tpl/include/autoconf.mk (TPL only) 34 35 If we could completely switch to Kconfig in a long run 36 (i.e. remove all the include/configs/*.h), those additional processings 37 above would be removed. 38 39 - defconfig 40 41 In U-Boot, "make defconfig" is a shorthand of "make sandbox_defconfig" 42 43 - <board>_defconfig 44 45 Now it works as in Linux. 46 The prefixes such as "+S:" in *_defconfig are deprecated. 47 You can simply remove the prefixes. Do not add them for new boards. 48 49 - <board>_config 50 51 This does not exist in Linux's Kconfig. 52 "make <board>_config" works the same as "make <board>_defconfig". 53 Prior to Kconfig, in U-Boot, "make <board>_config" was used for the 54 configuration. It is still supported for backward compatibility, so 55 we do not need to update the distro recipes. 56 57 58 The other configuration targets work as in Linux Kernel. 59 60 61 Migration steps to Kconfig 62 -------------------------- 63 64 Prior to Kconfig, the C preprocessor based board configuration had been used 65 in U-Boot. 66 67 Although Kconfig was introduced and some configs have been moved to Kconfig, 68 many of configs are still defined in C header files. It will take a very 69 long term to move all of them to Kconfig. In the interim, the two different 70 configuration infrastructures should coexist. 71 The configuration files are generated by both Kconfig and the old preprocessor 72 based configuration as follows: 73 74 Configuration files for use in C sources 75 - include/generated/autoconf.h (generated by Kconfig for Normal) 76 - include/configs/<board>.h (exists for all boards) 77 78 Configuration file for use in makefiles 79 - include/config/auto.conf (generated by Kconfig) 80 - include/autoconf.mk (generated by the old config for Normal) 81 - spl/include/autoconfig.mk (generated by the old config for SPL) 82 - tpl/include/autoconfig.mk (generated by the old config for TPL) 83 84 When adding a new CONFIG macro, it is highly recommended to add it to Kconfig 85 rather than to a header file. 86 87 88 Conversion from boards.cfg to Kconfig 89 ------------------------------------- 90 91 Prior to Kconfig, boards.cfg was a primary database that contained Arch, CPU, 92 SoC, etc. of all the supported boards. It was deleted when switching to 93 Kconfig. Each field of boards.cfg was converted as follows: 94 95 Status -> "S:" entry of MAINTAINERS 96 Arch -> CONFIG_SYS_ARCH defined by Kconfig 97 CPU -> CONFIG_SYS_CPU defined by Kconfig 98 SoC -> CONFIG_SYS_SOC defined by Kconfig 99 Vendor -> CONFIG_SYS_VENDOR defined by Kconfig 100 Board -> CONFIG_SYS_BOARD defined by Kconfig 101 Target -> File name of defconfig (configs/<target>_defconfig) 102 Options -> CONFIG_SYS_EXTRA_OPTIONS defined by Kconfig 103 Maintainers -> "M:" entry of MAINTAINERS 104 105 106 Tips to add/remove boards 107 ------------------------- 108 109 When adding a new board, the following steps are generally needed: 110 111 [1] Add a header file include/configs/<target>.h 112 [2] Make sure to define necessary CONFIG_SYS_* in Kconfig: 113 Define CONFIG_SYS_CPU="cpu" to compile arch/<arch>/cpu/<cpu> 114 Define CONFIG_SYS_SOC="soc" to compile arch/<arch>/cpu/<cpu>/<soc> 115 Define CONFIG_SYS_VENDOR="vendor" to compile board/<vendor>/common/* 116 and board/<vendor>/<board>/* 117 Define CONFIG_SYS_BOARD="board" to compile board/<board>/* 118 (or board/<vendor>/<board>/* if CONFIG_SYS_VENDOR is defined) 119 Define CONFIG_SYS_CONFIG_NAME="target" to include 120 include/configs/<target>.h 121 [3] Add a new entry to the board select menu in Kconfig. 122 The board select menu is located in arch/<arch>/Kconfig or 123 arch/<arch>/*/Kconfig. 124 [4] Add a MAINTAINERS file 125 It is generally placed at board/<board>/MAINTAINERS or 126 board/<vendor>/<board>/MAINTAINERS 127 [5] Add configs/<target>_defconfig 128 129 When removing an obsolete board, the following steps are generally needed: 130 131 [1] Remove configs/<target>_defconfig 132 [2] Remove include/configs/<target>.h if it is not used by any other boards 133 [3] Remove board/<vendor>/<board>/* or board/<board>/* if it is not used 134 by any other boards 135 [4] Update MAINTAINERS if necessary 136 [5] Remove the unused entry from the board select menu in Kconfig 137 [6] Add an entry to doc/README.scrapyard 138 139 140 TODO 141 ---- 142 143 - The option field of boards.cfg, which was used for the pre-Kconfig 144 configuration, moved to CONFIG_SYS_EXTRA_OPTIONS verbatim now. 145 Board maintainers are expected to implement proper Kconfig options 146 and switch over to them. Eventually CONFIG_SYS_EXTRA_OPTIONS will go away. 147 CONFIG_SYS_EXTRA_OPTIONS should not be used for new boards. 148 149 - In the pre-Kconfig, a single board had multiple entries in the boards.cfg 150 file with differences in the option fields. The corresponding defconfig 151 files were auto-generated when switching to Kconfig. Now we have too many 152 defconfig files compared with the number of the supported boards. It is 153 recommended to have only one defconfig per board and allow users to select 154 the config options. 155 156 - Move the config macros in header files to Kconfig. When we move at least 157 macros used in makefiles, we can drop include/autoconfig.mk, which makes 158 the build scripts much simpler. 159
README.kwbimage
1 --------------------------------------------- 2 Kirkwood Boot Image generation using mkimage 3 --------------------------------------------- 4 5 This document describes the U-Boot feature as it 6 is implemented for the Kirkwood family of SoCs. 7 8 The Kirkwood SoC's can boot directly from NAND FLASH, 9 SPI FLASH, SATA etc. using its internal bootRom support. 10 11 for more details refer section 24.2 of Kirkwood functional specifications. 12 ref: www.marvell.com/products/embedded.../kirkwood/index.jsp 13 14 Command syntax: 15 -------------- 16 ./tools/mkimage -l <kwboot_file> 17 to list the kwb image file details 18 19 ./tools/mkimage -n <board specific configuration file> \ 20 -T kwbimage -a <start address> -e <execution address> \ 21 -d <input_raw_binary> <output_kwboot_file> 22 23 for ex. 24 ./tools/mkimage -n ./board/Marvell/openrd_base/kwbimage.cfg \ 25 -T kwbimage -a 0x00600000 -e 0x00600000 \ 26 -d u-boot.bin u-boot.kwb 27 28 29 kwbimage support available with mkimage utility will generate kirkwood boot 30 image that can be flashed on the board NAND/SPI flash. The make target 31 which uses mkimage to produce such an image is "u-boot.kwb". For example: 32 33 export KBUILD_OUTPUT=/tmp/build 34 make distclean 35 make yourboard_config 36 make u-boot.kwb 37 38 39 Board specific configuration file specifications: 40 ------------------------------------------------ 41 1. This file must present in the $(BOARDDIR). The default name is 42 kwbimage.cfg. The name can be set as part of the full path 43 to the file using CONFIG_SYS_KWD_CONFIG (probably in 44 include/configs/<yourboard>.h). The path should look like: 45 $(CONFIG_BOARDDIR)/<yourkwbimagename>.cfg 46 2. This file can have empty lines and lines starting with "#" as first 47 character to put comments 48 3. This file can have configuration command lines as mentioned below, 49 any other information in this file is treated as invalid. 50 51 Configuration command line syntax: 52 --------------------------------- 53 1. Each command line is must have two strings, first one command or address 54 and second one data string 55 2. Following are the valid command strings and associated data strings:- 56 Command string data string 57 -------------- ----------- 58 BOOT_FROM nand/spi/sata 59 NAND_ECC_MODE default/rs/hamming/disabled 60 NAND_PAGE_SIZE any uint16_t hex value 61 SATA_PIO_MODE any uint32_t hex value 62 DDR_INIT_DELAY any uint32_t hex value 63 DATA regaddr and regdara hex value 64 you can have maximum 55 such register programming commands 65 66 3. All commands are optional to program 67 68 Typical example of kwimage.cfg file: 69 ----------------------------------- 70 71 # Boot Media configurations 72 BOOT_FROM nand 73 NAND_ECC_MODE default 74 NAND_PAGE_SIZE 0x0800 75 76 # Configure RGMII-0 interface pad voltage to 1.8V 77 DATA 0xFFD100e0 0x1b1b1b9b 78 # DRAM Configuration 79 DATA 0xFFD01400 0x43000c30 80 DATA 0xFFD01404 0x37543000 81 DATA 0xFFD01408 0x22125451 82 DATA 0xFFD0140C 0x00000a33 83 DATA 0xFFD01410 0x000000cc 84 DATA 0xFFD01414 0x00000000 85 DATA 0xFFD01418 0x00000000 86 DATA 0xFFD0141C 0x00000C52 87 DATA 0xFFD01420 0x00000040 88 DATA 0xFFD01424 0x0000F17F 89 DATA 0xFFD01428 0x00085520 90 DATA 0xFFD0147C 0x00008552 91 DATA 0xFFD01504 0x0FFFFFF1 92 DATA 0xFFD01508 0x10000000 93 DATA 0xFFD0150C 0x0FFFFFF5 94 DATA 0xFFD01514 0x00000000 95 DATA 0xFFD0151C 0x00000000 96 DATA 0xFFD01494 0x00030000 97 DATA 0xFFD01498 0x00000000 98 DATA 0xFFD0149C 0x0000E803 99 DATA 0xFFD01480 0x00000001 100 # End of Header extension 101 DATA 0x0 0x0 102 103 ------------------------------------------------ 104 Author: Prafulla Wadaskar <prafulla (a] marvell.com> 105
README.LED
1 Status LED 2 ======================================== 3 4 This README describes the status LED API. 5 6 The API is defined by the include file include/status_led.h 7 8 The first step is to enable CONFIG_LED_STATUS in menuconfig: 9 > Device Drivers > LED Support. 10 11 If the LED support is only for specific board, enable 12 CONFIG_LED_STATUS_BOARD_SPECIFIC in the menuconfig. 13 14 Status LEDS 0 to 5 are enabled by the following configurations at menuconfig: 15 CONFIG_STATUS_LED0, CONFIG_STATUS_LED1, ... CONFIG_STATUS_LED5 16 17 The following should be configured for each of the enabled LEDs: 18 CONFIG_STATUS_LED_BIT<n> 19 CONFIG_STATUS_LED_STATE<n> 20 CONFIG_STATUS_LED_FREQ<n> 21 Where <n> is an integer 1 through 5 (empty for 0). 22 23 CONFIG_STATUS_LED_BIT is passed into the __led_* functions to identify which LED 24 is being acted on. As such, the value choose must be unique with with respect to 25 the other CONFIG_STATUS_LED_BIT's. Mapping the value to a physical LED is the 26 reponsiblity of the __led_* function. 27 28 CONFIG_STATUS_LED_STATE is the initial state of the LED. It should be set to one 29 of these values: CONFIG_LED_STATUS_OFF or CONFIG_LED_STATUS_ON. 30 31 CONFIG_STATUS_LED_FREQ determines the LED blink frequency. 32 Values range from 2 to 10. 33 34 Some other LED macros 35 --------------------- 36 37 CONFIG_STATUS_LED_BOOT is the LED to light when the board is booting. 38 This must be a valid LED number (0-5). 39 40 CONFIG_STATUS_LED_RED is the red LED. It is used to signal errors. This must be 41 a valid LED number (0-5). Other similar color LED's macros are 42 CONFIG_STATUS_LED_GREEN, CONFIG_STATUS_LED_YELLOW and CONFIG_STATUS_LED_BLUE. 43 44 General LED functions 45 --------------------- 46 The following functions should be defined: 47 48 __led_init is called once to initialize the LED to CONFIG_STATUS_LED_STATE. 49 One time start up code should be placed here. 50 51 __led_set is called to change the state of the LED. 52 53 __led_toggle is called to toggle the current state of the LED. 54 55 Colour LED 56 ======================================== 57 58 Colour LED's are at present only used by ARM. 59 60 The functions names explain their purpose. 61 62 coloured_LED_init 63 red_LED_on 64 red_LED_off 65 green_LED_on 66 green_LED_off 67 yellow_LED_on 68 yellow_LED_off 69 blue_LED_on 70 blue_LED_off 71 72 These are weakly defined in arch/arm/lib/board.c to noops. Where applicable, define 73 these functions in the board specific source. 74 75 TBD : Describe older board dependent macros similar to what is done for 76 77 TBD : Describe general support via asm/status_led.h 78
README.LED_display
1 LED display internal API 2 ======================================= 3 4 This README describes the LED display API. 5 6 The API is defined by the include file include/led-display.h 7 8 The first step in to define CONFIG_CMD_DISPLAY in the board config file. 9 Then you need to provide the following functions to access LED display: 10 11 void display_set(int cmd); 12 13 This function should control the state of the LED display. Argument is 14 an ORed combination of the following values: 15 DISPLAY_CLEAR -- clear the display 16 DISPLAY_HOME -- set the position to the beginning of display 17 18 int display_putc(char c); 19 20 This function should display it's parameter on the LED display in the 21 current position. Returns the displayed character on success or -1 in 22 case of failure. 23 24 With this functions defined 'display' command will display it's 25 arguments on the LED display (or clear the display if called without 26 arguments). 27
README.link-local
1 ------------------------------------------ 2 Link-local IP address auto-configuration 3 ------------------------------------------ 4 5 Negotiate with other link-local clients on the local network 6 for an address that doesn't require explicit configuration. 7 This is especially useful if a DHCP server cannot be guaranteed 8 to exist in all environments that the device must operate. 9 10 This is an implementation of RFC3927. 11 12 ---------- 13 Commands 14 ---------- 15 16 When CONFIG_CMD_LINK_LOCAL is defined in the board config file, 17 the "linklocal" command is available. This running this will 18 take approximately 5 seconds while the address is negotiated. 19 20 ------------------------ 21 Environment interation 22 ------------------------ 23 24 The "llipaddr" variable is set with the most recently 25 negotiated address and is preferred in future negotiations. 26 27 The "ipaddr", "netmask", and "gatewayip" variables are set 28 after successful negotiation to enable network access. 29 30 ------------- 31 Limitations 32 ------------- 33 34 RFC3927 requires that addresses are continuously checked to 35 avoid conflicts, however this can only happen when the net_loop 36 is getting called. It is possible for a conflict to go undetected 37 until a command that accesses the network is executed. 38 39 Using NetConsole is one way to ensure that net_loop is always 40 processing packets and monitoring for conflicts. 41 42 This is also not a concern if the feature is use to connect 43 directly to another machine that may not be running a DHCP server. 44 45 ---------------- 46 Example script 47 ---------------- 48 49 This script allows use of DHCP and/or Link-local controlled 50 by env variables. It depends on CONFIG_CMD_LINK_LOCAL, CONFIG_CMD_DHCP, 51 and CONFIG_BOOTP_MAY_FAIL. 52 If both fail or are disabled, static settings are used. 53 54 #define CONFIG_EXTRA_ENV_SETTINGS \ 55 "ipconfigcmd=if test \\\"$dhcpenabled\\\" -ne 0;" \ 56 "then " \ 57 "dhcpfail=0;dhcp || dhcpfail=1;" \ 58 "else " \ 59 "dhcpfail=-1;" \ 60 "fi;" \ 61 "if test \\\"$linklocalenabled\\\" -ne 0 -a " \ 62 "\\\"$dhcpfail\\\" -ne 0;" \ 63 "then " \ 64 "linklocal;" \ 65 "llfail=0;" \ 66 "else " \ 67 "llfail=-1;" \ 68 "fi;" \ 69 "if test \\\"$llfail\\\" -ne 0 -a " \ 70 "\\\"$dhcpfail\\\" -ne 0; " \ 71 "then " \ 72 "setenv ipaddr $sipaddr; " \ 73 "setenv netmask $snetmask; " \ 74 "setenv gatewayip $sgatewayip; " \ 75 "fi;\0" \ 76
README.log
1 Logging in U-Boot 2 ================= 3 4 Introduction 5 ------------ 6 7 U-Boot's internal operation involves many different steps and actions. From 8 setting up the board to displaying a start-up screen to loading an Operating 9 System, there are many component parts each with many actions. 10 11 Most of the time this internal detail is not useful. Displaying it on the 12 console would delay booting (U-Boot's primary purpose) and confuse users. 13 14 But for digging into what is happening in a particular area, or for debugging 15 a problem it is often useful to see what U-Boot is doing in more detail than 16 is visible from the basic console output. 17 18 U-Boot's logging feature aims to satisfy this goal for both users and 19 developers. 20 21 22 Logging levels 23 -------------- 24 25 There are a number logging levels available, in increasing order of verbosity: 26 27 LOGL_EMERG - Printed before U-Boot halts 28 LOGL_ALERT - Indicates action must be taken immediate or U-Boot will crash 29 LOGL_CRIT - Indicates a critical error that will cause boot failure 30 LOGL_ERR - Indicates an error that may cause boot failure 31 LOGL_WARNING - Warning about an unexpected condition 32 LOGL_NOTE - Important information about progress 33 LOGL_INFO - Information about normal boot progress 34 LOGL_DEBUG - Debug information (useful for debugging a driver or subsystem) 35 LOGL_DEBUG_CONTENT - Debug message showing full message content 36 LOGL_DEBUG_IO - Debug message showing hardware I/O access 37 38 39 Logging category 40 ---------------- 41 42 Logging can come from a wide variety of places within U-Boot. Each log message 43 has a category which is intended to allow messages to be filtered according to 44 their source. 45 46 The following main categories are defined: 47 48 LOGC_NONE - Unknown category (e.g. a debug() statement) 49 UCLASS_... - Related to a particular uclass (e.g. UCLASS_USB) 50 LOGC_ARCH - Related to architecture-specific code 51 LOGC_BOARD - Related to board-specific code 52 LOGC_CORE - Related to core driver-model support 53 LOGC_DT - Related to device tree control 54 LOGC_EFI - Related to EFI implementation 55 56 57 Enabling logging 58 ---------------- 59 60 The following options are used to enable logging at compile time: 61 62 CONFIG_LOG - Enables the logging system 63 CONFIG_MAX_LOG_LEVEL - Max log level to build (anything higher is compiled 64 out) 65 CONFIG_LOG_CONSOLE - Enable writing log records to the console 66 67 If CONFIG_LOG is not set, then no logging will be available. 68 69 The above have SPL versions also, e.g. CONFIG_SPL_MAX_LOG_LEVEL. 70 71 72 Log commands 73 ------------ 74 75 The 'log' command provides access to several features: 76 77 level - access the default log level 78 format - access the console log format 79 rec - output a log record 80 test - run tests 81 82 Type 'help log' for details. 83 84 85 Using DEBUG 86 ----------- 87 88 U-Boot has traditionally used a #define called DEBUG to enable debugging on a 89 file-by-file basis. The debug() macro compiles to a printf() statement if 90 DEBUG is enabled, and an empty statement if not. 91 92 With logging enabled, debug() statements are interpreted as logging output 93 with a level of LOGL_DEBUG and a category of LOGC_NONE. 94 95 The logging facilities are intended to replace DEBUG, but if DEBUG is defined 96 at the top of a file, then it takes precedence. This means that debug() 97 statements will result in output to the console and this output will not be 98 logged. 99 100 101 Logging destinations 102 -------------------- 103 104 If logging information goes nowhere then it serves no purpose. U-Boot provides 105 several possible determinations for logging information, all of which can be 106 enabled or disabled independently: 107 108 console - goes to stdout 109 110 111 Log format 112 ---------- 113 114 You can control the log format using the 'log format' command. The basic 115 format is: 116 117 LEVEL.category,file.c:123-func() message 118 119 In the above, file.c:123 is the filename where the log record was generated and 120 func() is the function name. By default ('log format default') only the 121 function name and message are displayed on the console. You can control which 122 fields are present, but not the field order. 123 124 125 Filters 126 ------- 127 128 Filters are attached to log drivers to control what those drivers emit. Only 129 records that pass through the filter make it to the driver. 130 131 Filters can be based on several criteria: 132 133 - maximum log level 134 - in a set of categories 135 - in a set of files 136 137 If no filters are attached to a driver then a default filter is used, which 138 limits output to records with a level less than CONFIG_LOG_MAX_LEVEL. 139 140 141 Logging statements 142 ------------------ 143 144 The main logging function is: 145 146 log(category, level, format_string, ...) 147 148 Also debug() and error() will generate log records - these use LOG_CATEGORY 149 as the category, so you should #define this right at the top of the source 150 file to ensure the category is correct. 151 152 You can also define CONFIG_LOG_ERROR_RETURN to enable the log_ret() macro. This 153 can be used whenever your function returns an error value: 154 155 return log_ret(uclass_first_device(UCLASS_MMC, &dev)); 156 157 This will write a log record when an error code is detected (a value < 0). This 158 can make it easier to trace errors that are generated deep in the call stack. 159 160 161 Code size 162 --------- 163 164 Code size impact depends largely on what is enabled. The following numbers are 165 generated by 'buildman -S' for snow, which is a Thumb-2 board (all units in 166 bytes): 167 168 This series: adds bss +20.0 data +4.0 rodata +4.0 text +44.0 169 CONFIG_LOG: bss -52.0 data +92.0 rodata -635.0 text +1048.0 170 CONFIG_LOG_MAX_LEVEL=7: bss +188.0 data +4.0 rodata +49183.0 text +98124.0 171 172 The last option turns every debug() statement into a logging call, which 173 bloats the code hugely. The advantage is that it is then possible to enable 174 all logging within U-Boot. 175 176 177 To Do 178 ----- 179 180 There are lots of useful additions that could be made. None of the below is 181 implemented! If you do one, please add a test in test/py/tests/test_log.py 182 183 Convenience functions to support setting the category: 184 185 log_arch(level, format_string, ...) - category LOGC_ARCH 186 log_board(level, format_string, ...) - category LOGC_BOARD 187 log_core(level, format_string, ...) - category LOGC_CORE 188 log_dt(level, format_string, ...) - category LOGC_DT 189 190 Convenience functions to support a category defined for a single file, for 191 example: 192 193 #define LOG_CATEGORY UCLASS_USB 194 195 all of these can use LOG_CATEGORY as the category, and a log level 196 corresponding to the function name: 197 198 logc(level, format_string, ...) 199 200 More logging destinations: 201 202 device - goes to a device (e.g. serial) 203 buffer - recorded in a memory buffer 204 205 Convert debug() statements in the code to log() statements 206 207 Support making printf() emit log statements a L_INFO level 208 209 Convert error() statements in the code to log() statements 210 211 Figure out what to do with BUG(), BUG_ON() and warn_non_spl() 212 213 Figure out what to do with assert() 214 215 Add a way to browse log records 216 217 Add a way to record log records for browsing using an external tool 218 219 Add commands to add and remove filters 220 221 Add commands to add and remove log devices 222 223 Allow sharing of printf format strings in log records to reduce storage size 224 for large numbers of log records 225 226 Add a command-line option to sandbox to set the default logging level 227 228 Convert core driver model code to use logging 229 230 Convert uclasses to use logging with the correct category 231 232 Consider making log() calls emit an automatic newline, perhaps with a logn() 233 function to avoid that 234 235 Passing log records through to linux (e.g. via device tree /chosen) 236 237 Provide a command to access the number of log records generated, and the 238 number dropped due to them being generated before the log system was ready. 239 240 Add a printf() format string pragma so that log statements are checked properly 241 242 Enhance the log console driver to show level / category / file / line 243 information 244 245 Add a command to add new log records and delete existing records. 246 247 Provide additional log() functions - e.g. logc() to specify the category 248 249 -- 250 Simon Glass <sjg (a] chromium.org> 251 15-Sep-17 252
README.lynxkdi
1 LYNX KDI SUPPORT 2 3 Last Update: July 20, 2003 4 ======================================================================= 5 6 This file describes support for LynuxWorks KDI within U-Boot. Support 7 is enabled by defining CONFIG_LYNXKDI. 8 9 10 LYNXOS AND BLUECAT SUPPORTED 11 ============================ 12 Both LynxOS and BlueCat linux KDIs are supported. The implementation 13 automatically detects which is being booted. When you use mkimage 14 you should specify "lynxos" for both (see target-specific notes). 15 16 17 SUPPORTED ARCHITECTURE/TARGETS 18 ============================== 19 The following targets have been tested: 20 21 -PowerPC MPC8260ADS 22 23 24 FILES TO LOOK AT 25 ================ 26 include/lynxkdi.h -defines a simple struct passed to a kdi. 27 common/lynxkdi.c -implements the call to the kdi. 28 common/cmd_bootm.c -top-level command implementation ("bootm"). 29 30 31 ==================================================================== 32 TARGET SPECIFIC NOTES 33 ==================================================================== 34 35 MPC8260ADS 36 =========== 37 The default LynxOS and BlueCat implementations require some 38 modifications to the config file. 39 40 Edit include/configs/MPC8260ADS.h to use the following: 41 42 #define CONFIG_SYS_IMMR 0xFA200000 43 #define CONFIG_SYS_BCSR 0xFA100000 44 #define CONFIG_SYS_BR1_PRELIM 0xFA101801 45 46 When creating a LynxOS or BlueCat u-boot image using mkimage, 47 you must specify the following: 48 49 Both: -A ppc -O lynxos -T kernel -C none 50 LynxOS: -a 0x00004000 -e 0x00004020 51 BlueCat: -a 0x00500000 -e 0x00507000 52 53 To pass the MAC address to BlueCat you should define the 54 "fcc2_ether_addr" parameter in the "bootargs" environment 55 variable. E.g.: 56 57 ==> setenv bootargs fcc2_ether_addr=00:11:22:33:44:55:66 58
README.m54418twr
1 Freescale MCF54418TWR ColdFire Development Board 2 ================================================ 3 4 TsiChung Liew(Tsi-Chung.Liew (a] freescale.com) 5 Created Mar 22, 2012 6 =========================================== 7 8 9 Changed files: 10 ============== 11 12 - board/freescale/m54418twr/m54418twr.c Dram setup 13 - board/freescale/m54418twr/Makefile Makefile 14 - board/freescale/m54418twr/config.mk config make 15 - board/freescale/m54418twr/u-boot.lds Linker description 16 - board/freescale/m54418twr/sbf_dram_init.S 17 DDR/SDRAM initialization 18 19 - arch/m68k/cpu/mcf5445x/cpu.c cpu specific code 20 - arch/m68k/cpu/mcf5445x/cpu_init.c Flexbus ChipSelect, Mux pins setup, icache and RTC extra regs 21 - arch/m68k/cpu/mcf5445x/interrupts.c cpu specific interrupt support 22 - arch/m68k/cpu/mcf5445x/speed.c system, pci, flexbus, and cpu clock 23 - arch/m68k/cpu/mcf5445x/Makefile Makefile 24 - arch/m68k/cpu/mcf5445x/config.mk config make 25 - arch/m68k/cpu/mcf5445x/start.S start up assembly code 26 27 - doc/README.m54418twr This readme file 28 29 - drivers/net/mcffec.c ColdFire common FEC driver 30 - drivers/net/mcfmii.c ColdFire common MII driver 31 - drivers/serial/mcfuart.c ColdFire common UART driver 32 33 - arch/m68k/include/asm/bitops.h Bit operation function export 34 - arch/m68k/include/asm/byteorder.h Byte order functions 35 - arch/m68k/include/asm/fec.h FEC structure and definition 36 - arch/m68k/include/asm/global_data.h Global data structure 37 - arch/m68k/include/asm/immap.h ColdFire specific header file and driver macros 38 - arch/m68k/include/asm/immap_5441x.h mcf5441x specific header file 39 - arch/m68k/include/asm/io.h io functions 40 - arch/m68k/include/asm/m5441x.h mcf5441x specific header file 41 - arch/m68k/include/asm/posix_types.h Posix 42 - arch/m68k/include/asm/processor.h header file 43 - arch/m68k/include/asm/ptrace.h Exception structure 44 - arch/m68k/include/asm/rtc.h Realtime clock header file 45 - arch/m68k/include/asm/string.h String function export 46 - arch/m68k/include/asm/timer.h Timer structure and definition 47 - arch/m68k/include/asm/types.h Data types definition 48 - arch/m68k/include/asm/uart.h Uart structure and definition 49 - arch/m68k/include/asm/u-boot.h u-boot structure 50 51 - include/configs/M54418TWR.h Board specific configuration file 52 53 - arch/m68k/lib/board.c board init function 54 - arch/m68k/lib/cache.c 55 - arch/m68k/lib/interrupts.c Coldfire common interrupt functions 56 - arch/m68k/lib/time.c Timer functions (Dma timer and PIT) 57 - arch/m68k/lib/traps.c Exception init code 58 59 1 MCF5441x specific Options/Settings 60 ==================================== 61 1.1 pre-loader is no longer suppoer in thie coldfire family 62 63 1.2 Configuration settings for M54418TWR Development Board 64 CONFIG_MCF5441x -- define for all MCF5441x CPUs 65 CONFIG_M54418 -- define for all Freescale MCF54418 CPUs 66 67 CONFIG_MCFUART -- define to use common CF Uart driver 68 CONFIG_SYS_UART_PORT -- define UART port number, start with 0, 1 and 2 69 CONFIG_BAUDRATE -- define UART baudrate 70 71 CONFIG_MCFFEC -- define to use common CF FEC driver 72 CONFIG_MII -- enable to use MII driver 73 CONFIG_SYS_DISCOVER_PHY -- enable PHY discovery 74 CONFIG_SYS_RX_ETH_BUFFER -- Set FEC Receive buffer 75 CONFIG_SYS_FAULT_ECHO_LINK_DOWN -- 76 CONFIG_SYS_FEC0_PINMUX -- Set FEC0 Pin configuration 77 CONFIG_SYS_FEC1_PINMUX -- Set FEC1 Pin configuration 78 CONFIG_SYS_FEC0_MIIBASE -- Set FEC0 MII base register 79 CONFIG_SYS_FEC1_MIIBASE -- Set FEC0 MII base register 80 MCFFEC_TOUT_LOOP -- set FEC timeout loop 81 CONFIG_HAS_ETH1 -- define to enable second FEC in u-boot 82 83 CONFIG_MCFTMR -- define to use DMA timer 84 85 CONFIG_SYS_IMMR -- define for MBAR offset 86 87 CONFIG_EXTRA_CLOCK -- Enable extra clock such as vco, flexbus, pci, etc 88 89 CONFIG_SYS_MBAR -- define MBAR offset 90 91 CONFIG_MONITOR_IS_IN_RAM -- Not support 92 93 CONFIG_SYS_INIT_RAM_ADDR -- defines the base address of the MCF54455 internal SRAM 94 95 CONFIG_SYS_CSn_BASE -- defines the Chip Select Base register 96 CONFIG_SYS_CSn_MASK -- defines the Chip Select Mask register 97 CONFIG_SYS_CSn_CTRL -- defines the Chip Select Control register 98 99 CONFIG_SYS_SDRAM_BASE -- defines the DRAM Base 100 101 2. MEMORY MAP UNDER U-BOOT AND LINUX KERNEL 102 =========================================== 103 2.1. System memory map: 104 MRAM: 0x00000000-0x0003FFFF (256KB) 105 DDR: 0x40000000-0x47FFFFFF (128MB) 106 SRAM: 0x80000000-0x8000FFFF (64KB) 107 IP: 0xE0000000-0xFFFFFFFF (512MB) 108 109 3. COMPILATION 110 ============== 111 3.1 To create U-Boot the gcc-4.x compiler set (ColdFire ELF version) 112 from codesourcery.com was used. Download it from: 113 http://www.codesourcery.com/gnu_toolchains/coldfire/download.html 114 115 3.2 Compilation 116 export CROSS_COMPILE=cross-compile-prefix 117 cd u-boot 118 make distclean 119 make M54418TWR_config, or - default to spi serial flash boot, 50Mhz input clock 120 make M54418TWR_nand_mii_config, or - default to nand flash boot, mii mode, 25Mhz input clock 121 make M54418TWR_nand_rmii_config, or - default to nand flash boot, rmii mode, 50Mhz input clock 122 make M54418TWR_nand_rmii_lowfreq_config, or - default to nand flash boot, rmii mode, 50Mhz input clock 123 make M54418TWR_serial_mii_config, or - default to spi serial flash boot, 25Mhz input clock 124 make M54418TWR_serial_rmii_config, or - default to spi serial flash boot, 50Mhz input clock 125 make 126 127 4. SCREEN DUMP 128 ============== 129 4.1 M54418TWR Development board 130 Boot from NAND flash (NOTE: May not show exactly the same) 131 132 U-Boot 2012.10-00209-g12ae1d8-dirty (Oct 18 2012 - 15:54:54) 133 134 CPU: Freescale MCF54418 (Mask:a3 Version:1) 135 CPU CLK 250 MHz BUS CLK 125 MHz FLB CLK 125 MHz 136 INP CLK 50 MHz VCO CLK 500 MHz 137 Board: Freescale MCF54418 Tower System 138 SPI: ready 139 DRAM: 128 MiB 140 NAND: 256 MiB 141 In: serial 142 Out: serial 143 Err: serial 144 Net: FEC0, FEC1 145 -> pri 146 baudrate=115200 147 bootargs=root=/dev/mtdblock2 rw rootfstype=jffs2 mtdparts=NAND:1M(u-boot)ro,7M(k 148 ernel)ro,-(jffs2) console=ttyS0,115200 149 bootdelay=2 150 eth1addr=00:e0:0c:bc:e5:61 151 ethact=FEC0 152 ethaddr=00:e0:0c:bc:e5:60 153 fileaddr=40010000 154 filesize=27354 155 gatewayip=192.168.1.1 156 hostname=M54418TWR 157 inpclk=50000000 158 ipaddr=192.168.1.2 159 load=tftp ${loadaddr} ${u-boot}; 160 loadaddr=0x40010000 161 mem=129024k 162 netdev=eth0 163 netmask=255.255.255.0 164 prog=nand device 0;nand erase 0 40000;nb_update ${loadaddr} ${filesize};save 165 serverip=192.168.1.1 166 stderr=serial 167 stdin=serial 168 stdout=serial 169 u-boot=u-boot.bin 170 upd=run load; run prog 171 172 Environment size: 653/131068 bytes 173 -> bdinfo 174 memstart = 0x40000000 175 memsize = 0x08000000 176 flashstart = 0x00000000 177 flashsize = 0x00000000 178 flashoffset = 0x00000000 179 sramstart = 0x80000000 180 sramsize = 0x00010000 181 mbar = 0xFC000000 182 cpufreq = 250 MHz 183 busfreq = 125 MHz 184 flbfreq = 125 MHz 185 inpfreq = 50 MHz 186 vcofreq = 500 MHz 187 ethaddr = 00:e0:0c:bc:e5:60 188 eth1addr = 00:e0:0c:bc:e5:61 189 ip_addr = 192.168.1.2 190 baudrate = 115200 bps 191 -> help 192 ? - alias for 'help' 193 base - print or set address offset 194 bdinfo - print Board Info structure 195 boot - boot default, i.e., run 'bootcmd' 196 bootd - boot default, i.e., run 'bootcmd' 197 bootelf - Boot from an ELF image in memory 198 bootm - boot application image from memory 199 bootp - boot image via network using BOOTP/TFTP protocol 200 bootvx - Boot vxWorks from an ELF image 201 cmp - memory compare 202 coninfo - print console devices and information 203 cp - memory copy 204 crc32 - checksum calculation 205 dcache - enable or disable data cache 206 dhcp - boot image via network using DHCP/TFTP protocol 207 echo - echo args to console 208 editenv - edit environment variable 209 env - environment handling commands 210 exit - exit script 211 false - do nothing, unsuccessfully 212 go - start application at address 'addr' 213 help - print command description/usage 214 icache - enable or disable instruction cache 215 iminfo - print header information for application image 216 imxtract- extract a part of a multi-image 217 itest - return true/false on integer compare 218 loop - infinite loop on address range 219 md - memory display 220 mdio - MDIO utility commands 221 mii - MII utility commands 222 mm - memory modify (auto-incrementing address) 223 mtest - simple RAM read/write test 224 mw - memory write (fill) 225 nand - NAND sub-system 226 nb_update- Nand boot update program 227 nboot - boot from NAND device 228 nfs - boot image via network using NFS protocol 229 nm - memory modify (constant address) 230 ping - send ICMP ECHO_REQUEST to network host 231 printenv- print environment variables 232 reginfo - print register information 233 reset - Perform RESET of the CPU 234 run - run commands in an environment variable 235 saveenv - save environment variables to persistent storage 236 setenv - set environment variables 237 sf - SPI flash sub-system 238 showvar - print local hushshell variables 239 sleep - delay execution for some time 240 source - run script from memory 241 sspi - SPI utility command 242 test - minimal test like /bin/sh 243 tftpboot- boot image via network using TFTP protocol 244 true - do nothing, successfully 245 version - print monitor, compiler and linker version 246
README.m68k
1 2 U-Boot for Motorola (or Freescale/NXP) ColdFire processors 3 4 =============================================================================== 5 History 6 7 November 02, 2017 Angelo Dureghello <angelo (a] sysam.it> 8 August 08, 2005 Jens Scharsig <esw (a] bus-elektronik.de> 9 MCF5282 implementation without preloader 10 January 12, 2004 <josef.baumgartner (a] telex.de> 11 =============================================================================== 12 13 14 This file contains status information for the port of U-Boot to the 15 Motorola ColdFire series of CPUs. 16 17 18 1. Overview 19 20 The ColdFire instruction set is "assembly source" compatible but an evolution 21 of the original 68000 instruction set. Some not much used instructions has 22 been removed. The instructions are only 16, 32, or 48 bits long, a 23 simplification compared to the 68000 series. 24 25 Bernhard Kuhn ported U-Boot 0.4.0 to the Motorola ColdFire architecture. 26 The patches of Bernhard support the MCF5272 and MCF5282. A great disadvantage 27 of these patches was that they needed a pre-bootloader to start U-Boot. 28 Because of this, a new port was created which no longer needs a first stage 29 booter. 30 31 Thanks mainly to Freescale but also to several other contributors, U-Boot now 32 supports nearly the entire range of ColdFire processors and their related 33 development boards. 34 35 36 2. Supported CPU families 37 38 Please "make menuconfig" with ARCH=m68k, or check arch/m68k/cpu to see the 39 currently supported processor and families. 40 41 42 3. Supported boards 43 44 U-Boot supports actually more than 40 ColdFire based boards. 45 Board configuration can be done trough include/configs/<boardname>.h but the 46 current recommended method is to use the new and more friendly approach as 47 the "make menuconfig" way, very similar to the Linux way. 48 49 To know details as memory map, build targets, default setup, etc, of a 50 specific board please check: 51 52 include/configs/<boardname>.h 53 and/or 54 configs/<boardname>_defconfig 55 56 It is possible to build all ColdFire boards in a single command-line command, 57 from u-boot root directory, as: 58 59 ./tools/buildman/buildman m68k 60 61 62 3.1. Build U-Boot for a specific board 63 64 A bash script similar to the one below may be used: 65 66 #!/bin/bash 67 68 export CROSS_COMPILE=/opt/toolchains/m68k/gcc-4.9.0-nolibc/bin/m68k-linux- 69 70 board=M5475DFE 71 72 make distclean 73 make ARCH=m68k ${board}_defconfig 74 make ARCH=m68k KBUILD_VERBOSE=1 75 76 77 4. Adopted toolchains 78 79 Please check: 80 https://www.denx.de/wiki/U-Boot/ColdFireNotes 81 82 83 5. ColdFire specific configuration options/settings 84 85 86 5.1. Configuration to use a pre-loader 87 88 If U-Boot should be loaded to RAM and started by a pre-loader 89 CONFIG_MONITOR_IS_IN_RAM must be defined. If it is defined the 90 initial vector table and basic processor initialization will not 91 be compiled in. The start address of U-Boot must be adjusted in 92 the boards config header file (CONFIG_SYS_MONITOR_BASE) and Makefile 93 (CONFIG_SYS_TEXT_BASE) to the load address. 94 95 96 5.2 ColdFire CPU specific options/settings 97 98 To specify a CPU model, some defines shoudl be used, i.e.: 99 100 CONFIG_MCF52x2 -- defined for all MCF52x2 CPUs 101 CONFIG_M5272 -- defined for all Motorola MCF5272 CPUs 102 103 Other options, generally set inside include/configs/<boardname>.h, they may 104 apply to one or more cpu for the ColdFire family: 105 106 CONFIG_SYS_MBAR -- defines the base address of the MCF5272 configuration 107 registers 108 CONFIG_SYS_ENET_BD_BASE 109 -- defines the base address of the FEC buffer descriptors 110 CONFIG_SYS_SCR -- defines the contents of the System Configuration Register 111 CONFIG_SYS_SPR -- defines the contents of the System Protection Register 112 CONFIG_SYS_MFD -- defines the PLL Multiplication Factor Divider 113 (see table 9-4 of MCF user manual) 114 CONFIG_SYS_RFD -- defines the PLL Reduce Frequency Devider 115 (see table 9-4 of MCF user manual) 116 CONFIG_SYS_CSx_BASE 117 -- defines the base address of chip select x 118 CONFIG_SYS_CSx_SIZE 119 -- defines the memory size (address range) of chip select x 120 CONFIG_SYS_CSx_WIDTH 121 -- defines the bus with of chip select x 122 CONFIG_SYS_CSx_MASK 123 -- defines the mask for the related chip select x 124 CONFIG_SYS_CSx_RO 125 -- if set to 0 chip select x is read/write else chip select 126 is read only 127 CONFIG_SYS_CSx_WS 128 -- defines the number of wait states of chip select x 129 CONFIG_SYS_CACHE_ICACR 130 CONFIG_SYS_CACHE_DCACR 131 CONFIG_SYS_CACHE_ACRX 132 -- cache-related registers config 133 CONFIG_SYS_SDRAM_BASE 134 CONFIG_SYS_SDRAM_SIZE 135 CONFIG_SYS_SDRAM_BASEX 136 CONFIG_SYS_SDRAM_CFG1 137 CONFIG_SYS_SDRAM_CFG2 138 CONFIG_SYS_SDRAM_CTRL 139 CONFIG_SYS_SDRAM_MODE 140 CONFIG_SYS_SDRAM_EMOD 141 -- SDRAM config for SDRAM controller-specific registers, please 142 see arch/m68k/cpu/<specific_cpu>/start.S files to see how 143 these options are used. 144 CONFIG_MCFUART 145 -- defines enabling of ColdFire UART driver 146 CONFIG_SYS_UART_PORT 147 -- defines the UART port to be used (only a single UART can be 148 actually enabled) 149 CONFIG_SYS_SBFHDR_SIZE 150 -- size of the prepended SBF header, if any 151
README.malta
1 MIPS Malta board 2 3 How to flash using a MIPS Navigator Probe: 4 5 - Ensure that your Malta has jumper JP1 fitted. Without this jumper you will 6 be unable to flash your Malta using a Navigator Probe. 7 8 - Connect Navigator Console to your probe and Malta as usual. 9 10 - Within Navigator Console run the following commands: 11 12 source /path/to/u-boot/board/imgtec/malta/flash-malta-boot.tcl 13 reset 14 flash-boot /path/to/u-boot/u-boot.bin 15 16 - You should now be able to reboot your Malta to a U-Boot shell. 17
README.marubun-pcmcia
1 2 U-Boot MARUBUN MR-SHPC-01 PCMCIA controller driver 3 Last update 21/11/2007 by Nobuhiro Iwamatsu 4 5 ======================================================================================== 6 7 0. What's this? 8 This driver supports MARUBUN MR-SHPC-01. 9 url: http://www.marubun.co.jp/product/semicon/devices/qgc18e0000002n2z.html 10 (Sorry Japanese only.) 11 12 This chip is used with SuperH well, and adopted by the 13 reference board. 14 ex. * MS7750SE01 15 * MS7722SE01 16 * other 17 18 This chip doesn't support CardBus. 19 20 1. base source code 21 The code is based on sources from the Linux kernel 22 ( arch/sh/kernel/cf-enabler.c ). 23 24 2. How to use 25 The options you have to specify in the config file are (with the 26 value for my board as an example): 27 28 * CONFIG_MARUBUN_PCCARD 29 If you want to use this device driver, should define CONFIG_MARUBUN_PCCARD. 30 ex. #define CONFIG_MARUBUN_PCCARD 31 32 * CONFIG_PCMCIA_SLOT_A 33 Most devices have only one slot. You should define CONFIG_PCMCIA_SLOT_A . 34 ex. #define CONFIG_PCMCIA_SLOT_A 1 35 36 * CONFIG_SYS_MARUBUN_MRSHPC 37 This is MR-SHPC-01 PCMCIA controller base address. 38 You should do the setting matched to your environment. 39 ex. #define CONFIG_SYS_MARUBUN_MRSHPC 0xb03fffe0 40 ( for MS7722SE01 environment ) 41 42 * CONFIG_SYS_MARUBUN_MW1 43 This is MR-SHPC-01 memory window base address. 44 You should do the setting matched to your environment. 45 ex. #define CONFIG_SYS_MARUBUN_MW1 0xb0400000 46 ( for MS7722SE01 environment ) 47 48 * CONFIG_SYS_MARUBUN_MW1 49 This is MR-SHPC-01 attribute window base address. 50 You should do the setting matched to your environment. 51 ex. #define CONFIG_SYS_MARUBUN_MW2 0xb0500000 52 ( for MS7722SE01 environment ) 53 54 * CONFIG_SYS_MARUBUN_MW1 55 This is MR-SHPC-01 I/O window base address. 56 You should do the setting matched to your environment. 57 ex. #define CONFIG_SYS_MARUBUN_IO 0xb0600000 58 ( for MS7722SE01 environment ) 59 60 3. Other 61 * Check Compact Flash only. 62 * Maybe, NE2000 compatible NIC is sure to move. 63 64 Copyright (c) 2007 65 Nobuhiro Iwamatsu <iwamatsu (a] nigaur.org> 66
README.marvell
1 Marvell U-Boot Build Instructions 2 ================================= 3 4 This document describes how to compile the U-Boot and how to change U-Boot configuration 5 6 Build Procedure 7 ---------------- 8 1. Install required packages: 9 10 # sudo apt-get install libssl-dev 11 # sudo apt-get install device-tree-compiler 12 # sudo apt-get install swig libpython-dev 13 14 2. Set the cross compiler: 15 16 # export CROSS_COMPILE=/path/to/toolchain/aarch64-marvell-linux-gnu- 17 18 3. Clean-up old residuals: 19 20 # make mrproper 21 22 4. Configure the U-Boot: 23 24 # make <defconfig_file> 25 26 - For the Armada-70x0/80x0 DB board use "mvebu_db_armada8k_defconfig" 27 - For the Armada-80x0 MacchiatoBin use "make mvebu_mcbin-88f8040_defconfig" 28 - For the Armada-3700 DB board use "make mvebu_db-88f3720_defconfig" 29 - For the Armada-3700 EsspressoBin use "make mvebu_espressobin-88f3720_defconfig" 30 31 5. Configure the device-tree and build the U-Boot image: 32 33 Compile u-boot and set the required device-tree using: 34 35 # make DEVICE_TREE=<name> 36 37 NOTE: 38 Compilation with "mvebu_db_armada8k_defconfig" requires explicitly exporting DEVICE_TREE 39 for the requested board. 40 By default, u-boot is compiled with armada-8040-db device-tree. 41 Using A80x0 device-tree on A70x0 might break the device. 42 In order to prevent this, the required device-tree MUST be set during compilation. 43 All device-tree files are located in ./arch/arm/dts/ folder. 44 45 NOTE: 46 The u-boot.bin should not be used as a stand-alone image. 47 The ARM Trusted Firmware (ATF) build process uses this image to generate the 48 flash image. 49 50 Configuration update 51 --------------------- 52 To update the U-Boot configuration, please refer to doc/README.kconfig 53 54
README.memory-test
1 The most frequent cause of problems when porting U-Boot to new 2 hardware, or when using a sloppy port on some board, is memory errors. 3 In most cases these are not caused by failing hardware, but by 4 incorrect initialization of the memory controller. So it appears to 5 be a good idea to always test if the memory is working correctly, 6 before looking for any other potential causes of any problems. 7 8 U-Boot implements 3 different approaches to perform memory tests: 9 10 1. The get_ram_size() function (see "common/memsize.c"). 11 12 This function is supposed to be used in each and every U-Boot port 13 determine the presence and actual size of each of the potential 14 memory banks on this piece of hardware. The code is supposed to be 15 very fast, so running it for each reboot does not hurt. It is a 16 little known and generally underrated fact that this code will also 17 catch 99% of hardware related (i. e. reliably reproducible) memory 18 errors. It is strongly recommended to always use this function, in 19 each and every port of U-Boot. 20 21 2. The "mtest" command. 22 23 This is probably the best known memory test utility in U-Boot. 24 Unfortunately, it is also the most problematic, and the most 25 useless one. 26 27 There are a number of serious problems with this command: 28 29 - It is terribly slow. Running "mtest" on the whole system RAM 30 takes a _long_ time before there is any significance in the fact 31 that no errors have been found so far. 32 33 - It is difficult to configure, and to use. And any errors here 34 will reliably crash or hang your system. "mtest" is dumb and has 35 no knowledge about memory ranges that may be in use for other 36 purposes, like exception code, U-Boot code and data, stack, 37 malloc arena, video buffer, log buffer, etc. If you let it, it 38 will happily "test" all such areas, which of course will cause 39 some problems. 40 41 - It is not easy to configure and use, and a large number of 42 systems are seriously misconfigured. The original idea was to 43 test basically the whole system RAM, with only exempting the 44 areas used by U-Boot itself - on most systems these are the areas 45 used for the exception vectors (usually at the very lower end of 46 system memory) and for U-Boot (code, data, etc. - see above; 47 these are usually at the very upper end of system memory). But 48 experience has shown that a very large number of ports use 49 pretty much bogus settings of CONFIG_SYS_MEMTEST_START and 50 CONFIG_SYS_MEMTEST_END; this results in useless tests (because 51 the ranges is too small and/or badly located) or in critical 52 failures (system crashes). 53 54 Because of these issues, the "mtest" command is considered depre- 55 cated. It should not be enabled in most normal ports of U-Boot, 56 especially not in production. If you really need a memory test, 57 then see 1. and 3. above resp. below. 58 59 3. The most thorough memory test facility is available as part of the 60 POST (Power-On Self Test) sub-system, see "post/drivers/memory.c". 61 62 If you really need to perform memory tests (for example, because 63 it is mandatory part of your requirement specification), then 64 enable this test which is generic and should work on all archi- 65 tectures. 66 67 WARNING: 68 69 It should pointed out that _all_ these memory tests have one 70 fundamental, unfixable design flaw: they are based on the assumption 71 that memory errors can be found by writing to and reading from memory. 72 Unfortunately, this is only true for the relatively harmless, usually 73 static errors like shorts between data or address lines, unconnected 74 pins, etc. All the really nasty errors which will first turn your 75 hair gray, only to make you tear it out later, are dynamical errors, 76 which usually happen not with simple read or write cycles on the bus, 77 but when performing back-to-back data transfers in burst mode. Such 78 accesses usually happen only for certain DMA operations, or for heavy 79 cache use (instruction fetching, cache flushing). So far I am not 80 aware of any freely available code that implements a generic, and 81 efficient, memory test like that. The best known test case to stress 82 a system like that is to boot Linux with root file system mounted over 83 NFS, and then build some larger software package natively (say, 84 compile a Linux kernel on the system) - this will cause enough context 85 switches, network traffic (and thus DMA transfers from the network 86 controller), varying RAM use, etc. to trigger any weak spots in this 87 area. 88 89 Note: An attempt was made once to implement such a test to catch 90 memory problems on a specific board. The code is pretty much board 91 specific (for example, it includes setting specific GPIO signals to 92 provide triggers for an attached logic analyzer), but you can get an 93 idea how it works: see "examples/standalone/test_burst*". 94 95 Note 2: Ironically enough, the "test_burst" did not catch any RAM 96 errors, not a single one ever. The problems this code was supposed 97 to catch did not happen when accessing the RAM, but when reading from 98 NOR flash. 99
README.menu
1 SPDX-License-Identifier: GPL-2.0+ 2 /* 3 * Copyright 2010-2011 Calxeda, Inc. 4 */ 5 6 U-Boot provides a set of interfaces for creating and using simple, text 7 based menus. Menus are displayed as lists of labeled entries on the 8 console, and an entry can be selected by entering its label. 9 10 To use the menu code, enable CONFIG_MENU, and include "menu.h" where 11 the interfaces should be available. 12 13 Menus are composed of items. Each item has a key used to identify it in 14 the menu, and an opaque pointer to data controlled by the consumer. 15 16 If you want to show a menu, instead starting the shell, define 17 CONFIG_MENU_SHOW. You have to code the int menu_show(int bootdelay) 18 function, which handle your menu. This function returns the remaining 19 bootdelay. 20 21 Interfaces 22 ---------- 23 #include "menu.h" 24 25 /* 26 * Consumers of the menu interfaces will use a struct menu * as the 27 * handle for a menu. struct menu is only fully defined in menu.c, 28 * preventing consumers of the menu interfaces from accessing its 29 * contents directly. 30 */ 31 struct menu; 32 33 /* 34 * NOTE: See comments in common/menu.c for more detailed documentation on 35 * these interfaces. 36 */ 37 38 /* 39 * menu_create() - Creates a menu handle with default settings 40 */ 41 struct menu *menu_create(char *title, int timeout, int prompt, 42 void (*item_data_print)(void *), 43 char *(*item_choice)(void *), 44 void *item_choice_data); 45 46 /* 47 * menu_item_add() - Adds or replaces a menu item 48 */ 49 int menu_item_add(struct menu *m, char *item_key, void *item_data); 50 51 /* 52 * menu_default_set() - Sets the default choice for the menu 53 */ 54 int menu_default_set(struct menu *m, char *item_key); 55 56 /* 57 * menu_default_choice() - Set *choice to point to the default item's data 58 */ 59 int menu_default_choice(struct menu *m, void **choice); 60 61 /* 62 * menu_get_choice() - Returns the user's selected menu entry, or the 63 * default if the menu is set to not prompt or the timeout expires. 64 */ 65 int menu_get_choice(struct menu *m, void **choice); 66 67 /* 68 * menu_destroy() - frees the memory used by a menu and its items. 69 */ 70 int menu_destroy(struct menu *m); 71 72 /* 73 * menu_display_statusline(struct menu *m); 74 * shows a statusline for every menu_display call. 75 */ 76 void menu_display_statusline(struct menu *m); 77 78 Example Code 79 ------------ 80 This example creates a menu that always prompts, and allows the user 81 to pick from a list of tools. The item key and data are the same. 82 83 #include "menu.h" 84 85 char *tools[] = { 86 "Hammer", 87 "Screwdriver", 88 "Nail gun", 89 NULL 90 }; 91 92 char *pick_a_tool(void) 93 { 94 struct menu *m; 95 int i; 96 char *tool = NULL; 97 98 m = menu_create("Tools", 0, 1, NULL); 99 100 for(i = 0; tools[i]; i++) { 101 if (menu_item_add(m, tools[i], tools[i]) != 1) { 102 printf("failed to add item!"); 103 menu_destroy(m); 104 return NULL; 105 } 106 } 107 108 if (menu_get_choice(m, (void **)&tool) != 1) 109 printf("Problem picking tool!\n"); 110 111 menu_destroy(m); 112 113 return tool; 114 } 115 116 void caller(void) 117 { 118 char *tool = pick_a_tool(); 119 120 if (tool) { 121 printf("picked a tool: %s\n", tool); 122 use_tool(tool); 123 } 124 } 125
README.mips
1 2 Notes for the MIPS architecture port of U-Boot 3 4 Toolchains 5 ---------- 6 7 http://www.denx.de/wiki/DULG/ELDK 8 ELDK < DULG < DENX 9 10 http://www.emdebian.org/crosstools.html 11 Embedded Debian -- Cross-development toolchains 12 13 http://buildroot.uclibc.org/ 14 Buildroot 15 16 Known Issues 17 ------------ 18 19 * Cache incoherency issue caused by do_bootelf_exec() at cmd_elf.c 20 21 Cache will be disabled before entering the loaded ELF image without 22 writing back and invalidating cache lines. This leads to cache 23 incoherency in most cases, unless the code gets loaded after U-Boot 24 re-initializes the cache. The more common uImage 'bootm' command does 25 not suffer this problem. 26 27 [workaround] To avoid this cache incoherency, 28 1) insert flush_cache(all) before calling dcache_disable(), or 29 2) fix dcache_disable() to do both flushing and disabling cache. 30 31 * Note that Linux users need to kill dcache_disable() in do_bootelf_exec() 32 or override do_bootelf_exec() not to disable I-/D-caches, because most 33 Linux/MIPS ports don't re-enable caches after entering kernel_entry. 34 35 TODOs 36 ----- 37 38 * Probe CPU types, I-/D-cache and TLB size etc. automatically 39 40 * Secondary cache support missing 41 42 * Initialize TLB entries redardless of their use 43 44 * R2000/R3000 class parts are not supported 45 46 * Limited testing across different MIPS variants 47 48 * Due to cache initialization issues, the DRAM on board must be 49 initialized in board specific assembler language before the cache init 50 code is run -- that is, initialize the DRAM in lowlevel_init(). 51 52 * centralize/share more CPU code of MIPS32, MIPS64 and XBurst 53 54 * support Qemu Malta 55
README.mpc74xx
1 This file contains status information for the port of U-Boot to the 2 Motorola mpc74xx series of CPUs. 3 4 Author: Josh Huber <huber (a] mclx.com> 5 Mission Critical Linux, Inc. 6 7 Currently the support for these CPUs is pretty minimal, but enough to 8 get things going. (much like the support for the Galileo Eval Board) 9 10 There is a framework in place to enable the L2 cache, and to program 11 the BATs. Currently, there are still problems with the code which 12 sets up the L2 cache, so it's not enabled. (IMHO, it shouldn't be 13 anyway). Additionally, there is support for enabling the MMU, which 14 we also don't do. The BATs are programmed just for the benefit of 15 jumping into Linux in a sane configuration. 16 17 Most of the code was based on other cpus supported by U-Boot. 18 19 If you find any errors in the CPU setup code, please send us a note. 20 21 Thanks, 22 Josh 23
README.mpc83xx.ddrecc
1 Overview 2 ======== 3 4 The overall usage pattern for ECC diagnostic commands is the following: 5 6 * (injecting errors is initially disabled) 7 8 * define inject mask (which tells the DDR controller what type of errors 9 we'll be injecting: single/multiple bit etc.) 10 11 * enable injecting errors - from now on the controller injects errors as 12 indicated in the inject mask 13 14 IMPORTANT NOTICE: enabling injecting multiple-bit errors is potentially 15 dangerous as such errors are NOT corrected by the controller. Therefore caution 16 should be taken when enabling the injection of multiple-bit errors: it is only 17 safe when used on a carefully selected memory area and used under control of 18 the 'ecc testdw' 'ecc testword' command (see example 'Injecting Multiple-Bit 19 Errors' below). In particular, when you simply set the multiple-bit errors in 20 inject mask and enable injection, U-Boot is very likely to hang quickly as the 21 errors will be injected when it accesses its code, data etc. 22 23 24 Use cases for DDR 'ecc' command: 25 ================================ 26 27 Before executing particular tests reset target board or clear status registers: 28 29 => ecc captureclear 30 => ecc errdetectclr all 31 => ecc sbecnt 0 32 33 34 Injecting Single-Bit Errors 35 --------------------------- 36 37 1. Set 1 bit in Data Path Error Inject Mask 38 39 => ecc injectdatahi 1 40 41 2. Run test over some memory region 42 43 => ecc testdw 200000 10 44 45 3. Check ECC status 46 47 => ecc status 48 ... 49 Memory Data Path Error Injection Mask High/Low: 00000001 00000000 50 ... 51 Memory Single-Bit Error Management (0..255): 52 Single-Bit Error Threshold: 255 53 Single Bit Error Counter: 16 54 ... 55 Memory Error Detect: 56 Multiple Memory Errors: 0 57 Multiple-Bit Error: 0 58 Single-Bit Error: 0 59 ... 60 61 16 errors were generated, Single-Bit Error flag was not set as Single Bit Error 62 Counter did not reach Single-Bit Error Threshold. 63 64 4. Make sure used memory region got re-initialized with 0x0123456789abcdef 65 66 => md 200000 67 00200000: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg.... 68 00200010: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg.... 69 00200020: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg.... 70 00200030: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg.... 71 00200040: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg.... 72 00200050: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg.... 73 00200060: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg.... 74 00200070: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg.... 75 00200080: deadbeef deadbeef deadbeef deadbeef ................ 76 00200090: deadbeef deadbeef deadbeef deadbeef ................ 77 78 Injecting Multiple-Bit Errors 79 ----------------------------- 80 81 1. Set more than 1 bit in Data Path Error Inject Mask 82 83 => ecc injectdatahi 1 84 => ecc injectdatalo 1 85 86 2. Run test over some memory region 87 88 => ecc testword 200000 1 89 90 3. Check ECC status 91 92 => ecc status 93 ... 94 Memory Data Path Error Injection Mask High/Low: 00000001 00000001 95 ... 96 Memory Error Detect: 97 Multiple Memory Errors: 0 98 Multiple-Bit Error: 1 99 Single-Bit Error: 0 100 ... 101 102 The Multiple Memory Errors flags not set and Multiple-Bit Error flags are set. 103 104 4. Make sure used memory region got re-initialized with 0x0123456789abcdef 105 106 => md 200000 107 00200000: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg.... 108 00200010: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg.... 109 00200020: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg.... 110 00200030: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg.... 111 00200040: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg.... 112 00200050: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg.... 113 00200060: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg.... 114 00200070: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg.... 115 00200080: deadbeef deadbeef deadbeef deadbeef ................ 116 00200090: deadbeef deadbeef deadbeef deadbeef ................ 117 118 119 Test Single-Bit Error Counter and Threshold 120 ------------------------------------------- 121 122 1. Set 1 bit in Data Path Error Inject Mask 123 124 => ecc injectdatahi 1 125 126 2. Enable error injection 127 128 => ecc inject en 129 130 3. Let u-boot run for a with Single-Bit error injection enabled 131 132 4. Disable error injection 133 134 => ecc inject dis 135 136 4. Check status 137 138 => ecc status 139 140 ... 141 Memory Single-Bit Error Management (0..255): 142 Single-Bit Error Threshold: 255 143 Single Bit Error Counter: 199 144 145 Memory Error Detect: 146 Multiple Memory Errors: 1 147 Multiple-Bit Error: 0 148 Single-Bit Error: 1 149 ... 150 151 Observe that Single-Bit Error is 'on' which means that Single-Bit Error Counter 152 reached Single-Bit Error Threshold. Multiple Memory Errors bit is also 'on', that 153 is Counter reached Threshold more than one time (it wraps back after reaching 154 Threshold). 155
README.mpc83xxads
1 Freescale MPC83xx ADS Boards 2 ----------------------------------------- 3 4 0. Toolchain / Building 5 6 $ PATH=$PATH:/usr/powerpc/bin 7 $ CROSS_COMPILE=powerpc-linux- 8 $ export PATH CROSS_COMPILE 9 10 $ powerpc-linux-gcc -v 11 Reading specs from /usr/powerpc/lib/gcc/powerpc-linux/3.4.3/specs 12 Configured with: ../configure --prefix=/usr/powerpc 13 --exec-prefix=/usr/powerpc --target=powerpc-linux --enable-shared 14 --disable-nls --disable-multilib --enable-languages=c,c++,ada,f77,objc 15 Thread model: posix 16 gcc version 3.4.3 (Debian) 17 18 $ powerpc-linux-as -v 19 GNU assembler version 2.15 (powerpc-linux) using BFD version 2.15 20 21 22 $ make MPC8349ADS_config 23 Configuring for MPC8349ADS board... 24 25 $ make 26 27 28 1. Board Switches and Jumpers 29 30 31 2. Memory Map 32 33 2.1. The memory map should look pretty much like this: 34 35 0x0000_0000 0x7fff_ffff DDR 2G 36 0x8000_0000 0x9fff_ffff PCI MEM 512M 37 0xc000_0000 0xdfff_ffff Rapid IO 512M 38 0xe000_0000 0xe00f_ffff CCSR 1M 39 0xe200_0000 0xe2ff_ffff PCI IO 16M 40 0xf000_0000 0xf7ff_ffff SDRAM 128M 41 0xf800_0000 0xf80f_ffff BCSR 1M 42 0xfe00_0000 0xffff_ffff FLASH (boot bank) 16M 43 44 45 3. Definitions 46 47 3.1 Explanation of NEW definitions in: 48 49 include/configs/MPC8349ADS.h 50 51 CONFIG_MPC83xx MPC83xx family 52 CONFIG_MPC8349 MPC8349 specific 53 CONFIG_TSEC_ENET Use on-chip 10/100/1000 ethernet 54 55 56 4. Compilation 57 58 Assuming you're using BASH shell: 59 60 export CROSS_COMPILE=your-cross-compile-prefix 61 cd u-boot 62 make distclean 63 make MPC8349ADS_config 64 make 65 66 5. Downloading and Flashing Images 67 68 5.0 Download over serial line using Kermit: 69 70 loadb 71 [Drop to kermit: 72 ^\c 73 send <u-boot-bin-image> 74 c 75 ] 76 77 78 Or via tftp: 79 80 tftp 10000 u-boot.bin 81 82 5.1 Reflash U-Boot Image using U-Boot 83 84 tftp 10000 u-boot.bin 85 protect off fe000000 fe09ffff 86 erase fe000000 fe09ffff 87 88 cp.b 10000 fe000000 xxxx 89 or 90 cp.b 10000 fe000000 a0000 91 92 You might have to supply the correct byte count for 'xxxx' from 93 the TFTP. Maybe a0000 will work too, that corresponds to the 94 erased sectors. 95 96 97 6. Notes 98
README.mpc85xx
1 External Debug Support 2 ---------------------- 3 4 Freescale's e500v1 and e500v2 cores (used in mpc85xx chips) have some 5 restrictions on external debugging (JTAG). In particular, for the debugger to 6 be able to receive control after a single step or breakpoint: 7 - MSR[DE] must be set 8 - A valid opcode must be fetchable, through the MMU, from the debug 9 exception vector (IVPR + IVOR15). 10 11 To maximize the time during which this requirement is met, U-Boot sets MSR[DE] 12 immediately on entry and keeps it set. It also uses a temporary TLB to keep a 13 mapping to a valid opcode at the debug exception vector, even if we normally 14 don't support exception vectors being used that early, and that's not the area 15 where U-Boot currently executes from. 16 17 Note that there may still be some small windows where debugging will not work, 18 such as in between updating IVPR and IVOR15. 19 20 Config Switches: 21 ---------------- 22 23 Please refer README section "MPC85xx External Debug Support" 24 25 Major Config Switches during various boot Modes 26 ---------------------------------------------- 27 28 NOR boot 29 !defined(CONFIG_SYS_RAMBOOT) && !defined(CONFIG_SPL) 30 NOR boot Secure 31 !defined(CONFIG_SYS_RAMBOOT) && defined(CONFIG_SECURE_BOOT) 32 RAMBOOT(SD, SPI & NAND boot) 33 defined(CONFIG_SYS_RAMBOOT) 34 RAMBOOT Secure (SD, SPI & NAND) 35 defined(CONFIG_SYS_RAMBOOT) && defined(CONFIG_SECURE_BOOT) 36 NAND SPL BOOT 37 defined(CONFIG_SYS_RAMBOOT) && defined(CONFIG_NAND_SPL) 38 39 40 TLB Entries during u-boot execution 41 ----------------------------------- 42 43 Note: Sequence number is in order of execution 44 45 A) defined(CONFIG_SYS_RAMBOOT) i.e. SD, SPI, NAND RAMBOOT & NAND_SPL boot 46 47 1) TLB entry to overcome e500 v1/v2 debug restriction 48 Location : Label "_start_e500" 49 TLB Entry : CONFIG_SYS_PPC_E500_DEBUG_TLB 50 EPN -->RPN : CONFIG_SYS_MONITOR_BASE --> CONFIG_SYS_MONITOR_BASE 51 Properties : 256K, AS0, I, IPROT 52 53 2) TLB entry for working in AS1 54 Location : Label "create_init_ram_area" 55 TLB Entry : 15 56 EPN -->RPN : CONFIG_SYS_MONITOR_BASE --> CONFIG_SYS_MONITOR_BASE 57 Properties : 1M, AS1, I, G, IPROT 58 59 3) TLB entry for the stack during AS1 60 Location : Lable "create_init_ram_area" 61 TLB Entry : 14 62 EPN -->RPN : CONFIG_SYS_INIT_RAM_ADDR --> CONFIG_SYS_INIT_RAM_ADDR 63 Properties : 16K, AS1, IPROT 64 65 4) TLB entry for CCSRBAR during AS1 execution 66 Location : cpu_init_early_f 67 TLB Entry : 13 68 EPN -->RPN : CONFIG_SYS_CCSRBAR --> CONFIG_SYS_CCSRBAR 69 Properties : 1M, AS1, I, G 70 71 5) Invalidate unproctected TLB Entries 72 Location : cpu_init_early_f 73 Invalidated: 13 74 75 6) Create TLB entries as per boards/freescale/<board>/tlb.c 76 Location : cpu_init_early_f --> init_tlbs() 77 Properties : ..., AS0, ... 78 Please note It can overwrites previous TLB Entries. 79 80 7) Disable TLB Entries of AS1 81 Location : cpu_init_f --> disable_tlb() 82 Disable : 15, 14 83 84 8) Update Flash's TLB entry 85 Location : Board_init_r 86 TLB entry : Search from TLB entries 87 EPN -->RPN : CONFIG_SYS_FLASH_BASE --> CONFIG_SYS_FLASH_BASE_PHYS 88 Properties : Board specific size, AS0, I, G, IPROT 89 90 91 B) !defined(CONFIG_SYS_RAMBOOT) i.e. NOR boot 92 93 1) TLB entry to overcome e500 v1/v2 debug restriction 94 Location : Label "_start_e500" 95 TLB Entry : CONFIG_SYS_PPC_E500_DEBUG_TLB 96 #if defined(CONFIG_SECURE_BOOT) 97 EPN -->RPN : CONFIG_SYS_MONITOR_BASE --> CONFIG_SYS_PBI_FLASH_WINDOW 98 Properties : 1M, AS1, I, G, IPROT 99 #else 100 EPN -->RPN : CONFIG_SYS_MONITOR_BASE & 0xffc00000 --> 0xffc00000 101 Properties : 4M, AS0, I, G, IPROT 102 #endif 103 104 2) TLB entry for working in AS1 105 Location : Label "create_init_ram_area" 106 TLB Entry : 15 107 #if defined(CONFIG_SECURE_BOOT) 108 EPN -->RPN : CONFIG_SYS_MONITOR_BASE --> CONFIG_SYS_PBI_FLASH_WINDOW 109 Properties : 1M, AS1, I, G, IPROT 110 #else 111 EPN -->RPN : CONFIG_SYS_MONITOR_BASE & 0xffc00000 --> 0xffc00000 112 Properties : 4M, AS1, I, G, IPROT 113 #endif 114 115 3) TLB entry for the stack during AS1 116 Location : Lable "create_init_ram_area" 117 TLB Entry : 14 118 EPN -->RPN : CONFIG_SYS_INIT_RAM_ADDR --> CONFIG_SYS_INIT_RAM_ADDR 119 Properties : 16K, AS1, IPROT 120 121 4) TLB entry for CCSRBAR during AS1 execution 122 Location : cpu_init_early_f 123 TLB Entry : 13 124 EPN -->RPN : CONFIG_SYS_CCSRBAR --> CONFIG_SYS_CCSRBAR 125 Properties : 1M, AS1, I, G 126 127 5) TLB entry for Errata workaround CONFIG_SYS_FSL_ERRATUM_IFC_A003399 128 Location : cpu_init_early_f 129 TLB Entry : 9 130 EPN -->RPN : SRAM_BASE_ADDR --> SRAM_BASE_ADDR 131 Properties : 1M, AS1, I 132 133 6) CONFIG_SYS_FSL_ERRATUM_IFC_A003399 Adjust flash's phys addr 134 Location : cpu_init_early_f --> setup_ifc 135 TLB Entry : Get Flash TLB 136 EPN -->RPN : Adjusted flash_phys --> Adjusted flash_phys 137 Properties : 4M, AS1, I, G, IPROT 138 139 7) CONFIG_SYS_FSL_ERRATUM_IFC_A003399: E500 v1,v2 debug restriction 140 Location : cpu_init_early_f --> setup_ifc 141 TLB Entry : CONFIG_SYS_PPC_E500_DEBUG_TLB 142 EPN -->RPN : Adjusted flash_phys --> Adjusted flash_phys 143 Properties : 4M, AS0, I, G, IPROT 144 145 8) Invalidate unproctected TLB Entries 146 Location : cpu_init_early_f 147 Invalidated: 13, 9 148 149 9) Create TLB entries as per boards/freescale/<board>/tlb.c 150 Location : cpu_init_early_f --> init_tlbs() 151 Properties : ..., AS0, ... 152 Note: It can overwrites previous TLB Entries 153 154 10) Disable TLB Entries of AS1 155 Location : cpu_init_f --> disable_tlb() 156 Disable : 15, 14 157 158 11) Create DDR's TLB entriy 159 Location : Board_init_f -> dram_init 160 TLB entry : Search free TLB entry 161 162 12) Update Flash's TLB entry 163 Location : Board_init_r 164 TLB entry : Search from TLB entries 165 EPN -->RPN : CONFIG_SYS_FLASH_BASE --> CONFIG_SYS_FLASH_BASE_PHYS 166 Properties : Board specific size, AS0, I, G, IPROT 167
README.mpc85xx-sd-spi-boot
1 ---------------------------------------- 2 Booting from On-Chip ROM (eSDHC or eSPI) 3 ---------------------------------------- 4 5 boot_format is a tool to write SD bootable images to a filesystem and build 6 SD/SPI images to a binary file for writing later. 7 8 When booting from an SD card/MMC, boot_format puts the configuration file and 9 the RAM-based U-Boot image on the card. 10 When booting from an EEPROM, boot_format generates a binary image that is used 11 to boot from this EEPROM. 12 13 Where to get boot_format: 14 ======================== 15 16 you can browse it online at: 17 http://git.freescale.com/git/cgit.cgi/ppc/sdk/boot-format.git/ 18 19 Building 20 ======== 21 22 Run the following to build this project 23 24 $ make 25 26 Execution 27 ========= 28 29 boot_format runs under a regular Linux machine and requires a super user mode 30 to run. Execute boot_format as follows. 31 32 For building SD images by writing directly to a file system on SD media: 33 34 $ boot_format $config u-boot.bin -sd $device 35 36 Where $config is the included config.dat file for your platform and $device 37 is the target block device for the SD media on your computer. 38 39 For build binary images directly a local file: 40 41 $ boot_format $config u-boot.bin -spi $file 42 43 Where $file is the target file. Also keep in mind the u-boot.bin file needs 44 to be the u-boot built for your particular platform and target media. 45 46 Example: To generate a u-boot.bin for a P1022DS booting from SD, run the 47 following in the u-boot repository: 48 49 $ make P1022DS_SDCARD 50 51 Configuration Files 52 =================== 53 54 Below are the configuration files to be used with a particular platform. Keep 55 in mind that some of these config files are tied to the platforms DDR speed. 56 Please see the SoC reference manual for more documentation. 57 58 P1022DS config_sram_p1022ds.dat 59 P2020DS config_sram_p2020ds.dat 60 P1020RDB config_ddr2_1g_p1020rdb_533M.dat 61 P1020RDB config_ddr2_1g_p1020rdb_667M.dat 62 P2020RDB config_ddr2_1g_p2020rdb_800M.dat 63 P2020RDB config_ddr2_1g_p2020rdb_667M.dat 64 P2020RDB config_ddr3_1gb_64bit_p2020rdb_pc.dat 65 P1020RDB config_ddr3_1gb_p1_p2_rdb_pc_800M.dat 66 P1011RDB config_ddr3_1gb_p1_p2_rdb_pc_800M.dat 67 P1010RDB config_ddr3_1gb_p1010rdb_800M.dat 68 P1021RDB config_ddr3_1gb_p1_p2_rdb_pc_800M.dat 69 P1022DS config_ddr3_2gb_p1022ds.dat 70 P1024RDB config_ddr3_1gb_p1_p2_rdb_pc_667M.dat 71 P1025RDB config_ddr3_1gb_p1_p2_rdb_pc_667M.dat 72 P1016RDB config_ddr3_1gb_p1_p2_rdb_pc_667M.dat 73 P1020UTM config_ddr3_1gb_p1_p2_rdb_pc_800M.dat 74 P1020MBG config_ddr3_1gb_p1_p2_rdb_pc_800M.dat 75 MPC8536DS config_ddr2_512m_mpc8536ds_667M.dat 76
README.mpc85xx-spin-table
1 Spin table in cache 2 ===================================== 3 As specified by ePAPR v1.1, the spin table needs to be in cached memory. After 4 DDR is initialized and U-Boot relocates itself into DDR, the spin table is 5 accessible for core 0. It is part of release.S, within 4KB range after 6 __secondary_start_page. For other cores to use the spin table, the booting 7 process is described below: 8 9 Core 0 sets up the reset page on the top 4K of memory (or 4GB if total memory 10 is more than 4GB), and creates a TLB to map it to 0xffff_f000, regardless of 11 the physical address of this page, with WIMGE=0b01010. Core 0 also enables boot 12 page translation for secondary cores to use this page of memory. Then 4KB 13 memory is copied from __secondary_start_page to the boot page, after flusing 14 cache because this page is mapped as normal DDR. Before copying the reset page, 15 core 0 puts the physical address of the spin table (which is in release.S and 16 relocated to the top of mapped memory) into a variable __spin_table_addr so 17 that secondary cores can see it. 18 19 When secondary cores boot up from 0xffff_f000 page, they only have one default 20 TLB. While booting, they set up another TLB in AS=1 space and jump into 21 the new space. The new TLB covers the physical address of the spin table page, 22 with WIMGE =0b00100. Now secondary cores can keep polling the spin table 23 without stress DDR bus because both the code and the spin table is in cache. 24 25 For the above to work, DDR has to set the 'M' bit of WIMGE, in order to keep 26 cache coherence. 27
README.mpc85xxcds
1 Motorola MPC85xxCDS boards 2 -------------------------- 3 4 The CDS family of boards consists of a PCI backplane called the 5 "Arcadia", a PCI-form-factor carrier card that plugs into a PCI slot, 6 and a CPU daughter card that bolts onto the daughter card. 7 8 Much of the content of the README.mpc85xxads for the 85xx ADS boards 9 applies to the 85xx CDS boards as well. In particular the toolchain, 10 the switch nomenclature, and the basis for the memory map. There are 11 some differences, though. 12 13 14 Building U-Boot 15 --------------- 16 17 The Binutils in current ELDK toolchain will not support MPC85xx 18 chip. You need to use binutils-2.14.tar.bz2 (or newer) from 19 http://ftp.gnu.org/gnu/binutils. 20 21 The 85xx CDS code base is known to compile using: 22 gcc (GCC) 3.2.2 20030217 (Yellow Dog Linux 3.0 3.2.2-2a) 23 24 25 Memory Map 26 ---------- 27 28 The memory map for U-Boot and linux has been extended w.r.t. the ADS 29 platform to allow for utilization of all 85xx CDS devices. The memory 30 map is setup for linux to operate properly. The linux source when 31 configured for MPC85xx CDS has been updated to reflect the new memory 32 map. 33 34 The mapping is: 35 36 0x0000_0000 0x7fff_ffff DDR 2G 37 0x8000_0000 0x9fff_ffff PCI1 MEM 512M 38 0xa000_0000 0xbfff_ffff PCI2 MEM 512M 39 0xe000_0000 0xe00f_ffff CCSR 1M 40 0xe200_0000 0xe2ff_ffff PCI1 IO 16M 41 0xe300_0000 0xe3ff_ffff PCI2 IO 16M 42 0xf000_0000 0xf7ff_ffff SDRAM 128M 43 0xf800_0000 0xf80f_ffff NVRAM/CADMUS (*) 1M 44 0xff00_0000 0xff7f_ffff FLASH (2nd bank) 8M 45 0xff80_0000 0xffff_ffff FLASH (boot bank) 8M 46 47 (*) The system control registers (CADMUS) start at offset 0xfdb0_4000 48 within the NVRAM/CADMUS region of memory. 49 50 51 Using Flash 52 ----------- 53 54 The CDS board has two flash banks, each 8MB in size (2^23 = 0x00800000). 55 There is a switch which allows the boot-bank to be selected. The switch 56 settings for updating flash are given below. 57 58 The U-Boot commands for copying the boot-bank into the secondary bank are 59 as follows: 60 61 erase ff780000 ff7fffff 62 cp.b fff80000 ff780000 80000 63 64 65 U-Boot/kermit commands for downloading an image, then copying 66 it into the secondary bank: 67 68 loadb 69 [Drop to kermit: 70 ^\c 71 send <u-boot-bin-image> 72 c 73 ] 74 75 erase ff780000 ff7fffff 76 cp.b $loadaddr ff780000 80000 77 78 79 U-Boot commands for downloading an image via tftp and flashing 80 it into the second bank: 81 82 tftp 10000 <u-boot.bin.image> 83 erase ff780000 ff7fffff 84 cp.b 10000 ff780000 80000 85 86 87 After copying the image into the second bank of flash, be sure to toggle 88 SW2[2] on the carrier card before resetting the board in order to set the 89 secondary bank as the boot-bank. 90 91 92 Carrier Board Switches 93 ---------------------- 94 95 As a reminder, you should read the README.mpc85xxads too. 96 97 Most switches on the carrier board should not be changed. The only 98 user-settable switches on the carrier board are used to configure 99 the flash banks and determining the PCI slot. 100 101 The first two bits of SW2 control how flash is used on the board: 102 103 12345678 104 -------- 105 SW2=00XXXXXX FLASH: Boot bank 1, bank 2 available. 106 01XXXXXX FLASH: Boot bank 2, bank 1 available (swapped). 107 10XXXXXX FLASH: Boot promjet, bank 1 available 108 11XXXXXX FLASH: Boot promjet, bank 2 available 109 110 The boot bank is always mapped to FF80_0000 and listed first by 111 the "flinfo" command. The secondary bank is always FF00_0000. 112 113 When using PCI, linux needs to know to which slot the CDS carrier is 114 connected.. By convention, the user-specific bits of SW2 are used to 115 convey this information: 116 117 12345678 118 -------- 119 SW2=xxxxxx00 PCI SLOT INFORM: The CDS carrier is in slot0 of the Arcadia 120 xxxxxx01 PCI SLOT INFORM: The CDS carrier is in slot1 of the Arcadia 121 xxxxxx10 PCI SLOT INFORM: The CDS carrier is in slot2 of the Arcadia 122 xxxxxx11 PCI SLOT INFORM: The CDS carrier is in slot3 of the Arcadia 123 124 These are cleverly, er, clearly silkscreened as Slot 1 through 4, 125 respectively, on the Arcadia near the support posts. 126 127 128 The default setting of all switches on the carrier board is: 129 130 12345678 131 -------- 132 SW1=01101100 133 SW2=0x1111yy x=Flash bank, yy=PCI slot 134 SW3=11101111 135 SW4=10001000 136 137 138 8555/41 CPU Card Switches 139 ------------------------- 140 141 Most switches on the CPU Card should not be changed. However, the 142 frequency can be changed by setting SW3: 143 144 12345678 145 -------- 146 SW3=XX00XXXX == CORE:CCB 2:1 147 XX01XXXX == CORE:CCB 5:2 148 XX10XXXX == CORE:CCB 3:1 149 XX11XXXX == CORE:CCB 7:2 150 XXXX1000 == CCB:SYSCLK 8:1 151 XXXX1010 == CCB:SYSCLK 10:1 152 153 A safe default setting for all switches on the CPU board is: 154 155 12345678 156 -------- 157 SW1=10001111 158 SW2=01000111 159 SW3=00001000 160 SW4=11111110 161 162 163 8548 CPU Card Switches 164 ---------------------- 165 And, just to be confusing, in this set of switches: 166 167 ON = 1 168 OFF = 0 169 170 Default 171 SW1=11111101 172 SW2=10011111 173 SW3=11001000 (8X) (2:1) 174 SW4=11110011 175 176 SW3=X000XXXX == CORE:CCB 4:1 177 X001XXXX == CORE:CCB 9:2 178 X010XXXX == CORE:CCB 1:1 179 X011XXXX == CORE:CCB 3:2 180 X100XXXX == CORE:CCB 2:1 181 X101XXXX == CORE:CCB 5:2 182 X110XXXX == CORE:CCB 3:1 183 X111XXXX == CORE:CCB 7:2 184 XXXX0000 == CCB:SYSCLK 16:1 185 XXXX0001 == RESERVED 186 XXXX0010 == CCB:SYSCLK 2:1 187 XXXX0011 == CCB:SYSCLK 3:1 188 XXXX0100 == CCB:SYSCLK 4:1 189 XXXX0101 == CCB:SYSCLK 5:1 190 XXXX0110 == CCB:SYSCLK 6:1 191 XXXX0111 == RESERVED 192 XXXX1000 == CCB:SYSCLK 8:1 193 XXXX1001 == CCB:SYSCLK 9:1 194 XXXX1010 == CCB:SYSCLK 10:1 195 XXXX1011 == RESERVED 196 XXXX1100 == CCB:SYSCLK 12:1 197 XXXX1101 == CCB:SYSCLK 20:1 198 XXXX1110 == RESERVED 199 XXXX1111 == RESERVED 200 201 202 eDINK Info 203 ---------- 204 205 One bank of flash may contain an eDINK image. 206 207 Memory Map: 208 209 CCSRBAR @ 0xe0000000 210 Flash Bank 1 @ 0xfe000000 211 Flash Bank 2 @ 0xff000000 212 Ram @ 0 213 214 Commands for downloading a U-Boot image to memory from edink: 215 216 env -c 217 time -s 4/8/2004 4:30p 218 dl -k -b -o 100000 219 [Drop to kermit: 220 ^\c 221 transmit /binary <u-boot-bin-image> 222 c 223 ] 224 225 fu -l 100000 fe780000 80000 226
README.multi-dtb-fit
1 MULTI DTB FIT and SPL_MULTI_DTB_FIT 2 3 The purpose of this feature is to enable U-Boot or the SPL to select its DTB 4 from a FIT appended at the end of the binary. 5 It comes in two flavors: U-Boot (CONFIG_MULTI_DTB_FIT) and SPL 6 (CONFIG_SPL_MULTI_DTB_FIT). 7 8 U-Boot flavor: 9 Usually the DTB is selected by the SPL and passed down to U-Boot. But some 10 platforms don't use the SPL. In this case MULTI_DTB_FIT can used to provide 11 U-Boot with a choice of DTBs. 12 The relevant DTBs are packed into a FIT (list provided by CONFIG__OF_LIST). The 13 FIT is automatically generated at the end of the compilation and appended to 14 u-boot.bin so that U-Boot can locate it and select the correct DTB from inside 15 the FIT. 16 The selection is done using board_fit_config_name_match() (same as what the SPL 17 uses to select the DTB for U-Boot). The selection happens during fdtdec_setup() 18 which is called during before relocation by board_init_f(). 19 20 SPL flavor: 21 the SPL uses only a small subset of the DTB and it usually depends more 22 on the SOC than on the board. So it's usually fine to include a DTB in the 23 SPL that doesn't exactly match the board. There are howerver some cases 24 where it's not possible. In the later case, in order to support multiple 25 boards (or board revisions) with the same SPL binary, SPL_MULTI_DTB_FIT 26 can be used. 27 The relevant DTBs are packed into a FIT. This FIT is automatically generated 28 at the end of the compilation, compressed and appended to u-boot-spl.bin, so 29 that SPL can locate it and select the correct DTB from inside the FIT. 30 CONFIG_SPL__OF_LIST is used to list the relevant DTBs. 31 The compression stage is optional but reduces the impact on the size of the 32 SPL. LZO and GZIP compressions are supported. By default, the area where the 33 FIT is uncompressed is dynamicaly allocated but this behaviour can be changed 34 for platforms that don't provide a HEAP big enough to contain the uncompressed 35 FIT. 36 The SPL uses board_fit_config_name_match() to find the correct DTB within the 37 FIT (same as what the SPL uses to select the DTB for U-Boot). 38 Uncompression and selection stages happen in fdtdec_setup() which is called 39 during the early initialization stage of the SPL (spl_early_init() or 40 spl_init()) 41 42 Impacts and performances (SPL flavor): 43 The impact of this option is relatively small. Here are some numbers measured 44 for a TI DRA72 platform: 45 46 +----------+------------+-----------+------------+ 47 | size | size delta | SPL boot | boot time | 48 | (bytes) | (bytes) | time (s) | delta (s) | 49 +---------------------------+----------+------------+-----------+------------+ 50 | 1 DTB | | | | | 51 +---------------------------+----------+------------+-----------+------------+ 52 | reference | 125305 | 0 | 1.389 | 0 | 53 | LZO (dynamic allocation) | 125391 | 86 | 1.381 | -0.008 | 54 +---------------------------+----------+------------+-----------+------------+ 55 | 4 DTBs (DRA7, DRA71, | | | | | 56 | DRA72, DRA72 revC) | | | | | 57 +---------------------------+----------+------------+-----------+------------+ 58 | LZO (dynamic allocation) | 125991 | 686 | 1.39 | 0.001 | 59 | LZO (user defined area) | 125927 | 622 | 1.403 | 0.014 | 60 | GZIP (user defined area) | 133880 | 8575 | 1.421 | 0.032 | 61 | No compression (in place) | 137472 | 12167 | 1.412 | 0.023 | 62 +---------------------------+----------+------------+-----------+------------+ 63 64 Note: SPL boot time is the time elapsed between the 'reset' command is entered 65 and the time when the first U-Boot (not SPL) version string is displayed. 66
README.mxc_hab
1 1. High Assurance Boot (HAB) for i.MX CPUs 2 ------------------------------------------ 3 4 To enable the authenticated or encrypted boot mode of U-Boot, it is 5 required to set the proper configuration for the target board. This 6 is done by adding the following configuration in the defconfig file: 7 8 CONFIG_SECURE_BOOT=y 9 10 In addition, the U-Boot image to be programmed into the 11 boot media needs to be properly constructed, i.e. it must contain a 12 proper Command Sequence File (CSF). 13 14 The CSF itself is generated by the i.MX High Assurance Boot Reference 15 Code Signing Tool. 16 https://www.nxp.com/webapp/sps/download/license.jsp?colCode=IMX_CST_TOOL 17 18 More information about the CSF and HAB can be found in the AN4581. 19 https://www.nxp.com/docs/en/application-note/AN4581.pdf 20 21 We don't want to explain how to create a PKI tree or SRK table as 22 this is well explained in the Application Note. 23 24 2. Secure Boot on non-SPL targets 25 --------------------------------- 26 27 On non-SPL targets a singe U-Boot binary is generated, mkimage will 28 output additional information about "HAB Blocks" which can be used 29 in the CST to authenticate the U-Boot image (entries in the CSF file). 30 31 Image Type: Freescale IMX Boot Image 32 Image Ver: 2 (i.MX53/6 compatible) 33 Data Size: 327680 Bytes = 320.00 kB = 0.31 MB 34 Load Address: 177ff420 35 Entry Point: 17800000 36 HAB Blocks: 0x177ff400 0x00000000 0x0004dc00 37 ^^^^^^^^^^ ^^^^^^^^^^ ^^^^^^^^^^ 38 | | | 39 | | ----- (1) 40 | | 41 | ---------------- (2) 42 | 43 --------------------------- (3) 44 45 (1) Size of area in file u-boot-dtb.imx to sign 46 This area should include the IVT, the Boot Data the DCD 47 and U-Boot itself. 48 (2) Start of area in u-boot-dtb.imx to sign 49 (3) Start of area in RAM to authenticate 50 51 CONFIG_SECURE_BOOT currently enables only an additional command 52 'hab_status' in U-Boot to retrieve the HAB status and events. This 53 can be useful while developing and testing HAB. 54 55 Commands to generate a signed U-Boot using i.MX HAB CST tool: 56 # Compile CSF and create signature 57 cst --o csf-u-boot.bin --i command_sequence_uboot.csf 58 # Append compiled CSF to Binary 59 cat u-boot-dtb.imx csf-u-boot.bin > u-boot-signed.imx 60 61 3. Secure Boot on SPL targets 62 ----------------------------- 63 64 This version of U-Boot is able to build a signable version of the SPL 65 as well as a signable version of the U-Boot image. The signature can 66 be verified through High Assurance Boot (HAB). 67 68 After building, you need to create a command sequence file and use 69 i.MX HAB Code Signing Tool to sign both binaries. After creation, 70 the mkimage tool outputs the required information about the HAB Blocks 71 parameter for the CSF. During the build, the information is preserved 72 in log files named as the binaries. (SPL.log and u-boot-ivt.log). 73 74 Example Output of the SPL (imximage) creation: 75 Image Type: Freescale IMX Boot Image 76 Image Ver: 2 (i.MX53/6/7 compatible) 77 Mode: DCD 78 Data Size: 61440 Bytes = 60.00 kB = 0.06 MB 79 Load Address: 00907420 80 Entry Point: 00908000 81 HAB Blocks: 0x00907400 0x00000000 0x0000cc00 82 83 Example Output of the u-boot-ivt.img (firmware_ivt) creation: 84 Image Name: U-Boot 2016.11-rc1-31589-g2a4411 85 Created: Sat Nov 5 21:53:28 2016 86 Image Type: ARM U-Boot Firmware with HABv4 IVT (uncompressed) 87 Data Size: 352192 Bytes = 343.94 kB = 0.34 MB 88 Load Address: 17800000 89 Entry Point: 00000000 90 HAB Blocks: 0x177fffc0 0x0000 0x00054020 91 92 # Compile CSF and create signature 93 cst --o csf-u-boot.bin --i command_sequence_uboot.csf 94 cst --o csf-SPL.bin --i command_sequence_spl.csf 95 # Append compiled CSF to Binary 96 cat SPL csf-SPL.bin > SPL-signed 97 cat u-boot-ivt.img csf-u-boot.bin > u-boot-signed.img 98 99 These two signed binaries can be used on an i.MX in closed 100 configuration when the according SRK Table Hash has been flashed. 101 102 4. Setup U-Boot Image for Encrypted Boot 103 ---------------------------------------- 104 An authenticated U-Boot image is used as starting point for 105 Encrypted Boot. The image is encrypted by i.MX Code Signing 106 Tool (CST). The CST replaces only the image data of 107 u-boot-dtb.imx with the encrypted data. The Initial Vector Table, 108 DCD, and Boot data, remains in plaintext. 109 110 The image data is encrypted with a Encryption Key (DEK). 111 Therefore, this key is needed to decrypt the data during the 112 booting process. The DEK is protected by wrapping it in a Blob, 113 which needs to be appended to the U-Boot image and specified in 114 the CSF file. 115 116 The DEK blob is generated by an authenticated U-Boot image with 117 the dek_blob cmd enabled. The image used for DEK blob generation 118 needs to have the following configurations enabled in Kconfig: 119 120 CONFIG_SECURE_BOOT=y 121 CONFIG_CMD_DEKBLOB=y 122 123 Note: The encrypted boot feature is only supported by HABv4 or 124 greater. 125 126 The dek_blob command then can be used to generate the DEK blob of 127 a DEK previously loaded in memory. The command is used as follows: 128 129 dek_blob <DEK address> <Output Address> <Key Size in Bits> 130 example: dek_blob 0x10800000 0x10801000 192 131 132 The resulting DEK blob then is used to construct the encrypted 133 U-Boot image. Note that the blob needs to be transferred back 134 to the host.Then the following commands are used to construct 135 the final image. 136 137 cat u-boot-dtb.imx csf-u-boot.bin > u-boot-signed.imx 138 objcopy -I binary -O binary --pad-to <blob_dst> --gap-fill=0x00 \ 139 u-boot-signed.imx u-boot-signed-pad.bin 140 cat u-boot-signed-pad.imx DEK_blob.bin > u-boot-encrypted.imx 141 142 NOTE: u-boot-signed.bin needs to be padded to the value 143 equivalent to the address in which the DEK blob is specified 144 in the CSF. 145
README.mxc_ocotp
1 Driver implementing the fuse API for Freescale's On-Chip OTP Controller (OCOTP) 2 on MXC 3 4 This IP can be found on the following SoCs: 5 - Vybrid VF610, 6 - i.MX6. 7 8 Note that this IP is different from albeit similar to the IPs of the same name 9 that can be found on the following SoCs: 10 - i.MX23, 11 - i.MX28, 12 - i.MX50. 13 14 The section numbers in this file refer to the i.MX6 Reference Manual. 15 16 A fuse word contains 32 fuse bit slots, as explained in 46.2.1. 17 18 A bank contains 8 fuse word slots, as explained in 46.2.1 and shown by the 19 memory map in 46.4. 20 21 Some fuse bit or word slots may not have the corresponding fuses actually 22 implemented in the fusebox. 23 24 See the README files of the SoCs using this driver in order to know the 25 conventions used by U-Boot to store some specific data in the fuses, e.g. MAC 26 addresses. 27 28 Fuse operations: 29 30 Read 31 Read operations are implemented as read accesses to the shadow registers, 32 using "Bankx Wordy" from the memory map in 46.4. This is explained in 33 detail by the first two paragraphs in 46.2.1.2. 34 35 Sense 36 Sense operations are implemented as the direct fusebox read explained by 37 the steps in 46.2.1.2. 38 39 Program 40 Program operations are implemented as explained by the steps in 46.2.1.3. 41 Following this operation, the shadow registers are not reloaded by the 42 hardware. 43 44 Override 45 Override operations are implemented as write accesses to the shadow 46 registers, as explained by the first paragraph in 46.2.1.3. 47 48 Configuration: 49 50 CONFIG_MXC_OCOTP 51 Define this to enable the mxc_ocotp driver. 52
README.mxs
1 Booting U-Boot on a MXS processor 2 ================================= 3 4 This document describes the MXS U-Boot port. This document mostly covers topics 5 related to making the module/board bootable. 6 7 Terminology 8 ----------- 9 10 The term "MXS" refers to a family of Freescale SoCs that is composed by MX23 11 and MX28. 12 13 The dollar symbol ($) introduces a snipped of shell code. This shall be typed 14 into the unix command prompt in U-Boot source code root directory. 15 16 The (=>) introduces a snipped of code that should by typed into U-Boot command 17 prompt 18 19 Contents 20 -------- 21 22 1) Prerequisites 23 2) Compiling U-Boot for a MXS based board 24 3) Installation of U-Boot for a MXS based board to SD card 25 4) Installation of U-Boot into NAND flash on a MX28 based board 26 5) Installation of U-Boot into SPI NOR flash on a MX28 based board 27 28 1) Prerequisites 29 ---------------- 30 31 To make a MXS based board bootable, some tools are necessary. The only 32 mandatory tool is the "mxsboot" tool found in U-Boot source tree. The 33 tool is built automatically when compiling U-Boot for i.MX23 or i.MX28. 34 35 The production of BootStream image is handled via "mkimage", which is 36 also part of the U-Boot source tree. The "mkimage" requires OpenSSL 37 development libraries to be installed. In case of Debian and derivates, 38 this is installed by running: 39 40 $ sudo apt-get install libssl-dev 41 42 NOTE: The "elftosb" tool distributed by Freescale Semiconductor is no 43 longer necessary for general use of U-Boot on i.MX23 and i.MX28. 44 The mkimage supports generation of BootStream images encrypted 45 with a zero key, which is the vast majority of use-cases. In 46 case you do need to produce image encrypted with non-zero key 47 or other special features, please use the "elftosb" tool, 48 otherwise continue to section 2). The installation procedure of 49 the "elftosb" is outlined below: 50 51 Firstly, obtain the elftosb archive from the following location: 52 53 ftp://ftp.denx.de/pub/tools/elftosb-10.12.01.tar.gz 54 55 We use a $VER variable here to denote the current version. At the time of 56 writing of this document, that is "10.12.01". To obtain the file from command 57 line, use: 58 59 $ VER="10.12.01" 60 $ wget ftp://ftp.denx.de/pub/tools/elftosb-${VER}.tar.gz 61 62 Extract the file: 63 64 $ tar xzf elftosb-${VER}.tar.gz 65 66 Compile the file. We need to manually tell the linker to use also libm: 67 68 $ cd elftosb-${VER}/ 69 $ make LIBS="-lstdc++ -lm" elftosb 70 71 Optionally, remove debugging symbols from elftosb: 72 73 $ strip bld/linux/elftosb 74 75 Finally, install the "elftosb" binary. The "install" target is missing, so just 76 copy the binary by hand: 77 78 $ sudo cp bld/linux/elftosb /usr/local/bin/ 79 80 Make sure the "elftosb" binary can be found in your $PATH, in this case this 81 means "/usr/local/bin/" has to be in your $PATH. 82 83 2) Compiling U-Boot for a MXS based board 84 ------------------------------------------- 85 86 Compiling the U-Boot for a MXS board is straightforward and done as compiling 87 U-Boot for any other ARM device. For cross-compiler setup, please refer to 88 ELDK5.0 documentation. First, clean up the source code: 89 90 $ make mrproper 91 92 Next, configure U-Boot for a MXS based board 93 94 $ make <mxs_based_board_name>_config 95 96 Examples: 97 98 1. For building U-Boot for Aries M28EVK board: 99 100 $ make m28evk_config 101 102 2. For building U-Boot for Freescale MX28EVK board: 103 104 $ make mx28evk_config 105 106 3. For building U-Boot for Freescale MX23EVK board: 107 108 $ make mx23evk_config 109 110 4. For building U-Boot for Olimex MX23 Olinuxino board: 111 112 $ make mx23_olinuxino_config 113 114 Lastly, compile U-Boot and prepare a "BootStream". The "BootStream" is a special 115 type of file, which MXS CPUs can boot. This is handled by the following 116 command: 117 118 $ make u-boot.sb 119 120 HINT: To speed-up the build process, you can add -j<N>, where N is number of 121 compiler instances that'll run in parallel. 122 123 The code produces "u-boot.sb" file. This file needs to be augmented with a 124 proper header to allow successful boot from SD or NAND. Adding the header is 125 discussed in the following chapters. 126 127 NOTE: The process that produces u-boot.sb uses the mkimage to generate the 128 BootStream. The BootStream is encrypted with zero key. In case you need 129 some special features of the BootStream and plan on using the "elftosb" 130 tool instead, the invocation to produce a compatible BootStream with the 131 one produced by mkimage is outlined below. For further details, refer to 132 the documentation bundled with the "elftosb" package. 133 134 $ elftosb -zf imx23 -c arch/arm/cpu/arm926ejs/mxs/u-boot-imx23.bd \ 135 -o u-boot.sb 136 $ elftosb -zf imx28 -c arch/arm/cpu/arm926ejs/mxs/u-boot-imx28.bd \ 137 -o u-boot.sb 138 139 3) Installation of U-Boot for a MXS based board to SD card 140 ---------------------------------------------------------- 141 142 To boot a MXS based board from SD, set the boot mode DIP switches according to 143 to MX28 manual, section 12.2.1 (Table 12-2) or MX23 manual, section 35.1.2 144 (Table 35-3). 145 146 The SD card used to boot U-Boot must contain a DOS partition table, which in 147 turn carries a partition of special type and which contains a special header. 148 The rest of partitions in the DOS partition table can be used by the user. 149 150 To prepare such partition, use your favourite partitioning tool. The partition 151 must have the following parameters: 152 153 * Start sector .......... sector 2048 154 * Partition size ........ at least 1024 kb 155 * Partition type ........ 0x53 (sometimes "OnTrack DM6 Aux3") 156 157 For example in Linux fdisk, the sequence for a clear card follows. Be sure to 158 run fdisk with the option "-u=sectors" to set units to sectors: 159 160 * o ..................... create a clear partition table 161 * n ..................... create new partition 162 * p ............. primary partition 163 * 1 ............. first partition 164 * 2048 .......... first sector is 2048 165 * +1M ........... make the partition 1Mb big 166 * t 1 ................... change first partition ID 167 * 53 ............ change the ID to 0x53 (OnTrack DM6 Aux3) 168 * <create other partitions> 169 * w ..................... write partition table to disk 170 171 The partition layout is ready, next the special partition must be filled with 172 proper contents. The contents is generated by running the following command 173 (see chapter 2)): 174 175 $ ./tools/mxsboot sd u-boot.sb u-boot.sd 176 177 The resulting file, "u-boot.sd", shall then be written to the partition. In this 178 case, we assume the first partition of the SD card is /dev/mmcblk0p1: 179 180 $ dd if=u-boot.sd of=/dev/mmcblk0p1 181 182 Last step is to insert the card into the MXS based board and boot. 183 184 NOTE: If the user needs to adjust the start sector, the "mxsboot" tool contains 185 a "-p" switch for that purpose. The "-p" switch takes the sector number as 186 an argument. 187 188 4) Installation of U-Boot into NAND flash on a MX28 based board 189 --------------------------------------------------------------- 190 191 To boot a MX28 based board from NAND, set the boot mode DIP switches according 192 to MX28 manual section 12.2.1 (Table 12-2), PORT=GPMI, NAND 1.8 V. 193 194 There are two possibilities when preparing an image writable to NAND flash. 195 196 I) The NAND wasn't written at all yet or the BCB is broken 197 ---------------------------------------------------------- 198 In this case, both BCB (FCB and DBBT) and firmware needs to be 199 written to NAND. To generate NAND image containing all these, 200 there is a tool called "mxsboot" in the "tools/" directory. The tool 201 is invoked on "u-boot.sb" file from chapter 2): 202 203 $ ./tools/mxsboot nand u-boot.sb u-boot.nand 204 205 NOTE: The above invokation works for NAND flash with geometry of 206 2048b per page, 64b OOB data, 128kb erase size. If your chip 207 has a different geometry, please use: 208 209 -w <size> change page size (default 2048 b) 210 -o <size> change oob size (default 64 b) 211 -e <size> change erase size (default 131072 b) 212 213 The geometry information can be obtained from running U-Boot 214 on the MX28 board by issuing the "nand info" command. 215 216 The resulting file, "u-boot.nand" can be written directly to NAND 217 from the U-Boot prompt. To simplify the process, the U-Boot default 218 environment contains script "update_nand_full" to update the system. 219 220 This script expects a working TFTP server containing the file 221 "u-boot.nand" in it's root directory. This can be changed by 222 adjusting the "update_nand_full_filename" variable. 223 224 To update the system, run the following in U-Boot prompt: 225 226 => run update_nand_full 227 228 In case you would only need to update the bootloader in future, 229 see II) below. 230 231 II) The NAND was already written with a good BCB 232 ------------------------------------------------ 233 This part applies after the part I) above was done at least once. 234 235 If part I) above was done correctly already, there is no need to 236 write the FCB and DBBT parts of NAND again. It's possible to upgrade 237 only the bootloader image. 238 239 To simplify the process of firmware update, the U-Boot default 240 environment contains script "update_nand_firmware" to update only 241 the firmware, without rewriting FCB and DBBT. 242 243 This script expects a working TFTP server containing the file 244 "u-boot.sb" in it's root directory. This can be changed by 245 adjusting the "update_nand_firmware_filename" variable. 246 247 To update the system, run the following in U-Boot prompt: 248 249 => run update_nand_firmware 250 251 III) Special settings for the update scripts 252 -------------------------------------------- 253 There is a slight possibility of the user wanting to adjust the 254 STRIDE and COUNT options of the NAND boot. For description of these, 255 see MX28 manual section 12.12.1.2 and 12.12.1.3. 256 257 The update scripts take this possibility into account. In case the 258 user changes STRIDE by blowing fuses, the user also has to change 259 "update_nand_stride" variable. In case the user changes COUNT by 260 blowing fuses, the user also has to change "update_nand_count" 261 variable for the update scripts to work correctly. 262 263 In case the user needs to boot a firmware image bigger than 1Mb, the 264 user has to adjust the "update_nand_firmware_maxsz" variable for the 265 update scripts to work properly. 266 267 5) Installation of U-Boot into SPI NOR flash on a MX28 based board 268 ------------------------------------------------------------------ 269 270 The u-boot.sb file can be directly written to SPI NOR from U-Boot prompt. 271 272 Load u-boot.sb into RAM, this can be done in several ways and one way is to use 273 tftp: 274 => tftp u-boot.sb 0x42000000 275 276 Probe the SPI NOR flash: 277 => sf probe 278 279 (SPI NOR should be succesfully detected in this step) 280 281 Erase the blocks where U-Boot binary will be written to: 282 => sf erase 0x0 0x80000 283 284 Write u-boot.sb to SPI NOR: 285 => sf write 0x42000000 0 0x80000 286 287 Power off the board and set the boot mode DIP switches to boot from the SPI NOR 288 according to MX28 manual section 12.2.1 (Table 12-2) 289 290 Last step is to power up the board and U-Boot should start from SPI NOR. 291
README.mxsimage
1 Freescale i.MX233/i.MX28 SB image generator via mkimage 2 ======================================================= 3 4 This tool allows user to produce SB BootStream encrypted with a zero key. 5 Such a BootStream is then bootable on i.MX23/i.MX28. 6 7 Usage -- producing image: 8 ========================= 9 The mxsimage tool is targeted to be a simple replacement for the elftosb2 . 10 To generate an image, write an image configuration file and run: 11 12 mkimage -A arm -O u-boot -T mxsimage -n <path to configuration file> \ 13 <output bootstream file> 14 15 The output bootstream file is usually using the .sb file extension. Note 16 that the example configuration files for producing bootable BootStream with 17 the U-Boot bootloader can be found under arch/arm/boot/cpu/arm926ejs/mxs/ 18 directory. See the following files: 19 20 mxsimage.mx23.cfg -- This is an example configuration for i.MX23 21 mxsimage.mx28.cfg -- This is an example configuration for i.MX28 22 23 Each configuration file uses very simple instruction semantics and a few 24 additional rules have to be followed so that a useful image can be produced. 25 These semantics and rules will be outlined now. 26 27 - Each line of the configuration file contains exactly one instruction. 28 - Every numeric value must be encoded in hexadecimal and in format 0xabcdef12 . 29 - The configuration file is a concatenation of blocks called "sections" and 30 optionally "DCD blocks" (see below), and optional flags lines. 31 - Each "section" is started by the "SECTION" instruction. 32 - The "SECTION" instruction has the following semantics: 33 34 SECTION u32_section_number [BOOTABLE] 35 - u32_section_number :: User-selected ID of the section 36 - BOOTABLE :: Sets the section as bootable 37 38 - A bootable section is one from which the BootROM starts executing 39 subsequent instructions or code. Exactly one section must be selected 40 as bootable, usually the one containing the instructions and data to 41 load the bootloader. 42 43 - A "SECTION" must be immediatelly followed by a "TAG" instruction. 44 - The "TAG" instruction has the following semantics: 45 46 TAG [LAST] 47 - LAST :: Flag denoting the last section in the file 48 49 - After a "TAG" unstruction, any of the following instructions may follow 50 in any order and any quantity: 51 52 NOOP 53 - This instruction does nothing 54 55 LOAD u32_address string_filename 56 - Instructs the BootROM to load file pointed by "string_filename" onto 57 address "u32_address". 58 59 LOAD IVT u32_address u32_IVT_entry_point 60 - Crafts and loads IVT onto address "u32_address" with the entry point 61 of u32_IVT_entry_point. 62 - i.MX28-specific instruction! 63 64 LOAD DCD u32_address u32_DCD_block_ID 65 - Loads the DCD block with ID "u32_DCD_block_ID" onto address 66 "u32_address" and executes the contents of this DCD block 67 - i.MX28-specific instruction! 68 69 FILL u32_address u32_pattern u32_length 70 - Starts to write memory from addres "u32_address" with a pattern 71 specified by "u32_pattern". Writes exactly "u32_length" bytes of the 72 pattern. 73 74 JUMP [HAB] u32_address [u32_r0_arg] 75 - Jumps onto memory address specified by "u32_address" by setting this 76 address in PT. The BootROM will pass the "u32_r0_arg" value in ARM 77 register "r0" to the executed code if this option is specified. 78 Otherwise, ARM register "r0" will default to value 0x00000000. The 79 optional "HAB" flag is i.MX28-specific flag turning on the HAB boot. 80 81 CALL [HAB] u32_address [u32_r0_arg] 82 - See JUMP instruction above, as the operation is exactly the same with 83 one difference. The CALL instruction does allow returning into the 84 BootROM from the executed code. U-Boot makes use of this in it's SPL 85 code. 86 87 MODE string_mode 88 - Restart the CPU and start booting from device specified by the 89 "string_mode" argument. The "string_mode" differs for each CPU 90 and can be: 91 i.MX23, string_mode = USB/I2C/SPI1_FLASH/SPI2_FLASH/NAND_BCH 92 JTAG/SPI3_EEPROM/SD_SSP0/SD_SSP1 93 i.MX28, string_mode = USB/I2C/SPI2_FLASH/SPI3_FLASH/NAND_BCH 94 JTAG/SPI2_EEPROM/SD_SSP0/SD_SSP1 95 96 - An optional "DCD" blocks can be added at the begining of the configuration 97 file. Note that the DCD is only supported on i.MX28. 98 - The DCD blocks must be inserted before the first "section" in the 99 configuration file. 100 - The DCD block has the following semantics: 101 102 DCD u32_DCD_block_ID 103 - u32_DCD_block_ID :: The ID number of the DCD block, must match 104 the ID number used by "LOAD DCD" instruction. 105 106 - The DCD block must be followed by one of the following instructions. All 107 of the instructions operate either on 1, 2 or 4 bytes. This is selected by 108 the 'n' suffix of the instruction: 109 110 WRITE.n u32_address u32_value 111 - Write the "u32_value" to the "u32_address" address. 112 113 ORR.n u32_address u32_value 114 - Read the "u32_address", perform a bitwise-OR with the "u32_value" and 115 write the result back to "u32_address". 116 117 ANDC.n u32_address u32_value 118 - Read the "u32_address", perform a bitwise-AND with the complement of 119 "u32_value" and write the result back to "u32_address". 120 121 EQZ.n u32_address u32_count 122 - Read the "u32_address" at most "u32_count" times and test if the value 123 read is zero. If it is, break the loop earlier. 124 125 NEZ.n u32_address u32_count 126 - Read the "u32_address" at most "u32_count" times and test if the value 127 read is non-zero. If it is, break the loop earlier. 128 129 EQ.n u32_address u32_mask 130 - Read the "u32_address" in a loop and test if the result masked with 131 "u32_mask" equals the "u32_mask". If the values are equal, break the 132 reading loop. 133 134 NEQ.n u32_address u32_mask 135 - Read the "u32_address" in a loop and test if the result masked with 136 "u32_mask" does not equal the "u32_mask". If the values are not equal, 137 break the reading loop. 138 139 NOOP 140 - This instruction does nothing. 141 142 - An optional flags lines can be one of the following: 143 144 DISPLAYPROGRESS 145 - Enable boot progress output form the BootROM. 146 147 - If the boot progress output from the BootROM is enabled, the BootROM will 148 produce a letter on the Debug UART for each instruction it started processing. 149 Here is a mapping between the above instructions and the BootROM output: 150 151 H -- SB Image header loaded 152 T -- TAG instruction 153 N -- NOOP instruction 154 L -- LOAD instruction 155 F -- FILL instruction 156 J -- JUMP instruction 157 C -- CALL instruction 158 M -- MODE instruction 159 160 Usage -- verifying image: 161 ========================= 162 163 The mxsimage can also verify and dump contents of an image. Use the following 164 syntax to verify and dump contents of an image: 165 166 mkimage -l <input bootstream file> 167 168 This will output all the information from the SB image header and all the 169 instructions contained in the SB image. It will also check if the various 170 checksums in the SB image are correct. 171
README.N1213
1 N1213 is a configurable hard/soft core of NDS32's N12 CPU family. 2 3 Features 4 ======== 5 6 CPU Core 7 - 16-/32-bit mixable instruction format. 8 - 32 general-purpose 32-bit registers. 9 - 8-stage pipeline. 10 - Dynamic branch prediction. 11 - 32/64/128/256 BTB. 12 - Return address stack (RAS). 13 - Vector interrupts for internal/external. 14 interrupt controller with 6 hardware interrupt signals. 15 - 3 HW-level nested interruptions. 16 - User and super-user mode support. 17 - Memory-mapped I/O. 18 - Address space up to 4GB. 19 20 Memory Management Unit 21 - TLB 22 - 4/8-entry fully associative iTLB/dTLB. 23 - 32/64/128-entry 4-way set-associati.ve main TLB. 24 - TLB locking support 25 - Optional hardware page table walker. 26 - Two groups of page size support. 27 - 4KB & 1MB. 28 - 8KB & 1MB. 29 30 Memory Subsystem 31 - I & D cache. 32 - Virtually indexed and physically tagged. 33 - Cache size: 8KB/16KB/32KB/64KB. 34 - Cache line size: 16B/32B. 35 - Set associativity: 2-way, 4-way or direct-mapped. 36 - Cache locking support. 37 - I & D local memory (LM). 38 - Size: 4KB to 1MB. 39 - Bank numbers: 1 or 2. 40 - Optional 1D/2D DMA engine. 41 - Internal or external to CPU core. 42 43 Bus Interface 44 - Synchronous/Asynchronous AHB bus: 0, 1 or 2 ports. 45 - Synchronous High speed memory port. 46 (HSMP): 0, 1 or 2 ports. 47 48 Debug 49 - JTAG debug interface. 50 - Embedded debug module (EDM). 51 - Optional embedded program tracer interface. 52 53 Miscellaneous 54 - Programmable data endian control. 55 - Performance monitoring mechanism. 56
README.nand
1 # SPDX-License-Identifier: GPL-2.0+ 2 NAND FLASH commands and notes 3 4 See NOTE below!!! 5 6 # (C) Copyright 2003 7 # Dave Ellis, SIXNET, dge (a] sixnetio.com 8 # 9 10 Commands: 11 12 nand bad 13 Print a list of all of the bad blocks in the current device. 14 15 nand device 16 Print information about the current NAND device. 17 18 nand device num 19 Make device `num' the current device and print information about it. 20 21 nand erase off|partition size 22 nand erase clean [off|partition size] 23 Erase `size' bytes starting at offset `off'. Alternatively partition 24 name can be specified, in this case size will be eventually limited 25 to not exceed partition size (this behaviour applies also to read 26 and write commands). Only complete erase blocks can be erased. 27 28 If `erase' is specified without an offset or size, the entire flash 29 is erased. If `erase' is specified with partition but without an 30 size, the entire partition is erased. 31 32 If `clean' is specified, a JFFS2-style clean marker is written to 33 each block after it is erased. 34 35 This command will not erase blocks that are marked bad. There is 36 a debug option in cmd_nand.c to allow bad blocks to be erased. 37 Please read the warning there before using it, as blocks marked 38 bad by the manufacturer must _NEVER_ be erased. 39 40 nand info 41 Print information about all of the NAND devices found. 42 43 nand read addr ofs|partition size 44 Read `size' bytes from `ofs' in NAND flash to `addr'. Blocks that 45 are marked bad are skipped. If a page cannot be read because an 46 uncorrectable data error is found, the command stops with an error. 47 48 nand read.oob addr ofs|partition size 49 Read `size' bytes from the out-of-band data area corresponding to 50 `ofs' in NAND flash to `addr'. This is limited to the 16 bytes of 51 data for one 512-byte page or 2 256-byte pages. There is no check 52 for bad blocks or ECC errors. 53 54 nand write addr ofs|partition size 55 Write `size' bytes from `addr' to `ofs' in NAND flash. Blocks that 56 are marked bad are skipped. If a page cannot be read because an 57 uncorrectable data error is found, the command stops with an error. 58 59 As JFFS2 skips blocks similarly, this allows writing a JFFS2 image, 60 as long as the image is short enough to fit even after skipping the 61 bad blocks. Compact images, such as those produced by mkfs.jffs2 62 should work well, but loading an image copied from another flash is 63 going to be trouble if there are any bad blocks. 64 65 nand write.trimffs addr ofs|partition size 66 Enabled by the CONFIG_CMD_NAND_TRIMFFS macro. This command will write to 67 the NAND flash in a manner identical to the 'nand write' command 68 described above -- with the additional check that all pages at the end 69 of eraseblocks which contain only 0xff data will not be written to the 70 NAND flash. This behaviour is required when flashing UBI images 71 containing UBIFS volumes as per the UBI FAQ[1]. 72 73 [1] http://www.linux-mtd.infradead.org/doc/ubi.html#L_flasher_algo 74 75 nand write.oob addr ofs|partition size 76 Write `size' bytes from `addr' to the out-of-band data area 77 corresponding to `ofs' in NAND flash. This is limited to the 16 bytes 78 of data for one 512-byte page or 2 256-byte pages. There is no check 79 for bad blocks. 80 81 nand read.raw addr ofs|partition [count] 82 nand write.raw addr ofs|partition [count] 83 Read or write one or more pages at "ofs" in NAND flash, from or to 84 "addr" in memory. This is a raw access, so ECC is avoided and the 85 OOB area is transferred as well. If count is absent, it is assumed 86 to be one page. As with .yaffs2 accesses, the data is formatted as 87 a packed sequence of "data, oob, data, oob, ..." -- no alignment of 88 individual pages is maintained. 89 90 Configuration Options: 91 92 CONFIG_SYS_NAND_U_BOOT_OFFS 93 NAND Offset from where SPL will read u-boot image. This is the starting 94 address of u-boot MTD partition in NAND. 95 96 CONFIG_CMD_NAND 97 Enables NAND support and commands. 98 99 CONFIG_CMD_NAND_TORTURE 100 Enables the torture command (see description of this command below). 101 102 CONFIG_SYS_MAX_NAND_DEVICE 103 The maximum number of NAND devices you want to support. 104 105 CONFIG_SYS_NAND_MAX_ECCPOS 106 If specified, overrides the maximum number of ECC bytes 107 supported. Useful for reducing image size, especially with SPL. 108 This must be at least 48 if nand_base.c is used. 109 110 CONFIG_SYS_NAND_MAX_OOBFREE 111 If specified, overrides the maximum number of free OOB regions 112 supported. Useful for reducing image size, especially with SPL. 113 This must be at least 2 if nand_base.c is used. 114 115 CONFIG_SYS_NAND_MAX_CHIPS 116 The maximum number of NAND chips per device to be supported. 117 118 CONFIG_SYS_NAND_SELF_INIT 119 Traditionally, glue code in drivers/mtd/nand/nand.c has driven 120 the initialization process -- it provides the mtd and nand 121 structs, calls a board init function for a specific device, 122 calls nand_scan(), and registers with mtd. 123 124 This arrangement does not provide drivers with the flexibility to 125 run code between nand_scan_ident() and nand_scan_tail(), or other 126 deviations from the "normal" flow. 127 128 If a board defines CONFIG_SYS_NAND_SELF_INIT, drivers/mtd/nand/nand.c 129 will make one call to board_nand_init(), with no arguments. That 130 function is responsible for calling a driver init function for 131 each NAND device on the board, that performs all initialization 132 tasks except setting mtd->name, and registering with the rest of 133 U-Boot. Those last tasks are accomplished by calling nand_register() 134 on the new mtd device. 135 136 Example of new init to be added to the end of an existing driver 137 init: 138 139 /* chip is struct nand_chip, and is now provided by the driver. */ 140 mtd = nand_to_mtd(&chip); 141 142 /* 143 * Fill in appropriate values if this driver uses these fields, 144 * or uses the standard read_byte/write_buf/etc. functions from 145 * nand_base.c that use these fields. 146 */ 147 chip.IO_ADDR_R = ...; 148 chip.IO_ADDR_W = ...; 149 150 if (nand_scan_ident(mtd, CONFIG_SYS_MAX_NAND_CHIPS, NULL)) 151 error out 152 153 /* 154 * Insert here any code you wish to run after the chip has been 155 * identified, but before any other I/O is done. 156 */ 157 158 if (nand_scan_tail(mtd)) 159 error out 160 161 /* 162 * devnum is the device number to be used in nand commands 163 * and in mtd->name. Must be less than CONFIG_SYS_MAX_NAND_DEVICE. 164 */ 165 if (nand_register(devnum, mtd)) 166 error out 167 168 In addition to providing more flexibility to the driver, it reduces 169 the difference between a U-Boot driver and its Linux counterpart. 170 nand_init() is now reduced to calling board_nand_init() once, and 171 printing a size summary. This should also make it easier to 172 transition to delayed NAND initialization. 173 174 Please convert your driver even if you don't need the extra 175 flexibility, so that one day we can eliminate the old mechanism. 176 177 178 CONFIG_SYS_NAND_ONFI_DETECTION 179 Enables detection of ONFI compliant devices during probe. 180 And fetching device parameters flashed on device, by parsing 181 ONFI parameter page. 182 183 Platform specific options 184 ========================= 185 CONFIG_NAND_OMAP_GPMC 186 Enables omap_gpmc.c driver for OMAPx and AMxxxx platforms. 187 GPMC controller is used for parallel NAND flash devices, and can 188 do ECC calculation (not ECC error detection) for HAM1, BCH4, BCH8 189 and BCH16 ECC algorithms. 190 191 CONFIG_NAND_OMAP_ELM 192 Enables omap_elm.c driver for OMAPx and AMxxxx platforms. 193 ELM controller is used for ECC error detection (not ECC calculation) 194 of BCH4, BCH8 and BCH16 ECC algorithms. 195 Some legacy platforms like OMAP3xx do not have in-built ELM h/w engine, 196 thus such SoC platforms need to depend on software library for ECC error 197 detection. However ECC calculation on such plaforms would still be 198 done by GPMC controller. 199 200 CONFIG_SPL_NAND_AM33XX_BCH 201 Enables SPL-NAND driver (am335x_spl_bch.c) which supports ELM based 202 hardware ECC correction. This is useful for platforms which have ELM 203 hardware engine and use NAND boot mode. 204 Some legacy platforms like OMAP3xx do not have in-built ELM h/w engine, 205 so those platforms should use CONFIG_SPL_NAND_SIMPLE for enabling 206 SPL-NAND driver with software ECC correction support. 207 208 CONFIG_NAND_OMAP_ECCSCHEME 209 On OMAP platforms, this CONFIG specifies NAND ECC scheme. 210 It can take following values: 211 OMAP_ECC_HAM1_CODE_SW 212 1-bit Hamming code using software lib. 213 (for legacy devices only) 214 OMAP_ECC_HAM1_CODE_HW 215 1-bit Hamming code using GPMC hardware. 216 (for legacy devices only) 217 OMAP_ECC_BCH4_CODE_HW_DETECTION_SW 218 4-bit BCH code (unsupported) 219 OMAP_ECC_BCH4_CODE_HW 220 4-bit BCH code (unsupported) 221 OMAP_ECC_BCH8_CODE_HW_DETECTION_SW 222 8-bit BCH code with 223 - ecc calculation using GPMC hardware engine, 224 - error detection using software library. 225 - requires CONFIG_BCH to enable software BCH library 226 (For legacy device which do not have ELM h/w engine) 227 OMAP_ECC_BCH8_CODE_HW 228 8-bit BCH code with 229 - ecc calculation using GPMC hardware engine, 230 - error detection using ELM hardware engine. 231 OMAP_ECC_BCH16_CODE_HW 232 16-bit BCH code with 233 - ecc calculation using GPMC hardware engine, 234 - error detection using ELM hardware engine. 235 236 How to select ECC scheme on OMAP and AMxx platforms ? 237 ----------------------------------------------------- 238 Though higher ECC schemes have more capability to detect and correct 239 bit-flips, but still selection of ECC scheme is dependent on following 240 - hardware engines present in SoC. 241 Some legacy OMAP SoC do not have ELM h/w engine thus such 242 SoC cannot support BCHx_HW ECC schemes. 243 - size of OOB/Spare region 244 With higher ECC schemes, more OOB/Spare area is required to 245 store ECC. So choice of ECC scheme is limited by NAND oobsize. 246 247 In general following expression can help: 248 NAND_OOBSIZE >= 2 + (NAND_PAGESIZE / 512) * ECC_BYTES 249 where 250 NAND_OOBSIZE = number of bytes available in 251 OOB/spare area per NAND page. 252 NAND_PAGESIZE = bytes in main-area of NAND page. 253 ECC_BYTES = number of ECC bytes generated to 254 protect 512 bytes of data, which is: 255 3 for HAM1_xx ecc schemes 256 7 for BCH4_xx ecc schemes 257 14 for BCH8_xx ecc schemes 258 26 for BCH16_xx ecc schemes 259 260 example to check for BCH16 on 2K page NAND 261 NAND_PAGESIZE = 2048 262 NAND_OOBSIZE = 64 263 2 + (2048 / 512) * 26 = 106 > NAND_OOBSIZE 264 Thus BCH16 cannot be supported on 2K page NAND. 265 266 However, for 4K pagesize NAND 267 NAND_PAGESIZE = 4096 268 NAND_OOBSIZE = 224 269 ECC_BYTES = 26 270 2 + (4096 / 512) * 26 = 210 < NAND_OOBSIZE 271 Thus BCH16 can be supported on 4K page NAND. 272 273 274 CONFIG_NAND_OMAP_GPMC_PREFETCH 275 On OMAP platforms that use the GPMC controller 276 (CONFIG_NAND_OMAP_GPMC_PREFETCH), this options enables the code that 277 uses the prefetch mode to speed up read operations. 278 279 NOTE: 280 ===== 281 282 The Disk On Chip driver is currently broken and has been for some time. 283 There is a driver in drivers/mtd/nand, taken from Linux, that works with 284 the current NAND system but has not yet been adapted to the u-boot 285 environment. 286 287 Additional improvements to the NAND subsystem by Guido Classen, 10-10-2006 288 289 JFFS2 related commands: 290 291 implement "nand erase clean" and old "nand erase" 292 using both the new code which is able to skip bad blocks 293 "nand erase clean" additionally writes JFFS2-cleanmarkers in the oob. 294 295 Miscellaneous and testing commands: 296 "markbad [offset]" 297 create an artificial bad block (for testing bad block handling) 298 299 "scrub [offset length]" 300 like "erase" but don't skip bad block. Instead erase them. 301 DANGEROUS!!! Factory set bad blocks will be lost. Use only 302 to remove artificial bad blocks created with the "markbad" command. 303 304 "torture offset [size]" 305 Torture block to determine if it is still reliable. 306 Enabled by the CONFIG_CMD_NAND_TORTURE configuration option. 307 This command returns 0 if the block is still reliable, else 1. 308 If the block is detected as unreliable, it is up to the user to decide to 309 mark this block as bad. 310 The analyzed block is put through 3 erase / write cycles (or less if the block 311 is detected as unreliable earlier). 312 This command can be used in scripts, e.g. together with the markbad command to 313 automate retries and handling of possibly newly detected bad blocks if the 314 nand write command fails. 315 It can also be used manually by users having seen some NAND errors in logs to 316 search the root cause of these errors. 317 The underlying nand_torture() function is also useful for code willing to 318 automate actions following a nand->write() error. This would e.g. be required 319 in order to program or update safely firmware to NAND, especially for the UBI 320 part of such firmware. 321 Optionally, a second parameter size can be given to test multiple blocks with 322 one call. If size is not a multiple of the NAND's erase size, then the block 323 that contains offset + size will be tested in full. If used with size, this 324 command returns 0 if all tested blocks have been found reliable, else 1. 325 326 327 NAND locking command (for chips with active LOCKPRE pin) 328 329 "nand lock" 330 set NAND chip to lock state (all pages locked) 331 332 "nand lock tight" 333 set NAND chip to lock tight state (software can't change locking anymore) 334 335 "nand lock status" 336 displays current locking status of all pages 337 338 "nand unlock [offset] [size]" 339 unlock consecutive area (can be called multiple times for different areas) 340 341 "nand unlock.allexcept [offset] [size]" 342 unlock all except specified consecutive area 343 344 I have tested the code with board containing 128MiB NAND large page chips 345 and 32MiB small page chips. 346
README.nand-boot-ppc440
1 ----------------------------- 2 NAND boot on PPC440 platforms 3 ----------------------------- 4 5 This document describes the U-Boot NAND boot feature as it 6 is implemented for the AMCC Sequoia (PPC440EPx) board. 7 8 The PPC440EP(x)/GR(x) cpu's can boot directly from NAND FLASH, 9 completely without NOR FLASH. This can be done by using the NAND 10 boot feature of the 440 NAND flash controller (NDFC). 11 12 Here a short description of the different boot stages: 13 14 a) IPL (Initial Program Loader, integrated inside CPU) 15 ------------------------------------------------------ 16 Will load first 4k from NAND (SPL) into cache and execute it from there. 17 18 b) SPL (Secondary Program Loader) 19 --------------------------------- 20 Will load special U-Boot version (NUB) from NAND and execute it. This SPL 21 has to fit into 4kByte. It sets up the CPU and configures the SDRAM 22 controller and the NAND controller so that the special U-Boot image can be 23 loaded from NAND to SDRAM. 24 This special image is build in the directory "nand_spl". 25 26 c) NUB (NAND U-Boot) 27 -------------------- 28 This NAND U-Boot (NUB) is a special U-Boot version which can be started 29 from RAM. Therefore it mustn't (re-)configure the SDRAM controller. 30 31 On 440EPx the SPL is copied to internal SRAM before the NAND controller 32 is set up. While still running from cache, I experienced problems accessing 33 the NAND controller. 34 35 36 Example: Build and install NAND boot image for Sequoia (440EPx): 37 38 a) Configure for sequoia with NAND boot support: 39 # make sequoia_nand_config 40 41 b) Build image(s) 42 # make 43 44 This will generate the SPL image in the "nand_spl" directory: 45 nand_spl/u-boot-spl.bin 46 Also another image is created spanning a whole NAND block (16kBytes): 47 nand_spl/u-boot-spl-16k.bin 48 The main NAND U-Boot image is generated in the toplevel directory: 49 u-boot.bin 50 A combined image of u-boot-spl-16k.bin and u-boot.bin is also created: 51 u-boot-nand.bin 52 53 This image should be programmed at offset 0 in the NAND flash: 54 55 # tftp 100000 /tftpboot/sequoia/u-boot-nand.bin 56 # nand erase 0 60000 57 # nand write 100000 0 60000 58 59 60 September 07 2006, Stefan Roese <sr (a] denx.de> 61
README.NDS32
1 NDS32 is a new high-performance 32-bit RISC microprocessor core. 2 3 http://www.andestech.com/ 4 5 AndeStar ISA 6 ============ 7 AndeStar is a patent-pending 16-bit/32-bit mixed-length instruction set to 8 achieve optimal system performance, code density, and power efficiency. 9 10 It contains the following features: 11 - Intermixable 32-bit and 16-bit instruction sets without the need for 12 mode switch. 13 - 16-bit instructions as a frequently used subset of 32-bit instructions. 14 - RISC-style register-based instruction set. 15 - 32 32-bit General Purpose Registers (GPR). 16 - Upto 1024 User Special Registers (USR) for existing and extension 17 instructions. 18 - Rich load/store instructions for... 19 - Single memory access with base address update. 20 - Multiple aligned and unaligned memory accesses for memory copy and stack 21 operations. 22 - Data prefetch to improve data cache performance. 23 - Non-bus locking synchronization instructions. 24 - PC relative jump and PC read instructions for efficient position independent 25 code. 26 - Multiply-add and multiple-sub with 64-bit accumulator. 27 - Instruction for efficient power management. 28 - Bi-endian support. 29 - Three instruction extension space for application acceleration: 30 - Performance extension. 31 - Andes future extensions (for floating-point, multimedia, etc.) 32 - Customer extensions. 33 34 AndesCore CPU 35 ============= 36 Andes Technology has 4 families of CPU cores: N12, N10, N9, N8. 37 38 For details about N12 CPU family, please check doc/README.N1213. 39 40 The NDS32 ports of u-boot, the Linux kernel, the GNU toolchain and 41 other associated software are actively supported by Andes Technology Corporation. 42
README.ne2000
1 This driver supports NE2000 compatible cards (those based on DP8390, 2 DP83902 and similar). It can be used with PCMCIA/CF cards provided 3 that the CCR is correctly initialized. 4 5 The code is based on sources from the Linux kernel (pcnet_cs.c, 6 8390.h) and eCOS(if_dp83902a.c, if_dp83902a.h). Both of these 2 7 wonderful world are GPL, so this is, of course, GPL. 8 9 I developed and tested this driver on a custom PXA255 based system and 10 with a billionton CF network card connected to the PCMCIA interface of 11 the micro (have a look at README.PXA_CF for the support of this port). 12 13 The options you have to specify in the config file are (with the 14 value for my board as an example): 15 16 #define CONFIG_DRIVER_NE2000 17 18 - Enables the driver 19 20 #define CONFIG_DRIVER_NE2000_BASE (0x20000000+0x300) 21 22 - Address where the board is mapped 23 24 #define CONFIG_DRIVER_NE2000_CCR (0x28000000+0x3f8) 25 26 - Address of the CCR (card configuration register). It could be found 27 by enabling DEBUG in cmd_pcmcia.c. If this is not defined nothing is 28 done as far as PCMCIA support is concerned. 29 30 #define CONFIG_DRIVER_NE2000_VAL (0x20) 31 32 - The value to be written in the CCR. It selects among different I/O 33 spaces that could be used by the card. 34 35 36 Enjoy! 37 38 Christian Pellegrin <chri (a] ascensit.com> 39
README.NetConsole
1 2 In U-Boot, we implemented the networked console via the standard 3 "devices" mechanism, which means that you can switch between the 4 serial and network input/output devices by adjusting the 'stdin' and 5 'stdout' environment variables. To switch to the networked console, 6 set either of these variables to "nc". Input and output can be 7 switched independently. 8 9 CONFIG_NETCONSOLE_BUFFER_SIZE - Override the default buffer size 10 11 We use an environment variable 'ncip' to set the IP address and the 12 port of the destination. The format is <ip_addr>:<port>. If <port> is 13 omitted, the value of 6666 is used. If the env var doesn't exist, the 14 broadcast address and port 6666 are used. If it is set to an IP 15 address of 0 (or 0.0.0.0) then no messages are sent to the network. 16 The source / listening port can be configured separately by setting 17 the 'ncinport' environment variable and the destination port can be 18 configured by setting the 'ncoutport' environment variable. 19 20 For example, if your server IP is 192.168.1.1, you could use: 21 22 => setenv nc 'setenv stdout nc;setenv stdin nc' 23 => setenv ncip 192.168.1.1 24 => saveenv 25 => run nc 26 27 28 On the host side, please use this script to access the console: 29 30 tools/netconsole <ip> [port] 31 32 The script uses netcat to talk to the board over UDP. It requires you to 33 specify the target IP address (or host name, assuming DNS is working). The 34 script can be interrupted by pressing ^T (CTRL-T). 35 36 Be aware that in some distributives (Fedora Core 5 at least) 37 usage of nc has been changed and -l and -p options are considered 38 as mutually exclusive. If nc complains about options provided, 39 you can just remove the -p option from the script. 40 41 It turns out that 'netcat' cannot be used to listen to broadcast 42 packets. We developed our own tool 'ncb' (see tools directory) that 43 listens to broadcast packets on a given port and dumps them to the 44 standard output. It will be built when compiling for a board which 45 has CONFIG_NETCONSOLE defined. If the netconsole script can find it 46 in PATH or in the same directory, it will be used instead. 47 48 For Linux, the network-based console needs special configuration. 49 Minimally, the host IP address needs to be specified. This can be 50 done either via the kernel command line, or by passing parameters 51 while loading the netconsole.o module (when used in a loadable module 52 configuration). Please refer to Documentation/networking/logging.txt 53 file for the original Ingo Molnar's documentation on how to pass 54 parameters to the loadable module. 55 56 The format of the kernel command line parameter (for the static 57 configuration) is as follows: 58 59 netconsole=[src-port]@[src-ip]/[<dev>],[tgt-port]@<tgt-ip>/[tgt-macaddr] 60 61 where 62 63 src-port source for UDP packets 64 (defaults to 6665) 65 src-ip source IP to use 66 (defaults to the interface's address) 67 dev network interface 68 (defaults to eth0) 69 tgt-port port for logging agent 70 (defaults to 6666) 71 tgt-ip IP address for logging agent 72 (this is the required parameter) 73 tgt-macaddr ethernet MAC address for logging agent 74 (defaults to broadcast) 75 76 Examples: 77 78 netconsole=4444 (a] 10.0.0.1/eth1,9353 (a] 10.0.0.2/12:34:56:78:9a:bc 79 80 or 81 82 netconsole=@/,@192.168.3.1/ 83 84 Please note that for the Linux networked console to work, the 85 ethernet interface has to be up by the time the netconsole driver is 86 initialized. This means that in case of static kernel configuration, 87 the respective Ethernet interface has to be brought up using the "IP 88 Autoconfiguration" kernel feature, which is usually done by defaults 89 in the ELDK-NFS-based environment. 90 91 To browse the Linux network console output, use the 'netcat' tool invoked 92 as follows: 93 94 nc -u -l -p 6666 95 96 Note that unlike the U-Boot implementation the Linux netconsole is 97 unidirectional, i. e. you have console output only in Linux. 98
README.nios2
1 Nios II is a 32-bit embedded-processor architecture designed 2 specifically for the Altera family of FPGAs. 3 4 Please refer to the link for more information on Nios II, 5 https://www.altera.com/products/processors/overview.html 6 7 Please refer to the link for Linux port and toolchains, 8 http://rocketboards.org/foswiki/view/Documentation/NiosIILinuxUserManual 9 10 The Nios II port of u-boot is controlled by device tree. Please check 11 out doc/README.fdt-control. 12 13 To add a new board/configuration (eg, mysystem) to u-boot, you will need 14 three files. 15 16 1. The device tree source which describes the hardware, dts file. 17 arch/nios2/dts/mysystem.dts 18 19 2. Default configuration of Kconfig, defconfig file. 20 configs/mysystem_defconfig 21 22 3. The legacy board header file. 23 include/configs/mysystem.h 24 25 The device tree source must be generated from your qsys/sopc design 26 using the sopc2dts tool. Then modified to fit your configuration. Please 27 find the sopc2dts download and usage at the wiki, 28 http://www.alterawiki.com/wiki/Sopc2dts 29 30 $ java -jar sopc2dts.jar --force-altr -i mysystem.sopcinfo -o mysystem.dts 31 32 You will need to add additional properties to the dts. Please find an 33 example at, arch/nios2/dts/10m50_devboard.dts. 34 35 1. Add "stdout-path=..." property with your serial path to the chosen 36 node, like this, 37 chosen { 38 stdout-path = &uart_0; 39 }; 40 41 2. If you use SPI/EPCS or I2C, you will need to add aliases to number 42 the sequence of these devices, like this, 43 aliases { 44 spi0 = &epcs_controller; 45 }; 46 47 Next, you will need a default config file. You may start with 48 10m50_defconfig, modify the options and save it. 49 50 $ make 10m50_defconfig 51 $ make menuconfig 52 $ make savedefconfig 53 $ cp defconfig configs/mysystem_defconfig 54 55 You will need to change the names of board header file and device tree, 56 and select the drivers with menuconfig. 57 58 Nios II architecture ---> 59 (mysystem) Board header file 60 Device Tree Control ---> 61 (mysystem) Default Device Tree for DT control 62 63 There is a selection of "Provider of DTB for DT control" in the Device 64 Tree Control menu. 65 66 ( ) Separate DTB for DT control, will cat the dtb to end of u-boot 67 binary, output u-boot-dtb.bin. This should be used for production. 68 If you use boot copier, like EPCS boot copier, make sure the copier 69 copies all the u-boot-dtb.bin, not just u-boot.bin. 70 71 ( ) Embedded DTB for DT control, will include the dtb inside the u-boot 72 binary. This is handy for development, eg, using gdb or nios2-download. 73 74 The last thing, legacy board header file describes those config options 75 not covered in Kconfig yet. You may copy it from 10m50_devboard.h. 76 77 $ cp include/configs/10m50_devboard.h include/configs/mysystem.h 78 79 Please change the SDRAM base and size to match your board. The base 80 should be cached virtual address, for Nios II with MMU it is 0xCxxx_xxxx 81 to 0xDxxx_xxxx. 82 83 #define CONFIG_SYS_SDRAM_BASE 0xc8000000 84 #define CONFIG_SYS_SDRAM_SIZE 0x08000000 85 86 You will need to change the environment variables location and setting, 87 too. You may change other configs to fit your board. 88 89 After all these changes, you may build and test. 90 91 $ export CROSS_COMPILE=nios2-elf- (or nios2-linux-gnu-) 92 $ make mysystem_defconfig 93 $ make 94 95 Enjoy! 96
README.nokia_rx51
1 Board: Nokia RX-51 aka N900 2 3 This board definition results in a u-boot.bin which can be chainloaded 4 from NOLO in qemu or on a real N900. It does very little hardware config 5 because NOLO has already configured the board. Only needed is enabling 6 internal eMMC memory via twl4030 regulator which is not enabled by NOLO. 7 8 NOLO is expecting a kernel image and will treat any image it finds in 9 onenand as such. This u-boot is intended to be flashed to the N900 like 10 a kernel. In order to transparently boot the original kernel, it will be 11 appended to u-boot.bin at 0x40000. NOLO will load the entire image into 12 (random) memory and execute u-boot, which saves hw revision, boot reason 13 and boot mode ATAGs set by NOLO. Then the bootscripts will attempt to load 14 uImage or boot.scr from a fat, ext2/ext3 or ext4 filesystem in external 15 SD card or internal eMMC memory. If this fails or keyboard is closed then 16 the appended kernel image will be booted using some generated and some 17 stored ATAGs (see boot order). 18 19 There is support for hardware watchdog. Hardware watchdog is started by 20 NOLO so u-boot must kick watchdog to prevent reboot device (but not very 21 often, max every 2 seconds). There is also support for framebuffer display 22 output with ANSI espace codes and the N900 HW keyboard input. USB tty works 23 but is disabled because it prevents the current Maemo kernel from booting. 24 25 When U-Boot is starting it enable IBE bit in Auxiliary Control Register, 26 which is needed for Thumb-2 ISA support. It is workaround for errata 430973. 27 28 Default boot order: 29 30 * 0. if keyboard is closed boot automatically attached kernel image 31 * 1. try boot from external SD card 32 * 2. try boot from internal eMMC memory 33 * 3. try boot from attached kernel image 34 35 Boot from SD or eMMC in this order: 36 37 * 1. 38 * 1.1 find boot.scr on first fat partition 39 * 1.2 find uImage on first fat parition 40 * 1.3 same order for 2. - 4. fat partition 41 * 2. same as 1. but for ext2/3 partition 42 * 3. same as 1. but for ext4 partition 43 44 45 Available additional commands/variables: 46 47 * run sercon - Use serial port for control 48 * run usbcon - Use usbtty for control 49 * run vgacon - Use framebuffer and HW keyboard for control (default) 50 51 * run sdboot - Boot from external SD card (see boot order) 52 * run emmcboot - Boot from internal eMMC memory (see boot order) 53 * run attachboot - Boot attached kernel image (attached to U-Boot binary) 54 55 * run scriptload - Load boot script ${mmcscriptfile} 56 * run scriptboot - Run loaded boot script 57 * run kernload - Load kernel image ${mmckernfile} 58 * run initrdload - Load initrd image ${mmcinitrdfile} 59 * run kernboot - Boot loaded kernel image 60 * run kerninitrdboot - Boot loaded kernel image with loaded initrd image 61 62 * run trymmcscriptboot - Try to load and boot script ${mmcscriptfile} 63 * run trymmckernboot - Try to load and boot kernel image ${mmckernfile} 64 * run trymmckerninitrdboot - Try to load and boot kernel image ${mmckernfile} 65 with initrd image ${mmcinitrdfile} 66 67 Additional variables for loading files from mmc: 68 69 * mmc ${mmcnum} (0 - external, 1 - internal) 70 * partition number ${mmcpart} (1 - 4) 71 * parition type ${mmctype} (fat, ext2) 72 73 Additional varuables for booting kernel: 74 75 * setup_omap_atag - Add OMAP table into atags structure (needs maemo kernel) 76 * setup_console_atag - Enable serial console in OMAP table 77 * setup_boot_reason_atag - Change boot reason in OMAP table 78 * setup_boot_mode_atag - Change boot mode in OMAP table 79 80 USB TTY: 81 82 Maemo kernel 2.6.28 will crash if u-boot enable usb tty. So USB TTY is disabled. 83 For enabling USB TTY just add this line to file include/configs/nokia_rx51.h 84 85 #define CONFIG_USB_TTY 86 87 88 ONENAND support: 89 90 ONENAND support is disabled because not working yet and cause linux kernel to 91 crash or no access to mtd. For enabling ONENAND support add this line at begin 92 of file include/configs/nokia_rx51.h 93 94 #define ONENAND_SUPPORT 95 96 97 UBIFS support: 98 99 UBIFS support is disabled, because U-Boot image is too big and cannot be 100 flashed with attached zImage to RX-51 kernel nand area. For enabling UBIFS 101 support first enable ONENAND support and then add this line at begin of file 102 include/configs/nokia_rx51.h 103 104 #define UBIFS_SUPPORT 105
README.nvme
1 # SPDX-License-Identifier: GPL-2.0+ 2 # 3 # Copyright (C) 2017 NXP Semiconductors 4 # Copyright (C) 2017 Bin Meng <bmeng.cn (a] gmail.com> 5 6 What is NVMe 7 ============ 8 9 NVM Express (NVMe) is a register level interface that allows host software to 10 communicate with a non-volatile memory subsystem. This interface is optimized 11 for enterprise and client solid state drives, typically attached to the PCI 12 express interface. It is a scalable host controller interface designed to 13 address the needs of enterprise and client systems that utilize PCI express 14 based solid state drives (SSD). The interface provides optimized command 15 submission and completion paths. It includes support for parallel operation by 16 supporting up to 64K I/O queues with up to 64K commands per I/O queue. 17 18 The device is comprised of some number of controllers, where each controller 19 is comprised of some number of namespaces, where each namespace is comprised 20 of some number of logical blocks. A namespace is a quantity of non-volatile 21 memory that is formatted into logical blocks. An NVMe namespace is equivalent 22 to a SCSI LUN. Each namespace is operated as an independent "device". 23 24 How it works 25 ------------ 26 There is an NVMe uclass driver (driver name "nvme"), an NVMe host controller 27 driver (driver name "nvme") and an NVMe namespace block driver (driver name 28 "nvme-blk"). The host controller driver is supposed to probe the hardware and 29 do necessary initialization to put the controller into a ready state at which 30 it is able to scan all available namespaces attached to it. Scanning namespace 31 is triggered by the NVMe uclass driver and the actual work is done in the NVMe 32 namespace block driver. 33 34 Status 35 ------ 36 It only support basic block read/write functions in the NVMe driver. 37 38 Config options 39 -------------- 40 CONFIG_NVME Enable NVMe device support 41 CONFIG_CMD_NVME Enable basic NVMe commands 42 43 Usage in U-Boot 44 --------------- 45 To use an NVMe hard disk from U-Boot shell, a 'nvme scan' command needs to 46 be executed for all NVMe hard disks attached to the NVMe controller to be 47 identified. 48 49 To list all of the NVMe hard disks, try: 50 51 => nvme info 52 Device 0: Vendor: 0x8086 Rev: 8DV10131 Prod: CVFT535600LS400BGN 53 Type: Hard Disk 54 Capacity: 381554.0 MB = 372.6 GB (781422768 x 512) 55 56 and print out detailed information for controller and namespaces via: 57 58 => nvme detail 59 60 Raw block read/write to can be done via the 'nvme read/write' commands: 61 62 => nvme read a0000000 0 11000 63 64 => tftp 80000000 /tftpboot/kernel.itb 65 => nvme write 80000000 0 11000 66 67 Of course, file system command can be used on the NVMe hard disk as well: 68 69 => fatls nvme 0:1 70 32376967 kernel.itb 71 22929408 100m 72 73 2 file(s), 0 dir(s) 74 75 => fatload nvme 0:1 a0000000 /kernel.itb 76 => bootm a0000000 77 78 Testing NVMe with QEMU x86 79 -------------------------- 80 QEMU supports NVMe emulation and we can test NVMe driver with QEMU x86 running 81 U-Boot. Please see README.x86 for how to build u-boot.rom image for QEMU x86. 82 83 Example command line to call QEMU x86 below with emulated NVMe device: 84 $ ./qemu-system-i386 -drive file=nvme.img,if=none,id=drv0 -device nvme,drive=drv0,serial=QEMUNVME0001 -bios u-boot.rom 85
README.odroid
1 U-Boot for Odroid X2/U3/XU3/XU4 2 ======================== 3 4 1. Summary 5 ========== 6 This is a quick instruction for setup Odroid boards. 7 Board config: odroid_config for X2/U3 8 Board config: odroid-xu3_config for XU3/XU4 9 10 2. Supported devices 11 ==================== 12 This U-BOOT config can be used on three boards: 13 - Odroid U3 14 - Odroid X2 15 with CPU Exynos 4412 rev 2.0 and 2GB of RAM 16 - Odroid XU3 17 - Odroid XU4 18 with CPU Exynos5422 and 2GB of RAM 19 20 3. Boot sequence 21 ================ 22 iROM->BL1->(BL2 + TrustZone)->U-BOOT 23 24 This version of U-BOOT doesn't implement SPL. So, BL1, BL2, and TrustZone 25 binaries are needed to boot up. 26 27 << X2/U3 >> 28 It can be found in "boot.tar.gz" from here: 29 http://dev.odroid.com/projects/4412boot/wiki/FrontPage?action=download&value=boot.tar.gz 30 or here: 31 http://odroid.in/guides/ubuntu-lfs/boot.tar.gz 32 33 << XU3/XU4 >> 34 It can be downloaded from: 35 https://github.com/hardkernel/u-boot/tree/odroidxu3-v2012.07/sd_fuse/hardkernel_1mb_uboot 36 37 38 4. Boot media layout 39 ==================== 40 The table below shows SD/eMMC cards layout for U-Boot. 41 The block offset is starting from 0 and the block size is 512B. 42 ------------------------------------- 43 | Binary | Block offset| part type | 44 | name | SD | eMMC |(eMMC only)| 45 ------------------------------------- 46 | Bl1 | 1 | 0 | 1 (boot) | 47 | Bl2 | 31 | 30 | 1 (boot) | 48 | U-Boot | 63 | 62 | 1 (boot) | 49 | Tzsw | 2111 | 2110 | 1 (boot) | 50 | Uboot Env | 2560 | 2560 | 0 (user) | 51 ------------------------------------- 52 53 5. Prepare the SD boot card - with SD card reader 54 ================================================= 55 To prepare bootable media you need boot binaries provided by hardkernel. 56 From the downloaded files, You can find: 57 - bl1.bin 58 - tzsw.bin 59 - bl2.bin 60 - sd_fusing.sh 61 - u-boot.bin 62 (The file names can be slightly different, but you can distinguish what they are 63 without problem) 64 65 This is all you need to boot this board. But if you want to use your custom 66 U-Boot then you need to change u-boot.bin with your own U-Boot binary* 67 and run the script "sd_fusing.sh" - this script is valid only for SD card. 68 69 *note: 70 The proper binary file of current U-Boot is u-boot-dtb.bin. 71 72 quick steps for Linux: 73 - Download all files from the link at point 3 and extract it if needed. 74 - put any SD card into the SD reader 75 - check the device with "dmesg" 76 - run ./sd_fusing.sh /dev/sdX - where X is SD card device (but not a partition) 77 Check if Hardkernel U-Boot is booting, and next do the same with your U-Boot. 78 79 6. Prepare the eMMC boot card 80 with a eMMC card reader (boot from eMMC card slot) 81 ===================================================== 82 To boot the device from the eMMC slot you should use a special card reader 83 which supports eMMC partition switch. All of the boot binaries are stored 84 on the eMMC boot partition which is normally hidden. 85 86 The "sd_fusing.sh" script can be used after updating offsets of binaries 87 according to the table from point 4. Be sure that you are working on the right 88 eMMC partition - its size is usually very small, about 1-4 MiB. 89 90 7. Prepare the eMMC boot card 91 with a SD card reader (boot from SD card slot) 92 ================================================= 93 If you have an eMMC->microSD adapter you can prepare the card as in point 5. 94 But then the device can boot only from the SD card slot. 95 96 8. Prepare the boot media using Hardkernel U-Boot 97 ================================================= 98 You can update the U-Boot to the custom one if you have a working bootloader 99 delivered with the board on the eMMC/SD card. Then follow the steps: 100 - install the android fastboot tool 101 - connect a micro usb cable to the board 102 - on the U-Boot prompt, run command: fastboot (as a root) 103 - on the host, run command: "fastboot flash bootloader u-boot-dtb.bin" 104 - the custom U-Boot should start after the board resets. 105 106 9. Partition layout 107 ==================== 108 Default U-Boot environment is setup for fixed partition layout. 109 110 Partition table: MSDOS. Disk layout and files as listed in the table below. 111 ----- ------ ------ ------ -------- --------------------------------- 112 | Num | Name | FS | Size | Offset | Reguired files | 113 | | | Type | MiB | MiB | | 114 ----- ------ ------ ------ -------- --------------------------------- 115 | 1 | BOOT | fat | 100 | 2 | kernel, fdt** | 116 | 2 | ROOT | ext4 | - | | any Linux system | 117 ----- ------ ------ ------ -------- --------------------------------- 118 119 **note: 120 Supported fdt files are: 121 - exynos4412-odroidx2.dtb 122 - exynos4412-odroidu3.dtb 123 - exynos5422-odroidxu3.dtb 124 - exynos5422-odroidxu4.dtb 125 126 Supported kernel files are: 127 - Image.itb 128 - zImage 129 - uImage 130 131 The default environmental variable "dfu_alt_info" is set* for above layout. 132 Each partition size is just an example, dfu_alt_info tries init two partitions. 133 The size of each is not important. 134 135 *note: 136 $dfu_alt_info is set on a boot time and it is concatenated using two variables: 137 - $dfu_alt_boot(set dynamically) 138 - $dfu_alt_system(from current env). 139 140 To add any changes to dfu_alt_info - please modify $dfu_alt_system only. 141 Changes are visible after board reset. 142 143 10. The environment and booting the kernel 144 ========================================== 145 There are three macros defined in config for various boot options: 146 Two for both, kernel with device tree support and also without it: 147 - boot_uimg - load uImage 148 - boot_zimg - load zImage 149 If proper fdt file exists then it will be automatically loaded, 150 so for old kernel types, please remove fdt file from boot partition. 151 152 The third boot option for multi image support (more info: doc/uImage.FIT/) 153 - boot_fit - for binary file: "Image.itb" 154 155 Default boot command: "autoboot" 156 And the boot sequence is: 157 - boot_fit - if "Image.itb" exists 158 - boot_zimg - if "zImage" exists 159 - boot_uimg - if "uImage" exists 160 161 11. USB host support 162 ==================== 163 NOTE: This section is only for Odroid X2/U3. 164 165 The ethernet can be accessed after starting the USB subsystem in U-Boot. 166 The adapter does not come with a preconfigured MAC address, and hence it needs 167 to be set before starting USB. 168 setenv usbethaddr 02:DE:AD:BE:EF:FF 169 170 Note that in this example a locally managed MAC address is chosen. Care should 171 be taken to make these MAC addresses unique within the same subnet. 172 173 Start the USB subsystem: 174 Odroid # setenv usbethaddr 02:DE:AD:BE:EF:FF 175 Odroid # usb start 176 (Re)start USB... 177 USB0: USB EHCI 1.00 178 scanning bus 0 for devices... 4 USB Device(s) found 179 scanning usb for storage devices... 1 Storage Device(s) found 180 scanning usb for ethernet devices... 1 Ethernet Device(s) found 181 Odroid # 182 183 Automatic IP assignment: 184 ------------------------ 185 If the ethernet is connected to a DHCP server (router maybe with DHCP enabled), 186 then the below will automatically assign an ip address through DHCP. 187 setenv autoload no 188 dhcp 189 190 Odroid # setenv autoload no 191 Odroid # dhcp 192 Waiting for Ethernet connection... done. 193 BOOTP broadcast 1 194 DHCP client bound to address 192.168.1.10 (524 ms) 195 Odroid # 196 197 Note that this automatically sets the many IP address related variables in 198 U-Boot that is obtained from the DHCP server. 199 200 Odroid # printenv ipaddr netmask gatewayip dnsip 201 ipaddr=192.168.1.10 202 netmask=255.255.255.0 203 gatewayip=192.168.1.1 204 dnsip=192.168.1.1 205 206 Ping example: 207 The ping command can be used a test to check connectivity. In this example, 208 192.168.1.27 is a pingable server in the network. 209 Odroid # ping 192.168.1.27 210 Waiting for Ethernet connection... done. 211 Using sms0 device 212 host 192.168.1.27 is alive 213 Odroid # 214 215 Static IP assignment: 216 --------------------- 217 In the case where there are no DHCP servers in the network, or you want to 218 set the IP address statically, it can be done by: 219 Odroid # setenv ipaddr 192.168.1.10 220 Odroid # ping 192.168.1.27 221 Waiting for Ethernet connection... done. 222 Using sms0 device 223 host 192.168.1.27 is alive 224 225 TFTP booting: 226 ------------- 227 Say there exists a tftp server in the network with address 192.168.1.27 and 228 it serves a kernel image (zImage.3.17) and a DTB blob (exynos4412-odroidu3.dtb) 229 that needs to be loaded and booted. It can be accomplished as below: 230 (Assumes that you have setenv usbethaddr, and have not set autoload to no) 231 232 Odroid # setenv serverip 192.168.1.27 233 Odroid # tftpboot 0x40080000 zImage.3.17 234 Waiting for Ethernet connection... done. 235 Using sms0 device 236 TFTP from server 192.168.1.27; our IP address is 192.168.1.10 237 Filename 'zImage.3.17'. 238 Load address: 0x40080000 239 Loading: ################################################################# 240 ################################################################# 241 ################################################################# 242 ####################### 243 52.7 KiB/s 244 done 245 Bytes transferred = 3194200 (30bd58 hex) 246 Odroid # tftpboot 0x42000000 exynos4412-odroidu3.dtb 247 Waiting for Ethernet connection... done. 248 Using sms0 device 249 TFTP from server 192.168.1.27; our IP address is 192.168.1.10 250 Filename 'exynos4412-odroidu3.dtb'. 251 Load address: 0x42000000 252 Loading: #### 253 40 KiB/s 254 done 255 Bytes transferred = 46935 (b757 hex) 256 Odroid # printenv bootargs 257 bootargs=Please use defined boot 258 Odroid # setenv bootargs console=ttySAC1,115200n8 root=/dev/mmcblk0p2 rootwait 259 Odroid # bootz 40080000 - 42000000 260 Kernel image @ 0x40080000 [ 0x000000 - 0x30bd58 ] 261 ## Flattened Device Tree blob at 42000000 262 Booting using the fdt blob at 0x42000000 263 Loading Device Tree to 4fff1000, end 4ffff756 ... OK 264 265 Starting kernel ... 266 267 [ 0.000000] Booting Linux on physical CPU 0xa00 268 ... etc ... 269 270 In the above example you can substitute 'dhcp' for 'tftpboot' as well. 271 272 USB Storage booting: 273 -------------------- 274 Similarly we can use the USB storage to load the kernel image/initrd/fdt etc 275 and boot. For this example, there is a USB drive plugged in. It has a FAT 276 1st partition and an EXT 2nd partition. Using the generic FS (ls/load) makes 277 it even easier to work with FAT/EXT file systems. 278 For this example the second EXT partition is used for booting and as rootfs. 279 The boot files - kernel and the dtb are present in the /boot directory of the 280 second partition. 281 282 Odroid # usb start 283 (Re)start USB... 284 USB0: USB EHCI 1.00 285 scanning bus 0 for devices... 4 USB Device(s) found 286 scanning usb for storage devices... 1 Storage Device(s) found 287 scanning usb for ethernet devices... 288 Error: sms0 address not set. <----- Note the error as usbethaddr 289 Warning: failed to set MAC address <----- is not set. 290 1 Ethernet Device(s) found 291 Odroid # usb part 0 292 293 Partition Map for USB device 0 -- Partition Type: DOS 294 295 Part Start Sector Num Sectors UUID Type 296 1 3072 263168 000c4046-01 06 297 2 266240 13457408 000c4046-02 83 298 299 Odroid # ls usb 0:2 /boot 300 <DIR> 4096 . 301 <DIR> 4096 .. 302 353 boot.scr 303 281 boot.txt 304 101420 config-3.8.13.23 305 2127254 initrd.img-3.8.13.23 306 2194825 uInitrd 307 2194825 uInitrd-3.8.13.23 308 2453112 zImage 309 101448 config-3.8.13.26 310 2127670 uInitrd-3.8.13.26 311 2127606 initrd.img-3.8.13.26 312 3194200 zImage.3.17 <--- Kernel 313 46935 exynos4412-odroidu3.dtb <--- DTB 314 Odroid # load usb 0:2 40080000 /boot/zImage.3.17 315 3194200 bytes read in 471 ms (6.5 MiB/s) 316 Odroid # load usb 0:2 42000000 /boot/exynos4412-odroidu3.dtb 317 46935 bytes read in 233 ms (196.3 KiB/s) 318 Odroid # setenv bootargs console=ttySAC1,115200n8 root=/dev/sda2 rootwait 319 Odroid # bootz 40080000 - 42000000 320 Kernel image @ 0x40080000 [ 0x000000 - 0x30bd58 ] 321 ## Flattened Device Tree blob at 42000000 322 Booting using the fdt blob at 0x42000000 323 Loading Device Tree to 4fff1000, end 4ffff756 ... OK 324 325 Starting kernel ... 326 327 [ 0.000000] Booting Linux on physical CPU 0xa00 328 329 Please refer to README.usb for additional information. 330
README.OFT
1 Open Firmware Flat Tree and usage. 2 ---------------------------------- 3 4 As part of the ongoing cleanup of the Linux PPC trees, the preferred 5 way to pass bootloader and board setup information is the open 6 firmware flat tree. 7 8 Please take a look at the following email discussion for some 9 background. 10 11 http://ozlabs.org/pipermail/linuxppc-dev/2005-August/019408.html 12 http://ozlabs.org/pipermail/linuxppc-dev/2005-August/019362.html 13 14 The generated tree is part static and part dynamic. 15 16 There is a static part which is compiled in with DTC and a dynamic 17 part which is programmatically appended. 18 19 You'll need a fairly recent DTC tool, which is available by git at 20 21 rsync://ozlabs.org/dtc/dtc.git 22 23 The xxd binary dumper is needed too which I got from 24 25 ftp://ftp.uni-erlangen.de/pub/utilities/etc/xxd-1.10.tar.gz 26 27 28 Pantelis Antoniou, 13 Oct 2005 29
README.omap-ulpi-viewport
1 Reference code ""drivers/usb/ulpi/omap-ulpi-viewport.c" 2 3 Contains the ulpi read write api's to perform 4 any ulpi phy port access on omap platform. 5 6 On omap ehci reg map contains INSNREG05_ULPI 7 register which offers the ulpi phy access so 8 any ulpi phy commands should be passsed using this 9 register. 10 11 omap-ulpi-viewport.c is a low level function 12 implementation of "drivers/usb/ulpi/ulpi.c" 13 14 To enable and use omap-ulpi-viewport.c 15 we require CONFIG_USB_ULPI_VIEWPORT_OMAP and 16 CONFIG_USB_ULPI be enabled in config file. 17 18 Any ulpi ops request can be done with ulpi.c 19 and soc specific binding and usage is done with 20 omap-ulpi-viewport implementation. 21 22 Ex: scenario: 23 omap-ehci driver code requests for ulpi phy reset if 24 ehci is used in phy mode, which will call ulpi phy reset 25 the ulpi phy reset does ulpi_read/write from viewport 26 implementation which will do ulpi reset using the 27 INSNREG05_ULPI register. 28
README.omap3
1 2 Summary 3 ======= 4 5 This README is about U-Boot support for TI's ARM Cortex-A8 based OMAP3 [1] 6 family of SoCs. TI's OMAP3 SoC family contains an ARM Cortex-A8. Additionally, 7 some family members contain a TMS320C64x+ DSP and/or an Imagination SGX 2D/3D 8 graphics processor and various other standard peripherals. 9 10 Currently the following boards are supported: 11 12 * OMAP3530 BeagleBoard [2] 13 14 * Gumstix Overo [3] 15 16 * TI EVM [4] 17 18 * OpenPandora Ltd. Pandora [5] 19 20 * TI/Logic PD Zoom MDK [6] 21 22 * TI/Logic PD Zoom 2 [7] 23 24 * CompuLab Ltd. CM-T35 [8] 25 26 Toolchain 27 ========= 28 29 While ARM Cortex-A8 support ARM v7 instruction set (-march=armv7a) we compile 30 with -march=armv5 to allow more compilers to work. For U-Boot code this has 31 no performance impact. 32 33 Build 34 ===== 35 36 * BeagleBoard: 37 38 make omap3_beagle_config 39 make 40 41 * Gumstix Overo: 42 43 make omap3_overo_config 44 make 45 46 * TI EVM: 47 48 make omap3_evm_config 49 make 50 51 * Pandora: 52 53 make omap3_pandora_config 54 make 55 56 * Zoom MDK: 57 58 make omap3_zoom1_config 59 make 60 61 * Zoom 2: 62 63 make omap3_zoom2_config 64 make 65 66 * CM-T35: 67 68 make cm_t35_config 69 make 70 71 72 Custom commands 73 =============== 74 75 To make U-Boot for OMAP3 support NAND device SW or HW ECC calculation, U-Boot 76 for OMAP3 supports custom user command 77 78 nandecc hw/sw 79 80 To be compatible with NAND drivers using SW ECC (e.g. kernel code) 81 82 nandecc sw 83 84 enables SW ECC calculation. HW ECC enabled with 85 86 nandecc hw 87 88 is typically used to write 2nd stage bootloader (known as 'x-loader') which is 89 executed by OMAP3's boot rom and therefore has to be written with HW ECC. 90 91 For all other commands see 92 93 help 94 95 Interfaces 96 ========== 97 98 gpio 99 ---- 100 101 To set a bit : 102 103 if (!gpio_request(N, "")) { 104 gpio_direction_output(N, 0); 105 gpio_set_value(N, 1); 106 } 107 108 To clear a bit : 109 110 if (!gpio_request(N, "")) { 111 gpio_direction_output(N, 0); 112 gpio_set_value(N, 0); 113 } 114 115 To read a bit : 116 117 if (!gpio_request(N, "")) { 118 gpio_direction_input(N); 119 val = gpio_get_value(N); 120 gpio_free(N); 121 } 122 if (val) 123 printf("GPIO N is set\n"); 124 else 125 printf("GPIO N is clear\n"); 126 127 dma 128 --- 129 void omap3_dma_init(void) 130 Init the DMA module 131 int omap3_dma_get_conf_chan(uint32_t chan, struct dma4_chan *config); 132 Read config of the channel 133 int omap3_dma_conf_chan(uint32_t chan, struct dma4_chan *config); 134 Write config to the channel 135 int omap3_dma_conf_transfer(uint32_t chan, uint32_t *src, uint32_t *dst, 136 uint32_t sze) 137 Config source, destination and size of a transfer 138 int omap3_dma_wait_for_transfer(uint32_t chan) 139 Wait for a transfer to end - this hast to be called before a channel 140 or the data the channel transferd are used. 141 int omap3_dma_get_revision(uint32_t *minor, uint32_t *major) 142 Read silicon Revision of the DMA module 143 144 NAND 145 ==== 146 147 There are some OMAP3 devices out there with NAND attached. Due to the fact that 148 OMAP3 ROM code can only handle 1-bit hamming ECC for accessing first page 149 (place where SPL lives) we require this setup for u-boot at least when reading 150 the second progam within SPL. A lot of newer NAND chips however require more 151 than 1-bit ECC for the pages, some can live with 1-bit for the first page. To 152 handle this we can switch to another ECC algorithm after reading the payload 153 within SPL. 154 155 BCH8 156 ---- 157 158 To enable hardware assisted BCH8 (8-bit BCH [Bose, Chaudhuri, Hocquenghem]) on 159 OMAP3 devices we can use the BCH library in lib/bch.c. To do so add CONFIG_BCH 160 and set CONFIG_NAND_OMAP_ECCSCHEME=5 (refer README.nand) for selecting BCH8_SW. 161 The NAND OOB layout is the same as in linux kernel, if the linux kernel BCH8 162 implementation for OMAP3 works for you so the u-boot version should also. 163 When you require the SPL to read with BCH8 there are two more configs to 164 change: 165 166 * CONFIG_SYS_NAND_ECCPOS (must be the same as .eccpos in 167 GPMC_NAND_HW_BCH8_ECC_LAYOUT defined in 168 arch/arm/include/asm/arch-omap3/omap_gpmc.h) 169 * CONFIG_SYS_NAND_ECCSIZE must be 512 170 * CONFIG_SYS_NAND_ECCBYTES must be 13 for this BCH8 setup 171 172 Acknowledgements 173 ================ 174 175 OMAP3 U-Boot is based on U-Boot tar ball [9] for BeagleBoard and EVM done by 176 several TI employees. 177 178 Links 179 ===== 180 181 [1] OMAP3: 182 183 http://www.ti.com/omap3 (high volume) and 184 http://www.ti.com/omap35x (broad market) 185 186 [2] OMAP3530 BeagleBoard: 187 188 http://beagleboard.org/ 189 190 [3] Gumstix Overo: 191 192 http://www.gumstix.net/Overo/ 193 194 [4] TI EVM: 195 196 http://focus.ti.com/docs/toolsw/folders/print/tmdxevm3503.html 197 198 [5] OpenPandora Ltd. Pandora: 199 200 http://openpandora.org/ 201 202 [6] TI/Logic PD Zoom MDK: 203 204 http://www.logicpd.com/products/devkit/ti/zoom_mobile_development_kit 205 206 [7] TI/Logic PD Zoom 2 207 208 http://www.logicpd.com/sites/default/files/1012659A_Zoom_OMAP34x-II_MDP_Brief.pdf 209 210 [8] CompuLab Ltd. CM-T35: 211 212 http://www.compulab.co.il/t3530/html/t3530-cm-datasheet.htm 213 214 [9] TI OMAP3 U-Boot: 215 216 http://beagleboard.googlecode.com/files/u-boot_beagle_revb.tar.gz 217
README.pblimage
1 ------------------------------------------------------------------ 2 Freescale PBL(pre-boot loader) Boot Image generation using mkimage 3 ------------------------------------------------------------------ 4 5 The CoreNet SoC's can boot directly from eSPI FLASH, SD/MMC and 6 NAND, etc. These SoCs use PBL to load RCW and/or pre-initialization 7 instructions. For more details refer section 5 Pre-boot loader 8 specifications of reference manual P3041RM/P4080RM/P5020RM at link: 9 http://www.freescale.com/webapp/search/Serp.jsp?Reference+Manuals 10 11 Building PBL Boot Image and boot steps 12 -------------------------------------- 13 14 1. Building PBL Boot Image. 15 The default Image is u-boot.pbl. 16 17 For eSPI boot(available on P2041/P3041/P4080/P5020/P5040/T4240): 18 To build the eSPI boot image: 19 make <board_name>_SPIFLASH 20 21 For SD boot(available on P2041/P3041/P4080/P5020/P5040/T4240): 22 To build the SD boot image: 23 make <board_name>_SDCARD 24 25 For Nand boot(available on P2041/P3041/P5020/P5040): 26 To build the NAND boot image: 27 make <board_name>_NAND 28 29 30 2. pblimage support available with mkimage utility will generate Freescale PBL 31 boot image that can be flashed on the board eSPI flash, SD/MMC and NAND. 32 Following steps describe it in detail. 33 34 1). Boot from eSPI flash 35 Write u-boot.pbl to eSPI flash from offset 0x0. 36 for ex in u-boot: 37 =>tftp 100000 u-boot.pbl 38 =>sf probe 0 39 =>sf erase 0 100000 40 =>sf write 100000 0 $filesize 41 Change SW1[1:5] = off off on off on. 42 43 2). Boot from SD/MMC 44 Write u-boot.pbl to SD/MMC from offset 0x1000. 45 for ex in u-boot: 46 =>tftp 100000 u-boot.pbl 47 =>mmcinfo 48 =>mmc write 100000 8 441 49 Change SW1[1:5] = off off on on off. 50 51 3). Boot from Nand 52 Write u-boot.pbl to Nand from offset 0x0. 53 for ex in u-boot: 54 =>tftp 100000 u-boot.pbl 55 =>nand info 56 =>nand erase 0 100000 57 =>nand write 100000 0 $filesize 58 Change SW1[1:5] = off on off off on 59 Change SW7[1:4] = on off off on 60 61 Board specific configuration file specifications: 62 ------------------------------------------------ 63 1. Configuration files rcw.cfg and pbi.cfg must present in the 64 board/freescale/corenet_ds/, rcw.cfg is for RCW, pbi.cfg is for 65 PBI instructions. File name must not be changed since they are used 66 in Makefile. 67 2. These files can have empty lines and lines starting with "#" as first 68 character to put comments 69 70 Typical example of rcw.cfg file: 71 ----------------------------------- 72 73 #PBL preamble and RCW header 74 aa55aa55 010e0100 75 #64 bytes RCW data 76 4c580000 00000000 18185218 0000cccc 77 40464000 3c3c2000 58000000 61000000 78 00000000 00000000 00000000 008b6000 79 00000000 00000000 00000000 00000000 80 81 Typical example of pbi.cfg file: 82 ----------------------------------- 83 84 #PBI commands 85 #Initialize CPC1 86 09010000 00200400 87 09138000 00000000 88 091380c0 00000100 89 09010100 00000000 90 09010104 fff0000b 91 09010f00 08000000 92 09010000 80000000 93 #Configure LAW for CPC1 94 09000d00 00000000 95 09000d04 fff00000 96 09000d08 81000013 97 09000010 00000000 98 09000014 ff000000 99 09000018 81000000 100 #Initialize eSPI controller 101 09110000 80000403 102 09110020 2d170008 103 09110024 00100008 104 09110028 00100008 105 0911002c 00100008 106 #Flush PBL data 107 09138000 00000000 108 091380c0 00000000 109 110 ------------------------------------------------ 111 Author: Shaohui Xie<Shaohui.Xie (a] freescale.com> 112
README.plan9
1 Plan 9 from Bell Labs kernel images require additional setup to pass 2 configuration information to the kernel. An environment variable named 3 confaddr must be defined with the same value as CONFADDR (see mem.h). 4 Use of this facility is optional, but should be preferable to manual 5 configuration. 6 7 When booting an image, arguments supplied to the bootm command will be 8 copied to CONFADDR. If no arguments are specified, the contents of the 9 bootargs environment variable will be copied. 10 11 If no command line arguments or bootargs are defined, CONFADDR is left 12 uninitialized to permit manual configuration. For example, PC-style 13 configuration could be simulated by issuing a fatload in bootcmd: 14 15 # setenv bootcmd fatload mmc 0 $confaddr plan9.ini; ...; bootm 16 17 Steven Stallion 18 June 2013 19
README.POST
1 Power-On-Self-Test support in U-Boot 2 ------------------------------------ 3 4 This project is to support Power-On-Self-Test (POST) in U-Boot. 5 6 1. High-level requirements 7 8 The key requirements for this project are as follows: 9 10 1) The project shall develop a flexible framework for implementing 11 and running Power-On-Self-Test in U-Boot. This framework shall 12 possess the following features: 13 14 o) Extensibility 15 16 The framework shall allow adding/removing/replacing POST tests. 17 Also, standalone POST tests shall be supported. 18 19 o) Configurability 20 21 The framework shall allow run-time configuration of the lists 22 of tests running on normal/power-fail booting. 23 24 o) Controllability 25 26 The framework shall support manual running of the POST tests. 27 28 2) The results of tests shall be saved so that it will be possible to 29 retrieve them from Linux. 30 31 3) The following POST tests shall be developed for MPC823E-based 32 boards: 33 34 o) CPU test 35 o) Cache test 36 o) Memory test 37 o) Ethernet test 38 o) Serial channels test 39 o) Watchdog timer test 40 o) RTC test 41 o) I2C test 42 o) SPI test 43 o) USB test 44 45 4) The LWMON board shall be used for reference. 46 47 2. Design 48 49 This section details the key points of the design for the project. 50 The whole project can be divided into two independent tasks: 51 enhancing U-Boot/Linux to provide a common framework for running POST 52 tests and developing such tests for particular hardware. 53 54 2.1. Hardware-independent POST layer 55 56 A new optional module will be added to U-Boot, which will run POST 57 tests and collect their results at boot time. Also, U-Boot will 58 support running POST tests manually at any time by executing a 59 special command from the system console. 60 61 The list of available POST tests will be configured at U-Boot build 62 time. The POST layer will allow the developer to add any custom POST 63 tests. All POST tests will be divided into the following groups: 64 65 1) Tests running on power-on booting only 66 67 This group will contain those tests that run only once on 68 power-on reset (e.g. watchdog test) 69 70 2) Tests running on normal booting only 71 72 This group will contain those tests that do not take much 73 time and can be run on the regular basis (e.g. CPU test) 74 75 3) Tests running in special "slow test mode" only 76 77 This group will contain POST tests that consume much time 78 and cannot be run regularly (e.g. strong memory test, I2C test) 79 80 4) Manually executed tests 81 82 This group will contain those tests that can be run manually. 83 84 If necessary, some tests may belong to several groups simultaneously. 85 For example, SDRAM test may run in both normal and "slow test" mode. 86 In normal mode, SDRAM test may perform a fast superficial memory test 87 only, while running in slow test mode it may perform a full memory 88 check-up. 89 90 Also, all tests will be discriminated by the moment they run at. 91 Specifically, the following groups will be singled out: 92 93 1) Tests running before relocating to RAM 94 95 These tests will run immediately after initializing RAM 96 as to enable modifying it without taking care of its 97 contents. Basically, this group will contain memory tests 98 only. 99 100 2) Tests running after relocating to RAM 101 102 These tests will run immediately before entering the main 103 loop as to guarantee full hardware initialization. 104 105 The POST layer will also distinguish a special group of tests that 106 may cause system rebooting (e.g. watchdog test). For such tests, the 107 layer will automatically detect rebooting and will notify the test 108 about it. 109 110 2.1.1. POST layer interfaces 111 112 This section details the interfaces between the POST layer and the 113 rest of U-Boot. 114 115 The following flags will be defined: 116 117 #define POST_POWERON 0x01 /* test runs on power-on booting */ 118 #define POST_NORMAL 0x02 /* test runs on normal booting */ 119 #define POST_SLOWTEST 0x04 /* test is slow, enabled by key press */ 120 #define POST_POWERTEST 0x08 /* test runs after watchdog reset */ 121 #define POST_ROM 0x100 /* test runs in ROM */ 122 #define POST_RAM 0x200 /* test runs in RAM */ 123 #define POST_MANUAL 0x400 /* test can be executed manually */ 124 #define POST_REBOOT 0x800 /* test may cause rebooting */ 125 #define POST_PREREL 0x1000 /* test runs before relocation */ 126 127 The POST layer will export the following interface routines: 128 129 o) int post_run(bd_t *bd, char *name, int flags); 130 131 This routine will run the test (or the group of tests) specified 132 by the name and flag arguments. More specifically, if the name 133 argument is not NULL, the test with this name will be performed, 134 otherwise all tests running in ROM/RAM (depending on the flag 135 argument) will be executed. This routine will be called at least 136 twice with name set to NULL, once from board_init_f() and once 137 from board_init_r(). The flags argument will also specify the 138 mode the test is executed in (power-on, normal, power-fail, 139 manual). 140 141 o) void post_reloc(ulong offset); 142 143 This routine will be called from board_init_r() and will 144 relocate the POST test table. 145 146 o) int post_info(char *name); 147 148 This routine will print the list of all POST tests that can be 149 executed manually if name is NULL, and the description of a 150 particular test if name is not NULL. 151 152 o) int post_log(char *format, ...); 153 154 This routine will be called from POST tests to log their 155 results. Basically, this routine will print the results to 156 stderr. The format of the arguments and the return value 157 will be identical to the printf() routine. 158 159 Also, the following board-specific routines will be called from the 160 U-Boot common code: 161 162 o) int post_hotkeys_pressed(gd_t *gd) 163 164 This routine will scan the keyboard to detect if a magic key 165 combination has been pressed, or otherwise detect if the 166 power-on long-running tests shall be executed or not ("normal" 167 versus "slow" test mode). 168 169 The list of available POST tests be kept in the post_tests array 170 filled at U-Boot build time. The format of entry in this array will 171 be as follows: 172 173 struct post_test { 174 char *name; 175 char *cmd; 176 char *desc; 177 int flags; 178 int (*test)(bd_t *bd, int flags); 179 }; 180 181 o) name 182 183 This field will contain a short name of the test, which will be 184 used in logs and on listing POST tests (e.g. CPU test). 185 186 o) cmd 187 188 This field will keep a name for identifying the test on manual 189 testing (e.g. cpu). For more information, refer to section 190 "Command line interface". 191 192 o) desc 193 194 This field will contain a detailed description of the test, 195 which will be printed on user request. For more information, see 196 section "Command line interface". 197 198 o) flags 199 200 This field will contain a combination of the bit flags described 201 above, which will specify the mode the test is running in 202 (power-on, normal, power-fail or manual mode), the moment it 203 should be run at (before or after relocating to RAM), whether it 204 can cause system rebooting or not. 205 206 o) test 207 208 This field will contain a pointer to the routine that will 209 perform the test, which will take 2 arguments. The first 210 argument will be a pointer to the board info structure, while 211 the second will be a combination of bit flags specifying the 212 mode the test is running in (POST_POWERON, POST_NORMAL, 213 POST_SLOWTEST, POST_MANUAL) and whether the last execution of 214 the test caused system rebooting (POST_REBOOT). The routine will 215 return 0 on successful execution of the test, and 1 if the test 216 failed. 217 218 The lists of the POST tests that should be run at power-on/normal/ 219 power-fail booting will be kept in the environment. Namely, the 220 following environment variables will be used: post_poweron, 221 powet_normal, post_slowtest. 222 223 2.1.2. Test results 224 225 The results of tests will be collected by the POST layer. The POST 226 log will have the following format: 227 228 ... 229 -------------------------------------------- 230 START <name> 231 <test-specific output> 232 [PASSED|FAILED] 233 -------------------------------------------- 234 ... 235 236 Basically, the results of tests will be printed to stderr. This 237 feature may be enhanced in future to spool the log to a serial line, 238 save it in non-volatile RAM (NVRAM), transfer it to a dedicated 239 storage server and etc. 240 241 2.1.3. Integration issues 242 243 All POST-related code will be #ifdef'ed with the CONFIG_POST macro. 244 This macro will be defined in the config_<board>.h file for those 245 boards that need POST. The CONFIG_POST macro will contain the list of 246 POST tests for the board. The macro will have the format of array 247 composed of post_test structures: 248 249 #define CONFIG_POST \ 250 { 251 "On-board peripherals test", "board", \ 252 " This test performs full check-up of the " \ 253 "on-board hardware.", \ 254 POST_RAM | POST_SLOWTEST, \ 255 &board_post_test \ 256 } 257 258 A new file, post.h, will be created in the include/ directory. This 259 file will contain common POST declarations and will define a set of 260 macros that will be reused for defining CONFIG_POST. As an example, 261 the following macro may be defined: 262 263 #define POST_CACHE \ 264 { 265 "Cache test", "cache", \ 266 " This test verifies the CPU cache operation.", \ 267 POST_RAM | POST_NORMAL, \ 268 &cache_post_test \ 269 } 270 271 A new subdirectory will be created in the U-Boot root directory. It 272 will contain the source code of the POST layer and most of POST 273 tests. Each POST test in this directory will be placed into a 274 separate file (it will be needed for building standalone tests). Some 275 POST tests (mainly those for testing peripheral devices) will be 276 located in the source files of the drivers for those devices. This 277 way will be used only if the test subtantially uses the driver. 278 279 2.1.4. Standalone tests 280 281 The POST framework will allow to develop and run standalone tests. A 282 user-space library will be developed to provide the POST interface 283 functions to standalone tests. 284 285 2.1.5. Command line interface 286 287 A new command, diag, will be added to U-Boot. This command will be 288 used for listing all available hardware tests, getting detailed 289 descriptions of them and running these tests. 290 291 More specifically, being run without any arguments, this command will 292 print the list of all available hardware tests: 293 294 => diag 295 Available hardware tests: 296 cache - cache test 297 cpu - CPU test 298 enet - SCC/FCC ethernet test 299 Use 'diag [<test1> [<test2>]] ... ' to get more info. 300 Use 'diag run [<test1> [<test2>]] ... ' to run tests. 301 => 302 303 If the first argument to the diag command is not 'run', detailed 304 descriptions of the specified tests will be printed: 305 306 => diag cpu cache 307 cpu - CPU test 308 This test verifies the arithmetic logic unit of CPU. 309 cache - cache test 310 This test verifies the CPU cache operation. 311 => 312 313 If the first argument to diag is 'run', the specified tests will be 314 executed. If no tests are specified, all available tests will be 315 executed. 316 317 It will be prohibited to execute tests running in ROM manually. The 318 'diag' command will not display such tests and/or run them. 319 320 2.1.6. Power failure handling 321 322 The Linux kernel will be modified to detect power failures and 323 automatically reboot the system in such cases. It will be assumed 324 that the power failure causes a system interrupt. 325 326 To perform correct system shutdown, the kernel will register a 327 handler of the power-fail IRQ on booting. Being called, the handler 328 will run /sbin/reboot using the call_usermodehelper() routine. 329 /sbin/reboot will automatically bring the system down in a secure 330 way. This feature will be configured in/out from the kernel 331 configuration file. 332 333 The POST layer of U-Boot will check whether the system runs in 334 power-fail mode. If it does, the system will be powered off after 335 executing all hardware tests. 336 337 2.1.7. Hazardous tests 338 339 Some tests may cause system rebooting during their execution. For 340 some tests, this will indicate a failure, while for the Watchdog 341 test, this means successful operation of the timer. 342 343 In order to support such tests, the following scheme will be 344 implemented. All the tests that may cause system rebooting will have 345 the POST_REBOOT bit flag set in the flag field of the correspondent 346 post_test structure. Before starting tests marked with this bit flag, 347 the POST layer will store an identification number of the test in a 348 location in IMMR. On booting, the POST layer will check the value of 349 this variable and if it is set will skip over the tests preceding the 350 failed one. On second execution of the failed test, the POST_REBOOT 351 bit flag will be set in the flag argument to the test routine. This 352 will allow to detect system rebooting on the previous iteration. For 353 example, the watchdog timer test may have the following 354 declaration/body: 355 356 ... 357 #define POST_WATCHDOG \ 358 { 359 "Watchdog timer test", "watchdog", \ 360 " This test checks the watchdog timer.", \ 361 POST_RAM | POST_POWERON | POST_REBOOT, \ 362 &watchdog_post_test \ 363 } 364 ... 365 366 ... 367 int watchdog_post_test(bd_t *bd, int flags) 368 { 369 unsigned long start_time; 370 371 if (flags & POST_REBOOT) { 372 /* Test passed */ 373 return 0; 374 } else { 375 /* disable interrupts */ 376 disable_interrupts(); 377 /* 10-second delay */ 378 ... 379 /* if we've reached this, the watchdog timer does not work */ 380 enable_interrupts(); 381 return 1; 382 } 383 } 384 ... 385 386 2.2. Hardware-specific details 387 388 This project will also develop a set of POST tests for MPC8xx- based 389 systems. This section provides technical details of how it will be 390 done. 391 392 2.2.1. Generic PPC tests 393 394 The following generic POST tests will be developed: 395 396 o) CPU test 397 398 This test will check the arithmetic logic unit (ALU) of CPU. The 399 test will take several milliseconds and will run on normal 400 booting. 401 402 o) Cache test 403 404 This test will verify the CPU cache (L1 cache). The test will 405 run on normal booting. 406 407 o) Memory test 408 409 This test will examine RAM and check it for errors. The test 410 will always run on booting. On normal booting, only a limited 411 amount of RAM will be checked. On power-fail booting a fool 412 memory check-up will be performed. 413 414 2.2.1.1. CPU test 415 416 This test will verify the following ALU instructions: 417 418 o) Condition register istructions 419 420 This group will contain: mtcrf, mfcr, mcrxr, crand, crandc, 421 cror, crorc, crxor, crnand, crnor, creqv, mcrf. 422 423 The mtcrf/mfcr instructions will be tested by loading different 424 values into the condition register (mtcrf), moving its value to 425 a general-purpose register (mfcr) and comparing this value with 426 the expected one. The mcrxr instruction will be tested by 427 loading a fixed value into the XER register (mtspr), moving XER 428 value to the condition register (mcrxr), moving it to a 429 general-purpose register (mfcr) and comparing the value of this 430 register with the expected one. The rest of instructions will be 431 tested by loading a fixed value into the condition register 432 (mtcrf), executing each instruction several times to modify all 433 4-bit condition fields, moving the value of the conditional 434 register to a general-purpose register (mfcr) and comparing it 435 with the expected one. 436 437 o) Integer compare instructions 438 439 This group will contain: cmp, cmpi, cmpl, cmpli. 440 441 To verify these instructions the test will run them with 442 different combinations of operands, read the condition register 443 value and compare it with the expected one. More specifically, 444 the test will contain a pre-built table containing the 445 description of each test case: the instruction, the values of 446 the operands, the condition field to save the result in and the 447 expected result. 448 449 o) Arithmetic instructions 450 451 This group will contain: add, addc, adde, addme, addze, subf, 452 subfc, subfe, subme, subze, mullw, mulhw, mulhwu, divw, divwu, 453 extsb, extsh. 454 455 The test will contain a pre-built table of instructions, 456 operands, expected results and expected states of the condition 457 register. For each table entry, the test will cyclically use 458 different sets of operand registers and result registers. For 459 example, for instructions that use 3 registers on the first 460 iteration r0/r1 will be used as operands and r2 for result. On 461 the second iteration, r1/r2 will be used as operands and r3 as 462 for result and so on. This will enable to verify all 463 general-purpose registers. 464 465 o) Logic instructions 466 467 This group will contain: and, andc, andi, andis, or, orc, ori, 468 oris, xor, xori, xoris, nand, nor, neg, eqv, cntlzw. 469 470 The test scheme will be identical to that from the previous 471 point. 472 473 o) Shift instructions 474 475 This group will contain: slw, srw, sraw, srawi, rlwinm, rlwnm, 476 rlwimi 477 478 The test scheme will be identical to that from the previous 479 point. 480 481 o) Branch instructions 482 483 This group will contain: b, bl, bc. 484 485 The first 2 instructions (b, bl) will be verified by jumping to 486 a fixed address and checking whether control was transferred to 487 that very point. For the bl instruction the value of the link 488 register will be checked as well (using mfspr). To verify the bc 489 instruction various combinations of the BI/BO fields, the CTR 490 and the condition register values will be checked. The list of 491 such combinations will be pre-built and linked in U-Boot at 492 build time. 493 494 o) Load/store instructions 495 496 This group will contain: lbz(x)(u), lhz(x)(u), lha(x)(u), 497 lwz(x)(u), stb(x)(u), sth(x)(u), stw(x)(u). 498 499 All operations will be performed on a 16-byte array. The array 500 will be 4-byte aligned. The base register will point to offset 501 8. The immediate offset (index register) will range in [-8 ... 502 +7]. The test cases will be composed so that they will not cause 503 alignment exceptions. The test will contain a pre-built table 504 describing all test cases. For store instructions, the table 505 entry will contain: the instruction opcode, the value of the 506 index register and the value of the source register. After 507 executing the instruction, the test will verify the contents of 508 the array and the value of the base register (it must change for 509 "store with update" instructions). For load instructions, the 510 table entry will contain: the instruction opcode, the array 511 contents, the value of the index register and the expected value 512 of the destination register. After executing the instruction, 513 the test will verify the value of the destination register and 514 the value of the base register (it must change for "load with 515 update" instructions). 516 517 o) Load/store multiple/string instructions 518 519 520 The CPU test will run in RAM in order to allow run-time modification 521 of the code to reduce the memory footprint. 522 523 2.2.1.2 Special-Purpose Registers Tests 524 525 TBD. 526 527 2.2.1.3. Cache test 528 529 To verify the data cache operation the following test scenarios will 530 be used: 531 532 1) Basic test #1 533 534 - turn on the data cache 535 - switch the data cache to write-back or write-through mode 536 - invalidate the data cache 537 - write the negative pattern to a cached area 538 - read the area 539 540 The negative pattern must be read at the last step 541 542 2) Basic test #2 543 544 - turn on the data cache 545 - switch the data cache to write-back or write-through mode 546 - invalidate the data cache 547 - write the zero pattern to a cached area 548 - turn off the data cache 549 - write the negative pattern to the area 550 - turn on the data cache 551 - read the area 552 553 The negative pattern must be read at the last step 554 555 3) Write-through mode test 556 557 - turn on the data cache 558 - switch the data cache to write-through mode 559 - invalidate the data cache 560 - write the zero pattern to a cached area 561 - flush the data cache 562 - write the negative pattern to the area 563 - turn off the data cache 564 - read the area 565 566 The negative pattern must be read at the last step 567 568 4) Write-back mode test 569 570 - turn on the data cache 571 - switch the data cache to write-back mode 572 - invalidate the data cache 573 - write the negative pattern to a cached area 574 - flush the data cache 575 - write the zero pattern to the area 576 - invalidate the data cache 577 - read the area 578 579 The negative pattern must be read at the last step 580 581 To verify the instruction cache operation the following test 582 scenarios will be used: 583 584 1) Basic test #1 585 586 - turn on the instruction cache 587 - unlock the entire instruction cache 588 - invalidate the instruction cache 589 - lock a branch instruction in the instruction cache 590 - replace the branch instruction with "nop" 591 - jump to the branch instruction 592 - check that the branch instruction was executed 593 594 2) Basic test #2 595 596 - turn on the instruction cache 597 - unlock the entire instruction cache 598 - invalidate the instruction cache 599 - jump to a branch instruction 600 - check that the branch instruction was executed 601 - replace the branch instruction with "nop" 602 - invalidate the instruction cache 603 - jump to the branch instruction 604 - check that the "nop" instruction was executed 605 606 The CPU test will run in RAM in order to allow run-time modification 607 of the code. 608 609 2.2.1.4. Memory test 610 611 The memory test will verify RAM using sequential writes and reads 612 to/from RAM. Specifically, there will be several test cases that will 613 use different patterns to verify RAM. Each test case will first fill 614 a region of RAM with one pattern and then read the region back and 615 compare its contents with the pattern. The following patterns will be 616 used: 617 618 1) zero pattern (0x00000000) 619 2) negative pattern (0xffffffff) 620 3) checkerboard pattern (0x55555555, 0xaaaaaaaa) 621 4) bit-flip pattern ((1 << (offset % 32)), ~(1 << (offset % 32))) 622 5) address pattern (offset, ~offset) 623 624 Patterns #1, #2 will help to find unstable bits. Patterns #3, #4 will 625 be used to detect adherent bits, i.e. bits whose state may randomly 626 change if adjacent bits are modified. The last pattern will be used 627 to detect far-located errors, i.e. situations when writing to one 628 location modifies an area located far from it. Also, usage of the 629 last pattern will help to detect memory controller misconfigurations 630 when RAM represents a cyclically repeated portion of a smaller size. 631 632 Being run in normal mode, the test will verify only small 4Kb regions 633 of RAM around each 1Mb boundary. For example, for 64Mb RAM the 634 following areas will be verified: 0x00000000-0x00000800, 635 0x000ff800-0x00100800, 0x001ff800-0x00200800, ..., 0x03fff800- 636 0x04000000. If the test is run in power-fail mode, it will verify the 637 whole RAM. 638 639 The memory test will run in ROM before relocating U-Boot to RAM in 640 order to allow RAM modification without saving its contents. 641 642 2.2.2. Common tests 643 644 This section describes tests that are not based on any hardware 645 peculiarities and use common U-Boot interfaces only. These tests do 646 not need any modifications for porting them to another board/CPU. 647 648 2.2.2.1. I2C test 649 650 For verifying the I2C bus, a full I2C bus scanning will be performed 651 using the i2c_probe() routine. If a board defines 652 CONFIG_SYS_POST_I2C_ADDRS the I2C test will pass if all devices 653 listed in CONFIG_SYS_POST_I2C_ADDRS are found, and no additional 654 devices are detected. If CONFIG_SYS_POST_I2C_ADDRS is not defined 655 the test will pass if any I2C device is found. 656 657 The CONFIG_SYS_POST_I2C_IGNORES define can be used to list I2C 658 devices which may or may not be present when using 659 CONFIG_SYS_POST_I2C_ADDRS. The I2C POST test will pass regardless 660 if the devices in CONFIG_SYS_POST_I2C_IGNORES are found or not. 661 This is useful in cases when I2C devices are optional (eg on a 662 daughtercard that may or may not be present) or not critical 663 to board operation. 664 665 2.2.2.2. Watchdog timer test 666 667 To test the watchdog timer the scheme mentioned above (refer to 668 section "Hazardous tests") will be used. Namely, this test will be 669 marked with the POST_REBOOT bit flag. On the first iteration, the 670 test routine will make a 10-second delay. If the system does not 671 reboot during this delay, the watchdog timer is not operational and 672 the test fails. If the system reboots, on the second iteration the 673 POST_REBOOT bit will be set in the flag argument to the test routine. 674 The test routine will check this bit and report a success if it is 675 set. 676 677 2.2.2.3. RTC test 678 679 The RTC test will use the rtc_get()/rtc_set() routines. The following 680 features will be verified: 681 682 o) Time uniformity 683 684 This will be verified by reading RTC in polling within a short 685 period of time (5-10 seconds). 686 687 o) Passing month boundaries 688 689 This will be checked by setting RTC to a second before a month 690 boundary and reading it after its passing the boundary. The test 691 will be performed for both leap- and nonleap-years. 692 693 2.2.3. MPC8xx peripherals tests 694 695 This project will develop a set of tests verifying the peripheral 696 units of MPC8xx processors. Namely, the following controllers of the 697 MPC8xx communication processor module (CPM) will be tested: 698 699 o) Serial Management Controllers (SMC) 700 701 o) Serial Communication Controllers (SCC) 702 703 2.2.3.1. Ethernet tests (SCC) 704 705 The internal (local) loopback mode will be used to test SCC. To do 706 that the controllers will be configured accordingly and several 707 packets will be transmitted. These tests may be enhanced in future to 708 use external loopback for testing. That will need appropriate 709 reconfiguration of the physical interface chip. 710 711 The test routines for the SCC ethernet tests will be located in 712 arch/powerpc/cpu/mpc8xx/scc.c. 713 714 2.2.3.2. UART tests (SMC/SCC) 715 716 To perform these tests the internal (local) loopback mode will be 717 used. The SMC/SCC controllers will be configured to connect the 718 transmitter output to the receiver input. After that, several bytes 719 will be transmitted. These tests may be enhanced to make to perform 720 "external" loopback test using a loopback cable. In this case, the 721 test will be executed manually. 722 723 The test routine for the SMC/SCC UART tests will be located in 724 arch/powerpc/cpu/mpc8xx/serial.c. 725 726 2.2.3.3. USB test 727 728 TBD 729 730 2.2.3.4. SPI test 731 732 TBD 733
README.power-framework
1 # 2 # (C) Copyright 2014 Samsung Electronics 3 # Lukasz Majewski <l.majewski (at] samsung.com> 4 # 5 # SPDX-License-Identifier: GPL-2.0+ 6 # 7 8 Introduction 9 ------------ 10 11 This document describes the second version of the u-boot's PMIC (Power 12 Management IC) framework. As a reference boards please consider Samsungs' Trats 13 and Trats2. 14 15 Background 16 ---------- 17 18 Boards supported by u-boot are getting increasingly complex. Developers and 19 designers strive to cut down power consumption. Hence several different types of 20 devices are now available on the board - namely power managers (PMIC), fuel 21 gauges (FG), micro USB interface controllers (MUIC), batteries, multi-function 22 devices (MFD). 23 24 Explanation of key design decisions 25 ----------------------------------- 26 27 One package can integrate PMIC and MUIC with different addresses on the I2C bus. 28 The same device - e.g. MAX8997 uses two different I2C busses and addresses. 29 30 Power devices use not only I2C for communication, but SPI as well. Additionally 31 different ICs use different endianess. For this reason struct pmic holds 32 information about I2C/SPI transmission, which is used with generic 33 pmic_req_write() function. 34 35 The "flat" hierarchy for power devices works well when each device performs only 36 one operation - e.g. PMIC enables LDO. 37 38 The problem emerges when we have a device (battery) which conceptually shall be 39 the master and uses methods exported by other devices. We need to control MUIC 40 to start charging the battery, use PMIC to reduce board's overall power 41 consumption (by disabling not needed LDOs, BUCKs) and get current state of 42 energy on the battery from FG. 43 Up till now u-boot doesn't support device model, so a simple one had to be 44 added. 45 46 The directory hierarchy has following structure: 47 ./include/power/<device_name>_<device_function>.h 48 e.g. ./include/power/max8997_pmic.h 49 50 ./drivers/power/pmic/power_{core files}.c 51 e.g. ./drivers/power/pmic/power_core.c 52 53 ./drivers/power/pmic/<device_function>/<device_function>_<device_name>.c 54 e.g. ./drivers/power/pmic/pmic_max8997.c 55 e.g. ./drivers/power/battery/trats/bat_trats.c 56 e.g. ./drivers/power/fuel_gauge/fg_max17042.c 57 58 The framework classifies devices by their function - separate directories should 59 be maintained for different classes of devices. 60 61 Current design 62 -------------- 63 64 Everything is a power device described by struct pmic. Even battery is 65 considered as a valid power device. This helps for better management of those 66 devices. 67 68 - Block diagram of the hierarchy: 69 ----------------- 70 --------| BAT |------------ 71 | | | | 72 | ----------------- | 73 | | | 74 \|/ \|/ \|/ 75 ----------- ----------------- --------- 76 |FG | |MUIC | |CHRG | 77 | | | | | | 78 ----------- ----------------- --------- 79 80 81 1. When hierarchy is not needed (no complex battery charge): 82 83 Definition of the struct pmic is only required with proper name and parameters 84 for communication. This is enough to use the "pmic" command in the u-boot 85 prompt to change values of device's register (enable/disable LDO, BUCK). 86 87 The PG, MUIC and CHRG above are regarded to be in the same level in the 88 hierarchy. 89 90 2. Complex battery charging. 91 92 To charge a battery, information from several "abstract" power devices is 93 needed (defined at ./include/power/pmic.h): 94 - FG device (struct power_fg): 95 -- *fg_battery_check - check if battery is not above its limits 96 -- *fg_battery_update - update the pmic framework with current 97 battery state(voltage and current capacity) 98 99 - Charger device (struct power_chrq): 100 -- *chrg_type - type/capacity of the charger (including information 101 about USB cable disconnection) 102 -- *chrg_bat_present - detection if battery to be charged is 103 present 104 -- *chrg_state - status of the charger - if it is enabled or 105 disabled 106 107 - Battery device (struct power_battery): 108 -- *battery_init - assign proper callbacks to be used by top 109 hierarchy battery device 110 -- *battery_charge - called from "pmic" command, responsible 111 for performing the charging 112 113 Now two batteries are supported; trats and trats2 [*]. Those differ in the way 114 how they handle the exact charging. Trats uses polling (MAX8997) and trats2 115 relies on the PMIC/MUIC HW completely (MAX77693). 116 117 __Example for trats (this can be very different for other board):__ 118 -- *fg_battery_check -> FG device (fg_max17042.c) 119 -- *fg_battery_update -> FG device (fg_max17042.c) 120 -- *chrg_type -> MUIC device (muic_max8997.c) 121 -- *chrg_bat_present -> PMIC device (pmic_max8997.c) 122 -- *chrg_state -> PMIC device (pmic_max8997.c) 123 -- *battery_init -> BAT device (bat_trats.c) 124 -- *battery_charge -> BAT device (bat_trats.c) 125 126 Also the struct pmic holds method (*low_power_mode) for reducing board's 127 power consumption when one calls "pmic BAT_TRATS bat charge" command. 128 129 How to add a new power device 130 ----------------------------- 131 132 1. Simple device should be added with creation of file 133 <pmic_function>_<pmic_name>.c, <pmic_name>_<pmic_function>.h according to the 134 proposed and described above scheme. 135 136 Then "pmic" command supports reading/writing/dump of device's internal 137 registers. 138 139 2. Charging battery with hierarchy 140 Define devices as listed at 1. 141 142 Define battery file (bat_<board>.c). Please also note that one might need a 143 corresponding battery model description for FG. 144 145 For points 1 and 2 use a generic function power_init_board() to initialise the 146 power framework on your board. 147 148 For reference, please look into the trats/trats2 boards. 149 150 TO DO list (for PMICv3) - up till v2014.04 151 ------------------------------------------ 152 153 1. Description of the devices related to power via device tree is not available. 154 This is the main problem when a developer tries to build a multi-boot u-boot 155 binary. The best would be to parse the DTS from Linux kernel. 156 157 2. To support many instances of the same IC, like two MAX8997, one needs to 158 copy the corresponding pmic_max8997.c file with changed name to "MAX8997_PMICX", 159 where X is the device number. This problem will be addressed when extended 160 pmic_core.c will support storing available devices in a list. 161 162 3. Definition of batteries [*] (for trats/trats2) should be excluded from the 163 code responsible for charging them and since it in fact describes the charging 164 profile it should be put to a separate file. 165 166 4. Adjust the framework to work with the device model. 167
README.pxe
1 SPDX-License-Identifier: GPL-2.0+ 2 /* 3 * Copyright 2010-2011 Calxeda, Inc. 4 */ 5 6 The 'pxe' commands provide a near subset of the functionality provided by 7 the PXELINUX boot loader. This allows U-Boot based systems to be controlled 8 remotely using the same PXE based techniques that many non U-Boot based servers 9 use. 10 11 Commands 12 ======== 13 14 pxe get 15 ------- 16 syntax: pxe get 17 18 follows PXELINUX's rules for retrieving configuration files from a tftp 19 server, and supports a subset of PXELINUX's config file syntax. 20 21 Environment 22 ----------- 23 'pxe get' requires two environment variables to be set: 24 25 pxefile_addr_r - should be set to a location in RAM large enough to hold 26 pxe files while they're being processed. Up to 16 config files may be 27 held in memory at once. The exact number and size of the files varies with 28 how the system is being used. A typical config file is a few hundred bytes 29 long. 30 31 bootfile,serverip - these two are typically set in the DHCP response 32 handler, and correspond to fields in the DHCP response. 33 34 'pxe get' optionally supports these two environment variables being set: 35 36 ethaddr - this is the standard MAC address for the ethernet adapter in use. 37 'pxe get' uses it to look for a configuration file specific to a system's 38 MAC address. 39 40 pxeuuid - this is a UUID in standard form using lower case hexadecimal 41 digits, for example, 550e8400-e29b-41d4-a716-446655440000. 'pxe get' uses 42 it to look for a configuration file based on the system's UUID. 43 44 File Paths 45 ---------- 46 'pxe get' repeatedly tries to download config files until it either 47 successfully downloads one or runs out of paths to try. The order and 48 contents of paths it tries mirrors exactly that of PXELINUX - you can 49 read in more detail about it at: 50 51 http://syslinux.zytor.com/wiki/index.php/Doc/pxelinux 52 53 pxe boot 54 -------- 55 syntax: pxe boot [pxefile_addr_r] 56 57 Interprets a pxe file stored in memory. 58 59 pxefile_addr_r is an optional argument giving the location of the pxe file. 60 The file must be terminated with a NUL byte. 61 62 Environment 63 ----------- 64 There are some environment variables that may need to be set, depending 65 on conditions. 66 67 pxefile_addr_r - if the optional argument pxefile_addr_r is not supplied, 68 an environment variable named pxefile_addr_r must be supplied. This is 69 typically the same value as is used for the 'pxe get' command. 70 71 bootfile - typically set in the DHCP response handler based on the 72 same field in the DHCP respone, this path is used to generate the base 73 directory that all other paths to files retrieved by 'pxe boot' will use. 74 If no bootfile is specified, paths used in pxe files will be used as is. 75 76 serverip - typically set in the DHCP response handler, this is the IP 77 address of the tftp server from which other files will be retrieved. 78 79 kernel_addr_r, initrd_addr_r - locations in RAM at which 'pxe boot' will 80 store the kernel(or FIT image) and initrd it retrieves from tftp. These 81 locations will be passed to the bootm command to boot the kernel. These 82 environment variables are required to be set. 83 84 fdt_addr_r - location in RAM at which 'pxe boot' will store the fdt blob it 85 retrieves from tftp. The retrieval is possible if 'fdt' label is defined in 86 pxe file and 'fdt_addr_r' is set. If retrieval is possible, 'fdt_addr_r' 87 will be passed to bootm command to boot the kernel. 88 89 fdt_addr - the location of a fdt blob. 'fdt_addr' will be passed to bootm 90 command if it is set and 'fdt_addr_r' is not passed to bootm command. 91 92 pxe file format 93 =============== 94 The pxe file format is nearly a subset of the PXELINUX file format; see 95 http://syslinux.zytor.com/wiki/index.php/PXELINUX. It's composed of one line 96 commands - global commands, and commands specific to labels. Lines begining 97 with # are treated as comments. White space between and at the beginning of 98 lines is ignored. 99 100 The size of pxe files and the number of labels is only limited by the amount 101 of RAM available to U-Boot. Memory for labels is dynamically allocated as 102 they're parsed, and memory for pxe files is statically allocated, and its 103 location is given by the pxefile_addr_r environment variable. The pxe code is 104 not aware of the size of the pxefile memory and will outgrow it if pxe files 105 are too large. 106 107 Supported global commands 108 ------------------------- 109 Unrecognized commands are ignored. 110 111 default <label> - the label named here is treated as the default and is 112 the first label 'pxe boot' attempts to boot. 113 114 menu title <string> - sets a title for the menu of labels being displayed. 115 116 menu include <path> - use tftp to retrieve the pxe file at <path>, which 117 is then immediately parsed as if the start of its 118 contents were the next line in the current file. nesting 119 of include up to 16 files deep is supported. 120 121 prompt <flag> - if 1, always prompt the user to enter a label to boot 122 from. if 0, only prompt the user if timeout expires. 123 124 timeout <num> - wait for user input for <num>/10 seconds before 125 auto-booting a node. 126 127 label <name> - begin a label definition. labels continue until 128 a command not recognized as a label command is seen, 129 or EOF is reached. 130 131 Supported label commands 132 ------------------------ 133 labels end when a command not recognized as a label command is reached, or EOF. 134 135 menu default - set this label as the default label to boot; this is 136 the same behavior as the global default command but 137 specified in a different way 138 139 kernel <path> - if this label is chosen, use tftp to retrieve the kernel 140 (or FIT image) at <path>. it will be stored at the address 141 indicated in the kernel_addr_r environment variable, and 142 that address will be passed to bootm to boot this kernel. 143 144 append <string> - use <string> as the kernel command line when booting this 145 label. 146 147 initrd <path> - if this label is chosen, use tftp to retrieve the initrd 148 at <path>. it will be stored at the address indicated in 149 the initrd_addr_r environment variable, and that address 150 will be passed to bootm. 151 152 fdt <path> - if this label is chosen, use tftp to retrieve the fdt blob 153 at <path>. it will be stored at the address indicated in 154 the fdt_addr_r environment variable, and that address will 155 be passed to bootm. 156 157 fdtdir <path> - if this label is chosen, use tftp to retrieve a fdt blob 158 relative to <path>. If the fdtfile environment variable 159 is set, <path>/<fdtfile> is retrieved. Otherwise, the 160 filename is generated from the soc and board environment 161 variables, i.e. <path>/<soc>-<board>.dtb is retrieved. 162 If the fdt command is specified, fdtdir is ignored. 163 164 localboot <flag> - Run the command defined by "localcmd" in the environment. 165 <flag> is ignored and is only here to match the syntax of 166 PXELINUX config files. 167 168 Example 169 ------- 170 Here's a couple of example files to show how this works. 171 172 ------------/tftpboot/pxelinux.cfg/menus/base.menu----------- 173 menu title Linux selections 174 175 # This is the default label 176 label install 177 menu label Default Install Image 178 kernel kernels/install.bin 179 append console=ttyAMA0,38400 debug earlyprintk 180 initrd initrds/uzInitrdDebInstall 181 182 # Just another label 183 label linux-2.6.38 184 kernel kernels/linux-2.6.38.bin 185 append root=/dev/sdb1 186 187 # The locally installed kernel 188 label local 189 menu label Locally installed kernel 190 append root=/dev/sdb1 191 localboot 1 192 ------------------------------------------------------------- 193 194 ------------/tftpboot/pxelinux.cfg/default------------------- 195 menu include pxelinux.cfg/menus/base.menu 196 timeout 500 197 198 default linux-2.6.38 199 ------------------------------------------------------------- 200 201 When a pxe client retrieves and boots the default pxe file, 202 'pxe boot' will wait for user input for 5 seconds before booting 203 the linux-2.6.38 label, which will cause /tftpboot/kernels/linux-2.6.38.bin 204 to be downloaded, and boot with the command line "root=/dev/sdb1" 205 206 Differences with PXELINUX 207 ========================= 208 The biggest difference between U-Boot's pxe and PXELINUX is that since 209 U-Boot's pxe support is written entirely in C, it can run on any platform 210 with network support in U-Boot. Here are some other differences between 211 PXELINUX and U-Boot's pxe support. 212 213 - U-Boot's pxe does not support the PXELINUX DHCP option codes specified 214 in RFC 5071, but could be extended to do so. 215 216 - when U-Boot's pxe fails to boot, it will return control to U-Boot, 217 allowing another command to run, other U-Boot command, instead of resetting 218 the machine like PXELINUX. 219 220 - U-Boot's pxe doesn't rely on or provide an UNDI/PXE stack in memory, it 221 only uses U-Boot. 222 223 - U-Boot's pxe doesn't provide the full menu implementation that PXELINUX 224 does, only a simple text based menu using the commands described in 225 this README. With PXELINUX, it's possible to have a graphical boot 226 menu, submenus, passwords, etc. U-Boot's pxe could be extended to support 227 a more robust menuing system like that of PXELINUX's. 228 229 - U-Boot's pxe expects U-Boot uimg's as kernels. Anything that would work 230 with the 'bootm' command in U-Boot could work with the 'pxe boot' command. 231 232 - U-Boot's pxe only recognizes a single file on the initrd command line. It 233 could be extended to support multiple. 234 235 - in U-Boot's pxe, the localboot command doesn't necessarily cause a local 236 disk boot - it will do whatever is defined in the 'localcmd' env 237 variable. And since it doesn't support a full UNDI/PXE stack, the 238 type field is ignored. 239 240 - the interactive prompt in U-Boot's pxe only allows you to choose a label 241 from the menu. If you want to boot something not listed, you can ctrl+c 242 out of 'pxe boot' and use existing U-Boot commands to accomplish it. 243
README.qemu-arm
1 # SPDX-License-Identifier: GPL-2.0+ 2 # 3 # Copyright (C) 2017, Tuomas Tynkkynen <tuomas.tynkkynen (a] iki.fi> 4 5 U-Boot on QEMU's 'virt' machine on ARM & AArch64 6 ================================================ 7 8 QEMU for ARM supports a special 'virt' machine designed for emulation and 9 virtualization purposes. This document describes how to run U-Boot under it. 10 Both 32-bit ARM and AArch64 are supported. 11 12 The 'virt' platform provides the following as the basic functionality: 13 14 - A freely configurable amount of CPU cores 15 - U-Boot loaded and executing in the emulated flash at address 0x0 16 - A generated device tree blob placed at the start of RAM 17 - A freely configurable amount of RAM, described by the DTB 18 - A PL011 serial port, discoverable via the DTB 19 - An ARMv7/ARMv8 architected timer 20 - PSCI for rebooting the system 21 - A generic ECAM-based PCI host controller, discoverable via the DTB 22 23 Additionally, a number of optional peripherals can be added to the PCI bus. 24 25 Building U-Boot 26 --------------- 27 Set the CROSS_COMPILE environment variable as usual, and run: 28 29 - For ARM: 30 make qemu_arm_defconfig 31 make 32 33 - For AArch64: 34 make qemu_arm64_defconfig 35 make 36 37 Running U-Boot 38 -------------- 39 The minimal QEMU command line to get U-Boot up and running is: 40 41 - For ARM: 42 qemu-system-arm -machine virt -bios u-boot.bin 43 44 - For AArch64: 45 qemu-system-aarch64 -machine virt -cpu cortex-a57 -bios u-boot.bin 46 47 Note that for some odd reason qemu-system-aarch64 needs to be explicitly 48 told to use a 64-bit CPU or it will boot in 32-bit mode. 49 50 Additional peripherals that have been tested to work in both U-Boot and Linux 51 can be enabled with the following command line parameters: 52 53 - To add a Serial ATA disk via an Intel ICH9 AHCI controller, pass e.g.: 54 -drive if=none,file=disk.img,id=mydisk -device ich9-ahci,id=ahci -device ide-drive,drive=mydisk,bus=ahci.0 55 - To add an Intel E1000 network adapter, pass e.g.: 56 -netdev user,id=net0 -device e1000,netdev=net0 57 - To add an EHCI-compliant USB host controller, pass e.g.: 58 -device usb-ehci,id=ehci 59 - To add a NVMe disk, pass e.g.: 60 -drive if=none,file=disk.img,id=mydisk -device nvme,drive=mydisk,serial=foo 61 62 These have been tested in QEMU 2.9.0 but should work in at least 2.5.0 as well. 63
README.qemu-mips
1 By Vlad Lungu vlad.lungu (a] windriver.com 2007-Oct-01 2 ---------------------------------------- 3 Qemu is a full system emulator. See 4 5 http://www.nongnu.org/qemu/ 6 7 Limitations & comments 8 ---------------------- 9 Supports the "-M mips" configuration of qemu: serial,NE2000,IDE. 10 Supports little and big endian as well as 32 bit and 64 bit. 11 Derived from au1x00 with a lot of things cut out. 12 13 Supports emulated flash (patch Jean-Christophe PLAGNIOL-VILLARD) with 14 recent qemu versions. When using emulated flash, launch with 15 -pflash <filename> and erase mips_bios.bin. 16 17 18 Notes for the Qemu MIPS port 19 ---------------------------- 20 21 I) Example usage: 22 23 Using u-boot.bin as ROM (replaces Qemu monitor): 24 25 32 bit, big endian: 26 # make qemu_mips 27 # qemu-system-mips -M mips -bios u-boot.bin -nographic 28 29 32 bit, little endian: 30 # make qemu_mipsel 31 # qemu-system-mipsel -M mips -bios u-boot.bin -nographic 32 33 64 bit, big endian: 34 # make qemu_mips64 35 # qemu-system-mips64 -cpu MIPS64R2-generic -M mips -bios u-boot.bin -nographic 36 37 64 bit, little endian: 38 # make qemu_mips64el 39 # qemu-system-mips64el -cpu MIPS64R2-generic -M mips -bios u-boot.bin -nographic 40 41 or using u-boot.bin from emulated flash: 42 43 if you use a qemu version after commit 4224 44 45 create image: 46 # dd of=flash bs=1k count=4k if=/dev/zero 47 # dd of=flash bs=1k conv=notrunc if=u-boot.bin 48 start it (see above): 49 # qemu-system-mips[64][el] [-cpu MIPS64R2-generic] -M mips -pflash flash -nographic 50 51 2) Download kernel + initrd 52 53 On ftp://ftp.denx.de/pub/contrib/Jean-Christophe_Plagniol-Villard/qemu_mips/ 54 you can downland 55 56 #config to build the kernel 57 qemu_mips_defconfig 58 #patch to fix mips interrupt init on 2.6.24.y kernel 59 qemu_mips_kernel.patch 60 initrd.gz 61 vmlinux 62 vmlinux.bin 63 System.map 64 65 4) Generate uImage 66 67 # tools/mkimage -A mips -O linux -T kernel -C gzip -a 0x80010000 -e 0x80245650 -n "Linux 2.6.24.y" -d vmlinux.bin.gz uImage 68 69 5) Copy uImage to Flash 70 # dd if=uImage bs=1k conv=notrunc seek=224 of=flash 71 72 6) Generate Ide Disk 73 74 # dd of=ide bs=1k cout=100k if=/dev/zero 75 76 # sfdisk -C 261 -d ide 77 # partition table of ide 78 unit: sectors 79 80 ide1 : start= 63, size= 32067, Id=83 81 ide2 : start= 32130, size= 32130, Id=83 82 ide3 : start= 64260, size= 4128705, Id=83 83 ide4 : start= 0, size= 0, Id= 0 84 85 7) Copy to ide 86 87 # dd if=uImage bs=512 conv=notrunc seek=63 of=ide 88 89 8) Generate ext2 on part 2 on Copy uImage and initrd.gz 90 91 # Attached as loop device ide offset = 32130 * 512 92 # losetup -o 16450560 -f ide 93 # Format as ext2 ( arg2 : nb blocks) 94 # mke2fs /dev/loop0 16065 95 # losetup -d /dev/loop0 96 # Mount and copy uImage and initrd.gz to it 97 # mount -o loop,offset=16450560 -t ext2 ide /mnt 98 # mkdir /mnt/boot 99 # cp {initrd.gz,uImage} /mnt/boot/ 100 # Umount it 101 # umount /mnt 102 103 9) Set Environment 104 105 setenv rd_start 0x80800000 106 setenv rd_size 2663940 107 setenv kernel BFC38000 108 setenv oad_addr 80500000 109 setenv load_addr2 80F00000 110 setenv kernel_flash BFC38000 111 setenv load_addr_hello 80200000 112 setenv bootargs 'root=/dev/ram0 init=/bin/sh' 113 setenv load_rd_ext2 'ide res; ext2load ide 0:2 ${rd_start} /boot/initrd.gz' 114 setenv load_rd_tftp 'tftp ${rd_start} /initrd.gz' 115 setenv load_kernel_hda 'ide res; diskboot ${load_addr} 0:2' 116 setenv load_kernel_ext2 'ide res; ext2load ide 0:2 ${load_addr} /boot/uImage' 117 setenv load_kernel_tftp 'tftp ${load_addr} /qemu_mips/uImage' 118 setenv boot_ext2_ext2 'run load_rd_ext2; run load_kernel_ext2; run addmisc; bootm ${load_addr}' 119 setenv boot_ext2_flash 'run load_rd_ext2; run addmisc; bootm ${kernel_flash}' 120 setenv boot_ext2_hda 'run load_rd_ext2; run load_kernel_hda; run addmisc; bootm ${load_addr}' 121 setenv boot_ext2_tftp 'run load_rd_ext2; run load_kernel_tftp; run addmisc; bootm ${load_addr}' 122 setenv boot_tftp_hda 'run load_rd_tftp; run load_kernel_hda; run addmisc; bootm ${load_addr}' 123 setenv boot_tftp_ext2 'run load_rd_tftp; run load_kernel_ext2; run addmisc; bootm ${load_addr}' 124 setenv boot_tftp_flash 'run load_rd_tftp; run addmisc; bootm ${kernel_flash}' 125 setenv boot_tftp_tftp 'run load_rd_tftp; run load_kernel_tftp; run addmisc; bootm ${load_addr}' 126 setenv load_hello_tftp 'tftp ${load_addr_hello} /examples/hello_world.bin' 127 setenv go_tftp 'run load_hello_tftp; go ${load_addr_hello}' 128 setenv addmisc 'setenv bootargs ${bootargs} console=ttyS0,${baudrate} rd_start=${rd_start} rd_size=${rd_size} ethaddr=${ethaddr}' 129 setenv bootcmd 'run boot_tftp_flash' 130 131 10) Now you can boot from flash, ide, ide+ext2 and tfp 132 133 # qemu-system-mips -M mips -pflash flash -monitor null -nographic -net nic -net user -tftp `pwd` -hda ide 134 135 II) How to debug U-Boot 136 137 In order to debug U-Boot you need to start qemu with gdb server support (-s) 138 and waiting the connection to start the CPU (-S) 139 140 # qemu-system-mips -S -s -M mips -pflash flash -monitor null -nographic -net nic -net user -tftp `pwd` -hda ide 141 142 in an other console you start gdb 143 144 1) Debugging of U-Boot Before Relocation 145 146 Before relocation, the addresses in the ELF file can be used without any problems 147 by connecting to the gdb server localhost:1234 148 149 # mipsel-unknown-linux-gnu-gdb u-boot 150 GNU gdb 6.6 151 Copyright (C) 2006 Free Software Foundation, Inc. 152 GDB is free software, covered by the GNU General Public License, and you are 153 welcome to change it and/or distribute copies of it under certain conditions. 154 Type "show copying" to see the conditions. 155 There is absolutely no warranty for GDB. Type "show warranty" for details. 156 This GDB was configured as "--host=i486-linux-gnu --target=mipsel-unknown-linux-gnu"... 157 (gdb) target remote localhost:1234 158 Remote debugging using localhost:1234 159 _start () at start.S:64 160 64 RVECENT(reset,0) /* U-Boot entry point */ 161 Current language: auto; currently asm 162 (gdb) b board.c:289 163 Breakpoint 1 at 0xbfc00cc8: file board.c, line 289. 164 (gdb) c 165 Continuing. 166 167 Breakpoint 1, board_init_f (bootflag=<value optimized out>) at board.c:290 168 290 relocate_code (addr_sp, id, addr); 169 Current language: auto; currently c 170 (gdb) p/x addr 171 $1 = 0x87fa0000 172 173 2) Debugging of U-Boot After Relocation 174 175 For debugging U-Boot after relocation we need to know the address to which 176 U-Boot relocates itself to 0x87fa0000 by default. 177 And replace the symbol table to this offset. 178 179 (gdb) symbol-file 180 Discard symbol table from `/private/u-boot-arm/u-boot'? (y or n) y 181 Error in re-setting breakpoint 1: 182 No symbol table is loaded. Use the "file" command. 183 No symbol file now. 184 (gdb) add-symbol-file u-boot 0x87fa0000 185 add symbol table from file "u-boot" at 186 .text_addr = 0x87fa0000 187 (y or n) y 188 Reading symbols from /private/u-boot-arm/u-boot...done. 189 Breakpoint 1 at 0x87fa0cc8: file board.c, line 289. 190 (gdb) c 191 Continuing. 192 193 Program received signal SIGINT, Interrupt. 194 0xffffffff87fa0de4 in udelay (usec=<value optimized out>) at time.c:78 195 78 while ((tmo - read_c0_count()) < 0x7fffffff) 196
README.ramboot-ppc85xx
1 RAMBOOT for MPC85xx Platforms 2 ============================== 3 4 RAMBOOT literally means boot from DDR. But since DDR is volatile memory some 5 pre-mechanism is required to load the DDR with the bootloader binary. 6 - In case of SD and SPI boot this is done by BootROM code inside the chip 7 itself. 8 - In case of NAND boot FCM supports loading initial 4K code from NAND flash 9 which can initialize the DDR and get the complete bootloader copied to DDR. 10 11 In addition to the above there could be some more methods to initialize the DDR 12 and load it manually. 13 Two of them are described below.There is also an explanation as to where these 14 methods could be handy. 15 1. Load the RAM based bootloader onto DDR via JTAG/BDI interface. And then 16 execute the bootloader from DDR. 17 This may be handy in the following cases: 18 - In very early stage of platform bringup where other boot options are not 19 functional because of various reasons. 20 - In case the support to program the flashes on the board is not available. 21 22 2. Load the RAM based bootloader onto DDR using already existing bootloader on 23 the board.And then execute the bootloader from DDR. 24 Some usecases where this may be used: 25 - While developing some new feature of u-boot, for example USB driver or 26 SPI driver. 27 Suppose the board already has a working bootloader on it. And you would 28 prefer to keep it intact, at the same time want to test your bootloader. 29 In this case you can get your test bootloader binary into DDR via tftp 30 for example. Then execute the test bootloader. 31 - Suppose a platform already has a propreitery bootloader which does not 32 support for example AMP boot. In this case also RAM boot loader can be 33 utilized. 34 35 So basically when the original bootloader is required to be kept intact 36 RAM based bootloader can offer an updated bootloader on the system. 37 38 Both the above Bootloaders are slight variants of SDcard or SPI Flash 39 bootloader or for that matter even NAND bootloader. 40 All of them define CONFIG_SYS_RAMBOOT. 41 The main difference among all of them is the way the pre-environment is getting 42 configured and who is doing that. 43 - In case of SD card and SPI flash bootloader this is done by On Chip BootROM inside the Si itself. 44 - In case of NAND boot SPL/TPL code does it with some support from Si itself. 45 - In case of the pure RAM based bootloaders we have to do it by JTAG manually or already existing bootloader. 46 47 How to use them: 48 1. Using JTAG 49 Boot up in core hold off mode or stop the core after reset using JTAG 50 interface. 51 Preconfigure DDR/L2SRAM through JTAG interface. 52 - setup DDR controller registers. 53 - setup DDR LAWs 54 - setup DDR TLB 55 Load the RAM based boot loader to the proper location in DDR/L2SRAM. 56 set up IAR (Instruction counter properly) 57 Enable the core to execute. 58 59 2. Using already existing bootloader. 60 get the rambased boot loader binary into DDR/L2SRAM via tftp. 61 execute the RAM based bootloader. 62 => tftp 11000000 u-boot-ram.bin 63 => go 1107f000 64 65 Please note that L2SRAM can also be used instead of DDR if the SOC has 66 sufficient size of L2SRAM. 67 68 Necessary Code changes Required: 69 ===================================== 70 Please note that below mentioned changes are for 85xx platforms. 71 They have been tested on P1020/P2020/P1010 RDB. 72 73 The main difference between the above two methods from technical perspective is 74 that in 1st case SOC is just out of reset so it is in default configuration. 75 (CCSRBAR is at 0xff700000). 76 In the 2nd case bootloader has already re-located CCSRBAR to 0xffe00000 77 78 1. File name-> boards.cfg 79 There can be added specific Make options for RAMBoot. We can keep different 80 options for the two cases mentioned above. 81 for example 82 P1020RDB_JTAG_RAMBOOT and P1020RDB_GO_RAMBOOT. 83 84 2. platform config file 85 for example include/configs/P1_P2_RDB.h 86 87 #ifdef CONFIG_RAMBOOT 88 #define CONFIG_SDCARD 89 #endif 90 91 This will finally use the CONFIG_SYS_RAMBOOT. 92 93 3. Change CONFIG_SYS_CCSRBAR_DEFAULT in menuconfig accordingly. 94 In the section of the particular SOC, for example P1020, pseudo code 95 96 #if defined(CONFIG_GO) 97 #define CONFIG_SYS_CCSRBAR_DEFAULT 0xffe00000 98 #else 99 #define CONFIG_SYS_CCSRBAR_DEFAULT 0xff700000 100 #endif 101 102 For JTAG RAMBOOT this is not required because CCSRBAR is at ff700000. 103
README.rmobile
1 Summary 2 ======= 3 4 This README is about U-Boot support for Renesas's ARM Cortex-A9 based RMOBILE[1] 5 and Cortex-A9/A53/A57 based R-Car[2] family of SoCs. Renesas's RMOBILE/R-Car SoC 6 family contains an ARM Cortex-A9/A53/A57. 7 8 Currently the following boards are supported: 9 10 | SoC | Board | defconfig 11 |===============+========================================+=================== 12 | R8A73A0 | KMC KZM-A9-GT [3] | kzm9g_config 13 | R8A7734 | Atmark-Techno Armadillo-800-EVA [4] | armadillo-800eva_config 14 |===============+========================================+=================== 15 | R8A7790 H2 | Renesas Electronics Lager | lager_defconfig 16 | | Renesas Electronics Stout | stout_defconfig 17 |---------------+----------------------------------------+------------------- 18 | R8A7791 M2-W | Renesas Electronics Koelsch | koelsch_defconfig 19 | | Renesas Electronics Porter | porter_defconfig 20 |---------------+----------------------------------------+------------------- 21 | R8A7792 V2H | Renesas Electronics Blanche | blanche_defconfig 22 |---------------+----------------------------------------+------------------- 23 | R8A7793 M2-N | Renesas Electronics Gose | gose_defconfig 24 |---------------+----------------------------------------+------------------- 25 | R8A7794 E2 | Renesas Electronics Alt | alt_defconfig 26 | | Renesas Electronics Silk | silk_defconfig 27 |===============+========================================+=================== 28 | R8A7795 H3 | Renesas Electronics Salvator-XS ES2.0+ | r8a7795_salvator-x_defconfig 29 | R8A7795 H3 | Renesas Electronics ULCB ES2.0+ | r8a7795_ulcb 30 |---------------+----------------------------------------+------------------- 31 | R8A7796 M3-W | Renesas Electronics Salvator-X | r8a7796_salvator-x_defconfig 32 | R8A7796 M3-W | Renesas Electronics ULCB | r8a7796_ulcb 33 |---------------+----------------------------------------+------------------- 34 | R8A77965 M3-N | Renesas Electronics Salvator-XS | r8a77965_salvator-x_defconfig 35 |---------------+----------------------------------------+------------------- 36 | R8A77970 V3M | Renesas Electronics Eagle | r8a77970_eagle_defconfig 37 |---------------+----------------------------------------+------------------- 38 | R8A77995 D3 | Renesas Electronics Draak | r8a77995_draak_defconfig 39 '===============+========================================+=================== 40 41 Toolchain 42 ========= 43 44 Either ARMv7 toolchain for 32bit Cortex-A9 systems or ARMv8 (aarch64) 45 toolchain for 64bit Cortex-A53/A57 systems. Currently we compile the 46 32bit systems with -march=armv5 to allow more compilers to work. (For 47 U-Boot code this has no performance impact.) 48 49 Currently, ELDK[5], Linaro[6], CodeSourcery[7] and Emdebian[8] supports 50 ARMv7. Modern distributions also contain ARMv7 and ARMv8 crosstoolchains 51 in their package feeds. 52 53 Build 54 ===== 55 56 Locate defconfig in the table above. Then apply standard build procedure: 57 58 make <board>_defconfig 59 make 60 61 Note: Armadillo-800-EVA's U-Boot supports booting from SDcard only. 62 Please see "B.2 Appendix B Boot Specifications" in hardware manual. 63 64 Links 65 ===== 66 67 [1] Renesas RMOBILE: 68 69 http://am.renesas.com/products/soc/assp/mobile/r_mobile/index.jsp 70 71 [2] Renesas R-Car: 72 73 http://am.renesas.com/products/soc/assp/automotive/index.jsp 74 75 [3] KZM-A9-GT 76 77 http://www.kmckk.co.jp/kzma9-gt/index.html 78 79 [4] Armadillo-800-EVA 80 81 http://armadillo.atmark-techno.com/armadillo-800-EVA 82 83 [5] ELDK 84 85 http://www.denx.de/wiki/view/ELDK-5/WebHome#Section_1.6. 86 87 [6] Linaro 88 89 http://www.linaro.org/downloads/ 90 91 [7] CodeSourcey 92 93 http://www.mentor.com/embedded-software/codesourcery 94 95 [8] Emdebian 96 97 http://www.emdebian.org/crosstools.html 98
README.rockchip
1 # SPDX-License-Identifier: GPL-2.0+ 2 # 3 # Copyright (C) 2015 Google. Inc 4 # Written by Simon Glass <sjg (a] chromium.org> 5 6 U-Boot on Rockchip 7 ================== 8 9 There are several repositories available with versions of U-Boot that support 10 many Rockchip devices [1] [2]. 11 12 The current mainline support is experimental only and is not useful for 13 anything. It should provide a base on which to build. 14 15 So far only support for the RK3288 and RK3036 is provided. 16 17 18 Prerequisites 19 ============= 20 21 You will need: 22 23 - Firefly RK3288 board or something else with a supported RockChip SoC 24 - Power connection to 5V using the supplied micro-USB power cable 25 - Separate USB serial cable attached to your computer and the Firefly 26 (connect to the micro-USB connector below the logo) 27 - rkflashtool [3] 28 - openssl (sudo apt-get install openssl) 29 - Serial UART connection [4] 30 - Suitable ARM cross compiler, e.g.: 31 sudo apt-get install gcc-4.7-arm-linux-gnueabi 32 33 34 Building 35 ======== 36 37 At present nine RK3288 boards are supported: 38 39 - EVB RK3288 - use evb-rk3288 configuration 40 - Fennec RK3288 - use fennec-rk3288 configuration 41 - Firefly RK3288 - use firefly-rk3288 configuration 42 - Hisense Chromebook - use chromebook_jerry configuration 43 - MiQi RK3288 - use miqi-rk3288 configuration 44 - phyCORE-RK3288 RDK - use phycore-rk3288 configuration 45 - PopMetal RK3288 - use popmetal-rk3288 configuration 46 - Radxa Rock 2 - use rock2 configuration 47 - Tinker RK3288 - use tinker-rk3288 configuration 48 49 Two RK3036 board are supported: 50 51 - EVB RK3036 - use evb-rk3036 configuration 52 - Kylin - use kylin_rk3036 configuration 53 54 For example: 55 56 CROSS_COMPILE=arm-linux-gnueabi- make O=firefly firefly-rk3288_defconfig all 57 58 (or you can use another cross compiler if you prefer) 59 60 61 Writing to the board with USB 62 ============================= 63 64 For USB to work you must get your board into ROM boot mode, either by erasing 65 your MMC or (perhaps) holding the recovery button when you boot the board. 66 To erase your MMC, you can boot into Linux and type (as root) 67 68 dd if=/dev/zero of=/dev/mmcblk0 bs=1M 69 70 Connect your board's OTG port to your computer. 71 72 To create a suitable image and write it to the board: 73 74 ./firefly-rk3288/tools/mkimage -n rk3288 -T rkimage -d \ 75 ./firefly-rk3288/spl/u-boot-spl-dtb.bin out && \ 76 cat out | openssl rc4 -K 7c4e0304550509072d2c7b38170d1711 | rkflashtool l 77 78 If all goes well you should something like: 79 80 U-Boot SPL 2015.07-rc1-00383-ge345740-dirty (Jun 03 2015 - 10:06:49) 81 Card did not respond to voltage select! 82 spl: mmc init failed with error: -17 83 ### ERROR ### Please RESET the board ### 84 85 You will need to reset the board before each time you try. Yes, that's all 86 it does so far. If support for the Rockchip USB protocol or DFU were added 87 in SPL then we could in principle load U-Boot and boot to a prompt from USB 88 as several other platforms do. However it does not seem to be possible to 89 use the existing boot ROM code from SPL. 90 91 92 Booting from an SD card 93 ======================= 94 95 To write an image that boots from an SD card (assumed to be /dev/sdc): 96 97 ./firefly-rk3288/tools/mkimage -n rk3288 -T rksd -d \ 98 firefly-rk3288/spl/u-boot-spl-dtb.bin out && \ 99 sudo dd if=out of=/dev/sdc seek=64 && \ 100 sudo dd if=firefly-rk3288/u-boot-dtb.img of=/dev/sdc seek=16384 101 102 This puts the Rockchip header and SPL image first and then places the U-Boot 103 image at block 16384 (i.e. 8MB from the start of the SD card). This 104 corresponds with this setting in U-Boot: 105 106 #define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR 0x4000 107 108 Put this SD (or micro-SD) card into your board and reset it. You should see 109 something like: 110 111 U-Boot 2016.01-rc2-00309-ge5bad3b-dirty (Jan 02 2016 - 23:41:59 -0700) 112 113 Model: Radxa Rock 2 Square 114 DRAM: 2 GiB 115 MMC: dwmmc@ff0f0000: 0, dwmmc@ff0c0000: 1 116 *** Warning - bad CRC, using default environment 117 118 In: serial 119 Out: vop (a] ff940000.vidconsole 120 Err: serial 121 Net: Net Initialization Skipped 122 No ethernet found. 123 Hit any key to stop autoboot: 0 124 => 125 126 The rockchip bootrom can load and boot an initial spl, then continue to 127 load a second-level bootloader(ie. U-BOOT) as soon as it returns to bootrom. 128 Therefore RK3288 has another loading sequence like RK3036. The option of 129 U-Boot is controlled with this setting in U-Boot: 130 131 #define CONFIG_SPL_ROCKCHIP_BACK_TO_BROM 132 133 You can create the image via the following operations: 134 135 ./firefly-rk3288/tools/mkimage -n rk3288 -T rksd -d \ 136 firefly-rk3288/spl/u-boot-spl-dtb.bin out && \ 137 cat firefly-rk3288/u-boot-dtb.bin >> out && \ 138 sudo dd if=out of=/dev/sdc seek=64 139 140 If you have an HDMI cable attached you should see a video console. 141 142 For evb_rk3036 board: 143 ./evb-rk3036/tools/mkimage -n rk3036 -T rksd -d evb-rk3036/spl/u-boot-spl.bin out && \ 144 cat evb-rk3036/u-boot-dtb.bin >> out && \ 145 sudo dd if=out of=/dev/sdc seek=64 146 147 Note: rk3036 SDMMC and debug uart use the same iomux, so if you boot from SD, the 148 debug uart must be disabled 149 150 151 Booting from an SD card on RK3288 with TPL 152 ========================================== 153 154 Since the size of SPL can't be exceeded 0x8000 bytes in RK3288, it is not possible add 155 new SPL features like Falcon mode or etc. 156 157 So introduce TPL so-that adding new features to SPL is possible because now TPL should 158 run minimal with code like DDR, clock etc and rest of new features in SPL. 159 160 As of now TPL is added on Vyasa-RK3288 board. 161 162 To write an image that boots from an SD card (assumed to be /dev/mmcblk0): 163 164 ./tools/mkimage -n rk3288 -T rksd -d ./tpl/u-boot-tpl.bin out && 165 cat ./spl/u-boot-spl-dtb.bin >> out && 166 sudo dd if=out of=/dev/mmcblk0 seek=64 && 167 sudo dd if=u-boot-dtb.img of=/dev/mmcblk0 seek=16384 168 169 Booting from an SD card on RK3188 170 ================================= 171 172 For rk3188 boards the general storage onto the card stays the same as 173 described above, but the image creation needs a bit more care. 174 175 The bootrom of rk3188 expects to find a small 1kb loader which returns 176 control to the bootrom, after which it will load the real loader, which 177 can then be up to 29kb in size and does the regular ddr init. This is 178 handled by a single image (built as the SPL stage) that tests whether 179 it is handled for the first or second time via code executed from the 180 boot0-hook. 181 182 Additionally the rk3188 requires everything the bootrom loads to be 183 rc4-encrypted. Except for the very first stage the bootrom always reads 184 and decodes 2kb pages, so files should be sized accordingly. 185 186 # copy tpl, pad to 1020 bytes and append spl 187 tools/mkimage -n rk3188 -T rksd -d spl/u-boot-spl.bin out 188 189 # truncate, encode and append u-boot.bin 190 truncate -s %2048 u-boot.bin 191 cat u-boot.bin | split -b 512 --filter='openssl rc4 -K 7C4E0304550509072D2C7B38170D1711' >> out 192 193 194 Using fastboot on rk3288 195 ======================== 196 - Write GPT partition layout to mmc device which fastboot want to use it to 197 store the image 198 199 => gpt write mmc 1 $partitions 200 201 - Invoke fastboot command to prepare 202 203 => fastboot 1 204 205 - Start fastboot request on PC 206 207 fastboot -i 0x2207 flash loader evb-rk3288/spl/u-boot-spl-dtb.bin 208 209 You should see something like: 210 211 => fastboot 1 212 WARNING: unknown variable: partition-type:loader 213 Starting download of 357796 bytes 214 .. 215 downloading of 357796 bytes finished 216 Flashing Raw Image 217 ........ wrote 357888 bytes to 'loader' 218 219 Booting from SPI 220 ================ 221 222 To write an image that boots from SPI flash (e.g. for the Haier Chromebook): 223 224 ./chromebook_jerry/tools/mkimage -n rk3288 -T rkspi \ 225 -d chromebook_jerry/spl/u-boot-spl-dtb.bin spl.bin && \ 226 dd if=spl.bin of=spl-out.bin bs=128K conv=sync && \ 227 cat spl-out.bin chromebook_jerry/u-boot-dtb.img >out.bin && \ 228 dd if=out.bin of=out.bin.pad bs=4M conv=sync 229 230 This converts the SPL image to the required SPI format by adding the Rockchip 231 header and skipping every 2KB block. Then the U-Boot image is written at 232 offset 128KB and the whole image is padded to 4MB which is the SPI flash size. 233 The position of U-Boot is controlled with this setting in U-Boot: 234 235 #define CONFIG_SYS_SPI_U_BOOT_OFFS (128 << 10) 236 237 If you have a Dediprog em100pro connected then you can write the image with: 238 239 sudo em100 -s -c GD25LQ32 -d out.bin.pad -r 240 241 When booting you should see something like: 242 243 U-Boot SPL 2015.07-rc2-00215-g9a58220-dirty (Jun 23 2015 - 12:11:32) 244 245 246 U-Boot 2015.07-rc2-00215-g9a58220-dirty (Jun 23 2015 - 12:11:32 -0600) 247 248 Model: Google Jerry 249 DRAM: 2 GiB 250 MMC: 251 Using default environment 252 253 In: serial@ff690000 254 Out: serial@ff690000 255 Err: serial@ff690000 256 => 257 258 Future work 259 =========== 260 261 Immediate priorities are: 262 263 - USB host 264 - USB device 265 - Run CPU at full speed (code exists but we only see ~60 DMIPS maximum) 266 - NAND flash 267 - Support for other Rockchip parts 268 - Boot U-Boot proper over USB OTG (at present only SPL works) 269 270 271 Development Notes 272 ================= 273 274 There are plenty of patches in the links below to help with this work. 275 276 [1] https://github.com/rkchrome/uboot.git 277 [2] https://github.com/linux-rockchip/u-boot-rockchip.git branch u-boot-rk3288 278 [3] https://github.com/linux-rockchip/rkflashtool.git 279 [4] http://wiki.t-firefly.com/index.php/Firefly-RK3288/Serial_debug/en 280 281 rkimage 282 ------- 283 284 rkimage.c produces an SPL image suitable for sending directly to the boot ROM 285 over USB OTG. This is a very simple format - just the string RK32 (as 4 bytes) 286 followed by u-boot-spl-dtb.bin. 287 288 The boot ROM loads image to 0xff704000 which is in the internal SRAM. The SRAM 289 starts at 0xff700000 and extends to 0xff718000 where we put the stack. 290 291 rksd 292 ---- 293 294 rksd.c produces an image consisting of 32KB of empty space, a header and 295 u-boot-spl-dtb.bin. The header is defined by 'struct header0_info' although 296 most of the fields are unused by U-Boot. We just need to specify the 297 signature, a flag and the block offset and size of the SPL image. 298 299 The header occupies a single block but we pad it out to 4 blocks. The header 300 is encoding using RC4 with the key 7c4e0304550509072d2c7b38170d1711. The SPL 301 image can be encoded too but we don't do that. 302 303 The maximum size of u-boot-spl-dtb.bin which the boot ROM will read is 32KB, 304 or 0x40 blocks. This is a severe and annoying limitation. There may be a way 305 around this limitation, since there is plenty of SRAM, but at present the 306 board refuses to boot if this limit is exceeded. 307 308 The image produced is padded up to a block boundary (512 bytes). It should be 309 written to the start of an SD card using dd. 310 311 Since this image is set to load U-Boot from the SD card at block offset, 312 CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR, dd should be used to write 313 u-boot-dtb.img to the SD card at that offset. See above for instructions. 314 315 rkspi 316 ----- 317 318 rkspi.c produces an image consisting of a header and u-boot-spl-dtb.bin. The 319 resulting image is then spread out so that only the first 2KB of each 4KB 320 sector is used. The header is the same as with rksd and the maximum size is 321 also 32KB (before spreading). The image should be written to the start of 322 SPI flash. 323 324 See above for instructions on how to write a SPI image. 325 326 rkmux.py 327 -------- 328 329 You can use this script to create #defines for SoC register access. See the 330 script for usage. 331 332 333 Device tree and driver model 334 ---------------------------- 335 336 Where possible driver model is used to provide a structure to the 337 functionality. Device tree is used for configuration. However these have an 338 overhead and in SPL with a 32KB size limit some shortcuts have been taken. 339 In general all Rockchip drivers should use these features, with SPL-specific 340 modifications where required. 341 342 GPT partition layout 343 ---------------------------- 344 345 Rockchip use a unified GPT partition layout in open source support. 346 With this GPT partition layout, uboot can be compatilbe with other components, 347 like miniloader, trusted-os, arm-trust-firmware. 348 349 There are some documents about partitions in the links below. 350 http://rockchip.wikidot.com/partitions 351 352 -- 353 Simon Glass <sjg (a] chromium.org> 354 24 June 2015 355
README.rockusb
1 Rockusb (Rockchip USB protocol) 2 ===================================================== 3 4 Overview 5 -------- 6 7 Rockusb protocol is widely used by Rockchip SoC based devices. It can 8 read/write info, image to/from devices. This document briefly describes how to 9 use Rockusb for upgrading firmware (e.g. kernel, u-boot, rootfs, etc.). 10 11 Tools 12 -------- 13 There are many tools can support Rockusb protocol. rkdeveloptool 14 (https://github.com/rockchip-linux/rkdeveloptool) is open source, 15 It is maintained by Rockchip. People don't want to build from source 16 can download from here 17 (https://github.com/rockchip-linux/rkbin/blob/master/tools/rkdeveloptool) 18 19 Usage 20 -------- 21 The Usage of Rockusb command is: 22 23 rockusb <USB_controller> <devtype> <dev[:part]> 24 25 e.g. rockusb 0 mmc 0 26 27 On your U-Boot console, type this command to enter rockusb mode. 28 On your host PC. use lsusb command. you should see a usb device 29 using 0x2207 as its USB verdor id. 30 31 for more detail about the rkdeveloptool. please read the usage. 32 33 rkdeveloptool -h 34 35 use rkdeveloptool wl command to write lba. BeginSec is the lba on device 36 you want to write. 37 38 sudo rkdeveloptool wl <BeginSec> <File> 39 40 to flash U-Boot image use below command. U-Boot binary is made by mkimage. 41 see doc/README.rockchip for more detail about how to get U-Boot binary. 42 43 sudo rkdeveloptool wl 64 <U-Boot binary> 44 45 There are plenty of Rockusb command. but wl(write lba) and 46 rd(reboot) command. These two command can let people flash 47 image to device. 48 49 To do 50 ----- 51 * Fully support Rockusb protocol 52
README.s5pc1xx
1 2 Summary 3 ======= 4 5 This README is about U-Boot support for SAMSUNG's ARM Cortex-A8 based S5PC1xx 6 family of SoCs (S5PC100 [1] and S5PC110). 7 8 Currently the following board is supported: 9 10 * SMDKC100 [2] 11 12 Toolchain 13 ========= 14 15 While ARM Cortex-A8 support ARM v7 instruction set (-march=armv7a) we compile 16 with -march=armv5 to allow more compilers to work. For U-Boot code this has 17 no performance impact. 18 19 Build 20 ===== 21 22 * SMDKC100 23 24 make smdkc100_config 25 make 26 27 28 Interfaces 29 ========== 30 31 cpu 32 33 To check SoC: 34 35 if (cpu_is_s5pc100()) 36 printf("cpu is s5pc100\n"); 37 38 or 39 40 if (cpu_is_s5pc110()) 41 printf("cpu is s5pc110\n"); 42 43 gpio 44 45 struct s5pc100_gpio *gpio = (struct s5pc100_gpio*)S5PC100_GPIO_BASE; 46 47 /* GPA[0] pin set to irq */ 48 gpio_cfg_pin(&gpio->gpio_a, 0, GPIO_IRQ); 49 50 /* GPA[0] pin set to input */ 51 gpio_direction_input(&gpio->gpio_a, 0); 52 53 /* GPA[0] pin set to output/high */ 54 gpio_direction_output(&gpio->gpio_a, 0, 1); 55 56 /* GPA[0] value set to low */ 57 gpio_set_value(&gpio->gpio_a, 0, 0); 58 59 /* get GPA[0] value */ 60 value = gpio_get_value(&gpio->gpio_a, 0); 61 62 Links 63 ===== 64 65 [1] S5PC100: 66 67 http://www.samsung.com/global/business/semiconductor/productInfo.do? 68 fmly_id=229&partnum=S5PC100 69 70 [2] SMDKC100: 71 72 http://meritech.co.kr/eng/products/product_view.php?num=28 73
README.sata
1 1. SATA usage in U-Boot 2 3 There are two ways to operate the hard disk 4 5 * Read/write raw blocks from/to SATA hard disk 6 * ext2load to read a file from ext2 file system 7 8 1.0 How to read the SATA hard disk's information? 9 10 => sata info 11 12 SATA device 0: Model: ST3320620AS Firm: 3.AAD Ser#: 4QF01ZTN 13 Type: Hard Disk 14 Supports 48-bit addressing 15 Capacity: 305245.3 MB = 298.0 GB (625142448 x 512) 16 17 1.1 How to raw write the kernel, file system, dtb to a SATA hard disk? 18 19 Notes: Hard disk sectors are normally 512 bytes, so 20 0x1000 sectors = 2 MBytes 21 22 write kernel 23 => tftp 40000 /tftpboot/uImage.837x 24 => sata write 40000 0 2000 25 26 write ramdisk 27 => tftp 40000 /tftpboot/ramdisk.837x 28 => sata write 40000 2000 8000 29 30 write dtb 31 => tftp 40000 /tftpboot/mpc837xemds.dtb 32 => sata write 40000 a000 1000 33 34 1.2 How to raw read the kernel, file system, dtb from a SATA hard disk? 35 36 load kernel 37 => sata read 200000 0 2000 38 39 load ramdisk 40 => sata read 1000000 2000 8000 41 42 load dtb 43 => sata read 2000000 a000 1000 44 45 boot 46 => bootm 200000 1000000 2000000 47 48 1.3 How to load an image from an ext2 file system in U-Boot? 49 50 U-Boot doesn't support writing to an ext2 file system, so the 51 files must be written by other means (e.g. linux). 52 53 => ext2ls sata 0:1 / 54 <DIR> 4096 . 55 <DIR> 4096 .. 56 <DIR> 16384 lost+found 57 1352023 uImage.837x 58 3646377 ramdisk.837x 59 12288 mpc837xemds.dtb 60 12 hello.txt 61 62 => ext2load sata 0:1 200000 /uImage.837x 63 64 => ext2load sata 0:1 1000000 /ramdisk.837x 65 66 => ext2load sata 0:1 2000000 /mpc837xemds.dtb 67 68 => bootm 200000 1000000 2000000 69
README.sched
1 Notes on the scheduler in sched.c: 2 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3 4 'sched.c' provides an very simplistic multi-threading scheduler. 5 See the example, function 'sched(...)', in the same file for its 6 API usage. 7 8 Until an exhaustive testing can be done, the implementation cannot 9 qualify as that of production quality. It works with the example 10 in 'sched.c', it may or may not work in other cases. 11 12 13 Limitations: 14 ~~~~~~~~~~~~ 15 16 - There are NO primitives for thread synchronization (locking, 17 notify etc). 18 19 - Only the GPRs and FPRs context is saved during a thread context 20 switch. Other registers on the PowerPC processor (60x, 7xx, 7xxx 21 etc) are NOT saved. 22 23 - The scheduler is NOT transparent to the user. The user 24 applications must invoke thread_yield() to allow other threads to 25 scheduler. 26 27 - There are NO priorities, and the scheduling policy is round-robin 28 based. 29 30 - There are NO capabilities to collect thread CPU usage, scheduler 31 stats, thread status etc. 32 33 - The semantics are somewhat based on those of pthreads, but NOT 34 the same. 35 36 - Only seven threads are allowed. These can be easily increased by 37 changing "#define MAX_THREADS" depending on the available memory. 38 39 - The stack size of each thread is 8KBytes. This can be easily 40 increased depending on the requirement and the available memory, 41 by increasing "#define STK_SIZE". 42 43 - Only one master/parent thread is allowed, and it cannot be 44 stopped or deleted. Any given thread is NOT allowed to stop or 45 delete itself. 46 47 - There NOT enough safety checks as are probably in the other 48 threads implementations. 49 50 - There is no parent-child relationship between threads. Only one 51 thread may thread_join, preferably the master/parent thread. 52 53 (C) 2003 Arun Dharankar <ADharankar (a] ATTBI.Com> 54
README.scrapyard
1 Over time, support for more and more boards gets added to U-Boot - 2 while other board support code dies a silent death caused by 3 negligence in combination with ordinary bitrot. Sometimes this goes 4 by unnoticed, but often build errors will result. If nobody cares any 5 more to resolve such problems, then the code is really dead and will 6 be removed from the U-Boot source tree. The remainders rest in peace 7 in the imperishable depths of the git history. This document tries to 8 maintain a list of such former fellows, so archaeologists can check 9 easily if there is something they might want to dig for... 10 The list should be sorted in reverse chronological order. 11 12 13 Board Arch CPU Commit Removed Last known maintainer/contact 14 ================================================================================================= 15 ocotea powerpc ppc4xx 29155e73 2015-10-27 Stefan Roese <sr (a] denx.de> 16 taishan powerpc ppc4xx bb5553c6 2015-10-27 Stefan Roese <sr (a] denx.de> 17 ebony powerpc ppc4xx 9d9e2f5d 2015-10-27 Stefan Roese <sr (a] denx.de> 18 taihu powerpc ppc4xx 123b6cd7 2015-10-27 John Otken <jotken (a] softadvances.com> 19 lcd4_lwmon5 powerpc ppc4xx b6b5e394 2015-10-02 Stefan Roese <sr (a] denx.de> 20 da830evm arm arm926ejs d7e8b2b9 2015-09-12 Nick Thompson <nick.thompson (a] gefanuc.com> 21 wireless_space arm arm926ejs b352182a 2015-09-12 Albert ARIBAUD <albert.u.boot (a] aribaud.net> 22 stxgp3 powerpc mpc85xx 2ec69b88 2015-09-02 Dan Malek <dan (a] embeddedalley.com> 23 stxssa powerpc mpc85xx 2ec69b88 2015-09-02 Dan Malek <dan (a] embeddedalley.com> 24 cmi_mpc5xx powerpc mpc5xx 972f5320 2015-09-02 25 zeus powerpc ppc4xx eb5d1dc7 2015-09-02 Stefan Roese <sr (a] denx.de> 26 sbc405 powerpc ppc4xx 0e030593 2015-09-02 27 pcs440ep powerpc ppc4xx 242836a8 2015-09-02 Stefan Roese <sr (a] denx.de> 28 p3p440 powerpc ppc4xx c6999e5f 2015-09-02 Stefan Roese <sr (a] denx.de> 29 csb272/csb472 powerpc ppc4xx 54a3f260 2015-09-02 Tolunay Orkun <torkun (a] nextio.com> 30 alpr powerpc ppc4xx 0d2fc811 2015-09-02 Stefan Roese <sr (a] denx.de> 31 balloon3 arm pxa 679d4456 2015-08-30 Marek Vasut <marex (a] denx.de> 32 cpu9260_128M arm arm926ejs af7f884b 2015-08-30 Eric Benard <eric (a] eukrea.com> 33 cpu9260 arm arm926ejs af7f884b 2015-08-30 Eric Benard <eric (a] eukrea.com> 34 cpu9260_nand_128M arm arm926ejs af7f884b 2015-08-30 Eric Benard <eric (a] eukrea.com> 35 cpu9260_nand arm arm926ejs af7f884b 2015-08-30 Eric Benard <eric (a] eukrea.com> 36 cpu9G20_128M arm arm926ejs af7f884b 2015-08-30 Eric Benard <eric (a] eukrea.com> 37 cpu9G20 arm arm926ejs af7f884b 2015-08-30 Eric Benard <eric (a] eukrea.com> 38 cpuat91 arm arm920t af7f884b 2015-08-30 Eric Benard <eric (a] eukrea.com> 39 cpuat91_ram arm arm920t af7f884b 2015-08-30 Eric Benard <eric (a] eukrea.com> 40 davinci_dm355evm arm arm926ejs 6761946f 2015-08-30 41 davinci_dm355leopard arm arm926ejs 6761946f 2015-08-30 42 davinci_dm365evm arm arm926ejs 6761946f 2015-08-30 43 davinci_dm6467evm arm arm926ejs 6761946f 2015-08-30 44 davinci_dm6467Tevm arm arm926ejs 6761946f 2015-08-30 45 davinci_dvevm arm arm926ejs 6761946f 2015-08-30 46 davinci_schmoogie arm arm926ejs 6761946f 2015-08-30 47 davinci_sffsdr arm arm926ejs 6761946f 2015-08-30 48 davinci_sonata arm arm926ejs 6761946f 2015-08-30 49 dig297 arm armv7 5ff33d04 2015-08-30 Luca Ceresoli <luca.ceresoli (a] comelit.it> 50 ea20 arm arm926ejs 6761946f 2015-08-30 51 eb_cpux9k2 arm arm920t 5522f12b 2015-08-30 Jens Scharsig <esw (a] bus-elektronik.de> 52 eb_cpux9k2_ram arm arm920t 5522f12b 2015-08-30 Jens Scharsig <esw (a] bus-elektronik.de> 53 enbw_cmc arm arm926ejs a6f7f787 2015-08-30 Heiko Schocher <hs (a] denx.de> 54 ima3-mx53 arm armv7 3eb8f58d 2015-08-30 55 imx27lite arm arm926ejs bc0840bc 2015-08-30 Wolfgang Denk <wd (a] denx.de> 56 imx31_litekit arm arm1136 36d14178 2015-08-30 57 jornada arm sa1100 df0b116d 2015-08-30 Kristoffer Ericson <kristoffer.ericson (a] gmail.com> 58 lp8x4x arm pxa 9f840b8d 2015-08-30 Sergey Yanovich <ynvich (a] gmail.com> 59 magnesium arm arm926ejs bc0840bc 2015-08-30 Heiko Schocher <hs (a] denx.de> 60 mv88f6281gtw_ge arm arm926ejs 7cd768cf 2015-08-30 Prafulla Wadaskar <prafulla (a] marvell.com> 61 mx51_efikamx arm armv7 b6073fd2 2015-08-30 62 mx51_efikasb arm armv7 b6073fd2 2015-08-30 63 nhk8815 arm arm926ejs 0abdd9d0 2015-08-30 Nomadik Linux Team <STN_WMM_nomadik_linux (a] list.st.com> 64 nhk8815_onenand arm arm926ejs 0abdd9d0 2015-08-30 Nomadik Linux Team <STN_WMM_nomadik_linux (a] list.st.com> 65 omap3_mvblx arm armv7 8dc372f9 2015-08-30 Michael Jones <michael.jones (a] matrix-vision.de> 66 omap3_sdp3430 arm armv7 93b25c08 2015-08-30 Nishanth Menon <nm (a] ti.com> 67 otc570 arm arm926ejs 819216dd 2015-08-30 Daniel Gorsulowski <daniel.gorsulowski (a] esd.eu> 68 otc570_dataflash arm arm926ejs 819216dd 2015-08-30 Daniel Gorsulowski <daniel.gorsulowski (a] esd.eu> 69 palmld arm pxa 35782e9c 2015-08-30 Marek Vasut <marex (a] denx.de> 70 palmtc arm pxa 8896325d 2015-08-30 Marek Vasut <marex (a] denx.de> 71 palmtreo680 arm pxa ad4f54ea 2015-08-30 Mike Dunn <mikedunn (a] newsguy.com> 72 polaris arm pxa f6eac00a 2015-08-30 Stefano Babic <sbabic (a] denx.de> 73 portuxg20 arm arm926ejs 79d19734 2015-08-30 Markus Hubig <mhubig (a] imko.de> 74 pxa255_idp arm pxa 49d8899b 2015-08-30 Marek Vasut <marex (a] denx.de> 75 qong arm arm1136 daf77086 2015-08-30 Wolfgang Denk <wd (a] denx.de> 76 rd6281a arm arm926ejs 47b87d2e 2015-08-30 Prafulla Wadaskar <prafulla (a] marvell.com> 77 scb9328 arm arm920t 7650beb7 2015-08-30 Torsten Koschorrek <koschorrek (a] synertronixx.de> 78 snowball arm armv7 7495e41b 2015-08-30 Mathieu Poirier <mathieu.poirier (a] linaro.org> 79 stamp9g20 arm arm926ejs 79d19734 2015-08-30 Markus Hubig <mhubig (a] imko.de> 80 tk71 arm arm926ejs f73db66d 2015-08-30 81 trizepsiv arm pxa f6eac00a 2015-08-30 Stefano Babic <sbabic (a] denx.de> 82 tt01 arm arm1136 0c81f37d 2015-08-30 Helmut Raiger <helmut.raiger (a] hale.at> 83 tx25 arm arm926ejs b9599dd8 2015-08-30 John Rigby <jcrigby (a] gmail.com> 84 u8500_href arm armv7 7495e41b 2015-08-30 85 versatileab arm arm926ejs b928e658 2015-08-30 86 versatilepb arm arm926ejs b928e658 2015-08-30 87 versatileqemu arm arm926ejs b928e658 2015-08-30 88 vision2 arm armv7 bee2b99d 2015-08-30 Stefano Babic <sbabic (a] denx.de> 89 vl_ma2sc arm arm926ejs 6e830dfc 2015-08-30 Jens Scharsig <esw (a] bus-elektronik.de> 90 vl_ma2sc_ram arm arm926ejs 6e830dfc 2015-08-30 Jens Scharsig <esw (a] bus-elektronik.de> 91 vpac270_nor_128 arm pxa 452ef830 2015-08-30 Marek Vasut <marex (a] denx.de> 92 vpac270_nor_256 arm pxa 452ef830 2015-08-30 Marek Vasut <marex (a] denx.de> 93 vpac270_ond_256 arm pxa 452ef830 2015-08-30 Marek Vasut <marex (a] denx.de> 94 xaeniax arm pxa 1c87dd76 2015-08-30 95 zipitz2 arm pxa 49d8899b 2015-08-30 Cliff Brake <cliff.brake (a] gmail.com> 96 cam_enc_4xx arm arm926ejs 8d775763 2015-08-20 Heiko Schocher <hs (a] denx.de> 97 afeb9260 arm arm926ejs f6b42c14 2015-05-13 Sergey Lapin <slapin (a] ossfans.org> 98 tny_a9260 arm arm926ejs f6b42c14 2015-05-13 Albin Tonnerre <albin.tonnerre (a] free-electrons.com> 99 sbc35_a9g20 arm arm926ejs f6b42c14 2015-05-13 Albin Tonnerre <albin.tonnerre (a] free-electrons.com> 100 sc3 powerpc ppc4xx 27e72156 2015-05-10 Heiko Schocher <hs (a] denx.de> 101 T4240EMU powerpc mpc85xx 7fc63cca 2015-05-05 York Sun <yorksun (a] freescale.com> 102 korat powerpc ppc4xx 5043045d 2015-03-17 Larry Johnson <lrj (a] acm.org> 103 W7OLMC powerpc ppc4xx 6beecd5d 2015-03-17 Erik Theisen <etheisen (a] mindspring.com> 104 W7OLMG powerpc ppc4xx 6beecd5d 2015-03-17 Erik Theisen <etheisen (a] mindspring.com> 105 JSE powerpc ppc4xx 2da8137b 2015-03-17 Stephen Williams <steve (a] icarus.com> 106 hawkboard arm arm926ejs cb957cda 2015-02-24 Syed Mohammed Khasim <sm.khasim (a] gmail.com>:Sughosh Ganu <urwithsughosh (a] gmail.com> 107 tnetv107x arm arm1176 50b82c4b 2015-02-24 Chan-Taek Park <c-park (a] ti.com> 108 a320evb arm arm920t 29fc6f24 2015-02-24 Po-Yu Chuang <ratbert (a] faraday-tech.com> 109 cm4008 arm arm920t a2f39e83 2015-02-24 Greg Ungerer <greg.ungerer (a] opengear.com> 110 cm41xx arm arm920t a2f39e83 2015-02-24 111 dkb arm arm926ejs 346cfba4 2015-02-24 Lei Wen <leiwen (a] marvell.com> 112 jadecpu arm arm926ejs 41fbbbbc 2015-02-24 Matthias Weisser <weisserm (a] arcor.de> 113 CATcenter powerpc ppc4xx 5344cc1a 2015-01-23 114 PPChameleonEVB powerpc ppc4xx 5344cc1a 2015-01-23 Andrea "llandre" Marson <andrea.marson (a] dave-tech.it> 115 P2020DS powerpc mpc85xx 168dcc6c 2015-01-23 116 P2020COME powerpc mpc85xx 89123536 2015-01-23 Ira W. Snyder <iws (a] ovro.caltech.edu> 117 P2020RDB powerpc mpc85xx 743d4815 2015-01-23 Poonam Aggrwal <poonam.aggrwal (a] freescale.com> 118 P2010RDB powerpc mpc85xx 743d4815 2015-01-23 119 P1020RDB powerpc mpc85xx 743d4815 2015-01-23 120 P1011RDB powerpc mpc85xx 743d4815 2015-01-23 121 MPC8360EMDS powerpc mpc83xx 8d1e3cb1 2015-01-23 Dave Liu <daveliu (a] freescale.com> 122 MPC8360ERDK powerpc mpc83xx 8d1e3cb1 2015-01-23 Anton Vorontsov <avorontsov (a] ru.mvista.com> 123 P3G4 powerpc 74xx_7xx d928664f 2015-01-16 Wolfgang Denk <wd (a] denx.de> 124 ZUMA powerpc 74xx_7xx d928664f 2015-01-16 Nye Liu <nyet (a] zumanetworks.com> 125 ppmc7xx powerpc 74xx_7xx d928664f 2015-01-16 126 ELPPC powerpc 74xx_7xx d928664f 2015-01-16 127 mpc7448hpc2 powerpc 74xx_7xx d928664f 2015-01-16 Roy Zang <tie-fei.zang (a] freescale.com> 128 CPCI405 ppc4xx 405gp 5f1459dc 2015-01-13 Matthias Fuchs <matthias.fuchs (a] esd.eu> 129 CPCI405DT ppc4xx 405gpr 5f1459dc 2015-01-13 Matthias Fuchs <matthias.fuchs (a] esd.eu> 130 CPCI405AB ppc4xx 405gpr 5f1459dc 2015-01-13 Matthias Fuchs <matthias.fuchs (a] esd.eu> 131 G2000 ppc4xx 405ep 5f8f6294 2015-01-13 Matthias Fuchs <matthias.fuchs (a] esd.eu> 132 WUH405 ppc4xx 405ep fc88a5bf 2015-01-13 Matthias Fuchs <matthias.fuchs (a] esd.eu> 133 VOH405 ppc4xx 405ep 807db88b 2015-01-13 Matthias Fuchs <matthias.fuchs (a] esd.eu> 134 PMC405 ppc4xx 405gp d5263304 2015-01-13 Matthias Fuchs <matthias.fuchs (a] esd.eu> 135 PCI405 ppc4xx 405gp dbe7bb0d 2015-01-13 Matthias Fuchs <matthias.fuchs (a] esd.eu> 136 OCRTC ppc4xx 405gpr cc6e715f 2015-01-13 Matthias Fuchs <matthias.fuchs (a] esd.eu> 137 HUB405 ppc4xx 405ep e434d5d7 2015-01-13 Matthias Fuchs <matthias.fuchs (a] esd.eu> 138 HH405 ppc4xx 405ep 843125da 2015-01-13 Matthias Fuchs <matthias.fuchs (a] esd.eu> 139 DU440 ppc4xx 440epx 7ac9d47a 2015-01-13 Matthias Fuchs <matthias.fuchs (a] esd.eu> 140 DU405 ppc4xx 405gpr bc114076 2015-01-13 Matthias Fuchs <matthias.fuchs (a] esd.eu> 141 DP405 ppc4xx 405ep 9a4018e0 2015-01-13 Matthias Fuchs <matthias.fuchs (a] esd.eu> 142 CPCIISER4 ppc4xx 405gp 37057260 2015-01-13 Matthias Fuchs <matthias.fuchs (a] esd.eu> 143 CMS700 ppc4xx 405ep 2404124c 2015-01-13 Matthias Fuchs <matthias.fuchs (a] esd.eu> 144 ASH405 ppc4xx 405ep b5e7c84f 2015-01-13 Matthias Fuchs <matthias.fuchs (a] esd.eu> 145 AR405 ppc4xx 405gpr 61b57c4a 2015-01-13 Matthias Fuchs <matthias.fuchs (a] esd.eu> 146 APC405 ppc4xx 405gpr 2b8a04e5 2015-01-13 Matthias Fuchs <matthias.fuchs (a] esd.eu> 147 TASREG m68k mcf52x2 cbdc662a 2015-01-13 Matthias Fuchs <matthias.fuchs (a] esd.eu> 148 A3000 powerpc mpc824x d622ac39 2015-01-05 149 CPC45 powerpc mpc824x d622ac39 2015-01-05 Josef Wagner <Wagner (a] Microsys.de> 150 CU824 powerpc mpc824x d622ac39 2015-01-05 Wolfgang Denk <wd (a] denx.de> 151 eXalion powerpc mpc824x d622ac39 2015-01-05 Torsten Demke <torsten.demke (a] fci.com> 152 MVBLUE powerpc mpc824x d622ac39 2015-01-05 153 MUSENKI powerpc mpc824x d622ac39 2015-01-05 Jim Thompson <jim (a] musenki.com> 154 Sandpoint8240 powerpc mpc824x d622ac39 2015-01-05 Wolfgang Denk <wd (a] denx.de> 155 Sandpoint8245 powerpc mpc824x d622ac39 2015-01-05 Jim Thompson <jim (a] musenki.com> 156 utx8245 powerpc mpc824x d622ac39 2015-01-05 Greg Allen <gallen (a] arlut.utexas.edu> 157 atc powerpc mpc8260 9067b300 2015-01-05 Wolfgang Denk <wd (a] denx.de> 158 CPU86 powerpc mpc8260 f7e1af86 2015-01-05 Wolfgang Denk <wd (a] denx.de> 159 CPU87 powerpc mpc8260 f7e1af86 2015-01-05 160 ep82xxm powerpc mpc8260 e2b19629 2015-01-05 161 gw8260 powerpc mpc8260 8eecbaf3 2015-01-05 Oliver Brown <obrown (a] adventnetworks.com> 162 IPHASE4539 powerpc mpc8260 87882f57 2015-01-05 Wolfgang Grandegger <wg (a] denx.de> 163 muas3001 powerpc mpc8260 d2fd1d66 2015-01-05 Heiko Schocher <hs (a] denx.de> 164 PM825 powerpc mpc8260 dc0b2fb4 2015-01-05 Wolfgang Denk <wd (a] denx.de> 165 PM826 powerpc mpc8260 dc0b2fb4 2015-01-05 Wolfgang Denk <wd (a] denx.de> 166 PM828 powerpc mpc8260 dc0b2fb4 2015-01-05 167 MPC8266ADS powerpc mpc8260 b3a2bbe1 2015-01-05 Rune Torgersen <runet (a] innovsys.com> 168 VoVPN-GW powerpc mpc8260 cc90905f 2015-01-05 169 ep8260 powerpc mpc8260 4ad015ba 2015-01-05 Frank Panno <fpanno (a] delphintech.com> 170 ppmc8260 powerpc mpc8260 793116d2 2015-01-05 Brad Kemp <Brad.Kemp (a] seranoa.com> 171 sacsng powerpc mpc8260 b35c0ad6 2015-01-05 Jerry Van Baren <gerald.vanbaren (a] smiths-aerospace.com> 172 cogent_mpc8260 powerpc mpc8260 d19f6a60 2015-01-05 Murray Jensen <Murray.Jensen (a] csiro.au> 173 cogent_8xx powerpc mpc8xx d19f6a60 2015-01-05 Murray Jensen <Murray.Jensen (a] csiro.au> 174 ESTEEM192E powerpc mpc8xx af0e3514 2015-01-05 Conn Clark <clark (a] esteem.com> 175 IP860 powerpc mpc8xx 5ec71100 2015-01-05 Wolfgang Denk <wd (a] denx.de> 176 IVML24 powerpc mpc8xx ca620cd1 2015-01-05 Wolfgang Denk <wd (a] denx.de> 177 IVMS8 powerpc mpc8xx ca620cd1 2015-01-05 Wolfgang Denk <wd (a] denx.de> 178 lwmon powerpc mpc8xx acc2372d 2015-01-05 Wolfgang Denk <wd (a] denx.de> 179 NETVIA powerpc mpc8xx f017cd7f 2015-01-05 Pantelis Antoniou <panto (a] intracom.gr> 180 R360MPI powerpc mpc8xx 79cbecb8 2015-01-05 Wolfgang Denk <wd (a] denx.de> 181 RRvision powerpc mpc8xx 8737fc75 2015-01-05 Wolfgang Denk <wd (a] denx.de> 182 SPD823TS powerpc mpc8xx 72ba368f 2015-01-05 Wolfgang Denk <wd (a] denx.de> 183 KUP4K powerpc mpc8xx 4317d070 2015-01-05 Klaus Heydeck <heydeck (a] kieback-peter.de> 184 KUP4X powerpc mpc8xx 4317d070 2015-01-05 Klaus Heydeck <heydeck (a] kieback-peter.de> 185 ELPT860 powerpc mpc8xx 3c5b20f1 2015-01-05 The LEOX team <team (a] leox.org> 186 uc100 powerpc mpc8xx ceaf499b 2015-01-05 Stefan Roese <sr (a] denx.de> 187 FPS850L powerpc mpc8xx 5d2a5ef7 2015-01-05 Wolfgang Denk <wd (a] denx.de> 188 FPS860L powerpc mpc8xx 5d2a5ef7 2015-01-05 Wolfgang Denk <wd (a] denx.de> 189 NSCU powerpc mpc8xx 5d2a5ef7 2015-01-05 190 SM850 powerpc mpc8xx 5d2a5ef7 2015-01-05 Wolfgang Denk <wd (a] denx.de> 191 TK885D powerpc mpc8xx 5d2a5ef7 2015-01-05 192 virtlab2 powerpc mpc8xx 5d2a5ef7 2015-01-05 Wolfgang Denk <wd (a] denx.de> 193 hermes powerpc mpc8xx 36da51e 2014-12-08 Wolfgang Denk <wd (a] denx.de> 194 TOP860 powerpc mpc860 d58a945 2014-10-28 Reinhard Meyer <reinhard.meyer (a] emk-elektronik.de> 195 TOP9000 arm at91sam9xeXXX d58a945 2014-10-28 Reinhard Meyer <reinhard.meyer (a] emk-elektronik.de> 196 TQM8272 powerpc mpc8260 f06f9a1 2014-10-27 Wolfgang Denk <wd (a] denx.de> 197 TQM8260 powerpc mpc8260 ccc1950 2014-10-27 Wolfgang Denk <wd (a] denx.de> 198 IDS8247 powerpc mpc8260 6afb357 2014-10-27 Heiko Schocher <hs (a] denx.de> 199 HWW1U1A powerpc mpc85xx 4109cb0 2014-10-27 Kyle Moffett <Kyle.D.Moffett (a] boeing.com> 200 hymod powerpc mpc8260 5038d7f 2014-10-27 Murray Jensen <Murray.Jensen (a] csiro.au> 201 MHPC powerpc mpc8xx 1655f9f 2014-10-27 Frank Gottschling <fgottschling (a] eltec.de> 202 ICU862 powerpc mpc8xx 4af5f0f 2014-10-27 Wolfgang Denk <wd (a] denx.de> 203 CPCI750 powerpc 74xx_7xx 03b0040 2014-10-27 Reinhard Arlt <reinhard.arlt (a] esd-electronics.com> 204 DB64360 powerpc 74xx_7xx 03b0040 2014-10-27 205 DB64460 powerpc 74xx_7xx 03b0040 2014-10-27 206 p3m750 powerpc 74xx_7xx 03b0040 2014-10-27 Stefan Roese <sr (a] denx.de> 207 p3m7448 powerpc 74xx_7xx 03b0040 2014-10-27 Stefan Roese <sr (a] denx.de> 208 MERGERBOX powerpc mpc83xx e7a5656 2014-10-10 Andre Schwarz <andre.schwarz (a] matrix-vision.de> 209 MVBLM7 powerpc mpc83xx e7a5656 2014-10-10 Andre Schwarz <andre.schwarz (a] matrix-vision.de> 210 bluestone powerpc ppc4xx 9ed3246 2014-10-10 Tirumala Marri <tmarri (a] apm.com> 211 CRAYL1 powerpc ppc4xx 1521cdc 2014-10-10 David Updegraff <dave (a] cray.com> 212 KAREF powerpc ppc4xx dc9617e 2014-10-10 Travis Sawyer <travis.sawyer (a] sandburst.com> 213 METROBOX powerpc ppc4xx dc9617e 2014-10-10 Travis Sawyer <travis.sawyer (a] sandburst.com> 214 PK1C20 nios2 - 70fbc461 2014-08-24 Scott McNutt <smcnutt (a] psyent.com> 215 PCI5441 nios2 - 70fbc461 2014-08-24 Scott McNutt <smcnutt (a] psyent.com> 216 flagadm powerpc mpc8xx aec6f8c5 2014-08-22 Kri Davsson <kd (a] flaga.is> 217 gen860t powerpc mpc8xx 6bde1ec1 2014-08-22 Keith Outwater <Keith_Outwater (a] mvis.com> 218 sixnet powerpc mpc8xx 4723ce49 2014-08-22 Dave Ellis <DGE (a] sixnetio.com> 219 svm_sc8xx powerpc mpc8xx d1a4aafd 2014-08-22 John Zhan <zhanz (a] sinovee.com> 220 stxxtc powerpc mpc8xx 0ace4d9d 2014-08-22 Dan Malek <dan (a] embeddedalley.com> 221 omap5912osk arm arm926ejs 62d636aa 2014-08-22 Rishi Bhattacharya <rishi (a] ti.com> 222 p1023rds powerpc mpc85xx d0bc5140 2014-07-22 Roy Zang <tie-fei.zang (a] freescale.com> 223 spc1920 powerpc mpc8xx 98ad54be 2014-07-07 224 v37 powerpc mpc8xx b8c1438a 2014-07-07 225 fads powerpc mpc8xx 03f9d7d1 2014-07-07 226 netphone powerpc mpc8xx c51c1c9a 2014-07-07 227 netta2 powerpc mpc8xx c51c1c9a 2014-07-07 228 netta powerpc mpc8xx c51c1c9a 2014-07-07 229 rbc823 powerpc mpc8xx c750b9c0 2014-07-07 230 quantum powerpc mpc8xx 0657e46e 2014-07-07 231 RPXlite_dw powerpc mpc8xx 0657e46e 2014-07-07 232 qs850 powerpc mpc8xx dab0f762 2014-07-07 233 qs860t powerpc mpc8xx dab0f762 2014-07-07 234 simpc8313 powerpc mpc83xx 7445207f 2014-06-05 Ron Madrid <info (a] sheldoninst.com> 235 hidden_dragon powerpc mpc824x 3fe1a854 2014-05-30 Yusdi Santoso <yusdi_santoso (a] adaptec.com> 236 debris powerpc mpc824x 7edb1f7b 2014-05-30 Sangmoon Kim <dogoil (a] etinsys.com> 237 kvme080 powerpc mpc824x 2868f862 2014-05-30 Sangmoon Kim <dogoil (a] etinsys.com> 238 ep8248 powerpc mpc8260 49ad566d 2014-05-30 Yuli Barcohen <yuli (a] arabellasw.com> 239 ispan powerpc mpc8260 80bae39a 2014-05-30 Yuli Barcohen <yuli (a] arabellasw.com> 240 rattler powerpc mpc8260 d0664db4 2014-05-30 Yuli Barcohen <yuli (a] arabellasw.com> 241 zpc1900 powerpc mpc8260 6f80bb48 2014-05-30 Yuli Barcohen <yuli (a] arabellasw.com> 242 mpc8260ads powerpc mpc8260 facb6725 2014-05-30 Yuli Barcohen <yuli (a] arabellasw.com> 243 adder powerpc mpc8xx 373a9788 2014-05-30 Yuli Barcohen <yuli (a] arabellasw.com> 244 quad100hd powerpc ppc405ep 3569571d 2014-05-30 Gary Jennejohn <gljennjohn (a] googlemail.com> 245 incaip mips mips32 538cf92c 2014-04-20 Wolfgang Denk <wd (a] denx.de> 246 lubbock arm pxa 36bf57b 2014-04-18 Kyle Harris <kharris (a] nexus-tech.net> 247 EVB64260 powerpc mpc824x bb3aef9 2014-04-18 248 MOUSSE powerpc mpc824x 03f2ecc 2014-04-18 249 rsdproto powerpc mpc8260 8b043e6 2014-04-18 250 RPXsuper powerpc mpc8260 0ebf5f5 2014-04-18 251 RPXClassic powerpc mpc8xx 4fb3925 2014-04-18 252 RPXlite powerpc mpc8xx 4fb3925 2014-04-18 253 FADS powerpc mpc8xx aa6e1e4 2014-04-18 254 genietv powerpc mpc8xx b8a49bd 2014-04-18 255 mbx8xx powerpc mpc8xx d6b11fd 2014-04-18 256 nx823 powerpc mpc8xx a146e8b 2014-04-18 257 idmr m68k mcf52x2 ba650e9b 2014-01-28 258 M5271EVB m68k mcf52x2 ba650e9b 2014-01-28 259 dvl_host arm ixp e317de6b 2014-01-28 Michael Schwingen <michael (a] schwingen.org> 260 actux4 arm ixp 6ff7aafa 2014-01-28 Michael Schwingen <michael (a] schwingen.org> 261 actux3 arm ixp 38da33f3 2014-01-28 Michael Schwingen <michael (a] schwingen.org> 262 actux2 arm ixp 13e0ee7f 2014-01-28 Michael Schwingen <michael (a] schwingen.org> 263 actux1 arm ixp 373ee048 2014-01-28 Michael Schwingen <michael (a] schwingen.org> 264 mx1ads arm arm920t e570aca9 2014-01-13 265 mini2440 arm arm920t af5b9b1f 2014-01-13 Gabriel Huau <contact (a] huau-gabriel.fr> 266 omap730p2 arm arm926ejs 79c5c08d 2013-11-11 267 pn62 powerpc mpc824x 649acfe1 2013-11-11 Wolfgang Grandegger <wg (a] grandegger.com> 268 pdnb3 arm ixp 304db0b 2013-09-24 Stefan Roese <sr (a] denx.de> 269 scpu arm ixp 304db0b 2013-09-24 Stefan Roese <sr (a] denx.de> 270 omap1510inn arm arm925t 0610a16 2013-09-23 Kshitij Gupta <kshitij (a] ti.com> 271 CANBT powerpc 405CR fb8f4fd 2013-08-07 Matthias Fuchs <matthias.fuchs (a] esd.eu> 272 omap2420h4 arm omap24xx 7f5eef9 2013-06-04 Richard Woodruff <r-woodruff2 (a] ti.com> 273 Alaska8220 powerpc mpc8220 d6ed322 2013-05-11 274 Yukon8220 powerpc mpc8220 d6ed322 2013-05-11 275 sorcery powerpc mpc8220 d6ed322 2013-05-11 276 smdk6400 arm arm1176 52587f1 2013-04-12 Zhong Hongbo <bocui107 (a] gmail.com> 277 ns9750dev arm arm926ejs 4cfc611 2013-02-28 Markus Pietrek <mpietrek (a] fsforth.de> 278 eNET x86 x86 7e8c53d 2013-02-14 Graeme Russ <graeme.russ (a] gmail.com> 279 PCIPPC2 powerpc MPC740/MPC750 7c9e89b 2013-02-07 Wolfgang Denk <wd (a] denx.de> 280 PCIPPC6 powerpc MPC740/MPC750 7c9e89b 2013-02-07 Wolfgang Denk <wd (a] denx.de> 281 AMX860 powerpc mpc860 1b0757e 2012-10-28 Wolfgang Denk <wd (a] denx.de> 282 c2mon powerpc mpc855 1b0757e 2012-10-28 Wolfgang Denk <wd (a] denx.de> 283 EP88x powerpc mpc885 1b0757e 2012-10-28 284 ETX094 powerpc mpc850 1b0757e 2012-10-28 Wolfgang Denk <wd (a] denx.de> 285 IAD210 powerpc mpc860 1b0757e 2012-10-28 - 286 LANTEC powerpc mpc850 1b0757e 2012-10-28 Wolfgang Denk <wd (a] denx.de> 287 SCM powerpc mpc8260 1b0757e 2012-10-28 Wolfgang Grandegger <wg (a] denx.de> 288 SX1 arm arm925t 53c4154 2012-10-26 289 TQM85xx powerpc MPC85xx d923a5d 2012-10-04 Stefan Roese <sr (a] denx.de> 290 ADCIOP powerpc ppc4xx 99bcad1 2012-09-19 Matthias Fuchs <matthias.fuchs (a] esd-electronics.com> 291 DASA_SIM powerpc ppc4xx 99bcad1 2012-09-19 Matthias Fuchs <matthias.fuchs (a] esd-electronics.com> 292 apollon arm omap24xx 535c74f 2012-09-18 Kyungmin Park <kyungmin.park (a] samsung.com> 293 tb0229 mips mips32 3f3110d 2011-12-12 294 OXC powerpc MPC8240 309a292 2011-12-07 295 BAB7xx powerpc MPC740/MPC750 c53043b 2011-12-07 Frank Gottschling <fgottschling (a] eltec.de> 296 xm250 arm pxa c477d72 2011-11-25 297 pleb2 arm pxa d299173 2011-11-25 298 cradle arm pxa 00c4aca 2011-11-25 Kyle Harris <kharris (a] nexus-tech.net> 299 cerf250 arm pxa f13eba6 2011-11-25 Prakash Kumar <prakash (a] embedx.com> 300 mpq101 powerpc mpc85xx e877fab 2011-10-23 Alex Dubov <oakad (a] yahoo.com> 301 ixdpg425 arm ixp 0ca8eb7 2011-09-22 Stefan Roese <sr (a] denx.de> 302 ixdp425 arm ixp 0ca8eb7 2011-09-22 Kyle Harris <kharris (a] nexus-tech.net> 303 zylonite arm pxa b66521a 2011-09-05 304 shannon arm sa1100 5df092d 2011-09-05 Rolf Offermanns <rof (a] sysgo.de> 305 modnet50 arm arm720t 9c62815 2011-09-05 Thomas Elste <info (a] elste.org> 306 lpc2292sodimm arm arm720t d1a067a 2011-09-05 307 lart arm sa1100 3d57573 2011-09-05 Alex Zpke <azu (a] sysgo.de> 308 impa7 arm arm720t c1f8750 2011-09-05 Marius Grger <mag (a] sysgo.de> 309 gcplus arm sa1100 2c650e2 2011-09-05 George G. Davis <gdavis (a] mvista.com> 310 evb4510 arm arm720t 26e670e 2011-09-05 Curt Brune <curt (a] cucy.com> 311 ep7312 arm arm720t c8f63b4 2011-09-05 Marius Grger <mag (a] sysgo.de> 312 dnp1110 arm sa1100 fc5e5ce 2011-09-05 Alex Zpke <azu (a] sysgo.de> 313 SMN42 arm arm720t 6aac646 2011-09-05 314 at91rm9200dk arm arm920t 1c85752 2011-07-17 315 m501sk arm arm920t b1a2bd4 2011-07-17 316 kb9202 arm arm920t 5bd3814 2011-07-17 317 csb637 arm arm920t d14af08 2011-07-17 318 cmc_pu2 arm arm920t 37a9b4d 2011-07-17 319 at91cap9adk arm arm926ejs b550834 2011-07-17 Stelian Pop <stelian (a] popies.net> 320 voiceblue arm arm925t 1b793a4 2011-07-17 321 smdk2400 arm arm920t ad218a8 2011-07-17 Gary Jennejohn <garyj (a] denx.de> 322 sbc2410x arm arm920t 1f7f0ed 2011-07-17 323 netstar arm arm925t 6ea2405 2011-07-17 324 mx1fs2 arm arm920t 6962419 2011-07-17 325 lpd7a404 arm lh7a40x 957731e 2011-07-17 326 edb9301 arm arm920t 716f7ad 2011-07-17 327 edb9302 arm arm920t 716f7ad 2011-07-17 328 edb9302a arm arm920t 716f7ad 2011-07-17 329 edb9307 arm arm920t 716f7ad 2011-07-17 330 edb9307a arm arm920t 716f7ad 2011-07-17 331 edb9312 arm arm920t 716f7ad 2011-07-17 332 edb9315 arm arm920t 716f7ad 2011-07-17 333 edb9315a arm arm920t 716f7ad 2011-07-17 334 B2 arm s3c44b0 5dcf536 2011-07-16 Andrea Scian <andrea.scian (a] dave-tech.it> 335 armadillo arm arm720t be28857 2011-07-16 Rowel Atienza <rowel (a] diwalabs.com> 336 assabet arm sa1100 c91e90d 2011-07-16 George G. Davis <gdavis (a] mvista.com> 337 trab arm S3C2400 566e5cf 2011-05-01 Gary Jennejohn <garyj (a] denx.de> 338 mp2usb ARM AT91RM2900 ee986e2 2011-01-25 Eric Bnard <eric (a] eukrea.com> 339 barco powerpc MPC8245 afaa27b 2010-11-23 Marc Leeman <marc.leeman (a] barco.com> 340 ERIC powerpc 405GP d9ba451 2010-11-21 Swen Anderson <sand (a] peppercon.de> 341 VoVPN-GW_100MHz powerpc MPC8260 26fe3d2 2010-10-24 Juergen Selent <j.selent (a] elmeg.de> 342 xsengine ARM PXA2xx 4262a7c 2010-10-20 343 wepep250 ARM PXA2xx 7369478 2010-10-20 Peter Figuli <peposh (a] etc.sk> 344 delta ARM PXA2xx 75e2035 2010-10-20 345 NC650 powerpc MPC852 333d86d 2010-10-19 Wolfgang Denk <wd (a] denx.de> 346 CP850 powerpc MPC852 333d86d 2010-10-19 Wolfgang Denk <wd (a] denx.de> 347 logodl ARM PXA2xx 059e778 2010-10-18 August Hoeraendl <august.hoerandl (a] gmx.at> 348 CCM powerpc MPC860 dff07e1 2010-10-06 Wolfgang Grandegger <wg (a] denx.de> 349 PCU_E powerpc MPC860T 544d97e 2010-10-06 Wolfgang Denk <wd (a] denx.de> 350 HMI10 powerpc MPC823 77efe35 2010-09-19 Wolfgang Denk <wd (a] denx.de> 351 GTH powerpc MPC860 0fe247b 2010-07-17 Thomas Lange <thomas (a] corelatus.se> 352 AmigaOneG3SE powerpc 74xx_7xx 953b7e6 2010-06-23 353 suzaku microblaze - 4f18060 2009-10-03 Yasushi Shoji <yashi (a] atmark-techno.com> 354 XUPV2P microblaze - 8fab49e 2008-12-10 Michal Simek <monstr (a] monstr.eu> 355 MVS1 powerpc MPC823 306620b 2008-08-26 Andre Schwarz <andre.schwarz (a] matrix-vision.de> 356 adsvix ARM PXA27x 7610db1 2008-07-30 Adrian Filipi <adrian.filipi (a] eurotech.com> 357 R5200 ColdFire - 48ead7a 2008-03-31 Zachary P. Landau <zachary.landau (a] labxtechnologies.com> 358 CPCI440 powerpc 440GP b568fd2 2007-12-27 Matthias Fuchs <matthias.fuchs (a] esd-electronics.com> 359
README.sdp
1 ------------- 2 SDP in U-Boot 3 ------------- 4 5 SDP stands for serial download protocol. It is the protocol used in NXP's 6 i.MX SoCs ROM Serial Downloader and provides means to download a program 7 image to the chip over USB and UART serial connection. 8 9 The implementation in U-Boot uses the USB Downloader Gadget (g_dnl) to 10 provide a SDP implementation over USB. This allows to download program 11 images to the target in SPL/U-Boot using the same protocol/tooling the 12 SoC's recovery mechanism is using. 13 14 The SDP protocol over USB is a USB HID class protocol. USB HID class 15 protocols allow to access a USB device without OS specific drivers. The 16 U-Boot implementation has primarly been tested using the open source 17 imx_loader utility (https://github.com/boundarydevices/imx_usb_loader). 18 19 The host side utilities are typically capable to interpret the i.MX 20 specific image header (see doc/README.imximage). There are extensions 21 for imx_loader's imx_usb utility which allow to interpret the U-Boot 22 specific legacy image format (see mkimage(1)). Also the U-Boot side 23 support beside the i.MX specific header the U-Boot legacy header. 24 25 Usage 26 ----- 27 28 This implementation can be started in U-Boot using the sdp command 29 (CONFIG_CMD_USB_SDP) or in SPL if Serial Downloader boot mode has been 30 detected (CONFIG_SPL_USB_SDP_SUPPORT). 31 32 A typical use case is downloading full U-Boot after SPL has been 33 downloaded through the boot ROM's Serial Downloader. Using boot mode 34 detection the SPL will run the SDP implementation automatically in 35 this case: 36 37 # imx_usb SPL 38 39 Targets Serial Console: 40 41 Trying to boot from USB SDP 42 SDP: initialize... 43 SDP: handle requests... 44 45 At this point the SPL reenumerated as a new HID device and emulating 46 the boot ROM's SDP protocol. The USB VID/PID will depend on standard 47 U-Boot configurations CONFIG_G_DNL_(VENDOR|PRODUCT)_NUM. Make sure 48 imx_usb is aware of the USB VID/PID for your device by adding a 49 configuration entry in imx_usb.conf: 50 51 0x1b67:0x4fff, mx6_usb_sdp_spl.conf 52 53 And the device specific configuration file mx6_usb_sdp_spl.conf: 54 55 mx6_spl_sdp 56 hid,uboot_header,1024,0x910000,0x10000000,1G,0x00900000,0x40000 57 58 This allows to download the regular U-Boot with legacy image headers 59 (u-boot.img) using a second invocation of imx_usb: 60 61 # imx_usb u-boot.img 62 63 Furthermore, when U-Boot is running the sdp command can be used to 64 download and run scripts: 65 66 # imx_usb script.scr 67 68 imx_usb configuration files can be also used to download multiple 69 files and of arbitrary types, e.g. 70 71 mx6_usb_sdp_uboot 72 hid,1024,0x10000000,1G,0x00907000,0x31000 73 full.itb:load 0x12100000 74 boot.scr:load 0x12000000,jump 0x12000000 75 76 There is also a batch mode which allows imx_usb to handle multiple 77 consecutive reenumerations by adding multiple VID/PID specifications 78 in imx_usb.conf: 79 80 0x15a2:0x0061, mx6_usb_rom.conf, 0x1b67:0x4fff, mx6_usb_sdp_spl.conf 81 82 In this mode the file to download (imx_usb job) needs to be specified 83 in the configuration files. 84 85 mx6_usb_rom.conf: 86 87 mx6_qsb 88 hid,1024,0x910000,0x10000000,1G,0x00900000,0x40000 89 SPL:jump header2 90 91 mx6_usb_sdp_spl.conf: 92 93 mx6_spl_sdp 94 hid,uboot_header,1024,0x10000000,1G,0x00907000,0x31000 95 u-boot.img:jump header2 96 97 With that SPL and U-Boot can be downloaded with a single invocation 98 of imx_usb without arguments: 99 100 # imx_usb 101
README.semihosting
1 SPDX-License-Identifier: GPL-2.0+ 2 /* 3 * Copyright 2014 Broadcom Corporation. 4 */ 5 6 Semihosting is ARM's way of having a real or virtual target communicate 7 with a host or host debugger for basic operations such as file I/O, 8 console I/O, etc. Please see 9 http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0471c/Bgbjjgij.html for more information. 10 11 For developing on armv8 virtual fastmodel platforms, semihosting is a 12 valuable tool since it allows access to image/configuration files before 13 eMMC or other NV media are available. 14 15 There are two main ARM virtual Fixed Virtual Platform (FVP) models, 16 Versatile Express (VE) FVP and BASE FVP (See 17 http://www.arm.com/products/tools/models/fast-models/foundation-model.php) 18 The initial vexpress64 u-boot board created here runs on the VE virtual 19 platform using the license-free Foundation_v8 simulator. Fortunately, 20 the Foundation_v8 simulator also supports the BASE_FVP model which 21 companies can purchase licenses for and contain much more functionality. 22 So we can, in u-boot, run either model by either using the VE FVP (default), 23 or turning on CONFIG_BASE_FVP for the more full featured model. 24 25 Rather than create a new armv8 board similar to armltd/vexpress64, add 26 semihosting calls to the existing one, enabled with CONFIG_SEMIHOSTING 27 and CONFIG_BASE_FVP both set. Also reuse the existing board config file 28 vexpress_aemv8a.h but differentiate the two models by the presence or 29 absence of CONFIG_BASE_FVP. This change is tested and works on both the 30 Foundation and Base fastmodel simulators. 31 32 The semihosting code adds a command: 33 34 smhload <image> <address> [env var] 35 36 That will load an image from the host filesystem into RAM at the specified 37 address and optionally store the load end address in the specified 38 environment variable. 39
README.serial_multi
1 The support for multiple serial interfaces as implemented is mainly 2 intended to allow for modem dial-in / dial-out while still being able 3 to use a serial console on a (different) serial port. 4 5 MPC8XX Specific 6 =============== 7 At the moment, the ports must be split on a SMC and a SCC port on a 8 8xx processor; other configurations are not (yet) supported. 9 10 Support for hardware handshake has not been implemented yet (but is 11 in the works). 12 13 *) The default console depends on the keys pressed: 14 - SMC if keys not pressed (modem not enabled) 15 - SCC if keys pressed (modem enabled) 16 17 *) The console can be switched to SCC by any of the following commands: 18 19 setenv stdout serial_scc 20 setenv stdin serial_scc 21 setenv stderr serial_scc 22 23 *) The console can be switched to SMC by any of the following commands: 24 25 setenv stdout serial_smc 26 setenv stdin serial_smc 27 setenv stderr serial_smc 28 29 *) If a file descriptor is set to "serial" then the current serial device 30 will be used which, in turn, can be switched by above commands. 31 32 *) The baudrate is the same for all serial devices. But it can be switched 33 just after switching the console: 34 35 setenv sout serial_scc; setenv baudrate 38400 36 37 After that press 'enter' at the SCC console. Note that baudrates <38400 38 are not allowed on LWMON with watchdog enabled (see CONFIG_SYS_BAUDRATE_TABLE in 39 include/configs/lwmon.h). 40 41 42 PPC4XX Specific 43 =============== 44 *) The default console is UART0 45 46 *) The console can be switched to UART1 by any of the following commands: 47 setenv stdout serial1 48 setenv stderr serial1 49 setenv stdin serial1 50 51 *) The console can be switched to UART0 by any of the following commands: 52 setenv stdout serial0 53 setenv stderr serial0 54 setenv stdin serial0 55
README.sh
1 2 U-Boot for Renesas SuperH 3 Last update 01/18/2008 by Nobuhiro Iwamatsu 4 5 ================================================================================ 6 0. What's this? 7 This file contains status information for the port of U-Boot to the 8 Renesas SuperH series of CPUs. 9 10 ================================================================================ 11 1. Overview 12 SuperH has an original boot loader. However, source code is dirty, and 13 maintenance is not done. 14 To improve sharing and the maintenance of the code, Nobuhiro Iwamatsu 15 started the porting to u-boot in 2007. 16 17 ================================================================================ 18 2. Supported CPUs 19 20 2.1. Renesas SH7750/SH7750R 21 This CPU has the SH4 core. 22 23 2.2. Renesas SH7722 24 This CPU has the SH4AL-DSP core. 25 26 2.3. Renesas SH7720 27 This CPU has the SH3 core. 28 29 2.4. Renesas SH7710/SH7712 30 This CPU has the SH3-DSP core and Ethernet controller. 31 32 2.5. Renesas SH7780 33 This CPU has the SH4A core. 34 35 ================================================================================ 36 3. Supported Boards 37 38 3.1. Hitachi UL MS7750SE01/MS7750RSE01 39 Board specific code is in board/ms7750se 40 To use this board, type "make ms7750se_config". 41 Support devices are : 42 - SCIF 43 - SDRAM 44 - NOR Flash 45 - Marubun PCMCIA 46 47 3.2. Hitachi UL MS7722SE01 48 Board specific code is in board/ms7722se 49 To use this board, type "make ms7722se_config". 50 Support devices are : 51 - SCIF 52 - SDRAM 53 - NOR Flash 54 - Marubun PCMCIA 55 - SMC91x ethernet 56 57 3.2. Hitachi UL MS7720ERP01 58 Board specific code is in board/ms7720se 59 To use this board, type "make ms7720se_config". 60 Support devices are : 61 - SCIF 62 - SDRAM 63 - NOR Flash 64 - Marubun PCMCIA 65 66 3.3. Renesas R7780MP 67 Board specific code is in board/r7780mp 68 To use this board, type "make r7780mp_config". 69 Support devices are : 70 - SCIF 71 - DDR-SDRAM 72 - NOR Flash 73 - Compact Flash 74 - ASIX ethernet 75 - SH7780 PCI bridge 76 - RTL8110 ethernet 77 78 ** README ** 79 In SuperH, S-record and binary of made u-boot work on the memory. 80 When u-boot is written in the flash, it is necessary to change the 81 address by using 'objcopy'. 82 ex) shX-linux-objcopy -Ibinary -Osrec u-boot.bin u-boot.flash.srec 83 84 ================================================================================ 85 4. Compiler 86 You can use the following of u-boot to compile. 87 - SuperH Linux Open site 88 http://www.superh-linux.org/ 89 - KPIT GNU tools 90 http://www.kpitgnutools.com/ 91 92 ================================================================================ 93 5. Future 94 I plan to support the following CPUs and boards. 95 5.1. CPUs 96 - SH7751R(SH4) 97 - SH7785(SH4) 98 99 5.2. Boards 100 - Many boards ;-) 101 102 ================================================================================ 103 Copyright (c) 2007,2008 104 Nobuhiro Iwamatsu <iwamatsu (at] nigaur.org> 105
README.sh7752evb
1 ======================================== 2 Renesas R0P7752C00000RZ board 3 ======================================== 4 5 This board specification: 6 ========================= 7 8 The R0P7752C00000RZ(board config name:sh7752evb) has the following device: 9 10 - SH7752 (SH-4A) 11 - DDR3-SDRAM 512MB 12 - SPI ROM 8MB 13 - Gigabit Ethernet controllers 14 - eMMC 4GB 15 16 17 Configuration for This board: 18 ============================= 19 20 You can select the configuration as follows: 21 22 - make sh7752evb_config 23 24 25 This board specific command: 26 ============================ 27 28 This board has the following its specific command: 29 30 - write_mac 31 32 33 1. write_mac 34 35 You can write MAC address to SPI ROM. 36 37 Usage 1) Write MAC address 38 39 write_mac [GETHERC ch0] [GETHERC ch1] 40 41 For example) 42 => write_mac 74:90:50:00:33:9e 74:90:50:00:33:9f 43 *) We have to input the command as a single line 44 (without carriage return) 45 *) We have to reset after input the command. 46 47 Usage 2) Show current data 48 49 write_mac 50 51 For example) 52 => write_mac 53 GETHERC ch0 = 74:90:50:00:33:9e 54 GETHERC ch1 = 74:90:50:00:33:9f 55 56 57 Update SPI ROM: 58 ============================ 59 60 1. Copy u-boot image to RAM area. 61 2. Probe SPI device. 62 => sf probe 0 63 SF: Detected MX25L6405D with page size 64KiB, total 8 MiB 64 3. Erase SPI ROM. 65 => sf erase 0 80000 66 4. Write u-boot image to SPI ROM. 67 => sf write 0x48000000 0 80000 68
README.sh7753evb
1 ======================================== 2 Renesas SH7753 EVB board 3 ======================================== 4 5 This board specification: 6 ========================= 7 8 The SH7753 EVB (board config name:sh7753evb) has the following device: 9 10 - SH7753 (SH-4A) 11 - DDR3-SDRAM 512MB 12 - SPI ROM 8MB 13 - Gigabit Ethernet controllers 14 - eMMC 4GB 15 16 17 Configuration for This board: 18 ============================= 19 20 You can select the configuration as follows: 21 22 - make sh7753evb_config 23 24 25 This board specific command: 26 ============================ 27 28 This board has the following its specific command: 29 30 - write_mac 31 32 33 1. write_mac 34 35 You can write MAC address to SPI ROM. 36 37 Usage 1) Write MAC address 38 39 write_mac [GETHERC ch0] [GETHERC ch1] 40 41 For example) 42 => write_mac 74:90:50:00:33:9e 74:90:50:00:33:9f 43 *) We have to input the command as a single line 44 (without carriage return) 45 *) We have to reset after input the command. 46 47 Usage 2) Show current data 48 49 write_mac 50 51 For example) 52 => write_mac 53 GETHERC ch0 = 74:90:50:00:33:9e 54 GETHERC ch1 = 74:90:50:00:33:9f 55 56 57 Update SPI ROM: 58 ============================ 59 60 1. Copy u-boot image to RAM area. 61 2. Probe SPI device. 62 => sf probe 0 63 SF: Detected MX25L6405D with page size 64KiB, total 8 MiB 64 3. Erase SPI ROM. 65 => sf erase 0 80000 66 4. Write u-boot image to SPI ROM. 67 => sf write 0x48000000 0 80000 68
README.sha1
1 SHA1 usage: 2 ----------- 3 4 In the U-Boot Image for the pcs440ep board is a SHA1 checksum integrated. 5 This SHA1 sum is used, to check, if the U-Boot Image in Flash is not 6 corrupted. 7 8 The following command is available: 9 10 => help sha1 11 sha1 address len [addr] calculate the SHA1 sum [save at addr] 12 -p calculate the SHA1 sum from the U-Boot image in flash and print 13 -c check the U-Boot image in flash 14 15 "sha1 -p" 16 calculates and prints the SHA1 sum, from the Image stored in Flash 17 18 "sha1 -c" 19 check, if the SHA1 sum from the Image stored in Flash is correct 20 21 22 It is possible to calculate a SHA1 checksum from a memoryrange with: 23 24 "sha1 address len" 25 26 If you want to store a new Image in Flash for the pcs440ep board, 27 which has no SHA1 sum, you can do the following: 28 29 a) cp the new Image on a position in RAM (here 0x300000) 30 (for this example we use the Image from Flash, stored at 0xfffa0000 and 31 0x60000 Bytes long) 32 33 "cp.b fffa0000 300000 60000" 34 35 b) Initialize the SHA1 sum in the Image with 0x00 36 The SHA1 sum is stored in Flash at: 37 CONFIG_SYS_MONITOR_BASE + CONFIG_SYS_MONITOR_LEN + SHA1_SUM_POS 38 for the pcs440ep Flash: 0xfffa0000 + 0x60000 + -0x20 39 = 0xffffffe0 40 for the example in RAM: 0x300000 + 0x60000 + -0x20 41 = 0x35ffe0 42 43 note: a SHA1 checksum is 20 bytes long. 44 45 "mw.b 35ffe0 0 14" 46 47 c) now calculate the SHA1 sum from the memoryrange and write 48 the calculated checksum at the right place: 49 50 "sha1 300000 60000 35ffe0" 51 52 Now you have a U-Boot-Image for the pcs440ep board with the correct SHA1 sum. 53 54 If you do a "buildman -k pcs440ep" or a "make all" to get the U-Boot image, 55 which will be found in ../current/ipam390/ - the correct SHA1 sum will be 56 automagically included in the U-Boot image. 57 58 Heiko Schocher, 11 Jul 2007 59
README.silent
1 The config option CONFIG_SILENT_CONSOLE can be used to quiet messages 2 on the console. If the option has been enabled, the output can be 3 silenced by setting the environment variable "silent". 4 5 - CONFIG_SILENT_CONSOLE_UPDATE_ON_SET 6 When the "silent" variable is changed with env set, the change 7 will take effect immediately. 8 9 - CONFIG_SILENT_CONSOLE_UPDATE_ON_RELOC 10 Some environments are not available until relocation (e.g. NAND) 11 so this will make the value in the flash env take effect at 12 relocation. 13 14 The following actions are taken if "silent" is set at boot time: 15 16 - Until the console devices have been initialized, output has to be 17 suppressed by testing for the flag "GD_FLG_SILENT" in "gd->flags". 18 19 - When the console devices have been initialized, "stdout" and 20 "stderr" are set to "nulldev", so subsequent messages are 21 suppressed automatically. Make sure to enable "nulldev" by 22 #defining CONFIG_SYS_DEVICE_NULLDEV in your board config file. 23 24 - When booting a linux kernel, the "bootargs" are fixed up so that 25 the argument "console=" will be in the command line, no matter how 26 it was set in "bootargs" before. If you don't want the linux command 27 line to be affected, define CONFIG_SILENT_U_BOOT_ONLY in your board 28 config file as well, and this part of the feature will be disabled. 29
README.SNTP
1 To use SNTP support, add define CONFIG_CMD_SNTP to the 2 configuration file of the board. 3 4 The "sntp" command gets network time from NTP time server and 5 syncronize RTC of the board. This command needs the command line 6 parameter of server's IP address or environment variable 7 "ntpserverip". The network time is sent as UTC. So if you want to 8 set local time to RTC, set the offset in second from UTC to the 9 environment variable "time offset". 10 11 If the DHCP server provides time server's IP or time offset, you 12 don't need to set the above environment variables yourself. 13 14 Current limitations of SNTP support: 15 1. The roundtrip time is ignored. 16 2. Only the 1st NTP server IP, in the option ntp-servers of DHCP, will 17 be used. 18
README.socfpga
1 ---------------------------------------- 2 SOCFPGA Documentation for U-Boot and SPL 3 ---------------------------------------- 4 5 This README is about U-Boot and SPL support for Altera's ARM Cortex-A9MPCore 6 based SOCFPGA. To know more about the hardware itself, please refer to 7 www.altera.com. 8 9 10 socfpga_dw_mmc 11 -------------- 12 13 Here are macro and detailed configuration required to enable DesignWare SDMMC 14 controller support within SOCFPGA 15 16 #define CONFIG_SYS_MMC_MAX_BLK_COUNT 256 17 -> Using smaller max blk cnt to avoid flooding the limited stack in OCRAM 18 19 -------------------------------------------------- 20 Generating the handoff header files for U-Boot SPL 21 -------------------------------------------------- 22 23 This text is assuming quartus 16.1, but newer versions will probably work just fine too; 24 verified with DE1_SOC_Linux_FB demo project (https://github.com/VCTLabs/DE1_SOC_Linux_FB). 25 Updated/working projects should build using either process below. 26 27 Note: it *should* work from Quartus 14.0.200 onwards, however, the current vendor demo 28 projects must have the IP cores updated as shown below. 29 30 Rebuilding your Quartus project 31 ------------------------------- 32 33 Choose one of the follwing methods, either command line or GUI. 34 35 Using the comaand line 36 ~~~~~~~~~~~~~~~~~~~~~~ 37 38 First run the embedded command shell, using your path to the Quartus install: 39 40 $ /path/to/intelFPGA/16.1/embedded/embedded_command_shell.sh 41 42 Then (if necessary) update the IP cores in the project, generate HDL code, and 43 build the project: 44 45 $ cd path/to/project/dir 46 $ qsys-generate soc_system.qsys --upgrade-ip-cores 47 $ qsys-generate soc_system.qsys --synthesis=[VERILOG|VHDL] 48 $ quartus_sh --flow compile <project name> 49 50 Convert the resulting .sof file (SRAM object file) to .rbf file (Raw bit file): 51 52 $ quartus_cpf -c <project_name>.sof soc_system.rbf 53 54 55 Generate BSP handoff files 56 ~~~~~~~~~~~~~~~~~~~~~~~~~~ 57 58 You can run the bsp editor GUI below, or run the following command from the 59 project directory: 60 61 $ /path/to/bsb/tools/bsp-create-settings --type spl --bsp-dir build \ 62 --preloader-settings-dir hps_isw_handoff/soc_system_hps_0/ \ 63 --settings build/settings.bsp 64 65 You should use the bsp "build" directory above (ie, where the settings.bsp file is) 66 in the following u-boot command to update the board headers. Once these headers 67 are updated for a given project build, u-boot should be configured for the 68 project board (eg, de0-nano-sockit) and then build the normal spl build. 69 70 Now you can skip the GUI section. 71 72 73 Using the Qsys GUI 74 ~~~~~~~~~~~~~~~~~~ 75 76 1. Navigate to your project directory 77 2. Run Quartus II 78 3. Open Project (Ctrl+J), select <project_name>.qpf 79 4. Run QSys [Tools->QSys] 80 4.1 In the Open dialog, select '<project_name>.qsys' 81 4.2 In the Open System dialog, wait until completion and press 'Close' 82 4.3 In the Qsys window, click on 'Generate HDL...' in bottom right corner 83 4.3.1 In the 'Generation' window, click 'Generate' 84 4.3.2 In the 'Generate' dialog, wait until completion and click 'Close' 85 4.4 In the QSys window, click 'Finish' 86 4.4.1 In the 'Quartus II' pop up window, click 'OK' 87 5. Back in Quartus II main window, do the following 88 5.1 Use Processing -> Start -> Start Analysis & Synthesis (Ctrl+K) 89 5.2 Use Processing -> Start Compilation (Ctrl+L) 90 91 ... this may take some time, have patience ... 92 93 6. Start the embedded command shell as shown in the previous section 94 6.1 Change directory to 'software/spl_bsp' 95 6.2 Prepare BSP by launching the BSP editor from ECS 96 => bsp-editor 97 6.3 In BSP editor 98 6.3.1 Use File -> Open 99 6.3.2 Select 'settings.bsp' file 100 6.3.3 Click Generate 101 6.3.4 Click Exit 102 103 104 Post handoff generation 105 ~~~~~~~~~~~~~~~~~~~~~~~ 106 107 Now that the handoff files are generated, U-Boot can be used to process 108 the handoff files generated by the bsp-editor. For this, please use the 109 following script from the u-boot source tree: 110 111 $ ./arch/arm/mach-socfpga/qts-filter.sh \ 112 <soc_type> \ 113 <input_qts_dir> \ 114 <input_bsp_dir> \ 115 <output_dir> 116 117 Process QTS-generated files into U-Boot compatible ones. 118 119 soc_type - Type of SoC, either 'cyclone5' or 'arria5'. 120 input_qts_dir - Directory with compiled Quartus project 121 and containing the Quartus project file (QPF). 122 input_bsp_dir - Directory with generated bsp containing 123 the settings.bsp file. 124 output_dir - Directory to store the U-Boot compatible 125 headers. 126 127 This will generate (or update) the following 4 files: 128 129 iocsr_config.h 130 pinmux_config.h 131 pll_config.h 132 sdram_config.h 133 134 These files should be copied into "qts" directory in the board directory 135 (see output argument of qts-filter.sh command above). 136 137 Here is an example for the DE-0 Nano SoC after the above rebuild process: 138 139 $ ll board/terasic/de0-nano-soc/qts/ 140 total 36 141 -rw-r--r-- 1 sarnold sarnold 8826 Mar 21 18:11 iocsr_config.h 142 -rw-r--r-- 1 sarnold sarnold 4398 Mar 21 18:11 pinmux_config.h 143 -rw-r--r-- 1 sarnold sarnold 3190 Mar 21 18:11 pll_config.h 144 -rw-r--r-- 1 sarnold sarnold 9022 Mar 21 18:11 sdram_config.h 145 146 Note: file sizes will differ slightly depending on the selected board. 147 148 Now your board is ready for full mainline support including U-Boot SPL. 149 The Preloader will not be needed any more. 150
README.spear
1 2 SPEAr (Structured Processor Enhanced Architecture). 3 4 SPEAr600 is also known as SPEArPlus and SPEAr300 is also known as SPEArBasic 5 6 The SPEAr SoC family embeds a customizable logic that can be programmed 7 one-time by a customer at silicon mask level (i.e. not at runtime!). 8 9 U-Boot supports four SoCs: SPEAr600, SPEAr3xx 10 11 All 4 SoCs (SPEAr3xx and SPEAr600) share common peripherals. SPEAr300 and 12 SPEAr600 do not have EMI. 13 14 1. ARM926ejs core based (sp600 has two cores, the 2nd handled only in Linux) 15 2. FastEthernet (sp600 has Gbit version, but same controller - GMAC) 16 3. USB Host 17 4. USB Device 18 5. NAND controller (FSMC) 19 6. Serial NOR ctrl 20 7. I2C 21 8. SPI 22 9. CLCD 23 10. others .. 24 25 Everything is supported in Linux. 26 u-boot is currently not supporting all peripeharls (just a few as listed below). 27 1. USB Device 28 2. NAND controller (FSMC) 29 3. Serial Memory Interface 30 4. EMI (Parallel NOR interface) 31 4. I2C 32 5. UART 33 34 Build options 35 make spear320_config 36 spear320 build with environment variables placed at default 37 location i.e. Serial NOR device 38 make spear320_pnor_config 39 This option generates a uboot image that supports emi controller 40 for CFI compliant parallel NOR flash. Environment variables are 41 placed in Parallel NOR device 42 make spear320_nand_config 43 spear320 build with environment variables placed in NAND device 44 make spear320_usbtty_config 45 spear320 build with usbtty terminal as default and environment 46 placed at default location 47 make spear320_usbtty_pnor_config 48 spear320 build with usbtty terminal as default and environment 49 placed in pnor device 50 make spear320_usbtty_nand_config 51 Build with usbtty terminal as default and environment placed in 52 NAND device 53 make spear300_config 54 make spear300_nand_config 55 make spear300_usbtty_config 56 make spear300_usbtty_nand_config 57 make spear310_config 58 make spear310_pnor_config 59 make spear310_nand_config 60 make spear310_usbtty_config 61 make spear310_usbtty_pnor_config 62 make spear310_usbtty_nand_config 63 make spear600_config 64 make spear600_nand_config 65 make spear600_usbtty_config 66 make spear600_usbtty_nand_config 67 68 Mac id storage and retrieval in spear platforms 69 70 Please read doc/README.enetaddr for the implementation guidelines for mac id 71 usage. Basically, environment has precedence over board specific storage. The 72 ethaddr beeing used for the network interface is always taken only from 73 environment variables. Although, we can check the mac id programmed in i2c 74 memory by using chip_config command 75
README.SPL
1 Generic SPL framework 2 ===================== 3 4 Overview 5 -------- 6 7 To unify all existing implementations for a secondary program loader (SPL) 8 and to allow simply adding of new implementations this generic SPL framework 9 has been created. With this framework almost all source files for a board 10 can be reused. No code duplication or symlinking is necessary anymore. 11 12 13 How it works 14 ------------ 15 16 The object files for SPL are built separately and placed in the "spl" directory. 17 The final binaries which are generated are u-boot-spl, u-boot-spl.bin and 18 u-boot-spl.map. 19 20 A config option named CONFIG_SPL_BUILD is enabled by Kconfig for SPL. 21 Source files can therefore be compiled for SPL with different settings. 22 23 For example: 24 25 ifeq ($(CONFIG_SPL_BUILD),y) 26 obj-y += board_spl.o 27 else 28 obj-y += board.o 29 endif 30 31 obj-$(CONFIG_SPL_BUILD) += foo.o 32 33 #ifdef CONFIG_SPL_BUILD 34 foo(); 35 #endif 36 37 38 The building of SPL images can be enabled by CONFIG_SPL option in Kconfig. 39 40 Because SPL images normally have a different text base, one has to be 41 configured by defining CONFIG_SPL_TEXT_BASE. The linker script has to be 42 defined with CONFIG_SPL_LDSCRIPT. 43 44 To support generic U-Boot libraries and drivers in the SPL binary one can 45 optionally define CONFIG_SPL_XXX_SUPPORT. Currently following options 46 are supported: 47 48 CONFIG_SPL_LIBCOMMON_SUPPORT (common/libcommon.o) 49 CONFIG_SPL_LIBDISK_SUPPORT (disk/libdisk.o) 50 CONFIG_SPL_I2C_SUPPORT (drivers/i2c/libi2c.o) 51 CONFIG_SPL_GPIO_SUPPORT (drivers/gpio/libgpio.o) 52 CONFIG_SPL_MMC_SUPPORT (drivers/mmc/libmmc.o) 53 CONFIG_SPL_SERIAL_SUPPORT (drivers/serial/libserial.o) 54 CONFIG_SPL_SPI_FLASH_SUPPORT (drivers/mtd/spi/libspi_flash.o) 55 CONFIG_SPL_SPI_SUPPORT (drivers/spi/libspi.o) 56 CONFIG_SPL_FAT_SUPPORT (fs/fat/libfat.o) 57 CONFIG_SPL_EXT_SUPPORT 58 CONFIG_SPL_LIBGENERIC_SUPPORT (lib/libgeneric.o) 59 CONFIG_SPL_POWER_SUPPORT (drivers/power/libpower.o) 60 CONFIG_SPL_NAND_SUPPORT (drivers/mtd/nand/libnand.o) 61 CONFIG_SPL_DRIVERS_MISC_SUPPORT (drivers/misc) 62 CONFIG_SPL_DMA_SUPPORT (drivers/dma/libdma.o) 63 CONFIG_SPL_POST_MEM_SUPPORT (post/drivers/memory.o) 64 CONFIG_SPL_NAND_LOAD (drivers/mtd/nand/nand_spl_load.o) 65 CONFIG_SPL_SPI_LOAD (drivers/mtd/spi/spi_spl_load.o) 66 CONFIG_SPL_RAM_DEVICE (common/spl/spl.c) 67 CONFIG_SPL_WATCHDOG_SUPPORT (drivers/watchdog/libwatchdog.o) 68 69 70 Debugging 71 --------- 72 73 When building SPL with DEBUG set you may also need to set CONFIG_PANIC_HANG 74 as in most cases do_reset is not defined within SPL. 75 76 77 Estimating stack usage 78 ---------------------- 79 80 With gcc 4.6 (and later) and the use of GNU cflow it is possible to estimate 81 stack usage at various points in run sequence of SPL. The -fstack-usage option 82 to gcc will produce '.su' files (such as arch/arm/cpu/armv7/syslib.su) that 83 will give stack usage information and cflow can construct program flow. 84 85 Must have gcc 4.6 or later, which supports -fstack-usage 86 87 1) Build normally 88 2) Perform the following shell command to generate a list of C files used in 89 SPL: 90 $ find spl -name '*.su' | sed -e 's:^spl/::' -e 's:[.]su$:.c:' > used-spl.list 91 3) Execute cflow: 92 $ cflow --main=board_init_r `cat used-spl.list` 2>&1 | $PAGER 93 94 cflow will spit out a number of warnings as it does not parse 95 the config files and picks functions based on #ifdef. Parsing the '.i' 96 files instead introduces another set of headaches. These warnings are 97 not usually important to understanding the flow, however. 98
README.splashprepare
1 --------------------------------------------------------------------- 2 Splash Screen 3 --------------------------------------------------------------------- 4 The splash_screen_prepare() function is a weak function defined in 5 common/splash.c. It is called as part of the splash screen display 6 sequence. It gives the board an opportunity to prepare the splash 7 image data before it is processed and sent to the frame buffer by 8 U-Boot. Define your own version to use this feature. 9 10 CONFIG_SPLASH_SOURCE 11 12 Use the splash_source.c library. This library provides facilities to declare 13 board specific splash image locations, routines for loading splash image from 14 supported locations, and a way of controlling the selected splash location 15 using the "splashsource" environment variable. 16 17 splashsource works as follows: 18 - If splashsource is set to a supported location name as defined by board code, 19 use that splash location. 20 - If splashsource is undefined, use the first splash location as default. 21 - If splashsource is set to an unsupported value, do not load a splash screen. 22 23 A splash source location can describe either storage with raw data, a storage 24 formatted with a file system or a FIT image. In case of a filesystem, the splash 25 screen data is loaded as a file. The name of the splash screen file can be 26 controlled with the environment variable "splashfile". 27 28 To enable loading the splash image from a FIT image, CONFIG_FIT must be 29 enabled. Struct splash_location field 'name' should match the splash image 30 name within the FIT and the FIT should start at the 'offset' field address in 31 the specified storage. 32
README.srio-pcie-boot-corenet
1 --------------------------------------- 2 SRIO and PCIE Boot on Corenet Platforms 3 --------------------------------------- 4 5 For some PowerPC processors with SRIO or PCIE interface, boot location can be 6 configured to SRIO or PCIE by RCW. The processor booting from SRIO or PCIE can 7 do without flash for u-boot image, ucode and ENV. All the images can be fetched 8 from another processor's memory space by SRIO or PCIE link connected between 9 them. 10 11 This document describes the processes based on an example implemented on P4080DS 12 platforms and a RCW example with boot from SRIO or PCIE configuration. 13 14 Environment of the SRIO or PCIE boot: 15 a) Master and slave can be SOCs in one board or SOCs in separate boards. 16 b) They are connected with SRIO or PCIE links, whether 1x, 2x or 4x, and 17 directly or through switch system. 18 c) Only Master has NorFlash for booting, and all the Master's and Slave's 19 U-Boot images, UCodes will be stored in this flash. 20 d) Slave has its own EEPROM for RCW and PBI. 21 e) Slave's RCW should configure the SerDes for SRIO or PCIE boot port, set 22 the boot location to SRIO or PCIE, and holdoff all the cores. 23 24 ----------- ----------- ----------- 25 | | | | | | 26 | | | | | | 27 | NorFlash|<----->| Master |SRIO or PCIE | Slave |<---->[EEPROM] 28 | | | |<===========>| | 29 | | | | | | 30 ----------- ----------- ----------- 31 32 The example based on P4080DS platform: 33 Two P4080DS platforms can be used to implement the boot from SRIO or PCIE. 34 Their SRIO or PCIE ports 1 will be connected directly and will be used for 35 the boot from SRIO or PCIE. 36 37 1. Slave's RCW example for boot from SRIO port 1 and all cores in holdoff. 38 00000000: aa55 aa55 010e 0100 0c58 0000 0000 0000 39 00000010: 1818 1818 0000 8888 7440 4000 0000 2000 40 00000020: f440 0000 0100 0000 0000 0000 0000 0000 41 00000030: 0000 0000 0083 0000 0000 0000 0000 0000 42 00000040: 0000 0000 0000 0000 0813 8040 063c 778f 43 44 2. Slave's RCW example for boot from PCIE port 1 and all cores in holdoff. 45 00000000: aa55 aa55 010e 0100 0c58 0000 0000 0000 46 00000010: 1818 1818 0000 8888 1440 4000 0000 2000 47 00000020: f040 0000 0100 0000 0020 0000 0000 0000 48 00000030: 0000 0000 0083 0000 0000 0000 0000 0000 49 00000040: 0000 0000 0000 0000 0813 8040 547e ffc9 50 51 3. Sequence in Step by Step. 52 a) Update RCW for slave with boot from SRIO or PCIE port 1 configuration. 53 b) Program slave's U-Boot image, UCode, and ENV parameters into master's 54 NorFlash. 55 c) Set environment variable "bootmaster" to "SRIO1" or "PCIE1" and save 56 environment for master. 57 setenv bootmaster SRIO1 58 or 59 setenv bootmaster PCIE1 60 saveenv 61 d) Restart up master and it will boot up normally from its NorFlash. 62 Then, it will finish necessary configurations for slave's boot from 63 SRIO or PCIE port 1. 64 e) Master will set inbound SRIO or PCIE windows covered slave's U-Boot 65 image stored in master's NorFlash. 66 f) Master will set an inbound SRIO or PCIE window covered slave's UCode 67 and ENV stored in master's NorFlash. 68 g) Master will set outbound SRIO or PCIE windows in order to configure 69 slave's registers for the core's releasing. 70 h) Since all cores of slave in holdoff, slave should be powered on before 71 all the above master's steps, and wait to be released by master. In the 72 startup phase of the slave from SRIO or PCIE, it will finish some 73 necessary configurations. 74 i) Slave will set a specific TLB entry for the boot process. 75 j) Slave will set a LAW entry with the TargetID SRIO or PCIE port 1 for 76 the boot. 77 k) Slave will set a specific TLB entry in order to fetch UCode and ENV 78 from master. 79 l) Slave will set a LAW entry with the TargetID SRIO or PCIE port 1 for 80 UCode and ENV. 81 82 How to use this feature: 83 To use this feature, you need to focus those points. 84 85 1. Slave's RCW with SRIO or PCIE boot configurations, and all cores in holdoff 86 configurations. 87 Please refer to the examples given above. 88 89 2. U-Boot image's compilation. 90 For master, U-Boot image should be generated normally. 91 92 For example, master U-Boot image used on P4080DS should be compiled with 93 94 make P4080DS_config. 95 96 For slave, U-Boot image should be generated specifically by 97 98 make xxxx_SRIO_PCIE_BOOT_config. 99 100 For example, slave U-Boot image used on P4080DS should be compiled with 101 102 make P4080DS_SRIO_PCIE_BOOT_config. 103 104 3. Necessary modifications based on a specific environment. 105 For a specific environment, the addresses of the slave's U-Boot image, 106 UCode, ENV stored in master's NorFlash, and any other configurations 107 can be modified in the file: 108 include/configs/corenet_ds.h. 109 110 4. Set and save the environment variable "bootmaster" with "SRIO1", "SRIO2" 111 or "PCIE1", "PCIE2", "PCIE3" for master, and then restart it in order to 112 perform the role as a master for boot from SRIO or PCIE. 113 114 NOTE: When the Slave's ENV parameters are stored in Master's NorFlash, 115 it can fetch them through PCIE or SRIO interface. But the ENV 116 parameters can not be modified by "saveenv" or other commands under 117 the Slave's u-boot environment, because the Slave can not erase, 118 write Master's NorFlash by PCIE or SRIO link. 119
README.standalone
1 Design Notes on Exporting U-Boot Functions to Standalone Applications: 2 ====================================================================== 3 4 1. The functions are exported by U-Boot via a jump table. The jump 5 table is allocated and initialized in the jumptable_init() routine 6 (common/exports.c). Other routines may also modify the jump table, 7 however. The jump table can be accessed as the 'jt' field of the 8 'global_data' structure. The struct members for the jump table are 9 defined in the <include/exports.h> header. E.g., to substitute the 10 malloc() and free() functions that will be available to standalone 11 applications, one should do the following: 12 13 DECLARE_GLOBAL_DATA_PTR; 14 15 gd->jt->malloc = my_malloc; 16 gd->jt->free = my_free; 17 18 Note that the pointers to the functions are real function pointers 19 so the compiler can perform type checks on these assignments. 20 21 2. The pointer to the jump table is passed to the application in a 22 machine-dependent way. PowerPC, ARM, MIPS, Blackfin and Nios II 23 architectures use a dedicated register to hold the pointer to the 24 'global_data' structure: r2 on PowerPC, r9 on ARM, k0 on MIPS, 25 P3 on Blackfin and gp on Nios II. The x86 architecture does not 26 use such a register; instead, the pointer to the 'global_data' 27 structure is passed as 'argv[-1]' pointer. 28 29 The application can access the 'global_data' structure in the same 30 way as U-Boot does: 31 32 DECLARE_GLOBAL_DATA_PTR; 33 34 printf("U-Boot relocation offset: %x\n", gd->reloc_off); 35 36 3. The application should call the app_startup() function before any 37 call to the exported functions. Also, implementor of the 38 application may want to check the version of the ABI provided by 39 U-Boot. To facilitate this, a get_version() function is exported 40 that returns the ABI version of the running U-Boot. I.e., a 41 typical application startup may look like this: 42 43 int my_app (int argc, char * const argv[]) 44 { 45 app_startup (argv); 46 if (get_version () != XF_VERSION) 47 return 1; 48 } 49 50 4. The default load and start addresses of the applications are as 51 follows: 52 53 Load address Start address 54 x86 0x00040000 0x00040000 55 PowerPC 0x00040000 0x00040004 56 ARM 0x0c100000 0x0c100000 57 MIPS 0x80200000 0x80200000 58 Blackfin 0x00001000 0x00001000 59 NDS32 0x00300000 0x00300000 60 Nios II 0x02000000 0x02000000 61 RISC-V 0x00600000 0x00600000 62 63 For example, the "hello world" application may be loaded and 64 executed on a PowerPC board with the following commands: 65 66 => tftp 0x40000 hello_world.bin 67 => go 0x40004 68 69 5. To export some additional function long foobar(int i,char c), the following steps 70 should be undertaken: 71 72 - Append the following line at the end of the include/_exports.h 73 file: 74 75 EXPORT_FUNC(foobar, long, foobar, int, char) 76 77 Parameters to EXPORT_FUNC: 78 - the first parameter is the function that is exported (default implementation) 79 - the second parameter is the return value type 80 - the third parameter is the name of the member in struct jt_funcs 81 this is also the name that the standalone application will used. 82 the rest of the parameters are the function arguments 83 84 - Add the prototype for this function to the include/exports.h 85 file: 86 87 long foobar(int i, char c); 88 89 Initialization with the default implementation is done in jumptable_init() 90 91 You can override the default implementation using: 92 93 gd->jt->foobar = another_foobar; 94 95 The signature of another_foobar must then match the declaration of foobar. 96 97 - Increase the XF_VERSION value by one in the include/exports.h 98 file 99 100 - If you want to export a function which depends on a CONFIG_XXX 101 use 2 lines like this: 102 #ifdef CONFIG_FOOBAR 103 EXPORT_FUNC(foobar, long, foobar, int, char) 104 #else 105 EXPORT_FUNC(dummy, void, foobar, void) 106 #endif 107 108 109 6. The code for exporting the U-Boot functions to applications is 110 mostly machine-independent. The only places written in assembly 111 language are stub functions that perform the jump through the jump 112 table. That said, to port this code to a new architecture, the 113 only thing to be provided is the code in the examples/stubs.c 114 file. If this architecture, however, uses some uncommon method of 115 passing the 'global_data' pointer (like x86 does), one should add 116 the respective code to the app_startup() function in that file. 117 118 Note that these functions may only use call-clobbered registers; 119 those registers that are used to pass the function's arguments, 120 the stack contents and the return address should be left intact. 121
README.t1040-l2switch
1 This file contains information for VSC9953, a Vitesse L2 Switch IP 2 which is integrated in the T1040/T1020 Freescale SoCs. 3 4 About Device: 5 ============= 6 VSC9953 is an 8-port Gigabit Ethernet switch supports the following features: 7 - 8192 MAC addresses 8 - Static Address provisioning 9 - Dynamic learning of MAC addresses and aging 10 - 4096 VLANs 11 - Independent and shared VLAN learning (IVL, SVL) 12 - Policing with storm control and MC/BC protection 13 - IPv4 and IPv6 multicast 14 - Jumbo frames (9.6 KB) 15 - Access Control List 16 - VLAN editing, translation and remarking 17 - RMON counters per port 18 19 Switch interfaces: 20 - 8 Gigabit switch ports (ports 0 to 7) are external and are connected to external PHYs 21 - 2 switch ports (ports 8 and 9) of 2.5 G are connected (fixed links) 22 to FMan ports (FM1@DTSEC1 and FM1@DTSEC2) 23 24 Commands Overview: 25 ============= 26 Commands supported 27 - enable/disable a port or show its configuration (speed, duplexity, status, etc.) 28 - port statistics 29 - MAC learning 30 - add/remove FDB entries 31 - Port-based VLAN 32 - Private/Shared VLAN learning 33 - VLAN ingress filtering 34 - Port LAG 35 36 Commands syntax 37 ethsw [port <port_no>] { enable | disable | show } - enable/disable a port; show a port's configuration 38 ethsw [port <port_no>] statistics { [help] | [clear] } - show an l2 switch port's statistics 39 ethsw [port <port_no>] learning { [help] | show | auto | disable } - enable/disable/show learning configuration on a port 40 ethsw [port <port_no>] [vlan <vid>] fdb { [help] | show | flush | { add | del } <mac> } - add/delete a mac entry in FDB; use show to see FDB entries; 41 if [vlan <vid>] is missing, VID 1 will be used 42 ethsw [port <port_no>] pvid { [help] | show | <pvid> } - set/show PVID (ingress and egress VLAN tagging) for a port 43 ethsw [port <port_no>] vlan { [help] | show | add <vid> | del <vid> } - add a VLAN to a port (VLAN members) 44 ethsw [port <port_no>] untagged { [help] | show | all | none | pvid } - set egress tagging mode for a port 45 ethsw [port <port_no>] egress tag { [help] | show | pvid | classified } - configure VID source for egress tag. 46 Tag's VID could be the frame's classified VID or the PVID of the port 47 ethsw vlan fdb { [help] | show | shared | private } - make VLAN learning shared or private 48 ethsw [port <port_no>] ingress filtering { [help] | show | enable | disable } - enable/disable VLAN ingress filtering on port 49 ethsw [port <port_no>] aggr { [help] | show | <lag_group_no> } - get/set LAG group for a port 50 51 => ethsw show 52 Port Status Link Speed Duplex 53 0 enabled down 10 half 54 1 enabled down 10 half 55 2 enabled down 10 half 56 3 enabled up 1000 full 57 4 disabled down - half 58 5 disabled down - half 59 6 disabled down - half 60 7 disabled down - half 61 8 enabled up 2500 full 62 9 enabled up 2500 full 63 => 64
README.ti-secure
1 README on how boot images are created for secure TI devices 2 3 CONFIG_TI_SECURE_DEVICE: 4 Secure TI devices require a boot image that is authenticated by ROM 5 code to function. Without this, even JTAG remains locked and the 6 device is essentially useless. In order to create a valid boot image for 7 a secure device from TI, the initial public software image must be signed 8 and combined with various headers, certificates, and other binary images. 9 10 Information on the details on the complete boot image format can be obtained 11 from Texas Instruments. The tools used to generate boot images for secure 12 devices are part of a secure development package (SECDEV) that can be 13 downloaded from: 14 15 http://www.ti.com/mysecuresoftware (login required) 16 17 The secure development package is access controlled due to NDA and export 18 control restrictions. Access must be requested and granted by TI before the 19 package is viewable and downloadable. Contact TI, either online or by way 20 of a local TI representative, to request access. 21 22 Booting of U-Boot SPL 23 ===================== 24 25 When CONFIG_TI_SECURE_DEVICE is set, the U-Boot SPL build process 26 requires the presence and use of these tools in order to create a 27 viable boot image. The build process will look for the environment 28 variable TI_SECURE_DEV_PKG, which should be the path of the installed 29 SECDEV package. If the TI_SECURE_DEV_PKG variable is not defined or 30 if it is defined but doesn't point to a valid SECDEV package, a 31 warning is issued during the build to indicate that a final secure 32 bootable image was not created. 33 34 Within the SECDEV package exists an image creation script: 35 36 ${TI_SECURE_DEV_PKG}/scripts/create-boot-image.sh 37 38 This is called as part of the SPL/u-boot build process. As the secure 39 boot image formats and requirements differ between secure SOC from TI, 40 the purpose of this script is to abstract these details as much as 41 possible. 42 43 The script is basically the only required interface to the TI SECDEV 44 package for creating a bootable SPL image for secure TI devices. 45 46 Invoking the script for AM33xx Secure Devices 47 ============================================= 48 49 create-boot-image.sh \ 50 <IMAGE_FLAG> <INPUT_FILE> <OUTPUT_FILE> <SPL_LOAD_ADDR> 51 52 <IMAGE_FLAG> is a value that specifies the type of the image to 53 generate OR the action the image generation tool will take. Valid 54 values are: 55 SPI_X-LOADER - Generates an image for SPI flash (byte swapped) 56 X-LOADER - Generates an image for non-XIP flash 57 MLO - Generates an image for SD/MMC/eMMC media 58 2ND - Generates an image for USB, UART and Ethernet 59 XIP_X-LOADER - Generates a single stage u-boot for NOR/QSPI XiP 60 61 <INPUT_FILE> is the full path and filename of the public world boot 62 loaderbinary file (depending on the boot media, this is usually 63 either u-boot-spl.bin or u-boot.bin). 64 65 <OUTPUT_FILE> is the full path and filename of the final secure 66 image. The output binary images should be used in place of the standard 67 non-secure binary images (see the platform-specific user's guides and 68 releases notes for how the non-secure images are typically used) 69 u-boot-spl_HS_SPI_X-LOADER - byte swapped boot image for SPI flash 70 u-boot-spl_HS_X-LOADER - boot image for NAND or SD/MMC/eMMC rawmode 71 u-boot-spl_HS_MLO - boot image for SD/MMC/eMMC media 72 u-boot-spl_HS_2ND - boot image for USB, UART and Ethernet 73 u-boot_HS_XIP_X-LOADER - boot image for NOR or QSPI Xip flash 74 75 <SPL_LOAD_ADDR> is the address at which SOC ROM should load the 76 <INPUT_FILE> 77 78 Invoking the script for AM43xx Secure Devices 79 ============================================= 80 81 create-boot-image.sh \ 82 <IMAGE_FLAG> <INPUT_FILE> <OUTPUT_FILE> <SPL_LOAD_ADDR> 83 84 <IMAGE_FLAG> is a value that specifies the type of the image to 85 generate OR the action the image generation tool will take. Valid 86 values are: 87 SPI_X-LOADER - Generates an image for SPI flash (byte 88 swapped) 89 XIP_X-LOADER - Generates a single stage u-boot for 90 NOR/QSPI XiP 91 ISSW - Generates an image for all other boot modes 92 93 <INPUT_FILE> is the full path and filename of the public world boot 94 loaderbinary file (depending on the boot media, this is usually 95 either u-boot-spl.bin or u-boot.bin). 96 97 <OUTPUT_FILE> is the full path and filename of the final secure 98 image. The output binary images should be used in place of the standard 99 non-secure binary images (see the platform-specific user's guides and 100 releases notes for how the non-secure images are typically used) 101 u-boot-spl_HS_SPI_X-LOADER - byte swapped boot image for SPI flash 102 u-boot_HS_XIP_X-LOADER - boot image for NOR or QSPI flash 103 u-boot-spl_HS_ISSW - boot image for all other boot media 104 105 <SPL_LOAD_ADDR> is the address at which SOC ROM should load the 106 <INPUT_FILE> 107 108 Invoking the script for DRA7xx/AM57xx Secure Devices 109 ==================================================== 110 111 create-boot-image.sh <IMAGE_TYPE> <INPUT_FILE> <OUTPUT_FILE> 112 113 <IMAGE_TYPE> is a value that specifies the type of the image to 114 generate OR the action the image generation tool will take. Valid 115 values are: 116 X-LOADER - Generates an image for NOR or QSPI boot modes 117 MLO - Generates an image for SD/MMC/eMMC boot modes 118 ULO - Generates an image for USB/UART peripheral boot modes 119 Note: ULO is not yet used by the u-boot build process 120 121 <INPUT_FILE> is the full path and filename of the public world boot 122 loader binary file (for this platform, this is always u-boot-spl.bin). 123 124 <OUTPUT_FILE> is the full path and filename of the final secure image. 125 The output binary images should be used in place of the standard 126 non-secure binary images (see the platform-specific user's guides 127 and releases notes for how the non-secure images are typically used) 128 u-boot-spl_HS_MLO - boot image for SD/MMC/eMMC. This image is 129 copied to a file named MLO, which is the name that 130 the device ROM bootloader requires for loading from 131 the FAT partition of an SD card (same as on 132 non-secure devices) 133 u-boot-spl_HS_X-LOADER - boot image for all other flash memories 134 including QSPI and NOR flash 135 136 Invoking the script for Keystone2 Secure Devices 137 ============================================= 138 139 create-boot-image.sh \ 140 <UNUSED> <INPUT_FILE> <OUTPUT_FILE> <UNUSED> 141 142 <UNUSED> is currently ignored and reserved for future use. 143 144 <INPUT_FILE> is the full path and filename of the public world boot 145 loader binary file (only u-boot.bin is currently supported on 146 Keystone2 devices, u-boot-spl.bin is not currently supported). 147 148 <OUTPUT_FILE> is the full path and filename of the final secure image. 149 The output binary images should be used in place of the standard 150 non-secure binary images (see the platform-specific user's guides 151 and releases notes for how the non-secure images are typically used) 152 u-boot_HS_MLO - signed and encrypted boot image that can be used to 153 boot from all media. Secure boot from SPI NOR flash is not 154 currently supported. 155 156 Booting of Primary U-Boot (u-boot.img) 157 ====================================== 158 159 The SPL image is responsible for loading the next stage boot loader, 160 which is the main u-boot image. For secure TI devices, the SPL will 161 be authenticated, as described above, as part of the particular 162 device's ROM boot process. In order to continue the secure boot 163 process, the authenticated SPL must authenticate the main u-boot 164 image that it loads. 165 166 The configurations for secure TI platforms are written to make the boot 167 process use the FIT image format for the u-boot.img (CONFIG_SPL_FRAMEWORK 168 and CONFIG_SPL_LOAD_FIT). With these configurations the binary 169 components that the SPL loads include a specific DTB image and u-boot 170 image. These DTB image may be one of many available to the boot 171 process. In order to secure these components so that they can be 172 authenticated by the SPL as they are loaded from the FIT image, the 173 build procedure for secure TI devices will secure these images before 174 they are integrated into the FIT image. When those images are extracted 175 from the FIT image at boot time, they are post-processed to verify that 176 they are still secure. The outlined security-related SPL post-processing 177 is enabled through the CONFIG_SPL_FIT_IMAGE_POST_PROCESS option which 178 must be enabled for the secure boot scheme to work. In order to allow 179 verifying proper operation of the secure boot chain in case of successful 180 authentication messages like "Authentication passed: CERT_U-BOOT-NOD" are 181 output by the SPL to the console for each blob that got extracted from the 182 FIT image. Note that the last part of this log message is the (truncated) 183 name of the signing certificate embedded into the blob that got processed. 184 185 The exact details of the how the images are secured is handled by the 186 SECDEV package. Within the SECDEV package exists a script to process 187 an input binary image: 188 189 ${TI_SECURE_DEV_PKG}/scripts/secure-binary-image.sh 190 191 This is called as part of the u-boot build process. As the secure 192 image formats and requirements can differ between the various secure 193 SOCs from TI, this script in the SECDEV package abstracts these 194 details. This script is essentially the only required interface to the 195 TI SECDEV package for creating a u-boot.img image for secure TI 196 devices. 197 198 The SPL/u-boot code contains calls to dedicated secure ROM functions 199 to perform the validation on the secured images. The details of the 200 interface to those functions is shown in the code. The summary 201 is that they are accessed by invoking an ARM secure monitor call to 202 the device's secure ROM (fixed read-only-memory that is secure and 203 only accessible when the ARM core is operating in the secure mode). 204 205 Invoking the secure-binary-image script for Secure Devices 206 ========================================================== 207 208 secure-binary-image.sh <INPUT_FILE> <OUTPUT_FILE> 209 210 <INPUT_FILE> is the full path and filename of the input binary image 211 212 <OUTPUT_FILE> is the full path and filename of the output secure image. 213
README.TPL
1 Generic TPL framework 2 ===================== 3 4 Overview 5 -------- 6 7 TPL---Third Program Loader. 8 9 Due to the SPL on some boards(powerpc mpc85xx) has a size limit and cannot 10 be compatible with all the external device(e.g. DDR). So add a tertiary 11 program loader (TPL) to enable a loader stub loaded by the code from the 12 SPL. It loads the final uboot image into DDR, then jump to it to begin 13 execution. Now, only the powerpc mpc85xx has this requirement and will 14 implemente it. 15 16 Keep consistent with SPL, with this framework almost all source files for a 17 board can be reused. No code duplication or symlinking is necessary anymore. 18 19 How it works 20 ------------ 21 22 There has been a directory $(srctree)/spl which contains only a Makefile. The 23 Makefile is shared by SPL and TPL. 24 25 The object files are built separately for SPL/TPL and placed in the 26 directory spl/tpl. The final binaries which are generated are 27 u-boot-{spl|tpl}, u-boot-{spl|tpl}.bin and u-boot-{spl|tpl}.map. 28 29 During the TPL build a variable named CONFIG_TPL_BUILD is exported in the 30 make environment and also appended to CPPFLAGS with -DCONFIG_TPL_BUILD. 31 32 The SPL options are shared by SPL and TPL, the board config file should 33 determine which SPL options to choose based on whether CONFIG_TPL_BUILD 34 is set. Source files can be compiled for TPL with options choosed in the 35 board config file. 36 37 For example: 38 39 spl/Makefile: 40 LIBS-$(CONFIG_SPL_LIBCOMMON_SUPPORT) += common/libcommon.o 41 42 CONFIG_SPL_LIBCOMMON_SUPPORT is defined in board config file: 43 #ifdef CONFIG_TPL_BUILD 44 #define CONFIG_SPL_LIBCOMMON_SUPPORT 45 #endif 46
README.trace
1 # SPDX-License-Identifier: GPL-2.0+ 2 # 3 # Copyright (c) 2013 The Chromium OS Authors. 4 5 Tracing in U-Boot 6 ================= 7 8 U-Boot supports a simple tracing feature which allows a record of excecution 9 to be collected and sent to a host machine for analysis. At present the 10 main use for this is to profile boot time. 11 12 13 Overview 14 -------- 15 16 The trace feature uses GCC's instrument-functions feature to trace all 17 function entry/exit points. These are then recorded in a memory buffer. 18 The memory buffer can be saved to the host over a network link using 19 tftpput or by writing to an attached memory device such as MMC. 20 21 On the host, the file is first converted with a tool called 'proftool', 22 which extracts useful information from it. The resulting trace output 23 resembles that emitted by Linux's ftrace feature, so can be visually 24 displayed by pytimechart. 25 26 27 Quick-start using Sandbox 28 ------------------------- 29 30 Sandbox is a build of U-Boot that can run under Linux so it is a convenient 31 way of trying out tracing before you use it on your actual board. To do 32 this, follow these steps: 33 34 Add the following to include/configs/sandbox.h (if not already there) 35 36 #define CONFIG_TRACE 37 #define CONFIG_CMD_TRACE 38 #define CONFIG_TRACE_BUFFER_SIZE (16 << 20) 39 #define CONFIG_TRACE_EARLY_SIZE (8 << 20) 40 #define CONFIG_TRACE_EARLY 41 #define CONFIG_TRACE_EARLY_ADDR 0x00100000 42 43 Build sandbox U-Boot with tracing enabled: 44 45 $ make FTRACE=1 O=sandbox sandbox_config 46 $ make FTRACE=1 O=sandbox 47 48 Run sandbox, wait for a bit of trace information to appear, and then capture 49 a trace: 50 51 $ ./sandbox/u-boot 52 53 54 U-Boot 2013.04-rc2-00100-ga72fcef (Apr 17 2013 - 19:25:24) 55 56 DRAM: 128 MiB 57 trace: enabled 58 Using default environment 59 60 In: serial 61 Out: serial 62 Err: serial 63 =>trace stats 64 671,406 function sites 65 69,712 function calls 66 0 untracked function calls 67 73,373 traced function calls 68 16 maximum observed call depth 69 15 call depth limit 70 66,491 calls not traced due to depth 71 =>trace stats 72 671,406 function sites 73 1,279,450 function calls 74 0 untracked function calls 75 950,490 traced function calls (333217 dropped due to overflow) 76 16 maximum observed call depth 77 15 call depth limit 78 1,275,767 calls not traced due to depth 79 =>trace calls 0 e00000 80 Call list dumped to 00000000, size 0xae0a40 81 =>print 82 baudrate=115200 83 profbase=0 84 profoffset=ae0a40 85 profsize=e00000 86 stderr=serial 87 stdin=serial 88 stdout=serial 89 90 Environment size: 117/8188 bytes 91 =>sb save host 0 trace 0 ${profoffset} 92 11405888 bytes written in 10 ms (1.1 GiB/s) 93 =>reset 94 95 96 Then run proftool to convert the trace information to ftrace format. 97 98 $ ./sandbox/tools/proftool -m sandbox/System.map -p trace dump-ftrace >trace.txt 99 100 Finally run pytimechart to display it: 101 102 $ pytimechart trace.txt 103 104 Using this tool you can zoom and pan across the trace, with the function 105 calls on the left and little marks representing the start and end of each 106 function. 107 108 109 CONFIG Options 110 -------------- 111 112 - CONFIG_TRACE 113 Enables the trace feature in U-Boot. 114 115 - CONFIG_CMD_TRACE 116 Enables the trace command. 117 118 - CONFIG_TRACE_BUFFER_SIZE 119 Size of trace buffer to allocate for U-Boot. This buffer is 120 used after relocation, as a place to put function tracing 121 information. The address of the buffer is determined by 122 the relocation code. 123 124 - CONFIG_TRACE_EARLY 125 Define this to start tracing early, before relocation. 126 127 - CONFIG_TRACE_EARLY_SIZE 128 Size of 'early' trace buffer. Before U-Boot has relocated 129 it doesn't have a proper trace buffer. On many boards 130 you can define an area of memory to use for the trace 131 buffer until the 'real' trace buffer is available after 132 relocation. The contents of this buffer are then copied to 133 the real buffer. 134 135 - CONFIG_TRACE_EARLY_ADDR 136 Address of early trace buffer 137 138 139 Building U-Boot with Tracing Enabled 140 ------------------------------------ 141 142 Pass 'FTRACE=1' to the U-Boot Makefile to actually instrument the code. 143 This is kept as a separate option so that it is easy to enable/disable 144 instrumenting from the command line instead of having to change board 145 config files. 146 147 148 Collecting Trace Data 149 --------------------- 150 151 When you run U-Boot on your board it will collect trace data up to the 152 limit of the trace buffer size you have specified. Once that is exhausted 153 no more data will be collected. 154 155 Collecting trace data has an affect on execution time/performance. You 156 will notice this particularly with trvial functions - the overhead of 157 recording their execution may even exceed their normal execution time. 158 In practice this doesn't matter much so long as you are aware of the 159 effect. Once you have done your optimisations, turn off tracing before 160 doing end-to-end timing. 161 162 The best time to start tracing is right at the beginning of U-Boot. The 163 best time to stop tracing is right at the end. In practice it is hard 164 to achieve these ideals. 165 166 This implementation enables tracing early in board_init_f(). This means 167 that it captures most of the board init process, missing only the 168 early architecture-specific init. However, it also misses the entire 169 SPL stage if there is one. 170 171 U-Boot typically ends with a 'bootm' command which loads and runs an 172 OS. There is useful trace data in the execution of that bootm 173 command. Therefore this implementation provides a way to collect trace 174 data after bootm has finished processing, but just before it jumps to 175 the OS. In practical terms, U-Boot runs the 'fakegocmd' environment 176 variable at this point. This variable should have a short script which 177 collects the trace data and writes it somewhere. 178 179 Trace data collection relies on a microsecond timer, accesed through 180 timer_get_us(). So the first think you should do is make sure that 181 this produces sensible results for your board. Suitable sources for 182 this timer include high resolution timers, PWMs or profile timers if 183 available. Most modern SOCs have a suitable timer for this. Make sure 184 that you mark this timer (and anything it calls) with 185 __attribute__((no_instrument_function)) so that the trace library can 186 use it without causing an infinite loop. 187 188 189 Commands 190 -------- 191 192 The trace command has variable sub-commands: 193 194 - stats 195 Display tracing statistics 196 197 - pause 198 Pause tracing 199 200 - resume 201 Resume tracing 202 203 - funclist [<addr> <size>] 204 Dump a list of functions into the buffer 205 206 - calls [<addr> <size>] 207 Dump function call trace into buffer 208 209 If the address and size are not given, these are obtained from environment 210 variables (see below). In any case the environment variables are updated 211 after the command runs. 212 213 214 Environment Variables 215 --------------------- 216 217 The following are used: 218 219 - profbase 220 Base address of trace output buffer 221 222 - profoffset 223 Offset of first unwritten byte in trace output buffer 224 225 - profsize 226 Size of trace output buffer 227 228 All of these are set by the 'trace calls' command. 229 230 These variables keep track of the amount of data written to the trace 231 output buffer by the 'trace' command. The trace commands which write data 232 to the output buffer can use these to specify the buffer to write to, and 233 update profoffset each time. This allows successive commands to append data 234 to the same buffer, for example: 235 236 trace funclist 10000 e00000 237 trace calls 238 239 (the latter command appends more data to the buffer). 240 241 242 - fakegocmd 243 Specifies commands to run just before booting the OS. This 244 is a useful time to write the trace data to the host for 245 processing. 246 247 248 Writing Out Trace Data 249 ---------------------- 250 251 Once the trace data is in an output buffer in memory there are various ways 252 to transmit it to the host. Notably you can use tftput to send the data 253 over a network link: 254 255 fakegocmd=trace pause; usb start; set autoload n; bootp; 256 trace calls 10000000 1000000; 257 tftpput ${profbase} ${profoffset} 192.168.1.4:/tftpboot/calls 258 259 This starts up USB (to talk to an attached USB Ethernet dongle), writes 260 a trace log to address 10000000 and sends it to a host machine using 261 TFTP. After this, U-Boot will boot the OS normally, albeit a little 262 later. 263 264 265 Converting Trace Output Data 266 ---------------------------- 267 268 The trace output data is kept in a binary format which is not documented 269 here. To convert it into something useful, you can use proftool. 270 271 This tool must be given the U-Boot map file and the trace data received 272 from running that U-Boot. It produces a text output file. 273 274 Options 275 -m <map_file> 276 Specify U-Boot map file 277 278 -p <trace_file> 279 Specifiy profile/trace file 280 281 Commands: 282 283 - dump-ftrace 284 Write a text dump of the file in Linux ftrace format to stdout 285 286 287 Viewing the Trace Data 288 ---------------------- 289 290 You can use pytimechart for this (sudo apt-get pytimechart might work on 291 your Debian-style machine, and use your favourite search engine to obtain 292 documentation). It expects the file to have a .txt extension. The program 293 has terse user interface but is very convenient for viewing U-Boot 294 profile information. 295 296 297 Workflow Suggestions 298 -------------------- 299 300 The following suggestions may be helpful if you are trying to reduce boot 301 time: 302 303 1. Enable CONFIG_BOOTSTAGE and CONFIG_BOOTSTAGE_REPORT. This should get 304 you are helpful overall snapshot of the boot time. 305 306 2. Build U-Boot with tracing and run it. Note the difference in boot time 307 (it is common for tracing to add 10% to the time) 308 309 3. Collect the trace information as descibed above. Use this to find where 310 all the time is being spent. 311 312 4. Take a look at that code and see if you can optimise it. Perhaps it is 313 possible to speed up the initialisation of a device, or remove an unused 314 feature. 315 316 5. Rebuild, run and collect again. Compare your results. 317 318 6. Keep going until you run out of steam, or your boot is fast enough. 319 320 321 Configuring Trace 322 ----------------- 323 324 There are a few parameters in the code that you may want to consider. 325 There is a function call depth limit (set to 15 by default). When the 326 stack depth goes above this then no tracing information is recorded. 327 The maximum depth reached is recorded and displayed by the 'trace stats' 328 command. 329 330 331 Future Work 332 ----------- 333 334 Tracing could be a little tidier in some areas, for example providing 335 run-time configuration options for trace. 336 337 Some other features that might be useful: 338 339 - Trace filter to select which functions are recorded 340 - Sample-based profiling using a timer interrupt 341 - Better control over trace depth 342 - Compression of trace information 343 344 345 Simon Glass <sjg (a] chromium.org> 346 April 2013 347
README.u-boot_on_efi
1 # SPDX-License-Identifier: GPL-2.0+ 2 # 3 # Copyright (C) 2015 Google, Inc 4 5 U-Boot on EFI 6 ============= 7 This document provides information about U-Boot running on top of EFI, either 8 as an application or just as a means of getting U-Boot onto a new platform. 9 10 11 =========== Table of Contents =========== 12 13 Motivation 14 Status 15 Build Instructions 16 Trying it out 17 Inner workings 18 EFI Application 19 EFI Payload 20 Tables 21 Interrupts 22 32/64-bit 23 Future work 24 Where is the code? 25 26 27 Motivation 28 ---------- 29 Running U-Boot on EFI is useful in several situations: 30 31 - You have EFI running on a board but U-Boot does not natively support it 32 fully yet. You can boot into U-Boot from EFI and use that until U-Boot is 33 fully ported 34 35 - You need to use an EFI implementation (e.g. UEFI) because your vendor 36 requires it in order to provide support 37 38 - You plan to use coreboot to boot into U-Boot but coreboot support does 39 not currently exist for your platform. In the meantime you can use U-Boot 40 on EFI and then move to U-Boot on coreboot when ready 41 42 - You use EFI but want to experiment with a simpler alternative like U-Boot 43 44 45 Status 46 ------ 47 Only x86 is supported at present. If you are using EFI on another architecture 48 you may want to reconsider. However, much of the code is generic so could be 49 ported. 50 51 U-Boot supports running as an EFI application for 32-bit EFI only. This is 52 not very useful since only a serial port is provided. You can look around at 53 memory and type 'help' but that is about it. 54 55 More usefully, U-Boot supports building itself as a payload for either 32-bit 56 or 64-bit EFI. U-Boot is packaged up and loaded in its entirety by EFI. Once 57 started, U-Boot changes to 32-bit mode (currently) and takes over the 58 machine. You can use devices, boot a kernel, etc. 59 60 61 Build Instructions 62 ------------------ 63 First choose a board that has EFI support and obtain an EFI implementation 64 for that board. It will be either 32-bit or 64-bit. Alternatively, you can 65 opt for using QEMU [1] and the OVMF [2], as detailed below. 66 67 To build U-Boot as an EFI application (32-bit EFI required), enable CONFIG_EFI 68 and CONFIG_EFI_APP. The efi-x86_app config (efi-x86_app_defconfig) is set up 69 for this. Just build U-Boot as normal, e.g. 70 71 make efi-x86_app_defconfig 72 make 73 74 To build U-Boot as an EFI payload (32-bit or 64-bit EFI can be used), enable 75 CONFIG_EFI, CONFIG_EFI_STUB, and select either CONFIG_EFI_STUB_32BIT or 76 CONFIG_EFI_STUB_64BIT. The efi-x86_payload configs (efi-x86_payload32_defconfig 77 and efi-x86_payload32_defconfig) are set up for this. Then build U-Boot as 78 normal, e.g. 79 80 make efi-x86_payload32_defconfig (or efi-x86_payload64_defconfig) 81 make 82 83 You will end up with one of these files depending on what you build for: 84 85 u-boot-app.efi - U-Boot EFI application 86 u-boot-payload.efi - U-Boot EFI payload application 87 88 89 Trying it out 90 ------------- 91 QEMU is an emulator and it can emulate an x86 machine. Please make sure your 92 QEMU version is 2.3.0 or above to test this. You can run the payload with 93 something like this: 94 95 mkdir /tmp/efi 96 cp /path/to/u-boot*.efi /tmp/efi 97 qemu-system-x86_64 -bios bios.bin -hda fat:/tmp/efi/ 98 99 Add -nographic if you want to use the terminal for output. Once it starts 100 type 'fs0:u-boot-payload.efi' to run the payload or 'fs0:u-boot-app.efi' to 101 run the application. 'bios.bin' is the EFI 'BIOS'. Check [2] to obtain a 102 prebuilt EFI BIOS for QEMU or you can build one from source as well. 103 104 To try it on real hardware, put u-boot-app.efi on a suitable boot medium, 105 such as a USB stick. Then you can type something like this to start it: 106 107 fs0:u-boot-payload.efi 108 109 (or fs0:u-boot-app.efi for the application) 110 111 This will start the payload, copy U-Boot into RAM and start U-Boot. Note 112 that EFI does not support booting a 64-bit application from a 32-bit 113 EFI (or vice versa). Also it will often fail to print an error message if 114 you get this wrong. 115 116 117 Inner workings 118 ============== 119 Here follow a few implementation notes for those who want to fiddle with 120 this and perhaps contribute patches. 121 122 The application and payload approaches sound similar but are in fact 123 implemented completely differently. 124 125 EFI Application 126 --------------- 127 For the application the whole of U-Boot is built as a shared library. The 128 efi_main() function is in lib/efi/efi_app.c. It sets up some basic EFI 129 functions with efi_init(), sets up U-Boot global_data, allocates memory for 130 U-Boot's malloc(), etc. and enters the normal init sequence (board_init_f() 131 and board_init_r()). 132 133 Since U-Boot limits its memory access to the allocated regions very little 134 special code is needed. The CONFIG_EFI_APP option controls a few things 135 that need to change so 'git grep CONFIG_EFI_APP' may be instructive. 136 The CONFIG_EFI option controls more general EFI adjustments. 137 138 The only available driver is the serial driver. This calls back into EFI 139 'boot services' to send and receive characters. Although it is implemented 140 as a serial driver the console device is not necessarilly serial. If you 141 boot EFI with video output then the 'serial' device will operate on your 142 target devices's display instead and the device's USB keyboard will also 143 work if connected. If you have both serial and video output, then both 144 consoles will be active. Even though U-Boot does the same thing normally, 145 These are features of EFI, not U-Boot. 146 147 Very little code is involved in implementing the EFI application feature. 148 U-Boot is highly portable. Most of the difficulty is in modifying the 149 Makefile settings to pass the right build flags. In particular there is very 150 little x86-specific code involved - you can find most of it in 151 arch/x86/cpu. Porting to ARM (which can also use EFI if you are brave 152 enough) should be straightforward. 153 154 Use the 'reset' command to get back to EFI. 155 156 EFI Payload 157 ----------- 158 The payload approach is a different kettle of fish. It works by building 159 U-Boot exactly as normal for your target board, then adding the entire 160 image (including device tree) into a small EFI stub application responsible 161 for booting it. The stub application is built as a normal EFI application 162 except that it has a lot of data attached to it. 163 164 The stub application is implemented in lib/efi/efi_stub.c. The efi_main() 165 function is called by EFI. It is responsible for copying U-Boot from its 166 original location into memory, disabling EFI boot services and starting 167 U-Boot. U-Boot then starts as normal, relocates, starts all drivers, etc. 168 169 The stub application is architecture-dependent. At present it has some 170 x86-specific code and a comment at the top of efi_stub.c describes this. 171 172 While the stub application does allocate some memory from EFI this is not 173 used by U-Boot (the payload). In fact when U-Boot starts it has all of the 174 memory available to it and can operate as it pleases (but see the next 175 section). 176 177 Tables 178 ------ 179 The payload can pass information to U-Boot in the form of EFI tables. At 180 present this feature is used to pass the EFI memory map, an inordinately 181 large list of memory regions. You can use the 'efi mem all' command to 182 display this list. U-Boot uses the list to work out where to relocate 183 itself. 184 185 Although U-Boot can use any memory it likes, EFI marks some memory as used 186 by 'run-time services', code that hangs around while U-Boot is running and 187 is even present when Linux is running. This is common on x86 and provides 188 a way for Linux to call back into the firmware to control things like CPU 189 fan speed. U-Boot uses only 'conventional' memory, in EFI terminology. It 190 will relocate itself to the top of the largest block of memory it can find 191 below 4GB. 192 193 Interrupts 194 ---------- 195 U-Boot drivers typically don't use interrupts. Since EFI enables interrupts 196 it is possible that an interrupt will fire that U-Boot cannot handle. This 197 seems to cause problems. For this reason the U-Boot payload runs with 198 interrupts disabled at present. 199 200 32/64-bit 201 --------- 202 While the EFI application can in principle be built as either 32- or 64-bit, 203 only 32-bit is currently supported. This means that the application can only 204 be used with 32-bit EFI. 205 206 The payload stub can be build as either 32- or 64-bits. Only a small amount 207 of code is built this way (see the extra- line in lib/efi/Makefile). 208 Everything else is built as a normal U-Boot, so is always 32-bit on x86 at 209 present. 210 211 Future work 212 ----------- 213 This work could be extended in a number of ways: 214 215 - Add ARM support 216 217 - Add 64-bit application support 218 219 - Figure out how to solve the interrupt problem 220 221 - Add more drivers to the application side (e.g. video, block devices, USB, 222 environment access). This would mostly be an academic exercise as a strong 223 use case is not readily apparent, but it might be fun. 224 225 - Avoid turning off boot services in the stub. Instead allow U-Boot to make 226 use of boot services in case it wants to. It is unclear what it might want 227 though. 228 229 Where is the code? 230 ------------------ 231 lib/efi 232 payload stub, application, support code. Mostly arch-neutral 233 234 arch/x86/cpu/efi 235 x86 support code for running as an EFI application and payload 236 237 board/efi/efi-x86_app/efi.c 238 x86 board code for running as an EFI application 239 240 board/efi/efi-x86_payload 241 generic x86 EFI payload board support code 242 243 common/cmd_efi.c 244 the 'efi' command 245 246 -- 247 Ben Stoltz, Simon Glass 248 Google, Inc 249 July 2015 250 251 [1] http://www.qemu.org 252 [2] http://www.tianocore.org/ovmf/ 253
README.ubi
1 ------------------- 2 UBI usage in U-Boot 3 ------------------- 4 5 UBI support in U-Boot is broken down into five separate commands. 6 The first is the ubi command, which has six subcommands: 7 8 => help ubi 9 ubi - ubi commands 10 11 Usage: 12 ubi part [part] [offset] 13 - Show or set current partition (with optional VID header offset) 14 ubi info [l[ayout]] - Display volume and ubi layout information 15 ubi create[vol] volume [size] [type] - create volume name with size 16 ubi write[vol] address volume size - Write volume from address with size 17 ubi write.part address volume size [fullsize] 18 - Write part of a volume from address 19 ubi read[vol] address volume [size] - Read volume to address with size 20 ubi remove[vol] volume - Remove volume 21 [Legends] 22 volume: character name 23 size: specified in bytes 24 type: s[tatic] or d[ynamic] (default=dynamic) 25 26 27 The first command that is needed to be issues is "ubi part" to connect 28 one mtd partition to the UBI subsystem. This command will either create 29 a new UBI device on the requested MTD partition. Or it will attach a 30 previously created UBI device. The other UBI commands will only work 31 when such a UBI device is attached (via "ubi part"). Here an example: 32 33 => mtdparts 34 35 device nor0 <1fc000000.nor_flash>, # parts = 6 36 #: name size offset mask_flags 37 0: kernel 0x00200000 0x00000000 0 38 1: dtb 0x00040000 0x00200000 0 39 2: root 0x00200000 0x00240000 0 40 3: user 0x01ac0000 0x00440000 0 41 4: env 0x00080000 0x01f00000 0 42 5: u-boot 0x00080000 0x01f80000 0 43 44 active partition: nor0,0 - (kernel) 0x00200000 @ 0x00000000 45 46 defaults: 47 mtdids : nor0=1fc000000.nor_flash 48 mtdparts: mtdparts=1fc000000.nor_flash:2m(kernel),256k(dtb),2m(root),27392k(user),512k(env),512k(u-boot) 49 50 => ubi part root 51 Creating 1 MTD partitions on "nor0": 52 0x000000240000-0x000000440000 : "mtd=2" 53 UBI: attaching mtd1 to ubi0 54 UBI: physical eraseblock size: 262144 bytes (256 KiB) 55 UBI: logical eraseblock size: 262016 bytes 56 UBI: smallest flash I/O unit: 1 57 UBI: VID header offset: 64 (aligned 64) 58 UBI: data offset: 128 59 UBI: attached mtd1 to ubi0 60 UBI: MTD device name: "mtd=2" 61 UBI: MTD device size: 2 MiB 62 UBI: number of good PEBs: 8 63 UBI: number of bad PEBs: 0 64 UBI: max. allowed volumes: 128 65 UBI: wear-leveling threshold: 4096 66 UBI: number of internal volumes: 1 67 UBI: number of user volumes: 1 68 UBI: available PEBs: 0 69 UBI: total number of reserved PEBs: 8 70 UBI: number of PEBs reserved for bad PEB handling: 0 71 UBI: max/mean erase counter: 2/1 72 73 74 Now that the UBI device is attached, this device can be modified 75 using the following commands: 76 77 ubi info Display volume and ubi layout information 78 ubi createvol Create UBI volume on UBI device 79 ubi removevol Remove UBI volume from UBI device 80 ubi read Read data from UBI volume to memory 81 ubi write Write data from memory to UBI volume 82 ubi write.part Write data from memory to UBI volume, in parts 83 84 85 Here a few examples on the usage: 86 87 => ubi create testvol 88 Creating dynamic volume testvol of size 1048064 89 90 => ubi info l 91 UBI: volume information dump: 92 UBI: vol_id 0 93 UBI: reserved_pebs 4 94 UBI: alignment 1 95 UBI: data_pad 0 96 UBI: vol_type 3 97 UBI: name_len 7 98 UBI: usable_leb_size 262016 99 UBI: used_ebs 4 100 UBI: used_bytes 1048064 101 UBI: last_eb_bytes 262016 102 UBI: corrupted 0 103 UBI: upd_marker 0 104 UBI: name testvol 105 106 UBI: volume information dump: 107 UBI: vol_id 2147479551 108 UBI: reserved_pebs 2 109 UBI: alignment 1 110 UBI: data_pad 0 111 UBI: vol_type 3 112 UBI: name_len 13 113 UBI: usable_leb_size 262016 114 UBI: used_ebs 2 115 UBI: used_bytes 524032 116 UBI: last_eb_bytes 2 117 UBI: corrupted 0 118 UBI: upd_marker 0 119 UBI: name layout volume 120 121 => ubi info 122 UBI: MTD device name: "mtd=2" 123 UBI: MTD device size: 2 MiB 124 UBI: physical eraseblock size: 262144 bytes (256 KiB) 125 UBI: logical eraseblock size: 262016 bytes 126 UBI: number of good PEBs: 8 127 UBI: number of bad PEBs: 0 128 UBI: smallest flash I/O unit: 1 129 UBI: VID header offset: 64 (aligned 64) 130 UBI: data offset: 128 131 UBI: max. allowed volumes: 128 132 UBI: wear-leveling threshold: 4096 133 UBI: number of internal volumes: 1 134 UBI: number of user volumes: 1 135 UBI: available PEBs: 0 136 UBI: total number of reserved PEBs: 8 137 UBI: number of PEBs reserved for bad PEB handling: 0 138 UBI: max/mean erase counter: 4/1 139 140 => ubi write 800000 testvol 80000 141 Volume "testvol" found at volume id 0 142 143 => ubi read 900000 testvol 80000 144 Volume testvol found at volume id 0 145 read 524288 bytes from volume 0 to 900000(buf address) 146 147 => cmp.b 800000 900000 80000 148 Total of 524288 bytes were the same 149 150 151 Next, the ubifsmount command allows you to access filesystems on the 152 UBI partition which has been attached with the ubi part command: 153 154 => help ubifsmount 155 ubifsmount - mount UBIFS volume 156 157 Usage: 158 ubifsmount <volume-name> 159 - mount 'volume-name' volume 160 161 For example: 162 163 => ubifsmount ubi0:recovery 164 UBIFS: mounted UBI device 0, volume 0, name "recovery" 165 UBIFS: mounted read-only 166 UBIFS: file system size: 46473216 bytes (45384 KiB, 44 MiB, 366 LEBs) 167 UBIFS: journal size: 6348800 bytes (6200 KiB, 6 MiB, 50 LEBs) 168 UBIFS: media format: w4/r0 (latest is w4/r0) 169 UBIFS: default compressor: LZO 170 UBIFS: reserved for root: 0 bytes (0 KiB) 171 172 Note that unlike Linux, U-Boot can only have one active UBI partition 173 at a time, which can be referred to as ubi0, and must be supplied along 174 with the name of the filesystem you are mounting. 175 176 177 Once a UBI filesystem has been mounted, the ubifsls command allows you 178 to list the contents of a directory in the filesystem: 179 180 181 => help ubifsls 182 ubifsls - list files in a directory 183 184 Usage: 185 ubifsls [directory] 186 - list files in a 'directory' (default '/') 187 188 For example: 189 190 => ubifsls 191 17442 Thu Jan 01 02:57:38 1970 imx28-evk.dtb 192 2998146 Thu Jan 01 02:57:43 1970 zImage 193 194 195 And the ubifsload command allows you to load a file from a UBI 196 filesystem: 197 198 199 => help ubifsload 200 ubifsload - load file from an UBIFS filesystem 201 202 Usage: 203 ubifsload <addr> <filename> [bytes] 204 - load file 'filename' to address 'addr' 205 206 For example: 207 208 => ubifsload ${loadaddr} zImage 209 Loading file 'zImage' to addr 0x42000000 with size 2998146 (0x002dbf82)... 210 Done 211 212 213 Finally, you can unmount the UBI filesystem with the ubifsumount 214 command: 215 216 => help ubifsumount 217 ubifsumount - unmount UBIFS volume 218 219 Usage: 220 ubifsumount - unmount current volume 221 222 For example: 223 224 => ubifsumount 225 Unmounting UBIFS volume recovery! 226
README.ubispl
1 Lightweight UBI and UBI fastmap support 2 3 # Copyright (C) Thomas Gleixner <tglx (a] linutronix.de> 4 # 5 # SPDX-License-Identifier: GPL 2.0+ BSD-3-Clause 6 7 Scans the UBI information and loads the requested static volumes into 8 memory. 9 10 Configuration Options: 11 12 CONFIG_SPL_UBI 13 Enables the SPL UBI support 14 15 CONFIG_SPL_UBI_MAX_VOL_LEBS 16 The maximum number of logical eraseblocks which a static volume 17 to load can contain. Used for sizing the scan data structure 18 19 CONFIG_SPL_UBI_MAX_PEB_SIZE 20 The maximum physical erase block size. Either a compile time 21 constant or runtime detection. Used for sizing the scan data 22 structure 23 24 CONFIG_SPL_UBI_MAX_PEBS 25 The maximum physical erase block count. Either a compile time 26 constant or runtime detection. Used for sizing the scan data 27 structure 28 29 CONFIG_SPL_UBI_VOL_IDS 30 The maximum volume ids which can be loaded. Used for sizing the 31 scan data structure. 32 33 Usage notes: 34 35 In the board config file define for example: 36 37 #define CONFIG_SPL_UBI 38 #define CONFIG_SPL_UBI_MAX_VOL_LEBS 256 39 #define CONFIG_SPL_UBI_MAX_PEB_SIZE (256*1024) 40 #define CONFIG_SPL_UBI_MAX_PEBS 4096 41 #define CONFIG_SPL_UBI_VOL_IDS 8 42 43 The size requirement is roughly as follows: 44 45 2k for the basic data structure 46 + CONFIG_SPL_UBI_VOL_IDS * CONFIG_SPL_UBI_MAX_VOL_LEBS * 8 47 + CONFIG_SPL_UBI_MAX_PEBS * 64 48 + CONFIG_SPL_UBI_MAX_PEB_SIZE * UBI_FM_MAX_BLOCKS 49 50 The last one is big, but I really don't care in that stage. Real world 51 implementations only use the first couple of blocks, but the code 52 handles up to UBI_FM_MAX_BLOCKS. 53 54 Given the above configuration example the requirement is about 5M 55 which is usually not a problem to reserve in the RAM along with the 56 other areas like the kernel/dts load address. 57 58 So something like this will do the trick: 59 60 #define SPL_FINFO_ADDR 0x80800000 61 #define SPL_DTB_LOAD_ADDR 0x81800000 62 #define SPL_KERNEL_LOAD_ADDR 0x82000000 63 64 In the board file, implement the following: 65 66 static struct ubispl_load myvolumes[] = { 67 { 68 .vol_id = 0, /* kernel volume */ 69 .load_addr = (void *)SPL_KERNEL_LOAD_ADDR, 70 }, 71 { 72 .vol_id = 1, /* DT blob */ 73 .load_addr = (void *)SPL_DTB_LOAD_ADDR, 74 } 75 }; 76 77 int spl_start_uboot(void) 78 { 79 struct ubispl_info info; 80 81 info.ubi = (struct ubi_scan_info *) SPL_FINFO_ADDR; 82 info.fastmap = 1; 83 info.read = nand_spl_read_flash; 84 85 #if COMPILE_TIME_DEFINED 86 /* 87 * MY_NAND_NR_SPL_PEBS is the number of physical erase blocks 88 * in the FLASH which are reserved for the SPL. Think about 89 * mtd partitions: 90 * 91 * part_spl { .start = 0, .end = 4 } 92 * part_ubi { .start = 4, .end = NR_PEBS } 93 */ 94 info.peb_offset = MY_NAND_NR_SPL_PEBS; 95 info.peb_size = CONFIG_SYS_NAND_BLOCK_SIZE; 96 info.vid_offset = MY_NAND_UBI_VID_OFFS; 97 info.leb_start = MY_NAND_UBI_DATA_OFFS; 98 info.peb_count = MY_NAND_UBI_NUM_PEBS; 99 #else 100 get_flash_info(&flash_info); 101 info.peb_offset = MY_NAND_NR_SPL_PEBS; 102 info.peb_size = flash_info.peb_size; 103 104 /* 105 * The VID and Data offset depend on the capability of the 106 * FLASH chip to do subpage writes. 107 * 108 * If the flash chip supports subpage writes, then the VID 109 * header starts at the second subpage. So for 2k pages size 110 * with 4 subpages the VID offset is 512. The DATA offset is 2k. 111 * 112 * If the flash chip does not support subpage writes then the 113 * VID offset is FLASH_PAGE_SIZE and the DATA offset 114 * 2 * FLASH_PAGE_SIZE 115 */ 116 info.vid_offset = flash_info.vid_offset; 117 info.leb_start = flash_info.data_offset; 118 119 /* 120 * The flash reports the total number of erase blocks, so 121 * we need to subtract the number of blocks which are reserved 122 * for the SPL itself and not managed by UBI. 123 */ 124 info.peb_count = flash_info.peb_count - MY_NAND_NR_SPL_PEBS; 125 #endif 126 127 ret = ubispl_load_volumes(&info, myvolumes, ARRAY_SIZE(myvolumes); 128 129 .... 130 131 } 132 133 Note: you can load any payload that way. You can even load u-boot from 134 UBI, so the only non UBI managed FLASH area is the one which is 135 reserved for the SPL itself and read from the SoC ROM. 136 137 And you can do fallback scenarios: 138 139 if (ubispl_load_volumes(&info, volumes0, ARRAY_SIZE(volumes0))) 140 if (ubispl_load_volumes(&info, volumes1, ARRAY_SIZE(volumes1))) 141 ubispl_load_volumes(&info, vol_uboot, ARRAY_SIZE(vol_uboot)); 142
README.ublimage
1 --------------------------------------------- 2 UBL image Boot Image generation using mkimage 3 --------------------------------------------- 4 5 This document describes how to set up an U-Boot image that can be directly 6 booted by a DaVinci processor via NAND boot mode, using an UBL header, 7 but without need for UBL. 8 9 For more details see section 11.2 "ARM ROM Boot Modes" of 10 http://focus.ti.com/lit/ug/sprufg5a/sprufg5a.pdf 11 12 Command syntax: 13 -------------- 14 ./tools/mkimage -l <u-boot_file> 15 to list the UBL image file details 16 17 ./tools/mkimage -T ublimage \ 18 -n <board specific configuration file> \ 19 -d <u-boot binary> <output image file> 20 21 For example, for the davinci dm365evm board: 22 ./tools/mkimage -n ./board/davinci/dm365evm/ublimage.cfg \ 23 -T ublimage \ 24 -d u-boot-nand.bin u-boot.ubl 25 26 You can generate the image directly when you compile u-boot with: 27 28 $ make u-boot.ubl 29 30 The output image can be flashed into the NAND. 31 32 Please check the DaVinci documentation for further details. 33 34 Board specific configuration file specifications: 35 ------------------------------------------------- 36 1. This file must present in the $(BOARDDIR) and the name should be 37 ublimage.cfg (since this is used in Makefile). 38 2. This file can have empty lines and lines starting with "#" as first 39 character to put comments. 40 3. This file can have configuration command lines as mentioned below, 41 any other information in this file is treated as invalid. 42 43 Configuration command line syntax: 44 --------------------------------- 45 1. Each command line must have two strings, first one command or address 46 and second one data string 47 2. Following are the valid command strings and associated data strings:- 48 Command string data string 49 -------------- ----------- 50 MODE UBL special mode, on of: 51 safe 52 Example: 53 MODE safe 54 55 ENTRY Entry point address for the user 56 bootloader (absolute address) = TEXT_BASE 57 nand_spl loader. 58 Example: 59 ENTRY 0x00000020 60 61 PAGES Number of pages (size of user bootloader 62 in number of pages) 63 Example: 64 PAGES 27 65 66 START_BLOCK Block number where user bootloader is present 67 Example: 68 START_BLOCK 5 69 70 START_PAGE Page number where user bootloader is present 71 (for RBL always 0) 72 Example: 73 START_PAGE 0 74 75 ------------------------------------------------ 76 77 Structure of the u-boot.ubl binary: 78 79 compile steps: 80 81 1) nand_spl code compile, with pad_to = (TEXT_BASE + 82 (CONFIG_SYS_NROF_PAGES_NAND_SPL * pagesize)) 83 Example: cam_enc_4xx pad_to = 0x20 + (6 * 0x800) = 0x3020 = 12320 84 -> u-boot-spl-16k.bin 85 86 !! TEXT_BASE = 0x20, as the RBL starts at 0x20 87 88 2) compile u-boot.bin ("normal" u-boot) 89 -> u-boot.bin 90 91 3) create u-boot-nand.bin = u-boot-spl-16k.bin + u-boot.bin 92 93 4) create u-boot.ubl, size = 1 page size NAND 94 create UBL header and paste it before u-boot.bin 95 96 This steps are done automagically if you do a "make all" 97 98 -> You get an u-boot.ubl binary, which you can flash 99 into your NAND. 100 101 Structure of this binary (Example for the cam_enc_4xx board with a NAND 102 page size = 0x800): 103 104 offset : 0x00000 | 0x800 | 0x3800 105 content: UBL | nand_spl | u-boot code 106 Header | code | 107 108 The NAND layout looks for example like this: 109 110 (Example for the cam_enc_4xx board with a NAND page size = 0x800, block 111 size = 0x20000 and CONFIG_SYS_NROF_UBL_HEADER 5): 112 113 offset : 0x80000 | 0xa0000 | 0xa3000 114 content: UBL | nand_spl | u-boot code 115 Header | code | 116 ^ ^ 117 ^ 0xa0000 = CONFIG_SYS_NROF_UBL_HEADER * 0x20000 118 ^ 119 0x80000 = Block 4 * 0x20000 120 121 If the cpu starts in NAND boot mode, it checks the UBL descriptor 122 starting with block 1 (page 0). When a valid UBL signature is found, 123 the corresponding block number (from 1 to 24) is written to the last 32 124 bits of ARM internal memory (0x7ffc-0x8000). This feature is provided 125 as a basic debug mechanism. If not found, it continues with block 2 126 ... last possible block is 24 127 128 If a valid UBL descriptor is found, the UBL descriptor is read and 129 processed. The descriptor gives the information required for loading 130 and control transfer to the nand_spl code. The nand_spl code is then 131 read and processed. 132 133 Once the user-specified start-up conditions are set, the RBL copies the 134 nand_spl into ARM internal RAM, starting at address 0x0000: 0020. 135 ^^^^ 136 137 The nand_spl code itself now does necessary intializations, and at least, 138 copies the u-boot code from NAND into RAM, and jumps to it ... 139 140 ------------------------------------------------ 141 Author: Heiko Schocher <hs (a] denx.de> 142
README.uefi
1 <!-- 2 SPDX-License-Identifier: GPL-2.0+ 3 4 Copyright (c) 2018 Heinrich Schuchardt 5 --> 6 7 # UEFI on U-Boot 8 9 The Unified Extensible Firmware Interface Specification (UEFI) [1] has become 10 the default for booting on AArch64 and x86 systems. It provides a stable API for 11 the interaction of drivers and applications with the firmware. The API comprises 12 access to block storage, network, and console to name a few. The Linux kernel 13 and boot loaders like GRUB or the FreeBSD loader can be executed. 14 15 ## Building for UEFI 16 17 The UEFI standard supports only little endian systems. The UEFI support can be 18 activated for ARM and x86 by specifying 19 20 CONFIG_CMD_BOOTEFI=y 21 CONFIG_EFI_LOADER=y 22 23 in the .config file. 24 25 Support for attaching virtual block devices, e.g. iSCSI drives connected by the 26 loaded UEFI application [3], requires 27 28 CONFIG_BLK=y 29 CONFIG_PARTITIONS=y 30 31 ### Executing a UEFI binary 32 33 The bootefi command is used to start UEFI applications or to install UEFI 34 drivers. It takes two parameters 35 36 bootefi <image address> [fdt address] 37 38 * image address - the memory address of the UEFI binary 39 * fdt address - the memory address of the flattened device tree 40 41 Below you find the output of an example session starting GRUB. 42 43 => load mmc 0:2 ${fdt_addr_r} boot/dtb 44 29830 bytes read in 14 ms (2 MiB/s) 45 => load mmc 0:1 ${kernel_addr_r} efi/debian/grubaa64.efi 46 reading efi/debian/grubaa64.efi 47 120832 bytes read in 7 ms (16.5 MiB/s) 48 => bootefi ${kernel_addr_r} ${fdt_addr_r} 49 50 The environment variable 'bootargs' is passed as load options in the UEFI system 51 table. The Linux kernel EFI stub uses the load options as command line 52 arguments. 53 54 ### Executing the boot manager 55 56 The UEFI specfication foresees to define boot entries and boot sequence via UEFI 57 variables. Booting according to these variables is possible via 58 59 bootefi bootmgr [fdt address] 60 61 As of U-Boot v2018.03 UEFI variables are not persisted and cannot be set at 62 runtime. 63 64 ### Executing the built in hello world application 65 66 A hello world UEFI application can be built with 67 68 CONFIG_CMD_BOOTEFI_HELLO_COMPILE=y 69 70 It can be embedded into the U-Boot binary with 71 72 CONFIG_CMD_BOOTEFI_HELLO=y 73 74 The bootefi command is used to start the embedded hello world application. 75 76 bootefi hello [fdt address] 77 78 Below you find the output of an example session. 79 80 => bootefi hello ${fdtcontroladdr} 81 ## Starting EFI application at 01000000 ... 82 WARNING: using memory device/image path, this may confuse some payloads! 83 Hello, world! 84 Running on UEFI 2.7 85 Have SMBIOS table 86 Have device tree 87 Load options: root=/dev/sdb3 init=/sbin/init rootwait ro 88 ## Application terminated, r = 0 89 90 The environment variable fdtcontroladdr points to U-Boot's internal device tree 91 (if available). 92 93 ### Executing the built-in selftest 94 95 An UEFI selftest suite can be embedded in U-Boot by building with 96 97 CONFIG_CMD_BOOTEFI_SELFTEST=y 98 99 For testing the UEFI implementation the bootefi command can be used to start the 100 selftest. 101 102 bootefi selftest [fdt address] 103 104 The environment variable 'efi_selftest' can be used to select a single test. If 105 it is not provided all tests are executed except those marked as 'on request'. 106 If the environment variable is set to 'list' a list of all tests is shown. 107 108 Below you can find the output of an example session. 109 110 => setenv efi_selftest simple network protocol 111 => bootefi selftest 112 Testing EFI API implementation 113 Selected test: 'simple network protocol' 114 Setting up 'simple network protocol' 115 Setting up 'simple network protocol' succeeded 116 Executing 'simple network protocol' 117 DHCP Discover 118 DHCP reply received from 192.168.76.2 (52:55:c0:a8:4c:02) 119 as broadcast message. 120 Executing 'simple network protocol' succeeded 121 Tearing down 'simple network protocol' 122 Tearing down 'simple network protocol' succeeded 123 Boot services terminated 124 Summary: 0 failures 125 Preparing for reset. Press any key. 126 127 ## The UEFI life cycle 128 129 After the U-Boot platform has been initialized the UEFI API provides two kinds 130 of services 131 132 * boot services and 133 * runtime services. 134 135 The API can be extended by loading UEFI drivers which come in two variants 136 137 * boot drivers and 138 * runtime drivers. 139 140 UEFI drivers are installed with U-Boot's bootefi command. With the same command 141 UEFI applications can be executed. 142 143 Loaded images of UEFI drivers stay in memory after returning to U-Boot while 144 loaded images of applications are removed from memory. 145 146 An UEFI application (e.g. an operating system) that wants to take full control 147 of the system calls ExitBootServices. After a UEFI application calls 148 ExitBootServices 149 150 * boot services are not available anymore 151 * timer events are stopped 152 * the memory used by U-Boot except for runtime services is released 153 * the memory used by boot time drivers is released 154 155 So this is a point of no return. Afterwards the UEFI application can only return 156 to U-Boot by rebooting. 157 158 ## The UEFI object model 159 160 UEFI offers a flexible and expandable object model. The objects in the UEFI API 161 are devices, drivers, and loaded images. These objects are referenced by 162 handles. 163 164 The interfaces implemented by the objects are referred to as protocols. These 165 are identified by GUIDs. They can be installed and uninstalled by calling the 166 appropriate boot services. 167 168 Handles are created by the InstallProtocolInterface or the 169 InstallMultipleProtocolinterfaces service if NULL is passed as handle. 170 171 Handles are deleted when the last protocol has been removed with the 172 UninstallProtocolInterface or the UninstallMultipleProtocolInterfaces service. 173 174 Devices offer the EFI_DEVICE_PATH_PROTOCOL. A device path is the concatenation 175 of device nodes. By their device paths all devices of a system are arranged in a 176 tree. 177 178 Drivers offer the EFI_DRIVER_BINDING_PROTOCOL. This protocol is used to connect 179 a driver to devices (which are referenced as controllers in this context). 180 181 Loaded images offer the EFI_LOADED_IMAGE_PROTOCOL. This protocol provides meta 182 information about the image and a pointer to the unload callback function. 183 184 ## The UEFI events 185 186 In the UEFI terminology an event is a data object referencing a notification 187 function which is queued for calling when the event is signaled. The following 188 types of events exist: 189 190 * periodic and single shot timer events 191 * exit boot services events, triggered by calling the ExitBootServices() service 192 * virtual address change events 193 * memory map change events 194 * read to boot events 195 * reset system events 196 * system table events 197 * events that are only triggered programmatically 198 199 Events can be created with the CreateEvent service and deleted with CloseEvent 200 service. 201 202 Events can be assigned to an event group. If any of the events in a group is 203 signaled, all other events in the group are also set to the signaled state. 204 205 ## The UEFI driver model 206 207 A driver is specific for a single protocol installed on a device. To install a 208 driver on a device the ConnectController service is called. In this context 209 controller refers to the device for which the driver is installed. 210 211 The relevant drivers are identified using the EFI_DRIVER_BINDING_PROTOCOL. This 212 protocol has has three functions: 213 214 * supported - determines if the driver is compatible with the device 215 * start - installs the driver by opening the relevant protocol with 216 attribute EFI_OPEN_PROTOCOL_BY_DRIVER 217 * stop - uninstalls the driver 218 219 The driver may create child controllers (child devices). E.g. a driver for block 220 IO devices will create the device handles for the partitions. The child 221 controllers will open the supported protocol with the attribute 222 EFI_OPEN_PROTOCOL_BY_CHILD_CONTROLLER. 223 224 A driver can be detached from a device using the DisconnectController service. 225 226 ## U-Boot devices mapped as UEFI devices 227 228 Some of the U-Boot devices are mapped as UEFI devices 229 230 * block IO devices 231 * console 232 * graphical output 233 * network adapter 234 235 As of U-Boot 2018.03 the logic for doing this is hard coded. 236 237 The development target is to integrate the setup of these UEFI devices with the 238 U-Boot driver model. So when a U-Boot device is discovered a handle should be 239 created and the device path protocol and the relevant IO protocol should be 240 installed. The UEFI driver then would be attached by calling ConnectController. 241 When a U-Boot device is removed DisconnectController should be called. 242 243 ## UEFI devices mapped as U-Boot devices 244 245 UEFI drivers binaries and applications may create new (virtual) devices, install 246 a protocol and call the ConnectController service. Now the matching UEFI driver 247 is determined by iterating over the implementations of the 248 EFI_DRIVER_BINDING_PROTOCOL. 249 250 It is the task of the UEFI driver to create a corresponding U-Boot device and to 251 proxy calls for this U-Boot device to the controller. 252 253 In U-Boot 2018.03 this has only been implemented for block IO devices. 254 255 ### UEFI uclass 256 257 An UEFI uclass driver (lib/efi_driver/efi_uclass.c) has been created that 258 takes care of initializing the UEFI drivers and providing the 259 EFI_DRIVER_BINDING_PROTOCOL implementation for the UEFI drivers. 260 261 A linker created list is used to keep track of the UEFI drivers. To create an 262 entry in the list the UEFI driver uses the U_BOOT_DRIVER macro specifying 263 UCLASS_EFI as the ID of its uclass, e.g. 264 265 /* Identify as UEFI driver */ 266 U_BOOT_DRIVER(efi_block) = { 267 .name = "EFI block driver", 268 .id = UCLASS_EFI, 269 .ops = &driver_ops, 270 }; 271 272 The available operations are defined via the structure struct efi_driver_ops. 273 274 struct efi_driver_ops { 275 const efi_guid_t *protocol; 276 const efi_guid_t *child_protocol; 277 int (*bind)(efi_handle_t handle, void *interface); 278 }; 279 280 When the supported() function of the EFI_DRIVER_BINDING_PROTOCOL is called the 281 uclass checks if the protocol GUID matches the protocol GUID of the UEFI driver. 282 In the start() function the bind() function of the UEFI driver is called after 283 checking the GUID. 284 The stop() function of the EFI_DRIVER_BINDING_PROTOCOL disconnects the child 285 controllers created by the UEFI driver and the UEFI driver. (In U-Boot v2013.03 286 this is not yet completely implemented.) 287 288 ### UEFI block IO driver 289 290 The UEFI block IO driver supports devices exposing the EFI_BLOCK_IO_PROTOCOL. 291 292 When connected it creates a new U-Boot block IO device with interface type 293 IF_TYPE_EFI, adds child controllers mapping the partitions, and installs the 294 EFI_SIMPLE_FILE_SYSTEM_PROTOCOL on these. This can be used together with the 295 software iPXE to boot from iSCSI network drives [3]. 296 297 This driver is only available if U-Boot is configured with 298 299 CONFIG_BLK=y 300 CONFIG_PARTITIONS=y 301 302 ## TODOs as of U-Boot 2018.07 303 304 * unimplemented or incompletely implemented boot services 305 * Exit - call unload function, unload applications only 306 * ProtocolRegisterNotify 307 * UnloadImage 308 309 * unimplemented or incompletely implemented runtime services 310 * SetVariable() ignores attribute EFI_VARIABLE_APPEND_WRITE 311 * GetNextVariableName is not implemented 312 * QueryVariableInfo is not implemented 313 314 * unimplemented events 315 * EVT_RUNTIME 316 * EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE 317 * event groups 318 319 * data model 320 * manage events in a linked list 321 * manage configuration tables in a linked list 322 323 * UEFI drivers 324 * support DisconnectController for UEFI block devices. 325 326 * support for CONFIG_EFI_LOADER in the sandbox (CONFIG_SANDBOX=y) 327 328 * UEFI variables 329 * persistence 330 * runtime support 331 332 * support bootefi booting ARMv7 in non-secure mode (CONFIG_ARMV7_NONSEC=y) 333 334 ## Links 335 336 * [1](http://uefi.org/specifications) 337 http://uefi.org/specifications - UEFI specifications 338 * [2](./driver-model/README.txt) doc/driver-model/README.txt - Driver model 339 * [3](./README.iscsi) doc/README.iscsi - iSCSI booting with U-Boot and iPXE 340
README.unaligned-memory-access.txt
1 Editors note: This document is _heavily_ cribbed from the Linux Kernel, with 2 really only the section about "Alignment vs. Networking" removed. 3 4 UNALIGNED MEMORY ACCESSES 5 ========================= 6 7 Linux runs on a wide variety of architectures which have varying behaviour 8 when it comes to memory access. This document presents some details about 9 unaligned accesses, why you need to write code that doesn't cause them, 10 and how to write such code! 11 12 13 The definition of an unaligned access 14 ===================================== 15 16 Unaligned memory accesses occur when you try to read N bytes of data starting 17 from an address that is not evenly divisible by N (i.e. addr % N != 0). 18 For example, reading 4 bytes of data from address 0x10004 is fine, but 19 reading 4 bytes of data from address 0x10005 would be an unaligned memory 20 access. 21 22 The above may seem a little vague, as memory access can happen in different 23 ways. The context here is at the machine code level: certain instructions read 24 or write a number of bytes to or from memory (e.g. movb, movw, movl in x86 25 assembly). As will become clear, it is relatively easy to spot C statements 26 which will compile to multiple-byte memory access instructions, namely when 27 dealing with types such as u16, u32 and u64. 28 29 30 Natural alignment 31 ================= 32 33 The rule mentioned above forms what we refer to as natural alignment: 34 When accessing N bytes of memory, the base memory address must be evenly 35 divisible by N, i.e. addr % N == 0. 36 37 When writing code, assume the target architecture has natural alignment 38 requirements. 39 40 In reality, only a few architectures require natural alignment on all sizes 41 of memory access. However, we must consider ALL supported architectures; 42 writing code that satisfies natural alignment requirements is the easiest way 43 to achieve full portability. 44 45 46 Why unaligned access is bad 47 =========================== 48 49 The effects of performing an unaligned memory access vary from architecture 50 to architecture. It would be easy to write a whole document on the differences 51 here; a summary of the common scenarios is presented below: 52 53 - Some architectures are able to perform unaligned memory accesses 54 transparently, but there is usually a significant performance cost. 55 - Some architectures raise processor exceptions when unaligned accesses 56 happen. The exception handler is able to correct the unaligned access, 57 at significant cost to performance. 58 - Some architectures raise processor exceptions when unaligned accesses 59 happen, but the exceptions do not contain enough information for the 60 unaligned access to be corrected. 61 - Some architectures are not capable of unaligned memory access, but will 62 silently perform a different memory access to the one that was requested, 63 resulting in a subtle code bug that is hard to detect! 64 65 It should be obvious from the above that if your code causes unaligned 66 memory accesses to happen, your code will not work correctly on certain 67 platforms and will cause performance problems on others. 68 69 70 Code that does not cause unaligned access 71 ========================================= 72 73 At first, the concepts above may seem a little hard to relate to actual 74 coding practice. After all, you don't have a great deal of control over 75 memory addresses of certain variables, etc. 76 77 Fortunately things are not too complex, as in most cases, the compiler 78 ensures that things will work for you. For example, take the following 79 structure: 80 81 struct foo { 82 u16 field1; 83 u32 field2; 84 u8 field3; 85 }; 86 87 Let us assume that an instance of the above structure resides in memory 88 starting at address 0x10000. With a basic level of understanding, it would 89 not be unreasonable to expect that accessing field2 would cause an unaligned 90 access. You'd be expecting field2 to be located at offset 2 bytes into the 91 structure, i.e. address 0x10002, but that address is not evenly divisible 92 by 4 (remember, we're reading a 4 byte value here). 93 94 Fortunately, the compiler understands the alignment constraints, so in the 95 above case it would insert 2 bytes of padding in between field1 and field2. 96 Therefore, for standard structure types you can always rely on the compiler 97 to pad structures so that accesses to fields are suitably aligned (assuming 98 you do not cast the field to a type of different length). 99 100 Similarly, you can also rely on the compiler to align variables and function 101 parameters to a naturally aligned scheme, based on the size of the type of 102 the variable. 103 104 At this point, it should be clear that accessing a single byte (u8 or char) 105 will never cause an unaligned access, because all memory addresses are evenly 106 divisible by one. 107 108 On a related topic, with the above considerations in mind you may observe 109 that you could reorder the fields in the structure in order to place fields 110 where padding would otherwise be inserted, and hence reduce the overall 111 resident memory size of structure instances. The optimal layout of the 112 above example is: 113 114 struct foo { 115 u32 field2; 116 u16 field1; 117 u8 field3; 118 }; 119 120 For a natural alignment scheme, the compiler would only have to add a single 121 byte of padding at the end of the structure. This padding is added in order 122 to satisfy alignment constraints for arrays of these structures. 123 124 Another point worth mentioning is the use of __attribute__((packed)) on a 125 structure type. This GCC-specific attribute tells the compiler never to 126 insert any padding within structures, useful when you want to use a C struct 127 to represent some data that comes in a fixed arrangement 'off the wire'. 128 129 You might be inclined to believe that usage of this attribute can easily 130 lead to unaligned accesses when accessing fields that do not satisfy 131 architectural alignment requirements. However, again, the compiler is aware 132 of the alignment constraints and will generate extra instructions to perform 133 the memory access in a way that does not cause unaligned access. Of course, 134 the extra instructions obviously cause a loss in performance compared to the 135 non-packed case, so the packed attribute should only be used when avoiding 136 structure padding is of importance. 137 138 139 Code that causes unaligned access 140 ================================= 141 142 With the above in mind, let's move onto a real life example of a function 143 that can cause an unaligned memory access. The following function taken 144 from the Linux Kernel's include/linux/etherdevice.h is an optimized routine 145 to compare two ethernet MAC addresses for equality. 146 147 bool ether_addr_equal(const u8 *addr1, const u8 *addr2) 148 { 149 #ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS 150 u32 fold = ((*(const u32 *)addr1) ^ (*(const u32 *)addr2)) | 151 ((*(const u16 *)(addr1 + 4)) ^ (*(const u16 *)(addr2 + 4))); 152 153 return fold == 0; 154 #else 155 const u16 *a = (const u16 *)addr1; 156 const u16 *b = (const u16 *)addr2; 157 return ((a[0] ^ b[0]) | (a[1] ^ b[1]) | (a[2] ^ b[2])) == 0; 158 #endif 159 } 160 161 In the above function, when the hardware has efficient unaligned access 162 capability, there is no issue with this code. But when the hardware isn't 163 able to access memory on arbitrary boundaries, the reference to a[0] causes 164 2 bytes (16 bits) to be read from memory starting at address addr1. 165 166 Think about what would happen if addr1 was an odd address such as 0x10003. 167 (Hint: it'd be an unaligned access.) 168 169 Despite the potential unaligned access problems with the above function, it 170 is included in the kernel anyway but is understood to only work normally on 171 16-bit-aligned addresses. It is up to the caller to ensure this alignment or 172 not use this function at all. This alignment-unsafe function is still useful 173 as it is a decent optimization for the cases when you can ensure alignment, 174 which is true almost all of the time in ethernet networking context. 175 176 177 Here is another example of some code that could cause unaligned accesses: 178 void myfunc(u8 *data, u32 value) 179 { 180 [...] 181 *((u32 *) data) = cpu_to_le32(value); 182 [...] 183 } 184 185 This code will cause unaligned accesses every time the data parameter points 186 to an address that is not evenly divisible by 4. 187 188 In summary, the 2 main scenarios where you may run into unaligned access 189 problems involve: 190 1. Casting variables to types of different lengths 191 2. Pointer arithmetic followed by access to at least 2 bytes of data 192 193 194 Avoiding unaligned accesses 195 =========================== 196 197 The easiest way to avoid unaligned access is to use the get_unaligned() and 198 put_unaligned() macros provided by the <asm/unaligned.h> header file. 199 200 Going back to an earlier example of code that potentially causes unaligned 201 access: 202 203 void myfunc(u8 *data, u32 value) 204 { 205 [...] 206 *((u32 *) data) = cpu_to_le32(value); 207 [...] 208 } 209 210 To avoid the unaligned memory access, you would rewrite it as follows: 211 212 void myfunc(u8 *data, u32 value) 213 { 214 [...] 215 value = cpu_to_le32(value); 216 put_unaligned(value, (u32 *) data); 217 [...] 218 } 219 220 The get_unaligned() macro works similarly. Assuming 'data' is a pointer to 221 memory and you wish to avoid unaligned access, its usage is as follows: 222 223 u32 value = get_unaligned((u32 *) data); 224 225 These macros work for memory accesses of any length (not just 32 bits as 226 in the examples above). Be aware that when compared to standard access of 227 aligned memory, using these macros to access unaligned memory can be costly in 228 terms of performance. 229 230 If use of such macros is not convenient, another option is to use memcpy(), 231 where the source or destination (or both) are of type u8* or unsigned char*. 232 Due to the byte-wise nature of this operation, unaligned accesses are avoided. 233 234 -- 235 In the Linux Kernel, 236 Authors: Daniel Drake <dsd (a] gentoo.org>, 237 Johannes Berg <johannes (a] sipsolutions.net> 238 With help from: Alan Cox, Avuton Olrich, Heikki Orsila, Jan Engelhardt, 239 Kyle McMartin, Kyle Moffett, Randy Dunlap, Robert Hancock, Uli Kunitz, 240 Vadim Lobanov 241
README.uniphier
1 U-Boot for UniPhier SoC family 2 ============================== 3 4 5 Recommended toolchains 6 ---------------------- 7 8 The UniPhier platform is well tested with Linaro toolchains. 9 You can download pre-built toolchains from: 10 11 http://www.linaro.org/downloads/ 12 13 14 Compile the source 15 ------------------ 16 17 The source can be configured and built with the following commands: 18 19 $ make <defconfig> 20 $ make CROSS_COMPILE=<toolchain-prefix> DEVICE_TREE=<device-tree> 21 22 The recommended <toolchain-prefix> is `arm-linux-gnueabihf-` for 32bit SoCs, 23 `aarch64-linux-gnu-` for 64bit SoCs, but you may wish to change it to use your 24 favorite compiler. 25 26 The following tables show <defconfig> and <device-tree> for each board. 27 28 32bit SoC boards: 29 30 Board | <defconfig> | <device-tree> 31 ---------------|-----------------------------|------------------------------ 32 LD4 reference | uniphier_ld4_sld8_defconfig | uniphier-ld4-ref (default) 33 sld8 reference | uniphier_ld4_sld8_defconfig | uniphier-sld8-def 34 Pro4 reference | uniphier_v7_defconfig | uniphier-pro4-ref 35 Pro4 Ace | uniphier_v7_defconfig | uniphier-pro4-ace 36 Pro4 Sanji | uniphier_v7_defconfig | uniphier-pro4-sanji 37 Pro5 4KBOX | uniphier_v7_defconfig | uniphier-pro5-4kbox 38 PXs2 Gentil | uniphier_v7_defconfig | uniphier-pxs2-gentil 39 PXs2 Vodka | uniphier_v7_defconfig | uniphier-pxs2-vodka (default) 40 LD6b reference | uniphier_v7_defconfig | uniphier-ld6b-ref 41 42 64bit SoC boards: 43 44 Board | <defconfig> | <device-tree> 45 ---------------|-----------------------|---------------------------- 46 LD11 reference | uniphier_v8_defconfig | uniphier-ld11-ref 47 LD11 Global | uniphier_v8_defconfig | uniphier-ld11-global 48 LD20 reference | uniphier_v8_defconfig | uniphier-ld20-ref (default) 49 LD20 Global | uniphier_v8_defconfig | uniphier-ld20-global 50 PXs3 reference | uniphier_v8_defconfig | uniphier-pxs3-ref 51 52 For example, to compile the source for PXs2 Vodka board, run the following: 53 54 $ make uniphier_v7_defconfig 55 $ make CROSS_COMPILE=arm-linux-gnueabihf- DEVICE_TREE=uniphier-pxs2-vodka 56 57 The device tree marked as (default) can be omitted. `uniphier-pxs2-vodka` is 58 the default device tree for the configuration `uniphier_v7_defconfig`, so the 59 following gives the same result. 60 61 $ make uniphier_v7_defconfig 62 $ make CROSS_COMPILE=arm-linux-gnueabihf- 63 64 65 Booting 32bit SoC boards 66 ------------------------ 67 68 The build command will generate the following: 69 - u-boot.bin 70 - spl/u-boot.bin 71 72 U-Boot can boot UniPhier 32bit SoC boards by itself. Flash the generated images 73 to the storage device (NAND or eMMC) on your board. 74 75 - spl/u-boot-spl.bin at the offset address 0x00000000 76 - u-boot.bin at the offset address 0x00020000 77 78 The `u-boot-with-spl.bin` is the concatenation of the two (with appropriate 79 padding), so you can also do: 80 81 - u-boot-with-spl.bin at the offset address 0x00000000 82 83 If a TFTP server is available, the images can be easily updated. 84 Just copy the u-boot-spl.bin and u-boot.bin to the TFTP public directory, 85 and run the following command at the U-Boot command line: 86 87 To update the images in NAND: 88 89 => run nandupdate 90 91 To update the images in eMMC: 92 93 => run emmcupdate 94 95 96 Booting 64bit SoC boards 97 ------------------------ 98 99 The build command will generate the following: 100 - u-boot.bin 101 102 However, U-Boot is not the first stage loader for UniPhier 64bit SoC boards. 103 U-Boot serves as a non-secure boot loader loaded by [ARM Trusted Firmware], 104 so you need to provide the `u-boot.bin` to the build command of ARM Trusted 105 Firmware. 106 107 [ARM Trusted Firmware]: https://github.com/ARM-software/arm-trusted-firmware 108 109 110 Verified Boot 111 ------------- 112 113 U-Boot supports an image verification method called "Verified Boot". 114 This is a brief tutorial to utilize this feature for the UniPhier platform. 115 You will find details documents in the doc/uImage.FIT directory. 116 117 Here, we take LD20 reference board for example, but it should work for any 118 other boards including 32 bit SoCs. 119 120 1. Generate key to sign with 121 122 $ mkdir keys 123 $ openssl genpkey -algorithm RSA -out keys/dev.key \ 124 -pkeyopt rsa_keygen_bits:2048 -pkeyopt rsa_keygen_pubexp:65537 125 $ openssl req -batch -new -x509 -key keys/dev.key -out keys/dev.crt 126 127 Two files "dev.key" and "dev.crt" will be created. The base name is arbitrary, 128 but need to match to the "key-name-hint" property described below. 129 130 2. Describe FIT source 131 132 You need to write an FIT (Flattened Image Tree) source file to describe the 133 structure of the image container. 134 135 The following is an example for a simple usecase: 136 137 ---------------------------------------->8---------------------------------------- 138 /dts-v1/; 139 140 / { 141 description = "Kernel, DTB and Ramdisk for UniPhier LD20 Reference Board"; 142 #address-cells = <1>; 143 144 images { 145 kernel { 146 description = "linux"; 147 data = /incbin/("PATH/TO/YOUR/LINUX/DIR/arch/arm64/boot/Image.gz"); 148 type = "kernel"; 149 arch = "arm64"; 150 os = "linux"; 151 compression = "gzip"; 152 load = <0x82080000>; 153 entry = <0x82080000>; 154 hash-1 { 155 algo = "sha256"; 156 }; 157 }; 158 159 fdt-1 { 160 description = "fdt"; 161 data = /incbin/("PATH/TO/YOUR/LINUX/DIR/arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dtb"); 162 type = "flat_dt"; 163 arch = "arm64"; 164 compression = "none"; 165 hash-1 { 166 algo = "sha256"; 167 }; 168 }; 169 170 ramdisk { 171 description = "ramdisk"; 172 data = /incbin/("PATH/TO/YOUR/ROOTFS/DIR/rootfs.cpio"); 173 type = "ramdisk"; 174 arch = "arm64"; 175 os = "linux"; 176 compression = "none"; 177 hash-1 { 178 algo = "sha256"; 179 }; 180 }; 181 }; 182 183 configurations { 184 default = "config-1"; 185 186 config-1 { 187 description = "Configuration0"; 188 kernel = "kernel"; 189 fdt = "fdt-1"; 190 ramdisk = "ramdisk"; 191 signature-1 { 192 algo = "sha256,rsa2048"; 193 key-name-hint = "dev"; 194 sign-images = "kernel", "fdt", "ramdisk"; 195 }; 196 }; 197 }; 198 }; 199 ---------------------------------------->8---------------------------------------- 200 201 You need to change the three '/incbin/' lines, depending on the location of 202 your kernel image, device tree blob, and init ramdisk. The "load" and "entry" 203 properties also need to be adjusted if you want to change the physical placement 204 of the kernel. 205 206 The "key-name-hint" must specify the key name you have created in the step 1. 207 208 The FIT file name is arbitrary. Let's say you saved it into "fit.its". 209 210 3. Compile U-Boot with FIT and signature enabled 211 212 To use the Verified Boot, you need to enable the following two options: 213 CONFIG_FIT 214 CONFIG_FIT_SIGNATURE 215 216 They are disabled by default for UniPhier defconfig files. So, you need to 217 tweak the configuration from "make menuconfig" or friends. 218 219 $ make uniphier_v8_defconfig 220 $ make menuconfig 221 [ enable CONFIG_FIT and CONFIG_FIT_SIGNATURE ] 222 $ make CROSS_COMPILE=aarch64-linux-gnu- 223 224 4. Build the image tree blob 225 226 After building U-Boot, you will see tools/mkimage. With this tool, you can 227 create an image tree blob as follows: 228 229 $ tools/mkimage -f fit.its -k keys -K dts/dt.dtb -r -F fitImage 230 231 The -k option must specify the key directory you have created in step 1. 232 233 A file "fitImage" will be created. This includes kernel, DTB, Init-ramdisk, 234 hash data for each of the three, and signature data. 235 236 The public key needed for the run-time verification is stored in "dts/dt.dtb". 237 238 5. Compile U-Boot again 239 240 Since the "dt.dtb" has been updated in step 4, you need to re-compile the 241 U-Boot. 242 243 $ make CROSS_COMPILE=aarch64-linux-gnu- 244 245 The re-compiled "u-boot.bin" is appended with DTB that contains the public key. 246 247 6. Flash the image 248 249 Flash the "fitImage" to a storage device (NAND, eMMC, or whatever) on your 250 board. 251 252 Please note the "u-boot.bin" must be signed, and verified by someone when it is 253 loaded. For ARMv8 SoCs, the "someone" is generally ARM Trusted Firmware BL2. 254 ARM Trusted Firmware supports an image authentication mechanism called Trusted 255 Board Boot (TBB). The verification process must be chained from the moment of 256 the system reset. If the Chain of Trust has a breakage somewhere, the verified 257 boot process is entirely pointless. 258 259 7. Boot verified kernel 260 261 Load the fitImage to memory and run the following from the U-Boot command line. 262 263 > bootm <addr> 264 265 Here, <addr> is the base address of the fitImage. 266 267 If it is successful, you will see messages like follows: 268 269 ---------------------------------------->8---------------------------------------- 270 ## Loading kernel from FIT Image at 84100000 ... 271 Using 'config-1' configuration 272 Verifying Hash Integrity ... sha256,rsa2048:dev+ OK 273 Trying 'kernel' kernel subimage 274 Description: linux 275 Created: 2017-10-20 14:32:29 UTC 276 Type: Kernel Image 277 Compression: gzip compressed 278 Data Start: 0x841000c8 279 Data Size: 6957818 Bytes = 6.6 MiB 280 Architecture: AArch64 281 OS: Linux 282 Load Address: 0x82080000 283 Entry Point: 0x82080000 284 Hash algo: sha256 285 Hash value: 82a37b7f11ae55f4e07aa25bf77e4067cb9dc1014d52d6cd4d588f92eee3aaad 286 Verifying Hash Integrity ... sha256+ OK 287 ## Loading ramdisk from FIT Image at 84100000 ... 288 Using 'config-1' configuration 289 Trying 'ramdisk' ramdisk subimage 290 Description: ramdisk 291 Created: 2017-10-20 14:32:29 UTC 292 Type: RAMDisk Image 293 Compression: uncompressed 294 Data Start: 0x847a5cc0 295 Data Size: 5264365 Bytes = 5 MiB 296 Architecture: AArch64 297 OS: Linux 298 Load Address: unavailable 299 Entry Point: unavailable 300 Hash algo: sha256 301 Hash value: 44980a2874154a2e31ed59222c9f8ea968867637f35c81e4107a984de7014deb 302 Verifying Hash Integrity ... sha256+ OK 303 ## Loading fdt from FIT Image at 84100000 ... 304 Using 'config-1' configuration 305 Trying 'fdt-1' fdt subimage 306 Description: fdt 307 Created: 2017-10-20 14:32:29 UTC 308 Type: Flat Device Tree 309 Compression: uncompressed 310 Data Start: 0x847a2cb0 311 Data Size: 12111 Bytes = 11.8 KiB 312 Architecture: AArch64 313 Hash algo: sha256 314 Hash value: c517099db537f6d325e6be46b25c871a41331ad5af0283883fd29d40bfc14e1d 315 Verifying Hash Integrity ... sha256+ OK 316 Booting using the fdt blob at 0x847a2cb0 317 Uncompressing Kernel Image ... OK 318 reserving fdt memory region: addr=80000000 size=2000000 319 Loading Device Tree to 000000009fffa000, end 000000009fffff4e ... OK 320 321 Starting kernel ... 322 ---------------------------------------->8---------------------------------------- 323 324 Please pay attention to the lines that start with "Verifying Hash Integrity". 325 326 "Verifying Hash Integrity ... sha256,rsa2048:dev+ OK" means the signature check 327 passed. 328 329 "Verifying Hash Integrity ... sha256+ OK" (3 times) means the hash check passed 330 for kernel, DTB, and Init ramdisk. 331 332 If they are not displayed, the Verified Boot is not working. 333 334 335 UniPhier specific commands 336 -------------------------- 337 338 - pinmon (enabled by CONFIG_CMD_PINMON) 339 shows the boot mode pins that has been latched at the power-on reset 340 341 - ddrphy (enabled by CONFIG_CMD_DDRPHY_DUMP) 342 shows the DDR PHY parameters set by the PHY training 343 344 - ddrmphy (enabled by CONFIG_CMD_DDRMPHY_DUMP) 345 shows the DDR Multi PHY parameters set by the PHY training 346 347 348 Supported devices 349 ----------------- 350 351 - UART (on-chip) 352 - NAND 353 - SD/eMMC 354 - USB 2.0 (EHCI) 355 - USB 3.0 (xHCI) 356 - GPIO 357 - LAN (on-board SMSC9118) 358 - I2C 359 - EEPROM (connected to the on-board I2C bus) 360 - Support card (SRAM, NOR flash, some peripherals) 361 362 363 Micro Support Card 364 ------------------ 365 366 The recommended bit switch settings are as follows: 367 368 SW2 OFF(1)/ON(0) Description 369 ------------------------------------------ 370 bit 1 <---- BKSZ[0] 371 bit 2 ----> BKSZ[1] 372 bit 3 <---- SoC Bus Width 16/32 373 bit 4 <---- SERIAL_SEL[0] 374 bit 5 ----> SERIAL_SEL[1] 375 bit 6 ----> BOOTSWAP_EN 376 bit 7 <---- CS1/CS5 377 bit 8 <---- SOC_SERIAL_DISABLE 378 379 SW8 OFF(1)/ON(0) Description 380 ------------------------------------------ 381 bit 1 <---- CS1_SPLIT 382 bit 2 <---- CASE9_ON 383 bit 3 <---- CASE10_ON 384 bit 4 Don't Care Reserve 385 bit 5 Don't Care Reserve 386 bit 6 Don't Care Reserve 387 bit 7 ----> BURST_EN 388 bit 8 ----> FLASHBUS32_16 389 390 The BKSZ[1:0] specifies the address range of memory slot and peripherals 391 as follows: 392 393 BKSZ Description RAM slot Peripherals 394 -------------------------------------------------------------------- 395 0b00 15MB RAM / 1MB Peri 00000000-00efffff 00f00000-00ffffff 396 0b01 31MB RAM / 1MB Peri 00000000-01efffff 01f00000-01ffffff 397 0b10 64MB RAM / 1MB Peri 00000000-03efffff 03f00000-03ffffff 398 0b11 127MB RAM / 1MB Peri 00000000-07efffff 07f00000-07ffffff 399 400 Set BSKZ[1:0] to 0b01 for U-Boot. 401 This mode is the most handy because EA[24] is always supported by the save pin 402 mode of the system bus. On the other hand, EA[25] is not supported for some 403 newer SoCs. Even if it is, EA[25] is not connected on most of the boards. 404 405 -- 406 Masahiro Yamada <yamada.masahiro (a] socionext.com> 407 Oct. 2017 408
README.update
1 Automatic software update from a TFTP server 2 ============================================ 3 4 Overview 5 -------- 6 7 This feature allows to automatically store software updates present on a TFTP 8 server in NOR Flash. In more detail: a TFTP transfer of a file given in 9 environment variable 'updatefile' from server 'serverip' is attempted during 10 boot. The update file should be a FIT file, and can contain one or more 11 updates. Each update in the update file has an address in NOR Flash where it 12 should be placed, updates are also protected with a SHA-1 checksum. If the 13 TFTP transfer is successful, the hash of each update is verified, and if the 14 verification is positive, the update is stored in Flash. 15 16 The auto-update feature is enabled by the CONFIG_UPDATE_TFTP macro: 17 18 #define CONFIG_UPDATE_TFTP 1 19 20 21 Note that when enabling auto-update, Flash support must be turned on. Also, 22 one must enable FIT and LIBFDT support: 23 24 #define CONFIG_FIT 1 25 #define CONFIG_OF_LIBFDT 1 26 27 The auto-update feature uses the following configuration knobs: 28 29 - CONFIG_UPDATE_LOAD_ADDR 30 31 Normally, TFTP transfer of the update file is done to the address specified 32 in environment variable 'loadaddr'. If this variable is not present, the 33 transfer is made to the address given in CONFIG_UPDATE_LOAD_ADDR (0x100000 34 by default). 35 36 - CONFIG_UPDATE_TFTP_CNT_MAX 37 CONFIG_UPDATE_TFTP_MSEC_MAX 38 39 These knobs control the timeouts during initial connection to the TFTP 40 server. Since a transfer is attempted during each boot, it is undesirable to 41 have a long delay when a TFTP server is not present. 42 CONFIG_UPDATE_TFTP_MSEC_MAX specifies the number of milliseconds to wait for 43 the server to respond to initial connection, and CONFIG_UPDATE_TFTP_CNT_MAX 44 gives the number of such connection retries. CONFIG_UPDATE_TFTP_CNT_MAX must 45 be non-negative and is 0 by default, CONFIG_UPDATE_TFTP_MSEC_MAX must be 46 positive and is 100 by default. 47 48 Since the update file is in FIT format, it is created from an *.its file using 49 the mkimage tool. dtc tool with support for binary includes, e.g. in version 50 1.2.0 or later, must also be available on the system where the update file is 51 to be prepared. Refer to the doc/uImage.FIT/ directory for more details on FIT 52 images. 53 54 This mechanism can be also triggered by the command "fitupd". 55 If an optional, non-zero address is provided as argument, the TFTP transfer 56 is skipped and the image at this address is used. 57 The fitupd command is enabled by CONFIG_CMD_FITUPD. 58 59 60 Example .its files 61 ------------------ 62 63 - doc/uImage.FIT/update_uboot.its 64 65 A simple example that can be used to create an update file for automatically 66 replacing U-Boot image on a system. 67 68 Assuming that an U-Boot image u-boot.bin is present in the current working 69 directory, and that the address given in the 'load' property in the 70 'update_uboot.its' file is where the U-Boot is stored in Flash, the 71 following command will create the actual update file 'update_uboot.itb': 72 73 mkimage -f update_uboot.its update_uboot.itb 74 75 Place 'update_uboot.itb' on a TFTP server, for example as 76 '/tftpboot/update_uboot.itb', and set the 'updatefile' variable 77 appropriately, for example in the U-Boot prompt: 78 79 setenv updatefile /tftpboot/update_uboot.itb 80 saveenv 81 82 Now, when the system boots up and the update TFTP server specified in the 83 'serverip' environment variable is accessible, the new U-Boot image will be 84 automatically stored in Flash. 85 86 NOTE: do make sure that the 'u-boot.bin' image used to create the update 87 file is a good, working image. Also make sure that the address in Flash 88 where the update will be placed is correct. Making mistake here and 89 attempting the auto-update can render the system unusable. 90 91 - doc/uImage.FIT/update3.its 92 93 An example containing three updates. It can be used to update Linux kernel, 94 ramdisk and FDT blob stored in Flash. The procedure for preparing the update 95 file is similar to the example above. 96 97 TFTP update via DFU 98 ------------------- 99 100 - It is now possible to update firmware (bootloader, kernel, rootfs, etc.) via 101 TFTP by using DFU (Device Firmware Upgrade). More information can be found in 102 ./doc/README.dfutftp documentation entry. 103
README.usb
1 SPDX-License-Identifier: GPL-2.0+ 2 /* 3 * (C) Copyright 2001 4 * Denis Peter, MPL AG Switzerland 5 */ 6 7 USB Support 8 =========== 9 10 The USB support is implemented on the base of the UHCI Host 11 controller. 12 13 Currently supported are USB Hubs, USB Keyboards, USB Floppys, USB 14 flash sticks and USB network adaptors. 15 Tested with a TEAC Floppy TEAC FD-05PUB and Chicony KU-8933 Keyboard. 16 17 How it works: 18 ------------- 19 20 The USB (at least the USB UHCI) needs a frame list (4k), transfer 21 descripor and queue headers which are all located in the main memory. 22 The UHCI allocates every milisecond the PCI bus and reads the current 23 frame pointer. This may cause to crash the OS during boot. So the USB 24 _MUST_ be stopped during OS boot. This is the reason, why the USB is 25 NOT automatically started during start-up. If someone needs the USB 26 he has to start it and should therefore be aware that he had to stop 27 it before booting the OS. 28 29 For USB keyboards this can be done by a script which is automatically 30 started after the U-Boot is up and running. To boot an OS with a an 31 USB keyboard another script is necessary, which first disables the 32 USB and then executes the boot command. If the boot command fails, 33 the script can reenable the USB kbd. 34 35 Common USB Commands: 36 - usb start: 37 - usb reset: (re)starts the USB. All USB devices will be 38 initialized and a device tree is build for them. 39 - usb tree: shows all USB devices in a tree like display 40 - usb info [dev]: shows all USB infos of the device dev, or of all 41 the devices 42 - usb stop [f]: stops the USB. If f==1 the USB will also stop if 43 an USB keyboard is assigned as stdin. The stdin 44 is then switched to serial input. 45 Storage USB Commands: 46 - usb scan: scans the USB for storage devices.The USB must be 47 running for this command (usb start) 48 - usb device [dev]: show or set current USB storage device 49 - usb part [dev]: print partition table of one or all USB storage 50 devices 51 - usb read addr blk# cnt: 52 read `cnt' blocks starting at block `blk#'to 53 memory address `addr' 54 - usbboot addr dev:part: 55 boot from USB device 56 57 Config Switches: 58 ---------------- 59 CONFIG_CMD_USB enables basic USB support and the usb command 60 CONFIG_USB_UHCI defines the lowlevel part.A lowlevel part must be defined 61 if using CONFIG_CMD_USB 62 CONFIG_USB_KEYBOARD enables the USB Keyboard 63 CONFIG_USB_STORAGE enables the USB storage devices 64 CONFIG_USB_HOST_ETHER enables USB ethernet adapter support 65 66 67 USB Host Networking 68 =================== 69 70 If you have a supported USB Ethernet adapter you can use it in U-Boot 71 to obtain an IP address and load a kernel from a network server. 72 73 Note: USB Host Networking is not the same as making your board act as a USB 74 client. In that case your board is pretending to be an Ethernet adapter 75 and will appear as a network interface to an attached computer. In that 76 case the connection is via a USB cable with the computer acting as the host. 77 78 With USB Host Networking, your board is the USB host. It controls the 79 Ethernet adapter to which it is directly connected and the connection to 80 the outside world is your adapter's Ethernet cable. Your board becomes an 81 independent network device, able to connect and perform network operations 82 independently of your computer. 83 84 85 Device support 86 -------------- 87 88 Currently supported devices are listed in the drivers according to 89 their vendor and product IDs. You can check your device by connecting it 90 to a Linux machine and typing 'lsusb'. The drivers are in 91 drivers/usb/eth. 92 93 For example this lsusb output line shows a device with Vendor ID 0x0x95 94 and product ID 0x7720: 95 96 Bus 002 Device 010: ID 0b95:7720 ASIX Electronics Corp. AX88772 97 98 If you look at drivers/usb/eth/asix.c you will see this line within the 99 supported device list, so we know this adapter is supported. 100 101 { 0x0b95, 0x7720 }, /* Trendnet TU2-ET100 V3.0R */ 102 103 If your adapter is not listed there is a still a chance that it will 104 work. Try looking up the manufacturer of the chip inside your adapter. 105 or take the adapter apart and look for chip markings. Then add a line 106 for your vendor/product ID into the table of the appropriate driver, 107 build U-Boot and see if it works. If not then there might be differences 108 between the chip in your adapter and the driver. You could try to get a 109 datasheet for your device and add support for it to U-Boot. This is not 110 particularly difficult - you only need to provide support for four basic 111 functions: init, halt, send and recv. 112 113 114 Enabling USB Host Networking 115 ---------------------------- 116 117 The normal U-Boot commands are used with USB networking, but you must 118 start USB first. For example: 119 120 usb start 121 setenv bootfile /tftpboot/uImage 122 bootp 123 124 125 To enable USB Host Ethernet in U-Boot, your platform must of course 126 support USB with CONFIG_CMD_USB enabled and working. You will need to 127 add some config settings to your board config: 128 129 CONFIG_CMD_USB=y /* the 'usb' interactive command */ 130 CONFIG_USB_HOST_ETHER=y /* Enable USB Ethernet adapters */ 131 132 and one or more of the following for individual adapter hardware: 133 134 CONFIG_USB_ETHER_ASIX=y 135 CONFIG_USB_ETHER_ASIX88179=y 136 CONFIG_USB_ETHER_LAN75XX=y 137 CONFIG_USB_ETHER_LAN78XX=y 138 CONFIG_USB_ETHER_MCS7830=y 139 CONFIG_USB_ETHER_RTL8152=y 140 CONFIG_USB_ETHER_SMSC95XX=y 141 142 As with built-in networking, you will also want to enable some network 143 commands, for example: 144 145 CONFIG_CMD_NET=y 146 CONFIG_CMD_PING=y 147 CONFIG_CMD_DHCP=y 148 149 and some bootp options, which tell your board to obtain its subnet, 150 gateway IP, host name and boot path from the bootp/dhcp server. These 151 settings should start you off: 152 153 #define CONFIG_BOOTP_SUBNETMASK 154 #define CONFIG_BOOTP_GATEWAY 155 #define CONFIG_BOOTP_HOSTNAME 156 #define CONFIG_BOOTP_BOOTPATH 157 158 You can also set the default IP address of your board and the server 159 as well as the default file to load when a 'bootp' command is issued. 160 However note that encoding these individual network settings into a 161 common exectuable is discouraged, as it leads to potential conflicts, 162 and all the parameters can either get stored in the board's external 163 environment, or get obtained from the bootp server if not set. 164 165 #define CONFIG_IPADDR 10.0.0.2 (replace with your value) 166 #define CONFIG_SERVERIP 10.0.0.1 (replace with your value) 167 #define CONFIG_BOOTFILE "uImage" 168 169 170 The 'usb start' command should identify the adapter something like this: 171 172 CrOS> usb start 173 (Re)start USB... 174 USB EHCI 1.00 175 scanning bus for devices... 3 USB Device(s) found 176 scanning bus for storage devices... 0 Storage Device(s) found 177 scanning bus for ethernet devices... 1 Ethernet Device(s) found 178 CrOS> print ethact 179 ethact=asx0 180 181 You can see that it found an ethernet device and we can print out the 182 device name (asx0 in this case). 183 184 Then 'bootp' or 'dhcp' should use it to obtain an IP address from DHCP, 185 perhaps something like this: 186 187 CrOS> bootp 188 Waiting for Ethernet connection... done. 189 BOOTP broadcast 1 190 BOOTP broadcast 2 191 DHCP client bound to address 172.22.73.81 192 Using asx0 device 193 TFTP from server 172.22.72.144; our IP address is 172.22.73.81 194 Filename '/tftpboot/uImage-sjg-seaboard-261347'. 195 Load address: 0x40c000 196 Loading: ################################################################# 197 ################################################################# 198 ################################################################# 199 ################################################ 200 done 201 Bytes transferred = 3557464 (364858 hex) 202 CrOS> 203 204 205 Another way of doing this is to issue a tftp command, which will cause the 206 bootp to happen automatically. 207 208 209 MAC Addresses 210 ------------- 211 212 Most Ethernet dongles have a built-in MAC address which is unique in the 213 world. This is important so that devices on the network can be 214 distinguised from each other. MAC address conflicts are evil and 215 generally result in strange and eratic behaviour. 216 217 Some boards have USB Ethernet chips on-board, and these sometimes do not 218 have an assigned MAC address. In this case it is up to you to assign 219 one which is unique. You should obtain a valid MAC address from a range 220 assigned to you before you ship the product. 221 222 Built-in Ethernet adapters support setting the MAC address by means of 223 an ethaddr environment variable for each interface (ethaddr, eth1addr, 224 eth2addr). There is similar support on the USB network side, using the 225 names usbethaddr, usbeth1addr, etc. They are kept separate since we 226 don't want a USB device taking the MAC address of a built-in device or 227 vice versa. 228 229 So if your USB Ethernet chip doesn't have a MAC address available then 230 you must set usbethaddr to a suitable MAC address. At the time of 231 writing this functionality is only supported by the SMSC driver. 232
README.vf610
1 U-Boot for Freescale Vybrid VF610 2 3 This file contains information for the port of U-Boot to the Freescale Vybrid 4 VF610 SoC. 5 6 1. CONVENTIONS FOR FUSE ASSIGNMENTS 7 ----------------------------------- 8 9 1.1 MAC Address: It is stored in fuse bank 4, with the 16 msbs in word 2 and the 10 32 lsbs in word 3. 11
README.video
1 SPDX-License-Identifier: GPL-2.0+ 2 /* 3 * (C) Copyright 2000 4 * Paolo Scaffardi, AIRVENT SAM s.p.a - RIMINI(ITALY), arsenio (a] tin.it 5 */ 6 7 "video-mode" environment variable 8 ================================= 9 10 The 'video-mode' environment variable can be used to enable and configure 11 some video drivers. The format matches the video= command-line option used 12 for Linux: 13 14 video-mode=<driver>:<xres>x<yres>-<depth>@<freq><,option=string> 15 16 <driver> The video driver name, ignored by U-Boot 17 <xres> The X resolution (in pixels) to use. 18 <yres> The Y resolution (in pixels) to use. 19 <depth> The color depth (in bits) to use. 20 <freq> The frequency (in Hz) to use. 21 <options> A comma-separated list of device-specific options 22 23 24 U-Boot MPC8xx video controller driver 25 ===================================== 26 27 The driver has been tested with the following configurations: 28 29 - MPC823FADS with AD7176 on a PAL TV (YCbYCr) - arsenio (a] tin.it 30 31 Example: video-mode=fslfb:1280x1024-32@60,monitor=dvi 32 33 34 U-Boot sunxi video controller driver 35 ==================================== 36 37 U-Boot supports hdmi and lcd output on Allwinner sunxi SoCs, lcd output 38 requires the CONFIG_VIDEO_LCD_MODE Kconfig value to be set. 39 40 The sunxi U-Boot driver supports the following video-mode options: 41 42 - monitor=[none|dvi|hdmi|lcd|vga|composite-*] - Select the video output to use 43 none: Disable video output. 44 dvi/hdmi: Selects output over the hdmi connector with dvi resp. hdmi output 45 format, if edid is used the format is automatically selected. 46 lcd: Selects video output to a LCD screen. 47 vga: Selects video output over the VGA connector. 48 composite-pal/composite-ntsc/composite-pal-m/composite-pal-nc: 49 Selects composite video output, note the specified resolution is 50 ignored with composite video output. 51 Defaults to monitor=dvi. 52 53 - hpd=[0|1] - Enable use of the hdmi HotPlug Detect feature 54 0: Disabled. Configure dvi/hdmi output even if no cable is detected 55 1: Enabled. Fallback to the lcd / vga / none in that order (if available) 56 Defaults to hpd=1. 57 58 - hpd_delay=<int> - How long to wait for the hdmi HPD signal in milliseconds 59 When the monitor and the board power up at the same time, it may take some 60 time for the monitor to assert the HPD signal. This configures how long to 61 wait for the HPD signal before assuming no cable is connected. 62 Defaults to hpd_delay=500. 63 64 - edid=[0|1] - Enable use of DDC + EDID to get monitor info 65 0: Disabled. 66 1: Enabled. If valid EDID info was read from the monitor the EDID info will 67 overrides the xres, yres and refresh from the video-mode env. variable. 68 Defaults to edid=1. 69 70 - overscan_x/overscan_y=<int> - Set x/y overscan value 71 This configures a black border on the left and right resp. top and bottom 72 to deal with overscanning displays. Defaults to overscan_x=32 and 73 overscan_y=20 for composite monitors, 0 for other monitors. 74 75 For example to always use the hdmi connector, even if no cable is inserted, 76 using edid info when available and otherwise initalizing it at 1024x768@60Hz, 77 use: "setenv video-mode sunxi:1024x768-24@60,monitor=dvi,hpd=0,edid=1". 78
README.VLAN
1 U-Boot has networking support for VLANs (802.1q), and CDP (Cisco 2 Discovery Protocol). 3 4 You control the sending/receiving of VLAN tagged packets with the 5 "vlan" environmental variable. When not present no tagging is 6 performed. 7 8 CDP is used mainly to discover your device VLAN(s) when connected to 9 a Cisco switch. 10 11 Note: In order to enable CDP support a small change is needed in the 12 networking driver. You have to enable reception of the 13 01:00:0c:cc:cc:cc MAC address which is a multicast address. 14 15 Various defines control CDP; see the README section. 16
README.VSC3316-3308
1 This file contains API information of the initialization code written for 2 Vitesse cross-point devices, VSC3316 and VSC3308 for board B4860QDS 3 4 Author: Shaveta Leekha <shaveta (a] freescale.com> 5 6 About Device: 7 ============= 8 VSC 3316/3308 is a low-power, low-cost asynchronous crosspoint switch capable of data rates upto 11.5Gbps. 9 10 VSC3316 has 16 input and 16 output ports whereas VSC3308 has 8 input and 8 output ports. Programming of these devices are performed by two-wire or four-wire serial interface. 11 12 Initialization: 13 =============== 14 On reset, VSC devices are in low-power state with all inputs, outputs and connections in an off state. 15 First thing required is to program it to interface with either two-wire or four-wire interface. 16 In our case the interface is two-wire I2C serial interface. So the value in Interface mode register at address 79.h to be written is 0x02 for two-wire interface. Also for crosspoint connections to be activated, 01.h value need to be written in 75.h (core configuration register). 17 18 API Overview: 19 ============= 20 21 vsc_if_enable(u8 vsc_addr): 22 -------------------------- 23 This API programs VSC to interface with either two-wire or four-wire interface. In our case the interface is two-wire I2C serial interface. So the value in Interface mode register at address 79.h to be written is 0x02 for two-wire interface. 24 Parameters: 25 vsc_addr - Address of the VSC device on board. 26 27 28 vsc3316_config(u8 vsc_addr, int con_arr[][2], u8 num_con): 29 --------------------------------------------------------- 30 This API configures the VSC3316 device for required connections. Connection through the VSC device requires the inputs and outputs to be properly configured. 31 Connection registers are on page 00. It Configures the selected input and output correctly and join them to make a connection. It also program Input state register, Global input ISE, Global input LOS, Global core control, Output mode register and core control registers etc. 32 vsc3308_config(u8 vsc_addr, int con_arr[][2], u8 num_con) does the essential configurations for VSC3308. 33 34 Parameters: 35 vsc_addr - Address of the VSC device on board. 36 con_arr - connection array 37 num_con - number of connections to be configured 38 39 vsc_wp_config(u8 vsc_addr): 40 -------------------------- 41 For crosspoint connections to be activated, 01.h value need to be written in 75.h (core configuration register), which is done by this API. 42 Parameters: 43 vsc_addr - Address of the VSC device on board. 44
README.vxworks
1 # SPDX-License-Identifier: GPL-2.0+ 2 # 3 # Copyright (C) 2013, Miao Yan <miao.yan (a] windriver.com> 4 # Copyright (C) 2015-2018, Bin Meng <bmeng.cn (a] gmail.com> 5 6 VxWorks Support 7 =============== 8 9 This document describes the information about U-Boot loading VxWorks kernel. 10 11 Status 12 ------ 13 U-Boot supports loading VxWorks kernels via 'bootvx' and 'bootm' commands. 14 For booting old kernels (6.9.x) on PowerPC and ARM, and all kernel versions 15 on other architectures, 'bootvx' shall be used. For booting VxWorks 7 kernels 16 on PowerPC and ARM, 'bootm' shall be used. 17 18 With CONFIG_EFI_LOADER option, it's possible to chain load a VxWorks x86 kernel 19 via the UEFI boot loader application for VxWorks loaded by 'bootefi' command. 20 21 VxWorks 7 on PowerPC and ARM 22 --------------------------- 23 From VxWorks 7, VxWorks starts adopting device tree as its hardware description 24 mechanism (for PowerPC and ARM), thus requiring boot interface changes. 25 This section will describe the new interface. 26 27 For PowerPC, the calling convention of the new VxWorks entry point conforms to 28 the ePAPR standard, which is shown below (see ePAPR for more details): 29 30 void (*kernel_entry)(fdt_addr, 0, 0, EPAPR_MAGIC, boot_IMA, 0, 0) 31 32 For ARM, the calling convention is shown below: 33 34 void (*kernel_entry)(void *fdt_addr) 35 36 When booting a VxWorks 7 kernel (uImage format), the parameters passed to bootm 37 is like below: 38 39 bootm <kernel image address> - <device tree address> 40 41 VxWorks bootline 42 ---------------- 43 When using 'bootvx', the kernel bootline must be prepared by U-Boot at a 44 board-specific address before loading VxWorks. U-Boot supplies its address 45 via "bootaddr" environment variable. To check where the bootline should be 46 for a specific board, go to the VxWorks BSP for that board, and look for a 47 parameter called BOOT_LINE_ADRS. Assign its value to "bootaddr". A typical 48 value for "bootaddr" on an x86 board is 0x101200. 49 50 If a "bootargs" variable is defined, its content will be copied to the memory 51 location pointed by "bootaddr" as the kernel bootline. If "bootargs" is not 52 there, command 'bootvx' can construct a valid bootline using the following 53 environments variables: bootdev, bootfile, ipaddr, netmask, serverip, 54 gatewayip, hostname, othbootargs. 55 56 When using 'bootm', just define "bootargs" in the environment and U-Boot will 57 handle bootline fix up for the kernel dtb automatically. 58 59 When using 'bootefi' to chain load an x86 kernel, the UEFI boot loader 60 application for VxWorks takes care of the kernel bootline preparation. 61 62 Serial console 63 -------------- 64 It's very common that VxWorks BSPs configure a different baud rate for the 65 serial console from what is being used by U-Boot. For example, VxWorks tends 66 to use 9600 as the default baud rate on all x86 BSPs while U-Boot uses 115200. 67 Please configure both U-Boot and VxWorks to use the same baud rate, or it may 68 look like VxWorks hangs somewhere as nothing outputs on the serial console. 69 70 x86-specific information 71 ------------------------ 72 Before direct loading an x86 kernel via 'bootvx', one additional environment 73 variable need to be provided. This is "vx_phys_mem_base", which represent the 74 physical memory base address of VxWorks. 75 76 Check VxWorks kernel configuration to look for LOCAL_MEM_LOCAL_ADRS. For 77 VxWorks 7, this is normally a virtual address and you need find out its 78 corresponding physical address and assign its value to "vx_phys_mem_base". 79 80 For boards on which ACPI is not supported by U-Boot yet, VxWorks kernel must 81 be configured to use MP table and virtual wire interrupt mode. This requires 82 INCLUDE_MPTABLE_BOOT_OP and INCLUDE_VIRTUAL_WIRE_MODE to be included in a 83 VxWorks kernel configuration. 84 85 Both 32-bit x86 and 64-bit x64 kernels can be loaded. 86 87 There are two types of graphics console drivers in VxWorks. One is the 80x25 88 VGA text mode driver. The other one is the EFI console bitmapped graphics mode 89 driver. To make these drivers function, U-Boot needs to load and run the VGA 90 BIOS of the graphics card first. 91 92 - If the kernel is configured with 80x25 VGA text mode driver, 93 CONFIG_FRAMEBUFFER_SET_VESA_MODE must be unset in U-Boot. 94 - If the kernel is configured with bitmapped graphics mode driver, 95 CONFIG_FRAMEBUFFER_SET_VESA_MODE need remain set but care must be taken 96 at which VESA mode is to be set. The supported pixel format is 32-bit 97 RGBA, hence the available VESA mode can only be one of the following: 98 * FRAMEBUFFER_VESA_MODE_10F 99 * FRAMEBUFFER_VESA_MODE_112 100 * FRAMEBUFFER_VESA_MODE_115 101 * FRAMEBUFFER_VESA_MODE_118 102 * FRAMEBUFFER_VESA_MODE_11B 103
README.watchdog
1 Watchdog driver general info 2 3 CONFIG_HW_WATCHDOG 4 This enables hw_watchdog_reset to be called during various loops, 5 including waiting for a character on a serial port. But it 6 does not also call hw_watchdog_init. Boards which want this 7 enabled must call this function in their board file. This split 8 is useful because some rom's enable the watchdog when downloading 9 new code, so it must be serviced, but the board would rather it 10 was off. And, it cannot always be turned off once on. 11 12 CONFIG_WATCHDOG_TIMEOUT_MSECS 13 Can be used to change the timeout for i.mx31/35/5x/6x. 14 If not given, will default to maximum timeout. This would 15 be 128000 msec for i.mx31/35/5x/6x. 16 17 CONFIG_AT91SAM9_WATCHDOG 18 Available for AT91SAM9 to service the watchdog. 19 20 CONFIG_FTWDT010_WATCHDOG 21 Available for FTWDT010 to service the watchdog. 22 23 CONFIG_FTWDT010_HW_TIMEOUT 24 Can be used to change the timeout for FTWDT010. 25 26 CONFIG_IMX_WATCHDOG 27 Available for i.mx31/35/5x/6x to service the watchdog. This is not 28 automatically set because some boards (vision2) still need to define 29 their own hw_watchdog_reset routine. 30 TODO: vision2 is removed now, so perhaps this can be changed. 31 32 CONFIG_XILINX_TB_WATCHDOG 33 Available for Xilinx Axi platforms to service timebase watchdog timer. 34
README.x86
1 # SPDX-License-Identifier: GPL-2.0+ 2 # 3 # Copyright (C) 2014, Simon Glass <sjg (a] chromium.org> 4 # Copyright (C) 2014, Bin Meng <bmeng.cn (a] gmail.com> 5 6 U-Boot on x86 7 ============= 8 9 This document describes the information about U-Boot running on x86 targets, 10 including supported boards, build instructions, todo list, etc. 11 12 Status 13 ------ 14 U-Boot supports running as a coreboot [1] payload on x86. So far only Link 15 (Chromebook Pixel) and QEMU [2] x86 targets have been tested, but it should 16 work with minimal adjustments on other x86 boards since coreboot deals with 17 most of the low-level details. 18 19 U-Boot is a main bootloader on Intel Edison board. 20 21 U-Boot also supports booting directly from x86 reset vector, without coreboot. 22 In this case, known as bare mode, from the fact that it runs on the 23 'bare metal', U-Boot acts like a BIOS replacement. The following platforms 24 are supported: 25 26 - Bayley Bay CRB 27 - Cherry Hill CRB 28 - Congatec QEVAL 2.0 & conga-QA3/E3845 29 - Cougar Canyon 2 CRB 30 - Crown Bay CRB 31 - Galileo 32 - Link (Chromebook Pixel) 33 - Minnowboard MAX 34 - Samus (Chromebook Pixel 2015) 35 - QEMU x86 36 37 As for loading an OS, U-Boot supports directly booting a 32-bit or 64-bit 38 Linux kernel as part of a FIT image. It also supports a compressed zImage. 39 U-Boot supports loading an x86 VxWorks kernel. Please check README.vxworks 40 for more details. 41 42 Build Instructions for U-Boot as coreboot payload 43 ------------------------------------------------- 44 Building U-Boot as a coreboot payload is just like building U-Boot for targets 45 on other architectures, like below: 46 47 $ make coreboot_defconfig 48 $ make all 49 50 Note this default configuration will build a U-Boot payload for the QEMU board. 51 To build a coreboot payload against another board, you can change the build 52 configuration during the 'make menuconfig' process. 53 54 x86 architecture ---> 55 ... 56 (qemu-x86) Board configuration file 57 (qemu-x86_i440fx) Board Device Tree Source (dts) file 58 (0x01920000) Board specific Cache-As-RAM (CAR) address 59 (0x4000) Board specific Cache-As-RAM (CAR) size 60 61 Change the 'Board configuration file' and 'Board Device Tree Source (dts) file' 62 to point to a new board. You can also change the Cache-As-RAM (CAR) related 63 settings here if the default values do not fit your new board. 64 65 Build Instructions for U-Boot as main bootloader 66 ------------------------------------------------ 67 68 Intel Edison instructions: 69 70 Simple you can build U-Boot and obtain u-boot.bin 71 72 $ make edison_defconfig 73 $ make all 74 75 Build Instructions for U-Boot as BIOS replacement (bare mode) 76 ------------------------------------------------------------- 77 Building a ROM version of U-Boot (hereafter referred to as u-boot.rom) is a 78 little bit tricky, as generally it requires several binary blobs which are not 79 shipped in the U-Boot source tree. Due to this reason, the u-boot.rom build is 80 not turned on by default in the U-Boot source tree. Firstly, you need turn it 81 on by enabling the ROM build either via an environment variable 82 83 $ export BUILD_ROM=y 84 85 or via configuration 86 87 CONFIG_BUILD_ROM=y 88 89 Both tell the Makefile to build u-boot.rom as a target. 90 91 --- 92 93 Chromebook Link specific instructions for bare mode: 94 95 First, you need the following binary blobs: 96 97 * descriptor.bin - Intel flash descriptor 98 * me.bin - Intel Management Engine 99 * mrc.bin - Memory Reference Code, which sets up SDRAM 100 * video ROM - sets up the display 101 102 You can get these binary blobs by: 103 104 $ git clone http://review.coreboot.org/p/blobs.git 105 $ cd blobs 106 107 Find the following files: 108 109 * ./mainboard/google/link/descriptor.bin 110 * ./mainboard/google/link/me.bin 111 * ./northbridge/intel/sandybridge/systemagent-r6.bin 112 113 The 3rd one should be renamed to mrc.bin. 114 As for the video ROM, you can get it here [3] and rename it to vga.bin. 115 Make sure all these binary blobs are put in the board directory. 116 117 Now you can build U-Boot and obtain u-boot.rom: 118 119 $ make chromebook_link_defconfig 120 $ make all 121 122 --- 123 124 Chromebook Samus (2015 Pixel) instructions for bare mode: 125 126 First, you need the following binary blobs: 127 128 * descriptor.bin - Intel flash descriptor 129 * me.bin - Intel Management Engine 130 * mrc.bin - Memory Reference Code, which sets up SDRAM 131 * refcode.elf - Additional Reference code 132 * vga.bin - video ROM, which sets up the display 133 134 If you have a samus you can obtain them from your flash, for example, in 135 developer mode on the Chromebook (use Ctrl-Alt-F2 to obtain a terminal and 136 log in as 'root'): 137 138 cd /tmp 139 flashrom -w samus.bin 140 scp samus.bin username@ip_address:/path/to/somewhere 141 142 If not see the coreboot tree [4] where you can use: 143 144 bash crosfirmware.sh samus 145 146 to get the image. There is also an 'extract_blobs.sh' scripts that you can use 147 on the 'coreboot-Google_Samus.*' file to short-circuit some of the below. 148 149 Then 'ifdtool -x samus.bin' on your development machine will produce: 150 151 flashregion_0_flashdescriptor.bin 152 flashregion_1_bios.bin 153 flashregion_2_intel_me.bin 154 155 Rename flashregion_0_flashdescriptor.bin to descriptor.bin 156 Rename flashregion_2_intel_me.bin to me.bin 157 You can ignore flashregion_1_bios.bin - it is not used. 158 159 To get the rest, use 'cbfstool samus.bin print': 160 161 samus.bin: 8192 kB, bootblocksize 2864, romsize 8388608, offset 0x700000 162 alignment: 64 bytes, architecture: x86 163 164 Name Offset Type Size 165 cmos_layout.bin 0x700000 cmos_layout 1164 166 pci8086,0406.rom 0x7004c0 optionrom 65536 167 spd.bin 0x710500 (unknown) 4096 168 cpu_microcode_blob.bin 0x711540 microcode 70720 169 fallback/romstage 0x722a00 stage 54210 170 fallback/ramstage 0x72fe00 stage 96382 171 config 0x7476c0 raw 6075 172 fallback/vboot 0x748ec0 stage 15980 173 fallback/refcode 0x74cd80 stage 75578 174 fallback/payload 0x75f500 payload 62878 175 u-boot.dtb 0x76eb00 (unknown) 5318 176 (empty) 0x770000 null 196504 177 mrc.bin 0x79ffc0 (unknown) 222876 178 (empty) 0x7d66c0 null 167320 179 180 You can extract what you need: 181 182 cbfstool samus.bin extract -n pci8086,0406.rom -f vga.bin 183 cbfstool samus.bin extract -n fallback/refcode -f refcode.rmod 184 cbfstool samus.bin extract -n mrc.bin -f mrc.bin 185 cbfstool samus.bin extract -n fallback/refcode -f refcode.bin -U 186 187 Note that the -U flag is only supported by the latest cbfstool. It unpacks 188 and decompresses the stage to produce a coreboot rmodule. This is a simple 189 representation of an ELF file. You need the patch "Support decoding a stage 190 with compression". 191 192 Put all 5 files into board/google/chromebook_samus. 193 194 Now you can build U-Boot and obtain u-boot.rom: 195 196 $ make chromebook_link_defconfig 197 $ make all 198 199 If you are using em100, then this command will flash write -Boot: 200 201 em100 -s -d filename.rom -c W25Q64CV -r 202 203 --- 204 205 Intel Crown Bay specific instructions for bare mode: 206 207 U-Boot support of Intel Crown Bay board [4] relies on a binary blob called 208 Firmware Support Package [5] to perform all the necessary initialization steps 209 as documented in the BIOS Writer Guide, including initialization of the CPU, 210 memory controller, chipset and certain bus interfaces. 211 212 Download the Intel FSP for Atom E6xx series and Platform Controller Hub EG20T, 213 install it on your host and locate the FSP binary blob. Note this platform 214 also requires a Chipset Micro Code (CMC) state machine binary to be present in 215 the SPI flash where u-boot.rom resides, and this CMC binary blob can be found 216 in this FSP package too. 217 218 * ./FSP/QUEENSBAY_FSP_GOLD_001_20-DECEMBER-2013.fd 219 * ./Microcode/C0_22211.BIN 220 221 Rename the first one to fsp.bin and second one to cmc.bin and put them in the 222 board directory. 223 224 Note the FSP release version 001 has a bug which could cause random endless 225 loop during the FspInit call. This bug was published by Intel although Intel 226 did not describe any details. We need manually apply the patch to the FSP 227 binary using any hex editor (eg: bvi). Go to the offset 0x1fcd8 of the FSP 228 binary, change the following five bytes values from orginally E8 42 FF FF FF 229 to B8 00 80 0B 00. 230 231 As for the video ROM, you need manually extract it from the Intel provided 232 BIOS for Crown Bay here [6], using the AMI MMTool [7]. Check PCI option ROM 233 ID 8086:4108, extract and save it as vga.bin in the board directory. 234 235 Now you can build U-Boot and obtain u-boot.rom 236 237 $ make crownbay_defconfig 238 $ make all 239 240 --- 241 242 Intel Cougar Canyon 2 specific instructions for bare mode: 243 244 This uses Intel FSP for 3rd generation Intel Core and Intel Celeron processors 245 with mobile Intel HM76 and QM77 chipsets platform. Download it from Intel FSP 246 website and put the .fd file (CHIEFRIVER_FSP_GOLD_001_09-OCTOBER-2013.fd at the 247 time of writing) in the board directory and rename it to fsp.bin. 248 249 Now build U-Boot and obtain u-boot.rom 250 251 $ make cougarcanyon2_defconfig 252 $ make all 253 254 The board has two 8MB SPI flashes mounted, which are called SPI-0 and SPI-1 in 255 the board manual. The SPI-0 flash should have flash descriptor plus ME firmware 256 and SPI-1 flash is used to store U-Boot. For convenience, the complete 8MB SPI-0 257 flash image is included in the FSP package (named Rom00_8M_MB_PPT.bin). Program 258 this image to the SPI-0 flash according to the board manual just once and we are 259 all set. For programming U-Boot we just need to program SPI-1 flash. Since the 260 default u-boot.rom image for this board is set to 2MB, it should be programmed 261 to the last 2MB of the 8MB chip, address range [600000, 7FFFFF]. 262 263 --- 264 265 Intel Bay Trail based board instructions for bare mode: 266 267 This uses as FSP as with Crown Bay, except it is for the Atom E3800 series. 268 Two boards that use this configuration are Bayley Bay and Minnowboard MAX. 269 Download this and get the .fd file (BAYTRAIL_FSP_GOLD_003_16-SEP-2014.fd at 270 the time of writing). Put it in the corresponding board directory and rename 271 it to fsp.bin. 272 273 Obtain the VGA RAM (Vga.dat at the time of writing) and put it into the same 274 board directory as vga.bin. 275 276 You still need two more binary blobs. For Bayley Bay, they can be extracted 277 from the sample SPI image provided in the FSP (SPI.bin at the time of writing). 278 279 $ ./tools/ifdtool -x BayleyBay/SPI.bin 280 $ cp flashregion_0_flashdescriptor.bin board/intel/bayleybay/descriptor.bin 281 $ cp flashregion_2_intel_me.bin board/intel/bayleybay/me.bin 282 283 For Minnowboard MAX, we can reuse the same ME firmware above, but for flash 284 descriptor, we need get that somewhere else, as the one above does not seem to 285 work, probably because it is not designed for the Minnowboard MAX. Now download 286 the original firmware image for this board from: 287 288 http://firmware.intel.com/sites/default/files/2014-WW42.4-MinnowBoardMax.73-64-bit.bin_Release.zip 289 290 Unzip it: 291 292 $ unzip 2014-WW42.4-MinnowBoardMax.73-64-bit.bin_Release.zip 293 294 Use ifdtool in the U-Boot tools directory to extract the images from that 295 file, for example: 296 297 $ ./tools/ifdtool -x MNW2MAX1.X64.0073.R02.1409160934.bin 298 299 This will provide the descriptor file - copy this into the correct place: 300 301 $ cp flashregion_0_flashdescriptor.bin board/intel/minnowmax/descriptor.bin 302 303 Now you can build U-Boot and obtain u-boot.rom 304 Note: below are examples/information for Minnowboard MAX. 305 306 $ make minnowmax_defconfig 307 $ make all 308 309 Checksums are as follows (but note that newer versions will invalidate this): 310 311 $ md5sum -b board/intel/minnowmax/*.bin 312 ffda9a3b94df5b74323afb328d51e6b4 board/intel/minnowmax/descriptor.bin 313 69f65b9a580246291d20d08cbef9d7c5 board/intel/minnowmax/fsp.bin 314 894a97d371544ec21de9c3e8e1716c4b board/intel/minnowmax/me.bin 315 a2588537da387da592a27219d56e9962 board/intel/minnowmax/vga.bin 316 317 The ROM image is broken up into these parts: 318 319 Offset Description Controlling config 320 ------------------------------------------------------------ 321 000000 descriptor.bin Hard-coded to 0 in ifdtool 322 001000 me.bin Set by the descriptor 323 500000 <spare> 324 6ef000 Environment CONFIG_ENV_OFFSET 325 6f0000 MRC cache CONFIG_ENABLE_MRC_CACHE 326 700000 u-boot-dtb.bin CONFIG_SYS_TEXT_BASE 327 7b0000 vga.bin CONFIG_VGA_BIOS_ADDR 328 7c0000 fsp.bin CONFIG_FSP_ADDR 329 7f8000 <spare> (depends on size of fsp.bin) 330 7ff800 U-Boot 16-bit boot CONFIG_SYS_X86_START16 331 332 Overall ROM image size is controlled by CONFIG_ROM_SIZE. 333 334 Note that the debug version of the FSP is bigger in size. If this version 335 is used, CONFIG_FSP_ADDR needs to be configured to 0xfffb0000 instead of 336 the default value 0xfffc0000. 337 338 --- 339 340 Intel Cherry Hill specific instructions for bare mode: 341 342 This uses Intel FSP for Braswell platform. Download it from Intel FSP website, 343 put the .fd file to the board directory and rename it to fsp.bin. 344 345 Extract descriptor.bin and me.bin from the original BIOS on the board using 346 ifdtool and put them to the board directory as well. 347 348 Note the FSP package for Braswell does not ship a traditional legacy VGA BIOS 349 image for the integrated graphics device. Instead a new binary called Video 350 BIOS Table (VBT) is shipped. Put it to the board directory and rename it to 351 vbt.bin if you want graphics support in U-Boot. 352 353 Now you can build U-Boot and obtain u-boot.rom 354 355 $ make cherryhill_defconfig 356 $ make all 357 358 An important note for programming u-boot.rom to the on-board SPI flash is that 359 you need make sure the SPI flash's 'quad enable' bit in its status register 360 matches the settings in the descriptor.bin, otherwise the board won't boot. 361 362 For the on-board SPI flash MX25U6435F, this can be done by writing 0x40 to the 363 status register by DediProg in: Config > Modify Status Register > Write Status 364 Register(s) > Register1 Value(Hex). This is is a one-time change. Once set, it 365 persists in SPI flash part regardless of the u-boot.rom image burned. 366 367 --- 368 369 Intel Galileo instructions for bare mode: 370 371 Only one binary blob is needed for Remote Management Unit (RMU) within Intel 372 Quark SoC. Not like FSP, U-Boot does not call into the binary. The binary is 373 needed by the Quark SoC itself. 374 375 You can get the binary blob from Quark Board Support Package from Intel website: 376 377 * ./QuarkSocPkg/QuarkNorthCluster/Binary/QuarkMicrocode/RMU.bin 378 379 Rename the file and put it to the board directory by: 380 381 $ cp RMU.bin board/intel/galileo/rmu.bin 382 383 Now you can build U-Boot and obtain u-boot.rom 384 385 $ make galileo_defconfig 386 $ make all 387 388 --- 389 390 QEMU x86 target instructions for bare mode: 391 392 To build u-boot.rom for QEMU x86 targets, just simply run 393 394 $ make qemu-x86_defconfig 395 $ make all 396 397 Note this default configuration will build a U-Boot for the QEMU x86 i440FX 398 board. To build a U-Boot against QEMU x86 Q35 board, you can change the build 399 configuration during the 'make menuconfig' process like below: 400 401 Device Tree Control ---> 402 ... 403 (qemu-x86_q35) Default Device Tree for DT control 404 405 Test with coreboot 406 ------------------ 407 For testing U-Boot as the coreboot payload, there are things that need be paid 408 attention to. coreboot supports loading an ELF executable and a 32-bit plain 409 binary, as well as other supported payloads. With the default configuration, 410 U-Boot is set up to use a separate Device Tree Blob (dtb). As of today, the 411 generated u-boot-dtb.bin needs to be packaged by the cbfstool utility (a tool 412 provided by coreboot) manually as coreboot's 'make menuconfig' does not provide 413 this capability yet. The command is as follows: 414 415 # in the coreboot root directory 416 $ ./build/util/cbfstool/cbfstool build/coreboot.rom add-flat-binary \ 417 -f u-boot-dtb.bin -n fallback/payload -c lzma -l 0x1110000 -e 0x1110000 418 419 Make sure 0x1110000 matches CONFIG_SYS_TEXT_BASE, which is the symbol address 420 of _x86boot_start (in arch/x86/cpu/start.S). 421 422 If you want to use ELF as the coreboot payload, change U-Boot configuration to 423 use CONFIG_OF_EMBED instead of CONFIG_OF_SEPARATE. 424 425 To enable video you must enable these options in coreboot: 426 427 - Set framebuffer graphics resolution (1280x1024 32k-color (1:5:5)) 428 - Keep VESA framebuffer 429 430 And include coreboot_fb.dtsi in your board's device tree source file, like: 431 432 /include/ "coreboot_fb.dtsi" 433 434 At present it seems that for Minnowboard Max, coreboot does not pass through 435 the video information correctly (it always says the resolution is 0x0). This 436 works correctly for link though. 437 438 Note: coreboot framebuffer driver does not work on QEMU. The reason is unknown 439 at this point. Patches are welcome if you figure out anything wrong. 440 441 Test with QEMU for bare mode 442 ---------------------------- 443 QEMU is a fancy emulator that can enable us to test U-Boot without access to 444 a real x86 board. Please make sure your QEMU version is 2.3.0 or above test 445 U-Boot. To launch QEMU with u-boot.rom, call QEMU as follows: 446 447 $ qemu-system-i386 -nographic -bios path/to/u-boot.rom 448 449 This will instantiate an emulated x86 board with i440FX and PIIX chipset. QEMU 450 also supports emulating an x86 board with Q35 and ICH9 based chipset, which is 451 also supported by U-Boot. To instantiate such a machine, call QEMU with: 452 453 $ qemu-system-i386 -nographic -bios path/to/u-boot.rom -M q35 454 455 Note by default QEMU instantiated boards only have 128 MiB system memory. But 456 it is enough to have U-Boot boot and function correctly. You can increase the 457 system memory by pass '-m' parameter to QEMU if you want more memory: 458 459 $ qemu-system-i386 -nographic -bios path/to/u-boot.rom -m 1024 460 461 This creates a board with 1 GiB system memory. Currently U-Boot for QEMU only 462 supports 3 GiB maximum system memory and reserves the last 1 GiB address space 463 for PCI device memory-mapped I/O and other stuff, so the maximum value of '-m' 464 would be 3072. 465 466 QEMU emulates a graphic card which U-Boot supports. Removing '-nographic' will 467 show QEMU's VGA console window. Note this will disable QEMU's serial output. 468 If you want to check both consoles, use '-serial stdio'. 469 470 Multicore is also supported by QEMU via '-smp n' where n is the number of cores 471 to instantiate. Note, the maximum supported CPU number in QEMU is 255. 472 473 The fw_cfg interface in QEMU also provides information about kernel data, 474 initrd, command-line arguments and more. U-Boot supports directly accessing 475 these informtion from fw_cfg interface, which saves the time of loading them 476 from hard disk or network again, through emulated devices. To use it , simply 477 providing them in QEMU command line: 478 479 $ qemu-system-i386 -nographic -bios path/to/u-boot.rom -m 1024 -kernel /path/to/bzImage 480 -append 'root=/dev/ram console=ttyS0' -initrd /path/to/initrd -smp 8 481 482 Note: -initrd and -smp are both optional 483 484 Then start QEMU, in U-Boot command line use the following U-Boot command to 485 setup kernel: 486 487 => qfw 488 qfw - QEMU firmware interface 489 490 Usage: 491 qfw <command> 492 - list : print firmware(s) currently loaded 493 - cpus : print online cpu number 494 - load <kernel addr> <initrd addr> : load kernel and initrd (if any) and setup for zboot 495 496 => qfw load 497 loading kernel to address 01000000 size 5d9d30 initrd 04000000 size 1b1ab50 498 499 Here the kernel (bzImage) is loaded to 01000000 and initrd is to 04000000. Then, 500 'zboot' can be used to boot the kernel: 501 502 => zboot 01000000 - 04000000 1b1ab50 503 504 Updating U-Boot on Edison 505 ------------------------- 506 By default Intel Edison boards are shipped with preinstalled heavily 507 patched U-Boot v2014.04. Though it supports DFU which we may be able to 508 use. 509 510 1. Prepare u-boot.bin as described in chapter above. You still need one 511 more step (if and only if you have original U-Boot), i.e. run the 512 following command: 513 514 $ truncate -s %4096 u-boot.bin 515 516 2. Run your board and interrupt booting to U-Boot console. In the console 517 call: 518 519 => run do_force_flash_os 520 521 3. Wait for few seconds, it will prepare environment variable and runs 522 DFU. Run DFU command from the host system: 523 524 $ dfu-util -v -d 8087:0a99 --alt u-boot0 -D u-boot.bin 525 526 4. Return to U-Boot console and following hint. i.e. push Ctrl+C, and 527 reset the board: 528 529 => reset 530 531 CPU Microcode 532 ------------- 533 Modern CPUs usually require a special bit stream called microcode [8] to be 534 loaded on the processor after power up in order to function properly. U-Boot 535 has already integrated these as hex dumps in the source tree. 536 537 SMP Support 538 ----------- 539 On a multicore system, U-Boot is executed on the bootstrap processor (BSP). 540 Additional application processors (AP) can be brought up by U-Boot. In order to 541 have an SMP kernel to discover all of the available processors, U-Boot needs to 542 prepare configuration tables which contain the multi-CPUs information before 543 loading the OS kernel. Currently U-Boot supports generating two types of tables 544 for SMP, called Simple Firmware Interface (SFI) [9] and Multi-Processor (MP) 545 [10] tables. The writing of these two tables are controlled by two Kconfig 546 options GENERATE_SFI_TABLE and GENERATE_MP_TABLE. 547 548 Driver Model 549 ------------ 550 x86 has been converted to use driver model for serial, GPIO, SPI, SPI flash, 551 keyboard, real-time clock, USB. Video is in progress. 552 553 Device Tree 554 ----------- 555 x86 uses device tree to configure the board thus requires CONFIG_OF_CONTROL to 556 be turned on. Not every device on the board is configured via device tree, but 557 more and more devices will be added as time goes by. Check out the directory 558 arch/x86/dts/ for these device tree source files. 559 560 Useful Commands 561 --------------- 562 In keeping with the U-Boot philosophy of providing functions to check and 563 adjust internal settings, there are several x86-specific commands that may be 564 useful: 565 566 fsp - Display information about Intel Firmware Support Package (FSP). 567 This is only available on platforms which use FSP, mostly Atom. 568 iod - Display I/O memory 569 iow - Write I/O memory 570 mtrr - List and set the Memory Type Range Registers (MTRR). These are used to 571 tell the CPU whether memory is cacheable and if so the cache write 572 mode to use. U-Boot sets up some reasonable values but you can 573 adjust then with this command. 574 575 Booting Ubuntu 576 -------------- 577 As an example of how to set up your boot flow with U-Boot, here are 578 instructions for starting Ubuntu from U-Boot. These instructions have been 579 tested on Minnowboard MAX with a SATA drive but are equally applicable on 580 other platforms and other media. There are really only four steps and it's a 581 very simple script, but a more detailed explanation is provided here for 582 completeness. 583 584 Note: It is possible to set up U-Boot to boot automatically using syslinux. 585 It could also use the grub.cfg file (/efi/ubuntu/grub.cfg) to obtain the 586 GUID. If you figure these out, please post patches to this README. 587 588 Firstly, you will need Ubuntu installed on an available disk. It should be 589 possible to make U-Boot start a USB start-up disk but for now let's assume 590 that you used another boot loader to install Ubuntu. 591 592 Use the U-Boot command line to find the UUID of the partition you want to 593 boot. For example our disk is SCSI device 0: 594 595 => part list scsi 0 596 597 Partition Map for SCSI device 0 -- Partition Type: EFI 598 599 Part Start LBA End LBA Name 600 Attributes 601 Type GUID 602 Partition GUID 603 1 0x00000800 0x001007ff "" 604 attrs: 0x0000000000000000 605 type: c12a7328-f81f-11d2-ba4b-00a0c93ec93b 606 guid: 9d02e8e4-4d59-408f-a9b0-fd497bc9291c 607 2 0x00100800 0x037d8fff "" 608 attrs: 0x0000000000000000 609 type: 0fc63daf-8483-4772-8e79-3d69d8477de4 610 guid: 965c59ee-1822-4326-90d2-b02446050059 611 3 0x037d9000 0x03ba27ff "" 612 attrs: 0x0000000000000000 613 type: 0657fd6d-a4ab-43c4-84e5-0933c84b4f4f 614 guid: 2c4282bd-1e82-4bcf-a5ff-51dedbf39f17 615 => 616 617 This shows that your SCSI disk has three partitions. The really long hex 618 strings are called Globally Unique Identifiers (GUIDs). You can look up the 619 'type' ones here [11]. On this disk the first partition is for EFI and is in 620 VFAT format (DOS/Windows): 621 622 => fatls scsi 0:1 623 efi/ 624 625 0 file(s), 1 dir(s) 626 627 628 Partition 2 is 'Linux filesystem data' so that will be our root disk. It is 629 in ext2 format: 630 631 => ext2ls scsi 0:2 632 <DIR> 4096 . 633 <DIR> 4096 .. 634 <DIR> 16384 lost+found 635 <DIR> 4096 boot 636 <DIR> 12288 etc 637 <DIR> 4096 media 638 <DIR> 4096 bin 639 <DIR> 4096 dev 640 <DIR> 4096 home 641 <DIR> 4096 lib 642 <DIR> 4096 lib64 643 <DIR> 4096 mnt 644 <DIR> 4096 opt 645 <DIR> 4096 proc 646 <DIR> 4096 root 647 <DIR> 4096 run 648 <DIR> 12288 sbin 649 <DIR> 4096 srv 650 <DIR> 4096 sys 651 <DIR> 4096 tmp 652 <DIR> 4096 usr 653 <DIR> 4096 var 654 <SYM> 33 initrd.img 655 <SYM> 30 vmlinuz 656 <DIR> 4096 cdrom 657 <SYM> 33 initrd.img.old 658 => 659 660 and if you look in the /boot directory you will see the kernel: 661 662 => ext2ls scsi 0:2 /boot 663 <DIR> 4096 . 664 <DIR> 4096 .. 665 <DIR> 4096 efi 666 <DIR> 4096 grub 667 3381262 System.map-3.13.0-32-generic 668 1162712 abi-3.13.0-32-generic 669 165611 config-3.13.0-32-generic 670 176500 memtest86+.bin 671 178176 memtest86+.elf 672 178680 memtest86+_multiboot.bin 673 5798112 vmlinuz-3.13.0-32-generic 674 165762 config-3.13.0-58-generic 675 1165129 abi-3.13.0-58-generic 676 5823136 vmlinuz-3.13.0-58-generic 677 19215259 initrd.img-3.13.0-58-generic 678 3391763 System.map-3.13.0-58-generic 679 5825048 vmlinuz-3.13.0-58-generic.efi.signed 680 28304443 initrd.img-3.13.0-32-generic 681 => 682 683 The 'vmlinuz' files contain a packaged Linux kernel. The format is a kind of 684 self-extracting compressed file mixed with some 'setup' configuration data. 685 Despite its size (uncompressed it is >10MB) this only includes a basic set of 686 device drivers, enough to boot on most hardware types. 687 688 The 'initrd' files contain a RAM disk. This is something that can be loaded 689 into RAM and will appear to Linux like a disk. Ubuntu uses this to hold lots 690 of drivers for whatever hardware you might have. It is loaded before the 691 real root disk is accessed. 692 693 The numbers after the end of each file are the version. Here it is Linux 694 version 3.13. You can find the source code for this in the Linux tree with 695 the tag v3.13. The '.0' allows for additional Linux releases to fix problems, 696 but normally this is not needed. The '-58' is used by Ubuntu. Each time they 697 release a new kernel they increment this number. New Ubuntu versions might 698 include kernel patches to fix reported bugs. Stable kernels can exist for 699 some years so this number can get quite high. 700 701 The '.efi.signed' kernel is signed for EFI's secure boot. U-Boot has its own 702 secure boot mechanism - see [12] [13] and cannot read .efi files at present. 703 704 To boot Ubuntu from U-Boot the steps are as follows: 705 706 1. Set up the boot arguments. Use the GUID for the partition you want to 707 boot: 708 709 => setenv bootargs root=/dev/disk/by-partuuid/965c59ee-1822-4326-90d2-b02446050059 ro 710 711 Here root= tells Linux the location of its root disk. The disk is specified 712 by its GUID, using '/dev/disk/by-partuuid/', a Linux path to a 'directory' 713 containing all the GUIDs Linux has found. When it starts up, there will be a 714 file in that directory with this name in it. It is also possible to use a 715 device name here, see later. 716 717 2. Load the kernel. Since it is an ext2/4 filesystem we can do: 718 719 => ext2load scsi 0:2 03000000 /boot/vmlinuz-3.13.0-58-generic 720 721 The address 30000000 is arbitrary, but there seem to be problems with using 722 small addresses (sometimes Linux cannot find the ramdisk). This is 48MB into 723 the start of RAM (which is at 0 on x86). 724 725 3. Load the ramdisk (to 64MB): 726 727 => ext2load scsi 0:2 04000000 /boot/initrd.img-3.13.0-58-generic 728 729 4. Start up the kernel. We need to know the size of the ramdisk, but can use 730 a variable for that. U-Boot sets 'filesize' to the size of the last file it 731 loaded. 732 733 => zboot 03000000 0 04000000 ${filesize} 734 735 Type 'help zboot' if you want to see what the arguments are. U-Boot on x86 is 736 quite verbose when it boots a kernel. You should see these messages from 737 U-Boot: 738 739 Valid Boot Flag 740 Setup Size = 0x00004400 741 Magic signature found 742 Using boot protocol version 2.0c 743 Linux kernel version 3.13.0-58-generic (buildd@allspice) #97-Ubuntu SMP Wed Jul 8 02:56:15 UTC 2015 744 Building boot_params at 0x00090000 745 Loading bzImage at address 100000 (5805728 bytes) 746 Magic signature found 747 Initial RAM disk at linear address 0x04000000, size 19215259 bytes 748 Kernel command line: "root=/dev/disk/by-partuuid/965c59ee-1822-4326-90d2-b02446050059 ro" 749 750 Starting kernel ... 751 752 U-Boot prints out some bootstage timing. This is more useful if you put the 753 above commands into a script since then it will be faster. 754 755 Timer summary in microseconds: 756 Mark Elapsed Stage 757 0 0 reset 758 241,535 241,535 board_init_r 759 2,421,611 2,180,076 id=64 760 2,421,790 179 id=65 761 2,428,215 6,425 main_loop 762 48,860,584 46,432,369 start_kernel 763 764 Accumulated time: 765 240,329 ahci 766 1,422,704 vesa display 767 768 Now the kernel actually starts: (if you want to examine kernel boot up message 769 on the serial console, append "console=ttyS0,115200" to the kernel command line) 770 771 [ 0.000000] Initializing cgroup subsys cpuset 772 [ 0.000000] Initializing cgroup subsys cpu 773 [ 0.000000] Initializing cgroup subsys cpuacct 774 [ 0.000000] Linux version 3.13.0-58-generic (buildd@allspice) (gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) ) #97-Ubuntu SMP Wed Jul 8 02:56:15 UTC 2015 (Ubuntu 3.13.0-58.97-generic 3.13.11-ckt22) 775 [ 0.000000] Command line: root=/dev/disk/by-partuuid/965c59ee-1822-4326-90d2-b02446050059 ro console=ttyS0,115200 776 777 It continues for a long time. Along the way you will see it pick up your 778 ramdisk: 779 780 [ 0.000000] RAMDISK: [mem 0x04000000-0x05253fff] 781 ... 782 [ 0.788540] Trying to unpack rootfs image as initramfs... 783 [ 1.540111] Freeing initrd memory: 18768K (ffff880004000000 - ffff880005254000) 784 ... 785 786 Later it actually starts using it: 787 788 Begin: Running /scripts/local-premount ... done. 789 790 You should also see your boot disk turn up: 791 792 [ 4.357243] scsi 1:0:0:0: Direct-Access ATA ADATA SP310 5.2 PQ: 0 ANSI: 5 793 [ 4.366860] sd 1:0:0:0: [sda] 62533296 512-byte logical blocks: (32.0 GB/29.8 GiB) 794 [ 4.375677] sd 1:0:0:0: Attached scsi generic sg0 type 0 795 [ 4.381859] sd 1:0:0:0: [sda] Write Protect is off 796 [ 4.387452] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA 797 [ 4.399535] sda: sda1 sda2 sda3 798 799 Linux has found the three partitions (sda1-3). Mercifully it doesn't print out 800 the GUIDs. In step 1 above we could have used: 801 802 setenv bootargs root=/dev/sda2 ro 803 804 instead of the GUID. However if you add another drive to your board the 805 numbering may change whereas the GUIDs will not. So if your boot partition 806 becomes sdb2, it will still boot. For embedded systems where you just want to 807 boot the first disk, you have that option. 808 809 The last thing you will see on the console is mention of plymouth (which 810 displays the Ubuntu start-up screen) and a lot of 'Starting' messages: 811 812 * Starting Mount filesystems on boot [ OK ] 813 814 After a pause you should see a login screen on your display and you are done. 815 816 If you want to put this in a script you can use something like this: 817 818 setenv bootargs root=UUID=b2aaf743-0418-4d90-94cc-3e6108d7d968 ro 819 setenv boot zboot 03000000 0 04000000 \${filesize} 820 setenv bootcmd "ext2load scsi 0:2 03000000 /boot/vmlinuz-3.13.0-58-generic; ext2load scsi 0:2 04000000 /boot/initrd.img-3.13.0-58-generic; run boot" 821 saveenv 822 823 The \ is to tell the shell not to evaluate ${filesize} as part of the setenv 824 command. 825 826 You can also bake this behaviour into your build by hard-coding the 827 environment variables if you add this to minnowmax.h: 828 829 #undef CONFIG_BOOTCOMMAND 830 #define CONFIG_BOOTCOMMAND \ 831 "ext2load scsi 0:2 03000000 /boot/vmlinuz-3.13.0-58-generic; " \ 832 "ext2load scsi 0:2 04000000 /boot/initrd.img-3.13.0-58-generic; " \ 833 "run boot" 834 835 #undef CONFIG_EXTRA_ENV_SETTINGS 836 #define CONFIG_EXTRA_ENV_SETTINGS "boot=zboot 03000000 0 04000000 ${filesize}" 837 838 and change CONFIG_BOOTARGS value in configs/minnowmax_defconfig to: 839 840 CONFIG_BOOTARGS="root=/dev/sda2 ro" 841 842 Test with SeaBIOS 843 ----------------- 844 SeaBIOS [14] is an open source implementation of a 16-bit x86 BIOS. It can run 845 in an emulator or natively on x86 hardware with the use of U-Boot. With its 846 help, we can boot some OSes that require 16-bit BIOS services like Windows/DOS. 847 848 As U-Boot, we have to manually create a table where SeaBIOS gets various system 849 information (eg: E820) from. The table unfortunately has to follow the coreboot 850 table format as SeaBIOS currently supports booting as a coreboot payload. 851 852 To support loading SeaBIOS, U-Boot should be built with CONFIG_SEABIOS on. 853 Booting SeaBIOS is done via U-Boot's bootelf command, like below: 854 855 => tftp bios.bin.elf;bootelf 856 Using e1000#0 device 857 TFTP from server 10.10.0.100; our IP address is 10.10.0.108 858 ... 859 Bytes transferred = 122124 (1dd0c hex) 860 ## Starting application at 0x000ff06e ... 861 SeaBIOS (version rel-1.9.0) 862 ... 863 864 bios.bin.elf is the SeaBIOS image built from SeaBIOS source tree. 865 Make sure it is built as follows: 866 867 $ make menuconfig 868 869 Inside the "General Features" menu, select "Build for coreboot" as the 870 "Build Target". Inside the "Debugging" menu, turn on "Serial port debugging" 871 so that we can see something as soon as SeaBIOS boots. Leave other options 872 as in their default state. Then, 873 874 $ make 875 ... 876 Total size: 121888 Fixed: 66496 Free: 9184 (used 93.0% of 128KiB rom) 877 Creating out/bios.bin.elf 878 879 Currently this is tested on QEMU x86 target with U-Boot chain-loading SeaBIOS 880 to install/boot a Windows XP OS (below for example command to install Windows). 881 882 # Create a 10G disk.img as the virtual hard disk 883 $ qemu-img create -f qcow2 disk.img 10G 884 885 # Install a Windows XP OS from an ISO image 'winxp.iso' 886 $ qemu-system-i386 -serial stdio -bios u-boot.rom -hda disk.img -cdrom winxp.iso -smp 2 -m 512 887 888 # Boot a Windows XP OS installed on the virutal hard disk 889 $ qemu-system-i386 -serial stdio -bios u-boot.rom -hda disk.img -smp 2 -m 512 890 891 This is also tested on Intel Crown Bay board with a PCIe graphics card, booting 892 SeaBIOS then chain-loading a GRUB on a USB drive, then Linux kernel finally. 893 894 If you are using Intel Integrated Graphics Device (IGD) as the primary display 895 device on your board, SeaBIOS needs to be patched manually to get its VGA ROM 896 loaded and run by SeaBIOS. SeaBIOS locates VGA ROM via the PCI expansion ROM 897 register, but IGD device does not have its VGA ROM mapped by this register. 898 Its VGA ROM is packaged as part of u-boot.rom at a configurable flash address 899 which is unknown to SeaBIOS. An example patch is needed for SeaBIOS below: 900 901 diff --git a/src/optionroms.c b/src/optionroms.c 902 index 65f7fe0..c7b6f5e 100644 903 --- a/src/optionroms.c 904 +++ b/src/optionroms.c 905 @@ -324,6 +324,8 @@ init_pcirom(struct pci_device *pci, int isvga, u64 *sources) 906 rom = deploy_romfile(file); 907 else if (RunPCIroms > 1 || (RunPCIroms == 1 && isvga)) 908 rom = map_pcirom(pci); 909 + if (pci->bdf == pci_to_bdf(0, 2, 0)) 910 + rom = (struct rom_header *)0xfff90000; 911 if (! rom) 912 // No ROM present. 913 return; 914 915 Note: the patch above expects IGD device is at PCI b.d.f 0.2.0 and its VGA ROM 916 is at 0xfff90000 which corresponds to CONFIG_VGA_BIOS_ADDR on Minnowboard MAX. 917 Change these two accordingly if this is not the case on your board. 918 919 Development Flow 920 ---------------- 921 These notes are for those who want to port U-Boot to a new x86 platform. 922 923 Since x86 CPUs boot from SPI flash, a SPI flash emulator is a good investment. 924 The Dediprog em100 can be used on Linux. The em100 tool is available here: 925 926 http://review.coreboot.org/p/em100.git 927 928 On Minnowboard Max the following command line can be used: 929 930 sudo em100 -s -p LOW -d u-boot.rom -c W25Q64DW -r 931 932 A suitable clip for connecting over the SPI flash chip is here: 933 934 http://www.dediprog.com/pd/programmer-accessories/EM-TC-8 935 936 This allows you to override the SPI flash contents for development purposes. 937 Typically you can write to the em100 in around 1200ms, considerably faster 938 than programming the real flash device each time. The only important 939 limitation of the em100 is that it only supports SPI bus speeds up to 20MHz. 940 This means that images must be set to boot with that speed. This is an 941 Intel-specific feature - e.g. tools/ifttool has an option to set the SPI 942 speed in the SPI descriptor region. 943 944 If your chip/board uses an Intel Firmware Support Package (FSP) it is fairly 945 easy to fit it in. You can follow the Minnowboard Max implementation, for 946 example. Hopefully you will just need to create new files similar to those 947 in arch/x86/cpu/baytrail which provide Bay Trail support. 948 949 If you are not using an FSP you have more freedom and more responsibility. 950 The ivybridge support works this way, although it still uses a ROM for 951 graphics and still has binary blobs containing Intel code. You should aim to 952 support all important peripherals on your platform including video and storage. 953 Use the device tree for configuration where possible. 954 955 For the microcode you can create a suitable device tree file using the 956 microcode tool: 957 958 ./tools/microcode-tool -d microcode.dat -m <model> create 959 960 or if you only have header files and not the full Intel microcode.dat database: 961 962 ./tools/microcode-tool -H BAY_TRAIL_FSP_KIT/Microcode/M0130673322.h \ 963 -H BAY_TRAIL_FSP_KIT/Microcode/M0130679901.h \ 964 -m all create 965 966 These are written to arch/x86/dts/microcode/ by default. 967 968 Note that it is possible to just add the micrcode for your CPU if you know its 969 model. U-Boot prints this information when it starts 970 971 CPU: x86_64, vendor Intel, device 30673h 972 973 so here we can use the M0130673322 file. 974 975 If you platform can display POST codes on two little 7-segment displays on 976 the board, then you can use post_code() calls from C or assembler to monitor 977 boot progress. This can be good for debugging. 978 979 If not, you can try to get serial working as early as possible. The early 980 debug serial port may be useful here. See setup_internal_uart() for an example. 981 982 During the U-Boot porting, one of the important steps is to write correct PIRQ 983 routing information in the board device tree. Without it, device drivers in the 984 Linux kernel won't function correctly due to interrupt is not working. Please 985 refer to U-Boot doc [15] for the device tree bindings of Intel interrupt router. 986 Here we have more details on the intel,pirq-routing property below. 987 988 intel,pirq-routing = < 989 PCI_BDF(0, 2, 0) INTA PIRQA 990 ... 991 >; 992 993 As you see each entry has 3 cells. For the first one, we need describe all pci 994 devices mounted on the board. For SoC devices, normally there is a chapter on 995 the chipset datasheet which lists all the available PCI devices. For example on 996 Bay Trail, this is chapter 4.3 (PCI configuration space). For the second one, we 997 can get the interrupt pin either from datasheet or hardware via U-Boot shell. 998 The reliable source is the hardware as sometimes chipset datasheet is not 100% 999 up-to-date. Type 'pci header' plus the device's pci bus/device/function number 1000 from U-Boot shell below. 1001 1002 => pci header 0.1e.1 1003 vendor ID = 0x8086 1004 device ID = 0x0f08 1005 ... 1006 interrupt line = 0x09 1007 interrupt pin = 0x04 1008 ... 1009 1010 It shows this PCI device is using INTD pin as it reports 4 in the interrupt pin 1011 register. Repeat this until you get interrupt pins for all the devices. The last 1012 cell is the PIRQ line which a particular interrupt pin is mapped to. On Intel 1013 chipset, the power-up default mapping is INTA/B/C/D maps to PIRQA/B/C/D. This 1014 can be changed by registers in LPC bridge. So far Intel FSP does not touch those 1015 registers so we can write down the PIRQ according to the default mapping rule. 1016 1017 Once we get the PIRQ routing information in the device tree, the interrupt 1018 allocation and assignment will be done by U-Boot automatically. Now you can 1019 enable CONFIG_GENERATE_PIRQ_TABLE for testing Linux kernel using i8259 PIC and 1020 CONFIG_GENERATE_MP_TABLE for testing Linux kernel using local APIC and I/O APIC. 1021 1022 This script might be useful. If you feed it the output of 'pci long' from 1023 U-Boot then it will generate a device tree fragment with the interrupt 1024 configuration for each device (note it needs gawk 4.0.0): 1025 1026 $ cat console_output |awk '/PCI/ {device=$4} /interrupt line/ {line=$4} \ 1027 /interrupt pin/ {pin = $4; if (pin != "0x00" && pin != "0xff") \ 1028 {patsplit(device, bdf, "[0-9a-f]+"); \ 1029 printf "PCI_BDF(%d, %d, %d) INT%c PIRQ%c\n", strtonum("0x" bdf[1]), \ 1030 strtonum("0x" bdf[2]), bdf[3], strtonum(pin) + 64, 64 + strtonum(pin)}}' 1031 1032 Example output: 1033 PCI_BDF(0, 2, 0) INTA PIRQA 1034 PCI_BDF(0, 3, 0) INTA PIRQA 1035 ... 1036 1037 Porting Hints 1038 ------------- 1039 1040 Quark-specific considerations: 1041 1042 To port U-Boot to other boards based on the Intel Quark SoC, a few things need 1043 to be taken care of. The first important part is the Memory Reference Code (MRC) 1044 parameters. Quark MRC supports memory-down configuration only. All these MRC 1045 parameters are supplied via the board device tree. To get started, first copy 1046 the MRC section of arch/x86/dts/galileo.dts to your board's device tree, then 1047 change these values by consulting board manuals or your hardware vendor. 1048 Available MRC parameter values are listed in include/dt-bindings/mrc/quark.h. 1049 The other tricky part is with PCIe. Quark SoC integrates two PCIe root ports, 1050 but by default they are held in reset after power on. In U-Boot, PCIe 1051 initialization is properly handled as per Quark's firmware writer guide. 1052 In your board support codes, you need provide two routines to aid PCIe 1053 initialization, which are board_assert_perst() and board_deassert_perst(). 1054 The two routines need implement a board-specific mechanism to assert/deassert 1055 PCIe PERST# pin. Care must be taken that in those routines that any APIs that 1056 may trigger PCI enumeration process are strictly forbidden, as any access to 1057 PCIe root port's configuration registers will cause system hang while it is 1058 held in reset. For more details, check how they are implemented by the Intel 1059 Galileo board support codes in board/intel/galileo/galileo.c. 1060 1061 coreboot: 1062 1063 See scripts/coreboot.sed which can assist with porting coreboot code into 1064 U-Boot drivers. It will not resolve all build errors, but will perform common 1065 transformations. Remember to add attribution to coreboot for new files added 1066 to U-Boot. This should go at the top of each file and list the coreboot 1067 filename where the code originated. 1068 1069 Debugging ACPI issues with Windows: 1070 1071 Windows might cache system information and only detect ACPI changes if you 1072 modify the ACPI table versions. So tweak them liberally when debugging ACPI 1073 issues with Windows. 1074 1075 ACPI Support Status 1076 ------------------- 1077 Advanced Configuration and Power Interface (ACPI) [16] aims to establish 1078 industry-standard interfaces enabling OS-directed configuration, power 1079 management, and thermal management of mobile, desktop, and server platforms. 1080 1081 Linux can boot without ACPI with "acpi=off" command line parameter, but 1082 with ACPI the kernel gains the capabilities to handle power management. 1083 For Windows, ACPI is a must-have firmware feature since Windows Vista. 1084 CONFIG_GENERATE_ACPI_TABLE is the config option to turn on ACPI support in 1085 U-Boot. This requires Intel ACPI compiler to be installed on your host to 1086 compile ACPI DSDT table written in ASL format to AML format. You can get 1087 the compiler via "apt-get install iasl" if you are on Ubuntu or download 1088 the source from [17] to compile one by yourself. 1089 1090 Current ACPI support in U-Boot is basically complete. More optional features 1091 can be added in the future. The status as of today is: 1092 1093 * Support generating RSDT, XSDT, FACS, FADT, MADT, MCFG tables. 1094 * Support one static DSDT table only, compiled by Intel ACPI compiler. 1095 * Support S0/S3/S4/S5, reboot and shutdown from OS. 1096 * Support booting a pre-installed Ubuntu distribution via 'zboot' command. 1097 * Support installing and booting Ubuntu 14.04 (or above) from U-Boot with 1098 the help of SeaBIOS using legacy interface (non-UEFI mode). 1099 * Support installing and booting Windows 8.1/10 from U-Boot with the help 1100 of SeaBIOS using legacy interface (non-UEFI mode). 1101 * Support ACPI interrupts with SCI only. 1102 1103 Features that are optional: 1104 * Dynamic AML bytecodes insertion at run-time. We may need this to support 1105 SSDT table generation and DSDT fix up. 1106 * SMI support. Since U-Boot is a modern bootloader, we don't want to bring 1107 those legacy stuff into U-Boot. ACPI spec allows a system that does not 1108 support SMI (a legacy-free system). 1109 1110 ACPI was initially enabled on BayTrail based boards. Testing was done by booting 1111 a pre-installed Ubuntu 14.04 from a SATA drive. Installing Ubuntu 14.04 and 1112 Windows 8.1/10 to a SATA drive and booting from there is also tested. Most 1113 devices seem to work correctly and the board can respond a reboot/shutdown 1114 command from the OS. 1115 1116 For other platform boards, ACPI support status can be checked by examining their 1117 board defconfig files to see if CONFIG_GENERATE_ACPI_TABLE is set to y. 1118 1119 The S3 sleeping state is a low wake latency sleeping state defined by ACPI 1120 spec where all system context is lost except system memory. To test S3 resume 1121 with a Linux kernel, simply run "echo mem > /sys/power/state" and kernel will 1122 put the board to S3 state where the power is off. So when the power button is 1123 pressed again, U-Boot runs as it does in cold boot and detects the sleeping 1124 state via ACPI register to see if it is S3, if yes it means we are waking up. 1125 U-Boot is responsible for restoring the machine state as it is before sleep. 1126 When everything is done, U-Boot finds out the wakeup vector provided by OSes 1127 and jump there. To determine whether ACPI S3 resume is supported, check to 1128 see if CONFIG_HAVE_ACPI_RESUME is set for that specific board. 1129 1130 Note for testing S3 resume with Windows, correct graphics driver must be 1131 installed for your platform, otherwise you won't find "Sleep" option in 1132 the "Power" submenu from the Windows start menu. 1133 1134 EFI Support 1135 ----------- 1136 U-Boot supports booting as a 32-bit or 64-bit EFI payload, e.g. with UEFI. 1137 This is enabled with CONFIG_EFI_STUB to boot from both 32-bit and 64-bit 1138 UEFI BIOS. U-Boot can also run as an EFI application, with CONFIG_EFI_APP. 1139 The CONFIG_EFI_LOADER option, where U-Boot provides an EFI environment to 1140 the kernel (i.e. replaces UEFI completely but provides the same EFI run-time 1141 services) is supported too. For example, we can even use 'bootefi' command 1142 to load a 'u-boot-payload.efi', see below test logs on QEMU. 1143 1144 => load ide 0 3000000 u-boot-payload.efi 1145 489787 bytes read in 138 ms (3.4 MiB/s) 1146 => bootefi 3000000 1147 Scanning disk ide.blk#0... 1148 Found 2 disks 1149 WARNING: booting without device tree 1150 ## Starting EFI application at 03000000 ... 1151 U-Boot EFI Payload 1152 1153 1154 U-Boot 2018.07-rc2 (Jun 23 2018 - 17:12:58 +0800) 1155 1156 CPU: x86_64, vendor AMD, device 663h 1157 DRAM: 2 GiB 1158 MMC: 1159 Video: 1024x768x32 1160 Model: EFI x86 Payload 1161 Net: e1000: 52:54:00:12:34:56 1162 1163 Warning: e1000#0 using MAC address from ROM 1164 eth0: e1000#0 1165 No controllers found 1166 Hit any key to stop autoboot: 0 1167 1168 See README.u-boot_on_efi and README.uefi for details of EFI support in U-Boot. 1169 1170 64-bit Support 1171 -------------- 1172 U-Boot supports booting a 64-bit kernel directly and is able to change to 1173 64-bit mode to do so. However, U-Boot itself is currently always built 1174 in 32-bit mode. Some access to the full memory range is provided with 1175 arch_phys_memset(). 1176 1177 The development work to make U-Boot itself run in 64-bit mode has not yet 1178 been attempted. The best approach would likely be to build a 32-bit SPL 1179 image for U-Boot, with CONFIG_SPL_BUILD. This could then handle the early CPU 1180 init in 16-bit and 32-bit mode, running the FSP and any other binaries that 1181 are needed. Then it could change to 64-bit model and jump to U-Boot proper. 1182 1183 Given U-Boot's extensive 64-bit support this has not been a high priority, 1184 but it would be a nice addition. 1185 1186 TODO List 1187 --------- 1188 - Audio 1189 - Chrome OS verified boot 1190 - Building U-Boot to run in 64-bit mode 1191 1192 References 1193 ---------- 1194 [1] http://www.coreboot.org 1195 [2] http://www.qemu.org 1196 [3] http://www.coreboot.org/~stepan/pci8086,0166.rom 1197 [4] http://www.intel.com/content/www/us/en/embedded/design-tools/evaluation-platforms/atom-e660-eg20t-development-kit.html 1198 [5] http://www.intel.com/fsp 1199 [6] http://www.intel.com/content/www/us/en/secure/intelligent-systems/privileged/e6xx-35-b1-cmc22211.html 1200 [7] http://www.ami.com/products/bios-uefi-tools-and-utilities/bios-uefi-utilities/ 1201 [8] http://en.wikipedia.org/wiki/Microcode 1202 [9] http://simplefirmware.org 1203 [10] http://www.intel.com/design/archives/processors/pro/docs/242016.htm 1204 [11] https://en.wikipedia.org/wiki/GUID_Partition_Table 1205 [12] http://events.linuxfoundation.org/sites/events/files/slides/chromeos_and_diy_vboot_0.pdf 1206 [13] http://events.linuxfoundation.org/sites/events/files/slides/elce-2014.pdf 1207 [14] http://www.seabios.org/SeaBIOS 1208 [15] doc/device-tree-bindings/misc/intel,irq-router.txt 1209 [16] http://www.acpi.info 1210 [17] https://www.acpica.org/downloads 1211
README.xtensa
1 U-Boot for the Xtensa Architecture 2 ================================== 3 4 Xtensa Architecture and Diamond Cores 5 ------------------------------------- 6 7 Xtensa is a configurable processor architecture from Tensilica, Inc. 8 Diamond Cores are pre-configured instances available for license and 9 SoC cores in the same manner as ARM, MIPS, etc. 10 11 Xtensa licensees create their own Xtensa cores with selected features 12 and custom instructions, registers and co-processors. The custom core 13 is configured with Tensilica tools and built with Tensilica's Xtensa 14 Processor Generator. 15 16 There are an effectively infinite number of CPUs in the Xtensa 17 architecture family. It is, however, not feasible to support individual 18 Xtensa CPUs in U-Boot. Therefore, there is only a single 'xtensa' CPU 19 in the cpu tree of U-Boot. 20 21 In the same manner as the Linux port to Xtensa, U-Boot adapts to an 22 individual Xtensa core configuration using a set of macros provided with 23 the particular core. This is part of what is known as the hardware 24 abstraction layer (HAL). For the purpose of U-Boot, the HAL consists only 25 of a few header files. These provide CPP macros that customize sources, 26 Makefiles, and the linker script. 27 28 29 Adding support for an additional processor configuration 30 -------------------------------------------------------- 31 32 The header files for one particular processor configuration are inside 33 a variant-specific directory located in the arch/xtensa/include/asm 34 directory. The name of that directory starts with 'arch-' followed by 35 the name for the processor configuration, for example, arch-dc233c for 36 the Diamond DC233 processor. 37 38 core.h Definitions for the core itself. 39 40 The following files are part of the overlay but not used by U-Boot. 41 42 tie.h Co-processors and custom extensions defined 43 in the Tensilica Instruction Extension (TIE) 44 language. 45 tie-asm.h Assembly macros to access custom-defined registers 46 and states. 47 48 49 Global Data Pointer, Exported Function Stubs, and the ABI 50 --------------------------------------------------------- 51 52 To support standalone applications launched with the "go" command, 53 U-Boot provides a jump table of entrypoints to exported functions 54 (grep for EXPORT_FUNC). The implementation for Xtensa depends on 55 which ABI (or function calling convention) is used. 56 57 Windowed ABI presents unique difficulties with the approach based on 58 keeping global data pointer in dedicated register. Because the register 59 window rotates during a call, there is no register that is constantly 60 available for the gd pointer. Therefore, on xtensa gd is a simple 61 global variable. Another difficulty arises from the requirement to have 62 an 'entry' at the beginning of a function, which rotates the register 63 file and reserves a stack frame. This is an integral part of the 64 windowed ABI implemented in hardware. It makes using a jump table to an 65 arbitrary (separately compiled) function a bit tricky. Use of a simple 66 wrapper is also very tedious due to the need to move all possible 67 register arguments and adjust the stack to handle arguments that cannot 68 be passed in registers. The most efficient approach is to have the jump 69 table perform the 'entry' so as to pretend it's the start of the real 70 function. This requires decoding the target function's 'entry' 71 instruction to determine the stack frame size, and adjusting the stack 72 pointer accordingly, then jumping into the target function just after 73 the 'entry'. Decoding depends on the processor's endianness so uses the 74 HAL. The implementation (12 instructions) is in examples/stubs.c. 75 76 77 Access to Invalid Memory Addresses 78 ---------------------------------- 79 80 U-Boot does not check if memory addresses given as arguments to commands 81 such as "md" are valid. There are two possible types of invalid 82 addresses: an area of physical address space may not be mapped to RAM 83 or peripherals, or in the presence of MMU an area of virtual address 84 space may not be mapped to physical addresses. 85 86 Accessing first type of invalid addresses may result in hardware lockup, 87 reading of meaningless data, written data being ignored or an exception, 88 depending on the CPU wiring to the system. Accessing second type of 89 invalid addresses always ends with an exception. 90 91 U-Boot for Xtensa provides a special memory exception handler that 92 reports such access attempts and resets the board. 93 94 95 ------------------------------------------------------------------------------ 96 Chris Zankel 97 Ross Morley 98
README.zfs
1 This patch series adds support for ZFS listing and load to u-boot. 2 3 To Enable zfs ls and load commands, modify the board specific config file with 4 #define CONFIG_CMD_ZFS 5 6 Steps to test: 7 8 1. After applying the patch, zfs specific commands can be seen 9 in the boot loader prompt using 10 UBOOT #help 11 12 zfsload- load binary file from a ZFS file system 13 zfsls - list files in a directory (default /) 14 15 2. To list the files in zfs pool, device or partition, execute 16 zfsls <interface> <dev[:part]> [POOL/@/dir/file] 17 For example: 18 UBOOT #zfsls mmc 0:5 /rpool/@/usr/bin/ 19 20 3. To read and load a file from an ZFS formatted partition to RAM, execute 21 zfsload <interface> <dev[:part]> [addr] [filename] [bytes] 22 For example: 23 UBOOT #zfsload mmc 2:2 0x30007fc0 /rpool/@/boot/uImage 24 25 References : 26 -- ZFS GRUB sources from Solaris GRUB-0.97 27 -- GRUB Bazaar repository 28 29 Jorgen Lundman <lundman at lundman.net> 2012. 30
README.zynq
1 # SPDX-License-Identifier: GPL-2.0+ 2 # 3 # Xilinx ZYNQ U-Boot 4 # 5 # (C) Copyright 2013 Xilinx, Inc. 6 7 1. About this 8 9 This document describes the information about Xilinx Zynq U-Boot - 10 like supported boards, ML status and TODO list. 11 12 2. Zynq boards 13 14 Xilinx Zynq-7000 All Programmable SoCs enable extensive system level 15 differentiation, integration, and flexibility through hardware, software, 16 and I/O programmability. 17 18 * zc702 (single qspi, gem0, mmc) [1] 19 * zc706 (dual parallel qspi, gem0, mmc) [2] 20 * zed (single qspi, gem0, mmc) [3] 21 * microzed (single qspi, gem0, mmc) [4] 22 * zc770 23 - zc770-xm010 (single qspi, gem0, mmc) 24 - zc770-xm011 (8 or 16 bit nand) 25 - zc770-xm012 (nor) 26 - zc770-xm013 (dual parallel qspi, gem1) 27 28 3. Building 29 30 ex. configure and build for zc702 board 31 $ make zynq_zc702_config 32 $ make 33 34 4. Bootmode 35 36 Zynq has a facility to read the bootmode from the slcr bootmode register 37 once user is setting through jumpers on the board - see page no:1546 on [5] 38 39 All possible bootmode values are defined in Table 6-2:Boot_Mode MIO Pins 40 on [5]. 41 42 board_late_init() will read the bootmode values using slcr bootmode register 43 at runtime and assign the modeboot variable to specific bootmode string which 44 is intern used in autoboot. 45 46 SLCR bootmode register Bit[3:0] values 47 #define ZYNQ_BM_NOR 0x02 48 #define ZYNQ_BM_SD 0x05 49 #define ZYNQ_BM_JTAG 0x0 50 51 "modeboot" variable can assign any of "norboot", "sdboot" or "jtagboot" 52 bootmode strings at runtime. 53 54 5. Mainline status 55 56 - Added basic board configurations support. 57 - Added zynq u-boot bsp code - arch/arm/cpu/armv7/zynq 58 - Added zynq boards named - zc70x, zed, microzed, zc770_xm010/xm011/xm012/xm013 59 - Added zynq drivers: 60 serial - drivers/serial/serial_zynq.c 61 net - drivers/net/zynq_gem.c 62 mmc - drivers/mmc/zynq_sdhci.c 63 spi - drivers/spi/zynq_spi.c 64 qspi - drivers/spi/zynq_qspi.c 65 i2c - drivers/i2c/zynq_i2c.c 66 nand - drivers/mtd/nand/zynq_nand.c 67 - Done proper cleanups on board configurations 68 - Added basic FDT support for zynq boards 69 - d-cache support for zynq_gem.c 70 71 6. TODO 72 73 - Add FDT support on individual drivers 74 75 [1] http://www.xilinx.com/products/boards-and-kits/EK-Z7-ZC702-G.htm 76 [2] http://www.xilinx.com/products/boards-and-kits/EK-Z7-ZC706-G.htm 77 [3] http://zedboard.org/product/zedboard 78 [4] http://zedboard.org/product/microzed 79 [5] http://www.xilinx.com/support/documentation/user_guides/ug585-Zynq-7000-TRM.pdf 80 81 -- 82 Jagannadha Sutradharudu Teki <jaganna (a] xilinx.com> 83 Sun Dec 15 14:52:41 IST 2013 84
