Re: [U-Boot] [PATCH v2 14/23] sunxi: H3: add DRAM controller single bit delay support

[Chen-Yu Tsai]

On Mon, Dec 5, 2016 at 2:26 PM, Simon Glass  wrote:
> Hi Andre,
>
> On 4 December 2016 at 18:52, Andre Przywara  wrote:
>> From: Jens Kuske 
>>
>> Instead of setting the delay for whole bytes allow setting
>> it for each individual bit. Also add support for
>> address/command lane delays.
>>
>> Signed-off-by: Jens Kuske 
>> Signed-off-by: Andre Przywara 
>> ---
>>  arch/arm/mach-sunxi/dram_sun8i_h3.c | 54 
>> ++---
>>  1 file changed, 27 insertions(+), 27 deletions(-)
>
> ACBDLR_WRITE_DELAY_SHIFT
>
>>
>> diff --git a/arch/arm/mach-sunxi/dram_sun8i_h3.c 
>> b/arch/arm/mach-sunxi/dram_sun8i_h3.c
>> index 3dd6803..1647d76 100644
>> --- a/arch/arm/mach-sunxi/dram_sun8i_h3.c
>> +++ b/arch/arm/mach-sunxi/dram_sun8i_h3.c
>> @@ -16,12 +16,13 @@
>>  #include 
>>
>>  struct dram_para {
>> -   u32 read_delays;
>> -   u32 write_delays;
>> u16 page_size;
>> u8 bus_width;
>> u8 dual_rank;
>> u8 row_bits;
>> +   const u8 dx_read_delays[4][11];
>
> Can we have #defines for 4 and 11?
>
>> +   const u8 dx_write_delays[4][11];
>> +   const u8 ac_delays[31];
>>  };
>>
>>  static inline int ns_to_t(int nanoseconds)
>> @@ -64,34 +65,25 @@ static void mctl_phy_init(u32 val)
>> mctl_await_completion(_ctl->pgsr[0], PGSR_INIT_DONE, 0x1);
>>  }
>>
>> -static void mctl_dq_delay(u32 read, u32 write)
>> +static void mctl_set_bit_delays(struct dram_para *para)
>>  {
>> struct sunxi_mctl_ctl_reg * const mctl_ctl =
>> (struct sunxi_mctl_ctl_reg *)SUNXI_DRAM_CTL0_BASE;
>> int i, j;
>> -   u32 val;
>> -
>> -   for (i = 0; i < 4; i++) {
>> -   val = DXBDLR_WRITE_DELAY((write >> (i * 4)) & 0xf) |
>> - DXBDLR_READ_DELAY(((read >> (i * 4)) & 0xf) * 2);
>> -
>> -   for (j = DXBDLR_DQ(0); j <= DXBDLR_DM; j++)
>> -   writel(val, _ctl->dx[i].bdlr[j]);
>> -   }
>>
>> clrbits_le32(_ctl->pgcr[0], 1 << 26);
>>
>> -   for (i = 0; i < 4; i++) {
>> -   val = DXBDLR_WRITE_DELAY((write >> (16 + i * 4)) & 0xf) |
>> - DXBDLR_READ_DELAY((read >> (16 + i * 4)) & 0xf);
>> +   for (i = 0; i < 4; i++)
>> +   for (j = 0; j < 11; j++)
>> +   
>> writel(DXBDLR_WRITE_DELAY(para->dx_write_delays[i][j]) |
>> +  DXBDLR_READ_DELAY(para->dx_read_delays[i][j]),
>> +  _ctl->dx[i].bdlr[j]);
>>
>> -   writel(val, _ctl->dx[i].bdlr[DXBDLR_DQS]);
>> -   writel(val, _ctl->dx[i].bdlr[DXBDLR_DQSN]);
>> -   }
>> +   for (i = 0; i < 31; i++)
>> +   writel(ACBDLR_WRITE_DELAY(para->ac_delays[i]),
>> +  _ctl->acbdlr[i]);
>>
>> setbits_le32(_ctl->pgcr[0], 1 << 26);
>> -
>> -   udelay(1);
>>  }
>>
>>  static void mctl_set_master_priority(void)
>> @@ -372,11 +364,8 @@ static int mctl_channel_init(struct dram_para *para)
>> clrsetbits_le32(_ctl->dtcr, 0xf << 24,
>> (para->dual_rank ? 0x3 : 0x1) << 24);
>>
>> -
>> -   if (para->read_delays || para->write_delays) {
>> -   mctl_dq_delay(para->read_delays, para->write_delays);
>> -   udelay(50);
>> -   }
>> +   mctl_set_bit_delays(para);
>> +   udelay(50);
>>
>> mctl_zq_calibration(para);
>>
>> @@ -458,12 +447,23 @@ unsigned long sunxi_dram_init(void)
>> (struct sunxi_mctl_ctl_reg *)SUNXI_DRAM_CTL0_BASE;
>>
>> struct dram_para para = {
>> -   .read_delays = 0x7979,  /* dram_tpr12 */
>> -   .write_delays = 0x6aaa, /* dram_tpr11 */
>> .dual_rank = 0,
>> .bus_width = 32,
>> .row_bits = 15,
>> .page_size = 4096,
>> +
>> +   .dx_read_delays =  {{ 18, 18, 18, 18, 18, 18, 18, 18, 18,  
>> 0,  0 },
>> +   { 14, 14, 14, 14, 14, 14, 14, 14, 14,  
>> 0,  0 },
>> +   { 18, 18, 18, 18, 18, 18, 18, 18, 18,  
>> 0,  0 },
>> +   { 14, 14, 14, 14, 14, 14, 14, 14, 14,  
>> 0,  0 }},
>> +   .dx_write_delays = {{  0,  0,  0,  0,  0,  0,  0,  0,  0, 
>> 10, 10 },
>> +   {  0,  0,  0,  0,  0,  0,  0,  0,  0, 
>> 10, 10 },
>> +   {  0,  0,  0,  0,  0,  0,  0,  0,  0, 
>> 10, 10 },
>> +   {  0,  0,  0,  0,  0,  0,  0,  0,  0,  
>> 6,  6 }},
>> +   .ac_delays = {  0,  0,  0,  0,  0,  0,  0,  0,
>> +   0,  0,  0,  0,  0,  0,  0,  0,
>> +   0,  0,  0,  0,  0,  0,  0,  0,
>> +   0,  0,  0,  0,  0,  0,  0  },
>> };
>>
>> 

[U-Boot] [PATCH v4 2/2] splash: add support for loading splash from a FIT image

[Tomas Melin]

Enable support for loading a splash image from within a FIT image.
The image is assumed to be generated with mkimage -E flag to hold
the data external to the FIT.

Signed-off-by: Tomas Melin 
---

Changes in v4:
- Added missing changelog

Changes in v3:
- Add documentation to README.splashprepare
- Change printf() to debug()
- Coding style fixes

Changes in v2:
- Add helper functions to image-fit.c for getting required FIT data fields
- Add comments

 common/image-fit.c   | 48 
 common/splash_source.c   | 71 
 doc/README.splashprepare | 15 ++
 include/image.h  |  4 +++
 include/splash.h |  5 ++--
 5 files changed, 136 insertions(+), 7 deletions(-)

diff --git a/common/image-fit.c b/common/image-fit.c
index 25f8a11..8d9d050 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -775,6 +775,54 @@ int fit_image_get_data(const void *fit, int noffset,
 }
 
 /**
+ * Get 'data-offset' property from a given image node.
+ *
+ * @fit: pointer to the FIT image header
+ * @noffset: component image node offset
+ * @data_offset: holds the data-offset property
+ *
+ * returns:
+ * 0, on success
+ * -ENOENT if the property could not be found
+ */
+int fit_image_get_data_offset(const void *fit, int noffset, int *data_offset)
+{
+   const fdt32_t *val;
+
+   val = fdt_getprop(fit, noffset, FIT_DATA_OFFSET_PROP, NULL);
+   if (!val)
+   return -ENOENT;
+
+   *data_offset = fdt32_to_cpu(*val);
+
+   return 0;
+}
+
+/**
+ * Get 'data-size' property from a given image node.
+ *
+ * @fit: pointer to the FIT image header
+ * @noffset: component image node offset
+ * @data_size: holds the data-size property
+ *
+ * returns:
+ * 0, on success
+ * -ENOENT if the property could not be found
+ */
+int fit_image_get_data_size(const void *fit, int noffset, int *data_size)
+{
+   const fdt32_t *val;
+
+   val = fdt_getprop(fit, noffset, FIT_DATA_SIZE_PROP, NULL);
+   if (!val)
+   return -ENOENT;
+
+   *data_size = fdt32_to_cpu(*val);
+
+   return 0;
+}
+
+/**
  * fit_image_hash_get_algo - get hash algorithm name
  * @fit: pointer to the FIT format image header
  * @noffset: hash node offset
diff --git a/common/splash_source.c b/common/splash_source.c
index 70d724f..94b46d3 100644
--- a/common/splash_source.c
+++ b/common/splash_source.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -241,6 +242,72 @@ static struct splash_location *select_splash_location(
return NULL;
 }
 
+#ifdef CONFIG_FIT
+static int splash_load_fit(struct splash_location *location, u32 bmp_load_addr)
+{
+   int res;
+   int node_offset;
+   int splash_offset;
+   int splash_size;
+   struct image_header *img_header;
+   const u32 *fit_header;
+   u32 fit_size;
+   const size_t header_size = sizeof(struct image_header);
+
+   /* Read in image header */
+   res = splash_storage_read_raw(location, bmp_load_addr, header_size);
+   if (res < 0)
+   return res;
+
+   img_header = (struct image_header *)bmp_load_addr;
+   fit_size = fdt_totalsize(img_header);
+
+   /* Read in entire FIT */
+   fit_header = (const u32 *)(bmp_load_addr + header_size);
+   res = splash_storage_read_raw(location, (u32)fit_header, fit_size);
+   if (res < 0)
+   return res;
+
+   res = fit_check_format(fit_header);
+   if (!res) {
+   debug("Could not find valid FIT image\n");
+   return -EINVAL;
+   }
+
+   node_offset = fit_image_get_node(fit_header, location->name);
+   if (node_offset < 0) {
+   debug("Could not find splash image '%s' in FIT\n",
+ location->name);
+   return -ENOENT;
+   }
+
+   res = fit_image_get_data_offset(fit_header, node_offset,
+   _offset);
+   if (res < 0) {
+   debug("Could not find 'data-offset' property in FIT\n");
+   return res;
+   }
+
+   res = fit_image_get_data_size(fit_header, node_offset, _size);
+   if (res < 0) {
+   debug("Could not find 'data-size' property in FIT\n");
+   return res;
+   }
+
+   /* Align data offset to 4-byte boundrary */
+   fit_size = fdt_totalsize(fit_header);
+   fit_size = (fit_size + 3) & ~3;
+
+   /* Read in the splash data */
+   location->offset = (location->offset + fit_size + splash_offset);
+   res = splash_storage_read_raw(location, bmp_load_addr , splash_size);
+   if (res < 0)
+   return res;
+
+   return 0;
+}
+#endif /* CONFIG_FIT */
+
 /**
  * splash_source_load - load splash image from a supported location.
  *
@@ -277,5 +344,9 @@ int splash_source_load(struct splash_location *locations, 
uint size)
  

[U-Boot] [PATCH v4 1/2] splash: sort include files

[Tomas Melin]

Sort include files in accordance to u-boot coding style.

Signed-off-by: Tomas Melin 
---

Changes in v4:
- Added missing changelog

Changes in v3:
- Change patch order so that include sort patch comes prior to adding
  new include

Changes in v2:
- Add separate patch for sorting include files

 common/splash_source.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/common/splash_source.c b/common/splash_source.c
index d300e46..70d724f 100644
--- a/common/splash_source.c
+++ b/common/splash_source.c
@@ -7,15 +7,16 @@
  */
 
 #include 
-#include 
+#include 
 #include 
-#include 
-#include 
+#include 
+#include 
+#include 
+#include 
 #include 
+#include 
+#include 
 #include 
-#include 
-#include 
-#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
-- 
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 02/23] armv8: prevent using THUMB

[Maxime Ripard]

On Mon, Dec 05, 2016 at 01:52:09AM +, Andre Przywara wrote:
> The predominantely 32-bit ARM targets try to compile the SPL in Thumb
> mode to reduce code size.
> The 64-bit AArch64 instruction set does not know an alternative, concise
> encoding, so the Thumb build option should only be set for 32-bit
> targets.
> Likewise -marm machine options are only valid for ARMv7 targets.
> 
> Signed-off-by: Andre Przywara 
> Reviewed-by: Alexander Graf 

Acked-by: Maxime Ripard 

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 01/23] sun6i: Restrict some register initialization to Allwinner A31 SoC

[Maxime Ripard]

On Mon, Dec 05, 2016 at 01:52:08AM +, Andre Przywara wrote:
> These days many Allwinner SoCs use clock_sun6i.c, although out of them
> only the (original sun6i) A31 has a second MBUS clock register.
> Also the requirement for setting up the PRCM PLL_CTLR1 register to provide
> the proper voltage seems to be a property of older SoCs only as well.
> 
> Restrict the MBUS initialization to this SoC only to avoid writing bogus
> values to (undefined) registers in other chips.
> I can only verify that the PLL voltage setup is not needed for H3 and
> A64, so for now we only spare those two SoCs.
> 
> Signed-off-by: Andre Przywara 
> Reviewed-by: Alexander Graf 
> Reviewed-by: Chen-Yu Tsai 

Acked-by: Maxime Ripard 

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 03/23] armv8: add lowlevel_init.S

[Simon Glass]

Hi Andre,

On 4 December 2016 at 18:52, Andre Przywara  wrote:
> For boards that call s_init() when the SPL runs, we are expected to
> setup an early stack before calling this C function.
> Implement the proper AArch64 version of this based on the ARMv7 code.
> This allows sunxi boards to setup the basic peripherals even on with a
> 64-bit SPL.
>
> Signed-off-by: Andre Przywara 
> ---
>  arch/arm/cpu/armv8/Makefile|  1 +
>  arch/arm/cpu/armv8/lowlevel_init.S | 44 
> ++
>  2 files changed, 45 insertions(+)
>  create mode 100644 arch/arm/cpu/armv8/lowlevel_init.S

Is this actually needed / used for anything?

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 23/23] sunxi: A64: add 32-bit SPL support

[Simon Glass]

Hi Andre,

On 4 December 2016 at 18:52, Andre Przywara  wrote:
> When compiling the SPL for the Allwinner A64 in AArch64 mode, we can't
> use the more compact Thumb2 encoding, which only exists for AArch32
> code. This makes the SPL rather big, up to a point where any code
> additions or even a different compiler may easily exceed the 32KB limit
> that the Allwinner BROM imposes.
> Introduce a separate, mostly generic sun50i-a64 configuration, which
> defines the CPU_V7 symbol and thus will create a 32-bit binary using
> the memory-saving Thumb2 encoding.
> This should only be used for the SPL, the U-Boot proper should still be
> using the existing 64-bit configuration. The SPL code can switch to
> AArch64 if needed, so a 32-bit SPL can be combined with a 64-bit U-Boot
> proper to eventually launch arm64 kernels.

So if I understand correctly, you want SPL to be 32-bit and U-Boot
proper to be 64-bit? And you are adding a new board config for that?

Instead, can you do something similar to tegra, which uses ARMv4t for
SPL and ARMv7 for U-Boot proper?

>
> Signed-off-by: Andre Przywara 
> ---
>  board/sunxi/Kconfig| 14 --
>  configs/pine64_plus_defconfig  |  2 +-
>  configs/sun50i_spl32_defconfig | 10 ++
>  include/configs/sunxi-common.h |  2 +-
>  4 files changed, 24 insertions(+), 4 deletions(-)
>  create mode 100644 configs/sun50i_spl32_defconfig

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 22/23] sunxi: introduce RMR switch to enter payloads in 64-bit mode

[Simon Glass]

Hi Andre,

On 4 December 2016 at 18:52, Andre Przywara  wrote:
> The ARMv8 capable Allwinner A64 SoC comes out of reset in AArch32 mode.
> To run AArch64 code, we have to trigger a warm reset via the RMR register,
> which proceeds with code execution at the address stored in the RVBAR
> register.
> If the bootable payload in the FIT image is using a different
> architecture than the SPL has been compiled for, enter it via this said
> RMR switch mechanism, by writing the entry point address into the MMIO
> mapped, writable version of the RVBAR register.
> Then the warm reset is triggered via a system register write.
> If the payload architecture is the same as the SPL, we use the normal
> branch as usual.
>
> Signed-off-by: Andre Przywara 
> ---
>  arch/arm/mach-sunxi/Makefile |  1 +
>  arch/arm/mach-sunxi/spl_switch.c | 60 
> 
>  2 files changed, 61 insertions(+)
>  create mode 100644 arch/arm/mach-sunxi/spl_switch.c
>
> diff --git a/arch/arm/mach-sunxi/Makefile b/arch/arm/mach-sunxi/Makefile
> index 7daba11..128091e 100644
> --- a/arch/arm/mach-sunxi/Makefile
> +++ b/arch/arm/mach-sunxi/Makefile
> @@ -51,4 +51,5 @@ obj-$(CONFIG_MACH_SUN8I_A83T) += dram_sun8i_a83t.o
>  obj-$(CONFIG_MACH_SUN8I_H3)+= dram_sun8i_h3.o
>  obj-$(CONFIG_MACH_SUN9I)   += dram_sun9i.o
>  obj-$(CONFIG_MACH_SUN50I)  += dram_sun8i_h3.o
> +obj-$(CONFIG_MACH_SUN50I)  += spl_switch.o
>  endif
> diff --git a/arch/arm/mach-sunxi/spl_switch.c 
> b/arch/arm/mach-sunxi/spl_switch.c
> new file mode 100644
> index 000..20f21b1
> --- /dev/null
> +++ b/arch/arm/mach-sunxi/spl_switch.c
> @@ -0,0 +1,60 @@
> +/*
> + * (C) Copyright 2016 ARM Ltd.
> + *
> + * SPDX-License-Identifier: GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +static void __noreturn jump_to_image_native(struct spl_image_info *spl_image)
> +{
> +   typedef void __noreturn (*image_entry_noargs_t)(void);
> +
> +   image_entry_noargs_t image_entry =
> +   (image_entry_noargs_t)spl_image->entry_point;
> +
> +   image_entry();
> +}
> +
> +static void __noreturn reset_rmr_switch(void)
> +{
> +#ifdef CONFIG_ARM64
> +   __asm__ volatile ( "mrs  x0, RMR_EL3\n\t"
> +  "bic  x0, x0, #1\n\t"   /* Clear enter-in-64 bit */
> +  "orr  x0, x0, #2\n\t"   /* set reset request bit */
> +  "msr  RMR_EL3, x0\n\t"
> +  "isb  sy\n\t"
> +  "nop\n\t"
> +  "wfi\n\t"
> +  "b.\n"
> +  ::: "x0");
> +#else
> +   __asm__ volatile ( "mrc  15, 0, r0, cr12, cr0, 2\n\t"
> +  "orr  r0, r0, #3\n\t"   /* request reset in 64 bit 
> */
> +  "mcr  15, 0, r0, cr12, cr0, 2\n\t"
> +  "isb\n\t"
> +  "nop\n\t"
> +  "wfi\n\t"
> +  "b.\n"
> +  ::: "r0");
> +#endif
> +   while (1);  /* to avoid a compiler warning about __noreturn */
> +}
> +
> +void __noreturn jump_to_image_no_args(struct spl_image_info *spl_image)
> +{
> +   if (spl_image->arch == IH_ARCH_DEFAULT) {
> +   debug("entering by branch\n");
> +   jump_to_image_native(spl_image);
> +   } else {
> +   debug("entering by RMR switch\n");
> +   writel(spl_image->entry_point, 0x17000a0);
> +   DSB;
> +   ISB;
> +   reset_rmr_switch();
> +   }

I think this could use some comments or a pointer to a README to
explain what is going on.

> +}
> --
> 2.8.2
>

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 18/23] sunxi: A64: enable SPL

[Simon Glass]

On 4 December 2016 at 18:52, Andre Przywara  wrote:
> Now that the SPL is ready to be compiled in AArch64 and the DRAM
> init code is ready, enable SPL support for the A64 SoC and in the
> Pine64 defconfig.
> For now we keep the boot0 header in the U-Boot proper, as this allows
> to still use boot0 as an SPL replacement without hurting the SPL use
> case.
> We disable FEL support for now, as the code isn't ready yet.

Where is this done? Is it because you don't enable it?

>
> Signed-off-by: Andre Przywara 
> ---
>  arch/arm/mach-sunxi/board.c| 2 +-
>  board/sunxi/Kconfig| 2 ++
>  configs/pine64_plus_defconfig  | 1 +
>  include/configs/sunxi-common.h | 2 ++
>  4 files changed, 6 insertions(+), 1 deletion(-)

Reviewed-by: Simon Glass 

>
> diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
> index 0f8ead9..80d4b57 100644
> --- a/arch/arm/mach-sunxi/board.c
> +++ b/arch/arm/mach-sunxi/board.c
> @@ -133,7 +133,7 @@ static int gpio_init(void)
> return 0;
>  }
>
> -#ifdef CONFIG_SPL_BUILD
> +#if defined(CONFIG_SPL_BOARD_LOAD_IMAGE) && defined(CONFIG_SPL_BUILD)
>  static int spl_board_load_image(struct spl_image_info *spl_image,
> struct spl_boot_device *bootdev)
>  {
> diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
> index d477925..b5246df 100644
> --- a/board/sunxi/Kconfig
> +++ b/board/sunxi/Kconfig
> @@ -125,6 +125,7 @@ config MACH_SUN50I
> bool "sun50i (Allwinner A64)"
> select ARM64
> select SUNXI_GEN_SUN6I
> +   select SUPPORT_SPL
>
>  endchoice
>
> @@ -187,6 +188,7 @@ config DRAM_ODT_EN
> bool "sunxi dram odt enable"
> default n if !MACH_SUN8I_A23
> default y if MACH_SUN8I_A23
> +   default y if MACH_SUN50I
> ---help---
> Select this to enable dram odt (on die termination).
>
> diff --git a/configs/pine64_plus_defconfig b/configs/pine64_plus_defconfig
> index ebc24b8..2374170 100644
> --- a/configs/pine64_plus_defconfig
> +++ b/configs/pine64_plus_defconfig
> @@ -5,6 +5,7 @@ CONFIG_MACH_SUN50I=y
>  CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-pine64-plus"
>  # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
>  CONFIG_CONSOLE_MUX=y
> +CONFIG_SPL=y
>  # CONFIG_CMD_IMLS is not set
>  # CONFIG_CMD_FLASH is not set
>  # CONFIG_CMD_FPGA is not set
> diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
> index e05c318..5279e51 100644
> --- a/include/configs/sunxi-common.h
> +++ b/include/configs/sunxi-common.h
> @@ -183,7 +183,9 @@
>
>  #define CONFIG_SPL_FRAMEWORK
>
> +#ifndef CONFIG_MACH_SUN50I
>  #define CONFIG_SPL_BOARD_LOAD_IMAGE
> +#endif
>
>  #if defined(CONFIG_MACH_SUN9I)
>  #define CONFIG_SPL_TEXT_BASE   0x10040 /* sram start+header 
> */
> --
> 2.8.2
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 17/23] sunxi: DRAM: fix H3 DRAM size display on aarch64

[Simon Glass]

On 4 December 2016 at 18:52, Andre Przywara  wrote:
> Fix the output of the DRAM size on AArch64 SPLs.
>
> Signed-off-by: Andre Przywara 
> Reviewed-by: Alexander Graf 
> ---
>  arch/arm/mach-sunxi/dram_sun8i_h3.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 16/23] sunxi: H3/A64: fix non-ODT setting

[Simon Glass]

On 4 December 2016 at 18:52, Andre Przywara  wrote:
> According to Jens disabling the on-die-termination should set bit 5,
> not bit 1 in the respective register. Fix this.
>
> Reported-by: Jens Kuske 
> Signed-off-by: Andre Przywara 
> ---
>  arch/arm/mach-sunxi/dram_sun8i_h3.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

If you know the field name, a #define would be good.

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 15/23] sunxi: A64: use H3 DRAM initialization code for A64

[Simon Glass]

Hi Andre,

On 4 December 2016 at 18:52, Andre Przywara  wrote:
> From: Jens Kuske 
>
> The A64 DRAM controller is very similar to the H3 one,
> so the code can be reused with some small changes.

