Add Pine64 support

Gcc warns when you try to cast a u32 value into a pointer directly. When someone calls functions like readl or writel, he's pretty sure the parameter he passes is an address though, so we can as well cast it for him.

This makes porting 32bit code to armv8 easier, as it means we don't have to touch common board code with explicit casts or UL redefines.

Signed-off-by Alexander Graf <[email protected]>

---
  arch/arm/include/asm/io.h | 18 +++++++++---------
  1 file changed, 9 insertions(+), 9 deletions(-)

arch/arm/include/asm/io.h +9 -9

index 75773bd..b85f4d7 100644
@@ -67,15 +67,15 @@ static inline phys_addr_t virt_to_phys(void * vaddr)
   * read/writes.  We define __arch_*[bl] here, and leave __arch_*w
   * to the architecture specific code.
   */
-#define __arch_getb(a)			(*(volatile unsigned char *)(a))
-#define __arch_getw(a)			(*(volatile unsigned short *)(a))
-#define __arch_getl(a)			(*(volatile unsigned int *)(a))
-#define __arch_getq(a)			(*(volatile unsigned long long *)(a))
-
-#define __arch_putb(v,a)		(*(volatile unsigned char *)(a) = (v))
-#define __arch_putw(v,a)		(*(volatile unsigned short *)(a) = (v))
-#define __arch_putl(v,a)		(*(volatile unsigned int *)(a) = (v))
-#define __arch_putq(v,a)		(*(volatile unsigned long long *)(a) = (v))
+#define __arch_getb(a)			(*(volatile unsigned char *)(long)(a))
+#define __arch_getw(a)			(*(volatile unsigned short *)(long)(a))
+#define __arch_getl(a)			(*(volatile unsigned int *)(long)(a))
+#define __arch_getq(a)			(*(volatile unsigned long long *)(long)(a))
+
+#define __arch_putb(v,a)		(*(volatile unsigned char *)(long)(a) = (v))
+#define __arch_putw(v,a)		(*(volatile unsigned short *)(long)(a) = (v))
+#define __arch_putl(v,a)		(*(volatile unsigned int *)(long)(a) = (v))
+#define __arch_putq(v,a)		(*(volatile unsigned long long *)(long)(a) = (v))
 
  static inline void __raw_writesb(unsigned long addr, const void *data,
  				 int bytelen)

The Pine64 is a kickstarter backed SBC that runs on the Allwinner A64 SoC. This SoC can run AArch64 code, so this patch set lifts all arm version indepenent sunxi code into a mach directory and builds the A64 code as armv8 (aarch64) code.

With these patches applied, I can successfully boot my 1GB Pine64+ board with an openSUSE EFI image.

Alex

Alexander Graf (4):
sunxi: Move cpu independent code to mach directory
sunxi: Depend SPL configs on SUPPORT_SPL
arm: Allow u32 as addrs for readX/writeX
sunxi: Explicitly cast u32 pointer conversions

