Re: [U-Boot] [PATCH 04/10] video: exynos_fimd: Add framework to disable FIMD sysmmu

2014-06-19 Thread Ajay kumar
Hi Simon,


On Fri, Jun 20, 2014 at 8:59 AM, Simon Glass  wrote:
> On 17 June 2014 03:06, Ajay Kumar  wrote:
>> On Exynos5420 and newer versions, the FIMD sysmmus are in
>> "on state" by default.
>> We have to disable them in order to make FIMD DMA work.
>> This patch adds the required framework to exynos_fimd driver,
>> and disables FIMD sysmmu on Exynos5420.
>>
>> Signed-off-by: Ajay Kumar 
>
> Acked-by: Simon Glass 
> Tested-by: Simon Glass 
>
> (I assume this is the same device tree binding as Linux?)
Actually, No!
Kernel has a generic binding named "samsung,sysmmu-v3.3", and it is common
for all sysmmu nodes. There is a seperate IOMMU driver to handle the same.
We can port the device probing part from kernel to u-boot, but we would need
to add seperate driver(since the name is generic) to handle the same.
That driver, even though being generic, will be used only by FIMD
sysmmus(that too, just to turn them off).

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


Re: [U-Boot] [PATCH 09/10] CONFIGS: peach-pit: Enable display for peach_pit board

2014-06-19 Thread Ajay kumar
Simon,

On Fri, Jun 20, 2014 at 9:08 AM, Simon Glass  wrote:
> Hi Ajay,
>
> On 17 June 2014 03:06, Ajay Kumar  wrote:
>> Enable drivers for FIMD, DP and parade bridge chip.
>>
>> Signed-off-by: Ajay Kumar 
>> ---
>>  include/configs/peach-pit.h | 10 ++
>>  1 file changed, 10 insertions(+)
>>
>> diff --git a/include/configs/peach-pit.h b/include/configs/peach-pit.h
>> index 76b8d7a..88c093f 100644
>> --- a/include/configs/peach-pit.h
>> +++ b/include/configs/peach-pit.h
>> @@ -22,4 +22,14 @@
>>  #define CONFIG_SYS_PROMPT  "Peach # "
>>  #define CONFIG_IDENT_STRING" for Peach"
>>
>> +#define CONFIG_VIDEO_PARADE
>> +
>> +/* Display */
>> +#define CONFIG_LCD
>> +#ifdef CONFIG_LCD
>> +#define CONFIG_EXYNOS_FB
>> +#define CONFIG_EXYNOS_DP
>> +#define LCD_BPPLCD_COLOR16
>> +#endif
>> +
>>  #endif /* __CONFIG_PEACH_PIT_H */
>
> Can this go in exynos5420.h? It seems to be common except for the PARADE bit.
No. This patchset enables display only for peach_pit.
So, we cannot move this to exynos5420.h.

Ajay

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


Re: [U-Boot] [RFC PATCH 0/3] Implement "fastboot flash" for eMMC

2014-06-19 Thread Marek Vasut
On Friday, June 20, 2014 at 08:18:42 AM, Lukasz Majewski wrote:
> Hi Steve,
> 
> > This series implements the "fastboot flash" command for eMMC devices.
> > It supports both raw and sparse images.
> > 
> > NOTES:
> > - the support for the "fastboot flash" command is enabled with
> > CONFIG_FASTBOOT_FLASH
> > - the support for eMMC is enabled with CONFIG_FASTBOOT_FLASH_MMC_DEV
> > - (future) the support for NAND would be enabled with
> > CONFIG_FASTBOOT_FLASH_NAND(???)
> > - thus the proposal is to place the code in common/fb_mmc.c and
> > (future) common/fb_nand.c(???), however, this may not be the
> > appropriate location
> 
> Would you consider another approach for providing flashing backend for
> fastboot?
> 
> I'd like to propose reusing of the dfu flashing code for this purpose.
> Such approach has been used successfully with USB "thor" downloading
> function.
> 
> Since the "fastboot" is using gadget infrastructure (thanks to the
> effort of Rob Herring) I think that it would be feasible to reuse the
> same approach as "thor" does. In this way the low level code would be
> kept in one place and we could refine and test it more thoroughly.

I'm all for this approach as well if possible.

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


Re: [U-Boot] [RFC PATCH 0/3] Implement "fastboot flash" for eMMC

2014-06-19 Thread Lukasz Majewski
Hi Steve,

> This series implements the "fastboot flash" command for eMMC devices.
> It supports both raw and sparse images.
> 
> NOTES:
> - the support for the "fastboot flash" command is enabled with
> CONFIG_FASTBOOT_FLASH
> - the support for eMMC is enabled with CONFIG_FASTBOOT_FLASH_MMC_DEV
> - (future) the support for NAND would be enabled with
> CONFIG_FASTBOOT_FLASH_NAND(???)
> - thus the proposal is to place the code in common/fb_mmc.c and
> (future) common/fb_nand.c(???), however, this may not be the
> appropriate location
> 

Would you consider another approach for providing flashing backend for
fastboot?

I'd like to propose reusing of the dfu flashing code for this purpose.
Such approach has been used successfully with USB "thor" downloading
function.

Since the "fastboot" is using gadget infrastructure (thanks to the
effort of Rob Herring) I think that it would be feasible to reuse the
same approach as "thor" does. In this way the low level code would be
kept in one place and we could refine and test it more thoroughly. 

> This has been tested on ARMv7.
> This is a WIP -- and I would appreciate some comments/advice...
> Thanks, Steve
> 
> 
> Steve Rae (3):
>   usb/gadget: fastboot: add sparse image definitions
>   usb/gadget: fastboot: add eMMC support for flash command
>   usb/gadget: fastboot: add support for flash command
> 
>  README  |  10 +++
>  common/Makefile |   5 ++
>  common/fb_mmc.c | 144
> 
> doc/README.android-fastboot |   5 +-
> drivers/usb/gadget/f_fastboot.c |  31 +
> include/fb_mmc.h|   8 +++
> include/sparse_format.h |  58  7 files
> changed, 259 insertions(+), 2 deletions(-) create mode 100644
> common/fb_mmc.c create mode 100644 include/fb_mmc.h
>  create mode 100644 include/sparse_format.h
> 



-- 
Best regards,

Lukasz Majewski

Samsung R&D 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 1/2] sparc: merge LEON3 linker scripts

2014-06-19 Thread Masahiro Yamada
The linker scripts of LEON3

 - board/gaisler/grsim/u-boot.lds
 - board/gaisler/gr_cpci_ax2000/u-boot.lds
 - board/gaisler/gr_ep2s60/u-boot.lds
 - board/gaisler/gr_xc3s_1500/u-boot.lds

are the same (except cosmetic differences such as indentation).

This commit merges them into arch/sparc/cpu/leon3/u-boot.lds.

Signed-off-by: Masahiro Yamada 
Cc: Daniel Hellstrom 
---

 .../grsim => arch/sparc/cpu/leon3}/u-boot.lds  |   0
 board/gaisler/gr_cpci_ax2000/u-boot.lds| 143 
 board/gaisler/gr_ep2s60/u-boot.lds | 143 
 board/gaisler/gr_xc3s_1500/u-boot.lds  | 145 -
 4 files changed, 431 deletions(-)
 rename {board/gaisler/grsim => arch/sparc/cpu/leon3}/u-boot.lds (100%)
 delete mode 100644 board/gaisler/gr_cpci_ax2000/u-boot.lds
 delete mode 100644 board/gaisler/gr_ep2s60/u-boot.lds
 delete mode 100644 board/gaisler/gr_xc3s_1500/u-boot.lds

diff --git a/board/gaisler/grsim/u-boot.lds b/arch/sparc/cpu/leon3/u-boot.lds
similarity index 100%
rename from board/gaisler/grsim/u-boot.lds
rename to arch/sparc/cpu/leon3/u-boot.lds
diff --git a/board/gaisler/gr_cpci_ax2000/u-boot.lds 
b/board/gaisler/gr_cpci_ax2000/u-boot.lds
deleted file mode 100644
index 6d9c90c..000
--- a/board/gaisler/gr_cpci_ax2000/u-boot.lds
+++ /dev/null
@@ -1,143 +0,0 @@
-/*
- * Linker script for Gaisler Research AB's GR-CPCI-AX2000 board
- * with template design.
- *
- * (C) Copyright 2008
- * Daniel Hellstrom, Gaisler Research, dan...@gaisler.com.
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-OUTPUT_FORMAT("elf32-sparc", "elf32-sparc", "elf32-sparc")
-OUTPUT_ARCH(sparc)
-ENTRY(_start)
-SECTIONS
-{
-
-/* Read-only sections, merged into text segment: */
-   . = + SIZEOF_HEADERS;
-   .interp : { *(.interp) }
-   .hash  : { *(.hash) }
-   .dynsym: { *(.dynsym)   }
-   .dynstr: { *(.dynstr)   }
-   .rel.text  : { *(.rel.text) }
-   .rela.text : { *(.rela.text)}
-   .rel.data  : { *(.rel.data) }
-   .rela.data : { *(.rela.data)}
-   .rel.rodata: { *(.rel.rodata)   }
-   .rela.rodata   : { *(.rela.rodata)  }
-   .rel.got   : { *(.rel.got)  }
-   .rela.got  : { *(.rela.got) }
-   .rel.ctors : { *(.rel.ctors)}
-   .rela.ctors: { *(.rela.ctors)   }
-   .rel.dtors : { *(.rel.dtors)}
-   .rela.dtors: { *(.rela.dtors)   }
-   .rel.bss   : { *(.rel.bss)  }
-   .rela.bss  : { *(.rela.bss) }
-   .rel.plt   : { *(.rel.plt)  }
-   .rela.plt  : { *(.rela.plt) }
-   .init  : { *(.init) }
-   .plt : { *(.plt) }
-
-   .text : {
-   _load_addr = .;
-   _text = .;
-
-   *(.start)
-   arch/sparc/cpu/leon3/start.o (.text)
-/* 8k is the same as the PROM offset from end of main memory, 
(CONFIG_SYS_PROM_SIZE) */
-   . = ALIGN(8192);
-/* PROM CODE, Will be relocated to the end of memory,
- * no global data accesses please.
- */
-   __prom_start = .;
-   *(.prom.pgt)
-   *(.prom.data)
-   *(.prom.text)
-   . = ALIGN(16);
-   __prom_end = .;
-   *(.text)
-   *(.fixup)
-   *(.gnu.warning)
-/* *(.got1)*/
-   . = ALIGN(16);
-   *(.eh_frame)
-   *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*)))
-   }
-   . = ALIGN(4);
-   _etext = .;
-
-   /* CMD Table */
-
-
-   . = ALIGN(4);
-   .u_boot_list : {
-   KEEP(*(SORT(.u_boot_list*)));
-   }
-
-   .data   :
-   {
-   *(.data)
-   *(.data1)
-   *(.data.rel)
-   *(.data.rel.*)
-   *(.sdata)
-   *(.sdata2)
-   *(.dynamic)
-   CONSTRUCTORS
-   }
-   _edata  =   .;
-   PROVIDE (edata = .);
-
-   . = ALIGN(4);
-   __got_start = .;
-   .got : {
-   *(.got)
-/* *(.data.rel)
-   *(.data.rel.local)*/
-   . = ALIGN(16);
-   }
-   __got_end = .;
-
-/* .data.rel : { } */
-
-   . = ALIGN(4096);
-   __init_begin = .;
-   .text.init : { *(.text.init) }
-   .data.init : { *(.data.init) }
-   . = ALIGN(4096);
-   __init_end = .;
-
-   __bss_start = .;
-   .bss:
-   {
-*(.sbss) *(.scommon)
-*(.dynbss)
-*(.bss)
-*(COMMON)
-   . = ALIGN(16); /* to speed clearing of bss up */
-   }
-   __bss_end = . ;
-   __bss_end = . ;
-   PROVIDE (end = .);
-
-/* Relocated into main memory */
-
-   /* Start of main memory */
-   /*. = 0x4000;*/
-
-   .stack (NOLOAD) : { *(.sta

[U-Boot] [PATCH 2/2] sparc: merge LEON2 and LEON3 linker scripts

2014-06-19 Thread Masahiro Yamada
There is only one line diff between LEON2 and LEON3 linker scripts:

  - arch/sparc/cpu/leon2/start.o (.text)
  + arch/sparc/cpu/leon3/start.o (.text)

They can be written in the same way:

*/start.o (.text)

So, board/gaisler/grsim_leon2/u-boot.lds
and arch/sparc/cpu/leon3/u-boot.lds
can be merged into arch/sparc/cpu/u-boot.lds.

Signed-off-by: Masahiro Yamada 
Cc: Daniel Hellstrom 
---

 arch/sparc/cpu/{leon3 => }/u-boot.lds |   6 +-
 board/gaisler/grsim_leon2/u-boot.lds  | 142 --
 2 files changed, 2 insertions(+), 146 deletions(-)
 rename arch/sparc/cpu/{leon3 => }/u-boot.lds (95%)
 delete mode 100644 board/gaisler/grsim_leon2/u-boot.lds

diff --git a/arch/sparc/cpu/leon3/u-boot.lds b/arch/sparc/cpu/u-boot.lds
similarity index 95%
rename from arch/sparc/cpu/leon3/u-boot.lds
rename to arch/sparc/cpu/u-boot.lds
index cdc8394..1ade3b3 100644
--- a/arch/sparc/cpu/leon3/u-boot.lds
+++ b/arch/sparc/cpu/u-boot.lds
@@ -1,7 +1,5 @@
 /*
- * Linker script for Gaisler Research AB's GRSIM LEON3 simulator.
- *
- * (C) Copyright 2007
+ * (C) Copyright 2007-2008
  * Daniel Hellstrom, Gaisler Research, dan...@gaisler.com.
  *
  * SPDX-License-Identifier:GPL-2.0+
@@ -43,7 +41,7 @@ SECTIONS
_text = .;
 
*(.start)
-   arch/sparc/cpu/leon3/start.o (.text)
+   */start.o (.text)
 /* 8k is the same as the PROM offset from end of main memory, 
(CONFIG_SYS_PROM_SIZE) */
. = ALIGN(8192);
 /* PROM CODE, Will be relocated to the end of memory,
diff --git a/board/gaisler/grsim_leon2/u-boot.lds 
b/board/gaisler/grsim_leon2/u-boot.lds
deleted file mode 100644
index 1f038bc..000
--- a/board/gaisler/grsim_leon2/u-boot.lds
+++ /dev/null
@@ -1,142 +0,0 @@
-/*
- * Linker script for Gaisler Research AB's GRSIM LEON2 simulator.
- *
- * (C) Copyright 2007
- * Daniel Hellstrom, Gaisler Research, dan...@gaisler.com.
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-OUTPUT_FORMAT("elf32-sparc", "elf32-sparc", "elf32-sparc")
-OUTPUT_ARCH(sparc)
-ENTRY(_start)
-SECTIONS
-{
-
-/* Read-only sections, merged into text segment: */
-   . = + SIZEOF_HEADERS;
-   .interp : { *(.interp) }
-   .hash  : { *(.hash) }
-   .dynsym: { *(.dynsym) }
-   .dynstr: { *(.dynstr) }
-   .rel.text  : { *(.rel.text) }
-   .rela.text : { *(.rela.text) }
-   .rel.data  : { *(.rel.data) }
-   .rela.data : { *(.rela.data) }
-   .rel.rodata: { *(.rel.rodata) }
-   .rela.rodata   : { *(.rela.rodata) }
-   .rel.got   : { *(.rel.got) }
-   .rela.got  : { *(.rela.got) }
-   .rel.ctors : { *(.rel.ctors) }
-   .rela.ctors: { *(.rela.ctors) }
-   .rel.dtors : { *(.rel.dtors) }
-   .rela.dtors: { *(.rela.dtors) }
-   .rel.bss   : { *(.rel.bss) }
-   .rela.bss  : { *(.rela.bss) }
-   .rel.plt   : { *(.rel.plt) }
-   .rela.plt  : { *(.rela.plt) }
-   .init  : { *(.init) }
-   .plt : { *(.plt) }
-
-   .text : {
-   _load_addr = .;
-   _text = .;
-
-   *(.start)
-   arch/sparc/cpu/leon2/start.o (.text)
-/* 8k is the same as the PROM offset from end of main memory, 
(CONFIG_SYS_PROM_SIZE) */
-   . = ALIGN(8192);
-/* PROM CODE, Will be relocated to the end of memory,
- * no global data accesses please.
- */
-   __prom_start = .;
-   *(.prom.pgt)
-   *(.prom.data)
-   *(.prom.text)
-   . = ALIGN(16);
-   __prom_end = .;
-   *(.text)
-   *(.fixup)
-   *(.gnu.warning)
-/* *(.got1)*/
-   . = ALIGN(16);
-   *(.eh_frame)
-   *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*)))
-   }
-   . = ALIGN(4);
-   _etext = .;
-
-   /* CMD Table */
-
-
-   . = ALIGN(4);
-   .u_boot_list : {
-   KEEP(*(SORT(.u_boot_list*)));
-   }
-
-   .data   :
-   {
-   *(.data)
-   *(.data1)
-   *(.data.rel)
-   *(.data.rel.*)
-   *(.sdata)
-   *(.sdata2)
-   *(.dynamic)
-   CONSTRUCTORS
-   }
-   _edata  =   .;
-   PROVIDE (edata = .);
-
-   . = ALIGN(4);
-   __got_start = .;
-   .got : {
-   *(.got)
-/* *(.data.rel)
-   *(.data.rel.local)*/
-   . = ALIGN(16);
-   }
-   __got_end = .;
-
-/* .data.rel : { } */
-
-   . = ALIGN(4096);
-   __init_begin = .;
-   .text.init : { *(.text.init) }
-   .data.init : { *(.data.init) }
-   . = ALIGN(4096);
-   __init_end = .;
-
-   __bss_start = .;
-   .bss:
-   {
-*(.sbss) *(.scommon)
-*(.dynbss)
-*(.bss)
-*(COMMON)
-   . = ALIGN(16); /* t

[U-Boot] [PATCH 0/2] Merge all SPARC linker scripts into a single file

2014-06-19 Thread Masahiro Yamada
In the other architecutres, the default linker scripts are placed at
arch/${ARCH}/cpu/u-boot.lds or arch/${ARCH}/cpu/${CPU}/u-boot.lds.

On the other hand, SPARC does not have arch-default linker script
but has almost the same linker scripts under each board directory.

They can be easily merged.

I built all SPARC boards and compared MD5SUM.
The same binaries are produced before/after this series.
So I am sure this clean-up is correct.



Masahiro Yamada (2):
  sparc: merge LEON3 linker scripts
  sparc: merge LEON2 and LEON3 linker scripts

 {board/gaisler/grsim => arch/sparc/cpu}/u-boot.lds |   6 +-
 board/gaisler/gr_cpci_ax2000/u-boot.lds| 143 
 board/gaisler/gr_ep2s60/u-boot.lds | 143 
 board/gaisler/gr_xc3s_1500/u-boot.lds  | 145 -
 board/gaisler/grsim_leon2/u-boot.lds   | 142 
 5 files changed, 2 insertions(+), 577 deletions(-)
 rename {board/gaisler/grsim => arch/sparc/cpu}/u-boot.lds (95%)
 delete mode 100644 board/gaisler/gr_cpci_ax2000/u-boot.lds
 delete mode 100644 board/gaisler/gr_ep2s60/u-boot.lds
 delete mode 100644 board/gaisler/gr_xc3s_1500/u-boot.lds
 delete mode 100644 board/gaisler/grsim_leon2/u-boot.lds

-- 
1.9.1

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


[U-Boot] [PATCH] powerpc/t1040qds: Initialize EPHY2 clock to RGMII only

2014-06-19 Thread Vijay Rai
>From FPGAv9 onwards, new bits added for EPHY2 signal mux.
Setting FPGA register brdcfg9 EPHY2 bits to '0' to initialize EPHY2 clock to 
RGMII mode.

Signed-off-by: Vijay Rai 
Signed-off-by: Priyanka Jain 
Signed-off-by: Prabhakar Kushwaha 
---
 board/freescale/t1040qds/eth.c|4 +++-
 board/freescale/t1040qds/t1040qds_qixis.h |4 
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/board/freescale/t1040qds/eth.c b/board/freescale/t1040qds/eth.c
index 3077b4a..1929bba 100644
--- a/board/freescale/t1040qds/eth.c
+++ b/board/freescale/t1040qds/eth.c
@@ -355,7 +355,9 @@ static void set_brdcfg9_for_gtx_clk(void)
 {
u8 brdcfg9;
brdcfg9 = QIXIS_READ(brdcfg[9]);
-   brdcfg9 |= (1 << 5);
+/* Initializing EPHY2 clock to RGMII mode */
+   brdcfg9 &= ~(BRDCFG9_EPHY2_MASK);
+   brdcfg9 |= (BRDCFG9_EPHY2_VAL);
QIXIS_WRITE(brdcfg[9], brdcfg9);
 }
 