Yes but it makes the code a mess. Can you avoid putting #iifdefs everywhere?

Since it is a static function I wonder if you can instead use a
function parameter which defines the chip to support, and the compiler
will eliminate the unused code?

See below...

> [Andre: fixed up typo, merged in fixes from Jens]
>
> Signed-off-by: Jens Kuske 
> Signed-off-by: Andre Przywara 
> ---
>  arch/arm/include/asm/arch-sunxi/clock_sun6i.h   |   1 +
>  arch/arm/include/asm/arch-sunxi/dram.h  |   2 +-
>  arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h |  10 +-
>  arch/arm/mach-sunxi/Makefile|   1 +
>  arch/arm/mach-sunxi/clock_sun6i.c   |   2 +-
>  arch/arm/mach-sunxi/dram_sun8i_h3.c | 139 
> +++-
>  6 files changed, 123 insertions(+), 32 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h 
> b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> index be9fcfd..3f87672 100644
> --- a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> +++ b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> @@ -322,6 +322,7 @@ struct sunxi_ccm_reg {
>  #define CCM_DRAMCLK_CFG_DIV0_MASK  (0xf << 8)
>  #define CCM_DRAMCLK_CFG_SRC_PLL5   (0x0 << 20)
>  #define CCM_DRAMCLK_CFG_SRC_PLL6x2 (0x1 << 20)
> +#define CCM_DRAMCLK_CFG_SRC_PLL11  (0x1 << 20) /* A64 only */
>  #define CCM_DRAMCLK_CFG_SRC_MASK   (0x3 << 20)
>  #define CCM_DRAMCLK_CFG_UPD(0x1 << 16)
>  #define CCM_DRAMCLK_CFG_RST(0x1 << 31)
> diff --git a/arch/arm/include/asm/arch-sunxi/dram.h 
> b/arch/arm/include/asm/arch-sunxi/dram.h
> index e0be744..53e6d47 100644
> --- a/arch/arm/include/asm/arch-sunxi/dram.h
> +++ b/arch/arm/include/asm/arch-sunxi/dram.h
> @@ -24,7 +24,7 @@
>  #include 
>  #elif defined(CONFIG_MACH_SUN8I_A83T)
>  #include 
> -#elif defined(CONFIG_MACH_SUN8I_H3)
> +#elif defined(CONFIG_MACH_SUN8I_H3) || defined(CONFIG_MACH_SUN50I)
>  #include 
>  #elif defined(CONFIG_MACH_SUN9I)
>  #include 
> diff --git a/arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h 
> b/arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h
> index 867fd12..b0e5d93 100644
> --- a/arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h
> +++ b/arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h
> @@ -15,7 +15,8 @@
>
>  struct sunxi_mctl_com_reg {
> u32 cr; /* 0x00 control register */
> -   u8 res0[0xc];   /* 0x04 */
> +   u8 res0[0x8];   /* 0x04 */
> +   u32 tmr;/* 0x0c (A64 only) */
> u32 mcr[16][2]; /* 0x10 */
> u32 bwcr;   /* 0x90 bandwidth control register */
> u32 maer;   /* 0x94 master enable register */
> @@ -32,7 +33,9 @@ struct sunxi_mctl_com_reg {
> u32 swoffr; /* 0xc4 */
> u8 res2[0x8];   /* 0xc8 */
> u32 cccr;   /* 0xd0 */
> -   u8 res3[0x72c]; /* 0xd4 */
> +   u8 res3[0x54];  /* 0xd4 */
> +   u32 mdfs_bwlr[3];   /* 0x128 (A64 only) */
> +   u8 res4[0x6cc]; /* 0x134 */
> u32 protect;/* 0x800 */
>  };
>
> @@ -81,7 +84,8 @@ struct sunxi_mctl_ctl_reg {
> u32 rfshtmg;/* 0x90 refresh timing */
> u32 rfshctl1;   /* 0x94 */
> u32 pwrtmg; /* 0x98 */
> -   u8 res3[0x20];  /* 0x9c */
> +   u8 res3[0x1c];  /* 0x9c */
> +   u32 vtfcr;  /* 0xb8 (A64 only) */
> u32 dqsgmr; /* 0xbc */
> u32 dtcr;   /* 0xc0 */
> u32 dtar[4];/* 0xc4 */
> diff --git a/arch/arm/mach-sunxi/Makefile b/arch/arm/mach-sunxi/Makefile
> index e73114e..7daba11 100644
> --- a/arch/arm/mach-sunxi/Makefile
> +++ b/arch/arm/mach-sunxi/Makefile
> @@ -50,4 +50,5 @@ obj-$(CONFIG_MACH_SUN8I_A33)  += dram_sun8i_a33.o
>  obj-$(CONFIG_MACH_SUN8I_A83T)  += dram_sun8i_a83t.o
>  obj-$(CONFIG_MACH_SUN8I_H3)+= dram_sun8i_h3.o
>  obj-$(CONFIG_MACH_SUN9I)   += dram_sun9i.o
> +obj-$(CONFIG_MACH_SUN50I)  += dram_sun8i_h3.o
>  endif
> diff --git a/arch/arm/mach-sunxi/clock_sun6i.c 
> b/arch/arm/mach-sunxi/clock_sun6i.c
> index 80cfc0b..99f515d 100644
> --- a/arch/arm/mach-sunxi/clock_sun6i.c
> +++ b/arch/arm/mach-sunxi/clock_sun6i.c
> @@ -217,7 +217,7 @@ done:
>  }
>  #endif
>
> -#ifdef CONFIG_MACH_SUN8I_A33
> +#if defined(CONFIG_MACH_SUN8I_A33) || defined(CONFIG_MACH_SUN50I)
>  void clock_set_pll11(unsigned int clk, bool sigma_delta_enable)
>  {
> struct sunxi_ccm_reg * const ccm =
> diff --git a/arch/arm/mach-sunxi/dram_sun8i_h3.c 
> b/arch/arm/mach-sunxi/dram_sun8i_h3.c
> index 1647d76..2dc2071 100644
> --- 

Re: [U-Boot] [PATCH v2 14/23] sunxi: H3: add DRAM controller single bit delay support

[Simon Glass]

Hi Andre,

On 4 December 2016 at 18:52, Andre Przywara  wrote:
> From: Jens Kuske 
>
> Instead of setting the delay for whole bytes allow setting
> it for each individual bit. Also add support for
> address/command lane delays.
>
> Signed-off-by: Jens Kuske 
> Signed-off-by: Andre Przywara 
> ---
>  arch/arm/mach-sunxi/dram_sun8i_h3.c | 54 
> ++---
>  1 file changed, 27 insertions(+), 27 deletions(-)

ACBDLR_WRITE_DELAY_SHIFT

>
> diff --git a/arch/arm/mach-sunxi/dram_sun8i_h3.c 
> b/arch/arm/mach-sunxi/dram_sun8i_h3.c
> index 3dd6803..1647d76 100644
> --- a/arch/arm/mach-sunxi/dram_sun8i_h3.c
> +++ b/arch/arm/mach-sunxi/dram_sun8i_h3.c
> @@ -16,12 +16,13 @@
>  #include 
>
>  struct dram_para {
> -   u32 read_delays;
> -   u32 write_delays;
> u16 page_size;
> u8 bus_width;
> u8 dual_rank;
> u8 row_bits;
> +   const u8 dx_read_delays[4][11];

Can we have #defines for 4 and 11?

> +   const u8 dx_write_delays[4][11];
> +   const u8 ac_delays[31];
>  };
>
>  static inline int ns_to_t(int nanoseconds)
> @@ -64,34 +65,25 @@ static void mctl_phy_init(u32 val)
> mctl_await_completion(_ctl->pgsr[0], PGSR_INIT_DONE, 0x1);
>  }
>
> -static void mctl_dq_delay(u32 read, u32 write)
> +static void mctl_set_bit_delays(struct dram_para *para)
>  {
> struct sunxi_mctl_ctl_reg * const mctl_ctl =
> (struct sunxi_mctl_ctl_reg *)SUNXI_DRAM_CTL0_BASE;
> int i, j;
> -   u32 val;
> -
> -   for (i = 0; i < 4; i++) {
> -   val = DXBDLR_WRITE_DELAY((write >> (i * 4)) & 0xf) |
> - DXBDLR_READ_DELAY(((read >> (i * 4)) & 0xf) * 2);
> -
> -   for (j = DXBDLR_DQ(0); j <= DXBDLR_DM; j++)
> -   writel(val, _ctl->dx[i].bdlr[j]);
> -   }
>
> clrbits_le32(_ctl->pgcr[0], 1 << 26);
>
> -   for (i = 0; i < 4; i++) {
> -   val = DXBDLR_WRITE_DELAY((write >> (16 + i * 4)) & 0xf) |
> - DXBDLR_READ_DELAY((read >> (16 + i * 4)) & 0xf);
> +   for (i = 0; i < 4; i++)
> +   for (j = 0; j < 11; j++)
> +   
> writel(DXBDLR_WRITE_DELAY(para->dx_write_delays[i][j]) |
> +  DXBDLR_READ_DELAY(para->dx_read_delays[i][j]),
> +  _ctl->dx[i].bdlr[j]);
>
> -   writel(val, _ctl->dx[i].bdlr[DXBDLR_DQS]);
> -   writel(val, _ctl->dx[i].bdlr[DXBDLR_DQSN]);
> -   }
> +   for (i = 0; i < 31; i++)
> +   writel(ACBDLR_WRITE_DELAY(para->ac_delays[i]),
> +  _ctl->acbdlr[i]);
>
> setbits_le32(_ctl->pgcr[0], 1 << 26);
> -
> -   udelay(1);
>  }
>
>  static void mctl_set_master_priority(void)
> @@ -372,11 +364,8 @@ static int mctl_channel_init(struct dram_para *para)
> clrsetbits_le32(_ctl->dtcr, 0xf << 24,
> (para->dual_rank ? 0x3 : 0x1) << 24);
>
> -
> -   if (para->read_delays || para->write_delays) {
> -   mctl_dq_delay(para->read_delays, para->write_delays);
> -   udelay(50);
> -   }
> +   mctl_set_bit_delays(para);
> +   udelay(50);
>
> mctl_zq_calibration(para);
>
> @@ -458,12 +447,23 @@ unsigned long sunxi_dram_init(void)
> (struct sunxi_mctl_ctl_reg *)SUNXI_DRAM_CTL0_BASE;
>
> struct dram_para para = {
> -   .read_delays = 0x7979,  /* dram_tpr12 */
> -   .write_delays = 0x6aaa, /* dram_tpr11 */
> .dual_rank = 0,
> .bus_width = 32,
> .row_bits = 15,
> .page_size = 4096,
> +
> +   .dx_read_delays =  {{ 18, 18, 18, 18, 18, 18, 18, 18, 18,  0, 
>  0 },
> +   { 14, 14, 14, 14, 14, 14, 14, 14, 14,  0, 
>  0 },
> +   { 18, 18, 18, 18, 18, 18, 18, 18, 18,  0, 
>  0 },
> +   { 14, 14, 14, 14, 14, 14, 14, 14, 14,  0, 
>  0 }},
> +   .dx_write_delays = {{  0,  0,  0,  0,  0,  0,  0,  0,  0, 10, 
> 10 },
> +   {  0,  0,  0,  0,  0,  0,  0,  0,  0, 10, 
> 10 },
> +   {  0,  0,  0,  0,  0,  0,  0,  0,  0, 10, 
> 10 },
> +   {  0,  0,  0,  0,  0,  0,  0,  0,  0,  6, 
>  6 }},
> +   .ac_delays = {  0,  0,  0,  0,  0,  0,  0,  0,
> +   0,  0,  0,  0,  0,  0,  0,  0,
> +   0,  0,  0,  0,  0,  0,  0,  0,
> +   0,  0,  0,  0,  0,  0,  0  },
> };
>
> mctl_sys_init();
> --
> 2.8.2
>

I wonder if there is value in moving this to device tree with of-platdata?

Regards,
Simon
___
U-Boot mailing list

Re: [U-Boot] [PATCH v2 09/23] ARM: boot0 hook: remove macro, include whole header file

[Simon Glass]

On 4 December 2016 at 18:52, Andre Przywara  wrote:
> For prepending some board specific header area to U-Boot images we
> were so far including a header file with a macro definition containing
> the actual header specification.
> This works fine if there are just a few statements and if there is only
> one alternative.
> However adding more complex code quickly gets messy with this approach,
> so let's just drop that intermediate macro and let the #include actually
> insert the code directly.
> This converts the callers and the callees, but doesn't change anything
> at this point.
>
> Signed-off-by: Andre Przywara 
> ---
>  arch/arm/cpu/armv8/start.S | 1 -
>  arch/arm/include/asm/arch-bcm235xx/boot0.h | 8 +---
>  arch/arm/include/asm/arch-bcm281xx/boot0.h | 8 +---
>  arch/arm/include/asm/arch-sunxi/boot0.h| 8 +---
>  arch/arm/lib/vectors.S | 1 -
>  5 files changed, 3 insertions(+), 23 deletions(-)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 08/23] armv8: move reset branch into boot hook

[Simon Glass]

Hi Andre,

On 4 December 2016 at 18:52, Andre Przywara  wrote:
> The boot0 hook we have so far is applied _after_ the initial branch
> to the "reset" entry point. An upcoming change requires even this
> branch to be changed, so we apply the hook macro at the earliest
> point, and have the branch in the hook file as well.
> This is no functional change at this point, just refactoring to simplify
> upcoming patches.
>
> Signed-off-by: Andre Przywara 
> ---
>  arch/arm/cpu/armv8/start.S  | 4 ++--
>  arch/arm/include/asm/arch-sunxi/boot0.h | 1 +
>  2 files changed, 3 insertions(+), 2 deletions(-)

Will this not affect other boards which use ARM_SOC_BOOT0_HOOK?

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 13/23] sunxi: H3: add and rename some DRAM contoller registers

[Simon Glass]

Hi Andre,

On 4 December 2016 at 18:52, Andre Przywara  wrote:
> From: Jens Kuske 
>
> The IOCR registers got renamed to BDLR to match the public
> documentation of similar controllers.
>
> Signed-off-by: Jens Kuske 
> Signed-off-by: Andre Przywara 
> ---
>  arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h | 43 
> ++---
>  arch/arm/mach-sunxi/dram_sun8i_h3.c | 34 +--
>  2 files changed, 41 insertions(+), 36 deletions(-)

Reviewed-by: Simon Glass 

Some suggestions below if you have the energy.

>
> diff --git a/arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h 
> b/arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h
> index d0f2b8a..867fd12 100644
> --- a/arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h
> +++ b/arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h
> @@ -81,7 +81,7 @@ struct sunxi_mctl_ctl_reg {
> u32 rfshtmg;/* 0x90 refresh timing */
> u32 rfshctl1;   /* 0x94 */
> u32 pwrtmg; /* 0x98 */
> -   u8  res3[0x20]; /* 0x9c */
> +   u8 res3[0x20];  /* 0x9c */
> u32 dqsgmr; /* 0xbc */
> u32 dtcr;   /* 0xc0 */
> u32 dtar[4];/* 0xc4 */
> @@ -106,20 +106,23 @@ struct sunxi_mctl_ctl_reg {
> u32 perfhpr[2]; /* 0x1c4 */
> u32 perflpr[2]; /* 0x1cc */
> u32 perfwr[2];  /* 0x1d4 */
> -   u8 res8[0x2c];  /* 0x1dc */
> -   u32 aciocr; /* 0x208 */
> -   u8 res9[0xf4];  /* 0x20c */
> +   u8 res8[0x24];  /* 0x1dc */
> +   u32 acmdlr; /* 0x200 AC master delay line register */
> +   u32 aclcdlr;/* 0x204 AC local calibrated delay line 
> register */
> +   u32 aciocr; /* 0x208 AC I/O configuration register */
> +   u8 res9[0x4];   /* 0x20c */
> +   u32 acbdlr[31]; /* 0x210 AC bit delay line registers */
> +   u8 res10[0x74]; /* 0x28c */
> struct {/* 0x300 DATX8 modules*/
> -   u32 mdlr;   /* 0x00 */
> -   u32 lcdlr[3];   /* 0x04 */
> -   u32 iocr[11];   /* 0x10 IO configuration register */
> -   u32 bdlr6;  /* 0x3c */
> -   u32 gtr;/* 0x40 */
> -   u32 gcr;/* 0x44 */
> -   u32 gsr[3]; /* 0x48 */
> +   u32 mdlr;   /* 0x00 master delay line register */
> +   u32 lcdlr[3];   /* 0x04 local calibrated delay line 
> registers */
> +   u32 bdlr[12];   /* 0x10 bit delay line registers */
> +   u32 gtr;/* 0x40 general timing register */
> +   u32 gcr;/* 0x44 general configuration 
> register */
> +   u32 gsr[3]; /* 0x48 general status registers */
> u8 res0[0x2c];  /* 0x54 */
> -   } datx[4];
> -   u8 res10[0x388];/* 0x500 */
> +   } dx[4];
> +   u8 res11[0x388];/* 0x500 */
> u32 upd2;   /* 0x888 */
>  };
>
> @@ -174,12 +177,14 @@ struct sunxi_mctl_ctl_reg {
>
>  #define ZQCR_PWRDOWN   (0x1 << 31) /* ZQ power down */

1U << 31

>
> -#define DATX_IOCR_DQ(x)(x) /* DQ0-7 IOCR index */
> -#define DATX_IOCR_DM   (8) /* DM IOCR index */
> -#define DATX_IOCR_DQS  (9) /* DQS IOCR index */
> -#define DATX_IOCR_DQSN (10)/* DQSN IOCR index */
> +#define ACBDLR_WRITE_DELAY(x)  ((x) << 8)

Better to have

#define ACBDLR_WRITE_DELAY_SHIFT 8
#define ACBDLR_WRITE_DELAY_MASK (0xff <<  ACBDLR_WRITE_DELAY_SHIFT)

and then use that in the code. Similarly with other accessors.

>
> -#define DATX_IOCR_WRITE_DELAY(x)   ((x) << 8)
> -#define DATX_IOCR_READ_DELAY(x)((x) << 0)
> +#define DXBDLR_DQ(x)   (x) /* DQ0-7 BDLR index */
> +#define DXBDLR_DM  (8) /* DM BDLR index */

Can we drop the unnecessary brackets around constants?

> +#define DXBDLR_DQS (9) /* DQS BDLR index */
> +#define DXBDLR_DQSN(10)/* DQSN BDLR index */
> +
> +#define DXBDLR_WRITE_DELAY(x)  ((x) << 8)
> +#define DXBDLR_READ_DELAY(x)   ((x) << 0)
>
>  #endif /* _SUNXI_DRAM_SUN8I_H3_H */
> diff --git a/arch/arm/mach-sunxi/dram_sun8i_h3.c 
> b/arch/arm/mach-sunxi/dram_sun8i_h3.c
> index b08b8e6..3dd6803 100644
> --- a/arch/arm/mach-sunxi/dram_sun8i_h3.c
> +++ b/arch/arm/mach-sunxi/dram_sun8i_h3.c
> @@ -72,21 +72,21 @@ static void mctl_dq_delay(u32 read, u32 write)
> u32 val;
>
> for (i = 0; i < 4; i++) {
> -   val = DATX_IOCR_WRITE_DELAY((write >> (i * 4)) & 0xf) |
> - DATX_IOCR_READ_DELAY(((read >> (i * 4)) & 0xf) * 2);
> + 

Re: [U-Boot] [PATCH v2 10/23] sunxi: introduce extra config option for boot0 header

[Simon Glass]

On 4 December 2016 at 18:52, Andre Przywara  wrote:
> The ENABLE_ARM_SOC_BOOT0_HOOK option is a generic option shared with
> other boards. To allow alternative code to be inserted, we create
> another, now function specific config symbol on top of it to simplify
> later additions. No functional change at this time.
>
> Signed-off-by: Andre Przywara 
> ---
>  board/sunxi/Kconfig   | 9 +
>  configs/pine64_plus_defconfig | 2 +-
>  2 files changed, 10 insertions(+), 1 deletion(-)
>

Reviewed-by: Simon Glass 

> diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
> index e1d4ab1..0cd57a2 100644
> --- a/board/sunxi/Kconfig
> +++ b/board/sunxi/Kconfig
> @@ -133,6 +133,15 @@ config MACH_SUN8I
> bool
> default y if MACH_SUN8I_A23 || MACH_SUN8I_A33 || MACH_SUN8I_H3 || 
> MACH_SUN8I_A83T
>
> +config RESERVE_ALLWINNER_BOOT0_HEADER

Would RESERVE_SUNXI_BOOT0_HEADER be better?

> +   bool "reserve space for Allwinner boot0 header"
> +   select ENABLE_ARM_SOC_BOOT0_HOOK
> +   ---help---
> +   Prepend a 1536 byte (empty) header to the U-Boot image file, to be
> +   filled with magic values post build. The Allwinner provided boot0
> +   blob relies on this information to load and execute U-Boot.
> +   Only needed on 64-bit Allwinner boards so far when using boot0.
> +
>  config DRAM_TYPE
> int "sunxi dram type"
> depends on MACH_SUN8I_A83T
> diff --git a/configs/pine64_plus_defconfig b/configs/pine64_plus_defconfig
> index 6d0198f..ea53b96 100644
> --- a/configs/pine64_plus_defconfig
> +++ b/configs/pine64_plus_defconfig
> @@ -1,5 +1,5 @@
>  CONFIG_ARM=y
> -CONFIG_ENABLE_ARM_SOC_BOOT0_HOOK=y
> +CONFIG_RESERVE_ALLWINNER_BOOT0_HEADER=y
>  CONFIG_ARCH_SUNXI=y
>  CONFIG_MACH_SUN50I=y
>  CONFIG_DRAM_CLK=672
> --
> 2.8.2
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 12/23] sunxi: provide default DRAM config for sun50i in Kconfig

[Simon Glass]

On 4 December 2016 at 18:52, Andre Przywara  wrote:
> To avoid enumerating the very same DRAM values in defconfig files
> for each and every Allwinner A64 board out there, let's put some sane
> default values in the Kconfig file.
> Boards with different needs can override them at any time.
>
> Signed-off-by: Andre Przywara 
> ---
>  board/sunxi/Kconfig   | 2 ++
>  configs/pine64_plus_defconfig | 2 --
>  2 files changed, 2 insertions(+), 2 deletions(-)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 05/23] move UL() macro from armv8/mmu.h into common.h

[Simon Glass]

Hi Andre,

On 4 December 2016 at 18:52, Andre Przywara  wrote:
> The UL() macro is pretty useful in sharing constants between assembly
> and C files while still being able to specify a type for C.
> Move the macro from an armv8 specific header into a common header file
> to be able to use it by arm code (for instance) as well.
>
> Signed-off-by: Andre Przywara 
> Reviewed-by: Alexander Graf 
> ---
>  arch/arm/include/asm/armv8/mmu.h |  8 
>  include/common.h | 10 +-
>  2 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm/include/asm/armv8/mmu.h 
> b/arch/arm/include/asm/armv8/mmu.h
> index aa0f3c4..e9b4cdb 100644
> --- a/arch/arm/include/asm/armv8/mmu.h
> +++ b/arch/arm/include/asm/armv8/mmu.h
> @@ -8,14 +8,6 @@
>  #ifndef _ASM_ARMV8_MMU_H_
>  #define _ASM_ARMV8_MMU_H_
>
> -#ifdef __ASSEMBLY__
> -#define _AC(X, Y)  X
> -#else
> -#define _AC(X, Y)  (X##Y)
> -#endif
> -
> -#define UL(x)  _AC(x, UL)
> -
>  /***/
>  /*
>   * The following definitions are related each other, shoud be
> diff --git a/include/common.h b/include/common.h
> index a8d833b..5fcd5f5 100644
> --- a/include/common.h
> +++ b/include/common.h
> @@ -15,6 +15,8 @@ typedef volatile unsigned longvu_long;
>  typedef volatile unsigned short vu_short;
>  typedef volatile unsigned char vu_char;
>
> +#define _AC(X, Y)   (X##Y)
> +
>  #include 
>  #include 
>  #include 
> @@ -936,7 +938,11 @@ int cpu_disable(int nr);
>  int cpu_release(int nr, int argc, char * const argv[]);
>  #endif
>
> -#endif /* __ASSEMBLY__ */
> +#else  /* __ASSEMBLY__ */
> +
> +#define _AC(X, Y)   X

