Re: [U-Boot] [PATCH 2/2] armv8: add asserts of sizes to u-boot-spl.lds

[Masahiro Yamada]

2016-12-26 23:20 GMT+09:00 Oded Gabbay :
> This patch copies from arm u-boot-spl.lds some asserts that check that the
> size of the SPL image and BSS doesn't violate their max size.
>
> Signed-off-by: Oded Gabbay 
> Cc: Albert Aribaud 
> ---
>  arch/arm/cpu/armv8/u-boot-spl.lds | 19 +++
>  1 file changed, 19 insertions(+)
>
> diff --git a/arch/arm/cpu/armv8/u-boot-spl.lds 
> b/arch/arm/cpu/armv8/u-boot-spl.lds
> index e7799cc..0876a94 100644
> --- a/arch/arm/cpu/armv8/u-boot-spl.lds
> +++ b/arch/arm/cpu/armv8/u-boot-spl.lds
> @@ -78,3 +78,22 @@ SECTIONS
> /DISCARD/ : { *(.interp*) }
> /DISCARD/ : { *(.gnu*) }
>  }
> +
> +#if defined(CONFIG_SPL_MAX_SIZE)
> +ASSERT(__image_copy_end - __image_copy_start < (CONFIG_SPL_MAX_SIZE), \
> +   "SPL image too big");
> +#endif
> +
> +#if defined(CONFIG_SPL_BSS_MAX_SIZE) && defined(CONFIG_SPL_MAX_FOOTPRINT)
> +ASSERT(0, "CONFIG_SPL_BSS_MAX_SIZE and CONFIG_SPL_MAX_FOOTPRINT must not be 
> defined together");
> +#endif
> +
> +#if defined(CONFIG_SPL_BSS_MAX_SIZE)
> +ASSERT(__bss_end - __bss_start < (CONFIG_SPL_BSS_MAX_SIZE), \
> +   "SPL image BSS too big");
> +#endif
> +
> +#if defined(CONFIG_SPL_MAX_FOOTPRINT)
> +ASSERT(__bss_end - _start < (CONFIG_SPL_MAX_FOOTPRINT), \
> +   "SPL image plus BSS too big");
> +#endif
> --
> 2.7.4
>

This patch is wrong in multiple ways.



See the top lines of this file.

MEMORY { .sram : ORIGIN = CONFIG_SPL_TEXT_BASE,
 LENGTH = CONFIG_SPL_MAX_SIZE }
MEMORY { .sdram : ORIGIN = CONFIG_SPL_BSS_START_ADDR,
 LENGTH = CONFIG_SPL_BSS_MAX_SIZE }

This means CONFIG_SPL_BSS_MAX_SIZE must always be defined.




Your code

> +#if defined(CONFIG_SPL_BSS_MAX_SIZE) && defined(CONFIG_SPL_MAX_FOOTPRINT)
> +ASSERT(0, "CONFIG_SPL_BSS_MAX_SIZE and CONFIG_SPL_MAX_FOOTPRINT must not be 
> defined together");
> +#endif

... means CONFIG_SPL_BSS_MAX_FOOTPRINT can never be defined.


As a result,

> +#if defined(CONFIG_SPL_BSS_MAX_SIZE)
> +ASSERT(__bss_end - __bss_start < (CONFIG_SPL_BSS_MAX_SIZE), \
> +   "SPL image BSS too big");
> +#endif

the ifdef is always true, so meaningless.

> +ASSERT(__bss_end - __bss_start < (CONFIG_SPL_BSS_MAX_SIZE), \
> +   "SPL image BSS too big");

is already size-checked by the following:

MEMORY { .sdram : ORIGIN = CONFIG_SPL_BSS_START_ADDR,
 LENGTH = CONFIG_SPL_BSS_MAX_SIZE }


so, meaningless.


> +#if defined(CONFIG_SPL_MAX_FOOTPRINT)
> +ASSERT(__bss_end - _start < (CONFIG_SPL_MAX_FOOTPRINT), \
> +   "SPL image plus BSS too big");
> +#endif

This code is never enabled.



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

[U-Boot] [PATCH v2 1/2] powerpc: mpc83xx: Minimize r1 modification

[Mario Six]

The r1 register is modified several times during the cache-ram setup of
the MPC83xx SoCs.

Since this SP modification confuses debuggers, we use a general purpose
register to compute the new stack pointer value, and only set the SP
once after all computations are done.

Signed-off-by: Mario Six 
---

Changes in v2:

Patch added (following a suggestion by Joakim Tjernlund)

---
 arch/powerpc/cpu/mpc83xx/start.S | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/cpu/mpc83xx/start.S b/arch/powerpc/cpu/mpc83xx/start.S
index 0001687703..c366f615e7 100644
--- a/arch/powerpc/cpu/mpc83xx/start.S
+++ b/arch/powerpc/cpu/mpc83xx/start.S
@@ -258,14 +258,17 @@ in_flash:
 #endif

/* set up the stack pointer in our newly created
-* cache-ram (r1) */
-   lis r1, (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_GBL_DATA_OFFSET)@h
-   ori r1, r1, (CONFIG_SYS_INIT_RAM_ADDR + 
CONFIG_SYS_GBL_DATA_OFFSET)@l
+* cache-ram; use r3 to keep the new SP for now to
+* avoid overiding the SP it uselessly */
+   lis r3, (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_GBL_DATA_OFFSET)@h
+   ori r3, r3, (CONFIG_SYS_INIT_RAM_ADDR + 
CONFIG_SYS_GBL_DATA_OFFSET)@l

li  r0, 0   /* Make room for stack frame header and */
-   stwur0, -4(r1)  /* clear final stack frame so that  */
-   stwur0, -4(r1)  /* stack backtraces terminate cleanly   */
+   stwur0, -4(r3)  /* clear final stack frame so that  */
+   stwur0, -4(r3)  /* stack backtraces terminate cleanly   */

+   /* Finally, actually set SP */
+   mr  r1, r3

/* let the C-code set up the rest   */
/*  */
--
2.11.0

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

[U-Boot] [PATCH v2 2/2] powerpc: mpc83xx: Enable pre-relocation malloc

[Mario Six]

To enable DM on MPC83xx, we need pre-relocation malloc, which is
implemented in this patch.

Signed-off-by: Mario Six 
---

Changes in v2:

* Switched to r3 to hold SP modifications (as suggested by Joakim Tjernlund)

---
 arch/powerpc/cpu/mpc83xx/cpu_init.c|  3 +--
 arch/powerpc/cpu/mpc83xx/spl_minimal.c |  4 +---
 arch/powerpc/cpu/mpc83xx/start.S   | 23 +++
 3 files changed, 25 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/cpu/mpc83xx/cpu_init.c 
b/arch/powerpc/cpu/mpc83xx/cpu_init.c
index f911275b25..3a0916bdbf 100644
--- a/arch/powerpc/cpu/mpc83xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc83xx/cpu_init.c
@@ -205,8 +205,7 @@ void cpu_init_f (volatile immap_t * im)
/* Pointer is writable since we allocated a register for it */
gd = (gd_t *) (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_GBL_DATA_OFFSET);

-   /* Clear initial global data */
-   memset ((void *) gd, 0, sizeof (gd_t));
+   /* global data region was cleared in start.S */

/* system performance tweaking */
clrsetbits_be32(>arbiter.acr, acr_mask, acr_val);
diff --git a/arch/powerpc/cpu/mpc83xx/spl_minimal.c 
b/arch/powerpc/cpu/mpc83xx/spl_minimal.c
index 845861eea7..026da12e66 100644
--- a/arch/powerpc/cpu/mpc83xx/spl_minimal.c
+++ b/arch/powerpc/cpu/mpc83xx/spl_minimal.c
@@ -23,9 +23,7 @@ void cpu_init_f (volatile immap_t * im)
/* Pointer is writable since we allocated a register for it */
gd = (gd_t *) (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_GBL_DATA_OFFSET);

-   /* Clear initial global data */
-   for (i = 0; i < sizeof(gd_t); i++)
-   ((char *)gd)[i] = 0;
+   /* global data region was cleared in start.S */

/* system performance tweaking */

diff --git a/arch/powerpc/cpu/mpc83xx/start.S b/arch/powerpc/cpu/mpc83xx/start.S
index c366f615e7..ff312892bc 100644
--- a/arch/powerpc/cpu/mpc83xx/start.S
+++ b/arch/powerpc/cpu/mpc83xx/start.S
@@ -263,6 +263,29 @@ in_flash:
lis r3, (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_GBL_DATA_OFFSET)@h
ori r3, r3, (CONFIG_SYS_INIT_RAM_ADDR + 
CONFIG_SYS_GBL_DATA_OFFSET)@l

+   /* r4 = end of GD area */
+   addi r4, r3, GENERATED_GBL_DATA_SIZE
+
+   /* Zero GD area */
+   li  r0, 0
+1:
+   subir4, r4, 1
+   stb r0, 0(r4)
+   cmplw   r3, r4
+   bne 1b
+
+#ifdef CONFIG_SYS_MALLOC_F_LEN
+
+#if CONFIG_SYS_MALLOC_F_LEN + GENERATED_GBL_DATA_SIZE > 
CONFIG_SYS_INIT_RAM_SIZE
+#error "CONFIG_SYS_MALLOC_F_LEN too large to fit into initial RAM."
+#endif
+
+   /* r3 = new stack pointer / pre-reloc malloc area */
+   subir3, r3, CONFIG_SYS_MALLOC_F_LEN
+
+   /* Set pointer to pre-reloc malloc area in GD */
+   stw r3, GD_MALLOC_BASE(r4)
+#endif
li  r0, 0   /* Make room for stack frame header and */
stwur0, -4(r3)  /* clear final stack frame so that  */
stwur0, -4(r3)  /* stack backtraces terminate cleanly   */
--
2.11.0

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

Re: [U-Boot] [PATCH] spl: don't use %.*s with CONFIG_USE_TINY_PRINTF

[Masahiro Yamada]

2016-12-28 16:36 GMT+09:00 Oded Gabbay :
> In the tiny-printf implementation, there is no support for %.*s. This patch
> checks if CONFIG_USE_TINY_PRINTF is defined and if so, prints a different
> debug statement which doesn't use %.*s
>
> Signed-off-by: Oded Gabbay 
> Cc: Simon Glass 
> ---
>  common/spl/spl.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/common/spl/spl.c b/common/spl/spl.c
> index f7df834..7c4744d 100644
> --- a/common/spl/spl.c
> +++ b/common/spl/spl.c
> @@ -115,9 +115,14 @@ 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);
> +#ifdef CONFIG_USE_TINY_PRINTF
> +   debug("spl: payload image: %s load addr: 0x%x size: %d\n",
> +   spl_image->name, spl_image->load_addr, 
> spl_image->size);
> +#else
> debug("spl: payload image: %.*s load addr: 0x%x size: %d\n",
> (int)sizeof(spl_image->name), spl_image->name,
> spl_image->load_addr, spl_image->size);
> +#endif
> } else {
>  #ifdef CONFIG_SPL_PANIC_ON_RAW_IMAGE


Same here.

Please do not patch around with CONFIG_USE_TINY_PRINTF.

What you need to do is to fix tiny_printf() implementation.


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

Re: [U-Boot] [PATCH] spl: don't use %#l with CONFIG_USE_TINY_PRINTF

[Masahiro Yamada]

2016-12-28 17:12 GMT+09:00 Oded Gabbay :
> In the tiny-printf implementation, there is no support for %# and/or %l. This
> patch checks if CONFIG_USE_TINY_PRINTF is defined and if so, prints a
> different debug statement which doesn't use %#l
>
> Signed-off-by: Oded Gabbay 
> Cc: Simon Glass 
> ---
>  common/spl/spl.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/common/spl/spl.c b/common/spl/spl.c
> index f7df834..23dfa2d 100644
> --- a/common/spl/spl.c
> +++ b/common/spl/spl.c
> @@ -385,9 +385,14 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
> debug("Unsupported OS image.. Jumping nevertheless..\n");
> }
>  #if defined(CONFIG_SYS_MALLOC_F_LEN) && !defined(CONFIG_SYS_SPL_MALLOC_SIZE)
> +#ifdef CONFIG_USE_TINY_PRINTF
> +   debug("SPL malloc() used 0x%x bytes (%d KB)\n",
> +   (uint) gd->malloc_ptr, (uint) gd->malloc_ptr / 1024);
> +#else
> debug("SPL malloc() used %#lx bytes (%ld KB)\n", gd->malloc_ptr,
>   gd->malloc_ptr / 1024);
>  #endif
> +#endif
>


Please do not patch around with CONFIG_USE_TINY_PRINTF.

What you need to do is to fix tiny_printf() implementation.


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

Re: [U-Boot] [PATCH] powerpc: mpc83xx: Enable pre-relocation malloc

[Mario Six]

I'll take a look at the places where r1 is modified and send a v2.

On Mon, Jan 16, 2017 at 11:00 PM, york sun  wrote:
> On 01/06/2017 08:32 AM, Joakim Tjernlund wrote:
>> On Fri, 2017-01-06 at 14:56 +0100, Mario Six wrote:
>>> To enable DM on MPC83xx, we need pre-relocation malloc, which is
>>> implemented in this patch.
>>>
>>
>> Would be nice if you could avoid using r1, each time you modify r1 gdb will 
>> be
>> upset/confused if you ever try to debug start.S with gdb.
>>
>> I guess the whole file need a bit of trimming to avoid using r1 but one has 
>> to start somewhere.
>>
>>  Jocke
>>
>
> Guys,
>
> I am not a mpc83xx maintainer. If the patch is agreed, I can bring it in
> with mpc85xx. If r1 needs some rework, please continue.
>
> York
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [v4, 1/3] mmc: fsl_esdhc: move 'status' property fixup into a weak function

[Yangbo Lu]

Move fdt fixup of 'status' property into a weak function. This allows
board to define 'status' fdt fixup by themselves.

Signed-off-by: Yangbo Lu 
---
Changes for v2:
- None
Changes for v3:
- None
Changes for v4:
- None
---
 drivers/mmc/fsl_esdhc.c | 21 ++---
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index 0ae1cfd..7b7863f 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -911,17 +911,26 @@ void mmc_adapter_card_type_ident(void)
 #endif
 
 #ifdef CONFIG_OF_LIBFDT
-void fdt_fixup_esdhc(void *blob, bd_t *bd)
+__weak int esdhc_status_fixup(void *blob, const char *compat)
 {
-   const char *compat = "fsl,esdhc";
-
 #ifdef CONFIG_FSL_ESDHC_PIN_MUX
if (!hwconfig("esdhc")) {
do_fixup_by_compat(blob, compat, "status", "disabled",
-   8 + 1, 1);
-   return;
+   sizeof("disabled"), 1);
+   return 1;
}
 #endif
