Re: [U-Boot] [PATCH V2 1/3] arm: discard relocation entry for secure section

[Peng Fan]

Hi Albert,

On Tue, Oct 20, 2015 at 09:05:32AM +0200, Albert ARIBAUD wrote:
>Hello Peng,
>
>On Tue, 20 Oct 2015 13:59:53 +0800, Peng Fan 
>wrote:
>> The code such as PSCI in section named secure is bundled with
>> u-boot image, and when bootm, the code will be copied to their
>> runtime address same to compliation/linking address -
>> CONFIG_ARMV7_SECURE_BASE.
>> 
>> When compile the PSCI code and link it into the u-boot image,
>> there will be relocation entries in .rel.dyn section for PSCI.
>> Actually, we do not needs these relocation entries.
>> 
>> If still keep the relocation entries in .rel.dyn section,
>> r0 at line 103 and 106 in arch/arm/lib/relocate.S may be an invalid
>> address which may not support read/write for one SoC.
>> 102 /* relative fix: increase location by offset */
>> 103 add r0, r0, r4
>> 104 ldr r1, [r0]
>> 105 add r1, r1, r4
>> 106 str r1, [r0]
>> 
>> So discard the relocation entries for code in secure section.
>
>Actually, I'll need you to do a slight change -- that's my fault, and
>karma even ensured that my own self of two years ago would be the one
>to come and kick me. See:
>
>http://lists.denx.de/pipermail/u-boot/2013-December/168652.html

Ok. Then arch/arm/cpu/armv8/u-boot.lds should also have such fix,
since lots sections are discarded in u-boot.lds for armv8.

>
>Which basically is about never discarding any section in the ELF file,
>and only copying a subset of the ELF sections into the binary file.
>
>So rather than discarding the secure relocation records, let's move
>them to another section as you had proposed, and thus change the line
>
>> +/DISCARD/ : { *(.rel._secure*) }
>
>Into a
>
>   .rel._secure { *(.rel._secure*) }
>
>Placed right after the already present
>
>   .dynamic : { *(.dynamic*) }

It can not be placed after .dynamic, since the following is at front.
87 .rel.dyn : {
88 *(.rel*)
89 }
So relocation entry from secure text will first placed into .rel.dyn section.

If not DISCARD, then I prefer to put ".rel.secure : { *(.rel._secure*) }"
at line 55 which is wrapped by CONFIG_ARMV7_NONSEC in arch/arm/cpu/u-boot.lds.

See following patch:

>From 4b950418835ff52cd7be8dd2b80fb8b0e055f9a2 Mon Sep 17 00:00:00 2001
From: Peng Fan 
Date: Tue, 20 Oct 2015 15:18:22 +0800
Subject: [PATCH] arm: move relocation entry for secure section into a single
 section

The code such as PSCI in section named secure is bundled with
u-boot image, and when bootm, the code will be copied to their
runtime address same to compliation/linking address -
CONFIG_ARMV7_SECURE_BASE.

When compile the PSCI code and link it into the u-boot image,
there will be relocation entries in .rel.dyn section for PSCI.
Actually, we do not needs these relocation entries.

If still keep the relocation entries in .rel.dyn section,
r0 at line 103 and 106 in arch/arm/lib/relocate.S may be an invalid
address which may not support read/write for one SoC.
102 /* relative fix: increase location by offset */
103 add r0, r0, r4
104 ldr r1, [r0]
105 add r1, r1, r4
106 str r1, [r0]

So move them into a single section to avoid touching the relocation entry
in arch/arm/lib/relocate.S.

Signed-off-by: Peng Fan 
Cc: Tom Warren 
Cc: York Sun 
Cc: Hans De Goede 
Cc: Ian Campbell 
Cc: Albert Aribaud 
Cc: Tom Rini 
Cc: Jan Kiszka 
Cc: Stefano Babic 
---
 arch/arm/cpu/u-boot.lds | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
index 03cd9f6..65986e8 100644
--- a/arch/arm/cpu/u-boot.lds
+++ b/arch/arm/cpu/u-boot.lds
@@ -51,6 +51,8 @@ SECTIONS
*(.__secure_end)
LONG(0x1d1071c);/* Must output something to reset LMA */
}
+
+   .rel.secure : { *(.rel._secure*) }
 #endif
 
. = ALIGN(4);

Regards,
Peng.

>
>With my apologies for the very late realization.
>
>Amicalement,
>-- 
>Albert.

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

Re: [U-Boot] [PATCH V2 1/3] arm: discard relocation entry for secure section

[Albert ARIBAUD]

Hello Peng,

On Tue, 20 Oct 2015 15:20:43 +0800, Peng Fan 
wrote:
> Hi Albert,
> 
> On Tue, Oct 20, 2015 at 09:05:32AM +0200, Albert ARIBAUD wrote:
> >Hello Peng,
> >
> >On Tue, 20 Oct 2015 13:59:53 +0800, Peng Fan 
> >wrote:
> >> The code such as PSCI in section named secure is bundled with
> >> u-boot image, and when bootm, the code will be copied to their
> >> runtime address same to compliation/linking address -
> >> CONFIG_ARMV7_SECURE_BASE.
> >> 
> >> When compile the PSCI code and link it into the u-boot image,
> >> there will be relocation entries in .rel.dyn section for PSCI.
> >> Actually, we do not needs these relocation entries.
> >> 
> >> If still keep the relocation entries in .rel.dyn section,
> >> r0 at line 103 and 106 in arch/arm/lib/relocate.S may be an invalid
> >> address which may not support read/write for one SoC.
> >> 102 /* relative fix: increase location by offset */
> >> 103 add r0, r0, r4
> >> 104 ldr r1, [r0]
> >> 105 add r1, r1, r4
> >> 106 str r1, [r0]
> >> 
> >> So discard the relocation entries for code in secure section.
> >
> >Actually, I'll need you to do a slight change -- that's my fault, and
> >karma even ensured that my own self of two years ago would be the one
> >to come and kick me. See:
> >
> >http://lists.denx.de/pipermail/u-boot/2013-December/168652.html
> 
> Ok. Then arch/arm/cpu/armv8/u-boot.lds should also have such fix,
> since lots sections are discarded in u-boot.lds for armv8.

You are correct, armv8 needs to be fixed, as well as zynq (and x86 but
that's outside of my province). Anyway, that's a different problem
which does not need to be addressed in this series.

> >Which basically is about never discarding any section in the ELF file,
> >and only copying a subset of the ELF sections into the binary file.
> >
> >So rather than discarding the secure relocation records, let's move
> >them to another section as you had proposed, and thus change the line
> >
> >> +  /DISCARD/ : { *(.rel._secure*) }
> >
> >Into a
> >
> > .rel._secure { *(.rel._secure*) }
> >
> >Placed right after the already present
> >
> > .dynamic : { *(.dynamic*) }
> 
> It can not be placed after .dynamic, since the following is at front.
> 87 .rel.dyn : {
> 88 *(.rel*)
> 89 }
> So relocation entry from secure text will first placed into .rel.dyn section.
> 
> If not DISCARD, then I prefer to put ".rel.secure : { *(.rel._secure*) }"
> at line 55 which is wrapped by CONFIG_ARMV7_NONSEC in arch/arm/cpu/u-boot.lds.

I prefer all 'unused' sections to be kept together near the end of the
LDS file -- I'll add an explicit comment in the LDS about it.

Besides, there no need to wrap such a section with a preprocessor
conditional, as the linker will simply not emit an output section if
there are no input sections at all for it; IOW, adding the '.rel._secure
{ *(.rel._secure*) }' line will be binary-invariant for platforms which
do not have PSCI or other secure code.

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

Re: [U-Boot] [PATCH] vexpress64: compile Juno PCIe conditionally

[Ryan Harkin]

On 20 October 2015 at 09:07, Ryan Harkin  wrote:

>
>
> On 20 October 2015 at 07:05, Linus Walleij 
> wrote:
>
>> Only compile in PCIe support if the board really uses it. Provide
>> a stub for the init function if e.g. FVP is being built.
>>
>> Cc: Liviu Dudau 
>> Cc: Ryan Harkin 
>> Signed-off-by: Linus Walleij 
>> ---
>>  board/armltd/vexpress64/Makefile | 3 ++-
>>  board/armltd/vexpress64/pcie.c   | 2 --
>>  board/armltd/vexpress64/pcie.h   | 4 
>>  3 files changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/board/armltd/vexpress64/Makefile
>> b/board/armltd/vexpress64/Makefile
>> index a35db401b684..b4391a71249a 100644
>> --- a/board/armltd/vexpress64/Makefile
>> +++ b/board/armltd/vexpress64/Makefile
>> @@ -5,4 +5,5 @@
>>  # SPDX-License-Identifier: GPL-2.0+
>>  #
>>
>> -obj-y  := vexpress64.o pcie.o
>> +obj-y  := vexpress64.o
>> +obj-$(CONFIG_TARGET_VEXPRESS64_JUNO)   += pcie.o
>> diff --git a/board/armltd/vexpress64/pcie.c
>> b/board/armltd/vexpress64/pcie.c
>> index 7b999e8ef40b..311c4500e3ff 100644
>> --- a/board/armltd/vexpress64/pcie.c
>> +++ b/board/armltd/vexpress64/pcie.c
>> @@ -191,7 +191,5 @@ void xr3pci_init(void)
>>
>>  void vexpress64_pcie_init(void)
>>  {
>> -#ifdef CONFIG_TARGET_VEXPRESS64_JUNO
>> xr3pci_init();
>> -#endif
>>  }
>> diff --git a/board/armltd/vexpress64/pcie.h
>> b/board/armltd/vexpress64/pcie.h
>> index 14642f4f5c43..55b276d6af11 100644
>> --- a/board/armltd/vexpress64/pcie.h
>> +++ b/board/armltd/vexpress64/pcie.h
>> @@ -1,6 +1,10 @@
>>  #ifndef __VEXPRESS64_PCIE_H__
>>  #define __VEXPRESS64_PCIE_H__
>>
>> +#ifdef CONFIG_TARGET_VEXPRESS64_JUNO
>>  void vexpress64_pcie_init(void);
>> +#else
>> +static inline void vexpress64_pcie_init(void) {}
>> +#endif
>>
>>  #endif /* __VEXPRESS64_PCIE_H__ */
>>
>
> Tom specifically dropped this hunk when he merged Liviu's patch.  But is
> it necessary with the rest of your patch?  If pcie.h is only included in
> pcie.c, which is only built for JUNO, then the code shouldn't need
> conditional compilation. So I think we can drop the hunk, no?
>

Sorry, I'm wrong here.  vexpress64_pcie_init is called unconditionally from
board_init(), so needs a stub definition for non-Juno targets.

I guess another way to do it would be to make the call in board_init()
conditional, but that's not really any different than your patch, so I'm
happy enough with yours.

Reviewed-by: Ryan Harkin 
Tested-by: Ryan Harkin 
(I tested on FVP dram configuration, Juno R0 and Juno R1)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 00/11] imx: mx6: support lcdif

[Peng Fan]

Hi Stefano,

On Fri, Oct 02, 2015 at 10:48:21AM +0200, Stefano Babic wrote:
>Hi Peng,
>
>I have not forgotten this series. Anyway, this has introduced aome
>changes that could brick other boards and it is my opininio to postpone
>it after 2015.10 release. Of course, I will send to you a full review
>for that.

The patch set has been here for a long time. Since now 2015.10 released,
Can you please review this patch set?

Thanks,
Peng.

>
>Best regards,
>Stefano Babic
>
>
>On 10/09/2015 12:28, Peng Fan wrote:
>> This patch set is to introduce lcdif support for i.MX6.
>> 
>> Now only i.MX6UL support is in this patchset.
>> Patchset tested on mx6ul_14x14_evk and mx6ul_9x9_evk
>> (needs 9x9 SPL patch applied).
>> 
>> 1/11
>> There are two LCD interface for i.MX6SX and one interface for i.MX6UL,
>> so change the prototype mxs_set_lcdclk to handle different interface.
>> 
>> [2,3]/11
>> I am not sure, but from my understanding, the 'board_' should be discarded.
>> 
>> 4/11
>> mx28 and mx6ul/sx have similar register layout and bit definitions, so
>> move related structure and bit definitions to imx-common.
>> 
>> [5,6,7]/11
>> is to add related CCM macros, clock apis for enable lcdif on i.MX6
>> 
>> 8/11
>> support lcdif for i.MX6UL 14x14/9x9 board
>> 
>> 9/11
>> Introduce lcdif_power_down, to make system stable when reset or boot os
>> 
>> [10,11]/11
>> Need to call lcdif_power_down, before trigger wdog reset or boot os.
>> Or we may met unexpected system hang.
>> 
>> Peng Fan (11):
>>   mxs: add parameter base_addr for mxs_set_lcdclk
>>   sandisk: sfp: correct function name
>>   xfi3: correct function name
>>   imx: imx-common: move lcdif structure and macro definition to
>> imx-common
>>   imx: mx6: fix register address
>>   imx: mx6: crm_reg: add LCDIF related macros
>>   imx: mx6: add clock api for lcdif
>>   imx: mx6ul_14x14_evk: support lcdif display
>>   video: mxsfb: introduce lcdif_power_down
>>   imx: mx6: implement reset_misc
>>   imx: imx-common: power down lcdif before boot os
>> 
>>  arch/arm/cpu/arm926ejs/mxs/clock.c|   2 +-
>>  arch/arm/cpu/armv7/mx6/clock.c| 239 
>> ++
>>  arch/arm/cpu/armv7/mx6/soc.c  |   8 +
>>  arch/arm/imx-common/cpu.c |   3 +
>>  arch/arm/include/asm/arch-mx6/clock.h |   2 +
>>  arch/arm/include/asm/arch-mx6/crm_regs.h  |  34 ++-
>>  arch/arm/include/asm/arch-mx6/imx-regs.h  |  15 +-
>>  arch/arm/include/asm/arch-mxs/clock.h |   2 +-
>>  arch/arm/include/asm/arch-mxs/regs-lcdif.h| 201 +-
>>  arch/arm/include/asm/imx-common/regs-lcdif.h  | 222 
>>  arch/arm/include/asm/imx-common/sys_proto.h   |   2 +
>>  board/creative/xfi3/xfi3.c|   2 +-
>>  board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c |  63 ++
>>  board/sandisk/sansa_fuze_plus/sfp.c   |   2 +-
>>  drivers/video/mxsfb.c |  19 +-
>>  include/configs/mx6ul_14x14_evk.h |  18 ++
>>  16 files changed, 620 insertions(+), 214 deletions(-)
>>  create mode 100644 arch/arm/include/asm/imx-common/regs-lcdif.h
>> 
>
>
>-- 
>=
>DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
>HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
>Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
>=

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

[U-Boot] [PATCH] vexpress64: compile Juno PCIe conditionally

[Linus Walleij]

Only compile in PCIe support if the board really uses it. Provide
a stub for the init function if e.g. FVP is being built.

Cc: Liviu Dudau 
Cc: Ryan Harkin 
Signed-off-by: Linus Walleij 
---
 board/armltd/vexpress64/Makefile | 3 ++-
 board/armltd/vexpress64/pcie.c   | 2 --
 board/armltd/vexpress64/pcie.h   | 4 
 3 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/board/armltd/vexpress64/Makefile b/board/armltd/vexpress64/Makefile
index a35db401b684..b4391a71249a 100644
--- a/board/armltd/vexpress64/Makefile
+++ b/board/armltd/vexpress64/Makefile
@@ -5,4 +5,5 @@
 # SPDX-License-Identifier: GPL-2.0+
 #
 
-obj-y  := vexpress64.o pcie.o
+obj-y  := vexpress64.o
+obj-$(CONFIG_TARGET_VEXPRESS64_JUNO)   += pcie.o
diff --git a/board/armltd/vexpress64/pcie.c b/board/armltd/vexpress64/pcie.c
index 7b999e8ef40b..311c4500e3ff 100644
--- a/board/armltd/vexpress64/pcie.c
+++ b/board/armltd/vexpress64/pcie.c
@@ -191,7 +191,5 @@ void xr3pci_init(void)
 
 void vexpress64_pcie_init(void)
 {
-#ifdef CONFIG_TARGET_VEXPRESS64_JUNO
xr3pci_init();
-#endif
 }
diff --git a/board/armltd/vexpress64/pcie.h b/board/armltd/vexpress64/pcie.h
index 14642f4f5c43..55b276d6af11 100644
--- a/board/armltd/vexpress64/pcie.h
+++ b/board/armltd/vexpress64/pcie.h
@@ -1,6 +1,10 @@
 #ifndef __VEXPRESS64_PCIE_H__
 #define __VEXPRESS64_PCIE_H__
 
+#ifdef CONFIG_TARGET_VEXPRESS64_JUNO
 void vexpress64_pcie_init(void);
+#else
+static inline void vexpress64_pcie_init(void) {}
+#endif
 
 #endif /* __VEXPRESS64_PCIE_H__ */
-- 
2.4.3

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

[U-Boot] [PATCH V2 2/3] mx7: psci: add basic psci support

[Peng Fan]

1. add basic psci support for imx7 chip.
2. support cpu_on and cpu_off.
3. switch to non-secure mode when boot linux kernel.
4. set csu allow accessing all peripherial register in non-secure mode.

Signed-off-by: Frank Li 
Signed-off-by: Peng Fan 
Cc: Stefano Babic 
Cc: Fabio Estevam 
---

Changes V2:
 Refine commit msg.

 arch/arm/cpu/armv7/mx7/Makefile   |  4 ++
 arch/arm/cpu/armv7/mx7/psci-mx7.c | 78 +++
 arch/arm/cpu/armv7/mx7/psci.S | 54 +++
 arch/arm/cpu/armv7/mx7/soc.c  |  9 +
 4 files changed, 145 insertions(+)
 create mode 100644 arch/arm/cpu/armv7/mx7/psci-mx7.c
 create mode 100644 arch/arm/cpu/armv7/mx7/psci.S

diff --git a/arch/arm/cpu/armv7/mx7/Makefile b/arch/arm/cpu/armv7/mx7/Makefile
index e6ecef0..f25461c 100644
--- a/arch/arm/cpu/armv7/mx7/Makefile
+++ b/arch/arm/cpu/armv7/mx7/Makefile
@@ -6,3 +6,7 @@
 #
 
 obj-y  := soc.o clock.o clock_slice.o
+
+ifdef CONFIG_ARMV7_PSCI
+obj-y  += psci.o psci-mx7.o
+endif
diff --git a/arch/arm/cpu/armv7/mx7/psci-mx7.c 
b/arch/arm/cpu/armv7/mx7/psci-mx7.c
new file mode 100644
index 000..ec9ad87
--- /dev/null
+++ b/arch/arm/cpu/armv7/mx7/psci-mx7.c
@@ -0,0 +1,78 @@
+#include 
+#include 
+#include 
+
+#define __secure __attribute__((section("._secure.text")))
+
+#define GPC_CPU_PGC_SW_PDN_REQ 0xfc
+#define GPC_CPU_PGC_SW_PUP_REQ 0xf0
+#define GPC_PGC_C1 0x840
+
+#define BM_CPU_PGC_SW_PDN_PUP_REQ_CORE1_A7 0x2
+
+/* below is for i.MX7D */
+#define SRC_GPR1_MX7D  0x074
+#define SRC_A7RCR0 0x004
+#define SRC_A7RCR1 0x008
+
+#define BP_SRC_A7RCR0_A7_CORE_RESET0   0
+#define BP_SRC_A7RCR1_A7_CORE1_ENABLE  1
+
+static inline void psci_writel(u32 value, u32 reg)
+{
+   *(volatile u32 *)reg = value;
+}
+
+static inline int psci_readl(u32 reg)
+{
+   return *(volatile u32*)reg;
+}
+
+static inline void imx_gpcv2_set_m_core_pgc(bool enable, u32 offset)
+{
+   psci_writel(enable, GPC_IPS_BASE_ADDR + offset);
+}
+
+__secure void imx_gpcv2_set_core1_power(bool pdn)
+{
+   u32 reg = pdn ? GPC_CPU_PGC_SW_PUP_REQ : GPC_CPU_PGC_SW_PDN_REQ;
+   u32 val;
+
+   imx_gpcv2_set_m_core_pgc(true, GPC_PGC_C1);
+
+   val = psci_readl(GPC_IPS_BASE_ADDR + reg);
+   val |= BM_CPU_PGC_SW_PDN_PUP_REQ_CORE1_A7;
+   psci_writel(val, GPC_IPS_BASE_ADDR + reg);
+
+   while ((psci_readl(GPC_IPS_BASE_ADDR + reg) &
+  BM_CPU_PGC_SW_PDN_PUP_REQ_CORE1_A7) != 0)
+   ;
+
+   imx_gpcv2_set_m_core_pgc(false, GPC_PGC_C1);
+}
+
+__secure void imx_enable_cpu_ca7(int cpu, bool enable)
+{
+   u32 mask, val;
+
+   mask = 1 << (BP_SRC_A7RCR1_A7_CORE1_ENABLE + cpu - 1);
+   val = psci_readl(SRC_BASE_ADDR + SRC_A7RCR1);
+   val = enable ? val | mask : val & ~mask;
+   psci_writel(val, SRC_BASE_ADDR + SRC_A7RCR1);
+}
+
+__secure int imx_cpu_on(int fn, int cpu, int pc)
+{
+   psci_writel(pc, SRC_BASE_ADDR + cpu * 8 + SRC_GPR1_MX7D);
+   imx_gpcv2_set_core1_power(true);
+   imx_enable_cpu_ca7(cpu, true);
+   return 0;
+}
+
+__secure int imx_cpu_off(int cpu)
+{
+   imx_enable_cpu_ca7(cpu, false);
+   imx_gpcv2_set_core1_power(false);
+   psci_writel(0, SRC_BASE_ADDR + cpu * 8 + SRC_GPR1_MX7D + 4);
+   return 0;
+}
diff --git a/arch/arm/cpu/armv7/mx7/psci.S b/arch/arm/cpu/armv7/mx7/psci.S
new file mode 100644
index 000..34c6ab3
--- /dev/null
+++ b/arch/arm/cpu/armv7/mx7/psci.S
@@ -0,0 +1,54 @@
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+   .pushsection ._secure.text, "ax"
+
+   .arch_extension sec
+
+   @ r1 = target CPU
+   @ r2 = target PC
+
+.globl psci_arch_init
+psci_arch_init:
+   mov r6, lr
+
+   bl  psci_get_cpu_id
+   bl  psci_get_cpu_stack_top
+   mov sp, r0
+
+   bx  r6
+
+   @ r1 = target CPU
+   @ r2 = target PC
+
+.globl psci_cpu_on
+psci_cpu_on:
+   push{lr}
+
+   mov r0, r1
+   bl  psci_get_cpu_stack_top
+   str r2, [r0]
+   dsb
+
+   ldr r2, =psci_cpu_entry
+   bl  imx_cpu_on
+
+   pop {pc}
+
+.globl psci_cpu_off
+psci_cpu_off:
+
+   bl  psci_cpu_off_common
+   bl  psci_get_cpu_id
+   bl  imx_cpu_off
+
+1: wfi
+   b 1b
+
+   .globl psci_text_end
+psci_text_end:
+   .popsection
diff --git a/arch/arm/cpu/armv7/mx7/soc.c b/arch/arm/cpu/armv7/mx7/soc.c
index 2ed05ea..020731d 100644
--- a/arch/arm/cpu/armv7/mx7/soc.c
+++ b/arch/arm/cpu/armv7/mx7/soc.c
@@ -114,10 +114,19 @@ u32 __weak get_board_rev(void)
 }
 #endif
 
+/* enable all periherial can be access in nosec mode */
+static void init_csu(void)
+{
+   int i = 0;
+   for (i = 0; i < 64; i++)
+   writel(0x00FF00FF, 0x303e + i * 4);
+}
+
 int arch_cpu_init(void)
 {
init_aips();
 
+   init_csu();
/* 

[U-Boot] [PATCH V2 1/3] arm: discard relocation entry for secure section

[Peng Fan]

The code such as PSCI in section named secure is bundled with
u-boot image, and when bootm, the code will be copied to their
runtime address same to compliation/linking address -
CONFIG_ARMV7_SECURE_BASE.

When compile the PSCI code and link it into the u-boot image,
there will be relocation entries in .rel.dyn section for PSCI.
Actually, we do not needs these relocation entries.

If still keep the relocation entries in .rel.dyn section,
r0 at line 103 and 106 in arch/arm/lib/relocate.S may be an invalid
address which may not support read/write for one SoC.
102 /* relative fix: increase location by offset */
103 add r0, r0, r4
104 ldr r1, [r0]
105 add r1, r1, r4
106 str r1, [r0]

So discard the relocation entries for code in secure section.

Signed-off-by: Peng Fan 
Cc: Tom Warren 
Cc: York Sun 
Cc: Hans De Goede 
Cc: Ian Campbell 
Cc: Albert Aribaud 
Cc: Tom Rini 
Cc: Jan Kiszka 
Cc: Stefano Babic 
---

V1 thread: http://lists.denx.de/pipermail/u-boot/2015-October/229426.html
Changes V2:
 Refine commit msg.
 Discard the relocation entry section for secure text. 

 arch/arm/cpu/u-boot.lds | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
index 03cd9f6..55a0683 100644
--- a/arch/arm/cpu/u-boot.lds
+++ b/arch/arm/cpu/u-boot.lds
@@ -51,6 +51,8 @@ SECTIONS
*(.__secure_end)
LONG(0x1d1071c);/* Must output something to reset LMA */
}
+
+   /DISCARD/ : { *(.rel._secure*) }
 #endif
 
. = ALIGN(4);
-- 
1.8.4


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

Re: [U-Boot] [PATCH 2/2] ARM: dra7xx_evm: Add DFU support for qspi flash

[Vignesh R]

Hi Lukasz,

On 10/20/2015 04:07 PM, Lukasz Majewski wrote:
> Hi Vignesh,
> 
>> This adds support to update firmware on qspi flash using DFU.
>>
>> On device:
>> => setenv dfu_alt_info ${dfu_alt_info_qspi}
>> => dfu 0 sf 0:0
>>
>> On host:
>> $ sudo dfu-util -l
>> $ sudo dfu-util -D MLO -a MLO
>> $ sudo dfu-util -D u-boot.img -a u-boot.img
> 
> This patch series seems ok. I just have one question regarding dfu-util:
> 
> sudo dfu-util -D MLO -a MLO
> 
> Is the above correct?
> 
> Shouldn't it be sudo dfu-util -a 0 -D MLO 
> where alt setting 0 corresponds to MLO?
> 

According to man page of dfu-util 0.5 (supports DFU v1.0):
"-a"  can be used Specify the Altsetting of the DFU Interface by name or
by number

So since "MLO" is the name for alt setting 0 both
sudo dfu-util -D MLO -a MLO  and
sudo dfu-util -a 0 -D MLO  are correct.

I used the above format as its easier for reading. Thanks!

>>
>> Signed-off-by: Vignesh R 
>> ---
>>  include/configs/dra7xx_evm.h | 16 +++-
>>  1 file changed, 15 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/configs/dra7xx_evm.h
>> b/include/configs/dra7xx_evm.h index 6e32de854619..cb9544b49efb 100644
>> --- a/include/configs/dra7xx_evm.h
>> +++ b/include/configs/dra7xx_evm.h
>> @@ -82,11 +82,24 @@
>>  "fdt ram 0x80f8 0x8;" \
>>  "ramdisk ram 0x8100 0x400\0"
>>  
>> +#define DFU_ALT_INFO_QSPI \
>> +"dfu_alt_info_qspi=" \
>> +"MLO raw 0x0 0x01;" \
>> +"MLO.backup1 raw 0x01 0x01;" \
>> +"MLO.backup2 raw 0x02 0x01;" \
>> +"MLO.backup3 raw 0x03 0x01;" \
>> +"u-boot.img raw 0x04 0x010;" \
>> +"u-boot-spl-os raw 0x14 0x08;" \
>> +"u-boot-env raw 0x1C 0x01;" \
>> +"u-boot-env.backup raw 0x1D 0x01;" \
>> +"kernel raw 0x1E 0x80\0"
>> +
>>  #define DFUARGS \
>>  "dfu_bufsiz=0x1\0" \
>>  DFU_ALT_INFO_MMC \
>>  DFU_ALT_INFO_EMMC \
>> -DFU_ALT_INFO_RAM
>> +DFU_ALT_INFO_RAM \
>> +DFU_ALT_INFO_QSPI
>>  
>>  /* Fastboot */
>>  #define CONFIG_USB_FUNCTION_FASTBOOT
>> @@ -207,6 +220,7 @@
>>  
>>  #define CONFIG_DFU_MMC
>>  #define CONFIG_DFU_RAM
>> +#define CONFIG_DFU_SF
>>  
>>  /* SATA */
>>  #define CONFIG_BOARD_LATE_INIT
> 
> 
> 

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

[U-Boot] [PATCH 1/2] dfu: dfu_sf: Pass duplicate devstr to parse_dev

[Vignesh R]

parse_dev() alters the string pointed by devstr parameter. Due to this
subsequent parsing of sf entities will fail, as string pointed by devstr
is no longer valid sf dev arguments.
Fix this by passing pointer to the copy of the string to parse_dev
instead of pointer to the actual devstr.

Signed-off-by: Vignesh R 
---
 drivers/dfu/dfu_sf.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/dfu/dfu_sf.c b/drivers/dfu/dfu_sf.c
index 7646c6b7270c..9702eeea202a 100644
--- a/drivers/dfu/dfu_sf.c
+++ b/drivers/dfu/dfu_sf.c
@@ -115,8 +115,10 @@ static struct spi_flash *parse_dev(char *devstr)
 int dfu_fill_entity_sf(struct dfu_entity *dfu, char *devstr, char *s)
 {
char *st;
+   char *devstr_bkup = strdup(devstr);
 
-   dfu->data.sf.dev = parse_dev(devstr);
+   dfu->data.sf.dev = parse_dev(devstr_bkup);
+   free(devstr_bkup);
if (!dfu->data.sf.dev)
return -ENODEV;
 
-- 
2.6.2

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

[U-Boot] [PATCH 2/2] ARM: dra7xx_evm: Add DFU support for qspi flash

[Vignesh R]

This adds support to update firmware on qspi flash using DFU.

On device:
=> setenv dfu_alt_info ${dfu_alt_info_qspi}
=> dfu 0 sf 0:0

On host:
$ sudo dfu-util -l
$ sudo dfu-util -D MLO -a MLO
$ sudo dfu-util -D u-boot.img -a u-boot.img

Signed-off-by: Vignesh R 
---
 include/configs/dra7xx_evm.h | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h
index 6e32de854619..cb9544b49efb 100644
--- a/include/configs/dra7xx_evm.h
+++ b/include/configs/dra7xx_evm.h
@@ -82,11 +82,24 @@
"fdt ram 0x80f8 0x8;" \
"ramdisk ram 0x8100 0x400\0"
 
+#define DFU_ALT_INFO_QSPI \
+   "dfu_alt_info_qspi=" \
+   "MLO raw 0x0 0x01;" \
+   "MLO.backup1 raw 0x01 0x01;" \
+   "MLO.backup2 raw 0x02 0x01;" \
+   "MLO.backup3 raw 0x03 0x01;" \
+   "u-boot.img raw 0x04 0x010;" \
+   "u-boot-spl-os raw 0x14 0x08;" \
+   "u-boot-env raw 0x1C 0x01;" \
+   "u-boot-env.backup raw 0x1D 0x01;" \
+   "kernel raw 0x1E 0x80\0"
+
 #define DFUARGS \
"dfu_bufsiz=0x1\0" \
DFU_ALT_INFO_MMC \
DFU_ALT_INFO_EMMC \
-   DFU_ALT_INFO_RAM
+   DFU_ALT_INFO_RAM \
+   DFU_ALT_INFO_QSPI
 
 /* Fastboot */
 #define CONFIG_USB_FUNCTION_FASTBOOT
@@ -207,6 +220,7 @@
 
 #define CONFIG_DFU_MMC
 #define CONFIG_DFU_RAM
+#define CONFIG_DFU_SF
 
 /* SATA */
 #define CONFIG_BOARD_LATE_INIT
-- 
2.6.2

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

[U-Boot] [PATCH 0/2] DFU support for qspi on dra7xx

[Vignesh R]

Hi,

This patch series adds DFU support to update firmware on qspi flash on
DRA74 EVM. 
The first patch fixes a bug in DFU SF backend. Second patch adds enables
CONFIG_DFU_SF and adds dfu-alt_info string to support qspi partitions.

Tested on DRA74 EVM by flashing MLO and u-boot.img to QSPI flash using
via DFU and then booting the board in QSPI boot mode.

Vignesh R (2):
  dfu: dfu_sf: Pass duplicate devstr to parse_dev
  ARM: dra7xx_evm: Add DFU support for qspi flash

 drivers/dfu/dfu_sf.c |  4 +++-
 include/configs/dra7xx_evm.h | 16 +++-
 2 files changed, 18 insertions(+), 2 deletions(-)

-- 
2.6.2

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

Re: [U-Boot] [PATCH 00/11] imx: mx6: support lcdif

[Peng Fan]

On Tue, Oct 20, 2015 at 05:19:19PM +0800, Peng Fan wrote:
>Hi Stefano,
>
>On Fri, Oct 02, 2015 at 10:48:21AM +0200, Stefano Babic wrote:
>>Hi Peng,
>>
>>I have not forgotten this series. Anyway, this has introduced aome
>>changes that could brick other boards and it is my opininio to postpone
>>it after 2015.10 release. Of course, I will send to you a full review
>>for that.
>
>The patch set has been here for a long time. Since now 2015.10 released,
>Can you please review this patch set?

Seems there are conflicts when merging with latest uboot. I'll prepare
a new V2 patch set rebased on lastest uboot.

Regards,
Peng.

>
>Thanks,
>Peng.
>
>>
>>Best regards,
>>Stefano Babic
>>
>>
>>On 10/09/2015 12:28, Peng Fan wrote:
>>> This patch set is to introduce lcdif support for i.MX6.
>>> 
>>> Now only i.MX6UL support is in this patchset.
>>> Patchset tested on mx6ul_14x14_evk and mx6ul_9x9_evk
>>> (needs 9x9 SPL patch applied).
>>> 
>>> 1/11
>>> There are two LCD interface for i.MX6SX and one interface for i.MX6UL,
>>> so change the prototype mxs_set_lcdclk to handle different interface.
>>> 
>>> [2,3]/11
>>> I am not sure, but from my understanding, the 'board_' should be discarded.
>>> 
>>> 4/11
>>> mx28 and mx6ul/sx have similar register layout and bit definitions, so
>>> move related structure and bit definitions to imx-common.
>>> 
>>> [5,6,7]/11
>>> is to add related CCM macros, clock apis for enable lcdif on i.MX6
>>> 
>>> 8/11
>>> support lcdif for i.MX6UL 14x14/9x9 board
>>> 
>>> 9/11
>>> Introduce lcdif_power_down, to make system stable when reset or boot os
>>> 
>>> [10,11]/11
>>> Need to call lcdif_power_down, before trigger wdog reset or boot os.
>>> Or we may met unexpected system hang.
>>> 
>>> Peng Fan (11):
>>>   mxs: add parameter base_addr for mxs_set_lcdclk
>>>   sandisk: sfp: correct function name
>>>   xfi3: correct function name
>>>   imx: imx-common: move lcdif structure and macro definition to
>>> imx-common
>>>   imx: mx6: fix register address
>>>   imx: mx6: crm_reg: add LCDIF related macros
>>>   imx: mx6: add clock api for lcdif
>>>   imx: mx6ul_14x14_evk: support lcdif display
>>>   video: mxsfb: introduce lcdif_power_down
>>>   imx: mx6: implement reset_misc
>>>   imx: imx-common: power down lcdif before boot os
>>> 
>>>  arch/arm/cpu/arm926ejs/mxs/clock.c|   2 +-
>>>  arch/arm/cpu/armv7/mx6/clock.c| 239 
>>> ++
>>>  arch/arm/cpu/armv7/mx6/soc.c  |   8 +
>>>  arch/arm/imx-common/cpu.c |   3 +
>>>  arch/arm/include/asm/arch-mx6/clock.h |   2 +
>>>  arch/arm/include/asm/arch-mx6/crm_regs.h  |  34 ++-
>>>  arch/arm/include/asm/arch-mx6/imx-regs.h  |  15 +-
>>>  arch/arm/include/asm/arch-mxs/clock.h |   2 +-
>>>  arch/arm/include/asm/arch-mxs/regs-lcdif.h| 201 +-
>>>  arch/arm/include/asm/imx-common/regs-lcdif.h  | 222 
>>> 
>>>  arch/arm/include/asm/imx-common/sys_proto.h   |   2 +
>>>  board/creative/xfi3/xfi3.c|   2 +-
>>>  board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c |  63 ++
>>>  board/sandisk/sansa_fuze_plus/sfp.c   |   2 +-
>>>  drivers/video/mxsfb.c |  19 +-
>>>  include/configs/mx6ul_14x14_evk.h |  18 ++
>>>  16 files changed, 620 insertions(+), 214 deletions(-)
>>>  create mode 100644 arch/arm/include/asm/imx-common/regs-lcdif.h
>>> 
>>
>>
>>-- 
>>=
>>DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
>>HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
>>Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
>>=
>
>-- 

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

Re: [U-Boot] [PATCH 2/2] ARM: dra7xx_evm: Add DFU support for qspi flash

[Lukasz Majewski]

Hi Vignesh,

> This adds support to update firmware on qspi flash using DFU.
> 
> On device:
> => setenv dfu_alt_info ${dfu_alt_info_qspi}
> => dfu 0 sf 0:0
> 
> On host:
> $ sudo dfu-util -l
> $ sudo dfu-util -D MLO -a MLO
> $ sudo dfu-util -D u-boot.img -a u-boot.img

This patch series seems ok. I just have one question regarding dfu-util:

sudo dfu-util -D MLO -a MLO

Is the above correct?

Shouldn't it be sudo dfu-util -a 0 -D MLO 
where alt setting 0 corresponds to MLO?

> 
> Signed-off-by: Vignesh R 
> ---
>  include/configs/dra7xx_evm.h | 16 +++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/include/configs/dra7xx_evm.h
> b/include/configs/dra7xx_evm.h index 6e32de854619..cb9544b49efb 100644
> --- a/include/configs/dra7xx_evm.h
> +++ b/include/configs/dra7xx_evm.h
> @@ -82,11 +82,24 @@
>   "fdt ram 0x80f8 0x8;" \
>   "ramdisk ram 0x8100 0x400\0"
>  
> +#define DFU_ALT_INFO_QSPI \
> + "dfu_alt_info_qspi=" \
> + "MLO raw 0x0 0x01;" \
> + "MLO.backup1 raw 0x01 0x01;" \
> + "MLO.backup2 raw 0x02 0x01;" \
> + "MLO.backup3 raw 0x03 0x01;" \
> + "u-boot.img raw 0x04 0x010;" \
> + "u-boot-spl-os raw 0x14 0x08;" \
> + "u-boot-env raw 0x1C 0x01;" \
> + "u-boot-env.backup raw 0x1D 0x01;" \
> + "kernel raw 0x1E 0x80\0"
> +
>  #define DFUARGS \
>   "dfu_bufsiz=0x1\0" \
>   DFU_ALT_INFO_MMC \
>   DFU_ALT_INFO_EMMC \
> - DFU_ALT_INFO_RAM
> + DFU_ALT_INFO_RAM \
> + DFU_ALT_INFO_QSPI
>  
>  /* Fastboot */
>  #define CONFIG_USB_FUNCTION_FASTBOOT
> @@ -207,6 +220,7 @@
>  
>  #define CONFIG_DFU_MMC
>  #define CONFIG_DFU_RAM
> +#define CONFIG_DFU_SF
>  
>  /* SATA */
>  #define CONFIG_BOARD_LATE_INIT



-- 
Best regards,

Lukasz Majewski

Samsung R Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2 2/3] mx7: psci: add basic psci support

