[U-Boot] [PATCH 0/6][v2] powerpc: Add support 2 stage boot loader for corenet platform

2014-02-28 Thread Prabhakar Kushwaha

Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
---

Add support of 2 stage NAND boot loader in cornet platforms using SPL framework.

In current secenrio size of u-boot can become =512KB. So This patch set will 
be 
helpful for those SoC which has less internal SRAM(512KB).

here, PBL initialise the internal SRAM and copy SPL(192K) in SRAM.
SPL further initialise DDR using SPD and environment variables and copy
u-boot(768 KB) from flash to DDR.
Finally SPL transer control to u-boot for futher booting.

SPL has following features:
 - Executes within 256K
 - No relocation required

 Run time view of SPL framework :-
 ---
 Area| Address |
 ---
 GD, BD  | 0xFFFC  |
 ---
 ENV | 0xFFFC1000  |
 ---
 HEAP| 0xFFFC2800  |
 ---
 STACK   | 0xFFFD  |
 ---
 U-boot SPL  | 0xfffD -  0xfffc (192K) |
 ---

NAND Flash memory Map on B4860 and B4420QDS
--
 Start   EndDefinition  Size
0x000x0Fu-boot  1MB
0x140x15u-boot env  128KB
0x160x17FMAN Ucode  128KB
---
 This patch set contains:-

 [PATCH 1/6] powerpc/mpc85xx: Avoid hardcoding in SPL linker script
 
 [PATCH 2/6] powerpc:Add support of SPL non-relocation
 
 [PATCH 3/6] powerpc/mpc8xxx:Allow Parsing of LAW table in both SPL  non SPL
 
 [PATCH 4/6] driver/ifc: define nand_spl_load_image() for SPL

 [PATCH 5/6] Makefile: Add support of RAMBOOT_SPLPBL

 [PATCH 6/6] B4860QDS: Add support of 2 stage NAND boot loader
-- 
1.7.9.5



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


[U-Boot] [PATCH 1/6] powerpc/mpc85xx: Avoid hardcoding in SPL linker script

2014-02-28 Thread Prabhakar Kushwaha
SPL linker has fix location of bootpg and reset vector with respect to text 
base.
It is not necessary to have fixed locations.

Avoid such hardcoding.

Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
---
 arch/powerpc/cpu/mpc85xx/u-boot-spl.lds |7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds 
b/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
index acaa093..4fad68b 100644
--- a/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
+++ b/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
@@ -66,11 +66,16 @@ SECTIONS
} :text = 0x
 #else
 #if defined(CONFIG_FSL_IFC) /* Restrict bootpg at 4K boundry for IFC */
-   .bootpg ADDR(.text) + 0x1000 :
+#ifndef BOOT_PAGE_OFFSET
+#define BOOT_PAGE_OFFSET 0x1000
+#endif
+   .bootpg ADDR(.text) + BOOT_PAGE_OFFSET :
{
arch/powerpc/cpu/mpc85xx/start.o (.bootpg)
}
+#ifndef RESET_VECTOR_OFFSET
 #define RESET_VECTOR_OFFSET 0x1ffc /* IFC has 8K sram */
+#endif
 #elif defined(CONFIG_FSL_ELBC)
 #define RESET_VECTOR_OFFSET 0xffc /* LBC has 4k sram */
 #else
-- 
1.7.9.5



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


[U-Boot] [PATCH] board/b4860qds:Slow MDC clock to comply IEEE specs in PBI config

2014-02-28 Thread Prabhakar Kushwaha
With the default value of MDIO_CLK_DIV generatee MDC is too high and It is
violating the IEEE specs much higher than 2.5Mhz.

Although there is errata(A-006260) for EMI2(MDIO2), but same errata is
been hit on EMI1(MDIO1). unfortunately this errata never hit on B4 rev1.
So reduced the MDIO_CLK_DIV value.

Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
---
 board/freescale/b4860qds/b4_pbi.cfg |3 +++
 1 file changed, 3 insertions(+)

diff --git a/board/freescale/b4860qds/b4_pbi.cfg 
b/board/freescale/b4860qds/b4_pbi.cfg
index 57b726e..05377ba 100644
--- a/board/freescale/b4860qds/b4_pbi.cfg
+++ b/board/freescale/b4860qds/b4_pbi.cfg
@@ -22,6 +22,9 @@
 09110024 0018
 09110028 0018
 0911002c 0018
+#slowing down the MDC clock to make it = 2.5 MHZ
+094fc030 8148
+094fd030 8148
 #Flush PBL data
 09138000 
 091380c0 
-- 
1.7.9.5



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


[U-Boot] [PATCH 2/6] powerpc:Add support of SPL non-relocation

2014-02-28 Thread Prabhakar Kushwaha
Current SPL code base has BSS section placed after reset_vector. This means
they have to relocate to use the global variables. This put an implicit
requirement of having SPL size = Memory/2.

To avoid relocation:
- Move bss_section within SPL range
- Modify relocate_code()

Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
---
 README  |3 +++
 arch/powerpc/cpu/mpc85xx/start.S|2 ++
 arch/powerpc/cpu/mpc85xx/u-boot-spl.lds |   12 
 3 files changed, 17 insertions(+)

diff --git a/README b/README
index ff49260..3597a82 100644
--- a/README
+++ b/README
@@ -3300,6 +3300,9 @@ FIT uImage format:
continuing (the hardware starts execution after just
loading the first page rather than the full 4K).
 
+   CONFIG_SPL_SKIP_RELOCATE
+   Avoid SPL relocation
+
CONFIG_SPL_NAND_BASE
Include nand_base.c in the SPL.  Requires
CONFIG_SPL_NAND_DRIVERS.
diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S
index dbbd8e5..2360d49 100644
--- a/arch/powerpc/cpu/mpc85xx/start.S
+++ b/arch/powerpc/cpu/mpc85xx/start.S
@@ -1644,6 +1644,7 @@ relocate_code:
mr  r10,r5  /* Save copy of Destination Address */
 
GET_GOT
+#ifndef CONFIG_SPL_SKIP_RELOCATE
mr  r3,r5   /* Destination Address  */
lis r4,CONFIG_SYS_MONITOR_BASE@h/* Source  Address  
*/
ori r4,r4,CONFIG_SYS_MONITOR_BASE@l
@@ -1734,6 +1735,7 @@ relocate_code:
 
mtlrr0
blr /* NEVER RETURNS! */
+#endif
.globl  in_ram
 in_ram:
 
diff --git a/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds 
b/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
index 4fad68b..8453f3a 100644
--- a/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
+++ b/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
@@ -57,6 +57,16 @@ SECTIONS
. = ALIGN(8);
__init_begin = .;
__init_end = .;
+#ifdef CONFIG_SPL_SKIP_RELOCATE
+   . = ALIGN(4);
+   __bss_start = .;
+   .bss : {
+   *(.sbss*)
+   *(.bss*)
+   }
+   . = ALIGN(4);
+   __bss_end = .;
+#endif
 
 /* For ifc, elbc, esdhc, espi, all need the SPL without section .resetvec */
 #ifdef CONFIG_SYS_MPC85XX_NO_RESETVEC
@@ -86,6 +96,7 @@ SECTIONS
} = 0x
 #endif
 