+   do_fixup_by_compat(blob, compat, "status", "okay",
+  sizeof("okay"), 1);
+   return 0;
+}
+
+void fdt_fixup_esdhc(void *blob, bd_t *bd)
+{
+   const char *compat = "fsl,esdhc";
+
+   if (esdhc_status_fixup(blob, compat))
+   return;
 
 #ifdef CONFIG_FSL_ESDHC_USE_PERIPHERAL_CLK
do_fixup_by_compat_u32(blob, compat, "peripheral-frequency",
@@ -934,8 +943,6 @@ void fdt_fixup_esdhc(void *blob, bd_t *bd)
do_fixup_by_compat_u32(blob, compat, "adapter-type",
   (u32)(gd->arch.sdhc_adapter), 1);
 #endif
-   do_fixup_by_compat(blob, compat, "status", "okay",
-  4 + 1, 1);
 }
 #endif
 
-- 
2.1.0.27.g96db324

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

Re: [U-Boot] [PATCH v3 62/62] x86: link: Add a config for 64-bit U-Boot

[Bin Meng]

On Mon, Jan 16, 2017 at 10:04 PM, Simon Glass  wrote:
> Add a new link config which uses 64-bit U-Boot. This is not fully
> functional but is it a start. Missing features:
>
> - SDRAM sizing
> - Booting linux
> - EFI support
> - SCSI device init
> (and others)
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v3:
> - Drop patch 'x86: Add basic support for U-Boot as a 64-bit EFI application'
> - Drop patch 'Mention the MRC region in the README'
> - Drop patch 'x86: link: Add build options for SPL'
> - Drop unnecessary defconfig options for chromebook_link64
> - Avoid including helloworld.efi in the 64-bit U-Boot
>
> Changes in v2:
> - Drop patch 'video: Use ulong for video frame buffer address'
> - Add a new 64-bit link config instead of changing the existing one
>
>  board/google/Kconfig |  7 +++
>  board/google/chromebook_link/Kconfig |  2 +-
>  board/google/chromebook_link/MAINTAINERS |  7 +++
>  configs/chromebook_link64_defconfig  | 89 
> 
>  4 files changed, 104 insertions(+), 1 deletion(-)
>  create mode 100644 configs/chromebook_link64_defconfig
>

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

Re: [U-Boot] [PATCH v3 60/62] x86: link: Add build options for SPL

[Bin Meng]

On Mon, Jan 16, 2017 at 10:04 PM, Simon Glass  wrote:
> If SPL is used we want to use the generic SPL framework and boot from SPI
> via a board-specific means. Add these options to the board config file.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v3:
> - Remove duplicate CONFIG_VIDEO_IVYBRIDGE_IGD in defconfig file
> - Drop the unnecessary defconfig changes for chromebook_link
>
> Changes in v2: None
>
>  include/configs/chromebook_link.h | 9 +
>  1 file changed, 9 insertions(+)
>

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

Re: [U-Boot] [PATCH v2 52/63] x86: Move pirq_routing_table to global_data

[Bin Meng]

Hi Simon,

On Mon, Jan 16, 2017 at 10:08 PM, Simon Glass  wrote:
> Hi Bin,
>
> On 14 January 2017 at 06:32, Bin Meng  wrote:
>> Hi Simon,
>>
>> On Sun, Nov 20, 2016 at 4:25 AM, Simon Glass  wrote:
>>> To avoid using BSS in SPL before SDRAM is set up, move this field to
>>> global_data.
>>>
>>
>> Why is this needed? pirq routing table setup is done after SDRAM
>> initialization. Isn't SPL doing this with a different order?
>
> I'm not sure why it should. SPL sets up SDRAM so it should be able to
> set up interrupts, shouldn't it? Some device init may need interrupts,
> and my plan was to do all the 32-bit init in SPL.

Yes, but I see interrupt_init() is called after dram_init() in
arch/x86/lib/spl.c, where BSS is already cleared after dram_init(). Am
I missing anything?

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

Re: [U-Boot] [PATCH v3 50/62] x86: Support jumping from SPL to U-Boot

[Bin Meng]

On Mon, Jan 16, 2017 at 10:04 PM, Simon Glass  wrote:
> Add a rough function to handle jumping from 32-bit SPL to 64-bit U-Boot.
> This still needs work to clean it up.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  arch/x86/cpu/call64.S  |  3 +++
>  arch/x86/cpu/i386/cpu.c| 65 
> ++
>  arch/x86/include/asm/cpu.h |  9 +++
>  3 files changed, 77 insertions(+)
>

Fixed the first style issue by removing target64() as it is not needed:

WARNING: externs should be avoided in .c files
#68: FILE: arch/x86/cpu/i386/cpu.c:524:
+   void target64(void);

WARNING: externs should be avoided in .c files
#83: FILE: arch/x86/cpu/i386/cpu.c:539:
+   extern char gdt64[];

Leave the 2nd one in the codes, and

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 47/62] x86: Don't build 32-bit efi files on x86_64

[Bin Meng]

On Mon, Jan 16, 2017 at 10:04 PM, Simon Glass  wrote:
> These cannot be built in this mode, so drop them.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  arch/x86/lib/Makefile | 4 
>  1 file changed, 4 insertions(+)
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 46/62] x86: Don't build cpu files which are not supported on 64-bit

[Bin Meng]

On Mon, Jan 16, 2017 at 10:04 PM, Simon Glass  wrote:
> Some files cannot be built with 64-bit and mostly don't make sense in that
> context. Disable them.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  arch/x86/cpu/Makefile | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 48/62] x86: Don't try to boot Linux from SPL

[Bin Meng]

On Mon, Jan 16, 2017 at 10:04 PM, Simon Glass  wrote:
> Booting into linux from 64-bit U-Boot is not yet supported. Avoid bringing
> in the bootm code until it is implemented.
>
> Of course 32-bit U-Boot still supports booting into both 32- and 64-bit
> kernels.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  arch/x86/lib/Makefile | 4 
>  1 file changed, 4 insertions(+)
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 49/62] x86: Drop interrupt support in 64-bit mode

[Bin Meng]

On Mon, Jan 16, 2017 at 10:04 PM, Simon Glass  wrote:
> This is not currently supported, so drop the code.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  arch/x86/lib/interrupts.c | 5 +
>  1 file changed, 5 insertions(+)
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [U-boot] [PATCH 2/2] rockchip: firefly: configs: use spl back to brom

[Jacob Chen]

Keep it same with other boards otherwise i have to write special script for it..

Signed-off-by: Jacob Chen 
---

 configs/firefly-rk3288_defconfig | 2 +-
 include/configs/firefly-rk3288.h | 5 -
 2 files changed, 1 insertion(+), 6 deletions(-)

diff --git a/configs/firefly-rk3288_defconfig b/configs/firefly-rk3288_defconfig
index 3ed17b4..18e050d 100644
--- a/configs/firefly-rk3288_defconfig
+++ b/configs/firefly-rk3288_defconfig
@@ -2,6 +2,7 @@ CONFIG_ARM=y
 CONFIG_ARCH_ROCKCHIP=y
 CONFIG_SYS_MALLOC_F_LEN=0x2000
 CONFIG_ROCKCHIP_RK3288=y
+CONFIG_ROCKCHIP_SPL_BACK_TO_BROM=y
 CONFIG_TARGET_FIREFLY_RK3288=y
 CONFIG_SPL_STACK_R_ADDR=0x8
 CONFIG_DEFAULT_DEVICE_TREE="rk3288-firefly"
@@ -75,4 +76,3 @@ CONFIG_CONSOLE_SCROLL_LINES=10
 CONFIG_USE_TINY_PRINTF=y
 CONFIG_CMD_DHRYSTONE=y
 CONFIG_ERRNO_STR=y
-# CONFIG_SPL_OF_LIBFDT is not set
diff --git a/include/configs/firefly-rk3288.h b/include/configs/firefly-rk3288.h
index 14fdead..ec555dd 100644
--- a/include/configs/firefly-rk3288.h
+++ b/include/configs/firefly-rk3288.h
@@ -16,11 +16,6 @@
 
 #define CONFIG_ENV_IS_IN_MMC
 #define CONFIG_SYS_MMC_ENV_DEV 0
-/* SPL @ 32k for ~36k
- * ENV @ 96k
- * u-boot @ 128K
- */
-#define CONFIG_ENV_OFFSET (96 * 1024)
 
 #define CONFIG_SYS_WHITE_ON_BLACK
 
-- 
1.9.1

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

[U-Boot] [U-boot] [PATCH 1/2] rockchip: configs: move env offset to common header

[Jacob Chen]

To reduce redundant code.

Signed-off-by: Jacob Chen 
---

 include/configs/evb_rk3288.h  | 14 --
 include/configs/fennec_rk3288.h   | 14 --
 include/configs/kylin_rk3036.h| 14 --
 include/configs/miniarm_rk3288.h  | 14 --
 include/configs/popmetal_rk3288.h | 14 --
 include/configs/rock2.h   | 14 --
 include/configs/rockchip-common.h | 14 ++
 7 files changed, 14 insertions(+), 84 deletions(-)

diff --git a/include/configs/evb_rk3288.h b/include/configs/evb_rk3288.h
index 554ca0e..6a068bb 100644
--- a/include/configs/evb_rk3288.h
+++ b/include/configs/evb_rk3288.h
@@ -13,20 +13,6 @@
 #define CONFIG_ENV_IS_IN_MMC
 #define CONFIG_SYS_MMC_ENV_DEV 1
 
-#ifdef CONFIG_ROCKCHIP_SPL_BACK_TO_BROM
-/* SPL @ 32k for 34k
- * u-boot directly after @ 68k for 400k or so
- * ENV @ 992k
- */
-#define CONFIG_ENV_OFFSET ((1024-32) * 1024)
-#else
-/* SPL @ 32k for ~36k
- * ENV @ 96k
- * u-boot @ 128K
- */
-#define CONFIG_ENV_OFFSET (96 * 1024)
-#endif
-
 #define CONFIG_SYS_WHITE_ON_BLACK
 
 #endif
diff --git a/include/configs/fennec_rk3288.h b/include/configs/fennec_rk3288.h
index 554ca0e..6a068bb 100644
--- a/include/configs/fennec_rk3288.h
+++ b/include/configs/fennec_rk3288.h
@@ -13,20 +13,6 @@
 #define CONFIG_ENV_IS_IN_MMC
 #define CONFIG_SYS_MMC_ENV_DEV 1
 
-#ifdef CONFIG_ROCKCHIP_SPL_BACK_TO_BROM
-/* SPL @ 32k for 34k
- * u-boot directly after @ 68k for 400k or so
- * ENV @ 992k
- */
-#define CONFIG_ENV_OFFSET ((1024-32) * 1024)
-#else
-/* SPL @ 32k for ~36k
- * ENV @ 96k
- * u-boot @ 128K
- */
-#define CONFIG_ENV_OFFSET (96 * 1024)
-#endif
-
 #define CONFIG_SYS_WHITE_ON_BLACK
 
 #endif
diff --git a/include/configs/kylin_rk3036.h b/include/configs/kylin_rk3036.h
index bc28525..088aced 100644
--- a/include/configs/kylin_rk3036.h
+++ b/include/configs/kylin_rk3036.h
@@ -20,20 +20,6 @@
 #define CONFIG_SYS_MMC_ENV_DEV 0 /* emmc */
 #define CONFIG_SYS_MMC_ENV_PART0 /* user area */
 
-#ifdef CONFIG_ROCKCHIP_SPL_BACK_TO_BROM
-/* SPL @ 32k for 34k
- * u-boot directly after @ 68k for 400k or so
- * ENV @ 992k
- */
-#define CONFIG_ENV_OFFSET ((1024-32) * 1024)
-#else
-/* SPL @ 32k for ~36k
- * ENV @ 96k
- * u-boot @ 128K
- */
-#define CONFIG_ENV_OFFSET (96 * 1024)
-#endif
-
 #endif
 
 #endif
diff --git a/include/configs/miniarm_rk3288.h b/include/configs/miniarm_rk3288.h
index 5a623ca..860eb40 100644
--- a/include/configs/miniarm_rk3288.h
+++ b/include/configs/miniarm_rk3288.h
@@ -18,20 +18,6 @@
 #define CONFIG_ENV_IS_IN_MMC
 #define CONFIG_SYS_MMC_ENV_DEV 0
 
-#ifdef CONFIG_ROCKCHIP_SPL_BACK_TO_BROM
-/* SPL @ 32k for 34k
- * u-boot directly after @ 68k for 400k or so
- * ENV @ 992k
- */
-#define CONFIG_ENV_OFFSET ((1024-32) * 1024)
-#else
-/* SPL @ 32k for ~36k
- * ENV @ 96k
- * u-boot @ 128K
- */
-#define CONFIG_ENV_OFFSET (96 * 1024)
-#endif
-
 #define CONFIG_SYS_WHITE_ON_BLACK
 
 #endif
diff --git a/include/configs/popmetal_rk3288.h 
b/include/configs/popmetal_rk3288.h
index 554ca0e..6a068bb 100644
--- a/include/configs/popmetal_rk3288.h
+++ b/include/configs/popmetal_rk3288.h
@@ -13,20 +13,6 @@
 #define CONFIG_ENV_IS_IN_MMC
 #define CONFIG_SYS_MMC_ENV_DEV 1
 
-#ifdef CONFIG_ROCKCHIP_SPL_BACK_TO_BROM
-/* SPL @ 32k for 34k
- * u-boot directly after @ 68k for 400k or so
- * ENV @ 992k
- */
-#define CONFIG_ENV_OFFSET ((1024-32) * 1024)
-#else
-/* SPL @ 32k for ~36k
- * ENV @ 96k
- * u-boot @ 128K
- */
-#define CONFIG_ENV_OFFSET (96 * 1024)
-#endif
-
 #define CONFIG_SYS_WHITE_ON_BLACK
 
 #endif
diff --git a/include/configs/rock2.h b/include/configs/rock2.h
index b9c2290..ec555dd 100644
--- a/include/configs/rock2.h
+++ b/include/configs/rock2.h
@@ -17,20 +17,6 @@
 #define CONFIG_ENV_IS_IN_MMC
 #define CONFIG_SYS_MMC_ENV_DEV 0
 
-#ifdef CONFIG_ROCKCHIP_SPL_BACK_TO_BROM
-/* SPL @ 32k for 34k
- * u-boot directly after @ 68k for 400k or so
- * ENV @ 992k
- */
-#define CONFIG_ENV_OFFSET ((1024-32) * 1024)
-#else
-/* SPL @ 32k for ~36k
- * ENV @ 96k
- * u-boot @ 128K
- */
-#define CONFIG_ENV_OFFSET (96 * 1024)
-#endif
-
 #define CONFIG_SYS_WHITE_ON_BLACK
 
 #endif
diff --git a/include/configs/rockchip-common.h 
b/include/configs/rockchip-common.h
index be53e65..eb5f1ef 100644
--- a/include/configs/rockchip-common.h
+++ b/include/configs/rockchip-common.h
@@ -34,4 +34,18 @@
 
 #endif
 
+#ifdef CONFIG_ROCKCHIP_SPL_BACK_TO_BROM
+/* SPL @ 32k for 34k
+ * u-boot directly after @ 68k for 400k or so
+ * ENV @ 992k
+ */
+#define CONFIG_ENV_OFFSET ((1024-32) * 1024)
+#else
+/* SPL @ 32k for ~36k
+ * ENV @ 96k
+ * u-boot @ 128K
+ */
+#define CONFIG_ENV_OFFSET (96 * 1024)
+#endif
+
 #endif /* _ROCKCHIP_COMMON_H_ */
-- 
1.9.1

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

Re: [U-Boot] [PATCH v3 44/62] x86: Don't try to run the VGA BIOS in 64-bit mode

[Bin Meng]

On Mon, Jan 16, 2017 at 10:04 PM, Simon Glass  wrote:
> This is not supported, so disable it for now.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  arch/x86/lib/Makefile | 2 ++
>  drivers/pci/pci_rom.c | 2 +-
>  2 files changed, 3 insertions(+), 1 deletion(-)
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 43/62] x86: ivybridge: Provide a dummy SDRAM init for 64-bit

[Bin Meng]

On Tue, Jan 17, 2017 at 12:04 PM, Bin Meng  wrote:
> On Mon, Jan 16, 2017 at 10:04 PM, Simon Glass  wrote:
>> We don't support SDRAM init in 64-bit mode since it is essentially
>> impossible to get into that mode before SDRAM set up. Provide dummy functions
>> for now. At some point we will need to pass the SDRAM parameters through from
>> SPL.
>>
>> Signed-off-by: Simon Glass 
>> ---
>>
>> Changes in v3:
>> - Put dummy misc_init_r() and print_cpuinfo() functions into cpu.c
>> - Drop duplicate comment line in header
>>
>> Changes in v2: None
>>
>>  arch/x86/cpu/ivybridge/Makefile|  3 +++
>>  arch/x86/cpu/ivybridge/sdram_nop.c | 18 ++
>>  arch/x86/cpu/x86_64/cpu.c  | 10 ++
>>  3 files changed, 31 insertions(+)
>>  create mode 100644 arch/x86/cpu/ivybridge/sdram_nop.c
>>
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 42/62] x86: ivybridge: Skip SATA init in SPL

[Bin Meng]

On Mon, Jan 16, 2017 at 10:04 PM, Simon Glass  wrote:
> This doesn't work at present. Disable it for now.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v3:
> - Fix 'skipt' typo in the subject
>
> Changes in v2: None
>
>  arch/x86/cpu/ivybridge/Makefile | 2 ++
>  1 file changed, 2 insertions(+)
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 41/62] x86: Fix up type sizes for 64-bit

[Bin Meng]

On Tue, Jan 17, 2017 at 12:03 PM, Bin Meng  wrote:
> On Mon, Jan 16, 2017 at 10:04 PM, Simon Glass  wrote:
>> Adjust types as needed to support 64-bit compilation.
>>
>> Signed-off-by: Simon Glass 
>> ---
>>
>> Changes in v3: None
>> Changes in v2: None
>>
>>  arch/x86/include/asm/posix_types.h | 5 +
>>  arch/x86/include/asm/types.h   | 5 +
>>  2 files changed, 10 insertions(+)
>>
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 45/62] x86: Don't build call64 and setjmp on 64-bit

[Bin Meng]

On Tue, Jan 17, 2017 at 12:04 PM, Bin Meng  wrote:
> On Mon, Jan 16, 2017 at 10:04 PM, Simon Glass  wrote:
>> These are currently not supported. Calling 64-bit code from 64-bit U-Boot is
>> much simpler, so this code is not needed. setjmp() is not yet implemented for
>> 64-bit.
>>
>> Signed-off-by: Simon Glass 
>> ---
>>
>> Changes in v3:
>> - Add a TODO indicating that booting 32- and 64-bit kernels should be 
>> supported
>>
>> Changes in v2: None
>>
>>  arch/x86/cpu/Makefile | 6 +-
>>  arch/x86/lib/bootm.c  | 7 +++
>>  2 files changed, 12 insertions(+), 1 deletion(-)
>>
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 45/62] x86: Don't build call64 and setjmp on 64-bit