[Fabio Estevam]

On Tue, Oct 20, 2015 at 3:59 AM, Peng Fan  wrote:

> +static inline void psci_writel(u32 value, u32 reg)
> +{
> +   *(volatile u32 *)reg = value;
> +}
> +
> +static inline int psci_readl(u32 reg)
> +{
> +   return *(volatile u32*)reg;
> +}

Do you really need psci_writel() psci_readl() functions? Why not
simple call writel and readl instead?

> +/* enable all periherial can be access in nosec mode */
> +static void init_csu(void)
> +{
> +   int i = 0;
> +   for (i = 0; i < 64; i++)
> +   writel(0x00FF00FF, 0x303e + i * 4);

Lots of magic values here. Please add defines for improving code readability.

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

Re: [U-Boot] [PATCH 2/2] ARM: dra7xx_evm: Add DFU support for qspi flash

[Lukasz Majewski]

Hi Vignesh,

> Hi Lukasz,
> 
> On 10/20/2015 04:07 PM, Lukasz Majewski wrote:
> > Hi Vignesh,
> > 
> >> This adds support to update firmware on qspi flash using DFU.
> >>
> >> On device:
> >> => setenv dfu_alt_info ${dfu_alt_info_qspi}
> >> => dfu 0 sf 0:0
> >>
> >> On host:
> >> $ sudo dfu-util -l
> >> $ sudo dfu-util -D MLO -a MLO
> >> $ sudo dfu-util -D u-boot.img -a u-boot.img
> > 
> > This patch series seems ok. I just have one question regarding
> > dfu-util:
> > 
> > sudo dfu-util -D MLO -a MLO
> > 
> > Is the above correct?
> > 
> > Shouldn't it be sudo dfu-util -a 0 -D MLO 
> > where alt setting 0 corresponds to MLO?
> > 
> 
> According to man page of dfu-util 0.5 (supports DFU v1.0):
> "-a"  can be used Specify the Altsetting of the DFU Interface by name
> or by number
> 
> So since "MLO" is the name for alt setting 0 both
> sudo dfu-util -D MLO -a MLO  and
> sudo dfu-util -a 0 -D MLO  are correct.
> 
> I used the above format as its easier for reading. Thanks!

I'm using dfu-util for few years now and I was not aware of this :-).

I will test this patch set and then submit PR to Marek.

Thanks for your work!

> 
> >>
> >> Signed-off-by: Vignesh R 
> >> ---
> >>  include/configs/dra7xx_evm.h | 16 +++-
> >>  1 file changed, 15 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/include/configs/dra7xx_evm.h
> >> b/include/configs/dra7xx_evm.h index 6e32de854619..cb9544b49efb
> >> 100644 --- a/include/configs/dra7xx_evm.h
> >> +++ b/include/configs/dra7xx_evm.h
> >> @@ -82,11 +82,24 @@
> >>"fdt ram 0x80f8 0x8;" \
> >>"ramdisk ram 0x8100 0x400\0"
> >>  
> >> +#define DFU_ALT_INFO_QSPI \
> >> +  "dfu_alt_info_qspi=" \
> >> +  "MLO raw 0x0 0x01;" \
> >> +  "MLO.backup1 raw 0x01 0x01;" \
> >> +  "MLO.backup2 raw 0x02 0x01;" \
> >> +  "MLO.backup3 raw 0x03 0x01;" \
> >> +  "u-boot.img raw 0x04 0x010;" \
> >> +  "u-boot-spl-os raw 0x14 0x08;" \
> >> +  "u-boot-env raw 0x1C 0x01;" \
> >> +  "u-boot-env.backup raw 0x1D 0x01;" \
> >> +  "kernel raw 0x1E 0x80\0"
> >> +
> >>  #define DFUARGS \
> >>"dfu_bufsiz=0x1\0" \
> >>DFU_ALT_INFO_MMC \
> >>DFU_ALT_INFO_EMMC \
> >> -  DFU_ALT_INFO_RAM
> >> +  DFU_ALT_INFO_RAM \
> >> +  DFU_ALT_INFO_QSPI
> >>  
> >>  /* Fastboot */
> >>  #define CONFIG_USB_FUNCTION_FASTBOOT
> >> @@ -207,6 +220,7 @@
> >>  
> >>  #define CONFIG_DFU_MMC
> >>  #define CONFIG_DFU_RAM
> >> +#define CONFIG_DFU_SF
> >>  
> >>  /* SATA */
> >>  #define CONFIG_BOARD_LATE_INIT
> > 
> > 
> > 
> 



-- 
Best regards,

Lukasz Majewski

Samsung R Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v6 5/5] Revive OpenRD targets

[Albert ARIBAUD]

Revert commit 7a2c1b13 which dropped OpenRD boards.
Assume maintainership of OpenRD.
Switch OpenRD to generic board.
Switch to Thumb build.

Signed-off-by: Albert ARIBAUD 
---

Changes in v6:
- revive OpenRD targets and assume maintainership
- switch OpenRD to generic board and Thumb
- fix checkpatch warning and checks

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/mach-kirkwood/Kconfig|   4 +
 board/Marvell/openrd/Kconfig  |  12 +++
 board/Marvell/openrd/MAINTAINERS  |  12 +++
 board/Marvell/openrd/Makefile |  14 
 board/Marvell/openrd/kwbimage.cfg | 152 
 board/Marvell/openrd/openrd.c | 160 ++
 board/Marvell/openrd/openrd.h |  30 +++
 configs/openrd_base_defconfig |   7 ++
 configs/openrd_client_defconfig   |   7 ++
 configs/openrd_ultimate_defconfig |   7 ++
 include/configs/openrd.h  | 140 +
 11 files changed, 545 insertions(+)
 create mode 100644 board/Marvell/openrd/Kconfig
 create mode 100644 board/Marvell/openrd/MAINTAINERS
 create mode 100644 board/Marvell/openrd/Makefile
 create mode 100644 board/Marvell/openrd/kwbimage.cfg
 create mode 100644 board/Marvell/openrd/openrd.c
 create mode 100644 board/Marvell/openrd/openrd.h
 create mode 100644 configs/openrd_base_defconfig
 create mode 100644 configs/openrd_client_defconfig
 create mode 100644 configs/openrd_ultimate_defconfig
 create mode 100644 include/configs/openrd.h

diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig
index aab5d19..f7737bf 100644
--- a/arch/arm/mach-kirkwood/Kconfig
+++ b/arch/arm/mach-kirkwood/Kconfig
@@ -4,6 +4,9 @@ choice
prompt "Marvell Kirkwood board select"
optional
 
+config TARGET_OPENRD
+   bool "Marvell OpenRD Board"
+
 config TARGET_DREAMPLUG
bool "DreamPlug Board"
 
@@ -51,6 +54,7 @@ endchoice
 config SYS_SOC
default "kirkwood"
 
+source "board/Marvell/openrd/Kconfig"
 source "board/Marvell/dreamplug/Kconfig"
 source "board/Marvell/guruplug/Kconfig"
 source "board/Marvell/sheevaplug/Kconfig"
diff --git a/board/Marvell/openrd/Kconfig b/board/Marvell/openrd/Kconfig
new file mode 100644
index 000..124b66d
--- /dev/null
+++ b/board/Marvell/openrd/Kconfig
@@ -0,0 +1,12 @@
+if TARGET_OPENRD
+
+config SYS_BOARD
+   default "openrd"
+
+config SYS_VENDOR
+   default "Marvell"
+
+config SYS_CONFIG_NAME
+   default "openrd"
+
+endif
diff --git a/board/Marvell/openrd/MAINTAINERS b/board/Marvell/openrd/MAINTAINERS
new file mode 100644
index 000..3789a04
--- /dev/null
+++ b/board/Marvell/openrd/MAINTAINERS
@@ -0,0 +1,12 @@
+OPENRD BOARD
+M: Albert ARIBAUD 
+S: Maintained
+F: board/Marvell/openrd/
+F: include/configs/openrd.h
+F: configs/openrd_base_defconfig
+
+OPENRD_CLIENT BOARD
+M: Albert ARIBAUD 
+S: Maintained
+F: configs/openrd_client_defconfig
+F: configs/openrd_ultimate_defconfig
diff --git a/board/Marvell/openrd/Makefile b/board/Marvell/openrd/Makefile
new file mode 100644
index 000..8f95b79
--- /dev/null
+++ b/board/Marvell/openrd/Makefile
@@ -0,0 +1,14 @@
+#
+# (C) Copyright 2009
+# Net Insight 
+# Written-by: Simon Kagstrom 
+#
+# Based on sheevaplug:
+# (C) Copyright 2009
+# Marvell Semiconductor 
+# Written-by: Prafulla Wadaskar 
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y  := openrd.o
diff --git a/board/Marvell/openrd/kwbimage.cfg 
b/board/Marvell/openrd/kwbimage.cfg
new file mode 100644
index 000..8e59937
--- /dev/null
+++ b/board/Marvell/openrd/kwbimage.cfg
@@ -0,0 +1,152 @@
+#
+# (C) Copyright 2009
+# Marvell Semiconductor 
+# Written-by: Prafulla Wadaskar 
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Refer doc/README.kwbimage for more details about how-to configure
+# and create kirkwood boot image
+#
+
+# Boot Media configurations
+BOOT_FROM  nand
+NAND_ECC_MODE  default
+NAND_PAGE_SIZE 0x0800
+
+# SOC registers configuration using bootrom header extension
+# Maximum KWBIMAGE_MAX_CONFIG configurations allowed
+
+# Configure RGMII-0 interface pad voltage to 1.8V
+DATA 0xFFD100e0 0x1b1b1b9b
+
+#Dram initalization for SINGLE x16 CL=5 @ 400MHz
+DATA 0xFFD01400 0x43000c30 # DDR Configuration register
+# bit13-0:  0xc30 (3120 DDR2 clks refresh rate)
+# bit23-14: zero
+# bit24: 1= enable exit self refresh mode on DDR access
+# bit25: 1 required
+# bit29-26: zero
+# bit31-30: 01
+
+DATA 0xFFD01404 0x37543000 # DDR Controller Control Low
+# bit 4:0=addr/cmd in smame cycle
+# bit 5:0=clk is driven during self refresh, we don't care for APX
+# bit 6:0=use recommended falling edge of clk for addr/cmd
+# bit14:0=input buffer always powered up
+# bit18:1=cpu lock transaction enabled
+# bit23-20: 5=recommended 

[U-Boot] [PATCH v6 3/5] tricorder: switch to CONFIG_SYS_THUMB_BUILD

[Albert ARIBAUD]

The tricorder and tricorder_flash boards have grown too big.
Reduce their size by building them with CONFIG_SYS_THUMB_BUILD.

Signed-off-by: Albert ARIBAUD 
---

Changes in v6: None
Changes in v5:
- switched tricorder[_flash] to Thumb-1 build

Changes in v4: None
Changes in v3: None
Changes in v2: None

 include/configs/tricorder.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/tricorder.h b/include/configs/tricorder.h
index f04b572..2ac141c 100644
--- a/include/configs/tricorder.h
+++ b/include/configs/tricorder.h
@@ -17,6 +17,7 @@
 #define __CONFIG_H
 
 /* High Level Configuration Options */
+#define CONFIG_SYS_THUMB_BUILD
 #define CONFIG_OMAP/* in a TI OMAP core */
 #define CONFIG_OMAP_COMMON
 /* Common ARM Erratas */
-- 
2.1.4

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

[U-Boot] [PATCH v6 2/5] arm: support Thumb-1 with CONFIG_SYS_THUMB_BUILD

[Albert ARIBAUD]

When building a Thumb-1-only target with CONFIG_SYS_THUMB_BUILD,
some files fail to build, most of the time because they include
mcr instructions, which only exist for Thumb-2.

This patch introduces a Kconfig option CONFIG_THUMB2 and uses
it to select between Thumb-2 and ARM mode for the aforementioned
files.

Signed-off-by: Albert ARIBAUD 
---
This patch has been build-tested and run-tested on ED Mini V2,
above the "edmini: switch to SPL" patch, and found to reduce
U-Boot size by 25% and SPL size by 14%... and to run fine. :)

This patch has also been tested against side effects on the
non-Thumb wireless_space target. The binaries produced with
and without this patch were found to differ only by their
version string.

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3:
- added arch/arm/lib/mem{set,cpy}.S to the list of modules
  which should always be built in ARM state.
- Selected HAS_THUMB2 for CPU_V7M.
- Fixed invalidate_l2_cache() when building for Thumb-1.

Changes in v2:
- fixed a typo in the commit message
- added file arch/arm/thumb1/include/asm/proc-armv/system.h,
  which overrides arch/arm/include/asm/proc-armv/system.h
  when building for Thumb-1 and provides non-functional but
  Thumb-compilable IRQ and FIQ related macros and functions.

 Makefile   |  2 +
 arch/arm/Kconfig   |  5 ++
 arch/arm/cpu/arm926ejs/Makefile| 11 
 arch/arm/cpu/arm926ejs/cache.c |  5 ++
 arch/arm/include/asm/cache.h   |  4 ++
 arch/arm/lib/Makefile  | 24 +
 arch/arm/lib/cache.c   | 11 
 arch/arm/lib/memcpy.S  |  4 +-
 arch/arm/lib/memset.S  |  2 +-
 arch/arm/mach-orion5x/Makefile | 10 
 arch/arm/thumb1/include/asm/proc-armv/system.h | 69 ++
 examples/standalone/Makefile   | 10 
 12 files changed, 154 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/thumb1/include/asm/proc-armv/system.h

diff --git a/Makefile b/Makefile
index fd06024..ac207dd 100644
--- a/Makefile
+++ b/Makefile
@@ -605,6 +605,8 @@ KBUILD_CFLAGS += $(KCFLAGS)
 UBOOTINCLUDE:= \
-Iinclude \
$(if $(KBUILD_SRC), -I$(srctree)/include) \
+   $(if $(CONFIG_SYS_THUMB_BUILD), $(if $(CONFIG_HAS_THUMB2),, \
+   -I$(srctree)/arch/$(ARCH)/thumb1/include),) \
-I$(srctree)/arch/$(ARCH)/include \
-include $(srctree)/include/linux/kconfig.h
 
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 7981355..6e1eaa7 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -10,6 +10,9 @@ config ARM64
 config HAS_VBAR
 bool
 
+config HAS_THUMB2
+bool
+
 config CPU_ARM720T
 bool
 
@@ -32,9 +35,11 @@ config CPU_ARM1176
 config CPU_V7
 bool
 select HAS_VBAR
+select HAS_THUMB2
 
 config CPU_V7M
bool
+select HAS_THUMB2
 
 config CPU_PXA
 bool
diff --git a/arch/arm/cpu/arm926ejs/Makefile b/arch/arm/cpu/arm926ejs/Makefile
index 63fa159..fe78922 100644
--- a/arch/arm/cpu/arm926ejs/Makefile
+++ b/arch/arm/cpu/arm926ejs/Makefile
@@ -20,3 +20,14 @@ obj-$(CONFIG_MX25) += mx25/
 obj-$(CONFIG_MX27) += mx27/
 obj-$(if $(filter mxs,$(SOC)),y) += mxs/
 obj-$(if $(filter spear,$(SOC)),y) += spear/
+
+# some files can only build in ARM or THUMB2, not THUMB1
+
+ifdef CONFIG_SYS_THUMB_BUILD
+ifndef CONFIG_HAS_THUMB2
+
+CFLAGS_cpu.o := -marm
+CFLAGS_cache.o := -marm
+
+endif
+endif
diff --git a/arch/arm/cpu/arm926ejs/cache.c b/arch/arm/cpu/arm926ejs/cache.c
index e5c1a6a..2839c86 100644
--- a/arch/arm/cpu/arm926ejs/cache.c
+++ b/arch/arm/cpu/arm926ejs/cache.c
@@ -82,4 +82,9 @@ void flush_dcache_all(void)
 /*
  * Stub implementations for l2 cache operations
  */
+
 __weak void l2_cache_disable(void) {}
+
+#if defined CONFIG_SYS_THUMB_BUILD
+__weak void invalidate_l2_cache(void) {}
+#endif
diff --git a/arch/arm/include/asm/cache.h b/arch/arm/include/asm/cache.h
index a836e9f..1f63127 100644
--- a/arch/arm/include/asm/cache.h
+++ b/arch/arm/include/asm/cache.h
@@ -16,6 +16,9 @@
 /*
  * Invalidate L2 Cache using co-proc instruction
  */
+#ifdef CONFIG_SYS_THUMB_BUILD
+void invalidate_l2_cache(void);
+#else
 static inline void invalidate_l2_cache(void)
 {
unsigned int val=0;
@@ -24,6 +27,7 @@ static inline void invalidate_l2_cache(void)
: : "r" (val) : "cc");
isb();
 }
+#endif
 
 void l2_cache_enable(void);
 void l2_cache_disable(void);
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 2bdfaba..f3db7b5 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -60,3 +60,27 @@ obj-$(CONFIG_DEBUG_LL)   += debug.o
 ifneq (,$(findstring -mabi=aapcs-linux,$(PLATFORM_CPPFLAGS)))
 extra-y+= eabi_compat.o
 endif
+
+# some files can 

[U-Boot] [PATCH v6 0/5] Add support for Thumb-1 builds

[Albert ARIBAUD]

This series implements essential changes for thumb-1 support and
activates thumb-1 build for openrd and tricorder as a proof of
concept as well as a fix to bring the image sizes of openrd and
tricorder targets back under an acceptable limit.

For other targets, some additional files might need to be forced to
ARM building, notably architecture-specific instances of lowlevel_init.S
or of cpu.c. This should be handled on a case-by-case basis.

This series has two unfixed checkpatch diagnostics:

warning: arch/arm/mach-kirkwood/Kconfig,7:
please write a paragraph that describes the config symbol fully

(no option in this Kconfig has help info)

check: board/Marvell/openrd/openrd.c,42: Avoid CamelCase: 

(this is actually not an OpenRD problem and will be fixed
in another patch)

IMPORTANT NOTE:

The whole set has been build-tested across all ARM targets
and no build regression was detected -- actually, the series
does fix the x600 board which otherwise fails assembling an
mcr instruction.

Patch 1 has been confirmed to be binary-invariant.

Patch 2 has been build- and run-tested on ED Mini V2 (switched
temporarily to Thumb build) and confirmed to be binary-invariant
for non-thumb target Wireless Space.

Patches 3 through 6 have been build-tested BUT HAVE NOT BEEN
RUN-TESTED so far.

I will test on OpenRD (client) before the end of the merge
window, but:

*
Open-RD and Tricorder owners, PLEASE run-test this series
and report on the mailing list whether the target works.
*

Changes in v6:
- revive OpenRD targets and assume maintainership
- switch OpenRD to generic board and Thumb
- fix checkpatch warning and checks

Changes in v5:
- switched tricorder[_flash] to Thumb-1 build

Changes in v4:
- Made stm32f429-discovery explicitly state that it builds
  for Thumb

Changes in v3:
- added arch/arm/lib/mem{set,cpy}.S to the list of modules
  which should always be built in ARM state.
- Selected HAS_THUMB2 for CPU_V7M.
- Fixed invalidate_l2_cache() when building for Thumb-1.

Changes in v2:
- fixed a typo in the commit message
- added file arch/arm/thumb1/include/asm/proc-armv/system.h,
  which overrides arch/arm/include/asm/proc-armv/system.h
  when building for Thumb-1 and provides non-functional but
  Thumb-compilable IRQ and FIQ related macros and functions.

Albert ARIBAUD (5):
  stm32f429-discovery: add CONFIG_SYS_THUMB_BUILD
  arm: support Thumb-1 with CONFIG_SYS_THUMB_BUILD
  tricorder: switch to CONFIG_SYS_THUMB_BUILD
  kirkwood: support CONFIG_SYS_THUMB_BUILD
  Revive OpenRD targets

 Makefile   |   2 +
 arch/arm/Kconfig   |   5 +
 arch/arm/cpu/arm926ejs/Makefile|  11 ++
 arch/arm/cpu/arm926ejs/cache.c |   5 +
 arch/arm/include/asm/cache.h   |   4 +
 arch/arm/lib/Makefile  |  24 
 arch/arm/lib/cache.c   |  11 ++
 arch/arm/lib/memcpy.S  |   4 +-
 arch/arm/lib/memset.S  |   2 +-
 arch/arm/mach-kirkwood/Kconfig |   4 +
 arch/arm/mach-kirkwood/Makefile|   6 +
 arch/arm/mach-orion5x/Makefile |  10 ++
 arch/arm/thumb1/include/asm/proc-armv/system.h |  69 +++
 board/Marvell/openrd/Kconfig   |  12 ++
 board/Marvell/openrd/MAINTAINERS   |  12 ++
 board/Marvell/openrd/Makefile  |  14 +++
 board/Marvell/openrd/kwbimage.cfg  | 152 +++
 board/Marvell/openrd/openrd.c  | 160 +
 board/Marvell/openrd/openrd.h  |  30 +
 configs/openrd_base_defconfig  |   7 ++
 configs/openrd_client_defconfig|   7 ++
 configs/openrd_ultimate_defconfig  |   7 ++
 examples/standalone/Makefile   |  10 ++
 include/configs/openrd.h   | 140 ++
 include/configs/stm32f429-discovery.h  |   1 +
 include/configs/tricorder.h|   1 +
 26 files changed, 707 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/thumb1/include/asm/proc-armv/system.h
 create mode 100644 board/Marvell/openrd/Kconfig
 create mode 100644 board/Marvell/openrd/MAINTAINERS
 create mode 100644 board/Marvell/openrd/Makefile
 create mode 100644 board/Marvell/openrd/kwbimage.cfg
 create mode 100644 board/Marvell/openrd/openrd.c
 create mode 100644 board/Marvell/openrd/openrd.h
 create mode 100644 configs/openrd_base_defconfig
 create mode 100644 configs/openrd_client_defconfig
 create mode 100644 configs/openrd_ultimate_defconfig
 create mode 100644 include/configs/openrd.h

-- 
2.1.4

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

[U-Boot] [PATCH v6 1/5] stm32f429-discovery: add CONFIG_SYS_THUMB_BUILD

[Albert ARIBAUD]

This target is ARMv7-M therefore can only build for Thumb,
but it did not #define CONFIG_SYS_THUMB_BUILD, so the U-Boot
code did not know it had to build for Thumb(2), not ARM.

This patch is binary-invariant: builds of stm32f429-discovery
with and without this patch were compared and found to differ
only by their U-Boot version strings.

Signed-off-by: Albert ARIBAUD 
---

Changes in v6: None
Changes in v5: None
Changes in v4:
- Made stm32f429-discovery explicitly state that it builds
  for Thumb

Changes in v3: None
Changes in v2: None

 include/configs/stm32f429-discovery.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/stm32f429-discovery.h 
b/include/configs/stm32f429-discovery.h
index 19d9cf9..e773de4 100644
--- a/include/configs/stm32f429-discovery.h
+++ b/include/configs/stm32f429-discovery.h
@@ -9,6 +9,7 @@
 #define __CONFIG_H
 
 #define CONFIG_STM32F4
+#define CONFIG_SYS_THUMB_BUILD
 #define CONFIG_STM32F4DISCOVERY
 #define CONFIG_SYS_GENERIC_BOARD
 
-- 
2.1.4

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

[U-Boot] [PATCH v6 4/5] kirkwood: support CONFIG_SYS_THUMB_BUILD

[Albert ARIBAUD]

Kirkwood files cpu.c and cache.c cannot build in Thumb state;
force them in ARM state even under CONFIG_SYS_THUMB_BUILD.

Signed-off-by: Albert ARIBAUD 
---

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/mach-kirkwood/Makefile | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile
index df4756e..5abcf70 100644
--- a/arch/arm/mach-kirkwood/Makefile
+++ b/arch/arm/mach-kirkwood/Makefile
@@ -9,3 +9,9 @@
 obj-y  = cpu.o
 obj-y  += cache.o
 obj-y  += mpp.o
+
+# cpu.o and cache.o contain CP15 instructions which cannot be run in
+# Thumb state, so build them for ARM state even with CONFIG_SYS_THUMB_BUILD
+
+CFLAGS_cpu.o := -marm
+CFLAGS_cache.o := -marm
-- 
2.1.4

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

Re: [U-Boot] [PATCH V2 09/14] video: mxsfb: introduce lcdif_power_down

[Stefano Babic]

Hi Peng,

On 20/10/2015 13:39, Peng Fan wrote:
> Introudce a new function lcdif_power_down.
> 
> 1. Waits for a VSYNC interrupt to guarantee the reset is done at the
>VSYNC edge, which somehow makes the LCDIF consume the display FIFO(?)
>and helps the LCDIF work normally at the kernel stage.
> 2. Add power down function to stop lcdif.
> 
> The reason to introduce lcdif_power_down is that we want lcdif to be in
> initial state when doing uboot reset or before kernel boot to make
> system stable, otherwise system may hang.
> 

The explanation is independent from the processor type. But checking in
the next patch, this code runs only for 6UL. Why not for the 6sx ?


> Signed-off-by: Peng Fan 
> Cc: Stefano Babic 
> Cc: Anatolij Gustschin 
> ---
> 
> V2:
>  none
> 
>  arch/arm/include/asm/imx-common/sys_proto.h |  2 ++
>  drivers/video/mxsfb.c   | 17 +
>  2 files changed, 19 insertions(+)
> 
> diff --git a/arch/arm/include/asm/imx-common/sys_proto.h 
> b/arch/arm/include/asm/imx-common/sys_proto.h
> index 5673fb4..386c2dc 100644
> --- a/arch/arm/include/asm/imx-common/sys_proto.h
> +++ b/arch/arm/include/asm/imx-common/sys_proto.h
> @@ -47,6 +47,8 @@ int fecmxc_initialize(bd_t *bis);
>  u32 get_ahb_clk(void);
>  u32 get_periph_clk(void);
>  
> +void lcdif_power_down(void);
> +
>  int mxs_reset_block(struct mxs_register_32 *reg);
>  int mxs_wait_mask_set(struct mxs_register_32 *reg, u32 mask, u32 timeout);
>  int mxs_wait_mask_clr(struct mxs_register_32 *reg, u32 mask, u32 timeout);
> diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
> index eed57d5..ddbb118 100644
> --- a/drivers/video/mxsfb.c
> +++ b/drivers/video/mxsfb.c
> @@ -131,6 +131,23 @@ static void mxs_lcd_init(GraphicDevice *panel,
>   writel(LCDIF_CTRL_RUN, >hw_lcdif_ctrl_set);
>  }
>  
> +void lcdif_power_down(void)
> +{
> + struct mxs_lcdif_regs *regs = (struct mxs_lcdif_regs *)MXS_LCDIF_BASE;
> + int timeout = 100;
> +
> + writel(panel.frameAdrs, >hw_lcdif_cur_buf_reg);
> + writel(panel.frameAdrs, >hw_lcdif_next_buf_reg);
> + writel(LCDIF_CTRL1_VSYNC_EDGE_IRQ, >hw_lcdif_ctrl1_clr);
> + while (--timeout) {
> + if (readl(>hw_lcdif_ctrl1_reg) &
> + LCDIF_CTRL1_VSYNC_EDGE_IRQ)
> + break;
> + udelay(1);
> + }
> + mxs_reset_block((struct mxs_register_32 *)>hw_lcdif_ctrl_reg);
> +}
> +
>  void *video_hw_init(void)
>  {
>   int bpp = -1;
> 

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2 2/3] mx7: psci: add basic psci support

[Li Frank]

> -Original Message-
> From: Peng Fan [mailto:peng@freescale.com]
> Sent: Tuesday, October 20, 2015 1:00 AM
> To: u-boot@lists.denx.de
> Cc: Fan Peng-B51431 ; Li Frank-B20596
> ; Stefano Babic ; Estevam Fabio-
> R49496 
> Subject: [PATCH V2 2/3] mx7: psci: add basic psci support
> 
> 1. add basic psci support for imx7 chip.
> 2. support cpu_on and cpu_off.
> 3. switch to non-secure mode when boot linux kernel.
> 4. set csu allow accessing all peripherial register in non-secure mode.
> 
> Signed-off-by: Frank Li 
> Signed-off-by: Peng Fan 
> Cc: Stefano Babic 
> Cc: Fabio Estevam 
> ---
> 
> Changes V2:
>  Refine commit msg.
> 
>  arch/arm/cpu/armv7/mx7/Makefile   |  4 ++
>  arch/arm/cpu/armv7/mx7/psci-mx7.c | 78
> +++
>  arch/arm/cpu/armv7/mx7/psci.S | 54 +++
>  arch/arm/cpu/armv7/mx7/soc.c  |  9 +
>  4 files changed, 145 insertions(+)
>  create mode 100644 arch/arm/cpu/armv7/mx7/psci-mx7.c  create mode
> 100644 arch/arm/cpu/armv7/mx7/psci.S
> 
> diff --git a/arch/arm/cpu/armv7/mx7/Makefile
> b/arch/arm/cpu/armv7/mx7/Makefile index e6ecef0..f25461c 100644
> --- a/arch/arm/cpu/armv7/mx7/Makefile
> +++ b/arch/arm/cpu/armv7/mx7/Makefile
> @@ -6,3 +6,7 @@
>  #
> 
>  obj-y:= soc.o clock.o clock_slice.o
> +
> +ifdef CONFIG_ARMV7_PSCI
> +obj-y  += psci.o psci-mx7.o

Obj-y += psci-mx7.o psci.o
The otherwise psci_text_end will not be last one.

Best regards
Frank Li