diff --git a/board/freescale/t1040qds/t1040qds_qixis.h 
b/board/freescale/t1040qds/t1040qds_qixis.h
index 98d2d39..cef8ad0 100644
--- a/board/freescale/t1040qds/t1040qds_qixis.h
+++ b/board/freescale/t1040qds/t1040qds_qixis.h
@@ -17,6 +17,10 @@
 #define BRDCFG5_IMX_MASK   0xC0
 #define BRDCFG5_IMX_DIU0x80
 
+/* BRDCFG9[2] controls EPHY2 Clock */
+#define BRDCFG9_EPHY2_MASK  0x20
+#define BRDCFG9_EPHY2_VAL   0x00
+
 /* BRDCFG15[3] controls LCD Panel Powerdown*/
 #define BRDCFG15_LCDPD_MASK0x10
 #define BRDCFG15_LCDPD_ENABLED 0x00
-- 
1.7.9.5

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


[U-Boot] [PATCH 3/7] mpc8xx: remove rbc823 board support

2014-06-19 Thread Masahiro Yamada
This board is old enough and has no maintainer.

Signed-off-by: Masahiro Yamada 
---

 board/rbc823/Makefile  |   8 -
 board/rbc823/flash.c   | 445 -
 board/rbc823/kbd.c | 253 --
 board/rbc823/rbc823.c  | 256 --
 board/rbc823/u-boot.lds|  92 --
 boards.cfg |   1 -
 doc/README.scrapyard   |   1 +
 drivers/video/mpc8xx_lcd.c |  67 +--
 include/commproc.h |   2 +-
 include/configs/RBC823.h   | 407 -
 include/lcd.h  |   4 -
 include/status_led.h   |  19 --
 12 files changed, 3 insertions(+), 1552 deletions(-)
 delete mode 100644 board/rbc823/Makefile
 delete mode 100644 board/rbc823/flash.c
 delete mode 100644 board/rbc823/kbd.c
 delete mode 100644 board/rbc823/rbc823.c
 delete mode 100644 board/rbc823/u-boot.lds
 delete mode 100644 include/configs/RBC823.h