[Bin Meng]

On Mon, Jan 16, 2017 at 10:04 PM, Simon Glass  wrote:
> These are currently not supported. Calling 64-bit code from 64-bit U-Boot is
> much simpler, so this code is not needed. setjmp() is not yet implemented for
> 64-bit.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v3:
> - Add a TODO indicating that booting 32- and 64-bit kernels should be 
> supported
>
> Changes in v2: None
>
>  arch/x86/cpu/Makefile | 6 +-
>  arch/x86/lib/bootm.c  | 7 +++
>  2 files changed, 12 insertions(+), 1 deletion(-)
>

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

Re: [U-Boot] [PATCH v3 43/62] x86: ivybridge: Provide a dummy SDRAM init for 64-bit

[Bin Meng]

On Mon, Jan 16, 2017 at 10:04 PM, Simon Glass  wrote:
> We don't support SDRAM init in 64-bit mode since it is essentially
> impossible to get into that mode before SDRAM set up. Provide dummy functions
> for now. At some point we will need to pass the SDRAM parameters through from
> SPL.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v3:
> - Put dummy misc_init_r() and print_cpuinfo() functions into cpu.c
> - Drop duplicate comment line in header
>
> Changes in v2: None
>
>  arch/x86/cpu/ivybridge/Makefile|  3 +++
>  arch/x86/cpu/ivybridge/sdram_nop.c | 18 ++
>  arch/x86/cpu/x86_64/cpu.c  | 10 ++
>  3 files changed, 31 insertions(+)
>  create mode 100644 arch/x86/cpu/ivybridge/sdram_nop.c
>

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

Re: [U-Boot] [PATCH v3 41/62] x86: Fix up type sizes for 64-bit

[Bin Meng]

On Mon, Jan 16, 2017 at 10:04 PM, Simon Glass  wrote:
> Adjust types as needed to support 64-bit compilation.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  arch/x86/include/asm/posix_types.h | 5 +
>  arch/x86/include/asm/types.h   | 5 +
>  2 files changed, 10 insertions(+)
>

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

Re: [U-Boot] [PATCH v3 36/62] x86: Add a link script for 64-bit x86

[Bin Meng]

On Mon, Jan 16, 2017 at 10:04 PM, Simon Glass  wrote:
> This needs a different image format from 32-bit x86, so add a new link
> script.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  arch/x86/cpu/config.mk |  6 
>  arch/x86/cpu/u-boot-64.lds | 76 
> ++
>  2 files changed, 82 insertions(+)
>  create mode 100644 arch/x86/cpu/u-boot-64.lds
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 34/62] x86: Support global_data on x86_64

[Bin Meng]

On Tue, Jan 17, 2017 at 11:26 AM, Bin Meng  wrote:
> On Mon, Jan 16, 2017 at 10:03 PM, Simon Glass  wrote:
>> At present this is just an ordinary variable. We may consider making it a
>> fixed register in the future.
>>
>> Signed-off-by: Simon Glass 
>> ---
>>
>> Changes in v3:
>> - Add a TODO to look at using a fixed register for gd on x86_64
>> - Expand the TODO about the necessary printch() call
>> - Add a required debug_uart.h #include in this patch
>>
>> Changes in v2: None
>>
>>  arch/x86/cpu/x86_64/cpu.c  | 27 +++
>>  arch/x86/include/asm/global_data.h |  7 ++-
>>  2 files changed, 33 insertions(+), 1 deletion(-)
>>
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 35/62] x86: Fix up CONFIG_X86_64 check

[Bin Meng]

On Mon, Jan 16, 2017 at 10:04 PM, Simon Glass  wrote:
> When SPL and U-Boot proper have different settings for this flag, we need to
> use the correct one. Fix this up in the interrupt code.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  arch/x86/cpu/i386/interrupt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 40/62] x86: Drop flag_is_changable() on x86_64

[Bin Meng]

On Mon, Jan 16, 2017 at 10:04 PM, Simon Glass  wrote:
> This doesn't build at present and is not used in a 64-bit build. Disable it
> for now.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  arch/x86/include/asm/cpu.h | 3 +++
>  1 file changed, 3 insertions(+)
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 38/62] x86: Add SPL build rules for start-up code

[Bin Meng]

On Mon, Jan 16, 2017 at 10:04 PM, Simon Glass  wrote:
> When SPL is used we need to build the 16-bit start-up code. Add Makefile
> rules to handle this.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  scripts/Makefile.spl | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 39/62] x86: Fix up byteorder.h for x86_64

[Bin Meng]

On Mon, Jan 16, 2017 at 10:04 PM, Simon Glass  wrote:
> Remove the very old x86 code and add support for 64-bit.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  arch/x86/include/asm/byteorder.h | 17 +
>  1 file changed, 9 insertions(+), 8 deletions(-)
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 37/62] x86: Add a link script for SPL

[Bin Meng]

On Mon, Jan 16, 2017 at 10:04 PM, Simon Glass  wrote:
> If SPL is used it is always build in 32-bit mode. Add a link script to
> handle the correct placement of the sections.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  arch/x86/cpu/u-boot-spl.lds | 74 
> +
>  1 file changed, 74 insertions(+)
>  create mode 100644 arch/x86/cpu/u-boot-spl.lds
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 33/62] x86: Add cpu code for x86_64

[Bin Meng]

On Mon, Jan 16, 2017 at 10:03 PM, Simon Glass  wrote:
> There is not much needed at present, but set up a separate directory to put
> this code as it grows.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v3:
> - Drop blank line at end of arch/x86/cpu/x86_64/interrupts.c
> - Drop #include of debug_uart.h
>
> Changes in v2: None
>
>  arch/x86/cpu/Makefile|  4 +++-
>  arch/x86/cpu/x86_64/Makefile |  6 ++
>  arch/x86/cpu/x86_64/cpu.c| 34 ++
>  arch/x86/cpu/x86_64/interrupts.c | 29 +
>  4 files changed, 72 insertions(+), 1 deletion(-)
>  create mode 100644 arch/x86/cpu/x86_64/Makefile
>  create mode 100644 arch/x86/cpu/x86_64/cpu.c
>  create mode 100644 arch/x86/cpu/x86_64/interrupts.c
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 31/62] x86: Add an SPL implementation

[Bin Meng]

On Tue, Jan 17, 2017 at 11:24 AM, Bin Meng  wrote:
> On Mon, Jan 16, 2017 at 10:03 PM, Simon Glass  wrote:
>> SPL needs to set up the machine ready for loading 64-bit U-Boot and jumping
>> to it. Call the existing init routines in order to accomplish this.
>>
>> Signed-off-by: Simon Glass 
>> ---
>>
>> Changes in v3:
>> - Update copyright year
>> - Drop duplicate line in header commment
>> - Add a comment about stack position to x86_spl_init()
>> - Add a parameter to the use of the SPL_LOAD_IMAGE_METHOD() macro
>> - Fix printf() warning in spl_board_load_image()
>>
>> Changes in v2: None
>>
>>  arch/x86/include/asm/spl.h |   8 +++
>>  arch/x86/lib/Makefile  |   1 +
>>  arch/x86/lib/spl.c | 153 
>> +
>>  3 files changed, 162 insertions(+)
>>  create mode 100644 arch/x86/include/asm/spl.h
>>  create mode 100644 arch/x86/lib/spl.c
>>
>
> Reviewed-by: Bin Meng 

Fixed the style error reported by checkpatch,

ERROR: trailing statements should be on next line
#219: FILE: arch/x86/lib/spl.c:152:
+   while (1);

and applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 32/62] x86: Move the i386 code into its own directory

[Bin Meng]

On Mon, Jan 16, 2017 at 10:03 PM, Simon Glass  wrote:
> Much of the cpu and interrupt code cannot be compiled on 64-bit x86. Move it
> into its own directory and build it only in 32-bit mode.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  arch/x86/cpu/Makefile   |   6 +-
>  arch/x86/cpu/cpu.c  | 504 --
>  arch/x86/cpu/i386/Makefile  |   7 +
>  arch/x86/cpu/i386/cpu.c | 534 
> 
>  arch/x86/cpu/{interrupts.c => i386/interrupt.c} |   4 -
>  arch/x86/include/asm/mp.h   |   3 +
>  6 files changed, 549 insertions(+), 509 deletions(-)
>  create mode 100644 arch/x86/cpu/i386/Makefile
>  create mode 100644 arch/x86/cpu/i386/cpu.c
>  rename arch/x86/cpu/{interrupts.c => i386/interrupt.c} (99%)
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [v4, 3/3] armv8: ls1012a: define esdhc_status_fixup for RDB board

[Yangbo Lu]

On LS1012ARDB board, three dual 1:4 mux/demux devices drive the SDHC2
signals to eMMC, SDIO wifi, SPI and Ardiuno shield. Only when we select
eMMC and SDIO wifi, the SDHC2 could be used. Otherwise, the command
inhibit bits of eSDHC2_PRSSTAT register will never release. This would
cause below continious error messages in linux since it uses polling
mode to detect card.
"mmc1: Controller never released inhibit bit(s)."
"mmc1: Controller never released inhibit bit(s)."
"mmc1: Controller never released inhibit bit(s)."
This patch is to define esdhc_status_fixup function for RDB to disable
SDHC2 status if no SDIO wifi or eMMC is selected.

Signed-off-by: Yangbo Lu 
---
Changes for v2:
- Added this patch
Changes for v3:
- Fixed checkpatch issue
Changes for v4:
- Removed incorrect comments in code
---
 board/freescale/ls1012ardb/ls1012ardb.c | 38 +
 1 file changed, 38 insertions(+)

diff --git a/board/freescale/ls1012ardb/ls1012ardb.c 
b/board/freescale/ls1012ardb/ls1012ardb.c
index 778434d..65fa94c 100644
--- a/board/freescale/ls1012ardb/ls1012ardb.c
+++ b/board/freescale/ls1012ardb/ls1012ardb.c
@@ -113,6 +113,44 @@ int board_init(void)
return 0;
 }
 