> +endif
> diff --git a/arch/arm/cpu/armv7/mx7/psci-mx7.c
> b/arch/arm/cpu/armv7/mx7/psci-mx7.c
> new file mode 100644
> index 000..ec9ad87
> --- /dev/null
> +++ b/arch/arm/cpu/armv7/mx7/psci-mx7.c
> @@ -0,0 +1,78 @@
> +#include 
> +#include 
> +#include 
> +
> +#define __secure __attribute__((section("._secure.text")))
> +
> +#define GPC_CPU_PGC_SW_PDN_REQ   0xfc
> +#define GPC_CPU_PGC_SW_PUP_REQ   0xf0
> +#define GPC_PGC_C1   0x840
> +
> +#define BM_CPU_PGC_SW_PDN_PUP_REQ_CORE1_A7   0x2
> +
> +/* below is for i.MX7D */
> +#define SRC_GPR1_MX7D0x074
> +#define SRC_A7RCR0   0x004
> +#define SRC_A7RCR1   0x008
> +
> +#define BP_SRC_A7RCR0_A7_CORE_RESET0 0
> +#define BP_SRC_A7RCR1_A7_CORE1_ENABLE1
> +
> +static inline void psci_writel(u32 value, u32 reg) {
> + *(volatile u32 *)reg = value;
> +}
> +
> +static inline int psci_readl(u32 reg)
> +{
> + return *(volatile u32*)reg;
> +}
> +
> +static inline void imx_gpcv2_set_m_core_pgc(bool enable, u32 offset) {
> + psci_writel(enable, GPC_IPS_BASE_ADDR + offset); }
> +
> +__secure void imx_gpcv2_set_core1_power(bool pdn) {
> + u32 reg = pdn ? GPC_CPU_PGC_SW_PUP_REQ :
> GPC_CPU_PGC_SW_PDN_REQ;
> + u32 val;
> +
> + imx_gpcv2_set_m_core_pgc(true, GPC_PGC_C1);
> +
> + val = psci_readl(GPC_IPS_BASE_ADDR + reg);
> + val |= BM_CPU_PGC_SW_PDN_PUP_REQ_CORE1_A7;
> + psci_writel(val, GPC_IPS_BASE_ADDR + reg);
> +
> + while ((psci_readl(GPC_IPS_BASE_ADDR + reg) &
> +BM_CPU_PGC_SW_PDN_PUP_REQ_CORE1_A7) != 0)
> + ;
> +
> + imx_gpcv2_set_m_core_pgc(false, GPC_PGC_C1); }
> +
> +__secure void imx_enable_cpu_ca7(int cpu, bool enable) {
> + u32 mask, val;
> +
> + mask = 1 << (BP_SRC_A7RCR1_A7_CORE1_ENABLE + cpu - 1);
> + val = psci_readl(SRC_BASE_ADDR + SRC_A7RCR1);
> + val = enable ? val | mask : val & ~mask;
> + psci_writel(val, SRC_BASE_ADDR + SRC_A7RCR1); }
> +
> +__secure int imx_cpu_on(int fn, int cpu, int pc) {
> + psci_writel(pc, SRC_BASE_ADDR + cpu * 8 + SRC_GPR1_MX7D);
> + imx_gpcv2_set_core1_power(true);
> + imx_enable_cpu_ca7(cpu, true);
> + return 0;
> +}
> +
> +__secure int imx_cpu_off(int cpu)
> +{
> + imx_enable_cpu_ca7(cpu, false);
> + imx_gpcv2_set_core1_power(false);
> + psci_writel(0, SRC_BASE_ADDR + cpu * 8 + SRC_GPR1_MX7D + 4);
> + return 0;
> +}
> diff --git a/arch/arm/cpu/armv7/mx7/psci.S b/arch/arm/cpu/armv7/mx7/psci.S
> new file mode 100644 index 000..34c6ab3
> --- /dev/null
> +++ b/arch/arm/cpu/armv7/mx7/psci.S
> @@ -0,0 +1,54 @@
> +#include 
> +#include 
> +
> +#include 
> +#include  #include 
> +
> + .pushsection ._secure.text, "ax"
> +
> + .arch_extension sec
> +
> + @ r1 = target CPU
> + @ r2 = target PC
> +
> +.globl   psci_arch_init
> +psci_arch_init:
> + mov r6, lr
> +
> + bl  psci_get_cpu_id
> + bl  psci_get_cpu_stack_top
> + mov sp, r0
> +
> + bx  r6
> +
> + @ r1 = target CPU
> + @ r2 = target PC
> +
> +.globl psci_cpu_on
> +psci_cpu_on:
> + push{lr}
> +
> + mov r0, r1
> + bl  psci_get_cpu_stack_top
> + str r2, [r0]
> + dsb
> +
> + ldr r2, =psci_cpu_entry
> + bl  imx_cpu_on
> +
> + pop {pc}
> +
> +.globl 

[U-Boot] [PATCH V2 01/14] mxs: add parameter base_addr for mxs_set_lcdclk

[Peng Fan]

Change mxs_set_lcdclk prototype to add a new parameter
base_addr. There are two LCD interfaces for i.MX6SX,
we may support LCDIF1 or LCDIF2.

Signed-off-by: Peng Fan 
Cc: Stefano Babic 
Cc: Anatolij Gustschin 
---

V2:
 none

 arch/arm/cpu/arm926ejs/mxs/clock.c| 2 +-
 arch/arm/include/asm/arch-mxs/clock.h | 2 +-
 drivers/video/mxsfb.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/mxs/clock.c 
b/arch/arm/cpu/arm926ejs/mxs/clock.c
index e9d8800..dac8dc6 100644
--- a/arch/arm/cpu/arm926ejs/mxs/clock.c
+++ b/arch/arm/cpu/arm926ejs/mxs/clock.c
@@ -309,7 +309,7 @@ void mxs_set_ssp_busclock(unsigned int bus, uint32_t freq)
bus, tgtclk, freq);
 }
 
-void mxs_set_lcdclk(uint32_t freq)
+void mxs_set_lcdclk(uint32_t base_addr, uint32_t freq)
 {
struct mxs_clkctrl_regs *clkctrl_regs =
(struct mxs_clkctrl_regs *)MXS_CLKCTRL_BASE;
diff --git a/arch/arm/include/asm/arch-mxs/clock.h 
b/arch/arm/include/asm/arch-mxs/clock.h
index fc9d75b..8840335 100644
--- a/arch/arm/include/asm/arch-mxs/clock.h
+++ b/arch/arm/include/asm/arch-mxs/clock.h
@@ -46,7 +46,7 @@ uint32_t mxc_get_clock(enum mxc_clock clk);
 void mxs_set_ioclk(enum mxs_ioclock io, uint32_t freq);
 void mxs_set_sspclk(enum mxs_sspclock ssp, uint32_t freq, int xtal);
 void mxs_set_ssp_busclock(unsigned int bus, uint32_t freq);
-void mxs_set_lcdclk(uint32_t freq);
+void mxs_set_lcdclk(uint32_t base_addr, uint32_t freq);
 
 /* Compatibility with the FEC Ethernet driver */
 #defineimx_get_fecclk()mxc_get_clock(MXC_AHB_CLK)
diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
index 03b0f88..eed57d5 100644
--- a/drivers/video/mxsfb.c
+++ b/drivers/video/mxsfb.c
@@ -55,7 +55,7 @@ static void mxs_lcd_init(GraphicDevice *panel,
uint8_t valid_data = 0;
 
/* Kick in the LCDIF clock */
-   mxs_set_lcdclk(PS2KHZ(mode->pixclock));
+   mxs_set_lcdclk(MXS_LCDIF_BASE, PS2KHZ(mode->pixclock));
 
/* Restart the LCDIF block */
mxs_reset_block(>hw_lcdif_ctrl_reg);
-- 
1.8.4


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

[U-Boot] [PATCH V2 00/14] imx: mx6/7: support lcdif

[Peng Fan]

Changes v2:
 1. Rebased on Latest U-Boot
 2. Add i.MX7 LCDIF support

This patch set is to introduce lcdif support for i.MX6/7.
Patchset tested on mx6ul_14x14/9x9_evk and mx7dsabresd boards.

1/14
There are two LCD interface for i.MX6SX and one interface for i.MX6UL,
so change the prototype mxs_set_lcdclk to handle different interface.

[2,3]/14
I am not sure, but from my understanding, the 'board_' should be discarded.

4/14
mx28 and mx6ul/sx have similar register layout and bit definitions, so
move related structure and bit definitions to imx-common.

[5,6,7]/14
is to add related CCM macros, clock apis for enable lcdif on i.MX6

8/14
support lcdif for i.MX6UL 14x14/9x9 board

9/14
Introduce lcdif_power_down, to make system stable when reset or boot os

[10,11]/14
Need to call lcdif_power_down, before trigger wdog reset or boot os.
Or we may met unexpected system hang.

[12,13,14]/14
Mainly support LCDIF for i.MX7.

Peng Fan (14):
  mxs: add parameter base_addr for mxs_set_lcdclk
  sandisk: sfp: correct function name
  xfi3: correct function name
  imx: imx-common: move lcdif structure and macro definition to
imx-common
  imx: mx6: fix register address
  imx: mx6: crm_reg: add LCDIF related macros
  imx: mx6: add clock api for lcdif
  imx: mx6ul_14x14_evk: support lcdif display
  video: mxsfb: introduce lcdif_power_down
  imx: mx6: implement reset_misc
  imx: imx-common: power down lcdif before boot os
  imx: mx7: compile misc.c for mx7
  imx: mx7 use the common lcdif register structure
  imx: mx7dsabresd: support lcdif

 arch/arm/cpu/arm926ejs/mxs/clock.c|   2 +-
 arch/arm/cpu/armv7/mx6/clock.c| 239 ++
 arch/arm/cpu/armv7/mx6/soc.c  |   8 +
 arch/arm/imx-common/Makefile  |   2 +-
 arch/arm/imx-common/cpu.c |   3 +
 arch/arm/include/asm/arch-mx6/clock.h |   2 +
 arch/arm/include/asm/arch-mx6/crm_regs.h  |  34 ++-
 arch/arm/include/asm/arch-mx6/imx-regs.h  |  15 +-
 arch/arm/include/asm/arch-mx7/imx-regs.h  |  96 +
 arch/arm/include/asm/arch-mxs/clock.h |   2 +-
 arch/arm/include/asm/arch-mxs/regs-lcdif.h| 201 +-
 arch/arm/include/asm/imx-common/regs-lcdif.h  | 224 
 arch/arm/include/asm/imx-common/sys_proto.h   |   2 +
 board/creative/xfi3/xfi3.c|   2 +-
 board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c |  63 ++
 board/freescale/mx7dsabresd/mx7dsabresd.c |  64 ++
 board/sandisk/sansa_fuze_plus/sfp.c   |   2 +-
 drivers/video/mxsfb.c |  19 +-
 include/configs/mx6ul_14x14_evk.h |  18 ++
 include/configs/mx7dsabresd.h |  17 ++
 20 files changed, 705 insertions(+), 310 deletions(-)
 create mode 100644 arch/arm/include/asm/imx-common/regs-lcdif.h

-- 
1.8.4


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

[U-Boot] [PATCH V2 02/14] sandisk: sfp: correct function name

[Peng Fan]

board_mxsfb_system_setup shoule be named mxsfb_system_setup.

Signed-off-by: Peng Fan 
Cc: Marek Vasut 
Cc: Stefano Babic 
---

V2:
 none

 board/sandisk/sansa_fuze_plus/sfp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/sandisk/sansa_fuze_plus/sfp.c 
b/board/sandisk/sansa_fuze_plus/sfp.c
index a3865ad..8d1a797 100644
--- a/board/sandisk/sansa_fuze_plus/sfp.c
+++ b/board/sandisk/sansa_fuze_plus/sfp.c
@@ -311,7 +311,7 @@ static const struct {
{ 0x07, 0  , 0x0173 },
 };
 
-void board_mxsfb_system_setup(void)
+void mxsfb_system_setup(void)
 {
struct mxs_lcdif_regs *regs = (struct mxs_lcdif_regs *)MXS_LCDIF_BASE;
uint32_t id;
-- 
1.8.4


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

[U-Boot] [PATCH V2 03/14] xfi3: correct function name

[Peng Fan]

board_mxsfb_system_setup shoule be named mxsfb_system_setup.

Signed-off-by: Peng Fan 
Cc: Marek Vasut 
Cc: Stefano Babic 
---

V2:
 none

 board/creative/xfi3/xfi3.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/creative/xfi3/xfi3.c b/board/creative/xfi3/xfi3.c
index 1d83ea8..509c671 100644
--- a/board/creative/xfi3/xfi3.c
+++ b/board/creative/xfi3/xfi3.c
@@ -163,7 +163,7 @@ static const struct {
{ 0x21, 0,  0x },
 };
 
-void board_mxsfb_system_setup(void)
+void mxsfb_system_setup(void)
 {
struct mxs_lcdif_regs *regs = (struct mxs_lcdif_regs *)MXS_LCDIF_BASE;
int i;
-- 
1.8.4


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

[U-Boot] [PATCH] mmc: fsl_esdhc: fix mmc read/write error on T4160/T4080

[Yangbo Lu]

Fill the right command type when using CMD12 to stop data transfer.

Signed-off-by: Yangbo Lu 
---
 drivers/mmc/fsl_esdhc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index 0b37002..69c0728 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -106,7 +106,8 @@ static uint esdhc_xfertyp(struct mmc_cmd *cmd, struct 
mmc_data *data)
xfertyp |= XFERTYP_RSPTYP_48;
 
 #if defined(CONFIG_MX53) || defined(CONFIG_PPC_T4240) || \
-   defined(CONFIG_LS102XA) || defined(CONFIG_LS2085A)
+   defined(CONFIG_LS102XA) || defined(CONFIG_LS2085A) \
+   defined(CONFIG_PPC_T4160) || defined(CONFIG_PPC_T4080)
if (cmd->cmdidx == MMC_CMD_STOP_TRANSMISSION)
xfertyp |= XFERTYP_CMDTYP_ABORT;
 #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] Porting UBI fixes (specially fastmap's) to U-Boot

[Richard Weinberger]

Am 20.10.2015 um 06:00 schrieb Heiko Schocher:
> Hello Richard
> 
> Am 19.10.2015 um 23:48 schrieb Richard Weinberger:
>> Am 19.10.2015 um 23:40 schrieb Ezequiel Garcia:
>>> On 19 October 2015 at 17:22, Richard Weinberger  wrote:
 Am 19.10.2015 um 15:47 schrieb Ezequiel Garcia:
> After some further investigation, printing the counters as Richard 
> suggested
> I found it was a bug on my side :-( The Linux partition and the U-Boot 
> partition
> had different size (i.e. PEB count) and so Fastmap complained :-(
>
> We trimmed the Linux partition size, and forgot to change U-Boot's
> (or thought it wouldn't matter).
>
> Sorry for the noise guys!

 Good to know. :)

 Let me find a way to detect and report this kind of user error
 better.
 The WARN_ON() is only meant for bad internal errors.

>>>
>>> Sure. In case it's not clear, let me clarify what the issue was: the
>>> MTD partition
>>> has one size in Linux (4072 EB) and another size in U-Boot (4076 EB).
>>>
>>> When the map was built by Linux's Fastmap, it contained a number of PEBs 
>>> that
>>> conflicted with the number of PEBs U-Boot's Fastmap code was expecting
>>> (becase Linux EB != U-Boot EB).
>>>
>>> Not sure how you would detect such a mismatch, but it was a very good
>>> idea to print a noisy warning :-)
>>
>> I think it would make sense to drop the WARN_ON() and replace it to a
>> warning using ubi_err() which explains what possible went wrong.
>> i.e. MTD partition layout mismatch, an internal error, etc...
> 
> Yep.
> 
>>> We were effectively running without fastmap so far, becasue neither U-Boot
>>> nor Linux could find a proper fastmap and attach the UBI partition using it.
>>
>> Yeah, U-Boot's fast decided to fall back to scanning mode and had to drop the
>> existing fastmap and therefore Linux also had to do a full scan too.
> 
> Didn;t got this, why is fastmap not working in U-Boot?

No, the above explanation is why fastmap was used in Ezequiel's setup.

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

[U-Boot] [PATCH v4] x86: Added support for Advantech SOM-6896

[George McCollister]

Advantech SOM-6896 is a Broadwell U based COM Express Compact Module
Type 6. This patch adds support for it as a coreboot payload.

On board SATA and SPI are functional. On board Ethernet isn't functional
but since it's optional and ties up a PCIe x4 that is otherwise brought
out, this isn't a concern at the moment. USB doesn't work since the
xHCI driver appears to be broken.

Signed-off-by: George McCollister 
---
Changes for V2:
 Changed pci's compatible string to "pci-x86"
 Changed I/O from base of 0x1000 to base of 0x1900
 Changed spi-flash memory-map
Changes for V3:
 Renamed som-6896.dts to broadwell_som-6896.dts
Changes for V4:
 Changed PCI I/O start from 0x1900 to 0x2000 (actually did it this time)
 Removed whitespace before my name at the top of som-6896.h

 arch/x86/dts/Makefile   |  3 ++-
 arch/x86/dts/broadwell_som-6896.dts | 43 +
 include/configs/som-6896.h  | 38 
 3 files changed, 83 insertions(+), 1 deletion(-)
 create mode 100644 arch/x86/dts/broadwell_som-6896.dts
 create mode 100644 include/configs/som-6896.h

diff --git a/arch/x86/dts/Makefile b/arch/x86/dts/Makefile
index 71595c7..83a2b8c 100644
--- a/arch/x86/dts/Makefile
+++ b/arch/x86/dts/Makefile
@@ -6,7 +6,8 @@ dtb-y += bayleybay.dtb \
galileo.dtb \
minnowmax.dtb \
qemu-x86_i440fx.dtb \
-   qemu-x86_q35.dtb
+   qemu-x86_q35.dtb \
+   broadwell_som-6896.dtb
 
 targets += $(dtb-y)
 
diff --git a/arch/x86/dts/broadwell_som-6896.dts 
b/arch/x86/dts/broadwell_som-6896.dts
new file mode 100644
index 000..a6b5d0f
--- /dev/null
+++ b/arch/x86/dts/broadwell_som-6896.dts
@@ -0,0 +1,43 @@
+/dts-v1/;
+
+/include/ "skeleton.dtsi"
+/include/ "serial.dtsi"
+/include/ "rtc.dtsi"
+
+/ {
+   model = "Advantech SOM-6896";
+   compatible = "advantech,som-6896", "intel,broadwell";
+
+   aliases {
+   spi0 = "/spi";
+   };
+
+   config {
+  silent_console = <0>;
+   };
+
+   chosen {
+   stdout-path = "/serial";
+   };
+
+   pci {
+   compatible = "pci-x86";
+   #address-cells = <3>;
+   #size-cells = <2>;
+   u-boot,dm-pre-reloc;
+   ranges = <0x0200 0x0 0xe000 0xe000 0 0x1000
+   0x4200 0x0 0xd000 0xd000 0 0x1000
+   0x0100 0x0 0x2000 0x2000 0 0xe000>;
+   };
+
+   spi {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "intel,ich-spi";
+   spi-flash@0 {
+   reg = <0>;
+   compatible = "winbond,w25q128", "spi-flash";
+   memory-map = <0xff00 0x0100>;
+   };
+   };
+};
diff --git a/include/configs/som-6896.h b/include/configs/som-6896.h
new file mode 100644
index 000..300e9df
--- /dev/null
+++ b/include/configs/som-6896.h
@@ -0,0 +1,38 @@
+/*
+ * Configuration settings for the SOM-6896
+ *
+ * Copyright (C) 2015 NovaTech LLC
+ * George McCollister 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __CONFIG_H
+#define __CONFIG_H
+
+#include 
+
+#define CONFIG_SYS_MONITOR_LEN (1 << 20)
+
+#define CONFIG_BOARD_EARLY_INIT_F
+#define CONFIG_MISC_INIT_R
+
+#define CONFIG_SCSI_DEV_LIST   \
+   {PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_WILDCATPOINT_AHCI}
+
+#define CONFIG_SYS_EARLY_PCI_INIT
+#define CONFIG_PCI_PNP
+
+#define VIDEO_IO_OFFSET0
+#define CONFIG_X86EMU_RAW_IO
+
+#define CONFIG_ARCH_EARLY_INIT_R
+
+#define CONFIG_STD_DEVICES_SETTINGS "stdin=serial,vga,usbkbd\0" \
+   "stdout=serial,vga\0" \
+   "stderr=serial,vga\0"
+
+#define CONFIG_ENV_SECT_SIZE   0x1000
+#define CONFIG_ENV_OFFSET  0x00ff
+
+#endif /* __CONFIG_H */
-- 
2.5.0

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

[U-Boot] [PATCH V2 13/14] imx: mx7 use the common lcdif register structure

[Peng Fan]

Use the common lcdif register struct, but not define another
same register.
Introduce i.MX7 in lcdif register structure.

Signed-off-by: Peng Fan 
Cc: Stefano Babic 
Cc: Fabio Estevam 
---

V2:
 new patch

 arch/arm/include/asm/arch-mx7/imx-regs.h | 96 +---
 arch/arm/include/asm/imx-common/regs-lcdif.h |  8 ++-
 2 files changed, 6 insertions(+), 98 deletions(-)

diff --git a/arch/arm/include/asm/arch-mx7/imx-regs.h 
b/arch/arm/include/asm/arch-mx7/imx-regs.h
index 4dc11ee..5851e12 100644
--- a/arch/arm/include/asm/arch-mx7/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx7/imx-regs.h
@@ -217,6 +217,7 @@
 #define SNVS_LPGPR 0x68
 
 #if !(defined(__KERNEL_STRICT_NAMES) || defined(__ASSEMBLY__))
+#include 
 #include 
 
 extern void imx_get_mac_from_fuse(int dev_id, unsigned char *mac);
@@ -1029,101 +1030,6 @@ struct rdc_sema_regs {
u16 rstgt;  /* Reset Gate */
 };
 
-/* eLCDIF controller registers */
-struct mxs_lcdif_regs {
-   u32 hw_lcdif_ctrl;  /* 0x00 */
-   u32 hw_lcdif_ctrl_set;
-   u32 hw_lcdif_ctrl_clr;
-   u32 hw_lcdif_ctrl_tog;
-   u32 hw_lcdif_ctrl1; /* 0x10 */
-   u32 hw_lcdif_ctrl1_set;
-   u32 hw_lcdif_ctrl1_clr;
-   u32 hw_lcdif_ctrl1_tog;
-   u32 hw_lcdif_ctrl2; /* 0x20 */
-   u32 hw_lcdif_ctrl2_set;
-   u32 hw_lcdif_ctrl2_clr;
-   u32 hw_lcdif_ctrl2_tog;
-   u32 hw_lcdif_transfer_count;/* 0x30 */
-   u32 reserved1[3];
-   u32 hw_lcdif_cur_buf;   /* 0x40 */
-   u32 reserved2[3];
-   u32 hw_lcdif_next_buf;  /* 0x50 */
-   u32 reserved3[3];
-   u32 hw_lcdif_timing;/* 0x60 */
-   u32 reserved4[3];
-   u32 hw_lcdif_vdctrl0;   /* 0x70 */
-   u32 hw_lcdif_vdctrl0_set;
-   u32 hw_lcdif_vdctrl0_clr;
-   u32 hw_lcdif_vdctrl0_tog;
-   u32 hw_lcdif_vdctrl1;   /* 0x80 */
-   u32 reserved5[3];
-   u32 hw_lcdif_vdctrl2;   /* 0x90 */
-   u32 reserved6[3];
-   u32 hw_lcdif_vdctrl3;   /* 0xa0 */
-   u32 reserved7[3];
-   u32 hw_lcdif_vdctrl4;   /* 0xb0 */
-   u32 reserved8[3];
-   u32 hw_lcdif_dvictrl0;  /* 0xc0 */
-   u32 reserved9[3];
-   u32 hw_lcdif_dvictrl1;  /* 0xd0 */
-   u32 reserved10[3];
-   u32 hw_lcdif_dvictrl2;  /* 0xe0 */
-   u32 reserved11[3];
-   u32 hw_lcdif_dvictrl3;  /* 0xf0 */
-   u32 reserved12[3];
-   u32 hw_lcdif_dvictrl4;  /* 0x100 */
-   u32 reserved13[3];
-   u32 hw_lcdif_csc_coeffctrl0;/* 0x110 */
-   u32 reserved14[3];
-   u32 hw_lcdif_csc_coeffctrl1;/* 0x120 */
-   u32 reserved15[3];
-   u32 hw_lcdif_csc_coeffctrl2;/* 0x130 */
-   u32 reserved16[3];
-   u32 hw_lcdif_csc_coeffctrl3;/* 0x140 */
-   u32 reserved17[3];
-   u32 hw_lcdif_csc_coeffctrl4;/* 0x150 */
-   u32 reserved18[3];
-   u32 hw_lcdif_csc_offset;/* 0x160 */
-   u32 reserved19[3];
-   u32 hw_lcdif_csc_limit; /* 0x170 */
-   u32 reserved20[3];
-   u32 hw_lcdif_data;  /* 0x180 */
-   u32 reserved21[3];
-   u32 hw_lcdif_bm_error_stat; /* 0x190 */
-   u32 reserved22[3];
-   u32 hw_lcdif_crc_stat;  /* 0x1a0 */
-   u32 reserved23[3];
-   u32 hw_lcdif_lcdif_stat;/* 0x1b0 */
-   u32 reserved24[3];
-   u32 hw_lcdif_version;   /* 0x1c0 */
-   u32 reserved25[3];
-   u32 hw_lcdif_debug0;/* 0x1d0 */
-   u32 reserved26[3];
-   u32 hw_lcdif_debug1;/* 0x1e0 */
-   u32 reserved27[3];
-   u32 hw_lcdif_debug2;/* 0x1f0 */
-   u32 reserved28[3];
-   u32 hw_lcdif_thres; /* 0x200 */
-   u32 reserved29[3];
-   u32 hw_lcdif_as_ctrl;   /* 0x210 */
-   u32 reserved30[3];
-   u32 hw_lcdif_as_buf;/* 0x220 */
-   u32 reserved31[3];
-   u32 hw_lcdif_as_next_buf;   /* 0x230 */
-   u32 reserved32[3];
-   u32 hw_lcdif_as_clrkeylow;  /* 0x240 */
-   u32 reserved33[3];
-   u32 hw_lcdif_as_clrkeyhigh; /* 0x250 */
-   u32 reserved34[3];
-   u32 hw_lcdif_as_sync_delay; /* 0x260 */
-   u32 reserved35[3];
-   u32 hw_lcdif_as_debug3; /* 0x270 */
-   u32 reserved36[3];
-   u32 hw_lcdif_as_debug4; /* 0x280 */
-   u32 

[U-Boot] [PATCH V2 09/14] video: mxsfb: introduce lcdif_power_down

[Peng Fan]

Introudce a new function lcdif_power_down.

1. Waits for a VSYNC interrupt to guarantee the reset is done at the
   VSYNC edge, which somehow makes the LCDIF consume the display FIFO(?)
   and helps the LCDIF work normally at the kernel stage.
2. Add power down function to stop lcdif.

The reason to introduce lcdif_power_down is that we want lcdif to be in
initial state when doing uboot reset or before kernel boot to make
system stable, otherwise system may hang.

Signed-off-by: Peng Fan 
Cc: Stefano Babic 
Cc: Anatolij Gustschin 
---

V2:
 none

 arch/arm/include/asm/imx-common/sys_proto.h |  2 ++
 drivers/video/mxsfb.c   | 17 +
 2 files changed, 19 insertions(+)

diff --git a/arch/arm/include/asm/imx-common/sys_proto.h 
b/arch/arm/include/asm/imx-common/sys_proto.h
index 5673fb4..386c2dc 100644
--- a/arch/arm/include/asm/imx-common/sys_proto.h
+++ b/arch/arm/include/asm/imx-common/sys_proto.h
@@ -47,6 +47,8 @@ int fecmxc_initialize(bd_t *bis);
 u32 get_ahb_clk(void);
 u32 get_periph_clk(void);
 
+void lcdif_power_down(void);
+
 int mxs_reset_block(struct mxs_register_32 *reg);
 int mxs_wait_mask_set(struct mxs_register_32 *reg, u32 mask, u32 timeout);
 int mxs_wait_mask_clr(struct mxs_register_32 *reg, u32 mask, u32 timeout);
diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
index eed57d5..ddbb118 100644
--- a/drivers/video/mxsfb.c
+++ b/drivers/video/mxsfb.c
@@ -131,6 +131,23 @@ static void mxs_lcd_init(GraphicDevice *panel,
writel(LCDIF_CTRL_RUN, >hw_lcdif_ctrl_set);
 }
 
+void lcdif_power_down(void)
+{
+   struct mxs_lcdif_regs *regs = (struct mxs_lcdif_regs *)MXS_LCDIF_BASE;
+   int timeout = 100;
+
+   writel(panel.frameAdrs, >hw_lcdif_cur_buf_reg);
+   writel(panel.frameAdrs, >hw_lcdif_next_buf_reg);
+   writel(LCDIF_CTRL1_VSYNC_EDGE_IRQ, >hw_lcdif_ctrl1_clr);
+   while (--timeout) {
+   if (readl(>hw_lcdif_ctrl1_reg) &
+   LCDIF_CTRL1_VSYNC_EDGE_IRQ)
+   break;
+   udelay(1);
+   }
+   mxs_reset_block((struct mxs_register_32 *)>hw_lcdif_ctrl_reg);
+}
+
 void *video_hw_init(void)
 {
int bpp = -1;
-- 
1.8.4


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

[U-Boot] [PATCH V2 12/14] imx: mx7: compile misc.c for mx7

[Peng Fan]

Compile misc.c for mx7, since we need related function for
lcdif and nand.

Signed-off-by: Peng Fan 
Cc: Sanchayan Maity 
Cc: Stefan Agner 
Cc: Stefano Babic 
Cc: Fabio Estevam 
---

V2:
 new patch

 arch/arm/imx-common/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/imx-common/Makefile b/arch/arm/imx-common/Makefile
index 1698d06..45b3371 100644
--- a/arch/arm/imx-common/Makefile
+++ b/arch/arm/imx-common/Makefile
@@ -14,7 +14,7 @@ ifeq ($(SOC),$(filter $(SOC),mx5 mx6))
 obj-y  += timer.o cpu.o speed.o
 obj-$(CONFIG_SYS_I2C_MXC) += i2c-mxv7.o
 endif
-ifeq ($(SOC),$(filter $(SOC),mx6 mxs))
+ifeq ($(SOC),$(filter $(SOC),mx7 mx6 mxs))
 obj-y  += misc.o
 obj-$(CONFIG_SPL_BUILD)+= spl.o
 endif
-- 
1.8.4


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

[U-Boot] [PATCH V2 14/14] imx: mx7dsabresd: support lcdif

[Peng Fan]

Support LCDIF for mx7dsabresd board:
1. Add pinmux settings
2. Add VIDEO related macro definition and videomode env settings.

Signed-off-by: Peng Fan 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Adrian Alonso 
---

V2:
 new patch

 board/freescale/mx7dsabresd/mx7dsabresd.c | 64 +++
 include/configs/mx7dsabresd.h | 17 
 2 files changed, 81 insertions(+)

diff --git a/board/freescale/mx7dsabresd/mx7dsabresd.c 
b/board/freescale/mx7dsabresd/mx7dsabresd.c
index ee9890b..6c863da 100644
--- a/board/freescale/mx7dsabresd/mx7dsabresd.c
+++ b/board/freescale/mx7dsabresd/mx7dsabresd.c
@@ -41,6 +41,9 @@ DECLARE_GLOBAL_DATA_PTR;
 #define I2C_PAD_CTRL(PAD_CTL_DSE_3P3V_32OHM | PAD_CTL_SRE_SLOW | \
PAD_CTL_HYS | PAD_CTL_PUE | PAD_CTL_PUS_PU100KOHM)
 
+#define LCD_PAD_CTRL(PAD_CTL_HYS | PAD_CTL_PUS_PU100KOHM | \
+   PAD_CTL_DSE_3P3V_49OHM)
+
 #ifdef CONFIG_SYS_I2C_MXC
 #define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
 /* I2C1 for PMIC */
@@ -190,6 +193,63 @@ static void iox74lv_init(void)
gpio_direction_output(IOX_STCP, 1);
 };
 
+#ifdef CONFIG_VIDEO_MXS
+static iomux_v3_cfg_t const lcd_pads[] = {
+   MX7D_PAD_LCD_CLK__LCD_CLK | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX7D_PAD_LCD_ENABLE__LCD_ENABLE | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX7D_PAD_LCD_HSYNC__LCD_HSYNC | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX7D_PAD_LCD_VSYNC__LCD_VSYNC | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX7D_PAD_LCD_DATA00__LCD_DATA0 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX7D_PAD_LCD_DATA01__LCD_DATA1 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX7D_PAD_LCD_DATA02__LCD_DATA2 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX7D_PAD_LCD_DATA03__LCD_DATA3 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX7D_PAD_LCD_DATA04__LCD_DATA4 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX7D_PAD_LCD_DATA05__LCD_DATA5 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX7D_PAD_LCD_DATA06__LCD_DATA6 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX7D_PAD_LCD_DATA07__LCD_DATA7 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX7D_PAD_LCD_DATA08__LCD_DATA8 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX7D_PAD_LCD_DATA09__LCD_DATA9 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX7D_PAD_LCD_DATA10__LCD_DATA10 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX7D_PAD_LCD_DATA11__LCD_DATA11 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX7D_PAD_LCD_DATA12__LCD_DATA12 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX7D_PAD_LCD_DATA13__LCD_DATA13 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX7D_PAD_LCD_DATA14__LCD_DATA14 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX7D_PAD_LCD_DATA15__LCD_DATA15 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX7D_PAD_LCD_DATA16__LCD_DATA16 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX7D_PAD_LCD_DATA17__LCD_DATA17 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX7D_PAD_LCD_DATA18__LCD_DATA18 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX7D_PAD_LCD_DATA19__LCD_DATA19 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX7D_PAD_LCD_DATA20__LCD_DATA20 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX7D_PAD_LCD_DATA21__LCD_DATA21 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX7D_PAD_LCD_DATA22__LCD_DATA22 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX7D_PAD_LCD_DATA23__LCD_DATA23 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+
+   MX7D_PAD_LCD_RESET__GPIO3_IO4   | MUX_PAD_CTRL(LCD_PAD_CTRL),
+};
+
+static iomux_v3_cfg_t const pwm_pads[] = {
+   /* Use GPIO for Brightness adjustment, duty cycle = period */
+   MX7D_PAD_GPIO1_IO01__GPIO1_IO1 | MUX_PAD_CTRL(NO_PAD_CTRL),
+};
+
+static int setup_lcd(void)
+{
+   imx_iomux_v3_setup_multiple_pads(lcd_pads, ARRAY_SIZE(lcd_pads));
+
+   imx_iomux_v3_setup_multiple_pads(pwm_pads, ARRAY_SIZE(pwm_pads));
+
+   /* Reset LCD */
+   gpio_direction_output(IMX_GPIO_NR(3, 4) , 0);
+   udelay(500);
+   gpio_direction_output(IMX_GPIO_NR(3, 4) , 1);
+
+   /* Set Brightness to high */
+   gpio_direction_output(IMX_GPIO_NR(1, 1) , 1);
+
+   return 0;
+}
+#endif
+
 #ifdef CONFIG_FEC_MXC
 static iomux_v3_cfg_t const fec1_pads[] = {
MX7D_PAD_ENET1_RGMII_RX_CTL__ENET1_RGMII_RX_CTL | 
MUX_PAD_CTRL(ENET_RX_PAD_CTRL),
@@ -417,6 +477,10 @@ int board_init(void)
setup_fec();
 #endif
 
+#ifdef CONFIG_VIDEO_MXS
+   setup_lcd();
+#endif
+
return 0;
 }
 
diff --git a/include/configs/mx7dsabresd.h b/include/configs/mx7dsabresd.h
index f16f9c1..b412ffc 100644
--- a/include/configs/mx7dsabresd.h
+++ b/include/configs/mx7dsabresd.h
@@ -76,6 +76,7 @@
"fdt_addr=0x8300\0" \
"boot_fdt=try\0" \
"ip_dyn=yes\0" \
+   
"videomode=video=ctfb:x:480,y:272,depth:24,pclk:108695,le:8,ri:4,up:2,lo:4,hs:41,vs:10,sync:0,vmode:0\0"
 \
"mmcdev="__stringify(CONFIG_SYS_MMC_ENV_DEV)"\0" \
"mmcpart=" __stringify(CONFIG_SYS_MMC_IMG_LOAD_PART) "\0" \
"mmcroot=" CONFIG_MMCROOT " rootwait rw\0" \
@@ -188,4 +189,20 @@
 
 #define CONFIG_IMX_THERMAL
 
+#define CONFIG_VIDEO
+#ifdef CONFIG_VIDEO
+#define CONFIG_CFB_CONSOLE
+#define CONFIG_VIDEO_MXS
+#define CONFIG_VIDEO_LOGO
+#define 

Re: [U-Boot] [PATCH 00/11] imx: mx6: support lcdif

[Stefano Babic]

Hallo Peng,

On 20/10/2015 12:35, Peng Fan wrote:
> On Tue, Oct 20, 2015 at 05:19:19PM +0800, Peng Fan wrote:
>> Hi Stefano,
>>
>> On Fri, Oct 02, 2015 at 10:48:21AM +0200, Stefano Babic wrote:
>>> Hi Peng,
>>>
>>> I have not forgotten this series. Anyway, this has introduced aome
>>> changes that could brick other boards and it is my opininio to postpone
>>> it after 2015.10 release. Of course, I will send to you a full review
>>> for that.
>>
>> The patch set has been here for a long time. Since now 2015.10 released,
>> Can you please review this patch set?
> 
> Seems there are conflicts when merging with latest uboot. I'll prepare
> a new V2 patch set rebased on lastest uboot.
> 

Thanks - I will review V2, then

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] arm, powerpc: select SYS_GENERIC_BOARD

[Masahiro Yamada]

We have finished Generic Board conversion for ARM and PowerPC, i.e.
all the boards have been converted except OpenRISC, SuperH, SPARC,
which have not supported Generic Board framework yet.

Select SYS_GENERIC_BOARD in arch/Kconfig and delete all the macro
defines in include/configs/*.h.

Signed-off-by: Masahiro Yamada 
---

 arch/Kconfig   | 2 ++
 arch/arm/include/asm/arch-lpc32xx/config.h | 1 -
 include/configs/B4860QDS.h | 1 -
 include/configs/BSC9131RDB.h   | 1 -
 include/configs/BSC9132QDS.h   | 1 -
 include/configs/C29XPCIE.h | 1 -
 include/configs/CPCI2DP.h  | 1 -
 include/configs/CPCI4052.h | 1 -
 include/configs/MIP405.h   | 1 -
 include/configs/MPC8308RDB.h   | 1 -
 include/configs/MPC8313ERDB.h  | 1 -
 include/configs/MPC8315ERDB.h  | 1 -
 include/configs/MPC8323ERDB.h  | 1 -
 include/configs/MPC832XEMDS.h  | 1 -
 include/configs/MPC8349EMDS.h  | 1 -
 include/configs/MPC8349ITX.h   | 1 -
 include/configs/MPC837XEMDS.h  | 1 -
 include/configs/MPC837XERDB.h  | 1 -
 include/configs/MPC8536DS.h| 1 -
 include/configs/MPC8540ADS.h   | 1 -
 include/configs/MPC8541CDS.h   | 1 -
 include/configs/MPC8544DS.h| 1 -
 include/configs/MPC8548CDS.h   | 1 -
 include/configs/MPC8555CDS.h   | 1 -
 include/configs/MPC8560ADS.h   | 1 -
 include/configs/MPC8568MDS.h   | 1 -
 include/configs/MPC8569MDS.h   | 1 -
 include/configs/MPC8572DS.h| 1 -
 include/configs/MPC8610HPCD.h  | 1 -
 include/configs/MPC8641HPCN.h  | 1 -
 include/configs/P1010RDB.h | 1 -
 include/configs/P1022DS.h  | 1 -
 include/configs/P1023RDB.h | 1 -
 include/configs/P2041RDB.h | 1 -
 include/configs/PATI.h | 1 -
 include/configs/PIP405.h   | 1 -
 include/configs/PLU405.h   | 1 -
 include/configs/PMC405DE.h | 1 -
 include/configs/PMC440.h   | 1 -
 include/configs/T102xQDS.h | 1 -
 include/configs/T102xRDB.h | 1 -
 include/configs/T1040QDS.h | 1 -
 include/configs/T104xRDB.h | 1 -
 include/configs/T208xQDS.h | 1 -
 include/configs/T208xRDB.h | 1 -
 include/configs/T4240RDB.h | 1 -
 include/configs/TQM5200.h  | 1 -
 include/configs/TQM823L.h  | 1 -
 include/configs/TQM823M.h  | 1 -
 include/configs/TQM834x.h  | 1 -
 include/configs/TQM850L.h  | 1 -
 include/configs/TQM850M.h  | 1 -
 include/configs/TQM855L.h  | 1 -
 include/configs/TQM855M.h  | 1 -
 include/configs/TQM860L.h  | 1 -
 include/configs/TQM860M.h  | 1 -
 include/configs/TQM862L.h  | 1 -
 include/configs/TQM862M.h  | 1 -
 include/configs/TQM866M.h  | 1 -
 include/configs/TQM885D.h  | 1 -
 include/configs/UCP1020.h  | 1 -
 include/configs/VCMA9.h| 1 -
 include/configs/VOM405.h   | 1 -
 include/configs/a3m071.h   | 1 -
 include/configs/a4m072.h   | 1 -
 include/configs/ac14xx.h   | 1 -
 include/configs/am3517_crane.h | 1 -
 include/configs/am3517_evm.h   | 1 -
 include/configs/amcc-common.h  | 1 -
 include/configs/apf27.h| 1 -
 include/configs/aria.h | 1 -
 include/configs/armadillo-800eva.h | 1 -
 include/configs/aspenite.h | 5 -
 include/configs/at91-sama5_common.h| 1 -
 include/configs/at91rm9200ek.h | 1 -
 include/configs/at91sam9260ek.h| 1 -
 include/configs/at91sam9261ek.h| 1 -
 include/configs/at91sam9263ek.h| 1 -
 include/configs/at91sam9m10g45ek.h | 1 -
 include/configs/at91sam9n12ek.h| 1 -
 include/configs/at91sam9rlek.h | 1 -
 include/configs/at91sam9x5ek.h | 1 -
 include/configs/bcm28155_ap.h  | 1 -
 include/configs/bcm_ep_board.h | 1 -
 include/configs/bur_am335x_common.h| 1 -
 include/configs/calimain.h | 1 -
 include/configs/canmb.h| 1 -
 include/configs/cm5200.h   | 1 -
 include/configs/cm_t35.h   | 1 -
 include/configs/cm_t3517.h | 1 -
 include/configs/cm_t54.h   | 3 ---
 include/configs/colibri_pxa270.h   | 1 -
 include/configs/colibri_vf.h  

Re: [U-Boot] [PATCH v3] x86: Added support for Advantech SOM-6896

[George McCollister]

On Mon, Oct 19, 2015 at 9:02 PM, Bin Meng  wrote:
> Hi George,
>
> On Tue, Oct 20, 2015 at 1:46 AM, George McCollister
>  wrote:
>> Advantech SOM-6896 is a Broadwell U based COM Express Compact Module
>> Type 6. This patch adds support for it as a coreboot payload.
>>
>> On board SATA and SPI are functional. On board Ethernet isn't functional
>> but since it's optional and ties up a PCIe x4 that is otherwise brought
>> out, this isn't a concern at the moment. USB doesn't work since the
>> xHCI driver appears to be broken.
>>
>> Signed-off-by: George McCollister 
>> ---
>> Changes for V2:
>>  Changed pci's compatible string to "pci-x86"
>>  Changed I/O from base of 0x1000 to base of 0x1900
>>  Changed spi-flash memory-map
>> Changes for V3:
>>  Renamed som-6896.dts to broadwell_som-6896.dts
>>  Changed PCI I/O start from 0x1900 to 0x2000
>>
>>  arch/x86/dts/Makefile   |  3 ++-
>>  arch/x86/dts/broadwell_som-6896.dts | 43 
>> +
>>  include/configs/som-6896.h  | 38 
>>  3 files changed, 83 insertions(+), 1 deletion(-)
>>  create mode 100644 arch/x86/dts/broadwell_som-6896.dts
>>  create mode 100644 include/configs/som-6896.h
>>
>> diff --git a/arch/x86/dts/Makefile b/arch/x86/dts/Makefile
>> index 71595c7..83a2b8c 100644
>> --- a/arch/x86/dts/Makefile
>> +++ b/arch/x86/dts/Makefile
>> @@ -6,7 +6,8 @@ dtb-y += bayleybay.dtb \
>> galileo.dtb \
>> minnowmax.dtb \
>> qemu-x86_i440fx.dtb \
>> -   qemu-x86_q35.dtb
>> +   qemu-x86_q35.dtb \
>> +   broadwell_som-6896.dtb
>>
>>  targets += $(dtb-y)
>>
>> diff --git a/arch/x86/dts/broadwell_som-6896.dts 
>> b/arch/x86/dts/broadwell_som-6896.dts
>> new file mode 100644
>> index 000..4ca8208
>> --- /dev/null
>> +++ b/arch/x86/dts/broadwell_som-6896.dts
>> @@ -0,0 +1,43 @@
>> +/dts-v1/;
>> +
>> +/include/ "skeleton.dtsi"
>> +/include/ "serial.dtsi"
>> +/include/ "rtc.dtsi"
>> +
>> +/ {
>> +   model = "Advantech SOM-6896";
>> +   compatible = "advantech,som-6896", "intel,broadwell";
>> +
>> +   aliases {
>> +   spi0 = "/spi";
>> +   };
>> +
>> +   config {
>> +  silent_console = <0>;
>> +   };
>> +
>> +   chosen {
>> +   stdout-path = "/serial";
>> +   };
>> +
>> +   pci {
>> +   compatible = "pci-x86";
>> +   #address-cells = <3>;
>> +   #size-cells = <2>;
>> +   u-boot,dm-pre-reloc;
>> +   ranges = <0x0200 0x0 0xe000 0xe000 0 0x1000
>> +   0x4200 0x0 0xd000 0xd000 0 0x1000
>> +   0x0100 0x0 0x1900 0x1900 0 0xe700>;
>
> The change log for v3 says "hanged PCI I/O start from 0x1900 to
> 0x2000", but it is still 0x1900 here?
>
Ugh, had the hunk staged but neglected to commit --amend it. I'm
really sorry about that, I was trying to do too much at once
yesterday.
>> +   };
>> +
>> +   spi {
>> +   #address-cells = <1>;
>> +   #size-cells = <0>;
>> +   compatible = "intel,ich-spi";
>> +   spi-flash@0 {
>> +   reg = <0>;
>> +   compatible = "winbond,w25q128", "spi-flash";
>> +   memory-map = <0xff00 0x0100>;
>> +   };
>> +   };
>> +};
>> diff --git a/include/configs/som-6896.h b/include/configs/som-6896.h
>> new file mode 100644
>> index 000..518bf11
>> --- /dev/null
>> +++ b/include/configs/som-6896.h
>> @@ -0,0 +1,38 @@
>> +/*
>> + * Configuration settings for the SOM-6896
>> + *
>> + * Copyright (C) 2015 NovaTech LLC
>> + *   George McCollister 
>
> Nits: please remove the additional spaces before the email.
Will do.
>
>> + *
>> + * SPDX-License-Identifier:GPL-2.0+
>> + */
>> +
>> +#ifndef __CONFIG_H
>> +#define __CONFIG_H
>> +
>> +#include 
>> +
>> +#define CONFIG_SYS_MONITOR_LEN (1 << 20)
>> +
>> +#define CONFIG_BOARD_EARLY_INIT_F
>> +#define CONFIG_MISC_INIT_R
>> +
>> +#define CONFIG_SCSI_DEV_LIST   \
>> +   {PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_WILDCATPOINT_AHCI}
>> +
>> +#define CONFIG_SYS_EARLY_PCI_INIT
>> +#define CONFIG_PCI_PNP
>> +
>> +#define VIDEO_IO_OFFSET0
>> +#define CONFIG_X86EMU_RAW_IO
>> +
>> +#define CONFIG_ARCH_EARLY_INIT_R
>> +
>> +#define CONFIG_STD_DEVICES_SETTINGS "stdin=serial,vga,usbkbd\0" \
>> +   "stdout=serial,vga\0" \
>> +   "stderr=serial,vga\0"
>> +
>> +#define CONFIG_ENV_SECT_SIZE   0x1000
>> +#define CONFIG_ENV_OFFSET  0x00ff
>> +
>> +#endif /* __CONFIG_H */
>> --
>
> Regards,
> Bin

Thanks and sorry for the screw up,
George
___
U-Boot mailing list

[U-Boot] [PATCH V2 10/14] imx: mx6: implement reset_misc

[Peng Fan]

We need to power down lcdif before uboot reset to make reset can pass
stress test. Or system may hang.

Signed-off-by: Peng Fan 
Cc: Stefano Babic 
---

V2:
 none

 arch/arm/cpu/armv7/mx6/soc.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
index 282302b..5505821 100644
--- a/arch/arm/cpu/armv7/mx6/soc.c
+++ b/arch/arm/cpu/armv7/mx6/soc.c
@@ -392,6 +392,14 @@ const struct boot_mode soc_boot_modes[] = {
{NULL,  0},
 };
 
+void reset_misc(void)
+{
+#ifdef CONFIG_VIDEO_MXS
+   if (is_cpu_type(MXC_CPU_MX6UL))
+   lcdif_power_down();
+#endif
+}
+
 void s_init(void)
 {
struct anatop_regs *anatop = (struct anatop_regs *)ANATOP_BASE_ADDR;
-- 
1.8.4


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

[U-Boot] [PATCH V2 08/14] imx: mx6ul_14x14_evk: support lcdif display

[Peng Fan]

Support lcdif display:
1. Add pinmux and pad settings for LCDIF
2. Introduce setup_lcd to do the settings for LCDIF
3. Enable VIDEO related macros in board header files
4. Add a new env videomode which is needed by mxsfb.c. The
   settings for videomode in this patch is for TFT43AB.
5. Tested on mx6ul 14x14/9x9 evk.

Signed-off-by: Peng Fan 
Cc: Stefano Babic 
---

V2:
 Rebased to Latest U-Boot, resolve conflicts.

 board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c | 63 +++
 include/configs/mx6ul_14x14_evk.h | 18 +++
 2 files changed, 81 insertions(+)

diff --git a/board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c 
b/board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c
index 8650f35..287a421 100644
--- a/board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c
+++ b/board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c
@@ -52,6 +52,9 @@ DECLARE_GLOBAL_DATA_PTR;
PAD_CTL_SPEED_HIGH   |  \
PAD_CTL_DSE_48ohm   | PAD_CTL_SRE_FAST)
 
+#define LCD_PAD_CTRL(PAD_CTL_HYS | PAD_CTL_PUS_100K_UP | PAD_CTL_PUE | \
+   PAD_CTL_PKE | PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm)
+
 #define MDIO_PAD_CTRL  (PAD_CTL_PUS_100K_UP | PAD_CTL_PUE | \
PAD_CTL_DSE_48ohm   | PAD_CTL_SRE_FAST | PAD_CTL_ODE)
 
@@ -568,6 +571,62 @@ int board_phy_config(struct phy_device *phydev)
 }
 #endif
 
