On 16/04/17 02:20, Andreas Färber wrote: Hi Andreas,
thanks for the review! > Thanks for your awesome work on getting things in shape! > > Am 01.04.2017 um 00:31 schrieb Andre Przywara: >> +Quick Start / Overview >> +====================== >> +- Build the ARM Trusted Firmware binary (see "ARM Trusted firmware (ATF)" >> below) >> +- Build U-Boot (see "SPL/U-Boot" below) >> +- Transfer to an uSD card (see "microSD card" below) >> +- Boot and enjoy! >> + >> +Building the firmware >> +===================== >> + >> +The Allwinner A64 firmware consists of three parts: U-Boot's SPL, an >> +ARM Trusted Firmware (ATF) build and the U-Boot proper. >> +The SPL will load both ATF and U-Boot proper along with the right device >> +tree blob (.dtb) and will pass execution to ATF (in EL3), which in turn will >> +drop into the U-Boot proper (in EL2). >> +As the ATF binary will become part of the U-Boot image file, you will need >> +to build it first. >> + >> + ARM Trusted firmware (ATF) > > "Firmware" > >> +---------------------------- >> +Checkout the "allwinner" branch from the github repository [1] and build it: >> +$ export CROSS_COMPILE=aarch64-linux-gnu- >> +$ make PLAT=sun50iw1p1 DEBUG=1 bl31 >> + The resulting binary is build/sun50iw1p1/debug/bl31.bin. Copy this to the >> + root of the U-Boot source tree (or create a symbolic link). > > This sentence startled me - but luckily it does not need to be in the > _source_ directory, the U-Boot _build_ directory works just fine, too! > Care to revise the statement? Well, these instructions are more for the uninitiated, I guess, so tossing in a "build directory" is probably more confusing. I was silently assuming that people building in a separate build directory can read between the lines here. Let me see if I can find a wording which makes everyone happy ;-) > It would also be nice to be able to just set some BL31 variable with the > full path on the make command line, like ATF allows. Mmmh, that sounds like a good idea. Let me see how this can be integrated. > >> + >> + SPL/U-Boot >> +------------ >> +Both U-Boot proper and the SPL are using the 64-bit mode. As the boot ROM >> +enters the SPL still in AArch32 secure SVC mode, there is some shim code to >> +enter AArch64 very early. The rest of the SPL runs in AArch64 EL3. >> +U-boot proper runs in EL2 and can load any AArch64 code, EFI applications or > > "U-Boot" > >> +arm64 Linux kernel images (often named "Image") using the booti command. > > You may want to clarify this sentence - booti only applies to the > latter, EFI applications would use "bootefi" and arbitrary code "go". > Maybe just drop the "using" part? > >> + >> +$ make clean >> $ export CROSS_COMPILE=aarch64-linux-gnu- >> $ make pine64_plus_defconfig >> $ make > [snip] > > Build-testing this series with both pine64_plus_defconfig and > orangepi_pc2_defconfig, I ran into a ~1616 size overflow with gcc5. gcc6 > worked okay. Would be helpful to document such requirements here. Can you say which version of GCC 5? I think I used GCC 5.3.0 for a while and this was fine, but I need to re-check this. But yes: GCC 4.9 is not up to the task ;-) > > For the Orange Pi PC 2, for this series: > > Tested-by: Andreas Färber <[email protected]> > > Orange Pi PC 2 will benefit from the $fdtfile patch I sent for Pine64, > tested there as well. > > I note there is no README.orangepi_pc2. Should README.pine64 be renamed > to cover both boards, or were you planning to add a separate one? Yeah, I was stumbling upon this as well. One problem is that I think I was pointing people to README.pine64 for quite a while, so renaming this might break links or so. Other problem is to find a decent alternative name. I tend to use "sunxi64" if I talk about 64-bit Allwinner SoCs in general, but I am not sure if that is too technical or not meaning much to people. So I am open to suggestions. > Reason I ask is I tried unsuccessfully the Pine64 boot0.bin approach > (based on your extract_fw_blobs.sh) for orangepi_pc2 before, based on > current master branch, and it did not get me into U-Boot, unlike on the > Pine64, so some documentation somewhere would be good to have, > especially should this simplifying patchset miss the release again... The H5 boot0 changed quite a lot, so the A64 runes don't work anymore. The way the different meta data of the firmware parts (ATF, U-Boot, arisc) are stored is different. I really couldn't be bothered to rev-eng and hack this dead end (again). And since we have the SPL code working already this time, I thought we just go with the proper stuff. Cheers, Andre. > HELLO! BOOT0 is starting! > boot0 commit : 8 > boot0 version : 4.0 > set pll start > set pll end > rtc[0] value = 0x00000000 > rtc[1] value = 0x00000000 > rtc[2] value = 0x00000000 > rtc[3] value = 0x00000000 > rtc[4] value = 0x00000000 > rtc[5] value = 0x00000000 > DRAM BOOT DRIVE INFO: V0.6 > the chip id is 0x00000001 > the chip id is 0x00000001 > the chip id is 0x00000001 > the chip id is 0x00000001 > the chip id is 0x00000001 > axp not exist > DRAM CLK =672 MHZ > DRAM Type =3 (2:DDR2,3:DDR3,6:LPDDR2,7:LPDDR3) > DRAM zq value: 0x003b3bf9 > DRAM SIZE =1024 M > DRAM simple test OK. > dram size =1024 > card no is 0 > sdcard 0 line count 4 > [mmc]: mmc driver ver 2016-03-15 20:40 > [mmc]: sdc0 spd mode error, 2 > [mmc]: Wrong media type 0x00000000 > [mmc]: ***Try SD card 0*** > [mmc]: HSSDR52/SDR25 4 bit > [mmc]: 50000000 Hz > [mmc]: 30436 MB > [mmc]: ***SD/MMC 0 init OK!!!*** > PANIC : sunxi_flash_init() error --2--,toc1 magic error > PANIC : sunxi_flash_init() error --2--,toc1 magic error > PANIC : sunxi_flash_init() error --0-- > Ready to disable icache. > > Possibly related is that the output from boot0img was significantly > larger than for Pine64? (same bl31.bin, other boot0.bin and u-boot.bin) > > $ filesize orangepipc2.img > 20013056 > $ filesize pine64.img > 499712 > > Searching for a how-to I also noticed that linux-sunxi.org still links > to a stale h5 branch from December (and that there is an spl-fit-v2 > branch but none with the latest v3 code ;)). > > Cheers, > Andreas > _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