+int esdhc_status_fixup(void *blob, const char *compat)
+{
+   char esdhc0_path[] = "/soc/esdhc@156";
+   char esdhc1_path[] = "/soc/esdhc@158";
+   u8 io = 0;
+   u8 mux_sdhc2;
+
+   do_fixup_by_path(blob, esdhc0_path, "status", "okay",
+sizeof("okay"), 1);
+
+   i2c_set_bus_num(0);
+
+   /*
+* The I2C IO-expander for mux select is used to control the muxing
+* of various onboard interfaces.
+*
+* IO1[3:2] indicates SDHC2 interface demultiplexer select lines.
+*  00 - SDIO wifi
+*  01 - GPIO (to Arduino)
+*  10 - eMMC Memory
+*  11 - SPI
+*/
+   if (i2c_read(I2C_MUX_IO1_ADDR, 0, 1, , 1) < 0) {
+   printf("Error reading i2c boot information!\n");
+   return 0; /* Don't want to hang() on this error */
+   }
+
+   mux_sdhc2 = (io & 0x0c) >> 2;
+   /* Enable SDHC2 only when use SDIO wifi and eMMC */
+   if (mux_sdhc2 == 2 || mux_sdhc2 == 0)
+   do_fixup_by_path(blob, esdhc1_path, "status", "okay",
+sizeof("okay"), 1);
+   else
+   do_fixup_by_path(blob, esdhc1_path, "status", "disabled",
+sizeof("disabled"), 1);
+   return 0;
+}
+
 int ft_board_setup(void *blob, bd_t *bd)
 {
arch_fixup_fdt(blob);
-- 
2.1.0.27.g96db324

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

Re: [U-Boot] [PATCH v3 34/62] x86: Support global_data on x86_64

[Bin Meng]

On Mon, Jan 16, 2017 at 10:03 PM, Simon Glass  wrote:
> At present this is just an ordinary variable. We may consider making it a
> fixed register in the future.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v3:
> - Add a TODO to look at using a fixed register for gd on x86_64
> - Expand the TODO about the necessary printch() call
> - Add a required debug_uart.h #include in this patch
>
> Changes in v2: None
>
>  arch/x86/cpu/x86_64/cpu.c  | 27 +++
>  arch/x86/include/asm/global_data.h |  7 ++-
>  2 files changed, 33 insertions(+), 1 deletion(-)
>

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

[U-Boot] [PATCH 2/2] ARM: OMAP5+: Remove unsed dpll structures

[Lokesh Vutla]

Latest gcc compile strted complaining about defined structure definition
that are not used. Remove the unused sturctures.

Reported-by: Dan Murphy 
Signed-off-by: Lokesh Vutla 
---
 arch/arm/mach-omap2/omap5/hw_data.c | 59 +++--
 1 file changed, 4 insertions(+), 55 deletions(-)

diff --git a/arch/arm/mach-omap2/omap5/hw_data.c 
b/arch/arm/mach-omap2/omap5/hw_data.c
index 58991d7d04..5d956b5b14 100644
--- a/arch/arm/mach-omap2/omap5/hw_data.c
+++ b/arch/arm/mach-omap2/omap5/hw_data.c
@@ -28,17 +28,6 @@ struct vcores_data const **omap_vcores =
 struct omap_sys_ctrl_regs const **ctrl =
(struct omap_sys_ctrl_regs const **)OMAP_SRAM_SCRATCH_SYS_CTRL;
 
-/* OPP HIGH FREQUENCY for ES2.0 */
-static const struct dpll_params mpu_dpll_params_1_5ghz[NUM_SYS_CLKS] = {
-   {125, 0, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},/* 12 MHz   */
-   {-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1},   /* 13 MHz   */
-   {625, 6, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},/* 16.8 MHz */
-   {625, 7, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},/* 19.2 MHz */
-   {750, 12, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},   /* 26 MHz   */
-   {-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1},   /* 27 MHz   */
-   {625, 15, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1}/* 38.4 MHz */
-};
-
 /* OPP NOM FREQUENCY for ES1.0 */
 static const struct dpll_params mpu_dpll_params_800mhz[NUM_SYS_CLKS] = {
{200, 2, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},/* 12 MHz   */
@@ -50,28 +39,6 @@ static const struct dpll_params 
mpu_dpll_params_800mhz[NUM_SYS_CLKS] = {
{375, 17, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1}/* 38.4 MHz */
 };
 
-/* OPP LOW FREQUENCY for ES1.0 */
-static const struct dpll_params mpu_dpll_params_400mhz[NUM_SYS_CLKS] = {
-   {200, 2, 2, -1, -1, -1, -1, -1, -1, -1, -1, -1},/* 12 MHz   */
-   {-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1},   /* 13 MHz   */
-   {1000, 20, 2, -1, -1, -1, -1, -1, -1, -1, -1, -1},  /* 16.8 MHz */
-   {375, 8, 2, -1, -1, -1, -1, -1, -1, -1, -1, -1},/* 19.2 MHz */
-   {400, 12, 2, -1, -1, -1, -1, -1, -1, -1, -1, -1},   /* 26 MHz   */
-   {-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1},   /* 27 MHz   */
-   {375, 17, 2, -1, -1, -1, -1, -1, -1, -1, -1, -1}/* 38.4 MHz */
-};
-
-/* OPP LOW FREQUENCY for ES2.0 */
-static const struct dpll_params mpu_dpll_params_499mhz[NUM_SYS_CLKS] = {
-   {499, 11, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},   /* 12 MHz   */
-   {-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1},   /* 13 MHz   */
-   {297, 9, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},/* 16.8 MHz */
-   {493, 18, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},   /* 19.2 MHz */
-   {499, 25, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},   /* 26 MHz   */
-   {-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1},   /* 27 MHz   */
-   {493, 37, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1}/* 38.4 MHz */
-};
-
 /* OPP NOM FREQUENCY for OMAP5 ES2.0, and DRA7 ES1.0 */
 static const struct dpll_params mpu_dpll_params_1ghz[NUM_SYS_CLKS] = {
{250, 2, 1, 1, -1, -1, -1, -1, -1, -1, -1, -1}, /* 12 MHz   */
@@ -116,28 +83,6 @@ static const struct dpll_params
{277, 9, 2, 1, -1, 4, 62, 5, -1, 5, 4, 6},  /* 38.4 MHz */
 };
 
-static const struct dpll_params
-   core_dpll_params_2128mhz_ddr266[NUM_SYS_CLKS] = {
-   {266, 2, 4, 8, 8, 8, 62, 10, -1, 10, 14, -1},   /* 12 MHz   */
-   {-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1},   /* 13 MHz   */
-   {443, 6, 4, 8, 8, 8, 62, 10, -1, 10, 14, -1},   /* 16.8 MHz */
-   {277, 4, 4, 8, 8, 8, 62, 10, -1, 10, 14, -1},   /* 19.2 MHz */
-   {368, 8, 4, 8, 8, 8, 62, 10, -1, 10, 14, -1},   /* 26 MHz   */
-   {-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1},   /* 27 MHz   */
-   {277, 9, 4, 8, 8, 8, 62, 10, -1, 10, 14, -1}/* 38.4 MHz */
-};
-
-static const struct dpll_params
-   core_dpll_params_2128mhz_ddr266_es2[NUM_SYS_CLKS] = {
-   {266, 2, 4, 8, 8, 8, 62, 5, 12, 10, 14, 12},/* 12 MHz   */
-   {-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1},   /* 13 MHz   */
-   {443, 6, 4, 8, 8, 8, 62, 5, 12, 10, 14, 12},/* 16.8 MHz */
-   {277, 4, 4, 8, 8, 8, 62, 5, 12, 10, 14, 12},/* 19.2 MHz */
-   {368, 8, 4, 8, 8, 8, 62, 5, 12, 10, 14, 12},/* 26 MHz   */
-   {-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1},   /* 27 MHz   */
-   {277, 9, 4, 8, 8, 8, 62, 5, 12, 10, 14, 12} /* 38.4 MHz */
-};
-
 static const struct dpll_params per_dpll_params_768mhz[NUM_SYS_CLKS] = {
{32, 0, 4, 3, 6, 4, -1, 2, -1, -1, -1, -1}, /* 12 MHz   */
{-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1}, 

[U-Boot] [PATCH 1/2] ARM: OMAP4: Fix compiler warning

[Lokesh Vutla]

Latest gcc 6.2 compiler is throwing the below warning for omap4_panda_defconfig
arch/arm/mach-omap2/omap4/hw_data.c:136:3: warning: 
'abe_dpll_params_sysclk_196608khz' defined but not used 
[-Wunused-const-variable=]
   abe_dpll_params_sysclk_196608khz[NUM_SYS_CLKS] = {

Fix this by guarding it with CONFIG_SYS_OMAP_ABE_SYSCK

Reported-by: Dan Murphy 
Signed-off-by: Lokesh Vutla 
---
 arch/arm/mach-omap2/omap4/hw_data.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/omap4/hw_data.c 
b/arch/arm/mach-omap2/omap4/hw_data.c
index 6a4b8b93c0..471f1c4834 100644
--- a/arch/arm/mach-omap2/omap4/hw_data.c
+++ b/arch/arm/mach-omap2/omap4/hw_data.c
@@ -132,6 +132,7 @@ static const struct dpll_params 
iva_dpll_params_1862mhz[NUM_SYS_CLKS] = {
 };
 
 /* ABE M & N values with sys_clk as source */
+#ifdef CONFIG_SYS_OMAP_ABE_SYSCK
 static const struct dpll_params
abe_dpll_params_sysclk_196608khz[NUM_SYS_CLKS] = {
{49, 5, 1, 1, -1, -1, -1, -1, -1, -1, -1, -1},  /* 12 MHz   */
@@ -142,11 +143,12 @@ static const struct dpll_params
{29, 7, 1, 1, -1, -1, -1, -1, -1, -1, -1, -1},  /* 27 MHz   */
{64, 24, 1, 1, -1, -1, -1, -1, -1, -1, -1, -1}  /* 38.4 MHz */
 };
-
+#else
 /* ABE M & N values with 32K clock as source */
 static const struct dpll_params abe_dpll_params_32k_196608khz = {
750, 0, 1, 1, -1, -1, -1, -1, -1, -1, -1, -1
 };
+#endif
 
 static const struct dpll_params usb_dpll_params_1920mhz[NUM_SYS_CLKS] = {
{80, 0, 2, -1, -1, -1, -1, -1, -1, -1, -1, -1}, /* 12 MHz   */
-- 
2.11.0

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

Re: [U-Boot] [PATCH v3 31/62] x86: Add an SPL implementation

[Bin Meng]

On Mon, Jan 16, 2017 at 10:03 PM, Simon Glass  wrote:
> SPL needs to set up the machine ready for loading 64-bit U-Boot and jumping
> to it. Call the existing init routines in order to accomplish this.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v3:
> - Update copyright year
> - Drop duplicate line in header commment
> - Add a comment about stack position to x86_spl_init()
> - Add a parameter to the use of the SPL_LOAD_IMAGE_METHOD() macro
> - Fix printf() warning in spl_board_load_image()
>
> Changes in v2: None
>
>  arch/x86/include/asm/spl.h |   8 +++
>  arch/x86/lib/Makefile  |   1 +
>  arch/x86/lib/spl.c | 153 
> +
>  3 files changed, 162 insertions(+)
>  create mode 100644 arch/x86/include/asm/spl.h
>  create mode 100644 arch/x86/lib/spl.c
>

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

[U-Boot] [PATCH] drivers: usb: gadget: ether: Fix compiler warning

[Lokesh Vutla]

Latest gcc 6.2 compiler is throwing the below warning for 
am335x_baltos_defconfig
drivers/usb/gadget/ether.c:501:17: warning: 'mdlm_detail_desc' defined but not 
used [-Wunused-const-variable=]
 static const u8 mdlm_detail_desc[] = {

Guard mdlm_detail_desc with CONFIG_USB_ETH_SUBSET to avoid the warning

Reported-by: Dan Murphy 
Signed-off-by: Lokesh Vutla 
---
 drivers/usb/gadget/ether.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index f1b0709821..4137d76c42 100644
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -507,6 +507,7 @@ static const struct usb_cdc_mdlm_desc mdlm_desc = {
  * can't really use its struct.  All we do here is say that we're using
  * the submode of "SAFE" which directly matches the CDC Subset.
  */
+#ifdef CONFIG_USB_ETH_SUBSET
 static const u8 mdlm_detail_desc[] = {
6,
USB_DT_CS_INTERFACE,
@@ -516,6 +517,7 @@ static const u8 mdlm_detail_desc[] = {
0,  /* network control capabilities (none) */
0,  /* network data capabilities ("raw" encapsulation) */
 };
+#endif
 
 #endif
 
-- 
2.11.0

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

Re: [U-Boot] [PATCH v2] armv8: aarch64: Fix the warning about x1-x3 nonzero issue

[Alison Wang]

> On 16 January 2017 at 08:34, Alexander Graf  wrote:
> >
> >
> > On 16/01/2017 07:16, Alison Wang wrote:
> >>
> >> For 64-bit kernel, there is a warning about x1-x3 nonzero in
> >> violation of boot protocol. To fix this issue, input argument 4 is
> >> added for
> >> armv8_switch_to_el2 and armv8_switch_to_el1. The input argument 4
> >> will be set to the right value, such as zero.
> >>
> >> Signed-off-by: Alison Wang 
> 
> Thanks Alison, this removes the warning for me now and still boots fine.
> I tested with Juno R0/1/2 and FVP Foundation and AEMv8 models.
> 
> Tested-by: Ryan Harkin 
[Alison Wang] Ryan, thanks for your test. :)

Best Regards,
Alison Wang
> 
> 
> >> ---
> >> Changes in v2:
> >> - Add another input argument 4 for armv8_switch_to_el2 and
> >> armv8_switch_to_el1.
> >> - Give up the previous way to adjust the parameters to transfer and
> >> make sure x3 is zero.
> >>
> >>  arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S | 28
> >> ++--
> >>  arch/arm/cpu/armv8/sec_firmware_asm.S|  5 +++--
> >>  arch/arm/cpu/armv8/start.S   |  8 
> >>  arch/arm/cpu/armv8/transition.S  | 22 +++--
> -
> >>  arch/arm/include/asm/system.h|  8 +---
> >>  arch/arm/lib/bootm.c | 10 +-
> >>  arch/arm/mach-rmobile/lowlevel_init_gen3.S   |  8 
> >>  cmd/bootefi.c|  2 +-
> >>  8 files changed, 47 insertions(+), 44 deletions(-)
> >>
> >> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
> >> b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
> >> index 72f2c11..63215f0 100644
> >> --- a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
> >> +++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
> >> @@ -378,29 +378,29 @@ cpu_is_le:
> >> b.eq1f
> >>
> >>  #ifdef CONFIG_ARMV8_SWITCH_TO_EL1
> >> -   adr x3, secondary_switch_to_el1
> >> -   ldr x4, =ES_TO_AARCH64
> >> +   adr x4, secondary_switch_to_el1
> >> +   ldr x5, =ES_TO_AARCH64
> >>  #else
> >> -   ldr x3, [x11]
> >> -   ldr x4, =ES_TO_AARCH32
> >> +   ldr x4, [x11]
> >> +   ldr x5, =ES_TO_AARCH32
> >>  #endif
> >> bl  secondary_switch_to_el2
> >>
> >>  1:
> >>  #ifdef CONFIG_ARMV8_SWITCH_TO_EL1
> >> -   adr x3, secondary_switch_to_el1
> >> +   adr x4, secondary_switch_to_el1
> >>  #else
> >> -   ldr x3, [x11]
> >> +   ldr x4, [x11]
> >>  #endif
> >> -   ldr x4, =ES_TO_AARCH64
> >> +   ldr x5, =ES_TO_AARCH64
> >> bl  secondary_switch_to_el2
> >>
> >>  ENDPROC(secondary_boot_func)
> >>
> >>  ENTRY(secondary_switch_to_el2)
> >> -   switch_el x5, 1f, 0f, 0f
> >> +   switch_el x6, 1f, 0f, 0f
> >>  0: ret
> >> -1: armv8_switch_to_el2_m x3, x4, x5
> >> +1: armv8_switch_to_el2_m x4, x5, x6
> >>  ENDPROC(secondary_switch_to_el2)
> >>
> >>  ENTRY(secondary_switch_to_el1)
> >> @@ -414,22 +414,22 @@ ENTRY(secondary_switch_to_el1)
> >> /* physical address of this cpus spin table element */
> >> add x11, x1, x0
> >>
> >> -   ldr x3, [x11]
> >> +   ldr x4, [x11]
> >>
> >> ldr x5, [x11, #24]
> >> ldr x6, =IH_ARCH_DEFAULT
> >> cmp x6, x5
> >> b.eq2f
> >>
> >> -   ldr x4, =ES_TO_AARCH32
> >> +   ldr x5, =ES_TO_AARCH32
> >> bl  switch_to_el1
> >>
> >> -2: ldr x4, =ES_TO_AARCH64
> >> +2: ldr x5, =ES_TO_AARCH64
> >>
> >>  switch_to_el1:
> >> -   switch_el x5, 0f, 1f, 0f
> >> +   switch_el x6, 0f, 1f, 0f
> >>  0: ret
> >> -1: armv8_switch_to_el1_m x3, x4, x5
> >> +1: armv8_switch_to_el1_m x4, x5, x6
> >>  ENDPROC(secondary_switch_to_el1)
> >>
> >> /* Ensure that the literals used by the secondary boot code
> >> are diff --git a/arch/arm/cpu/armv8/sec_firmware_asm.S
> >> b/arch/arm/cpu/armv8/sec_firmware_asm.S
> >> index 903195d..747b53f 100644
> >> --- a/arch/arm/cpu/armv8/sec_firmware_asm.S
> >> +++ b/arch/arm/cpu/armv8/sec_firmware_asm.S
> >> @@ -57,7 +57,8 @@ ENDPROC(_sec_firmware_support_psci_version)
> >>   * x0: argument, zero
> >>   * x1: machine nr
> >>   * x2: fdt address
> >> - * x3: kernel entry point
> >> + * x3: input argument
> >> + * x4: kernel entry point
> >>   * @param outputs for secure firmware:
> >>   * x0: function id
> >>   * x1: kernel entry point
> >> @@ -65,7 +66,7 @@ ENDPROC(_sec_firmware_support_psci_version)
> >>   * x3: fdt address
> >>  */
> >>  ENTRY(armv8_el2_to_aarch32)
> >> -   mov x0, x3
> >> +   mov x0, x4
> >
> >
> > You no longer need x0 as scratch register. Just write ...
> >
> >> mov x3, x2
> >> mov x2, x1
> >> mov x1, x0
> >
> >
> > ... x4 directly into x1 here.
> >
> >
> > Otherwise looks good to me. So with the change above you can add my
> >
> >   

Re: [U-Boot] [PATCH v2] defconfig: Add a config for AM335x High Security EVM

[Lokesh Vutla]

On Monday 16 January 2017 10:14 PM, Andrew F. Davis wrote:
> Add a new defconfig file for the AM335x High Security EVM. This config
> is specific for the case of memory device booting. Memory device booting
> is handled separatly from peripheral booting on HS devices as the load
> address changes.
> 
> This defconfig is the same as for the non-secure part, except for:
>   CONFIG_TI_SECURE_DEVICE option set to 'y'
>   CONFIG_ISW_ENTRY_ADDR updated for secure images.
>   CONFIG_FIT_IMAGE_POST_PROCESS option set to 'y'
>   CONFIG_SPL_FIT_IMAGE_POST_PROCESS option set to 'y'
>   CONFIG_USE_TINY_PRINTF option set to 'y' to reduce SPL size
>   CONFIG_SPL_SYS_MALLOC_SIMPLE set to 'y' to reduce SPL size
> 
> Signed-off-by: Andrew F. Davis 
> ---
> 
> Changes from v1:
>  - Add to MAINTAINERS file
> 
>  MAINTAINERS |  1 +
>  configs/am335x_hs_evm_defconfig | 62 
> +
>  2 files changed, 63 insertions(+)
>  create mode 100644 configs/am335x_hs_evm_defconfig
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1ea7ae013a..788e16a391 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -441,6 +441,7 @@ F:arch/arm/mach-omap2/omap5/sec_entry_cpu1.S
>  F:   arch/arm/mach-omap2/omap5/sec-fxns.c
>  F:   arch/arm/mach-omap2/sec-common.c
>  F:   arch/arm/mach-omap2/config_secure.mk
> +F:   configs/am335x_hs_evm_defconfig
>  F:   configs/am43xx_hs_evm_defconfig
>  F:   configs/am57xx_hs_evm_defconfig
>  F:   configs/dra7xx_hs_evm_defconfig
> diff --git a/configs/am335x_hs_evm_defconfig b/configs/am335x_hs_evm_defconfig
> new file mode 100644
> index 00..f8445c3249
> --- /dev/null
> +++ b/configs/am335x_hs_evm_defconfig
> @@ -0,0 +1,62 @@
> +CONFIG_ARM=y
> +CONFIG_AM33XX=y
> +CONFIG_TI_SECURE_DEVICE=y
> +# CONFIG_SPL_EXT_SUPPORT is not set
> +# CONFIG_SPL_NAND_SUPPORT is not set
> +CONFIG_TARGET_AM335X_EVM=y
> +CONFIG_ISW_ENTRY_ADDR=0x40300350
> +CONFIG_SPL_STACK_R_ADDR=0x8200
> +# CONFIG_SPL_YMODEM_SUPPORT is not set
> +CONFIG_DEFAULT_DEVICE_TREE="am335x-evm"
> +CONFIG_DISTRO_DEFAULTS=y
> +CONFIG_FIT=y
> +CONFIG_SYS_EXTRA_OPTIONS="NAND"
> +CONFIG_SPL_LOAD_FIT=y
> +CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
> +CONFIG_FIT_IMAGE_POST_PROCESS=y
> +CONFIG_SYS_CONSOLE_INFO_QUIET=y
> +CONFIG_VERSION_VARIABLE=y
> +CONFIG_SPL=y
> +CONFIG_SPL_SYS_MALLOC_SIMPLE=y
> +CONFIG_SPL_STACK_R=y
> +CONFIG_SPL_MTD_SUPPORT=y
> +# CONFIG_CMD_IMLS is not set
> +CONFIG_CMD_ASKENV=y
> +# CONFIG_CMD_FLASH is not set
> +CONFIG_CMD_MMC=y
> +CONFIG_CMD_SF=y
> +CONFIG_CMD_SPI=y
> +CONFIG_CMD_I2C=y
> +CONFIG_CMD_USB=y
> +CONFIG_CMD_DFU=y
> +CONFIG_CMD_GPIO=y
> +# CONFIG_CMD_SETEXPR is not set
> +CONFIG_CMD_EXT4_WRITE=y
> +CONFIG_OF_CONTROL=y
> +CONFIG_OF_LIST="am335x-evm am335x-bone am335x-boneblack am335x-evmsk 
> am335x-bonegreen am335x-icev2"

Just wondering, do we have HS variants of all these boards? If not we
can just keep am335x-evm.

Thanks and regards,
Lokesh

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

[U-Boot] [v4, 2/3] armv8: ls1012a: define esdhc_status_fixup for QDS board

[Yangbo Lu]

The LS1012AQDS board has a hardware issue. When there is no eMMC
adapter card inserted in SDHC2 adapter slot, the command inhibit
bits of eSDHC2_PRSSTAT register will never release. This would cause
below continious error messages in linux since it uses polling mode
to detect card.
"mmc1: Controller never released inhibit bit(s)."
"mmc1: Controller never released inhibit bit(s)."
"mmc1: Controller never released inhibit bit(s)."
This patch is to define esdhc_status_fixup function for QDS to
disable SDHC2 status if no eMMC adapter card is detected.

Signed-off-by: Yangbo Lu 
---
Changes for v2:
- Added annotation in code
- Added return value
- Modified commit message
Changes for v3:
- None
Changes for v4:
- None
---
 board/freescale/ls1012aqds/ls1012aqds.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/board/freescale/ls1012aqds/ls1012aqds.c 
b/board/freescale/ls1012aqds/ls1012aqds.c
index 94440b3..88fb4ce 100644
--- a/board/freescale/ls1012aqds/ls1012aqds.c
+++ b/board/freescale/ls1012aqds/ls1012aqds.c
@@ -121,6 +121,34 @@ int board_eth_init(bd_t *bis)
return pci_eth_init(bis);
 }
 
+int esdhc_status_fixup(void *blob, const char *compat)
+{
+   char esdhc0_path[] = "/soc/esdhc@156";
+   char esdhc1_path[] = "/soc/esdhc@158";
+   u8 card_id;
+
+   do_fixup_by_path(blob, esdhc0_path, "status", "okay",
+sizeof("okay"), 1);
+
+   /*
+* The Presence Detect 2 register detects the installation
+* of cards in various PCI Express or SGMII slots.
+*
+* STAT_PRS2[7:5]: Specifies the type of card installed in the
+* SDHC2 Adapter slot. 0b111 indicates no adapter is installed.
+*/
+   card_id = (QIXIS_READ(present2) & 0xe0) >> 5;
+
+   /* If no adapter is installed in SDHC2, disable SDHC2 */
+   if (card_id == 0x7)
+   do_fixup_by_path(blob, esdhc1_path, "status", "disabled",
+sizeof("disabled"), 1);
+   else
+   do_fixup_by_path(blob, esdhc1_path, "status", "okay",
+sizeof("okay"), 1);
+   return 0;
+}
+
 #ifdef CONFIG_OF_BOARD_SETUP
 int ft_board_setup(void *blob, bd_t *bd)
 {
-- 
2.1.0.27.g96db324

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

[U-Boot] [u-boot] AR8033 SerDes Test and System Mode Control setting issue

[Ken.Lin]

Hi Joe and Mugunthan,

We encountered the voltage peak issue while doing the IEEE PHY conformance 
test, which has to do with the AR8033 register (SetDes Test and System Mode 
Control) setting in u-boot.
In your commit change info, you tried to enable tx clock delay by setting bit 8 
to 1 (filling in 0x100, setting the reserved bits to 0) for solving the auto 
negotiation failure issue.
https://patchwork.ozlabs.org/patch/681801/

After we checked with Qualcomm (Atheros) and they responded that on their 
platform, the register should be set to 0x2C47 (for the reserved bits) and this 
would solve the voltage peak issue we experienced.
Could you please help check if it's appropriate to set the reserved bits 
according to Qualcomm's setting since your commit breaks the original setting 
(see https://community.nxp.com/message/868898 for more details info)?
Please let me know if you have any suggestions/comments on this.

Thank you

Cheers,
Ken Lin


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

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

Re: [U-Boot] [PATCH v3 30/62] x86: Tidy up use of size_t in relocation

[Bin Meng]

On Mon, Jan 16, 2017 at 10:03 PM, Simon Glass  wrote:
> Addresses should not be cast to size_t. Use uintptr_t instead.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  arch/x86/lib/relocate.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 29/62] x86: Add support for 64-bit relocation

[Bin Meng]

On Mon, Jan 16, 2017 at 10:03 PM, Simon Glass  wrote:
> Add a 64-bit relocation function. SPL loads U-Boot into RAM at a fixed
> address and runs it. U-Boot then relocates itself to the top of RAM using
> this relocation function.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  arch/x86/lib/relocate.c | 45 +
>  1 file changed, 45 insertions(+)
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 28/62] x86: Refactor relocation to prepare for 64-bit

[Bin Meng]

On Tue, Jan 17, 2017 at 10:33 AM, Bin Meng  wrote:
> On Mon, Jan 16, 2017 at 10:03 PM, Simon Glass  wrote:
>> Move the core relocation code into a separate function so that the checking
>> code can be used for 64-bit relocation also.
>>
>> Signed-off-by: Simon Glass 
>> ---
>>
>> Changes in v3:
>> - Mention the commit ID containing information about the need for reloc 
>> checks
>> - Drop the pre-panic printf() of the relocation addresses
>>
>> Changes in v2: None
>>
>>  arch/x86/lib/relocate.c | 55 
>> -
>>  1 file changed, 31 insertions(+), 24 deletions(-)
>>
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 26/62] x86: board_r: Set the global data pointer after relocation

[Bin Meng]

On Tue, Jan 17, 2017 at 10:29 AM, Bin Meng  wrote:
> On Mon, Jan 16, 2017 at 10:03 PM, Simon Glass  wrote:
>> Since 'gd' is just a normal variable on 64-bit x86, it is relocated by the
>> time we get to board_init_r(). The old 'gd' variable is passed in as
>> parameter to board_init_r(), presumably for this situation.
>>
>> Assign it on 64-bit x86 so that gd points to the correct data.
>>
>> Options to improve this:
>> - Make gd a fixed register and remove the board_init_r() parameter
>> - Make all archs use this board_init_r() parameter
>>
>> The second has a TODO in the code. The first has a TODO in a future commit
>> ('x86: Support global_data on x86_64')
>>
>> Signed-off-by: Simon Glass 
>> ---
>>
>> Changes in v3:
>> - Add a TODO to board_init_r() regarding the use of the new_gd parameter
>>
>> Changes in v2: None
>>
>>  common/board_r.c | 10 ++
>>  1 file changed, 10 insertions(+)
>>
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 27/62] x86: Do relocation before clearing BSS

[Bin Meng]

On Mon, Jan 16, 2017 at 10:03 PM, Simon Glass  wrote:
> The BSS region may overlap with relocations. If we clear BSS we will
> overwrite the start of the relocation area. This doesn't matter when running
> from SPI flash, since it is read-only. But when relocating 64-bit U-Boot
> from one place in RAM to another, relocation will fail because some of its
> relocations have been zeroed.
>
> To fix this, put the ELF fixup call before the BSS clearing call.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  common/board_f.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 24/62] x86: board_f: Update init sequence for 64-bit startup

[Bin Meng]

On Mon, Jan 16, 2017 at 10:03 PM, Simon Glass  wrote:
> Adjust the code so that 64-bit startup works. Since we don't need to do CAR
> changes in U-Boot proper anymore (they are done in SPL) we can simplify the
> flow and return normally from board_init_f().
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v3:
> - Move 'const' change into its own patch
>
> Changes in v2: None
>
>  common/board_f.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 25/62] board_f/r: Use static const for the init sequences

[Bin Meng]

On Tue, Jan 17, 2017 at 10:27 AM, Bin Meng  wrote:
> On Mon, Jan 16, 2017 at 10:03 PM, Simon Glass  wrote:
>> These tables should be declared static const. Unfortunately the table in
>> board_r is updated on machines with manual relocation.
>>
>> Update them.
>>
>> Signed-off-by: Simon Glass 
>> ---
>>
>> Changes in v3:
>> - Add new patch to use static const for the board_f/r init sequences
>>
>> Changes in v2: None
>>
>>  common/board_f.c | 4 ++--
>>  common/board_r.c | 2 +-
>>  2 files changed, 3 insertions(+), 3 deletions(-)
>>
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 23/62] x86: Add 64-bit start-up code

[Bin Meng]

On Tue, Jan 17, 2017 at 10:25 AM, Bin Meng  wrote:
> On Mon, Jan 16, 2017 at 10:03 PM, Simon Glass  wrote:
>> Add code to start up U-Boot in 64-bit mode. It is fairly simple since we are
>> running from RAM and SPL has done the low-level init.
>>
>> Signed-off-by: Simon Glass 
>> ---
>>
>> Changes in v3:
>> - Drop unused headers
>> - Drop unused board_debug_uart_init function
>> - Use call instead of callq
>>
>> Changes in v2: None
>>
>>  arch/x86/Makefile  |  5 +
>>  arch/x86/cpu/Makefile  |  4 
>>  arch/x86/cpu/start64.S | 28 
>>  3 files changed, 37 insertions(+)
>>  create mode 100644 arch/x86/cpu/start64.S
>>
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 21/62] x86: Use X86_32BIT_INIT instead of X86_RESET_VECTOR

[Bin Meng]

On Mon, Jan 16, 2017 at 10:03 PM, Simon Glass  wrote:
> Use this new option to control the location of 32-bit init. This will allow
> us to place this in SPL if needed.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  arch/x86/cpu/intel_common/Makefile | 10 ++
>  arch/x86/lib/init_helpers.c|  2 +-
>  2 files changed, 7 insertions(+), 5 deletions(-)
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 22/62] x86: ivybridge: Allow 32-bit init to move to SPL