diff --git a/board/rbc823/Makefile b/board/rbc823/Makefile
deleted file mode 100644
index 060a144..000
--- a/board/rbc823/Makefile
+++ /dev/null
@@ -1,8 +0,0 @@
-#
-# (C) Copyright 2000-2006
-# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
-#
-# SPDX-License-Identifier: GPL-2.0+
-#
-
-obj-y  = rbc823.o flash.o kbd.o
diff --git a/board/rbc823/flash.c b/board/rbc823/flash.c
deleted file mode 100644
index 8a22652..000
--- a/board/rbc823/flash.c
+++ /dev/null
@@ -1,445 +0,0 @@
-/*
- * (C) Copyright 2000
- * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#include 
-#include 
-
-flash_info_t   flash_info[CONFIG_SYS_MAX_FLASH_BANKS];
-
-/*
- * Functions
- */
-static ulong flash_get_size(vu_long *addr, flash_info_t *info);
-static int write_word(flash_info_t *info, ulong dest, ulong data);
-static void flash_get_offsets(ulong base, flash_info_t *info);
-
-unsigned long flash_init(void)
-{
-   unsigned long size_b0;
-   int i;
-
-   /* Init: no FLASHes known */
-   for (i = 0; i < CONFIG_SYS_MAX_FLASH_BANKS; ++i)
-   flash_info[i].flash_id = FLASH_UNKNOWN;
-
-   /* Detect size */
-   size_b0 = flash_get_size((vu_long *)CONFIG_SYS_FLASH_BASE,
-   &flash_info[0]);
-
-   /* Setup offsets */
-   flash_get_offsets(CONFIG_SYS_FLASH_BASE, &flash_info[0]);
-
-#if CONFIG_SYS_MONITOR_BASE >= CONFIG_SYS_FLASH_BASE
-   /* Monitor protection ON by default */
-   flash_protect(FLAG_PROTECT_SET,
- CONFIG_SYS_MONITOR_BASE,
- CONFIG_SYS_MONITOR_BASE+monitor_flash_len-1,
- &flash_info[0]);
-#endif
-
-   flash_info[0].size = size_b0;
-
-   return size_b0;
-}
-
-/*---
- * Fix this to support variable sector sizes
-*/
-static void flash_get_offsets(ulong base, flash_info_t *info)
-{
-   int i;
-
-   /* set up sector start address table */
-   if ((info->flash_id & FLASH_TYPEMASK) == FLASH_AM040) {
-   /* set sector offsets for bottom boot block type*/
-   for (i = 0; i < info->sector_count; i++)
-   info->start[i] = base + (i * 0x0001);
-   }
-}
-
-/*---
- */
-void flash_print_info(flash_info_t *info)
-{
-   int i;
-
-   if (info->flash_id == FLASH_UNKNOWN) {
-   puts("missing or unknown FLASH type\n");
-   return;
-   }
-
-   switch (info->flash_id & FLASH_VENDMASK) {
-   case FLASH_MAN_AMD:
-   printf("AMD ");
-   break;
-   case FLASH_MAN_FUJ:
-   printf("FUJITSU ");
-   break;
-   case FLASH_MAN_BM:
-   printf("BRIGHT MICRO ");
-   break;
-   default:
-   printf("Unknown Vendor ");
-   break;
-   }
-
-   switch (info->flash_id & FLASH_TYPEMASK) {
-   case FLASH_AM040:
-   printf("29F040 or 29LV040 (4 Mbit, uniform sectors)\n");
-   break;
-   case FLASH_AM400B:
-   printf("AM29LV400B (4 Mbit, bottom boot sect)\n");
-   break;
-   case FLASH_AM400T:
-   printf("AM29LV400T (4 Mbit, top boot sector)\n");
-   break;
-   case FLASH_AM800B:
-   printf("AM29LV800B (8 Mbit, bottom boot sect)\n");
-   break;
-   case FLASH_AM800T:
-   printf("AM29LV800T (8 Mbit, top boot sector)\n");
-   break;
-   case FLASH_AM160B:
-   printf("AM29LV160B (16 Mbit, bottom boot sect)\n");
-   break;
-   case FLASH_AM160T:
-   printf("AM29LV160T (16 Mbit, top boot sector)\n");
-   break;
-   case FLASH_AM320B:
-   printf("AM29LV320B (32 Mbit, bottom boot sect)\n");
-   break;
-   case FLASH_AM320

[U-Boot] [PATCH 0/7] powerpc: Remove mpc8xx boards without maintainers

2014-06-19 Thread Masahiro Yamada

Various global changes are happening to U-boot:
Generic board, driver model, Kconfig, ...

The more boards we have, the more efforts we need
for those future changes.

This series removes MPC8xx boards which have no maintainers.
I guess they are old enough and almost dead.

I built all the other boards and
I confirmed this series has no impact on them.



Masahiro Yamada (7):
  mpc8xx: remove qs850, qs860t board support
  mpc8xx: remove RPXlite_dw, quantum board support
  mpc8xx: remove rbc823 board support
  mpc8xx: remove netta, netta2, netphone board support
  mpc8xx: remove fads board support
  mpc8xx: remove v37 board support
  mpc8xx: remove spc1920 board support

 arch/powerpc/cpu/mpc824x/start.S   |3 -
 arch/powerpc/cpu/mpc8xx/cpu.c  |8 +-
 arch/powerpc/cpu/mpc8xx/cpu_init.c |6 -
 arch/powerpc/cpu/mpc8xx/fec.c  |   46 --
 arch/powerpc/cpu/mpc8xx/scc.c  |   34 -
 arch/powerpc/cpu/mpc8xx/serial.c   |   14 -
 arch/powerpc/cpu/mpc8xx/video.c|   48 +-
 board/RPXlite_dw/Makefile  |8 -
 board/RPXlite_dw/README|  161 
 board/RPXlite_dw/RPXlite_dw.c  |  164 
 board/RPXlite_dw/flash.c   |  474 
 board/RPXlite_dw/u-boot.lds|   82 --
 board/RPXlite_dw/u-boot.lds.debug  |  121 ---
 board/fads/Makefile|8 -
 board/fads/README  |   73 --
 board/fads/fads.c  |  870 -
 board/fads/fads.h  |  468 
 board/fads/flash.c |  544 -
 board/fads/lamp.c  |   43 --
 board/fads/pcmcia.c|   71 --
 board/fads/u-boot.lds  |   85 ---
 board/netphone/Makefile|8 -
 board/netphone/flash.c |  513 -
 board/netphone/netphone.c  |  690 -
 board/netphone/phone_console.c | 1128 ---
 board/netphone/u-boot.lds  |   82 --
 board/netphone/u-boot.lds.debug|  121 ---
 board/netta/Makefile   |8 -
 board/netta/codec.c| 1481 
 board/netta/dsp.c  | 1208 -
 board/netta/flash.c|  492 
 board/netta/netta.c|  558 --
 board/netta/pcmcia.c   |  346 -
 board/netta/u-boot.lds |   82 --
 board/netta/u-boot.lds.debug   |  121 ---
 board/netta2/Makefile  |8 -
 board/netta2/flash.c   |  490 
 board/netta2/netta2.c  |  624 ---
 board/netta2/u-boot.lds|   82 --
 board/netta2/u-boot.lds.debug  |  121 ---
 board/quantum/Makefile |8 -
 board/quantum/fpga.c   |  247 --
 board/quantum/fpga.h   |   16 -
 board/quantum/quantum.c|  243 --
 board/quantum/u-boot.lds   |   82 --
 board/quantum/u-boot.lds.debug |  114 ---
 board/rbc823/Makefile  |8 -
 board/rbc823/flash.c   |  445 ---
 board/rbc823/kbd.c |  253 --
 board/rbc823/rbc823.c  |  256 ---
 board/rbc823/u-boot.lds|   92 ---
 board/snmc/qs850/Makefile  |8 -
 board/snmc/qs850/flash.c   |  600 ---
 board/snmc/qs850/qs850.c   |  214 --
 board/snmc/qs850/u-boot.lds|   85 ---
 board/snmc/qs860t/Makefile |8 -
 board/snmc/qs860t/flash.c  | 1099 --
 board/snmc/qs860t/qs860t.c |  220 --
 board/snmc/qs860t/u-boot.lds   |   82 --
 board/spc1920/Makefile |8 -
 board/spc1920/hpi.c|  596 ---
 board/spc1920/hpi.h|   12 -
 board/spc1920/pld.h|   14 -
 board/spc1920/spc1920.c|  248 --
 board/spc1920/u-boot.lds   |   82 --
 board/v37/Makefile |8 -
 board/v37/flash.c  |  543 -
 board/v37/u-boot.lds   |   82 --
 board/v37/v37.c|  202 -
 boards.cfg |   29 -
 doc/README.scrapyard   |   13 +-
 drivers/pcmcia/Makefile|1 -
 drivers/pcmcia/mpc8xx_pcmcia.c |   10 -
 drivers/pcmcia/rpx_pcmcia.c|   73 --
 drivers/video/mpc8xx_lcd.c |   80 +-
 include/common.h   |8 +-
 include/commproc.h |  144 +---
 include/configs/MPC86xADS.h|   51 --
 include/configs/MPC885ADS.h|   39 -
 include/configs/NETPHONE.h |  701 -
 include/configs/NETTA.h|  666 
 include/configs/NETTA2.h   |  654 
 include/configs/QS823.h|  551 --
 include/configs/QS850.h|  551 --
 include/configs/QS860T.h   |  390 --
 include/configs/RBC823.h 

[U-Boot] [PATCH 6/7] mpc8xx: remove v37 board support

2014-06-19 Thread Masahiro Yamada
This board is old enough and has no maintainer.

Signed-off-by: Masahiro Yamada 
---

 board/v37/Makefile |   8 -
 board/v37/flash.c  | 543 -
 board/v37/u-boot.lds   |  82 ---
 board/v37/v37.c| 202 -
 boards.cfg |   1 -
 doc/README.scrapyard   |   1 +
 drivers/video/mpc8xx_lcd.c |   8 +-
 include/commproc.h |  23 --
 include/configs/v37.h  | 375 ---
 9 files changed, 2 insertions(+), 1241 deletions(-)
 delete mode 100644 board/v37/Makefile
 delete mode 100644 board/v37/flash.c
 delete mode 100644 board/v37/u-boot.lds
 delete mode 100644 board/v37/v37.c
 delete mode 100644 include/configs/v37.h

diff --git a/board/v37/Makefile b/board/v37/Makefile
deleted file mode 100644
index 2df4b82..000
--- a/board/v37/Makefile
+++ /dev/null
@@ -1,8 +0,0 @@
-#
-# (C) Copyright 2003-2006
-# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
-#
-# SPDX-License-Identifier: GPL-2.0+
-#
-
-obj-y  = v37.o flash.o
diff --git a/board/v37/flash.c b/board/v37/flash.c
deleted file mode 100644
index 5b34af2..000
--- a/board/v37/flash.c
+++ /dev/null
@@ -1,543 +0,0 @@
-/*
- * (C) Copyright 2003
- * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-/*
- * Yoo. Jonghoon, IPone, yo...@ipone.co.kr
- * U-Boot port on RPXlite board
- *
- * Some of flash control words are modified. (from 2x16bit device
- * to 4x8bit device)
- * RPXLite board I tested has only 4 AM29LV800BB devices. Other devices
- * are not tested.
- *
- * (?) Does an RPXLite board which
- * does not use AM29LV800 flash memory exist ?
- * I don't know...
- */
-
-#include 
-#include 
-
-flash_info_t   flash_info[CONFIG_SYS_MAX_FLASH_BANKS]; /* info for FLASH chips 
*/
-
-/*---
- * Functions
- */
-static ulong flash_get_size ( short manu, short dev_id, flash_info_t *info);
-static int write_word (flash_info_t *info, ulong dest, ulong data);
-static void flash_get_offsets (ulong base, flash_info_t *info, int two_chips);
-static void flash_get_id_word( void *ptr,  short *ptr_manuf, short 
*ptr_dev_id);
-static void flash_get_id_long( void *ptr,  short *ptr_manuf, short 
*ptr_dev_id);
-
-/*---
- */
-
-unsigned long flash_init (void)
-{
-   volatile immap_t *immap  = (immap_t *)CONFIG_SYS_IMMR;
-   volatile memctl8xx_t *memctl = &immap->im_memctl;
-   unsigned long size_b0, size_b1;
-   short manu, dev_id;
-   int i;
-
-   /* Init: no FLASHes known */
-   for (i=0; imemc_or0 = CONFIG_SYS_OR_TIMING_FLASH | (0 - size_b0);
-
-#if CONFIG_SYS_MONITOR_BASE >= CONFIG_SYS_FLASH_BASE0
-   /* monitor protection ON by default */
-   flash_protect(FLAG_PROTECT_SET,
- CONFIG_SYS_MONITOR_BASE,
- CONFIG_SYS_MONITOR_BASE+monitor_flash_len-1,
- &flash_info[0]);
-#endif
-
-   flash_get_id_long((void*)CONFIG_SYS_FLASH_BASE1,&manu,&dev_id);
-
-   size_b1 = 2 * flash_get_size(manu, dev_id, &flash_info[1]);
-
-   flash_get_offsets(CONFIG_SYS_FLASH_BASE1, &flash_info[1],1);
-
-   memctl->memc_or1 = CONFIG_SYS_OR_TIMING_FLASH | (0 - size_b1);
-
-   flash_info[0].size = size_b0;
-   flash_info[1].size = size_b1;
-
-   return (size_b0+size_b1);
-}
-
-/*---
- */
-static void flash_get_offsets (ulong base, flash_info_t *info, int two_chips)
-{
-   int i, addr_shift;
-   vu_short *addr = (vu_short*)base;
-
-   addr[0x555] = 0x00AA ;
-   addr[0xAAA] = 0x0055 ;
-   addr[0x555] = 0x0090 ;
-
-   addr_shift = (two_chips ? 2 : 1 );
-
-   /* set up sector start address table */
-   if (info->flash_id & FLASH_BTYPE) {
-   /* set sector offsets for bottom boot block type*/
-   info->start[0] = base + (0xstart[i] = base + ((i-3) * 
(0x8000start[i--] = base + info->size - (0x2000size - (0x3000size - (0x4000<= 0; i--) {
-   info->start[i] = base + i * (0x8000start[i]);
-   info->protect[i] = addr[1flash

[U-Boot] [PATCH 7/7] mpc8xx: remove spc1920 board support

2014-06-19 Thread Masahiro Yamada
This board is old enough and has no maintainer.

Signed-off-by: Masahiro Yamada 
---

 arch/powerpc/cpu/mpc8xx/cpu_init.c |   1 -
 board/spc1920/Makefile |   8 -
 board/spc1920/hpi.c| 596 -
 board/spc1920/hpi.h|  12 -
 board/spc1920/pld.h|  14 -
 board/spc1920/spc1920.c| 248 ---
 board/spc1920/u-boot.lds   |  82 -
 boards.cfg |   1 -
 doc/README.scrapyard   |   1 +
 include/configs/spc1920.h  | 405 -
 10 files changed, 1 insertion(+), 1367 deletions(-)
 delete mode 100644 board/spc1920/Makefile
 delete mode 100644 board/spc1920/hpi.c
 delete mode 100644 board/spc1920/hpi.h
 delete mode 100644 board/spc1920/pld.h
 delete mode 100644 board/spc1920/spc1920.c
 delete mode 100644 board/spc1920/u-boot.lds
 delete mode 100644 include/configs/spc1920.h

diff --git a/arch/powerpc/cpu/mpc8xx/cpu_init.c 
b/arch/powerpc/cpu/mpc8xx/cpu_init.c
index b4001de..e51fec7 100644
--- a/arch/powerpc/cpu/mpc8xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc8xx/cpu_init.c
@@ -138,7 +138,6 @@ void cpu_init_f (volatile immap_t * immr)
 defined(CONFIG_MHPC)   || \
 defined(CONFIG_R360MPI)|| \
 defined(CONFIG_RMU)|| \
-defined(CONFIG_SPC1920)|| \
 defined(CONFIG_SPD823TS)
 
memctl->memc_br0 = CONFIG_SYS_BR0_PRELIM;
diff --git a/board/spc1920/Makefile b/board/spc1920/Makefile
deleted file mode 100644
index c0c9a32..000
--- a/board/spc1920/Makefile
+++ /dev/null
@@ -1,8 +0,0 @@
-#
-# (C) Copyright 2000-2006
-# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
-#
-# SPDX-License-Identifier: GPL-2.0+
-#
-
-obj-y  = spc1920.o hpi.o
diff --git a/board/spc1920/hpi.c b/board/spc1920/hpi.c
deleted file mode 100644
index c593837..000
--- a/board/spc1920/hpi.c
+++ /dev/null
@@ -1,596 +0,0 @@
-/*
- * (C) Copyright 2006
- * Markus Klotzbuecher, DENX Software Engineering, m...@denx.de.
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-/*
- * Host Port Interface (HPI)
- */
-
-/* debug levels:
- *  0 : errors
- *  1 : usefull info
- *  2 : lots of info
- *  3 : noisy
- */
-
-#define DEBUG 0
-
-#include 
-#include 
-#include 
-
-#include "pld.h"
-#include "hpi.h"
-
-#define_NOT_USED_  0x
-
-/* original table:
- * - inserted loops to achieve long CS low and high Periods (~217ns)
- * - move cs high 2/4 to the right
- */
-const uint dsp_table_slow[] =
-{
-   /* single read   (offset  0x00 in upm ram) */
-   0x8fffdc04, 0x0fffdc84, 0x0fffdc84, 0x0fffdc00,
-   0x3fffdc04, 0xdc84, 0xdc84, 0xdc05,
-
-   /* burst read(offset 0x08 in upm ram) */
-   _NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
-   _NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
-   _NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
-   _NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
-
-   /* single write  (offset 0x18 in upm ram) */
-   0x8fffd004, 0x0fffd084, 0x0fffd084, 0x3fffd000,
-   0xd084, 0xd084, 0xd005, _NOT_USED_,
-
-   /* burst write   (offset 0x20 in upm ram) */
-   _NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
-   _NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
-   _NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
-   _NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
-   /* refresh   (offset 0x30 in upm ram) */
-   _NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
-   _NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
-   _NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
-   /* exception (offset 0x3C in upm ram) */
-   _NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
-};
-
-/* dsp hpi upm ram table
- * works fine for noninc access, failes on incremental.
- * - removed first word
- */
-const uint dsp_table_fast[] =
-{
-   /* single read   (offset  0x00 in upm ram) */
-   0x8fffdc04, 0x0fffdc04, 0x0fffdc00, 0x3fffdc04,
-   0xdc05, _NOT_USED_, _NOT_USED_, _NOT_USED_,
-
-   /* burst read(offset 0x08 in upm ram) */
-   _NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
-   _NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
-   _NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
-   _NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
-
-   /* single write  (offset 0x18 in upm ram) */
-   0x8fffd004, 0x0fffd004, 0x3fffd000, 0xd005,
-   _NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
-
-   /* burst write   (offset 0x20 in upm ram) */
-   _NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
-   _NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
-   _NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
-   _NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
-   /* refresh   (offset 0x30 in upm ram) */
-   _NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
-   _NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
-   _NOT_USED_, _NOT_USED_, _N

Re: [U-Boot] [Patch v7 5/5] ARMv8/ls2100a_emu: Add LS2100A emulator and simulator board support

2014-06-19 Thread York Sun


On 6/18/14 12:05 PM, "York Sun"  wrote:

>LS2100A is an ARMv8 implementation. This adds board support for emulator
>and simulator:
>  Two DDR controllers
>  UART2 is used as the console
>  IFC timing is tightened for speedy booting
>  Support DDR3 and DDR4 as separated targets
>  Management Complex (MC) is enabled
>
>Signed-off-by: York Sun 
>Signed-off-by: Arnab Basu 
>Signed-off-by: J. German Rivera 
>Signed-off-by: Bhupesh Sharma 
>---

Please do not apply this patch. The SoC name has changed. I will send out
a new version soon.

York

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


Re: [U-Boot] [PATCH v4 09/15] dm: Cast away the const-ness of the global_data pointer

2014-06-19 Thread Marek Vasut
On Friday, June 20, 2014 at 06:07:02 AM, Simon Glass wrote:
> Hi Marek,
> 
> On 17 June 2014 23:36, Simon Glass  wrote:
> > Hi Marek,
> > 
> > On 17 June 2014 16:42, Marek Vasut  wrote:
> >> On Thursday, June 12, 2014 at 05:26:50 AM, Simon Glass wrote:
> >>> Hi Marek,
> >>> 
> >>> On 8 June 2014 01:00, Marek Vasut  wrote:
> >>> > On Friday, June 06, 2014 at 09:13:26 PM, Simon Glass wrote:
> >>> >> In a very few cases we need to adjust the driver model root device,
> >>> >> such as when setting it up at initialisation. Add a macro to make
> >>> >> this easier.
> >>> >> 
> >>> >> Signed-off-by: Simon Glass 
> >>> >> ---
> >>> > 
> >>> > [...]
> >>> > 
> >>> >> - ret = device_bind_by_name(NULL, &root_info, &gd->dm_root);
> >>> >> + ret = device_bind_by_name(NULL, &root_info, &DM_ROOT());
> >>> > 
> >>> > [...]
> >>> > 
> >>> >> +/* Cast away any volatile pointer */
> >>> >> +#define DM_ROOT()(((gd_t *)gd)->dm_root)
> >>> >> +#define DM_UCLASS_ROOT() (((gd_t *)gd)->uclass_root)
> >>> > 
> >>> > Can you implement this "DM_ROOT()" macro as a function instead ? I
> >>> > believe that'd be much nicer , would have typechecking etc., usual
> >>> > stuff.
> >>> 
> >>> I had a look at this. I don't see how I can do it, but you might have
> >>> ideas.
> >>> 
> >>> In this function call I need to pass a pointer without its const bit.
> >>> I made it const since nothing should change the dm root except driver
> >>> model itself.
> >> 
> >> All right, I will just be doing a little guesswork here. Shall you not
> >> have some functions to change the DM root then instead of exposing the
> >> DM root ? Such functions shall not be exported publicly , but available
> >> via separate header file too ?
> > 
> > Firstly I should retitle the commit - it is of course the volatile
> > that I'm trying to get rid of as it says in the commit message. I
> > might have just been trying to confuse everyone.
> > 
> > I have code like this:
> > 
> > INIT_LIST_HEAD(&gd->uclass_root);
> > 
> > I don't see how I can turn this into a function. I suppose I could
> > init the list head in a temporary variable and then assign it to
> > gd->uclass_root, perhaps with memcpy(), but that doesn't really seem
> > any better to me.
> > 
> >> Sorry, I might be completely wrong.
> > 
> > Well I'm not saying it's pretty, so if you have time and come up with
> > a better option please let me know.
> > 
> > Also, this is not exported 'publicly'. It is in device-internal.h
> 
> Please let me know on this one. If you have a better option please let me
> know.
> 
> Otherwise I'd like to do a dm pull request soon to get these fixes
> into the release.

Ah, please get the PR out. We can tweak this later I'm sure. Apologies for 
holding you and the PR.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v4 09/15] dm: Cast away the const-ness of the global_data pointer

2014-06-19 Thread Simon Glass
Hi Marek,

On 17 June 2014 23:36, Simon Glass  wrote:
> Hi Marek,
>
> On 17 June 2014 16:42, Marek Vasut  wrote:
>> On Thursday, June 12, 2014 at 05:26:50 AM, Simon Glass wrote:
>>> Hi Marek,
>>>
>>> On 8 June 2014 01:00, Marek Vasut  wrote:
>>> > On Friday, June 06, 2014 at 09:13:26 PM, Simon Glass wrote:
>>> >> In a very few cases we need to adjust the driver model root device, such
>>> >> as when setting it up at initialisation. Add a macro to make this
>>> >> easier.
>>> >>
>>> >> Signed-off-by: Simon Glass 
>>> >> ---
>>> >
>>> > [...]
>>> >
>>> >> - ret = device_bind_by_name(NULL, &root_info, &gd->dm_root);
>>> >> + ret = device_bind_by_name(NULL, &root_info, &DM_ROOT());
>>> >
>>> > [...]
>>> >
>>> >> +/* Cast away any volatile pointer */
>>> >> +#define DM_ROOT()(((gd_t *)gd)->dm_root)
>>> >> +#define DM_UCLASS_ROOT() (((gd_t *)gd)->uclass_root)
>>> >
>>> > Can you implement this "DM_ROOT()" macro as a function instead ? I
>>> > believe that'd be much nicer , would have typechecking etc., usual
>>> > stuff.
>>>
>>> I had a look at this. I don't see how I can do it, but you might have
>>> ideas.
>>>
>>> In this function call I need to pass a pointer without its const bit.
>>> I made it const since nothing should change the dm root except driver
>>> model itself.
>>
>> All right, I will just be doing a little guesswork here. Shall you not have 
>> some
>> functions to change the DM root then instead of exposing the DM root ? Such
>> functions shall not be exported publicly , but available via separate header
>> file too ?
>
> Firstly I should retitle the commit - it is of course the volatile
> that I'm trying to get rid of as it says in the commit message. I
> might have just been trying to confuse everyone.
>
> I have code like this:
>
> INIT_LIST_HEAD(&gd->uclass_root);
>
> I don't see how I can turn this into a function. I suppose I could
> init the list head in a temporary variable and then assign it to
> gd->uclass_root, perhaps with memcpy(), but that doesn't really seem
> any better to me.
>
>>
>> Sorry, I might be completely wrong.
>
> Well I'm not saying it's pretty, so if you have time and come up with
> a better option please let me know.
>
> Also, this is not exported 'publicly'. It is in device-internal.h

Please let me know on this one. If you have a better option please let me know.

Otherwise I'd like to do a dm pull request soon to get these fixes
into the release.

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


Re: [U-Boot] [PATCH 10/10] Pit WIP

2014-06-19 Thread Simon Glass
Hi Ajay,

On 17 June 2014 03:06, Ajay Kumar  wrote:
> From: Simon Glass 
>
> WIP patch to enable cros-ec on peach_pit.
>
> Signed-off-by: Simon Glass 
> ---
>  drivers/misc/cros_ec_spi.c|   4 +-
>  drivers/power/pmic/Makefile   |   3 +-
>  drivers/power/pmic/pmic_tps65090_ec.c | 212 
> ++
>  drivers/spi/exynos_spi.c  |   9 +-
>  drivers/spi/spi.c |   2 +
>  include/configs/exynos5-dt.h  |   2 +-
>  include/configs/peach-pit.h   |   2 +
>  include/power/tps65090_pmic.h |   6 +
>  8 files changed, 232 insertions(+), 8 deletions(-)
>  create mode 100644 drivers/power/pmic/pmic_tps65090_ec.c

Yes I will put together a few patches for this, thanks for posting it.
Until we have driver model I2C we are going to have to live with
duplicating this driver for the EC interface.

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


Re: [U-Boot] [PATCH 09/10] CONFIGS: peach-pit: Enable display for peach_pit board

2014-06-19 Thread Simon Glass
Hi Ajay,

On 17 June 2014 03:06, Ajay Kumar  wrote:
> Enable drivers for FIMD, DP and parade bridge chip.
>
> Signed-off-by: Ajay Kumar 
> ---
>  include/configs/peach-pit.h | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/include/configs/peach-pit.h b/include/configs/peach-pit.h
> index 76b8d7a..88c093f 100644
> --- a/include/configs/peach-pit.h
> +++ b/include/configs/peach-pit.h
> @@ -22,4 +22,14 @@
>  #define CONFIG_SYS_PROMPT  "Peach # "
>  #define CONFIG_IDENT_STRING" for Peach"
>
> +#define CONFIG_VIDEO_PARADE
> +
> +/* Display */
> +#define CONFIG_LCD
> +#ifdef CONFIG_LCD
> +#define CONFIG_EXYNOS_FB
> +#define CONFIG_EXYNOS_DP
> +#define LCD_BPPLCD_COLOR16
> +#endif
> +
>  #endif /* __CONFIG_PEACH_PIT_H */

Can this go in exynos5420.h? It seems to be common except for the PARADE bit.

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


Re: [U-Boot] [PATCH 08/10] ARM: exynos: peach_pit: Add DT nodes for fimd and parade bridge chip

2014-06-19 Thread Simon Glass
On 17 June 2014 03:06, Ajay Kumar  wrote:
> This patch adds DT properties for fimd and the parade bridge chip
> present on peach_pit. The panel supports 1366x768 resolution.
>
> Signed-off-by: Ajay Kumar 

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


Re: [U-Boot] [PATCH 07/10] exynos5420: add callbacks needed for exynos_fb driver

2014-06-19 Thread Simon Glass
On 17 June 2014 03:06, Ajay Kumar  wrote:
> Add initialization code for peach_pit panel, parade bridge chip,
> and backlight.
>
> Signed-off-by: Ajay Kumar 

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


Re: [U-Boot] [PATCH 06/10] ARM: exynos: Add missing declaration for gpio_direction_input

2014-06-19 Thread Simon Glass
Hi Ajay,

On 17 June 2014 03:06, Ajay Kumar  wrote:
> This patch adds missing declaration for gpio_direction_input
> function, thereby helps in resolving compilation warnings.
>
> Signed-off-by: Ajay Kumar 
> ---
>  arch/arm/include/asm/arch-exynos/gpio.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/include/asm/arch-exynos/gpio.h 
> b/arch/arm/include/asm/arch-exynos/gpio.h
> index be5113f..8fb5c23 100644
> --- a/arch/arm/include/asm/arch-exynos/gpio.h
> +++ b/arch/arm/include/asm/arch-exynos/gpio.h
> @@ -1504,6 +1504,7 @@ static const struct gpio_name_num_table 
> exynos5420_gpio_table[] = {
>  void gpio_cfg_pin(int gpio, int cfg);
>  void gpio_set_pull(int gpio, int mode);
>  void gpio_set_drv(int gpio, int mode);
> +int gpio_direction_input(unsigned gpio);
>  int gpio_direction_output(unsigned gpio, int value);
>  int gpio_set_value(unsigned gpio, int value);
>  int gpio_get_value(unsigned gpio);
> --
> 1.8.1.2

Actually I think that the problem is that we are using asm/arch/gpio.h
instead of asm/gpio.h. I have a patch that fixes this - see
u-boot-dm.git branch working, commit 56236bf. I expect to send a patch
next week.

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


Re: [U-Boot] [PATCH 04/10] video: exynos_fimd: Add framework to disable FIMD sysmmu

2014-06-19 Thread Simon Glass
On 17 June 2014 03:06, Ajay Kumar  wrote:
> On Exynos5420 and newer versions, the FIMD sysmmus are in
> "on state" by default.
> We have to disable them in order to make FIMD DMA work.
> This patch adds the required framework to exynos_fimd driver,
> and disables FIMD sysmmu on Exynos5420.
>
> Signed-off-by: Ajay Kumar 

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


Re: [U-Boot] [PATCH 03/10] arm: exynos: Add get_lcd_clk and set_lcd_clk callbacks for Exynos5420

2014-06-19 Thread Simon Glass
On 17 June 2014 03:06, Ajay Kumar  wrote:
> Add get_lcd_clk and set_lcd_clk callbacks for Exynos5420 needed by
> exynos video driver.
> Also, configure ACLK_400_DISP1 as the parent for MUX_ACLK_400_DISP1_SUB_SEL.
>
> Signed-off-by: Ajay Kumar 

(BTW please don't send patches to my google.com address as I use
Chromium for this - thanks)

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


Re: [U-Boot] [PATCH 05/10] video: Add driver for Parade PS8625 dP to LVDS bridge

2014-06-19 Thread Simon Glass
On 17 June 2014 03:06, Ajay Kumar  wrote:
> From: Vadim Bendebury 
>
> The initialization table comes from the "Illustration of I2C command
> for initialing PS8625" document supplied by Parade.
>
> Signed-off-by: Vadim Bendebury 
> Signed-off-by: Ajay Kumar 

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


Re: [U-Boot] [PATCH 05/10] video: Add driver for Parade PS8625 dP to LVDS bridge

2014-06-19 Thread Simon Glass
On 17 June 2014 03:06, Ajay Kumar  wrote:
> From: Vadim Bendebury 
>
> The initialization table comes from the "Illustration of I2C command
> for initialing PS8625" document supplied by Parade.
>
> Signed-off-by: Vadim Bendebury 
> Signed-off-by: Ajay Kumar 

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


Re: [U-Boot] [PATCH 04/10] video: exynos_fimd: Add framework to disable FIMD sysmmu

2014-06-19 Thread Simon Glass
On 17 June 2014 03:06, Ajay Kumar  wrote:
> On Exynos5420 and newer versions, the FIMD sysmmus are in
> "on state" by default.
> We have to disable them in order to make FIMD DMA work.
> This patch adds the required framework to exynos_fimd driver,
> and disables FIMD sysmmu on Exynos5420.
>
> Signed-off-by: Ajay Kumar 

Acked-by: Simon Glass 
Tested-by: Simon Glass 

(I assume this is the same device tree binding as Linux?)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 03/10] arm: exynos: Add get_lcd_clk and set_lcd_clk callbacks for Exynos5420

2014-06-19 Thread Simon Glass
On 17 June 2014 03:06, Ajay Kumar  wrote:
> Add get_lcd_clk and set_lcd_clk callbacks for Exynos5420 needed by
> exynos video driver.
> Also, configure ACLK_400_DISP1 as the parent for MUX_ACLK_400_DISP1_SUB_SEL.
>
> Signed-off-by: Ajay Kumar 

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


Re: [U-Boot] [PATCH 02/10] arm: exynos: Add RPLL for Exynos5420

2014-06-19 Thread Simon Glass
On 17 June 2014 03:06, Ajay Kumar  wrote:
> RPLL is needed to drive the LCD panel on Exynos5420 based boards.
>
> Signed-off-by: Ajay Kumar 

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


Re: [U-Boot] [PATCH 01/10] exynos_fb: Remove usage of static defines

2014-06-19 Thread Simon Glass
On 17 June 2014 03:06, Ajay Kumar  wrote:
> Previously, we used to statically assign values for vl_col, vl_row and
> vl_bpix using #defines like LCD_XRES, LCD_YRES and LCD_COLOR16.
>
> Introducing the function exynos_lcd_early_init() would take care of this
> assignment on the fly by parsing FIMD DT properties, thereby allowing us
> to remove LCD_XRES and LCD_YRES from the main config file.
>
> Signed-off-by: Ajay Kumar 

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


Re: [U-Boot] [PATCH v4 1/6] Exynos5420: Let macros be used for exynos5420

2014-06-19 Thread Simon Glass
On 18 June 2014 06:23, Akshay Saraswat  wrote:
> Macros defined in exynos5_setup.h specific to SMDK5420
> are required for Peach-Pit too. Hence, replacing
> CONFIG_SMDK5420 with CONFIG_EXYNOS5420 to enable these
> macros for all the boards based on Exynos5420.
>
> Signed-off-by: Akshay Saraswat 
> Acked-by: Simon Glass 
Tested-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v4 0/6] Introduction of new board Peach-Pit

2014-06-19 Thread Simon Glass
Hi Akshay,

On 18 June 2014 06:23, Akshay Saraswat  wrote:
> This board is based on Exynos5420 and is similar to SMDK5420 board.
> Adding new and refactoring existing  DT and config files to support
> both SMDK5420 and Peach-Pit.
> This patch set also intends to place env at the end of flash, increase
> SPL footprint, enable USB boot mode and split memory bank config.
>
> Changes since v1:
> - Added "Acked-by".
> Changes since v2:
> - Changed order of the patches because 2/2 alone results in compiler
>   errors and has dependency over patch 1/2.
> - Removed CONFIG_CHROMEOS_PEACH.
> Changes since v3:
> - Took four patches in this set from a different patch set.
> - Rebased all the patches to Top of Tree.
>
> Akshay Saraswat (5):
>   Exynos5420: Let macros be used for exynos5420
>   Exynos5420: Introduce support for the Peach-Pit board
>   Exynos5: Config: Place environment at the end of SPI flash
>   Exynos5: Config: Increase SPL footprint for Exynos5420
>   Exynos5: Config: Enable USB boot mode for all Exynos5 SoCs
>
> Michael Pratt (1):
>   Exynos: Split 5250 and 5420 memory bank configuration

For me I needed to reduce the speed in SPL to 900MHz by adding this to
the device tree:

arm-frequency = <9>;

Otherwise it would not boot over USB A-A.

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


Re: [U-Boot] [PATCH 2/5] kbuild: sync mixed targets handling with Linux 3.16-rc1

2014-06-19 Thread Masahiro Yamada
Hi Jeroen,


On Tue, 17 Jun 2014 20:45:05 +0200
Jeroen Hofstee  wrote:

> [jeroen@freebsd /usr/home/jeroen/u-boot]$ gmake CC="cc" HOSTCC="cc" V=1 
> NO_SDL=1 sandbox_config tools
> set -e; \
> for i in sandbox_config tools; do \
>  gmake -f /usr/home/jeroen/u-boot/Makefile $i; \
> done
> Configuring for sandbox board...
>cc -x c -DDO_DEPS_ONLY -M -Wall -Wstrict-prototypes -Wno-format-security 
> -fno-builtin -ffreestanding -Os -fno-stack-protector -g 
> -Wno-format-nonliteral   -D__KERNEL__ -DCONFIG_SANDBOX -D__SANDBOX__ 
> -U_FORTIFY_SOURCE -DCONFIG_ARCH_MAP_SYSMEM -DCONFIG_SYS_GENERIC_BOARD 
> -DSANDBOX_NO_SDL  -pipe -Iinclude 
> -I/usr/home/jeroen/u-boot/arch/sandbox/include  -nostdinc -isystem 
> /usr/lib/include -MQ include/autoconf.mk 
> /usr/home/jeroen/u-boot/include/common.h > include/autoconf.mk.dep || rm 
> include/autoconf.mk.dep
>cc -E -Wall -Wstrict-prototypes -Wno-format-security -fno-builtin 
> -ffreestanding -Os  -fno-stack-protector -g -Wno-format-nonliteral 
> -D__KERNEL__   -DCONFIG_SANDBOX -D__SANDBOX__ -U_FORTIFY_SOURCE 
> -DCONFIG_ARCH_MAP_SYSMEM -DCONFIG_SYS_GENERIC_BOARD -DSANDBOX_NO_SDL  -pipe 
> -Iinclude -I/usr/home/jeroen/u-boot/arch/sandbox/include  -nostdinc -isystem 
> /usr/lib/include -DDO_DEPS_ONLY -dM /usr/home/jeroen/u-boot/include/common.h 
> > include/autoconf.mk.tmp && sed -n -f 
> /usr/home/jeroen/u-boot/tools/scripts/define2mk.sed include/autoconf.mk.tmp > 
> include/autoconf.mk; rm include/autoconf.mk.tmp
> gmake[1]: gcc: Command not found
> gmake[1]: gcc: Command not found
> gcc: not found


What looks really weird here is that
gmake invoked 'cc',
but an error message 'gcc :Command not found' was displayed.

I don't know why.



Best Regards
Masahiro Yamada

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


Re: [U-Boot] [PATCH 2/5] kbuild: sync mixed targets handling with Linux 3.16-rc1

2014-06-19 Thread Masahiro Yamada
Hi Jeroen,

On Tue, 17 Jun 2014 20:45:05 +0200
Jeroen Hofstee  wrote:

> >> There is some issue with this in current master I guess. I haven't
> >> bothered too much, but I think the one liner cause gcc to be called even
> >> if both compilers are set to clang. With a separate config and make step
> >> I have never seen such behavior. I only noticed it on FreeBSD though
> >> since gcc is not installed there and actually errors, so it might be
> >> awk / sed related as well.
> >>
> >> Anyway, perhaps rings a bell...
> >
> > Could you tell me how to reproduce the problem?
> >
> > As far as I tested on FreeBSD where gcc is not installed,
> > I do not see that problem.
> >
> > This is my repeat steps.
> > It fails on the halfway, but at least Clang is used for both HOSTCC and CC.
> 
> Weird, below is my build output on current master with some floating
> patches to make the build succeed [1] (well I didn't send the time.h yet
> since I don't understand how linux gets away with that at the moment)
> 
> As mentioned I have no clue why it fails and haven't looked into it.
> Just noticed it didn't work.
> 
> [1] https://github.com/jhofstee/u-boot/tree/FreeBSD
> 



I followd the same steps as you did,
using your GitHub repository.

In my test, gcc was not called during the build.


My log is as follows:


$ git clone  g...@github.com:jhofstee/u-boot.git u-boot-bsd
$ cd u-boot-bsd
$ git checkout -b FreeBSD origin/FreeBSD
$ git branch
* FreeBSD
   master
$ git rev-parse HEAD
91882055567ee0c5581ee7c5b9e707dd5ad99142
$ uname -a
FreeBSD collie.diag.org 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu Jan 
16 22:34:59 UTC 2014 r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC  
amd64
$ gcc -v
-bash: gcc: command not found
$ cc -v
FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
Target: x86_64-unknown-freebsd10.0
Thread model: posix
$ gmake -v
GNU Make 3.82
Built for amd64-portbld-freebsd10.0
Copyright (C) 2010  Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ gmake CC="cc" HOSTCC="cc" V=1 NO_SDL=1 sandbox_config tools
set -e; \
for i in sandbox_config tools; do \
gmake -f /usr/home/yamada/workspace/u-boot-bsd/Makefile $i; \
done
Configuring for sandbox board...
  cc -x c -DDO_DEPS_ONLY -M -Wall -Wstrict-prototypes -Wno-format-security 
-fno-builtin -ffreestanding -Os  -fno-stack-protector -g -Wno-format-nonliteral 
  -D__KERNEL__   -DCONFIG_SANDBOX -D__SANDBOX__ -U_FORTIFY_SOURCE 
-DCONFIG_ARCH_MAP_SYSMEM -DCONFIG_SYS_GENERIC_BOARD -DSANDBOX_NO_SDL  -pipe 
-Iinclude  -I/usr/home/yamada/workspace/u-boot-bsd/arch/sandbox/include  
-nostdinc -isystem /usr/lib/include -MQ include/autoconf.mk 
/usr/home/yamada/workspace/u-boot-bsd/include/common.h > 
include/autoconf.mk.dep || rm include/autoconf.mk.dep
  cc -E -Wall -Wstrict-prototypes -Wno-format-security -fno-builtin 
-ffreestanding -Os  -fno-stack-protector -g -Wno-format-nonliteral   
-D__KERNEL__   -DCONFIG_SANDBOX -D__SANDBOX__ -U_FORTIFY_SOURCE 
-DCONFIG_ARCH_MAP_SYSMEM -DCONFIG_SYS_GENERIC_BOARD -DSANDBOX_NO_SDL  -pipe 
-Iinclude  -I/usr/home/yamada/workspace/u-boot-bsd/arch/sandbox/include  
-nostdinc -isystem /usr/lib/include -DDO_DEPS_ONLY -dM 
/usr/home/yamada/workspace/u-boot-bsd/include/common.h > 
include/autoconf.mk.tmp && sed -n -f 
/usr/home/yamada/workspace/u-boot-bsd/tools/scripts/define2mk.sed 
include/autoconf.mk.tmp > include/autoconf.mk; rm include/autoconf.mk.tmp
set -e; : '  CHK include/config/uboot.release'; mkdir -p include/config/;   
echo "2014.07-rc3$(sh 
/usr/home/yamada/workspace/u-boot-bsd/scripts/setlocalversion 
/usr/home/yamada/workspace/u-boot-bsd)" < Makefile > 
include/config/uboot.release.tmp; if [ -r include/config/uboot.release ] && cmp 
-s include/config/uboot.release include/config/uboot.release.tmp; then rm -f 
include/config/uboot.release.tmp; else : '  UPD 
include/config/uboot.release'; mv -f include/config/uboot.release.tmp 
include/config/uboot.release; fi
set -e; : '  CHK include/generated/version_autogenerated.h'; mkdir -p 
include/generated/;   (echo \#define PLAIN_VERSION \"2014.07-rc3-g9188205\"; 
echo \#define U_BOOT_VERSION \"U-Boot \" PLAIN_VERSION; echo \#define 
CC_VERSION_STRING \"$(cc --version | head -n 1)\"; echo \#define 
LD_VERSION_STRING \"$(ld --version | head -n 1)\"; ) < 
include/config/uboot.release > include/generated/version_autogenerated.h.tmp; 
if [ -r include/generated/version_autogenerated.h ] && cmp -s 
include/generated/version_autogenerated.h 
include/generated/version_autogenerated.h.tmp; then rm -f 
include/generated/version_autogenerated.h.tmp; else : '  UPD 
include/generated/version_autogenerated.h'; mv -f 
include/generated/version_autogenerated.h.tmp 
include/generated/version_autogenerated.h; fi
set -e; : '  CHK include/generated/timestamp_autogenerated.h';

Re: [U-Boot] [U-Boot, v8] nand/denali: Adding Denali NAND driver support

2014-06-19 Thread Scott Wood
On Tue, Jun 10, 2014 at 12:42:19AM -0500, Chin Liang See wrote:
> To add the Denali NAND driver support into U-Boot. It required
> information such as register base address from configuration
> header file  within include/configs folder.

This is hard to parse.  What exactly is required from include/configs and
where is it documented?

I see that this driver exists in Linux...  Is this patch related to a
particular Linux SHA1?

> Signed-off-by: Chin Liang See 
> Cc: Artem Bityutskiy 
> Cc: David Woodhouse 
> Cc: Brian Norris 
> Cc: Scott Wood 
> Cc: Masahiro Yamada 
> Signed-off-by: Masahiro Yamada 
> Reviewed-by: Masahiro Yamada 
> Tested-by: Masahiro Yamada 

Are these people on CC because they're involved in the U-Boot patch in
some way, or is this just copy-and-paste from a Linux patch?

> +/* Reset the flash controller */
> +static uint32_t denali_nand_reset(struct denali_nand_info *denali)
> +{
> + uint32_t i;
> +
> + for (i = 0; i < denali->max_banks; i++)
> + writel(INTR_STATUS__RST_COMP | INTR_STATUS__TIME_OUT,
> +denali->flash_reg + INTR_STATUS(i));
> +
> + for (i = 0; i < denali->max_banks; i++) {
> + writel(1 << i, denali->flash_reg + DEVICE_RESET);
> + while (!(readl(denali->flash_reg + INTR_STATUS(i)) &
> + (INTR_STATUS__RST_COMP | INTR_STATUS__TIME_OUT)))
> + if (readl(denali->flash_reg + INTR_STATUS(i)) &
> + INTR_STATUS__TIME_OUT)
> + debug(KERN_DEBUG "NAND Reset operation "
> + "timed out on bank %d\n", i);
> + }

WARNING: quoted string split across lines
#283: FILE: drivers/mtd/nand/denali.c:203:
+   debug(KERN_DEBUG "NAND Reset operation "
+   "timed out on bank %d\n", i);

(likewise elsewhere)

This instance is not even from Linux -- and where does KERN_DEBUG come
from?  The Linux driver has never used it.

> +#if ONFI_BLOOM_TIME
> + if ((en_hi * CLK_X) < (treh[mode] + 2))
> + en_hi++;
> +#endif

When would this #if not be true?

> + if ((en_lo + en_hi) * CLK_X < trc[mode])
> + en_lo += DIV_ROUND_UP((trc[mode] - (en_lo + en_hi) * CLK_X),
> +   CLK_X);
> +
> + if ((en_lo + en_hi) < CLK_MULTI)
> + en_lo += CLK_MULTI - en_lo - en_hi;
> +
> + while (dv_window < 8) {
> + data_invalid_rhoh = en_lo * CLK_X + trhoh[mode];
> +
> + data_invalid_rloh = (en_lo + en_hi) * CLK_X + trloh[mode];
> +
> + data_invalid =
> + data_invalid_rhoh <
> + data_invalid_rloh ? data_invalid_rhoh : data_invalid_rloh;
> +
> + dv_window = data_invalid - trea[mode];
> +
> + if (dv_window < 8)
> + en_lo++;
> + }
> +
> + acc_clks = DIV_ROUND_UP(trea[mode], CLK_X);
> +
> + while (((acc_clks * CLK_X) - trea[mode]) < 3)
> + acc_clks++;
> +
> + if ((data_invalid - acc_clks * CLK_X) < 2)
> + debug(KERN_WARNING "%s, Line %d: Warning!\n",
> +   __FILE__, __LINE__);
> +
> + addr_2_data = DIV_ROUND_UP(tadl[mode], CLK_X);
> + re_2_we = DIV_ROUND_UP(trhw[mode], CLK_X);
> + re_2_re = DIV_ROUND_UP(trhz[mode], CLK_X);
> + we_2_re = DIV_ROUND_UP(twhr[mode], CLK_X);
> + cs_cnt = DIV_ROUND_UP((tcs[mode] - trp[mode]), CLK_X);
> + if (!tclsrising)
> + cs_cnt = DIV_ROUND_UP(tcs[mode], CLK_X);
> + if (cs_cnt == 0)
> + cs_cnt = 1;
> +
> + if (tcea[mode]) {
> + while (((cs_cnt * CLK_X) + trea[mode]) < tcea[mode])
> + cs_cnt++;
> + }
> +
> +#if MODE5_WORKAROUND
> + if (mode == 5)
> + acc_clks = 5;
> +#endif

Likewise, this is dead code.

If these are meant to be configurable, they need to be named as config
symbols, documented, and located in a config file rather than denali.h --
and ideally there should be at least one board that sets the option and
at least one that does not set it, so that both possibilities get build
coverage.

I see that the Linux driver has the same thing, so perhaps we can excuse
it if it's not actually meant to be altered by a user, but in that case
the driver ought to actually correspond to a specific SHA1 of the Linux
driver.

> +/* validation function to verify that the controlling software is making
> + * a valid request
> + */
> +static inline bool is_flash_bank_valid(int flash_bank)
> +{
> + return (flash_bank >= 0 && flash_bank < 4);
> +}

ERROR: return is not a function, parentheses are not required
#589: FILE: drivers/mtd/nand/denali.c:509:
+   return (flash_bank >= 0 && flash_bank < 4);

> +/* setups the HW to perform the data DMA */
> +static void denali_setup_dma(struct denali_nand_info *denali, int op)
> +{
> + uint32_t mode;
> + const int page_count = 1;
> + uint32_t ad

Re: [U-Boot] [U-Boot, U-boot, 2/2] mtd: nand: davinci: allow to change ecclayout by ecclayout command

2014-06-19 Thread Scott Wood
On Fri, May 16, 2014 at 09:26:37PM +0300, Khoronzhuk, Ivan wrote:
> From: WingMan Kwok 
> 
> This patch adds opportunity to change ecclayout of current nand
> device during runtime. So we can change the current nand device
> ecclayout using the "nand ecclayout set" command before writing
> the data to nand flash.
> 
> Signed-off-by: Hao Zhang 
> Signed-off-by: WingMan Kwok 
> Signed-off-by: Ivan Khoronzhuk 
> 
> ---
> drivers/mtd/nand/davinci_nand.c | 101 
>  1 file changed, 101 insertions(+)
> 
> diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
> index 75b03a7..b33de0d 100644
> --- a/drivers/mtd/nand/davinci_nand.c
> +++ b/drivers/mtd/nand/davinci_nand.c
> @@ -306,6 +306,103 @@ static struct nand_ecclayout 
> nand_davinci_4bit_layout_oobfirst = {
>  #endif
>  };
>  
> +#if defined(CONFIG_CMD_NAND_ECCLAYOUT)
> +#if defined(CONFIG_SYS_NAND_PAGE_2K)

Undocumented CONFIG symbol (yes, I know it's not new)... Also redundant
with CONFIG_SYS_NAND_PAGE_SIZE (though that's only documented in the
context of SPL).

> +static struct nand_ecclayout nand_keystone_rbl_4bit_layout_oobfirst = {
> + .eccbytes = 40,
> + .eccpos = {
> + 6, 7,
> + 8, 9, 10, 11, 12, 13, 14, 15,
> + 22, 23,
> + 24, 25, 26, 27, 28, 29, 30, 31,
> + 38, 39,
> + 40, 41, 42, 43, 44, 45, 46, 47,
> + 54, 55,
> + 56, 57, 58, 59, 60, 61, 62, 63,
> + },

Why the odd 2/8 pattern?

> + .oobfree = {
> + {.offset = 2, .length = 4, },
> + {.offset = 16, .length = 6, },
> + {.offset = 32, .length = 6, },
> + {.offset = 48, .length = 6, },
> + },
> +};
> +#elif defined(CONFIG_SYS_NAND_PAGE_4K)
> +static struct nand_ecclayout nand_keystone_rbl_4bit_layout_oobfirst = {
> + .eccbytes = 80,
> + .eccpos = {
> + 6, 7,
> + 8, 9, 10, 11, 12, 13, 14, 15,
> + 22, 23,
> + 24, 25, 26, 27, 28, 29, 30, 31,
> + 38, 39,
> + 40, 41, 42, 43, 44, 45, 46, 47,
> + 54, 55,
> + 56, 57, 58, 59, 60, 61, 62, 63,
> + 70, 71,
> + 72, 73, 74, 75, 76, 77, 78, 79,
> + 86, 87,
> + 88, 89, 90, 91, 92, 93, 94, 95,
> + 102, 103,
> + 104, 105, 106, 107, 108, 109, 110, 111,
> + 118, 119,
> + 120, 121, 122, 123, 124, 125, 126, 127,
> + },
> + .oobfree = {
> + {.offset = 2, .length = 4, },
> + {.offset = 16, .length = 6, },
> + {.offset = 32, .length = 6, },
> + {.offset = 48, .length = 6, },
> + {.offset = 64, .length = 6, },
> + {.offset = 80, .length = 6, },
> + {.offset = 96, .length = 6, },
> + {.offset = 112, .length = 6, },
> + },
> +};
> +#endif
> +
> +#define NAND_ECCLAYOUT_NUM 2
> +
> +struct nand_ecclayout *davinci_nand_ecclayouts[NAND_ECCLAYOUT_NUM] = {
> + &nand_davinci_4bit_layout_oobfirst,
> + &nand_keystone_rbl_4bit_layout_oobfirst,
> +};
> +
> +int board_nand_ecclayout_get_idx(struct nand_chip *nand,
> +  struct nand_ecclayout *p)
> +{
> + int i;
> +
> + if (!p)
> + return -1;
> +
> + for (i = 0; i < NAND_ECCLAYOUT_NUM; i++)
> + if (davinci_nand_ecclayouts[i] == p)
> + return i;
> +
> + return -1;
> +}

Use ARRAY_SIZE().

> +
> +struct nand_ecclayout *board_nand_ecclayout_get_layout(struct nand_chip 
> *nand,
> +int idx)
> +{
> + if ((idx >= 0) && (idx < NAND_ECCLAYOUT_NUM))
> + return davinci_nand_ecclayouts[idx];
> + else
> + return NULL;
> +}
> +
> +int board_nand_ecclayout_set(struct nand_chip *nand, int idx)
> +{
> + if (idx < 0 || idx >= NAND_ECCLAYOUT_NUM)
> + return -1;
> +
> + nand->ecc.layout = davinci_nand_ecclayouts[idx];
> +
> + return 0;
> +}
> +#endif

Put a comment on this indicating what condition the #endif is ending.

>  static void nand_davinci_4bit_enable_hwecc(struct mtd_info *mtd, int mode)
>  {
>   u32 val;
> @@ -631,7 +728,11 @@ void davinci_nand_init(struct nand_chip *nand)
>   nand->ecc.calculate = nand_davinci_4bit_calculate_ecc;
>   nand->ecc.correct = nand_davinci_4bit_correct_data;
>   nand->ecc.hwctl = nand_davinci_4bit_enable_hwecc;
> +#ifndef CONFIG_CMD_NAND_ECCLAYOUT
>   nand->ecc.layout = &nand_davinci_4bit_layout_oobfirst;
> +#else
> + nand->ecc.layout = &nand_keystone_rbl_4bit_layout_oobfirst;
> +#endif

Use "ifdef/else" rather than "ifndef/else".

Why does enabling layout selection change the default layout?  Nothing in
the changelog suggests that.

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

Re: [U-Boot] [U-Boot, U-boot, 1/2] common: cmd_nand: add nand ecclayout command

2014-06-19 Thread Scott Wood
On Fri, May 16, 2014 at 09:26:36PM +0300, Khoronzhuk, Ivan wrote:
> From: WingMan Kwok 
> 
> This commit adds a nand ecclayout command that allows the ecclayout of
> the current nand device to be changed during run time. This feature is
> useful when using u-boot to write something to nand flash that will be
> read by other applications, such as ROM bootloader, that expects a
> different ECC layout. In that case, change the current nand device
> ecclayout using the "nand ecclayout set" command before writing the
> data to nand flash.
> 
> Signed-off-by: WingMan Kwok 
> Signed-off-by: Ivan Khoronzhuk 
> 
> ---
> common/cmd_nand.c | 115 +-
>  include/nand.h|  10 +
>  2 files changed, 124 insertions(+), 1 deletion(-)
> 
> diff --git a/common/cmd_nand.c b/common/cmd_nand.c
> index 04ab0f1..7cbe6fc 100644
> --- a/common/cmd_nand.c
> +++ b/common/cmd_nand.c
> @@ -462,6 +462,53 @@ static void adjust_size_for_badblocks(loff_t *size, 
> loff_t offset, int dev)
>   }
>  }
>  
> +#ifdef CONFIG_CMD_NAND_ECCLAYOUT
> +static void nand_print_ecclayout_info(struct nand_ecclayout *p)
> +{
> + int i;
> + struct nand_oobfree *oobfree;
> +
> + if (!p)
> + return;
> +
> + printf("  num ecc bytes: %d\n", p->eccbytes);
> + puts("  ecc pos:\n");
> +
> + for (i = 0; i < p->eccbytes; i++) {
> + if (i && !(i % 9))
> + printf("\n");
> +
> + printf("%2d ", p->eccpos[i]);
> + }

Why 9?

> + puts("\n  oobfree:\n");
> + puts("offset length\n");
> +
> + oobfree = p->oobfree;
> + for (i = 0; oobfree->length && i < MTD_MAX_OOBFREE_ENTRIES_LARGE; i++) {
> + printf(" %2d%2d\n", oobfree->offset, oobfree->length);
> + oobfree++;
> + }
> +}
> +
> +static void nand_print_device_ecclayout(int dev)
> +{
> + int idx;
> + nand_info_t *nand = &nand_info[dev];
> + struct nand_chip *chip = nand->priv;
> +
> + idx = board_nand_ecclayout_get_idx(chip, chip->ecc.layout);
> +
> + if (idx < 0) {
> + puts("no ecc layout\n");
> + return;
> + }
> +
> + printf("\necc layout %d:\n", idx);
> + nand_print_ecclayout_info(chip->ecc.layout);
> +}
> +#endif
> +
>  static int do_nand(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
>  {
>   int i, ret = 0;
> @@ -506,8 +553,12 @@ static int do_nand(cmd_tbl_t *cmdtp, int flag, int argc, 
> char * const argv[])
>   putc('\n');
>   if (dev < 0 || dev >= CONFIG_SYS_MAX_NAND_DEVICE)
>   puts("no devices available\n");
> - else
> + else {
>   nand_print_and_set_info(dev);
> +#ifdef CONFIG_CMD_NAND_ECCLAYOUT
> + nand_print_device_ecclayout(dev);
> +#endif
> + }
>   return 0;
>   }

Braces are needed on both sides of if/else if used on one side.

It would be better to provide an inline no-op stub when
CONFIG_CMD_NAND_ECCLAYOUT, than ifdeffing at the call site.

Does it really make sense to dump this information here, when the user
could use the ecclayout command instead?

> @@ -836,6 +887,60 @@ static int do_nand(cmd_tbl_t *cmdtp, int flag, int argc, 
> char * const argv[])
>   }
>  #endif
>  
> +#ifdef CONFIG_CMD_NAND_ECCLAYOUT
> + if (strcmp(cmd, "ecclayout") == 0) {
> + int idx;
> + struct nand_ecclayout *p;
> + nand_info_t *nand = &nand_info[dev];
> + struct nand_chip *chip = nand->priv;
> +
> + if (argc < 3) {
> + puts("Current device ecclayout:\n");
> + nand_print_device_ecclayout(dev);
> + return 0;
> + }
> +
> + if (!strcmp(argv[2], "set")) {
> + if (argc < 4)
> + return 1;
> +
> + idx = (int)simple_strtoul(argv[3], NULL, 10);
> + if (!board_nand_ecclayout_set(chip, idx)) {
> + p = chip->ecc.layout;
> + p->oobavail = 0;
> + for (i = 0; p->oobfree[i].length &&
> + i < ARRAY_SIZE(p->oobfree); i++)
> + p->oobavail += p->oobfree[i].length;
> +
> + nand->oobavail = p->oobavail;

Shouldn't board_nand_ecclayout_set() take care of this?  Possibly via
common helper functions, but not here.

> + } else {
> + printf("Setting current device"
> +" to ecc layout %d FAILED!\n", idx);

Don't wrap user-visible strings (checkpatch should have warned you about
this).

> + }
> +
> + return 0;
> +   

Re: [U-Boot] [U-Boot, v2] mtd: nand: Fix address cycle problem with NAND_CMD_RNDOUT

2014-06-19 Thread Scott Wood
On Tue, May 06, 2014 at 11:15:35AM +0200, Stefan Roese wrote:
> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
> index 1ce55fd..f11fce4 100644
> --- a/drivers/mtd/nand/nand_base.c
> +++ b/drivers/mtd/nand/nand_base.c
> @@ -674,7 +674,7 @@ static void nand_command_lp(struct mtd_info *mtd, 
> unsigned int command,
>   ctrl &= ~NAND_CTRL_CHANGE;
>   chip->cmd_ctrl(mtd, column >> 8, ctrl);
>   }
> - if (page_addr != -1) {
> + if (page_addr != -1 && command != NAND_CMD_RNDOUT) {
>   chip->cmd_ctrl(mtd, page_addr, ctrl);
>   chip->cmd_ctrl(mtd, page_addr >> 8,
>  NAND_NCE | NAND_ALE);

Where is this being called with NAND_CMD_RNDOUT and page_addr != -1, and
shouldn't the fix be to not do that?

Is there a corresponding Linux change?

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


Re: [U-Boot] U-boot hangs on imx6 pci driver

2014-06-19 Thread Marek Vasut
On Tuesday, June 17, 2014 at 04:14:20 PM, Fabio Estevam wrote:
> Hi Tim,
> 
> On Fri, Jun 6, 2014 at 1:35 AM, Tim Harvey  wrote:
> > Fabio,
> > 
> > Good catch, but that doesn't resolve the issue i'm seeing here.
> > 
> > Any other ideas?
> 
> Do you still have issues after applying David's delay workaround?

Yes

Again, apologies for the late reply.

> On my mx6qsabresd I noticed that:
> 
> - if U-boot has PCI driver enabled, then kernel hangs 100% of time.

That's because the PCIe core and PCIe PIPE PHY are not properly restarted. Do 
we 
have any software way to put the PCIe core to an initial state ? Same pro PIPE 
PHY ?

> - if U-boot does not have PCI driver enabled, then the kernel boots
> but does not detect my PCI card.

Well, that's some other shitness. I can get MX6SabreSDP to detect my card, but 
I 
have that 1-out-of-200 "phy link never came up" problem.

> After applying David's workaround I can boot the kernel with PCI
> driver enabled in U-boot and the kernel does detect the PCI Wifi
> module.

OK. Even with David's patch or with FSL supplied patches, I still have the 1-
out-of-200 failure case :-/

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


Re: [U-Boot] U-boot hangs on imx6 pci driver

2014-06-19 Thread Marek Vasut
On Thursday, June 05, 2014 at 12:13:39 PM, Tim Harvey wrote:
> On Wed, Jun 4, 2014 at 11:30 PM, "David Müller (ELSOFT AG)"
> 
>  wrote:
> > Tim Harvey wrote:
> >> When enabling PCI support in u-boot my 3.14 kernel hangs somewhere
> >> during PCI init or enumeration (can't tell as uart is not up yet)
> > 
> > Enabling "earlyprintk" support may help.
> 
> David,
> 
> This is definitely related to PCI_RST# as the delay you inserted is
> essentially after imx6_pcie_probe() gets the reset_gpio from OF and
> asserts it low. Moving the delay around I find that it must come
> before imx6_pcie_assert_core_reset(), specifically before
> IMOUX_GPR1:18 is set (phy power down request).
> 
> Enabling earlyprintk to try to debug the 'hang' on my boards further I
> find that I hang in in imx6_pcie_link_up() during the
> readl(pp->dbi_base + PCIE_PHY_DEBUG_R1) which is called after setting
> IOMUXC_GPR12:1 to start LTSSM. If I add a udelay(55) (55us determined
> via trial and error) directly after setting IOMUXC_GPR12:1 I get
> passed 'this' hang however during pci_scan_bridge() I find that
> PCI_PRIMARY_BUS config dword comes back as 0x instead of
> 0x00010100. This appears to cause the causes the pci code to think the
> RC is a bridge, tries to scan behind it, and hangs (because its not a
> bridge and those transactions are not valid).
> 
> All of this seems to indicate to me that the PLX bridge I have on my
> boards requires a longer minimum time to be held in reset 'before' the
> PCIe PHY is powered down 'if' it has already been enumerated (or
> something to that nature) as I only see this if I enable PCI in uboot.
> Why I also need the extra udelay after enabling LTSSM in this scenario
> I can't say.
> 
> This may correlate with your findings as I believe you say you have an
> i210 attached to the IMX6 RC and have found an errata indicating the
> i210 needs a longer time in reset. Do you find that this is the case
> even if you disable PCI in uboot? My first thought when I read about
> that i210 errata you pointed out was that it wasn't an issue because
> we do hold reset low for 100ms in the kernel but if the issue has
> something to do with holding it in reset with the PHY being powered
> down then perhaps this explains things.
> 
> Merek,
> 
> you've done much more work on IMX6 link than I... any of this make
> sense to you? I believe you have never encountered this 100%
> repeatable issue on your board(s) that David and I do encounter, but
> you have encountered a 1% PCIe link failure rate (which I'm inclined
> to say is something completely different?).

Sorry for the later reply. Most certainly, I observe a failure rate of 1-out-
of-200 or so. I also use i210 though, so it might be related somehow. Can you 
tell me which i210 errata are you talking about here please?

I am currently discussing this with FSL, but it didn't yield any results yet.

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


Re: [U-Boot] [PATCH v4 0/3] mtd, ubi, ubifs: resync with Linux-3.14

2014-06-19 Thread Scott Wood
On Thu, 2014-06-19 at 12:34 +0200, Heiko Schocher wrote:
> Hello Tom, Scott,
> 
> Am 18.06.2014 23:42, schrieb Tom Rini:
> > On Wed, Jun 18, 2014 at 04:24:39PM -0500, Scott Wood wrote:
> >> On Wed, 2014-06-18 at 09:55 +0200, Heiko Schocher wrote:
> >>> Hello Scott,
> > [snip]
>  history to see what Linux version corresponded to the last mtd sync, and
>  generate a diff relative to that.
> >>>
> >>> I think, we should have the linux code as the reference, and on top
> >>> of this, we should add our U-Boot changes ... Thats the reason
> >>> for the git tree [1].
> >>
> >> One of the strengths of version control is the ability to do three-way
> >> merges, rather than throw away the downstream code and reassemble it
> >> from scratch.
> >
> > Indeed.
> >
> > [snip]
> >>
> >> What does #ifndef __UBOOT__ tell you that a diff between the U-Boot and
> >> Linux files, as of the SHA1 that was last merged into U-Boot, doesn't
> >> tell you?
> >>
> >>> There we have the "simple copy from linux patch" [2]. It overwrites
> >>> the U-Boot specific changes, yes, but only in an intermediate step
> >>> in this git tree ... (Maybe I should add in the commit message, that
> >>> this is a simple copy from linux sources)
> >>>
> >>> Then a U-Boot specifc patch [3], which introduces again hopefully
> >>> all U-Boot specific changes... so *all* U-Boot specific changs are
> >>> documented. At last a seperate licencse file patch [4] added which
> >>> changes the license text.
> >>>
> >>> My hope was, that future linux mtd syncs could look like:
> >>>
> >>> a) copy new linux source files to u-boot tree [1] (make a new branch
> >>>  go back to commit [2] ... and copy new files from linux)
> >>>  (commit this, to have all linux changes since last sync
> >>>   with linux documented)
> >>> b) apply [3] and fix problems
> >>>  All U-Boot changes documented
> >>> c) apply [4] and fix problems
> >>> d) add newly added U-Boot specific patches
> >>>  (mark them with _UBOOT_ define if they are not yet marked with it)
> >>>  (maybe squash them to step b ?)
> >>>
> >>>  ->  new git tree ready
> >>>
> >>> e) squash all patches into one patch and send it to mainline ...
> >>>  so the mainline patch has only new changes with all U-Boot
> >>>  specific changes.
> >>
> >> If you take over as NAND custodian, you can of course do the updates as
> >> you please (unless Tom or Wolfgang disagree), but until then I insist on
> >> doing a proper merge, and not littering the code with #ifndef __UBOOT__.
> >>
> >>> Thats sounds easy ... and you have all linux and all U-Boot
> >>> changes visible and documented ... I must admit, I did not
> >>> tried your proposal to look into the linux changes since
> >>> the last mtd sync ... but that sounds the more tricky way
> >>> to get this sync, as the history can be long ... and shouldn;t
> >>> be the result the same?
> >>
> >> Why does the length of the history matter?  I'm not asking you to go
> >> patch by patch.  Just take a diff between the SHA1 of last merge and the
> >> SHA1 you want to merge now, and apply that patch.
> >
> > But it's not even that hard to do so!  git format-patch -o mtd-resync
> > v3.7..v3.14 drivers/mtd/nand will give you only the relevant patches,
> 
> "git format-patch -o mtd-resync v3.7..v3.14 drivers/mtd/nand"
> results in 440 patches ... :-(

This is why I suggested taking one big diff rather than going
patch-to-patch.  Then you don't have to resolve the same conflicts over
and over.

You should also exclude files that U-Boot doesn't have, and include
header files that are relevant.

> "git am" first patch immediately fails ...
> 
> Ok, one step back ... I try only "drivers/mtd/mtdcore.c":
> 
> $ git format-patch -o mtdcore v3.7..v3.14 drivers/mtd/mtdcore.c
> mtdcore/0001-mtd-convert-to-idr_alloc.patch
> mtdcore/0002-mtd-add-const-qualifier-to-a-couple-of-register-func.patch
> mtdcore/0003-mtd-mtdcore-remove-few-useless-ifdef-s.patch
> mtdcore/0004-mtd-merge-mtdchar-module-with-mtdcore.patch
> mtdcore/0005-Include-missing-linux-slab.h-inclusions.patch
> mtdcore/0006-drivers-avoid-format-string-in-dev_set_name.patch
> mtdcore/0007-mtd-add-a-new-sys-node-to-show-the-ecc-step-size.patch
> mtdcore/0008-mtd-add-MTD_MLCNANDFLASH-case-for-mtd_type_show.patch
> mtdcore/0009-mtd-Move-major-number-definitions-to-major.h.patch
> mtdcore/0010-mtd-remove-duplicated-include-from-mtdcore.c.patch
> mtdcore/0011-mtd-convert-to-use-ATTRIBUTE_GROUPS.patch
> $
> 
> Only 11 patches, great ... but:
> 
> $ git am -3 mtdcore/0001-mtd-convert-to-idr_alloc.patch
> Wende an: mtd: convert to idr_alloc()
> fatal: sha1 information is lacking or useless (drivers/mtd/mtdcore.c).

If you fetch the Linux tree into your U-boot repository, then -3 will
work.

> > and they should mostly apply, and then you can squash them after the
> > fact.
> 
> I try to try this ASAP and report (first steps see above ...). But as a
> lot of linux code is missing in U-Boot code, I feel, that a 

Re: [U-Boot] m68k: Fix warnings with gcc 4.6

2014-06-19 Thread Simon Glass
Hi Tom,

On 18 June 2014 11:53, Tom Rini  wrote:
> On Tue, Jun 17, 2014 at 08:52:09PM -0700, Simon Glass wrote:
>> Hi Masahiro,
>>
>> On 17 June 2014 01:34, Masahiro Yamada  wrote:
>> > Hi Simon,
>> >
>> >
>> > On Wed, 11 Jun 2014 18:19:28 -0400
>> > Tom Rini  wrote:
>> >
>> >> On Sat, Jun 07, 2014 at 10:07:58PM -0600, Simon Glass wrote:
>> >>
>> >> > Most of the warnings seem to be related to using 'int' for size_t. 
>> >> > Change
>> >> > this and fix up the remaining warnings and problems. For bootm, the 
>> >> > warning
>> >> > was masked by others, and there is an actual bug in the code.
>> >> >
>> >> > Signed-off-by: Simon Glass 
>> >>
>> >> Applied to u-boot/master, thanks!
>> >>
>> >> --
>> >> Tom
>> >
>> >
>> >
>> > Since commit ddc94378d, I see lots of warnings when compiling m68k boards 
>> > like this:
>> >
>> >
>> >
>> >
>> > Configuring for M52277EVB - Board: M52277EVB, Options: 
>> > SYS_SPANSION_BOOT,SYS_TEXT_BASE=0x
>> >textdata bss dec hex filename
>> >  117375   115304092  132997   20785 ./u-boot
>> > common/cli_simple.c: In function 'process_macros':
>> > common/cli_simple.c:73:2: warning: format '%zd' expects argument of type 
>> > 'signed size_t', but argument 2 has type '__kernel_size_t' [-Wformat]
>> > common/cli_simple.c:162:2: warning: format '%zd' expects argument of type 
>> > 'signed size_t', but argument 2 has type '__kernel_size_t' [-Wformat]
>> > drivers/mtd/spi/sf.c: In function 'spi_flash_read_write':
>> > drivers/mtd/spi/sf.c:30:3: warning: format '%zu' expects argument of type 
>> > 'size_t', but argument 2 has type 'long unsigned int' [-Wformat]
>> > drivers/mtd/spi/sf.c:36:4: warning: format '%zu' expects argument of type 
>> > 'size_t', but argument 2 has type 'long unsigned int' [-Wformat]
>> > drivers/mtd/spi/sf_ops.c: In function 'spi_flash_cmd_write_ops':
>> > drivers/mtd/spi/sf_ops.c:323:3: warning: format '%zu' expects argument of 
>> > type 'size_t', but argument 7 has type 'long unsigned int' [-Wformat]
>> > common/cmd_sf.c: In function 'spi_flash_update_block':
>> > common/cmd_sf.c:154:2: warning: format '%zx' expects argument of type 
>> > 'size_t', but argument 4 has type 'long unsigned int' [-Wformat]
>> > common/cmd_sf.c:161:3: warning: format '%zx' expects argument of type 
>> > 'size_t', but argument 3 has type 'long unsigned int' [-Wformat]
>> > common/cmd_sf.c: In function 'spi_flash_update':
>> > common/cmd_sf.c:218:9: warning: format '%zu' expects argument of type 
>> > 'size_t', but argument 2 has type 'long unsigned int' [-Wformat]
>> > common/cmd_sf.c:236:9: warning: format '%zu' expects argument of type 
>> > 'size_t', but argument 2 has type 'long unsigned int' [-Wformat]
>> > common/cmd_sf.c:236:9: warning: format '%zu' expects argument of type 
>> > 'size_t', but argument 3 has type 'long unsigned int' [-Wformat]
>> > common/cmd_sf.c: In function 'do_spi_flash_read_write':
>> > common/cmd_sf.c:291:10: warning: format '%zu' expects argument of type 
>> > 'size_t', but argument 2 has type 'long unsigned int' [-Wformat]
>> > common/cmd_sf.c: In function 'do_spi_flash_erase':
>> > common/cmd_sf.c:326:9: warning: format '%zu' expects argument of type 
>> > 'size_t', but argument 2 has type 'long unsigned int' [-Wformat]
>> > common/cmd_nvedit.c: In function 'do_env_export':
>> > common/cmd_nvedit.c:914:3: warning: format '%zX' expects argument of type 
>> > 'size_t', but argument 3 has type 'long unsigned int' [-Wformat]
>> > common/cmd_nvedit.c: In function 'do_env_import':
>> > common/cmd_nvedit.c:1036:3: warning: format '%zu' expects argument of type 
>> > 'size_t', but argument 2 has type 'long unsigned int' [-Wformat]
>> > common/cmd_nvedit.c:1036:3: warning: format '%zX' expects argument of type 
>> > 'size_t', but argument 3 has type 'long unsigned int' [-Wformat]
>> > lib/hashtable.c: In function 'hexport_r':
>> > lib/hashtable.c:605:2: warning: format '%zu' expects argument of type 
>> > 'size_t', but argument 5 has type 'long unsigned int' [-Wformat]
>> > lib/hashtable.c:661:5: warning: format '%zu' expects argument of type 
>> > 'size_t', but argument 2 has type 'long unsigned int' [-Wformat]
>> > lib/hashtable.c:661:5: warning: format '%zu' expects argument of type 
>> > 'size_t', but argument 3 has type 'long unsigned int' [-Wformat]
>> > lib/hashtable.c: In function 'himport_r':
>> > lib/hashtable.c:793:3: warning: format '%zu' expects argument of type 
>> > 'size_t', but argument 2 has type 'long unsigned int' [-Wformat]
>> >
>> >
>> > Reverting the following fixes the warnings.
>> >
>> >  --- a/arch/m68k/include/asm/posix_types.h
>> >  +++ b/arch/m68k/include/asm/posix_types.h
>> >  @@ -15,7 +15,7 @@ typedef long  __kernel_off_t;
>> >   typedef int__kernel_pid_t;
>> >   typedef unsigned int   __kernel_uid_t;
>> >   typedef unsigned int   __kernel_gid_t;
>> >  -typedef unsigned int   __kernel_size_t;
>> >  +typedef unsigned long  __kernel_size_t;
>> >   typedef int__ker

Re: [U-Boot] [U-Boot, v2, 06/14] bootm: Split out code from cmd_bootm.c

2014-06-19 Thread Simon Glass
Hi Tom,

On 19 June 2014 09:31, Tom Rini  wrote:
> On Thu, Jun 19, 2014 at 11:23:24AM -0400, Tom Rini wrote:
>> On Thu, Jun 12, 2014 at 07:24:46AM -0600, Simon Glass wrote:
>>
>> > This file has code in three different categories:
>> > - Command processing
>> > - OS-specific boot code
>> > - Locating images and setting up to boot
>> >
>> > Only the first category really belongs in a file called cmd_bootm.c.
>> >
>> > Leave the command processing code where it is. Split out the OS-specific
>> > boot code into bootm_os.c. Split out the other code into bootm.c
>> >
>> > Header files and extern declarations are tidied but otherwise no code
>> > changes are made, to make it easier to review.
>> >
>> > Signed-off-by: Simon Glass 
>>
>> This, on am335x GP EVM doing UART booting (you can replicate the same on
>> beaglebone black with no SD card / nothing bootable on eMMC and holing
>> down the "user" button for the first boot, SYSBOOT pins will be set
>> until next hard power cycle) causes:
>> Sending /tmp/u-boot-spl.bin, 646 blocks: Give your local XMODEM receive
>> command now.
>> Bytes Sent:  82816   BPS:10461
>>
>> Transfer complete
>> Sending: u-boot.img
>> Ymodem sectors/kbytes sent: 3433/429kyzModem - CRC mode,
>> 4(SOH)/438(STX)/0(CAN) packets, 2 retries
>> Loaded 448676 bytes
>> No valid FDT found - please append one to U-Boot binary, use
>> u-boot-dtb.bin or define CONFIG_OF_EMBED. For sandbox, use -d 
>> initcall sequence 8085d568 failed at call 8083e678
>> ### ERROR ### Please RESET the board ###
>
> ... because I didn't use u-boot-dtb.img which is a functional change,
> which is why I then sent out and applied this morning a patch to move
> most of this support on am335x_evm to be under ENABLE_VBOOT.

Yes I was wondering whether you wanted things that way.

In this case I think the problem is that you need to download
'u-boot-dtb.img' instead. But there may be another problem.

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


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

2014-06-19 Thread Tom Rini
Hey,

The following changes since commit 0a26e1d6c394aacbf1153977b7348d1dff85db3f:

  arm: fix a double-definition error of _start symbol (2014-06-09 10:36:40 
+0200)

are available in the git repository at:

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

for you to fetch changes up to 12cc54376768461533b55ada1b0b6d4979f40579:

  omap3: overo: Select fdtfile for expansion board (2014-06-19 17:53:59 -0400)


Ash Charles (3):
  omap: Don't enable GPMC CS0 with nothing attached
  omap4: duovero: Correct name of default device tree
  omap3: overo: Select fdtfile for expansion board

Axel Lin (1):
  spi: davinci: Fix register address for SPI1_BUS

Felipe Balbi (5):
  board: ti: am43xx: print unsupported board name
  cpu: armv7: am33x: ddr: write emif ref_ctrl_shadow register
  board: ti: am43xx: add support for AM43xx Starter Kit
  board: ti: am43xx: add AM437x SK PHY Address
  board: ti: am43xx: enable QSPI and Gbit Ethernet on AM437x SK

Jeroen Hofstee (1):
  omap3: board: trivial: add void for no args

Khoronzhuk, Ivan (2):
  mtd: nand: davinci: add header file for driver definitions
  ARM: keystone: aemif: move aemif driver to drivers/memory/ti-aemif.c

Stefano Babic (1):
  OMAP: disable gpmc timeout safely for reenabling

 arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c|2 +-
 arch/arm/cpu/arm926ejs/davinci/dm365_lowlevel.c|1 +
 arch/arm/cpu/armv7/am33xx/ddr.c|1 +
 arch/arm/cpu/armv7/keystone/Makefile   |1 -
 arch/arm/cpu/armv7/omap-common/mem-common.c|6 +-
 arch/arm/cpu/armv7/omap3/board.c   |4 +-
 arch/arm/include/asm/arch-davinci/emif_defs.h  |   72 --
 arch/arm/include/asm/arch-davinci/hardware.h   |1 -
 arch/arm/include/asm/arch-davinci/nand_defs.h  |   38 --
 arch/arm/include/asm/arch-keystone/hardware-k2hk.h |7 --
 arch/arm/include/asm/arch-keystone/hardware.h  |   30 +---
 arch/arm/include/asm/arch-keystone/nand_defs.h |   23 --
 arch/arm/include/asm/arch-tnetv107x/emif_defs.h|1 -
 arch/arm/include/asm/arch-tnetv107x/hardware.h |2 +
 arch/arm/include/asm/arch-tnetv107x/nand_defs.h|   23 --
 .../emif_defs.h => ti-common/davinci_nand.h}   |   55 ++
 arch/arm/include/asm/ti-common/ti-aemif.h  |   39 ++
 board/Barix/ipam390/ipam390.c  |2 +-
 board/ait/cam_enc_4xx/cam_enc_4xx.c|2 +-
 board/davinci/da8xxevm/da830evm.c  |3 +-
 board/davinci/da8xxevm/da850evm.c  |2 +-
 board/davinci/dm355evm/dm355evm.c  |3 +-
 board/davinci/dm355leopard/dm355leopard.c  |2 +-
 board/davinci/dm365evm/dm365evm.c  |3 +-
 board/davinci/dm6467evm/dm6467evm.c|3 +-
 board/davinci/ea20/ea20.c  |2 +-
 board/davinci/sonata/sonata.c  |2 +-
 board/enbw/enbw_cmc/enbw_cmc.c |2 +-
 board/omicron/calimain/calimain.c  |2 +-
 board/overo/overo.c|   14 
 board/ti/am43xx/board.c|   79 +++-
 board/ti/am43xx/board.h|5 ++
 board/ti/am43xx/mux.c  |3 +
 board/ti/k2hk_evm/board.c  |   10 +--
 board/ti/tnetv107xevm/sdb_board.c  |2 +-
 drivers/Makefile   |1 +
 drivers/memory/Makefile|1 +
 .../keystone/aemif.c => drivers/memory/ti-aemif.c  |   37 +
 drivers/mtd/nand/davinci_nand.c|3 +-
 drivers/spi/davinci_spi.c  |2 +-
 include/configs/am43xx_evm.h   |2 +
 include/configs/davinci_dm6467evm.h|2 +
 include/configs/k2hk_evm.h |6 ++
 include/configs/omap3_overo.h  |   10 +--
 include/configs/ti_omap4_common.h  |2 +-
 45 files changed, 255 insertions(+), 258 deletions(-)
 delete mode 100644 arch/arm/include/asm/arch-davinci/emif_defs.h
 delete mode 100644 arch/arm/include/asm/arch-davinci/nand_defs.h
 delete mode 100644 arch/arm/include/asm/arch-keystone/nand_defs.h
 delete mode 100644 arch/arm/include/asm/arch-tnetv107x/emif_defs.h
 delete mode 100644 arch/arm/include/asm/arch-tnetv107x/nand_defs.h
 rename arch/arm/include/asm/{arch-keystone/emif_defs.h => 
ti-common/davinci_nand.h} (56%)
 create mode 100644 arch/arm/include/asm/ti-common/ti-aemif.h
 create mode 100644 drivers/memory/Makefile
 rename arch/arm/cpu/armv7/keystone/aemif.c => drivers/memory/ti-aemif.c (63%)

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot ma

Re: [U-Boot] [U-Boot, U-boot, v3] mtd: nand: davinci: add header file for driver definitions

2014-06-19 Thread Ivan Khoronzhuk


On 06/20/2014 01:01 AM, Tom Rini wrote:

On Sat, Jun 07, 2014 at 04:22:52AM +0300, Khoronzhuk, Ivan wrote:


The definitions inside emif_defs.h concern davinci nand driver and
should be in it's header. So create header file for davinci nand
driver and move definitions from emif_defs.h and nand_defs.h to it.

Acked-by: Vitaly Andrianov 
Signed-off-by: Ivan Khoronzhuk 

Fixed a few more bits of davinci fallout and applied to
u-boot-ti/master, thanks!



Thanks

--
Regards,
Ivan Khoronzhuk

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


Re: [U-Boot] omap: Don't enable GPMC CS0 with nothing attached

2014-06-19 Thread Ash Charles
Thanks for the correction Tom.
--Ash

On Thu, Jun 19, 2014 at 3:01 PM, Tom Rini  wrote:
> On Fri, Jun 06, 2014 at 11:27:28AM -0700, Ash Charles wrote:
>
>> If CONFIG_(NAND|NOR|ONENAND) is not defined, no configuration is set
>> for GPMC on chip select #0---size is 0.  In this case, the GPMC
>> configuration should be reset but not enabled.  Enabling causes the
>> Gumstix DuoVero board to hang when entering Linux.
>>
>> Signed-off-by: Ash Charles 
>
> After changing the test to be on 'base' not 'size' (as GPMC_SIZE_256M is
> 0x0), applied to u-boot-ti/master, thanks!
>
> --
> Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [U-Boot, v2, 4/5] board: ti: am43xx: add AM437x SK PHY Address

2014-06-19 Thread Tom Rini
On Tue, Jun 10, 2014 at 03:01:21PM -0500, Felipe Balbi wrote:

> pass correct PHY Address when running on SK
> so that we have working ethernet with this board
> too.
> 
> Signed-off-by: Felipe Balbi 

Applied to u-boot-ti/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v2, 5/5] board: ti: am43xx: enable QSPI and Gbit Ethernet on AM437x SK

2014-06-19 Thread Tom Rini
On Tue, Jun 10, 2014 at 03:01:22PM -0500, Felipe Balbi wrote:

> AM437x Starter Kit has a qspi flash and gbit ethernet
> support. By muxing those signals, we can use those
> interfaces from u-boot.
> 
> Signed-off-by: Felipe Balbi 

Applied to u-boot-ti/master, thanks!

-- 
Tom


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


Re: [U-Boot] OMAP: disable gpmc timeout safely for reenabling

2014-06-19 Thread Tom Rini
On Tue, Jun 17, 2014 at 04:47:40PM +0200, Stefano Babic wrote:

> gpmc timeout is disabled and the reset counter
> is set to 0. However, if later a driver activates
> the timeout setting the reset to a valid value,
> the old reset value with zero is still valid
> for the first access. In fact, the timeout block
> loads the reset counter after a successful access.
> 
> Found on a am335x board with a FPGA connected
> to the GPMC bus together with the NAND.
> When the FPGA driver in kernel activates
> the timeout, the system hangs at the first access
> by the NAND driver.
> 
> Signed-off-by: Stefano Babic 

Applied to u-boot-ti/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v2, 3/5] board: ti: am43xx: add support for AM43xx Starter Kit

2014-06-19 Thread Tom Rini
On Tue, Jun 10, 2014 at 03:01:20PM -0500, Felipe Balbi wrote:

> AM43xx Starter Kit is a new board based on
> AM437x line of SoCs. Being a low-cost EVM and
> small size EVM are intended to provide an entry
> level development platform on a full fledged
> Hardware System.
> 
> Signed-off-by: Felipe Balbi 

Applied to u-boot-ti/master, thanks!

-- 
Tom


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


Re: [U-Boot] spi: davinci: Fix register address for SPI1_BUS

2014-06-19 Thread Tom Rini
On Wed, Jun 18, 2014 at 09:09:34AM +0800, Axel Lin wrote:

> Fix a trivial copy-paste bug.
> 
> Signed-off-by: Axel Lin 

Applied to u-boot-ti/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v2, 2/5] cpu: armv7: am33x: ddr: write emif ref_ctrl_shadow register

2014-06-19 Thread Tom Rini
On Tue, Jun 10, 2014 at 03:01:19PM -0500, Felipe Balbi wrote:

> Signed-off-by: Felipe Balbi 

Applied to u-boot-ti/master, thanks!

-- 
Tom


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


Re: [U-Boot] omap3: board: trivial: add void for no args

2014-06-19 Thread Tom Rini
On Mon, Jun 16, 2014 at 11:22:23PM +0200, Jeroen Hofstee wrote:

> Signed-off-by: Jeroen Hofstee 

Applied to u-boot-ti/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, U-boot, v3] mtd: nand: davinci: add header file for driver definitions

2014-06-19 Thread Tom Rini
On Sat, Jun 07, 2014 at 04:22:52AM +0300, Khoronzhuk, Ivan wrote:

> The definitions inside emif_defs.h concern davinci nand driver and
> should be in it's header. So create header file for davinci nand
> driver and move definitions from emif_defs.h and nand_defs.h to it.
> 
> Acked-by: Vitaly Andrianov 
> Signed-off-by: Ivan Khoronzhuk 

Fixed a few more bits of davinci fallout and applied to
u-boot-ti/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v3] omap3: overo: Select fdtfile for expansion board

2014-06-19 Thread Tom Rini
On Tue, Jun 10, 2014 at 12:02:36PM -0700, Ash Charles wrote:

> The u-boot Overo board actually supports both Overo (OMAP35xx)
> and Overo Storm (AM/DM37xx) COMs with a range of different expansion
> boards.  This provides a mechanism to select the an appropriate device
> tree file based on the processor version and, if available, the
> expansion board ID written on the expansion board EEPROM. To match the
> 3.15+ kernels, fdtfile names have this format:
>  "omap3-overo[-storm]-.dtb"
> 
> By default, we use "omap3-overo-storm-tobi.dtb".
> 
> Signed-off-by: Ash Charles 

Applied to u-boot-ti/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v2, 1/5] board: ti: am43xx: print unsupported board name

2014-06-19 Thread Tom Rini
On Tue, Jun 10, 2014 at 03:01:18PM -0500, Felipe Balbi wrote:

> when porting u-boot to a new am43xx board, it
> helps to know the name of the current unsupported
> board so we don't have to hunt for design documents
> to figure out what's written in the EEPROM.
> 
> Signed-off-by: Felipe Balbi 

Applied to u-boot-ti/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, U-boot, v3] ARM: keystone: aemif: move aemif driver to drivers/memory/ti-aemif.c

2014-06-19 Thread Tom Rini
On Sat, Jun 07, 2014 at 05:10:49AM +0300, Khoronzhuk, Ivan wrote:

> Move AEMIF driver to drivers/memory/ti-aemif.c along with AEMIF
> definitions collected in arch/arm/include/asm/ti-common/ti-aemif.h
> 
> Acked-by: Vitaly Andrianov 
> Signed-off-by: Ivan Khoronzhuk 

Applied to u-boot-ti/master, thanks!

-- 
Tom


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


Re: [U-Boot] omap4: duovero: Correct name of default device tree

2014-06-19 Thread Tom Rini
On Fri, Jun 06, 2014 at 11:36:50AM -0700, Ash Charles wrote:

> Signed-off-by: Ash Charles 

Applied to u-boot-ti/master, thanks!

-- 
Tom


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


Re: [U-Boot] omap: Don't enable GPMC CS0 with nothing attached

2014-06-19 Thread Tom Rini
On Fri, Jun 06, 2014 at 11:27:28AM -0700, Ash Charles wrote:

> If CONFIG_(NAND|NOR|ONENAND) is not defined, no configuration is set
> for GPMC on chip select #0---size is 0.  In this case, the GPMC
> configuration should be reset but not enabled.  Enabling causes the
> Gumstix DuoVero board to hang when entering Linux.
> 
> Signed-off-by: Ash Charles 

After changing the test to be on 'base' not 'size' (as GPMC_SIZE_256M is
0x0), applied to u-boot-ti/master, thanks!

-- 
Tom


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


[U-Boot] [RFC PATCH 3/3] usb/gadget: fastboot: add support for flash command

2014-06-19 Thread Steve Rae
- implement 'fastboot flash' for eMMC devices

Signed-off-by: Steve Rae 
---

 README  | 10 ++
 doc/README.android-fastboot |  5 +++--
 drivers/usb/gadget/f_fastboot.c | 31 +++
 3 files changed, 44 insertions(+), 2 deletions(-)

diff --git a/README b/README
index 7129df8..73071fc 100644
--- a/README
+++ b/README
@@ -1600,6 +1600,16 @@ The following options need to be configured:
downloads. This buffer should be as large as possible for a
platform. Define this to the size available RAM for fastboot.
 
+   CONFIG_FASTBOOT_FLASH
+   The fastboot protocol includes a "flash" command for writing
+   the downloaded image to a non-volatile storage device. Define
+   this to enable the "fastboot flash" command.
+
+   CONFIG_FASTBOOT_FLASH_MMC_DEV
+   The fastboot "flash" command requires addition information
+   regarding the non-volatile storage device. Define this to
+   the eMMC device that fastboot should use to store the image.
+
 - Journaling Flash filesystem support:
CONFIG_JFFS2_NAND, CONFIG_JFFS2_NAND_OFF, 
CONFIG_JFFS2_NAND_SIZE,
CONFIG_JFFS2_NAND_DEV
diff --git a/doc/README.android-fastboot b/doc/README.android-fastboot
index f1d128c..f00fd41 100644
--- a/doc/README.android-fastboot
+++ b/doc/README.android-fastboot
@@ -6,8 +6,9 @@ Overview
 The protocol that is used over USB is described in
 README.android-fastboot-protocol in same directory.
 
-The current implementation does not yet support the flash and erase
-commands.
+The current implementation does not yet support the erase
+command, and there is minimal support for the flash command;
+it only supports eMMC devices.
 
 Client installation
 ===
diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c
index 9dd85b6..89c2d3e 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -19,6 +19,9 @@
 #include 
 #include 
 #include 
+#ifdef CONFIG_FASTBOOT_FLASH_MMC_DEV
+#include 
+#endif
 
 #define FASTBOOT_VERSION   "0.4"
 
@@ -466,6 +469,28 @@ static void cb_boot(struct usb_ep *ep, struct usb_request 
*req)
fastboot_tx_write_str("OKAY");
 }
 
+#ifdef CONFIG_FASTBOOT_FLASH
+static void cb_flash(struct usb_ep *ep, struct usb_request *req)
+{
+   char *cmd = req->buf;
+   char response[RESPONSE_LEN];
+
+   strsep(&cmd, ":");
+   if (!cmd) {
+   printf("%s: missing partition name\n", __func__);
+   fastboot_tx_write_str("FAILmissing partition name");
+   return;
+   }
+
+   strcpy(response, "FAILno flash device defined");
+#ifdef CONFIG_FASTBOOT_FLASH_MMC_DEV
+   fb_mmc_flash_write(cmd, (void *)CONFIG_USB_FASTBOOT_BUF_ADDR,
+  download_bytes, response);
+#endif
+   fastboot_tx_write_str(response);
+}
+#endif
+
 struct cmd_dispatch_info {
char *cmd;
void (*cb)(struct usb_ep *ep, struct usb_request *req);
@@ -485,6 +510,12 @@ static const struct cmd_dispatch_info cmd_dispatch_info[] 
= {
.cmd = "boot",
.cb = cb_boot,
},
+#ifdef CONFIG_FASTBOOT_FLASH
+   {
+   .cmd = "flash",
+   .cb = cb_flash,
+   },
+#endif
 };
 
 static void rx_handler_command(struct usb_ep *ep, struct usb_request *req)
-- 
1.8.5

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


[U-Boot] [RFC PATCH 2/3] usb/gadget: fastboot: add eMMC support for flash command

2014-06-19 Thread Steve Rae
- add support for 'fastboot flash' command for eMMC devices

Signed-off-by: Steve Rae 
---
I suspect that the "sparse image" handling (ie. the "while (remaining_chunks)" 
loop)
has been implemented elsewhere -- I need help finding the original code to 
determine
any licensing issues
Thanks, Steve

 common/Makefile  |   5 ++
 common/fb_mmc.c  | 144 +++
 include/fb_mmc.h |   8 
 3 files changed, 157 insertions(+)
 create mode 100644 common/fb_mmc.c
 create mode 100644 include/fb_mmc.h

diff --git a/common/Makefile b/common/Makefile
index f6cd980..c825c2c 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -264,4 +264,9 @@ obj-$(CONFIG_FIT_SIGNATURE) += image-sig.o
 obj-y += memsize.o
 obj-y += stdio.o
 
+# This option is not just y/n - it can have a numeric value
+ifdef CONFIG_FASTBOOT_FLASH_MMC_DEV
+obj-y += fb_mmc.o
+endif
+
 CFLAGS_env_embedded.o := -Wa,--no-warn -DENV_CRC=$(shell tools/envcrc 
2>/dev/null)
diff --git a/common/fb_mmc.c b/common/fb_mmc.c
new file mode 100644
index 000..de6a4c7
--- /dev/null
+++ b/common/fb_mmc.c
@@ -0,0 +1,144 @@
+/*
+ * Copyright TODO
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+void fb_mmc_flash_write(const char *cmd, void *download_buffer,
+   unsigned int download_bytes, char *response)
+{
+   int ret;
+   block_dev_desc_t *mmc_dev;
+   disk_partition_t info;
+   lbaint_t blk;
+   lbaint_t blkcnt;
+   ulong blks;
+   sparse_header_t *s_header = (sparse_header_t *)download_buffer;
+   chunk_header_t *c_header;
+   void *buffer;
+   uint32_t blk_sz;
+   uint32_t remaining_chunks;
+   uint32_t bytes_written = 0;
+
+   mmc_dev = mmc_get_dev(CONFIG_FASTBOOT_FLASH_MMC_DEV);
+   if (!mmc_dev || mmc_dev->type == DEV_TYPE_UNKNOWN) {
+   printf("%s: invalid mmc device\n", __func__);
+   strcpy(response, "FAILinvalid mmc device");
+   return;
+   }
+
+   ret = get_partition_info_efi_by_name(mmc_dev, cmd, &info);
+   if (ret) {
+   printf("%s: cannot find partition: '%s'\n", __func__, cmd);
+   strcpy(response, "FAILcannot find partition");
+   return;
+   }
+
+   if ((le32_to_cpu(s_header->magic) == SPARSE_HEADER_MAGIC) &&
+   (le16_to_cpu(s_header->major_version) == 1)) {
+   /* sparse image */
+
+   blk_sz = le32_to_cpu(s_header->blk_sz);
+
+   /* verify s_header->blk_sz is exact multiple of info.blksz */
+   if (blk_sz != (blk_sz & ~(info.blksz - 1))) {
+   printf("%s: Sparse image block size issue [%u]\n",
+  __func__, blk_sz);
+   strcpy(response, "FAILsparse image block size issue");
+   return;
+   }
+
+   if ((le32_to_cpu(s_header->total_blks) * blk_sz) >
+   (info.size * info.blksz)) {
+   printf("%s: Sparse image is too large for the 
partition\n",
+  __func__);
+   strcpy(response, "FAILsparse image is too large");
+   return;
+   }
+
+   printf("Flashing Sparse Image\n");
+
+   blk = info.start;
+   remaining_chunks = le32_to_cpu(s_header->total_chunks);
+   c_header = (chunk_header_t *)(download_buffer +
+   le16_to_cpu(s_header->file_hdr_sz));
+   while (remaining_chunks) {
+   switch (le16_to_cpu(c_header->chunk_type)) {
+   case CHUNK_TYPE_RAW:
+   blkcnt =
+   (le32_to_cpu(c_header->chunk_sz) * blk_sz) /
+   info.blksz;
+   buffer =
+   (void *)c_header +
+   le16_to_cpu(s_header->chunk_hdr_sz);
+
+   blks = mmc_dev->block_write(mmc_dev->dev, blk,
+   blkcnt, buffer);
+   if (blks != blkcnt) {
+   printf("Write failed %lu\n", blks);
+   strcpy(response,
+  "FAILmmc write failure");
+   return;
+   }
+
+   bytes_written += blkcnt * info.blksz;
+   break;
+
+   case CHUNK_TYPE_FILL:
+   case CHUNK_TYPE_DONT_CARE:
+   case CHUNK_TYPE_CRC32:
+   /* do nothing */
+   break;
+
+   default:
+   /* error */
+ 

[U-Boot] [RFC PATCH 1/3] usb/gadget: fastboot: add sparse image definitions

2014-06-19 Thread Steve Rae
- to prepare for the support of fastboot sparse images

Signed-off-by: Steve Rae 
---
This file is ASIS from:
  
https://raw.githubusercontent.com/AOSB/android_system_core/master/libsparse/sparse_format.h
  (commit 28fa5bc347390480fe190294c6c385b6a9f0d68b)
except for the __UBOOT__ conditional include.

 include/sparse_format.h | 58 +
 1 file changed, 58 insertions(+)
 create mode 100644 include/sparse_format.h

diff --git a/include/sparse_format.h b/include/sparse_format.h
new file mode 100644
index 000..21fbd05
--- /dev/null
+++ b/include/sparse_format.h
@@ -0,0 +1,58 @@
+/*
+ * Copyright (C) 2010 The Android Open Source Project
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#ifndef _LIBSPARSE_SPARSE_FORMAT_H_
+#define _LIBSPARSE_SPARSE_FORMAT_H_
+#define __UBOOT__
+#ifndef __UBOOT__
+#include "sparse_defs.h"
+#endif
+
+typedef struct sparse_header {
+  __le32   magic;  /* 0xed26ff3a */
+  __le16   major_version;  /* (0x1) - reject images with higher major 
versions */
+  __le16   minor_version;  /* (0x0) - allow images with higer minor 
versions */
+  __le16   file_hdr_sz;/* 28 bytes for first revision of the file 
format */
+  __le16   chunk_hdr_sz;   /* 12 bytes for first revision of the file 
format */
+  __le32   blk_sz; /* block size in bytes, must be a multiple of 4 
(4096) */
+  __le32   total_blks; /* total blocks in the non-sparse output image 
*/
+  __le32   total_chunks;   /* total chunks in the sparse input image */
+  __le32   image_checksum; /* CRC32 checksum of the original data, 
counting "don't care" */
+   /* as 0. Standard 802.3 polynomial, use a 
Public Domain */
+   /* table implementation */
+} sparse_header_t;
+
+#define SPARSE_HEADER_MAGIC0xed26ff3a
+
+#define CHUNK_TYPE_RAW 0xCAC1
+#define CHUNK_TYPE_FILL0xCAC2
+#define CHUNK_TYPE_DONT_CARE   0xCAC3
+#define CHUNK_TYPE_CRC320xCAC4
+
+typedef struct chunk_header {
+  __le16   chunk_type; /* 0xCAC1 -> raw; 0xCAC2 -> fill; 0xCAC3 -> 
don't care */
+  __le16   reserved1;
+  __le32   chunk_sz;   /* in blocks in output image */
+  __le32   total_sz;   /* in bytes of chunk input file including chunk 
header and data */
+} chunk_header_t;
+
+/* Following a Raw or Fill or CRC32 chunk is data.
+ *  For a Raw chunk, it's the data in chunk_sz * blk_sz.
+ *  For a Fill chunk, it's 4 bytes of the fill data.
+ *  For a CRC32 chunk, it's 4 bytes of CRC32
+ */
+
+#endif
-- 
1.8.5

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


[U-Boot] [RFC PATCH 0/3] Implement "fastboot flash" for eMMC

2014-06-19 Thread Steve Rae
This series implements the "fastboot flash" command for eMMC devices.
It supports both raw and sparse images.

NOTES:
- the support for the "fastboot flash" command is enabled with 
CONFIG_FASTBOOT_FLASH
- the support for eMMC is enabled with CONFIG_FASTBOOT_FLASH_MMC_DEV
- (future) the support for NAND would be enabled with 
CONFIG_FASTBOOT_FLASH_NAND(???)
- thus the proposal is to place the code in common/fb_mmc.c and (future) 
common/fb_nand.c(???),
  however, this may not be the appropriate location

This has been tested on ARMv7.
This is a WIP -- and I would appreciate some comments/advice...
Thanks, Steve


Steve Rae (3):
  usb/gadget: fastboot: add sparse image definitions
  usb/gadget: fastboot: add eMMC support for flash command
  usb/gadget: fastboot: add support for flash command

 README  |  10 +++
 common/Makefile |   5 ++
 common/fb_mmc.c | 144 
 doc/README.android-fastboot |   5 +-
 drivers/usb/gadget/f_fastboot.c |  31 +
 include/fb_mmc.h|   8 +++
 include/sparse_format.h |  58 
 7 files changed, 259 insertions(+), 2 deletions(-)
 create mode 100644 common/fb_mmc.c
 create mode 100644 include/fb_mmc.h
 create mode 100644 include/sparse_format.h

-- 
1.8.5

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


[U-Boot] am335x: board.c: clang warning

2014-06-19 Thread Jeroen Hofstee
Hello Tom,

The following clang warnings are not trivial to fix for me,
And since the file in question has many contributers I am not
sure who is responsible nowadays. Can you make sure this end up
at someone who knows about the am335x, since this sound a bit
fishy.. (but likely works somehow...)

Regards,
Jeroen

e.g. make am335x_boneblack_config

board/ti/am335x/board.c:87:44: warning: signed shift result
(0x48000) requires 36 bits to represent, but 'int' only has 32 bits
[-Wshift-overflow]
.datardsratio0 = ((MT47H128M16RT25E_RD_DQS<<30) |
   ~~~^ ~~
board/ti/am335x/board.c:103:49: warning: signed shift result
(0x20) requires 39 bits to represent, but 'int' only has 32 bits
[-Wshift-overflow]
.datafwsratio0 = ((MT47H128M16RT25E_PHY_FIFO_WE<<30) |
   ^ ~~
board/ti/am335x/board.c:107:49: warning: signed shift result
(0x10) requires 38 bits to represent, but 'int' only has 32 bits
[-Wshift-overflow]
.datawrsratio0 = ((MT47H128M16RT25E_PHY_WR_DATA<<30) |
   ^ ~~
3 warnings generated.


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


Re: [U-Boot] [PATCH] driver/ddr: Fix DDR4 driver for ARM

2014-06-19 Thread York Sun
Noted. Maybe we can pull in part of barrier.h into io.h. It is easier but I am
not sure if it is the cleanest way to go.

York

On 06/19/2014 11:01 AM, Jon Loeliger wrote:
> That might be a fine starting point.  But I might point out
> that U-Boot has some notions down this line already too.
> For example, do a 'git grep wmb' in the U-Boot repo.
> Also ponder arch/arm/include/asm/io.h too.
> 
> HTH,
> jdl
> 
> On Thu, Jun 19, 2014 at 12:47 PM, York Sun  wrote:
>> On 06/18/2014 07:57 AM, Jon Loeliger wrote:
>>> On Tue, Jun 17, 2014 at 5:07 PM, York Sun  wrote:
 Previously the driver was only tested on Power SoCs. Minor fix is needed
 for ARM SoCs.

 Signed-off-by: York Sun 
>>>
>>>
>>> Hi York!
>>>
>>>
 --- a/drivers/ddr/fsl/fsl_ddr_gen4.c
 +++ b/drivers/ddr/fsl/fsl_ddr_gen4.c
>>>
 @@ -183,12 +184,20 @@ step2:
  * we choose the max, that is 500 us for all of case.
  */
 udelay(500);
 +#ifdef CONFIG_PPC
 asm volatile("sync;isync");
 +#else
 +   asm volatile("dsb sy;isb");
 +#endif

 /* Let the controller go */
 temp_sdram_cfg = ddr_in32(&ddr->sdram_cfg) & ~SDRAM_CFG_BI;
 ddr_out32(&ddr->sdram_cfg, temp_sdram_cfg | SDRAM_CFG_MEM_EN);
 +#ifdef CONFIG_PPC
 asm volatile("sync;isync");
 +#else
 +   asm volatile("dsb sy;isb");
 +#endif

 total_gb_size_per_controller = 0;
 for (i = 0; i < CONFIG_CHIP_SELECTS_PER_CTRL; i++) {
>>>
>>> This is a great example where we should try to introduce better abstractions
>>> in much the same way that Linux has.  Specifically, we (U-Boot) collective
>>> might work toward some common lower-level abstractions such as a
>>> memory_barrier() (and variants), and let those generic names get mapped
>>> into architecture-specific implementations via a linked binding.  Then this
>>> code would not need to change, nor would #ifdefs be needed.
>>>
>>
>> Jon,
>>
>> Are you suggesting to pick arch//include/asm/barrier.h from Linux, or 
>> part
>> of it?
>>
>> York
>>

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


[U-Boot] pull request for u-boot-tegra/master into ARM/master

2014-06-19 Thread Tom Warren
Albert,

Please pull u-boot-tegra/master into ARM/master. Thanks!

./MAKEALL -s tegra AOK, checkpatch.pl is OK, and ./MAKEALL -a arm only
shows failures that were already present in ARM/master.

The following changes since commit 0a26e1d6c394aacbf1153977b7348d1dff85db3f:

  arm: fix a double-definition error of _start symbol (2014-06-09 10:36:40
+0200)

are available in the git repository at:

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

for you to fetch changes up to fe7b7cd26683b29bed407bf5ab778e8d80201d73:

  ARM: tegra: set initrd_high so boot scripts work (2014-06-19 10:47:20
-0700)


Jeroen Hofstee (2):
  tegra20: display: fix checking of return value
  ARM: tegra: fix include guard

Stephen Warren (2):
  ARM: tegra: fix extlinux.conf search location
  ARM: tegra: set initrd_high so boot scripts work

 arch/arm/cpu/armv7/tegra20/display.c | 2 +-
 include/configs/tegra-common-post.h  | 9 +
 include/configs/tegra-common-ums.h   | 2 +-
 3 files changed, 7 insertions(+), 6 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] driver/ddr: Fix DDR4 driver for ARM

2014-06-19 Thread York Sun
On 06/18/2014 07:57 AM, Jon Loeliger wrote:
> On Tue, Jun 17, 2014 at 5:07 PM, York Sun  wrote:
>> Previously the driver was only tested on Power SoCs. Minor fix is needed
>> for ARM SoCs.
>>
>> Signed-off-by: York Sun 
> 
> 
> Hi York!
> 
> 
>> --- a/drivers/ddr/fsl/fsl_ddr_gen4.c
>> +++ b/drivers/ddr/fsl/fsl_ddr_gen4.c
> 
>> @@ -183,12 +184,20 @@ step2:
>>  * we choose the max, that is 500 us for all of case.
>>  */
>> udelay(500);
>> +#ifdef CONFIG_PPC
>> asm volatile("sync;isync");
>> +#else
>> +   asm volatile("dsb sy;isb");
>> +#endif
>>
>> /* Let the controller go */
>> temp_sdram_cfg = ddr_in32(&ddr->sdram_cfg) & ~SDRAM_CFG_BI;
>> ddr_out32(&ddr->sdram_cfg, temp_sdram_cfg | SDRAM_CFG_MEM_EN);
>> +#ifdef CONFIG_PPC
>> asm volatile("sync;isync");
>> +#else
>> +   asm volatile("dsb sy;isb");
>> +#endif
>>
>> total_gb_size_per_controller = 0;
>> for (i = 0; i < CONFIG_CHIP_SELECTS_PER_CTRL; i++) {
> 
> This is a great example where we should try to introduce better abstractions
> in much the same way that Linux has.  Specifically, we (U-Boot) collective
> might work toward some common lower-level abstractions such as a
> memory_barrier() (and variants), and let those generic names get mapped
> into architecture-specific implementations via a linked binding.  Then this
> code would not need to change, nor would #ifdefs be needed.
> 

Jon,

Are you suggesting to pick arch//include/asm/barrier.h from Linux, or part
of it?

York

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


Re: [U-Boot] [PATCH] mmc: sdhci: Fixed timeout for sdhci_send_command()

2014-06-19 Thread Eli Billauer

On 19/06/14 19:43, Andy Fleming wrote:

On Thu, Jun 12, 2014 at 4:41 AM, Eli Billauer  wrote:
   

The current wait loop just reads the status 1 times, which makes the
actual timeout period platform-dependent. The udelay() call within the loop
makes the new timeout ~100 ms.

[ snipped patch ]
 


Hmmm...

Is 100ms part of the spec? I like the idea of making the timeout more
time-based, but it seems to me that this changes the timeout quite
significantly. If it took N ms before, it now takes N + 100 ms.

I think, if we want the timeout to be ~100ms, we should use a udelay
of 100 or 1000, and then reduce "retry" accordingly.
   

Hi,

As I said in the mail preceding this patch, I don't know what the 
timeout should be. Maybe someone with a better knowledge on MMC could 
come forward.


Regards,
   Eli

Andy

   


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


[U-Boot] [PATCH 2/2] ARM: tegra: set initrd_high so boot scripts work

2014-06-19 Thread Stephen Warren
From: Stephen Warren 

During bootm/z, U-Boot relocates the DTB and initrd to high memory so
they are out of the way of the kernel. On ARM at least, some parts of
high memory are "highmem" and can't be accessed at early boot. To solve
this, we need to restrict this relocation process to use lower parts of
RAM that area accessible.

For the DTB, an earlier patch of mine set CONFIG_SYS_BOOTMAPSZ. However,
since some platforms have different restrictions on DTB and initrd
location, that config option doesn't affect the initrd. We need to set
the initrd_high environment variable to control the initrd relocation.

Since we have carefully chosen the load addresses for the DTB and
initrd (see comments in include/configs/tegraNNN-common.h re: values in
MEM_LAYOUT_ENV_SETTINGS), we don't actually need any DTB or initrd
relocation at all. Skipping relocation removes some redundant work.
Hence, set both fdt_high and initrd_high to  which completely
disables relocation.

If the user does something unusual, such as using custom locations for
the DTB/initrd load address or wanting to use DTB/initrd relocation for
some reason, they can simply set these variables to custom values to
override these environment defaults.

With this change, cmd_sysboot works correctly for a filesystem created
by the Fedora installer.

Signed-off-by: Stephen Warren 
---
 include/configs/tegra-common-post.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/tegra-common-post.h 
b/include/configs/tegra-common-post.h
index 8cfc17a93c74..1c770c90feca 100644
--- a/include/configs/tegra-common-post.h
+++ b/include/configs/tegra-common-post.h
@@ -173,6 +173,8 @@
 #define CONFIG_EXTRA_ENV_SETTINGS \
TEGRA_DEVICE_SETTINGS \
MEM_LAYOUT_ENV_SETTINGS \
+   "fdt_high=\0" \
+   "initrd_high=\0" \
BOOTCMDS_COMMON \
BOARD_EXTRA_ENV_SETTINGS
 
-- 
1.8.1.5

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


[U-Boot] [PATCH 1/2] ARM: tegra: fix extlinux.conf search location

2014-06-19 Thread Stephen Warren
From: Stephen Warren 

extlinux.conf is stored in /boot/extlinux/extlinux.conf rather than
/boot/extlinux.conf. Adjust Tegra's default boot scripts to use the
correct location. This change aligns Tegra's boot scripts with rpi_b.h
and also the location that the Fedora installer actually puts the file.

Signed-off-by: Stephen Warren 
---
 include/configs/tegra-common-post.h | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/include/configs/tegra-common-post.h 
b/include/configs/tegra-common-post.h
index 76dad4e88cd9..8cfc17a93c74 100644
--- a/include/configs/tegra-common-post.h
+++ b/include/configs/tegra-common-post.h
@@ -101,13 +101,12 @@
\
"do_sysboot_boot="\
"sysboot ${devtype} ${devnum}:${rootpart} any "   \
-   "${scriptaddr} ${prefix}extlinux.conf\0"  \
+   "${scriptaddr} ${prefix}extlinux/extlinux.conf\0" \
\
"sysboot_boot="   \
"if test -e ${devtype} ${devnum}:${rootpart} "\
-   "${prefix}extlinux.conf; then "   \
-   "echo Found extlinux config " \
-   "${prefix}extlinux.conf; "\
+   "${prefix}extlinux/extlinux.conf; then "  \
+   "echo Found ${prefix}extlinux/extlinux.conf; "\
"run do_sysboot_boot; "   \
"echo SCRIPT FAILED: continuing...; " \
"fi\0"\
-- 
1.8.1.5

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


Re: [U-Boot] [PATCH] mmc: sdhci: Fixed timeout for sdhci_send_command()

2014-06-19 Thread Andy Fleming
On Thu, Jun 12, 2014 at 4:41 AM, Eli Billauer  wrote:
> The current wait loop just reads the status 1 times, which makes the
> actual timeout period platform-dependent. The udelay() call within the loop
> makes the new timeout ~100 ms.
>
> Signed-off-by: Eli Billauer 
> ---
>  drivers/mmc/sdhci.c |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
> index 3125d13..80f3a91 100644
> --- a/drivers/mmc/sdhci.c
> +++ b/drivers/mmc/sdhci.c
> @@ -226,6 +226,7 @@ int sdhci_send_command(struct mmc *mmc, struct mmc_cmd 
> *cmd,
> break;
> if (--retry == 0)
> break;
> +   udelay(10);
> } while ((stat & mask) != mask);


Hmmm...

Is 100ms part of the spec? I like the idea of making the timeout more
time-based, but it seems to me that this changes the timeout quite
significantly. If it took N ms before, it now takes N + 100 ms.

I think, if we want the timeout to be ~100ms, we should use a udelay
of 100 or 1000, and then reduce "retry" accordingly.

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


[U-Boot] Consistently repeated TFTP timeouts (target directly connected to host PC)

2014-06-19 Thread Johnson Thomas
Hi all,

I am facing an issue of repeated TFTP timeouts when downloading the kernel
image in U-Boot with target directly connected to host PC. The download
pattern almost 95% of the time looks like this

TFTP from server 10.11.2.47; our IP address is 10.11.6.94
Filename 'uImage'.
Load address: 0xc070
Loading: #T ###T
#
 #
 T #
 #
 #
 #
 ##T T ##T
#
 ##
 186.5 KiB/s
done

I did verify the solution provided in [1], the PHY has the setting 100Mbps
full duplex mode and the MAC is configured to the same setting by U-Boot in
davinci_emac.c (can be verified from the log snippets shown below,
MACCONTROL: 32801 = 0x8021 = 100Mbps Full Duplex mode).

Although, there are repeated TFTP timeouts, the kernel image is eventually
downloaded and boots up. It can also be noted that there were instances
where no TFTP timeouts were observed when downloading the kernel image.

The custom board that I am using has an OMAPL138 ARM processor. In order to
debug the issue, I applied the following debug patch to U-Boot

diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 1db586d..c243e04 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -46,7 +46,7 @@
 #include 
 #include "davinci_emac.h"

-unsigned int   emac_dbg = 0;
+unsigned int   emac_dbg = 1;
 #define debug_emac(fmt,args...)if (emac_dbg) printf(fmt,##args)

 #ifdef EMAC_HW_RAM_ADDR
@@ -699,12 +699,34 @@ static int davinci_eth_rcv_packet (struct eth_device
*dev)
volatile emac_desc *rx_curr_desc;
volatile emac_desc *curr_desc;
volatile emac_desc *tail_desc;
-   int status, ret = -1;
-
+   int status, ret = -1, i;
+
davinci_invalidate_rx_descs();

rx_curr_desc = emac_rx_active_head;
status = rx_curr_desc->pkt_flag_len;
+   unsigned long tmp_status = rx_curr_desc->pkt_flag_len;
+   unsigned long tmp_macstatus, tmp_maccontrol, tmp_macintmaskset;
+   tmp_macstatus = readl(&adap_emac->MACSTATUS);
+   tmp_maccontrol = readl(&adap_emac->MACCONTROL);
+   tmp_macintmaskset = readl(&adap_emac->MACINTMASKSET);
+   printf("Receive Status: %ul\n",tmp_status);
+   printf("MACSTATUS = %ul, MACCONTROL = %ul\n", tmp_macstatus,
tmp_maccontrol);
+   if(rx_curr_desc != NULL) {
+   printf("Rx active head: %p\n",rx_curr_desc);
+   printf("Buffer length: %d\n",rx_curr_desc->buff_off_len &
0x);
+   printf("Packet length: %d\n",rx_curr_desc->pkt_flag_len &
0x);
+   struct ethernet_hdr *tmp_pkt = (struct ethernet_hdr
*)((uchar *) rx_curr_desc->buffer);
+   printf("Dest Node\n");
+   for(i=0;i<6;i++)
+   printf("%u ",tmp_pkt->et_dest[i]);
+   printf("\n");
+   printf("Src Node\n");
+   for(i=0;i<6;i++)
+   printf("%u ",tmp_pkt->et_src[i]);
+   printf("\n");
+   printf("ProtLen: %d\n",tmp_pkt->et_protlen);
+   }
if ((rx_curr_desc) && ((status & EMAC_CPPI_OWNERSHIP_BIT) == 0)) {
if (status & EMAC_CPPI_RX_ERROR_FRAME) {
/* Error in packet - discard it and requeue desc */
diff --git a/include/net.h b/include/net.h
index 970d4d1..20e68f8 100644
--- a/include/net.h
+++ b/include/net.h
@@ -19,10 +19,10 @@
 #include 
 #include  /* for nton* / ntoh* stuff */

-#define DEBUG_LL_STATE 0   /* Link local state machine changes */
-#define DEBUG_DEV_PKT 0/* Packets or info directed to the
device */
-#define DEBUG_NET_PKT 0/* Packets on info on the network
at large */
-#define DEBUG_INT_STATE 0  /* Internal network state changes */
+#define DEBUG_LL_STATE 1   /* Link local state machine changes */
+#define DEBUG_DEV_PKT 1/* Packets or info directed to the
device */
+#define DEBUG_NET_PKT 1/* Packets on info on the network
at large */
+#define DEBUG_INT_STATE 1  /* Internal network state changes */

 /*
  * The number of receive packet buffers, and the required packet buffer

I observed the following log snippet repeated multiple times during each
TFTP timeout, after which the download works fine until the next timeout

Receive Status: 536870912l
MACSTATUS = 2147483648l, MACCONTROL = 32801l
Rx active head: 01e20060
Buffer length: 1518
Packet length: 0
Dest Node
0 17 64 47 0 4
Src Node
8 0 39 91 249 79
ProtLen: 8

Following are some log snippets which m

Re: [U-Boot] [PATCH] ARM: tegra: fix include guard

2014-06-19 Thread Tom Rini
On Thu, Jun 19, 2014 at 09:08:08AM -0700, Tom Warren wrote:

> Just got back from vacation - I'll put it in u-boot-tegra/next. Should I send 
> a PR to Albert so it goes up the chain in the usual manner? Or would you like 
> to pull it directly once it's in u-boot-tegra?

It's a trivial enough patch that I'm fine with it coming in for this
release, via Albert as usual.  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] ARM: tegra: fix include guard

2014-06-19 Thread Tom Warren
Just got back from vacation - I'll put it in u-boot-tegra/next. Should I send a 
PR to Albert so it goes up the chain in the usual manner? Or would you like to 
pull it directly once it's in u-boot-tegra?

--
nvpublic

> -Original Message-
> From: Tom Rini [mailto:tom.r...@gmail.com] On Behalf Of Tom Rini
> Sent: Thursday, June 19, 2014 8:56 AM
> To: Stephen Warren
> Cc: Tom Warren; u-boot@lists.denx.de; Jeroen Hofstee; Stephen Warren
> Subject: Re: [U-Boot] [PATCH] ARM: tegra: fix include guard
> 
> * PGP Signed by an unknown key
> 
> On Thu, Jun 19, 2014 at 09:52:53AM -0600, Stephen Warren wrote:
> 
> > On 06/11/2014 01:55 PM, Stephen Warren wrote:
> > > On 06/11/2014 01:53 PM, Jeroen Hofstee wrote:
> > >
> > >> diff --git a/include/configs/tegra-common-ums.h
> > >> b/include/configs/tegra-common-ums.h
> > >
> > >>  #ifndef _TEGRA_COMMON_UMS_H_
> > >> -#define _TEGRA_COMMON_UMS_H
> > >> +#define _TEGRA_COMMON_UMS_H_
> > >
> > > Acked-by: Stephen Warren 
> >
> > Has this been picked up? I wonder if TomR or TomW will do that?
> 
> I tossed this towards Tom W in patchwork, got enough time left in the
> release for one more PR at least :)
> 
> --
> Tom
> 
> * Unknown Key
> * 0x94391D56
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 3/6] mmc: fsl_esdhc: Add CMD11 support to switch to 1.8V

2014-06-19 Thread Andy Fleming
On Sun, Jun 15, 2014 at 7:46 PM, Otavio Salvador
 wrote:
> This adds support to switch to 1.8V in case CMD11 succeeds.
>
> Signed-off-by: Otavio Salvador 
> ---
>
>  drivers/mmc/fsl_esdhc.c | 30 +++---
>  include/fsl_esdhc.h |  2 ++
>  include/mmc.h   |  1 +
>  3 files changed, 26 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
> index 5541613..c75b38f 100644
> --- a/drivers/mmc/fsl_esdhc.c
> +++ b/drivers/mmc/fsl_esdhc.c
> @@ -47,19 +47,21 @@ struct fsl_esdhc {
> uintfevt;   /* Force event register */
> uintadmaes; /* ADMA error status register */
> uintadsaddr;/* ADMA system address register */
> -   charreserved2[160]; /* reserved */
> +   charreserved2[100]; /* reserved */
> +   uintvendorspec; /* Vendor Specific register */
> +   charreserved3[59];  /* reserved */
> uinthostver;/* Host controller version register */
> -   charreserved3[4];   /* reserved */
> -   uintdmaerraddr; /* DMA error address register */
> charreserved4[4];   /* reserved */
> -   uintdmaerrattr; /* DMA error attribute register */
> +   uintdmaerraddr; /* DMA error address register */
> charreserved5[4];   /* reserved */
> +   uintdmaerrattr; /* DMA error attribute register */
> +   charreserved6[4];   /* reserved */
> uinthostcapblt2;/* Host controller capabilities register 2 */
> -   charreserved6[8];   /* reserved */
> +   charreserved7[8];   /* reserved */
> uinttcr;/* Tuning control register */
> -   charreserved7[28];  /* reserved */
> +   charreserved8[28];  /* reserved */
> uintsddirctl;   /* SD direction control register */
> -   charreserved8[712]; /* reserved */
> +   charreserved9[712]; /* reserved */
> uintscr;/* eSDHC control register */
>  };
>
> @@ -334,6 +336,15 @@ esdhc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, 
> struct mmc_data *data)
> goto out;
> }
>
> +   /* Switch voltage to 1.8V if CMD11 succeeded */
> +   if (cmd->cmdidx == SD_CMD_SWITCH_UHS18V) {
> +   esdhc_setbits32(®s->vendorspec, ESDHC_VENDORSPEC_VSELECT);
> +
> +   printf("Run CMD11 1.8V switch\n");
> +   /* Sleep for 5 ms - max time for card to switch to 1.8V */
> +   udelay(5000);
> +   }
> +


This seems like the wrong place to put this sort of change. send_cmd
is meant to deal with sending a command and dealing with any errors.
Voltage changes should probably be handled by set_ios. It looks like
Linux actually implements a separate op for voltage change, but the
operation should be:

send CMD11
deactivate clock
change voltage
wait 5ms
reactivate clock
wait 1ms
check for errors


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


Re: [U-Boot] [PATCH] ARM: tegra: Disable VPR

2014-06-19 Thread Stephen Warren
On 06/19/2014 12:58 AM, Alexandre Courbot wrote:
> From: Bryan Wu 
> 
> On Tegra114 and Tegra124 platforms, certain display-related registers cannot
> be accessed unless the VPR registers are programmed.  For bootloader, we
> probably don't care about VPR, so we disable it (which counts as programming
> it, and allows those display-related registers to be accessed.

> diff --git a/arch/arm/cpu/tegra-common/vpr.c b/arch/arm/cpu/tegra-common/vpr.c

> +void config_vpr(void)

> + /* Turn off VPR */
> + writel(0x, &mc->mc_video_protect_size_mb);
> + writel(0x0001, &mc->mc_video_protect_reg_ctrl);

Can we use a #define rather than "1" there, so we know what the bit
means. Also "0" is as good as "0x" and same for "1".

> diff --git a/arch/arm/include/asm/arch-tegra/mc.h 
> b/arch/arm/include/asm/arch-tegra/mc.h

> +/**
> + * Defines the memory controller registers we need/care about
> + */
> +struct mc_ctlr {
> + u32 reserved0[4];   /* offset 0x00 - 0x0C */
> + u32 mc_smmu_config; /* offset 0x10 */
...

Is this entire layout valid for Tegra20/30 too, and identical for
Tegra114/124? If not, I'd prefer that we:

- Define the structure in arch/arm/include/asm/arch-tegraNNN/mc.h, so
it's obvious that it's not identical on all SoCs (or if the differences
are small, then ifdef the fields in the struct without moving the file
to avoid duplicating the identical parts).

- ifdef out the body of config_vpr() except on SoCs where struct mc_ctrl
is defined.

(actually, ifdefing the body might be useful anyway to remove the code
from builds for older SoCs)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] ARM: tegra: fix include guard

2014-06-19 Thread Tom Rini
On Thu, Jun 19, 2014 at 09:52:53AM -0600, Stephen Warren wrote:

> On 06/11/2014 01:55 PM, Stephen Warren wrote:
> > On 06/11/2014 01:53 PM, Jeroen Hofstee wrote:
> > 
> >> diff --git a/include/configs/tegra-common-ums.h 
> >> b/include/configs/tegra-common-ums.h
> > 
> >>  #ifndef _TEGRA_COMMON_UMS_H_
> >> -#define _TEGRA_COMMON_UMS_H
> >> +#define _TEGRA_COMMON_UMS_H_
> > 
> > Acked-by: Stephen Warren 
> 
> Has this been picked up? I wonder if TomR or TomW will do that?

I tossed this towards Tom W in patchwork, got enough time left in the
release for one more PR at least :)

-- 
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] ARM: tegra: fix include guard

2014-06-19 Thread Stephen Warren
On 06/11/2014 01:55 PM, Stephen Warren wrote:
> On 06/11/2014 01:53 PM, Jeroen Hofstee wrote:
> 
>> diff --git a/include/configs/tegra-common-ums.h 
>> b/include/configs/tegra-common-ums.h
> 
>>  #ifndef _TEGRA_COMMON_UMS_H_
>> -#define _TEGRA_COMMON_UMS_H
>> +#define _TEGRA_COMMON_UMS_H_
> 
> Acked-by: Stephen Warren 

Has this been picked up? I wonder if TomR or TomW will do that?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] m68k: Remove CONFIG_CMD_BEDBUG related code

2014-06-19 Thread Tom Rini
On Sun, Jun 15, 2014 at 06:41:16PM +0300, Vasili Galka wrote:

> This flag does not compile on m68k since 2003 (8bde7f7) when a
> required "cmd_bedbug.h" header was removed. Eleven years passed,
> lets clean up a little...
> 
> Signed-off-by: Vasili Galka 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v2, 06/14] bootm: Split out code from cmd_bootm.c

2014-06-19 Thread Tom Rini
On Thu, Jun 19, 2014 at 11:23:24AM -0400, Tom Rini wrote:
> On Thu, Jun 12, 2014 at 07:24:46AM -0600, Simon Glass wrote:
> 
> > This file has code in three different categories:
> > - Command processing
> > - OS-specific boot code
> > - Locating images and setting up to boot
> > 
> > Only the first category really belongs in a file called cmd_bootm.c.
> > 
> > Leave the command processing code where it is. Split out the OS-specific
> > boot code into bootm_os.c. Split out the other code into bootm.c
> > 
> > Header files and extern declarations are tidied but otherwise no code
> > changes are made, to make it easier to review.
> > 
> > Signed-off-by: Simon Glass 
> 
> This, on am335x GP EVM doing UART booting (you can replicate the same on
> beaglebone black with no SD card / nothing bootable on eMMC and holing
> down the "user" button for the first boot, SYSBOOT pins will be set
> until next hard power cycle) causes:
> Sending /tmp/u-boot-spl.bin, 646 blocks: Give your local XMODEM receive
> command now.
> Bytes Sent:  82816   BPS:10461
> 
> Transfer complete
> Sending: u-boot.img
> Ymodem sectors/kbytes sent: 3433/429kyzModem - CRC mode,
> 4(SOH)/438(STX)/0(CAN) packets, 2 retries
> Loaded 448676 bytes
> No valid FDT found - please append one to U-Boot binary, use
> u-boot-dtb.bin or define CONFIG_OF_EMBED. For sandbox, use -d 
> initcall sequence 8085d568 failed at call 8083e678
> ### ERROR ### Please RESET the board ###

... because I didn't use u-boot-dtb.img which is a functional change,
which is why I then sent out and applied this morning a patch to move
most of this support on am335x_evm to be under ENABLE_VBOOT.

-- 
Tom


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


Re: [U-Boot] [U-Boot, v2, 13/14] Enhance fit_check_sign to check all images

2014-06-19 Thread Tom Rini
On Thu, Jun 12, 2014 at 07:24:53AM -0600, Simon Glass wrote:

> At present this tool only checks the configuration signing. Have it also
> look at each of the images in the configuration and confirm that they
> verify.
> 
> 
> Signed-off-by: Simon Glass 
> Acked-by: Heiko Schocher  (v1)

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [PATCH] am335x_evm: Only enable OF_CONTROL/OF_SEPARATE on VBOOT for now

2014-06-19 Thread Tom Rini
On Thu, Jun 19, 2014 at 08:48:08AM -0400, Tom Rini wrote:

> We don't make use of the device tree otherwise yet (and will need to
> think how to not break the current multi-board support) and this causes
> further breakage with additional changes.
> 
> Signed-off-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [PATCH v2 06/14] bootm: Split out code from cmd_bootm.c

2014-06-19 Thread Tom Rini
On Thu, Jun 12, 2014 at 07:24:46AM -0600, Simon Glass wrote:

> This file has code in three different categories:
> - Command processing
> - OS-specific boot code
> - Locating images and setting up to boot
> 
> Only the first category really belongs in a file called cmd_bootm.c.
> 
> Leave the command processing code where it is. Split out the OS-specific
> boot code into bootm_os.c. Split out the other code into bootm.c
> 
> Header files and extern declarations are tidied but otherwise no code
> changes are made, to make it easier to review.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/master, thanks! ... is what I meant to say, oops :)

-- 
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] pmic: tps65090: correct checking i2c bus

2014-06-19 Thread Tom Rini
On Sun, Jun 15, 2014 at 05:17:04PM +0200, Jeroen Hofstee wrote:

> The function tps65090_init checks the i2c bus of p->bus. However
> the pointer p is not intialiased at this point. Check the local
> variable bus instead.
> 
> cc: Tom Wai-Hong Tam 
> cc: Simon Glass 
> Signed-off-by: Jeroen Hofstee 
> Acked-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] Remove nios-32 arch remnants

2014-06-19 Thread Tom Rini
On Sun, Jun 15, 2014 at 06:42:09PM +0300, Vasili Galka wrote:

> nios-32 arch was removed back in 2010 (1117cbf). Code depending on
> its headers (nios.h, nios-io.h) can't possibly compile since then.
> As it wasn't fixed till now it is safe to remove.
> 
> Signed-off-by: Vasili Galka 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] cmd_md5sum.c: remove dead code / fix warning