+#ifndef CONFIG_SPL_SKIP_RELOCATE
/*
 * Make sure that the bss segment isn't linked at 0x0, otherwise its
 * address won't be updated during relocation fixups.
@@ -100,4 +111,5 @@ SECTIONS
}
. = ALIGN(4);
__bss_end = .;
+#endif
 }
-- 
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/6] powerpc/mpc8xxx:Allow Parsing of LAW table in both SPL non SPL

2014-02-28 Thread Prabhakar Kushwaha
 It is not necessary for SPL to define all required LAW of the system.
 Re-parse LAW table again during non SPL boot.

Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
---
 arch/powerpc/cpu/mpc8xxx/law.c |9 -
 1 file changed, 9 deletions(-)

diff --git a/arch/powerpc/cpu/mpc8xxx/law.c b/arch/powerpc/cpu/mpc8xxx/law.c
index a401083..d76ba22 100644
--- a/arch/powerpc/cpu/mpc8xxx/law.c
+++ b/arch/powerpc/cpu/mpc8xxx/law.c
@@ -244,15 +244,6 @@ void init_laws(void)
gd-arch.used_laws |= (1  i);
}
 
-#if (defined(CONFIG_NAND_U_BOOT)  !defined(CONFIG_NAND_SPL)) || \
-   (defined(CONFIG_SPL)  !defined(CONFIG_SPL_BUILD))
-   /*
-* in SPL boot we've already parsed the law_table and setup those LAWs
-* so don't do it again.
-*/
-   return;
-#endif
-
for (i = 0; i  num_law_entries; i++) {
if (law_table[i].index == -1)
set_next_law(law_table[i].addr, law_table[i].size,
-- 
1.7.9.5



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


[U-Boot] [PATCH 5/6] Makefile: Add support of RAMBOOT_SPLPBL

2014-02-28 Thread Prabhakar Kushwaha
Objective of this target to have concatenate binary having
- SPL binary in PBL command format
- U-boot binary

Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
---
 Makefile |9 +
 README   |4 
 2 files changed, 13 insertions(+)

diff --git a/Makefile b/Makefile
index 0281171..2c95130 100644
--- a/Makefile
+++ b/Makefile
@@ -708,6 +708,7 @@ ALL-y += u-boot.srec u-boot.bin System.map
 ALL-$(CONFIG_NAND_U_BOOT) += u-boot-nand.bin
 ALL-$(CONFIG_ONENAND_U_BOOT) += u-boot-onenand.bin
 ALL-$(CONFIG_RAMBOOT_PBL) += u-boot.pbl
+ALL-$(CONFIG_RAMBOOT_SPLPBL) += u-boot-with-spl-pbl.bin
 ALL-$(CONFIG_SPL) += spl/u-boot-spl.bin
 ALL-$(CONFIG_SPL_FRAMEWORK) += u-boot.img
 ALL-$(CONFIG_TPL) += tpl/u-boot-tpl.bin
@@ -835,6 +836,14 @@ OBJCOPYFLAGS_u-boot-with-tpl.bin = -I binary -O binary \
 tpl/u-boot-with-tpl.bin: tpl/u-boot-tpl.bin u-boot.bin FORCE
$(call if_changed,pad_cat)
 
+u-boot-with-spl-pbl.bin: spl/u-boot-spl.bin
+   tools/mkimage -n $(CONFIG_SYS_FSL_PBL_RCW) \
+   -R $(CONFIG_SYS_FSL_PBL_PBI) -T pblimage \
+   -d $ $@
+   $(OBJCOPY) -I binary -O binary \
+   --pad-to=$(CONFIG_SPL_PAD_TO) --gap-fill=0xff $@
+   cat u-boot.bin  $@
+
 SPL: spl/u-boot-spl.bin FORCE
$(Q)$(MAKE) $(build)=arch/arm/imx-common $@
 
diff --git a/README b/README
index 3597a82..2cd0bdf 100644
--- a/README
+++ b/README
@@ -486,6 +486,10 @@ The following options need to be configured:
PBI commands can be used to configure SoC before it starts the 
execution.
Please refer doc/README.pblimage for more details
 
+   CONFIG_RAMBOOT_SPLPBL
+   It adds a target to create boot binary having SPL binary in PBI 
format
+   concatenated with u-boot binary.
+
CONFIG_SYS_FSL_DDR_BE
Defines the DDR controller register space as Big Endian
 
-- 
1.7.9.5



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


[U-Boot] [PATCH 6/6] B4860QDS: Add support of 2 stage NAND boot loader

2014-02-28 Thread Prabhakar Kushwaha
Add support of 2 stage NAND boot loader using SPL framework.
here, PBL initialise the internal SRAM and copy SPL(96K). This further
initialise DDR using SPD and environment and copy u-boot(512 kb) from NAND to 
DDR.
Finally SPL transer control to u-boot.

Initialise/create followings required for SPL framework
  - Add spl.c which defines board_init_f, board_init_r
  - update tlb and ddr accordingly

Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
---
 board/freescale/b4860qds/Makefile |9 ++-
 board/freescale/b4860qds/ddr.c|6 +-
 board/freescale/b4860qds/spl.c|  115 +
 board/freescale/b4860qds/tlb.c|   10 
 boards.cfg|2 +-
 doc/README.b4860qds   |   33 +++
 include/configs/B4860QDS.h|   61 ++--
 7 files changed, 227 insertions(+), 9 deletions(-)
 create mode 100644 board/freescale/b4860qds/spl.c

diff --git a/board/freescale/b4860qds/Makefile 
b/board/freescale/b4860qds/Makefile
index e5cc054..0acd2a9 100644
--- a/board/freescale/b4860qds/Makefile
+++ b/board/freescale/b4860qds/Makefile
@@ -4,9 +4,14 @@
 # SPDX-License-Identifier: GPL-2.0+
 #
 
+ifdef CONFIG_SPL_BUILD
+obj-y += spl.o
+else
 obj-y  += b4860qds.o
-obj-y  += ddr.o
 obj-$(CONFIG_B4860QDS)+= eth_b4860qds.o
-obj-$(CONFIG_PCI)  += pci.o
+obj-$(CONFIG_PCI)  += pci.o
+endif
+
+obj-y  += ddr.o
 obj-y  += law.o
 obj-y  += tlb.o
diff --git a/board/freescale/b4860qds/ddr.c b/board/freescale/b4860qds/ddr.c
index 187c3b3..c3cd5ce 100644
--- a/board/freescale/b4860qds/ddr.c
+++ b/board/freescale/b4860qds/ddr.c
@@ -181,12 +181,16 @@ phys_size_t initdram(int board_type)
 
puts(Initializingusing SPD\n);
 
+#if defined(CONFIG_SPL_BUILD) || !defined(CONFIG_RAMBOOT_PBL)
dram_size = fsl_ddr_sdram();
 
dram_size = setup_ddr_tlbs(dram_size / 0x10);
dram_size *= 0x10;
 
-   puts(DDR: );
+#else
+   puts(DDR has been initialised by First stage boot loader\n);
+   dram_size =  0x8000;
+#endif
return dram_size;
 }
 
diff --git a/board/freescale/b4860qds/spl.c b/board/freescale/b4860qds/spl.c
new file mode 100644
index 000..d56cd30
--- /dev/null
+++ b/board/freescale/b4860qds/spl.c
@@ -0,0 +1,115 @@
+/* Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include asm/spl.h
+#include malloc.h
+#include ns16550.h
+#include nand.h
+#include i2c.h
+#include ../common/qixis.h
+#include b4860qds_qixis.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+phys_size_t get_effective_memsize(void)
+{
+   return CONFIG_SYS_L3_SIZE;
+}
+
+unsigned long get_board_sys_clk(void)
+{
+   u8 sysclk_conf = QIXIS_READ(brdcfg[1]);
+
+   switch ((sysclk_conf  0x0C)  2) {
+   case QIXIS_CLK_100:
+   return 1;
+   case QIXIS_CLK_125:
+   return 12500;
+   case QIXIS_CLK_133:
+   return 1;
+   }
+   return ;
+}
+
+unsigned long get_board_ddr_clk(void)
+{
+   u8 ddrclk_conf = QIXIS_READ(brdcfg[1]);
+
+   switch (ddrclk_conf  0x03) {
+   case QIXIS_CLK_100:
+   return 1;
+   case QIXIS_CLK_125:
+   return 12500;
+   case QIXIS_CLK_133:
+   return 1;
+   }
+   return ;
+}
+
+void board_init_f(ulong bootflag)
+{
+   u32 plat_ratio, sys_clk, uart_clk;
+   ccsr_gur_t *gur = (void *)CONFIG_SYS_MPC85xx_GUTS_ADDR;
+
+   /* Memcpy existing GD at CONFIG_SPL_GD_ADDR */
+   memcpy((void *)CONFIG_SPL_GD_ADDR, (void *)gd, sizeof(gd_t));
+
+   /* Update GD pointer */
+   gd = (gd_t *)(CONFIG_SPL_GD_ADDR);
+   __asm__ __volatile__( : : : memory);
+
+   console_init_f();
+
+   /* initialize selected port with appropriate baud rate */
+   sys_clk = get_board_sys_clk();
+   plat_ratio = (in_be32(gur-rcwsr[0])  25)  0x1f;
+   uart_clk = sys_clk * plat_ratio / 2;
+
+   NS16550_init((NS16550_t)CONFIG_SYS_NS16550_COM1,
+uart_clk / 16 / CONFIG_BAUDRATE);
+
+   relocate_code(CONFIG_SPL_RELOC_STACK, (gd_t *)CONFIG_SPL_GD_ADDR, 0x0);
+}
+
+void board_init_r(gd_t *gd, ulong dest_addr)
+{
+   bd_t *bd;
+
+   bd = (bd_t *)(gd + sizeof(gd_t));
+   memset(bd, 0, sizeof(bd_t));
+   gd-bd = bd;
+   bd-bi_memstart = CONFIG_SYS_INIT_L3_ADDR;
+   bd-bi_memsize = CONFIG_SYS_L3_SIZE;
+
+   probecpu();
+   get_clocks();
+   mem_malloc_init(CONFIG_SPL_RELOC_MALLOC_ADDR,
+   CONFIG_SPL_RELOC_MALLOC_SIZE);
+
+#ifndef CONFIG_SPL_NAND_BOOT
+   env_init();
+#endif
+
+   /* relocate environment function pointers etc. */
+#ifdef CONFIG_SPL_NAND_BOOT
+   nand_spl_load_image(CONFIG_ENV_OFFSET, CONFIG_ENV_SIZE,
+   (uchar *)CONFIG_ENV_ADDR);
+   gd-env_addr  = (ulong)(CONFIG_ENV_ADDR);
+   gd-env_valid = 1;
+#else
+ 

Re: [U-Boot] [PATCH V3 03/12] video:exynos_fb:fdt: add additional fdt data

2014-02-28 Thread Piotr Wilczek

Hi Ajay,

Thank you for review. Please see answers below.

On 02/27/2014 03:10 PM, Ajay kumar wrote:

Piotr,

Adding more comments.

On Thu, Feb 27, 2014 at 10:50 PM, Ajay kumar ajayn...@gmail.com wrote:


Hi Piotr,
Find my comments inline.


On Tue, Feb 25, 2014 at 11:33 PM, Piotr Wilczek p.wilc...@samsung.comwrote:


This patch adds additional data parsing from DTB and adds the new
exynos_lcd_panel_init() function for panel specific initialisation
from the board file.

Signed-off-by: Piotr Wilczek p.wilc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
---
Changes for v3:
  - none

Changes for v2:
  - removed duplicate DTB node parsing for panel_info.logo_on
  - added (weak) exynos_lcd_panel_init function for panel specific
 initialisation from board file

  drivers/video/exynos_fb.c | 21 +
  1 file changed, 21 insertions(+)

diff --git a/drivers/video/exynos_fb.c b/drivers/video/exynos_fb.c
index 00a0a11..88d9037 100644
--- a/drivers/video/exynos_fb.c
+++ b/drivers/video/exynos_fb.c
@@ -104,6 +104,13 @@ void __exynos_backlight_reset(void)
  void exynos_backlight_reset(void)
 __attribute__((weak, alias(__exynos_backlight_reset)));

+int __exynos_lcd_panel_init(vidinfo_t *vid)
+{
+   return 0;
+}
+int exynos_lcd_panel_init(vidinfo_t *vid)
+   __attribute__((weak, alias(__exynos_lcd_panel_init)));
+


This is redundant! We already have exynos_cfg_lcd_gpio, exynos_lcd_power_on
and other similar functions to support panel init.
The 'init_panel_info' is used to init lcd panel from he board file. It 
is called when CONFIG_OF_CONTROL is not defined. When CONFIG_OF_CONTROL 
is defined then we init panel from DTB data in exynos_fimd_parse_dt 
function.


However, it may be necessary to do some additional initializations that 
are optional and board specific. That’s what 'exynos_lcd_panel_init' 
function is for.



Please check board/samsung/smdk5250.c

smdk5250.c is compiled when CONFIG_OF_CONTROL is not defined.
With CONFIG_OF_CONTROL enabled, the exynos5-dt.c is used but it does not 
implement 'init_panel_info' so I would get undefined reference to 
'init_panel_info'. Tahts another reason that I introduced the above 
function.





  static void lcd_panel_on(vidinfo_t *vid)
  {
 udelay(vid-init_delay);
@@ -269,6 +276,15 @@ int exynos_fimd_parse_dt(const void *blob)
 panel_info.dual_lcd_enabled = fdtdec_get_int(blob, node,

samsung,dual-lcd-enabled, 0);

+   panel_info.resolution = fdtdec_get_int(blob, node,
+   samsung,resolution, 0);
+
+   panel_info.rgb_mode = fdtdec_get_int(blob, node,
+   samsung,rgb-mode, 0);
+
+   panel_info.power_on_delay = fdtdec_get_int(blob, node,
+   samsung,power-on-delay,
0);
+


All the above DT properties are already present in the same file!
This are definitely duplicate entries.
Right, rgb_mode and power_on_delay I was supposed to remove in the 
previous version but overlooked that, thanks.



For passing resolution, please use samsung,vl-col and samsung,vl-row
Previously HD_RESOLUTION was assigned to panel_info.resolution. It is 
defined as 0 in libtizen.h.





 return 0;
  }
  #endif
@@ -281,10 +297,15 @@ void lcd_ctrl_init(void *lcdbase)
  #ifdef CONFIG_OF_CONTROL
 if (exynos_fimd_parse_dt(gd-fdt_blob))
 debug(Can't get proper panel info\n);
+#ifdef CONFIG_EXYNOS_MIPI_DSIM
+   exynos_init_dsim_platform_data(panel_info);
+#endif
+   exynos_lcd_panel_init(panel_info);


This is already present as part of lcd_enable in same file!
Please check it.


Ok. I just heard from MIPI-DSI engineer that MIPI-DSI should
usually be initialized before FIMD video output starts.

Is that the reason why you are trying to do panel_init here?
That seems ok, but definitely you should not be using a new
function for that.
exynos_lcd_panel_init function is supposed to do only additional (to 
exynos_fimd_parse_dt) initializations like ex: get_tizen_logo_info.




Use something like below snippet:

/* exynos_fb.c */
.
lcd_ctrl_init()
{.
.
.
if(CONFIG_EXYNOS_MIPI...)
call lcd_panel_on  /* MIPI-DSI to be initialized before FIMD init */
.
do exynos_lcd_init() /* FIMD init */
.
}
.
.
.
.
lcd_enable()
{
.
.
if(CONFIG_EXYNOS_DP...)
call lcd_panel_on /* DP to be initialized after FIMD init */
.
.
}


   #else

 /* initialize parameters which is specific to panel. */
 init_panel_info(panel_info);
  #endif
+
 panel_width = panel_info.vl_width;
 panel_height = panel_info.vl_height;

--
1.8.3.2

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




Regards,
Ajay Kumar



Regards,
Ajay Kumar



___
U-Boot mailing list

Re: [U-Boot] U-Boot: could not cross-compile u-boot tools

2014-02-28 Thread Masahiro Yamada
Hello Heiko,

  Is this a Bug, which should be fixed? Any hints?
 
  It seems like we need to pick up
  http://lists.linaro.org/pipermail/linaro-kernel/2013-August/005772.html
 
 Yes, this seems a way to go...
 
 @Masahiro: What is your opinion?

Hmm, I don't like such a patch because
 [1] It changes too much
 [2] We must build tools in two steps.
First time, build tools for host
  make O=path/to/buildhost/ silentoldconfig prepare scripts
Second time, built tools for the target 
 make HOSTCC=$CROSS_COMPILE \
   KBUILD_SCRIPTROOT=path/to/buildhost/
silentoldconfig prepare scripts
   It seems ridiculous to type so many magic commands.



Heiko, can you check if the following works for you?


Modify tools/Makefile as follows

  --- a/tools/Makefile
  +++ b/tools/Makefile
  @@ -5,6 +5,10 @@
   # SPDX-License-Identifier: GPL-2.0+
   #

   +ifneq ($(CROSS_BUILD_TOOLS),)
   +HOSTCC = $(CC)
   +endif
   +
#
# toolchains targeting win32 generate .exe files
#


Usage:
Build tools for host
 make  CROSS_COMPILE=your_gcc_prefix tools
Build tools for target
 make CROSS_BUILD_TOOLS=1  CROSS_COMPILE=your_gcc_prefix tools


This is my log.

$ make IDS8247_config
Configuring for IDS8247 board...
$ make CROSS_COMPILE=powerpc-linux-gnu- CROSS_BUILD_TOOLS=1 tools
  GEN include/autoconf.mk.dep
  GEN include/autoconf.mk
  CHK include/config/uboot.release
  UPD include/config/uboot.release
  CHK include/generated/version_autogenerated.h
  UPD include/generated/version_autogenerated.h
  CHK include/generated/timestamp_autogenerated.h
  UPD include/generated/timestamp_autogenerated.h
  HOSTCC  scripts/basic/fixdep
  CC  lib/asm-offsets.s
  GEN include/generated/generic-asm-offsets.h
  HOSTCC  tools/aisimage.o
  HOSTCC  tools/crc32.o
  HOSTCC  tools/default_image.o
  HOSTCC  tools/dumpimage.o
  HOSTCC  tools/env_embedded.o
  HOSTCC  tools/envcrc.o
  HOSTCC  tools/fdt.o
  HOSTCC  tools/fdt_ro.o
  HOSTCC  tools/fdt_rw.o
  HOSTCC  tools/fdt_strerror.o
  HOSTCC  tools/fdt_wip.o
  HOSTCC  tools/fit_image.o
  HOSTCC  tools/image-fit.o
  HOSTCC  tools/image-host.o
  HOSTCC  tools/image.o
  HOSTCC  tools/imagetool.o
  HOSTCC  tools/imximage.o
  HOSTCC  tools/kwbimage.o
  HOSTCC  tools/md5.o
  HOSTCC  tools/mkenvimage.o
  HOSTCC  tools/mkimage.o
  HOSTCC  tools/mxsimage.o
  HOSTCC  tools/omapimage.o
  HOSTCC  tools/os_support.o
  HOSTCC  tools/pblimage.o
  HOSTCC  tools/sha1.o
  HOSTCC  tools/ublimage.o
  HOSTLD  tools/envcrc
  HOSTCC  tools/gen_eth_addr
  HOSTCC  tools/img2srec
  HOSTLD  tools/mkenvimage
  HOSTLD  tools/dumpimage
  HOSTLD  tools/mkimage
  HOSTCC  tools/proftool
$ file tools/mkimage
tools/mkimage: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 
(SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, 
BuildID[sha1]=0xb76ad5a10a41700fcab9e86c079118c424446d89, with unknown 
capability 0x4100 = 0xf676e75, with unknown capability 0x1 = 0x70401, 
not stripped



Uknown Issue:
Tools are not stripped.
Too big for your target board?


Best Regards
Masahiro Yamada

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


[U-Boot] [PATCH 4/6] driver/ifc: define nand_spl_load_image() for SPL

2014-02-28 Thread Prabhakar Kushwaha
nand_spl_load_image() can also be used for non TPL framework.

Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
---
 drivers/mtd/nand/fsl_ifc_spl.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/nand/fsl_ifc_spl.c b/drivers/mtd/nand/fsl_ifc_spl.c
index 2f82f7c..8a7a3a3 100644
--- a/drivers/mtd/nand/fsl_ifc_spl.c
+++ b/drivers/mtd/nand/fsl_ifc_spl.c
@@ -88,7 +88,7 @@ static inline int bad_block(uchar *marker, int port_size)
return __raw_readw((u16 *)marker) != 0x;
 }
 
-#ifdef CONFIG_TPL_BUILD
+#if defined(CONFIG_TPL_BUILD) || defined(CONFIG_SPL_BUILD)
 int nand_spl_load_image(uint32_t offs, unsigned int uboot_size, void *vdst)
 #else
 static int nand_load(uint32_t offs, unsigned int uboot_size, void *vdst)
@@ -221,7 +221,7 @@ static int nand_load(uint32_t offs, unsigned int 
uboot_size, void *vdst)
  * Defines a static function nand_load_image() here, because non-static makes
  * the code too large for certain SPLs(minimal SPL, maximum size = 4Kbytes)
  */
-#ifndef CONFIG_TPL_BUILD
+#if !defined(CONFIG_TPL_BUILD)  !defined(CONFIG_SPL_BUILD)
 #define nand_spl_load_image(offs, uboot_size, vdst) \
nand_load(offs, uboot_size, vdst)
 #endif
-- 
1.7.9.5



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


Re: [U-Boot] U-Boot: could not cross-compile u-boot tools

2014-02-28 Thread Heiko Schocher

Hallo Masahiro,

Am 28.02.2014 10:03, schrieb Masahiro Yamada:

Hello Heiko,


Is this a Bug, which should be fixed? Any hints?


It seems like we need to pick up
http://lists.linaro.org/pipermail/linaro-kernel/2013-August/005772.html


Yes, this seems a way to go...

@Masahiro: What is your opinion?


Hmm, I don't like such a patch because
  [1] It changes too much


Ok, if there is an easier way, that would be great!


  [2] We must build tools in two steps.
 First time, build tools for host
   make O=path/to/buildhost/ silentoldconfig prepare scripts
 Second time, built tools for the target
  make HOSTCC=$CROSS_COMPILE \
KBUILD_SCRIPTROOT=path/to/buildhost/
 silentoldconfig prepare scripts
It seems ridiculous to type so many magic commands.


But it should be possible to compile the tools for the
target. If this a serperate build step, that is as it was
before the kbuild changes, so that should be no problem.


Heiko, can you check if the following works for you?


Modify tools/Makefile as follows

   --- a/tools/Makefile
   +++ b/tools/Makefile
   @@ -5,6 +5,10 @@
# SPDX-License-Identifier: GPL-2.0+
#

+ifneq ($(CROSS_BUILD_TOOLS),)
+HOSTCC = $(CC)
+endif
+
 #
 # toolchains targeting win32 generate .exe files
 #


Usage:
Build tools for host
  make  CROSS_COMPILE=your_gcc_prefix  tools
Build tools for target
  make CROSS_BUILD_TOOLS=1  CROSS_COMPILE=your_gcc_prefix  tools


Yep, works, great!


This is my log.

$ make IDS8247_config

[...]

$ file tools/mkimage
tools/mkimage: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 
(SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, 
BuildID[sha1]=0xb76ad5a10a41700fcab9e86c079118c424446d89, with unknown 
capability 0x4100 = 0xf676e75, with unknown capability 0x1 = 0x70401, 
not stripped



Uknown Issue:
Tools are not stripped.
Too big for your target board?


strip them would be nice ...

bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v6] socfpga: Adding Scan Manager driver

2014-02-28 Thread Michal Simek
On 02/27/2014 05:03 PM, Chin Liang See wrote:
 Scan Manager driver will be called to configure the IOCSR
 scan chain. This configuration will setup the IO buffer settings
 
 Signed-off-by: Chin Liang See cl...@altera.com
 Cc: Dinh Nguyen dingu...@altera.com
 Cc: Wolfgang Denk w...@denx.de
 CC: Pavel Machek pa...@denx.de
 Cc: Tom Rini tr...@ti.com
 Cc: Albert Aribaud albert.u.b...@aribaud.net
 ---
 Changes for v6
 - Fixed various coding style issue
 Changes for v5
 - Removal of additional blank line
 - Added comment for magic number
 Changes for v4
 - avoid code duplication by add goto error
 - include underscore to variables name
 Changes for v3
 - merge the handoff file and driver into single patch
 Changes for v2
 - rebase with latest v2014.01-rc1
 ---
  arch/arm/cpu/armv7/socfpga/Makefile|2 +-
  arch/arm/cpu/armv7/socfpga/scan_manager.c  |  211 +++
  arch/arm/cpu/armv7/socfpga/spl.c   |4 +
  arch/arm/include/asm/arch-socfpga/scan_manager.h   |   96 +++
  .../include/asm/arch-socfpga/socfpga_base_addrs.h  |1 +
  board/altera/socfpga/iocsr_config.c|  657 
 
  board/altera/socfpga/iocsr_config.h|   17 +


I still have problem with content of these two files.
In iocsr_config.c is ~600 lines which targets just one specific hardware design
configuration. I can't see any reason why this should go to mainline
and stay there. Because it brings no value.

I would recommend you just to define that arrays like this

const unsigned long iocsr_scan_chain0_table[];
const unsigned long iocsr_scan_chain0_table[];
...

+ in header
#define CONFIG_HPS_IOCSR_SCANCHAIN0_LENGTH0
#define CONFIG_HPS_IOCSR_SCANCHAIN1_LENGTH0
#define CONFIG_HPS_IOCSR_SCANCHAIN2_LENGTH0
#define CONFIG_HPS_IOCSR_SCANCHAIN3_LENGTH0

and write these 2 files by hand. Then your users will just replace them
by hand for specific board/design.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP - KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform




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


Re: [U-Boot] Ethernet persistence

2014-02-28 Thread Michal Simek
On 02/27/2014 05:09 PM, Anthony Mahar wrote:
 How can I make the ethernet connection persistent (after first use), rather
 than reconnecting/re initializing on each reuse? 
 
 I'm working with a Xilinx Zynq zc706 board and am up and running u-boot
 quite successfully.  My main use case is to store u-boot in on-board flash,
 and have u-boot tftp get / boot the bitstream, kernel image, devicetree, and
 ramdisk image.  The following script functions well:
   qspiboot=echo Configure PL and booting Linux from TFTP...   \
   fpga info 0;  \
   tftp 0x100 system.bin;\
   fpga load 0 0x100 cb44bc; \
   tftp 0x300 ${kernel_image}; \
   tftp 0x2A0 ${devicetree_image}; \
   tftp 0x200 ${ramdisk_image}; \
   bootm 0x300 0x200 0x2A0\0 \
 
 
 The ethernet (Zynq's gem.e000b000) will get initialized on first use, as
 appropriate, however the Ethernet is reinitialized and auto negotiated again
 for each subsequent tftp request which shouldn't be necessary.  A snippet is
 listed below.  Each 'reconnection' takes several seconds... a few to auto
 negotiate, then a few more for the Windows based TFTP server to recognize
 the connection and allow connections to the server.  Multiply this by the
 number of transfers and it takes a very long time to transfer a very little
 amount of data.
 
 Snippet:
 
 Xilinx Device
 Descriptor @ 0x3ffbaf78
 Family: Zynq PL
 Interface type: Device configuration interface (Zynq)
 Device Size:13321404 bytes
 Cookie: 0x45 (69)
 Device name:7z045
 No Device Function Table.
 Gem.e000b000 Waiting for PHY auto negotiation to complete... done
 Using Gem.e000b000 device
 TFTP from server 192.168.2.1; our IP address is 192.168.2.10
 Filename 'system.bin'.
 Load address: 0x100
 Loading: T #
  #
  #
  #
  #
  #
  #
  #
  #
  #
  #
  #
  #
  ###
  953.1 KiB/s
 done
 Bytes transferred = 13321404 (cb44bc hex)
 Gem.e000b000:7 is connected to Gem.e000b000.  Reconnecting to Gem.e000b000
 Gem.e000b000 Waiting for PHY auto negotiation to complete... done
 Using Gem.e000b000 device
 TFTP from server 192.168.2.1; our IP address is 192.168.2.10
 Filename 'uImage'.
 Load address: 0x300
 Loading: T #
  #
  #
  
  429.7 KiB/s
 done
 

I am not sure if this is intention with phylib but this was bring up
with phylib. I still support non-phylib version in xilinx u-boot git version
(but it is not regularly tested).

Not sure what your system.bin is but if you use FIT then you can just download
one image.

Thanks
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP - KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform




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


Re: [U-Boot] [PATCH v3 1/2] watchdog/denali: Adding DesignWare watchdog driver support

2014-02-28 Thread Michal Simek
On 02/27/2014 08:52 PM, Chin Liang See wrote:
 Hi Michal,
 
 On Mon, 2014-02-24 at 08:51 +0100, Michal Simek wrote:
 On 02/21/2014 09:57 PM, Chin Liang See wrote:
 To add the DesignWare watchdog driver support. It required
 information such as register base address and clock info from
 configuration header file  within include/configs folder.

 Signed-off-by: Chin Liang See cl...@altera.com
 Cc: Anatolij Gustschin ag...@denx.de
 Cc: Albert Aribaud albert.u.b...@aribaud.net
 Cc: Heiko Schocher h...@denx.de
 Cc: Tom Rini tr...@ti.com
 ---
 Changes for v3
 - Split to 2 series patch
 Changes for v2
 - Enable this driver at socfpga_cyclone5 board
 ---
  drivers/watchdog/Makefile |1 +
  drivers/watchdog/designware_wdt.c |   73 
 +
  2 files changed, 74 insertions(+)
  create mode 100644 drivers/watchdog/designware_wdt.c


 Checkpatch.
 total: 0 errors, 1 warnings, 1 checks, 77 lines checked
 
 Fixed
 


 diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
 index 06ced10..0276a10 100644
 --- a/drivers/watchdog/Makefile
 +++ b/drivers/watchdog/Makefile
 @@ -15,3 +15,4 @@ obj-$(CONFIG_S5P)   += s5p_wdt.o
  obj-$(CONFIG_XILINX_TB_WATCHDOG) += xilinx_tb_wdt.o
  obj-$(CONFIG_BFIN_WATCHDOG)  += bfin_wdt.o
  obj-$(CONFIG_OMAP_WATCHDOG) += omap_wdt.o
 +obj-$(CONFIG_DESIGNWARE_WATCHDOG) += designware_wdt.o
 diff --git a/drivers/watchdog/designware_wdt.c 
 b/drivers/watchdog/designware_wdt.c
 new file mode 100644
 index 000..cb88844
 --- /dev/null
 +++ b/drivers/watchdog/designware_wdt.c
 @@ -0,0 +1,73 @@
 +/*
 + * Copyright (C) 2013 Altera Corporation www.altera.com

 2014?
 
 Oops, good catch. Fixed
 


 + *
 + * SPDX-License-Identifier:GPL-2.0+
 + */
 +
 +#include common.h
 +#include watchdog.h
 +#include asm/io.h
 +#include asm/utils.h
 +
 +#define DW_WDT_CR  0x00
 +#define DW_WDT_TORR0x04
 +#define DW_WDT_CRR 0x0C
 +
 +#define DW_WDT_CR_EN_OFFSET0x00
 +#define DW_WDT_CR_RMOD_OFFSET  0x01
 +#define DW_WDT_CR_RMOD_VAL 0x00
 +#define DW_WDT_CRR_RESTART_VAL 0x76
 +
 +/*
 + * Set the watchdog time interval.
 + * Counter is 32 bit.
 + */
 +int designware_wdt_settimeout(unsigned int timeout)
 +{
 +   signed int i;

 you should separate variables from code.
 
 Actually I am trying to avoid to create a new header as its just few
 simple defines.

don't get you. I just thought to add one more blank line below this
line.

Thanks,
Michal



-- 
Michal Simek, Ing. (M.Eng), OpenPGP - KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform




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


Re: [U-Boot] [PATCH v4 1/2] watchdog/denali: Adding DesignWare watchdog driver support

2014-02-28 Thread Michal Simek
On 02/27/2014 08:53 PM, Chin Liang See wrote:
 To add the DesignWare watchdog driver support. It required
 information such as register base address and clock info from
 configuration header file  within include/configs folder.
 
 Signed-off-by: Chin Liang See cl...@altera.com
 Cc: Anatolij Gustschin ag...@denx.de
 Cc: Albert Aribaud albert.u.b...@aribaud.net
 Cc: Heiko Schocher h...@denx.de
 Cc: Tom Rini tr...@ti.com
 ---
 Changes for v4
 - Add 2014 to license header
 Changes for v3
 - Split to 2 series patch
 Changes for v2
 - Enable this driver at socfpga_cyclone5 board
 ---
  drivers/watchdog/Makefile |1 +
  drivers/watchdog/designware_wdt.c |   73 
 +
  2 files changed, 74 insertions(+)
  create mode 100644 drivers/watchdog/designware_wdt.c
 
 diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
 index 06ced10..0276a10 100644
 --- a/drivers/watchdog/Makefile
 +++ b/drivers/watchdog/Makefile
 @@ -15,3 +15,4 @@ obj-$(CONFIG_S5P)   += s5p_wdt.o
  obj-$(CONFIG_XILINX_TB_WATCHDOG) += xilinx_tb_wdt.o
  obj-$(CONFIG_BFIN_WATCHDOG)  += bfin_wdt.o
  obj-$(CONFIG_OMAP_WATCHDOG) += omap_wdt.o
 +obj-$(CONFIG_DESIGNWARE_WATCHDOG) += designware_wdt.o
 diff --git a/drivers/watchdog/designware_wdt.c 
 b/drivers/watchdog/designware_wdt.c
 new file mode 100644
 index 000..6abee81
 --- /dev/null
 +++ b/drivers/watchdog/designware_wdt.c
 @@ -0,0 +1,73 @@
 +/*
 + * Copyright (C) 2013-2014 Altera Corporation www.altera.com
 + *
 + * SPDX-License-Identifier:  GPL-2.0+
 + */
 +
 +#include common.h
 +#include watchdog.h
 +#include asm/io.h
 +#include asm/utils.h
 +
 +#define DW_WDT_CR0x00
 +#define DW_WDT_TORR  0x04
 +#define DW_WDT_CRR   0x0C
 +
 +#define DW_WDT_CR_EN_OFFSET  0x00
 +#define DW_WDT_CR_RMOD_OFFSET0x01
 +#define DW_WDT_CR_RMOD_VAL   0x00
 +#define DW_WDT_CRR_RESTART_VAL   0x76
 +
 +/*
 + * Set the watchdog time interval.
 + * Counter is 32 bit.
 + */
 +int designware_wdt_settimeout(unsigned int timeout)
 +{
 + signed int i;
 + /* calculate the timeout range value */
 + i = (log_2_n_round_up(timeout * CONFIG_DW_WDT_CLOCK_KHZ)) - 16;
 + if (i  15)
 + i = 15;
 + if (i  0)
 + i = 0;
 +
 + writel((i | (i4)), (CONFIG_DW_WDT_BASE + DW_WDT_TORR));

i  4


 + return 0;
 +}
 +
 +void designware_wdt_enable(void)
 +{
 + writel(((DW_WDT_CR_RMOD_VAL  DW_WDT_CR_RMOD_OFFSET) |
 +(0x1  DW_WDT_CR_EN_OFFSET)),
 +(CONFIG_DW_WDT_BASE + DW_WDT_CR));
 +}
 +
 +unsigned int designware_wdt_is_enabled(void)
 +{
 + unsigned long val;
 + val = readl((CONFIG_DW_WDT_BASE + DW_WDT_CR));
 + return val  0x1;
 +}

all 3 functions above I believe should be static because
you use them just here.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP - KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform




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


Re: [U-Boot] [PATCH v3 2/2] socfpga: Adding DesignWare watchdog support

2014-02-28 Thread Michal Simek
On 02/27/2014 08:55 PM, Chin Liang See wrote:
 Hi Michal,
 
 On Mon, 2014-02-24 at 08:52 +0100, Michal Simek wrote:
 On 02/21/2014 09:57 PM, Chin Liang See wrote:
 To enable the DesignWare watchdog support at SOCFPGA Cyclone V
 dev kit.

 Signed-off-by: Chin Liang See cl...@altera.com
 Cc: Anatolij Gustschin ag...@denx.de
 Cc: Albert Aribaud albert.u.b...@aribaud.net
 Cc: Heiko Schocher h...@denx.de
 Cc: Tom Rini tr...@ti.com
 ---
 Changes for v3
 - Split to 2 series patch
 Changes for v2
 - Enable this driver at socfpga_cyclone5 board
 ---
  .../include/asm/arch-socfpga/socfpga_base_addrs.h  |1 +
  include/configs/socfpga_cyclone5.h |   13 +
  2 files changed, 14 insertions(+)

 diff --git a/arch/arm/include/asm/arch-socfpga/socfpga_base_addrs.h 
 b/arch/arm/include/asm/arch-socfpga/socfpga_base_addrs.h
 index 20f12e0..5f73824 100644
 --- a/arch/arm/include/asm/arch-socfpga/socfpga_base_addrs.h
 +++ b/arch/arm/include/asm/arch-socfpga/socfpga_base_addrs.h
 @@ -11,6 +11,7 @@
  #define SOCFPGA_UART0_ADDRESS 0xffc02000
  #define SOCFPGA_UART1_ADDRESS 0xffc03000
  #define SOCFPGA_OSC1TIMER0_ADDRESS 0xffd0
 +#define SOCFPGA_L4WD0_ADDRESS 0xffd02000
  #define SOCFPGA_CLKMGR_ADDRESS 0xffd04000
  #define SOCFPGA_RSTMGR_ADDRESS 0xffd05000
  #define SOCFPGA_SYSMGR_ADDRESS 0xffd08000
 diff --git a/include/configs/socfpga_cyclone5.h 
 b/include/configs/socfpga_cyclone5.h
 index fc921ee..1b78ccb 100644
 --- a/include/configs/socfpga_cyclone5.h
 +++ b/include/configs/socfpga_cyclone5.h
 @@ -207,6 +207,16 @@
  #define CONFIG_ENV_IS_NOWHERE
  
  /*
 + * L4 Watchdog
 + */

 Why multiline comment here?
 
 Oh its just for easy reading.
 

 +#define CONFIG_HW_WATCHDOG
 +#define CONFIG_HW_WATCHDOG_TIMEOUT_MS  2000
 +#define CONFIG_DESIGNWARE_WATCHDOG
 +#define CONFIG_DW_WDT_BASE SOCFPGA_L4WD0_ADDRESS

 Why not just use SOCFPGA_L4WD0_ADDRESS directly?
 
 Nope, cause this driver might be used by other platform.

ok It means that SOCFPGA_L4WD0_ADDRESS is system controller right?

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP - KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform




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


Re: [U-Boot] [PATCH v2 1/2] nand/denali: Adding Denali NAND driver support

2014-02-28 Thread Michal Simek
 +/* lld_nand.h */
 +/*
 + * NAND Flash Controller Device Driver
 + * Copyright (c) 2009, Intel Corporation and its suppliers.
 + *
 + * This program is free software; you can redistribute it and/or modify it
 + * under the terms and conditions of the GNU General Public License,
 + * version 2, as published by the Free Software Foundation.
 + *
 + * This program is distributed in the hope it will be useful, but WITHOUT
 + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License 
 for
 + * more details.
 + *
 + * You should have received a copy of the GNU General Public License along 
 with
 + * this program; if not, write to the Free Software Foundation, Inc.,
 + * 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.


 Isn't this pretty weird if we are using SPDX?
 
 I believe the Linux driver owner wish to maintain this header when
 he/she copy into NAND driver. Anyhow, the SPDX license already stated at
 top of the header file.

1. Using address in license is just wrong and it should be removed
because they can move to different location.

2. u-boot adopted SPDX and all these fragments were removed.

Wolfgang/Tom: IMHO this should be also changed/fixed.

Thanks,
Michal


-- 
Michal Simek, Ing. (M.Eng), OpenPGP - KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform




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


[U-Boot] [PATCH] board: gaisler: delete unnecessary include path

2014-02-28 Thread Masahiro Yamada
The same outputs are generated with or without -I$(TOPDIR)/board.
I cannot understand why it is necessary. Remove.

Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
Cc: Daniel Hellstrom dan...@gaisler.com
---
 board/gaisler/gr_cpci_ax2000/config.mk | 2 --
 board/gaisler/gr_ep2s60/config.mk  | 2 --
 board/gaisler/gr_xc3s_1500/config.mk   | 2 --
 board/gaisler/grsim/config.mk  | 2 --
 board/gaisler/grsim_leon2/config.mk| 2 --
 5 files changed, 10 deletions(-)

diff --git a/board/gaisler/gr_cpci_ax2000/config.mk 
b/board/gaisler/gr_cpci_ax2000/config.mk
index 309c879..731a539 100644
--- a/board/gaisler/gr_cpci_ax2000/config.mk
+++ b/board/gaisler/gr_cpci_ax2000/config.mk
@@ -17,5 +17,3 @@ CONFIG_SYS_TEXT_BASE = 0x
 
 # U-BOOT IN SDRAM
 #CONFIG_SYS_TEXT_BASE = 0x6000
-
-PLATFORM_CPPFLAGS += -I$(TOPDIR)/board
diff --git a/board/gaisler/gr_ep2s60/config.mk 
b/board/gaisler/gr_ep2s60/config.mk
index d57efae..6e01f07 100644
--- a/board/gaisler/gr_ep2s60/config.mk
+++ b/board/gaisler/gr_ep2s60/config.mk
@@ -15,5 +15,3 @@ CONFIG_SYS_TEXT_BASE = 0x
 
 # U-BOOT IN SDRAM
 #CONFIG_SYS_TEXT_BASE = 0x4000
-
-PLATFORM_CPPFLAGS += -I$(TOPDIR)/board
diff --git a/board/gaisler/gr_xc3s_1500/config.mk 
b/board/gaisler/gr_xc3s_1500/config.mk
index e87320b..e4a66cb 100644
--- a/board/gaisler/gr_xc3s_1500/config.mk
+++ b/board/gaisler/gr_xc3s_1500/config.mk
@@ -14,5 +14,3 @@ CONFIG_SYS_TEXT_BASE = 0x
 
 # U-BOOT IN RAM
 #CONFIG_SYS_TEXT_BASE = 0x4000
-
-PLATFORM_CPPFLAGS += -I$(TOPDIR)/board
diff --git a/board/gaisler/grsim/config.mk b/board/gaisler/grsim/config.mk
index df26f82..d1f61da 100644
--- a/board/gaisler/grsim/config.mk
+++ b/board/gaisler/grsim/config.mk
@@ -14,5 +14,3 @@ CONFIG_SYS_TEXT_BASE = 0x
 
 # U-BOOT IN RAM
 #CONFIG_SYS_TEXT_BASE = 0x4000
-
-PLATFORM_CPPFLAGS += -I$(TOPDIR)/board
diff --git a/board/gaisler/grsim_leon2/config.mk 
b/board/gaisler/grsim_leon2/config.mk
index 99f9a68..f98b23b 100644
--- a/board/gaisler/grsim_leon2/config.mk
+++ b/board/gaisler/grsim_leon2/config.mk
@@ -14,5 +14,3 @@ CONFIG_SYS_TEXT_BASE = 0x
 
 # RUN U-BOOT FROM RAM
 #CONFIG_SYS_TEXT_BASE = 0x4000
-
-PLATFORM_CPPFLAGS += -I$(TOPDIR)/board
-- 
1.8.3.2

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


[U-Boot] Writing to SD partitions from u-boot

2014-02-28 Thread David Cemin
Hi,

I am trying to use u-boot to replace kernel and filesystem in the SD card.
 I have this set of partitions:

SOCFPGA_CYCLONE5 # mmc part

Partition Map for MMC device 0  --   Partition Type: DOS

PartStart SectorNum Sectors UUIDType
  1 2121728 101 -01 0b
  2 14336   2097153 -02 83
  3 20482049-03 a2


First partition is used to store kernel and dtb files. Second, to store
filesystem and the third stores preloader and u-boot.

Currently, i boot the board by calling mmcload and mmcboot.

mmcboot=setenv bootargs console=ttyS0,57600 root=${mmcroot} rw
rootwait;bootz ${loadaddr} - ${fdtaddr}
mmcload=mmc rescan;${mmcloadcmd} mmc 0:${mmcloadpart} ${loadaddr}
${bootimage};${mmcloadcmd} mmc 0:${mmcloadpart} ${fdtaddr} ${fdtimage}
mmcloadcmd=fatload
mmcloadpart=1
mmcroot=/dev/mmcblk0p2

mmcload script loads kernel and dtb from sdcard to memory and mmcboot boots
using this values and setting root do the second partition of the sdcard.


My first idea would be:

1) tftp rootfs to memory and rewrite the partition 2 from my card.
2) tftp kernel and dtb files and boot from there.

The item 2) can be achieved by calling the script getkernel below:
getkernel=setenv bootargs console=ttyS0,57600 root=${mmcroot} rw
rootwait;tftp ${loadaddr} ${bootimage}; tftp ${fdtaddr} ${fdtimage}; bootz
${loadaddr} - ${fdtaddr}


I am having troubles with the first step though.

First I downloaded the rootfs.img to an address that its not in use
($fpgadata = 0x20 and $fsimage=rootfs.dtb) :
tftp ${fpgadata} ${fsimage}

My second partition is fomated as ext3 (type 83), but u-boot doesnt have
commands to write to ext partitions. I tried using fatwrite, but it didnt
work, and my first guess is that fatwrite is used to write to partitions
using fat.

 fatwrite mmc 0:2 ${fpgadata} rootfs.img 52428800

** Unable to use mmc 0:2 for fatwrite **

So another option would be using mmc write, but i cant change the partition
from it so that i can write. mmc write has the following syntax:
mmc write addr blk# cnt

So it will write in the current mmc partition the content of the address
addr with size indexed by blk# and cnt.

SOCFPGA_CYCLONE5 # mmc dev 0 2
Card doesn't support part_switch


So i dont know what actually would be easier to do. I could:

1) Change partition 2 to ubifs, and hope that the ubi utilities have
read/write functions implemented;
2) Write the functions in c to write to ext filesystems and export that to
use in the macros on boot prompt

So does anyone have any idea ? It can be another approach or even some
thoughts in what I am trying to do. That would be very helpful !

Thank you.

-- 
David Cemin
+49 0152-3670-8342
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH] cosmetic: boards.cfg: mark dead email addresses

2014-02-28 Thread Masahiro Yamada
When I Cced board maintainers, some of them resulted
in bounce mails.
I'd say at least 8 addresses (listed as Cc: below)
are dead.

After discussing with Detlev, I agreed to just mark
them as dead address and keep them.
Deleting the e-mail means loosing important information.

Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
Cc: Yuli Barcohen y...@arabellasw.com
Cc: Travis Sawyer travis.saw...@sandburst.com
Cc: Yusdi Santoso yusdi_sant...@adaptec.com
Cc: David Updegraff d...@cray.com
Cc: Sangmoon Kim dog...@etinsys.com
Cc: Anton Vorontsov avoront...@ru.mvista.com
Cc: Blackfin Team u-boot-de...@blackfin.uclinux.org
Cc: Bluetechnix Tinyboards bluetech...@blackfin.uclinux.org
---

Detlev suggested to keep the email addresses even though
they are dead.

See this thread:
http://u-boot.10912.n7.nabble.com/A-list-of-dead-email-addresses-of-board-maintainers-td171476.html


 boards.cfg | 110 ++---
 1 file changed, 55 insertions(+), 55 deletions(-)

diff --git a/boards.cfg b/boards.cfg
index d28e09b..b0e7f3f 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -415,40 +415,40 @@ Active  avr32   at32ap at32ap700x  in-circuit 
 -
 Active  avr32   at32ap at32ap700x  mimc-   
mimc200  -  

   Mark Jackson m...@mimc.co.uk
 Active  avr32   at32ap at32ap700x  miromico-   
hammerhead   -  

   Julien May julien@miromico.ch:Alex Raimondi 
alex.raimo...@miromico.ch
 Active  blackfinblackfin   -   -   -   
bct-brettl2  -  

   Peter Meerwald de...@bct-electronic.com
-Active  blackfinblackfin   -   -   -   
bf506f-ezkit -  

   Sonic Zhang sonic@gmail.com:Blackfin Team 
u-boot-de...@blackfin.uclinux.org
-Active  blackfinblackfin   -   -   -   
bf518f-ezbrd -  

   Sonic Zhang sonic@gmail.com:Blackfin Team 
u-boot-de...@blackfin.uclinux.org
+Active  blackfinblackfin   -   -   -   
bf506f-ezkit -  

   Sonic Zhang sonic@gmail.com:Blackfin Team (dead 
address)u-boot-de...@blackfin.uclinux.org
+Active  blackfinblackfin   -   -   -   
bf518f-ezbrd -  

   Sonic Zhang sonic@gmail.com:Blackfin Team (dead 
address)u-boot-de...@blackfin.uclinux.org
 Active  blackfinblackfin   -   -   -   
bf525-ucr2   -  

   Haitao Zhang hzh...@ucrobotics.com:Chong Huang 
chu...@ucrobotics.com
-Active  blackfinblackfin   -   -   -   
bf526-ezbrd  -  

   Sonic Zhang sonic@gmail.com:Blackfin Team 
u-boot-de...@blackfin.uclinux.org
-Active  blackfinblackfin   -   -   -   
bf527-ad7160-eval-  

   Sonic Zhang sonic@gmail.com:Blackfin Team 
u-boot-de...@blackfin.uclinux.org
-Active  blackfinblackfin   -   -   -   
bf527-ezkit  -  

   Sonic Zhang sonic@gmail.com:Blackfin Team 
u-boot-de...@blackfin.uclinux.org
-Active  blackfinblackfin   -   -   -   
bf527-sdp-  
  

[U-Boot] [PATCH] board: .gitignore: ignore board-specific generated files

2014-02-28 Thread Masahiro Yamada
Ignore
  - board/cray/L1/bootscript.{c|image}
  - board/matrix_vision/mvblm7/bootscript.img
  - board/maxtir_vision/mvsmr/bootscript.img

Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
Cc: Andre Schwarz andre.schw...@matrix-vision.de
---
 board/cray/L1/.gitignore  | 2 ++
 board/matrix_vision/mvblm7/.gitignore | 1 +
 board/matrix_vision/mvsmr/.gitignore  | 1 +
 3 files changed, 4 insertions(+)
 create mode 100644 board/cray/L1/.gitignore
 create mode 100644 board/matrix_vision/mvblm7/.gitignore
 create mode 100644 board/matrix_vision/mvsmr/.gitignore

diff --git a/board/cray/L1/.gitignore b/board/cray/L1/.gitignore
new file mode 100644
index 000..cd76d66
--- /dev/null
+++ b/board/cray/L1/.gitignore
@@ -0,0 +1,2 @@
+bootscript.c
+bootscript.image
diff --git a/board/matrix_vision/mvblm7/.gitignore 
b/board/matrix_vision/mvblm7/.gitignore
new file mode 100644
index 000..469f1bc
--- /dev/null
+++ b/board/matrix_vision/mvblm7/.gitignore
@@ -0,0 +1 @@
+bootscript.img
diff --git a/board/matrix_vision/mvsmr/.gitignore 
b/board/matrix_vision/mvsmr/.gitignore
new file mode 100644
index 000..469f1bc
--- /dev/null
+++ b/board/matrix_vision/mvsmr/.gitignore
@@ -0,0 +1 @@
+bootscript.img
-- 
1.8.3.2

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


Re: [U-Boot] U-Boot: could not cross-compile u-boot tools

2014-02-28 Thread Wolfgang Denk
Dear Heiko  Masahiro,

In message 53105765.3010...@denx.de you wrote:
 
  Usage:
  Build tools for host
make  CROSS_COMPILE=your_gcc_prefix  tools
  Build tools for target
make CROSS_BUILD_TOOLS=1  CROSS_COMPILE=your_gcc_prefix  tools
 
 Yep, works, great!

I'm not really hapy with the additional CROSS_BUILD_TOOLS paramert -
but this may be a matter of taste, so the following is just a thought
and a question:

Would it make more sense to provide a sparate make target instead?

Say, something like this:

Build tools for host
make  CROSS_COMPILE=your_gcc_prefix tools
Build tools for target
make  CROSS_COMPILE=your_gcc_prefix cross_tools

?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Comparing information  and  knowledge  is  like  asking  whether  the
fatness  of  a  pig  is more or less green than the designated hitter
rule.   - David Guaspari
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH] board: config.mk: delete unused sinclude directive

2014-02-28 Thread Masahiro Yamada
config.tmp is not there.

Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---
 board/freescale/m54418twr/config.mk | 2 --
 board/micronas/vct/config.mk| 2 --
 2 files changed, 4 deletions(-)

diff --git a/board/freescale/m54418twr/config.mk 
b/board/freescale/m54418twr/config.mk
index b306d03..07f52e0 100644
--- a/board/freescale/m54418twr/config.mk
+++ b/board/freescale/m54418twr/config.mk
@@ -4,6 +4,4 @@
 # SPDX-License-Identifier: GPL-2.0+
 #
 
-sinclude $(OBJTREE)/board/$(BOARDDIR)/config.tmp
-
 PLATFORM_CPPFLAGS += -DTEXT_BASE=$(CONFIG_SYS_TEXT_BASE)
diff --git a/board/micronas/vct/config.mk b/board/micronas/vct/config.mk
index 0f004e0..354d918 100644
--- a/board/micronas/vct/config.mk
+++ b/board/micronas/vct/config.mk
@@ -8,8 +8,6 @@
 # vct_xxx boards with MIPS 4Kc CPU core
 #
 
-sinclude $(TOPDIR)/board/$(BOARDDIR)/config.tmp
-
 ifndef CONFIG_SYS_TEXT_BASE
 CONFIG_SYS_TEXT_BASE = 0x8700
 endif
-- 
1.8.3.2

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


[U-Boot] [PATCH 1/2 v2] mpc85xx: Add support for the supplement configuration unit register

2014-02-28 Thread Yuantian.Tang
From: Tang Yuantian yuantian.t...@freescale.com

The supplement configuration unit (SCFG) provides chip-specific
configuration and status registers for the device. It is the chip
defined module for extending the device configuration unit (DCFG)
module. It provides a set of CCSR registers in addition to those
available in the device configuration unit.
The base address for this unit is 0x0F_C000.

Signed-off-by: Tang Yuantian yuantian.t...@freescale.com
---
v2:
- no change

 arch/powerpc/include/asm/immap_85xx.h | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/arch/powerpc/include/asm/immap_85xx.h 
b/arch/powerpc/include/asm/immap_85xx.h
index 9d08321..ad2532a 100644
--- a/arch/powerpc/include/asm/immap_85xx.h
+++ b/arch/powerpc/include/asm/immap_85xx.h
@@ -3124,4 +3124,26 @@ struct dcsr_dcfg_regs {
 #defineDCSR_DCFG_ECC_DISABLE_USB2  0x4000
u8  res_524[0x1000 - 0x524]; /* 0x524 - 0x1000 */
 };
+
+#define CONFIG_SYS_MPC85xx_SCFG \
+   (CONFIG_SYS_IMMR + CONFIG_SYS_MPC85xx_SCFG_OFFSET)
+#define CONFIG_SYS_MPC85xx_SCFG_OFFSET 0xfc000
+/* The supplement configuration unit register */
+struct ccsr_scfg {
+   u32 dpslpcr;/* 0x000 Deep Sleep Control register */
+   u32 usb1dpslpcsr;   /* 0x004 USB1 Deep Sleep Control Status 
register */
+   u32 usb2dpslpcsr;   /* 0x008 USB2 Deep Sleep Control Status 
register */
+   u32 fmclkdpslpcr;   /* 0x00c FM Clock Deep Sleep Control register */
+   u32 res1[4];
+   u32 esgmiiselcr;/* 0x020 Ethernet Switch SGMII Select Control 
register */
+   u32 res2;
+   u32 pixclkcr;   /* 0x028 Pixel Clock Control register */
+   u32 res3[245];
+   u32 qeioclkcr;  /* 0x400 QUICC Engine IO Clock Control register 
*/
+   u32 emiiocr;/* 0x404 EMI MDIO Control Register */
+   u32 sdhciovselcr;   /* 0x408 SDHC IO VSEL Control register */
+   u32 qmifrstcr;  /* 0x40c QMAN Interface Reset Control register 
*/
+   u32 res4[60];
+   u32 sparecr[8]; /* 0x500 Spare Control register(0-7) */
+};
 #endif /*__IMMAP_85xx__*/
-- 
1.8.5


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


[U-Boot] [PATCH 2/2 v2] mpc85xx/t104x: Add deep sleep framework support

2014-02-28 Thread Yuantian.Tang
From: Tang Yuantian yuantian.t...@freescale.com

When T104x soc wakes up from deep sleep, control is passed to the
primary core that starts executing uboot. After re-initialized some
IP blocks, like DDRC, kernel will take responsibility to continue
to restore environment it leaves before.

Signed-off-by: Tang Yuantian yuantian.t...@freescale.com
---
v2: 
- added explaination for CONFIG_DEEP_SLEEP
- fixed some issues

 README |  4 +++
 arch/powerpc/cpu/mpc85xx/asm-offsets.c | 24 ++
 arch/powerpc/cpu/mpc85xx/cpu_init.c|  7 +
 arch/powerpc/cpu/mpc85xx/fdt.c | 25 +++
 arch/powerpc/cpu/mpc85xx/liodn.c   | 27 +++-
 arch/powerpc/cpu/mpc85xx/start.S   | 12 +++
 arch/powerpc/include/asm/global_data.h |  2 ++
 arch/powerpc/lib/board.c   | 57 +++---
 drivers/ddr/fsl/mpc85xx_ddr_gen3.c | 42 ++---
 include/fsl_ddr_sdram.h|  6 
 10 files changed, 190 insertions(+), 16 deletions(-)
 create mode 100644 arch/powerpc/cpu/mpc85xx/asm-offsets.c

diff --git a/README b/README
index ff49260..0fa646e 100644
--- a/README
+++ b/README
@@ -427,6 +427,10 @@ The following options need to be configured:
In this mode, a single differential clock is used to supply
clocks to the sysclock, ddrclock and usbclock.
 
+   CONFIG_DEEP_SLEEP
+   Inidcates this SoC supports deep sleep feature. If deep sleep is
+   supported, core will start to execute uboot when wakes up.
+
 - Generic CPU options:
CONFIG_SYS_BIG_ENDIAN, CONFIG_SYS_LITTLE_ENDIAN
 
diff --git a/arch/powerpc/cpu/mpc85xx/asm-offsets.c 
b/arch/powerpc/cpu/mpc85xx/asm-offsets.c
new file mode 100644
index 000..1e422e7
--- /dev/null
+++ b/arch/powerpc/cpu/mpc85xx/asm-offsets.c
@@ -0,0 +1,24 @@
+/*
+ * Adapted from Linux v2.6.36 kernel: arch/powerpc/kernel/asm-offsets.c
+ *
+ * This program is used to generate definitions needed by
+ * assembly language modules.
+ *
+ * We use the technique used in the OSF Mach kernel code:
+ * generate asm statements containing #defines,
+ * compile this file to assembler, and then extract the
+ * #defines from the assembly-language output.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+
+#include linux/kbuild.h
+
+int main(void)
+{
+   DEFINE(GD_FLAGS_OFF, offsetof(struct global_data, flags));
+
+   return 0;
+}
diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c 
b/arch/powerpc/cpu/mpc85xx/cpu_init.c
index b31efb7..80ffe5c 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
@@ -231,6 +231,7 @@ void cpu_init_f (void)
 #ifdef CONFIG_MPC8548
ccsr_local_ecm_t *ecm = (void *)(CONFIG_SYS_MPC85xx_ECM_ADDR);
uint svr = get_svr();
+   gd = (gd_t *)(CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_GBL_DATA_OFFSET);
 
/*
 * CPU2 errata workaround: A core hang possible while executing
@@ -282,6 +283,12 @@ void cpu_init_f (void)
in_be32(gur-dcsrcr);
 #endif
 
+#ifdef CONFIG_DEEP_SLEEP
+   /* disable the console if boot from deep sleep */
+   if (in_be32(gur-scrtsr[0])  (1  3))
+   gd-flags |= GD_FLG_SILENT |
+   GD_FLG_DEEP_SLEEP | GD_FLG_DISABLE_CONSOLE;
+#endif
 }
 
 /* Implement a dummy function for those platforms w/o SERDES */
diff --git a/arch/powerpc/cpu/mpc85xx/fdt.c b/arch/powerpc/cpu/mpc85xx/fdt.c
index 33bc900..4404b0b 100644
--- a/arch/powerpc/cpu/mpc85xx/fdt.c
+++ b/arch/powerpc/cpu/mpc85xx/fdt.c
@@ -24,6 +24,7 @@ DECLARE_GLOBAL_DATA_PTR;
 extern void ft_qe_setup(void *blob);
 extern void ft_fixup_num_cores(void *blob);
 extern void ft_srio_setup(void *blob);
+extern ulong __bss_end;
 
 #ifdef CONFIG_MP
 #include mp.h
@@ -35,6 +36,9 @@ void ft_fixup_cpu(void *blob, u64 memory_limit)
u32 bootpg = determine_mp_bootpg(NULL);
u32 id = get_my_id();
const char *enable_method;
+#ifdef CONFIG_DEEP_SLEEP
+   ulong len;
+#endif
 
off = fdt_node_offset_by_prop_value(blob, -1, device_type, cpu, 4);
while (off != -FDT_ERR_NOTFOUND) {
@@ -77,6 +81,25 @@ void ft_fixup_cpu(void *blob, u64 memory_limit)
device_type, cpu, 4);
}
 
+#ifdef CONFIG_DEEP_SLEEP
+   /*
+* reserve the memory space for deep sleep.
+* This space will be re-used next time when boot from deep sleep.
+* The space includes bd_t, gd_t, stack and uboot image.
+* Reserve 1K for stack.
+*/
+   len = sizeof(bd_t) + sizeof(gd_t) + (1  10);
+   /* round up to 4K */
+   len = (len + (4096 - 1))  ~(4096 - 1);
+
+   off = fdt_add_mem_rsv(blob, gd-relocaddr - len,
+   len + ((ulong)__bss_end - gd-relocaddr));
+   if (off  0)
+   printf(Failed to reserve memory for deep sleep: %s\n,
+  

Re: [U-Boot] Writing to SD partitions from u-boot

2014-02-28 Thread Wolfgang Denk
Dear David,

In message CADqAesiEy5dwjZ5V7qHSVSsEDiOFLzWRWRzY4xgRKdd=gri...@mail.gmail.com 
you wrote:

 First partition is used to store kernel and dtb files. Second, to store
 filesystem and the third stores preloader and u-boot.

Actually this information is mostly irrelevant.  Partitions do not
play a big role here - what matters are file systems.

 I am having troubles with the first step though.
 
 First I downloaded the rootfs.img to an address that its not in use
 ($fpgadata = 0x20 and $fsimage=rootfs.dtb) :
 tftp ${fpgadata} ${fsimage}
 
 My second partition is fomated as ext3 (type 83), but u-boot doesnt have
 commands to write to ext partitions. I tried using fatwrite, but it didnt
 work, and my first guess is that fatwrite is used to write to partitions
 using fat.

This makes no sense.  If you download a file system _image_ then you
cannot use any file system level commands to write such an image - you
must write the image directly to the storage device.  In your case,
with a MMC based storage device, that would be done using mmc write.

There are more errors in your posting:

- U-Boot does support writing to ext file system - EXT4, to be
  precise. See CONFIG_CMD_EXT4_WRITE

- fatwrite (and the other fat* commands) operate on FAT file systems;
  it does not matter of these are on partitions with FAT partition
  type.  If you like, you can also put a FAT file system on a partitin
  marked as swap space (type 82) and it will just work fine.

But as mentioned - using any file system level commands is inherently
wrong when you try to store a file system image.

 So another option would be using mmc write, but i cant change the partition
 from it so that i can write. mmc write has the following syntax:
 mmc write addr blk# cnt

s is the correct thing to do.

 So it will write in the current mmc partition the content of the address
 addr with size indexed by blk# and cnt.
 
 SOCFPGA_CYCLONE5 # mmc dev 0 2
 Card doesn't support part_switch

Well, not this is your real problem.  Fix it.

 1) Change partition 2 to ubifs, and hope that the ubi utilities have
 read/write functions implemented;

It makes no sense to use UBIFS on a MMC device.

 2) Write the functions in c to write to ext filesystems and export that to
 use in the macros on boot prompt