Siarhei Siamashka (2):
sunxi: Add support for Allwinner A64 SoCs
sunxi: Add Pine64+ support

  arch/arm/Kconfig                                   |   4 +-
  arch/arm/Makefile                                  |   1 +
  arch/arm/cpu/armv7/sunxi/Makefile                  |  40 +-
  arch/arm/dts/Makefile                              |   2 +
  arch/arm/dts/a64.dtsi                              | 564 +++++++++++++++++++++
  arch/arm/dts/pine64.dts                            |  62 +++
  arch/arm/dts/pine64_common.dtsi                    |  76 +++
  arch/arm/dts/pine64_plus.dts                       |  63 +++
  arch/arm/include/asm/arch-sunxi/clock.h            |   3 +-
  arch/arm/include/asm/arch-sunxi/clock_sun6i.h      |   4 +-
  arch/arm/include/asm/arch-sunxi/gpio.h             |   1 +
  arch/arm/include/asm/arch-sunxi/spl.h              |   5 +-
  arch/arm/include/asm/io.h                          |  18 +-
  arch/arm/include/asm/system.h                      |   6 +
  arch/arm/mach-sunxi/Makefile                       |  51 ++
  arch/arm/{cpu/armv7/sunxi => mach-sunxi}/board.c   |  30 +-
  arch/arm/{cpu/armv7/sunxi => mach-sunxi}/clock.c   |   0
  .../{cpu/armv7/sunxi => mach-sunxi}/clock_sun4i.c  |   0
  .../{cpu/armv7/sunxi => mach-sunxi}/clock_sun6i.c  |   0
  .../armv7/sunxi => mach-sunxi}/clock_sun8i_a83t.c  |   0
  .../{cpu/armv7/sunxi => mach-sunxi}/clock_sun9i.c  |   0
  .../arm/{cpu/armv7/sunxi => mach-sunxi}/cpu_info.c |   2 +
  .../{cpu/armv7/sunxi => mach-sunxi}/dram_helpers.c |   0
  .../{cpu/armv7/sunxi => mach-sunxi}/dram_sun4i.c   |   0
  .../{cpu/armv7/sunxi => mach-sunxi}/dram_sun6i.c   |   0
  .../armv7/sunxi => mach-sunxi}/dram_sun8i_a23.c    |   0
  .../armv7/sunxi => mach-sunxi}/dram_sun8i_a33.c    |   0
  .../armv7/sunxi => mach-sunxi}/dram_sun8i_a83t.c   |   0
  .../armv7/sunxi => mach-sunxi}/dram_sun8i_h3.c     |   0
  arch/arm/{cpu/armv7/sunxi => mach-sunxi}/p2wi.c    |   0
  arch/arm/{cpu/armv7/sunxi => mach-sunxi}/pinmux.c  |   0
  .../arm/{cpu/armv7/sunxi => mach-sunxi}/pmic_bus.c |   0
  arch/arm/{cpu/armv7/sunxi => mach-sunxi}/prcm.c    |   0
  arch/arm/{cpu/armv7/sunxi => mach-sunxi}/rsb.c     |   0
  arch/arm/{cpu/armv7/sunxi => mach-sunxi}/usb_phy.c |   2 +-
  board/sunxi/Kconfig                                |   9 +-
  board/sunxi/board.c                                |  38 +-
  configs/pine64_plus_defconfig                      |  12 +
  drivers/mmc/sunxi_mmc.c                            |   6 +-
  drivers/power/Kconfig                              |   2 +-
  include/configs/sun50i.h                           |  22 +
  include/configs/sunxi-common.h                     |  20 +-
  42 files changed, 977 insertions(+), 66 deletions(-)

create mode 100644 arch/arm/dts/a64.dtsi
create mode 100644 arch/arm/dts/pine64.dts
create mode 100644 arch/arm/dts/pine64_common.dtsi
create mode 100644 arch/arm/dts/pine64_plus.dts
create mode 100644 arch/arm/mach-sunxi/Makefile
rename arch/arm/{cpu/armv7/sunxi => mach-sunxi}/board.c (91%) rename arch/arm/{cpu/armv7/sunxi => mach-sunxi}/clock.c (100%) rename arch/arm/{cpu/armv7/sunxi => mach-sunxi}/clock_sun4i.c (100%) rename arch/arm/{cpu/armv7/sunxi => mach-sunxi}/clock_sun6i.c (100%) rename arch/arm/{cpu/armv7/sunxi => mach-sunxi}/clock_sun8i_a83t.c (100%) rename arch/arm/{cpu/armv7/sunxi => mach-sunxi}/clock_sun9i.c (100%) rename arch/arm/{cpu/armv7/sunxi => mach-sunxi}/cpu_info.c (97%) rename arch/arm/{cpu/armv7/sunxi => mach-sunxi}/dram_helpers.c (100%) rename arch/arm/{cpu/armv7/sunxi => mach-sunxi}/dram_sun4i.c (100%) rename arch/arm/{cpu/armv7/sunxi => mach-sunxi}/dram_sun6i.c (100%) rename arch/arm/{cpu/armv7/sunxi => mach-sunxi}/dram_sun8i_a23.c (100%) rename arch/arm/{cpu/armv7/sunxi => mach-sunxi}/dram_sun8i_a33.c (100%) rename arch/arm/{cpu/armv7/sunxi => mach-sunxi}/dram_sun8i_a83t.c (100%) rename arch/arm/{cpu/armv7/sunxi => mach-sunxi}/dram_sun8i_h3.c (100%) rename arch/arm/{cpu/armv7/sunxi => mach-sunxi}/p2wi.c (100%) rename arch/arm/{cpu/armv7/sunxi => mach-sunxi}/pinmux.c (100%) rename arch/arm/{cpu/armv7/sunxi => mach-sunxi}/pmic_bus.c (100%) rename arch/arm/{cpu/armv7/sunxi => mach-sunxi}/prcm.c (100%) rename arch/arm/{cpu/armv7/sunxi => mach-sunxi}/rsb.c (100%) rename arch/arm/{cpu/armv7/sunxi => mach-sunxi}/usb_phy.c (99%) create mode 100644 configs/pine64_plus_defconfig
create mode 100644 include/configs/sun50i.h