2014-06-19 Thread Tom Rini
On Mon, Jun 16, 2014 at 12:10:42AM +0200, Jeroen Hofstee wrote:

> commit ecd729500 "Add parameter to md5sum to save the md5 sum"
> adds support to build a string to be saved in the env and tries
> to zero end it with str_ptr = '\0'; This does actually set the
> pointer to the end of the buffer itself to zero. Since the
> string was already zero terminated by the sprintf before it,
> just remove the line, preventing a clang warning.
> 
> cc: Joe Hershberger 
> Signed-off-by: Jeroen Hofstee 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] cosmetic: autoboot: update old style GNU struct init

2014-06-19 Thread Tom Rini
On Mon, Jun 16, 2014 at 12:17:33AM +0200, Jeroen Hofstee wrote:

> Signed-off-by: Jeroen Hofstee 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot,3/3] m68k: eliminate a warning in cpu_init

2014-06-19 Thread Tom Rini
On Wed, Oct 16, 2013 at 01:53:04PM +0900, Masahiro Yamada wrote:

> Signed-off-by: Masahiro Yamada 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] freescale: m5253demo: fix unused-but-set-variable warnings

2014-06-19 Thread Tom Rini
On Tue, Apr 15, 2014 at 01:26:34PM +0900, Masahiro Yamada wrote:

> Fix the following warning messages:
> 
> In function 'flash_erase': 180:21:
> warning: variable 'last' set but not used [-Wunused-but-set-variable]
> In function 'write_buff':  322:10:
> warning: variable 'port_width' set but not used [-Wunused-but-set-variable]
> 
> Signed-off-by: Masahiro Yamada 
> Cc: TsiChung Liew 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v2, 06/14] bootm: Split out code from cmd_bootm.c

2014-06-19 Thread Tom Rini
On Thu, Jun 12, 2014 at 07:24:46AM -0600, Simon Glass wrote:

> This file has code in three different categories:
> - Command processing
> - OS-specific boot code
> - Locating images and setting up to boot
> 
> Only the first category really belongs in a file called cmd_bootm.c.
> 
> Leave the command processing code where it is. Split out the OS-specific
> boot code into bootm_os.c. Split out the other code into bootm.c
> 
> Header files and extern declarations are tidied but otherwise no code
> changes are made, to make it easier to review.
> 
> Signed-off-by: Simon Glass 

This, on am335x GP EVM doing UART booting (you can replicate the same on
beaglebone black with no SD card / nothing bootable on eMMC and holing
down the "user" button for the first boot, SYSBOOT pins will be set
until next hard power cycle) causes:
Sending /tmp/u-boot-spl.bin, 646 blocks: Give your local XMODEM receive
command now.
Bytes Sent:  82816   BPS:10461