Can you please comment what this macro is for?

> +
> +#endif /* __ASSEMBLY__ */
>
>  #ifdef CONFIG_PPC
>  /*
> @@ -948,6 +954,8 @@ int cpu_release(int nr, int argc, char * const argv[]);
>
>  /* Put only stuff here that the assembler can digest */
>
> +#define UL(x)   _AC(x, UL)
> +
>  #ifdef CONFIG_POST
>  #define CONFIG_HAS_POST
>  #ifndef CONFIG_POST_ALT_LIST
> --
> 2.8.2
>

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 07/23] armv8: add simple sdelay implementation

[Simon Glass]

Hi Andre,

On 4 December 2016 at 18:52, Andre Przywara  wrote:
> The sunxi DRAM setup code needs an sdelay() implementation, which
> wasn't defined for armv8 so far.
> Shamelessly copy the armv7 version and adjust it to work in AArch64.
>
> Signed-off-by: Andre Przywara 
> ---
>  arch/arm/cpu/armv8/cpu.c | 13 +
>  1 file changed, 13 insertions(+)
>
> diff --git a/arch/arm/cpu/armv8/cpu.c b/arch/arm/cpu/armv8/cpu.c
> index e06c3cc..0366ff4 100644
> --- a/arch/arm/cpu/armv8/cpu.c
> +++ b/arch/arm/cpu/armv8/cpu.c
> @@ -16,6 +16,19 @@
>  #include 
>  #include 
>
> +/

Can we drop the extra stars and use the normal function comment style?

> + * sdelay() - simple spin loop.  Will be constant time as
> + *  its generally used in bypass conditions only.  This
> + *  is necessary until timers are accessible.
> + *
> + *  not inline to increase chances its in cache when called

Should mention the meaning of the parameter and that it cannot be called with 0.

> + */
> +void sdelay(unsigned long loops)
> +{
> +   __asm__ volatile ("1:\n" "subs %0, %0, #1\n"
> + "b.ne 1b" : "=r" (loops) : "0"(loops) : "cc");
> +}
> +
>  int cleanup_before_linux(void)
>  {
> /*
> --
> 2.8.2
>

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 06/23] SPL: make struct spl_image 64-bit safe

[Simon Glass]

On 4 December 2016 at 18:52, Andre Przywara  wrote:
> Since entry_point and load_addr are addresses, they should be
> represented as longs to cover the whole address space and to avoid
> warning when compiling the SPL in 64-bit.
> Also adjust debug prints to add the 'l' specifier, where needed.
>
> Signed-off-by: Andre Przywara 
> Reviewed-by: Alexander Graf 
> ---
>  arch/arm/mach-omap2/boot-common.c | 2 +-
>  arch/arm/mach-tegra/spl.c | 2 +-
>  common/spl/spl.c  | 8 
>  common/spl/spl_mmc.c  | 2 +-
>  include/spl.h | 4 ++--
>  5 files changed, 9 insertions(+), 9 deletions(-)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 11/23] sunxi: A64: do an RMR switch if started in AArch32 mode

[Simon Glass]

Hi Andre,

On 4 December 2016 at 18:52, Andre Przywara  wrote:
> The Allwinner A64 SoC starts execution in AArch32 mode, and both
> the boot ROM and Allwinner's boot0 keep running in this mode.
> So U-Boot gets entered in 32-bit, although we want it to run in AArch64.
>
> By using a "magic" instruction, which happens to be an almost-NOP in
> AArch64 and a branch in AArch32, we differentiate between being
> entered in 64-bit or 32-bit mode.
> If in 64-bit mode, we proceed with the branch to reset, but in 32-bit
> mode we trigger an RMR write to bring the core into AArch64/EL3 and
> re-enter U-Boot at CONFIG_SYS_TEXT_BASE.
> This allows a 64-bit U-Boot to be both entered in 32 and 64-bit mode,
> so we can use the same start code for the SPL and the U-Boot proper.
>
> We use the existing custom header (boot0.h) functionality, but restrict
> the existing boot0 header reservation to the non-SPL build now. A SPL
> wouldn't need such header anyway. This allows to have both options
> defined and lets us use one for the SPL and the other for U-Boot proper.
>
> Signed-off-by: Andre Przywara 
> ---
>  arch/arm/include/asm/arch-sunxi/boot0.h | 27 +++
>  board/sunxi/Kconfig |  5 +
>  2 files changed, 32 insertions(+)

Reviewed-by: Simon Glass 

>
> diff --git a/arch/arm/include/asm/arch-sunxi/boot0.h 
> b/arch/arm/include/asm/arch-sunxi/boot0.h
> index 6a13db5..7799a03 100644
> --- a/arch/arm/include/asm/arch-sunxi/boot0.h
> +++ b/arch/arm/include/asm/arch-sunxi/boot0.h
> @@ -4,6 +4,33 @@
>   * SPDX-License-Identifier:GPL-2.0+
>   */
>
> +#if defined(CONFIG_RESERVE_ALLWINNER_BOOT0_HEADER) && 
> !defined(CONFIG_SPL_BUILD)
>  /* reserve space for BOOT0 header information */
> b   reset
> .space  1532
> +#elif defined(CONFIG_ARM_BOOT_HOOK_RMR)
> +/* switch into AArch64 if needed */
> +   tst x0, x0  // this is "b #0x84" in ARM
> +   b   reset
> +   .space  0x7c
> +   .word   0xe59f1024  // ldr r1, [pc, #36] ; 0x17a0
> +   .word   0xe59f0024  // ldr r0, [pc, #36] ; CONFIG_*_TEXT_BASE
> +   .word   0xe581  // str r0, [r1]
> +   .word   0xf57ff04f  // dsb sy
> +   .word   0xf57ff06f  // isb sy
> +   .word   0xee1c0f50  // mrc 15, 0, r0, cr12, cr0, {2} ; RMR
> +   .word   0xe383  // orr r0, r0, #3
> +   .word   0xee0c0f50  // mcr 15, 0, r0, cr12, cr0, {2} ; RMR
> +   .word   0xf57ff06f  // isb sy
> +   .word   0xe320f003  // wfi
> +   .word   0xeafd  // b   @wfi
> +   .word   0x017000a0  // writeable RVBAR mapping address

How come you cannot use the assembler here?

> +#ifdef CONFIG_SPL_BUILD
> +   .word   CONFIG_SPL_TEXT_BASE
> +#else
> +   .word   CONFIG_SYS_TEXT_BASE
> +#endif
> +#else
> +/* normal execution */
> +   b   reset
> +#endif
> diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
> index 0cd57a2..ba72e76 100644
> --- a/board/sunxi/Kconfig
> +++ b/board/sunxi/Kconfig
> @@ -142,6 +142,11 @@ config RESERVE_ALLWINNER_BOOT0_HEADER
> blob relies on this information to load and execute U-Boot.
> Only needed on 64-bit Allwinner boards so far when using boot0.
>
> +config ARM_BOOT_HOOK_RMR
> +   bool
> +   default y if ARM64
> +   select ENABLE_ARM_SOC_BOOT0_HOOK

help?

> +
>  config DRAM_TYPE
> int "sunxi dram type"
> depends on MACH_SUN8I_A83T
> --
> 2.8.2
>

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/6] arm64: mvebu: pinctrl: Add pin control driver for A8K family

[Simon Glass]

Hi Kostya,

On 4 December 2016 at 09:12,   wrote:
> From: Konstantin Porotchkin 
>
> Add a DM port of Marvell pin control driver.
> The A8K SoC family contains several silicone dies interconnected
> in a single package. Every die is normally equipped with its own
> pin controller unit.
> There are 2 pin controllers in A70x0 SoC and 3 in A80x0 SoC.
>
> Changes for v2:
> - Fix the code following Simon's review
> - Code syntax fixes
> - MPP functions documentation for CP110 and APN806
>
> Signed-off-by: Konstantin Porotchkin 
> Cc: Simon Glass 
> Cc: Stefan Roese 
> Cc: Nadav Haklai 
> Cc: Neta Zur Hershkovits 
> Cc: Omri Itach 
> Cc: Igal Liberman 
> Cc: Haim Boot 
> Cc: Hanna Hawa 
> ---
>  arch/arm/include/asm/arch-armada8k/soc-info.h  |  17 ++
>  .../pinctrl/marvell,armada-apn806-pinctrl.txt  |  25 ++
>  .../pinctrl/marvell,armada-cp110-pinctrl.txt   | 270 
> +
>  .../pinctrl/marvell,mvebu-pinctrl.txt  | 113 +
>  drivers/pinctrl/Kconfig|   1 +
>  drivers/pinctrl/Makefile   |   1 +
>  drivers/pinctrl/mvebu/Kconfig  |   7 +
>  drivers/pinctrl/mvebu/Makefile |   7 +
>  drivers/pinctrl/mvebu/pinctrl-mvebu.c  | 179 ++
>  drivers/pinctrl/mvebu/pinctrl-mvebu.h  |  31 +++
>  10 files changed, 651 insertions(+)
>  create mode 100644 arch/arm/include/asm/arch-armada8k/soc-info.h
>  create mode 100644 
> doc/device-tree-bindings/pinctrl/marvell,armada-apn806-pinctrl.txt
>  create mode 100644 
> doc/device-tree-bindings/pinctrl/marvell,armada-cp110-pinctrl.txt
>  create mode 100644 doc/device-tree-bindings/pinctrl/marvell,mvebu-pinctrl.txt
>  create mode 100644 drivers/pinctrl/mvebu/Kconfig
>  create mode 100644 drivers/pinctrl/mvebu/Makefile
>  create mode 100644 drivers/pinctrl/mvebu/pinctrl-mvebu.c
>  create mode 100644 drivers/pinctrl/mvebu/pinctrl-mvebu.h

Reviewed-by: Simon Glass 

It would be good to have a bit more detail in the Kconfig help about
what the hardware supports, and what your drive supports

- Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 04/23] SPL: tiny-printf: add "l" modifier

[Simon Glass]

On 4 December 2016 at 18:52, Andre Przywara  wrote:
> tiny-printf does not know about the "l" modifier so far, which breaks
> the crash dump on AArch64, because it uses %lx to print the registers.
> Add an easy way of handling longs correctly. Also there are printfs
> using the '-' modifier, which we choose to ignore for simplicity.
>
> Using a relatively decent compiler (GCC 5.3.0) this does _not_ increase
> the code size of tiny-printf.o for 32-bit builds (where long and int
> are actually the same), actually it looses three (ARM Thumb2) instructions
> from the actual SPL (numbers for orangepi_plus_defconfig):
>   textdata bss dec hex filename
>758   0   0 758 2f6 spl/lib/tiny-printf.obefore
>  18839 488 232   195594c67 spl/u-boot-spl   before
>758   0   0 758 2f6 spl/lib/tiny-printf.oafter
>  18833 488 232   195534c61 spl/u-boot-spl   after
>
> This adds some substantial amount of code to a 64-bit build, though:
> (taken after a later commit, which enables the ARM64 SPL build for sunxi)
>   textdata bss dec hex filename
>   1542   0   01542 606 spl/lib/tiny-printf.obefore
>  25830 392 360   2658267d6 spl/u-boot-spl   before
>   1758   0   01758 6de spl/lib/tiny-printf.oafter
>  26040 392 360   2679268a8 spl/u-boot-spl   after
>
> Signed-off-by: Andre Przywara 
> ---
>  lib/tiny-printf.c | 50 +++---
>  1 file changed, 39 insertions(+), 11 deletions(-)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 02/23] armv8: prevent using THUMB

[Simon Glass]

On 4 December 2016 at 18:52, Andre Przywara  wrote:
> The predominantely 32-bit ARM targets try to compile the SPL in Thumb
> mode to reduce code size.
> The 64-bit AArch64 instruction set does not know an alternative, concise
> encoding, so the Thumb build option should only be set for 32-bit
> targets.
> Likewise -marm machine options are only valid for ARMv7 targets.
>
> Signed-off-by: Andre Przywara 
> Reviewed-by: Alexander Graf 
> ---
>  arch/arm/lib/Makefile  | 2 ++
>  include/configs/sunxi-common.h | 2 +-
>  2 files changed, 3 insertions(+), 1 deletion(-)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 01/23] sun6i: Restrict some register initialization to Allwinner A31 SoC

[Simon Glass]

On 4 December 2016 at 18:52, Andre Przywara  wrote:
> These days many Allwinner SoCs use clock_sun6i.c, although out of them
> only the (original sun6i) A31 has a second MBUS clock register.
> Also the requirement for setting up the PRCM PLL_CTLR1 register to provide
> the proper voltage seems to be a property of older SoCs only as well.
>
> Restrict the MBUS initialization to this SoC only to avoid writing bogus
> values to (undefined) registers in other chips.
> I can only verify that the PLL voltage setup is not needed for H3 and
> A64, so for now we only spare those two SoCs.
>
> Signed-off-by: Andre Przywara 
> Reviewed-by: Alexander Graf 
> Reviewed-by: Chen-Yu Tsai 
> ---
>  arch/arm/mach-sunxi/clock_sun6i.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: tegra: allow passing cboot DTB to the kernel

[Simon Glass]

On 2 December 2016 at 12:26, Stephen Warren  wrote:
> From: Stephen Warren 
>
> Some users may wish to pass the cboot-supplied DTB to the booted kernel
> rather than having U-Boot load the DTB itself. To allow this, expose the
> address of the cboot-supplied DTB in environment variable $fdt_addr. At
> least when using extlinux.conf, if the user doesn't explicitly specify
> which DTB to pass to the kernel, U-Boot passes the DTB referred to by
> this variable.
>
> Signed-off-by: Stephen Warren 
> ---
>  arch/arm/mach-tegra/tegra186/nvtboot_board.c | 18 ++
>  1 file changed, 18 insertions(+)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v5 10/13] tegra: Use a U-Boot-specific .dtsi file

[Simon Glass]

Hi Stephen,

On 2 December 2016 at 12:19, Stephen Warren  wrote:
> On 11/30/2016 07:19 PM, Simon Glass wrote:
>>
>> Hi Stephen,
>>
>> On 29 November 2016 at 21:09, Stephen Warren 
>> wrote:
>>>
>>> On 11/28/2016 03:09 PM, Simon Glass wrote:


 Hi Stephen,

 On 17 November 2016 at 12:45, Stephen Warren 
 wrote:
>
>
>
> On 11/16/2016 06:13 PM, Simon Glass wrote:
>>
>>
>>
>> With the new device-tree rules it is possible to put device-tree
>> changes
>> needed by U-Boot into their own file. As an example of this approach,
>> move
>> Tegra over to use it.
>
>
>
>
> Sounds like a good idea.
>
>> diff --git a/arch/arm/dts/tegra20-u-boot.dtsi
>> b/arch/arm/dts/tegra20-u-boot.dtsi
>>>
>>>
>>>
> I'd expect to see more "U-Boot overlay" DTs than this; I recall there
> being more differences between U-Boot and kernel DTS files when I last
> sync'd the two.



 Yes but most of those changes should be dropped. I did a partial sync
 a few months back but if you recall there were still differences. Is
 this something the Tegra maintainer might look at?

 I don't want to immortalise those differences in a separate U-Boot
 file when really we should just get rid of them.
>>>
>>>
>>>
>>> From my perspective, we should have two files:
>>>
>>> 1) The base DT.
>>>
>>> This should not contain any U-Boot modifications, and should exactly
>>> match
>>> the DT used elsewhere, such as in mainline Linux. Since this should
>>> always
>>> match other DTs, we should pretty much always be able to over-write it
>>> with
>>> any updated DT from other sources.
>>>
>>> 2) The U-Boot modifications.
>>>
>>> This always contain /all/ local modifications applied by U-Boot. It
>>> shouldn't matter why the change was made, or how long we hope/expect the
>>> delta to continue to exist. This will isolate all U-Boot changes into
>>> this
>>> file so it's obvious what local changes exist. If some changes are
>>> intended
>>> to be temporary, we can add a comment to that effect, and eventually
>>> submit
>>> a patch to remove the delta.
>>>
>>> I don't think that putting a change into this "U-Boot local overlay"
>>> should
>>> in any way imply that the change is by definition correct and long-term;
>>> some changes may satisfy that decription and others won't. Just like we
>>> sometimes have C code that we wish we didn't and eventually clean up.
>>
>>
>> That's fine with me. What do you want to do with this patch?
>
>
> IIRC the patch content is fine as far as it goes, but it'd be nice to take
> it all the way and move all the U-Boot diffs into
> arch/arm/dts/tegra20-u-boot.dtsi if possible.

OK, can you please add a review or test tag?

I will see if I can take a look in January. Is there any chance that
Nvidia might put some effort into this?

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 1/1] cmd: pci: add option to parse and display BAR information

[Simon Glass]

On 1 December 2016 at 08:14,   wrote:
> From: Yehuda Yitschak 
>
> Currently the PCI command only allows to see the BAR register
> values but not the size and actual base address.
> This little extension parses the BAR registers and displays
> the base, size and type of each BAR.
>
> Signed-off-by: Yehuda Yitschak 
> ---
>  cmd/pci.c | 83 
> +++
>  1 file changed, 83 insertions(+)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 2/2] splash: add support for loading splash from a FIT image

[Simon Glass]

Hi Tomas,

On 1 December 2016 at 05:21, Tomas Melin  wrote:
> Enable support for loading a splash image from within a FIT image.
> The image is assumed to be generated with mkimage -E flag to hold
> the data external to the FIT.
>
> Signed-off-by: Tomas Melin 
> ---
>  common/image-fit.c   | 48 
>  common/splash_source.c   | 71 
> 
>  doc/README.splashprepare | 15 ++
>  include/image.h  |  4 +++
>  include/splash.h |  5 ++--
>  5 files changed, 136 insertions(+), 7 deletions(-)

Can you please resend this with a change log?

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3] spi: Add error checking for invalid bus widths

[Simon Glass]

Hi Jagan,

On 1 December 2016 at 05:45, Jagan Teki  wrote:
> On Wed, Nov 30, 2016 at 8:30 AM, Simon Glass  wrote:
>> At present an invalid bus width prints a message but does not return an
>> error. This is the opposite of the correct behaviour. Adjust it to avoid
>> code bloat in the common case, and avoid hard-to-debug failure in the
>> uncommon case.
>>
>> Signed-off-by: Simon Glass 
>> ---
>>
>> Changes in v3:
>> - Display an error in U-Boot proper, but then continue
>> - Drop patches previously applied
>>
>>  drivers/spi/spi-uclass.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c
>> index f59a701..1ab5b75 100644
>> --- a/drivers/spi/spi-uclass.c
>> +++ b/drivers/spi/spi-uclass.c
>> @@ -418,7 +418,7 @@ int spi_slave_ofdata_to_platdata(const void *blob, int 
>> node,
>> mode |= SPI_TX_QUAD;
>> break;
>> default:
>> -   error("spi-tx-bus-width %d not supported\n", value);
>> +   warn_non_spl("spi-tx-bus-width %d not supported\n", value);
>
> I thought in SPL it will reverse like debug and return by error, make sense?

Sorry I don't understand this comment. The intent here is to:

- do nothing in SPL
- warn in U-Boot proper with printf()

Are you saying that it should use debug() in SPL?

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 1/2] splash: sort include files

[Simon Glass]

On 1 December 2016 at 05:21, Tomas Melin  wrote:
> Sort include files in accordance to u-boot coding style.
>
> Signed-off-by: Tomas Melin 
> ---
>  common/splash_source.c | 13 +++--
>  1 file changed, 7 insertions(+), 6 deletions(-)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 12/14] fdt: eth_fixup: Add hook for board to override MAC

[Simon Glass]

Hi Oliver,

On 2 December 2016 at 03:16, Olliver Schinagl  wrote:
> Hey Joe,
>
>
>
> On 30-11-16 21:40, Joe Hershberger wrote:
>>
>> On Fri, Nov 25, 2016 at 9:30 AM, Olliver Schinagl 
>> wrote:
>>>
>>> This patch adds a method for the board to set the MAC address if the
>>> environment is not yet set. The environment based MAC addresses are not
>>> touched, but if the fdt has an alias set, it is parsed and put into the
>>> environment.
>>>
>>> E.g. The environment contains ethaddr and eth1addr, and the fdt contains
>>> an ethernet1 nothing happens. If the fdt contains ethernet2 however, it
>>> is parsed and inserted into the environment as eth2addr.
>>>
>>> Signed-off-by: Olliver Schinagl 
>>> ---
>>>   common/fdt_support.c | 8 +++-
>>>   1 file changed, 7 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/common/fdt_support.c b/common/fdt_support.c
>>> index c34a13c..f127392 100644
>>> --- a/common/fdt_support.c
>>> +++ b/common/fdt_support.c
>>> @@ -465,6 +465,11 @@ int fdt_fixup_memory(void *blob, u64 start, u64
>>> size)
>>>  return fdt_fixup_memory_banks(blob, , , 1);
>>>   }
>>>
>>> +__weak int board_get_enetaddr(const int i, unsigned char *mac_addr)
>>
>> Ugh. This collides with a function in board/v38b/ethaddr.c and in
>> board/intercontrol/digsy_mtc/digsy_mtc.c
>>
>> Also, it's so generic, and only gets called by the fdt fixup stuff...
>> This function should probably be named in such a way that its
>> association with fdt is clear.
>
> I did not notice that, sorry! But naming suggestions are welcome :)
>
> Right now, I use it in two unrelated spots however.
>
> from the fdt as seen above and in a subclass driver (which will come up for
> review) as suggested by Simon.
>
> There I do:
>
> +static int sunxi_gmac_eth_read_rom_hwaddr(struct udevice *dev)
> +{
> +   struct eth_pdata *pdata = dev_get_platdata(dev);
> +
> +   return board_get_enetaddr(dev->seq, pdata->enetaddr);
> +}
> +
>  const struct eth_ops sunxi_gmac_eth_ops = {
> .start  = designware_eth_start,
> .send   = designware_eth_send,
> @@ -102,6 +110,7 @@ const struct eth_ops sunxi_gmac_eth_ops = {
> .free_pkt   = designware_eth_free_pkt,
> .stop   = designware_eth_stop,
> .write_hwaddr   = designware_eth_write_hwaddr,
> +   .read_rom_hwaddr= sunxi_gmac_eth_read_rom_hwaddr,
>  };
>
> which is completly unrelated to the fdt.
>
> So naming suggestion or overal suggestion how to handle this nice and
> generically?
>
> Based from the name however I would think that all board_get_enetaddr's work
> the same however so should have been interchangeable? Or was that silly
> thinking?

Would it be possible to use a name without 'board' in it? I think this
/ hope is actually sunxi-specific code, not board-specific?

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] About U-boot's TPM

[Simon Glass]

Hi Ronny,

On 1 December 2016 at 04:53, Ronny Ko  wrote:
> Hi Simon,
>
> I received the following reply from Minnowboard enginer from intel:
>
>> fTPM is implemented in firmware. Firmware will capture IO transition and
>> show same behavior like dTPM. From user point of view, fTPM is transparent,
>> you can use it like dTPM. You can’t access fTPM code space as it is
>> protected by hardware. Please use it according to TCG spec.
>
>
> So it seems that firmware TPM in UEFI is identical with discrete TPM,
> software-wise. But I wouldn't be able to use it with U-boot, anyway, because
> it's TPM 2.0 standard...

Well it would be possible to add TPM 2 support for U-Boot - it will
need to be done at some point anyway. You can look at the chromium
project for open source TPM2 code, for example.

So it sounds like you need to load a binary blob into memory somewhere
for the fTPM? Is this handled by the Intel Management Engine? If so
then I suppose it should work with some addressing changes in U-Boot.

Regards,
Simon