Hi,

Quoted 6 lines · Alexander Graf

The Pine64 is a kickstarter backed SBC that runs on the Allwinner A64 SoC.
This SoC can run AArch64 code, so this patch set lifts all arm version indepenent sunxi code into a mach directory and builds the A64 code as armv8 (aarch64) code.

Quoted 2 lines

With these patches applied, I can successfully boot my 1GB Pine64+ board with an openSUSE EFI image.

Can you provide some quick instructions on how to test this ? Bonus point for a link to a boot0.bin which I can dd to a sdcard and use with a u-boot.bin build with these patches.

Quoted 9 lines · Hans de Goede

Hi,

Quoted 6 lines · Alexander Graf

The Pine64 is a kickstarter backed SBC that runs on the Allwinner A64 SoC.
This SoC can run AArch64 code, so this patch set lifts all arm version indepenent sunxi code into a mach directory and builds the A64 code as armv8 (aarch64) code.

Quoted 6 lines

Quoted 2 lines

With these patches applied, I can successfully boot my 1GB Pine64+ board with an openSUSE EFI image.

Can you provide some quick instructions on how to test this ? Bonus point for a link to a boot0.bin which I can dd to a sdcard and use with a u-boot.bin build with these patches.

Sure. Grab these all the files in this directory:

   http://csgraf.de/agraf/pine64

Then do

   $ gcc pine64_image.c -o pine64_image
   $ cat bl31.bin <u-boot-dir>/u-boot.bin > bl31uboot.bin
   $ ./pine64_image scp.bin bl31uboot.bin u-boot.img
   $ dd if=boot0.bin of=/dev/mmcblk0 seek=16
   $ dd if=u-boot.img of=/dev/mmcblk0 seek=80

That should give you a working system. The scp.bin and boot0.bin are from the Allwinner binary distribution. ATF (bl31.bin) is built from these sources:

https://build.opensuse.org/package/show/devel:ARM:Factory:Contrib:Pine64/firmware-pine64

Quoted 9 lines · Hans de Goede

Hi,

Quoted 6 lines · Alexander Graf

The Pine64 is a kickstarter backed SBC that runs on the Allwinner A64 SoC.
This SoC can run AArch64 code, so this patch set lifts all arm version indepenent sunxi code into a mach directory and builds the A64 code as armv8 (aarch64) code.

Quoted 6 lines

Quoted 2 lines

With these patches applied, I can successfully boot my 1GB Pine64+ board with an openSUSE EFI image.

Can you provide some quick instructions on how to test this ? Bonus point for a link to a boot0.bin which I can dd to a sdcard and use with a u-boot.bin build with these patches.

Sure. Grab these all the files in this directory:

   http://csgraf.de/agraf/pine64

Then do

   $ gcc pine64_image.c -o pine64_image
   $ cat bl31.bin <u-boot-dir>/u-boot.bin > bl31uboot.bin
   $ ./pine64_image scp.bin bl31uboot.bin u-boot.img
   $ dd if=boot0.bin of=/dev/mmcblk0 seek=16
   $ dd if=u-boot.img of=/dev/mmcblk0 seek=80

That should give you a working system. The scp.bin and boot0.bin are from the Allwinner binary distribution. ATF (bl31.bin) is built from these sources:

https://build.opensuse.org/package/show/devel:ARM:Factory:Contrib:Pine64/firmware-pine64

Enjoy,

Am 31.03.2016 um 20:53 schrieb Hans de Goede <[email protected]>:

Hi,

Quoted 37 lines · Alexander Graf

Quoted 12 lines · Hans de Goede

Hi,

Quoted 7 lines · Alexander Graf

The Pine64 is a kickstarter backed SBC that runs on the Allwinner A64 SoC.
This SoC can run AArch64 code, so this patch set lifts all arm version indepenent sunxi code into a mach directory and builds the A64 code as armv8 (aarch64) code.

Quoted 6 lines

Quoted 2 lines

With these patches applied, I can successfully boot my 1GB Pine64+ board with an openSUSE EFI image.

Can you provide some quick instructions on how to test this ? Bonus point for a link to a boot0.bin which I can dd to a sdcard and use with a u-boot.bin build with these patches.

Sure. Grab these all the files in this directory:

http://csgraf.de/agraf/pine64

Then do

  $ gcc pine64_image.c -o pine64_image
  $ cat bl31.bin <u-boot-dir>/u-boot.bin > bl31uboot.bin
  $ ./pine64_image scp.bin bl31uboot.bin u-boot.img
  $ dd if=boot0.bin of=/dev/mmcblk0 seek=16
  $ dd if=u-boot.img of=/dev/mmcblk0 seek=80

That should give you a working system. The scp.bin and boot0.bin are from the Allwinner binary distribution. ATF (bl31.bin) is built from these sources:

Quoted 4 lines

https://build.opensuse.org/package/show/devel:ARM:Factory:Contrib:Pine64/firmware-pine64

Enjoy,

Thanks, works like a charm.

I've applied the entire series to my tree, except for "[PATCH 3/6] arm: Allow u32 as addrs for readX/writeX" instead I've added 2 extra casts to your
"[PATCH 4/6] sunxi: Explicitly cast u32 pointer conversions" patch, which is enough to build warning free for me.

I still have some other patches to process, I'll send a pull-req tomorrow morning.

Note I've squashed the following fixes into "[PATCH 5/6] sunxi: Add support for Allwinner A64 SoCs" :

arch/arm/include/asm/arch-sunxi/clock_sun6i.h +3 -3

@@ -352,10 +352,10 @@ struct sunxi_ccm_reg {
 
 #if defined(CONFIG_MACH_SUN50I)
 #define MBUS_CLK_DEFAULT               0x81000002 /* PLL6x2 / 3 */
-#elif !defined(CONFIG_MACH_SUN8I)
-#define MBUS_CLK_DEFAULT           0x81000001 /* PLL6 / 2 */
-#else
+#elif defined(CONFIG_MACH_SUN8I)
 #define MBUS_CLK_DEFAULT               0x81000003 /* PLL6 / 4 */
+#else
+#define MBUS_CLK_DEFAULT             0x81000001 /* PLL6 / 2 */
 #endif
 #define MBUS_CLK_GATE                  (0x1 << 31)
 

arch/arm/include/asm/system.h +0 -0

 void __asm_flush_dcache_all(void);
 void __asm_invalidate_dcache_all(void);
 void __asm_flush_dcache_range(u64 start, u64 end);

board/sunxi/board.c +1 -4

@@ -76,10 +76,7 @@ DECLARE_GLOBAL_DATA_PTR;
 /* add board specific code here */
 int board_init(void)
 {
-#ifndef CONFIG_ARM64
-       int id_pfr1;
-#endif
-       int ret;
+       __maybe_unused int id_pfr1, ret;
 
       gd->bd->bi_boot_params = (PHYS_SDRAM_0 + 0x100);
 

Regards,

Hans

Quoted 50 lines

Am 31.03.2016 um 20:53 schrieb Hans de Goede <[email protected]>:

Hi,

Quoted 37 lines · Alexander Graf

Quoted 12 lines · Hans de Goede

Hi,

Quoted 7 lines · Alexander Graf

The Pine64 is a kickstarter backed SBC that runs on the Allwinner A64 SoC.
This SoC can run AArch64 code, so this patch set lifts all arm version indepenent sunxi code into a mach directory and builds the A64 code as armv8 (aarch64) code.

Quoted 6 lines

Quoted 2 lines

With these patches applied, I can successfully boot my 1GB Pine64+ board with an openSUSE EFI image.

Can you provide some quick instructions on how to test this ? Bonus point for a link to a boot0.bin which I can dd to a sdcard and use with a u-boot.bin build with these patches.

Sure. Grab these all the files in this directory:

   http://csgraf.de/agraf/pine64

Then do

   $ gcc pine64_image.c -o pine64_image
   $ cat bl31.bin <u-boot-dir>/u-boot.bin > bl31uboot.bin
   $ ./pine64_image scp.bin bl31uboot.bin u-boot.img
   $ dd if=boot0.bin of=/dev/mmcblk0 seek=16
   $ dd if=u-boot.img of=/dev/mmcblk0 seek=80

That should give you a working system. The scp.bin and boot0.bin are from the Allwinner binary distribution. ATF (bl31.bin) is built from these sources:

Quoted 4 lines

https://build.opensuse.org/package/show/devel:ARM:Factory:Contrib:Pine64/firmware-pine64

Enjoy,

Thanks, works like a charm.

Quoted 8 lines

I've applied the entire series to my tree, except for "[PATCH 3/6] arm: Allow u32 as addrs for readX/writeX" instead I've added 2 extra casts to your
"[PATCH 4/6] sunxi: Explicitly cast u32 pointer conversions" patch, which is enough to build warning free for me.

I still have some other patches to process, I'll send a pull-req tomorrow morning.

Thanks :)

Quoted 27 lines

Note I've squashed the following fixes into "[PATCH 5/6] sunxi: Add support for Allwinner A64 SoCs" :

arch/arm/include/asm/arch-sunxi/clock_sun6i.h +3 -3

@@ -352,10 +352,10 @@ struct sunxi_ccm_reg {
 
 #if defined(CONFIG_MACH_SUN50I)
 #define MBUS_CLK_DEFAULT               0x81000002 /* PLL6x2 / 3 */
-#elif !defined(CONFIG_MACH_SUN8I)
-#define MBUS_CLK_DEFAULT           0x81000001 /* PLL6 / 2 */
-#else
+#elif defined(CONFIG_MACH_SUN8I)
 #define MBUS_CLK_DEFAULT               0x81000003 /* PLL6 / 4 */
+#else
+#define MBUS_CLK_DEFAULT             0x81000001 /* PLL6 / 2 */
 #endif
 #define MBUS_CLK_GATE                  (0x1 << 31)
 

arch/arm/include/asm/system.h +0 -0

@@ -92,12 +92,6 @@ static inline unsigned long read_mpidr(void)
 
 #define BSP_COREID     0
 

arch/arm/include/asm/system.h static inline unsigned long read_mpidr(void) · line 100

Quoted 6 lines

arch/arm/include/asm/system.h +0 -6

-static inline void sdelay(unsigned long n)
-{
-       int i;
-       for (i = 0; i < n; i++) asm volatile("");
-}
-

How did you manage to build without sdelay? The sun6i clock code used it, no? Or is something there guarded with CONFIG_SPL_BUILD?

Hi,

Quoted 88 lines · Alexander Graf

Quoted 50 lines

Am 31.03.2016 um 20:53 schrieb Hans de Goede <[email protected]>:

Hi,

Quoted 37 lines · Alexander Graf

Quoted 12 lines · Hans de Goede

Hi,

Quoted 7 lines · Alexander Graf

The Pine64 is a kickstarter backed SBC that runs on the Allwinner A64 SoC.
This SoC can run AArch64 code, so this patch set lifts all arm version indepenent sunxi code into a mach directory and builds the A64 code as armv8 (aarch64) code.

Quoted 6 lines

Quoted 2 lines

With these patches applied, I can successfully boot my 1GB Pine64+ board with an openSUSE EFI image.

Can you provide some quick instructions on how to test this ? Bonus point for a link to a boot0.bin which I can dd to a sdcard and use with a u-boot.bin build with these patches.

Sure. Grab these all the files in this directory:

   http://csgraf.de/agraf/pine64

Then do

   $ gcc pine64_image.c -o pine64_image
   $ cat bl31.bin <u-boot-dir>/u-boot.bin > bl31uboot.bin
   $ ./pine64_image scp.bin bl31uboot.bin u-boot.img
   $ dd if=boot0.bin of=/dev/mmcblk0 seek=16
   $ dd if=u-boot.img of=/dev/mmcblk0 seek=80

That should give you a working system. The scp.bin and boot0.bin are from the Allwinner binary distribution. ATF (bl31.bin) is built from these sources:

Quoted 4 lines

https://build.opensuse.org/package/show/devel:ARM:Factory:Contrib:Pine64/firmware-pine64

Enjoy,

Thanks, works like a charm.

Quoted 8 lines

I've applied the entire series to my tree, except for "[PATCH 3/6] arm: Allow u32 as addrs for readX/writeX" instead I've added 2 extra casts to your
"[PATCH 4/6] sunxi: Explicitly cast u32 pointer conversions" patch, which is enough to build warning free for me.

I still have some other patches to process, I'll send a pull-req tomorrow morning.

Thanks :)

Quoted 27 lines

Note I've squashed the following fixes into "[PATCH 5/6] sunxi: Add support for Allwinner A64 SoCs" :

arch/arm/include/asm/arch-sunxi/clock_sun6i.h +3 -3

@@ -352,10 +352,10 @@ struct sunxi_ccm_reg {
 
 #if defined(CONFIG_MACH_SUN50I)
 #define MBUS_CLK_DEFAULT               0x81000002 /* PLL6x2 / 3 */
-#elif !defined(CONFIG_MACH_SUN8I)
-#define MBUS_CLK_DEFAULT           0x81000001 /* PLL6 / 2 */
-#else
+#elif defined(CONFIG_MACH_SUN8I)
 #define MBUS_CLK_DEFAULT               0x81000003 /* PLL6 / 4 */
+#else
+#define MBUS_CLK_DEFAULT             0x81000001 /* PLL6 / 2 */
 #endif
 #define MBUS_CLK_GATE                  (0x1 << 31)
 

arch/arm/include/asm/system.h +0 -0

@@ -92,12 +92,6 @@ static inline unsigned long read_mpidr(void)
 
 #define BSP_COREID     0
 

Quoted 8 lines

arch/arm/include/asm/system.h static inline unsigned long read_mpidr(void) · line 100

Quoted 6 lines

arch/arm/include/asm/system.h +0 -6

-static inline void sdelay(unsigned long n)
-{
-       int i;
-       for (i = 0; i < n; i++) asm volatile("");
-}
-

How did you manage to build without sdelay? The sun6i clock code used it, no? Or is something there guarded with CONFIG_SPL_BUILD?

The code in question is #ifdef CONFIG_SPL_BUILD I guess we will need to fix this somehow when we get SPL support, I'm pretty sure the above is not the right solution.

On the A64 we usually boot with ATF running in EL3. ATF as it is available today resides in the first 16MB of RAM. So we should make sure we reserve that space in our memory maps.

Quoted 3 lines · Alexander Graf

On the A64 we usually boot with ATF running in EL3. ATF as it is available today resides in the first 16MB of RAM. So we should make sure we reserve that space in our memory maps.

Would using fdt_add_mem_rsv() be better than fiddling with the DRAM banks?

Quoted 8 lines · Ian Campbell

Quoted 4 lines · Alexander Graf

On the A64 we usually boot with ATF running in EL3. ATF as it is available today resides in the first 16MB of RAM. So we should make sure we reserve that space in our memory maps.

Would using fdt_add_mem_rsv() be better than fiddling with the DRAM banks?

Nope, because that wouldn't populate into the EFI memory descriptors ;).

Quoted 5 lines · Alexander Graf

Quoted 3 lines · Ian Campbell

Quoted 1 line · Alexander Graf

Quoted 6 lines

Quoted 5 lines

Quoted 3 lines

On the A64 we usually boot with ATF running in EL3. ATF as it is available today resides in the first 16MB of RAM. So we should make sure we reserve that space in our memory maps.

Would using fdt_add_mem_rsv() be better than fiddling with the DRAM banks?

Nope, because that wouldn't populate into the EFI memory descriptors ;).

Isn't that a bug? ;-)

On the A64 we usually boot with ATF running in EL3. ATF as it is available today resides in the first 16MB of RAM.

So we should make sure we reserve
that space in our memory maps.

Signed-off-by Alexander Graf <[email protected]>

---
 board/sunxi/board.c | 9 +++++++++
 1 file changed, 9 insertions(+)

board/sunxi/board.c +2 -0

index 74510c5..331cb0a 100644
@@ -136,6 +136,15 @@ int dram_init(void)
      return 0;
 }
 
+#ifdef CONFIG_MACH_SUN50I
+void dram_init_banksize(void)

Hi,

sorry for the late reply, just found your series here.

Quoted 2 lines · Alexander Graf

On the A64 we usually boot with ATF running in EL3. ATF as it is available today resides in the first 16MB of RAM.

So this is actually a mistake Allwinner made and which we haven't fixed yet. ATF (at least BL3-1, which is the runtime service part we use for the A64) should at least run in secure memory, actually in secure SRAM. Having it in DRAM is a kludge, unnecessary (it's small enough to reside in some SRAM), a waste of memory (it should get along with something like 32KB) and also insecure, as long as we don't use the TrustZone controller to mark this part of DRAM as secure.

