| Up to higher level directory | |||
| Name | Date | Size | |
|---|---|---|---|
| ahci.c | 22-Oct-2020 | 2.9K | |
| board.c | 22-Oct-2020 | 22.7K | |
| dram_sun4i_auto.c | 22-Oct-2020 | 673 | |
| dram_sun5i_auto.c | 22-Oct-2020 | 783 | |
| dram_timings_sun4i.h | 22-Oct-2020 | 5.2K | |
| gmac.c | 22-Oct-2020 | 2.7K | |
| MAINTAINERS | 22-Oct-2020 | 10.4K | |
| Makefile | 22-Oct-2020 | 483 | |
| mksunxi_fit_atf.sh | 22-Oct-2020 | 1.5K | |
| README.nand | 22-Oct-2020 | 2K | |
| README.sunxi64 | 22-Oct-2020 | 8.1K | |
README.nand
1 Allwinner NAND flashing 2 ======================= 3 4 A lot of Allwinner devices, especially the older ones (pre-H3 era), 5 comes with a NAND. NANDs storages are a pretty weak choice when it 6 comes to the reliability, and it comes with a number of flaws like 7 read and write disturbs, data retention issues, bloks becoming 8 unusable, etc. 9 10 In order to mitigate that, various strategies have been found to be 11 able to recover from those issues like ECC, hardware randomization, 12 and of course, redundancy for the critical parts. 13 14 This is obviously something that we will take into account when 15 creating our images. However, the BROM will use a quite weird pattern 16 when accessing the NAND, and will access only at most 4kB per page, 17 which means that we also have to split that binary accross several 18 pages. 19 20 In order to accomodate that, we create a tool that will generate an 21 SPL image that is ready to be programmed directly embedding the ECCs, 22 randomized, and with the necessary bits needed to reduce the number of 23 bitflips. The U-Boot build system, when configured for the NAND will 24 also generate the image sunxi-spl-with-ecc.bin that will have been 25 generated by that tool. 26 27 In order to flash your U-Boot image onto a board, assuming that the 28 board is in FEL mode, you'll need the sunxi-tools that you can find at 29 this repository: https://github.com/linux-sunxi/sunxi-tools 30 31 Then, you'll need to first load an SPL to initialise the RAM: 32 sunxi-fel spl spl/sunxi-spl.bin 33 34 Load the binaries we'll flash into RAM: 35 sunxi-fel write 0x4a000000 u-boot-dtb.bin 36 sunxi-fel write 0x43000000 spl/sunxi-spl-with-ecc.bin 37 38 And execute U-Boot 39 sunxi-fel exe 0x4a000000 40 41 On your board, you'll now have all the needed binaries into RAM, so 42 you only need to erase the NAND... 43 44 nand erase.chip 45 46 Then write the SPL and its backup: 47 48 nand write.raw.noverify 0x43000000 0 40 49 nand write.raw.noverify 0x43000000 0x400000 40 50 51 And finally write the U-Boot binary: 52 nand write 0x4a000000 0x800000 0xc0000 53 54 You can now reboot and enjoy your NAND.
README.sunxi64
1 Allwinner 64-bit boards README 2 ============================== 3 4 Newer Allwinner SoCs feature ARMv8 cores (ARM Cortex-A53) with support for 5 both the 64-bit AArch64 mode and the ARMv7 compatible 32-bit AArch32 mode. 6 Examples are the Allwinner A64 (used for instance on the Pine64 board) or 7 the Allwinner H5 SoC (as used on the OrangePi PC 2). 8 These SoCs are wired to start in AArch32 mode on reset and execute 32-bit 9 code from the Boot ROM (BROM). As this has some implications on U-Boot, this 10 file describes how to make full use of the 64-bit capabilities. 11 12 Quick Start / Overview 13 ====================== 14 - Build the ARM Trusted Firmware binary (see "ARM Trusted Firmware (ATF)" below) 15 - Build U-Boot (see "SPL/U-Boot" below) 16 - Transfer to an uSD card (see "microSD card" below) 17 - Boot and enjoy! 18 19 Building the firmware 20 ===================== 21 22 The Allwinner A64/H5 firmware consists of three parts: U-Boot's SPL, an 23 ARM Trusted Firmware (ATF) build and the U-Boot proper. 24 The SPL will load both ATF and U-Boot proper along with the right device 25 tree blob (.dtb) and will pass execution to ATF (in EL3), which in turn will 26 drop into the U-Boot proper (in EL2). 27 As the ATF binary will become part of the U-Boot image file, you will need 28 to build it first. 29 30 ARM Trusted Firmware (ATF) 31 ---------------------------- 32 Checkout the "allwinner" branch from the github repository [1] and build it: 33 $ export CROSS_COMPILE=aarch64-linux-gnu- 34 $ make PLAT=sun50iw1p1 DEBUG=1 bl31 35 The resulting binary is build/sun50iw1p1/debug/bl31.bin. Either put the 36 location of this file into the BL31 environment variable or copy this to 37 the root of your U-Boot build directory (or create a symbolic link). 38 $ export BL31=/src/arm-trusted-firmware/build/sun50iw1p1/debug/bl31.bin 39 (adjust the actual path accordingly) 40 41 If you run into size issues with the resulting U-Boot image file, it might 42 help to use a release build, by using "DEBUG=0" when building bl31.bin. 43 As sometimes the ATF build process is a bit picky about the toolchain used, 44 or if you can't be bothered with building ATF, there are known working 45 binaries in the firmware repository[3], purely for convenience reasons. 46 47 SPL/U-Boot 48 ------------ 49 Both U-Boot proper and the SPL are using the 64-bit mode. As the boot ROM 50 enters the SPL still in AArch32 secure SVC mode, there is some shim code to 51 enter AArch64 very early. The rest of the SPL runs in AArch64 EL3. 52 U-Boot proper runs in EL2 and can load any AArch64 code (using the "go" 53 command), EFI applications (with "bootefi") or arm64 Linux kernel images 54 (often named "Image"), using the "booti" command. 55 56 $ make clean 57 $ export CROSS_COMPILE=aarch64-linux-gnu- 58 $ make pine64_plus_defconfig 59 $ make 60 61 This will build the SPL in spl/sunxi-spl.bin and a FIT image called u-boot.itb, 62 which contains the rest of the firmware. 63 64 65 Boot process 66 ============ 67 The on-die BROM code will try several methods to load and execute the firmware. 68 On a typical board like the Pine64 this will result in the following boot order: 69 70 1) Reading 32KB from sector 16 (@8K) of the microSD card to SRAM A1. If the 71 BROM finds the magic "eGON" header in the first bytes, it will execute that 72 code. If not (no SD card at all or invalid magic), it will: 73 2) Try to read 32KB from sector 16 (@8K) of memory connected to the MMC2 74 controller, typically an on-board eMMC chip. If there is no eMMC or it does 75 not contain a valid boot header, it will: 76 3) Initialize the SPI0 controller and try to access a NOR flash connected to 77 it (using the CS0 pin). If a flash chip is found, the BROM will load the 78 first 32KB (from offset 0) into SRAM A1. Now it checks for the magic eGON 79 header and checksum and will execute the code upon finding it. If not, it will: 80 4) Initialize the USB OTG controller and will wait for a host to connect to 81 it, speaking the Allwinner proprietary (but deciphered) "FEL" USB protocol. 82 83 84 To boot the Pine64 board, you can use U-Boot and any of the described methods. 85 86 FEL boot (USB OTG) 87 ------------------ 88 FEL is the name of the Allwinner defined USB boot protocol built in the 89 mask ROM of most Allwinner SoCs. It allows to bootstrap a board solely 90 by using the USB-OTG interface and a host port on another computer. 91 As the FEL mode is controlled by the boot ROM, it expects to be running in 92 AArch32. For now the AArch64 SPL cannot properly return into FEL mode, so the 93 feature is disabled in the configuration at the moment. 94 95 microSD card 96 ------------ 97 Transfer the SPL and the U-Boot FIT image directly to an uSD card: 98 # dd if=spl/sunxi-spl.bin of=/dev/sdx bs=8k seek=1 99 # dd if=u-boot.itb of=/dev/sdx bs=8k seek=5 100 # sync 101 (replace /dev/sdx with you SD card device file name, which could be 102 /dev/mmcblk[x] as well). 103 104 Alternatively you can use the SPL and the U-Boot FIT image combined into a 105 single file and transfer that instead: 106 # dd if=u-boot-sunxi-with-spl.bin of=/dev/sdx bs=8k seek=1 107 108 You can partition the microSD card, but leave the first MB unallocated (most 109 partitioning tools will do this anyway). 110 111 NOR flash 112 --------- 113 Some boards (like the SoPine, Pinebook or the OrangePi PC2) come with a 114 soldered SPI NOR flash chip. On other boards like the Pine64 such a chip 115 can be connected to the SPI0/CS0 pins on the PI-2 headers. 116 Create the SPL and FIT image like described above for the SD card. 117 Now connect either an "A to A" USB cable to the upper USB port on the Pine64 118 or get an adaptor and use a regular A-microB cable connected to it. Other 119 boards often have a proper micro-B USB socket connected to the USB OTB port. 120 Remove a microSD card from the slot and power on the board. 121 On your host computer download and build the sunxi-tools package[2], then 122 use "sunxi-fel" to access the board: 123 $ ./sunxi-fel ver -v -p 124 This should give you an output starting with: AWUSBFEX soc=00001689(A64) ... 125 Now use the sunxi-fel tool to write to the NOR flash: 126 $ ./sunxi-fel spiflash-write 0 spl/sunxi-spl.bin 127 $ ./sunxi-fel spiflash-write 32768 u-boot.itb 128 Now boot the board without an SD card inserted and you should see the 129 U-Boot prompt on the serial console. 130 131 (Legacy) boot0 method 132 --------------------- 133 boot0 is Allwiner's secondary program loader and it can be used as some kind 134 of SPL replacement to get U-Boot up and running from an microSD card. 135 For some time using boot0 was the only option to get the Pine64 booted. 136 With working DRAM init code in U-Boot's SPL this is no longer necessary, 137 but this method is described here for the sake of completeness. 138 Please note that this method works only with the boot0 files shipped with 139 A64 based boards, the H5 uses an incompatible layout which is not supported 140 by this method. 141 142 The boot0 binary is a 32 KByte blob and contained in the official Pine64 images 143 distributed by Pine64 or Allwinner. It can be easily extracted from a micro 144 SD card or an image file: 145 # dd if=/dev/sd<x> of=boot0.bin bs=8k skip=1 count=4 146 where /dev/sd<x> is the device name of the uSD card or the name of the image 147 file. Apparently Allwinner allows re-distribution of this proprietary code 148 "as-is". 149 This boot0 blob takes care of DRAM initialisation and loads the remaining 150 firmware parts, then switches the core into AArch64 mode. 151 The original boot0 code looks for U-Boot at a certain place on an uSD card 152 (at 19096 KB), also it expects a header with magic bytes and a checksum. 153 There is a tool called boot0img[3] which takes a boot0.bin image and a compiled 154 U-Boot binary (plus other binaries) and will populate that header accordingly. 155 To make space for the magic header, the pine64_plus_defconfig will make sure 156 there is sufficient space at the beginning of the U-Boot binary. 157 boot0img will also take care of putting the different binaries at the right 158 places on the uSD card and works around unused, but mandatory parts by using 159 trampoline code. See the output of "boot0img -h" for more information. 160 boot0img can also patch boot0 to avoid loading U-Boot from 19MB, instead 161 fetching it from just behind the boot0 binary (-B option). 162 $ ./boot0img -o firmware.img -B boot0.img -u u-boot-dtb.bin -e -s bl31.bin \ 163 -a 0x44008 -d trampoline64:0x44000 164 Then write this image to a microSD card, replacing /dev/sdx with the right 165 device file (see above): 166 $ dd if=firmware.img of=/dev/sdx bs=8k seek=1 167 168 [1] https://github.com/apritzel/arm-trusted-firmware.git 169 [2] git://github.com/linux-sunxi/sunxi-tools.git 170 [3] https://github.com/apritzel/pine64/ 171