[Bin Meng]

On Mon, Jan 16, 2017 at 10:03 PM, Simon Glass  wrote:
> Update the Makefile so that some 32-bit init can be built into SPL rather
> than U-Boot proper.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  arch/x86/cpu/ivybridge/Makefile | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 28/62] x86: Refactor relocation to prepare for 64-bit

[Bin Meng]

On Mon, Jan 16, 2017 at 10:03 PM, Simon Glass  wrote:
> Move the core relocation code into a separate function so that the checking
> code can be used for 64-bit relocation also.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v3:
> - Mention the commit ID containing information about the need for reloc checks
> - Drop the pre-panic printf() of the relocation addresses
>
> Changes in v2: None
>
>  arch/x86/lib/relocate.c | 55 
> -
>  1 file changed, 31 insertions(+), 24 deletions(-)
>

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

Re: [U-Boot] [PATCH v3 26/62] x86: board_r: Set the global data pointer after relocation

[Bin Meng]

On Mon, Jan 16, 2017 at 10:03 PM, Simon Glass  wrote:
> Since 'gd' is just a normal variable on 64-bit x86, it is relocated by the
> time we get to board_init_r(). The old 'gd' variable is passed in as
> parameter to board_init_r(), presumably for this situation.
>
> Assign it on 64-bit x86 so that gd points to the correct data.
>
> Options to improve this:
> - Make gd a fixed register and remove the board_init_r() parameter
> - Make all archs use this board_init_r() parameter
>
> The second has a TODO in the code. The first has a TODO in a future commit
> ('x86: Support global_data on x86_64')
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v3:
> - Add a TODO to board_init_r() regarding the use of the new_gd parameter
>
> Changes in v2: None
>
>  common/board_r.c | 10 ++
>  1 file changed, 10 insertions(+)
>

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

Re: [U-Boot] [PATCH v3 25/62] board_f/r: Use static const for the init sequences

[Bin Meng]

On Mon, Jan 16, 2017 at 10:03 PM, Simon Glass  wrote:
> These tables should be declared static const. Unfortunately the table in
> board_r is updated on machines with manual relocation.
>
> Update them.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v3:
> - Add new patch to use static const for the board_f/r init sequences
>
> Changes in v2: None
>
>  common/board_f.c | 4 ++--
>  common/board_r.c | 2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
>

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

[U-Boot] [PATCH v3] armv8: aarch64: Fix the warning about x1-x3 nonzero issue

[Alison Wang]

For 64-bit kernel, there is a warning about x1-x3 nonzero in violation
of boot protocol. To fix this issue, input argument 4 is added for
armv8_switch_to_el2 and armv8_switch_to_el1. The input argument 4 will
be set to the right value, such as zero.

Signed-off-by: Alison Wang 
Reviewed-by: Alexander Graf 
Tested-by: Ryan Harkin 
---
Changes in v3:
- Remove redundant code.
Changes in v2:
- Add another input argument 4 for armv8_switch_to_el2 and armv8_switch_to_el1.
- Give up the previous way to adjust the parameters to transfer and make sure 
x3 is zero.

 arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S | 28 ++--
 arch/arm/cpu/armv8/sec_firmware_asm.S|  6 +++---
 arch/arm/cpu/armv8/start.S   |  8 
 arch/arm/cpu/armv8/transition.S  | 22 +++---
 arch/arm/include/asm/system.h|  8 +---
 arch/arm/lib/bootm.c | 10 +-
 arch/arm/mach-rmobile/lowlevel_init_gen3.S   |  8 
 cmd/bootefi.c|  2 +-
 8 files changed, 47 insertions(+), 45 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S 
b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
index 72f2c11..63215f0 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
+++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
@@ -378,29 +378,29 @@ cpu_is_le:
b.eq1f
 
 #ifdef CONFIG_ARMV8_SWITCH_TO_EL1
-   adr x3, secondary_switch_to_el1
-   ldr x4, =ES_TO_AARCH64
+   adr x4, secondary_switch_to_el1
+   ldr x5, =ES_TO_AARCH64
 #else
-   ldr x3, [x11]
-   ldr x4, =ES_TO_AARCH32
+   ldr x4, [x11]
+   ldr x5, =ES_TO_AARCH32
 #endif
bl  secondary_switch_to_el2
 
 1:
 #ifdef CONFIG_ARMV8_SWITCH_TO_EL1
-   adr x3, secondary_switch_to_el1
+   adr x4, secondary_switch_to_el1
 #else
-   ldr x3, [x11]
+   ldr x4, [x11]
 #endif
-   ldr x4, =ES_TO_AARCH64
+   ldr x5, =ES_TO_AARCH64
bl  secondary_switch_to_el2
 
 ENDPROC(secondary_boot_func)
 
 ENTRY(secondary_switch_to_el2)
-   switch_el x5, 1f, 0f, 0f
+   switch_el x6, 1f, 0f, 0f
 0: ret
-1: armv8_switch_to_el2_m x3, x4, x5
+1: armv8_switch_to_el2_m x4, x5, x6
 ENDPROC(secondary_switch_to_el2)
 
 ENTRY(secondary_switch_to_el1)
@@ -414,22 +414,22 @@ ENTRY(secondary_switch_to_el1)
/* physical address of this cpus spin table element */
add x11, x1, x0
 
-   ldr x3, [x11]
+   ldr x4, [x11]
 
ldr x5, [x11, #24]
ldr x6, =IH_ARCH_DEFAULT
cmp x6, x5
b.eq2f
 
-   ldr x4, =ES_TO_AARCH32
+   ldr x5, =ES_TO_AARCH32
bl  switch_to_el1
 
-2: ldr x4, =ES_TO_AARCH64
+2: ldr x5, =ES_TO_AARCH64
 
 switch_to_el1:
-   switch_el x5, 0f, 1f, 0f
+   switch_el x6, 0f, 1f, 0f
 0: ret
-1: armv8_switch_to_el1_m x3, x4, x5
+1: armv8_switch_to_el1_m x4, x5, x6
 ENDPROC(secondary_switch_to_el1)
 
/* Ensure that the literals used by the secondary boot code are
diff --git a/arch/arm/cpu/armv8/sec_firmware_asm.S 
b/arch/arm/cpu/armv8/sec_firmware_asm.S
index 903195d..5ed3677 100644
--- a/arch/arm/cpu/armv8/sec_firmware_asm.S
+++ b/arch/arm/cpu/armv8/sec_firmware_asm.S
@@ -57,7 +57,8 @@ ENDPROC(_sec_firmware_support_psci_version)
  * x0: argument, zero
  * x1: machine nr
  * x2: fdt address
- * x3: kernel entry point
+ * x3: input argument
+ * x4: kernel entry point
  * @param outputs for secure firmware:
  * x0: function id
  * x1: kernel entry point
@@ -65,10 +66,9 @@ ENDPROC(_sec_firmware_support_psci_version)
  * x3: fdt address
 */
 ENTRY(armv8_el2_to_aarch32)
-   mov x0, x3
mov x3, x2
mov x2, x1
-   mov x1, x0
+   mov x1, x4
ldr x0, =0xc000ff04
smc #0
ret
diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
index 9535057..eb1b8a6 100644
--- a/arch/arm/cpu/armv8/start.S
+++ b/arch/arm/cpu/armv8/start.S
@@ -250,14 +250,14 @@ WEAK(lowlevel_init)
/*
 * All slaves will enter EL2 and optionally EL1.
 */
-   adr x3, lowlevel_in_el2
-   ldr x4, =ES_TO_AARCH64
+   adr x4, lowlevel_in_el2
+   ldr x5, =ES_TO_AARCH64
bl  armv8_switch_to_el2
 
 lowlevel_in_el2:
 #ifdef CONFIG_ARMV8_SWITCH_TO_EL1
-   adr x3, lowlevel_in_el1
-   ldr x4, =ES_TO_AARCH64
+   adr x4, lowlevel_in_el1
+   ldr x5, =ES_TO_AARCH64
bl  armv8_switch_to_el1
 
 lowlevel_in_el1:
diff --git a/arch/arm/cpu/armv8/transition.S b/arch/arm/cpu/armv8/transition.S
index adb9f35..ca07465 100644
--- a/arch/arm/cpu/armv8/transition.S
+++ b/arch/arm/cpu/armv8/transition.S
@@ -11,9 +11,9 @@
 #include 
 
 ENTRY(armv8_switch_to_el2)
-   switch_el x5, 1f, 

Re: [U-Boot] [PATCH v3 23/62] x86: Add 64-bit start-up code

[Bin Meng]

On Mon, Jan 16, 2017 at 10:03 PM, Simon Glass  wrote:
> Add code to start up U-Boot in 64-bit mode. It is fairly simple since we are
> running from RAM and SPL has done the low-level init.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v3:
> - Drop unused headers
> - Drop unused board_debug_uart_init function
> - Use call instead of callq
>
> Changes in v2: None
>
>  arch/x86/Makefile  |  5 +
>  arch/x86/cpu/Makefile  |  4 
>  arch/x86/cpu/start64.S | 28 
>  3 files changed, 37 insertions(+)
>  create mode 100644 arch/x86/cpu/start64.S
>

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

Re: [U-Boot] [PATCH v3 18/62] x86: Add Kconfig options to build 64-bit U-Boot

[Bin Meng]

On Mon, Jan 16, 2017 at 10:03 PM, Simon Glass  wrote:
> Add a new CONFIG_X86_64 option which will eventually cause U-Boot to be
> built as a 64-bit application, with SPL doing the 16/32-bit init.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v3:
> - Use tab instead of space in Kconfig help line
>
> Changes in v2: None
>
>  arch/x86/Kconfig | 46 ++
>  1 file changed, 46 insertions(+)
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 20/62] x86: Use X86_16BIT_INIT instead of X86_RESET_VECTOR