Transfer complete
Sending: u-boot.img
Ymodem sectors/kbytes sent: 3433/429kyzModem - CRC mode,
4(SOH)/438(STX)/0(CAN) packets, 2 retries
Loaded 448676 bytes
No valid FDT found - please append one to U-Boot binary, use
u-boot-dtb.bin or define CONFIG_OF_EMBED. For sandbox, use -d 
initcall sequence 8085d568 failed at call 8083e678
### ERROR ### Please RESET the board ###

-- 
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] fix: CONFIG_NETCONSOLE start/handle this stuff only outside SPL

2014-06-19 Thread Tom Rini
On Fri, Jun 13, 2014 at 06:25:29AM +0200, Hannes Petermaier wrote:

> SPL stage does not support various networking things, and therefore
> CONFIG_NETCONSOLE cannot be built within SPL.
> 
> Signed-off-by: Hannes Petermaier 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] includes: move openssl headers to include/u-boot

2014-06-19 Thread Tom Rini
On Thu, Jun 12, 2014 at 10:27:12PM +0200, Jeroen Hofstee wrote:

> commit 18b06652cd "tools: include u-boot version of sha256.h"
> unconditionally forced the sha256.h from u-boot to be used
> for tools instead of the host version. This is fragile though
> as it will also include the host version. Therefore move it
> to include/u-boot to join u-boot/md5.h etc which were renamed
> for the same reason.
> 
> cc: Simon Glass 
> Signed-off-by: Jeroen Hofstee 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] test: vboot: explicitly request bash