+#ifdef CONFIG_VIDEO_MXS
+static iomux_v3_cfg_t const lcd_pads[] = {
+   MX6_PAD_LCD_CLK__LCDIF_CLK | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX6_PAD_LCD_ENABLE__LCDIF_ENABLE | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX6_PAD_LCD_HSYNC__LCDIF_HSYNC | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX6_PAD_LCD_VSYNC__LCDIF_VSYNC | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX6_PAD_LCD_DATA00__LCDIF_DATA00 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX6_PAD_LCD_DATA01__LCDIF_DATA01 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX6_PAD_LCD_DATA02__LCDIF_DATA02 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX6_PAD_LCD_DATA03__LCDIF_DATA03 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX6_PAD_LCD_DATA04__LCDIF_DATA04 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX6_PAD_LCD_DATA05__LCDIF_DATA05 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX6_PAD_LCD_DATA06__LCDIF_DATA06 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX6_PAD_LCD_DATA07__LCDIF_DATA07 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX6_PAD_LCD_DATA08__LCDIF_DATA08 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX6_PAD_LCD_DATA09__LCDIF_DATA09 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX6_PAD_LCD_DATA10__LCDIF_DATA10 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX6_PAD_LCD_DATA11__LCDIF_DATA11 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX6_PAD_LCD_DATA12__LCDIF_DATA12 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX6_PAD_LCD_DATA13__LCDIF_DATA13 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX6_PAD_LCD_DATA14__LCDIF_DATA14 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX6_PAD_LCD_DATA15__LCDIF_DATA15 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX6_PAD_LCD_DATA16__LCDIF_DATA16 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX6_PAD_LCD_DATA17__LCDIF_DATA17 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX6_PAD_LCD_DATA18__LCDIF_DATA18 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX6_PAD_LCD_DATA19__LCDIF_DATA19 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX6_PAD_LCD_DATA20__LCDIF_DATA20 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX6_PAD_LCD_DATA21__LCDIF_DATA21 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX6_PAD_LCD_DATA22__LCDIF_DATA22 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+   MX6_PAD_LCD_DATA23__LCDIF_DATA23 | MUX_PAD_CTRL(LCD_PAD_CTRL),
+
+   /* LCD_RST */
+   MX6_PAD_SNVS_TAMPER9__GPIO5_IO09 | MUX_PAD_CTRL(NO_PAD_CTRL),
+
+   /* Use GPIO for Brightness adjustment, duty cycle = period. */
+   MX6_PAD_GPIO1_IO08__GPIO1_IO08 | MUX_PAD_CTRL(NO_PAD_CTRL),
+};
+
+static int setup_lcd(void)
+{
+   enable_lcdif_clock(0);
+
+   imx_iomux_v3_setup_multiple_pads(lcd_pads, ARRAY_SIZE(lcd_pads));
+
+   /* Reset the LCD */
+   gpio_direction_output(IMX_GPIO_NR(5, 9) , 0);
+   udelay(500);
+   gpio_direction_output(IMX_GPIO_NR(5, 9) , 1);
+
+   /* Set Brightness to high */
+   gpio_direction_output(IMX_GPIO_NR(1, 8) , 1);
+
+   return 0;
+}
+#endif
+
 int board_early_init_f(void)
 {
setup_iomux_uart();
@@ -600,6 +659,10 @@ int board_init(void)
board_qspi_init();
 #endif
 
+#ifdef CONFIG_VIDEO_MXS
+   setup_lcd();
+#endif
+
return 0;
 }
 
diff --git a/include/configs/mx6ul_14x14_evk.h 
b/include/configs/mx6ul_14x14_evk.h
index d5faae6..5779632 100644
--- a/include/configs/mx6ul_14x14_evk.h
+++ b/include/configs/mx6ul_14x14_evk.h
@@ -77,6 +77,7 @@
"fdt_addr=0x8300\0" \
"boot_fdt=try\0" \
"ip_dyn=yes\0" \
+   
"videomode=video=ctfb:x:480,y:272,depth:24,pclk:108695,le:8,ri:4,up:2,lo:4,hs:41,vs:10,sync:0,vmode:0\0"
 \
"mmcdev="__stringify(CONFIG_SYS_MMC_ENV_DEV)"\0" \
"mmcpart=" __stringify(CONFIG_SYS_MMC_IMG_LOAD_PART) "\0" \
"mmcroot=" CONFIG_MMCROOT " rootwait rw\0" \
@@ -242,4 +243,21 @@
 
 #define CONFIG_IMX_THERMAL
 
+#define 

[U-Boot] [PATCH V2 04/14] imx: imx-common: move lcdif structure and macro definition to imx-common

[Peng Fan]

Move 'struct mxs_lcdif_regs' and lcdif related macro definitions to
arch/arm/include/asm/imx-common/regs-lcdif.h.

i.MX6SX/UL/28 have similar register layout and bit definitions of registers.

Signed-off-by: Peng Fan 
Cc: Stefano Babic 
---

V2:
 none

 arch/arm/include/asm/arch-mxs/regs-lcdif.h   | 201 +---
 arch/arm/include/asm/imx-common/regs-lcdif.h | 222 +++
 2 files changed, 223 insertions(+), 200 deletions(-)
 create mode 100644 arch/arm/include/asm/imx-common/regs-lcdif.h

diff --git a/arch/arm/include/asm/arch-mxs/regs-lcdif.h 
b/arch/arm/include/asm/arch-mxs/regs-lcdif.h
index 8915d84..bee1f9a 100644
--- a/arch/arm/include/asm/arch-mxs/regs-lcdif.h
+++ b/arch/arm/include/asm/arch-mxs/regs-lcdif.h
@@ -13,205 +13,6 @@
 #ifndef __MX28_REGS_LCDIF_H__
 #define __MX28_REGS_LCDIF_H__
 
-#include 
-
-#ifndef__ASSEMBLY__
-struct mxs_lcdif_regs {
-   mxs_reg_32(hw_lcdif_ctrl)   /* 0x00 */
-   mxs_reg_32(hw_lcdif_ctrl1)  /* 0x10 */
-#if defined(CONFIG_MX28)
-   mxs_reg_32(hw_lcdif_ctrl2)  /* 0x20 */
-#endif
-   mxs_reg_32(hw_lcdif_transfer_count) /* 0x20/0x30 */
-   mxs_reg_32(hw_lcdif_cur_buf)/* 0x30/0x40 */
-   mxs_reg_32(hw_lcdif_next_buf)   /* 0x40/0x50 */
-
-#if defined(CONFIG_MX23)
-   uint32_treserved1[4];
-#endif
-
-   mxs_reg_32(hw_lcdif_timing) /* 0x60 */
-   mxs_reg_32(hw_lcdif_vdctrl0)/* 0x70 */
-   mxs_reg_32(hw_lcdif_vdctrl1)/* 0x80 */
-   mxs_reg_32(hw_lcdif_vdctrl2)/* 0x90 */
-   mxs_reg_32(hw_lcdif_vdctrl3)/* 0xa0 */
-   mxs_reg_32(hw_lcdif_vdctrl4)/* 0xb0 */
-   mxs_reg_32(hw_lcdif_dvictrl0)   /* 0xc0 */
-   mxs_reg_32(hw_lcdif_dvictrl1)   /* 0xd0 */
-   mxs_reg_32(hw_lcdif_dvictrl2)   /* 0xe0 */
-   mxs_reg_32(hw_lcdif_dvictrl3)   /* 0xf0 */
-   mxs_reg_32(hw_lcdif_dvictrl4)   /* 0x100 */
-   mxs_reg_32(hw_lcdif_csc_coeffctrl0) /* 0x110 */
-   mxs_reg_32(hw_lcdif_csc_coeffctrl1) /* 0x120 */
-   mxs_reg_32(hw_lcdif_csc_coeffctrl2) /* 0x130 */
-   mxs_reg_32(hw_lcdif_csc_coeffctrl3) /* 0x140 */
-   mxs_reg_32(hw_lcdif_csc_coeffctrl4) /* 0x150 */
-   mxs_reg_32(hw_lcdif_csc_offset) /* 0x160 */
-   mxs_reg_32(hw_lcdif_csc_limit)  /* 0x170 */
-
-#if defined(CONFIG_MX23)
-   uint32_treserved2[12];
-#endif
-   mxs_reg_32(hw_lcdif_data)   /* 0x1b0/0x180 */
-   mxs_reg_32(hw_lcdif_bm_error_stat)  /* 0x1c0/0x190 */
-#if defined(CONFIG_MX28)
-   mxs_reg_32(hw_lcdif_crc_stat)   /* 0x1a0 */
-#endif
-   mxs_reg_32(hw_lcdif_lcdif_stat) /* 0x1d0/0x1b0 */
-   mxs_reg_32(hw_lcdif_version)/* 0x1e0/0x1c0 */
-   mxs_reg_32(hw_lcdif_debug0) /* 0x1f0/0x1d0 */
-   mxs_reg_32(hw_lcdif_debug1) /* 0x200/0x1e0 */
-   mxs_reg_32(hw_lcdif_debug2) /* 0x1f0 */
-};
-#endif
-
-#defineLCDIF_CTRL_SFTRST   (1 << 
31)
-#defineLCDIF_CTRL_CLKGATE  (1 << 
30)
-#defineLCDIF_CTRL_YCBCR422_INPUT   (1 << 
29)
-#defineLCDIF_CTRL_READ_WRITEB  (1 << 
28)
-#defineLCDIF_CTRL_WAIT_FOR_VSYNC_EDGE  (1 << 
27)
-#defineLCDIF_CTRL_DATA_SHIFT_DIR   (1 << 
26)
-#defineLCDIF_CTRL_SHIFT_NUM_BITS_MASK  (0x1f 
<< 21)
-#defineLCDIF_CTRL_SHIFT_NUM_BITS_OFFSET21
-#defineLCDIF_CTRL_DVI_MODE (1 << 
20)
-#defineLCDIF_CTRL_BYPASS_COUNT (1 << 
19)
-#defineLCDIF_CTRL_VSYNC_MODE   (1 << 
18)
-#defineLCDIF_CTRL_DOTCLK_MODE  (1 << 
17)
-#defineLCDIF_CTRL_DATA_SELECT  (1 << 
16)
-#defineLCDIF_CTRL_INPUT_DATA_SWIZZLE_MASK  (0x3 << 
14)
-#defineLCDIF_CTRL_INPUT_DATA_SWIZZLE_OFFSET14
-#defineLCDIF_CTRL_CSC_DATA_SWIZZLE_MASK(0x3 << 
12)
-#defineLCDIF_CTRL_CSC_DATA_SWIZZLE_OFFSET  12
-#defineLCDIF_CTRL_LCD_DATABUS_WIDTH_MASK   (0x3 << 
10)
-#defineLCDIF_CTRL_LCD_DATABUS_WIDTH_OFFSET 10
-#defineLCDIF_CTRL_LCD_DATABUS_WIDTH_16BIT  (0 << 
10)
-#defineLCDIF_CTRL_LCD_DATABUS_WIDTH_8BIT   (1 << 
10)
-#defineLCDIF_CTRL_LCD_DATABUS_WIDTH_18BIT  (2 << 
10)
-#defineLCDIF_CTRL_LCD_DATABUS_WIDTH_24BIT   

[U-Boot] [PATCH V2 06/14] imx: mx6: crm_reg: add LCDIF related macros

[Peng Fan]

Add i.MX6UL/SX LCDIF related macros. Discard uneccessary
'#ifdef xxx'.

Signed-off-by: Peng Fan 
Cc: Stefano Babic 
---

V2:
 none

 arch/arm/include/asm/arch-mx6/crm_regs.h | 34 
 1 file changed, 30 insertions(+), 4 deletions(-)

diff --git a/arch/arm/include/asm/arch-mx6/crm_regs.h 
b/arch/arm/include/asm/arch-mx6/crm_regs.h
index 10306cd..13e0a3d 100644
--- a/arch/arm/include/asm/arch-mx6/crm_regs.h
+++ b/arch/arm/include/asm/arch-mx6/crm_regs.h
@@ -174,6 +174,9 @@ struct mxc_ccm_reg {
 #define MXC_CCM_CBCMR_GPU3D_SHADER_PODF_OFFSET 29
 #define MXC_CCM_CBCMR_GPU3D_CORE_PODF_MASK (0x7 << 26)
 #define MXC_CCM_CBCMR_GPU3D_CORE_PODF_OFFSET   26
+/* LCDIF on i.MX6SX/UL */
+#define MXC_CCM_CBCMR_LCDIF1_PODF_MASK  (0x7 << 23)
+#define MXC_CCM_CBCMR_LCDIF1_PODF_OFFSET23
 #define MXC_CCM_CBCMR_GPU2D_CORE_PODF_MASK (0x7 << 23)
 #define MXC_CCM_CBCMR_GPU2D_CORE_PODF_OFFSET   23
 #define MXC_CCM_CBCMR_PRE_PERIPH2_CLK_SEL_MASK (0x3 << 21)
@@ -210,7 +213,10 @@ struct mxc_ccm_reg {
 #define MXC_CCM_CSCMR1_ACLK_EMI_OFFSET 27
 #define MXC_CCM_CSCMR1_ACLK_EMI_SLOW_PODF_MASK (0x7 << 23)
 #define MXC_CCM_CSCMR1_ACLK_EMI_SLOW_PODF_OFFSET   23
-/* ACLK_EMI_PODF is LCFIF2_PODF on MX6SX */
+/* LCFIF2_PODF on i.MX6SX */
+#define MXC_CCM_CSCMR1_LCDIF2_PODF_MASK(0x7 << 20)
+#define MXC_CCM_CSCMR1_LCDIF2_PODF_OFFSET   20
+/* ACLK_EMI on i.MX6DQ/SDL/DQP */
 #define MXC_CCM_CSCMR1_ACLK_EMI_PODF_MASK  (0x7 << 20)
 #define MXC_CCM_CSCMR1_ACLK_EMI_PODF_OFFSET20
 /* CSCMR1_GPMI/BCH exist on i.MX6UL */
@@ -400,6 +406,20 @@ struct mxc_ccm_reg {
 #define MXC_CCM_CSCDR2_ECSPI_CLK_PODF_OFFSET   19
 /* ECSPI_CLK_SEL exists on i.MX6SX/SL/QP */
 #define MXC_CCM_CSCDR2_ECSPI_CLK_SEL_MASK  (0x1 << 18)
+/* LCDIF1 on i.MX6SX/UL */
+#define MXC_CCM_CSCDR2_LCDIF1_PRED_SEL_MASK (0x7 << 15)
+#define MXC_CCM_CSCDR2_LCDIF1_PRED_SEL_OFFSET   15
+#define MXC_CCM_CSCDR2_LCDIF1_PRE_DIV_MASK  (0x7 << 12)
+#define MXC_CCM_CSCDR2_LCDIF1_PRE_DIV_OFFSET12
+#define MXC_CCM_CSCDR2_LCDIF1_CLK_SEL_MASK  (0x7 << 9)
+#define MXC_CCM_CSCDR2_LCDIF1_CLK_SEL_OFFSET9
+/* LCDIF2 on i.MX6SX */
+#define MXC_CCM_CSCDR2_LCDIF2_PRED_SEL_MASK (0x7 << 6)
+#define MXC_CCM_CSCDR2_LCDIF2_PRED_SEL_OFFSET   6
+#define MXC_CCM_CSCDR2_LCDIF2_PRE_DIV_MASK  (0x7 << 3)
+#define MXC_CCM_CSCDR2_LCDIF2_PRE_DIV_OFFSET3
+#define MXC_CCM_CSCDR2_LCDIF2_CLK_SEL_MASK  (0x7 << 0)
+#define MXC_CCM_CSCDR2_LCDIF2_CLK_SEL_OFFSET 0
 
 /* All IPU2_DI1 are LCDIF1 on MX6SX */
 #define MXC_CCM_CHSCCDR_IPU2_DI1_PRE_CLK_SEL_MASK  (0x7 << 15)
@@ -622,17 +642,16 @@ struct mxc_ccm_reg {
 #define MXC_CCM_CCGR2_IPMUX3_MASK  (3 << 
MXC_CCM_CCGR2_IPMUX3_OFFSET)
 #define MXC_CCM_CCGR2_IPSYNC_IP2APB_TZASC1_IPGS_OFFSET 22
 #define MXC_CCM_CCGR2_IPSYNC_IP2APB_TZASC1_IPGS_MASK   (3 << 
MXC_CCM_CCGR2_IPSYNC_IP2APB_TZASC1_IPGS_OFFSET)
-#ifdef CONFIG_MX6SX
+/* i.MX6SX/UL LCD and PXP */
 #define MXC_CCM_CCGR2_LCD_OFFSET   28
 #define MXC_CCM_CCGR2_LCD_MASK (3 << 
MXC_CCM_CCGR2_LCD_OFFSET)
 #define MXC_CCM_CCGR2_PXP_OFFSET   30
 #define MXC_CCM_CCGR2_PXP_MASK (3 << 
MXC_CCM_CCGR2_PXP_OFFSET)
-#else
+
 #define MXC_CCM_CCGR2_IPSYNC_IP2APB_TZASC2_IPG_OFFSET  24
 #define MXC_CCM_CCGR2_IPSYNC_IP2APB_TZASC2_IPG_MASK(3 << 
MXC_CCM_CCGR2_IPSYNC_IP2APB_TZASC2_IPG_OFFSET)
 #define MXC_CCM_CCGR2_IPSYNC_VDOA_IPG_MASTER_CLK_OFFSET26
 #define MXC_CCM_CCGR2_IPSYNC_VDOA_IPG_MASTER_CLK_MASK  (3 << 
MXC_CCM_CCGR2_IPSYNC_VDOA_IPG_MASTER_CLK_OFFSET)
-#endif
 
 /* Exist on i.MX6SX */
 #define MXC_CCM_CCGR3_M4_OFFSET2