You do not want to write to an ext (or any other) file system - you
want to write to the raw storage device.  For MMC, this is done with
the mmc write command.  If this is not working for you (because you
cannot switch partitions), then you should fix the root cause - the
failing partition switch.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Remember that the best relationship is one in  which  your  love  for
each other exceeds your need for each other. - Dalai Lama
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] net: asix: don't pad odd-length TX packets

2014-02-28 Thread Marek Vasut
On Thursday, February 27, 2014 at 09:38:48 PM, Simon Glass wrote:
 Hi Stephen,
 
 On 27 February 2014 13:27, Stephen Warren swar...@wwwdotorg.org wrote:
  From: Stephen Warren swar...@nvidia.com
  
  For Ethernet/USB RX packets, the ASIX HW pads odd-sized packets so that
  they have an even size. Currently, asix_recv() does remove this padding,
  and asic_send() adds equivalent padding in the TX path. However, the HW
  does not appear to need this packing for TX packets in practical testing
  with ASIX Elec. Corp. AX88x72A 01 Vendor: 0x0b95 Product 0x7720
  Version 0.1. The Linux kernel does no such padding for the TX path.
  
  Remove the padding from the TX path:
  
  * For consistency with the Linux kernel.
  * NVIDIA has a Tegra simulator which validates that the length of USB
  