>
> Ronny
>
> On Thu, Dec 1, 2016 at 12:50 AM, Ronny Ko  wrote:
>>
>> Hi Simon,
>>
>> fTPM is firmware TPM (virtual TPM), and dTPM is discrete TPM (hardware
>> TPM). The intel engineer said fTPM and discrete TPM 1.2 are identical from
>> the OS developer's viewpoint.
>>
>> I try to build an IoT hypervisor, and for this I've been looking for a
>> board that supports x64, TPM 1.2 and U-boot. But there seems to be none
>> which qualifies all these three categories...
>>
>> Ronny
>>
>> On Thu, Dec 1, 2016 at 12:20 AM, Simon Glass  wrote:
>>>
>>> Hi Ronny,
>>>
>>> What is ftpm and dtpm?
>>>
>>> No U-Boot does not support TPM 2.0 yet. Are you thinking of running
>>> U-Boot from UEFI, and having U-Boot access UEFI's virtual TPM?
>>>
>>> Regards,
>>> SImon
>>>
>>> On 30 November 2016 at 13:55, Ronny Ko  wrote:
>>> > Hi Simon,
>>> >
>>> > I checked with the Minnowboard management team in intel, and they say
>>> > fTPM
>>> > is implemented in the UEFI firmware, which is simply a virtual version
>>> > of
>>> > dTPM. I think this is why TPM is not in the datasheet of the target
>>> > CPU.
>>> > They also said the way of using an fTPM should be the same as dTPM.
>>> >
>>> > But fTPM is based on TPM 2.0 standard (not TPM 1.2). Does U-boot
>>> > support TPM
>>> > 2.0 in its library? If so, I think Minnowboard's fTPM could be accessed
>>> > and
>>> > seamlessly utilized via U-boot's TPM library calls.
>>> >
>>> > Ronny
>>> >
>>> >
>>> >
>>> > On Wed, Nov 30, 2016 at 12:40 AM, Simon Glass  wrote:
>>> >>
>>> >> Hi Ronny,
>>> >>
>>> >> On 27 November 2016 at 10:47, Ronny Ko  wrote:
>>> >> > Hi Simon,
>>> >> >
>>> >> > I'm using Minnowboard MAX. It has fTPM, which is an integrated TPM
>>> >> > into
>>> >> > SoC
>>> >> > (Bay Trail).
>>> >> >
>>> >> > http://wiki.minnowboard.org/MinnowBoard_MAX
>>> >> >
>>> >> >
>>> >> > https://firmware.intel.com/blog/security-technologies-and-minnowboard-max
>>> >> >
>>> >> >
>>> >> > https://prosauce.org/blog/2016/1/11/minnowboard-max-enable-and-test-the-firmware-txe-tpm-20
>>> >>
>>> >> I don't see any info in the datasheet here:
>>> >>
>>> >>
>>> >>
>>> >> http://www.intel.com/content/www/us/en/embedded/products/bay-trail/atom-e3800-family-datasheet.html
>>> >>
>>> >> Do you know where it is documented?
>>> >>
>>> >> Regards,
>>> >> SImon
>>> >>
>>> >> >
>>> >> > Ronny
>>> >> >
>>> >> > On Sun, Nov 27, 2016 at 7:02 PM, Simon Glass 
>>> >> > wrote:
>>> >> >>
>>> >> >> Hi Ronny,
>>> >> >>
>>> >> >> On 24 November 2016 at 14:20, Ronny Ko  wrote:
>>> >> >> > Hi Simon,
>>> >> >> >
>>> >> >> > I have a question about using a TPM from U-Boot. I try to run
>>> >> >> > U-Boot
>>> >> >> > on
>>> >> >> > Minnowboard MAX, which has a firmware TPM (fTPM), instead of
>>> >> >> > discrete
>>> >> >> > TPM
>>> >> >> > (dTPM). I wonder if the way of using fTPM from U-Boot is the same
>>> >> >> > as
>>> >> >> > using
>>> >> >> > dTPM. I suppose the answer is yes, if an fTPM is simply a virtual
>>> >> >> > version of
>>> >> >> > dTPM. Or is it not so?
>>> >> >>
>>> >> >> I don't know how that is connected. Do you have any documentation?
>>> >> >>
>>> >> >> Regards,
>>> >> >> Simon
>>> >> >
>>> >> >
>>> >
>>> >
>>
>>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] uefi: x86: uboot as uefi payload

[Simon Glass]

Hi Markus,

On 1 December 2016 at 01:58, Markus Valentin  wrote:
> Hi Simon,
> Am Mittwoch, den 30.11.2016, 19:20 -0700 schrieb Simon Glass:
>> Hi Markus,
>>
>> On 30 November 2016 at 04:32, Markus Valentin  wrote:
>> >
>> > Hi,
>> >
>> > im trying to run u-boot as uefi-payload for qemu this works totally
>> > fine.
>> >
>> > My real target is a Minnowboard Turbot. I did use the
>> > minnowmax_defconfig enabled CONFIG_EFI, CONFIG_EFI_STUB and
>> > CONFIG_EFI_STUB_64BIT. The Board has the latest uefi by Intel
>> > installed(0.93, X64).
>> >
>> > When i load U-Boot as payload for the board-uefi the efi_main
>> > function
>> > gets executed but the call to "cpu_call32" seems to get stuck ( i
>> > think
>> > its at the "retf" arch/x86/cpu/call32.S:37).
>> >
>> > Debuglog:
>> >
>> > Shell> u-boot-payload_64.efi
>> > U-Boot EFI Payload
>> > gdt: 0047, addr: 784fd570
>> > 00:   
>> > 08: 00cf9200  
>> > 10: 00af9a00  
>> > 18: 00cf9300  
>> > 20: 00cf9a00  
>> > 28:   
>> > 30: 00cf9200  
>> > 38: 00af9b00  
>> > 40:   
>> >  32-bit code segment: 20
>> >  page_table: 79313000
>> >  EFI table at 78787018 size 0760
>> >
>> > Does anyone have experiences with this issue or with running u-boot
>> > as
>> > uefi-64 payload at all?
>>
>> I have used this on the original Minnowboard and it is used on some
>> broadwell platforms.
> Great so i should be able to get it working too.
>>
>> I did hit a similar problem due to the 'ret' not generating the right
>> instruction. I thought it was fixed but I suppose it is not
>> impossible
>> that the gcc toolchains might generate different op codes in
>> different
>> situations.
>>
>> Which toolchain are you using?
> Im using the gcc6 from Debian/testing,(6.2.0-13) and glibc6 2.24-5.
>
> Can you suggest a Toolchain? Mine is probably too "current"?

I was using 4.9.0 now but I'm not sure if that is what I tested with.
I'll try it again when I get a chance, but it will be a week or so as
I am travelling.

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v1] dm: spl: mmc: Fix EXT SPL support

[Simon Glass]

On 1 December 2016 at 03:23, Jaehoon Chung  wrote:
> On 12/01/2016 07:09 PM, Michal Simek wrote:
>> The patch
>> "dm: spl: mmc: Support CONFIG_BLK in SPL MMC"
>> (sha1: 87bce4e5c0b55452d70830928b2d7b98fa24d4e3)
>> converted FAT part of spl_mmc_do_fs_boot() but forget to update also EXT
>> part by 's/>block_dev/mmc_get_blk_desc(mmc)/'.
>> This patch is fixing compilation error when CONFIG_SPL_EXT_SUPPORT
>> is enabled.
>>
>> Signed-off-by: Michal Simek 
>
> Reviewed-by: Jaehoon Chung 

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 4/5] mmc: tegra: allow disabling external clock loopback

[Simon Glass]

On 1 December 2016 at 00:40, Marcel Ziswiler  wrote:
>
>
> On December 1, 2016 3:20:55 AM GMT+01:00, Simon Glass  
> wrote:
>>Hi Marcel,
>>
>>On 30 November 2016 at 09:47, Marcel Ziswiler 
>>wrote:
>>> From: Marcel Ziswiler 
>>>
>>> Introduce CONFIG_TEGRA124_MMC_DISABLE_EXT_LOOPBACK to disable the
>>external clock
>>> loopback and use the internal one on SDMMC3 as per the
>>SDMMC_VENDOR_MISC_CNTRL_0
>>> register's SDMMC_SPARE1 bits being set to 0xfffd according to the
>>TRM.
>>>
>>> Signed-off-by: Marcel Ziswiler 
>>> ---
>>>
>>>  arch/arm/include/asm/arch-tegra/tegra_mmc.h |  2 ++
>>>  drivers/mmc/Kconfig |  8 
>>>  drivers/mmc/tegra_mmc.c | 13 +
>>>  3 files changed, 23 insertions(+)
>>
>>This should be controlled by the device tree, shouldn't it?
>
> Glad you brought it up. So far NVIDIA hasn't even acknowledged that they 
> completely seriously screwed this one up big time. Unlike their PCIe bug I 
> reported which eventually did make it to the errata... Anyway, my hopes were 
> kind of to sneak this one into U-Boot first, then work on a proper kernel 
> integration probably involving device tree integration and only in a later 
> third step maybe updating this in U-Boot again.

OK, please can you add a TODO(email) in there so it is clear this is temporary?

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 06/17] dm: Add callback to modify the device tree

[Simon Glass]

Hi,

On 1 December 2016 at 01:39, Stefan Roese  wrote:
> (Adding Simon and Maxim to Cc)
>
> On 23.11.2016 16:12, Mario Six wrote:
>>
>> Certain boards come in different variations by way of utilizing daughter
>> boards, for example. These boards might contain additional chips, which
>> are added to the main board's busses, e.g. I2C.
>>
>> The device tree support for such boards would either, quite naturally,
>> employ the overlay mechanism to add such chips to the tree, or would use
>> one large default device tree, and delete the devices that are actually
>> not present.
>>
>> Regardless of approach, even on the U-Boot level, a modification of the
>> device tree is a prerequisite to have such modular families of boards
>> supported properly.
>>
>> Therefore, we add an option to make the U-Boot device tree (the actual
>> copy later used by the driver model) writeable, and add a callback
>> method that allows boards to modify the device tree at an early stage,
>> at which, hopefully, also the application of device tree overlays will
>> be possible.
>>
>> Signed-off-by: Mario Six 
>
>
> I didn't follow DT overlay lately closely especially not in U-Boot.
> Simon, Maxim could you please take a look at this patch and comment
> on its necessity?
>
>
>> ---
>>  common/board_f.c  |  3 +++
>>  dts/Kconfig   | 10 ++
>>  include/asm-generic/global_data.h |  4 
>>  include/common.h  |  1 +
>>  4 files changed, 18 insertions(+)
>>
>> diff --git a/common/board_f.c b/common/board_f.c
>> index 4b74835..cda5aae 100644
>> --- a/common/board_f.c
>> +++ b/common/board_f.c
>> @@ -1034,6 +1034,9 @@ static init_fnc_t init_sequence_f[] = {
>>  #ifdef CONFIG_SYS_EXTBDINFO
>> setup_board_extra,
>>  #endif
>> +#ifdef CONFIG_OF_BOARD_FIXUP
>> +   board_fix_fdt,
>> +#endif

Can you add documentation for this somewhere? E.g. in the driver model readme?

>> INIT_FUNC_WATCHDOG_RESET
>> reloc_fdt,
>> setup_reloc,
>> diff --git a/dts/Kconfig b/dts/Kconfig
>> index 4b7d8b1..3f64eda 100644
>> --- a/dts/Kconfig
>> +++ b/dts/Kconfig
>> @@ -14,6 +14,16 @@ config OF_CONTROL
>>   This feature provides for run-time configuration of U-Boot
>>   via a flattened device tree.
>>
>> +config OF_BOARD_FIXUP
>> +   bool "Board-specific manipulation of Device Tree"
>> +   help
>> + In certain circumstances it is necessary to be able to modify
>> + U-Boot's device tree (e.g. to delete device from it). This
>> option
>> + make the Device Tree writeable and provides a board-specific
>> + "board_fix_fdt" callback (called during pre-relocation time),
>> which
>> + enables the board initialization to modifiy the Device Tree. The
>> + modified copy is subsequently used by U-Boot after relocation.
>> +
>>  config SPL_OF_CONTROL
>> bool "Enable run-time configuration via Device Tree in SPL"
>> depends on SPL && OF_CONTROL
>> diff --git a/include/asm-generic/global_data.h
>> b/include/asm-generic/global_data.h
>> index e02863d..f566186 100644
>> --- a/include/asm-generic/global_data.h
>> +++ b/include/asm-generic/global_data.h
>> @@ -69,7 +69,11 @@ typedef struct global_data {
>> struct udevice  *timer; /* Timer instance for Driver Model
>> */
>>  #endif
>>
>> +#ifdef CONFIG_OF_BOARD_FIXUP
>> +   void *fdt_blob; /* Our device tree, NULL if none
>> */
>> +#else
>> const void *fdt_blob;   /* Our device tree, NULL if none
>> */
>> +#endif

Can we keep it as const and just use a cast when it needs to change?
You could add a function which returns a writable pointer.


>> void *new_fdt;  /* Relocated FDT */
>> unsigned long fdt_size; /* Space reserved for relocated
>> FDT */
>> struct jt_funcs *jt;/* jump table */
>> diff --git a/include/common.h b/include/common.h
>> index a8d833b..293ce23 100644
>> --- a/include/common.h
>> +++ b/include/common.h
>> @@ -502,6 +502,7 @@ extern ssize_t spi_write (uchar *, int, uchar *, int);
>>
>>  /* $(BOARD)/$(BOARD).c */
>>  int board_early_init_f (void);
>> +int board_fix_fdt (void);

Comment please. Perhaps it should pass a writable fdt pointer?

>>  int board_late_init (void);
>>  int board_postclk_init (void); /* after clocks/timebase, before
>> env/serial */
>>  int board_early_init_r (void);

There have been discussions about moving to a live tree (hierarchical
format) in U-Boot post-relocation. What do you think? It might make
these changes easier or more efficient.

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 07/17] lib: tpm: Add command to flush resources

[Simon Glass]

On 1 December 2016 at 01:42, Stefan Roese  wrote:
> (Adding Simon to Cc)
>
> On 23.11.2016 16:12, Mario Six wrote:
>>
>> This patch adds a function to the TPM library, which allows U-Boot to
>> flush resources, e.g. keys, from the TPM.
>>
>> Signed-off-by: Mario Six 
>
>
> Simon, do you have any comments on this patch please?

Reviewed-by: Simon Glass 

Is it possible to add a new tpm subcommand for this?

>
>
>> ---
>>  board/gdsys/p1022/controlcenterd-id.c |  9 ---
>>  include/tpm.h | 45
>> +++
>>  lib/tpm.c | 28 ++
>>  3 files changed, 73 insertions(+), 9 deletions(-)
>>
>> diff --git a/board/gdsys/p1022/controlcenterd-id.c
>> b/board/gdsys/p1022/controlcenterd-id.c
>> index 2c6c698..1648f13 100644
>> --- a/board/gdsys/p1022/controlcenterd-id.c
>> +++ b/board/gdsys/p1022/controlcenterd-id.c
>> @@ -43,15 +43,6 @@
>>  #define CCDM_AUTO_FIRST_STAGE
>>  #endif
>>
>> -/* enums from TCG specs */
>> -enum {
>> -   /* capability areas */
>> -   TPM_CAP_NV_INDEX= 0x0011,
>> -   TPM_CAP_HANDLE  = 0x0014,
>> -   /* resource types */
>> -   TPM_RT_KEY  = 0x0001,
>> -};
>> -
>>  /* CCDM specific contants */
>>  enum {
>> /* NV indices */
>> diff --git a/include/tpm.h b/include/tpm.h
>> index 9a6585d..800f29c 100644
>> --- a/include/tpm.h
>> +++ b/include/tpm.h
>> @@ -47,6 +47,42 @@ enum tpm_nv_index {
>> TPM_NV_INDEX_DIR= 0x1001,
>>  };
>>
>> +enum tpm_resource_type {
>> +   TPM_RT_KEY  = 0x0001,
>> +   TPM_RT_AUTH = 0x0002,
>> +   TPM_RT_HASH = 0x0003,
>> +   TPM_RT_TRANS= 0x0004,
>> +   TPM_RT_CONTEXT  = 0x0005,
>> +   TPM_RT_COUNTER  = 0x0006,
>> +   TPM_RT_DELEGATE = 0x0007,
>> +   TPM_RT_DAA_TPM  = 0x0008,
>> +   TPM_RT_DAA_V0   = 0x0009,
>> +   TPM_RT_DAA_V1   = 0x000A,
>> +};
>> +
>> +enum tpm_capability_areas {
>> +   TPM_CAP_ORD = 0x0001,
>> +   TPM_CAP_ALG = 0x0002,
>> +   TPM_CAP_PID = 0x0003,
>> +   TPM_CAP_FLAG= 0x0004,
>> +   TPM_CAP_PROPERTY= 0x0005,
>> +   TPM_CAP_VERSION = 0x0006,
>> +   TPM_CAP_KEY_HANDLE  = 0x0007,
>> +   TPM_CAP_CHECK_LOADED= 0x0008,
>> +   TPM_CAP_SYM_MODE= 0x0009,
>> +   TPM_CAP_KEY_STATUS  = 0x000C,
>> +   TPM_CAP_NV_LIST = 0x000D,
>> +   TPM_CAP_MFR = 0x0010,
>> +   TPM_CAP_NV_INDEX= 0x0011,
>> +   TPM_CAP_TRANS_ALG   = 0x0012,
>> +   TPM_CAP_HANDLE  = 0x0014,
>> +   TPM_CAP_TRANS_ES= 0x0015,
>> +   TPM_CAP_AUTH_ENCRYPT= 0x0017,
>> +   TPM_CAP_SELECT_SIZE = 0x0018,
>> +   TPM_CAP_DA_LOGIC= 0x0019,
>> +   TPM_CAP_VERSION_VAL = 0x001A,
>> +};
>> +
>>  #define TPM_NV_PER_GLOBALLOCK  (1U << 15)
>>  #define TPM_NV_PER_PPWRITE (1U << 0)
>>  #define TPM_NV_PER_READ_STCLEAR(1U << 31)
>> @@ -594,4 +630,13 @@ uint32_t tpm_get_permanent_flags(struct
>> tpm_permanent_flags *pflags);
>>   */
>>  uint32_t tpm_get_permissions(uint32_t index, uint32_t *perm);
>>
>> +/**
>> + * Flush a resource with a given handle and type from the TPM
>> + *
>> + * @param key_handle   handle of the resource
>> + * @param resource_typetype of the resource
>> + * @return return code of the operation
>> + */
>> +uint32_t tpm_flush_specific(uint32_t key_handle, uint32_t resource_type);
>> +
>>  #endif /* __TPM_H */
>> diff --git a/lib/tpm.c b/lib/tpm.c
>> index 88f2406..98c20a0 100644
>> --- a/lib/tpm.c
>> +++ b/lib/tpm.c
>> @@ -645,6 +645,34 @@ uint32_t tpm_get_permissions(uint32_t index, uint32_t
>> *perm)
>> return 0;
>>  }
>>
>> +uint32_t tpm_flush_specific(uint32_t key_handle, uint32_t resource_type)
>> +{
>> +   const uint8_t command[18] = {
>> +   0x00, 0xc1, /* TPM_TAG */
>> +   0x00, 0x00, 0x00, 0x12, /* parameter size */
>> +   0x00, 0x00, 0x00, 0xba, /* TPM_COMMAND_CODE */
>> +   0x00, 0x00, 0x00, 0x00, /* key handle */
>> +   0x00, 0x00, 0x00, 0x00, /* resource type */
>> +   };
>> +   const size_t key_handle_offset = 10;
>> +   const size_t resource_type_offset = 14;
>> +

Drop blank line

>> +   uint8_t buf[COMMAND_BUFFER_SIZE], response[COMMAND_BUFFER_SIZE];
>> +   size_t response_length = sizeof(response);
>> +   uint32_t err;
>> +
>> +   if (pack_byte_string(buf, sizeof(buf), "sdd",
>> +0, command, sizeof(command),
>> +key_handle_offset, key_handle,
>> +resource_type_offset, resource_type))
>> + 

Re: [U-Boot] Query on qspi driver

[Siva Durga Prasad Paladugu]

Hi Jagan,

Ping!


> -Original Message-
> From: Siva Durga Prasad Paladugu
> Sent: Tuesday, November 29, 2016 10:30 AM
> To: 'Jagan Teki' 
> Cc: u-boot@lists.denx.de; Michal Simek (michal.si...@xilinx.com)
> 
> Subject: RE: [U-Boot] Query on qspi driver
> 
> 
> Hi Jagan,
> 
> > -Original Message-
> > From: Jagan Teki [mailto:ja...@openedev.com]
> > Sent: Thursday, November 24, 2016 11:48 PM
> > To: Siva Durga Prasad Paladugu 
> > Cc: u-boot@lists.denx.de; Michal Simek (michal.si...@xilinx.com)
> > 
> > Subject: Re: [U-Boot] Query on qspi driver
> >
> > On Wed, Nov 23, 2016 at 11:21 AM, Siva Durga Prasad Paladugu
> >  wrote:
> > > Hi Jagan,
> > >
> > > I am planning to send ZynqMP qspi driver to mainline. As per your
> > > recent
> > patches, I can see that, you are moving qspi flash stuff to spi-nor
> > and these are not in main tree yet.
> > > As you said earlier, I have seen u-boot-spi.git and there are few
> > > branches
> > on which you have spi-nor related changes. Could you please let me
> > know branch to work for sending my ZynqMP qspi driver patches.
> > > Also, could you let me know your plan or target release for spi-nor
> > changes, so that I will work on it accordingly.
> >
> > Please note that, if this controller is specially designed for spi-nor
> > flash's with exact functionalities which are more likely a flash
> > related I can recommend you to add the driver on mtd side, if not it
> > should be a pure spi driver.
> >
> > If you want to write the driver on mtd side, use the master tree
> > itself and once SPI-NOR ML will make the changes accordingly.
> Yes, I want to write driver on mtd side.
> Which master you are referring, is it u-boot-spi.git Or u-boot.git master?
> If it is u-boot.git, then I didn’t find any spi-nor related changes there. Do 
> you
> want me to add driver on mtd side with current spi on master?
> Also, could you let me know your plan or target release for spi-nor changes,
> so that I will work on it accordingly.
> 
> Regards,
> Siva
> >
> > thanks!
> > --
> > Jagan Teki
> > Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream
> > Maintainer Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 0/4] mmc: sdhci: Add support for frequency constrained peripheral interfaces

[Jaehoon Chung]

Hi Stefan,

On 12/02/2016 10:24 PM, stefan.herbrechtsme...@weidmueller.de wrote:
> From: Stefan Herbrechtsmeier 
> 
> 
> The sdhci controller assumes that the base clock frequency is fully
> supported by the peripheral and doesn't support hardware limitations.
> Distinguish between base clock of the host controller and maximal
> supported peripheral clock frequency of the peripheral interface.
> This is needed for the zynq platform to support two sdhci ports with
> different IO routings.

I understood what your purpose is...When i checked your patch, i wonder one 
thing about dwmmc controller.
There is also using dwmci_setup_cfg() and it is assigned to cfg->f_min/max with 
max_clk/min_clk.

I think it also needs to take your approach, right?
do you have any plan for dwmmc controller?

I want to apply at same time..because cfg->f_min/f_max should be used in mmc.c.
so It has to consider about all host controller, not only sdhci controller. :)

Best Regards,
Jaehoon Chung

> 
> Changes in v3:
> - Rename arguments of sdhci_setup_cfg function from max_clk/min_clk to 
> f_max/f_min
> 
> Changes in v2:
> - Remove unused index from get uart clock function
> - Remove unused index from get sdio clock function
> - Introduce common get clock function
> 
> Stefan Herbrechtsmeier (4):
>   mmc: sdhci: Distinguish between base clock and maximum peripheral
> frequency
>   serial: zynq: Remove unused index from get uart clock function
>   mmc: zynq: Determine base clock frequency via clock framework
>   mmc: zynq: Add fdt max-frequency support
> 
>  arch/arm/mach-zynq/clk.c  | 51 
> +++
>  arch/arm/mach-zynq/include/mach/clk.h |  3 ++-
>  drivers/mmc/atmel_sdhci.c |  7 +++--
>  drivers/mmc/bcm2835_sdhci.c   |  3 ++-
>  drivers/mmc/ftsdc021_sdhci.c  |  3 ++-
>  drivers/mmc/kona_sdhci.c  |  3 ++-
>  drivers/mmc/msm_sdhci.c   |  2 ++
>  drivers/mmc/mv_sdhci.c|  3 ++-
>  drivers/mmc/pci_mmc.c |  1 +
>  drivers/mmc/pic32_sdhci.c |  4 ++-
>  drivers/mmc/rockchip_sdhci.c  |  4 +--
>  drivers/mmc/s5p_sdhci.c   |  5 ++--
>  drivers/mmc/sdhci.c   | 34 ---
>  drivers/mmc/spear_sdhci.c |  3 ++-
>  drivers/mmc/zynq_sdhci.c  | 40 ++-
>  drivers/serial/serial_zynq.c  |  2 +-
>  include/sdhci.h   | 13 -
>  17 files changed, 133 insertions(+), 48 deletions(-)
> 

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 23/23] sunxi: A64: add 32-bit SPL support