[Bin Meng]

On Mon, Jan 16, 2017 at 10:03 PM, Simon Glass  wrote:
> Use this new option to control the location of 16-bit init. This will allow
> us to place this in SPL if needed.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  Makefile| 7 ---
>  arch/x86/Makefile   | 6 ++
>  arch/x86/cpu/Makefile   | 2 +-
>  arch/x86/cpu/u-boot.lds | 2 +-
>  4 files changed, 8 insertions(+), 9 deletions(-)
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 19/62] x86: Kconfig: Add location options for 16/32-bit init

[Bin Meng]

On Mon, Jan 16, 2017 at 10:03 PM, Simon Glass  wrote:
> At present all 16/32-bit init is controlled by CONFIG_X86_RESET_VECTOR. If
> this is enabled, then U-Boot is the 'first' boot loader and handles execution
> from the reset vector through to U-Boot's command prompt. If it is not
> enabled then U-Boot starts at the 32-bit entry and skips most of its init,
> assuming that the previous boot loader has done this already.
>
> With the move to suport 64-bit operation, we have more cases to consider.
> The 16-bit and 32-bit init may be in SPL rather than in U-Boot proper.
>
> Add Kconfig options which control the location of the 16-bit and the 32-bit
> init. These are not intended to be user-setting except for experimentation.
> Their values should be determined by whether 64-bit U-Boot is used.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v3:
> - Fix s/32-bit init/16-bit init/ and expand the comment
>
> Changes in v2: None
>
>  arch/x86/Kconfig | 40 
>  1 file changed, 40 insertions(+)
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 17/62] x86: lib: Fix types and casts for 64-bit compilation

[Bin Meng]

On Mon, Jan 16, 2017 at 10:03 PM, Simon Glass  wrote:
> Fix various compiler warnings in the x86 library code.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v3: None
> Changes in v2:
> - Move table-related changes to an earlier patch
>
>  arch/x86/lib/bios.c | 4 ++--
>  arch/x86/lib/pinctrl_ich6.c | 2 +-
>  arch/x86/lib/pirq_routing.c | 4 ++--
>  3 files changed, 5 insertions(+), 5 deletions(-)
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 16/62] x86: fsp: Fix cast for 64-bit compilation

[Bin Meng]

On Mon, Jan 16, 2017 at 10:03 PM, Simon Glass  wrote:
> Fix a cast in get_next_hob() that causes warnings on 64-bit machines.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v3: None
> Changes in v2:
> - Fix cast in get_guid_hob_data() also
>
>  arch/x86/include/asm/fsp/fsp_hob.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 13/62] x86: ivybridge: Add more debugging for failures

[Bin Meng]

On Mon, Jan 16, 2017 at 10:03 PM, Simon Glass  wrote:
> Add various debug() messages in places where errors occur. This aids with
> debugging.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v3: None
> Changes in v2:
> - Output error code values in debug() statements
>
>  arch/x86/cpu/ivybridge/cpu.c   |  4 +++-
>  arch/x86/cpu/ivybridge/sdram.c | 37 -
>  2 files changed, 31 insertions(+), 10 deletions(-)
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 15/62] x86: dts: Mark serial as needed before relocation

[Bin Meng]

On Mon, Jan 16, 2017 at 10:03 PM, Simon Glass  wrote:
> We almost always need the serial port before relocation, so mark it as such.
> This will ensure that it appears in the device tree for SPL, if used.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  arch/x86/dts/serial.dtsi | 1 +
>  1 file changed, 1 insertion(+)
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 14/62] x86: ivybridge: Fix types for 64-bit compilation

[Bin Meng]

On Mon, Jan 16, 2017 at 10:03 PM, Simon Glass  wrote:
> Fix a few types that causes warnings on 64-bit machines.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v3: None
> Changes in v2:
> - Fix cast in bd82x6x_video_probe() also
>
>  arch/x86/cpu/ivybridge/sata.c | 4 ++--
>  drivers/video/ivybridge_igd.c | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 11/62] x86: Update mpspec to build on 64-bit machines

[Bin Meng]

On Mon, Jan 16, 2017 at 10:03 PM, Simon Glass  wrote:
> At present this uses u32 to store an address. We should use unsigned long
> and avoid special types in function return values and parameters unless
> necessary. This makes the code more portable.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v3:
> - Drop WIP tag as this patch is actually needed
>
> Changes in v2: None
>
>  arch/x86/include/asm/mpspec.h |  8 
>  arch/x86/lib/mpspec.c | 12 ++--
>  2 files changed, 10 insertions(+), 10 deletions(-)
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 12/62] x86: ivybridge: Declare global data where it is used

[Bin Meng]

On Mon, Jan 16, 2017 at 10:03 PM, Simon Glass  wrote:
> Some files are missing this declaration. Add it to avoid build errors when
> we actually need the declaration.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v3: None
> Changes in v2:
> - Drop change to gma.c
>
>  arch/x86/cpu/ivybridge/bd82x6x.c | 2 ++
>  arch/x86/cpu/ivybridge/lpc.c | 2 ++
>  arch/x86/cpu/ivybridge/model_206ax.c | 2 ++
>  arch/x86/cpu/ivybridge/northbridge.c | 2 ++
>  drivers/video/ivybridge_igd.c| 2 ++
>  5 files changed, 10 insertions(+)
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 10/62] x86: Use unsigned long for address in table generation

[Bin Meng]

On Mon, Jan 16, 2017 at 10:03 PM, Simon Glass  wrote:
> We should use unsigned long rather than u32 for addresses. Update this so
> that the table-generation code builds correctly on 64-bit machines.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v3: None
> Changes in v2:
> - Move table-related changes from a later patch
> - Rebase to mainline
> - Drop the write_smbios_table_wrapper() function
>
>  arch/x86/cpu/irq.c|  2 +-
>  arch/x86/include/asm/acpi_table.h |  2 +-
>  arch/x86/include/asm/mpspec.h |  2 +-
>  arch/x86/include/asm/sfi.h|  2 +-
>  arch/x86/include/asm/tables.h |  2 +-
>  arch/x86/lib/acpi_table.c |  4 ++--
>  arch/x86/lib/mpspec.c |  2 +-
>  arch/x86/lib/sfi.c|  6 +++---
>  arch/x86/lib/tables.c | 11 ++-
>  arch/x86/lib/zimage.c |  2 +-
>  drivers/misc/qfw.c|  4 ++--
>  include/smbios.h  |  4 ++--
>  lib/smbios.c  | 22 +++---
>  13 files changed, 29 insertions(+), 36 deletions(-)
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 08/62] spl: Allow PCH drivers to be used in SPL

[Bin Meng]

On Mon, Jan 16, 2017 at 10:03 PM, Simon Glass  wrote:
> Add an option for building Platorm Controller Hub drivers in SPL.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  common/spl/Kconfig | 9 +
>  drivers/Makefile   | 1 +
>  2 files changed, 10 insertions(+)
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 07/62] spl: Allow timer drivers to be used in SPL

[Bin Meng]

On Mon, Jan 16, 2017 at 10:03 PM, Simon Glass  wrote:
> Add a new Kconfig option to allow timer drivers to be used in SPL.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  common/spl/Kconfig | 9 +
>  drivers/Makefile   | 1 +
>  2 files changed, 10 insertions(+)
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 09/62] spl: Don't create a BSS padding when it is separate

[Bin Meng]

On Mon, Jan 16, 2017 at 10:03 PM, Simon Glass  wrote:
> When BSS does not immediate follow the SPL image we don't need padding
> before the device tree. Remove it in this case.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  scripts/Makefile.spl | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 05/62] spl: Allow PCI drivers to be used in SPL

[Bin Meng]

On Mon, Jan 16, 2017 at 10:03 PM, Simon Glass  wrote:
> Add a new Kconfig option to allow PCI drivers to be used in SPL.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  common/spl/Kconfig | 9 +
>  drivers/Makefile   | 1 +
>  2 files changed, 10 insertions(+)
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 04/62] spl: Allow CPU drivers to be used in SPL

[Bin Meng]

On Mon, Jan 16, 2017 at 10:03 PM, Simon Glass  wrote:
> Add a new Kconfig option to allow CPU drivers to be used in SPL.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  common/spl/Kconfig | 10 ++
>  drivers/Makefile   |  1 +
>  2 files changed, 11 insertions(+)
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 06/62] spl: Allow RTC drivers to be used in SPL

[Bin Meng]

On Mon, Jan 16, 2017 at 10:03 PM, Simon Glass  wrote:
> Add a new Kconfig option to allow RTC drivers to be used in SPL.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  common/spl/Kconfig | 10 ++
>  drivers/Makefile   |  1 +
>  2 files changed, 11 insertions(+)
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 02/62] spl: spi: Add a debug message if loading fails

[Bin Meng]

On Mon, Jan 16, 2017 at 10:03 PM, Simon Glass  wrote:
> This currently fails silently. Add a debug message to aid debugging.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v3: None
> Changes in v2:
> - Show the error value in spl_spi_load_image()
>
>  common/spl/spl_spi.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 03/62] spl: Makefile: Define SPL_ earlier

[Bin Meng]

On Mon, Jan 16, 2017 at 10:03 PM, Simon Glass  wrote:
> This Makefile variable can be used in the architecture's main Makefile but
> at present it is not set up until later. Set it just before this Makefile is
> included.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  scripts/Makefile.spl | 6 ++
>  1 file changed, 6 insertions(+)
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 01/62] console: Don't enable CONFIG-CONSOLE_MUX, etc. in SPL

[Bin Meng]

On Mon, Jan 16, 2017 at 10:03 PM, Simon Glass  wrote:
> CONFIG_CONSOLE_MUX and CONFIG_SYS_CONSOLE_IS_IN_ENV are not applicable
> for SPL. Update the console code to use CONFIG_IS_ENABLED(), so that these
> options will be inactive in SPL.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v3:
> - update iomux.c and usb_kbd.c also
>
> Changes in v2: None
>
>  common/console.c | 30 +++---
>  common/iomux.c   |  4 ++--
>  common/usb_kbd.c |  6 +++---
>  3 files changed, 20 insertions(+), 20 deletions(-)
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] armv8: aarch64: Fix the warning about x1-x3 nonzero issue

[Alison Wang]

> On 16/01/2017 07:16, Alison Wang wrote:
> > For 64-bit kernel, there is a warning about x1-x3 nonzero in
> violation
> > of boot protocol. To fix this issue, input argument 4 is added for
> > armv8_switch_to_el2 and armv8_switch_to_el1. The input argument 4
> will
> > be set to the right value, such as zero.
> >
> > Signed-off-by: Alison Wang 
> > ---
> > Changes in v2:
> > - Add another input argument 4 for armv8_switch_to_el2 and
> armv8_switch_to_el1.
> > - Give up the previous way to adjust the parameters to transfer and
> make sure x3 is zero.
> >
> >  arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S | 28 ++
> --
> >  arch/arm/cpu/armv8/sec_firmware_asm.S|  5 +++--
> >  arch/arm/cpu/armv8/start.S   |  8 
> >  arch/arm/cpu/armv8/transition.S  | 22 +++---
> 
> >  arch/arm/include/asm/system.h|  8 +---
> >  arch/arm/lib/bootm.c | 10 +-
> >  arch/arm/mach-rmobile/lowlevel_init_gen3.S   |  8 
> >  cmd/bootefi.c|  2 +-
> >  8 files changed, 47 insertions(+), 44 deletions(-)
> >
> > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
> > b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
> > index 72f2c11..63215f0 100644
> > --- a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
> > +++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
> > @@ -378,29 +378,29 @@ cpu_is_le:
> > b.eq1f
> >
> >  #ifdef CONFIG_ARMV8_SWITCH_TO_EL1
> > -   adr x3, secondary_switch_to_el1
> > -   ldr x4, =ES_TO_AARCH64
> > +   adr x4, secondary_switch_to_el1
> > +   ldr x5, =ES_TO_AARCH64
> >  #else
> > -   ldr x3, [x11]
> > -   ldr x4, =ES_TO_AARCH32
> > +   ldr x4, [x11]
> > +   ldr x5, =ES_TO_AARCH32
> >  #endif
> > bl  secondary_switch_to_el2
> >
> >  1:
> >  #ifdef CONFIG_ARMV8_SWITCH_TO_EL1
> > -   adr x3, secondary_switch_to_el1
> > +   adr x4, secondary_switch_to_el1
> >  #else
> > -   ldr x3, [x11]
> > +   ldr x4, [x11]
> >  #endif
> > -   ldr x4, =ES_TO_AARCH64
> > +   ldr x5, =ES_TO_AARCH64
> > bl  secondary_switch_to_el2
> >
> >  ENDPROC(secondary_boot_func)
> >
> >  ENTRY(secondary_switch_to_el2)
> > -   switch_el x5, 1f, 0f, 0f
> > +   switch_el x6, 1f, 0f, 0f
> >  0: ret
> > -1: armv8_switch_to_el2_m x3, x4, x5
> > +1: armv8_switch_to_el2_m x4, x5, x6
> >  ENDPROC(secondary_switch_to_el2)
> >
> >  ENTRY(secondary_switch_to_el1)
> > @@ -414,22 +414,22 @@ ENTRY(secondary_switch_to_el1)
> > /* physical address of this cpus spin table element */
> > add x11, x1, x0
> >
> > -   ldr x3, [x11]
> > +   ldr x4, [x11]
> >
> > ldr x5, [x11, #24]
> > ldr x6, =IH_ARCH_DEFAULT
> > cmp x6, x5
> > b.eq2f
> >
> > -   ldr x4, =ES_TO_AARCH32
> > +   ldr x5, =ES_TO_AARCH32
> > bl  switch_to_el1
> >
> > -2: ldr x4, =ES_TO_AARCH64
> > +2: ldr x5, =ES_TO_AARCH64
> >
> >  switch_to_el1:
> > -   switch_el x5, 0f, 1f, 0f
> > +   switch_el x6, 0f, 1f, 0f
> >  0: ret
> > -1: armv8_switch_to_el1_m x3, x4, x5
> > +1: armv8_switch_to_el1_m x4, x5, x6
> >  ENDPROC(secondary_switch_to_el1)
> >
> > /* Ensure that the literals used by the secondary boot code are
> diff
> > --git a/arch/arm/cpu/armv8/sec_firmware_asm.S
> > b/arch/arm/cpu/armv8/sec_firmware_asm.S
> > index 903195d..747b53f 100644
> > --- a/arch/arm/cpu/armv8/sec_firmware_asm.S
> > +++ b/arch/arm/cpu/armv8/sec_firmware_asm.S
> > @@ -57,7 +57,8 @@ ENDPROC(_sec_firmware_support_psci_version)
> >   * x0: argument, zero
> >   * x1: machine nr
> >   * x2: fdt address
> > - * x3: kernel entry point
> > + * x3: input argument
> > + * x4: kernel entry point
> >   * @param outputs for secure firmware:
> >   * x0: function id
> >   * x1: kernel entry point
> > @@ -65,7 +66,7 @@ ENDPROC(_sec_firmware_support_psci_version)
> >   * x3: fdt address
> >  */
> >  ENTRY(armv8_el2_to_aarch32)
> > -   mov x0, x3
> > +   mov x0, x4
> 
> You no longer need x0 as scratch register. Just write ...
> 
> > mov x3, x2
> > mov x2, x1
> > mov x1, x0
> 
> ... x4 directly into x1 here.
> 
> 
> Otherwise looks good to me. So with the change above you can add my
> 
>Reviewed-by: Alexander Graf 
> 
> tag in the next version.
> 
[Alison Wang] Alex, thanks for your detail comment. I will change it in v3.


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

Re: [U-Boot] [PATCH v1 1/1] x86: Synchronize list of x86 subarchitectures (update bootparam.h)

[Bin Meng]

On Tue, Jan 17, 2017 at 9:46 AM, Bin Meng  wrote:
> On Mon, Jan 9, 2017 at 4:51 AM, Andy Shevchenko
>  wrote:
>> Basically rename X86_SUBARCH_MRST to X86_SUBARCH_INTEL_MID to be more 
>> specific.
>>
>> Signed-off-by: Andy Shevchenko 
>> ---
>>  arch/x86/include/asm/bootparam.h | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v1 1/1] x86: Synchronize list of x86 subarchitectures (update bootparam.h)