@@ -685,6 +704,13 @@ struct mxc_ccm_reg {
 #define MXC_CCM_CCGR3_MMDC_CORE_IPG_CLK_P0_MASK(3 << 
MXC_CCM_CCGR3_MMDC_CORE_IPG_CLK_P0_OFFSET)
 #define MXC_CCM_CCGR3_MMDC_CORE_IPG_CLK_P1_OFFSET  26
 #define MXC_CCM_CCGR3_MMDC_CORE_IPG_CLK_P1_MASK(3 << 
MXC_CCM_CCGR3_MMDC_CORE_IPG_CLK_P1_OFFSET)
+
+#define MXC_CCM_CCGR3_DISP_AXI_OFFSET   6
+#define MXC_CCM_CCGR3_DISP_AXI_MASK (3 << 
MXC_CCM_CCGR3_DISP_AXI_OFFSET)
+#define MXC_CCM_CCGR3_LCDIF2_PIX_OFFSET 8
+#define MXC_CCM_CCGR3_LCDIF2_PIX_MASK   (3 << 
MXC_CCM_CCGR3_LCDIF2_PIX_OFFSET)
+#define MXC_CCM_CCGR3_LCDIF1_PIX_OFFSET 10
+#define MXC_CCM_CCGR3_LCDIF1_PIX_MASK   (3 << 
MXC_CCM_CCGR3_LCDIF1_PIX_OFFSET)
 /* AXI on i.MX6UL */
 #define MXC_CCM_CCGR3_AXI_CLK_OFFSET   28
 #define 

[U-Boot] [PATCH V2 07/14] imx: mx6: add clock api for lcdif

[Peng Fan]

Implement mxs_set_lcdclk, enable_lcdif_clock and enable_pll_video.
The three API can be used to configure lcdif related clock when
CONFIG_VIDEO_MXS enabled.

Signed-off-by: Peng Fan 
Cc: Stefano Babic 
---

V2:
 none

 arch/arm/cpu/armv7/mx6/clock.c| 239 ++
 arch/arm/include/asm/arch-mx6/clock.h |   2 +
 2 files changed, 241 insertions(+)

diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c
index 11efd12..8a88378 100644
--- a/arch/arm/cpu/armv7/mx6/clock.c
+++ b/arch/arm/cpu/armv7/mx6/clock.c
@@ -473,6 +473,245 @@ static u32 get_mmdc_ch0_clk(void)
}
 }
 
+#if defined(CONFIG_VIDEO_MXS)
+static int enable_pll_video(u32 pll_div, u32 pll_num, u32 pll_denom,
+   u32 post_div)
+{
+   u32 reg = 0;
+   ulong start;
+
+   debug("pll5 div = %d, num = %d, denom = %d\n",
+ pll_div, pll_num, pll_denom);
+
+   /* Power up PLL5 video */
+   writel(BM_ANADIG_PLL_VIDEO_POWERDOWN |
+  BM_ANADIG_PLL_VIDEO_BYPASS |
+  BM_ANADIG_PLL_VIDEO_DIV_SELECT |
+  BM_ANADIG_PLL_VIDEO_POST_DIV_SELECT,
+  _ccm->analog_pll_video_clr);
+
+   /* Set div, num and denom */
+   switch (post_div) {
+   case 1:
+   writel(BF_ANADIG_PLL_VIDEO_DIV_SELECT(pll_div) |
+  BF_ANADIG_PLL_VIDEO_POST_DIV_SELECT(0x2),
+  _ccm->analog_pll_video_set);
+   break;
+   case 2:
+   writel(BF_ANADIG_PLL_VIDEO_DIV_SELECT(pll_div) |
+  BF_ANADIG_PLL_VIDEO_POST_DIV_SELECT(0x1),
+  _ccm->analog_pll_video_set);
+   break;
+   case 4:
+   writel(BF_ANADIG_PLL_VIDEO_DIV_SELECT(pll_div) |
+  BF_ANADIG_PLL_VIDEO_POST_DIV_SELECT(0x0),
+  _ccm->analog_pll_video_set);
+   break;
+   default:
+   puts("Wrong test_div!\n");
+   return -EINVAL;
+   }
+
+   writel(BF_ANADIG_PLL_VIDEO_NUM_A(pll_num),
+  _ccm->analog_pll_video_num);
+   writel(BF_ANADIG_PLL_VIDEO_DENOM_B(pll_denom),
+  _ccm->analog_pll_video_denom);
+
+   /* Wait PLL5 lock */
+   start = get_timer(0);   /* Get current timestamp */
+
+   do {
+   reg = readl(_ccm->analog_pll_video);
+   if (reg & BM_ANADIG_PLL_VIDEO_LOCK) {
+   /* Enable PLL out */
+   writel(BM_ANADIG_PLL_VIDEO_ENABLE,
+  _ccm->analog_pll_video_set);
+   return 0;
+   }
+   } while (get_timer(0) < (start + 10)); /* Wait 10ms */
+
+   printf("Lock PLL5 timeout\n");
+
+   return -ETIME;
+}
+
+/*
+ * 24M--> PLL_VIDEO -> LCDIFx_PRED -> LCDIFx_PODF -> LCD
+ *
+ * 'freq' using KHz as unit, see driver/video/mxsfb.c.
+ */
+void mxs_set_lcdclk(u32 base_addr, u32 freq)
+{
+   u32 reg = 0;
+   u32 hck = MXC_HCLK / 1000;
+   /* DIV_SELECT ranges from 27 to 54 */
+   u32 min = hck * 27;
+   u32 max = hck * 54;
+   u32 temp, best = 0;
+   u32 i, j, max_pred = 8, max_postd = 8, pred = 1, postd = 1;
+   u32 pll_div, pll_num, pll_denom, post_div = 1;
+
+   debug("mxs_set_lcdclk, freq = %dKHz\n", freq);
+
+   if ((!is_cpu_type(MXC_CPU_MX6SX)) && !is_cpu_type(MXC_CPU_MX6UL))
+   return;
+
+   if (base_addr == LCDIF1_BASE_ADDR) {
+   reg = readl(_ccm->cscdr2);
+   /* Can't change clocks when clock not from pre-mux */
+   if ((reg & MXC_CCM_CSCDR2_LCDIF1_CLK_SEL_MASK) != 0)
+   return;
+   }
+
+   if (is_cpu_type(MXC_CPU_MX6SX)) {
+   reg = readl(_ccm->cscdr2);
+   /* Can't change clocks when clock not from pre-mux */
+   if ((reg & MXC_CCM_CSCDR2_LCDIF2_CLK_SEL_MASK) != 0)
+   return;
+   }
+
+   temp = freq * max_pred * max_postd;
+   if (temp > max) {
+   puts("Please decrease freq, too large!\n");
+   return;
+   }
+   if (temp < min) {
+   /*
+* Register: PLL_VIDEO
+* Bit Field: POST_DIV_SELECT
+* 00 ??? Divide by 4.
+* 01 ??? Divide by 2.
+* 10 ??? Divide by 1.
+* 11 ??? Reserved
+* No need to check post_div(1)
+*/
+   for (post_div = 2; post_div <= 4; post_div <<= 1) {
+   if ((temp * post_div) > min) {
+   freq *= post_div;
+   break;
+   }
+   }
+
+   if (post_div > 4) {
+   printf("Fail to set rate to %dkhz", freq);
+   return;
+   }
+   }
+
+   /* Choose the best pred and postd to match 

[U-Boot] [PATCH V2 11/14] imx: imx-common: power down lcdif before boot os

[Peng Fan]

Need to call lcdif_power_down to make lcdif in initial state
before kernel boot. Similar issue for uboot reset with lcdif
enabled, system will hang after serveral times resetting. Need
to let lcdif initial state to make all go well.

Signed-off-by: Peng Fan 
Cc: Stefano Babic 
Cc: Eric Nelson 
Cc: Nikita Kiryanov 
Cc: Tim Harvey 
Cc: Fabio Estevam 
---

V2:
 none

 arch/arm/imx-common/cpu.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/imx-common/cpu.c b/arch/arm/imx-common/cpu.c
index d3d1fc5..656bb60 100644
--- a/arch/arm/imx-common/cpu.c
+++ b/arch/arm/imx-common/cpu.c
@@ -279,6 +279,9 @@ void arch_preboot_os(void)
/* disable video before launching O/S */
ipuv3_fb_shutdown();
 #endif
+#if defined(CONFIG_VIDEO_MXS)
+   lcdif_power_down();
+#endif
 }
 
 void set_chipselect_size(int const cs_size)
-- 
1.8.4


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

[U-Boot] [PATCH V2 05/14] imx: mx6: fix register address

[Peng Fan]

1. Move WDOG3_BASE_ADDR to '#if !(defined(__ASSEMBLY__))'.
2. Add i.MX6UL LCDIF register base address. And Introduce
   LCDIF1_BASE_ADDR to support runtime check.
3. include  for imx-regs.h to avoid
   building error for mxsfb.c, since mxsfb.c use imx-regs.h.

Signed-off-by: Peng Fan 
Cc: Stefano Babic 
---

V2:
 none

 arch/arm/include/asm/arch-mx6/imx-regs.h | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/arch/arm/include/asm/arch-mx6/imx-regs.h 
b/arch/arm/include/asm/arch-mx6/imx-regs.h
index 74512ac..ec0fa8f 100644
--- a/arch/arm/include/asm/arch-mx6/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx6/imx-regs.h
@@ -264,6 +264,7 @@
 #define CSU_BASE_ADDR   (AIPS2_OFF_BASE_ADDR + 0x4)
 #define IP2APB_PERFMON1_BASE_ADDR   (AIPS2_OFF_BASE_ADDR + 0x44000)
 #define IP2APB_PERFMON2_BASE_ADDR   (AIPS2_OFF_BASE_ADDR + 0x48000)
+#define MX6UL_LCDIF1_BASE_ADDR  (AIPS2_OFF_BASE_ADDR + 0x48000)
 #ifdef CONFIG_MX6SX
 #define DEBUG_MONITOR_BASE_ADDR (AIPS2_OFF_BASE_ADDR + 0x4C000)
 #else
@@ -300,7 +301,6 @@
 #define CSI1_BASE_ADDR  (AIPS3_ARB_BASE_ADDR + 0x14000)
 #define PXP_BASE_ADDR   (AIPS3_ARB_BASE_ADDR + 0x18000)
 #define CSI2_BASE_ADDR  (AIPS3_ARB_BASE_ADDR + 0x1C000)
-#define LCDIF1_BASE_ADDR(AIPS3_ARB_BASE_ADDR + 0x2)
 #define LCDIF2_BASE_ADDR(AIPS3_ARB_BASE_ADDR + 0x24000)
 #define VADC_BASE_ADDR  (AIPS3_ARB_BASE_ADDR + 0x28000)
 #define VDEC_BASE_ADDR  (AIPS3_ARB_BASE_ADDR + 0x2C000)
@@ -319,12 +319,9 @@
 #define PWM7_BASE_ADDR  (AIPS3_ARB_BASE_ADDR + 0xAC000)
 #define PWM8_BASE_ADDR  (AIPS3_ARB_BASE_ADDR + 0xB)
 #endif
+#define MX6SX_LCDIF1_BASE_ADDR  (AIPS3_ARB_BASE_ADDR + 0x2)
 #define MX6SX_WDOG3_BASE_ADDR   (AIPS3_ARB_BASE_ADDR + 0x88000)
 
-/* only for i.MX6SX/UL */
-#define WDOG3_BASE_ADDR (is_cpu_type(MXC_CPU_MX6UL) ?  \
-MX6UL_WDOG3_BASE_ADDR :  MX6SX_WDOG3_BASE_ADDR)
-
 #define CHIP_REV_1_0 0x10
 #define CHIP_REV_1_2 0x12
 #define CHIP_REV_1_5 0x15
@@ -336,9 +333,17 @@
 #endif
 #define FEC_QUIRK_ENET_MAC
 
+#include 
 #if !(defined(__KERNEL_STRICT_NAMES) || defined(__ASSEMBLY__))
 #include 
 
+/* only for i.MX6SX/UL */
+#define WDOG3_BASE_ADDR (is_cpu_type(MXC_CPU_MX6UL) ?  \
+MX6UL_WDOG3_BASE_ADDR :  MX6SX_WDOG3_BASE_ADDR)
+#define LCDIF1_BASE_ADDR (is_cpu_type(MXC_CPU_MX6UL)) ?\
+ MX6UL_LCDIF1_BASE_ADDR : MX6SX_LCDIF1_BASE_ADDR
+
+
 extern void imx_get_mac_from_fuse(int dev_id, unsigned char *mac);
 
 #define SRC_SCR_CORE_1_RESET_OFFSET 14
-- 
1.8.4


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

Re: [U-Boot] [PATCH V2 1/3] arm: discard relocation entry for secure section

[Peng Fan]

Hi Albert,

On Tue, Oct 20, 2015 at 09:32:51AM +0200, Albert ARIBAUD wrote:
>Hello Peng,
>
>On Tue, 20 Oct 2015 15:20:43 +0800, Peng Fan 
>wrote:
>> Hi Albert,
>> 
>> On Tue, Oct 20, 2015 at 09:05:32AM +0200, Albert ARIBAUD wrote:
>> >Hello Peng,
>> >
>> >On Tue, 20 Oct 2015 13:59:53 +0800, Peng Fan 
>> >wrote:
>> >> The code such as PSCI in section named secure is bundled with
>> >> u-boot image, and when bootm, the code will be copied to their
>> >> runtime address same to compliation/linking address -
>> >> CONFIG_ARMV7_SECURE_BASE.
>> >> 
>> >> When compile the PSCI code and link it into the u-boot image,
>> >> there will be relocation entries in .rel.dyn section for PSCI.
>> >> Actually, we do not needs these relocation entries.
>> >> 
>> >> If still keep the relocation entries in .rel.dyn section,
>> >> r0 at line 103 and 106 in arch/arm/lib/relocate.S may be an invalid
>> >> address which may not support read/write for one SoC.
>> >> 102 /* relative fix: increase location by offset */
>> >> 103 add r0, r0, r4
>> >> 104 ldr r1, [r0]
>> >> 105 add r1, r1, r4
>> >> 106 str r1, [r0]
>> >> 
>> >> So discard the relocation entries for code in secure section.
>> >
>> >Actually, I'll need you to do a slight change -- that's my fault, and
>> >karma even ensured that my own self of two years ago would be the one
>> >to come and kick me. See:
>> >
>> >http://lists.denx.de/pipermail/u-boot/2013-December/168652.html
>> 
>> Ok. Then arch/arm/cpu/armv8/u-boot.lds should also have such fix,
>> since lots sections are discarded in u-boot.lds for armv8.
>
>You are correct, armv8 needs to be fixed, as well as zynq (and x86 but
>that's outside of my province). Anyway, that's a different problem
>which does not need to be addressed in this series.
>
>> >Which basically is about never discarding any section in the ELF file,
>> >and only copying a subset of the ELF sections into the binary file.
>> >
>> >So rather than discarding the secure relocation records, let's move
>> >them to another section as you had proposed, and thus change the line
>> >
>> >> + /DISCARD/ : { *(.rel._secure*) }
>> >
>> >Into a
>> >
>> >.rel._secure { *(.rel._secure*) }
>> >
>> >Placed right after the already present
>> >
>> >.dynamic : { *(.dynamic*) }
>> 
>> It can not be placed after .dynamic, since the following is at front.
>> 87 .rel.dyn : {
>> 88 *(.rel*)
>> 89 }
>> So relocation entry from secure text will first placed into .rel.dyn section.
>> 
>> If not DISCARD, then I prefer to put ".rel.secure : { *(.rel._secure*) }"
>> at line 55 which is wrapped by CONFIG_ARMV7_NONSEC in 
>> arch/arm/cpu/u-boot.lds.
>
>I prefer all 'unused' sections to be kept together near the end of the
>LDS file -- I'll add an explicit comment in the LDS about it.
>
>Besides, there no need to wrap such a section with a preprocessor
>conditional, as the linker will simply not emit an output section if
>there are no input sections at all for it; IOW, adding the '.rel._secure
>{ *(.rel._secure*) }' line will be binary-invariant for platforms which
>do not have PSCI or other secure code.

But ".rel._secure { *(.rel._secure*) }" can not be placed after
".dynamic : { *(.dynamic*) }". Actually ".rel._secure { *(.rel._secure*) }"
should be placed before ".rel_dyn_start" in u-boot.lds, otherwise
the secure relocation entries will be placed into ".rel.dyn", but not
".rel._secure".

Regards,
Peng.

>
>Amicalement,
>-- 
>Albert.

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

[U-Boot] [PATCH V2 3/3] imx: mx7: default enable non-secure mode

[Peng Fan]

Support PSCI and switch to non-secure mode when booting linux.

Signed-off-by: Peng Fan 
Signed-off-by: Frank Li 
Cc: Stefano Babic 
Cc: Fabio Estevam 
---

Changes V2:
 default no enable CONFIG_ARMV7_VIRT

 include/configs/mx7_common.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/include/configs/mx7_common.h b/include/configs/mx7_common.h
index ea2be49..fac76bd 100644
--- a/include/configs/mx7_common.h
+++ b/include/configs/mx7_common.h
@@ -92,4 +92,14 @@
 #define CONFIG_CMD_FUSE
 #define CONFIG_MXC_OCOTP
 
+/* Default boot linux kernel in no secure mode.
+ * If want to boot kernel in secure mode, please define CONFIG_MX7_SEC
+ */
+#ifndef CONFIG_MX7_SEC
+#define CONFIG_ARMV7_NONSEC 1
+#define CONFIG_ARMV7_PSCI 1
+#define CONFIG_ARMV7_PSCI_NR_CPUS  2
+#define CONFIG_ARMV7_SECURE_BASE 0x0090
+#endif
+
 #endif
-- 
1.8.4


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

Re: [U-Boot] [PATCH V2 1/3] arm: discard relocation entry for secure section

[Albert ARIBAUD]

Hello Peng,

On Tue, 20 Oct 2015 13:59:53 +0800, Peng Fan 
wrote:
> The code such as PSCI in section named secure is bundled with
> u-boot image, and when bootm, the code will be copied to their
> runtime address same to compliation/linking address -
> CONFIG_ARMV7_SECURE_BASE.
> 
> When compile the PSCI code and link it into the u-boot image,
> there will be relocation entries in .rel.dyn section for PSCI.
> Actually, we do not needs these relocation entries.
> 
> If still keep the relocation entries in .rel.dyn section,
> r0 at line 103 and 106 in arch/arm/lib/relocate.S may be an invalid
> address which may not support read/write for one SoC.
> 102 /* relative fix: increase location by offset */
> 103 add r0, r0, r4
> 104 ldr r1, [r0]
> 105 add r1, r1, r4
> 106 str r1, [r0]
> 
> So discard the relocation entries for code in secure section.

Actually, I'll need you to do a slight change -- that's my fault, and
karma even ensured that my own self of two years ago would be the one
to come and kick me. See:

http://lists.denx.de/pipermail/u-boot/2013-December/168652.html

Which basically is about never discarding any section in the ELF file,
and only copying a subset of the ELF sections into the binary file.

So rather than discarding the secure relocation records, let's move
them to another section as you had proposed, and thus change the line

> + /DISCARD/ : { *(.rel._secure*) }

Into a

.rel._secure { *(.rel._secure*) }

Placed right after the already present

.dynamic : { *(.dynamic*) }

With my apologies for the very late realization.

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

Re: [U-Boot] [PATCH] arm: sunxi: Add icnova-a20-swac defconfig and dts file

[Ian Campbell]

On Mon, 2015-10-19 at 13:42 +0200, Hans de Goede wrote:
> 
> I'm sorry but I'm not going to budge on this one, having
> CONFIG_OLD_SUNXI_KERNEL_COMPAT=y in a defconfig is simply not acceptable
> IMHO. It is not a board specific thing, and there are very good reasons
> why it defaults to n in board/sunxi/Kconfig

Agreed.

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

Re: [U-Boot] [PATCH] arm: sunxi: Add icnova-a20-swac defconfig and dts file

[Ian Campbell]

On Mon, 2015-10-19 at 13:44 +0200, Hans de Goede wrote:
> > Okay. Hans, do you want me to change this (and potential other
> > changes as well - see file naming above) via a follow-up patch
> > once its available in mainline U-Boot?
> 
> Actually I would prefer to get this right in one go, esp. the
> filename bits, having u-boot and the kernel disagreeing on the
> dtb filename is no good. So I plan to remove this version of
> the patch from u-boot-sunxi/next for now. Once you and Maxime
> agree on a dts / dtb filename please submit a new version and
> I'll merge that one instead.

Wasn't our policy supposed to be that we (u-boot) would only take DTS
files which were at least on their way to mainline Linux (i.e. in
Maxime's tree)?

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

Re: [U-Boot] [PATCH] vexpress64: compile Juno PCIe conditionally

[Ryan Harkin]

On 20 October 2015 at 07:05, Linus Walleij  wrote:

> Only compile in PCIe support if the board really uses it. Provide
> a stub for the init function if e.g. FVP is being built.
>
> Cc: Liviu Dudau 
> Cc: Ryan Harkin 
> Signed-off-by: Linus Walleij 
> ---
>  board/armltd/vexpress64/Makefile | 3 ++-
>  board/armltd/vexpress64/pcie.c   | 2 --
>  board/armltd/vexpress64/pcie.h   | 4 
>  3 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/board/armltd/vexpress64/Makefile
> b/board/armltd/vexpress64/Makefile
> index a35db401b684..b4391a71249a 100644
> --- a/board/armltd/vexpress64/Makefile
> +++ b/board/armltd/vexpress64/Makefile
> @@ -5,4 +5,5 @@
>  # SPDX-License-Identifier: GPL-2.0+
>  #
>
> -obj-y  := vexpress64.o pcie.o
> +obj-y  := vexpress64.o
> +obj-$(CONFIG_TARGET_VEXPRESS64_JUNO)   += pcie.o
> diff --git a/board/armltd/vexpress64/pcie.c
> b/board/armltd/vexpress64/pcie.c
> index 7b999e8ef40b..311c4500e3ff 100644
> --- a/board/armltd/vexpress64/pcie.c
> +++ b/board/armltd/vexpress64/pcie.c
> @@ -191,7 +191,5 @@ void xr3pci_init(void)
>
>  void vexpress64_pcie_init(void)
>  {
> -#ifdef CONFIG_TARGET_VEXPRESS64_JUNO
> xr3pci_init();
> -#endif
>  }
> diff --git a/board/armltd/vexpress64/pcie.h
> b/board/armltd/vexpress64/pcie.h
> index 14642f4f5c43..55b276d6af11 100644
> --- a/board/armltd/vexpress64/pcie.h
> +++ b/board/armltd/vexpress64/pcie.h
> @@ -1,6 +1,10 @@
>  #ifndef __VEXPRESS64_PCIE_H__
>  #define __VEXPRESS64_PCIE_H__
>
> +#ifdef CONFIG_TARGET_VEXPRESS64_JUNO
>  void vexpress64_pcie_init(void);
> +#else
> +static inline void vexpress64_pcie_init(void) {}
> +#endif
>
>  #endif /* __VEXPRESS64_PCIE_H__ */
>

Tom specifically dropped this hunk when he merged Liviu's patch.  But is it
necessary with the rest of your patch?  If pcie.h is only included in
pcie.c, which is only built for JUNO, then the code shouldn't need
conditional compilation. So I think we can drop the hunk, no?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v7 5/9] arm: serial: Add ability to use pre-initialized UARTs

[Linus Walleij]

On Mon, Oct 19, 2015 at 9:21 PM, Rob Herring  wrote:
> On Mon, Oct 19, 2015 at 7:57 AM, Linus Walleij  
> wrote:

>> The MAINTAINERS entry for device tree bindings does not state a
>> git tree and I've never seen any of the maintainers send a pull request for
>> DT binding files. (Beat me up properly if you have, guys.) I've seen
>> Grant send some at times.
>
> Err, what?
>
> $ git log --merges --grep='Pull.*\(Herring\|Likely\)' --oneline
> Documentation/devicetree/

OK nice, bad research from me. My sloppy statement was
based on this:

OPEN FIRMWARE AND FLATTENED DEVICE TREE
M:  Rob Herring 
M:  Frank Rowand 
M:  Grant Likely 
L:  devicet...@vger.kernel.org
W:  http://www.devicetree.org/
T:  git git://git.kernel.org/pub/scm/linux/kernel/git/glikely/linux.git
S:  Maintained
F:  drivers/of/
F:  include/linux/of*.h
F:  scripts/dtc/

> The DT core code and bindings (which don't go thru subsystem trees) go
> together.

I guess I should just send a patch adding

F:Documentation/devicetree/*

...and hope things get better from that.

>> I suggest sending U-Boot DT bindings to not only
>> devicet...@vger.kernel.org
>> but also, as indicated, to Jon Corbet and linux-doc.
>
> I'd suggest devicetree-spec@vger for common things. Perhaps we need a
> better name, but the whole point of this was to separate the common
> issues from the firehose and have multiple OS participation.

Hm, wasn't devicet...@vger.kernel.org supposed to be for that?

>> If noone cares to comment in two weeks, Jon can merge them,
>> breaking the status quo on external DT bindings.
>
> Did someone tell Jon to drink from that firehose?

I'm sorry, I guess this whole mail was something I wrote in light
panic over the increasing threat from the separatists.

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

Re: [U-Boot] [PATCH v7 5/9] arm: serial: Add ability to use pre-initialized UARTs

[Linus Walleij]

On Tue, Oct 20, 2015 at 10:10 AM, Linus Walleij
 wrote:
> On Mon, Oct 19, 2015 at 9:21 PM, Rob Herring  wrote:
>> On Mon, Oct 19, 2015 at 7:57 AM, Linus Walleij  
>> wrote:
>
>> Err, what?
>>
>> $ git log --merges --grep='Pull.*\(Herring\|Likely\)' --oneline
>> Documentation/devicetree/
>
> OK nice, bad research from me. My sloppy statement was
> based on this:
>
> OPEN FIRMWARE AND FLATTENED DEVICE TREE
> M:  Rob Herring 
> M:  Frank Rowand 
> M:  Grant Likely 
> L:  devicet...@vger.kernel.org
> W:  http://www.devicetree.org/
> T:  git git://git.kernel.org/pub/scm/linux/kernel/git/glikely/linux.git
> S:  Maintained
> F:  drivers/of/
> F:  include/linux/of*.h
> F:  scripts/dtc/
>
>> The DT core code and bindings (which don't go thru subsystem trees) go
>> together.
>
> I guess I should just send a patch adding
>
> F:Documentation/devicetree/*
>
> ...and hope things get better from that.

Ah yeah now I also woke up properly... so there is a special group of people
listed under another heading for this, and I should know that, mea culpa.

OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
M:  Rob Herring 
M:  Pawel Moll 
M:  Mark Rutland 
M:  Ian Campbell 
M:  Kumar Gala 
L:  devicet...@vger.kernel.org
S:  Maintained
F:  Documentation/devicetree/
F:  arch/*/boot/dts/
F:  include/dt-bindings/

So can we add your git tree as T: here and replace Grant's tree in
the overall DT entry above it?

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

[U-Boot] Bisected broken Ethernet support on ODROID-X (Exynos4412 board)

[Siarhei Siamashka]

Hello,

Ethernet support does not work anymore when using the current U-Boot
(version v2014.10) on the ODROID-X board. Bisecting shows that this
happened starting from commit 874dde80169e0a0c00020e2e0bbcd380c61097e3
("dm: usb: exynos: Use driver model for USB"):

http://git.denx.de/?p=u-boot.git;a=commitdiff;h=874dde80169e0a0c00020e2e0bbcd380c61097e3

Below are the logs from the serial console.

=== works properly ==

U-Boot 2015.04-00271-g52e6935-dirty (Oct 20 2015 - 16:38:09)

CPU:Exynos4412@1000MHz
Model: Odroid based on Exynos4412
DRAM:  1 GiB
Board PMIC init
MMC:   SAMSUNG SDHCI: 0, EXYNOS DWMMC: 1
Net:   No ethernet found.
Hit any key to stop autoboot:  0 
reading boot.scr
129 bytes read in 11 ms (10.7 KiB/s)
## Executing script at 40408000
starting USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 4 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
   scanning usb for ethernet devices... 1 Ethernet Device(s) found

=== fails ==

U-Boot 2015.04-00273-g78ab40b-dirty (Oct 20 2015 - 16:41:11)

CPU:Exynos4412@1000MHz
Model: Odroid based on Exynos4412
DRAM:  1 GiB
Board PMIC init
MMC:   SAMSUNG SDHCI: 0, EXYNOS DWMMC: 1
Net:   No ethernet found.
Hit any key to stop autoboot:  0 
reading boot.scr
129 bytes read in 12 ms (9.8 KiB/s)
## Executing script at 40408000
starting USB...
USB-1:   USB EHCI 1.00
scanning bus 0 for devices... 1 USB Device(s) found
   scanning usb for ethernet devices... 0 Ethernet Device(s) found

===

As a test, reverting f56da290b8df14a058b43735494dbbb0f8521a89 ("Drop
the code that doesn't use driver model for USB.") and disabling
CONFIG_DM_USB in odroid_defconfig makes it work again.


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

Re: [U-Boot] [PATCH V2 2/3] mx7: psci: add basic psci support

[Li Frank]

> -Original Message-
> From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net]
> Sent: Tuesday, October 20, 2015 9:25 AM
> To: Li Frank-B20596 
> Cc: Fan Peng-B51431 ; u-boot@lists.denx.de;
> Estevam Fabio-R49496 
> Subject: Re: [U-Boot] [PATCH V2 2/3] mx7: psci: add basic psci support
> 
> Hello Li,
> 
> On Tue, 20 Oct 2015 14:05:45 +, Li Frank 
> wrote:
> >
> >
> > > -Original Message-
> > > From: Peng Fan [mailto:peng@freescale.com]
> > > Sent: Tuesday, October 20, 2015 1:00 AM
> > > To: u-boot@lists.denx.de
> > > Cc: Fan Peng-B51431 ; Li Frank-B20596
> > > ; Stefano Babic ; Estevam
> > > Fabio-
> > > R49496 
> > > Subject: [PATCH V2 2/3] mx7: psci: add basic psci support
> > >
> > > 1. add basic psci support for imx7 chip.
> > > 2. support cpu_on and cpu_off.
> > > 3. switch to non-secure mode when boot linux kernel.
> > > 4. set csu allow accessing all peripherial register in non-secure mode.
> > >
> > > Signed-off-by: Frank Li 
> > > Signed-off-by: Peng Fan 
> > > Cc: Stefano Babic 
> > > Cc: Fabio Estevam 
> > > ---
> > >
> > > Changes V2:
> > >  Refine commit msg.
> > >
> > >  arch/arm/cpu/armv7/mx7/Makefile   |  4 ++
> > >  arch/arm/cpu/armv7/mx7/psci-mx7.c | 78
> > > +++
> > >  arch/arm/cpu/armv7/mx7/psci.S | 54 +++
> > >  arch/arm/cpu/armv7/mx7/soc.c  |  9 +
> > >  4 files changed, 145 insertions(+)
> > >  create mode 100644 arch/arm/cpu/armv7/mx7/psci-mx7.c  create mode
> > > 100644 arch/arm/cpu/armv7/mx7/psci.S
> > >
> > > diff --git a/arch/arm/cpu/armv7/mx7/Makefile
> > > b/arch/arm/cpu/armv7/mx7/Makefile index e6ecef0..f25461c 100644
> > > --- a/arch/arm/cpu/armv7/mx7/Makefile
> > > +++ b/arch/arm/cpu/armv7/mx7/Makefile
> > > @@ -6,3 +6,7 @@
> > >  #
> > >
> > >  obj-y:= soc.o clock.o clock_slice.o
> > > +
> > > +ifdef CONFIG_ARMV7_PSCI
> > > +obj-y  += psci.o psci-mx7.o
> >
> > Obj-y += psci-mx7.o psci.o
> > The otherwise psci_text_end will not be last one.
> 
> I don't like this object module order sensitivity.
> 
> The object module order of secure code modules should not affect the resulting
> binary to the point of possibly preventing it from working -- after all, the 
> object
> module order of 'vanilla' image code does not matter (1). We don't have this
> kind of problem when defining the image start and end, why would we have it
> with the secure code start and end?

Secure code use psci_text_end to calculate stack top point. 

> 
> IOW, psci_text_end could (and should) be defined in the linker script, not in 
> an
> object module.

I agree.  The other platform put psci_text_end to object module. 

Best regards
Frank Li

> 
> (1) except for start.S, which *must* be linked first, and even that is not 
> done
> through object order but through linker script section order.
> 
> > Best regards
> > Frank Li
> 
> Amicalement,
> --
> Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v2, 5/6] sbc8641d: enable and test CONFIG_SYS_GENERIC_BOARD

[Paul Gortmaker]

On 2015-10-19 08:07 PM, Tom Rini wrote:
> On Sat, Oct 17, 2015 at 04:40:30PM -0400, Paul Gortmaker wrote:
> 
> [nuked most of the commit message as it's now not true]

Ah crap, I forgot to get rid of that; thanks for tossing it.

P.
--

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

Re: [U-Boot] [PATCH V2 2/3] mx7: psci: add basic psci support

[Albert ARIBAUD]

Hello Li,

On Tue, 20 Oct 2015 14:05:45 +, Li Frank 
wrote:
> 
> 
> > -Original Message-
> > From: Peng Fan [mailto:peng@freescale.com]
> > Sent: Tuesday, October 20, 2015 1:00 AM
> > To: u-boot@lists.denx.de
> > Cc: Fan Peng-B51431 ; Li Frank-B20596
> > ; Stefano Babic ; Estevam Fabio-
> > R49496 
> > Subject: [PATCH V2 2/3] mx7: psci: add basic psci support
> > 
> > 1. add basic psci support for imx7 chip.
> > 2. support cpu_on and cpu_off.
> > 3. switch to non-secure mode when boot linux kernel.
> > 4. set csu allow accessing all peripherial register in non-secure mode.
> > 
> > Signed-off-by: Frank Li 
> > Signed-off-by: Peng Fan 
> > Cc: Stefano Babic 
> > Cc: Fabio Estevam 
> > ---
> > 
> > Changes V2:
> >  Refine commit msg.
> > 
> >  arch/arm/cpu/armv7/mx7/Makefile   |  4 ++
> >  arch/arm/cpu/armv7/mx7/psci-mx7.c | 78
> > +++
> >  arch/arm/cpu/armv7/mx7/psci.S | 54 +++
> >  arch/arm/cpu/armv7/mx7/soc.c  |  9 +
> >  4 files changed, 145 insertions(+)
> >  create mode 100644 arch/arm/cpu/armv7/mx7/psci-mx7.c  create mode
> > 100644 arch/arm/cpu/armv7/mx7/psci.S
> > 
> > diff --git a/arch/arm/cpu/armv7/mx7/Makefile
> > b/arch/arm/cpu/armv7/mx7/Makefile index e6ecef0..f25461c 100644
> > --- a/arch/arm/cpu/armv7/mx7/Makefile
> > +++ b/arch/arm/cpu/armv7/mx7/Makefile
> > @@ -6,3 +6,7 @@
> >  #
> > 
> >  obj-y  := soc.o clock.o clock_slice.o
> > +
> > +ifdef CONFIG_ARMV7_PSCI
> > +obj-y  += psci.o psci-mx7.o
> 
> Obj-y += psci-mx7.o psci.o
> The otherwise psci_text_end will not be last one.

I don't like this object module order sensitivity.

The object module order of secure code modules should not affect the
resulting binary to the point of possibly preventing it from working --
after all, the object module order of 'vanilla' image code does not
matter (1). We don't have this kind of problem when defining the image
start and end, why would we have it with the secure code start and end?

IOW, psci_text_end could (and should) be defined in the linker script,
not in an object module.

(1) except for start.S, which *must* be linked first, and even that
is not done through object order but through linker script section
order.

> Best regards
> Frank Li

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

Re: [U-Boot] [PATCH V3 05/10] fat: ff: read max contiguous file data

[Stephen Warren]

On 10/02/2015 12:06 AM, Stephen Warren wrote:

Enhance f_read() to find the maximum contiguous set of clusters to read,
and read it all at once (which is fast) rather one by one (which is
slow).


Hmm. I had hoped that the author of ff.c would accept this patch 
upstream, so we could pick up a later upstream version that included 
this patch. However, it seems the author of ff.c has a policy of not 
accepting outside contributions:


http://elm-chan.org/fsw/ff/bd/?show=2472
(That's a link to the author's reply to my patch, on the forum system 
associated with his/her SW)


I wonder how much of a liability incorporating ff.c into U-Boot will be, 
if we can't ever get any fixes merged upstream. Perhaps we just fork it, 
although I had hoped we'd be able to keep picking up new versions.

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

Re: [U-Boot] [PATCH V3 05/10] fat: ff: read max contiguous file data

[Tom Rini]

On Tue, Oct 20, 2015 at 12:57:32PM -0600, Stephen Warren wrote:
> On 10/02/2015 12:06 AM, Stephen Warren wrote:
> >Enhance f_read() to find the maximum contiguous set of clusters to read,
> >and read it all at once (which is fast) rather one by one (which is
> >slow).
> 
> Hmm. I had hoped that the author of ff.c would accept this patch
> upstream, so we could pick up a later upstream version that included
> this patch. However, it seems the author of ff.c has a policy of not
> accepting outside contributions:
> 
> http://elm-chan.org/fsw/ff/bd/?show=2472
> (That's a link to the author's reply to my patch, on the forum
> system associated with his/her SW)

The bit about the license is at
http://elm-chan.org/fsw/ff/en/appnote.html#license

> I wonder how much of a liability incorporating ff.c into U-Boot will
> be, if we can't ever get any fixes merged upstream. Perhaps we just
> fork it, although I had hoped we'd be able to keep picking up new
> versions.

Arg, that really does take away one of the potential nice features.  I
guess, sadly, at this point I'd rather stick with the version we have
unless you want to deal with re-syncing their releases but still
effectively doing a fork (so that we can also make use of caches which I
think you said before you thought might be part of the performance
problem.

Or we take a look at borrowing the kernel's code, similar to how we
leverage UBIFS today.

Regardless, thanks for the time you've already put in on this!

-- 
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] [PATCH] Revert "arm: Remove d2net_v2 defconfig file"

[Simon Glass]

On 19 October 2015 at 18:07, Tom Rini  wrote:
> On Mon, Oct 19, 2015 at 11:27:49AM -0400, Tom Rini wrote:
>
>> Upon further review when populating README.scrapyard, d2net_v2 is a
>> variant on net2big_v2 and not just an orphan config.  To help in the
>> future also add this to board/LaCie/net2big_v2/MAINTAINERS which needed
>> a little consolidation anyhow.
>>
>> This reverts commit 1363740e7948a8e4bee8d5adcdf0f63f7782879d.
>>
>> Cc: Simon Guinot 
>> Cc: Simon Glass 
>> Signed-off-by: Tom Rini 
>
> Applied to u-boot/master, thanks!

Thanks for handling this, and also the scrapyard stuff also!

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

Re: [U-Boot] [PATCH] fill_scrapyard.py: Pass a directory to tempfile.mkstemp()

[Tom Rini]

On Tue, Oct 20, 2015 at 11:10:23AM +0900, Masahiro Yamada wrote:
> Hi Tom,
> 
> 
> 2015-10-19 23:56 GMT+09:00 Tom Rini :
> > In some cases os.rename() may later fail due to "Cross-device link"
> > issues.  The easy way to deal with this is to simply make our temporary
> > file here as well rather than TMPDIR.
> >
> > Cc: Masahiro Yamada 
> > Signed-off-by: Tom Rini 
> > ---
> >  scripts/fill_scrapyard.py |2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/scripts/fill_scrapyard.py b/scripts/fill_scrapyard.py
> > index 9a94354..cd630ef 100755
> > --- a/scripts/fill_scrapyard.py
> > +++ b/scripts/fill_scrapyard.py
> > @@ -119,7 +119,7 @@ class TmpFile:
> >
> >  def __init__(self):
> >  """Constructor - create a temporary file"""
> > -fd, self.filename = tempfile.mkstemp()
> > +fd, self.filename = tempfile.mkstemp(dir='.')
> >  self.file = os.fdopen(fd, 'w')
> >
> >  def __del__(self):
> 
> 
> 
> I personally prefer replacing "os.rename(tmpfile.filename, DOC)"
> with "shutil.move(tmpfile.filename, DOC)".

Yeah, I saw that too but wasn't sure if we wanted to depend on that
package.

-- 
Tom


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

[U-Boot] [PATCH] ohci: Add missing cache-flush for hcca area

[Hans de Goede]

We need to cache-flush the hcca area after the initial memset, otherwise
on the first hc_interrupt we might see an old $random value as done_head and
try to interpret that as the address for a completed td (followed by chaos).

Signed-off-by: Hans de Goede 
---
 drivers/usb/host/ohci-hcd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 9bde2b2..ccbfc02 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -2205,6 +2205,7 @@ int ohci_register(struct udevice *dev, struct ohci_regs 
*regs)
if (!ohci->hcca)
return -ENOMEM;
memset(ohci->hcca, 0, sizeof(struct ohci_hcca));
+   flush_dcache_hcca(ohci->hcca);
 
if (hc_reset(ohci) < 0)
return -EIO;
-- 
2.5.0

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

Re: [U-Boot] [PATCH 2/3] gpt: add optional parameter guid in gpt command

[Tom Rini]

On Mon, Oct 19, 2015 at 04:59:28PM +0200, Patrick Delaunay wrote:
> 2015-10-15 23:46 GMT+02:00 Tom Rini :
> 
> > On Thu, Oct 15, 2015 at 03:58:24PM -0500, Rob Herring wrote:
> > > On Tue, Oct 13, 2015 at 9:23 AM, Patrick Delaunay
> > >  wrote:
> > > > code under flag CONFIG_PARTITION_TYPE_GUID
> > > > add parameter guid to select partition type guid
> > > >
> > > > example of use with gpt command :
> > > >
> > > >   partitions = uuid_disk=${uuid_gpt_disk};name=boot,start=0x4400,
> > > >   size=0x6bc00,uuid=${uuid_gpt_boot};name=root,start=0x7,
> > > >   size=0x7538ba00,uuid=${uuid_gpt_root},
> > > >   guid=0fc63daf-8483-4772-8e79-3d69d8477de4;
> > >
> > > The mixture of UUID and GUID is confusing. What we want are the
> > > GUIDs/UUIDs for unique ID and the partition type. I would just call
> > > the partition type "type". This would allow the same format to be used
> > > for MBR partitions if someone wanted to do support for that.
> >
> > ... and if someone wants to add MBR support, there's enough use cases
> > for it (mainly around flashing/factory stuff) that I wouldn't object.
> > So yes, lets do this with that kind of thing in mind.
> >
> 
> 
> Hi,
> 
> if you prefer, I can modify the parameter name to "type" as proposed in a
> version 2 of the patchset.
> 
> partitions =
> uuid_disk=${uuid_gpt_disk}; \
> name=boot,start=0x4400,size=0x6bc00,uuid=${uuid_gpt_boot}; \
> 
> name=root,start=0x7,size=0x7538ba00,uuid=${uuid_gpt_root},type=0fc63daf-8483-4772-8e79-3d69d8477de4;
> 
> and to be coherent, I will also modify the field in the struct
> disk_partition_t to type_guid
> 
> +#ifdef CONFIG_PARTITION_TYPE_GUID
> +chartype_guid[37];/* type GUID as string, if exists*/
> +#endif
>  } disk_partition_t;

Sounds like a plan, thanks!

-- 
Tom


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

Re: [U-Boot] [ANN] U-Boot v2015.10 released

[Wolfgang Denk]

Dear Tom,

In message <20151020153139.GK23893@bill-the-cat> you wrote:
> 
> > It appears you did not push the tag, though?
> 
> Oops, fixed.

Thanks.  Tarballs are on the FTP and ACD servers.

Statistics will follow ASAP.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
HANDLE WITH EXTREME CARE:  This Product Contains  Minute Electrically
Charged  Particles  Moving  at  Velocities  in Excess of Five Hundred
Million Miles Per Hour.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [ANN] U-Boot v2015.10 released

[Tom Rini]

On Tue, Oct 20, 2015 at 07:18:49PM +0300, Igor Grinberg wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On 10/20/15 18:31, Tom Rini wrote:
> > On Tue, Oct 20, 2015 at 07:34:27AM +0200, Wolfgang Denk wrote:
> >> Dear Tom,
> >>
> >> In message <2015102800.GF23893@bill-the-cat> you wrote:
> >>>
> >>> I've pushed v2015.10 out to the repository and tarballs should exist
> >>> soon.
> >>
> >> It appears you did not push the tag, though?
> > 
> > Oops, fixed.
> 
> I've just pulled and nope, not there...

Wolfgang, I think we need a little back-end love (the tag was in fact
messed up as I did a commit --amend and not changed anything, but that
still re-did the hash, after tagging and before pushing so I think it's
"stuck" due to that.

-- 
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] OpenEmbedded-Core pending patch

[Tom Rini]

On Thu, Jul 23, 2015 at 05:55:46PM -0300, Otavio Salvador wrote:

> Hello folks,
> 
> I went over the process of upgrading the U-Boot, in OE-Core, and now
> we have 2015.07 merged.
> 
> Along the process I found a pending patch for merging[1] and I would
> like to know how is the best way to address this specific issue in
> mainline.
> 
> 1. 
> http://git.openembedded.org/openembedded-core/tree/meta/recipes-bsp/u-boot/u-boot/0001-u-boot-mpc85xx-u-boot-.lds-remove-_GLOBAL_OFFSET_TAB.patch
> 
> I am also adding the patch Author in Cc.

This got burried, sorry.  My concern would be if things are still
correct (runtime testing required) with older toolchains.  Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v2 00/14] Implement fastboot over NAND and sparse transfers

[Tom Rini]

On Mon, Oct 19, 2015 at 10:17:46AM +0200, Maxime Ripard wrote:
> On Sat, Oct 17, 2015 at 04:42:09PM +0200, Hans de Goede wrote:
> > Hi,
> > 
> > On 17-10-15 15:59, Hans de Goede wrote:
> > >Hi,
> > >
> > >On 15-10-15 14:34, Maxime Ripard wrote:
> > >>Hi everyone,
> > >>
> > >>Here is the second attempt at getting fastboot flashing functions
> > >>working on top of a NAND, for arbitraly large images.
> > >>
> > >>While the NAND support itself was quite easy to do, the support for
> > >>the Android sparse images was quite difficult to add, and ended up
> > >>being a quite huge refactoring of the sparse parse already in tree,
> > >>that was tied to the MMC layer.
> > >>
> > >>This serie has been tested on a CHIP and an A13-Olinuxino, two
> > >>Allwinner devices, the CHIP for the NAND, and the Cubietruck to test
> > >>the MMC.
> > >>
> > >>Let me know what you think,
> > >>Maxime
> > >
> > >Thanks, I've applied the 3 sunxi patches (12 - 14) to u-boot-sunxi/next,
> > >with the commit msg fixup suggested by Ian.
> > 
> > Looks like I've spoken too soon, the patch for enabling otg on the 
> > cubietruck
> > causes build errors:
> > 
> > arm-linux-gnu-ld.bfd: error: 
> > /usr/lib/gcc/arm-linux-gnueabi/5.2.1/libgcc.a(_udivmoddi4.o) uses VFP 
> > register arguments, u-boot does not
> > arm-linux-gnu-ld.bfd: failed to merge target specific data of file 
> > /usr/lib/gcc/arm-linux-gnueabi/5.2.1/libgcc.a(_udivmoddi4.o)
> > Makefile:1173: recipe for target 'u-boot' failed
> > make: *** [u-boot] Error 1
> > 
> > Usually this means that some code is using 64 bit int division
> > without using the proper macros for this.
> > 
> > For some reason I'm not seeing the same on the A13-OlinuxIno, that patch
> > for that seems to be missing the id pin, which could have something to do
> > with this.
> > 
> > I think this is caused by some 64 bit math in the fastboot code somewhere 
> > ...
> > 
> > For now I've dropped these 2 patches from u-boot-sunxi/next
> 
> Which 2 patches then? Cubietruck and this one?
> 
> Do you have a toolchain tarball for this so that I can test easily?

The arm-none-eabi toolchain that's apt-get'able should show this.  You
could even fudge this by (I _think_) forcing U-Boot to build with
-march=armv5te rather than armv7.  I _might_ even be able to spot it in
the patch review :)

-- 
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] [PATCH] vexpress64: compile Juno PCIe conditionally

[Tom Rini]

On Tue, Oct 20, 2015 at 08:05:40AM +0200, Linus Walleij wrote:

> Only compile in PCIe support if the board really uses it. Provide
> a stub for the init function if e.g. FVP is being built.
> 
> Cc: Liviu Dudau 
> Cc: Ryan Harkin 
> Signed-off-by: Linus Walleij 
> ---
>  board/armltd/vexpress64/Makefile | 3 ++-
>  board/armltd/vexpress64/pcie.c   | 2 --
>  board/armltd/vexpress64/pcie.h   | 4 
>  3 files changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/board/armltd/vexpress64/Makefile 
> b/board/armltd/vexpress64/Makefile
> index a35db401b684..b4391a71249a 100644
> --- a/board/armltd/vexpress64/Makefile
> +++ b/board/armltd/vexpress64/Makefile
> @@ -5,4 +5,5 @@
>  # SPDX-License-Identifier:   GPL-2.0+
>  #
>  
> -obj-y:= vexpress64.o pcie.o
> +obj-y:= vexpress64.o
> +obj-$(CONFIG_TARGET_VEXPRESS64_JUNO) += pcie.o
> diff --git a/board/armltd/vexpress64/pcie.c b/board/armltd/vexpress64/pcie.c
> index 7b999e8ef40b..311c4500e3ff 100644
> --- a/board/armltd/vexpress64/pcie.c
> +++ b/board/armltd/vexpress64/pcie.c
> @@ -191,7 +191,5 @@ void xr3pci_init(void)
>  
>  void vexpress64_pcie_init(void)
>  {
> -#ifdef CONFIG_TARGET_VEXPRESS64_JUNO
>   xr3pci_init();
> -#endif
>  }
> diff --git a/board/armltd/vexpress64/pcie.h b/board/armltd/vexpress64/pcie.h
> index 14642f4f5c43..55b276d6af11 100644
> --- a/board/armltd/vexpress64/pcie.h
> +++ b/board/armltd/vexpress64/pcie.h
> @@ -1,6 +1,10 @@
>  #ifndef __VEXPRESS64_PCIE_H__
>  #define __VEXPRESS64_PCIE_H__
>  
> +#ifdef CONFIG_TARGET_VEXPRESS64_JUNO
>  void vexpress64_pcie_init(void);
> +#else
> +static inline void vexpress64_pcie_init(void) {}
> +#endif
>  
>  #endif /* __VEXPRESS64_PCIE_H__ */

Alright, so the versatile platform makes life fun at times.  First, my
preference is for weak functions (and I _think_ the linker ends up being
smart enough about them to optimize things away, if not, arrg).  Second,
the question I have is, is this xr3pci_init() bit really a Juno thing or
a baseboard thing (I assume no) or a going to be the same on the next
Cortex-Asomething module thing?  The way the code stands today a
hypothethical A72-based vexpress64 module would need to call
vexpress64_pcie_init() but not strictly xr3pci_init().  It would be a
little ugly as pcie.c would #if/#elif/#endif the enabler call however so
we could __weak a no-op in board.c and rename pcie.c to juno.c and have
a72codenameboard.c later on with its own function.

-- 
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] [PATCH 2/2] ARM: dra7xx_evm: Add DFU support for qspi flash

[Tom Rini]

On Tue, Oct 20, 2015 at 03:22:01PM +0530, Vignesh R wrote:

> This adds support to update firmware on qspi flash using DFU.
> 
> On device:
> => setenv dfu_alt_info ${dfu_alt_info_qspi}
> => dfu 0 sf 0:0
> 
> On host:
> $ sudo dfu-util -l
> $ sudo dfu-util -D MLO -a MLO
> $ sudo dfu-util -D u-boot.img -a u-boot.img
> 
> Signed-off-by: Vignesh R 

Reviewed-by: Tom Rini 
Lukasz, can you just pull this in along with 1/2 when you do that?
Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 1/2] dfu: dfu_sf: Pass duplicate devstr to parse_dev

[Tom Rini]

On Tue, Oct 20, 2015 at 03:22:00PM +0530, Vignesh R wrote:

> parse_dev() alters the string pointed by devstr parameter. Due to this
> subsequent parsing of sf entities will fail, as string pointed by devstr
> is no longer valid sf dev arguments.
> Fix this by passing pointer to the copy of the string to parse_dev
> instead of pointer to the actual devstr.
> 
> Signed-off-by: Vignesh R 

Reviewed-by: Tom Rini 

-- 
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] Bisected broken Ethernet support on ODROID-X (Exynos4412 board)

[Simon Glass]

Hi,

On 20 October 2015 at 08:13, Siarhei Siamashka
 wrote:
> Hello,
>
> Ethernet support does not work anymore when using the current U-Boot
> (version v2014.10) on the ODROID-X board. Bisecting shows that this
> happened starting from commit 874dde80169e0a0c00020e2e0bbcd380c61097e3
> ("dm: usb: exynos: Use driver model for USB"):
> 
> http://git.denx.de/?p=u-boot.git;a=commitdiff;h=874dde80169e0a0c00020e2e0bbcd380c61097e3
>
> Below are the logs from the serial console.
>
> === works properly ==
>
> U-Boot 2015.04-00271-g52e6935-dirty (Oct 20 2015 - 16:38:09)
>
> CPU:Exynos4412@1000MHz
> Model: Odroid based on Exynos4412
> DRAM:  1 GiB
> Board PMIC init
> MMC:   SAMSUNG SDHCI: 0, EXYNOS DWMMC: 1
> Net:   No ethernet found.
> Hit any key to stop autoboot:  0
> reading boot.scr
> 129 bytes read in 11 ms (10.7 KiB/s)
> ## Executing script at 40408000
> starting USB...
> USB0:   USB EHCI 1.00
> scanning bus 0 for devices... 4 USB Device(s) found
>scanning usb for storage devices... 0 Storage Device(s) found
>scanning usb for ethernet devices... 1 Ethernet Device(s) found
>
> === fails ==
>
> U-Boot 2015.04-00273-g78ab40b-dirty (Oct 20 2015 - 16:41:11)
>
> CPU:Exynos4412@1000MHz
> Model: Odroid based on Exynos4412
> DRAM:  1 GiB
> Board PMIC init
> MMC:   SAMSUNG SDHCI: 0, EXYNOS DWMMC: 1
> Net:   No ethernet found.
> Hit any key to stop autoboot:  0
> reading boot.scr
> 129 bytes read in 12 ms (9.8 KiB/s)
> ## Executing script at 40408000
> starting USB...
> USB-1:   USB EHCI 1.00
> scanning bus 0 for devices... 1 USB Device(s) found
>scanning usb for ethernet devices... 0 Ethernet Device(s) found
>
> ===
>
> As a test, reverting f56da290b8df14a058b43735494dbbb0f8521a89 ("Drop
> the code that doesn't use driver model for USB.") and disabling
> CONFIG_DM_USB in odroid_defconfig makes it work again.

Does this problem happen on the XU3?

Are you able to debug this? You can use 'dm tree' to see what devices
are present before and after the 'usb start'.

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

Re: [U-Boot] [PATCH v4] x86: Added support for Advantech SOM-6896

[Simon Glass]

On 20 October 2015 at 07:12, Bin Meng  wrote:
> On Tue, Oct 20, 2015 at 8:46 PM, George McCollister
>  wrote:
>> Advantech SOM-6896 is a Broadwell U based COM Express Compact Module
>> Type 6. This patch adds support for it as a coreboot payload.
>>
>> On board SATA and SPI are functional. On board Ethernet isn't functional
>> but since it's optional and ties up a PCIe x4 that is otherwise brought
>> out, this isn't a concern at the moment. USB doesn't work since the
>> xHCI driver appears to be broken.
>>
>> Signed-off-by: George McCollister 
>> ---
>> Changes for V2:
>>  Changed pci's compatible string to "pci-x86"
>>  Changed I/O from base of 0x1000 to base of 0x1900
>>  Changed spi-flash memory-map
>> Changes for V3:
>>  Renamed som-6896.dts to broadwell_som-6896.dts
>> Changes for V4:
>>  Changed PCI I/O start from 0x1900 to 0x2000 (actually did it this time)
>>  Removed whitespace before my name at the top of som-6896.h
>>
>>  arch/x86/dts/Makefile   |  3 ++-
>>  arch/x86/dts/broadwell_som-6896.dts | 43 
>> +
>>  include/configs/som-6896.h  | 38 
>>  3 files changed, 83 insertions(+), 1 deletion(-)
>>  create mode 100644 arch/x86/dts/broadwell_som-6896.dts
>>  create mode 100644 include/configs/som-6896.h
>>
[snip]
>
> Reviewed-by: Bin Meng 

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

Re: [U-Boot] [PATCH 2/2] ARM: dra7xx_evm: Add DFU support for qspi flash

[Lukasz Majewski]

Hi Tom,

> On Tue, Oct 20, 2015 at 03:22:01PM +0530, Vignesh R wrote:
> 
> > This adds support to update firmware on qspi flash using DFU.
> > 
> > On device:
> > => setenv dfu_alt_info ${dfu_alt_info_qspi}
> > => dfu 0 sf 0:0
> > 
> > On host:
> > $ sudo dfu-util -l
> > $ sudo dfu-util -D MLO -a MLO
> > $ sudo dfu-util -D u-boot.img -a u-boot.img
> > 
> > Signed-off-by: Vignesh R 
> 
> Reviewed-by: Tom Rini 
> Lukasz, can you just pull this in along with 1/2 when you do that?

I've already pulled this to dfu tree, branch testing.
I will send proper PR in a few days time.

> Thanks!
> 



-- 
Best regards,

Lukasz Majewski

Samsung R Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [ANN] U-Boot v2015.10 released

[Igor Grinberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 10/20/15 18:31, Tom Rini wrote:
> On Tue, Oct 20, 2015 at 07:34:27AM +0200, Wolfgang Denk wrote:
>> Dear Tom,
>>
>> In message <2015102800.GF23893@bill-the-cat> you wrote:
>>>
>>> I've pushed v2015.10 out to the repository and tarballs should exist
>>> soon.
>>
>> It appears you did not push the tag, though?
> 
> Oops, fixed.

I've just pulled and nope, not there...


- -- 
Regards,
Igor.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWJmlpAAoJEBDE8YO64Efae4wP+gOCnXgEH5Rz+l3lm5cYE0W5
MGeNANvVQqVPFNatwstqMTKhxS+/gCKxzku/YYh2AblqbSlxF4+kEYtnCHye561A
ZOgddVCJrWrE2a+kkGvjwiK2xu+oLsvlSdSQUN7tCn2zSn8Vej6UVffbOGKcL6/Q
O4Bd3qCIBJG4i5Wj1qSUpa2G9mmj9LRq7KocG++lCw7ZKpE5vSdq5WN87y7/6X0m
/9jUHA5HQGA7KyhR3WOJ3ilIkRwOahrELS/GYeGNep8gYg6YVaGk/dPWBuKC/P+W
eZWDF9z3G+QzmCNCVKVPtgHBBOq88vYThJInYoZiC1MjXxvp1VgwC9m4Z9QUXn2f
olfV4MQ7K+AGgt0g0Ak2cBTdTYz5zqu3smktjyFt2G/lxNQiTT2wGq44HRBbfI+p
JfadBndjn6Xpk3enflmwmGHHXoo78Vp3SexSianuD6SHYG9Gq4UV2TfFm9FJgJxJ
S8ugeR6QI0131qNfi8krxv1Wkq+Bxqx4LJ8oobrOQczUXhqSQAQ9lRuf/kRw8LYi
IT2O+VI05ed/+Ri6jbZV3dsdJaIU7xsikf3VYkJCBhezDAjefcOrWCv5keTsyrWE
kk0Sb67Cec0NzZwCec88w8gxBYUKNgje/qZtMITdnIocf+07+MAPk2NV/3jqztt1
J5HgfXhHamEqxJB/kfw3
=GBX4
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] How do I tell buildman to use a /specific/ toolchain?

[Simon Glass]

Hi Tom,

On 20 October 2015 at 09:21, Tom Rini  wrote:
>
> On Sun, Oct 04, 2015 at 05:38:41PM +0100, Simon Glass wrote:
> > Hi Stephen,
> >
> > On 3 October 2015 at 20:20, Stephen Warren  wrote:
> > > On 10/03/2015 08:30 AM, Simon Glass wrote:
> > >> Hi Stephen,
> > >>
> > >> On 2 October 2015 at 00:27, Stephen Warren  wrote:
> > >>> On 10/01/2015 04:59 PM, Simon Glass wrote:
> > 
> >  Hi Stephen,
> > 
> >  On Wednesday, 23 September 2015, Stephen Warren 
> >  wrote:
> > >
> > >
> > > Simon,
> > >
> > > I have 3 different ARM toolchains installed into /usr/bin via distro
> > > packages. How do I tell buildman which of those to use?
> > >
> > > I had originally thought that ~/.buildman's [toolchain] section 
> > > contained
> > > CROSS_COMPILE-like values, so I tried:
> > >
> > >> [toolchain]
> > >> root: /
> > >> arm0-not-installed: arm-none-gnueabi-
> > >> arm1: arm-none-eabi-
> > >> arm2: arm-linux-gnueabihf-
> > >> arm3: arm-linux-gnueabi-
> > >> arch64: aarch64-linux-gnu-
> > >>
> > >> [toolchain-alias]
> > >> arm: arm1
> > >> aarch64: aarch64
> > >
> > >
> > >
> > > (I intended to change the "arm: arm1" line to point at arm1/2/3 based 
> > > on
> > > which I wanted to use at a particular time).
> > >
> > > However, running "buildman --list-toolchains" and re-reading the docs
> > > shows me that the [toolchain] values are absolute directories that 
> > > buildman
> > > searches for files named *-gcc:
> > >
> > >> - scanning path 'arm-none-gnueabi-'
> > >>- looking in 'arm-none-gnueabi-/.'
> > >>- looking in 'arm-none-gnueabi-/bin'
> > >>- looking in 'arm-none-gnueabi-/usr/bin'
> > >
> > >
> > >
> > > If buildman finds multiple toolchains, there doesn't seem to be a way 
> > > to
> > > tell it which one to use. Am I missing something?
> > >
> > > I suppose a solution wouuld be to move the compiler binaries into
> > > different separate directories, and only list one of those 
> > > directories in
> > > ~/.buildman. However, I can't do that for distro-packaged toolchains 
> > > (well,
> > > I suppose I could manually mv everything all over the place, but 
> > > that's
> > > really fragile since it'd break any time the package got upgraded or 
> > > removed
> > > and re-installed).
> > >
> > > I think it makes sense to add new syntax into ~/.buildman to specify
> > > "don't do automagical searching, just use this CROSS_COMPILE value 
> > > that I
> > > say". Does that sound reasonable? Automagic stuff makes for great 
> > > defaults,
> > > but if it can't be overridden, it sucks when you actually know what 
> > > you
> > > want.
> > 
> > 
> >  Yes I think it would be fine to add an option to use CROSS_COMPILE (of
> >  course it would fail if you tried to build the board with the wrong
> >  arch).
> > >>>
> > >>>
> > >>> I wasn't necessarily looking for buildman to pick up the CROSS_COMPILE
> > >>> environment variable, although that would be a simple solution for
> > >>> single-arch builds at least. My mention of CROSS_COMPILE immediately 
> > >>> above
> > >>> was re: using values that are formatted in the same way as the 
> > >>> CROSS_COMPILE
> > >>> environment variable would be, rather than directory names, in the 
> > >>> config
> > >>> file. In other words, the example content I showed above.
> > >>>
> >  The option other option at present is -G which lets you use multiple
> >  .buildman files. You could have one of these for each toolchain.
> > >>>
> > >>>
> > >>> I don't think that gets me what I want. As far as I can tell, the 
> > >>> buildman
> > >>> config file contains a list directories to search within, yet if I have 
> > >>> 3
> > >>> toolchains in a single directory, there's no way to select which one I 
> > >>> want
> > >>> to use, is there?
> > >>>
> > >>> In other words, a config file that contains:
> > >>>
> > >>> [toolchain]
> > >>> distro-packages: /usr/bin
> > >>>
> > >>> ... finds the following toolchains:
> > >>>
> > >>> [swarren@swarren-lx1 u-boot]$ ./tools/buildman/buildman \
> > >>> --list-tool-chains
> > >>> Scanning for tool chains
> > >>>- scanning path '/usr/bin'
> > >>>   - looking in '/usr/bin/.'
> > >>>  - found '/usr/bin/./arm-linux-gnueabi-gcc'
> > >>>  - found '/usr/bin/./arm-linux-gnueabihf-gcc'
> > >>>  - found '/usr/bin/./arm-none-eabi-gcc'
> > >>> (That's 3 AArch32 toolchains found)
> > >>>  - found '/usr/bin/./winegcc'
> > >>>  - found '/usr/bin/./aarch64-linux-gnu-gcc'
> > >>>  - found '/usr/bin/./gcc'
> > >>>  - found '/usr/bin/./c89-gcc'
> > >>>  - found 

Re: [U-Boot] [ANN] U-Boot v2015.10 released

[Tom Rini]

On Tue, Oct 20, 2015 at 07:34:27AM +0200, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <2015102800.GF23893@bill-the-cat> you wrote:
> > 
> > I've pushed v2015.10 out to the repository and tarballs should exist
> > soon.
> 
> It appears you did not push the tag, though?

Oops, fixed.

-- 
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] How do I tell buildman to use a /specific/ toolchain?

[Tom Rini]

On Sun, Oct 04, 2015 at 05:38:41PM +0100, Simon Glass wrote:
> Hi Stephen,
> 
> On 3 October 2015 at 20:20, Stephen Warren  wrote:
> > On 10/03/2015 08:30 AM, Simon Glass wrote:
> >> Hi Stephen,
> >>
> >> On 2 October 2015 at 00:27, Stephen Warren  wrote:
> >>> On 10/01/2015 04:59 PM, Simon Glass wrote:
> 
>  Hi Stephen,
> 
>  On Wednesday, 23 September 2015, Stephen Warren 
>  wrote:
> >
> >
> > Simon,
> >
> > I have 3 different ARM toolchains installed into /usr/bin via distro
> > packages. How do I tell buildman which of those to use?
> >
> > I had originally thought that ~/.buildman's [toolchain] section 
> > contained
> > CROSS_COMPILE-like values, so I tried:
> >
> >> [toolchain]
> >> root: /
> >> arm0-not-installed: arm-none-gnueabi-
> >> arm1: arm-none-eabi-
> >> arm2: arm-linux-gnueabihf-
> >> arm3: arm-linux-gnueabi-
> >> arch64: aarch64-linux-gnu-
> >>
> >> [toolchain-alias]
> >> arm: arm1
> >> aarch64: aarch64
> >
> >
> >
> > (I intended to change the "arm: arm1" line to point at arm1/2/3 based on
> > which I wanted to use at a particular time).
> >
> > However, running "buildman --list-toolchains" and re-reading the docs
> > shows me that the [toolchain] values are absolute directories that 
> > buildman
> > searches for files named *-gcc:
> >
> >> - scanning path 'arm-none-gnueabi-'
> >>- looking in 'arm-none-gnueabi-/.'
> >>- looking in 'arm-none-gnueabi-/bin'
> >>- looking in 'arm-none-gnueabi-/usr/bin'
> >
> >
> >
> > If buildman finds multiple toolchains, there doesn't seem to be a way to
> > tell it which one to use. Am I missing something?
> >
> > I suppose a solution wouuld be to move the compiler binaries into
> > different separate directories, and only list one of those directories 
> > in
> > ~/.buildman. However, I can't do that for distro-packaged toolchains 
> > (well,
> > I suppose I could manually mv everything all over the place, but that's
> > really fragile since it'd break any time the package got upgraded or 
> > removed
> > and re-installed).
> >
> > I think it makes sense to add new syntax into ~/.buildman to specify
> > "don't do automagical searching, just use this CROSS_COMPILE value that 
> > I
> > say". Does that sound reasonable? Automagic stuff makes for great 
> > defaults,
> > but if it can't be overridden, it sucks when you actually know what you
> > want.
> 
> 
>  Yes I think it would be fine to add an option to use CROSS_COMPILE (of
>  course it would fail if you tried to build the board with the wrong
>  arch).
> >>>
> >>>
> >>> I wasn't necessarily looking for buildman to pick up the CROSS_COMPILE
> >>> environment variable, although that would be a simple solution for
> >>> single-arch builds at least. My mention of CROSS_COMPILE immediately above
> >>> was re: using values that are formatted in the same way as the 
> >>> CROSS_COMPILE
> >>> environment variable would be, rather than directory names, in the config
> >>> file. In other words, the example content I showed above.
> >>>
>  The option other option at present is -G which lets you use multiple
>  .buildman files. You could have one of these for each toolchain.
> >>>
> >>>
> >>> I don't think that gets me what I want. As far as I can tell, the buildman
> >>> config file contains a list directories to search within, yet if I have 3
> >>> toolchains in a single directory, there's no way to select which one I 
> >>> want
> >>> to use, is there?
> >>>
> >>> In other words, a config file that contains:
> >>>
> >>> [toolchain]
> >>> distro-packages: /usr/bin
> >>>
> >>> ... finds the following toolchains:
> >>>
> >>> [swarren@swarren-lx1 u-boot]$ ./tools/buildman/buildman \
> >>> --list-tool-chains
> >>> Scanning for tool chains
> >>>- scanning path '/usr/bin'
> >>>   - looking in '/usr/bin/.'
> >>>  - found '/usr/bin/./arm-linux-gnueabi-gcc'
> >>>  - found '/usr/bin/./arm-linux-gnueabihf-gcc'
> >>>  - found '/usr/bin/./arm-none-eabi-gcc'
> >>> (That's 3 AArch32 toolchains found)
> >>>  - found '/usr/bin/./winegcc'
> >>>  - found '/usr/bin/./aarch64-linux-gnu-gcc'
> >>>  - found '/usr/bin/./gcc'
> >>>  - found '/usr/bin/./c89-gcc'
> >>>  - found '/usr/bin/./x86_64-linux-gnu-gcc'
> >>>  - found '/usr/bin/./i586-mingw32msvc-gcc'
> >>>  - found '/usr/bin/./c99-gcc'
> >>>   - looking in '/usr/bin/bin'
> >>>   - looking in '/usr/bin/usr/bin'
> >>> Tool chain test:  OK
> >>> Tool chain test:  OK
> >>> Tool chain test:  OK
> >>> Tool chain test:  OK
> >>> Tool chain test:  OK
> >>> Tool chain test:  OK
> >>> Tool chain test:  OK

Re: [U-Boot] [ANN] U-Boot v2015.10 released

[Wolfgang Denk]

Dear Tom,

In message <20151020153139.GK23893@bill-the-cat> you wrote:
> 
> > It appears you did not push the tag, though?
> 
> Oops, fixed.

OK, and here are the release statistics; for the full version please
see  http://www.denx.de/wiki/U-Boot/UbootStat_2015_10


Processed 2069 csets from 182 developers
30 employers found
A total of 180893 lines added, 90724 removed (delta 90169)

Developers with the most changesets
Simon Glass376 (18.2%)
Marek Vasut263 (12.7%)
Bin Meng   157 (7.6%)
Masahiro Yamada117 (5.7%)
Hans de Goede   92 (4.4%)
Peng Fan81 (3.9%)
Stefan Roese60 (2.9%)
Paul Kocialkowski   42 (2.0%)
Stephen Warren  39 (1.9%)
Fabio Estevam   38 (1.8%)
...

Developers with the most changed lines
Simon Glass   68254 (27.8%)
Stefan Roese  30346 (12.4%)
Masahiro Yamada   23310 (9.5%)
Marek Vasut   19480 (7.9%)
Bin Meng  14028 (5.7%)
Adrian Alonso 10199 (4.2%)
Dinh Nguyen   7920 (3.2%)
Tom Rini  7247 (3.0%)
Peng Fan  5138 (2.1%)
Tom Warren4975 (2.0%)
...

Developers with the most lines removed
Masahiro Yamada   8811 (9.7%)
Simon Glass   8130 (9.0%)
Kun-Hua Huang 2054 (2.3%)
Ulf Magnusson  346 (0.4%)
Josh Wu 70 (0.1%)
Peter Robinson  64 (0.1%)
Alexander Stein 26 (0.0%)
Adam Ford   20 (0.0%)
Andrew Ruder15 (0.0%)
Shaohui Xie 13 (0.0%)
...

Developers with the most signoffs (total 328)
Tom Warren  65 (19.8%)
Hans de Goede   24 (7.3%)
Simon Glass 22 (6.7%)
Ye.Li   17 (5.2%)
Prabhakar Kushwaha  16 (4.9%)
Michal Simek14 (4.3%)
Tom Rini13 (4.0%)
Peng Fan11 (3.4%)
Stephen Warren  10 (3.0%)
Minkyu Kang  8 (2.4%)
...

Developers with the most reviews (total 557)
York Sun   120 (21.5%)
Bin Meng   105 (18.9%)
Tom Rini84 (15.1%)
Simon Glass 82 (14.7%)
Jagan Teki  34 (6.1%)
Heiko Schocher  32 (5.7%)
Stefano Babic   17 (3.1%)
Linus Walleij   11 (2.0%)
Marek Vasut 10 (1.8%)
Joe Hershberger  9 (1.6%)
...

Developers with the most test credits (total 136)
Bin Meng21 (15.4%)
Simon Glass 20 (14.7%)
Przemyslaw Marczak  13 (9.6%)
Łukasz Majewski11 (8.1%)
Stephen Warren   8 (5.9%)
Marcel Ziswiler  7 (5.1%)
Sylvain Lemieux  6 (4.4%)
Fabio Estevam5 (3.7%)
Stefan Roese 4 (2.9%)
Andrew Bradford  4 (2.9%)
...

Developers who gave the most tested-by credits (total 136)
Simon Glass 24 (17.6%)
Bin Meng16 (11.8%)
Stephen Warren   7 (5.1%)
Vladimir Zapolskiy   6 (4.4%)
Tim Harvey   6 (4.4%)
Peng Fan 6 (4.4%)
Alexander Stein  6 (4.4%)
Paul Kocialkowski5 (3.7%)
Tom Rini 4 (2.9%)
Chris Packham4 (2.9%)
...

Developers with the most report credits (total 28)
Yan Liu  3 (10.7%)
Thierry Reding   2 (7.1%)
Nishanth Menon   2 (7.1%)
Simon Glass  1 (3.6%)
Stephen Warren   1 (3.6%)
Tim Harvey   1 (3.6%)
Paul Kocialkowski1 (3.6%)
Przemyslaw Marczak   1 (3.6%)
Stefan Agner 1 (3.6%)
Andrew Bradford  1 (3.6%)
...

Developers who gave the most report credits (total 28)
Lokesh Vutla 7 (25.0%)
Simon Glass  3 (10.7%)
Stephen Warren   3 (10.7%)
Fabio Estevam3 (10.7%)
Stefan Roese 2 (7.1%)
Thierry Reding   1 (3.6%)
Nishanth Menon   1 (3.6%)
Bin Meng 1 (3.6%)
Tom Rini 1 (3.6%)
Chris Packham1 (3.6%)
...

Top changeset contributors by employer
(Unknown)  568 (27.5%)
Google, Inc.   376 (18.2%)
DENX Software Engineering  354 (17.1%)
Freescale  303 (14.6%)
Red Hat 92 (4.4%)
NVidia  75 (3.6%)
Texas Instruments   69 (3.3%)
Xilinx  50 (2.4%)
CompuLab32 (1.5%)
Konsulko Group  29 (1.4%)
...

Top lines changed by employer
Google, Inc.  68254 (27.8%)
(Unknown) 67079 (27.3%)
DENX Software Engineering 53855 (21.9%)
Freescale 26609 (10.8%)
NVidia7344 (3.0%)
Konsulko Group7237 (2.9%)
Red Hat   

Re: [U-Boot] [ANN] U-Boot v2015.10 released

[Tom Rini]

On Tue, Oct 20, 2015 at 09:44:12PM +0200, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20151020153139.GK23893@bill-the-cat> you wrote:
> > 
> > > It appears you did not push the tag, though?
> > 
> > Oops, fixed.
> 
> OK, and here are the release statistics; for the full version please
> see  http://www.denx.de/wiki/U-Boot/UbootStat_2015_10
[snip]
> Developers with the most reviews (total 557)
> York Sun   120 (21.5%)
> Bin Meng   105 (18.9%)
> Tom Rini84 (15.1%)
> Simon Glass 82 (14.7%)
> Jagan Teki  34 (6.1%)
> Heiko Schocher  32 (5.7%)
> Stefano Babic   17 (3.1%)
> Linus Walleij   11 (2.0%)
> Marek Vasut 10 (1.8%)
> Joe Hershberger  9 (1.6%)
> ...
> 
> Developers with the most test credits (total 136)
> Bin Meng21 (15.4%)
> Simon Glass 20 (14.7%)
> Przemyslaw Marczak  13 (9.6%)
> Łukasz Majewski11 (8.1%)
> Stephen Warren   8 (5.9%)
> Marcel Ziswiler  7 (5.1%)
> Sylvain Lemieux  6 (4.4%)
> Fabio Estevam5 (3.7%)
> Stefan Roese 4 (2.9%)
> Andrew Bradford  4 (2.9%)
> ...
> 
> Developers who gave the most tested-by credits (total 136)
> Simon Glass 24 (17.6%)
> Bin Meng16 (11.8%)
> Stephen Warren   7 (5.1%)
> Vladimir Zapolskiy   6 (4.4%)
> Tim Harvey   6 (4.4%)
> Peng Fan 6 (4.4%)
> Alexander Stein  6 (4.4%)
> Paul Kocialkowski5 (3.7%)
> Tom Rini 4 (2.9%)
> Chris Packham4 (2.9%)

I'm very happy to see that these numbers have been growing over time.
It's important that we review eachothers code (and test it when
possible) and report that back.  It's also an "easy" way to start
getting involved in the community.  So thanks a lot to everyone that's
been doing this, especially the people that didn't quite make top 10!

-- 
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] [ANN] U-Boot v2015.10 released

[Wolfgang Denk]

Dear Igor,

In message <56266969.9070...@compulab.co.il> you wrote:
>
> >> It appears you did not push the tag, though?
> > 
> > Oops, fixed.
> 
> I've just pulled and nope, not there...

Should be fixed.  Please try again.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Every little picofarad has a nanohenry all its own.  - Don Vonada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 05/14] fastboot: Move fastboot response functions to fastboot core

[Tom Rini]

On Thu, Oct 15, 2015 at 02:34:13PM +0200, Maxime Ripard wrote:

> The functions and a few define to generate a fastboot message to be sent
> back to the host were so far duplicated among the users.
> 
> Move them all to a common place.
> 
> Signed-off-by: Maxime Ripard 

Reviewed-by: Tom Rini 

-- 
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] [PATCH v2 11/14] sparse: Rename the file and header

[Tom Rini]

On Thu, Oct 15, 2015 at 02:34:19PM +0200, Maxime Ripard wrote:

> The Android sparse image format is currently supported through a file
> called aboot, which isn't really such a great name, since the sparse image
> format is only used for transferring data with fastboot.
> 
> Rename the file and header to a file called "sparse", which also makes it
> consistent with the header defining the image structures.
> 
> Signed-off-by: Maxime Ripard 

Reviewed-by: Tom Rini 

-- 
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] [PATCH v2 08/14] sparse: Implement several chunks flashing

[Tom Rini]

On Thu, Oct 15, 2015 at 02:34:16PM +0200, Maxime Ripard wrote:

> The fastboot client will split the sparse images into several chunks if the
> image that it tries to flash is bigger than what the device can handle.
> 
> In such a case, the bootloader is supposed to retain the last offset to
> which it wrote to, so that it can resume the writes at the right offset
> when flashing the next chunk.
> 
> Retain the last offset we used, and use the session ID to know if we need
> it or not.
> 
> Signed-off-by: Maxime Ripard 

Reviewed-by: Tom Rini 

-- 
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] [PATCH V2 2/3] mx7: psci: add basic psci support

[Li Frank]

> -Original Message-
> From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net]
> Sent: Tuesday, October 20, 2015 4:04 PM
> To: Li Frank-B20596 
> Cc: Fan Peng-B51431 ; Estevam Fabio-R49496
> ; u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH V2 2/3] mx7: psci: add basic psci support
> 
> Hello Li,
> 
> (sorry for my dropping other receipients from the discussion; restoring them
> 
> On Tue, 20 Oct 2015 15:04:40 +, Li Frank 
> wrote:
> >
> >
> > > -Original Message-
> > > From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net]
> > > Sent: Tuesday, October 20, 2015 9:55 AM
> > > To: Li Frank-B20596 
> > > Subject: Re: [U-Boot] [PATCH V2 2/3] mx7: psci: add basic psci
> > > support
> > >
> > > Hello Li,
> > >
> > > On Tue, 20 Oct 2015 14:29:46 +, Li Frank
> > > 
> > > wrote:
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net]
> > > > > Sent: Tuesday, October 20, 2015 9:25 AM
> > > > > To: Li Frank-B20596 
> > > > > Cc: Fan Peng-B51431 ;
> > > > > u-boot@lists.denx.de; Estevam Fabio-R49496
> > > > > 
> > > > > Subject: Re: [U-Boot] [PATCH V2 2/3] mx7: psci: add basic psci
> > > > > support
> > > > >
> > > > > Hello Li,
> > > > >
> > > > > On Tue, 20 Oct 2015 14:05:45 +, Li Frank
> > > > > 
> > > > > wrote:
> > > > > >
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: Peng Fan [mailto:peng@freescale.com]
> > > > > > > Sent: Tuesday, October 20, 2015 1:00 AM
> > > > > > > To: u-boot@lists.denx.de
> > > > > > > Cc: Fan Peng-B51431 ; Li
> > > > > > > Frank-B20596 ; Stefano Babic
> > > > > > > ; Estevam
> > > > > > > Fabio-
> > > > > > > R49496 
> > > > > > > Subject: [PATCH V2 2/3] mx7: psci: add basic psci support
> > > > > > >
> > > > > > > 1. add basic psci support for imx7 chip.
> > > > > > > 2. support cpu_on and cpu_off.
> > > > > > > 3. switch to non-secure mode when boot linux kernel.
> > > > > > > 4. set csu allow accessing all peripherial register in non-secure
> mode.
> > > > > > >
> > > > > > > Signed-off-by: Frank Li 
> > > > > > > Signed-off-by: Peng Fan 
> > > > > > > Cc: Stefano Babic 
> > > > > > > Cc: Fabio Estevam 
> > > > > > > ---
> > > > > > >
> > > > > > > Changes V2:
> > > > > > >  Refine commit msg.
> > > > > > >
> > > > > > >  arch/arm/cpu/armv7/mx7/Makefile   |  4 ++
> > > > > > >  arch/arm/cpu/armv7/mx7/psci-mx7.c | 78
> > > > > > > +++
> > > > > > >  arch/arm/cpu/armv7/mx7/psci.S | 54
> > > +++
> > > > > > >  arch/arm/cpu/armv7/mx7/soc.c  |  9 +
> > > > > > >  4 files changed, 145 insertions(+)  create mode 100644
> > > > > > > arch/arm/cpu/armv7/mx7/psci-mx7.c  create mode
> > > > > > > 100644 arch/arm/cpu/armv7/mx7/psci.S
> > > > > > >
> > > > > > > diff --git a/arch/arm/cpu/armv7/mx7/Makefile
> > > > > > > b/arch/arm/cpu/armv7/mx7/Makefile index e6ecef0..f25461c
> > > > > > > 100644
> > > > > > > --- a/arch/arm/cpu/armv7/mx7/Makefile
> > > > > > > +++ b/arch/arm/cpu/armv7/mx7/Makefile
> > > > > > > @@ -6,3 +6,7 @@
> > > > > > >  #
> > > > > > >
> > > > > > >  obj-y:= soc.o clock.o clock_slice.o
> > > > > > > +
> > > > > > > +ifdef CONFIG_ARMV7_PSCI
> > > > > > > +obj-y  += psci.o psci-mx7.o
> > > > > >
> > > > > > Obj-y += psci-mx7.o psci.o
> > > > > > The otherwise psci_text_end will not be last one.
> > > > >
> > > > > I don't like this object module order sensitivity.
> > > > >
> > > > > The object module order of secure code modules should not affect
> > > > > the resulting binary to the point of possibly preventing it from
> > > > > working
> > > > > -- after all, the object module order of 'vanilla' image code
> > > > > does not matter (1). We don't have this kind of problem when
> > > > > defining the image start and end, why would we have it with the
> > > > > secure code start and
> > > end?
> > > >
> > > > Secure code use psci_text_end to calculate stack top point.
> > >
> > > Yes, and that does not require defining psci_text_end in an object
> > > module, nor does it require specific object module ordering.
> >
> > If psci_text_end in mid of secure text,
> > And psci_text_end + 1k < total secure text size,   stack will overwrite the 
> > code.
> 
> This is a good reason to allocate the PSCCI stack and create a symbol for its 
> top
> in the linker script.
> 
> > > > > IOW, psci_text_end could (and should) be defined in the linker
> > > > > script, not in an object module.
> > > >
> > > > I agree.  The other platform put psci_text_end to object 

[U-Boot] Please pull u-boot-sunxi master

[Hans de Goede]

Hi Tom,

Here is the first pull-req for sunxi, it contains some none
sunxi specific patches which I've picked up as sunxi is the first
user of them, these patches have been reviewed by you and/or
Simon Glass.

Highlights:
-Only simple-malloc in SPL (also post "reloc") to save space
-Remove a couple of board-configs which have been replaced with more generic 
shared board-configs
-Fully Kconfig-ify the pmic and voltage selection
-Add support for the BPI-M2 and the CHIP

The following changes since commit 5ec0003b19cbdf06ccd6941237cbc0d1c3468e2d:

  Prepare v2015.10 (2015-10-19 19:59:38 -0400)

are available in the git repository at:

  http://git.denx.de/u-boot-sunxi.git master

for you to fetch changes up to fd8133b725198978865ead730ff20d3991e05f20:

  sunxi: Add CHIP support (2015-10-20 22:48:29 +0200)


Hans de Goede (19):
  spl: spl_relocate_stack_gd: Do not unnecessarily clear bss
  malloc_simple: Add Kconfig option for using only malloc_simple in the SPL
  malloc_simple: Add support for switching to DRAM heap
  sunxi: Enable CONFIG_SPL_STACK_R
  sunxi: Switch to using malloc_simple for the spl
  sunxi: Remove board defconfig-s for specific Q8 tablet PCB-s
  sunxi: Kconfig-ify CONFIG_AXP152_POWER and _AXP209_POWER
  sunxi: power: Make all voltages configurable through Kconfig
  sunxi: power: Unify axp pmic function names
  sunxi: power: Change A23/A33 VDD-SYS default from 1.2V to 1.1V
  sunxi: power: Change A23/A33 aldo1 default voltage to 3.0V
  sunxi: power: Use pmic_bus functions for axp152 / axp209 driver
  sunxi: power: Drop protection against multiple calls from axp221 
axp_init()
  sunxi: power: Add support for disabling axp209 regulators
  sunxi: power: Change axp209 LDO3 and LDO4 default to disabled
  sunxi: power: Columbus: only enable ELDO3 when necessary
  sunxi: Add a bootcmd_sunxi_compat to the default environment to boot old 
kernels
  sunxi: Fix sorting of boards in MAINTAINERS
  sunxi: Add defconfig for the Sinovoip BPI-M2 board

Maxime Ripard (8):
  sunxi: Add support for android boot image
  fastboot: Implement OEM format only when we have MMC support
  mmc: Add generic Kconfig option
  sunxi: board: Only try to use the MMC related functions if enabled
  sunxi: Use Kconfig CONFIG_MMC
  sun5i: Sync the DTSI with the kernel
  axp209: Sync the DTSI with the kernel
  sunxi: Add CHIP support

 Kconfig|  20 ++
 arch/arm/Kconfig   |   2 +
 arch/arm/cpu/armv7/sunxi/board.c   |   7 +-
 arch/arm/cpu/armv7/sunxi/cpu_info.c|   4 +-
 arch/arm/cpu/armv7/sunxi/usb_phy.c |   9 -
 arch/arm/dts/Makefile  |  12 +-
 arch/arm/dts/axp209.dtsi   |   5 +
 arch/arm/dts/sun5i-a10s.dtsi   |  47 -
 arch/arm/dts/sun5i-a13-forfun-q88db.dts|  29 ---
 arch/arm/dts/sun5i-a13-tzx-q8-713b7.dts|  29 ---
 arch/arm/dts/sun5i-a13.dtsi|  28 ++-
 ...sun8i-a23-ippo-q8h-v5.dts => sun5i-r8-chip.dts} | 158 
 .../{sun8i-a23-ippo-q8h-v1.2.dts => sun5i-r8.dtsi} |  25 ++-
 arch/arm/dts/sun5i.dtsi|  22 +++
 arch/arm/dts/sun6i-a31.dtsi|  18 ++
 ...q8h-v1.2.dts => sun6i-a31s-sinovoip-bpi-m2.dts} | 153 ++-
 arch/arm/dts/sun8i-a33-et-q8-v1.6.dts  |  88 -
 board/sunxi/Kconfig|   8 +
 board/sunxi/MAINTAINERS|  26 +--
 board/sunxi/board.c|  68 +++
 common/malloc_simple.c |   2 +-
 common/spl/spl.c   |  13 +-
 configs/A10-OLinuXino-Lime_defconfig   |   2 +-
 configs/A10s-OLinuXino-M_defconfig |   3 +-
 configs/A13-OLinuXinoM_defconfig   |   1 +
 configs/A13-OLinuXino_defconfig|   2 +-
 configs/A20-OLinuXino-Lime2_defconfig  |   2 +-
 configs/A20-OLinuXino-Lime_defconfig   |   2 +-
 configs/A20-OLinuXino_MICRO_defconfig  |   2 +-
 configs/A20-Olimex-SOM-EVB_defconfig   |   2 +-
 configs/Ainol_AW1_defconfig|   1 -
 configs/Ampe_A76_defconfig |   2 +-
 configs/Auxtek-T003_defconfig  |   2 +-
 configs/Auxtek-T004_defconfig  |   2 +-
 configs/Bananapi_defconfig |   2 +-
 configs/Bananapro_defconfig|   2 +-
 configs/CHIP_defconfig |  14 ++
 configs/CSQ_CS908_defconfig|   4 +-
 configs/Chuwi_V7_CW0825_defconfig  |   1 -
 configs/Colombus_defconfig | 

Re: [U-Boot] [PATCH V2 2/3] mx7: psci: add basic psci support

[Albert ARIBAUD]

Hello Li,

(sorry for my dropping other receipients from the discussion; restoring
them

On Tue, 20 Oct 2015 15:04:40 +, Li Frank 
wrote:
> 
> 
> > -Original Message-
> > From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net]
> > Sent: Tuesday, October 20, 2015 9:55 AM
> > To: Li Frank-B20596 
> > Subject: Re: [U-Boot] [PATCH V2 2/3] mx7: psci: add basic psci support
> > 
> > Hello Li,
> > 
> > On Tue, 20 Oct 2015 14:29:46 +, Li Frank 
> > wrote:
> > >
> > >
> > > > -Original Message-
> > > > From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net]
> > > > Sent: Tuesday, October 20, 2015 9:25 AM
> > > > To: Li Frank-B20596 
> > > > Cc: Fan Peng-B51431 ; u-boot@lists.denx.de;
> > > > Estevam Fabio-R49496 
> > > > Subject: Re: [U-Boot] [PATCH V2 2/3] mx7: psci: add basic psci
> > > > support
> > > >
> > > > Hello Li,
> > > >
> > > > On Tue, 20 Oct 2015 14:05:45 +, Li Frank
> > > > 
> > > > wrote:
> > > > >
> > > > >
> > > > > > -Original Message-
> > > > > > From: Peng Fan [mailto:peng@freescale.com]
> > > > > > Sent: Tuesday, October 20, 2015 1:00 AM
> > > > > > To: u-boot@lists.denx.de
> > > > > > Cc: Fan Peng-B51431 ; Li Frank-B20596
> > > > > > ; Stefano Babic ;
> > > > > > Estevam
> > > > > > Fabio-
> > > > > > R49496 
> > > > > > Subject: [PATCH V2 2/3] mx7: psci: add basic psci support
> > > > > >
> > > > > > 1. add basic psci support for imx7 chip.
> > > > > > 2. support cpu_on and cpu_off.
> > > > > > 3. switch to non-secure mode when boot linux kernel.
> > > > > > 4. set csu allow accessing all peripherial register in non-secure 
> > > > > > mode.
> > > > > >
> > > > > > Signed-off-by: Frank Li 
> > > > > > Signed-off-by: Peng Fan 
> > > > > > Cc: Stefano Babic 
> > > > > > Cc: Fabio Estevam 
> > > > > > ---
> > > > > >
> > > > > > Changes V2:
> > > > > >  Refine commit msg.
> > > > > >
> > > > > >  arch/arm/cpu/armv7/mx7/Makefile   |  4 ++
> > > > > >  arch/arm/cpu/armv7/mx7/psci-mx7.c | 78
> > > > > > +++
> > > > > >  arch/arm/cpu/armv7/mx7/psci.S | 54
> > +++
> > > > > >  arch/arm/cpu/armv7/mx7/soc.c  |  9 +
> > > > > >  4 files changed, 145 insertions(+)  create mode 100644
> > > > > > arch/arm/cpu/armv7/mx7/psci-mx7.c  create mode
> > > > > > 100644 arch/arm/cpu/armv7/mx7/psci.S
> > > > > >
> > > > > > diff --git a/arch/arm/cpu/armv7/mx7/Makefile
> > > > > > b/arch/arm/cpu/armv7/mx7/Makefile index e6ecef0..f25461c 100644
> > > > > > --- a/arch/arm/cpu/armv7/mx7/Makefile
> > > > > > +++ b/arch/arm/cpu/armv7/mx7/Makefile
> > > > > > @@ -6,3 +6,7 @@
> > > > > >  #
> > > > > >
> > > > > >  obj-y  := soc.o clock.o clock_slice.o
> > > > > > +
> > > > > > +ifdef CONFIG_ARMV7_PSCI
> > > > > > +obj-y  += psci.o psci-mx7.o
> > > > >
> > > > > Obj-y += psci-mx7.o psci.o
> > > > > The otherwise psci_text_end will not be last one.
> > > >
> > > > I don't like this object module order sensitivity.
> > > >
> > > > The object module order of secure code modules should not affect the
> > > > resulting binary to the point of possibly preventing it from working
> > > > -- after all, the object module order of 'vanilla' image code does
> > > > not matter (1). We don't have this kind of problem when defining the
> > > > image start and end, why would we have it with the secure code start and
> > end?
> > >
> > > Secure code use psci_text_end to calculate stack top point.
> > 
> > Yes, and that does not require defining psci_text_end in an object module, 
> > nor
> > does it require specific object module ordering.
> 
> If psci_text_end in mid of secure text, 
> And psci_text_end + 1k < total secure text size,   stack will overwrite the 
> code. 

This is a good reason to allocate the PSCCI stack and create a symbol
for its top in the linker script.

> > > > IOW, psci_text_end could (and should) be defined in the linker
> > > > script, not in an object module.
> > >
> > > I agree.  The other platform put psci_text_end to object module.
> > 
> > Which 'other platform' is this?
> 
> arch/arm/cpu/armv7/sunxi
> arch/arm/cpu/armv7/ls102xa

Ok, but they all use the same routine for moving the PSCI code and
setting its stack, right?

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

Re: [U-Boot] [PATCH v2 00/14] Implement fastboot over NAND and sparse transfers

[Tom Rini]

On Tue, Oct 20, 2015 at 03:32:27PM -0400, Tom Rini wrote:
> On Mon, Oct 19, 2015 at 10:17:46AM +0200, Maxime Ripard wrote:
> > On Sat, Oct 17, 2015 at 04:42:09PM +0200, Hans de Goede wrote:
> > > Hi,
> > > 
> > > On 17-10-15 15:59, Hans de Goede wrote:
> > > >Hi,
> > > >
> > > >On 15-10-15 14:34, Maxime Ripard wrote:
> > > >>Hi everyone,
> > > >>
> > > >>Here is the second attempt at getting fastboot flashing functions
> > > >>working on top of a NAND, for arbitraly large images.
> > > >>
> > > >>While the NAND support itself was quite easy to do, the support for
> > > >>the Android sparse images was quite difficult to add, and ended up
> > > >>being a quite huge refactoring of the sparse parse already in tree,
> > > >>that was tied to the MMC layer.
> > > >>
> > > >>This serie has been tested on a CHIP and an A13-Olinuxino, two
> > > >>Allwinner devices, the CHIP for the NAND, and the Cubietruck to test
> > > >>the MMC.
> > > >>
> > > >>Let me know what you think,
> > > >>Maxime
> > > >
> > > >Thanks, I've applied the 3 sunxi patches (12 - 14) to u-boot-sunxi/next,
> > > >with the commit msg fixup suggested by Ian.
> > > 
> > > Looks like I've spoken too soon, the patch for enabling otg on the 
> > > cubietruck
> > > causes build errors:
> > > 
> > > arm-linux-gnu-ld.bfd: error: 
> > > /usr/lib/gcc/arm-linux-gnueabi/5.2.1/libgcc.a(_udivmoddi4.o) uses VFP 
> > > register arguments, u-boot does not
> > > arm-linux-gnu-ld.bfd: failed to merge target specific data of file 
> > > /usr/lib/gcc/arm-linux-gnueabi/5.2.1/libgcc.a(_udivmoddi4.o)
> > > Makefile:1173: recipe for target 'u-boot' failed
> > > make: *** [u-boot] Error 1
> > > 
> > > Usually this means that some code is using 64 bit int division
> > > without using the proper macros for this.
> > > 
> > > For some reason I'm not seeing the same on the A13-OlinuxIno, that patch
> > > for that seems to be missing the id pin, which could have something to do
> > > with this.
> > > 
> > > I think this is caused by some 64 bit math in the fastboot code somewhere 
> > > ...
> > > 
> > > For now I've dropped these 2 patches from u-boot-sunxi/next
> > 
> > Which 2 patches then? Cubietruck and this one?
> > 
> > Do you have a toolchain tarball for this so that I can test easily?
> 
> The arm-none-eabi toolchain that's apt-get'able should show this.  You
> could even fudge this by (I _think_) forcing U-Boot to build with
> -march=armv5te rather than armv7.  I _might_ even be able to spot it in
> the patch review :)

... I take it back, I couldn't locally reproduce this with the
arm-none-eabi toolchain I have around and 12-14 applied in a local
branch.  Hans, last time I saw this error (last night even) there was a
bit more in the log about which file/function was doing the mis-match.
Do you have the full error log handy?  Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v2 04/14] sparse: Simplify multiple logic

[Tom Rini]

On Thu, Oct 15, 2015 at 02:34:12PM +0200, Maxime Ripard wrote:

> To check the alignment of the image blocks to the storage blocks, the
> current code uses a convoluted syntax, while a simple mod also does the
> work.
> 
> Signed-off-by: Maxime Ripard 

Reviewed-by: Tom Rini 

-- 
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] [PATCH v2 09/14] fastboot: Implement NAND backend

[Tom Rini]

On Thu, Oct 15, 2015 at 02:34:17PM +0200, Maxime Ripard wrote:

> So far the fastboot code was only supporting MMC-backed devices for its
> flashing operations (flash and erase).
> 
> Add a storage backend for NAND-backed devices.
> 
> Signed-off-by: Maxime Ripard 

This is mutually exclusive with MMC support, right?  If so, it's not
quite written that way in the #ifdef's so I think it need to be down in
say:

> @@ -569,6 +572,11 @@ static void cb_flash(struct usb_ep *ep, struct 
> usb_request *req)
>  (void *)CONFIG_FASTBOOT_BUF_ADDR,
>  download_bytes, response);
>  #endif
> +#ifdef CONFIG_FASTBOOT_FLASH_NAND_DEV
> + fb_nand_flash_write(cmd, fastboot_flash_session_id,
> + (void *)CONFIG_FASTBOOT_BUF_ADDR,
> + download_bytes, response);
> +#endif

With #elif/#error "Fastboot enabled but without any backing store
support" and we drop the #error once this is Kconfig'zied.

-- 
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] [PATCH V3 05/10] fat: ff: read max contiguous file data

[Stephen Warren]

On 10/20/2015 01:10 PM, Tom Rini wrote:

On Tue, Oct 20, 2015 at 12:57:32PM -0600, Stephen Warren wrote:

On 10/02/2015 12:06 AM, Stephen Warren wrote:

Enhance f_read() to find the maximum contiguous set of clusters to read,
and read it all at once (which is fast) rather one by one (which is
slow).


Hmm. I had hoped that the author of ff.c would accept this patch
upstream, so we could pick up a later upstream version that included
this patch. However, it seems the author of ff.c has a policy of not
accepting outside contributions:

http://elm-chan.org/fsw/ff/bd/?show=2472
(That's a link to the author's reply to my patch, on the forum
system associated with his/her SW)


The bit about the license is at
http://elm-chan.org/fsw/ff/en/appnote.html#license


I wonder how much of a liability incorporating ff.c into U-Boot will
be, if we can't ever get any fixes merged upstream. Perhaps we just
fork it, although I had hoped we'd be able to keep picking up new
versions.


Arg, that really does take away one of the potential nice features.  I
guess, sadly, at this point I'd rather stick with the version we have
unless you want to deal with re-syncing their releases but still
effectively doing a fork (so that we can also make use of caches which I
think you said before you thought might be part of the performance
problem.


FWIW, the caching (of FAT bitmap, not CPU memory) turned out not to be 
an issue at all; it was just my wild conjecture before I'd investigated 
the read performance issues.

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

Re: [U-Boot] [ANN] U-Boot v2015.10 released

[Wolfgang Denk]

Dear Tom,

In message <20151020195044.GG23893@bill-the-cat> you wrote:
> 
> I'm very happy to see that these numbers have been growing over time.
> It's important that we review eachothers code (and test it when
> possible) and report that back.  It's also an "easy" way to start
> getting involved in the community.  So thanks a lot to everyone that's
> been doing this, especially the people that didn't quite make top 10!

Full ACK here - and keep in mind that _everybody_ should be listed on
the web page (and please feel free to contactme if you find yourself
missing there).

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Some programming languages manage to  absorb  change,  but  withstand
progress.  -- Epigrams in Programming, ACM SIGPLAN Sept. 1982
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Relocation issue - need help!

[Tom Rini]