[Andre Przywara]

When compiling the SPL for the Allwinner A64 in AArch64 mode, we can't
use the more compact Thumb2 encoding, which only exists for AArch32
code. This makes the SPL rather big, up to a point where any code
additions or even a different compiler may easily exceed the 32KB limit
that the Allwinner BROM imposes.
Introduce a separate, mostly generic sun50i-a64 configuration, which
defines the CPU_V7 symbol and thus will create a 32-bit binary using
the memory-saving Thumb2 encoding.
This should only be used for the SPL, the U-Boot proper should still be
using the existing 64-bit configuration. The SPL code can switch to
AArch64 if needed, so a 32-bit SPL can be combined with a 64-bit U-Boot
proper to eventually launch arm64 kernels.

Signed-off-by: Andre Przywara 
---
 board/sunxi/Kconfig| 14 --
 configs/pine64_plus_defconfig  |  2 +-
 configs/sun50i_spl32_defconfig | 10 ++
 include/configs/sunxi-common.h |  2 +-
 4 files changed, 24 insertions(+), 4 deletions(-)
 create mode 100644 configs/sun50i_spl32_defconfig

diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index b5246df..bb6e7fa 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -43,6 +43,10 @@ config SUNXI_GEN_SUN6I
watchdog, etc.
 
 
+config MACH_SUN50I
+   bool
+   select SUNXI_GEN_SUN6I
+
 choice
prompt "Sunxi SoC Variant"
optional
@@ -121,10 +125,16 @@ config MACH_SUN9I
select SUNXI_GEN_SUN6I
select SUPPORT_SPL
 
-config MACH_SUN50I
+config MACH_SUN50I_64
bool "sun50i (Allwinner A64)"
+   select MACH_SUN50I
select ARM64
-   select SUNXI_GEN_SUN6I
+   select SUPPORT_SPL
+
+config MACH_SUN50I_32
+   bool "sun50i (Allwinner A64) SPL-32bit"
+   select MACH_SUN50I
+   select CPU_V7
select SUPPORT_SPL
 
 endchoice
diff --git a/configs/pine64_plus_defconfig b/configs/pine64_plus_defconfig
index 2374170..a76f66a 100644
--- a/configs/pine64_plus_defconfig
+++ b/configs/pine64_plus_defconfig
@@ -1,7 +1,7 @@
 CONFIG_ARM=y
 CONFIG_RESERVE_ALLWINNER_BOOT0_HEADER=y
 CONFIG_ARCH_SUNXI=y
-CONFIG_MACH_SUN50I=y
+CONFIG_MACH_SUN50I_64=y
 CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-pine64-plus"
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
 CONFIG_CONSOLE_MUX=y
diff --git a/configs/sun50i_spl32_defconfig b/configs/sun50i_spl32_defconfig
new file mode 100644
index 000..29c6a47
--- /dev/null
+++ b/configs/sun50i_spl32_defconfig
@@ -0,0 +1,10 @@
+CONFIG_ARM=y
+CONFIG_ARCH_SUNXI=y
+CONFIG_MACH_SUN50I_32=y
+CONFIG_SPL=y
+CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-pine64-plus"
+CONFIG_OF_LIST="sun50i-a64-pine64 sun50i-a64-pine64-plus"
+# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_FLASH is not set
+# CONFIG_CMD_FPGA is not set
+CONFIG_MMC_SUNXI_SLOT_EXTRA=2
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 5279e51..4113591 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -183,7 +183,7 @@
 
 #define CONFIG_SPL_FRAMEWORK
 
-#ifndef CONFIG_MACH_SUN50I
+#ifndef CONFIG_MACH_SUN50I_64
 #define CONFIG_SPL_BOARD_LOAD_IMAGE
 #endif
 
-- 
2.8.2

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 20/23] Makefile: use "arm64" architecture for U-Boot image files

[Andre Przywara]

At the moment we use the arch/arm directory for arm64 boards as well,
so the Makefile will pick up the "arm" name for the architecture to use
for tagging binaries in U-Boot image files.
Differentiate between the two by looking at the CPU variable being defined
to "armv8", and use the arm64 architecture name on creating the image
file if that matches.

Signed-off-by: Andre Przywara 
Reviewed-by: Simon Glass 
---
 Makefile | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 96ddc59..d6ef646 100644
--- a/Makefile
+++ b/Makefile
@@ -921,13 +921,18 @@ quiet_cmd_cpp_cfg = CFG $@
 cmd_cpp_cfg = $(CPP) -Wp,-MD,$(depfile) $(cpp_flags) $(LDPPFLAGS) -ansi \
-DDO_DEPS_ONLY -D__ASSEMBLY__ -x assembler-with-cpp -P -dM -E -o $@ $<
 
+ifeq ($(CPU),armv8)
+IH_ARCH := arm64
+else
+IH_ARCH := $(ARCH)
+endif
 ifdef CONFIG_SPL_LOAD_FIT
-MKIMAGEFLAGS_u-boot.img = -f auto -A $(ARCH) -T firmware -C none -O u-boot \
+MKIMAGEFLAGS_u-boot.img = -f auto -A $(IH_ARCH) -T firmware -C none -O u-boot \
-a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \
-n "U-Boot $(UBOOTRELEASE) for $(BOARD) board" -E \
$(patsubst %,-b arch/$(ARCH)/dts/%.dtb,$(subst ",,$(CONFIG_OF_LIST)))
 else
-MKIMAGEFLAGS_u-boot.img = -A $(ARCH) -T firmware -C none -O u-boot \
+MKIMAGEFLAGS_u-boot.img = -A $(IH_ARCH) -T firmware -C none -O u-boot \
-a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \
-n "U-Boot $(UBOOTRELEASE) for $(BOARD) board"
 endif
-- 
2.8.2

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 21/23] ARM: SPL/FIT: differentiate between arm and arm64 arch properties

[Andre Przywara]

Since the SPL FIT loader can now differentiate between different
architectures, teach it how to tell arm and arm64 apart when a FIT
image is used.
We just support those two for now, as these are so far the only sensible
alternatives.

Signed-off-by: Andre Przywara 
Reviewed-by: Simon Glass 
---
 arch/arm/lib/spl.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/lib/spl.c b/arch/arm/lib/spl.c
index e606d47..45d285c 100644
--- a/arch/arm/lib/spl.c
+++ b/arch/arm/lib/spl.c
@@ -63,3 +63,18 @@ void __noreturn jump_to_image_linux(struct spl_image_info 
*spl_image, void *arg)
image_entry(0, machid, arg);
 }
 #endif
+
+/* This overwrites the weak definition in spl_fit.c */
+u8 spl_genimg_get_arch_id(const char *arch_str)
+{
+   if (!arch_str)
+   return IH_ARCH_DEFAULT;
+
+   if (!strcmp(arch_str, "arm"))
+   return IH_ARCH_ARM;
+
+   if (!strcmp(arch_str, "arm64"))
+   return IH_ARCH_ARM64;
+
+   return IH_ARCH_DEFAULT;
+}
-- 
2.8.2

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 22/23] sunxi: introduce RMR switch to enter payloads in 64-bit mode

[Andre Przywara]

The ARMv8 capable Allwinner A64 SoC comes out of reset in AArch32 mode.
To run AArch64 code, we have to trigger a warm reset via the RMR register,
which proceeds with code execution at the address stored in the RVBAR
register.
If the bootable payload in the FIT image is using a different
architecture than the SPL has been compiled for, enter it via this said
RMR switch mechanism, by writing the entry point address into the MMIO
mapped, writable version of the RVBAR register.
Then the warm reset is triggered via a system register write.
If the payload architecture is the same as the SPL, we use the normal
branch as usual.

Signed-off-by: Andre Przywara 
---
 arch/arm/mach-sunxi/Makefile |  1 +
 arch/arm/mach-sunxi/spl_switch.c | 60 
 2 files changed, 61 insertions(+)
 create mode 100644 arch/arm/mach-sunxi/spl_switch.c

diff --git a/arch/arm/mach-sunxi/Makefile b/arch/arm/mach-sunxi/Makefile
index 7daba11..128091e 100644
--- a/arch/arm/mach-sunxi/Makefile
+++ b/arch/arm/mach-sunxi/Makefile
@@ -51,4 +51,5 @@ obj-$(CONFIG_MACH_SUN8I_A83T) += dram_sun8i_a83t.o
 obj-$(CONFIG_MACH_SUN8I_H3)+= dram_sun8i_h3.o
 obj-$(CONFIG_MACH_SUN9I)   += dram_sun9i.o
 obj-$(CONFIG_MACH_SUN50I)  += dram_sun8i_h3.o
+obj-$(CONFIG_MACH_SUN50I)  += spl_switch.o
 endif
diff --git a/arch/arm/mach-sunxi/spl_switch.c b/arch/arm/mach-sunxi/spl_switch.c
new file mode 100644
index 000..20f21b1
--- /dev/null
+++ b/arch/arm/mach-sunxi/spl_switch.c
@@ -0,0 +1,60 @@
+/*
+ * (C) Copyright 2016 ARM Ltd.
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include 
+#include 
+
+#include 
+#include 
+
+static void __noreturn jump_to_image_native(struct spl_image_info *spl_image)
+{
+   typedef void __noreturn (*image_entry_noargs_t)(void);
+
+   image_entry_noargs_t image_entry =
+   (image_entry_noargs_t)spl_image->entry_point;
+
+   image_entry();
+}
+
+static void __noreturn reset_rmr_switch(void)
+{
+#ifdef CONFIG_ARM64
+   __asm__ volatile ( "mrs  x0, RMR_EL3\n\t"
+  "bic  x0, x0, #1\n\t"   /* Clear enter-in-64 bit */
+  "orr  x0, x0, #2\n\t"   /* set reset request bit */
+  "msr  RMR_EL3, x0\n\t"
+  "isb  sy\n\t"
+  "nop\n\t"
+  "wfi\n\t"
+  "b.\n"
+  ::: "x0");
+#else
+   __asm__ volatile ( "mrc  15, 0, r0, cr12, cr0, 2\n\t"
+  "orr  r0, r0, #3\n\t"   /* request reset in 64 bit */
+  "mcr  15, 0, r0, cr12, cr0, 2\n\t"
+  "isb\n\t"
+  "nop\n\t"
+  "wfi\n\t"
+  "b.\n"
+  ::: "r0");
+#endif
+   while (1);  /* to avoid a compiler warning about __noreturn */
+}
+
+void __noreturn jump_to_image_no_args(struct spl_image_info *spl_image)
+{
+   if (spl_image->arch == IH_ARCH_DEFAULT) {
+   debug("entering by branch\n");
+   jump_to_image_native(spl_image);
+   } else {
+   debug("entering by RMR switch\n");
+   writel(spl_image->entry_point, 0x17000a0);
+   DSB;
+   ISB;
+   reset_rmr_switch();
+   }
+}
-- 
2.8.2

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 19/23] SPL: read and store arch property from U-Boot image

[Andre Przywara]

Read the specified "arch" value from a legacy or FIT U-Boot image and
store it in our SPL data structure.
This allows loaders to take the target architecture in account for
custom loading procedures.
Having the complete string -> arch mapping for FIT based images in the
SPL would be too big, so we leave it up to architectures (or boards) to
overwrite the weak function that does the actual translation, possibly
covering only the required subset there.
Document struct spl_image_info on the way.

Signed-off-by: Andre Przywara 
Reviewed-by: Simon Glass 
---
 common/spl/spl.c |  1 +
 common/spl/spl_fit.c |  8 
 include/spl.h| 15 ++-
 3 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/common/spl/spl.c b/common/spl/spl.c