[Bin Meng]

On Mon, Jan 9, 2017 at 4:51 AM, Andy Shevchenko
 wrote:
> Basically rename X86_SUBARCH_MRST to X86_SUBARCH_INTEL_MID to be more 
> specific.
>
> Signed-off-by: Andy Shevchenko 
> ---
>  arch/x86/include/asm/bootparam.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>

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

Re: [U-Boot] armv8: fix #if around spin-table code in start.S

[Tom Rini]

On Mon, Jan 16, 2017 at 10:19:46AM +0900, Masahiro Yamada wrote:
> Hi Tom.
> 
> 
> 2017-01-16 3:29 GMT+09:00 Tom Rini :
> > On Tue, Dec 27, 2016 at 11:19:43AM +0200, Oded Gabbay wrote:
> >
> >> Using CONFIG_IS_ENABLED() doesn't work in SPL. This patch replaces the only
> >> occurrence of CONFIG_IS_ENABLED() in start.S to a regular #if defined().
> >> It also adds "&& !defined(CONFIG_SPL_BUILD)" to that #if statement because
> >> the spin-table code can't currently work in SPL, and the spin-table file
> >> isn't even compiled in SPL.
> >>
> >> Signed-off-by: Oded Gabbay 
> >
> > Applied to u-boot/master, thanks!
> >
> > --
> > Tom
> >
> 
> 
> I had not noticed this patch until it was applied.
> 
> At least, the statement in the git-log
> "Using CONFIG_IS_ENABLED() doesn't work in SPL" is wrong.
> So, when I saw the git history today, I wondered what was going on.
> Then, I found this discussion in the ML.
> 
> It does not matter to either apply or discard this patch
> because it is a matter of taste.
> 
> 
> If you decide to apply it,
> the git-log should have been replaced with Oded's comment:
> 
> 
> You need to go to kconfig.h, read the comments there to
> understand how CONFIG_IS_ENABLED is working with SPL, which is more
> tiresome than just doing straight #ifdef. It is definitely more
> confusing for a newbee.
> 
> In addition, this patch makes the code more consistent, because all
> other configuration checks in start.S use a straight #ifdef and not
> CONFIG_IS_ENABLED.
> --
> 
> 
> It is too late this time, but please take care of it next time.

Yeah, I should have asked for a v2 with a different commit message.

-- 
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] [PATCHv7 1/2] armv8/ls1043a: fixup GIC offset for ls1043a rev1

[york sun]

On 01/13/2017 03:27 AM, Zhiqiang Hou wrote:



> diff --git a/arch/arm/include/asm/arch-fsl-layerscape/config.h 
> b/arch/arm/include/asm/arch-fsl-layerscape/config.h
> index c50894a..577f00c 100644
> --- a/arch/arm/include/asm/arch-fsl-layerscape/config.h
> +++ b/arch/arm/include/asm/arch-fsl-layerscape/config.h
> @@ -174,6 +174,30 @@
>  /* Generic Interrupt Controller Definitions */
>  #define GICD_BASE0x01401000
>  #define GICC_BASE0x01402000
> +#define GICH_BASE0x01404000
> +#define GICV_BASE0x01406000
> +#define GICD_SIZE0x1000
> +#define GICC_SIZE0x2000
> +#define GICH_SIZE0x2000
> +#define GICV_SIZE0x2000
> +#ifdef CONFIG_HAS_FEATURE_GIC64K_ALIGN
> +#define GICD_BASE_64K0x0141
> +#define GICC_BASE_64K0x0142
> +#define GICH_BASE_64K0x0144
> +#define GICV_BASE_64K0x0146
> +#define GICD_SIZE_64K0x1
> +#define GICC_SIZE_64K0x2
> +#define GICH_SIZE_64K0x2
> +#define GICV_SIZE_64K0x2
> +#endif
> +
> +#define DCFG_CCSR_SVR0x1ee00a4
> +#define REV1_0   0x10
> +#define REV1_1   0x11
> +#define GIC_ADDR_BIT 31
> +#define SCFG_GIC400_ALIGN0x1570188
> +#define LS1043A_SVR  0x8792

There is already a macro SVR_LS1043A defined in 
arch/arm/include/asm/arch-fsl-layerscape/soc.h. Can you use that instead?

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

Re: [U-Boot] [PATCH v6 01/13] binman: Introduce binman, a tool for building binary images

[Jörg Krause]

Hi,

On Fri, 2016-11-25 at 20:15 -0700, Simon Glass wrote:
> This adds the basic code for binman, including command parsing,
> processing
> of entries and generation of images.
> 
> So far no entry types are supported. These will be added in future
> commits
> as examples of how to add new types.
> 
> See the README for documentation.
> 
> Signed-off-by: Simon Glass 
> ---
> 

[snip]

> +
> +To do
> +-
> +
> +Some ideas:
> +- Fill out the device tree to include the final position and size of
> each
> +  entry (since the input file may not always specify these)
> +- Use of-platdata to make the information available to code that is
> unable
> +  to use device tree (such as a very small SPL image)
> +- Write an image map to a text file
> +- Allow easy building of images by specifying just the board name
> +- Produce a full Python binding for libfdt (for upstream)
> +- Add an option to decode an image into the constituent binaries
> +- Suppoort hierarchical images (packing of binaries into another
> binary
> +  which is then placed in the image)
> +- Support building an image for a board (-b) more completely, with a
> +  configurable build directory
> +- Consider making binman work with buildman, although if it is used
> in the
> +  Makefile, this will be automatic
> +- Implement align-end

Any plans to add support for Python 3 as it is done for patman?

Best regards,
Jörg Krause
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] armv8: fsl-layerscape: Fix SECURE_BOOT config

[york sun]

On 01/14/2017 09:13 AM, Simon Glass wrote:
> On 4 January 2017 at 11:32, York Sun  wrote:
>> Without a prompt in Kconfig, SECURE_BOOT cannot be selected by
>> defconfig. The option was dropped unintentionally when defconfig
>> files were cleaned up. Three targets were impacted
>> ls1043ardb_SECURE_BOOT, ls2080ardb_SECURE_BOOT,
>> ls2080aqds_SECURE_BOOT.
>>
>> Signed-off-by: York Sun 
>>
>> ---
>>
>>  arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 2 +-
>>  configs/ls1043ardb_SECURE_BOOT_defconfig  | 1 +
>>  configs/ls2080aqds_SECURE_BOOT_defconfig  | 1 +
>>  configs/ls2080ardb_SECURE_BOOT_defconfig  | 1 +
>>  4 files changed, 4 insertions(+), 1 deletion(-)
>
> Reviewed-by: Simon Glass 
>
> It might be worth pointing to your README in the Kconfig help.

You meant the README for secure boot, didn't you? I wish there is such file.

York

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

Re: [U-Boot] [PATCH] powerpc: mpc83xx: Enable pre-relocation malloc

[york sun]

On 01/06/2017 08:32 AM, Joakim Tjernlund wrote:
> On Fri, 2017-01-06 at 14:56 +0100, Mario Six wrote:
>> To enable DM on MPC83xx, we need pre-relocation malloc, which is
>> implemented in this patch.
>>
>
> Would be nice if you could avoid using r1, each time you modify r1 gdb will be
> upset/confused if you ever try to debug start.S with gdb.
>
> I guess the whole file need a bit of trimming to avoid using r1 but one has 
> to start somewhere.
>
>  Jocke
>

Guys,

I am not a mpc83xx maintainer. If the patch is agreed, I can bring it in 
with mpc85xx. If r1 needs some rework, please continue.

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

Re: [U-Boot] [PATCH v2] board/t1024rdb: enable board-level reset when issuing reset command

[york sun]

On 01/11/2017 09:39 PM, Shengzhou Liu wrote:
> As board-specific reset logic, it needs to issue reset signal
> via CPLD when issuing 'reset' command in u-boot, this patch
> solves the issue of reset command not working on T1024RDB.
>
> Signed-off-by: Shengzhou Liu 
> ---
> v2: add build condition.
>
>  board/freescale/t102xrdb/t102xrdb.c | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/board/freescale/t102xrdb/t102xrdb.c 
> b/board/freescale/t102xrdb/t102xrdb.c
> index 01dbf38..0f453a7 100644
> --- a/board/freescale/t102xrdb/t102xrdb.c
> +++ b/board/freescale/t102xrdb/t102xrdb.c
> @@ -167,6 +167,13 @@ unsigned long get_board_ddr_clk(void)
>   return CONFIG_DDR_CLK_FREQ;
>  }
>
> +#ifdef CONFIG_T1024RDB

Shengzhou

This macro is no longer used. Please use CONFIG_TARGET_T1024RDB instead.

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

Re: [U-Boot] [PATCH v3 1/3] SECURE_BOOT: Enable chain of trust on LS1046A platform

[york sun]

On 01/05/2017 10:32 PM, Sumit Garg wrote:
> Define bootscript and its header addresses for QSPI target. Also
> define PPA header address to enable PPA validation.
>
> Signed-off-by: Vinitha Pillai 
> Signed-off-by: Sumit Garg 
> ---
>
> Changes in v3:
> Changes in comment style.
>
> Changes in v2:
> Split patches logically from 2 to 3.
>
>  arch/arm/include/asm/arch-fsl-layerscape/config.h |  2 +-
>  arch/arm/include/asm/fsl_secure_boot.h| 20 +++-
>  2 files changed, 16 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-fsl-layerscape/config.h 
> b/arch/arm/include/asm/arch-fsl-layerscape/config.h
> index 6073d44..dd5ce9d 100644
> --- a/arch/arm/include/asm/arch-fsl-layerscape/config.h
> +++ b/arch/arm/include/asm/arch-fsl-layerscape/config.h
> @@ -175,7 +175,7 @@
>
>  #define CONFIG_SYS_FSL_IFC_BE
>  #define CONFIG_SYS_FSL_SFP_VER_3_2
> -#define CONFIG_SYS_FSL_SNVS_LE
> +#define CONFIG_SYS_FSL_SEC_MON_BE
>  #define CONFIG_SYS_FSL_SFP_BE
>  #define CONFIG_SYS_FSL_SRK_LE
>  #define CONFIG_KEY_REVOCATION
> diff --git a/arch/arm/include/asm/fsl_secure_boot.h 
> b/arch/arm/include/asm/fsl_secure_boot.h
> index 4525287..b270c96 100644
> --- a/arch/arm/include/asm/fsl_secure_boot.h
> +++ b/arch/arm/include/asm/fsl_secure_boot.h
> @@ -59,9 +59,10 @@
>
>  #endif
>
> -#if defined(CONFIG_LS1043A) || defined(CONFIG_LS2080A)
> -/* For LS1043 (ARMv8), ESBC image Address in Header is 64 bit
> - * Similiarly for LS2080
> +#if defined(CONFIG_FSL_LAYERSCAPE)
> +/*
> + * For fsl layerscape based platforms, ESBC image Address in Header
> + * is 64 bit.
>   */
>  #define CONFIG_ESBC_ADDR_64BIT
>  #endif
> @@ -103,12 +104,19 @@
>  #define CONFIG_BS_ADDR_DEVICE0x0840
>  #define CONFIG_BS_HDR_SIZE   0x0010
>  #define CONFIG_BS_SIZE   0x0008
> -#else
> +#elif defined(CONFIG_QSPI_BOOT)
> +#ifdef CONFIG_ARCH_LS1046A
> +#define CONFIG_BS_HDR_ADDR_DEVICE0x4078
> +#define CONFIG_BS_ADDR_DEVICE0x4080
> +#endif

How about #else? If you don't expect #else here, please put an error. 
You may have other than LS1046A in the future.

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

Re: [U-Boot] [PATCH][v2] driver: net: fsl-mc: Use aligned address for MC FW load

[york sun]

On 01/09/2017 10:22 PM, Priyanka Jain wrote:
> Firmware of Management Complex (MC) should be loaded at 512MB aligned
> address. So,
> -mc_ram_addr address calculation in mc_get_dram_addr() is updated to
>  fetch aligned address
> -calculate_mc_private_ram_params() is removed as it is no longer required
> -num_256mb_blocks calculation is moved to mc_init()
>
> Signed-off-by: Priyanka Jain 
> ---
> Changes for v2:
>  Update mc_get_dram_addr() logic for adress calculation instead of
>  updating variable mc_ram_addr
>
>  drivers/net/fsl-mc/mc.c |   87 
> ++-
>  1 files changed, 33 insertions(+), 54 deletions(-)
>
> diff --git a/drivers/net/fsl-mc/mc.c b/drivers/net/fsl-mc/mc.c
> index 46b8a6b..06d373d 100644
> --- a/drivers/net/fsl-mc/mc.c
> +++ b/drivers/net/fsl-mc/mc.c
> @@ -41,6 +41,7 @@ struct fsl_dpbp_obj *dflt_dpbp = NULL;
>  struct fsl_dpio_obj *dflt_dpio = NULL;
>  struct fsl_dpni_obj *dflt_dpni = NULL;
>  static u64 mc_lazy_dpl_addr;
> +u64 mc_ram_addr = 0;

You have global variable with the same name as local variable. It is 
confusing to me. Please avoid using global variable.

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

Re: [U-Boot] ARM - cache and alignment

[Marek Vasut]

On 01/16/2017 08:16 PM, Jean-Jacques Hiblot wrote:
> 
> 
> On 16/01/2017 17:00, Marek Vasut wrote:
>> On 01/16/2017 02:29 PM, Jean-Jacques Hiblot wrote:
>>> Tom, Marek
>> Hi,
>>
>>> At the moment, whenever an unaligned address is used in cache operations
>>> (invalidate_dcache_range, or flush_dcache_range), the whole request is
>>> discarded  for am926ejs. for armV7 or armV8 only the aligned part is
>>> maintained. This is probably what is causing the bug addressed in
>>> 8133f43d1cd. There are a lot of unaligned buffers used in DMA operations
>>> and for all of them, we're possibly handling the cached partially or not
>>> at all. I've seen this when using the environment from a file stored in
>>> a FAT partition. commit 8133f43d1cd addresses this by using a bounce
>>> buffer at the FAT level but it's only one of many cases.
>>>
>>> I think we can do better with unaligned cache operations:
>>>
>>> * flush (writeback + invalidate): Suppose we use address p which is
>>> unaligned, flush_dcache_range() can do the writeback+invalidate on the
>>> whole range [p & ~(line_sz - 1); p + length | (line_sz - 1)]. There
>>> should no problem with that since writeback can happen at any point in
>>> time.
>>>
>>> * invalidation
>>>
>>> It is a bit trickier. here is a pseudo-code:
>>> invalidate_dcache_range(p,length)
>>> {
>>>   write_back_invalidate(first line)
>>>   write_back_invalidate(last line)
>>>   invalidate(all other lines)
>>> }
>>>
>>> Here again this should work fine IF invalidate_dcache_range() is called
>>> BEFORE the DMA operation (again the writeback can happen at time so it's
>>> valid do it here). Calling it only AFTER the operation, may corrupt the
>>> data written by the DMA with old data from CPU. This how I used to
>>> handle unaligned buffers in some other projects.
>>>
>>>
>>> There is however one loophole: a data sitting in the first or the last
>>> line is accessed before the memory is updated by the DMA, then the
>>> first/line will be corrupted. But it's not highly probable as this data
>>> would have to be used in parallel of the DMA (interrupt handling, SMP?,
>>> dma mgt related variable). So it's not perfect but it would still be
>>> better than we have today.
>> Or just fix all the code which complains about unaligned buffers, done.
>> That's the way to go without all the complications above.
> It's not that complex, but it's not perfect. We would need to keep the
> same warning as we have now, but it would make it work in more cases.