packets sent to an ASIX device matches the packet length value inside
the packet data. Having U-Boot and the kernel do the same thing when
creating the TX packets simplifies the simulator's validation.
  
  Cc: Lucas Stach d...@lynxeye.de
  Cc: Marek Vasut ma...@denx.de
  Cc: Simon Glass s...@chromium.org
  Signed-off-by: Stephen Warren swar...@nvidia.com
 
 My notes indicate I added this due to a problem I had at the time with
 bootp. However, since you have tested it, perhaps the root cause was
 somewhere else.
 
 Acked-by: Simon Glass s...@chromium.org

Tested on two different ASIX dongles:

0x2001:0x3c05 ; DUB-E100 ; D-Link Corporation
0x0b95:0x7720 ; ZoWii ; Zoltan Tech

Acked-by: Marek Vasut ma...@denx.de
Tested-by: Marek Vasut ma...@denx.de

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 v2 1/2] nand/denali: Adding Denali NAND driver support

2014-02-28 Thread Masahiro Yamada
Hello Chin,


Where do you set nand-ecc.strength?
   
   I believe this is only applicable for NAND_ECC_HW_SYNDROME mode. We are
   using the NAND_ECC_HW (without the syndrome). Wonder you hit error
   during run?
  
  No, it must always be set for hardware ECC.  Note the lack of a break;
  before case NAND_ECC_HW_SYNDROME.
 
 Good catch, thanks Scott!

ecc.strengh must be set for NAND_ECC_HW.

Otherwise, error message will be displayed and reboot.

   NAND:  NAND:  Denali NAND controller
   BUG: failure at drivers/mtd/nand/nand_base.c:3224/nand_scan_tail()!
   BUG!
   resetting ...

You said this driver was tested against 3 different devices.

In that case, I can't understand how your board passed
through nand_scan_tail().

Anyway, I modifed denali_nand_init() locally
to set nand-ecc.strength.



 Hi Masahiro,
 
 I rechecked my documentation and the value is 8.
 The data sector size is 512 bytes while ECC sector size is 14 bytes.
 With that, the controller able to auto correct up to 8 bits.
 This is how a page will look like
 
 512 bytes data | 14 bytes ECC | 512 bytes data | 14 bytes ECC | 512
 bytes data | 14 bytes ECC | 470 bytes data | 2 byte for bad block marker
 | 42 bytes data | 14 bytes ECC | unused 
 
 FYI, my documentation is located at
 http://rocketboards.org/gitweb/?p=u-boot-socfpga.git;a=blob_plain;f=doc/README.SOCFPGA;hb=refs/heads/socfpga_v2013.01.01

