[U-Boot] [PATCH v3 19/19] sunxi: update Pine64 README

["André Przywara" <andre.przywara@arm.com>]

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 <afaerber@suse.de>
> 
> 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
>