index cda2f8a..b457052 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -114,6 +114,7 @@ int spl_parse_image_header(struct spl_image_info *spl_image,
header_size;
}
spl_image->os = image_get_os(header);
+   spl_image->arch = image_get_arch(header);
spl_image->name = image_get_name(header);
debug("spl: payload image: %.*s load addr: 0x%lx size: %d\n",
(int)sizeof(spl_image->name), spl_image->name,
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index aae556f..a5d903b 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -123,6 +123,11 @@ static int get_aligned_image_size(struct spl_load_info 
*info, int data_size,
return (data_size + info->bl_len - 1) / info->bl_len;
 }
 
+__weak u8 spl_genimg_get_arch_id(const char *arch_str)
+{
+   return IH_ARCH_DEFAULT;
+}
+
 int spl_load_simple_fit(struct spl_image_info *spl_image,
struct spl_load_info *info, ulong sector, void *fit)
 {
@@ -136,6 +141,7 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
int base_offset, align_len = ARCH_DMA_MINALIGN - 1;
int src_sector;
void *dst, *src;
+   const char *arch_str;
 
/*
 * Figure out where the external images start. This is the base for the
@@ -184,10 +190,12 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
data_offset = fdt_getprop_u32(fit, node, "data-offset");
data_size = fdt_getprop_u32(fit, node, "data-size");
load = fdt_getprop_u32(fit, node, "load");
+   arch_str = fdt_getprop(fit, node, "arch", NULL);
debug("data_offset=%x, data_size=%x\n", data_offset, data_size);
spl_image->load_addr = load;
spl_image->entry_point = load;
spl_image->os = IH_OS_U_BOOT;
+   spl_image->arch = spl_genimg_get_arch_id(arch_str);
 
/*
 * Work out where to place the image. We read it so that the first
diff --git a/include/spl.h b/include/spl.h
index feadb33..87129df 100644
--- a/include/spl.h
+++ b/include/spl.h
@@ -20,13 +20,26 @@
 #define MMCSD_MODE_FS  2
 #define MMCSD_MODE_EMMCBOOT3
 
+/*
+ * Information about an U-Boot image file as described in include/image.h.
+ * Parsed by the SPL code from a legacy or FIT image file.
+ *
+ * @name: descriptive string (mkimage -n)
+ * @load_addr: address to load the image file to (mkimage -a)
+ * @entry_point: address of first instruction to execute (mkimage -e)
+ * @size: size of image in bytes
+ * @flags: optional, used only for SPL_COPY_PAYLOAD_ONLY so far
+ * @os: target operating system, one of IH_OS_* (mkimage -O)
+ * @arch: target architecture, one of IH_ARCH_* (mkimage -A)
+ */
 struct spl_image_info {
const char *name;
-   u8 os;
ulong load_addr;
ulong entry_point;
u32 size;
u32 flags;
+   u8 os;
+   u8 arch;
 };
 
 /*
-- 
2.8.2

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 17/23] sunxi: DRAM: fix H3 DRAM size display on aarch64

[Andre Przywara]

Fix the output of the DRAM size on AArch64 SPLs.

Signed-off-by: Andre Przywara 
Reviewed-by: Alexander Graf 
---
 arch/arm/mach-sunxi/dram_sun8i_h3.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-sunxi/dram_sun8i_h3.c 
b/arch/arm/mach-sunxi/dram_sun8i_h3.c
index 3d569fc..5ee8b3d 100644
--- a/arch/arm/mach-sunxi/dram_sun8i_h3.c
+++ b/arch/arm/mach-sunxi/dram_sun8i_h3.c
@@ -571,6 +571,6 @@ unsigned long sunxi_dram_init(void)
mctl_auto_detect_dram_size();
mctl_set_cr();
 
-   return (1 << (para.row_bits + 3)) * para.page_size *
+   return (1UL << (para.row_bits + 3)) * para.page_size *
(para.dual_rank ? 2 : 1);
 }
-- 
2.8.2

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 18/23] sunxi: A64: enable SPL

[Andre Przywara]

Now that the SPL is ready to be compiled in AArch64 and the DRAM
init code is ready, enable SPL support for the A64 SoC and in the
Pine64 defconfig.
For now we keep the boot0 header in the U-Boot proper, as this allows
to still use boot0 as an SPL replacement without hurting the SPL use
case.
We disable FEL support for now, as the code isn't ready yet.

Signed-off-by: Andre Przywara 
---
 arch/arm/mach-sunxi/board.c| 2 +-
 board/sunxi/Kconfig| 2 ++
 configs/pine64_plus_defconfig  | 1 +
 include/configs/sunxi-common.h | 2 ++
 4 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
index 0f8ead9..80d4b57 100644
--- a/arch/arm/mach-sunxi/board.c
+++ b/arch/arm/mach-sunxi/board.c
@@ -133,7 +133,7 @@ static int gpio_init(void)
return 0;
 }
 
-#ifdef CONFIG_SPL_BUILD
+#if defined(CONFIG_SPL_BOARD_LOAD_IMAGE) && defined(CONFIG_SPL_BUILD)
 static int spl_board_load_image(struct spl_image_info *spl_image,
struct spl_boot_device *bootdev)
 {
diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index d477925..b5246df 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -125,6 +125,7 @@ config MACH_SUN50I
bool "sun50i (Allwinner A64)"
select ARM64
select SUNXI_GEN_SUN6I
+   select SUPPORT_SPL
 
 endchoice
 
@@ -187,6 +188,7 @@ config DRAM_ODT_EN
bool "sunxi dram odt enable"
default n if !MACH_SUN8I_A23
default y if MACH_SUN8I_A23
+   default y if MACH_SUN50I
---help---
Select this to enable dram odt (on die termination).
 
diff --git a/configs/pine64_plus_defconfig b/configs/pine64_plus_defconfig
index ebc24b8..2374170 100644
--- a/configs/pine64_plus_defconfig
+++ b/configs/pine64_plus_defconfig
@@ -5,6 +5,7 @@ CONFIG_MACH_SUN50I=y
 CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-pine64-plus"
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
 CONFIG_CONSOLE_MUX=y
+CONFIG_SPL=y
 # CONFIG_CMD_IMLS is not set
 # CONFIG_CMD_FLASH is not set
 # CONFIG_CMD_FPGA is not set
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index e05c318..5279e51 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -183,7 +183,9 @@
 
 #define CONFIG_SPL_FRAMEWORK
 
+#ifndef CONFIG_MACH_SUN50I
 #define CONFIG_SPL_BOARD_LOAD_IMAGE
+#endif
 
 #if defined(CONFIG_MACH_SUN9I)
 #define CONFIG_SPL_TEXT_BASE   0x10040 /* sram start+header */
-- 
2.8.2

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 13/23] sunxi: H3: add and rename some DRAM contoller registers

[Andre Przywara]

From: Jens Kuske 

The IOCR registers got renamed to BDLR to match the public
documentation of similar controllers.

Signed-off-by: Jens Kuske 
Signed-off-by: Andre Przywara 
---
 arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h | 43 ++---
 arch/arm/mach-sunxi/dram_sun8i_h3.c | 34 +--
 2 files changed, 41 insertions(+), 36 deletions(-)

diff --git a/arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h 
b/arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h
index d0f2b8a..867fd12 100644
--- a/arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h
+++ b/arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h
@@ -81,7 +81,7 @@ struct sunxi_mctl_ctl_reg {
u32 rfshtmg;/* 0x90 refresh timing */
u32 rfshctl1;   /* 0x94 */
u32 pwrtmg; /* 0x98 */
-   u8  res3[0x20]; /* 0x9c */
+   u8 res3[0x20];  /* 0x9c */
u32 dqsgmr; /* 0xbc */
u32 dtcr;   /* 0xc0 */
u32 dtar[4];/* 0xc4 */
@@ -106,20 +106,23 @@ struct sunxi_mctl_ctl_reg {
u32 perfhpr[2]; /* 0x1c4 */
u32 perflpr[2]; /* 0x1cc */
u32 perfwr[2];  /* 0x1d4 */
-   u8 res8[0x2c];  /* 0x1dc */
-   u32 aciocr; /* 0x208 */
-   u8 res9[0xf4];  /* 0x20c */
+   u8 res8[0x24];  /* 0x1dc */
+   u32 acmdlr; /* 0x200 AC master delay line register */
+   u32 aclcdlr;/* 0x204 AC local calibrated delay line 
register */
+   u32 aciocr; /* 0x208 AC I/O configuration register */
+   u8 res9[0x4];   /* 0x20c */
+   u32 acbdlr[31]; /* 0x210 AC bit delay line registers */
+   u8 res10[0x74]; /* 0x28c */
struct {/* 0x300 DATX8 modules*/
-   u32 mdlr;   /* 0x00 */
-   u32 lcdlr[3];   /* 0x04 */
-   u32 iocr[11];   /* 0x10 IO configuration register */
-   u32 bdlr6;  /* 0x3c */
-   u32 gtr;/* 0x40 */
-   u32 gcr;/* 0x44 */
-   u32 gsr[3]; /* 0x48 */
+   u32 mdlr;   /* 0x00 master delay line register */
+   u32 lcdlr[3];   /* 0x04 local calibrated delay line 
registers */
+   u32 bdlr[12];   /* 0x10 bit delay line registers */
+   u32 gtr;/* 0x40 general timing register */
+   u32 gcr;/* 0x44 general configuration register 
*/
+   u32 gsr[3]; /* 0x48 general status registers */
u8 res0[0x2c];  /* 0x54 */
-   } datx[4];
-   u8 res10[0x388];/* 0x500 */
+   } dx[4];
+   u8 res11[0x388];/* 0x500 */
u32 upd2;   /* 0x888 */
 };
 
@@ -174,12 +177,14 @@ struct sunxi_mctl_ctl_reg {
 
 #define ZQCR_PWRDOWN   (0x1 << 31) /* ZQ power down */
 
-#define DATX_IOCR_DQ(x)(x) /* DQ0-7 IOCR index */
-#define DATX_IOCR_DM   (8) /* DM IOCR index */
-#define DATX_IOCR_DQS  (9) /* DQS IOCR index */
-#define DATX_IOCR_DQSN (10)/* DQSN IOCR index */
+#define ACBDLR_WRITE_DELAY(x)  ((x) << 8)
 
-#define DATX_IOCR_WRITE_DELAY(x)   ((x) << 8)
-#define DATX_IOCR_READ_DELAY(x)((x) << 0)
+#define DXBDLR_DQ(x)   (x) /* DQ0-7 BDLR index */
+#define DXBDLR_DM  (8) /* DM BDLR index */
+#define DXBDLR_DQS (9) /* DQS BDLR index */
+#define DXBDLR_DQSN(10)/* DQSN BDLR index */
+
+#define DXBDLR_WRITE_DELAY(x)  ((x) << 8)
+#define DXBDLR_READ_DELAY(x)   ((x) << 0)
 
 #endif /* _SUNXI_DRAM_SUN8I_H3_H */
diff --git a/arch/arm/mach-sunxi/dram_sun8i_h3.c 
b/arch/arm/mach-sunxi/dram_sun8i_h3.c
index b08b8e6..3dd6803 100644
--- a/arch/arm/mach-sunxi/dram_sun8i_h3.c
+++ b/arch/arm/mach-sunxi/dram_sun8i_h3.c
@@ -72,21 +72,21 @@ static void mctl_dq_delay(u32 read, u32 write)
u32 val;
 
for (i = 0; i < 4; i++) {
-   val = DATX_IOCR_WRITE_DELAY((write >> (i * 4)) & 0xf) |
- DATX_IOCR_READ_DELAY(((read >> (i * 4)) & 0xf) * 2);
+   val = DXBDLR_WRITE_DELAY((write >> (i * 4)) & 0xf) |
+ DXBDLR_READ_DELAY(((read >> (i * 4)) & 0xf) * 2);
 
-   for (j = DATX_IOCR_DQ(0); j <= DATX_IOCR_DM; j++)
-   writel(val, _ctl->datx[i].iocr[j]);
+   for (j = DXBDLR_DQ(0); j <= DXBDLR_DM; j++)
+   writel(val, _ctl->dx[i].bdlr[j]);
}
 
clrbits_le32(_ctl->pgcr[0], 1 << 26);
 
for (i = 0; i < 4; i++) {
-   val = DATX_IOCR_WRITE_DELAY((write >> (16 + i * 4)) & 0xf) |
- DATX_IOCR_READ_DELAY((read >> (16 + i * 4)) & 0xf);

[U-Boot] [PATCH v2 14/23] sunxi: H3: add DRAM controller single bit delay support

[Andre Przywara]

From: Jens Kuske 

Instead of setting the delay for whole bytes allow setting
it for each individual bit. Also add support for
address/command lane delays.

Signed-off-by: Jens Kuske 
Signed-off-by: Andre Przywara 
---
 arch/arm/mach-sunxi/dram_sun8i_h3.c | 54 ++---
 1 file changed, 27 insertions(+), 27 deletions(-)

diff --git a/arch/arm/mach-sunxi/dram_sun8i_h3.c 
b/arch/arm/mach-sunxi/dram_sun8i_h3.c
index 3dd6803..1647d76 100644
--- a/arch/arm/mach-sunxi/dram_sun8i_h3.c
+++ b/arch/arm/mach-sunxi/dram_sun8i_h3.c
@@ -16,12 +16,13 @@
 #include 
 
 struct dram_para {
-   u32 read_delays;
-   u32 write_delays;
u16 page_size;
u8 bus_width;
u8 dual_rank;
u8 row_bits;
+   const u8 dx_read_delays[4][11];
+   const u8 dx_write_delays[4][11];
+   const u8 ac_delays[31];
 };
 
 static inline int ns_to_t(int nanoseconds)
@@ -64,34 +65,25 @@ static void mctl_phy_init(u32 val)
mctl_await_completion(_ctl->pgsr[0], PGSR_INIT_DONE, 0x1);
 }
 
-static void mctl_dq_delay(u32 read, u32 write)
+static void mctl_set_bit_delays(struct dram_para *para)
 {
struct sunxi_mctl_ctl_reg * const mctl_ctl =
(struct sunxi_mctl_ctl_reg *)SUNXI_DRAM_CTL0_BASE;
int i, j;
-   u32 val;
-
-   for (i = 0; i < 4; i++) {
-   val = DXBDLR_WRITE_DELAY((write >> (i * 4)) & 0xf) |
- DXBDLR_READ_DELAY(((read >> (i * 4)) & 0xf) * 2);
-
-   for (j = DXBDLR_DQ(0); j <= DXBDLR_DM; j++)
-   writel(val, _ctl->dx[i].bdlr[j]);
-   }
 
clrbits_le32(_ctl->pgcr[0], 1 << 26);
 
-   for (i = 0; i < 4; i++) {
-   val = DXBDLR_WRITE_DELAY((write >> (16 + i * 4)) & 0xf) |
- DXBDLR_READ_DELAY((read >> (16 + i * 4)) & 0xf);
+   for (i = 0; i < 4; i++)
+   for (j = 0; j < 11; j++)
+   writel(DXBDLR_WRITE_DELAY(para->dx_write_delays[i][j]) |
+  DXBDLR_READ_DELAY(para->dx_read_delays[i][j]),
+  _ctl->dx[i].bdlr[j]);
 
-   writel(val, _ctl->dx[i].bdlr[DXBDLR_DQS]);
-   writel(val, _ctl->dx[i].bdlr[DXBDLR_DQSN]);
-   }
+   for (i = 0; i < 31; i++)
+   writel(ACBDLR_WRITE_DELAY(para->ac_delays[i]),
+  _ctl->acbdlr[i]);
 
setbits_le32(_ctl->pgcr[0], 1 << 26);
-
-   udelay(1);
 }
 
 static void mctl_set_master_priority(void)
@@ -372,11 +364,8 @@ static int mctl_channel_init(struct dram_para *para)
clrsetbits_le32(_ctl->dtcr, 0xf << 24,
(para->dual_rank ? 0x3 : 0x1) << 24);
 
-
-   if (para->read_delays || para->write_delays) {
-   mctl_dq_delay(para->read_delays, para->write_delays);
-   udelay(50);
-   }
+   mctl_set_bit_delays(para);
+   udelay(50);
 
mctl_zq_calibration(para);
 
@@ -458,12 +447,23 @@ unsigned long sunxi_dram_init(void)
(struct sunxi_mctl_ctl_reg *)SUNXI_DRAM_CTL0_BASE;
 
struct dram_para para = {
-   .read_delays = 0x7979,  /* dram_tpr12 */
-   .write_delays = 0x6aaa, /* dram_tpr11 */
.dual_rank = 0,
.bus_width = 32,
.row_bits = 15,
.page_size = 4096,
+
+   .dx_read_delays =  {{ 18, 18, 18, 18, 18, 18, 18, 18, 18,  0,  
0 },
+   { 14, 14, 14, 14, 14, 14, 14, 14, 14,  0,  
0 },
+   { 18, 18, 18, 18, 18, 18, 18, 18, 18,  0,  
0 },
+   { 14, 14, 14, 14, 14, 14, 14, 14, 14,  0,  
0 }},
+   .dx_write_delays = {{  0,  0,  0,  0,  0,  0,  0,  0,  0, 10, 
10 },
+   {  0,  0,  0,  0,  0,  0,  0,  0,  0, 10, 
10 },
+   {  0,  0,  0,  0,  0,  0,  0,  0,  0, 10, 
10 },
+   {  0,  0,  0,  0,  0,  0,  0,  0,  0,  6,  
6 }},
+   .ac_delays = {  0,  0,  0,  0,  0,  0,  0,  0,
+   0,  0,  0,  0,  0,  0,  0,  0,
+   0,  0,  0,  0,  0,  0,  0,  0,
+   0,  0,  0,  0,  0,  0,  0  },
};
 
mctl_sys_init();
-- 
2.8.2

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 15/23] sunxi: A64: use H3 DRAM initialization code for A64

[Andre Przywara]

From: Jens Kuske 

The A64 DRAM controller is very similar to the H3 one,
so the code can be reused with some small changes.
[Andre: fixed up typo, merged in fixes from Jens]

Signed-off-by: Jens Kuske 
Signed-off-by: Andre Przywara 
---
 arch/arm/include/asm/arch-sunxi/clock_sun6i.h   |   1 +
 arch/arm/include/asm/arch-sunxi/dram.h  |   2 +-
 arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h |  10 +-
 arch/arm/mach-sunxi/Makefile|   1 +
 arch/arm/mach-sunxi/clock_sun6i.c   |   2 +-
 arch/arm/mach-sunxi/dram_sun8i_h3.c | 139 +++-
 6 files changed, 123 insertions(+), 32 deletions(-)

diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h 
b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
index be9fcfd..3f87672 100644
--- a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
+++ b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
@@ -322,6 +322,7 @@ struct sunxi_ccm_reg {
 #define CCM_DRAMCLK_CFG_DIV0_MASK  (0xf << 8)
 #define CCM_DRAMCLK_CFG_SRC_PLL5   (0x0 << 20)
 #define CCM_DRAMCLK_CFG_SRC_PLL6x2 (0x1 << 20)
+#define CCM_DRAMCLK_CFG_SRC_PLL11  (0x1 << 20) /* A64 only */
 #define CCM_DRAMCLK_CFG_SRC_MASK   (0x3 << 20)
 #define CCM_DRAMCLK_CFG_UPD(0x1 << 16)
 #define CCM_DRAMCLK_CFG_RST(0x1 << 31)
diff --git a/arch/arm/include/asm/arch-sunxi/dram.h 
b/arch/arm/include/asm/arch-sunxi/dram.h
index e0be744..53e6d47 100644
--- a/arch/arm/include/asm/arch-sunxi/dram.h
+++ b/arch/arm/include/asm/arch-sunxi/dram.h
@@ -24,7 +24,7 @@
 #include 
 #elif defined(CONFIG_MACH_SUN8I_A83T)
 #include 
-#elif defined(CONFIG_MACH_SUN8I_H3)
+#elif defined(CONFIG_MACH_SUN8I_H3) || defined(CONFIG_MACH_SUN50I)
 #include 
 #elif defined(CONFIG_MACH_SUN9I)
 #include 
diff --git a/arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h 
b/arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h
index 867fd12..b0e5d93 100644
--- a/arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h
+++ b/arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h
@@ -15,7 +15,8 @@
 
 struct sunxi_mctl_com_reg {
u32 cr; /* 0x00 control register */
-   u8 res0[0xc];   /* 0x04 */
+   u8 res0[0x8];   /* 0x04 */
+   u32 tmr;/* 0x0c (A64 only) */
u32 mcr[16][2]; /* 0x10 */
u32 bwcr;   /* 0x90 bandwidth control register */
u32 maer;   /* 0x94 master enable register */
@@ -32,7 +33,9 @@ struct sunxi_mctl_com_reg {
u32 swoffr; /* 0xc4 */
u8 res2[0x8];   /* 0xc8 */
u32 cccr;   /* 0xd0 */
-   u8 res3[0x72c]; /* 0xd4 */
+   u8 res3[0x54];  /* 0xd4 */
+   u32 mdfs_bwlr[3];   /* 0x128 (A64 only) */
+   u8 res4[0x6cc]; /* 0x134 */
u32 protect;/* 0x800 */
 };
 
@@ -81,7 +84,8 @@ struct sunxi_mctl_ctl_reg {
u32 rfshtmg;/* 0x90 refresh timing */
u32 rfshctl1;   /* 0x94 */
u32 pwrtmg; /* 0x98 */
-   u8 res3[0x20];  /* 0x9c */
+   u8 res3[0x1c];  /* 0x9c */
+   u32 vtfcr;  /* 0xb8 (A64 only) */
u32 dqsgmr; /* 0xbc */
u32 dtcr;   /* 0xc0 */
u32 dtar[4];/* 0xc4 */
diff --git a/arch/arm/mach-sunxi/Makefile b/arch/arm/mach-sunxi/Makefile
index e73114e..7daba11 100644
--- a/arch/arm/mach-sunxi/Makefile
+++ b/arch/arm/mach-sunxi/Makefile
@@ -50,4 +50,5 @@ obj-$(CONFIG_MACH_SUN8I_A33)  += dram_sun8i_a33.o
 obj-$(CONFIG_MACH_SUN8I_A83T)  += dram_sun8i_a83t.o
 obj-$(CONFIG_MACH_SUN8I_H3)+= dram_sun8i_h3.o
 obj-$(CONFIG_MACH_SUN9I)   += dram_sun9i.o
+obj-$(CONFIG_MACH_SUN50I)  += dram_sun8i_h3.o
 endif
diff --git a/arch/arm/mach-sunxi/clock_sun6i.c 
b/arch/arm/mach-sunxi/clock_sun6i.c
index 80cfc0b..99f515d 100644
--- a/arch/arm/mach-sunxi/clock_sun6i.c
+++ b/arch/arm/mach-sunxi/clock_sun6i.c
@@ -217,7 +217,7 @@ done:
 }
 #endif
 
-#ifdef CONFIG_MACH_SUN8I_A33
+#if defined(CONFIG_MACH_SUN8I_A33) || defined(CONFIG_MACH_SUN50I)
 void clock_set_pll11(unsigned int clk, bool sigma_delta_enable)
 {
struct sunxi_ccm_reg * const ccm =
diff --git a/arch/arm/mach-sunxi/dram_sun8i_h3.c 
b/arch/arm/mach-sunxi/dram_sun8i_h3.c
index 1647d76..2dc2071 100644
--- a/arch/arm/mach-sunxi/dram_sun8i_h3.c
+++ b/arch/arm/mach-sunxi/dram_sun8i_h3.c
@@ -32,30 +32,6 @@ static inline int ns_to_t(int nanoseconds)
return DIV_ROUND_UP(ctrl_freq * nanoseconds, 1000);
 }
 
-static u32 bin_to_mgray(int val)
-{
-   static const u8 lookup_table[32] = {
-   0x00, 0x01, 0x02, 0x03, 0x06, 0x07, 0x04, 0x05,
-   0x0c, 0x0d, 0x0e, 0x0f, 0x0a, 0x0b, 0x08, 0x09,
-   0x18, 0x19, 0x1a, 0x1b, 0x1e, 0x1f, 0x1c, 0x1d,
-   0x14, 0x15, 0x16, 0x17, 0x12, 0x13, 0x10, 0x11,
-   };
-
-   return 

[U-Boot] [PATCH v2 16/23] sunxi: H3/A64: fix non-ODT setting

[Andre Przywara]

According to Jens disabling the on-die-termination should set bit 5,
not bit 1 in the respective register. Fix this.

Reported-by: Jens Kuske 
Signed-off-by: Andre Przywara 
---
 arch/arm/mach-sunxi/dram_sun8i_h3.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-sunxi/dram_sun8i_h3.c 
b/arch/arm/mach-sunxi/dram_sun8i_h3.c
index 2dc2071..3d569fc 100644
--- a/arch/arm/mach-sunxi/dram_sun8i_h3.c
+++ b/arch/arm/mach-sunxi/dram_sun8i_h3.c
@@ -385,7 +385,7 @@ static int mctl_channel_init(struct dram_para *para)
clrsetbits_le32(_ctl->dx[i].gcr, (0x3 << 4) |
(0x1 << 1) | (0x3 << 2) | (0x3 << 12) |
(0x3 << 14),
-   IS_ENABLED(CONFIG_DRAM_ODT_EN) ? 0x0 : 0x2);
+   IS_ENABLED(CONFIG_DRAM_ODT_EN) ? 0x0 : 0x20);
 
/* AC PDR should always ON */
setbits_le32(_ctl->aciocr, 0x1 << 1);
-- 
2.8.2

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 08/23] armv8: move reset branch into boot hook

[Andre Przywara]

The boot0 hook we have so far is applied _after_ the initial branch
to the "reset" entry point. An upcoming change requires even this
branch to be changed, so we apply the hook macro at the earliest
point, and have the branch in the hook file as well.
This is no functional change at this point, just refactoring to simplify
upcoming patches.

Signed-off-by: Andre Przywara 
---
 arch/arm/cpu/armv8/start.S  | 4 ++--
 arch/arm/include/asm/arch-sunxi/boot0.h | 1 +
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
index 4f5f6d8..ee393d7 100644
--- a/arch/arm/cpu/armv8/start.S
+++ b/arch/arm/cpu/armv8/start.S
@@ -19,8 +19,6 @@
 
 .globl _start
 _start:
-   b   reset
-
 #ifdef CONFIG_ENABLE_ARM_SOC_BOOT0_HOOK
 /*
  * Various SoCs need something special and SoC-specific up front in
@@ -29,6 +27,8 @@ _start:
  */
 #include 
 ARM_SOC_BOOT0_HOOK
+#else
+   b   reset
 #endif
 
.align 3
diff --git a/arch/arm/include/asm/arch-sunxi/boot0.h 
b/arch/arm/include/asm/arch-sunxi/boot0.h
index ea5675e..6f28d63 100644
--- a/arch/arm/include/asm/arch-sunxi/boot0.h
+++ b/arch/arm/include/asm/arch-sunxi/boot0.h
@@ -9,6 +9,7 @@
 
 /* reserve space for BOOT0 header information */
 #define ARM_SOC_BOOT0_HOOK \
+   b   reset;  \
.space  1532
 
 #endif /* __BOOT0_H */
-- 
2.8.2

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 11/23] sunxi: A64: do an RMR switch if started in AArch32 mode

[Andre Przywara]

The Allwinner A64 SoC starts execution in AArch32 mode, and both
the boot ROM and Allwinner's boot0 keep running in this mode.
So U-Boot gets entered in 32-bit, although we want it to run in AArch64.

By using a "magic" instruction, which happens to be an almost-NOP in
AArch64 and a branch in AArch32, we differentiate between being
entered in 64-bit or 32-bit mode.
If in 64-bit mode, we proceed with the branch to reset, but in 32-bit
mode we trigger an RMR write to bring the core into AArch64/EL3 and
re-enter U-Boot at CONFIG_SYS_TEXT_BASE.
This allows a 64-bit U-Boot to be both entered in 32 and 64-bit mode,
so we can use the same start code for the SPL and the U-Boot proper.

We use the existing custom header (boot0.h) functionality, but restrict
the existing boot0 header reservation to the non-SPL build now. A SPL
wouldn't need such header anyway. This allows to have both options
defined and lets us use one for the SPL and the other for U-Boot proper.

Signed-off-by: Andre Przywara 
---
 arch/arm/include/asm/arch-sunxi/boot0.h | 27 +++
 board/sunxi/Kconfig |  5 +
 2 files changed, 32 insertions(+)

diff --git a/arch/arm/include/asm/arch-sunxi/boot0.h 
b/arch/arm/include/asm/arch-sunxi/boot0.h
index 6a13db5..7799a03 100644
--- a/arch/arm/include/asm/arch-sunxi/boot0.h
+++ b/arch/arm/include/asm/arch-sunxi/boot0.h
@@ -4,6 +4,33 @@
  * SPDX-License-Identifier:GPL-2.0+
  */
 
+#if defined(CONFIG_RESERVE_ALLWINNER_BOOT0_HEADER) && 
!defined(CONFIG_SPL_BUILD)
 /* reserve space for BOOT0 header information */
b   reset
.space  1532
+#elif defined(CONFIG_ARM_BOOT_HOOK_RMR)
+/* switch into AArch64 if needed */
+   tst x0, x0  // this is "b #0x84" in ARM
+   b   reset
+   .space  0x7c
+   .word   0xe59f1024  // ldr r1, [pc, #36] ; 0x17a0
+   .word   0xe59f0024  // ldr r0, [pc, #36] ; CONFIG_*_TEXT_BASE
+   .word   0xe581  // str r0, [r1]
+   .word   0xf57ff04f  // dsb sy
+   .word   0xf57ff06f  // isb sy
+   .word   0xee1c0f50  // mrc 15, 0, r0, cr12, cr0, {2} ; RMR
+   .word   0xe383  // orr r0, r0, #3
+   .word   0xee0c0f50  // mcr 15, 0, r0, cr12, cr0, {2} ; RMR
+   .word   0xf57ff06f  // isb sy
+   .word   0xe320f003  // wfi
+   .word   0xeafd  // b   @wfi
+   .word   0x017000a0  // writeable RVBAR mapping address
+#ifdef CONFIG_SPL_BUILD
+   .word   CONFIG_SPL_TEXT_BASE
+#else
+   .word   CONFIG_SYS_TEXT_BASE
+#endif
+#else
+/* normal execution */
+   b   reset
+#endif
diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index 0cd57a2..ba72e76 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -142,6 +142,11 @@ config RESERVE_ALLWINNER_BOOT0_HEADER
blob relies on this information to load and execute U-Boot.
Only needed on 64-bit Allwinner boards so far when using boot0.
 
+config ARM_BOOT_HOOK_RMR
+   bool
+   default y if ARM64
+   select ENABLE_ARM_SOC_BOOT0_HOOK
+
 config DRAM_TYPE
int "sunxi dram type"
depends on MACH_SUN8I_A83T
-- 
2.8.2

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 12/23] sunxi: provide default DRAM config for sun50i in Kconfig

[Andre Przywara]

To avoid enumerating the very same DRAM values in defconfig files
for each and every Allwinner A64 board out there, let's put some sane
default values in the Kconfig file.
Boards with different needs can override them at any time.

Signed-off-by: Andre Przywara 
---
 board/sunxi/Kconfig   | 2 ++
 configs/pine64_plus_defconfig | 2 --
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index ba72e76..d477925 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -159,6 +159,7 @@ config DRAM_CLK
default 792 if MACH_SUN9I
default 312 if MACH_SUN6I || MACH_SUN8I
default 360 if MACH_SUN4I || MACH_SUN5I || MACH_SUN7I
+   default 672 if MACH_SUN50I
---help---
Set the dram clock speed, valid range 240 - 480 (prior to sun9i),
must be a multiple of 24. For the sun9i (A80), the tested values
@@ -178,6 +179,7 @@ config DRAM_ZQ
default 123 if MACH_SUN4I || MACH_SUN5I || MACH_SUN6I || MACH_SUN8I
default 127 if MACH_SUN7I
default 4145117 if MACH_SUN9I
+   default 3881915 if MACH_SUN50I
---help---
Set the dram zq value.
 
diff --git a/configs/pine64_plus_defconfig b/configs/pine64_plus_defconfig
index ea53b96..ebc24b8 100644
--- a/configs/pine64_plus_defconfig
+++ b/configs/pine64_plus_defconfig
@@ -2,8 +2,6 @@ CONFIG_ARM=y
 CONFIG_RESERVE_ALLWINNER_BOOT0_HEADER=y
 CONFIG_ARCH_SUNXI=y
 CONFIG_MACH_SUN50I=y
-CONFIG_DRAM_CLK=672
-CONFIG_DRAM_ZQ=3881915
 CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-pine64-plus"
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
 CONFIG_CONSOLE_MUX=y
-- 
2.8.2

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 09/23] ARM: boot0 hook: remove macro, include whole header file

[Andre Przywara]

For prepending some board specific header area to U-Boot images we
were so far including a header file with a macro definition containing
the actual header specification.
This works fine if there are just a few statements and if there is only
one alternative.
However adding more complex code quickly gets messy with this approach,
so let's just drop that intermediate macro and let the #include actually
insert the code directly.
This converts the callers and the callees, but doesn't change anything
at this point.

Signed-off-by: Andre Przywara 
---
 arch/arm/cpu/armv8/start.S | 1 -
 arch/arm/include/asm/arch-bcm235xx/boot0.h | 8 +---
 arch/arm/include/asm/arch-bcm281xx/boot0.h | 8 +---
 arch/arm/include/asm/arch-sunxi/boot0.h| 8 +---
 arch/arm/lib/vectors.S | 1 -
 5 files changed, 3 insertions(+), 23 deletions(-)

diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
index ee393d7..140609d 100644
--- a/arch/arm/cpu/armv8/start.S
+++ b/arch/arm/cpu/armv8/start.S
@@ -26,7 +26,6 @@ _start:
  * use it here.
  */
 #include 
-ARM_SOC_BOOT0_HOOK
 #else
b   reset
 #endif
diff --git a/arch/arm/include/asm/arch-bcm235xx/boot0.h 
b/arch/arm/include/asm/arch-bcm235xx/boot0.h
index 7e72882..9ff90b8 100644
--- a/arch/arm/include/asm/arch-bcm235xx/boot0.h
+++ b/arch/arm/include/asm/arch-bcm235xx/boot0.h
@@ -4,12 +4,6 @@
  * SPDX-License-Identifier:GPL-2.0+
  */
 
-#ifndef __BOOT0_H
-#define __BOOT0_H
-
 /* BOOT0 header information */
-#define ARM_SOC_BOOT0_HOOK \
-   .word   0xbabeface; \
+   .word   0xbabeface;
.word   _end - _start
-
-#endif /* __BOOT0_H */
diff --git a/arch/arm/include/asm/arch-bcm281xx/boot0.h 
b/arch/arm/include/asm/arch-bcm281xx/boot0.h
index 7e72882..9ff90b8 100644
--- a/arch/arm/include/asm/arch-bcm281xx/boot0.h
+++ b/arch/arm/include/asm/arch-bcm281xx/boot0.h
@@ -4,12 +4,6 @@
  * SPDX-License-Identifier:GPL-2.0+
  */
 
-#ifndef __BOOT0_H
-#define __BOOT0_H
-
 /* BOOT0 header information */
-#define ARM_SOC_BOOT0_HOOK \
-   .word   0xbabeface; \
+   .word   0xbabeface;
.word   _end - _start
-
-#endif /* __BOOT0_H */
diff --git a/arch/arm/include/asm/arch-sunxi/boot0.h 
b/arch/arm/include/asm/arch-sunxi/boot0.h
index 6f28d63..6a13db5 100644
--- a/arch/arm/include/asm/arch-sunxi/boot0.h
+++ b/arch/arm/include/asm/arch-sunxi/boot0.h
@@ -4,12 +4,6 @@
  * SPDX-License-Identifier:GPL-2.0+
  */
 
-#ifndef __BOOT0_H
-#define __BOOT0_H
-
 /* reserve space for BOOT0 header information */
-#define ARM_SOC_BOOT0_HOOK \
-   b   reset;  \
+   b   reset
.space  1532
-
-#endif /* __BOOT0_H */
diff --git a/arch/arm/lib/vectors.S b/arch/arm/lib/vectors.S
index 5cc132b..9fe7415 100644
--- a/arch/arm/lib/vectors.S
+++ b/arch/arm/lib/vectors.S
@@ -67,7 +67,6 @@ _start:
  * use it here.
  */
 #include 