For SOCFPAG, Denali controller IP is configured with
512 byte ECC sector size. OK.

I refer to Denali NAND Flash Memory Controller User's Guide.

Accoding to it, Denali's IP has 2  choice for  ECC sector size:
512 byte or 1024 byte.

Panasonic's UniPhier SoCs adopt 1024 byte ECC sector size.
(CONFIG_NAND_DENALI_ECC_SIZE = nand-ecc.size = 1024 for us.)
ECC strength (nand-ecc.strength) is selectable from 8bit/16bit/24bit.
(They correspond to  nand-ecc.bytes = 14, 28, 42, respectively)

So, In our SoC s
1024 byte data | {14 or 28 or 42 byte ECC} | 1024 byte data | 
{14 or 28 or 42 byte ECC} ...


 #ifdef CONFIG_SYS_NAND_15BIT_HW_ECC_OOBFIRST
 #define ECC_15BITS26
 static struct nand_ecclayout nand_15bit_oob = {
   .eccbytes = ECC_15BITS,
 };
 #else
 #define ECC_8BITS 14
 static struct nand_ecclayout nand_8bit_oob = {
   .eccbytes = ECC_8BITS,
 };
 #endif  /* CONFIG_SYS_NAND_15BIT_HW_ECC_OOBFIRST */

I'm afraid this part works only for 512 byte ECC sector.

Denali's document says
For 512B ECC sector size,
   ecc.bytes = Ceiling to next word (13 * ecc.strength)
For 1024B ECC sector size,
   ecc.bytes = Ceiling to next word (14 * ecc.strength)



And denali_setup_dma_sequence() function
(Why did you rename this function?)
did not work either.
I needed to fix it locally.


So bad news is this version itself does not work for me.
Good news is I could adjust it locally and confirmed some features
worked. (But I think I need more test.)

So, how will this situation work?
It turned out there are some differences between
two Denali hardwares and this driver works only for yours.