Quoted 2 lines

So we should make sure we reserve
that space in our memory maps.

I will try to load ATF into one of the SRAM regions the A64 has, and tag that as secure. U-Boot shouldn't care about ATF then, we don't need to reserve any memory for it - after all those SRAM regions look like some kind of MMIO device which we wouldn't touch anyway.

Quoted 19 lines · Andre Przywara

Hi,

sorry for the late reply, just found your series here.

Quoted 2 lines · Alexander Graf

On the A64 we usually boot with ATF running in EL3. ATF as it is available today resides in the first 16MB of RAM.

So this is actually a mistake Allwinner made and which we haven't fixed yet. ATF (at least BL3-1, which is the runtime service part we use for the A64) should at least run in secure memory, actually in secure SRAM. Having it in DRAM is a kludge, unnecessary (it's small enough to reside in some SRAM), a waste of memory (it should get along with something like 32KB) and also insecure, as long as we don't use the TrustZone controller to mark this part of DRAM as secure.

Quoted 2 lines

So we should make sure we reserve
that space in our memory maps.

Quoted 4 lines

I will try to load ATF into one of the SRAM regions the A64 has, and tag that as secure. U-Boot shouldn't care about ATF then, we don't need to reserve any memory for it - after all those SRAM regions look like some kind of MMIO device which we wouldn't touch anyway.