-ARM_SOC_BOOT0_HOOK
 #endif
 
 /*
-- 
2.8.2

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 07/23] armv8: add simple sdelay implementation

[Andre Przywara]

The sunxi DRAM setup code needs an sdelay() implementation, which
wasn't defined for armv8 so far.
Shamelessly copy the armv7 version and adjust it to work in AArch64.

Signed-off-by: Andre Przywara 
---
 arch/arm/cpu/armv8/cpu.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/cpu/armv8/cpu.c b/arch/arm/cpu/armv8/cpu.c
index e06c3cc..0366ff4 100644
--- a/arch/arm/cpu/armv8/cpu.c
+++ b/arch/arm/cpu/armv8/cpu.c
@@ -16,6 +16,19 @@
 #include 
 #include 
 
+/
+ * sdelay() - simple spin loop.  Will be constant time as
+ *  its generally used in bypass conditions only.  This
+ *  is necessary until timers are accessible.
+ *
+ *  not inline to increase chances its in cache when called
+ */
+void sdelay(unsigned long loops)
+{
+   __asm__ volatile ("1:\n" "subs %0, %0, #1\n"
+ "b.ne 1b" : "=r" (loops) : "0"(loops) : "cc");
+}
+
 int cleanup_before_linux(void)
 {
/*
-- 
2.8.2

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 10/23] sunxi: introduce extra config option for boot0 header

[Andre Przywara]

The ENABLE_ARM_SOC_BOOT0_HOOK option is a generic option shared with
other boards. To allow alternative code to be inserted, we create
another, now function specific config symbol on top of it to simplify
later additions. No functional change at this time.

Signed-off-by: Andre Przywara 
---
 board/sunxi/Kconfig   | 9 +
 configs/pine64_plus_defconfig | 2 +-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index e1d4ab1..0cd57a2 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -133,6 +133,15 @@ config MACH_SUN8I
bool
default y if MACH_SUN8I_A23 || MACH_SUN8I_A33 || MACH_SUN8I_H3 || 
MACH_SUN8I_A83T
 
+config RESERVE_ALLWINNER_BOOT0_HEADER
+   bool "reserve space for Allwinner boot0 header"
+   select ENABLE_ARM_SOC_BOOT0_HOOK
+   ---help---
+   Prepend a 1536 byte (empty) header to the U-Boot image file, to be
+   filled with magic values post build. The Allwinner provided boot0
+   blob relies on this information to load and execute U-Boot.
+   Only needed on 64-bit Allwinner boards so far when using boot0.
+
 config DRAM_TYPE
int "sunxi dram type"
depends on MACH_SUN8I_A83T
diff --git a/configs/pine64_plus_defconfig b/configs/pine64_plus_defconfig
index 6d0198f..ea53b96 100644
--- a/configs/pine64_plus_defconfig
+++ b/configs/pine64_plus_defconfig
@@ -1,5 +1,5 @@
 CONFIG_ARM=y
-CONFIG_ENABLE_ARM_SOC_BOOT0_HOOK=y
+CONFIG_RESERVE_ALLWINNER_BOOT0_HEADER=y
 CONFIG_ARCH_SUNXI=y
 CONFIG_MACH_SUN50I=y
 CONFIG_DRAM_CLK=672
-- 
2.8.2

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 06/23] SPL: make struct spl_image 64-bit safe

[Andre Przywara]

Since entry_point and load_addr are addresses, they should be
represented as longs to cover the whole address space and to avoid
warning when compiling the SPL in 64-bit.
Also adjust debug prints to add the 'l' specifier, where needed.

Signed-off-by: Andre Przywara 
Reviewed-by: Alexander Graf 
---
 arch/arm/mach-omap2/boot-common.c | 2 +-
 arch/arm/mach-tegra/spl.c | 2 +-
 common/spl/spl.c  | 8 
 common/spl/spl_mmc.c  | 2 +-
 include/spl.h | 4 ++--
 5 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-omap2/boot-common.c 
b/arch/arm/mach-omap2/boot-common.c
index 385310b..7ae3d80 100644
--- a/arch/arm/mach-omap2/boot-common.c
+++ b/arch/arm/mach-omap2/boot-common.c
@@ -228,7 +228,7 @@ void __noreturn jump_to_image_no_args(struct spl_image_info 
*spl_image)
 
u32 boot_params = *((u32 *)OMAP_SRAM_SCRATCH_BOOT_PARAMS);
 
-   debug("image entry point: 0x%X\n", spl_image->entry_point);
+   debug("image entry point: 0x%lX\n", spl_image->entry_point);
/* Pass the saved boot_params from rom code */
image_entry((u32 *)boot_params);
 }
diff --git a/arch/arm/mach-tegra/spl.c b/arch/arm/mach-tegra/spl.c
index e0f9d5b..41c88cb 100644
--- a/arch/arm/mach-tegra/spl.c
+++ b/arch/arm/mach-tegra/spl.c
@@ -42,7 +42,7 @@ u32 spl_boot_device(void)
 
 void __noreturn jump_to_image_no_args(struct spl_image_info *spl_image)
 {
-   debug("image entry point: 0x%X\n", spl_image->entry_point);
+   debug("image entry point: 0x%lX\n", spl_image->entry_point);
 
start_cpu((u32)spl_image->entry_point);
halt_avp();
diff --git a/common/spl/spl.c b/common/spl/spl.c
index 32b9f1e..cda2f8a 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -115,7 +115,7 @@ int spl_parse_image_header(struct spl_image_info *spl_image,
}
spl_image->os = image_get_os(header);
spl_image->name = image_get_name(header);
-   debug("spl: payload image: %.*s load addr: 0x%x size: %d\n",
+   debug("spl: payload image: %.*s load addr: 0x%lx size: %d\n",
(int)sizeof(spl_image->name), spl_image->name,
spl_image->load_addr, spl_image->size);
} else {
@@ -140,7 +140,7 @@ int spl_parse_image_header(struct spl_image_info *spl_image,
spl_image->load_addr = CONFIG_SYS_LOAD_ADDR;
spl_image->entry_point = CONFIG_SYS_LOAD_ADDR;
spl_image->size = end - start;
-   debug("spl: payload zImage, load addr: 0x%x size: %d\n",
+   debug("spl: payload zImage, load addr: 0x%lx size: 
%d\n",
  spl_image->load_addr, spl_image->size);
return 0;
}
@@ -164,9 +164,9 @@ __weak void __noreturn jump_to_image_no_args(struct 
spl_image_info *spl_image)
typedef void __noreturn (*image_entry_noargs_t)(void);
 
image_entry_noargs_t image_entry =
-   (image_entry_noargs_t)(unsigned long)spl_image->entry_point;
+   (image_entry_noargs_t)spl_image->entry_point;
 
-   debug("image entry point: 0x%X\n", spl_image->entry_point);
+   debug("image entry point: 0x%lX\n", spl_image->entry_point);
image_entry();
 }
 
diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index 58b061f..9575d48 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -36,7 +36,7 @@ static int mmc_load_legacy(struct spl_image_info *spl_image, 
struct mmc *mmc,
/* Read the header too to avoid extra memcpy */
count = blk_dread(mmc_get_blk_desc(mmc), sector, image_size_sectors,
  (void *)(ulong)spl_image->load_addr);
-   debug("read %x sectors to %x\n", image_size_sectors,
+   debug("read %x sectors to %lx\n", image_size_sectors,
  spl_image->load_addr);
if (count != image_size_sectors)
return -EIO;
diff --git a/include/spl.h b/include/spl.h
index c727eb7..feadb33 100644
--- a/include/spl.h
+++ b/include/spl.h
@@ -23,8 +23,8 @@
 struct spl_image_info {
const char *name;
u8 os;
-   u32 load_addr;
-   u32 entry_point;
+   ulong load_addr;
+   ulong entry_point;
u32 size;
u32 flags;
 };
-- 
2.8.2

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 04/23] SPL: tiny-printf: add "l" modifier

[Andre Przywara]

tiny-printf does not know about the "l" modifier so far, which breaks
the crash dump on AArch64, because it uses %lx to print the registers.
Add an easy way of handling longs correctly. Also there are printfs
using the '-' modifier, which we choose to ignore for simplicity.

Using a relatively decent compiler (GCC 5.3.0) this does _not_ increase
the code size of tiny-printf.o for 32-bit builds (where long and int
are actually the same), actually it looses three (ARM Thumb2) instructions
from the actual SPL (numbers for orangepi_plus_defconfig):
  textdata bss dec hex filename
   758   0   0 758 2f6 spl/lib/tiny-printf.obefore
 18839 488 232   195594c67 spl/u-boot-spl   before
   758   0   0 758 2f6 spl/lib/tiny-printf.oafter
 18833 488 232   195534c61 spl/u-boot-spl   after

This adds some substantial amount of code to a 64-bit build, though:
(taken after a later commit, which enables the ARM64 SPL build for sunxi)
  textdata bss dec hex filename
  1542   0   01542 606 spl/lib/tiny-printf.obefore
 25830 392 360   2658267d6 spl/u-boot-spl   before
  1758   0   01758 6de spl/lib/tiny-printf.oafter
 26040 392 360   2679268a8 spl/u-boot-spl   after

Signed-off-by: Andre Przywara 
---
 lib/tiny-printf.c | 50 +++---
 1 file changed, 39 insertions(+), 11 deletions(-)

diff --git a/lib/tiny-printf.c b/lib/tiny-printf.c
index 30ac759..dfa8432 100644
--- a/lib/tiny-printf.c
+++ b/lib/tiny-printf.c
@@ -38,8 +38,8 @@ static void out_dgt(struct printf_info *info, char dgt)
info->zs = 1;
 }
 
-static void div_out(struct printf_info *info, unsigned int *num,
-   unsigned int div)
+static void div_out(struct printf_info *info, unsigned long *num,
+   unsigned long div)
 {
unsigned char dgt = 0;
 
@@ -56,9 +56,9 @@ int _vprintf(struct printf_info *info, const char *fmt, 
va_list va)
 {
char ch;
char *p;
-   unsigned int num;
+   unsigned long num;
char buf[12];
-   unsigned int div;
+   unsigned long div;
 
while ((ch = *(fmt++))) {
if (ch != '%') {
@@ -66,8 +66,12 @@ int _vprintf(struct printf_info *info, const char *fmt, 
va_list va)
} else {
bool lz = false;
int width = 0;
+   bool islong = false;
 
ch = *(fmt++);
+   if (ch == '-')
+   ch = *(fmt++);
+
if (ch == '0') {
ch = *(fmt++);
lz = 1;
@@ -80,6 +84,11 @@ int _vprintf(struct printf_info *info, const char *fmt, 
va_list va)
ch = *fmt++;
}
}
+   if (ch == 'l') {
+   ch = *(fmt++);
+   islong = true;
+   }
+
info->bf = buf;
p = info->bf;
info->zs = 0;
@@ -89,24 +98,43 @@ int _vprintf(struct printf_info *info, const char *fmt, 
va_list va)
goto abort;
case 'u':
case 'd':
-   num = va_arg(va, unsigned int);
-   if (ch == 'd' && (int)num < 0) {
-   num = -(int)num;
-   out(info, '-');
+   div = 10;
+   if (islong) {
+   num = va_arg(va, unsigned long);
+   if (sizeof(long) > 4)
+   div *= div * 10;
+   } else {
+   num = va_arg(va, unsigned int);
+   }
+
+   if (ch == 'd') {
+   if (islong && (long)num < 0) {
+   num = -(long)num;
+   out(info, '-');
+   } else if (!islong && (int)num < 0) {
+   num = -(int)num;
+   out(info, '-');
+   }
}
if (!num) {
out_dgt(info, 0);
} else {
-   for (div = 10; div; div /= 10)
+   

[U-Boot] [PATCH v2 05/23] move UL() macro from armv8/mmu.h into common.h

[Andre Przywara]

The UL() macro is pretty useful in sharing constants between assembly
and C files while still being able to specify a type for C.
Move the macro from an armv8 specific header into a common header file
to be able to use it by arm code (for instance) as well.

Signed-off-by: Andre Przywara 
Reviewed-by: Alexander Graf 
---
 arch/arm/include/asm/armv8/mmu.h |  8 
 include/common.h | 10 +-
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/arm/include/asm/armv8/mmu.h b/arch/arm/include/asm/armv8/mmu.h
index aa0f3c4..e9b4cdb 100644
--- a/arch/arm/include/asm/armv8/mmu.h
+++ b/arch/arm/include/asm/armv8/mmu.h
@@ -8,14 +8,6 @@
 #ifndef _ASM_ARMV8_MMU_H_
 #define _ASM_ARMV8_MMU_H_
 
-#ifdef __ASSEMBLY__
-#define _AC(X, Y)  X
-#else
-#define _AC(X, Y)  (X##Y)
-#endif
-
-#define UL(x)  _AC(x, UL)
-
 /***/
 /*
  * The following definitions are related each other, shoud be
diff --git a/include/common.h b/include/common.h
index a8d833b..5fcd5f5 100644
--- a/include/common.h
+++ b/include/common.h
@@ -15,6 +15,8 @@ typedef volatile unsigned longvu_long;
 typedef volatile unsigned short vu_short;
 typedef volatile unsigned char vu_char;
 
+#define _AC(X, Y)   (X##Y)
+
 #include 
 #include 
 #include 
@@ -936,7 +938,11 @@ int cpu_disable(int nr);
 int cpu_release(int nr, int argc, char * const argv[]);
 #endif
 
-#endif /* __ASSEMBLY__ */
+#else  /* __ASSEMBLY__ */
+
+#define _AC(X, Y)   X
+
+#endif /* __ASSEMBLY__ */
 
 #ifdef CONFIG_PPC
 /*
@@ -948,6 +954,8 @@ int cpu_release(int nr, int argc, char * const argv[]);
 
 /* Put only stuff here that the assembler can digest */
 
+#define UL(x)   _AC(x, UL)
+
 #ifdef CONFIG_POST
 #define CONFIG_HAS_POST
 #ifndef CONFIG_POST_ALT_LIST
-- 
2.8.2

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 00/23] sunxi: Allwinner A64: SPL support

[Andre Przywara]

Hi,

this is the second spin of the SPL support series for the Allwinner A64
SoC. Thanks for the review comments, I hope I addressed all of them.
As v1, this one includes support for both AArch64 and AArch32 SPL
builds. The FIT support is still missing, which means the functionality is
limited. Due to the missing ARM Trusted Firmware (ATF) in this firmware
chain we lose Ethernet and SMP, among other minor things.
A full 64-bit build can be written to an SD card as expected and will
boot the U-Boot proper prompt. However Linux will crash on boot, as
PSCI is missing.
Building the 32-bit version of the SPL and combining this with an ATF
build and the 64-bit U-Boot proper allows to use FEL booting now:
# sunxi-fel spl sunxi-spl.bin write 0x4a00 u-boot-dtb.bin \
  write 0x44000 bl31.bin reset64 0x44000

The first patch is a fix, which has been slightly tweaked compared to
v1 (see below).
Patch 2-7 prepare the SPL code to be compiled for 64-bit in general and
AArch64 in particular.
Patch 8-10 refactor the existing boot0 header functionality to be used
by patch 11, which introduces the 64-bit switch in the first SPL
instructions.
Patches 12-16 then introduce the actual core of the SPL support: the DRAM
initialization, courtesy of Jens. This piggy backs on the existing
H3 DRAM code, deviating where needed.
Patch 18 finally enables the 64-bit SPL support. So now building the
existing pine64_plus_defconfig will generate a sunxi-spl.bin, which
can be prepended to the U-Boot proper image (not .bin) to boot from
an SD card. Due to the missing ATF support this is of limited usability
at the moment, though. Also FEL support requires more love - to switch
back to AArch32 before returning to FEL (without crashing, that is ;-),
so this is disabled.
On my setup this results in a 26KB SPL binary, which is close to the
28K limit mksunxiboot imposes at the moment. Adding anything (like
FIT support or DEBUG) will exceed this, and although I have patches
to let mksunxiboot get close to 32KB, this is the ulimate frontier.

So patches 19-22 then teach the SPL how to detect an U-Boot image file
of a different bitness and do the RMR switch from AArch32 to AArch64,
if needed.
This is used by the final patch 23, which creates another _defconfig
to let the SPL compile for AArch32 using the Thumb2 encoding. This
results in a binary of less than 17KB in my case, so has plenty of
room for extensions.

Cheers,
Andre.

Changelog v1 .. v2:
- drop SPI build fix (already merged)
- confine A31 register init change to H3 and A64
- use IS_ENABLED() instead of #idef to guard MBUS2 clock init
- fix tiny-printf (proper sign extension for 32-bit integers)
- add "size" output in commit msg to document tiny-printf size impact
- fix sdelay(): use only one register, add "cc" clobber
- update RMR switch code to provide easy access to RVBAR register address
- drop redundant DRAM frequency setting from Pine64 defconfig
- minor changes as requested by reviewers

Andre Przywara (20):
  sun6i: Restrict some register initialization to Allwinner A31 SoC
  armv8: prevent using THUMB
  armv8: add lowlevel_init.S
  SPL: tiny-printf: add "l" modifier
  move UL() macro from armv8/mmu.h into common.h
  SPL: make struct spl_image 64-bit safe
  armv8: add simple sdelay implementation
  armv8: move reset branch into boot hook
  ARM: boot0 hook: remove macro, include whole header file
  sunxi: introduce extra config option for boot0 header
  sunxi: A64: do an RMR switch if started in AArch32 mode
  sunxi: provide default DRAM config for sun50i in Kconfig
  sunxi: H3/A64: fix non-ODT setting
  sunxi: DRAM: fix H3 DRAM size display on aarch64
  sunxi: A64: enable SPL
  SPL: read and store arch property from U-Boot image
  Makefile: use "arm64" architecture for U-Boot image files
  ARM: SPL/FIT: differentiate between arm and arm64 arch properties
  sunxi: introduce RMR switch to enter payloads in 64-bit mode
  sunxi: A64: add 32-bit SPL support

Jens Kuske (3):
  sunxi: H3: add and rename some DRAM contoller registers
  sunxi: H3: add DRAM controller single bit delay support
  sunxi: A64: use H3 DRAM initialization code for A64

 Makefile|   9 +-
 arch/arm/cpu/armv8/Makefile |   1 +
 arch/arm/cpu/armv8/cpu.c|  13 ++
 arch/arm/cpu/armv8/lowlevel_init.S  |  44 +
 arch/arm/cpu/armv8/start.S  |   5 +-
 arch/arm/include/asm/arch-bcm235xx/boot0.h  |   8 +-
 arch/arm/include/asm/arch-bcm281xx/boot0.h  |   8 +-
 arch/arm/include/asm/arch-sunxi/boot0.h |  34 +++-
 arch/arm/include/asm/arch-sunxi/clock_sun6i.h   |   1 +
 arch/arm/include/asm/arch-sunxi/dram.h  |   2 +-
 arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h |  51 +++---
 arch/arm/include/asm/armv8/mmu.h|   8 -
 arch/arm/lib/Makefile   |   2 +
 arch/arm/lib/spl.c  |  15 ++
 arch/arm/lib/vectors.S   

[U-Boot] [PATCH v2 03/23] armv8: add lowlevel_init.S

[Andre Przywara]

For boards that call s_init() when the SPL runs, we are expected to
setup an early stack before calling this C function.
Implement the proper AArch64 version of this based on the ARMv7 code.
This allows sunxi boards to setup the basic peripherals even on with a
64-bit SPL.

Signed-off-by: Andre Przywara 
---
 arch/arm/cpu/armv8/Makefile|  1 +
 arch/arm/cpu/armv8/lowlevel_init.S | 44 ++
 2 files changed, 45 insertions(+)
 create mode 100644 arch/arm/cpu/armv8/lowlevel_init.S

diff --git a/arch/arm/cpu/armv8/Makefile b/arch/arm/cpu/armv8/Makefile
index dea1465..799a752 100644
--- a/arch/arm/cpu/armv8/Makefile
+++ b/arch/arm/cpu/armv8/Makefile
@@ -25,3 +25,4 @@ obj-$(CONFIG_FSL_LAYERSCAPE) += fsl-layerscape/
 obj-$(CONFIG_S32V234) += s32v234/
 obj-$(CONFIG_ARCH_ZYNQMP) += zynqmp/
 obj-$(CONFIG_TARGET_HIKEY) += hisilicon/
+obj-$(CONFIG_ARCH_SUNXI) += lowlevel_init.o
diff --git a/arch/arm/cpu/armv8/lowlevel_init.S 
b/arch/arm/cpu/armv8/lowlevel_init.S
new file mode 100644
index 000..189e35f
--- /dev/null
+++ b/arch/arm/cpu/armv8/lowlevel_init.S
@@ -0,0 +1,44 @@
+/*
+ * A lowlevel_init function that sets up the stack to call a C function to
+ * perform further init.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+
+ENTRY(lowlevel_init)
+   /*
+* Setup a temporary stack. Global data is not available yet.
+*/
+#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_STACK)
+   ldr w0, =CONFIG_SPL_STACK
+#else
+   ldr w0, =CONFIG_SYS_INIT_SP_ADDR
+#endif
+   bic sp, x0, #0xf/* 16-byte alignment for ABI compliance */
+
+   /*
+* Save the old LR(passed in x29) and the current LR to stack
+*/
+   stp x29, x30, [sp, #-16]!
+
+   /*
+* Call the very early init function. This should do only the
+* absolute bare minimum to get started. It should not:
+*
+* - set up DRAM
+* - use global_data
+* - clear BSS
+* - try to start a console
+*
+* For boards with SPL this should be empty since SPL can do all of
+* this init in the SPL board_init_f() function which is called
+* immediately after this.
+*/
+   bl  s_init
+   ldp x29, x30, [sp]
+   ret
+ENDPROC(lowlevel_init)
-- 
2.8.2

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 02/23] armv8: prevent using THUMB

[Andre Przywara]

The predominantely 32-bit ARM targets try to compile the SPL in Thumb
mode to reduce code size.
The 64-bit AArch64 instruction set does not know an alternative, concise
encoding, so the Thumb build option should only be set for 32-bit
targets.
Likewise -marm machine options are only valid for ARMv7 targets.

Signed-off-by: Andre Przywara 
Reviewed-by: Alexander Graf 
---
 arch/arm/lib/Makefile  | 2 ++
 include/configs/sunxi-common.h | 2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 0051f76..024139d 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -77,8 +77,10 @@ ifndef CONFIG_HAS_THUMB2
 
 # for C files, just apend -marm, which will override previous -mthumb*
 
+ifndef CONFIG_ARM64
 CFLAGS_cache.o := -marm
 CFLAGS_cache-cp15.o := -marm
+endif
 
 # For .S, drop -mthumb* and other thumb-related options.
 # CFLAGS_REMOVE_* would not have an effet, so AFLAGS_REMOVE_*
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index b0bfc0d..e05c318 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -35,7 +35,7 @@
 /*
  * High Level Configuration Options
  */
-#ifdef CONFIG_SPL_BUILD
+#if defined(CONFIG_SPL_BUILD) && !defined(CONFIG_ARM64)
 #define CONFIG_SYS_THUMB_BUILD /* Thumbs mode to save space in SPL */
 #endif
 
-- 
2.8.2

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 01/23] sun6i: Restrict some register initialization to Allwinner A31 SoC

[Andre Przywara]

These days many Allwinner SoCs use clock_sun6i.c, although out of them
only the (original sun6i) A31 has a second MBUS clock register.
Also the requirement for setting up the PRCM PLL_CTLR1 register to provide
the proper voltage seems to be a property of older SoCs only as well.

Restrict the MBUS initialization to this SoC only to avoid writing bogus
values to (undefined) registers in other chips.
I can only verify that the PLL voltage setup is not needed for H3 and
A64, so for now we only spare those two SoCs.

Signed-off-by: Andre Przywara 
Reviewed-by: Alexander Graf 
Reviewed-by: Chen-Yu Tsai 
---
 arch/arm/mach-sunxi/clock_sun6i.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-sunxi/clock_sun6i.c 
b/arch/arm/mach-sunxi/clock_sun6i.c
index ed8cd9b..80cfc0b 100644
--- a/arch/arm/mach-sunxi/clock_sun6i.c
+++ b/arch/arm/mach-sunxi/clock_sun6i.c
@@ -21,6 +21,8 @@ void clock_init_safe(void)
 {
struct sunxi_ccm_reg * const ccm =
(struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
+
+#if !defined(CONFIG_MACH_SUN8I_H3) && !defined(CONFIG_MACH_SUN50I)
struct sunxi_prcm_reg * const prcm =
(struct sunxi_prcm_reg *)SUNXI_PRCM_BASE;
 
@@ -31,6 +33,7 @@ void clock_init_safe(void)
PRCM_PLL_CTRL_LDO_DIGITAL_EN | PRCM_PLL_CTRL_LDO_ANALOG_EN |
PRCM_PLL_CTRL_EXT_OSC_EN | PRCM_PLL_CTRL_LDO_OUT_L(1140));
clrbits_le32(>pll_ctrl1, PRCM_PLL_CTRL_LDO_KEY_MASK);
+#endif
 
clock_set_pll1(40800);
 
@@ -41,7 +44,8 @@ void clock_init_safe(void)
writel(AHB1_ABP1_DIV_DEFAULT, >ahb1_apb1_div);
 
writel(MBUS_CLK_DEFAULT, >mbus0_clk_cfg);
-   writel(MBUS_CLK_DEFAULT, >mbus1_clk_cfg);
+   if (IS_ENABLED(CONFIG_MACH_SUN6I))
+   writel(MBUS_CLK_DEFAULT, >mbus1_clk_cfg);
 }
 #endif
 
-- 
2.8.2

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 2/2] test/py: Create tests for ext4 and fat testing on sandbox

[Stefan Brüns]

From: Stefan Brüns 

The following checks are currently implemented:
1. listing a directory
2. verifying size of a file
3. veryfying md5sum for a file region
4. reading the beginning of a file

Signed-off-by: Stefan Brüns 
---
 test/py/tests/test_fs.py | 357 +++
 1 file changed, 357 insertions(+)
 create mode 100644 test/py/tests/test_fs.py

diff --git a/test/py/tests/test_fs.py b/test/py/tests/test_fs.py
new file mode 100644
index 00..7aaf8debaf
--- /dev/null
+++ b/test/py/tests/test_fs.py
@@ -0,0 +1,357 @@
+# Copyright (c) 2016, Stefan Bruens 
+#
+# SPDX-License-Identifier: GPL-2.0
+
+# Test U-Boot's filesystem implementations
+#
+# The tests are currently covering the ext4 and fat filesystem implementations.
+#
+# Following functionality is currently checked:
+# - Listing a directory and checking for a set of files
+# - Verifying the size of a file
+# - Reading sparse and non-sparse files
+# - File content verification using md5sums
+
+
+from distutils.spawn import find_executable
+import hashlib
+import pytest
+import os
+import random
+import re
+import u_boot_utils as util
+
+@pytest.fixture(scope='session')
+def prereq_commands():
+"""Detect required commands to run file system tests."""
+for command in ['mkfs', 'mount', 'umount']:
+if find_executable(command) is None:
+pytest.skip('Filesystem tests, "{0}" not in PATH'.format(command))
+
+"""
+Scenarios:
+hostfs: access image contents through the sandbox hostfs
+facility, using the filesytem implementation of
+the sandbox host, e.g. Linux kernel
+generic: test u-boots native filesystem implementations,
+using the 'generic' command names, e.g. 'load'
+TODO -
+fscommands: test u-boots native filesystem implementations,
+using the fs specific commands, e.g. 'ext4load'
+"""
+@pytest.fixture(scope='class', params=['generic', 'hostfs'])
+def scenario(request):
+request.cls.scenario = request.param
+return request.param
+
+
+"""
+Dictionary of files to use during filesystem tests. The files
+are keyed by the filenames. The value is an array of strides, each tuple
+contains the the start offset (inclusive) and end offset (exclusive).
+"""
+files = {
+'empty.file' : [(0, 0)],
+'1MB.file'   : [(0, 1e6)],
+'1MB.sparse.file'   : [(1e6-1, 1e6)],
+'32MB.sparse.file'   : [(0, 1e6), (4e6, 5e6), (31e6, 32e6)],
+# Creating a 2.5 GB file on FAT is exceptionally slow, disable it for now
+# '2_5GB.sparse.file'   : [(0, 1e6), (1e9, 1e9+1e6), (2.5e9-1e6, 2.5e9)],
+}
+
+"""Options to pass to mkfs."""
+mkfs_opts = {
+   'fat' :'-t vfat',
+   'ext4' : '-t ext4 -F',
+}
+
+class FsImage:
+def __init__(self, fstype, imagepath, mountpath):
+"""Create a new filesystem image.
+
+Args:
+fstype: filesystem type (string)
+imagepath: full path to image file
+mountpath: mountpoint directory
+"""
+self.fstype = fstype
+self.imagepath = imagepath
+self.mountpath = mountpath
+self.md5s = {}
+with open(self.imagepath, 'w') as fd:
+fd.truncate(0)
+fd.seek(3e9)
+fd.write(bytes([0]))
+
+def mkfs(self, log):
+mkfsopts = mkfs_opts.get(self.fstype)
+util.run_and_log(log,
+'mkfs {0} {1}'.format(mkfsopts, self.imagepath))
+
+def create_file(self, log, filename, strides):
+"""Create a single file in the filesystem. Each file
+is defined by one or more strides, which is filled with
+random data. For each stride, the md5sum is calculated
+and stored.
+"""
+md5sums = []
+with open(self.mountpath + '/' + filename, 'w') as fd:
+for stride in strides:
+length = int(stride[1] - stride[0])
+data = bytearray(random.getrandbits(8) for _ in xrange(length))
+md5 = hashlib.md5(data).hexdigest()
+md5sums.append(md5)
+log.info('{0}: write {1} bytes @ {2} : {3}'.format(
+filename, int(stride[1] - stride[0]),
+int(stride[0]), md5))
+fd.seek(stride[0])
+fd.write(data);
+self.md5s[filename] = md5sums
+
+def create_files(self, log):
+with log.section('Create initial files'):
+for filename in files:
+self.create_file(log, filename, files[filename])
+log.info('Created test files in "{0}"'.format(self.mountpath))
+util.run_and_log(log, 'ls -la {0}'.format(self.mountpath))
+util.run_and_log(log, 'sync {0}'.format(self.mountpath))
+
+def mount(self, log):
+if not os.path.exists(self.mountpath):
+os.mkdir(self.mountpath)
+log.info('Mounting {0} at 

[U-Boot] [PATCH v2 1/2] test/py: Allow to pass u_boot_log instead of console for run_and_log

[Stefan Brüns]

The runner actually has no console dependency, only on the log provided
by the console. Accept both u_boot_console or a multiplexed_log.

Signed-off-by: Stefan Brüns 
---
 test/py/u_boot_utils.py | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/test/py/u_boot_utils.py b/test/py/u_boot_utils.py
index 2ba4baed07..b9a72ab1de 100644
--- a/test/py/u_boot_utils.py
+++ b/test/py/u_boot_utils.py
@@ -153,11 +153,11 @@ def wait_until_file_open_fails(fn, ignore_errors):
 return
 raise Exception('File can still be opened')
 
-def run_and_log(u_boot_console, cmd, ignore_errors=False):
+def run_and_log(u_boot_console_or_log, cmd, ignore_errors=False):
 """Run a command and log its output.
 
 Args:
-u_boot_console: A console connection to U-Boot.
+u_boot_console_or_log: A console connection to U-Boot, or a LogFile.
 cmd: The command to run, as an array of argv[], or a string.
 If a string, note that it is split up so that quoted spaces
 will not be preserved. E.g. "fred and" becomes ['"fred', 'and"']
@@ -171,25 +171,33 @@ def run_and_log(u_boot_console, cmd, ignore_errors=False):
 """
 if isinstance(cmd, str):
 cmd = cmd.split()
-runner = u_boot_console.log.get_runner(cmd[0], sys.stdout)
+if hasattr(u_boot_console_or_log, 'get_runner'):
+get_runner = u_boot_console_or_log.get_runner
+else:
+get_runner = u_boot_console_or_log.log.get_runner
+runner = get_runner(cmd[0], sys.stdout)
 output = runner.run(cmd, ignore_errors=ignore_errors)
 runner.close()
 return output
 
-def run_and_log_expect_exception(u_boot_console, cmd, retcode, msg):
+def run_and_log_expect_exception(u_boot_console_or_log, cmd, retcode, msg):
 """Run a command that is expected to fail.
 
 This runs a command and checks that it fails with the expected return code
 and exception method. If not, an exception is raised.
 
 Args:
-u_boot_console: A console connection to U-Boot.
+u_boot_console_or_log: A console connection to U-Boot, or a LogFile.
 cmd: The command to run, as an array of argv[].
 retcode: Expected non-zero return code from the command.
 msg: String that should be contained within the command's output.
 """
+if hasattr(u_boot_console_or_log, 'get_runner'):
+get_runner = u_boot_console_or_log.get_runner
+else:
+get_runner = u_boot_console_or_log.log.get_runner
+runner = get_runner(cmd[0], sys.stdout)
 try:
-runner = u_boot_console.log.get_runner(cmd[0], sys.stdout)
 runner.run(cmd)
 except Exception as e:
 assert(retcode == runner.exit_status)
-- 
2.11.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] omap4_sdp4430: Disable SPL_OS_BOOT

[Tom Rini]

On Sun, Dec 04, 2016 at 05:21:14PM -0500, Tom Rini wrote:

> We are tight on space on this board so drop SPL_OS_BOOT
> 
> Signed-off-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, 9/9] ti_armv7_common: env: Increase IO buffer size

[Tom Rini]

On Fri, Nov 25, 2016 at 11:14:26AM +0530, Lokesh Vutla wrote:

> There are certain environment variables whose length is greater than
> the defined IO buffer size. So, increase the IO buffer size to print the
> entire variables.
> 
> Signed-off-by: Lokesh Vutla 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, 7/9] board: ti: am57xx: Add support for the am571x idk

[Tom Rini]

On Fri, Nov 25, 2016 at 11:14:24AM +0530, Lokesh Vutla wrote:

> From: Steve Kipisz 
> 
> The AM571x Industrial Development Kit (IDK) is a board based on TI's
> AM571x SoC which has a single core 1.5GHz Cortex-A15processor. This
> board is a development platform for the Industrial Market with:
> 
> - 1GB of DDR3L
> - Dual 1Gbps Ethernet
> - HDMI
> - PRU-ICSS
> - uSD
> - 16GB eMMC
> - CAN
> - RS-485
> - PCIe
> - USB3.0
> - Video Input Port
> - Industrial IO port and expansion connector
> 
> The PRU/ICSS will be supported by 3rd party software for EtherCat,
> Profibus, and other Industrial protocols.
> 
> The link to the data sheet and TRM can be found here:
> http://www.ti.com/product/AM5718
> 
> Signed-off-by: Steve Kipisz 
> Signed-off-by: Nishanth Menon 
> Signed-off-by: Lokesh Vutla 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot,8/9] ARM: dts: AM571x-IDK Initial Support

[Tom Rini]

On Fri, Nov 25, 2016 at 11:14:25AM +0530, Lokesh Vutla wrote:

> From: Schuyler Patton 
> 
> Add initial DTS support for AM571-IDK evm.
> 
> Signed-off-by: Schuyler Patton 
> Signed-off-by: Nishanth Menon 
> Signed-off-by: Lokesh Vutla 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, 6/9] board: ti: am572x-idk: Update pinmux using latest PMT