2014-06-19 Thread Tom Rini
On Thu, Jun 12, 2014 at 10:27:39AM -0600, Stephen Warren wrote:

> From: Stephen Warren 
> 
> vboot_test.sh uses Bashisms. Explicitly use #!/bin/bash so the script
> doesn't fail if /bin/sh isn't Bash.
> 
> Signed-off-by: Stephen Warren 
> Acked-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v2, 12/14] bootm: Move decompression code into its own function

2014-06-19 Thread Tom Rini
On Thu, Jun 12, 2014 at 07:24:52AM -0600, Simon Glass wrote:

> This makes it possible to decompress an image without it being a kernel
> and without intending to boot it (as it needed for host tools, for example).
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v2, 14/14] Add documentation for verified boot on Beaglebone Black

2014-06-19 Thread Tom Rini
On Thu, Jun 12, 2014 at 07:24:54AM -0600, Simon Glass wrote:

> As an example of an end-to-end process for using verified boot in U-Boot,
> add a detailed description of the steps to be used for a Beaglebone
> Black.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v2, 11/14] Allow compiling common/bootm.c on with HOSTCC

2014-06-19 Thread Tom Rini
On Thu, Jun 12, 2014 at 07:24:51AM -0600, Simon Glass wrote:

> We want to use some of the functionality in this file, so make it
> build on the host.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v2, 09/14] Fix small 'case' typo in image-fit.c

2014-06-19 Thread Tom Rini
On Thu, Jun 12, 2014 at 07:24:49AM -0600, Simon Glass wrote:

> This typo makes the comment confusing. Fix it.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v2, 07/14] image: Remove the fit_load_image() property parameter

2014-06-19 Thread Tom Rini
On Thu, Jun 12, 2014 at 07:24:47AM -0600, Simon Glass wrote:

> This can be obtained by looking up the image type, so is redundant. It is
> better to centralise this lookup to avoid errors.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v2, 10/14] Avoid including config.h in command.h

2014-06-19 Thread Tom Rini
On Thu, Jun 12, 2014 at 07:24:50AM -0600, Simon Glass wrote:

> This is not necessary and prevents using this header when building tools.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v2, 08/14] bootm: Support android boot on sandbox

2014-06-19 Thread Tom Rini
On Thu, Jun 12, 2014 at 07:24:48AM -0600, Simon Glass wrote:

> A small change allows this to operate on sandbox.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v2, 03/14] fdt: Rename the DEV_TREE_BIN Makefile flag to to EXT_DTB

2014-06-19 Thread Tom Rini
On Thu, Jun 12, 2014 at 07:24:43AM -0600, Simon Glass wrote:

> This seems like a better name. This is a patch-up to the earlier commit
> 63b4b5b, and also removes a redundant Makefile change.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v2, 05/14] Reverse the meaning of the fit_config_verify() return code

2014-06-19 Thread Tom Rini
On Thu, Jun 12, 2014 at 07:24:45AM -0600, Simon Glass wrote:

> It is more common to have 0 mean OK, and -ve mean error. Change this
> function to work the same way to avoid confusion.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


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


  1   2   >