Re: [U-Boot] [PATCH v3 19/19] sunxi: update Pine64 README
On Thu, Apr 20, 2017 at 12:21:41AM +0200, Andreas Färber wrote: > Am 18.04.2017 um 22:38 schrieb André Przywara: > > On 16/04/17 02:20, Andreas Färber wrote: > >> 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. > > Failure was with a Linaro GCC 5.1. > > Working was Linaro GCC 6.3.1. > > I would happily use our latest SUSE GCC 7.0.1 if only U-Boot had a > private libgcc for aarch64... :( With some quick hacking here, we could get away with adding arch/arm/lib/dummy.S, with a comment of why (to have an empty lib.a be generated) and then we could fake out the not-required libgcc. The other way to go here would be to see what platforms really require -lgcc and introduce another flag, CONFIG_USE_COMPILER_LIBGCC and then allow for PLATFORM_LIBGCC to just be empty. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 19/19] sunxi: update Pine64 README
> On 20 Apr 2017, at 00:21, Andreas Färber wrote: > > Am 18.04.2017 um 22:38 schrieb André Przywara: >> On 16/04/17 02:20, Andreas Färber wrote: >>> 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. > > Failure was with a Linaro GCC 5.1. > > Working was Linaro GCC 6.3.1. > > I would happily use our latest SUSE GCC 7.0.1 if only U-Boot had a > private libgcc for aarch64... :( > U-Boot tries to use -lgcc for the hello_world example (which I did not > find a way to suppress other than hacking the Makefile?) and for the > final u-boot.bin. Successfully tested with aarch64-unknown-elf based on GCC 6.1.0 and 6.3.0 Regards, Philipp. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 19/19] sunxi: update Pine64 README
Am 18.04.2017 um 22:38 schrieb André Przywara: > On 16/04/17 02:20, Andreas Färber wrote: >> 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. Failure was with a Linaro GCC 5.1. Working was Linaro GCC 6.3.1. I would happily use our latest SUSE GCC 7.0.1 if only U-Boot had a private libgcc for aarch64... :( U-Boot tries to use -lgcc for the hello_world example (which I did not find a way to suppress other than hacking the Makefile?) and for the final u-boot.bin. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 19/19] sunxi: update Pine64 README
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 > > 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 = 0x > rtc[1] value = 0x > rtc[2] value = 0x > rtc[3] value = 0x > rtc[4] value = 0x > rtc[5] value = 0x > DRAM BOOT DRIVE INFO: V0.6 > the chip id is 0x0001 > the chip id is 0x0001 > the chip id is 0x0001 > the chip
Re: [U-Boot] [PATCH v3 19/19] sunxi: update Pine64 README
Am 01.04.2017 um 00:31 schrieb Andre Przywara: > With the DRAM init code and the SPL's ability to load the ATF binary as > well, we can now officially get rid of the boot0 boot method, which > involed a closed-source proprietary blob to be used. "involved" > Rework the Pine64 README file to document how to build the firmware. > > Signed-off-by: Andre Przywara > --- > board/sunxi/README.pine64 | 177 > ++ > 1 file changed, 115 insertions(+), 62 deletions(-) > > diff --git a/board/sunxi/README.pine64 b/board/sunxi/README.pine64 > index 5553415..41fb58e 100644 > --- a/board/sunxi/README.pine64 > +++ b/board/sunxi/README.pine64 [...] > +Alternative you can concatenate the SPL and the U-Boot FIT image into a > single "Alternatively" > +file and transfer that instead: [snip] Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 19/19] sunxi: update Pine64 README
On 31 March 2017 at 16:31, Andre Przywara wrote: > With the DRAM init code and the SPL's ability to load the ATF binary as > well, we can now officially get rid of the boot0 boot method, which > involed a closed-source proprietary blob to be used. > Rework the Pine64 README file to document how to build the firmware. > > Signed-off-by: Andre Przywara > --- > board/sunxi/README.pine64 | 177 > ++ > 1 file changed, 115 insertions(+), 62 deletions(-) Change log? Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 19/19] sunxi: update Pine64 README
Hi Andre, 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? 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. > + > + 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. For the Orange Pi PC 2, for this series: Tested-by: Andreas Färber 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? 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... HELLO! BOOT0 is starting! boot0 commit : 8 boot0 version : 4.0 set pll start set pll end rtc[0] value = 0x rtc[1] value = 0x rtc[2] value = 0x rtc[3] value = 0x rtc[4] value = 0x rtc[5] value = 0x DRAM BOOT DRIVE INFO: V0.6 the chip id is 0x0001 the chip id is 0x0001 the chip id is 0x0001 the chip id is 0x0001 the chip id is 0x0001 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 0x [mmc]: ***Try SD card 0*** [mmc]: HSSDR52/SDR25 4 bit [mmc]: 5000 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 -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 19/19] sunxi: update Pine64 README
With the DRAM init code and the SPL's ability to load the ATF binary as well, we can now officially get rid of the boot0 boot method, which involed a closed-source proprietary blob to be used. Rework the Pine64 README file to document how to build the firmware. Signed-off-by: Andre Przywara --- board/sunxi/README.pine64 | 177 ++ 1 file changed, 115 insertions(+), 62 deletions(-) diff --git a/board/sunxi/README.pine64 b/board/sunxi/README.pine64 index 5553415..41fb58e 100644 --- a/board/sunxi/README.pine64 +++ b/board/sunxi/README.pine64 @@ -8,75 +8,130 @@ This chip has ARM Cortex A-53 cores and thus can run both in AArch32 in AArch32 mode and executes 32-bit code from the Boot ROM (BROM). This has some implications on U-Boot. -Quick start - -- Get hold of a boot0.img file (see below for more details). -- Get the boot0img tool source from the tools directory in [1] and compile - that on your host. -- Build U-Boot: +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) + +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). + + 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 +arm64 Linux kernel images (often named "Image") using the booti command. + +$ make clean $ export CROSS_COMPILE=aarch64-linux-gnu- $ make pine64_plus_defconfig $ make -- You also need a compiled ARM Trusted Firmware (ATF) binary. Checkout the - "allwinner" branch from the github repository [2] and build it: -$ export CROSS_COMPILE=aarch64-linux-gnu- -$ make PLAT=sun50iw1p1 DEBUG=1 bl31 - The resulting binary is build/sun50iw1p1/debug/bl31.bin. -Now put an empty (or disposable) micro SD card in your card reader and learn -its device file name, replacing /dev/sd below with the result (that could -be /dev/mmcblk as well): +This will build the SPL in spl/sunxi-spl.bin and a FIT image called u-boot.itb, +which contains the rest of the firmware. + -$ ./boot0img --device /dev/sd -e -u u-boot.bin -B boot0.img \ - -d trampoline64:0x44000 -s bl31.bin -a 0x44008 -p 100 -(either copying the respective files to the working directory or specifying -the paths directly) +Boot process + +The on-die BROM code will try several methods to load and execute the firmware. +On the Pine64 this will result in the following boot order: +1) Reading 32KB from sector 16 (@8K) of the microSD card to SRAM A1. If the +BROM finds the magic "eGON" header in the first bytes, it will execute that +code. If not, it will: +2) Initialize the SPI0 controller and try to access a NOR flash connected to +it (using the CS0 pin). If a flash chip is found, the BROM will load the +first 32KB (from offset 0) into SRAM A1. Now it checks for the magic eGON +header and will execute the code upon finding it. If not, it will: +3) Initialize the USB OTG controller and will wait for a host to connect to +it, speaking the Allwinner proprietary (but deciphered) "FEL" USB protocol. + +To boot the Pine64 board, you can use U-Boot and any of the described methods. -This will create a new partition table (with a 100 MB FAT boot partition), -copies boot0.img, ATF and U-Boot to the proper locations on the SD card and -will fill in the magic Allwinner header to be recognized by boot0. -Prefix the above call with "sudo" if you don't have write access to the -uSD card. You can also use "-o output.img" instead of "--device /dev/sd" -to create an image file and "dd" that to the uSD card. -Omitting the "-p" option will skip the partition table. +FEL boot (USB OTG) +-- +FEL is the name of the Allwinner defined USB boot protocol built in the +mask ROM of most Allwinner SoCs. It allows to bootstrap a board solely +by using the USB-OTG interface and a host port on another computer. +As the F