On Tue, Oct 20, 2015 at 04:06:51PM -0500, Andy Fleming wrote:
> On Fri, Oct 16, 2015 at 8:14 AM, Joakim Tjernlund
>  wrote:
> > On Fri, 2015-10-16 at 07:47 -0400, Tom Rini wrote:
> >> On Fri, Oct 16, 2015 at 06:55:58AM +, Joakim Tjernlund wrote:
> >> > On Thu, 2015-10-15 at 17:58 -0400, Tom Rini wrote:
> >> > > On Thu, Oct 15, 2015 at 03:56:09PM +, Joakim Tjernlund wrote:
> >> > > > On Tue, 2015-10-06 at 11:17 +, Joakim Tjernlund wrote:
> >> > > > > On Thu, 2015-10-01 at 08:57 +, Joakim Tjernlund wrote:
> >> > > > > > On Wed, 2015-09-30 at 21:35 +0200, Marek Vasut wrote:
> >> > > > > > > On Wednesday, September 30, 2015 at 08:24:10 PM, Andy Fleming 
> >> > > > > > > wrote:
> >> > > > > > >
> >> > > > > > > Hi!
> >> > > > > > >
> >> > > > > > > > On Thu, Oct 23, 2014 at 8:10 AM, Wolfgang Denk 
> >> > > > > > > >  wrote:
> >> > > > > > > > > Dear Joakim, dear Dirk,
> >> > > > > > > > >
> >> > > > > > > > > In message  >> > > > > > > c1257d7a.0024d...@transmode.se> you wrote:
> >> > > > > > > > > > Ouch, that was a nasty surprise.
> >> > > > > > > > >
> >> > > > > > > > > Indeed.
> >> > > > > > > > >
> >> > > > > > > > > > > In my original mail I referenced this potential 
> >> > > > > > > > > > > solution, at least it
> >> > > > > > > > > > > worked for me:
> >> > > > > > > > > > > https://gcc.gnu.org/ml/gcc-help/2014-02/msg00054.html
> >> > > > > > > > > >
> >> > > > > > > > > > That looks like the correct fix but I presume both 
> >> > > > > > > > > > .data.rel.ro and
> >> > > > > > > > > > data.rel.ro.local should be added?
> >> > > > > > > > >
> >> > > > > > > > > I can confirm:
> >> > > > > > > > >
> >> > > > > > > > > 1) The problem was observed with gcc 4.8.1 [as in Yocto 
> >> > > > > > > > > 1.5.x / ELDK
> >> > > > > > > > >
> >> > > > > > > > >5.5.x].
> >> > > > > > > > >
> >> > > > > > > > > 2) Switching back to gcc 4.7.2 [as in Yocto 1.4 / ELDK 
> >> > > > > > > > > 5.4] makes the
> >> > > > > > > > >
> >> > > > > > > > >problem go away.
> >> > > > > > > > >
> >> > > > > > > > > 3) Switching forward to gcc 4.9.1 [as in Yocto 1.7 / ELDK 
> >> > > > > > > > > 5.7] makes
> >> > > > > > > > >
> >> > > > > > > > >the problem go away.
> >> > > > > > > > >
> >> > > > > > > > > 4) For the problemativ 4.8.x versions of GCC, the 
> >> > > > > > > > > following patch
> >> > > > > > > > >
> >> > > > > > > > >apparently solves the problem for my (MPC5200 based) 
> >> > > > > > > > > board - guess
> >> > > > > > > > >this would have to be applied to all .lds files...
> >> > > > > > > > >
> >> > > > > > > > > diff --git a/arch/powerpc/cpu/mpc5xxx/u-boot.lds
> >> > > > > > > > > b/arch/powerpc/cpu/mpc5xxx/u-boot.lds index 
> >> > > > > > > > > cd9e23f..82c86d7 100644
> >> > > > > > > > > --- a/arch/powerpc/cpu/mpc5xxx/u-boot.lds
> >> > > > > > > > > +++ b/arch/powerpc/cpu/mpc5xxx/u-boot.lds
> >> > > > > > > > > @@ -27,6 +27,8 @@ SECTIONS
> >> > > > > > > > >
> >> > > > > > > > >{
> >> > > > > > > > >
> >> > > > > > > > >  _GOT2_TABLE_ = .;
> >> > > > > > > > >  KEEP(*(.got2))
> >> > > > > > > > >
> >> > > > > > > > > +KEEP(*(.data.rel.ro))
> >> > > > > > > > > +KEEP(*(.data.rel.ro.local))
> >> > > > > > > > >
> >> > > > > > > > >  KEEP(*(.got))
> >> > > > > > > > >  PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4);
> >> > > > > > > > >  _FIXUP_TABLE_ = .;
> >> > > > > > > > >
> >> > > > > > > > > Given that GCC 4.9.1 apparently solves this issue I wonder 
> >> > > > > > > > > which
> >> > > > > > > > > approach we should take?
> >> > > > > > > > >
> >> > > > > > > > > Should we blacklist GCC 4.8.x (and 4.9.0) like the kernel 
> >> > > > > > > > > folks are
> >> > > > > > > > > doing [1] ?
> >> > > > > > > > >
> >> > > > > > > > > [1] https://lkml.org/lkml/2014/10/10/272
> >> > > > > > > >
> >> > > > > > > > Was there a resolution to this thread? I just spent a bunch 
> >> > > > > > > > of time
> >> > > > > > > > trying to figure out why u-boot was crashing, and eventually
> >> > > > > > > > determined that switching from 4.9.0 to 4.6.3 solved the 
> >> > > > > > > > problem.
> >> > > > > > > > Should I submit a patch to do what was suggested above? Or 
> >> > > > > > > > add the
> >> > > > > > > > "blacklist" patch? If so, it should be noted that 4.9.0 is 
> >> > > > > > > > the current
> >> > > > > > > > default installed when you ask buildman to install a powerpc 
> >> > > > > > > > cross
> >> > > > > > > > compiler...
> >> > > > > > >
> >> > > > > > > Blacklist patch please, thank you!
> >> > > > > >
> >> > > > > > Yes, but all gcc 4.8.x versions?
> >> > > > > >
> >> > > > > > There is a fix here
> >> > > > > >   https://gcc.gnu.org/ml/gcc-patches/2014-04/msg01679.html
> >> > > > > > but I don't know if it got committed or not or which version.
> >> > > > > >
> >> > > > > > I am using gcc 4.8.4 and it works but I have one problem, if I 
> >> > > > > > erase uboot
> >> > > > > > after relocation, u-boot 

Re: [U-Boot] [PATCH v2 07/14] fastboot: Implement flashing session counter

[Tom Rini]

On Thu, Oct 15, 2015 at 02:34:15PM +0200, Maxime Ripard wrote:

> The fastboot flash command that writes an image to a partition works in
> several steps:
> 
> 1 - Retrieve the maximum size the device can download through the
> "max-download-size" variable
> 
> 2 - Retrieve the partition type through the "partition-type:%s" variable,
> that indicates whether or not the partition needs to be erased (even
> though the fastboot client has minimal support for that)
> 
> 3a - If the image is smaller than what the device can handle, send the image
>  and flash it.
> 
> 3b - If the image is larger than what the device can handle, create a
>  sparse image, and split it in several chunks that would fit. Send the
>  chunk, flash it, repeat until we have no more data to send.
> 
> However, in the 3b case, the subsequent transfers have no particular
> identifiers, the protocol just assumes that you would resume the writes
> where you left it.
> 
> While doing so works well, it also means that flashing two subsequent
> images on the same partition (for example because the user made a mistake)
> would not work withouth flashing another partition or rebooting the board,
> which is not really intuitive.
> 
> Since we have always the same pattern, we can however maintain a counter
> that will be reset every time the client will retrieve max-download-size,
> and incremented after each buffer will be flashed, that will allow us to
> tell whether we should simply resume the flashing where we were, or start
> back at the beginning of the partition.
> 
> Signed-off-by: Maxime Ripard 

Reviewed-by: Tom Rini 

-- 
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] Relocation issue - need help!

[Andy Fleming]

On Fri, Oct 16, 2015 at 8:14 AM, Joakim Tjernlund
 wrote:
> On Fri, 2015-10-16 at 07:47 -0400, Tom Rini wrote:
>> On Fri, Oct 16, 2015 at 06:55:58AM +, Joakim Tjernlund wrote:
>> > On Thu, 2015-10-15 at 17:58 -0400, Tom Rini wrote:
>> > > On Thu, Oct 15, 2015 at 03:56:09PM +, Joakim Tjernlund wrote:
>> > > > On Tue, 2015-10-06 at 11:17 +, Joakim Tjernlund wrote:
>> > > > > On Thu, 2015-10-01 at 08:57 +, Joakim Tjernlund wrote:
>> > > > > > On Wed, 2015-09-30 at 21:35 +0200, Marek Vasut wrote:
>> > > > > > > On Wednesday, September 30, 2015 at 08:24:10 PM, Andy Fleming 
>> > > > > > > wrote:
>> > > > > > >
>> > > > > > > Hi!
>> > > > > > >
>> > > > > > > > On Thu, Oct 23, 2014 at 8:10 AM, Wolfgang Denk  
>> > > > > > > > wrote:
>> > > > > > > > > Dear Joakim, dear Dirk,
>> > > > > > > > >
>> > > > > > > > > In message > > > > > > > c1257d7a.0024d...@transmode.se> you wrote:
>> > > > > > > > > > Ouch, that was a nasty surprise.
>> > > > > > > > >
>> > > > > > > > > Indeed.
>> > > > > > > > >
>> > > > > > > > > > > In my original mail I referenced this potential 
>> > > > > > > > > > > solution, at least it
>> > > > > > > > > > > worked for me:
>> > > > > > > > > > > https://gcc.gnu.org/ml/gcc-help/2014-02/msg00054.html
>> > > > > > > > > >
>> > > > > > > > > > That looks like the correct fix but I presume both 
>> > > > > > > > > > .data.rel.ro and
>> > > > > > > > > > data.rel.ro.local should be added?
>> > > > > > > > >
>> > > > > > > > > I can confirm:
>> > > > > > > > >
>> > > > > > > > > 1) The problem was observed with gcc 4.8.1 [as in Yocto 
>> > > > > > > > > 1.5.x / ELDK
>> > > > > > > > >
>> > > > > > > > >5.5.x].
>> > > > > > > > >
>> > > > > > > > > 2) Switching back to gcc 4.7.2 [as in Yocto 1.4 / ELDK 5.4] 
>> > > > > > > > > makes the
>> > > > > > > > >
>> > > > > > > > >problem go away.
>> > > > > > > > >
>> > > > > > > > > 3) Switching forward to gcc 4.9.1 [as in Yocto 1.7 / ELDK 
>> > > > > > > > > 5.7] makes
>> > > > > > > > >
>> > > > > > > > >the problem go away.
>> > > > > > > > >
>> > > > > > > > > 4) For the problemativ 4.8.x versions of GCC, the following 
>> > > > > > > > > patch
>> > > > > > > > >
>> > > > > > > > >apparently solves the problem for my (MPC5200 based) 
>> > > > > > > > > board - guess
>> > > > > > > > >this would have to be applied to all .lds files...
>> > > > > > > > >
>> > > > > > > > > diff --git a/arch/powerpc/cpu/mpc5xxx/u-boot.lds
>> > > > > > > > > b/arch/powerpc/cpu/mpc5xxx/u-boot.lds index cd9e23f..82c86d7 
>> > > > > > > > > 100644
>> > > > > > > > > --- a/arch/powerpc/cpu/mpc5xxx/u-boot.lds
>> > > > > > > > > +++ b/arch/powerpc/cpu/mpc5xxx/u-boot.lds
>> > > > > > > > > @@ -27,6 +27,8 @@ SECTIONS
>> > > > > > > > >
>> > > > > > > > >{
>> > > > > > > > >
>> > > > > > > > >  _GOT2_TABLE_ = .;
>> > > > > > > > >  KEEP(*(.got2))
>> > > > > > > > >
>> > > > > > > > > +KEEP(*(.data.rel.ro))
>> > > > > > > > > +KEEP(*(.data.rel.ro.local))
>> > > > > > > > >
>> > > > > > > > >  KEEP(*(.got))
>> > > > > > > > >  PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4);
>> > > > > > > > >  _FIXUP_TABLE_ = .;
>> > > > > > > > >
>> > > > > > > > > Given that GCC 4.9.1 apparently solves this issue I wonder 
>> > > > > > > > > which
>> > > > > > > > > approach we should take?
>> > > > > > > > >
>> > > > > > > > > Should we blacklist GCC 4.8.x (and 4.9.0) like the kernel 
>> > > > > > > > > folks are
>> > > > > > > > > doing [1] ?
>> > > > > > > > >
>> > > > > > > > > [1] https://lkml.org/lkml/2014/10/10/272
>> > > > > > > >
>> > > > > > > > Was there a resolution to this thread? I just spent a bunch of 
>> > > > > > > > time
>> > > > > > > > trying to figure out why u-boot was crashing, and eventually
>> > > > > > > > determined that switching from 4.9.0 to 4.6.3 solved the 
>> > > > > > > > problem.
>> > > > > > > > Should I submit a patch to do what was suggested above? Or add 
>> > > > > > > > the
>> > > > > > > > "blacklist" patch? If so, it should be noted that 4.9.0 is the 
>> > > > > > > > current
>> > > > > > > > default installed when you ask buildman to install a powerpc 
>> > > > > > > > cross
>> > > > > > > > compiler...
>> > > > > > >
>> > > > > > > Blacklist patch please, thank you!
>> > > > > >
>> > > > > > Yes, but all gcc 4.8.x versions?
>> > > > > >
>> > > > > > There is a fix here
>> > > > > >   https://gcc.gnu.org/ml/gcc-patches/2014-04/msg01679.html
>> > > > > > but I don't know if it got committed or not or which version.
>> > > > > >
>> > > > > > I am using gcc 4.8.4 and it works but I have one problem, if I 
>> > > > > > erase uboot
>> > > > > > after relocation, u-boot misbehavex or crashes so there is 
>> > > > > > something off still.
>> > > > > >
>> > > > > > Does it work for all but me to erase u-boot after relocation?
>> > > > > > Using T1040(mpc85xx family)
>> > > > >
>> > > > > Here is a better URL:
>> > > > > 

Re: [U-Boot] [PATCH v2] nios2: add README.nios2

[Marek Vasut]

On Tuesday, October 20, 2015 at 03:48:46 AM, Thomas Chou wrote:
> Add README.nios2 about how to add nios2 boards to u-boot.
> 
> Signed-off-by: Thomas Chou 
> ---
> v2
>   add ref and fix words as suggested by Marek.
> 
>  doc/README.nios2 | 97
>  1 file changed,
> 97 insertions(+)
>  create mode 100644 doc/README.nios2
> 
> diff --git a/doc/README.nios2 b/doc/README.nios2
> new file mode 100644
> index 000..453c7c7
> --- /dev/null
> +++ b/doc/README.nios2
> @@ -0,0 +1,97 @@
> +Nios II is a 32-bit embedded-processor architecture designed
> +specifically for the Altera family of FPGAs.
> +
> +Please refer to the link for more information on Nios II,
> +https://www.altera.com/products/processors/overview.html
> +
> +Please refer to the link for Linux port and toolchains,
> +http://rocketboards.org/foswiki/view/Documentation/NiosIILinuxUserManual
> +
> +The Nios II port of u-boot is controlled by device tree. Please check
> +out doc/README.fdt-control.
> +
> +To add a new board/configuration (eg, mysystem) to u-boot, you will need
> +three files.
> +
> +1. The device tree source which describes the hardware, dts file.
> +arch/nios2/dts/mysystem.dts
> +
> +2. Default configuration of Kconfig, defconfig file.
> +configs/mysystem_defconfig
> +
> +3. The legacy board header file.
> +include/configs/mysystem.h
> +
> +The device tree source must be generated from your qsys/sopc design
> +using the sopc2dts tool. Then modified to fit your configuration. Please
> +find the sopc2dts download and usage at the wiki,
> +http://www.alterawiki.com/wiki/Sopc2dts
> +
> +java -jar sopc2dts.jar --force-altr -i mysystem.sopcinfo -o mysystem.dts

Just a hint -- in case you're listing a command, add a dollar sign before
it to be explicit it's a command, like this:

$ java -jar ...

Otherwise,

Acked-by: Marek Vasut 

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

[U-Boot] [PATCH v3] Tegra: T210: Add QSPI driver

[Tom Warren]

This is the normal Tegra SPI driver modified to work with the
QSPI controller in Tegra210. It does not do 2x/4x transfers
or any other QSPI protocol.

Author: Yen Lin 
Signed-off-by: Yen Lin 
Signed-off-by: Tom Warren 
---
Changes in v2:
- Drop defconfig and pinmux files, this is a driver-only patch.
- If/when pinmux tables have been updated for P2371/P2571, another
- patch will be sent to enable the QSPI driver on those boards.
Changes in v3:
- removed status reg write/clear in claim_bus(), done in xfer()

 drivers/spi/Kconfig |   5 +
 drivers/spi/Makefile|   1 +
 drivers/spi/tegra210_qspi.c | 400 
 3 files changed, 406 insertions(+)
 create mode 100644 drivers/spi/tegra210_qspi.c

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 8e04fce..168f31d 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -115,6 +115,11 @@ config TEGRA20_SLINK
  be used to access the SPI NOR flash on platforms embedding this
  nVidia Tegra20/Tegra30 IP cores.
 
+config TEGRA210_QSPI
+   bool "nVidia Tegra210 QSPI driver"
+   help
+ Enable the Tegra Quad-SPI (QSPI) driver for T210.
+
 config XILINX_SPI
bool "Xilinx SPI driver"
help
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index de241be..209a41e 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_SH_QSPI) += sh_qspi.o
 obj-$(CONFIG_TEGRA114_SPI) += tegra114_spi.o
 obj-$(CONFIG_TEGRA20_SFLASH) += tegra20_sflash.o
 obj-$(CONFIG_TEGRA20_SLINK) += tegra20_slink.o
+obj-$(CONFIG_TEGRA210_QSPI) += tegra210_qspi.o
 obj-$(CONFIG_TI_QSPI) += ti_qspi.o
 obj-$(CONFIG_XILINX_SPI) += xilinx_spi.o
 obj-$(CONFIG_ZYNQ_SPI) += zynq_spi.o
diff --git a/drivers/spi/tegra210_qspi.c b/drivers/spi/tegra210_qspi.c
new file mode 100644
index 000..6be37f3
--- /dev/null
+++ b/drivers/spi/tegra210_qspi.c
@@ -0,0 +1,400 @@
+/*
+ * NVIDIA Tegra210 QSPI controller driver
+ *  (C) Copyright 2015
+ *  NVIDIA Corporation 
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "tegra_spi.h"
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* COMMAND1 */
+#define QSPI_CMD1_GO   (1 << 31)
+#define QSPI_CMD1_M_S  (1 << 30)
+#define QSPI_CMD1_MODE_MASK0x3
+#define QSPI_CMD1_MODE_SHIFT   28
+#define QSPI_CMD1_CS_SEL_MASK  0x3
+#define QSPI_CMD1_CS_SEL_SHIFT 26
+#define QSPI_CMD1_CS_POL_INACTIVE0 (1 << 22)
+#define QSPI_CMD1_CS_SW_HW (1 << 21)
+#define QSPI_CMD1_CS_SW_VAL(1 << 20)
+#define QSPI_CMD1_IDLE_SDA_MASK0x3
+#define QSPI_CMD1_IDLE_SDA_SHIFT   18
+#define QSPI_CMD1_BIDIR(1 << 17)
+#define QSPI_CMD1_LSBI_FE  (1 << 16)
+#define QSPI_CMD1_LSBY_FE  (1 << 15)
+#define QSPI_CMD1_BOTH_EN_BIT  (1 << 14)
+#define QSPI_CMD1_BOTH_EN_BYTE (1 << 13)
+#define QSPI_CMD1_RX_EN(1 << 12)
+#define QSPI_CMD1_TX_EN(1 << 11)
+#define QSPI_CMD1_PACKED   (1 << 5)
+#define QSPI_CMD1_BITLEN_MASK  0x1F
+#define QSPI_CMD1_BITLEN_SHIFT 0
+
+/* COMMAND2 */
+#define QSPI_CMD2_TX_CLK_TAP_DELAY (1 << 6)
+#define QSPI_CMD2_TX_CLK_TAP_DELAY_MASK(0x3F << 6)
+#define QSPI_CMD2_RX_CLK_TAP_DELAY (1 << 0)
+#define QSPI_CMD2_RX_CLK_TAP_DELAY_MASK(0x3F << 0)
+
+/* TRANSFER STATUS */
+#define QSPI_XFER_STS_RDY  (1 << 30)
+
+/* FIFO STATUS */
+#define QSPI_FIFO_STS_CS_INACTIVE  (1 << 31)
+#define QSPI_FIFO_STS_FRAME_END(1 << 30)
+#define QSPI_FIFO_STS_RX_FIFO_FLUSH(1 << 15)
+#define QSPI_FIFO_STS_TX_FIFO_FLUSH(1 << 14)
+#define QSPI_FIFO_STS_ERR  (1 << 8)
+#define QSPI_FIFO_STS_TX_FIFO_OVF  (1 << 7)
+#define QSPI_FIFO_STS_TX_FIFO_UNR  (1 << 6)
+#define QSPI_FIFO_STS_RX_FIFO_OVF  (1 << 5)
+#define QSPI_FIFO_STS_RX_FIFO_UNR  (1 << 4)
+#define QSPI_FIFO_STS_TX_FIFO_FULL (1 << 3)
+#define QSPI_FIFO_STS_TX_FIFO_EMPTY(1 << 2)
+#define QSPI_FIFO_STS_RX_FIFO_FULL (1 << 1)
+#define QSPI_FIFO_STS_RX_FIFO_EMPTY(1 << 0)
+
+#define QSPI_TIMEOUT   1000
+
+struct qspi_regs {
+   u32 command1;   /* 000:QSPI_COMMAND1 register */
+   u32 command2;   /* 004:QSPI_COMMAND2 register */
+   u32 timing1;/* 008:QSPI_CS_TIM1 register */
+   u32 timing2;/* 00c:QSPI_CS_TIM2 register */
+   u32 xfer_status;/* 010:QSPI_TRANS_STATUS register */
+   u32 fifo_status;/* 014:QSPI_FIFO_STATUS register */
+   u32 tx_data;/* 018:QSPI_TX_DATA register */
+   u32 rx_data;/* 01c:QSPI_RX_DATA register */
+   u32 dma_ctl;/* 020:QSPI_DMA_CTL register */
+   u32 dma_blk;/* 024:QSPI_DMA_BLK register */
+   u32 rsvd[56];   /* 028-107 reserved */
+   u32 

Re: [U-Boot] [PATCH] ohci: Add missing cache-flush for hcca area

[Marek Vasut]

On Tuesday, October 20, 2015 at 06:39:29 PM, Hans de Goede wrote:
> We need to cache-flush the hcca area after the initial memset, otherwise
> on the first hc_interrupt we might see an old $random value as done_head
> and try to interpret that as the address for a completed td (followed by
> chaos).
> 
> Signed-off-by: Hans de Goede 

Dang, this came three hours after the release of 2015.10 ;-)

Oh well. Applied, thanks!

> ---
>  drivers/usb/host/ohci-hcd.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
> index 9bde2b2..ccbfc02 100644
> --- a/drivers/usb/host/ohci-hcd.c
> +++ b/drivers/usb/host/ohci-hcd.c
> @@ -2205,6 +2205,7 @@ int ohci_register(struct udevice *dev, struct
> ohci_regs *regs) if (!ohci->hcca)
>   return -ENOMEM;
>   memset(ohci->hcca, 0, sizeof(struct ohci_hcca));
> + flush_dcache_hcca(ohci->hcca);
> 
>   if (hc_reset(ohci) < 0)
>   return -EIO;

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

Re: [U-Boot] Bisected broken Ethernet support on ODROID-X (Exynos4412 board)

[Siarhei Siamashka]

On Tue, 20 Oct 2015 09:15:07 -0600
Simon Glass  wrote:

> Hi,
> 
> On 20 October 2015 at 08:13, Siarhei Siamashka
>  wrote:
> > Hello,
> >
> > Ethernet support does not work anymore when using the current U-Boot
> > (version v2014.10) on the ODROID-X board. Bisecting shows that this
> > happened starting from commit 874dde80169e0a0c00020e2e0bbcd380c61097e3
> > ("dm: usb: exynos: Use driver model for USB"):
> > 
> > http://git.denx.de/?p=u-boot.git;a=commitdiff;h=874dde80169e0a0c00020e2e0bbcd380c61097e3
> >
> > Below are the logs from the serial console.
> >
> > === works properly ==
> >
> > U-Boot 2015.04-00271-g52e6935-dirty (Oct 20 2015 - 16:38:09)
> >
> > CPU:Exynos4412@1000MHz
> > Model: Odroid based on Exynos4412
> > DRAM:  1 GiB
> > Board PMIC init
> > MMC:   SAMSUNG SDHCI: 0, EXYNOS DWMMC: 1
> > Net:   No ethernet found.
> > Hit any key to stop autoboot:  0
> > reading boot.scr
> > 129 bytes read in 11 ms (10.7 KiB/s)
> > ## Executing script at 40408000
> > starting USB...
> > USB0:   USB EHCI 1.00
> > scanning bus 0 for devices... 4 USB Device(s) found
> >scanning usb for storage devices... 0 Storage Device(s) found
> >scanning usb for ethernet devices... 1 Ethernet Device(s) found
> >
> > === fails ==
> >
> > U-Boot 2015.04-00273-g78ab40b-dirty (Oct 20 2015 - 16:41:11)
> >
> > CPU:Exynos4412@1000MHz
> > Model: Odroid based on Exynos4412
> > DRAM:  1 GiB
> > Board PMIC init
> > MMC:   SAMSUNG SDHCI: 0, EXYNOS DWMMC: 1
> > Net:   No ethernet found.
> > Hit any key to stop autoboot:  0
> > reading boot.scr
> > 129 bytes read in 12 ms (9.8 KiB/s)
> > ## Executing script at 40408000
> > starting USB...
> > USB-1:   USB EHCI 1.00
> > scanning bus 0 for devices... 1 USB Device(s) found
> >scanning usb for ethernet devices... 0 Ethernet Device(s) found
> >
> > ===
> >
> > As a test, reverting f56da290b8df14a058b43735494dbbb0f8521a89 ("Drop
> > the code that doesn't use driver model for USB.") and disabling
> > CONFIG_DM_USB in odroid_defconfig makes it work again.
> 
> Does this problem happen on the XU3?

I don't have XU3. My only board is ODROID-X (the same as ODROID-X2, but
with slower CPU clock speed and less RAM).

> Are you able to debug this?

I'm not sure if I can really spend much time on it. Debugging this
issue would require comparing the old exynos usb code and the new
dm code to see where exactly they differ. For example, the new
'ehci_usb_probe()' function does not call 'board_usb_init()' while
the old 'ehci_hcd_init()' function did:

http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/usb/host/ehci-exynos.c;h=86cf6312febc30b7e142146c3b4763a6a871d5a6;hb=02e4d3fbc54b345883d9bead4f2a911d0f0f59b1#l329
And just calling 'board_usb_init()' on ODROID-X is still not enough
to get this problem resolved for the CONFIG_DM_USB=y configuration,
so there must be something else.

I also don't quite like that the usb parts of the U-Boot dts files
for exynos differ from the Linux dts files.

So far I'm satisfied that the old exynos usb code still works if
its removal is reverted. And debugging U-Boot was not my primary
intention when fetching this old ODROID-X board from a closet.
I had plans to do some other interesting tests with it :-)

If Przemyslaw Marczak (the ODROID boards maintainer) could confirm
the problem on ODROID-X2 and take care of it, then this would be
the best for me.

> You can use 'dm tree' to see what devices are present
> before and after the 'usb start'.

Thanks, this indeed prints some useful information. Here is the log:

U-Boot 2015.10-1-g0374f7f-dirty (Jan 01 1970 - 00:00:00 +)

CPU:   Exynos4412 @ 1 GHz
Model: Odroid based on Exynos4412
Board: Odroid based on Exynos4412
Model: x
DRAM:  1 GiB
LDO20@VDDQ_EMMC_1.8V: set 180 uV; enabling
LDO22@VDDQ_EMMC_2.8V: set 280 uV; enabling
LDO21@TFLASH_2.8V: set 280 uV; enabling
MMC:   SAMSUNG SDHCI: 0, EXYNOS DWMMC: 1
Net:   No ethernet found.
Hit any key to stop autoboot:  0 
reading boot.scr
215 bytes read in 107 ms (2 KiB/s)
## Executing script at 40408000
=== dm tree before usb start ===
 Class   Probed   Name

 root[ + ]root_driver
 serial  [   ]|-- serial@1380
 serial  [ + ]|-- serial@1381
 serial  [   ]|-- serial@1382
 serial  [   ]|-- serial@1383
 serial  [   ]|-- serial@1384
 i2c [ + ]|-- i2c@1386
 pmic[ + ]|   `-- max77686_pmic@09
 regulator   [   ]|   |-- LDO1
 regulator   [   ]|   |-- LDO2
 regulator   [   ]|   |-- LDO3
 regulator   [   ]|   |-- LDO4
 regulator   [   ]|   |-- LDO5
 regulator   [   ]|   |-- LDO6
 regulator   [   ]|   |-- LDO7
 regulator   [   ]|   |-- LDO8
 regulator   [   ]|   |-- LDO10
 regulator   [   ]|   |-- LDO11
 regulator   [   ]|   |-- LDO12
 regulator   [   ]|   |-- 

Re: [U-Boot] [PATCH v2] nios2: add README.nios2

[Thomas Chou]

Hi Marek,

On 10/21/2015 05:25 AM, Marek Vasut wrote:

+java -jar sopc2dts.jar --force-altr -i mysystem.sopcinfo -o mysystem.dts


Just a hint -- in case you're listing a command, add a dollar sign before
it to be explicit it's a command, like this:

$ java -jar ...


Thanks for the hint. I will add that.

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

[U-Boot] Please pull u-boot-marvell master

[Luka Perkov]

Hi Tom,

can you please pull various mvebu enhancements from Stefan?

The following changes since commit 5ec0003b19cbdf06ccd6941237cbc0d1c3468e2d:

  Prepare v2015.10 (2015-10-19 19:59:38 -0400)

are available in the git repository at:

  git://git.denx.de/u-boot-marvell.git 

for you to fetch changes up to 5b37212a3d78f546b5ef3f97a75155b3a0fd88cb:

  mmc: mv_sdhci: Configure the SDHCI MBUS bridge windows (2015-10-21 02:25:02 
+0200)


Stefan Roese (12):
  arm: mvebu: Move Armada XP/38x Kconfig to mach specific Kconfig file
  arm: mvebu: Add option to use UART xmodem protocol via kwboot
  arm: mvebu: Only set CONFIG_SKIP_LOWLEVEL_INIT for SPL
  dm: core: Enable optional use of fdt_translate_address()
  kwbimage: Align payload size to 4 bytes
  arm: mvebu: Do not call board_init_r() from board_init_f()
  arm: mvebu: Add basic Armada XP / 38x dtsi/dts files
  arm: mvebu: Add DM (driver model) support
  usb: ehci-marvell.c: Add DM support
  arm: mvebu: Enable DM_USB on AXP / A38x boards
  arm: mvebu: Enable DM_SERIAL on AXP / A38x boards
  mmc: mv_sdhci: Configure the SDHCI MBUS bridge windows

 Makefile   |  14 +-
 arch/arm/Kconfig   |  20 +-
 arch/arm/dts/Makefile  |   5 +
 arch/arm/dts/armada-370-xp.dtsi| 333 ++
 arch/arm/dts/armada-380.dtsi   | 152 +
 arch/arm/dts/armada-385.dtsi   | 184 ++
 arch/arm/dts/armada-388-gp.dts | 413 +++
 arch/arm/dts/armada-388.dtsi   |  70 
 arch/arm/dts/armada-38x.dtsi   | 600 +
 arch/arm/dts/armada-xp-gp.dts  | 245 ++
 arch/arm/dts/armada-xp-mv78230.dtsi| 231 +
 arch/arm/dts/armada-xp-mv78260.dtsi| 333 ++
 arch/arm/dts/armada-xp-mv78460.dtsi| 371 
 arch/arm/dts/armada-xp.dtsi| 320 ++
 arch/arm/mach-mvebu/Kconfig|  31 ++
 arch/arm/mach-mvebu/cpu.c  |  31 +-
 arch/arm/mach-mvebu/include/mach/cpu.h |   2 +
 arch/arm/mach-mvebu/include/mach/soc.h |   2 +-
 arch/arm/mach-mvebu/lowlevel_spl.S |  16 +
 arch/arm/mach-mvebu/spl.c  |  26 +-
 board/Marvell/db-88f6820-gp/Kconfig|   3 -
 board/Marvell/db-mv784mp-gp/Kconfig|   3 -
 board/maxbcm/Kconfig   |   3 -
 configs/db-88f6820-gp_defconfig|   7 +
 configs/db-mv784mp-gp_defconfig|   7 +
 configs/maxbcm_defconfig   |   2 +
 drivers/core/Kconfig   |  30 ++
 drivers/core/device.c  |  20 ++
 drivers/mmc/mv_sdhci.c |  41 +++
 drivers/usb/host/Kconfig   |   7 +
 drivers/usb/host/ehci-marvell.c|  86 -
 include/configs/db-88f6820-gp.h|   6 +-
 include/configs/db-mv784mp-gp.h|   6 +-
 include/configs/maxbcm.h   |   2 +
 include/configs/mv-common.h|  10 +-
 tools/kwbimage.c   |   3 +
 36 files changed, 3570 insertions(+), 65 deletions(-)
 create mode 100644 arch/arm/dts/armada-370-xp.dtsi
 create mode 100644 arch/arm/dts/armada-380.dtsi
 create mode 100644 arch/arm/dts/armada-385.dtsi
 create mode 100644 arch/arm/dts/armada-388-gp.dts
 create mode 100644 arch/arm/dts/armada-388.dtsi
 create mode 100644 arch/arm/dts/armada-38x.dtsi
 create mode 100644 arch/arm/dts/armada-xp-gp.dts
 create mode 100644 arch/arm/dts/armada-xp-mv78230.dtsi
 create mode 100644 arch/arm/dts/armada-xp-mv78260.dtsi
 create mode 100644 arch/arm/dts/armada-xp-mv78460.dtsi
 create mode 100644 arch/arm/dts/armada-xp.dtsi
 create mode 100644 arch/arm/mach-mvebu/Kconfig

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

Re: [U-Boot] [ANN] U-Boot v2015.10 released

[Masahiro Yamada]

Hi Wolfgang,


> Top changeset contributors by employer
> (Unknown)  568 (27.5%)
> Google, Inc.   376 (18.2%)
> DENX Software Engineering  354 (17.1%)
> Freescale  303 (14.6%)
> Red Hat 92 (4.4%)
> NVidia  75 (3.6%)
> Texas Instruments   69 (3.3%)
> Xilinx  50 (2.4%)
> CompuLab32 (1.5%)
> Konsulko Group  29 (1.4%)


I also see

Google6 0.3%


Why are "Google, Inc." and "Google" double-counted?


>
> Top lines changed by employer
> Google, Inc.  68254 (27.8%)
> (Unknown) 67079 (27.3%)

My employer is  Socionext Inc.





> Employers with the most signoffs (total 328)
> Freescale   85 (25.9%)
> NVidia  76 (23.2%)
> (Unknown)   40 (12.2%)
> Red Hat 25 (7.6%)
> Google, Inc.22 (6.7%)
> Xilinx  20 (6.1%)
> Konsulko Group  14 (4.3%)
> Samsung 10 (3.0%)
> Texas Instruments7 (2.1%)
> Broadcom 5 (1.5%)

Nobuhiro Iwamatsu4 1.2%



Nobuhiro is not an independent developer.
He works for Hitach.






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