You merge it first, and (if you don't mind) shall I modify it
in a more generic way to run on both hardwares?

 If you want to run under SPL, there are some patches for that. Let me
 know if you need that. While for U-Boot, they are working fine. Probably

Thanks for your offering help.
But I am not sure if SOCFPGA and UniPhier can share a SPL nand driver.
(Actually I have locally our own Denali driver for SPL.
And I have Denali driver for main U-Boot, which is adjusted for
our SoCs, too.
But I don't mind to switch onto your driver if it works for me.)

 +#define CONFIG_SYS_NAND_USE_FLASH_BBT
 +#define CONFIG_SYS_NAND_REGS_BASESOCFPGA_NAND_REGS_ADDRESS
 +#define CONFIG_SYS_NAND_DATA_BASESOCFPGA_NAND_DATA_ADDRESS
 +#define CONFIG_SYS_NAND_BASE CONFIG_SYS_NAND_REGS_BASE

Maybe
#define CONFIG_SYS_NAND_BASE(SOCFPGA_NAND_DATA_ADDRESS + 0x10)
?


BTW, you changed all  denali-foo  to denali.foo.
It looks unnecessay to me.


Best Regards
Masahiro Yamada

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


Re: [U-Boot] U-Boot: could not cross-compile u-boot tools

2014-02-28 Thread Tom Rini
On Fri, Feb 28, 2014 at 12:12:31PM +0100, Wolfgang Denk wrote:
 Dear Heiko  Masahiro,
 
 In message 53105765.3010...@denx.de you wrote:
  
   Usage:
   Build tools for host
 make  CROSS_COMPILE=your_gcc_prefix  tools
   Build tools for target
 make CROSS_BUILD_TOOLS=1  CROSS_COMPILE=your_gcc_prefix  tools
  
  Yep, works, great!
 
 I'm not really hapy with the additional CROSS_BUILD_TOOLS paramert -
 but this may be a matter of taste, so the following is just a thought
 and a question:
 
 Would it make more sense to provide a sparate make target instead?
 
 Say, something like this:
 
   Build tools for host
   make  CROSS_COMPILE=your_gcc_prefix tools
   Build tools for target
   make  CROSS_COMPILE=your_gcc_prefix cross_tools
   
 ?

I agree, this seems more natural.

-- 
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] Ethernet persistence

2014-02-28 Thread Simon Glass
Hi Anthony,

On 27 February 2014 09:09, Anthony Mahar anthony.j.ma...@gmail.com wrote:

 How can I make the ethernet connection persistent (after first use), rather
 than reconnecting/re initializing on each reuse?

 I'm working with a Xilinx Zynq zc706 board and am up and running u-boot
 quite successfully.  My main use case is to store u-boot in on-board flash,
 and have u-boot tftp get / boot the bitstream, kernel image, devicetree,
 and
 ramdisk image.  The following script functions well:
 qspiboot=echo Configure PL and booting Linux from TFTP...   \
 fpga info 0;
  \
 tftp 0x100 system.bin;
  \
 fpga load 0 0x100 cb44bc; \
 tftp 0x300 ${kernel_image}; \
 tftp 0x2A0 ${devicetree_image}; \
 tftp 0x200 ${ramdisk_image}; \
 bootm 0x300 0x200 0x2A0\0 \


 The ethernet (Zynq's gem.e000b000) will get initialized on first use, as
 appropriate, however the Ethernet is reinitialized and auto negotiated
 again
 for each subsequent tftp request which shouldn't be necessary.  A snippet
 is
 listed below.  Each 'reconnection' takes several seconds... a few to auto
 negotiate, then a few more for the Windows based TFTP server to recognize
 the connection and allow connections to the server.  Multiply this by the
 number of transfers and it takes a very long time to transfer a very little
 amount of data.


Yes as Michal says you should use FIT and put everything in one file, or
less than 4. I'm not sure if we have a command to load your FPGA image from
FIT though. We could add one fairly easily now that we have
fit_image_load().

Also take a look at asix_init() in drivers/usb/eth, which does not re-init
the link if it is already up. This speeds things up.

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


[U-Boot] [PATCH 0/3] samsung: misc: add new lcd menu options

2014-02-28 Thread Przemyslaw Marczak
Changes:
- small code refactor
- add menu option: gpt restore
- add menu option: env default

Inha Song (1):
  samsung: misc: add env default option to lcd menu

Przemyslaw Marczak (2):
  samsung: misc: check_keys(), key_pressed() - remove type static.
  samsung: misc: add gpt restore option to lcd menu

 board/samsung/common/misc.c |   60 +--
 include/samsung/misc.h  |6 +
 2 files changed, 36 insertions(+), 30 deletions(-)

-- 
1.7.9.5

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


[U-Boot] [PATCH 2/3] samsung: misc: add gpt restore option to lcd menu

2014-02-28 Thread Przemyslaw Marczak
Function cmd_process() runs commands with directly given list
of arguments but it doesn't expand given macros. Command gpt
expects expanded macro e.g. $partitions as an argument so it
needs to be called with function run_command().

Changes:
- extend array mode_name by lower case commands names - used by find_cmd()
- put each command arguments into one string - used by run_command()
- use run_command() instead of cmd_process()

Change-Id: I2749d0b3661e2430bedd215d4024f5ae68f358db
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
cc: Minkyu Kang mk7.k...@samsung.com
---
 board/samsung/common/misc.c |   52 +--
 include/samsung/misc.h  |1 +
 2 files changed, 26 insertions(+), 27 deletions(-)

diff --git a/board/samsung/common/misc.c b/board/samsung/common/misc.c
index 1d6f4e4..c66d262 100644
--- a/board/samsung/common/misc.c
+++ b/board/samsung/common/misc.c
@@ -115,12 +115,13 @@ int check_keys(void)
  * 4 BOOT_MODE_EXIT
  */
 static char *
-mode_name[BOOT_MODE_EXIT + 1] = {
-   DEVICE,
-   THOR,
-   UMS,
-   DFU,
-   EXIT
+mode_name[BOOT_MODE_EXIT + 1][2] = {
+   {DEVICE, },
+   {THOR, thor},
+   {UMS, ums},
+   {DFU, dfu},
+   {GPT, gpt},
+   {EXIT, },
 };
 
 static char *
@@ -129,18 +130,18 @@ mode_info[BOOT_MODE_EXIT + 1] = {
downloader,
mass storage,
firmware update,
+   restore,
and run normal boot
 };
 
-#define MODE_CMD_ARGC  4
-
 static char *
-mode_cmd[BOOT_MODE_EXIT + 1][MODE_CMD_ARGC] = {
-   {, , , },
-   {thor, 0, mmc, 0},
-   {ums, 0, mmc, 0},
-   {dfu, 0, mmc, 0},
-   {, , , },
+mode_cmd[BOOT_MODE_EXIT + 1] = {
+   ,
+   thor 0 mmc 0,
+   ums 0 mmc 0,
+   dfu 0 mmc 0,
+   gpt write mmc 0 $partitions,
+   ,
 };
 
 static void display_board_info(void)
@@ -181,11 +182,10 @@ static void display_board_info(void)
 static int mode_leave_menu(int mode)
 {
char *exit_option;
-   char *exit_boot = boot;
+   char *exit_reset = reset;
char *exit_back = back;
cmd_tbl_t *cmd;
int cmd_result;
-   int cmd_repeatable;
int leave;
 
lcd_clear();
@@ -199,31 +199,29 @@ static int mode_leave_menu(int mode)
leave = 0;
break;
default:
-   cmd = find_cmd(mode_cmd[mode][0]);
+   cmd = find_cmd(mode_name[mode][1]);
if (cmd) {
-   printf(Enter: %s %s\n, mode_name[mode],
+   printf(Enter: %s %s\n, mode_name[mode][0],
 mode_info[mode]);
-   lcd_printf(\n\n\t%s %s\n, mode_name[mode],
+   lcd_printf(\n\n\t%s %s\n, mode_name[mode][0],
mode_info[mode]);
lcd_puts(\n\tDo not turn off device before finish!\n);
 
-   cmd_result = cmd_process(0, MODE_CMD_ARGC,
-*(mode_cmd + mode),
-cmd_repeatable, NULL);
+   cmd_result = run_command(mode_cmd[mode], 0);
 
if (cmd_result == CMD_RET_SUCCESS) {
printf(Command finished\n);
lcd_clear();
lcd_printf(\n\n\t%s finished\n,
-  mode_name[mode]);
+  mode_name[mode][0]);
 
-   exit_option = exit_boot;
+   exit_option = exit_reset;
leave = 1;
} else {
printf(Command error\n);
lcd_clear();
lcd_printf(\n\n\t%s command error\n,
-  mode_name[mode]);
+  mode_name[mode][0]);
 
exit_option = exit_back;
leave = 0;
@@ -263,7 +261,7 @@ static void display_download_menu(int mode)
 
for (i = 0; i = BOOT_MODE_EXIT; i++)
lcd_printf(\t%s  %s - %s\n\n, selection[i],
-   mode_name[i],
+   mode_name[i][0],
mode_info[i]);
 }
 
@@ -304,7 +302,7 @@ static void download_menu(void)
 
if (run) {
if (mode_leave_menu(mode))
-   break;
+   run_command(reset, 0);
 
display_download_menu(mode);
}
diff --git a/include/samsung/misc.h b/include/samsung/misc.h
index 47beb1f..ac0fc0b 100644
--- a/include/samsung/misc.h
+++ b/include/samsung/misc.h
@@ 

[U-Boot] [PATCH 1/3] samsung: misc: check_keys(), key_pressed() - remove type static.

2014-02-28 Thread Przemyslaw Marczak
This patch removes type static from those functions declaration.
Now it can be used outside.

Change-Id: I2244ca3568b73251401e5102f26cc113ea69c1a4
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
cc: Minkyu Kang mk7.k...@samsung.com
---
 board/samsung/common/misc.c |5 ++---
 include/samsung/misc.h  |4 
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/board/samsung/common/misc.c b/board/samsung/common/misc.c
index eb15739..1d6f4e4 100644
--- a/board/samsung/common/misc.c
+++ b/board/samsung/common/misc.c
@@ -15,7 +15,6 @@
 #include asm/arch/cpu.h
 #include asm/arch/gpio.h
 #include asm/gpio.h
-#include linux/input.h
 #include power/pmic.h
 #include mmc.h
 
@@ -72,7 +71,7 @@ static int power_key_pressed(u32 reg)
return !!(status  mask);
 }
 
-static int key_pressed(int key)
+int key_pressed(int key)
 {
int value;
 
@@ -94,7 +93,7 @@ static int key_pressed(int key)
return value;
 }
 
-static int check_keys(void)
+int check_keys(void)
 {
int keys = 0;
 
diff --git a/include/samsung/misc.h b/include/samsung/misc.h
index ede6c15..47beb1f 100644
--- a/include/samsung/misc.h
+++ b/include/samsung/misc.h
@@ -1,6 +1,8 @@
 #ifndef __SAMSUNG_MISC_COMMON_H__
 #define __SAMSUNG_MISC_COMMON_H__
 
+#include linux/input.h
+
 #ifdef CONFIG_REVISION_TAG
 u32 get_board_rev(void);
 #endif
@@ -19,6 +21,8 @@ enum {
 };
 
 void keys_init(void);
+int check_keys(void);
+int key_pressed(int key);
 void check_boot_mode(void);
 #endif /* CONFIG_LCD_MENU */
 
-- 
1.7.9.5

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


Re: [U-Boot] Writing to SD partitions from u-boot

2014-02-28 Thread David Cemin
Hi,

I figured that it supports writing to ext4 filesystems and I changed it
already. It works.

But that doesnt actually matter because what I do want to do is to write to
the raw storage device.

So, browsing the code, i found that I cant switch partitions when my SD
card has mmc-part_config = 0xff. This is the default value which is set on
the function mmc_startup, on drivers/mmc/mmc.c.

This value is set below if my sd card is a mmc and if version is = than 4.
 So, I was all the time using a SD card and not an MMC card, but i double
checked it and the statement:

if (!IS_SD(mmc)  (mmc-version = MMC_VERSION_4)) {


Wont be true, because:
 IS_SD(mmc) = 0x2 and mmc-version = 0x20020

Apparently I should use a mmc card in order to use the mmc functions, which
makes perfect sense to me :)

Do we have on u-boot flash write / flash read functions implemented, so
that I can write / read the sd card ?

Thank you.

best regards,

--
David


On Fri, Feb 28, 2014 at 12:23 PM, Wolfgang Denk w...@denx.de wrote:

 Dear David,

 In message CADqAesiEy5dwjZ5V7qHSVSsEDiOFLzWRWRzY4xgRKdd=
 gri...@mail.gmail.com you wrote:
 
  First partition is used to store kernel and dtb files. Second, to store
  filesystem and the third stores preloader and u-boot.

 Actually this information is mostly irrelevant.  Partitions do not
 play a big role here - what matters are file systems.

  I am having troubles with the first step though.
 
  First I downloaded the rootfs.img to an address that its not in use
  ($fpgadata = 0x20 and $fsimage=rootfs.dtb) :
  tftp ${fpgadata} ${fsimage}
 
  My second partition is fomated as ext3 (type 83), but u-boot doesnt have
  commands to write to ext partitions. I tried using fatwrite, but it didnt
  work, and my first guess is that fatwrite is used to write to partitions
  using fat.

 This makes no sense.  If you download a file system _image_ then you
 cannot use any file system level commands to write such an image - you
 must write the image directly to the storage device.  In your case,
 with a MMC based storage device, that would be done using mmc write.

 There are more errors in your posting:

 - U-Boot does support writing to ext file system - EXT4, to be
   precise. See CONFIG_CMD_EXT4_WRITE

 - fatwrite (and the other fat* commands) operate on FAT file systems;
   it does not matter of these are on partitions with FAT partition
   type.  If you like, you can also put a FAT file system on a partitin
   marked as swap space (type 82) and it will just work fine.

 But as mentioned - using any file system level commands is inherently
 wrong when you try to store a file system image.

  So another option would be using mmc write, but i cant change the
 partition
  from it so that i can write. mmc write has the following syntax:
  mmc write addr blk# cnt

 s is the correct thing to do.

  So it will write in the current mmc partition the content of the address
  addr with size indexed by blk# and cnt.
 
  SOCFPGA_CYCLONE5 # mmc dev 0 2
  Card doesn't support part_switch

 Well, not this is your real problem.  Fix it.

  1) Change partition 2 to ubifs, and hope that the ubi utilities have
  read/write functions implemented;

 It makes no sense to use UBIFS on a MMC device.

  2) Write the functions in c to write to ext filesystems and export that
 to
  use in the macros on boot prompt

 You do not want to write to an ext (or any other) file system - you
 want to write to the raw storage device.  For MMC, this is done with
 the mmc write command.  If this is not working for you (because you
 cannot switch partitions), then you should fix the root cause - the
 failing partition switch.

 Best regards,

 Wolfgang Denk

 --
 DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
 HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
 Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
 Remember that the best relationship is one in  which  your  love  for
 each other exceeds your need for each other. - Dalai Lama




-- 
David Cemin
+49 0152-3670-8342
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 3/3] samsung: misc: add env default option to lcd menu

2014-02-28 Thread Przemyslaw Marczak
From: Inha Song ideal.s...@samsung.com

Change-Id: Idded38acfeb63c909fa22ff1a1b1ec77b46d7515
Signed-off-by: Inha Song ideal.s...@samsung.com
Acked-by: Przemyslaw Marczak p.marc...@samsung.com
cc: Minkyu Kang mk7.k...@samsung.com
---
 board/samsung/common/misc.c |3 +++
 include/samsung/misc.h  |1 +
 2 files changed, 4 insertions(+)

diff --git a/board/samsung/common/misc.c b/board/samsung/common/misc.c
index c66d262..0c13aa1 100644
--- a/board/samsung/common/misc.c
+++ b/board/samsung/common/misc.c
@@ -121,6 +121,7 @@ mode_name[BOOT_MODE_EXIT + 1][2] = {
{UMS, ums},
{DFU, dfu},
{GPT, gpt},
+   {ENV, env},
{EXIT, },
 };
 
@@ -131,6 +132,7 @@ mode_info[BOOT_MODE_EXIT + 1] = {
mass storage,
firmware update,
restore,
+   default,
and run normal boot
 };
 
@@ -141,6 +143,7 @@ mode_cmd[BOOT_MODE_EXIT + 1] = {
ums 0 mmc 0,
dfu 0 mmc 0,
gpt write mmc 0 $partitions,
+   env default -a; saveenv,
,
 };
 
diff --git a/include/samsung/misc.h b/include/samsung/misc.h
index ac0fc0b..1fb9e38 100644
--- a/include/samsung/misc.h
+++ b/include/samsung/misc.h
@@ -18,6 +18,7 @@ enum {
BOOT_MODE_UMS,
BOOT_MODE_DFU,
BOOT_MODE_GPT,
+   BOOT_MODE_ENV,
BOOT_MODE_EXIT,
 };
 
-- 
1.7.9.5

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


Re: [U-Boot] [PATCH 0/3] samsung: misc: add new lcd menu options

2014-02-28 Thread Przemyslaw Marczak

Hello,

On 02/28/2014 03:30 PM, Przemyslaw Marczak wrote:

Changes:
- small code refactor
- add menu option: gpt restore
- add menu option: env default

Inha Song (1):
   samsung: misc: add env default option to lcd menu

Przemyslaw Marczak (2):
   samsung: misc: check_keys(), key_pressed() - remove type static.
   samsung: misc: add gpt restore option to lcd menu

  board/samsung/common/misc.c |   60 +--
  include/samsung/misc.h  |6 +
  2 files changed, 36 insertions(+), 30 deletions(-)



Sorry for the Change-Id in the commits.
It's from gerrit - I forgot remove it.

Thank you
--
Przemyslaw Marczak
Samsung RD Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] Ethernet persistence

2014-02-28 Thread Michal Simek
Hi Simon,

On 02/28/2014 03:24 PM, Simon Glass wrote:
 Hi Anthony,
 
 On 27 February 2014 09:09, Anthony Mahar anthony.j.ma...@gmail.com wrote:
 
 How can I make the ethernet connection persistent (after first use), rather
 than reconnecting/re initializing on each reuse?

 I'm working with a Xilinx Zynq zc706 board and am up and running u-boot
 quite successfully.  My main use case is to store u-boot in on-board flash,
 and have u-boot tftp get / boot the bitstream, kernel image, devicetree,
 and
 ramdisk image.  The following script functions well:
 qspiboot=echo Configure PL and booting Linux from TFTP...   \
 fpga info 0;
  \
 tftp 0x100 system.bin;
  \
 fpga load 0 0x100 cb44bc; \
 tftp 0x300 ${kernel_image}; \
 tftp 0x2A0 ${devicetree_image}; \
 tftp 0x200 ${ramdisk_image}; \
 bootm 0x300 0x200 0x2A0\0 \


 The ethernet (Zynq's gem.e000b000) will get initialized on first use, as
 appropriate, however the Ethernet is reinitialized and auto negotiated
 again
 for each subsequent tftp request which shouldn't be necessary.  A snippet
 is
 listed below.  Each 'reconnection' takes several seconds... a few to auto
 negotiate, then a few more for the Windows based TFTP server to recognize
 the connection and allow connections to the server.  Multiply this by the
 number of transfers and it takes a very long time to transfer a very little
 amount of data.

 
 Yes as Michal says you should use FIT and put everything in one file, or
 less than 4. I'm not sure if we have a command to load your FPGA image from
 FIT though. We could add one fairly easily now that we have
 fit_image_load().

I have this on my todo list and definitely I would love to extend FIT image
with adding FPGA to it.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP - KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform




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


[U-Boot] [PATCH 2/2] cmd:gpt: randomly generate each partition uuid if undefined

2014-02-28 Thread Przemyslaw Marczak
Changes:
- randomly generate each partition uuid if undefined
- print info about generated uuid
- save environment on gpt write success
- update doc/README.gpt

Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Acked-by: Lukasz Majewski l.majew...@samsung.com
cc: Piotr Wilczek p.wilc...@samsung.com
cc: Tom Rini tr...@ti.com
---
 common/cmd_gpt.c |   29 +++--
 doc/README.gpt   |1 +
 2 files changed, 24 insertions(+), 6 deletions(-)

diff --git a/common/cmd_gpt.c b/common/cmd_gpt.c
index 1f12e6d..7be5fcf 100644
--- a/common/cmd_gpt.c
+++ b/common/cmd_gpt.c
@@ -31,6 +31,7 @@
  */
 static char extract_env(const char *str, char **env)
 {
+   int ret = -1;
char *e, *s;
 
if (!str || strlen(str)  4)
@@ -43,16 +44,23 @@ static char extract_env(const char *str, char **env)
memset(s + strlen(s) - 1, '\0', 1);
memmove(s, s + 2, strlen(s) - 1);
e = getenv(s);
-   free(s);
if (e == NULL) {
-   printf(Environmental '%s' not set\n, str);
-   return -1; /* env not set */
+   printf(%s unset. , str);
+   e = get_uuid_str();
+   if (e) {
+   printf(Setting to: %s\n, e);
+   setenv(s, e);
+   ret = 0;
+   }
+   } else {
+   ret = 0;
}
+
*env = e;
-   return 0;
+   free(s);
}
 
-   return -1;
+   return ret;
 }
 
 /**
@@ -299,8 +307,17 @@ static int do_gpt(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
return CMD_RET_FAILURE;
}
 
-   if (gpt_default(blk_dev_desc, argv[4]))
+   puts(Writing GPT: );
+
+   ret = gpt_default(blk_dev_desc, argv[4]);
+   if (!ret) {
+   puts(success!\n);
+   saveenv();
+   return CMD_RET_SUCCESS;
+   } else {
+   puts(error!\n);
return CMD_RET_FAILURE;
+   }
} else {
return CMD_RET_USAGE;
}
diff --git a/doc/README.gpt b/doc/README.gpt
index 5c133f3..afe2538 100644
--- a/doc/README.gpt
+++ b/doc/README.gpt
@@ -176,3 +176,4 @@ Please, pay attention at -l switch for parted.
 uuid program is recommended to generate UUID string. Moreover it can decode
 (-d switch) passed in UUID string. It can be used to generate partitions UUID
 passed to u-boot environment variables.
+If each partition uuid no exists then it will be randomly generated.
-- 
1.7.9.5

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


[U-Boot] [PATCH 1/2] lib: uuid: add function to generate UUID version 4

2014-02-28 Thread Przemyslaw Marczak
lib/uuid.c:
Add get_uuid_str() - this function returns 36 character hexadecimal ASCII
string representation of a 128-bit (16 octets) UUID (Universally Unique
Identifier) version 4 based on RFC4122, which is randomly generated.

Source: https://www.ietf.org/rfc/rfc4122.txt

Changes:
Move functions:
- disk/part_efi.c uuid_string() to lib/uuid.c - uuid_bin_to_str()
- disk/part_efi.c string_uuid() to lib/uuid.c - uuid_str_to_bin()

Update files:
- include/common.h
- disk/part_efi.c
- lib/Makefile

Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
cc: Jason Hobbs jason.ho...@calxeda.com
cc: Stephen Warren swar...@nvidia.com
cc: Lukasz Majewski l.majew...@samsung.com
cc: tr...@ti.com
---
 disk/part_efi.c  |   90 ++
 include/common.h |7 +++-
 lib/Makefile |4 ++
 lib/uuid.c   |  114 --
 4 files changed, 131 insertions(+), 84 deletions(-)

diff --git a/disk/part_efi.c b/disk/part_efi.c
index 733d5bd..a280ab5 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -63,26 +63,6 @@ static char *print_efiname(gpt_entry *pte)
return name;
 }
 
-static void uuid_string(unsigned char *uuid, char *str)
-{
-   static const u8 le[16] = {3, 2, 1, 0, 5, 4, 7, 6, 8, 9, 10, 11,
- 12, 13, 14, 15};
-   int i;
-
-   for (i = 0; i  16; i++) {
-   sprintf(str, %02x, uuid[le[i]]);
-   str += 2;
-   switch (i) {
-   case 3:
-   case 5:
-   case 7:
-   case 9:
-   *str++ = '-';
-   break;
-   }
-   }
-}
-
 static efi_guid_t system_guid = PARTITION_SYSTEM_GUID;
 
 static inline int is_bootable(gpt_entry *p)
@@ -103,6 +83,7 @@ void print_part_efi(block_dev_desc_t * dev_desc)
gpt_entry *gpt_pte = NULL;
int i = 0;
char uuid[37];
+   unsigned char *uuid_bin;
 
if (!dev_desc) {
printf(%s: Invalid Argument(s)\n, __func__);
@@ -132,9 +113,11 @@ void print_part_efi(block_dev_desc_t * dev_desc)
le64_to_cpu(gpt_pte[i].ending_lba),
print_efiname(gpt_pte[i]));
printf(\tattrs:\t0x%016llx\n, gpt_pte[i].attributes.raw);
-   uuid_string(gpt_pte[i].partition_type_guid.b, uuid);
+   uuid_bin = (unsigned char *)gpt_pte[i].partition_type_guid.b;
+   uuid_bin_to_str(uuid_bin, uuid);
printf(\ttype:\t%s\n, uuid);
-   uuid_string(gpt_pte[i].unique_partition_guid.b, uuid);
+   uuid_bin = (unsigned char *)gpt_pte[i].unique_partition_guid.b;
+   uuid_bin_to_str(uuid_bin, uuid);
printf(\tuuid:\t%s\n, uuid);
}
 
@@ -182,7 +165,7 @@ int get_partition_info_efi(block_dev_desc_t * dev_desc, int 
part,
sprintf((char *)info-type, U-Boot);
info-bootable = is_bootable(gpt_pte[part - 1]);
 #ifdef CONFIG_PARTITION_UUIDS
-   uuid_string(gpt_pte[part - 1].unique_partition_guid.b, info-uuid);
+   uuid_bin_to_str(gpt_pte[part - 1].unique_partition_guid.b, info-uuid);
 #endif
 
debug(%s: start 0x LBAF , size 0x LBAF , name %s, __func__,
@@ -237,60 +220,6 @@ static int set_protective_mbr(block_dev_desc_t *dev_desc)
return 0;
 }
 
-/**
- * string_uuid(); Convert UUID stored as string to bytes
- *
- * @param uuid - UUID represented as string
- * @param dst - GUID buffer
- *
- * @return return 0 on successful conversion
- */
-static int string_uuid(char *uuid, u8 *dst)
-{
-   efi_guid_t guid;
-   u16 b, c, d;
-   u64 e;
-   u32 a;
-   u8 *p;
-   u8 i;
-
-   const u8 uuid_str_len = 36;
-
-   /* The UUID is written in text: */
-   /* 1914   19   24 */
-   /* ---- */
-
-   debug(%s: uuid: %s\n, __func__, uuid);
-
-   if (strlen(uuid) != uuid_str_len)
-   return -1;
-
-   for (i = 0; i  uuid_str_len; i++) {
-   if ((i == 8) || (i == 13) || (i == 18) || (i == 23)) {
-   if (uuid[i] != '-')
-   return -1;
-   } else {
-   if (!isxdigit(uuid[i]))
-   return -1;
-   }
-   }
-
-   a = (u32)simple_strtoul(uuid, NULL, 16);
-   b = (u16)simple_strtoul(uuid + 9, NULL, 16);
-   c = (u16)simple_strtoul(uuid + 14, NULL, 16);
-   d = (u16)simple_strtoul(uuid + 19, NULL, 16);
-   e = (u64)simple_strtoull(uuid + 24, NULL, 16);
-
-   p = (u8 *) e;
-   guid = EFI_GUID(a, b, c, d  8, d  0xFF,
-   *(p + 5), *(p + 4), *(p + 3),
-   *(p + 2), *(p + 1) , *p);
-
-   memcpy(dst, guid.b, sizeof(efi_guid_t));
-
-   return 0;
-}
-
 int write_gpt_table(block_dev_desc_t *dev_desc,
gpt_header *gpt_h, gpt_entry *gpt_e)
 {
@@ 

[U-Boot] [PATCH 3/3] trats/trats2: enable exynos security subsystem and function hw_rand()

2014-02-28 Thread Przemyslaw Marczak
This allows to use exynos random number generator.

Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Acked-by: Lukasz Majewski l.majew...@samsung.com
cc: Piotr Wilczek p.wilc...@samsung.com
cc: Minkyu Kang mk7.k...@samsung.com
---
 include/configs/trats.h  |4 
 include/configs/trats2.h |4 
 2 files changed, 8 insertions(+)

diff --git a/include/configs/trats.h b/include/configs/trats.h
index 718107a..2bf4172 100644
--- a/include/configs/trats.h
+++ b/include/configs/trats.h
@@ -313,6 +313,10 @@
 #define CONFIG_USB_GADGET_VBUS_DRAW2
 #define CONFIG_USB_CABLE_CHECK
 
+/* Security subsystem - enable hw_rand() */
+#define CONFIG_EXYNOS_ACE_SHA
+#define CONFIG_RAND_HW_ACCEL
+
 /* Common misc for Samsung */
 #define CONFIG_MISC_COMMON
 
diff --git a/include/configs/trats2.h b/include/configs/trats2.h
index e30c428..4163fcd 100644
--- a/include/configs/trats2.h
+++ b/include/configs/trats2.h
@@ -324,6 +324,10 @@ int get_soft_i2c_sda_pin(void);
 #define CONFIG_USB_GADGET_VBUS_DRAW2
 #define CONFIG_USB_CABLE_CHECK
 
+/* Security subsystem - enable hw_rand() */
+#define CONFIG_EXYNOS_ACE_SHA
+#define CONFIG_RAND_HW_ACCEL
+
 /* Common misc for Samsung */
 #define CONFIG_MISC_COMMON
 
-- 
1.7.9.5

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


[U-Boot] [PATCH 1/3] cpu: exynos4: ace_sha: add hardware random number generator support.

2014-02-28 Thread Przemyslaw Marczak
This patch adds implementation of function hw_rand() based on exynos
security sub system.

Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
cc: Akshay Saraswat aksha...@samsung.com
cc: ARUN MANKUZHI aru...@samsung.com
cc: Minkyu Kang mk7.k...@samsung.com
---
 arch/arm/include/asm/arch-exynos/cpu.h |4 ++--
 drivers/crypto/ace_sha.c   |   41 
 drivers/crypto/ace_sha.h   |8 ---
 3 files changed, 48 insertions(+), 5 deletions(-)

diff --git a/arch/arm/include/asm/arch-exynos/cpu.h 
b/arch/arm/include/asm/arch-exynos/cpu.h
index bccce63..a5c280d 100644
--- a/arch/arm/include/asm/arch-exynos/cpu.h
+++ b/arch/arm/include/asm/arch-exynos/cpu.h
@@ -48,7 +48,7 @@
 #define EXYNOS4_GPIO_PART4_BASEDEVICE_NOT_AVAILABLE
 #define EXYNOS4_DP_BASEDEVICE_NOT_AVAILABLE
 #define EXYNOS4_SPI_ISP_BASE   DEVICE_NOT_AVAILABLE
-#define EXYNOS4_ACE_SFR_BASE   DEVICE_NOT_AVAILABLE
+#define EXYNOS4_ACE_SFR_BASE   0x1083
 #define EXYNOS4_DMC_PHY_BASE   DEVICE_NOT_AVAILABLE
 #define EXYNOS4_AUDIOSS_BASE   DEVICE_NOT_AVAILABLE
 #define EXYNOS4_USB_HOST_XHCI_BASE DEVICE_NOT_AVAILABLE
@@ -87,7 +87,7 @@
 #define EXYNOS4X12_I2S_BASEDEVICE_NOT_AVAILABLE
 #define EXYNOS4X12_SPI_BASEDEVICE_NOT_AVAILABLE
 #define EXYNOS4X12_SPI_ISP_BASEDEVICE_NOT_AVAILABLE
-#define EXYNOS4X12_ACE_SFR_BASEDEVICE_NOT_AVAILABLE
+#define EXYNOS4X12_ACE_SFR_BASE0x1083
 #define EXYNOS4X12_DMC_PHY_BASEDEVICE_NOT_AVAILABLE
 #define EXYNOS4X12_AUDIOSS_BASEDEVICE_NOT_AVAILABLE
 #define EXYNOS4X12_USB_HOST_XHCI_BASE  DEVICE_NOT_AVAILABLE
diff --git a/drivers/crypto/ace_sha.c b/drivers/crypto/ace_sha.c
index acbafde..d12a507 100644
--- a/drivers/crypto/ace_sha.c
+++ b/drivers/crypto/ace_sha.c
@@ -111,3 +111,44 @@ void hw_sha1(const unsigned char *pbuf, unsigned int 
buf_len,
if (ace_sha_hash_digest(pbuf, buf_len, pout, ACE_SHA_TYPE_SHA1))
debug(ACE was not setup properly or it is faulty\n);
 }
+
+unsigned int hw_rand(void)
+{
+   struct exynos_ace_sfr *reg =
+   (struct exynos_ace_sfr *)samsung_get_base_ace_sfr();
+   int status, i;
+   int seed[5];
+   unsigned int ret = 0;
+
+   /* Seed data */
+   for (i = 0; i  ACE_HASH_PRNG_REG_NUM; i++)
+   writel(seed[i], reg-hash_seed[i]);
+
+   status = 0;
+   /* Wait for seed setup done */
+   while (!(status  ACE_HASH_SEEDSETTING_MASK)) {
+   status = readl(reg-hash_status);
+   if (status  ACE_HASH_PRNGERROR_MASK)
+   return 0;
+   }
+
+   /* Start PRNG */
+   writel(ACE_HASH_ENGSEL_PRNG | ACE_HASH_STARTBIT_ON, reg-hash_control);
+
+   status = 0;
+   /* Wait for PRNG done */
+   while (!(status  ACE_HASH_PRNGDONE_MASK)) {
+   status = readl(reg-hash_status);
+   if (status  ACE_HASH_PRNGERROR_MASK)
+   return 0;
+   }
+
+   /* Clear Done IRQ */
+   writel(ACE_HASH_PRNGDONE_MASK, reg-hash_status);
+
+   /* Read a PRNG result */
+   for (i = 0; i  ACE_HASH_PRNG_REG_NUM; i++)
+   ret += readl(reg-hash_prng[i]);
+
+   return ret;
+}
diff --git a/drivers/crypto/ace_sha.h b/drivers/crypto/ace_sha.h
index a426d52..f1097f7 100644
--- a/drivers/crypto/ace_sha.h
+++ b/drivers/crypto/ace_sha.h
@@ -72,9 +72,10 @@ struct exynos_ace_sfr {
unsigned char   res12[0x30];
unsigned inthash_result[8];
unsigned char   res13[0x20];
-   unsigned inthash_seed[8];
-   unsigned inthash_prng[8];
-   unsigned char   res14[0x180];
+   unsigned inthash_seed[5];
+   unsigned char   res14[12];
+   unsigned inthash_prng[5];
+   unsigned char   res15[0x18c];
 
unsigned intpka_sfr[5]; /* base + 0x700 */
 };
@@ -291,6 +292,7 @@ struct exynos_ace_sfr {
 #define ACE_HASH_PRNGERROR_MASK(1  7)
 #define ACE_HASH_PRNGERROR_OFF (0  7)
 #define ACE_HASH_PRNGERROR_ON  (1  7)
+#define ACE_HASH_PRNG_REG_NUM  5
 
 #define ACE_SHA_TYPE_SHA1  1
 #define ACE_SHA_TYPE_SHA2562
-- 
1.7.9.5

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


[U-Boot] [PATCH 2/3] lib: rand: add call to hw_rand() - hardware random number generator

2014-02-28 Thread Przemyslaw Marczak
Changes:
- lib/rand.c: add call to hw_rand() (depends on CONFIG_RAND_HW_ACCEL)
- include/common.h: add hw_rand() declaration.

Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
cc: Michael Walle mich...@walle.cc
cc: Tom Rini tr...@ti.com
---
 include/common.h |3 +++
 lib/rand.c   |4 
 2 files changed, 7 insertions(+)

diff --git a/include/common.h b/include/common.h
index 96a45a6..58e2fbc 100644
--- a/include/common.h
+++ b/include/common.h
@@ -836,6 +836,9 @@ void srand(unsigned int seed);
 unsigned int rand(void);
 unsigned int rand_r(unsigned int *seedp);
 #endif
+#ifdef CONFIG_RAND_HW_ACCEL
+unsigned int hw_rand(void);
+#endif
 
 /* common/console.c */
 intconsole_init_f(void);   /* Before relocation; uses the serial  stuff
*/
diff --git a/lib/rand.c b/lib/rand.c
index 5c367e1..f534635 100644
--- a/lib/rand.c
+++ b/lib/rand.c
@@ -23,7 +23,11 @@ unsigned int rand_r(unsigned int *seedp)
 
 unsigned int rand(void)
 {
+#ifdef CONFIG_RAND_HW_ACCEL
+   return hw_rand();
+#else
return rand_r(y);
+#endif
 }
 
 void srand(unsigned int seed)
-- 
1.7.9.5

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


Re: [U-Boot] [PATCH] powerpc/t2080rdb: Add T2080PCIe-RDB board support

2014-02-28 Thread York Sun
On 02/28/2014 02:21 AM, Shengzhou Liu wrote:
 ---
  board/freescale/t208xrdb/Makefile   |  13 +
  board/freescale/t208xrdb/README | 196 
  board/freescale/t208xrdb/cpld.c |  71 +++
  board/freescale/t208xrdb/cpld.h |  42 ++
  board/freescale/t208xrdb/ddr.c  | 112 +
  board/freescale/t208xrdb/ddr.h  |  47 ++
  board/freescale/t208xrdb/eth_t208xrdb.c | 106 +
  board/freescale/t208xrdb/law.c  |  34 ++
  board/freescale/t208xrdb/pci.c  |  23 +
  board/freescale/t208xrdb/t2080_pbi.cfg  |  41 ++
  board/freescale/t208xrdb/t2080_rcw.cfg  |   8 +
  board/freescale/t208xrdb/t208xrdb.c | 115 +
  board/freescale/t208xrdb/t208xrdb.h |  13 +
  board/freescale/t208xrdb/tlb.c  | 151 +++
  boards.cfg  |   5 +
  include/configs/T208xRDB.h  | 779 
 
  16 files changed, 1756 insertions(+)
  create mode 100644 board/freescale/t208xrdb/Makefile
  create mode 100644 board/freescale/t208xrdb/README
  create mode 100644 board/freescale/t208xrdb/cpld.c
  create mode 100644 board/freescale/t208xrdb/cpld.h
  create mode 100644 board/freescale/t208xrdb/ddr.c
  create mode 100644 board/freescale/t208xrdb/ddr.h
  create mode 100644 board/freescale/t208xrdb/eth_t208xrdb.c
  create mode 100644 board/freescale/t208xrdb/law.c
  create mode 100644 board/freescale/t208xrdb/pci.c
  create mode 100644 board/freescale/t208xrdb/t2080_pbi.cfg
  create mode 100644 board/freescale/t208xrdb/t2080_rcw.cfg
  create mode 100644 board/freescale/t208xrdb/t208xrdb.c
  create mode 100644 board/freescale/t208xrdb/t208xrdb.h
  create mode 100644 board/freescale/t208xrdb/tlb.c
  create mode 100644 include/configs/T208xRDB.h
 

Shengzhou,

I have said with your T2081QDS patch


Next time, please format the patch with this command

git format-patch -M -C --find-copies-harder


I believe you didn't create these files from scratch. By using the proper
command, you will format the patch to identify copies and moves. The change set
will be smaller and easier to review.

York

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


Re: [U-Boot] [PATCH 1/2] lib: uuid: add function to generate UUID version 4

2014-02-28 Thread Stephen Warren
On 02/28/2014 08:18 AM, Przemyslaw Marczak wrote:
 lib/uuid.c:
 Add get_uuid_str() - this function returns 36 character hexadecimal ASCII
 string representation of a 128-bit (16 octets) UUID (Universally Unique
 Identifier) version 4 based on RFC4122, which is randomly generated.
 
 Source: https://www.ietf.org/rfc/rfc4122.txt

 diff --git a/disk/part_efi.c b/disk/part_efi.c

 @@ -132,9 +113,11 @@ void print_part_efi(block_dev_desc_t * dev_desc)
   le64_to_cpu(gpt_pte[i].ending_lba),
   print_efiname(gpt_pte[i]));
   printf(\tattrs:\t0x%016llx\n, gpt_pte[i].attributes.raw);
 - uuid_string(gpt_pte[i].partition_type_guid.b, uuid);
 + uuid_bin = (unsigned char *)gpt_pte[i].partition_type_guid.b;
 + uuid_bin_to_str(uuid_bin, uuid);

I don't know why you need the uuid_bin temporary variable; you could
just as well do the cast as part of the function parameter. Not a big
deal though.

 @@ -182,7 +165,7 @@ int get_partition_info_efi(block_dev_desc_t * dev_desc, 
 int part,

  #ifdef CONFIG_PARTITION_UUIDS
 - uuid_string(gpt_pte[part - 1].unique_partition_guid.b, info-uuid);
 + uuid_bin_to_str(gpt_pte[part - 1].unique_partition_guid.b, info-uuid);
  #endif

But you don't use a temporary here, for example.

 diff --git a/include/common.h b/include/common.h

  /* lib/uuid.c */
 -void uuid_str_to_bin(const char *uuid, unsigned char *out);
 +char *get_uuid_str(void);

See below; I think this prototype should be added in a separate patch.

 +int uuid_bin_to_str(unsigned char *uuid, char *str);

Can this ever fail? If you're explicitly changing it to have a return
cdoe, why do none of the callers check the return code?

  /* lib/rand.c */
  #if defined(CONFIG_RANDOM_MACADDR) || \
   defined(CONFIG_BOOTP_RANDOM_DELAY) || \
 - defined(CONFIG_CMD_LINK_LOCAL)
 + defined(CONFIG_CMD_LINK_LOCAL) || \
 + defined(CONFIG_PARTITION_UUIDS)

This patch does two things:

a) Refactor the UUID bin-str code so that it's in a shared place
b) Add new code get_uuid_str().

I think this patch should only do (a), and (b) should be part of a
separate patch. As such, the hunk above should be separated out. Perhaps
(b) should be part of patch 2/2, or a new patch inserted between the two.

Also, not everyone who defines CONFIG_PARTITION_UUIDs needs the new
get_uuid_str() function, and hence not everyone needs rand() etc.

 diff --git a/lib/Makefile b/lib/Makefile

 +ifdef CONFIG_PARTITION_UUIDS
 +obj-y += rand.o
 +obj-y += uuid.o
 +endif

That'd be better as:

obj-$(CONFIG_PARTITION_UUIDS) rand.o
obj-$(CONFIG_PARTITION_UUIDS) uuid.o

... although the rand.o change should be in a separate patch.

 diff --git a/lib/uuid.c b/lib/uuid.c

 +#define UUID_STR_BYTE_LEN37
 +
 +#define UUID_VERSION_CLEAR_BITS  0x0fff
 +#define UUID_VERSION_SHIFT   12
 +#define UUID_VERSION 0x4
 +
 +#define UUID_VARIANT_CLEAR_BITS  0x3f
 +#define UUID_VARIANT_SHIFT   7
 +#define UUID_VARIANT 0x1
 +
 +struct uuid {
 + unsigned int time_low;
 + unsigned short time_mid;
 + unsigned short time_hi_and_version;
 + unsigned char clock_seq_hi_and_reserved;
 + unsigned char clock_seq_low;
 + unsigned char node[6];
 +};

Most/all of that is support for get_uuid_str(), so should probably be
added in a separate patch.

 -void uuid_str_to_bin(const char *uuid, unsigned char *out)
 +int uuid_str_to_bin(char *uuid, unsigned char *out)
  {
   uint16_t tmp16;
   uint32_t tmp32;
   uint64_t tmp64;
  
   if (!uuid || !out)
 - return;
 + return -EINVAL;
 +
 + if (!uuid_str_valid(uuid))
 + return -EINVAL;

I'm not convinced it's useful to add this error-check; the code already
works or doesn't. Adding a unit-test to test/command_ut.c might be more
useful.

 +/*
 + * get_uuid_str() - this function returns pointer to 36 character hexadecimal
 + * ASCII string representation of a 128-bit (16 octets) UUID (Universally
 + * Unique Identifier) version 4 based on RFC4122.
 + * source: https://www.ietf.org/rfc/rfc4122.txt
 + *
 + * Layout of UUID Version 4:
 + * timestamp - 60-bit: time_low, time_mid, time_hi_and_version
 + * version   - 4 bit (bit 4 through 7 of the time_hi_and_version)
 + * clock seq - 14 bit: clock_seq_hi_and_reserved, clock_seq_low
 + * variant:  - bit 6 and 7 of clock_seq_hi_and_reserved
 + * node  - 48 bit
 + * In this version all fields beside 4 bit version are randomly generated.
 + *
 + * @ret: pointer to 36 bytes len characters array
 + */
 +char *get_uuid_str(void)

This function name isn't particularly good; it gives no hint that it's
generating a random UUID. Perhaps generate_random_uuid_str() would be
better.

Why does the function malloc the string, rather than writing to a
user-allocated buffer like uuid_bin_to_str()? That would be more
consistent with the other API, and simpler to code, and 

Re: [U-Boot] [PATCH 2/2] cmd:gpt: randomly generate each partition uuid if undefined

2014-02-28 Thread Stephen Warren
On 02/28/2014 08:18 AM, Przemyslaw Marczak wrote:
 Changes:
 - randomly generate each partition uuid if undefined
 - print info about generated uuid
 - save environment on gpt write success
 - update doc/README.gpt

 diff --git a/common/cmd_gpt.c b/common/cmd_gpt.c

  static char extract_env(const char *str, char **env)
  {
 + int ret = -1;

Why does the function return char not int? At least the type of ret
should match the return type of the function.

There's no need to introduce a ret variable anyway; just don't delete
the return statements that are already in the function.

 @@ -43,16 +44,23 @@ static char extract_env(const char *str, char **env)
   memset(s + strlen(s) - 1, '\0', 1);
   memmove(s, s + 2, strlen(s) - 1);
   e = getenv(s);
 - free(s);
   if (e == NULL) {
 - printf(Environmental '%s' not set\n, str);
 - return -1; /* env not set */
 + printf(%s unset. , str);
 + e = get_uuid_str();
 + if (e) {
 + printf(Setting to: %s\n, e);
 + setenv(s, e);

Why should the environment variable be set? I rather dislike commands
that randomly set environment variables as an implicit side-effect.

It'd be far better if this function simply wasn't modified, but rather
the user was provided with a function to explicitly set an environment
variable to a randomly generated GPT. That way the user/script would be
in control. Something like:

$ gen_random_uuid env_var_name

 @@ -299,8 +307,17 @@ static int do_gpt(cmd_tbl_t *cmdtp, int flag, int argc, 
 char * const argv[])
   return CMD_RET_FAILURE;
   }
  
 - if (gpt_default(blk_dev_desc, argv[4]))
 + puts(Writing GPT: );
 +
 + ret = gpt_default(blk_dev_desc, argv[4]);
 + if (!ret) {
 + puts(success!\n);
 + saveenv();

Uggh. Definitely don't save the environment behind the user's back.
There is no reason to believe that's safe. What if the user had added
some temporary changes to their environment that they didn't want saved?
This kind of logic belongs in scripts, not code.

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


Re: [U-Boot] [PATCH 2/3] lib: rand: add call to hw_rand() - hardware random number generator

2014-02-28 Thread Michael Walle
Am Freitag, 28. Februar 2014, 17:30:54 schrieb Przemyslaw Marczak:
 Changes:
 - lib/rand.c: add call to hw_rand() (depends on CONFIG_RAND_HW_ACCEL)
 - include/common.h: add hw_rand() declaration.
 
 Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
 cc: Michael Walle mich...@walle.cc
 cc: Tom Rini tr...@ti.com
 ---
  include/common.h |3 +++
  lib/rand.c   |4 
  2 files changed, 7 insertions(+)
 
 diff --git a/include/common.h b/include/common.h
 index 96a45a6..58e2fbc 100644
 --- a/include/common.h
 +++ b/include/common.h
 @@ -836,6 +836,9 @@ void srand(unsigned int seed);
  unsigned int rand(void);
  unsigned int rand_r(unsigned int *seedp);
  #endif
 +#ifdef CONFIG_RAND_HW_ACCEL
 +unsigned int hw_rand(void);
 +#endif
 
  /* common/console.c */
  int  console_init_f(void);   /* Before relocation; uses the serial  stuff
*/
 diff --git a/lib/rand.c b/lib/rand.c
 index 5c367e1..f534635 100644
 --- a/lib/rand.c
 +++ b/lib/rand.c
 @@ -23,7 +23,11 @@ unsigned int rand_r(unsigned int *seedp)
 
  unsigned int rand(void)
  {
 +#ifdef CONFIG_RAND_HW_ACCEL
 + return hw_rand();
 +#else
   return rand_r(y);
 +#endif
  }

shouldn't we put that into rand_r() and ignore the argument? because then both 
users of rand() and rand_r() will benefit from the hardware random generator.

and what does HW_ACCEL mean? is this a real hardware random generator? if this 
is the case, wouldn't it make more sense to name it CONFIG_RAND_USE_HW_RNG.

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


Re: [U-Boot] Ethernet persistence

2014-02-28 Thread Scott Wood
On Fri, 2014-02-28 at 07:24 -0700, Simon Glass wrote:
 Hi Anthony,
 
 On 27 February 2014 09:09, Anthony Mahar anthony.j.ma...@gmail.com wrote:
 
  How can I make the ethernet connection persistent (after first use), rather
  than reconnecting/re initializing on each reuse?
 
  I'm working with a Xilinx Zynq zc706 board and am up and running u-boot
  quite successfully.  My main use case is to store u-boot in on-board flash,
  and have u-boot tftp get / boot the bitstream, kernel image, devicetree,
  and
  ramdisk image.  The following script functions well:
  qspiboot=echo Configure PL and booting Linux from TFTP...   \
  fpga info 0;
   \
  tftp 0x100 system.bin;
   \
  fpga load 0 0x100 cb44bc; \
  tftp 0x300 ${kernel_image}; \
  tftp 0x2A0 ${devicetree_image}; \
  tftp 0x200 ${ramdisk_image}; \
  bootm 0x300 0x200 0x2A0\0 \
 
 
  The ethernet (Zynq's gem.e000b000) will get initialized on first use, as
  appropriate, however the Ethernet is reinitialized and auto negotiated
  again
  for each subsequent tftp request which shouldn't be necessary.  A snippet
  is
  listed below.  Each 'reconnection' takes several seconds... a few to auto
  negotiate, then a few more for the Windows based TFTP server to recognize
  the connection and allow connections to the server.  Multiply this by the
  number of transfers and it takes a very long time to transfer a very little
  amount of data.
 
 
 Yes as Michal says you should use FIT and put everything in one file, or
 less than 4. I'm not sure if we have a command to load your FPGA image from
 FIT though. We could add one fairly easily now that we have
 fit_image_load().

FIT is not particularly convenient when repeatedly updating a single
component, and requires more work to assemble.  I thought it was meant
to replace old-style multi-image, not to deprecate individual images.

 Also take a look at asix_init() in drivers/usb/eth, which does not re-init
 the link if it is already up. This speeds things up.

So the question is why other ethernet drivers don't do this...

-Scott


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


[U-Boot] [PATCH] Trats/Trats2: Update Tizen partitions layout and dfu entities

2014-02-28 Thread Przemyslaw Marczak
Changes:
- update partitions layout
- update dfu entities
to be consistent with Tizen images for trats/trats2

Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Acked-by: Łukasz Majewski l.majew...@samsung.com
cc: Piotr Wilczek p.wilc...@samsung.com
cc: Minkyu Kang mk7.k...@samsung.com
---
 include/configs/trats.h  |   19 +++
 include/configs/trats2.h |   14 +-
 2 files changed, 20 insertions(+), 13 deletions(-)

diff --git a/include/configs/trats.h b/include/configs/trats.h
index 718107a..eb7f864 100644
--- a/include/configs/trats.h
+++ b/include/configs/trats.h
@@ -122,29 +122,32 @@
 
 /* Tizen - partitions definitions */
 #define PARTS_CSA  csa-mmc
-#define PARTS_BOOTLOADER   u-boot
 #define PARTS_BOOT boot
+#define PARTS_QBOOTqboot
+#define PARTS_CSC  csc
 #define PARTS_ROOT platform
 #define PARTS_DATA data
-#define PARTS_CSC  csc
 #define PARTS_UMS  ums
 
 #define PARTS_DEFAULT \
uuid_disk=${uuid_gpt_disk}; \
-   name=PARTS_CSA,size=8MiB,uuid=${uuid_gpt_PARTS_CSA}; \
-   name=PARTS_BOOTLOADER,size=60MiB, \
-   uuid=${uuid_gpt_PARTS_BOOTLOADER}; \
-   name=PARTS_BOOT,size=100MiB,uuid=${uuid_gpt_PARTS_BOOT}; \
-   name=PARTS_ROOT,size=1GiB,uuid=${uuid_gpt_PARTS_ROOT}; \
-   name=PARTS_DATA,size=3GiB,uuid=${uuid_gpt_PARTS_DATA}; \
+   name=PARTS_CSA,start=5MiB,size=8MiB,uuid=${uuid_gpt_PARTS_CSA}; \
+   name=PARTS_BOOT,size=60MiB,uuid=${uuid_gpt_PARTS_BOOT}; \
+   name=PARTS_QBOOT,size=100MiB,uuid=${uuid_gpt_PARTS_QBOOT}; \
name=PARTS_CSC,size=150MiB,uuid=${uuid_gpt_PARTS_CSC}; \
+   name=PARTS_ROOT,size=1536MiB,uuid=${uuid_gpt_PARTS_ROOT}; \
+   name=PARTS_DATA,size=3000MiB,uuid=${uuid_gpt_PARTS_DATA}; \
name=PARTS_UMS,size=-,uuid=${uuid_gpt_PARTS_UMS}\0 \
 
 #define CONFIG_DFU_ALT \
u-boot mmc 80 400; \
uImage ext4 0 2; \
+   modem.bin ext4 0 2; \
exynos4210-trats.dtb ext4 0 2; \
+   PARTS_CSA part 0 1; \
PARTS_BOOT part 0 2; \
+   PARTS_QBOOT part 0 3; \
+   PARTS_CSC part 0 4; \
PARTS_ROOT part 0 5; \
PARTS_DATA part 0 6; \
PARTS_UMS part 0 7; \
diff --git a/include/configs/trats2.h b/include/configs/trats2.h
index e30c428..eeebacf 100644
--- a/include/configs/trats2.h
+++ b/include/configs/trats2.h
@@ -156,9 +156,9 @@
 #define CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
 
 /* Tizen - partitions definitions */
-#define PARTS_CSA  csa
+#define PARTS_CSA  csa-mmc
 #define PARTS_BOOT boot
-#define PARTS_MODEMmodem
+#define PARTS_QBOOTqboot
 #define PARTS_CSC  csc
 #define PARTS_ROOT platform
 #define PARTS_DATA data
@@ -167,18 +167,22 @@
 #define PARTS_DEFAULT \
uuid_disk=${uuid_gpt_disk}; \
name=PARTS_CSA,start=5MiB,size=8MiB,uuid=${uuid_gpt_PARTS_CSA}; \
-   name=PARTS_BOOT,size=64MiB,uuid=${uuid_gpt_PARTS_BOOT}; \
-   name=PARTS_MODEM,size=100MiB,uuid=${uuid_gpt_PARTS_MODEM}; \
+   name=PARTS_BOOT,size=60MiB,uuid=${uuid_gpt_PARTS_BOOT}; \
+   name=PARTS_QBOOT,size=100MiB,uuid=${uuid_gpt_PARTS_QBOOT}; \
name=PARTS_CSC,size=150MiB,uuid=${uuid_gpt_PARTS_CSC}; \
name=PARTS_ROOT,size=1536MiB,uuid=${uuid_gpt_PARTS_ROOT}; \
-   name=PARTS_DATA,size=512MiB,uuid=${uuid_gpt_PARTS_DATA}; \
+   name=PARTS_DATA,size=3000MiB,uuid=${uuid_gpt_PARTS_DATA}; \
name=PARTS_UMS,size=-,uuid=${uuid_gpt_PARTS_UMS}\0 \
 
 #define CONFIG_DFU_ALT \
u-boot mmc 80 800; \
uImage ext4 0 2; \
+   modem.bin ext4 0 2; \
exynos4412-trats2.dtb ext4 0 2; \
+   PARTS_CSA part 0 1; \
PARTS_BOOT part 0 2; \
+   PARTS_QBOOT part 0 3; \
+   PARTS_CSC part 0 4; \
PARTS_ROOT part 0 5; \
PARTS_DATA part 0 6; \
PARTS_UMS part 0 7; \
-- 
1.7.9.5

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


[U-Boot] [PATCH] usb: dfu: add static alt num count in dfu_config_entities()

2014-02-28 Thread Przemyslaw Marczak
Thanks to this multiple call of function dfu_config_entities()
gives continuous dfu alt numbering until call dfu_free_entities().

This allows to store dfu entities in multiple variables.

Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Acked-by: Łukasz Majewski l.majew...@samsung.com
---
 drivers/dfu/dfu.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 07011e9..56e69fd 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -19,6 +19,7 @@
 static bool dfu_reset_request;
 static LIST_HEAD(dfu_list);
 static int dfu_alt_num;
+static int alt_num_cnt;
 
 bool dfu_reset(void)
 {
@@ -377,6 +378,8 @@ void dfu_free_entities(void)
if (t)
free(t);
INIT_LIST_HEAD(dfu_list);
+
+   alt_num_cnt = 0;
 }
 
 int dfu_config_entities(char *env, char *interface, int num)
@@ -394,11 +397,12 @@ int dfu_config_entities(char *env, char *interface, int 
num)
for (i = 0; i  dfu_alt_num; i++) {
 
s = strsep(env, ;);
-   ret = dfu_fill_entity(dfu[i], s, i, interface, num);
+   ret = dfu_fill_entity(dfu[i], s, alt_num_cnt, interface, num);
if (ret)
return -1;
 
list_add_tail(dfu[i].list, dfu_list);
+   alt_num_cnt++;
}
 
return 0;
-- 
1.7.9.5

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


Re: [U-Boot] Writing to SD partitions from u-boot

2014-02-28 Thread Wolfgang Denk
Dear David,

In message cadqaesiqedc41z1zc7naqjxlake5q-ctubxwi3n_bpjtjey...@mail.gmail.com 
you wrote:

 This value is set below if my sd card is a mmc and if version is = than 4.
  So, I was all the time using a SD card and not an MMC card, but i double
 checked it and the statement:
 
 if (!IS_SD(mmc)  (mmc-version = MMC_VERSION_4)) {
 
 
 Wont be true, because:
  IS_SD(mmc) = 0x2 and mmc-version = 0x20020
 
 Apparently I should use a mmc card in order to use the mmc functions, which
 makes perfect sense to me :)

mmc read and mmc write work just fine on SDcards, too.

 On Fri, Feb 28, 2014 at 12:23 PM, Wolfgang Denk w...@denx.de wrote:
 
  Dear David,
...
[full quote deleted]

Please stop top-posting / full-quoting.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
I see that Microsoft's campaign  to  destroy  all  knowledge  of  any
operating   environment   but  its  own  environment-of-the-year  has
succeeded in creating a generation of users who don't understand  the
concept of a shell...
-- L. Peter Deutsch in m0x5jnx-000r...@lamp.aladdin.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] Writing to SD partitions from u-boot

2014-02-28 Thread Wolfgang Denk
Dear David,

please make sure to keep the mailing list on Cc:

In message cadqaesgh4ufznsfyzutvsb64tr6gd3dwl4kttugqinwumhk...@mail.gmail.com 
you wrote:

 Ok, thats good to know, thank you. That doesnt explain though what kind of
 sd cards I should use to be able to switch partitions. Am I
 misunderstanding the function that does that? From the code, i will only be
 able to do that when mmc-part_config is different than 0xff
 (MMCPART_NOAVAILABLE). What should I do with my card to get it to work ?

I don't see why exactly you need to switch partitions...

The mme part command will print you the numbers of the first sector
in each partition, so it's trivial to write an image.

For example, assume we want to write the file system image
rootfs.img into the second partition of an SDcard:

= tftp $loadaddr rootfs.img
Using FEC device
TFTP from server 192.168.1.1; our IP address is 192.168.20.56
Filename 'rootfs.img'.
Load address: 0x7080
Loading: #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 
 763.7 KiB/s
done
Bytes transferred = 16385024 (fa0400 hex)
= setexpr cnt $filesize + 0x1ff
= setexpr cnt $cnt / 0x200
= mmc part

Partition Map for MMC device 0  --   Partition Type: DOS

PartStart SectorNum Sectors UUIDType
  1 8192131072  -01 83
  2 139264  7753728 -02 83
= mmc write $loadaddr 0x22000 $cnt

MMC write: dev # 0, block # 139264, count 32002 ... 32002 blocks write: OK


The only tricky part here is to convert the decimal number 139264
for the start sector of partition 2 into hexadecimal format as
expected by mmc write: decimal 139264 = 0x22000.

[Note that even the conversion of the file size in bytes into block
numbers can be scripted with two simple setexpr commands.]


Hope this helps.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
When in doubt, mumble;   when in trouble, delegate;  when in  charge,
ponder. -- James H. Boren
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] Licensing Question on ARM Semihosting Code

2014-02-28 Thread Darwin Rambo
Given the ARM header below, is this code possible to put into u-boot?

For reference, I see this discussion below.
http://lists.denx.de/pipermail/u-boot/2011-November/110884.html

If this is not acceptable, presumably due to the All rights reserved
and Redistribution in binary form... clauses below, we could try to
find an alternative implementation that is GPL2.0+ licensed or rewrite
the parts we need from scratch.

Any suggestions you have would be most welcome. Thanks.

Regards,
Darwin Rambo


 /*
  * Copyright (c) 2013-2014, ARM Limited and Contributors. All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions are met:
  *
  * Redistributions of source code must retain the above copyright notice, this
  * list of conditions and the following disclaimer.
  *
  * Redistributions in binary form must reproduce the above copyright notice,
  * this list of conditions and the following disclaimer in the documentation
  * and/or other materials provided with the distribution.
  *
  * Neither the name of ARM nor the names of its contributors may be used
  * to endorse or promote products derived from this software without specific
  * prior written permission.
  *
  * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS AS IS
  * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
  * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
  * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
  * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
  * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
  * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
  * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
  * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
  * POSSIBILITY OF SUCH DAMAGE.
  */

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


Re: [U-Boot] Licensing Question on ARM Semihosting Code

2014-02-28 Thread Tom Rini
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/28/2014 01:18 PM, Darwin Rambo wrote:
 Given the ARM header below, is this code possible to put into
 u-boot?
 
 For reference, I see this discussion below. 
 http://lists.denx.de/pipermail/u-boot/2011-November/110884.html
 
 If this is not acceptable, presumably due to the All rights
 reserved and Redistribution in binary form... clauses below, we
 could try to find an alternative implementation that is GPL2.0+
 licensed or rewrite the parts we need from scratch.
 
 Any suggestions you have would be most welcome. Thanks.

So, that particular discussion was about fastboot, and in that
particular case everything is OK, in the long run (I poked TI's
lawyers about that).  We're just missing a clean design version being
ported and I know of a few groups / companies leaning on another
entity to do so.

But with your particular quoted header, I think we cannot use it as it
puts restrictions on the binary redistribution as well.

- -- 
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTENovAAoJENk4IS6UOR1WuUYP/RukZAEnPLM4IEEIMpa9tAir
J7FUa+zIJKerQfNQ+rrW5/sWGG2Zj/1A8twjcs7W8KXrbbaQEr+jpQRPspS3pa5q
bmfeBDclNpuwqXtzeQvm6eNWVbkq0+4fJ25AI7fL1EuhpGFmcPfXoAW4DOFBJBUW
B11BHzHO1PuWl+7fm5PLBT/kMjB8rv8gx6rhyNxp0f3/aN+U4GkSNvVBXo8cBOWm
4gO2dqWM299e3x2GYVKBbYwbAydBXXOjwpa3VoGljJPiz5iBT1DrMJV9R37kTRkj
D07PUlV2aMNdZv+dNxV1FOce/bhcT8iRWyzUSlecPrNWDWp7nFaIaGBpDHh8iRKA
thB7LlT1hQI88ksQH923CBaa2N1N/HgYtXYSiwRXx8bQexLIBieCvfUsHxqtWKRQ
r+bf3febP0MYiU5BCHKHHpY3zfERGRIVmgAs/7khtm038ORAIxWLX7myvQyubfBz
jRbwkZfpR1UXQ8g6zcbRah9mB12foVURF8a67v+9JC7p4/Jrrjb3ARgw8LwA61de
kiqjUr3qDfEcow9KTxZPVFi5gLJXTSdMPzgrs/2cCJ2jFnN/olGd//eGaIZUzf6P
7L2oOEwv2i7p4FwwciTGhQWCfLO3YzU0MHnFJsHu+NaDdUxhpf/X/zwcAHvQqrc+
L6bmYpnta9ViVwJHzOSS
=Si6y
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] Licensing Question on ARM Semihosting Code

2014-02-28 Thread Måns Rullgård
Darwin Rambo dra...@broadcom.com writes:

 Given the ARM header below, is this code possible to put into u-boot?

 For reference, I see this discussion below.
 http://lists.denx.de/pipermail/u-boot/2011-November/110884.html

 If this is not acceptable, presumably due to the All rights reserved
 and Redistribution in binary form... clauses below, we could try to
 find an alternative implementation that is GPL2.0+ licensed or rewrite
 the parts we need from scratch.

 Any suggestions you have would be most welcome. Thanks.

 Regards,
 Darwin Rambo

 /*
  * Copyright (c) 2013-2014, ARM Limited and Contributors. All rights 
 reserved.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions are 
 met:
  *
  * Redistributions of source code must retain the above copyright notice, 
 this
  * list of conditions and the following disclaimer.
  *
  * Redistributions in binary form must reproduce the above copyright notice,
  * this list of conditions and the following disclaimer in the documentation
  * and/or other materials provided with the distribution.
  *
  * Neither the name of ARM nor the names of its contributors may be used
  * to endorse or promote products derived from this software without specific
  * prior written permission.
  *
  * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS AS 
 IS
  * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
  * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
  * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
  * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
  * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
  * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
  * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
  * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
  * POSSIBILITY OF SUCH DAMAGE.
  */

This is the standard 3-clause BSD licence, just without the usual
explicit numbering.  According to the FSF [1], it is compatible with the
GPL.

[1] http://www.gnu.org/licenses/license-list.html#ModifiedBSD

-- 
Måns Rullgård
m...@mansr.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH V2] cfb_console: force natural alignment of 32-bit fields in gzipped .bmp files

2014-02-28 Thread Eric Nelson
.bmp files contain 32-bit integers aligned at offsets of +2, +6,
et cetera within the bmp_header structure (see include/bmp_layout.h).

Support for gzip-compressed .bmp files is present in the cfb_console
display subsystem by uncompressing them prior to use.

This patch forces the in-memory header to be aligned properly
for these compressed images by extracting them to a 2-byte
offset in the memory returned by malloc. Since malloc will always
return a 4-byte aligned value, this forces the .bmp header
fields to be naturally aligned on 4-byte addresses.

Refer to these files for more details:
doc/README.displaying-bmps
doc/README.arm-unaligned-accesses

Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
---
 drivers/video/cfb_console.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c
index 6db4073..2209148 100644
--- a/drivers/video/cfb_console.c
+++ b/drivers/video/cfb_console.c
@@ -1473,7 +1473,10 @@ int video_display_bitmap(ulong bmp_image, int x, int y)
printf(Error: malloc in gunzip failed!\n);
return 1;
}
-   if (gunzip(dst, CONFIG_SYS_VIDEO_LOGO_MAX_SIZE,
+   /* NB: we need to force offset of +2
+* See doc/README.displaying-bmps
+*/
+   if (gunzip(dst+2, CONFIG_SYS_VIDEO_LOGO_MAX_SIZE-2,
   (uchar *) bmp_image,
   len) != 0) {
printf(Error: no valid bmp or bmp.gz image at %lx\n,
@@ -1489,7 +1492,7 @@ int video_display_bitmap(ulong bmp_image, int x, int y)
/*
 * Set addr to decompressed image
 */
-   bmp = (bmp_image_t *) dst;
+   bmp = (bmp_image_t *)(dst+2);
 
if (!((bmp-header.signature[0] == 'B') 
  (bmp-header.signature[1] == 'M'))) {
-- 
1.8.3.2

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


Re: [U-Boot] [PATCH V2] cfb_console: force natural alignment of 32-bit fields in gzipped .bmp files

2014-02-28 Thread Wolfgang Denk
Dear Eric Nelson,

your message contains no thread information - there is neither a
In-reply-to: nor any References: header.  This is bad!

Please also make sure to keep the Subject: test short; the recommended
style for the commit message is 50/72 formatting, i. e. the Subject
should not exceed 50 (...60) characters.

In message 1393621572-10306-1-git-send-email-eric.nel...@boundarydevices.com 
you wrote:
 .bmp files contain 32-bit integers aligned at offsets of +2, +6,
 et cetera within the bmp_header structure (see include/bmp_layout.h).
 
 Support for gzip-compressed .bmp files is present in the cfb_console
 display subsystem by uncompressing them prior to use.
 
 This patch forces the in-memory header to be aligned properly
 for these compressed images by extracting them to a 2-byte
 offset in the memory returned by malloc. Since malloc will always
 return a 4-byte aligned value, this forces the .bmp header
 fields to be naturally aligned on 4-byte addresses.
 
 Refer to these files for more details:
   doc/README.displaying-bmps
   doc/README.arm-unaligned-accesses
 
 Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
 ---
  drivers/video/cfb_console.c | 7 +--
  1 file changed, 5 insertions(+), 2 deletions(-)

So what exactly has changed since version 1?  Please note that the
change log is mandatory!

 diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c
 index 6db4073..2209148 100644
 --- a/drivers/video/cfb_console.c
 +++ b/drivers/video/cfb_console.c
 @@ -1473,7 +1473,10 @@ int video_display_bitmap(ulong bmp_image, int x, int y)
   printf(Error: malloc in gunzip failed!\n);
   return 1;
   }
 - if (gunzip(dst, CONFIG_SYS_VIDEO_LOGO_MAX_SIZE,
 + /* NB: we need to force offset of +2
 +  * See doc/README.displaying-bmps
 +  */

Incorrect multiline comment style, please fix.

I asked you before to fix that, please make sure not to ignore
review comments!

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
G's Third Law: In spite of all evidence  to  the  contra-
ry,  the  entire  universe  is composed of only two basic substances:
magic and bullshit.
H's Dictum:There is no magic ...
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH V2] cfb_console: force natural alignment of 32-bit fields in gzipped .bmp files

2014-02-28 Thread Eric Nelson

Sorry Wolfgang,

On 02/28/2014 02:44 PM, Wolfgang Denk wrote:

Dear Eric Nelson,

your message contains no thread information - there is neither a
In-reply-to: nor any References: header.  This is bad!

Please also make sure to keep the Subject: test short; the recommended
style for the commit message is 50/72 formatting, i. e. the Subject
should not exceed 50 (...60) characters.



Okay. I was trying to be more explicit here.


In message 1393621572-10306-1-git-send-email-eric.nel...@boundarydevices.com 
you wrote:

.bmp files contain 32-bit integers aligned at offsets of +2, +6,
et cetera within the bmp_header structure (see include/bmp_layout.h).

Support for gzip-compressed .bmp files is present in the cfb_console
display subsystem by uncompressing them prior to use.

This patch forces the in-memory header to be aligned properly
for these compressed images by extracting them to a 2-byte
offset in the memory returned by malloc. Since malloc will always
return a 4-byte aligned value, this forces the .bmp header
fields to be naturally aligned on 4-byte addresses.

Refer to these files for more details:
doc/README.displaying-bmps
doc/README.arm-unaligned-accesses

Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
---
  drivers/video/cfb_console.c | 7 +--
  1 file changed, 5 insertions(+), 2 deletions(-)


So what exactly has changed since version 1?  Please note that the
change log is mandatory!



Got it.


diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c
index 6db4073..2209148 100644
--- a/drivers/video/cfb_console.c
+++ b/drivers/video/cfb_console.c
@@ -1473,7 +1473,10 @@ int video_display_bitmap(ulong bmp_image, int x, int y)
printf(Error: malloc in gunzip failed!\n);
return 1;
}
-   if (gunzip(dst, CONFIG_SYS_VIDEO_LOGO_MAX_SIZE,
+   /* NB: we need to force offset of +2
+* See doc/README.displaying-bmps
+*/


Incorrect multiline comment style, please fix.

I asked you before to fix that, please make sure not to ignore
review comments!


Not intentional... Will fix in V3.

Regards,


Eric

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