The warning is there for that exact reason -- to inform you something's
wrong.

> Tracking every possible unaligned buffer that gets invalidated is not a
> trivial job. Most of the time the buffer is allocated in a upper layer
> and passed down to a driver via layers like network stack, block layer
> etc.And in many cases, the warning will come and go depending on how the
> variable aligned on the stack or the heap.

I didn't observe this much in fact. I usually see the buffers coming it
aligned or being allocated in drivers. Also, I think that's why the RC
cycle is there, so we can test the next release and fix these issues.


-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] ARM - cache and alignment

[Jean-Jacques Hiblot]

On 16/01/2017 17:00, Marek Vasut wrote:

On 01/16/2017 02:29 PM, Jean-Jacques Hiblot wrote:

Tom, Marek

Hi,


At the moment, whenever an unaligned address is used in cache operations
(invalidate_dcache_range, or flush_dcache_range), the whole request is
discarded  for am926ejs. for armV7 or armV8 only the aligned part is
maintained. This is probably what is causing the bug addressed in
8133f43d1cd. There are a lot of unaligned buffers used in DMA operations
and for all of them, we're possibly handling the cached partially or not
at all. I've seen this when using the environment from a file stored in
a FAT partition. commit 8133f43d1cd addresses this by using a bounce
buffer at the FAT level but it's only one of many cases.

I think we can do better with unaligned cache operations:

* flush (writeback + invalidate): Suppose we use address p which is
unaligned, flush_dcache_range() can do the writeback+invalidate on the
whole range [p & ~(line_sz - 1); p + length | (line_sz - 1)]. There
should no problem with that since writeback can happen at any point in
time.

* invalidation

It is a bit trickier. here is a pseudo-code:
invalidate_dcache_range(p,length)
{
  write_back_invalidate(first line)
  write_back_invalidate(last line)
  invalidate(all other lines)
}

Here again this should work fine IF invalidate_dcache_range() is called
BEFORE the DMA operation (again the writeback can happen at time so it's
valid do it here). Calling it only AFTER the operation, may corrupt the
data written by the DMA with old data from CPU. This how I used to
handle unaligned buffers in some other projects.


There is however one loophole: a data sitting in the first or the last
line is accessed before the memory is updated by the DMA, then the
first/line will be corrupted. But it's not highly probable as this data
would have to be used in parallel of the DMA (interrupt handling, SMP?,
dma mgt related variable). So it's not perfect but it would still be
better than we have today.

Or just fix all the code which complains about unaligned buffers, done.
That's the way to go without all the complications above.
It's not that complex, but it's not perfect. We would need to keep the 
same warning as we have now, but it would make it work in more cases.


Tracking every possible unaligned buffer that gets invalidated is not a 
trivial job. Most of the time the buffer is allocated in a upper layer 
and passed down to a driver via layers like network stack, block layer 
etc.And in many cases, the warning will come and go depending on how the 
variable aligned on the stack or the heap.






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

Re: [U-Boot] [PATCH v2] splash: fix splash source flags check

[Michael Nazzareno Trimarchi]

Hi



On 14 Jan 2017 3:54 a.m., "Anatolij Gustschin"  wrote:

From: "tomas.me...@vaisala.com" 

SPLASH_STORAGE_RAW is defined as 0, so a check against & will
never be true. These flags are never combined so do a check
against == instead.

Signed-off-by: Tomas Melin 
Reviewed-by: Tom Rini 
---

Changes in v2:
- rebased on u-boot-video/master

 common/splash_source.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/common/splash_source.c b/common/splash_source.c
index 4c64f10..a5eeb3f 100644
--- a/common/splash_source.c
+++ b/common/splash_source.c
@@ -395,9 +395,9 @@ int splash_source_load(struct splash_location
*locations, uint size)
if (!splash_location)
return -EINVAL;

-   if (splash_location->flags & SPLASH_STORAGE_RAW)
+   if (splash_location->flags == SPLASH_STORAGE_RAW)
return splash_load_raw(splash_location, bmp_load_addr);
-   else if (splash_location->flags & SPLASH_STORAGE_FS)
+   else if (splash_location->flags == SPLASH_STORAGE_FS)
return splash_load_fs(splash_location, bmp_load_addr);
 #ifdef CONFIG_FIT
else if (splash_location->flags == SPLASH_STORAGE_FIT)


So switch

Michael

--
2.7.4

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

[U-Boot] Please pull u-boot-video/master

[Anatolij Gustschin]

Hi Tom,

The following changes since commit a705ebc81b7f91bbd0ef7c634284208342901149:

  Prepare v2017.01 (2017-01-09 11:57:05 -0500)

are available in the git repository at:

  git://git.denx.de/u-boot-video.git master

for you to fetch changes up to 3b593f9030bae149af9261f51933805be506f6b1:

  splash: fix splash source flags check (2017-01-13 20:45:25 +0100)


Anatolij Gustschin (1):
  video: cfb_console: fix hang if splashimage file is missing

tomas.me...@vaisala.com (3):
  splash: sort include files
  splash: add support for loading splash from a FIT image
  splash: fix splash source flags check

 common/image-fit.c  | 48 
 common/splash_source.c  | 89 -
 doc/README.splashprepare| 15 +---
 drivers/video/cfb_console.c |  6 ++-
 include/image.h |  4 ++
 include/splash.h|  5 ++-
 6 files changed, 149 insertions(+), 18 deletions(-)

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

Re: [U-Boot] [PATCH v2] splash: fix splash source flags check

[Anatolij Gustschin]

On Fri, 13 Jan 2017 20:54:23 +0100
Anatolij Gustschin ag...@denx.de wrote:
... 
>  common/splash_source.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

applied to u-boot-video/master.

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

Re: [U-Boot] ARM - cache and alignment

[Marek Vasut]

On 01/16/2017 02:29 PM, Jean-Jacques Hiblot wrote:
> Tom, Marek

Hi,

> At the moment, whenever an unaligned address is used in cache operations
> (invalidate_dcache_range, or flush_dcache_range), the whole request is
> discarded  for am926ejs. for armV7 or armV8 only the aligned part is
> maintained. This is probably what is causing the bug addressed in
> 8133f43d1cd. There are a lot of unaligned buffers used in DMA operations
> and for all of them, we're possibly handling the cached partially or not
> at all. I've seen this when using the environment from a file stored in
> a FAT partition. commit 8133f43d1cd addresses this by using a bounce
> buffer at the FAT level but it's only one of many cases.
> 
> I think we can do better with unaligned cache operations:
> 
> * flush (writeback + invalidate): Suppose we use address p which is
> unaligned, flush_dcache_range() can do the writeback+invalidate on the
> whole range [p & ~(line_sz - 1); p + length | (line_sz - 1)]. There
> should no problem with that since writeback can happen at any point in
> time.
> 
> * invalidation
> 
> It is a bit trickier. here is a pseudo-code:
> invalidate_dcache_range(p,length)
> {
>  write_back_invalidate(first line)
>  write_back_invalidate(last line)
>  invalidate(all other lines)
> }
> 
> Here again this should work fine IF invalidate_dcache_range() is called
> BEFORE the DMA operation (again the writeback can happen at time so it's
> valid do it here). Calling it only AFTER the operation, may corrupt the
> data written by the DMA with old data from CPU. This how I used to
> handle unaligned buffers in some other projects.
> 
> 
> There is however one loophole: a data sitting in the first or the last
> line is accessed before the memory is updated by the DMA, then the
> first/line will be corrupted. But it's not highly probable as this data
> would have to be used in parallel of the DMA (interrupt handling, SMP?,
> dma mgt related variable). So it's not perfect but it would still be
> better than we have today.

Or just fix all the code which complains about unaligned buffers, done.
That's the way to go without all the complications above.

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH RESEND v2 3/4] i2c: i2c-cdns: Implement workaround for hold quirk of the rev 1.0

[Moritz Fischer]

Revision 1.0 of this IP has a quirk where if during a long read transfer
the transfer_size register will go to 0, the master will send a NACK to
the slave prematurely.
The way to work around this is to reprogram the transfer_size register
mid-transfer when the only the receive fifo is known full, i.e. the I2C
bus is known non-active.
The workaround is based on the implementation in the linux-kernel.

Signed-off-by: Moritz Fischer 
Cc: Heiko Schocher 
Cc: Michal Simek 
Cc: u-boot@lists.denx.de
---
Changes from v1:
- Fixed the removal/addition of printf/debug
---
 drivers/i2c/i2c-cdns.c | 119 -
 1 file changed, 89 insertions(+), 30 deletions(-)

diff --git a/drivers/i2c/i2c-cdns.c b/drivers/i2c/i2c-cdns.c
index 1c9fda8..89d429b 100644
--- a/drivers/i2c/i2c-cdns.c
+++ b/drivers/i2c/i2c-cdns.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -67,6 +68,8 @@ struct cdns_i2c_regs {
 
 #define CDNS_I2C_FIFO_DEPTH16
 #define CDNS_I2C_TRANSFER_SIZE_MAX 255 /* Controller transfer limit */
+#define CDNS_I2C_TRANSFER_SIZE (CDNS_I2C_TRANSFER_SIZE_MAX - 3)
+
 #define CDNS_I2C_BROKEN_HOLD_BIT   BIT(0)
 
 #ifdef DEBUG
@@ -247,15 +250,21 @@ static int cdns_i2c_write_data(struct i2c_cdns_bus 
*i2c_bus, u32 addr, u8 *data,
   u32 len)
 {
u8 *cur_data = data;
-
struct cdns_i2c_regs *regs = i2c_bus->regs;
 
+   /* Set the controller in Master transmit mode and clear FIFO */
setbits_le32(>control, CDNS_I2C_CONTROL_CLR_FIFO);
-
-
clrbits_le32(>control, CDNS_I2C_CONTROL_RW);
 
+   /* Check message size against FIFO depth, and set hold bus bit
+* if it is greater than FIFO depth
+*/
+   if (len > CDNS_I2C_FIFO_DEPTH)
+   setbits_le32(>control, CDNS_I2C_CONTROL_HOLD);
+
+   /* Clear the interrupts in status register */
writel(0xFF, >interrupt_status);
+
writel(addr, >address);
 
while (len--) {
@@ -280,48 +289,98 @@ static int cdns_i2c_write_data(struct i2c_cdns_bus 
*i2c_bus, u32 addr, u8 *data,
return 0;
 }
 
+static inline bool cdns_is_hold_quirk(int hold_quirk, int curr_recv_count)
+{
+   return hold_quirk && (curr_recv_count == CDNS_I2C_FIFO_DEPTH + 1);
+}
+
 static int cdns_i2c_read_data(struct i2c_cdns_bus *i2c_bus, u32 addr, u8 *data,
- u32 len)
+ u32 recv_count)
 {
-   u32 status;
-   u32 i = 0;
u8 *cur_data = data;
-
-   /* TODO: Fix this */
struct cdns_i2c_regs *regs = i2c_bus->regs;
+   int curr_recv_count;
+   int updatetx, hold_quirk;
 
/* Check the hardware can handle the requested bytes */
-   if ((len < 0))
+   if ((recv_count < 0))
return -EINVAL;
 
+   curr_recv_count = recv_count;
+
+   /* Check for the message size against the FIFO depth */
+   if (recv_count > CDNS_I2C_FIFO_DEPTH)
+   setbits_le32(>control, CDNS_I2C_CONTROL_HOLD);
+
setbits_le32(>control, CDNS_I2C_CONTROL_CLR_FIFO |
CDNS_I2C_CONTROL_RW);
 
+   if (recv_count > CDNS_I2C_TRANSFER_SIZE) {
+   curr_recv_count = CDNS_I2C_TRANSFER_SIZE;
+   writel(curr_recv_count, >transfer_size);
+   } else {
+   writel(recv_count, >transfer_size);
+   }
+
/* Start reading data */
writel(addr, >address);
-   writel(len, >transfer_size);
-
-   /* Wait for data */
-   do {
-   status = cdns_i2c_wait(regs, CDNS_I2C_INTERRUPT_COMP |
-   CDNS_I2C_INTERRUPT_DATA);
-   if (!status) {
-   /* Release the bus */
-   clrbits_le32(>control, CDNS_I2C_CONTROL_HOLD);
-   return -ETIMEDOUT;
+
+   updatetx = recv_count > curr_recv_count;
+
+   hold_quirk = (i2c_bus->quirks & CDNS_I2C_BROKEN_HOLD_BIT) && updatetx;
+
+   while (recv_count) {
+   while (readl(>status) & CDNS_I2C_STATUS_RXDV) {
+   if (recv_count < CDNS_I2C_FIFO_DEPTH &&
+   !i2c_bus->hold_flag) {
+   clrbits_le32(>control,
+CDNS_I2C_CONTROL_HOLD);
+   }
+   *(cur_data)++ = readl(>data);
+   recv_count--;
+   curr_recv_count--;
+
+   if (cdns_is_hold_quirk(hold_quirk, curr_recv_count))
+   break;
}
-   debug("Read %d bytes\n",
- len - readl(>transfer_size));
-   for (; i < len - readl(>transfer_size); i++)
-   *(cur_data++) = readl(>data);
-   } while (readl(>transfer_size) != 0);
-   /* All done... 

[U-Boot] [PATCH RESEND v2 4/4] i2c: i2c-cdns: No need for dedicated probe function

[Moritz Fischer]

The generic probe code in dm works, so get rid of the leftover cruft.

Signed-off-by: Moritz Fischer 
Cc: Heiko Schocher 
Cc: Michal Simek 
Cc: u-boot@lists.denx.de
---
Changes from v1:
- None
---
 drivers/i2c/i2c-cdns.c | 21 -
 1 file changed, 21 deletions(-)

diff --git a/drivers/i2c/i2c-cdns.c b/drivers/i2c/i2c-cdns.c
index 89d429b..dec1820 100644
--- a/drivers/i2c/i2c-cdns.c
+++ b/drivers/i2c/i2c-cdns.c
@@ -226,26 +226,6 @@ static int cdns_i2c_set_bus_speed(struct udevice *dev, 
unsigned int speed)
return 0;
 }
 
-/* Probe to see if a chip is present. */
-static int cdns_i2c_probe_chip(struct udevice *bus, uint chip_addr,
-   uint chip_flags)
-{
-   struct i2c_cdns_bus *i2c_bus = dev_get_priv(bus);
-   struct cdns_i2c_regs *regs = i2c_bus->regs;
-
-   /* Attempt to read a byte */
-   setbits_le32(>control, CDNS_I2C_CONTROL_CLR_FIFO |
-   CDNS_I2C_CONTROL_RW);
-   clrbits_le32(>control, CDNS_I2C_CONTROL_HOLD);
-   writel(0xFF, >interrupt_status);
-   writel(chip_addr, >address);
-   writel(1, >transfer_size);
-
-   return (cdns_i2c_wait(regs, CDNS_I2C_INTERRUPT_COMP |
-   CDNS_I2C_INTERRUPT_NACK) &
-   CDNS_I2C_INTERRUPT_COMP) ? 0 : -ETIMEDOUT;
-}
-
 static int cdns_i2c_write_data(struct i2c_cdns_bus *i2c_bus, u32 addr, u8 
*data,
   u32 len)
 {
@@ -453,7 +433,6 @@ static int cdns_i2c_ofdata_to_platdata(struct udevice *dev)
 
 static const struct dm_i2c_ops cdns_i2c_ops = {
.xfer = cdns_i2c_xfer,
-   .probe_chip = cdns_i2c_probe_chip,
.set_bus_speed = cdns_i2c_set_bus_speed,
 };
 
-- 
2.7.4

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

[U-Boot] [PATCH RESEND v2 2/4] i2c: i2c-cdns: Reorder timeout loop for interrupt waiting

[Moritz Fischer]

Reorder the timeout loop such that we first check if the
condition is already true, and then call udelay() so if
the condition is already true, break early.

Reviewed-by: Michal Simek 
Signed-off-by: Moritz Fischer 
Cc: Heiko Schocher 
Cc: Michal Simek 
Cc: u-boot@lists.denx.de
---
Changes from v1:
- None

---
 drivers/i2c/i2c-cdns.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/i2c-cdns.c b/drivers/i2c/i2c-cdns.c
index c1d6427..1c9fda8 100644
--- a/drivers/i2c/i2c-cdns.c
+++ b/drivers/i2c/i2c-cdns.c
@@ -130,10 +130,10 @@ static u32 cdns_i2c_wait(struct cdns_i2c_regs *cdns_i2c, 
u32 mask)
int timeout, int_status;
 
for (timeout = 0; timeout < 100; timeout++) {
-   udelay(100);
int_status = readl(_i2c->interrupt_status);
if (int_status & mask)
break;
+   udelay(100);
}
 
/* Clear interrupt status flags */
-- 
2.7.4

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