I think that's a great plan moving forward. Is there any way we can runtime detect this in U-Boot to run with both old and new ATF versions or should we just break backwards compatibility?

Quoted 22 lines · Alexander Graf

Quoted 19 lines · Andre Przywara

Hi,

sorry for the late reply, just found your series here.

Quoted 2 lines · Alexander Graf

On the A64 we usually boot with ATF running in EL3. ATF as it is available today resides in the first 16MB of RAM.

So this is actually a mistake Allwinner made and which we haven't fixed yet. ATF (at least BL3-1, which is the runtime service part we use for the A64) should at least run in secure memory, actually in secure SRAM. Having it in DRAM is a kludge, unnecessary (it's small enough to reside in some SRAM), a waste of memory (it should get along with something like 32KB) and also insecure, as long as we don't use the TrustZone controller to mark this part of DRAM as secure.

Quoted 2 lines

So we should make sure we reserve
that space in our memory maps.

Quoted 8 lines

Quoted 4 lines

I will try to load ATF into one of the SRAM regions the A64 has, and tag that as secure. U-Boot shouldn't care about ATF then, we don't need to reserve any memory for it - after all those SRAM regions look like some kind of MMIO device which we wouldn't touch anyway.

I think that's a great plan moving forward. Is there any way we can runtime detect this in U-Boot to run with both old and new ATF versions or should we just break backwards compatibility?

I wouldn't give anything on compatibility to those code versions. I expect both U-Boot, SPL/boot0 and ATF bundled together in some kind of firmware build or image.
Also in the moment this is all in early development stage - I have removed more cruft from the ATF source and am tempted to switch to a proper upstream port soon. Also I am about to remove the SCP completely.

So I'd like to see us doing proper upstream ports of all components, without caring about outdated and abandoned code bases.
If people care about a certain feature or capability of some legacy firmware version, they are welcome to either port this properly or use that old build.