[Tom Rini]

On Fri, Nov 25, 2016 at 11:14:23AM +0530, Lokesh Vutla wrote:

> Update the board pinmux for AM572x-IDK board using latest PMT[1] and the
> board files named am572x_idk_v1p3b_sr2p0 that were autogenerated on
> 20th October, 2016 by "Steve Kipisz " and
> "Tom Johnson ".
> 
> [1] https://dev.ti.com/pinmux/app.html#/default/
> 
> Signed-off-by: Nishanth Menon 
> Signed-off-by: Lokesh Vutla 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, 5/9] board: ti: am572x: Add pinmux for X15/GPEVM SR2.0 using latest PMT

[Tom Rini]

On Fri, Nov 25, 2016 at 11:14:22AM +0530, Lokesh Vutla wrote:

> From: Nishanth Menon 
> 
> Update the board pinmux for AM572x-IDK board using latest PMT[1] and the
> board files named am572x_gp_evm_A3a_sr2p0 that were autogenerated on
> 19th October, 2016 by "Ahmad Rashed".
> 
> [1] https://dev.ti.com/pinmux/app.html#/default/
> 
> Signed-off-by: Nishanth Menon 
> Signed-off-by: Lokesh Vutla 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, 4/9] board: ti: am57xx: Update SR1.1 RGMII0 iodelay timings for x15/GPEVM

[Tom Rini]

On Fri, Nov 25, 2016 at 11:14:21AM +0530, Lokesh Vutla wrote:

> From: Nishanth Menon 
> 
> Update the timing for RGMII0 interface based on
> PCT_DRA75x_DRA74x_SR1.1_v1.3.10 version (Jan 2016). This update
> is for SR1.1
> 
> Signed-off-by: Nishanth Menon 
> Signed-off-by: Lokesh Vutla 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, 3/9] board: ti: am57xx: Add support for detection of X15 revb1

[Tom Rini]

On Fri, Nov 25, 2016 at 11:14:20AM +0530, Lokesh Vutla wrote:

> BeagleBoard-X15 Rev B1 with SR1.1 platform have incompatible changes for HDMI
> GPIO requiring new dtb support. This implies we have to properly identify
> the platform now as well. Hence provide a different board name for the
> Rev B1 variants.
> 
> Signed-off-by: Lokesh Vutla 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, 2/9] board: ti: am57xx: Add support for detection of reva3 variations for GPEVM

[Tom Rini]

On Fri, Nov 25, 2016 at 11:14:19AM +0530, Lokesh Vutla wrote:

> From: Nishanth Menon 
> 
> AM57xx evm Rev A3 with SR2.0 platform have incompatible changes for HDMI
> GPIO requiring new dtb support. This implies we have to properly identify
> the platform now as well. Hence provide a different board name for the
> Rev A3 variations.
> 
> Signed-off-by: Nishanth Menon 
> Signed-off-by: Lokesh Vutla 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, 1/9] ARM: dts: am57xx: sync DT with latest Linux

[Tom Rini]

On Fri, Nov 25, 2016 at 11:14:18AM +0530, Lokesh Vutla wrote:

> Sync all am57xx based dts files with latest Linux
> 
> Signed-off-by: Lokesh Vutla 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot,v2,3/4] arm: Remove VCMA9 board

[Tom Rini]

On Wed, Nov 23, 2016 at 06:01:31AM -0700, Simon Glass wrote:

> This board has not been converted to DM_SERIAL by the deadline.
> Remove it.
> 
> Signed-off-by: Simon Glass 
> Acked-by: David Müller 
> Reviewed-by: Jagan Teki 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v2, 4/4] serial: Drop the s3c24x0 serial driver

[Tom Rini]

On Wed, Nov 23, 2016 at 06:01:32AM -0700, Simon Glass wrote:

> This is not used by any boards. Drop it.
> 
> Signed-off-by: Simon Glass 
> Acked-by: David Müller 
> Reviewed-by: Jagan Teki 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot,v2,2/4] arm: Remove smdk2410 board

[Tom Rini]

On Wed, Nov 23, 2016 at 06:01:30AM -0700, Simon Glass wrote:

> This board has not been converted to DM_SERIAL by the deadline.
> Remove it.
> 
> Signed-off-by: Simon Glass 
> Acked-by: David Müller 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v2, 1/4] serial: Update docs to indicate mcfuart supports DM_SERIAL

[Tom Rini]

On Wed, Nov 23, 2016 at 06:01:29AM -0700, Simon Glass wrote:

> This driver was converted so we should remove it from the list.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] post: cosmetic: fix typo

[Tom Rini]

On Wed, Nov 23, 2016 at 02:52:32PM +0200, tomas.me...@vaisala.com wrote:

> From: Niko Mauno 
> 
> Change 'date' to 'data'.
> 
> Signed-off-by: Tomas Melin 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot,11/11] configs: dra7xx: Enable lp873x options

[Tom Rini]

On Wed, Nov 23, 2016 at 01:25:34PM +0530, Lokesh Vutla wrote:

> From: Keerthy 
> 
> DRA71-evm uses LP873x regulator. Enable lp873x PMIC config options.
> 
> Signed-off-by: Keerthy 
> Signed-off-by: Lokesh Vutla 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, 10/11] configs: dra7xx: Enable pmic/regulator options

[Tom Rini]

On Wed, Nov 23, 2016 at 01:25:33PM +0530, Lokesh Vutla wrote:

> Enable pmic/regulator config options.
> 
> Signed-off-by: Lokesh Vutla 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot,09/11] configs: dra7xx: hs: Enable DM_ETH

[Tom Rini]

On Wed, Nov 23, 2016 at 01:25:32PM +0530, Lokesh Vutla wrote:

> Enable DM_ETH for hs boards.
> 
> Signed-off-by: Lokesh Vutla 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, 08/11] configs: ti_omap5_common: Select dtb name for dra71x

[Tom Rini]

On Wed, Nov 23, 2016 at 01:25:31PM +0530, Lokesh Vutla wrote:

> From: Nishanth Menon 
> 
> Select dtb name for dra71x-evm.
> 
> Signed-off-by: Nishanth Menon 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot,07/11] ARM: dts: dra71x-evm: Add DT support

[Tom Rini]

On Wed, Nov 23, 2016 at 01:25:30PM +0530, Lokesh Vutla wrote:

> Add DT support for dra71-evm and built it as part of FIT image.
> 
> Signed-off-by: Lokesh Vutla 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, 06/11] ARM: dts: dra7xx: sync DT with latest Linux

[Tom Rini]

On Wed, Nov 23, 2016 at 01:25:29PM +0530, Lokesh Vutla wrote:

> Sync all dra7xx based dts files with latest Linux
> 
> Signed-off-by: Lokesh Vutla 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, 04/11] board: ti: dra71x-evm: Add PMIC support

[Tom Rini]

On Wed, Nov 23, 2016 at 01:25:27PM +0530, Lokesh Vutla wrote:

> From: Keerthy 
> 
> Add the pmic_data for LP873x PMIC which is used to power
> up dra71x-evm.
> 
> Note: As per the DM[1] DRA71x supports only OP_NOM. So, updating
> the efuse registers only to use OPP_NOM irrespective of any
> CONFIG_DRA7__OPP_{NOM,od,high} is defined.
> 
> [1] http://www.ti.com/product/DRA718/technicaldocuments
> 
> Signed-off-by: Keerthy 
> Signed-off-by: Lokesh Vutla 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, 05/11] ARM: OMAP4+: Add support for getting pbias info from board

[Tom Rini]

On Wed, Nov 23, 2016 at 01:25:28PM +0530, Lokesh Vutla wrote:

> Palmas driver assumes it is always TPS659xx regulator on all DRA7xx based
> boards to enable mmc regulator. This is not true always like in case of
> DRA71x-evm. So get this information based on the board.
> 
> Signed-off-by: Lokesh Vutla 
> Signed-off-by: Vignesh R 
> Signed-off-by: Nishanth Menon 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, 03/11] board: ti: dra72: Introduce optimization for rgmii timing for rev C

[Tom Rini]

On Wed, Nov 23, 2016 at 01:25:26PM +0530, Lokesh Vutla wrote:

> From: Nishanth Menon 
> 
> Rev C version of EVM does require IODelay to be configured for RGMII
> pins in MANUAL_1 configuration. Update the same based on PG2.0 initial
> simulation values.
> Data based on PCT_DRA72x_SR2.0_SR1.0_v1.3.0.7
> 
> Signed-off-by: Nishanth Menon 
> Signed-off-by: Lokesh Vutla 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, 02/11] board: ti: dra71x-evm: Add mux settings

[Tom Rini]

On Wed, Nov 23, 2016 at 01:25:25PM +0530, Lokesh Vutla wrote:

> Add mux and iodelay settings for dra71x-evm.
> Data generated using PCT_DRA71x_SR2.0_v1.0.0.0 version (June 2016).
> 
> Signed-off-by: Lokesh Vutla 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, 01/11] board: ti: dra71x-evm: Add epprom support

[Tom Rini]

On Wed, Nov 23, 2016 at 01:25:24PM +0530, Lokesh Vutla wrote:

> The dra71x-evm is a board based on TI's DRA718 processor targeting 
> BOM-optimized
> entry infotainment systems such as display audio and is a software compatible
> derivative of the highly successful DRA74 and DRA72 processor families.
> More information can be found here[1].
> 
> Add epprom detection for dra71-evm.
> 
> [1] http://www.ti.com/product/dra718
> 
> Signed-off-by: Lokesh Vutla 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v2, 3/3] ARM: DRA7: Fixup DSPEVE, IVA and GPU clock frequencies based on OPP

[Tom Rini]

On Wed, Nov 23, 2016 at 12:54:41PM +0530, Lokesh Vutla wrote:

> From: Suman Anna 
> 
> This patch adds support to update the device-tree blob to adjust the
> DSP and IVA DPLL clocks pertinent to the selected OPP choice, with
> the default being OPP_NOM. The voltage settings are done in u-boot,
> but the actual clock configuration itself is done in kernel because
> of the following reasons:
> 1. SoC definition constraints us to NOT to do dynamic voltage
>scaling ever after the initial avs0 setting in bootloader
>- so the voltage must be set in bootloader.
> 2. The voltage level must be set even if the IP blocks like
>GPU/DSP are unused.
> 3. The IVA, GPU and DSP DPLLs are not essential for u-boot functionality,
>and similar DPLL clock configuration code has been cleaned up in
>v2014.10 u-boot release. See commit, 02c41535b6a4 ("ARM: OMAP4/5:
>Remove dead code against CONFIG_SYS_CLOCKS_ENABLE_ALL").
> 
> The non-essential DPLLs are configured within the kernel during
> the clock init step when parsing the device tree and creating
> the clock devices. This approach meets both the u-boot and kernel
> needs.
> 
> Signed-off-by: Suman Anna 
> Signed-off-by: Subhajit Paul 
> Signed-off-by: Lokesh Vutla 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v2, 2/3] ARM: DRA7: Redefine voltage and efuse macros per OPP using Kconfig

[Tom Rini]

On Wed, Nov 23, 2016 at 12:54:40PM +0530, Lokesh Vutla wrote:

> From: Suman Anna 
> 
> Redefine the macros used to define the voltage values and the
> efuse register offsets based on OPP for all the voltage domains.
> This is done using Kconfig macros that can be set in a defconfig
> or selected during a config step. This allows a voltage domain
> to be configured/set to a corresponding voltage value depending
> on the OPP selection choice.
> 
> The Kconfig choices have been added for MPU, DSPEVE, IVA and GPU
> voltage domains, with the MPU domain restricted to OPP_NOM. The
> OPP_OD and OPP_HIGH options will be added when the support for
> configuring the MPU clock frequency is added. The clock
> configuration for other voltage domains is out of scope in
> u-boot code.
> 
> The CORE voltage domain does not have separate voltage values
> and efuse register offset at different OPPs, while the MPU
> voltage domain only has different efuse register offsets for
> different OPPs, but uses the same voltage value. Any different
> choices of OPPs for voltage domains on common ganged-rails
> is automatically taken care to select the corresponding
> highest OPP voltage value.
> 
> Signed-off-by: Suman Anna 
> Signed-off-by: Lokesh Vutla 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v2, 1/3] ARM: OMAP4+: Add support for dynamically selecting OPPs

[Tom Rini]

On Wed, Nov 23, 2016 at 12:54:39PM +0530, Lokesh Vutla wrote:

> It can be expected that different paper spins of a SoC can have
> different definitions for OPP and can have their own constraints
> on the boot up OPP for each voltage rail. In order to have this
> flexibility, add support for dynamically selecting the OPP voltage
> based on the board to handle any such exceptions.
> 
> Signed-off-by: Lokesh Vutla 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, U-BOOT, TEST, 5/5] Cosmetic api: api_storage.c Spelling correction

[Tom Rini]

On Wed, Nov 23, 2016 at 01:26:14AM -0500, Walt Feasel wrote:

> Make spelling correction for 'from'
> 
> Signed-off-by: Walt Feasel 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, U-BOOT, TEST, 4/5] Cosmetic api: api_storage.c Comment style

[Tom Rini]

On Wed, Nov 23, 2016 at 01:26:13AM -0500, Walt Feasel wrote:

> Make comment style modifications
> 
> Signed-off-by: Walt Feasel 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, U-BOOT, TEST, 3/5] Cosmetic api: api_storage.c Line over 80 char

[Tom Rini]

On Wed, Nov 23, 2016 at 01:26:12AM -0500, Walt Feasel wrote:

> Make checkpatch style modification for
> WARNING: line over 80 characters
> 
> Signed-off-by: Walt Feasel 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, U-BOOT, TEST, 2/5] Cosmetic api: api_storage.c Blank line after {

[Tom Rini]

On Wed, Nov 23, 2016 at 01:26:11AM -0500, Walt Feasel wrote:

> Make checkpatch style modification for
> CHECK: Blank lines aren't necessary after
> an open brace '{'
> 
> Signed-off-by: Walt Feasel 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot