Re: [U-Boot] [PATCH V2 08/21] mx6: add plugin file for use with imximage.cfg

2012-09-23 Thread Stefano Babic
On 22/09/2012 04:39, Troy Kisky wrote:
 The plugin command of mkimage can take this
 file as an argument.
 
 Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com
 ---

Hi Troy,

I agree with Vikram that a better explanation of what a plugin is can
help to understand without reading deeply into the i.MX6 manual.

So a plugin is a chunk of code that can be called directly by the
BootROM of i.MX processors supporting V2 version of the i.MX header.
In my understanding, this is supported by i.MX53, too. After the plugin
run, the control is returned to the BootROM.

Now that we have some basis, why do we need this mechanism to boot this
board ? Is it not possible to make the same initialization directly in
u-boot ?

In principle, this adds stil some code that is not so easy to maintain.

  arch/arm/cpu/armv7/mx6/Makefile  |5 +-
  arch/arm/cpu/armv7/mx6/plugin.S  |  164 
 ++
  arch/arm/include/asm/arch-mx6/imx-regs.h |1 +
  3 files changed, 169 insertions(+), 1 deletion(-)
  create mode 100644 arch/arm/cpu/armv7/mx6/plugin.S
 
 diff --git a/arch/arm/cpu/armv7/mx6/Makefile b/arch/arm/cpu/armv7/mx6/Makefile
 index cbce411..b1fce4e 100644
 --- a/arch/arm/cpu/armv7/mx6/Makefile
 +++ b/arch/arm/cpu/armv7/mx6/Makefile
 @@ -33,11 +33,14 @@ SOBJS   = lowlevel_init.o
  SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
  OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS))
  
 -all: $(obj).depend $(LIB)
 +all: $(obj).depend $(LIB) plugin.bin
  
  $(LIB):  $(OBJS)
   $(call cmd_link_o_target, $(OBJS))
  
 +plugin.bin: plugin.o
 + $(OBJCOPY) -O binary --gap-fill 0xff $ $@

If we add a plugin mechanism, we can have several plugins (booting
directly from Net, maybe ?). We should then have a general mechanism. A
directory plugins here can contain the code, and it is compiled only
if a CONFIG_ is set or better if required from imximage.cfg


 +
  #
  
  # defines $(obj).depend target
 diff --git a/arch/arm/cpu/armv7/mx6/plugin.S b/arch/arm/cpu/armv7/mx6/plugin.S
 new file mode 100644
 index 000..99c6b20
 --- /dev/null
 +++ b/arch/arm/cpu/armv7/mx6/plugin.S
 @@ -0,0 +1,164 @@
 +/*
 + * Copyright (C) 2012 Boundary Devices Inc.
 + *
 + * Licensed under the GPL-2 or later.
 + */
 +#include config.h
 +#include asm/arch/imx-regs.h
 +
 +#define HAB_RVT_ENTRY0x98
 +#define HAB_RVT_FAIL_SAFE_VECT   0xbc
 +#define HAB_RVT_LOAD_DATA0xc8
 +
 +#define HDR_SELF_PTR 0x14
 +#define HDR_BOOT_DATA0x20
 +#define HDR_IMAGE_LEN0x24
 +
 +#define L2X0_CTRL0x100
 +#define SCU_CONFIG   0x004
 +
 +/*
 + * Disable L2 cache because ROM will turn it on when a plugin is used.
 + * There are cache coherence problems if cache is on when Linux kernel
 + * expects it to be off.
 + */
 +.macro disable_l2_cache
 + ldr r1, =L2_BASE_ADDR
 + mov r0, #0x0
 + str r0, [r1, #L2X0_CTRL]
 +.endm
 +
 +
 +/*
 + * plugin_start(void **start, size_t *bytes, UINT32 *ivt_offset)
 + */
 +plugin_start:
 +/* Save the return address and the function arguments */
 + push{r0-r8, lr}
 +
 +/* r0-r2 must be  = 0x100 and must be 4 byte aligned */
 + cmp r0, #0x100
 + cmphs   r1, #0x100
 + cmphs   r2, #0x100
 +
 +/* rCPU: 22 - mx6q, 12 - mx6dl, 12|0x100 - solo, 2 - sololite */
 +#define rCPU r2
 +#define rIomux   r3
 +#define rVal0r4  /* mx6q value */
 +#define rVal1r5  /* mx6dl value */
 +#define rVal2r6  /* mx6solo value */
 +#define rVal3r7  /* mx6sololite value */
 +#define rFlaglr
 +#define rTable   r8
 +
 + orr rFlag, r0, r1
 + orr rFlag, rFlag, r2
 + orrlo   rFlag, rFlag, #1
 +
 + mov rCPU, #22   /* mx6q */
 + mov r1, #SCU_BASE_ADDR
 + ldr r0, [r1, #SCU_CONFIG]
 + and r0, r0, #3
 + cmp r0, #3  /* is mx6q? */
 + movne   rCPU, #12   /* mx6dl */
 + cmpne   r0, #1  /* is mx6dl? */
 + movne   rCPU, #2/* mx6 sololite */
 +
 + ldrne   r1, =ANATOP_BASE_ADDR
 + ldrne   r0, [r1, #0x280]
 + movne   r0, r0, LSR #16
 + cmpne   r0, #0x60   /* is mx6 Sololite? */
 + movne   rCPU, #12 | 0x100   /* Solo */

Ok - until here you have checked which processor is running. Now the
more obscure code:

 +
 + mov rVal0, #0
 + mov rVal1, #0
 + mov rVal2, #0
 + mov rVal3, #0
 + ldr rIomux, =IOMUXC_BASE_ADDR
 + adr rTable, mx6_table
 + b   3f



 +
 +1:   movsr0, r1, LSR #30
 + beq 2f
 + mov r1, r1, LSL rCPU
 + movsr1, r1, LSR #32-10
 + addne   r1, rIomux, r1, LSL #2
 + cmp r0, #3
 + subne   r0, r0, #1
 + orr r1, r1, r0
 +

The reason is to write GPR12 ? But why do we need a plugin for that ? I
do not understand why we cannot do it in the initialization 

Re: [U-Boot] [PATCH V2 01/21] imximage: make header variable length

2012-09-23 Thread Stefano Babic
On 22/09/2012 04:38, Troy Kisky wrote:

Hi Troy,

 Also, the header offset is no longer
 right before the code starts.

Comment and subject of the patch do not match. Can you better explain it
? What have making header variable length, that is, a new feature,
with  the header offset is no longer rigth, that is, a bug ?

Do we already have a variable header the we add a vrec_header function
to  image_type_params ?

 Series tested on an mx51 and mx6q
 ---
  tools/imximage.c |  142 
 +++---
  tools/imximage.h |   10 ++--
  2 files changed, 87 insertions(+), 65 deletions(-)
 
 diff --git a/tools/imximage.c b/tools/imximage.c
 index 03a7716..25d3b74 100644
 --- a/tools/imximage.c
 +++ b/tools/imximage.c
 @@ -65,12 +65,15 @@ static table_entry_t imximage_versions[] = {
   {-1,,  (Invalid), },
  };
  
 -static struct imx_header imximage_header;
  static uint32_t imximage_version;
  
  static set_dcd_val_t set_dcd_val;
  static set_dcd_rst_t set_dcd_rst;
  static set_imx_hdr_t set_imx_hdr;
 +static set_imx_size_t set_imx_size;
 +static uint32_t g_flash_offset;
 +
 +static struct image_type_params imximage_params;
  
  static uint32_t get_cfg_value(char *token, char *name,  int linenr)
  {
 @@ -207,85 +210,79 @@ static void set_dcd_rst_v2(struct imx_header *imxhdr, 
 uint32_t dcd_len,
   dcd_v2-write_dcd_command.param = DCD_COMMAND_PARAM;
  }
  
 -static void set_imx_hdr_v1(struct imx_header *imxhdr, uint32_t dcd_len,
 - struct stat *sbuf,
 - struct mkimage_params *params)
 +static int set_imx_hdr_v1(struct imx_header *imxhdr, uint32_t dcd_len,
 + uint32_t entry_point, uint32_t flash_offset)
  {
   imx_header_v1_t *hdr_v1 = imxhdr-header.hdr_v1;
   flash_header_v1_t *fhdr_v1 = hdr_v1-fhdr;
   dcd_v1_t *dcd_v1 = hdr_v1-dcd_table;
 - uint32_t base_offset;
 -
 - /* Exit if there is no BOOT_FROM field specifying the flash_offset */
 - if(imxhdr-flash_offset == FLASH_OFFSET_UNDEFINED) {
 - fprintf(stderr, Error: Header v1: No BOOT_FROM tag in %s\n,
 - params-imagename);
 - exit(EXIT_FAILURE);
 - }

Do you drop BOOT_FROM ? Then this should be documented. Is this to allow
that the same image can be loaded from different media, that share the
same flash offset ? Then, instead of drop it, I suggest to add more
entries in the imximage file, one for each media that is allow.

Something like:
BOOT_FROM   sd, nand, spi

and maybe a check in the code if all entries do not share the same start
address.

 + uint32_t hdr_base;
 + uint32_t header_length = (((char *)dcd_v1-addr_data[dcd_len].addr)
 + - ((char *)imxhdr));
  

For V1, the header is preallocated with the maximum size, that is the
maximum number of DCD entries the SOC in V1 can support. Why do we need
a dynamic length for V1 processors ? As far as I know, the number of
entries and fields for theses SOCs (i.MX25, i.MX35, i.MX51) is fixed.

   /* Set magic number */
   fhdr_v1-app_code_barker = APP_CODE_BARKER;
  
 - fhdr_v1-app_dest_ptr = params-addr;
 - fhdr_v1-app_dest_ptr = params-ep - imxhdr-flash_offset -
 - sizeof(struct imx_header);
 - fhdr_v1-app_code_jump_vector = params-ep;
 + hdr_base = entry_point - header_length;
 + fhdr_v1-app_dest_ptr = hdr_base - flash_offset;
 + fhdr_v1-app_code_jump_vector = entry_point;
  
 - base_offset = fhdr_v1-app_dest_ptr + imxhdr-flash_offset ;
 - fhdr_v1-dcd_ptr_ptr =
 - (uint32_t) (offsetof(flash_header_v1_t, dcd_ptr) -
 - offsetof(flash_header_v1_t, app_code_jump_vector) +
 - base_offset);
 -
 - fhdr_v1-dcd_ptr = base_offset +
 - offsetof(imx_header_v1_t, dcd_table);
 -
 - /* The external flash header must be at the end of the DCD table */
 - dcd_v1-addr_data[dcd_len].type = sbuf-st_size +
 - imxhdr-flash_offset +
 - sizeof(struct imx_header);
 + fhdr_v1-dcd_ptr_ptr = hdr_base + offsetof(flash_header_v1_t, dcd_ptr);
 + fhdr_v1-dcd_ptr = hdr_base + offsetof(imx_header_v1_t, dcd_table);
  
   /* Security feature are not supported */
   fhdr_v1-app_code_csf = 0;
   fhdr_v1-super_root_key = 0;
 + return header_length;
 +}
 +

Ok, I skip review of this part - it depends on your answer on the
previous question.

  
 -static void set_imx_hdr_v2(struct imx_header *imxhdr, uint32_t dcd_len,
 - struct stat *sbuf,
 - struct mkimage_params *params)
 +static int set_imx_hdr_v2(struct imx_header *imxhdr, uint32_t dcd_len,
 + uint32_t entry_point, uint32_t flash_offset)
  {
   imx_header_v2_t *hdr_v2 = imxhdr-header.hdr_v2;
   flash_header_v2_t *fhdr_v2 = hdr_v2-fhdr;
 -
 -

Re: [U-Boot] [PATCH V2 02/21] imximage: check dcd_len as entries added

2012-09-23 Thread Stefano Babic
On 22/09/2012 04:38, Troy Kisky wrote:
 Before the len was checked after the entire file
 was processed, so it could have already overflowed.
 

Hi Troy,

 Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com
 ---
  tools/imximage.c |   26 +++---
  1 file changed, 11 insertions(+), 15 deletions(-)
 
 diff --git a/tools/imximage.c b/tools/imximage.c
 index 25d3b74..0bfbec3 100644
 --- a/tools/imximage.c
 +++ b/tools/imximage.c
 @@ -71,6 +71,7 @@ static set_dcd_val_t set_dcd_val;
  static set_dcd_rst_t set_dcd_rst;
  static set_imx_hdr_t set_imx_hdr;
  static set_imx_size_t set_imx_size;
 +static uint32_t max_dcd_entries;
  static uint32_t g_flash_offset;
  
  static struct image_type_params imximage_params;
 @@ -173,13 +174,6 @@ static void set_dcd_rst_v1(struct imx_header *imxhdr, 
 uint32_t dcd_len,
  {
   dcd_v1_t *dcd_v1 = imxhdr-header.hdr_v1.dcd_table;
  
 - if (dcd_len  MAX_HW_CFG_SIZE_V1) {
 - fprintf(stderr, Error: %s[%d] -
 - DCD table exceeds maximum size(%d)\n,
 - name, lineno, MAX_HW_CFG_SIZE_V1);
 - exit(EXIT_FAILURE);
 - }
 -
   dcd_v1-preamble.barker = DCD_BARKER;
   dcd_v1-preamble.length = dcd_len * sizeof(dcd_type_addr_data_t);
  }
 @@ -193,13 +187,6 @@ static void set_dcd_rst_v2(struct imx_header *imxhdr, 
 uint32_t dcd_len,
  {
   dcd_v2_t *dcd_v2 = imxhdr-header.hdr_v2.dcd_table;
  
 - if (dcd_len  MAX_HW_CFG_SIZE_V2) {
 - fprintf(stderr, Error: %s[%d] -
 - DCD table exceeds maximum size(%d)\n,
 - name, lineno, MAX_HW_CFG_SIZE_V2);
 - exit(EXIT_FAILURE);
 - }
 -
   dcd_v2-header.tag = DCD_HEADER_TAG;
   dcd_v2-header.length = cpu_to_be16(
   dcd_len * sizeof(dcd_addr_data_t) + 8);
 @@ -293,12 +280,14 @@ static void set_hdr_func(struct imx_header *imxhdr)
   set_dcd_rst = set_dcd_rst_v1;
   set_imx_hdr = set_imx_hdr_v1;
   set_imx_size = set_imx_size_v1;
 + max_dcd_entries = MAX_HW_CFG_SIZE_V1;
   break;
   case IMXIMAGE_V2:
   set_dcd_val = set_dcd_val_v2;
   set_dcd_rst = set_dcd_rst_v2;
   set_imx_hdr = set_imx_hdr_v2;
   set_imx_size = set_imx_size_v2;
 + max_dcd_entries = MAX_HW_CFG_SIZE_V2;
   break;
   default:
   err_imximage_version(imximage_version);
 @@ -425,8 +414,15 @@ static void parse_cfg_fld(struct imx_header *imxhdr, 
 int32_t *cmd,
   value = get_cfg_value(token, name, lineno);
   (*set_dcd_val)(imxhdr, name, lineno, fld, value, *dcd_len);
  
 - if (fld == CFG_REG_VALUE)
 + if (fld == CFG_REG_VALUE) {
   (*dcd_len)++;
 + if (*dcd_len  max_dcd_entries) {
 + fprintf(stderr, Error: %s[%d] -
 + DCD table exceeds maximum size(%d)\n,
 + name, lineno, max_dcd_entries);
 + exit(EXIT_FAILURE);
 + }
 + }
   break;
   default:
   break;
 

This patch seems to me unrelated to the rest, and fixes the case when
too much DCD entries are put into the imximage.cfg file. What about to
rebase it on the current code and post it as separate patch ? I think
this can be merged directly, also in the current realease.

Best regards,
Stefano Babic

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


Re: [U-Boot] [PATCH V2 04/21] imximage: cleanup parsing

2012-09-23 Thread Stefano Babic
On 22/09/2012 04:39, Troy Kisky wrote:
 Move to pulling tokens instead of pushing them.
 Remove need for switch statements to process commands.
 Add error messages such as command not finished,
 extra data at end of line, and invalid token
 Add ';' as command separator.
 
 Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com
 ---

Hi Troy,

you add code in previous patch and you remove it in this one. This makes
quite difficult to review them.

Normally, we do do have this case, and code is not added and removed in
the same patches series. Should you not squash patches together and / or
rearrange them with different topic ?

Best regards,
Stefano Babic


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


[U-Boot] [PATCH 1/2] mx25: add CPU revision 1.2

2012-09-23 Thread Eric Bénard
tested on a MCIMX257CJM4A which now reports :
CPU:   Freescale i.MX25 rev1.2 at 399 MHz

Signed-off-by: Eric Bénard e...@eukrea.com
Acked-by: Otavio Salvador ota...@ossystems.com.br
---
v2 : rebased against 2012.10-rc1, added Otavio's ack

 arch/arm/cpu/arm926ejs/mx25/generic.c |3 +++
 arch/arm/include/asm/arch-mx25/imx-regs.h |1 +
 2 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/mx25/generic.c 
b/arch/arm/cpu/arm926ejs/mx25/generic.c
index a5c15ce..3b7f327 100644
--- a/arch/arm/cpu/arm926ejs/mx25/generic.c
+++ b/arch/arm/cpu/arm926ejs/mx25/generic.c
@@ -140,6 +140,9 @@ u32 get_cpu_rev(void)
case 0x01:
system_rev |= CHIP_REV_1_1;
break;
+   case 0x02:
+   system_rev |= CHIP_REV_1_2;
+   break;
default:
system_rev |= 0x8000;
break;
diff --git a/arch/arm/include/asm/arch-mx25/imx-regs.h 
b/arch/arm/include/asm/arch-mx25/imx-regs.h
index 672f9d7..e780296 100644
--- a/arch/arm/include/asm/arch-mx25/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx25/imx-regs.h
@@ -357,5 +357,6 @@ struct aips_regs {
 
 #define CHIP_REV_1_0   0x10
 #define CHIP_REV_1_1   0x11
+#define CHIP_REV_1_2   0x12
 
 #endif /* _IMX_REGS_H */
-- 
1.7.7.6

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


[U-Boot] [PATCH v2 1/2] mx25: add CPU revision 1.2

2012-09-23 Thread Eric Bénard
tested on a MCIMX257CJM4A which now reports :
CPU:   Freescale i.MX25 rev1.2 at 399 MHz

Signed-off-by: Eric Bénard e...@eukrea.com
Acked-by: Otavio Salvador ota...@ossystems.com.br
---
v2 : rebased against 2012.10-rc1, added Otavio's ack

 arch/arm/cpu/arm926ejs/mx25/generic.c |3 +++
 arch/arm/include/asm/arch-mx25/imx-regs.h |1 +
 2 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/mx25/generic.c 
b/arch/arm/cpu/arm926ejs/mx25/generic.c
index a5c15ce..3b7f327 100644
--- a/arch/arm/cpu/arm926ejs/mx25/generic.c
+++ b/arch/arm/cpu/arm926ejs/mx25/generic.c
@@ -140,6 +140,9 @@ u32 get_cpu_rev(void)
case 0x01:
system_rev |= CHIP_REV_1_1;
break;
+   case 0x02:
+   system_rev |= CHIP_REV_1_2;
+   break;
default:
system_rev |= 0x8000;
break;
diff --git a/arch/arm/include/asm/arch-mx25/imx-regs.h 
b/arch/arm/include/asm/arch-mx25/imx-regs.h
index 672f9d7..e780296 100644
--- a/arch/arm/include/asm/arch-mx25/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx25/imx-regs.h
@@ -357,5 +357,6 @@ struct aips_regs {
 
 #define CHIP_REV_1_0   0x10
 #define CHIP_REV_1_1   0x11
+#define CHIP_REV_1_2   0x12
 
 #endif /* _IMX_REGS_H */
-- 
1.7.7.6

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


[U-Boot] [PATCH v2 2/2] add Eukrea's CPUIMX25

2012-09-23 Thread Eric Bénard
this board is based on an i.MX25 from Freescale.
It consists of a SOM containing :
- NAND flash (internal or external boot supported and tested)
- mDDR (64MB tested)
- ethernet PHY connected in RMII mode (tested)
and a baseboard containing :
- a serial transceiver on UART1 (tested)
- a SDCard connector on eSDHC1 (tested but disabled until Benoît's fix
  gets applied)

bootlog :
U-Boot 2012.10-rc1-3-gdd12be5 (Sep 23 2012 - 13:53:21)

CPU:   Freescale i.MX25 rev1.2 at 399 MHz
Reset cause: POR

DRAM:  64 MiB
NAND:  256 MiB
MMC:
In:serial
Out:   serial
Err:   serial
Net:   FEC
Hit any key to stop autoboot:  0

Signed-off-by: Eric Bénard e...@eukrea.com
---
v2: rebased against 2012.10-rc1, disabled eSDHC until proper fix
from Benoît gets applied, updated bootlog.

 MAINTAINERS   |2 +
 board/eukrea/cpuimx25/Makefile|   44 +++
 board/eukrea/cpuimx25/config.mk   |5 +
 board/eukrea/cpuimx25/cpuimx25.c  |  123 ++
 board/eukrea/cpuimx25/imximage.cfg|   55 
 board/eukrea/cpuimx25/lowlevel_init.S |  113 
 boards.cfg|2 +
 include/configs/cpuimx25.h|  198 +
 nand_spl/board/eukrea/cpuimx25/Makefile   |   79 
 nand_spl/board/eukrea/cpuimx25/config.mk  |1 +
 nand_spl/board/eukrea/cpuimx25/u-boot.lds |   83 
 11 files changed, 705 insertions(+), 0 deletions(-)
 create mode 100644 board/eukrea/cpuimx25/Makefile
 create mode 100644 board/eukrea/cpuimx25/config.mk
 create mode 100644 board/eukrea/cpuimx25/cpuimx25.c
 create mode 100644 board/eukrea/cpuimx25/imximage.cfg
 create mode 100644 board/eukrea/cpuimx25/lowlevel_init.S
 create mode 100644 include/configs/cpuimx25.h
 create mode 100644 nand_spl/board/eukrea/cpuimx25/Makefile
 create mode 100644 nand_spl/board/eukrea/cpuimx25/config.mk
 create mode 100644 nand_spl/board/eukrea/cpuimx25/u-boot.lds

diff --git a/MAINTAINERS b/MAINTAINERS
index aa54fe1..94e759f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -606,6 +606,8 @@ Eric Benard e...@eukrea.com
cpuat91 ARM920T
cpu9260 ARM926EJS (AT91SAM9260 SoC)
cpu9G20 ARM926EJS (AT91SAM9G20 SoC)
+   cpuimx25i.MX25
+   cpuimx25nandi.MX25
 
 Ajay Bhargav ajay.bhar...@einfochips.com
 
diff --git a/board/eukrea/cpuimx25/Makefile b/board/eukrea/cpuimx25/Makefile
new file mode 100644
index 000..46131fd
--- /dev/null
+++ b/board/eukrea/cpuimx25/Makefile
@@ -0,0 +1,44 @@
+#
+# (C) Copyright 2009 DENX Software Engineering
+# Author: John Rigby jcri...@gmail.com
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that 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., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS  := cpuimx25.o
+SOBJS  := lowlevel_init.o
+
+SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS))
+SOBJS  := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+   $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+#
+
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/eukrea/cpuimx25/config.mk b/board/eukrea/cpuimx25/config.mk
new file mode 100644
index 000..18b2883
--- /dev/null
+++ b/board/eukrea/cpuimx25/config.mk
@@ -0,0 +1,5 @@
+ifdef CONFIG_NAND_SPL
+CONFIG_SYS_TEXT_BASE = 0x810c
+else
+CONFIG_SYS_TEXT_BASE = 0x8120
+endif
diff --git a/board/eukrea/cpuimx25/cpuimx25.c b/board/eukrea/cpuimx25/cpuimx25.c
new file mode 100644
index 000..72fa8a5
--- /dev/null
+++ b/board/eukrea/cpuimx25/cpuimx25.c
@@ -0,0 +1,123 @@
+/*
+ * (C) Copyright 2009 DENX Software Engineering
+ * (C) Copyright 2012 Eukrea Electromatique www.eukrea.com
+ * Eric Benard e...@eukrea.com
+ *
+ * Based on tx25.c:
+ *   Author: John Rigby jri...@gmail.com
+ *
+ * Based on imx27lite.c:
+ *   Copyright (C) 2008,2009 Eric Jarrige jora...@users.sourceforge.net
+ *   Copyright (C) 2009 Ilya Yanok ya...@emcraft.com
+ * And:
+ *   RedBoot tx25_misc.c Copyright (C) 2009 Red Hat
+ *
+ * This program is free software; you can 

Re: [U-Boot] [PATCH v6] [RFC] early_malloc for DM added.

2012-09-23 Thread Graeme Russ
On Sep 23, 2012 8:09 AM, Tomas Hlavacek tmshl...@gmail.com wrote:

 early_malloc for DM with support for more heaps and lightweight
 first heap in the same memory as an early stack.

 Adaptation layer for seamless calling of early_malloc or dlmalloc from
 DM based on init stage added (dmmalloc() and related functions).

 Signed-off-by: Tomas Hlavacek tmshl...@gmail.com
 ---

[snip]

 +#ifdef CONFIG_SYS_EARLY_MALLOC
 +__weak struct early_heap_header *early_brk(size_t size)
 +{
 +   struct early_heap_header *h =
 +   (struct early_heap_header *)CONFIG_SYS_EARLY_HEAP_ADDR;
 +   struct early_heap_header *ehp = gd-early_heap_first;
 +
 +   while (ehp != NULL) {
 +   if (ehp == h)
 +   return NULL;
 +
 +   ehp = ehp-next_early_heap;
 +   }

if (g-early_heap_first == NULL)
h = CONFIF_SYS_EARLY_HEAP_ADDR);
else
return NULL;

 +
 +   h-free_space_pointer = (void *)(roundup(
 +   (phys_addr_t)CONFIG_SYS_EARLY_HEAP_ADDR +
 +   sizeof(struct early_heap_header),
 +   sizeof(phys_addr_t)));
 +   h-free_bytes = size - roundup(sizeof(struct early_heap_header),
 +   sizeof(phys_addr_t));
 +   h-next_early_heap = NULL;
 +
 +   return h;
 +}

Regards,

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


[U-Boot] [PATCH v2 0/6] Add h2200 support and pxa25x ethernet gadget

2012-09-23 Thread Lukasz Dalek
Patch 2/6 (usbethernet support) was revied. I've added only simple
noisy defintion (at the end of patch).

+#ifndef DEBUG
+# define NOISY 0
+#endif

Patch 3/6 was also revied.

Lukasz Dalek (6):
  h2200: Add support for iPAQ h2200 palmtop
  pxa25x: Add support for USB ethernet gadget
  pxa: Add some stuff to examine cpu model and rev
  usbether: Fixed bug when using with PXA25X chips
  usbether: Define CONFIG_USB_ETH_{CDC,SUBSET}
  usbether: Removed DEV_CONFIG_{CDC,SUBSET}

 arch/arm/cpu/pxa/cpuinfo.c  |   11 +-
 arch/arm/include/asm/arch-pxa/pxa.h |   13 +
 board/h2200/Makefile|   51 +
 board/h2200/h2200-header.S  |   27 +
 board/h2200/h2200.c |   66 ++
 board/h2200/h2200.h |   28 +
 boards.cfg  |2 +
 drivers/usb/gadget/Makefile |1 +
 drivers/usb/gadget/ether.c  |   69 +-
 drivers/usb/gadget/pxa25x_udc.c | 2059 +++
 drivers/usb/gadget/pxa25x_udc.h |  162 +++
 include/configs/h2200.h |  189 
 12 files changed, 2646 insertions(+), 32 deletions(-)
 create mode 100644 board/h2200/Makefile
 create mode 100644 board/h2200/h2200-header.S
 create mode 100644 board/h2200/h2200.c
 create mode 100644 board/h2200/h2200.h
 create mode 100644 drivers/usb/gadget/pxa25x_udc.c
 create mode 100644 drivers/usb/gadget/pxa25x_udc.h
 create mode 100644 include/configs/h2200.h

-- 
1.7.8.6

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


[U-Boot] [PATCH v2 1/6] h2200: Add support for iPAQ h2200 palmtop

2012-09-23 Thread Lukasz Dalek
Basic support of HP iPAQ h2200 palmtop. Support includes also USB
ethernet gadget.

Signed-off-by: Lukasz Dalek luk0...@gmail.com
---
 board/h2200/Makefile   |   51 
 board/h2200/h2200-header.S |   27 ++
 board/h2200/h2200.c|   66 +++
 board/h2200/h2200.h|   28 +++
 boards.cfg |2 +
 include/configs/h2200.h|  189 
 6 files changed, 363 insertions(+), 0 deletions(-)
 create mode 100644 board/h2200/Makefile
 create mode 100644 board/h2200/h2200-header.S
 create mode 100644 board/h2200/h2200.c
 create mode 100644 board/h2200/h2200.h
 create mode 100644 include/configs/h2200.h

diff --git a/board/h2200/Makefile b/board/h2200/Makefile
new file mode 100644
index 000..2265aa9
--- /dev/null
+++ b/board/h2200/Makefile
@@ -0,0 +1,51 @@
+#
+# h2200 Support
+#
+# Copyright (C) 2012 Lukasz Dalek luk0...@gmail.com
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that 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., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS  := h2200.o
+
+SRCS   := $(COBJS:.o=.c) h2200-header.S
+OBJS   := $(addprefix $(obj),$(COBJS))
+
+ALL: $(LIB) h2200-header.bin
+
+h2200-header.o: h2200-header.S
+   $(CC) $(CFLAGS) -c -o $@ $
+
+h2200-header.bin: h2200-header.o
+   $(OBJCOPY) -O binary $ $@
+
+all: $(LIB) h2200-header.bin
+
+$(LIB):$(obj).depend $(OBJS)
+   $(call cmd_link_o_target, $(OBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/h2200/h2200-header.S b/board/h2200/h2200-header.S
new file mode 100644
index 000..c335bfe
--- /dev/null
+++ b/board/h2200/h2200-header.S
@@ -0,0 +1,27 @@
+/*
+ * iPAQ h2200 header
+ *
+ * Copyright (C) 2012 Lukasz Dalek luk0...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that 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., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+   .word 0xea0003fe /* b 0x1000 */
+
+   .org 0x40
+   .ascii ECEC
+
+   .org 0x1000 - 1
+   .byte 0x0
diff --git a/board/h2200/h2200.c b/board/h2200/h2200.c
new file mode 100644
index 000..a6b1c48
--- /dev/null
+++ b/board/h2200/h2200.c
@@ -0,0 +1,66 @@
+/*
+ * iPAQ h2200 board configuration
+ *
+ * Copyright (C) 2012 Lukasz Dalek luk0...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that 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., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+#include common.h
+#include asm/arch/pxa.h
+#include asm/arch/pxa-regs.h
+#include asm/io.h
+#include h2200.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#ifdef CONFIG_H2200_USBETH
+int board_eth_init(bd_t *bis)
+{
+   usb_eth_initialize(bis);
+   return 0;
+}
+#endif
+
+int board_init(void)
+{
+   /* We have RAM, disable cache */
+   dcache_disable();
+   icache_disable();
+
+   gd-bd-bi_arch_number = MACH_TYPE_H2200;
+
+   /* adress of boot parameters */
+   gd-bd-bi_boot_params = 0xa100;
+
+   /* 

[U-Boot] [PATCH v2 3/6] pxa: Add some stuff to examine cpu model and rev

2012-09-23 Thread Lukasz Dalek
Add function which return CPU model and revision which can be used for
cpu detection.

Signed-off-by: Lukasz Dalek luk0...@gmail.com
---
 arch/arm/cpu/pxa/cpuinfo.c  |   11 +--
 arch/arm/include/asm/arch-pxa/pxa.h |   13 +
 2 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/pxa/cpuinfo.c b/arch/arm/cpu/pxa/cpuinfo.c
index f1cdd40..bab6340 100644
--- a/arch/arm/cpu/pxa/cpuinfo.c
+++ b/arch/arm/cpu/pxa/cpuinfo.c
@@ -24,9 +24,11 @@
 #include errno.h
 #include linux/compiler.h
 
-#defineCPU_MASK_PXA_REVID  0x00f
+#defineCPU_MASK_PXA_PRODID 0x03f0
+#defineCPU_MASK_PXA_REVID  0x000f
+
+#defineCPU_MASK_PRODREV(CPU_MASK_PXA_PRODID | 
CPU_MASK_PXA_REVID)
 
-#defineCPU_MASK_PXA_PRODID 0x3f0
 #defineCPU_VALUE_PXA25X0x100
 #defineCPU_VALUE_PXA27X0x110
 
@@ -51,6 +53,11 @@ int cpu_is_pxa27x(void)
return id == CPU_VALUE_PXA27X;
 }
 
+uint32_t pxa_get_cpu_revision(void)
+{
+   return pxa_get_cpuid()  CPU_MASK_PRODREV;
+}
+
 #ifdef CONFIG_DISPLAY_CPUINFO
 static const char *pxa25x_get_revision(void)
 {
diff --git a/arch/arm/include/asm/arch-pxa/pxa.h 
b/arch/arm/include/asm/arch-pxa/pxa.h
index 49c6552..b67d8f2 100644
--- a/arch/arm/include/asm/arch-pxa/pxa.h
+++ b/arch/arm/include/asm/arch-pxa/pxa.h
@@ -22,8 +22,21 @@
 #ifndef__PXA_H__
 #define__PXA_H__
 
+#define PXA255_A0  0x0106
+#define PXA250_C0  0x0105
+#define PXA250_B2  0x0104
+#define PXA250_B1  0x0103
+#define PXA250_B0  0x0102
+#define PXA250_A1  0x0101
+#define PXA250_A0  0x0100
+#define PXA210_C0  0x0125
+#define PXA210_B2  0x0124
+#define PXA210_B1  0x0123
+#define PXA210_B0  0x0122
+
 int cpu_is_pxa25x(void);
 int cpu_is_pxa27x(void);
+uint32_t pxa_get_cpu_revision(void);
 void pxa2xx_dram_init(void);
 
 #endif /* __PXA_H__ */
-- 
1.7.8.6

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


[U-Boot] [PATCH v2 4/6] usbether: Fixed bug when using with PXA25X chips

2012-09-23 Thread Lukasz Dalek
PXA25X chips don't support alternate settings so driver uses non-CDC
driver.
But only code defined between DEV_CONFIG_CDC signals that network is up.
This patch is fixing this bug by signaling that network is up after USB
SET_INTERFACE request.

Signed-off-by: Lukasz Dalek luk0...@gmail.com
---
 drivers/usb/gadget/ether.c |   17 -
 1 files changed, 16 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index d975fb6..9ce2c17 100644
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -44,7 +44,12 @@ extern struct platform_data brd;
 
 unsigned packet_received, packet_sent;
 
-#define DEV_CONFIG_CDC 1
+#ifdef CONFIG_USB_GADGET_PXA2XX
+# undef DEV_CONFIG_CDC
+# define DEV_CONFIG_SUBSET 1
+#else
+# define DEV_CONFIG_CDC1
+#endif
 #define GFP_ATOMIC ((gfp_t) 0)
 #define GFP_KERNEL ((gfp_t) 0)
 
@@ -864,7 +869,9 @@ static struct usb_gadget_stringsstringtab = {
 
 
/**/
 static u8 control_req[USB_BUFSIZ];
+#if defined(DEV_CONFIG_CDC) || defined(CONFIG_USB_ETH_RNDIS)
 static u8 status_req[STATUS_BYTECOUNT] __attribute__ ((aligned(4)));
+#endif
 
 
 /**
@@ -1352,6 +1359,14 @@ eth_setup(struct usb_gadget *gadget, const struct 
usb_ctrlrequest *ctrl)
if (gadget_is_pxa(gadget)) {
value = eth_set_config(dev, DEV_CONFIG_VALUE,
GFP_ATOMIC);
+   /*
+* PXA25x driver use non-CDC ethernet gadget.
+* But only _CDC and _RNDIS code can signalize
+* that network is working. So we signalize it
+* here.
+*/
+   l_ethdev.network_started = 1;
+   debug(USB network up!\n);
goto done_set_intf;
}
 
-- 
1.7.8.6

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


[U-Boot] [PATCH v2 5/6] usbether: Define CONFIG_USB_ETH_{CDC, SUBSET}

2012-09-23 Thread Lukasz Dalek
Introduced CONFIG_USB_ETH_CDC and CONFIG_USB_ETH_SUBSET as preparation
for removal DEV_CONFIG_CDC and DEV_CONFIG_SUBSET

Signed-off-by: Lukasz Dalek luk0...@gmail.com
---
 drivers/usb/gadget/ether.c |   19 ++-
 1 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index 9ce2c17..7e6491d 100644
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -44,12 +44,21 @@ extern struct platform_data brd;
 
 unsigned packet_received, packet_sent;
 
-#ifdef CONFIG_USB_GADGET_PXA2XX
-# undef DEV_CONFIG_CDC
-# define DEV_CONFIG_SUBSET 1
-#else
-# define DEV_CONFIG_CDC1
+#undef DEV_CONFIG_CDC
+#undef DEV_CONFIG_SUBSET
+
+#if !defined(CONFIG_USB_ETH_CDC)  !defined(CONFIG_USB_ETH_SUBSET)
+# define DEV_CONFIG_CDC1   /* preserve default behavior */
+#endif
+
+#if defined(CONFIG_USB_ETH_CDC)
+# define DEV_CONFIG_CDC1
 #endif
+
+#if defined(CONFIG_USB_ETH_SUBSET)
+# define DEV_CONFIG_SUBSET 1
+#endif
+
 #define GFP_ATOMIC ((gfp_t) 0)
 #define GFP_KERNEL ((gfp_t) 0)
 
-- 
1.7.8.6

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


[U-Boot] [PATCH v2 6/6] usbether: Removed DEV_CONFIG_{CDC,SUBSET}

2012-09-23 Thread Lukasz Dalek
Removed DEV_CONFIG_CDC and DEV_CONFIG_SUBSET and replaced it with
CONFIG_USB_ETH_CDC and CONFIG_USB_ETH_SUBSET.

Signed-off-by: Lukasz Dalek luk0...@gmail.com
---
 drivers/usb/gadget/ether.c |   75 +--
 1 files changed, 30 insertions(+), 45 deletions(-)

diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index 7e6491d..1e187e5 100644
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -44,21 +44,6 @@ extern struct platform_data brd;
 
 unsigned packet_received, packet_sent;
 
-#undef DEV_CONFIG_CDC
-#undef DEV_CONFIG_SUBSET
-
-#if !defined(CONFIG_USB_ETH_CDC)  !defined(CONFIG_USB_ETH_SUBSET)
-# define DEV_CONFIG_CDC1   /* preserve default behavior */
-#endif
-
-#if defined(CONFIG_USB_ETH_CDC)
-# define DEV_CONFIG_CDC1
-#endif
-
-#if defined(CONFIG_USB_ETH_SUBSET)
-# define DEV_CONFIG_SUBSET 1
-#endif
-
 #define GFP_ATOMIC ((gfp_t) 0)
 #define GFP_KERNEL ((gfp_t) 0)
 
@@ -174,9 +159,9 @@ static struct usb_gadget_driver eth_driver;
 /* main config is either CDC, or its simple subset */
 static inline int is_cdc(struct eth_dev *dev)
 {
-#if!defined(DEV_CONFIG_SUBSET)
+#if!defined(CONFIG_USB_ETH_SUBSET)
return 1;   /* only cdc possible */
-#elif  !defined(DEV_CONFIG_CDC)
+#elif  !defined(CONFIG_USB_ETH_CDC)
return 0;   /* only subset possible */
 #else
return dev-cdc;/* depends on what hardware we found */
@@ -420,7 +405,7 @@ rndis_config = {
  * get those drivers from MCCI, or bundled with various products.
  */
 
-#ifdef DEV_CONFIG_CDC
+#ifdef CONFIG_USB_ETH_CDC
 static struct usb_interface_descriptor
 control_intf = {
.bLength =  sizeof control_intf,
@@ -459,7 +444,7 @@ static const struct usb_cdc_header_desc header_desc = {
.bcdCDC =   __constant_cpu_to_le16(0x0110),
 };
 
-#if defined(DEV_CONFIG_CDC) || defined(CONFIG_USB_ETH_RNDIS)
+#if defined(CONFIG_USB_ETH_CDC) || defined(CONFIG_USB_ETH_RNDIS)
 
 static const struct usb_cdc_union_desc union_desc = {
.bLength =  sizeof union_desc,
@@ -493,7 +478,7 @@ static const struct usb_cdc_acm_descriptor acm_descriptor = 
{
 
 #endif
 
-#ifndef DEV_CONFIG_CDC
+#ifndef CONFIG_USB_ETH_CDC
 
 /*
  * SAFE loosely follows CDC WMC MDLM, violating the spec in various
@@ -543,7 +528,7 @@ static const struct usb_cdc_ether_desc ether_desc = {
.bNumberPowerFilters =  0,
 };
 
-#if defined(DEV_CONFIG_CDC) || defined(CONFIG_USB_ETH_RNDIS)
+#if defined(CONFIG_USB_ETH_CDC) || defined(CONFIG_USB_ETH_RNDIS)
 
 /*
  * include the status endpoint if we can, even where it's optional.
@@ -575,7 +560,7 @@ fs_status_desc = {
 };
 #endif
 
-#ifdef DEV_CONFIG_CDC
+#ifdef CONFIG_USB_ETH_CDC
 
 /* the default data interface has no endpoints ... */
 
@@ -630,7 +615,7 @@ rndis_data_intf = {
 
 #endif
 
-#ifdef DEV_CONFIG_SUBSET
+#ifdef CONFIG_USB_ETH_SUBSET
 
 /*
  * Simple CDC-subset option is a simple vendor-neutral model that most
@@ -676,7 +661,7 @@ fs_sink_desc = {
 
 static const struct usb_descriptor_header *fs_eth_function[11] = {
(struct usb_descriptor_header *) otg_descriptor,
-#ifdef DEV_CONFIG_CDC
+#ifdef CONFIG_USB_ETH_CDC
/* cdc mode descriptors */
(struct usb_descriptor_header *) control_intf,
(struct usb_descriptor_header *) header_desc,
@@ -690,12 +675,12 @@ static const struct usb_descriptor_header 
*fs_eth_function[11] = {
(struct usb_descriptor_header *) fs_source_desc,
(struct usb_descriptor_header *) fs_sink_desc,
NULL,
-#endif /* DEV_CONFIG_CDC */
+#endif /* CONFIG_USB_ETH_CDC */
 };
 
 static inline void fs_subset_descriptors(void)
 {
-#ifdef DEV_CONFIG_SUBSET
+#ifdef CONFIG_USB_ETH_SUBSET
/* behavior is CDC Subset; extra descriptors say SAFE */
fs_eth_function[1] = (struct usb_descriptor_header *) subset_data_intf;
fs_eth_function[2] = (struct usb_descriptor_header *) header_desc;
@@ -733,7 +718,7 @@ static const struct usb_descriptor_header 
*fs_rndis_function[] = {
  * descriptors, unless they only run at full speed.
  */
 
-#if defined(DEV_CONFIG_CDC) || defined(CONFIG_USB_ETH_RNDIS)
+#if defined(CONFIG_USB_ETH_CDC) || defined(CONFIG_USB_ETH_RNDIS)
 static struct usb_endpoint_descriptor
 hs_status_desc = {
.bLength =  USB_DT_ENDPOINT_SIZE,
@@ -743,7 +728,7 @@ hs_status_desc = {
.wMaxPacketSize =   __constant_cpu_to_le16(STATUS_BYTECOUNT),
.bInterval =LOG2_STATUS_INTERVAL_MSEC + 4,
 };
-#endif /* DEV_CONFIG_CDC */
+#endif /* CONFIG_USB_ETH_CDC */
 
 static struct usb_endpoint_descriptor
 hs_source_desc = {
@@ -776,7 +761,7 @@ dev_qualifier = {
 
 static const struct usb_descriptor_header *hs_eth_function[11] = {
(struct usb_descriptor_header *) otg_descriptor,
-#ifdef DEV_CONFIG_CDC
+#ifdef CONFIG_USB_ETH_CDC
/* cdc mode descriptors */
(struct usb_descriptor_header *) 

[U-Boot] [PATCH] env: remove duplicated env_get_char_spec()

2012-09-23 Thread Igor Grinberg
env_fat and env_remote have an implementation of env_get_char_spec()
function that is not different than the default.
Remove the duplicated code.

Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
 common/env_fat.c|5 -
 common/env_remote.c |5 -
 2 files changed, 0 insertions(+), 10 deletions(-)

diff --git a/common/env_fat.c b/common/env_fat.c
index bad92aa..ca76967 100644
--- a/common/env_fat.c
+++ b/common/env_fat.c
@@ -40,11 +40,6 @@ env_t *env_ptr;
 
 DECLARE_GLOBAL_DATA_PTR;
 
-uchar env_get_char_spec(int index)
-{
-   return *((uchar *)(gd-env_addr + index));
-}
-
 int env_init(void)
 {
/* use default */
diff --git a/common/env_remote.c b/common/env_remote.c
index 3bf0f95..87af1936 100644
--- a/common/env_remote.c
+++ b/common/env_remote.c
@@ -41,11 +41,6 @@ DECLARE_GLOBAL_DATA_PTR;
 #define CONFIG_ENV_OFFSET 0
 #endif
 
-uchar env_get_char_spec(int index)
-{
-   return *((uchar *)(gd-env_addr + index));
-}
-
 int env_init(void)
 {
if (crc32(0, env_ptr-data, ENV_SIZE) == env_ptr-crc) {
-- 
1.7.3.4

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


Re: [U-Boot] [PATCH V2 05/21] imximage: add expression evaluation

2012-09-23 Thread Stefano Babic
On 22/09/2012 04:39, Troy Kisky wrote:
 Basic expressions with order precedence is
 now supported.
 ie. (3 + ((1+2*3)/--2 + --5 *(8/4))) is 16.
 
 Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com
 ---

Hi Troy,

  tools/imximage.c |  172 
 ++
  1 file changed, 162 insertions(+), 10 deletions(-)
 
 diff --git a/tools/imximage.c b/tools/imximage.c
 index 1e120354..2c5a622 100644

I have some general considerations. First, if you plan to add support
for expression evaluation, this feature should be available generally
for mkimage, that means also other processors / architecture can profit
of it. It should be moved away from imximage.c code.

Then, you want also let that the preprocesso can parse the imximage
code. I can imagine that in such terms it could be then possible to
define in imximage.cfg something like:

#define DDR_VAL (1 17 | 3  7)
#define ADDRESS 0x0x53something

DATA 4 ADDRESS DDR_VAL

Else, why do we need the power of C preprocessor ?

If this is true, can you explain us which is the use case using the C
preprocessor and which is the one for the expression evaluator ? And why
do we need both ?


 --- a/tools/imximage.c
 +++ b/tools/imximage.c
 @@ -380,20 +380,172 @@ char *grab_token(char *dest, int size, char *src)
   return src;
  }
  
 +char precedence[] = {
 + /* (  +  -  *  /^  |  ) */
 +0, 2, 2, 1, 1, 3, 4, 5, 6
 +};
 +char unary_operations[]  = (+-;
 +char binary_operations[] =  +-*/^|);
 +
 +uint32_t do_func(uint32_t val1, uint32_t val2, int op)
 +{
 + switch (op) {
 + case 1:
 + return val1 + val2;
 + case 2:
 + return val1 - val2;
 + case 3:
 + return val1 * val2;
 + case 4:
 + return val1 / val2;
 + case 5:
 + return val1  val2;
 + case 6:
 + return val1 ^ val2;
 + case 7:
 + return val1 | val2;
 + }
 + fprintf(stderr, Error: in func %s: val1=%d val2=%d op = %d\n,
 + __func__, val1, val2, op);
 + exit(EXIT_FAILURE);
 +}
 +
 +int find_op(char c, char *p)
 +{
 + int i;
 + for (i = 0; ; i++) {
 + if (c == p[i])
 + return i;
 + if (!p[i])
 + break;
 + }
 + return -1;
 +}
 +
 +#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
 +
  static uint32_t get_cfg_value(struct data_src *ds, uint32_t *pval)
  {
   char *endptr;
 - uint32_t value;
 + int op_i = 0;
 + int val_i = 0;
 + unsigned char op[16];
 + uint32_t val[16];
 + int unary = 1;
 + char *p;
  
 - if (skip_separators(ds))
 - return -1;
 - errno = 0;
 - value = strtoul(ds-p, endptr, 16);
 - if (errno || (ds-p == endptr))
 - return -1;
 - *pval = value;
 - ds-p = endptr;
 - return 0;
 + p = ds-p;
 + for (;;) {
 + char c;
 + int i, j;
 + char *ops = unary ? unary_operations : binary_operations;
 +
 + if (unary) {
 + ds-p = p;
 + if (skip_separators(ds))
 + return -1;
 + p = ds-p;
 + c = *p;
 + } else {
 + for (;;) {
 + c = *p;
 + if ((c != ' ')  (c != '\t'))
 + break;
 + p++;
 + }
 + }
 + i = find_op(c, ops);
 + debug(%d,%c,%d:%s\n, i, c, unary, p);
 + if ((i  0)  unary) {
 + if (val_i = ARRAY_SIZE(val))
 + return -1;
 + errno = 0;
 + val[val_i++] = strtoul(p, endptr, 16);
 + if (errno || (p == endptr)) {
 + ds-p = p;
 + return -1;
 + }
 + p = endptr;
 + unary = 0;
 + debug(val[%d]=%x,%d,%d\n, val_i - 1, val[val_i - 1],
 + op_i, val_i);
 +do_unary:
 + while (op_i) {
 + j = op[op_i - 1];
 + if (!(j  0x80))
 + break;
 + op_i--;
 + val[val_i - 1] = do_func(0,
 + val[val_i - 1], j  0x7f);
 + debug(un:%d,%x,%d,%d\n, val[val_i - 1], j,
 + op_i, val_i);
 + }
 + continue;
 + }
 + if (i  0) {
 + c = 0;
 + i = 8;
 + } else {
 + p++;
 + }
 + if (c == '(') {
 +   

Re: [U-Boot] [PATCH V2 17/21] mx6: soc: add get_cpu_type

2012-09-23 Thread Stefano Babic
On 22/09/2012 19:07, Troy Kisky wrote:
 On 9/21/2012 7:50 PM, Fabio Estevam wrote:
 Hi Troy,

 On Fri, Sep 21, 2012 at 11:39 PM, Troy Kisky
 troy.ki...@boundarydevices.com wrote:
 Add function to return the processor type.

 i.e. MX6Q, MX6DL, MX6SOLO, MX6SOLOLITE
 On arch/arm/imx-common/cpu.c we have:

 static const char *get_imx_type(u32 imxtype)
 {
 switch (imxtype) {
 case 0x63:
 return 6Q;/* Quad-core version of the mx6 */
 case 0x61:
 return 6DS;/* Dual/Solo version of the mx6 */
 case 0x60:
 return 6SL;/* Solo-Lite version of the mx6 */
 case 0x51:
 return 51;
 case 0x53:
 return 53;
 default:
 return ??;
 }
 }

 ,which seems to serve the same purpose.

 Regards,

 Fabio Estevam

 
 No, not similar to get_imx_type, but it is similar to get_cpu_rev.
 
 I guess I should fix get_imx_type, and get_cpu_rev, instead of
 adding a new one.
 

Indeed. Try to use as much as possible code in imx-common, avoiding to
duplicate code.

Best regards,
Stefano

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


Re: [U-Boot] Please pull u-boot-mpc85xx (for v2012.10)

2012-09-23 Thread Andy Fleming
Argh, actually I think I sent the pull request, but it got stuck in our mail 
system, and I didn't notice. Thanks for sending this out, Kumar.

On Sep 22, 2012, at 9:09, Kumar Gala ga...@kernel.crashing.org wrote:

 Tom,
 
 Sorry for both sending this and the late request.  I think Andy's been 
 swamped with some chip bringup and lost notice of window (thus my sending 
 this request).  Would be good to get this stuff (and some fixes, etc) into 
 v2012.10.
 
 Thanks
 
 - k
 
 The following changes since commit ee1f4caaa2a3f79d692155eec8a4c7289d60e106:
  Tom Rini (1):
Prepare v2012.10-rc1
 
 are available in the git repository at:
 
  git://git.denx.de/u-boot-mpc85xx.git master
 
 Andy Fleming (1):
  Revert powerpc: Fix declaration type for I/O functions
 
 Joakim Tjernlund (2):
  mpc85xx: Initial SP alignment is wrong.
  powerpc: Stack Pointer not properly aligned
 
 Kumar Gala (3):
  Add e6500 processor detection
  Add IFC offset for DPAA/Corenet platforms
  Added new ext fields to IFC
 
 Liu Gang (6):
  powerpc/corenet_ds: Update README.srio-boot-corenet
  powerpc/corenet_ds: Get rid of the SRIOBOOT_MASTER build target
  powerpc/corenet_ds: Get rid of the CONFIG_SRIOBOOT_SLAVE_PORTx macro
  powerpc/corenet_ds: Update README and README.srio-pcie-boot-corenet
  powerpc/corenet_ds: Master module for boot from PCIE
  powerpc/corenet_ds: Slave module for boot from PCIE
 
 Matthew McClintock (6):
  p1014rdb: set ddr bus width properly depending on SVR
  p1010rdb: fix ddr values for p1014rdb (setting bus width to 16bit)
  powerpc/p1010rdb: nandboot: compare SVR properly
  nand_spl: update udelay for Freescale boards
  nand_spl: p1023rds: wait before enabling DDR controller
  nand_spl: change out_be32 to raw_writel and depend on subsequent sync
 
 Paul Gortmaker (1):
  mpc85xx: use LCRR_DBYP define instead of raw constant
 
 Prabhakar Kushwaha (2):
  powerpc/mpc85xx:Enable debugger support to missed e500v2 SoC
  powerpc/mpc85xx: Add IFC LAW target ID for FSL High-End SoC
 
 Scott Wood (6):
  nand/fsl_elbc: shrink SPL a bit by converting out_be32() to 
 __raw_writel()
  powerpc/fsl-corenet: remove dead variant symbols
  powerpc/fsl-corenet: work around erratum A004510
  powerpc/85xx: clear out TLB on boot
  powerpc/p1_p2_rdb_pc: print -PC suffix in board name
  powerpc/mpc85xx/p1_p2_rdb: add all LAWs during SPL
 
 Shaohui Xie (1):
  powerpc/CoreNet: add tool to support pbl image build.
 
 Timur Tabi (6):
  powerpc/85xx: add support for FM2 DTSEC5
  fm-eth: add function fm_info_get_phy_address()
  powerpc/85xx: introduce function serdes_device_from_fm_port()
  fm-eth: use fdt_status_disabled() function in ft_fixup_port()
  powerpc/85xx: get rid of enum board_slots in P4080 MDIO driver
  powerpc/85xx: remove support for the Freescale P3060
 
 York Sun (14):
  powerpc/mpc85xx: Make NMG_CPU_A011 workaround conditional
  powerpc/mpc8xxx: Remove P1015 and P1016 from CPU list
  powerpc/mpc8xxx: Add immap for topology and rcpm registers
  powerpc/mpc8xxx: use topology registers to calculate number of cores
  powerpc/mpc8xxx: fix core id for multicore booting
  powerpc/mpc85xx: Skip zero values for DDR debug registers
  powerpc/mpc8xxx: Add fine timing support for DDR3
  powerpc/mpc8xxx: Add support for cas latency 12 and above
  powerpc/mpc8xxx: Enable 3-way and 4-way DDR interleaving
  powerpc/mpc8xxx: Fix bug for extended DDR timing
  powerpc/mpc8xxx DDR: Fix CAS latency calculation
  powerpc/mpc8xxx DDR: Fall back to raw timing for first controller only
  powerpc/mpc8xxx DDR: Fix interactive DDR debugging
  powerpc/mpc8xxx: Move HWCONFIG_BUFFER_SIZE into config.h
 
 Makefile   |6 +
 README |   37 +-
 arch/powerpc/cpu/mpc85xx/Makefile  |   10 -
 arch/powerpc/cpu/mpc85xx/cmd_errata.c  |9 +-
 arch/powerpc/cpu/mpc85xx/cpu.c |   15 +-
 arch/powerpc/cpu/mpc85xx/cpu_init.c|   52 ++-
 arch/powerpc/cpu/mpc85xx/ddr-gen3.c|   26 +-
 arch/powerpc/cpu/mpc85xx/fdt.c |7 +-
 arch/powerpc/cpu/mpc85xx/fsl_corenet_serdes.c  |8 +-
 arch/powerpc/cpu/mpc85xx/p3060_ids.c   |  117 -
 arch/powerpc/cpu/mpc85xx/p3060_serdes.c|  118 -
 arch/powerpc/cpu/mpc85xx/release.S |   87 +++-
 arch/powerpc/cpu/mpc85xx/speed.c   |3 +-
 arch/powerpc/cpu/mpc85xx/start.S   |  376 +--
 arch/powerpc/cpu/mpc8xxx/cpu.c |   68 ++-
 arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c   |  223 -
 arch/powerpc/cpu/mpc8xxx/ddr/ddr3_dimm_params.c|   25 +-
 arch/powerpc/cpu/mpc8xxx/ddr/interactive.c |   26 +-
 

[U-Boot] [PATCH] env: checkpatch clean env_fat

2012-09-23 Thread Igor Grinberg
env_fat has several checkpatch warnings - clean those up.

Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
 common/env_fat.c |   20 ++--
 1 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/common/env_fat.c b/common/env_fat.c
index ca76967..6ef5318 100644
--- a/common/env_fat.c
+++ b/common/env_fat.c
@@ -58,6 +58,7 @@ int saveenv(void)
block_dev_desc_t *dev_desc = NULL;
int dev = FAT_ENV_DEVICE;
int part = FAT_ENV_PART;
+   int err;
 
res = (char *)env_new.data;
len = hexport_r(env_htab, '\0', res, ENV_SIZE, 0, NULL);
@@ -67,7 +68,7 @@ int saveenv(void)
}
 
 #ifdef CONFIG_MMC
-   if (strcmp (FAT_ENV_INTERFACE, mmc) == 0) {
+   if (strcmp(FAT_ENV_INTERFACE, mmc) == 0) {
struct mmc *mmc = find_mmc_device(dev);
 
if (!mmc) {
@@ -86,14 +87,17 @@ int saveenv(void)
FAT_ENV_INTERFACE, dev);
return 1;
}
-   if (fat_register_device(dev_desc, part) != 0) {
+
+   err = fat_register_device(dev_desc, part);
+   if (err) {
printf(Failed to register %s%d:%d\n,
FAT_ENV_INTERFACE, dev, part);
return 1;
}
 
env_new.crc = crc32(0, env_new.data, ENV_SIZE);
-   if (file_fat_write(FAT_ENV_FILE, (void *)env_new, sizeof(env_t)) == 
-1) {
+   err = file_fat_write(FAT_ENV_FILE, (void *)env_new, sizeof(env_t));
+   if (err == -1) {
printf(\n** Unable to write \%s\ from %s%d:%d **\n,
FAT_ENV_FILE, FAT_ENV_INTERFACE, dev, part);
return 1;
@@ -110,9 +114,10 @@ void env_relocate_spec(void)
block_dev_desc_t *dev_desc = NULL;
int dev = FAT_ENV_DEVICE;
int part = FAT_ENV_PART;
+   int err;
 
 #ifdef CONFIG_MMC
-   if (strcmp (FAT_ENV_INTERFACE, mmc) == 0) {
+   if (strcmp(FAT_ENV_INTERFACE, mmc) == 0) {
struct mmc *mmc = find_mmc_device(dev);
 
if (!mmc) {
@@ -133,14 +138,17 @@ void env_relocate_spec(void)
set_default_env(NULL);
return;
}
-   if (fat_register_device(dev_desc, part) != 0) {
+
+   err = fat_register_device(dev_desc, part);
+   if (err) {
printf(Failed to register %s%d:%d\n,
FAT_ENV_INTERFACE, dev, part);
set_default_env(NULL);
return;
}
 
-   if (file_fat_read(FAT_ENV_FILE, (unsigned char *)buf, CONFIG_ENV_SIZE) 
== -1) {
+   err = file_fat_read(FAT_ENV_FILE, (uchar *)buf, CONFIG_ENV_SIZE);
+   if (err == -1) {
printf(\n** Unable to read \%s\ from %s%d:%d **\n,
FAT_ENV_FILE, FAT_ENV_INTERFACE, dev, part);
set_default_env(NULL);
-- 
1.7.3.4

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


Re: [U-Boot] [PATCH v6] [RFC] early_malloc for DM added.

2012-09-23 Thread Tomas Hlavacek
Hello!

On Sun, Sep 23, 2012 at 3:06 PM, Graeme Russ graeme.r...@gmail.com wrote:

 On Sep 23, 2012 8:09 AM, Tomas Hlavacek tmshl...@gmail.com wrote:

 early_malloc for DM with support for more heaps and lightweight
 first heap in the same memory as an early stack.

 Adaptation layer for seamless calling of early_malloc or dlmalloc from
 DM based on init stage added (dmmalloc() and related functions).

 Signed-off-by: Tomas Hlavacek tmshl...@gmail.com
 ---

 [snip]

 +#ifdef CONFIG_SYS_EARLY_MALLOC
 +__weak struct early_heap_header *early_brk(size_t size)
 +{
 +   struct early_heap_header *h =
 +   (struct early_heap_header *)CONFIG_SYS_EARLY_HEAP_ADDR;
 +   struct early_heap_header *ehp = gd-early_heap_first;
 +
 +   while (ehp != NULL) {
 +   if (ehp == h)
 +   return NULL;
 +
 +   ehp = ehp-next_early_heap;
 +   }

 if (g-early_heap_first == NULL)
 h = CONFIF_SYS_EARLY_HEAP_ADDR);
 else
 return NULL;

Yes, I was too paranoid. What about:

if (g-early_heap_first != NULL)
return NULL;


 +
 +   h-free_space_pointer = (void *)(roundup(
 +   (phys_addr_t)CONFIG_SYS_EARLY_HEAP_ADDR +
 +   sizeof(struct early_heap_header),
 +   sizeof(phys_addr_t)));
 +   h-free_bytes = size - roundup(sizeof(struct early_heap_header),
 +   sizeof(phys_addr_t));
 +   h-next_early_heap = NULL;
 +
 +   return h;
 +}


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


Re: [U-Boot] [PATCH] ZFS: fix some warnings, cleanup

2012-09-23 Thread Pavel Herrmann
Add some CCs

On Wednesday 19 September 2012 17:32:36 Pavel Herrmann wrote:
 Fix warnings about type mismatch in cmd_zfs.
 Dont use a global block_dev_desc, instead use a local one in each cmd.
 
 Signed-off-by: Pavel Herrmann morpheus.i...@gmail.com
 ---
  common/cmd_zfs.c | 7 +--
  fs/zfs/zfs.c | 2 --
  include/zfs_common.h | 3 ---
  3 files changed, 5 insertions(+), 7 deletions(-)
 
 diff --git a/common/cmd_zfs.c b/common/cmd_zfs.c
 index a6ea2c0..42e286e 100644
 --- a/common/cmd_zfs.c
 +++ b/common/cmd_zfs.c
 @@ -46,7 +46,8 @@
  #define DOS_FS_TYPE_OFFSET   0x36
  #define DOS_FS32_TYPE_OFFSET 0x52
 
 -static int do_zfs_load(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 +static int do_zfs_load(cmd_tbl_t *cmdtp, int flag, int argc,
 + char * const argv[])
  {
   char *filename = NULL;
   char *ep;
 @@ -60,6 +61,7 @@ static int do_zfs_load(cmd_tbl_t *cmdtp, int flag, int
 argc, char *argv[]) const char *addr_str;
   struct zfs_file zfile;
   struct device_s vdev;
 + struct block_dev_desc *zfs_dev_desc;
 
   if (argc  3)
   return CMD_RET_USAGE;
 @@ -178,7 +180,7 @@ int zfs_print(const char *entry, const struct
 zfs_dirhook_info *data)
 
 
 
 -static int do_zfs_ls(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 +static int do_zfs_ls(cmd_tbl_t *cmdtp, int flag, int argc, char * const
 argv[]) {
   const char *filename = /;
   int dev;
 @@ -186,6 +188,7 @@ static int do_zfs_ls(cmd_tbl_t *cmdtp, int flag, int
 argc, char *argv[]) char *ep;
   int part_length;
   struct device_s vdev;
 + struct block_dev_desc *zfs_dev_desc;
 
   if (argc  3)
   return cmd_usage(cmdtp);
 diff --git a/fs/zfs/zfs.c b/fs/zfs/zfs.c
 index 360f723..d709e02 100644
 --- a/fs/zfs/zfs.c
 +++ b/fs/zfs/zfs.c
 @@ -31,8 +31,6 @@
  #include asm/byteorder.h
  #include zfs_common.h
 
 -block_dev_desc_t *zfs_dev_desc;
 -
  /*
   * The zfs plug-in routines for GRUB are:
   *
 diff --git a/include/zfs_common.h b/include/zfs_common.h
 index 04e73d0..fa0919a 100644
 --- a/include/zfs_common.h
 +++ b/include/zfs_common.h
 @@ -66,9 +66,6 @@ struct zfs_filesystem {
   block_dev_desc_t *dev_desc;
  };
 
 -
 -extern block_dev_desc_t *zfs_dev_desc;
 -
  struct device_s {
   uint64_t part_length;
  };
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] FAT: split block device interactions from filesystem logic

2012-09-23 Thread Pavel Herrmann
add some CCs

On Wednesday 19 September 2012 16:34:02 Pavel Herrmann wrote:
 Put block device interaction code into separate file from filesystem logic.
 This makes it easier to change block device API, and is similar to what
 other filesystems do.
 Cleanup some logic inconsistencies as well.
 
 Signed-off-by: Pavel Herrmann morpheus.i...@gmail.com
 ---
  fs/fat/Makefile|   4 +-
  fs/fat/dev.c   | 191
 + fs/fat/fat.c   |
 175 ++-- fs/fat/fat_write.c | 
 21 +++---
  include/fat.h  |   7 ++
  5 files changed, 228 insertions(+), 170 deletions(-)
  create mode 100644 fs/fat/dev.c
 
 diff --git a/fs/fat/Makefile b/fs/fat/Makefile
 index 9635d36..5d10b24 100644
 --- a/fs/fat/Makefile
 +++ b/fs/fat/Makefile
 @@ -24,8 +24,8 @@ include $(TOPDIR)/config.mk
  LIB  = $(obj)libfat.o
 
  AOBJS=
 -COBJS-$(CONFIG_CMD_FAT)  := fat.o
 -COBJS-$(CONFIG_FAT_WRITE):= fat_write.o
 +COBJS-$(CONFIG_CMD_FAT)  := fat.o dev.o
 +COBJS-$(CONFIG_FAT_WRITE) := fat_write.o dev.o
 
  ifndef CONFIG_SPL_BUILD
  COBJS-$(CONFIG_CMD_FAT)  += file.o
 diff --git a/fs/fat/dev.c b/fs/fat/dev.c
 new file mode 100644
 index 000..d5ff0c5
 --- /dev/null
 +++ b/fs/fat/dev.c
 @@ -0,0 +1,191 @@
 +/*
 + * (C) Copyright 2012
 + * Pavel Herrmann morpheus.i...@gmail.com
 + *
 + * See file CREDITS for list of people who contributed to this
 + * project.
 + *
 + * This program is free software; you can redistribute it and/or
 + * modify it under the terms of the GNU General Public License as
 + * published by the Free Software Foundation; either version 2 of
 + * the License, or (at your option) any later version.
 + *
 + * This program is distributed in the hope that 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., 59 Temple Place, Suite 330, Boston,
 + * MA 02111-1307 USA
 + */
 +
 +#include common.h
 +#include fat.h
 +#include part.h
 +#include errno.h
 +
 +#define DOS_BOOT_MAGIC_OFFSET   0x1fe
 +#define DOS_FS_TYPE_OFFSET  0x36
 +#define DOS_FS32_TYPE_OFFSET0x52
 +
 +static block_dev_desc_t *cur_dev;
 +static unsigned int cur_part_nr;
 +static disk_partition_t cur_part_info;
 +
 +int fat_disk_read(__u32 block, __u32 nr_blocks, void *buf)
 +{
 + if (!cur_dev || !cur_dev-block_read)
 + return -1;
 +
 + return cur_dev-block_read(cur_dev-dev,
 + cur_part_info.start + block, nr_blocks, buf);
 +}
 +
 +int fat_disk_write(__u32 block, __u32 nr_blocks, void *buf)
 +{
 + if (!cur_dev || !cur_dev-block_read)
 + return -1;
 +
 + return cur_dev-block_read(cur_dev-dev,
 + cur_part_info.start + block, nr_blocks, buf);
 +}
 +
 +int fat_get_blksz(void)
 +{
 + if (cur_dev == NULL)
 + return -EINVAL;
 + return cur_dev-blksz;
 +}
 +
 +int fat_get_partsize(void)
 +{
 + if (cur_dev == NULL)
 + return -EINVAL;
 + return cur_part_info.size;
 +}
 +
 +int fat_register_device(block_dev_desc_t *dev_desc, int part_no)
 +{
 + ALLOC_CACHE_ALIGN_BUFFER(unsigned char, buffer, dev_desc-blksz);
 +
 + /* First close any currently found FAT filesystem */
 + cur_dev = NULL;
 +
 +#if (defined(CONFIG_CMD_IDE) || \
 + defined(CONFIG_CMD_SATA) || \
 + defined(CONFIG_CMD_SCSI) || \
 + defined(CONFIG_CMD_USB) || \
 + defined(CONFIG_MMC) || \
 + defined(CONFIG_SYSTEMACE))
 +
 + /* Read the partition table, if present */
 + if (!get_partition_info(dev_desc, part_no, cur_part_info)) {
 + cur_dev = dev_desc;
 + cur_part_nr = part_no;
 + }
 +#endif
 +
 + /* Otherwise it might be a superfloppy (whole-disk FAT filesystem) */
 + if (!cur_dev) {
 + if (part_no != 1) {
 + printf(** Partition %d not valid on device %d **\n,
 + part_no, dev_desc-dev);
 + return -1;
 + }
 +
 + cur_dev = dev_desc;
 + cur_part_nr = 1;
 + cur_part_info.start = 0;
 + cur_part_info.size = dev_desc-lba;
 + cur_part_info.blksz = dev_desc-blksz;
 + memset(cur_part_info.name, 0, sizeof(cur_part_info.name));
 + memset(cur_part_info.type, 0, sizeof(cur_part_info.type));
 + }
 +
 + /* Make sure it has a valid FAT header */
 + if (fat_disk_read(0, 1, buffer) != 1) {
 + cur_dev = NULL;
 + return -1;
 + }
 +
 + /* Check if it's actually a DOS volume */
 + if (memcmp(buffer + DOS_BOOT_MAGIC_OFFSET, \x55\xAA, 2)) {
 + cur_dev = NULL;
 + return -1;
 + }
 +
 + /* Check for 

Re: [U-Boot] [PATCH] ZFS: fix some warnings, cleanup

2012-09-23 Thread Marek Vasut
Dear Pavel Herrmann,

Did you test the changes?

 Add some CCs
 
 On Wednesday 19 September 2012 17:32:36 Pavel Herrmann wrote:
  Fix warnings about type mismatch in cmd_zfs.
  Dont use a global block_dev_desc, instead use a local one in each cmd.

The warnings generated would be appreciated in the commit message.

  Signed-off-by: Pavel Herrmann morpheus.i...@gmail.com
  ---
  
   common/cmd_zfs.c | 7 +--
   fs/zfs/zfs.c | 2 --
   include/zfs_common.h | 3 ---
   3 files changed, 5 insertions(+), 7 deletions(-)
  
  diff --git a/common/cmd_zfs.c b/common/cmd_zfs.c
  index a6ea2c0..42e286e 100644
  --- a/common/cmd_zfs.c
  +++ b/common/cmd_zfs.c
  @@ -46,7 +46,8 @@
  
   #define DOS_FS_TYPE_OFFSET 0x36
   #define DOS_FS32_TYPE_OFFSET   0x52
  
  -static int do_zfs_load(cmd_tbl_t *cmdtp, int flag, int argc, char
  *argv[]) +static int do_zfs_load(cmd_tbl_t *cmdtp, int flag, int argc,
  +   char * const argv[])
  
   {
   
  char *filename = NULL;
  char *ep;
  
  @@ -60,6 +61,7 @@ static int do_zfs_load(cmd_tbl_t *cmdtp, int flag, int
  argc, char *argv[]) const char *addr_str;
  
  struct zfs_file zfile;
  struct device_s vdev;
  
  +   struct block_dev_desc *zfs_dev_desc;
  
  if (argc  3)
  
  return CMD_RET_USAGE;
  
  @@ -178,7 +180,7 @@ int zfs_print(const char *entry, const struct
  zfs_dirhook_info *data)
  
  
  
  -static int do_zfs_ls(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
  +static int do_zfs_ls(cmd_tbl_t *cmdtp, int flag, int argc, char * const
  argv[]) {
  
  const char *filename = /;
  int dev;
  
  @@ -186,6 +188,7 @@ static int do_zfs_ls(cmd_tbl_t *cmdtp, int flag, int
  argc, char *argv[]) char *ep;
  
  int part_length;
  struct device_s vdev;
  
  +   struct block_dev_desc *zfs_dev_desc;
  
  if (argc  3)
  
  return cmd_usage(cmdtp);
  
  diff --git a/fs/zfs/zfs.c b/fs/zfs/zfs.c
  index 360f723..d709e02 100644
  --- a/fs/zfs/zfs.c
  +++ b/fs/zfs/zfs.c
  @@ -31,8 +31,6 @@
  
   #include asm/byteorder.h
   #include zfs_common.h
  
  -block_dev_desc_t *zfs_dev_desc;
  -
  
   /*
   
* The zfs plug-in routines for GRUB are:
*
  
  diff --git a/include/zfs_common.h b/include/zfs_common.h
  index 04e73d0..fa0919a 100644
  --- a/include/zfs_common.h
  +++ b/include/zfs_common.h
  @@ -66,9 +66,6 @@ struct zfs_filesystem {
  
  block_dev_desc_t *dev_desc;
   
   };
  
  -
  -extern block_dev_desc_t *zfs_dev_desc;
  -
  
   struct device_s {
   
  uint64_t part_length;
   
   };

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


[U-Boot] [PATCH v7] [RFC] early_malloc for DM added.

2012-09-23 Thread Tomas Hlavacek
early_malloc for DM with support for more heaps and lightweight
first heap in the same memory as an early stack.

Adaptation layer for seamless calling of early_malloc or dlmalloc from
DM based on init stage added (dmmalloc() and related functions).

Signed-off-by: Tomas Hlavacek tmshl...@gmail.com
---
Changelog since v5:
dmmalloc() and all dm* functions has been moved to header, made static
inline and preprocessor-dependent blocks are reworked.
early_malloc_active() corrected and made not static.
s/CONFIG_SYS_DM/CONFIG_DM/ applied.

Changelog sice v6:
Check of first heap emptyness in early_brk() has been simplified.

 arch/arm/include/asm/global_data.h|3 +
 arch/arm/lib/board.c  |8 +++
 arch/avr32/include/asm/global_data.h  |3 +
 arch/avr32/lib/board.c|9 +++
 arch/blackfin/include/asm/global_data.h   |3 +
 arch/blackfin/lib/board.c |8 +++
 arch/m68k/include/asm/global_data.h   |3 +
 arch/m68k/lib/board.c |8 +++
 arch/microblaze/include/asm/global_data.h |3 +
 arch/microblaze/lib/board.c   |9 +++
 arch/mips/include/asm/global_data.h   |3 +
 arch/mips/lib/board.c |8 +++
 arch/nds32/include/asm/global_data.h  |3 +
 arch/nds32/lib/board.c|8 +++
 arch/nios2/include/asm/global_data.h  |3 +
 arch/nios2/lib/board.c|8 +++
 arch/openrisc/include/asm/global_data.h   |3 +
 arch/openrisc/lib/board.c |8 +++
 arch/powerpc/include/asm/global_data.h|3 +
 arch/powerpc/lib/board.c  |8 +++
 arch/sandbox/include/asm/global_data.h|3 +
 arch/sandbox/lib/board.c  |8 +++
 arch/sh/include/asm/global_data.h |3 +
 arch/sh/lib/board.c   |8 +++
 arch/sparc/include/asm/global_data.h  |3 +
 arch/sparc/lib/board.c|8 +++
 arch/x86/include/asm/global_data.h|3 +
 arch/x86/lib/board.c  |   18 ++
 common/Makefile   |1 +
 common/dmmalloc.c |   88 
 include/dmmalloc.h|   89 +
 31 files changed, 344 insertions(+)
 create mode 100644 common/dmmalloc.c
 create mode 100644 include/dmmalloc.h

diff --git a/arch/arm/include/asm/global_data.h 
b/arch/arm/include/asm/global_data.h
index f8088fe..ef727b0 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -82,6 +82,9 @@ typedef   struct  global_data {
unsigned long   post_log_res; /* success of POST test */
unsigned long   post_init_f_time; /* When post_init_f started */
 #endif
+#ifdef CONFIG_SYS_EARLY_MALLOC
+   void*early_heap_first;  /* heap for early_malloc */
+#endif
 } gd_t;
 
 #include asm-generic/global_data_flags.h
diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index f1951e8..f73d8b2 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -53,6 +53,10 @@
 #include post.h
 #include logbuff.h
 
+#ifdef CONFIG_DM
+#include dmmalloc.h
+#endif
+
 #ifdef CONFIG_BITBANGMII
 #include miiphy.h
 #endif
@@ -281,6 +285,10 @@ void board_init_f(ulong bootflag)
 
memset((void *)gd, 0, sizeof(gd_t));
 
+#ifdef CONFIG_SYS_EARLY_MALLOC
+   gd-early_heap_first = early_brk(CONFIG_SYS_EARLY_HEAP_SIZE);
+#endif /* CONFIG_SYS_EARLY_MALLOC */
+
gd-mon_len = _bss_end_ofs;
 #ifdef CONFIG_OF_EMBED
/* Get a pointer to the FDT */
diff --git a/arch/avr32/include/asm/global_data.h 
b/arch/avr32/include/asm/global_data.h
index 7878bb1..0654a61 100644
--- a/arch/avr32/include/asm/global_data.h
+++ b/arch/avr32/include/asm/global_data.h
@@ -48,6 +48,9 @@ typedef   struct  global_data {
 #endif
void**jt;   /* jump table */
charenv_buf[32];/* buffer for getenv() before reloc. */
+#ifdef CONFIG_SYS_EARLY_MALLOC
+   void*early_heap_first;  /* heap for early_malloc */
+#endif
 } gd_t;
 
 #include asm-generic/global_data_flags.h
diff --git a/arch/avr32/lib/board.c b/arch/avr32/lib/board.c
index d7a64b4..f1bd946 100644
--- a/arch/avr32/lib/board.c
+++ b/arch/avr32/lib/board.c
@@ -42,6 +42,11 @@
 #ifdef CONFIG_GENERIC_ATMEL_MCI
 #include mmc.h
 #endif
+
+#ifdef CONFIG_DM
+#include dmmalloc.h
+#endif
+
 DECLARE_GLOBAL_DATA_PTR;
 
 unsigned long monitor_flash_len;
@@ -161,6 +166,10 @@ void board_init_f(ulong board_type)
memset(gd_data, 0, sizeof(gd_data));
gd = gd_data;
 
+#ifdef CONFIG_SYS_EARLY_MALLOC
+   gd-early_heap_first = early_brk(CONFIG_SYS_EARLY_HEAP_SIZE);
+#endif /* CONFIG_SYS_EARLY_MALLOC */
+
/* Perform initialization sequence */
board_early_init_f();
cpu_init();
diff --git a/arch/blackfin/include/asm/global_data.h 

Re: [U-Boot] [PATCH V2 06/21] imximage: add plugin commands

2012-09-23 Thread Stefano Babic
On 22/09/2012 04:39, Troy Kisky wrote:
 Add commands
 plugin address filename
 iomux_entry addr, data1 [, data2, [, data3]]
 write_entry addr, data1 [, data2, [, data3]]

Why do we need explicitely an IOMUX command ? As far as I can see, the
program image defined in V2 defines a plugin, but not an iomux.
I am expecting that the imximage generates a iMX header only, without
moving some code from the initialization code directly here. In the
manula there is a Write Data (what we have always had), a Check data
and an Unlock commands.

If we start to add special commands, maybe we are staring again to
reimplement U-Boot. We could have some SET_CLK, SET_CPU_FREQ, and so on.
What I am really mising in this series is why you are moving a lot of
things from U-Boot into the iMX header.

It seems to me we want to put much more code in the iMX header as what
it is really required to boot the device.

Adding / modifying the syntax requires to update doc/README.imximage, too.

 
 Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com
 ---
  tools/imximage.c |  334 
 --
  tools/imximage.h |   11 +-
  2 files changed, 283 insertions(+), 62 deletions(-)
 
 diff --git a/tools/imximage.c b/tools/imximage.c
 index 2c5a622..fae786a 100644
 --- a/tools/imximage.c
 +++ b/tools/imximage.c
 @@ -31,7 +31,6 @@
  #include mkimage.h
  #include image.h
  #include imximage.h
 -
  /*
   * Supported commands for configuration file
   */
 @@ -39,6 +38,9 @@ static table_entry_t imximage_cmds[] = {
   {CMD_BOOT_FROM, BOOT_FROM,boot command,   },
   {CMD_DATA,  DATA, Reg Write Data, },
   {CMD_IMAGE_VERSION, IMAGE_VERSION,image version,  },
 + {CMD_PLUGIN,plugin,   plugin addr,file,  },
 + {CMD_IOMUX_ENTRY,   iomux_entry,  Write iomux reg,  },
 + {CMD_WRITE_ENTRY,   write_entry,  Write register,  },
   {-1,, ,   },
  };
  
 @@ -69,8 +71,8 @@ static uint32_t imximage_version;
  
  static set_dcd_val_t set_dcd_val;
  static set_imx_hdr_t set_imx_hdr;
 -static set_imx_size_t set_imx_size;
  static uint32_t *p_max_dcd;
 +static uint32_t *header_size_ptr;
  static uint32_t g_flash_offset;
  
  static struct image_type_params imximage_params;
 @@ -88,8 +90,7 @@ static uint32_t detect_imximage_version(struct imx_header 
 *imx_hdr)
   return IMXIMAGE_V1;
  
   /* Try to detect V2 */
 - if ((fhdr_v2-header.tag == IVT_HEADER_TAG) 
 - (hdr_v2-dcd_table.header.tag == DCD_HEADER_TAG))
 + if ((fhdr_v2-header.tag == IVT_HEADER_TAG))
   return IMXIMAGE_V2;

Help me to understand. I am reading i.MX6 manual and, even if the number
of DCD entries could be variable, I do not see why the header tag of DCD
is moving. At least, this is what I can see on picture 7-19, Image
Vector table.

  
   return IMXIMAGE_VER_INVALID;
 @@ -160,7 +161,7 @@ static int set_dcd_val_v2(struct imx_header *imxhdr, 
 uint32_t *data)
  }
  
  static int set_imx_hdr_v1(struct imx_header *imxhdr,
 - uint32_t entry_point, uint32_t flash_offset)
 + uint32_t entry_point, uint32_t flash_offset, int plugin)
  {
   imx_header_v1_t *hdr_v1 = imxhdr-header.hdr_v1;
   flash_header_v1_t *fhdr_v1 = hdr_v1-fhdr;
 @@ -180,22 +181,12 @@ static int set_imx_hdr_v1(struct imx_header *imxhdr,
   /* Security feature are not supported */
   fhdr_v1-app_code_csf = 0;
   fhdr_v1-super_root_key = 0;
 + header_size_ptr = (uint32_t *)(((char *)imxhdr) + header_length - 4);
   return header_length;
  }
  
 -static void set_imx_size_v1(struct imx_header *imxhdr, uint32_t file_size,
 - uint32_t flash_offset)
 -{
 - uint32_t *p = (uint32_t *)(((char *)imxhdr)
 - + imximage_params.header_size);
 -
 - /* The external flash header must be at the end of the DCD table */
 - /* file_size includes header */
 - p[-1] = file_size + flash_offset;
 -}

I think you have to squash some of your patches or to defines them in
another way. You added this code previously, and you drop now. This
makes more difficult to review your patches.

 -
  static int set_imx_hdr_v2(struct imx_header *imxhdr,
 - uint32_t entry_point, uint32_t flash_offset)
 + uint32_t entry_point, uint32_t flash_offset, int plugin)
  {
   imx_header_v2_t *hdr_v2 = imxhdr-header.hdr_v2;
   flash_header_v2_t *fhdr_v2 = hdr_v2-fhdr;
 @@ -216,27 +207,20 @@ static int set_imx_hdr_v2(struct imx_header *imxhdr,
   fhdr_v2-boot_data_ptr = hdr_base
   + offsetof(imx_header_v2_t, boot_data);
   hdr_v2-boot_data.start = hdr_base - flash_offset;
 + hdr_v2-boot_data.plugin = plugin;
  
   /* Security feature are not supported */
   fhdr_v2-csf = 0;
 + header_size_ptr = hdr_v2-boot_data.size;
   return 

[U-Boot] [PATCH 1/4] COMMON: Add __stringify() function

2012-09-23 Thread Marek Vasut
Copied from Linux kernel:
commit 8f7c2c37319a81ef4c2bfdec67b1ccd5744d97e4
Date:   Wed Apr 8 16:58:57 2009 +0800

This function converts static number to string in preprocessor.
This is useful as it allows higher usage of puts() in favour of printf()

Signed-off-by: Marek Vasut ma...@denx.de
Cc: Wolfgang Denk w...@denx.de
---
 include/common.h  |1 +
 include/linux/stringify.h |   12 
 2 files changed, 13 insertions(+), 0 deletions(-)
 create mode 100644 include/linux/stringify.h

diff --git a/include/common.h b/include/common.h
index 55025c0..9937a57 100644
--- a/include/common.h
+++ b/include/common.h
@@ -39,6 +39,7 @@ typedef volatile unsigned charvu_char;
 #include linux/bitops.h
 #include linux/types.h
 #include linux/string.h
+#include linux/stringify.h
 #include asm/ptrace.h
 #include stdarg.h
 #if defined(CONFIG_PCI)  (defined(CONFIG_4xx)  !defined(CONFIG_AP1000))
diff --git a/include/linux/stringify.h b/include/linux/stringify.h
new file mode 100644
index 000..841cec8
--- /dev/null
+++ b/include/linux/stringify.h
@@ -0,0 +1,12 @@
+#ifndef __LINUX_STRINGIFY_H
+#define __LINUX_STRINGIFY_H
+
+/* Indirect stringification.  Doing two levels allows the parameter to be a
+ * macro itself.  For example, compile with -DFOO=bar, __stringify(FOO)
+ * converts to bar.
+ */
+
+#define __stringify_1(x...)#x
+#define __stringify(x...)  __stringify_1(x)
+
+#endif /* !__LINUX_STRINGIFY_H */
-- 
1.7.7.6

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


[U-Boot] [PATCH 2/4] COMMON: Use __stringify() instead of xstr()

2012-09-23 Thread Marek Vasut
Kill multiple occurances and redeclaration of xstr in favor of __stringify().

Signed-off-by: Marek Vasut ma...@denx.de
Cc: Wolfgang Denk w...@denx.de
---
 include/configs/MPC8308RDB.h|9 ++-
 include/configs/amcc-common.h   |   25 ++-
 include/configs/at91sam9263ek.h |5 +---
 include/configs/cam_enc_4xx.h   |   36 --
 include/configs/ea20.h  |   11 +++--
 include/configs/enbw_cmc.h  |   19 +++--
 include/configs/flea3.h |   14 +---
 include/configs/ima3-mx53.h |   10 +++-
 include/configs/imx27lite-common.h  |   15 +
 include/configs/km/keymile-common.h |   13 ---
 include/configs/km/km-powerpc.h |   12 +-
 include/configs/km/km_arm.h |   14 ++--
 include/configs/manroland/common.h  |   21 ---
 include/configs/mpc8308_p1m.h   |9 ++-
 include/configs/mx35pdk.h   |   14 +---
 include/configs/qong.h  |9 ++-
 include/configs/tam3517-common.h|   11 +++--
 include/configs/tx25.h  |5 +---
 18 files changed, 104 insertions(+), 148 deletions(-)

diff --git a/include/configs/MPC8308RDB.h b/include/configs/MPC8308RDB.h
index 7f2761c..a2716aa 100644
--- a/include/configs/MPC8308RDB.h
+++ b/include/configs/MPC8308RDB.h
@@ -525,9 +525,6 @@
 
 #define CONFIG_BOOTDELAY   5   /* -1 disables auto-boot */
 
-#define xstr(s)str(s)
-#define str(s) #s
-
 #defineCONFIG_EXTRA_ENV_SETTINGS   
\
netdev=eth0\0 \
consoledev=ttyS0\0\
@@ -561,10 +558,10 @@
bootm ${kernel_addr_r} - ${fdt_addr_r}\0  \
bootcmd=run flash_self\0  \
load=tftp ${loadaddr} ${u-boot}\0 \
-   update=protect off  xstr(CONFIG_SYS_MONITOR_BASE) \
-+${filesize};era  xstr(CONFIG_SYS_MONITOR_BASE)  \
+   update=protect off  __stringify(CONFIG_SYS_MONITOR_BASE)  \
++${filesize};era  __stringify(CONFIG_SYS_MONITOR_BASE)\
 +${filesize};cp.b ${fileaddr}\
-   xstr(CONFIG_SYS_MONITOR_BASE)  ${filesize}\0  \
+   __stringify(CONFIG_SYS_MONITOR_BASE)  ${filesize}\0   \
upd=run load update\0 \
 
 #endif /* __CONFIG_H */
diff --git a/include/configs/amcc-common.h b/include/configs/amcc-common.h
index 056a22a..9d0c80b 100644
--- a/include/configs/amcc-common.h
+++ b/include/configs/amcc-common.h
@@ -189,14 +189,11 @@
 #define CONFIG_ADDMISC addmisc=setenv bootargs ${bootargs}\0
 #endif
 
-#define xstr(s)str(s)
-#define str(s) #s
-
 /*
  * General common environment variables shared on all AMCC eval boards
  */
 #define CONFIG_AMCC_DEF_ENV\
-   netdev= xstr(CONFIG_USE_NETDEV) \0  \
+   netdev= __stringify(CONFIG_USE_NETDEV) \0   
\
nfsargs=setenv bootargs root=/dev/nfs rw  \
nfsroot=${serverip}:${rootpath}\0 \
ramargs=setenv bootargs root=/dev/ram rw\0\
@@ -204,15 +201,15 @@
ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}  \
:${hostname}:${netdev}:off panic=1\0  \
addtty=setenv bootargs ${bootargs}\
-console= xstr(CONFIG_USE_TTY) ,${baudrate}\0   \
+console= __stringify(CONFIG_USE_TTY) ,${baudrate}\0
\
CONFIG_ADDMISC  \
initrd_high=3000\0\
kernel_addr_r=100\0   \
fdt_addr_r=180\0  \
ramdisk_addr_r=190\0  \
-   hostname= xstr(CONFIG_HOSTNAME) \0  \
-   bootfile= xstr(CONFIG_HOSTNAME) /uImage\0   \
-   ramdisk_file= xstr(CONFIG_HOSTNAME) /uRamdisk\0 \
+   hostname= __stringify(CONFIG_HOSTNAME) \0   
\
+   bootfile= __stringify(CONFIG_HOSTNAME) /uImage\0
\
+   ramdisk_file= __stringify(CONFIG_HOSTNAME) /uRamdisk\0  
\
CONFIG_AMCC_DEF_ENV_ROOTPATH
 
 /*
@@ -234,7 +231,7 @@
net_self=run net_self_load;   \
run ramargs addip addtty addmisc; \
bootm ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r}\0 \
-   fdt_file= xstr(CONFIG_HOSTNAME) / 

[U-Boot] [PATCH 4/4] COMMON: Use __stringify() instead of rest of implementations

2012-09-23 Thread Marek Vasut
Fix up the rest of implementations of __stringify().

Signed-off-by: Marek Vasut ma...@denx.de
Cc: Wolfgang Denk w...@denx.de
---
 board/logicpd/zoom2/zoom2_serial.h |7 +++
 include/configs/astro_mcf5373l.h   |7 +++
 include/configs/tegra20-common.h   |   12 +++-
 include/nios2.h|5 +++--
 4 files changed, 12 insertions(+), 19 deletions(-)

diff --git a/board/logicpd/zoom2/zoom2_serial.h 
b/board/logicpd/zoom2/zoom2_serial.h
index 4e30587..ad63a07 100644
--- a/board/logicpd/zoom2/zoom2_serial.h
+++ b/board/logicpd/zoom2/zoom2_serial.h
@@ -22,6 +22,8 @@
 #ifndef ZOOM2_SERIAL_H
 #define ZOOM2_SERIAL_H
 
+#include linux/stringify.h
+
 extern int zoom2_debug_board_connected (void);
 
 #define SERIAL_TL16CP754C_BASE 0x1000  /* Zoom2 Serial chip address */
@@ -31,9 +33,6 @@ extern int zoom2_debug_board_connected (void);
 #define QUAD_BASE_2(SERIAL_TL16CP754C_BASE + 0x200)
 #define QUAD_BASE_3(SERIAL_TL16CP754C_BASE + 0x300)
 
-#define S(a) #a
-#define N(a) S(quad##a)
-
 #define QUAD_INIT(n)   \
 int quad_init_##n(void)\
 {  \
@@ -61,7 +60,7 @@ int quad_tstc_##n(void)   \
 }  \
 struct serial_device zoom2_serial_device##n =  \
 {  \
-   N(n),   \
+   __stringify(n), \
quad_init_##n,  \
NULL,   \
quad_setbrg_##n,\
diff --git a/include/configs/astro_mcf5373l.h b/include/configs/astro_mcf5373l.h
index 5c4cac9..a0ed8f1 100644
--- a/include/configs/astro_mcf5373l.h
+++ b/include/configs/astro_mcf5373l.h
@@ -33,6 +33,8 @@
 #ifndef _CONFIG_ASTRO_MCF5373L_H
 #define _CONFIG_ASTRO_MCF5373L_H
 
+#include linux/stringify.h
+
 /*
  * set the card type to actually compile for; either of
  * the possibilities listed below has to be used!
@@ -209,12 +211,9 @@
  * u-boot: 'set' command
  */
 
-#define _QUOTEME(x)#x
-#define QUOTEME(x) _QUOTEME(x)
-
 #define CONFIG_EXTRA_ENV_SETTINGS  \
loaderversion=11\0\
-   card_id=QUOTEME(ASTRO_ID)\0 \
+   card_id=__stringify(ASTRO_ID)\0 \
alterafile=0\0\
xilinxfile=0\0\
xilinxload=imxtract 0x54 $xilinxfile 0x4100\
diff --git a/include/configs/tegra20-common.h b/include/configs/tegra20-common.h
index 4c02f20..6f20d75 100644
--- a/include/configs/tegra20-common.h
+++ b/include/configs/tegra20-common.h
@@ -24,14 +24,7 @@
 #ifndef __TEGRA20_COMMON_H
 #define __TEGRA20_COMMON_H
 #include asm/sizes.h
-
-/*
- * QUOTE(m) will evaluate to a string version of the value of the macro m
- * passed in.  The extra level of indirection here is to first evaluate the
- * macro m before applying the quoting operator.
- */
-#define QUOTE_(m)   #m
-#define QUOTE(m)QUOTE_(m)
+#include linux/stringify.h
 
 /*
  * High Level Configuration Options
@@ -58,7 +51,8 @@
 #define TEGRA_LP0_ADDR 0x1C406000
 #define TEGRA_LP0_SIZE 0x2000
 #define TEGRA_LP0_VEC \
-   lp0_vec= QUOTE(TEGRA_LP0_SIZE) @ QUOTE(TEGRA_LP0_ADDR)  
+   lp0_vec= __stringify(TEGRA_LP0_SIZE)  \
+   @ __stringify(TEGRA_LP0_ADDR)  
 #else
 #define TEGRA_LP0_VEC
 #endif
diff --git a/include/nios2.h b/include/nios2.h
index 54954e3..df8126a 100644
--- a/include/nios2.h
+++ b/include/nios2.h
@@ -24,6 +24,8 @@
 #ifndef __NIOS2_H__
 #define __NIOS2_H__
 
+#include linux/stringify.h
+
 /*
  * Control registers -- use with wrctl()  rdctl()
  *--*/
@@ -36,11 +38,10 @@
 /*
  * Access to control regs
  *--*/
-#define _str_(x) #x
 
 #define rdctl(reg)\
({unsigned int val;\
-   asm volatile( rdctl %0, ctl _str_(reg)\
+   asm volatile(rdctl %0, ctl __stringify(reg) \
: =r (val) ); val;})
 
 #define wrctl(reg,val)\
-- 
1.7.7.6

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


Re: [U-Boot] [PATCH v2 1/6] h2200: Add support for iPAQ h2200 palmtop

2012-09-23 Thread Marek Vasut
Dear Lukasz Dalek,

[...]

 +int dram_init(void)
 +{
 + /*
 +  * Everything except MSC0 was already set up by
 +  * 1st stage bootloader
 +  */
 + clrsetbits_le32(MSC0, 0x, 0x246c7ffc);

This magic would use more description eventually.

 + gd-ram_size = CONFIG_SYS_SDRAM_SIZE;
 + return 0;
 +}
 diff --git a/board/h2200/h2200.h b/board/h2200/h2200.h
 new file mode 100644

Do you need this file at all? Can the udc_disconnect() not be put somewhere 
into 
usb.h ?

[...]

Rest seems fine, thanks.

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 2/6] pxa25x: Add support for USB ethernet gadget

2012-09-23 Thread Marek Vasut
Dear Lukasz Dalek,

 Add to pxa25x based devices support for USB ethernet gadget. This is a
 port of pxa25x UDC driver from Linux kernel.
 
 Signed-off-by: Lukasz Dalek luk0...@gmail.com
 ---
  drivers/usb/gadget/Makefile |1 +
  drivers/usb/gadget/pxa25x_udc.c | 2059
 +++ drivers/usb/gadget/pxa25x_udc.h | 
 162 +++
  3 files changed,  insertions(+), 0 deletions(-)
  create mode 100644 drivers/usb/gadget/pxa25x_udc.c
  create mode 100644 drivers/usb/gadget/pxa25x_udc.h
[...]

So what's the change here? Or is it a repost?

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 1/2] i.MX: mxc_ipuv3_fb: add ipuv3_fb_shutdown() routine to stop IPU before bootm

2012-09-23 Thread Stefano Babic
On 22/09/2012 16:37, Fabio Estevam wrote:
 On Sat, Sep 22, 2012 at 10:42 AM, Otavio Salvador
 ota...@ossystems.com.br wrote:
 Hello Eric,

 On Fri, Sep 21, 2012 at 5:36 PM, Eric Nelson
 eric.nel...@boundarydevices.com wrote:
 Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com

 Did you test it in mx5 too? We seem to need to handle it in mx5 too as
 we had hungs in FSL kernel when using framebuffer in U-Boot. We're
 using a patch in kernel for workaround it but it seems your fix does
 what is need.
 
 I have just tested Eric's series on a mx53loco and it does fix the
 kernel hang issue.
 
 I made some comments on this series and hopefully Eric's v2 can get
 into 2012.10, since this is a bug fix.

Ok, I am waiting for V2 and I will push it.

Anyway, a question about the issue. It seems to me that it is not
possible with IPUV3 (I have not tested myself, so my question) to get
the u-boot splashscreen displayed on the LCD until the kernel has
finished to boot. This could be possible (and it is possible on other
SOC) if the IPU is loaded as module instead of statically linked to the
kernel, and if the kernel does not touch the IPU setup. This means also
that it should not disable the clocks used by U-Boot for the IPU.

But I understand from your patch that this way is not possible on
iMX53/MX6, and IPU must be always disabled. Is this correct ?


Best regards,
Stefano

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


Re: [U-Boot] [PATCH 1/3] mx25: add CPU revision 1.2

2012-09-23 Thread Stefano Babic
On 22/09/2012 22:50, Eric Bénard wrote:
 tested on a MCIMX257CJM4A which now reports :
 CPU:   Freescale i.MX25 rev1.2 at 399 MHz
 
 Signed-off-by: Eric Bénard e...@eukrea.com
 ---
  arch/arm/cpu/arm926ejs/mx25/generic.c |3 +++
  arch/arm/include/asm/arch-mx25/imx-regs.h |1 +
  2 files changed, 4 insertions(+), 0 deletions(-)
 
 diff --git a/arch/arm/cpu/arm926ejs/mx25/generic.c 
 b/arch/arm/cpu/arm926ejs/mx25/generic.c
 index 8b07dae..cb74b82 100644
 --- a/arch/arm/cpu/arm926ejs/mx25/generic.c
 +++ b/arch/arm/cpu/arm926ejs/mx25/generic.c
 @@ -140,6 +140,9 @@ u32 get_cpu_rev(void)
   case 0x01:
   system_rev |= CHIP_REV_1_1;
   break;
 + case 0x02:
 + system_rev |= CHIP_REV_1_2;
 + break;
   default:
   system_rev |= 0x8000;
   break;
 diff --git a/arch/arm/include/asm/arch-mx25/imx-regs.h 
 b/arch/arm/include/asm/arch-mx25/imx-regs.h
 index cf925d7..35a2fb6 100644
 --- a/arch/arm/include/asm/arch-mx25/imx-regs.h
 +++ b/arch/arm/include/asm/arch-mx25/imx-regs.h
 @@ -355,5 +355,6 @@ struct aips_regs {
  
  #define CHIP_REV_1_0 0x10
  #define CHIP_REV_1_1 0x11
 +#define CHIP_REV_1_2 0x12
  
  #endif   /* _IMX_REGS_H */
 

Acked-by: Stefano Babic sba...@denx.de

Best regards,
Stefano Babic

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


[U-Boot] [PATCH v8] [RFC] early_malloc for DM added.

2012-09-23 Thread Tomas Hlavacek
early_malloc for DM with support for more heaps and lightweight
first heap in the same memory as an early stack.

Adaptation layer for seamless calling of early_malloc or dlmalloc from
DM based on init stage added (dmmalloc() and related functions).

Signed-off-by: Tomas Hlavacek tmshl...@gmail.com
---
Changelog since v5:
dmmalloc() and all dm* functions has been moved to header, made static
inline and preprocessor-dependent blocks are reworked.
early_malloc_active() corrected and made not static.
s/CONFIG_SYS_DM/CONFIG_DM/ applied.

Changelog sice v6:
Check of first heap emptyness in early_brk() has been simplified.

Changelog since v7:
dmcalloc() implmentation added.
Comments added to header.

 arch/arm/include/asm/global_data.h|3 +
 arch/arm/lib/board.c  |8 ++
 arch/avr32/include/asm/global_data.h  |3 +
 arch/avr32/lib/board.c|9 +++
 arch/blackfin/include/asm/global_data.h   |3 +
 arch/blackfin/lib/board.c |8 ++
 arch/m68k/include/asm/global_data.h   |3 +
 arch/m68k/lib/board.c |8 ++
 arch/microblaze/include/asm/global_data.h |3 +
 arch/microblaze/lib/board.c   |9 +++
 arch/mips/include/asm/global_data.h   |3 +
 arch/mips/lib/board.c |8 ++
 arch/nds32/include/asm/global_data.h  |3 +
 arch/nds32/lib/board.c|8 ++
 arch/nios2/include/asm/global_data.h  |3 +
 arch/nios2/lib/board.c|8 ++
 arch/openrisc/include/asm/global_data.h   |3 +
 arch/openrisc/lib/board.c |8 ++
 arch/powerpc/include/asm/global_data.h|3 +
 arch/powerpc/lib/board.c  |8 ++
 arch/sandbox/include/asm/global_data.h|3 +
 arch/sandbox/lib/board.c  |8 ++
 arch/sh/include/asm/global_data.h |3 +
 arch/sh/lib/board.c   |8 ++
 arch/sparc/include/asm/global_data.h  |3 +
 arch/sparc/lib/board.c|8 ++
 arch/x86/include/asm/global_data.h|3 +
 arch/x86/lib/board.c  |   18 +
 common/Makefile   |1 +
 common/dmmalloc.c |   88 ++
 include/dmmalloc.h|  117 +
 31 files changed, 372 insertions(+)
 create mode 100644 common/dmmalloc.c
 create mode 100644 include/dmmalloc.h

diff --git a/arch/arm/include/asm/global_data.h 
b/arch/arm/include/asm/global_data.h
index f8088fe..ef727b0 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -82,6 +82,9 @@ typedef   struct  global_data {
unsigned long   post_log_res; /* success of POST test */
unsigned long   post_init_f_time; /* When post_init_f started */
 #endif
+#ifdef CONFIG_SYS_EARLY_MALLOC
+   void*early_heap_first;  /* heap for early_malloc */
+#endif
 } gd_t;
 
 #include asm-generic/global_data_flags.h
diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index f1951e8..f73d8b2 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -53,6 +53,10 @@
 #include post.h
 #include logbuff.h
 
+#ifdef CONFIG_DM
+#include dmmalloc.h
+#endif
+
 #ifdef CONFIG_BITBANGMII
 #include miiphy.h
 #endif
@@ -281,6 +285,10 @@ void board_init_f(ulong bootflag)
 
memset((void *)gd, 0, sizeof(gd_t));
 
+#ifdef CONFIG_SYS_EARLY_MALLOC
+   gd-early_heap_first = early_brk(CONFIG_SYS_EARLY_HEAP_SIZE);
+#endif /* CONFIG_SYS_EARLY_MALLOC */
+
gd-mon_len = _bss_end_ofs;
 #ifdef CONFIG_OF_EMBED
/* Get a pointer to the FDT */
diff --git a/arch/avr32/include/asm/global_data.h 
b/arch/avr32/include/asm/global_data.h
index 7878bb1..0654a61 100644
--- a/arch/avr32/include/asm/global_data.h
+++ b/arch/avr32/include/asm/global_data.h
@@ -48,6 +48,9 @@ typedef   struct  global_data {
 #endif
void**jt;   /* jump table */
charenv_buf[32];/* buffer for getenv() before reloc. */
+#ifdef CONFIG_SYS_EARLY_MALLOC
+   void*early_heap_first;  /* heap for early_malloc */
+#endif
 } gd_t;
 
 #include asm-generic/global_data_flags.h
diff --git a/arch/avr32/lib/board.c b/arch/avr32/lib/board.c
index d7a64b4..f1bd946 100644
--- a/arch/avr32/lib/board.c
+++ b/arch/avr32/lib/board.c
@@ -42,6 +42,11 @@
 #ifdef CONFIG_GENERIC_ATMEL_MCI
 #include mmc.h
 #endif
+
+#ifdef CONFIG_DM
+#include dmmalloc.h
+#endif
+
 DECLARE_GLOBAL_DATA_PTR;
 
 unsigned long monitor_flash_len;
@@ -161,6 +166,10 @@ void board_init_f(ulong board_type)
memset(gd_data, 0, sizeof(gd_data));
gd = gd_data;
 
+#ifdef CONFIG_SYS_EARLY_MALLOC
+   gd-early_heap_first = early_brk(CONFIG_SYS_EARLY_HEAP_SIZE);
+#endif /* CONFIG_SYS_EARLY_MALLOC */
+
/* Perform initialization sequence */
board_early_init_f();
cpu_init();
diff --git 

Re: [U-Boot] [PATCH V2 08/21] mx6: add plugin file for use with imximage.cfg

2012-09-23 Thread Eric Nelson

On 09/23/2012 03:17 AM, Stefano Babic wrote:

On 22/09/2012 04:39, Troy Kisky wrote:

The plugin command of mkimage can take this
file as an argument.

Signed-off-by: Troy Kiskytroy.ki...@boundarydevices.com
---


Hi Troy,

I agree with Vikram that a better explanation of what a plugin is can
help to understand without reading deeply into the i.MX6 manual.

So a plugin is a chunk of code that can be called directly by the
BootROM of i.MX processors supporting V2 version of the i.MX header.
In my understanding, this is supported by i.MX53, too. After the plugin
run, the control is returned to the BootROM.


Hi Stefano,

It seems that there's some general confusion on the list, so I think
a little more background and commentary is in order.

The primary rationale for plugins is to allow separate link maps in
a single image loaded by the BootROM.

The idea is to allow first-level code to initialize resources (usually
DDR) while running in internal RAM, then return to the boot rom for
further image loading (typically into DDR). This prevents the need
for the first-level code to support all boot sources (SPI-NOR,
NAND, SD card, etc) and allows it to focus on machine setup.

The feature is normally needed to allow the first level to access
a PMIC. I'm surprised that the 51evk and 53Loco boards aren't
using it.

Troy's rationale for using it now is to enable a single image on
i.MX6Quad, Dual lite and Solo processors, which have very slight
initialization differences. The 6Solo processor has 32-bit DDR
bus, so it would otherwise require a separate binary.

By doing this in code (plugin), we can introduce a conditional
based on processor type and have a single image that will boot
on any of the three.

The other key change for these processors is the location of
the iomux controller (moved on 6Solo/Duallite from 6Quad).

6Solo has 32-bit DDR and iomux controller moved from 6Q
6Duallite has 64-bit DDR but same iomux location as 6Q

Note that this highlights a slight down side to the plugin approach.

Because of the movement of the iomux controller, we can't use
a universal i.MX6 image header to write any IOMUX registers
through imximage.cfg.

Regards,


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


Re: [U-Boot] [PATCH v4 10/11] Add u-boot-pad.bin target to the Makefile

2012-09-23 Thread Wolfgang Denk
Dear Marek Vasut,

In message 201209212124.05075.ma...@denx.de you wrote:
 
 Leave u-boot.bin be, that's the u-boot binary ... the new name might be u-
 boot.img (as in flash image), what do you say ?

Please re-read my earlier posting here:

http://article.gmane.org/gmane.comp.boot-loaders.u-boot/141749

Are there any strong arguments against my proposal?

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
If programming was easy, they wouldn't need something as  complicated
as a human being to do it, now would they?
   - L. Wall  R. L. Schwartz, _Programming Perl_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v8] [RFC] early_malloc for DM added.

2012-09-23 Thread Wolfgang Denk
Dear Tomas Hlavacek,

In message 1348416940-20319-1-git-send-email-tmshl...@gmail.com you wrote:
 early_malloc for DM with support for more heaps and lightweight
 first heap in the same memory as an early stack.
 
 Adaptation layer for seamless calling of early_malloc or dlmalloc from
 DM based on init stage added (dmmalloc() and related functions).
 
 Signed-off-by: Tomas Hlavacek tmshl...@gmail.com
 ---
 Changelog since v5:
 dmmalloc() and all dm* functions has been moved to header, made static
 inline and preprocessor-dependent blocks are reworked.
 early_malloc_active() corrected and made not static.
 s/CONFIG_SYS_DM/CONFIG_DM/ applied.
 
 Changelog sice v6:
 Check of first heap emptyness in early_brk() has been simplified.
 
 Changelog since v7:
 dmcalloc() implmentation added.
 Comments added to header.

Your change log does not make much sense to me.  It appears there has
been some dmcalloc() implementation already in v5 (and eearlier?), as
you write there you moved it into the header file.  Now you add it
again?

This changelog is intended to desccribe the difference between the
patch versions, to allow a reviewer to recognize which comments you
addressed, and where you decided otherwise.

Your log does not provide any such information.


Also, please re-read the recommendations for the commit message.
FOO added is considered bad; please use something like add FOO
instead (i. e. describe what this commit actually does).


Also, please make sure tu run ALL patches through checkpatch before
submitting; your patch throws 4 errors that all need fixing.

Finally, you might want to consult a spell checker every now and then
(see for example implmentation, perfrom, etc.).

Thanks.

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'm not a god, I was misquoted. - Lister, Red Dwarf
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/2] i.MX: mxc_ipuv3_fb: add ipuv3_fb_shutdown() routine to stop IPU before bootm

2012-09-23 Thread Dirk Behme

On 23.09.2012 17:56, Stefano Babic wrote:

On 22/09/2012 16:37, Fabio Estevam wrote:

On Sat, Sep 22, 2012 at 10:42 AM, Otavio Salvador
ota...@ossystems.com.br  wrote:

Hello Eric,

On Fri, Sep 21, 2012 at 5:36 PM, Eric Nelson
eric.nel...@boundarydevices.com  wrote:

Signed-off-by: Eric Nelsoneric.nel...@boundarydevices.com


Did you test it in mx5 too? We seem to need to handle it in mx5 too as
we had hungs in FSL kernel when using framebuffer in U-Boot. We're
using a patch in kernel for workaround it but it seems your fix does
what is need.


I have just tested Eric's series on a mx53loco and it does fix the
kernel hang issue.

I made some comments on this series and hopefully Eric's v2 can get
into 2012.10, since this is a bug fix.


Ok, I am waiting for V2 and I will push it.

Anyway, a question about the issue. It seems to me that it is not
possible with IPUV3 (I have not tested myself, so my question) to get
the u-boot splashscreen displayed on the LCD until the kernel has
finished to boot. This could be possible (and it is possible on other
SOC) if the IPU is loaded as module instead of statically linked to the
kernel, and if the kernel does not touch the IPU setup. This means also
that it should not disable the clocks used by U-Boot for the IPU.

But I understand from your patch that this way is not possible on
iMX53/MX6, and IPU must be always disabled. Is this correct ?


I'm no expert on this, so I might be wrong and people will correct me:

No, not always. It's my understanding that at the *moment* we have to 
disable the IPU in U-Boot before jumping into the kernel due to a bug 
in Sascha's kernel IPU driver:


http://lists.infradead.org/pipermail/linux-arm-kernel/2012-September/121980.html

http://lists.infradead.org/pipermail/linux-arm-kernel/2012-September/122100.html

So from my understanding, this isn't a SOC limitation. But we have to 
do it as long as the kernel's IPU driver isn't fixed.


Sorry if this is wrong ;)

Best regards

Dirk

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


Re: [U-Boot] [PATCH 1/2] i.MX: mxc_ipuv3_fb: add ipuv3_fb_shutdown() routine to stop IPU before bootm

2012-09-23 Thread Eric Nelson

Hi Stefano,

On 09/23/2012 08:56 AM, Stefano Babic wrote:

On 22/09/2012 16:37, Fabio Estevam wrote:

On Sat, Sep 22, 2012 at 10:42 AM, Otavio Salvador
ota...@ossystems.com.br  wrote:

Hello Eric,

On Fri, Sep 21, 2012 at 5:36 PM, Eric Nelson
eric.nel...@boundarydevices.com  wrote:

Signed-off-by: Eric Nelsoneric.nel...@boundarydevices.com


Did you test it in mx5 too? We seem to need to handle it in mx5 too as
we had hungs in FSL kernel when using framebuffer in U-Boot. We're
using a patch in kernel for workaround it but it seems your fix does
what is need.


I have just tested Eric's series on a mx53loco and it does fix the
kernel hang issue.

I made some comments on this series and hopefully Eric's v2 can get
into 2012.10, since this is a bug fix.


Ok, I am waiting for V2 and I will push it.



I'll forward this later today.


Anyway, a question about the issue. It seems to me that it is not
possible with IPUV3 (I have not tested myself, so my question) to get
the u-boot splashscreen displayed on the LCD until the kernel has
finished to boot. This could be possible (and it is possible on other
SOC) if the IPU is loaded as module instead of statically linked to the
kernel, and if the kernel does not touch the IPU setup. This means also
that it should not disable the clocks used by U-Boot for the IPU.



I'm not sure I understand. The splash screen comes up as soon as
the call to ipuv3_fb_init() is made (in board_video_skip() in my
implementation for SABRE Lite).

As it stands, if we leave the IPU running, we'll see garbage on
the display as the kernel re-purposes the RAM used by U-Boot's
frame buffer.


But I understand from your patch that this way is not possible on
iMX53/MX6, and IPU must be always disabled. Is this correct ?



Sascha responded to a note about this on AKML that the hand-over of
a live FB isn't a supported kernel use case and it's definitely
tricky.

I don't know about the policy, but from a practical matter, the
IPU frame buffer implementation in U-Boot isn't currently up to
that task, since:
it only supports a single display (i.MX6 can handle 4)
it only supports 16bpp

Additional functionality would be helpful here.

I would like to see a handoff of display settings from U-Boot to
the kernel, but that's also a tricky thing as long as we're supporting
different mechanisms (DT in main-line and kernel parameters in
older kernels).

Regards,


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


Re: [U-Boot] [PATCH v8] [RFC] early_malloc for DM added.

2012-09-23 Thread Tomas Hlavacek
Dear Wolfgang Denk,

On Sun, Sep 23, 2012 at 6:32 PM, Wolfgang Denk w...@denx.de wrote:

 Changelog since v7:
 dmcalloc() implmentation added.
 Comments added to header.

 Your change log does not make much sense to me.  It appears there has
 been some dmcalloc() implementation already in v5 (and eearlier?), as
 you write there you moved it into the header file.  Now you add it
 again?

Well no. The dmcalloc function returned always NULL in the early stage
in the previous versions. The current version of dmcalloc simulates
calloc also in the early_mallocator stage.


 Also, please re-read the recommendations for the commit message.
 FOO added is considered bad; please use something like add FOO
 instead (i. e. describe what this commit actually does).

I will do that.

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


Re: [U-Boot] [PATCH 1/2] i.MX: mxc_ipuv3_fb: add ipuv3_fb_shutdown() routine to stop IPU before bootm

2012-09-23 Thread Fabio Estevam
On Sun, Sep 23, 2012 at 1:46 PM, Eric Nelson
eric.nel...@boundarydevices.com wrote:

 As it stands, if we leave the IPU running, we'll see garbage on
 the display as the kernel re-purposes the RAM used by U-Boot's
 frame buffer.

And on mx53qsb we get kernel hangs at about half of the boots (tested
on 2.6.35 FSL kernel).

So turning off the IPU in U-boot, as Eric did in this series is an
important fix.

Regards,

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


Re: [U-Boot] [PATCH 1/4] COMMON: Add __stringify() function

2012-09-23 Thread Albert ARIBAUD
Hi Marek,

On Sun, 23 Sep 2012 17:41:22 +0200, Marek Vasut ma...@denx.de wrote:

 Copied from Linux kernel:
 commit 8f7c2c37319a81ef4c2bfdec67b1ccd5744d97e4
 Date:   Wed Apr 8 16:58:57 2009 +0800
 
 This function converts static number to string in preprocessor.
 This is useful as it allows higher usage of puts() in favour of printf()

Fix commit message: this fonction is not limited to numbers.
 
 Signed-off-by: Marek Vasut ma...@denx.de
 Cc: Wolfgang Denk w...@denx.de
 ---
  include/common.h  |1 +
  include/linux/stringify.h |   12 
  2 files changed, 13 insertions(+), 0 deletions(-)
  create mode 100644 include/linux/stringify.h
 
 diff --git a/include/common.h b/include/common.h
 index 55025c0..9937a57 100644
 --- a/include/common.h
 +++ b/include/common.h
 @@ -39,6 +39,7 @@ typedef volatile unsigned char  vu_char;
  #include linux/bitops.h
  #include linux/types.h
  #include linux/string.h
 +#include linux/stringify.h
  #include asm/ptrace.h
  #include stdarg.h
  #if defined(CONFIG_PCI)  (defined(CONFIG_4xx)  !defined(CONFIG_AP1000))
 diff --git a/include/linux/stringify.h b/include/linux/stringify.h
 new file mode 100644
 index 000..841cec8
 --- /dev/null
 +++ b/include/linux/stringify.h
 @@ -0,0 +1,12 @@
 +#ifndef __LINUX_STRINGIFY_H
 +#define __LINUX_STRINGIFY_H
 +
 +/* Indirect stringification.  Doing two levels allows the parameter to be a
 + * macro itself.  For example, compile with -DFOO=bar, __stringify(FOO)
 + * converts to bar.
 + */
 +
 +#define __stringify_1(x...)  #x
 +#define __stringify(x...)__stringify_1(x)
 +
 +#endif   /* !__LINUX_STRINGIFY_H */



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


Re: [U-Boot] [PATCH V2 08/21] mx6: add plugin file for use with imximage.cfg

2012-09-23 Thread Stefano Babic
On 23/09/2012 18:23, Eric Nelson wrote:
 On 09/23/2012 03:17 AM, Stefano Babic wrote:
 On 22/09/2012 04:39, Troy Kisky wrote:
 The plugin command of mkimage can take this
 file as an argument.

 Signed-off-by: Troy Kiskytroy.ki...@boundarydevices.com
 ---

 Hi Troy,

 I agree with Vikram that a better explanation of what a plugin is can
 help to understand without reading deeply into the i.MX6 manual.

 So a plugin is a chunk of code that can be called directly by the
 BootROM of i.MX processors supporting V2 version of the i.MX header.
 In my understanding, this is supported by i.MX53, too. After the plugin
 run, the control is returned to the BootROM.

 Hi Stefano,
 
 It seems that there's some general confusion on the list, so I think
 a little more background and commentary is in order.

Well, it is - thanks for explanation.

 
 The primary rationale for plugins is to allow separate link maps in
 a single image loaded by the BootROM.
 
 The idea is to allow first-level code to initialize resources (usually
 DDR) while running in internal RAM, then return to the boot rom for
 further image loading (typically into DDR). This prevents the need
 for the first-level code to support all boot sources (SPI-NOR,
 NAND, SD card, etc) and allows it to focus on machine setup.
 
 The feature is normally needed to allow the first level to access
 a PMIC. I'm surprised that the 51evk and 53Loco boards aren't
 using it.

The mx51 uses a V1 header and the plugin feature is not supported at
all. So, it can't, simply. The mx53 can, but it is not needed.
Both boards boot without plugin. So it seem we have a misunderstanding,
and thanks to raise this issue ;-)

The setup is done by the SOC interpreting the DCD data into the iMX
header. After this setup, that in any case cannot be very long, the
control is still taken by the bootROM, that copies data from the media
device to the DDR according to the values set into the iMX header. Still
without plugin. After the copy, the bootROM gives the control to U-Boot
for the rest that starts with the usual initialization.

There is no need to setup the pMIC on mx51evk and mx53qsb to get the DDR
running. However, even if we need it, we can do it in another way, as I
will explain now.

 
 Troy's rationale for using it now is to enable a single image on
 i.MX6Quad, Dual lite and Solo processors, which have very slight
 initialization differences. The 6Solo processor has 32-bit DDR
 bus, so it would otherwise require a separate binary.
 
 By doing this in code (plugin), we can introduce a conditional
 based on processor type and have a single image that will boot
 on any of the three.

Ok - but why cannot this check be done directly by U-Boot ?

My understanding is that you want to add a plugin written in assembly to
allow different setup of the DDR controller. Let's see how we can do
with standard U-Boot code.

Core of the startup is that the SOC copies itself some code into the
internal RAM and started. This is done by bootROM, running is own code
and running the plugin.

We have already this mechanism with the SPL framework. The big advantage
for this approach is that the same mechanism can be used on SOC of
different vendors, while the one in this series is a solution strictly
bound with (some) Freescale's SOC.

The imx header can be still adapted to copy the SPL code into the
internal RAM. When SPL is running, you have all freedom to check which
is the CPU running and to adjust your DDR setting, and everything is C
code. Both MX5 and MX6 have plenty of internal RAM to do this, because
SPL requires ~30KB.

I think the goal to have the same U-Boot binary can be reached using the
SPL framework. As you are running U-Boot code, you have the possibility
to do whatever you want.

So my question is: if the main reason is to have a single image for all
your iMX6 boards, why cannot we do it in a standard way using SPL ?

 
 The other key change for these processors is the location of
 the iomux controller (moved on 6Solo/Duallite from 6Quad).
 
 6Solo has 32-bit DDR and iomux controller moved from 6Q
 6Duallite has 64-bit DDR but same iomux location as 6Q
 
 Note that this highlights a slight down side to the plugin approach.
 
 Because of the movement of the iomux controller, we can't use
 a universal i.MX6 image header to write any IOMUX registers
 through imximage.cfg.

However, you can do it with this approach:

- you have a general imx header, that does not write into IOMUX
It is your choice if this should set the DDR or not. You could also
decide to have an empty DCD table.
- your imx Header is generated for your SPL code, and the destination
address for the SPL code is put into internal RAM
- the bootROM will start reading the iMX header and DCD data and copies
data from media (NAND, SPI, ..) into iRAM. There is no need for any
special setup because the iRAM is always available. Then it gives the
control to the SPL.
- the SPL starts and performs the setup of the DDR, checking 

Re: [U-Boot] [PATCH 1/2] i.MX: mxc_ipuv3_fb: add ipuv3_fb_shutdown() routine to stop IPU before bootm

2012-09-23 Thread Stefano Babic
On 23/09/2012 18:46, Eric Nelson wrote:
 Hi Stefano,
 
 On 09/23/2012 08:56 AM, Stefano Babic wrote:
 On 22/09/2012 16:37, Fabio Estevam wrote:
 On Sat, Sep 22, 2012 at 10:42 AM, Otavio Salvador
 ota...@ossystems.com.br  wrote:
 Hello Eric,

 On Fri, Sep 21, 2012 at 5:36 PM, Eric Nelson
 eric.nel...@boundarydevices.com  wrote:
 Signed-off-by: Eric Nelsoneric.nel...@boundarydevices.com

 Did you test it in mx5 too? We seem to need to handle it in mx5 too as
 we had hungs in FSL kernel when using framebuffer in U-Boot. We're
 using a patch in kernel for workaround it but it seems your fix does
 what is need.

 I have just tested Eric's series on a mx53loco and it does fix the
 kernel hang issue.

 I made some comments on this series and hopefully Eric's v2 can get
 into 2012.10, since this is a bug fix.

 Ok, I am waiting for V2 and I will push it.

 
 I'll forward this later today.

Ok

 
 Anyway, a question about the issue. It seems to me that it is not
 possible with IPUV3 (I have not tested myself, so my question) to get
 the u-boot splashscreen displayed on the LCD until the kernel has
 finished to boot. This could be possible (and it is possible on other
 SOC) if the IPU is loaded as module instead of statically linked to the
 kernel, and if the kernel does not touch the IPU setup. This means also
 that it should not disable the clocks used by U-Boot for the IPU.

 
 I'm not sure I understand. The splash screen comes up as soon as
 the call to ipuv3_fb_init() is made (in board_video_skip() in my
 implementation for SABRE Lite).
 
 As it stands, if we leave the IPU running, we'll see garbage on
 the display as the kernel re-purposes the RAM used by U-Boot's
 frame buffer.

Right, if the kernel reuse the same memory. I am aware that it is not
implemented, I am asking if there some reason to make it impossible.

Some customers want to have a picture shown on the LCD until their
application is running. This makes sense, because the application can
take a lot of time before displaying something on the LCD.

If we reserve some memory for this scope, that is not used by the kernel
later (passing the mem= parameter, for example, or using a .reserve
entry in the board initialization code), we can reach the goal. In
U-Boot we have a single display with 16bit, that means that the memory
consumption is not very high.

 
 But I understand from your patch that this way is not possible on
 iMX53/MX6, and IPU must be always disabled. Is this correct ?

 
 Sascha responded to a note about this on AKML that the hand-over of
 a live FB isn't a supported kernel use case and it's definitely
 tricky.

And I agree with him, the handover is tricky and not easy, I mean, it
can work with a SOC (it remains tricky..) but not with another one. What
I am saying is not this, but what happens if the IPU is not touched
until the IPU modules are loaded.

 
 I don't know about the policy, but from a practical matter, the
 IPU frame buffer implementation in U-Boot isn't currently up to
 that task, since:
 it only supports a single display (i.MX6 can handle 4)
 it only supports 16bpp
 
 Additional functionality would be helpful here.

Agree with you. And this is the reason I am not supposing that the
kernel takes the IPU setup made by U-Boot. It could be a nightmare.

 
 I would like to see a handoff of display settings from U-Boot to
 the kernel, but that's also a tricky thing as long as we're supporting
 different mechanisms (DT in main-line and kernel parameters in
 older kernels).

Yes, and a lot of other things. I know Anatolji implemented this
behavior for a PPC5121, but we cannot generalize. I agree that the
handoff is difficult and not maintainable. My question is different: if
the IPU drivers in kernel are compiled as modules, and I will load them
only after booting, and the framebuffer's memory is reserved so that the
kernel does not touch it, is there still a known reason because the IPU
should not run when we boot the kernel? I know this issue with USB,
maybe we have now the same with the IPU.

Note: this has nothing to do with this patch ;-). I will merge it into
the current release when you push V2.

Best regards,
Stefano

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


Re: [U-Boot] [PATCH v2 2/2] add Eukrea's CPUIMX25

2012-09-23 Thread Vikram Narayanan

On 9/23/2012 5:33 PM, Eric Bénard wrote:

this board is based on an i.MX25 from Freescale.
It consists of a SOM containing :
- NAND flash (internal or external boot supported and tested)
- mDDR (64MB tested)
- ethernet PHY connected in RMII mode (tested)
and a baseboard containing :
- a serial transceiver on UART1 (tested)
- a SDCard connector on eSDHC1 (tested but disabled until Benoît's fix
   gets applied)

bootlog :
U-Boot 2012.10-rc1-3-gdd12be5 (Sep 23 2012 - 13:53:21)

CPU:   Freescale i.MX25 rev1.2 at 399 MHz
Reset cause: POR

DRAM:  64 MiB
NAND:  256 MiB
MMC:
In:serial
Out:   serial
Err:   serial
Net:   FEC
Hit any key to stop autoboot:  0

Signed-off-by: Eric Bénarde...@eukrea.com
---
v2: rebased against 2012.10-rc1, disabled eSDHC until proper fix
 from Benoît gets applied, updated bootlog.

  MAINTAINERS   |2 +
  board/eukrea/cpuimx25/Makefile|   44 +++
  board/eukrea/cpuimx25/config.mk   |5 +
  board/eukrea/cpuimx25/cpuimx25.c  |  123 ++
  board/eukrea/cpuimx25/imximage.cfg|   55 
  board/eukrea/cpuimx25/lowlevel_init.S |  113 
  boards.cfg|2 +
  include/configs/cpuimx25.h|  198 +
  nand_spl/board/eukrea/cpuimx25/Makefile   |   79 
  nand_spl/board/eukrea/cpuimx25/config.mk  |1 +
  nand_spl/board/eukrea/cpuimx25/u-boot.lds |   83 
  11 files changed, 705 insertions(+), 0 deletions(-)
  create mode 100644 board/eukrea/cpuimx25/Makefile
  create mode 100644 board/eukrea/cpuimx25/config.mk
  create mode 100644 board/eukrea/cpuimx25/cpuimx25.c
  create mode 100644 board/eukrea/cpuimx25/imximage.cfg
  create mode 100644 board/eukrea/cpuimx25/lowlevel_init.S
  create mode 100644 include/configs/cpuimx25.h
  create mode 100644 nand_spl/board/eukrea/cpuimx25/Makefile
  create mode 100644 nand_spl/board/eukrea/cpuimx25/config.mk
  create mode 100644 nand_spl/board/eukrea/cpuimx25/u-boot.lds

diff --git a/MAINTAINERS b/MAINTAINERS
index aa54fe1..94e759f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -606,6 +606,8 @@ Eric Benarde...@eukrea.com
cpuat91 ARM920T
cpu9260 ARM926EJS (AT91SAM9260 SoC)
cpu9G20 ARM926EJS (AT91SAM9G20 SoC)
+   cpuimx25i.MX25
+   cpuimx25nandi.MX25

  Ajay Bhargavajay.bhar...@einfochips.com

diff --git a/board/eukrea/cpuimx25/Makefile b/board/eukrea/cpuimx25/Makefile
new file mode 100644
index 000..46131fd
--- /dev/null
+++ b/board/eukrea/cpuimx25/Makefile
@@ -0,0 +1,44 @@
+#
+# (C) Copyright 2009 DENX Software Engineering
+# Author: John Rigbyjcri...@gmail.com
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that 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., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS  := cpuimx25.o
+SOBJS  := lowlevel_init.o
+
+SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS))
+SOBJS  := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+   $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+#
+
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/eukrea/cpuimx25/config.mk b/board/eukrea/cpuimx25/config.mk
new file mode 100644
index 000..18b2883
--- /dev/null
+++ b/board/eukrea/cpuimx25/config.mk
@@ -0,0 +1,5 @@
+ifdef CONFIG_NAND_SPL
+CONFIG_SYS_TEXT_BASE = 0x810c
+else
+CONFIG_SYS_TEXT_BASE = 0x8120
+endif
diff --git a/board/eukrea/cpuimx25/cpuimx25.c b/board/eukrea/cpuimx25/cpuimx25.c
new file mode 100644
index 000..72fa8a5
--- /dev/null
+++ b/board/eukrea/cpuimx25/cpuimx25.c
@@ -0,0 +1,123 @@
+/*
+ * (C) Copyright 2009 DENX Software Engineering
+ * (C) Copyright 2012 Eukrea Electromatiquewww.eukrea.com
+ * Eric Benarde...@eukrea.com
+ *
+ * Based on tx25.c:
+ *   Author: John Rigbyjri...@gmail.com
+ *
+ * Based on imx27lite.c:
+ *   Copyright (C) 2008,2009 Eric Jarrigejora...@users.sourceforge.net
+ *   Copyright (C) 2009 Ilya Yanokya...@emcraft.com
+ * And:
+ *   RedBoot tx25_misc.c Copyright (C) 2009 

[U-Boot] [PATCH V2 2/2] i.MX: shut down video before launch of O/S

2012-09-23 Thread Eric Nelson
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
---
 V2 moves arch_preboot_os() into imx-common/cpu.c instead
 of adding file imx-common/preboot.c

 arch/arm/imx-common/cpu.c |9 +
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/arch/arm/imx-common/cpu.c b/arch/arm/imx-common/cpu.c
index fa1d468..a10d12d 100644
--- a/arch/arm/imx-common/cpu.c
+++ b/arch/arm/imx-common/cpu.c
@@ -30,6 +30,7 @@
 #include asm/arch/clock.h
 #include asm/arch/sys_proto.h
 #include asm/arch/crm_regs.h
+#include ipu_pixfmt.h
 
 #ifdef CONFIG_FSL_ESDHC
 #include fsl_esdhc.h
@@ -138,3 +139,11 @@ u32 get_ahb_clk(void)
 
return get_periph_clk() / (ahb_podf + 1);
 }
+
+#if defined(CONFIG_VIDEO_IPUV3)
+void arch_preboot_os(void)
+{
+   /* disable video before launching O/S */
+   ipuv3_fb_shutdown();
+}
+#endif
-- 
1.7.9

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


[U-Boot] [PATCH V2 1/2] i.MX: mxc_ipuv3_fb: add ipuv3_fb_shutdown() routine to stop IPU frame buffer

2012-09-23 Thread Eric Nelson
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
Tested-by: Fabio Estevam fabio.este...@freescale.com
---
 V2 is unchanged from V1

 drivers/video/mxc_ipuv3_fb.c |   20 
 include/ipu_pixfmt.h |1 +
 2 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/drivers/video/mxc_ipuv3_fb.c b/drivers/video/mxc_ipuv3_fb.c
index c38e22d..47b336e 100644
--- a/drivers/video/mxc_ipuv3_fb.c
+++ b/drivers/video/mxc_ipuv3_fb.c
@@ -38,6 +38,7 @@
 #include videomodes.h
 #include ipu.h
 #include mxcfb.h
+#include ipu_regs.h
 
 static int mxcfb_map_video_memory(struct fb_info *fbi);
 static int mxcfb_unmap_video_memory(struct fb_info *fbi);
@@ -576,6 +577,25 @@ err0:
return ret;
 }
 
+void ipuv3_fb_shutdown(void)
+{
+   int i;
+   struct ipu_stat *stat = (struct ipu_stat *)IPU_STAT;
+
+   for (i = 0; i  ARRAY_SIZE(mxcfb_info); i++) {
+   struct fb_info *fbi = mxcfb_info[i];
+   if (fbi) {
+   struct mxcfb_info *mxc_fbi = fbi-par;
+   ipu_disable_channel(mxc_fbi-ipu_ch);
+   ipu_uninit_channel(mxc_fbi-ipu_ch);
+   }
+   }
+   for (i = 0; i  ARRAY_SIZE(stat-int_stat); i++) {
+   __raw_writel(__raw_readl(stat-int_stat[i]),
+stat-int_stat[i]);
+   }
+}
+
 void *video_hw_init(void)
 {
int ret;
diff --git a/include/ipu_pixfmt.h b/include/ipu_pixfmt.h
index 0019898..4baa711 100644
--- a/include/ipu_pixfmt.h
+++ b/include/ipu_pixfmt.h
@@ -77,5 +77,6 @@
 #define IPU_PIX_FMT_YUV422P fourcc('4', '2', '2', 'P') /* 16 YUV 4:2:2 */
 
 int ipuv3_fb_init(struct fb_videomode *mode, uint8_t disp, uint32_t pixfmt);
+void ipuv3_fb_shutdown(void);
 
 #endif
-- 
1.7.9

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


[U-Boot] [PATCH V2 0/2] i.MX: ipufb: shut down IPU frame buffer before booting

2012-09-23 Thread Eric Nelson

V2 moves arch_preboot_os() into arch/arm/imx-common/cpu.c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] FAT: split block device interactions from filesystem logic

2012-09-23 Thread Benoît Thébaudeau
Hi Pavel,

On Sunday, September 23, 2012 5:28:31 PM, Pavel Herrmann wrote:
 add some CCs
 
 On Wednesday 19 September 2012 16:34:02 Pavel Herrmann wrote:
  Put block device interaction code into separate file from
  filesystem logic.
  This makes it easier to change block device API, and is similar to
  what
  other filesystems do.
  Cleanup some logic inconsistencies as well.

Sounds good. See my comments below.

This might need some light rework to make it applicable after
http://patchwork.ozlabs.org/patch/184793/, which should be applied soon.

  Signed-off-by: Pavel Herrmann morpheus.i...@gmail.com
  ---
   fs/fat/Makefile|   4 +-
   fs/fat/dev.c   | 191
  + fs/fat/fat.c
|
  175 ++--
  fs/fat/fat_write.c |
  21 +++---
   include/fat.h  |   7 ++
   5 files changed, 228 insertions(+), 170 deletions(-)
   create mode 100644 fs/fat/dev.c
  
  diff --git a/fs/fat/Makefile b/fs/fat/Makefile
  index 9635d36..5d10b24 100644
  --- a/fs/fat/Makefile
  +++ b/fs/fat/Makefile
  @@ -24,8 +24,8 @@ include $(TOPDIR)/config.mk
   LIB= $(obj)libfat.o
  
   AOBJS  =
  -COBJS-$(CONFIG_CMD_FAT):= fat.o
  -COBJS-$(CONFIG_FAT_WRITE):= fat_write.o
  +COBJS-$(CONFIG_CMD_FAT):= fat.o dev.o
  +COBJS-$(CONFIG_FAT_WRITE) := fat_write.o dev.o
  
   ifndef CONFIG_SPL_BUILD
   COBJS-$(CONFIG_CMD_FAT)+= file.o
  diff --git a/fs/fat/dev.c b/fs/fat/dev.c
  new file mode 100644
  index 000..d5ff0c5
  --- /dev/null
  +++ b/fs/fat/dev.c
  @@ -0,0 +1,191 @@
  +/*
  + * (C) Copyright 2012
  + * Pavel Herrmann morpheus.i...@gmail.com

Since 99% of the code here comes from fat.c and fat_write.c, the copyright
information from these files should probably be added here too.

  + *
  + * See file CREDITS for list of people who contributed to this
  + * project.
  + *
  + * This program is free software; you can redistribute it and/or
  + * modify it under the terms of the GNU General Public License as
  + * published by the Free Software Foundation; either version 2 of
  + * the License, or (at your option) any later version.
  + *
  + * This program is distributed in the hope that 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., 59 Temple Place, Suite 330, Boston,
  + * MA 02111-1307 USA
  + */
  +
  +#include common.h
  +#include fat.h
  +#include part.h
  +#include errno.h
  +
  +#define DOS_BOOT_MAGIC_OFFSET   0x1fe
  +#define DOS_FS_TYPE_OFFSET  0x36
  +#define DOS_FS32_TYPE_OFFSET0x52
  +
  +static block_dev_desc_t *cur_dev;
  +static unsigned int cur_part_nr;
  +static disk_partition_t cur_part_info;
  +
  +int fat_disk_read(__u32 block, __u32 nr_blocks, void *buf)
  +{
  +   if (!cur_dev || !cur_dev-block_read)
  +   return -1;
  +
  +   return cur_dev-block_read(cur_dev-dev,
  +   cur_part_info.start + block, nr_blocks, buf);
  +}
  +
  +int fat_disk_write(__u32 block, __u32 nr_blocks, void *buf)
  +{
  +   if (!cur_dev || !cur_dev-block_read)
  +   return -1;
  +
  +   return cur_dev-block_read(cur_dev-dev,
  +   cur_part_info.start + block, nr_blocks, buf);
  +}

block_write...

Please, split this patch into:
 - moved code + renaming,
 - behavior changes (one patch per behavior change).
That will make things clearer and easier to review.

  +
  +int fat_get_blksz(void)

cur_dev-blksz is ulong, so long might be better here, even if it does not seem
strictly necessary.

  +{
  +   if (cur_dev == NULL)
  +   return -EINVAL;
  +   return cur_dev-blksz;

Or cur_part_info.blksize? Your calls to this function replace both usages, so
please make sure that this won't cause any trouble.

  +}
  +
  +int fat_get_partsize(void)

long?

  +{
  +   if (cur_dev == NULL)
  +   return -EINVAL;

This test looks unrelated to the line below and changes the behavior where this
function is called. Please clarify.

  +   return cur_part_info.size;
  +}
  +
  +int fat_register_device(block_dev_desc_t *dev_desc, int part_no)
  +{
  +   ALLOC_CACHE_ALIGN_BUFFER(unsigned char, buffer, dev_desc-blksz);
  +
  +   /* First close any currently found FAT filesystem */
  +   cur_dev = NULL;
  +
  +#if (defined(CONFIG_CMD_IDE) || \
  +   defined(CONFIG_CMD_SATA) || \
  +   defined(CONFIG_CMD_SCSI) || \
  +   defined(CONFIG_CMD_USB) || \
  +   defined(CONFIG_MMC) || \
  +   defined(CONFIG_SYSTEMACE))
  +
  +   /* Read the partition table, if present */
  +   if (!get_partition_info(dev_desc, part_no, cur_part_info)) {
  +   cur_dev = dev_desc;
  +   cur_part_nr = part_no;
  +   }
  +#endif
  +
  +   /* Otherwise it might be a 

Re: [U-Boot] [PATCH v2 2/2] add Eukrea's CPUIMX25

2012-09-23 Thread Stefano Babic
On 23/09/2012 14:03, Eric Bénard wrote:
 this board is based on an i.MX25 from Freescale.
 It consists of a SOM containing :
 - NAND flash (internal or external boot supported and tested)
 - mDDR (64MB tested)
 - ethernet PHY connected in RMII mode (tested)
 and a baseboard containing :
 - a serial transceiver on UART1 (tested)
 - a SDCard connector on eSDHC1 (tested but disabled until Benoît's fix
   gets applied)

Hi Eric,


 
 bootlog :
 U-Boot 2012.10-rc1-3-gdd12be5 (Sep 23 2012 - 13:53:21)
 
 CPU:   Freescale i.MX25 rev1.2 at 399 MHz
 Reset cause: POR
 
 DRAM:  64 MiB
 NAND:  256 MiB
 MMC:
 In:serial
 Out:   serial
 Err:   serial
 Net:   FEC
 Hit any key to stop autoboot:  0
 
 Signed-off-by: Eric Bénard e...@eukrea.com
 ---
 v2: rebased against 2012.10-rc1, disabled eSDHC until proper fix
 from Benoît gets applied, updated bootlog.
 
  MAINTAINERS   |2 +
  board/eukrea/cpuimx25/Makefile|   44 +++
  board/eukrea/cpuimx25/config.mk   |5 +
  board/eukrea/cpuimx25/cpuimx25.c  |  123 ++
  board/eukrea/cpuimx25/imximage.cfg|   55 
  board/eukrea/cpuimx25/lowlevel_init.S |  113 
  boards.cfg|2 +
  include/configs/cpuimx25.h|  198 
 +
  nand_spl/board/eukrea/cpuimx25/Makefile   |   79 
  nand_spl/board/eukrea/cpuimx25/config.mk  |1 +
  nand_spl/board/eukrea/cpuimx25/u-boot.lds |   83 

There is a main issue with these patches. According to some discussion
in previous threads and hopefully I do not misinterprete Wolfgang's will
about the direction that U-Boot will have in future, the nand_spl code
is obsolete and it remains for the already supported boards.

However, new boards must implement SPL using the SPL framework. New
boards using nand_spl will not be integrated in mainline.

 +#
 diff --git a/board/eukrea/cpuimx25/config.mk b/board/eukrea/cpuimx25/config.mk
 new file mode 100644
 index 000..18b2883
 --- /dev/null
 +++ b/board/eukrea/cpuimx25/config.mk
 @@ -0,0 +1,5 @@
 +ifdef CONFIG_NAND_SPL
 +CONFIG_SYS_TEXT_BASE = 0x810c
 +else
 +CONFIG_SYS_TEXT_BASE = 0x8120
 +endif

config.mk is obsolete in board's directory. We removed most of these
config.mk. It must not be used anymore.

 +int board_init()
 +{
 +#ifdef CONFIG_MXC_UART

Maybe you can drop the #ifdef, CONFIG_MXC_UART should always be set

 +#ifdef CONFIG_FSL_ESDHC
 +int board_mmc_getcd(struct mmc *mmc)
 +{
 + struct iomuxc_mux_ctl *muxctl;
 + struct iomuxc_pad_ctl *padctl;
 + struct gpio_regs *gpio2 = (struct gpio_regs *)IMX_GPIO2_BASE;
 + u32 val;
 +
 + muxctl = (struct iomuxc_mux_ctl *)IMX_IOPADMUX_BASE;
 + padctl = (struct iomuxc_pad_ctl *)IMX_IOPADCTL_BASE;
 +
 + writel(MX25_PIN_MUX_MODE(5), muxctl-pad_de_b);

Why is the setup of the iomux here and not in board_mmc_init ?


 diff --git a/board/eukrea/cpuimx25/lowlevel_init.S 
 b/board/eukrea/cpuimx25/lowlevel_init.S
 new file mode 100644
 index 000..76e4e6f
 --- /dev/null
 +++ b/board/eukrea/cpuimx25/lowlevel_init.S
 @@ -0,0 +1,113 @@
 +/*
 + * (C) Copyright 2009 DENX Software Engineering
 + * (C) Copyright 2012 Eukrea Electromatique www.eukrea.com
 + * Eric Benard e...@eukrea.com
 + *
 + * Based on tx25 and zmx25:
 + * Author: John Rigby jri...@gmail.com
 + *
 + * Based on U-Boot and RedBoot sources for several different i.mx
 + * platforms.
 + *
 + * This program is free software; you can redistribute it and/or
 + * modify it under the terms of the GNU General Public License as
 + * published by the Free Software Foundation; either version 2 of
 + * the License, or (at your option) any later version.
 + *
 + * This program is distributed in the hope that 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., 59 Temple Place, Suite 330, Boston,
 + * MA 02111-1307 USA
 + */
 +
 +#include asm/macro.h
 +#include asm/arch/macro.h
 +#include asm/arch/imx-regs.h
 +#include generated/asm-offsets.h
 +
 +.macro init_m3if
 + write32 0xb8003000, 0x1
 +.endm
 +
 +.macro init_clocks
 + write32 0x53f80064, 0x
 + write32 0x53f80008, 0x20034000
 +
 + /*
 +  * enable all implemented clocks in all three
 +  * clock control registers
 +  */
 + write32 0x53f8000c, 0x1fff
 + write32 0x53f80010, 0x
 + write32 0x53f80014, 0xfdfff
 +.endm
 +
 +.macro init_lpddr
 + /* Skip SDRAM initialization if we run from RAM */
 + cmp pc, #0x8000
 + bls 1f
 + cmp pc, #0x9000
 + 

Re: [U-Boot] [PATCH] mx6qsabresd: Add Ethernet support

2012-09-23 Thread Stefano Babic
On 19/09/2012 05:24, Fabio Estevam wrote:
 From: Fabio Estevam fabio.este...@freescale.com
 
 mx6qsabresd has a AR8031 Gigabit PHY.
 
 Add support for it. 
 
 Also increase CONFIG_SYS_MALLOC_LEN so that FEC buffer allocation does not 
 fail.
 
 Tested on 1Gbp and 100Mbps networks.
 
 Suggested-by: Kim Phillips kim.phill...@freescale.com
 Signed-off-by: Fabio Estevam fabio.este...@freescale.com
 ---

Applied to u-boot-imx, next branch.

Best regards,
Stefano Babic


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


Re: [U-Boot] [PATCH] mx6qsabresd: Add 8-bit USDHC support

2012-09-23 Thread Stefano Babic
On 18/09/2012 21:27, Fabio Estevam wrote:
 USDHC3 has 8 pins wired in mx6qsabresd. Configure the extra pins.
 
 Signed-off-by: Fabio Estevam fabio.este...@freescale.com
 ---

Applied to u-boot-imx, next branch, thanks.

Best regards,
Stefano Babic

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


Re: [U-Boot] [PATCH v2] mx51evk: Add CONFIG_REVISION_TAG

2012-09-23 Thread Stefano Babic
On 18/09/2012 16:48, Benoît Thébaudeau wrote:
 FSL 2.6.35 kernel assumes that the bootloader passes the CONFIG_REVISION_TAG
 information.
 
 If this data is not present, the kernel misconfigures the TZIC, which results 
 in
 the timer interrupt handler never being called, so the kernel deadlocks while
 calibrating its delay.
 
 Suggested-by: Greg Topmiller greg.topmil...@jdsu.com
 Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com
 Cc: Stefano Babic sba...@denx.de
 Cc: Fabio Estevam feste...@gmail.com
 ---

Applied to u-boot-imx (fix), thanks.

Best regards,
Stefano Babic


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


Re: [U-Boot] [PATCH] KARO TX25: Fix NAND Flash R/W cycle times

2012-09-23 Thread Stefano Babic
On 08/08/2012 15:55, Benoît Thébaudeau wrote:
 The NAND Flash of the KARO TX25 board is a Samsung K9F1G08U0B with 25-ns R/W
 cycle times. However, the NFC clock for this board was set to 66.5 MHz, so 
 using
 the NFC driver in symmetric mode (i.e. 1 NFC clock cycle = 1 NF R/W cycle)
 resulted in NF R/W cycle times of 15 ns, hence corrupted NF accesses.
 
 This patch fixes this issue by setting the NFC clock to the highest frequency
 complying to the 25-ns NF R/W cycle times specification, i.e. 33.25 MHz.
 

Applied to u-boot-imx(fix), thanks.

Best regards,
Stefano Babic

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


Re: [U-Boot] [PATCH 1/2] mx25: add CPU revision 1.2

2012-09-23 Thread Eric Bénard
Hi,

Le Sun, 23 Sep 2012 14:02:17 +0200,
Eric Bénard e...@eukrea.com a écrit :

 tested on a MCIMX257CJM4A which now reports :
 CPU:   Freescale i.MX25 rev1.2 at 399 MHz
 
 Signed-off-by: Eric Bénard e...@eukrea.com
 Acked-by: Otavio Salvador ota...@ossystems.com.br
 ---
 v2 : rebased against 2012.10-rc1, added Otavio's ack
 
sorry for the noise, this one was missing the v2 in the subject and I
git Ctrl-C to late :-(

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


Re: [U-Boot] Displays on i.MX (was Re: [PATCH 1/2])

2012-09-23 Thread Eric Nelson

Hi Stefano,

I changed the subject line because we've veered off-topic.

On 09/23/2012 10:27 AM, Stefano Babic wrote:

On 23/09/2012 18:46, Eric Nelson wrote:

Hi Stefano,

On 09/23/2012 08:56 AM, Stefano Babic wrote:

On 22/09/2012 16:37, Fabio Estevam wrote:

On Sat, Sep 22, 2012 at 10:42 AM, Otavio Salvador
ota...@ossystems.com.br   wrote:

Hello Eric,

On Fri, Sep 21, 2012 at 5:36 PM, Eric Nelson
eric.nel...@boundarydevices.com   wrote:

Signed-off-by: Eric Nelsoneric.nel...@boundarydevices.com


Did you test it in mx5 too? We seem to need to handle it in mx5 too as
we had hungs in FSL kernel when using framebuffer in U-Boot. We're
using a patch in kernel for workaround it but it seems your fix does
what is need.


I have just tested Eric's series on a mx53loco and it does fix the
kernel hang issue.

I made some comments on this series and hopefully Eric's v2 can get
into 2012.10, since this is a bug fix.


Ok, I am waiting for V2 and I will push it.



I'll forward this later today.


Ok




Anyway, a question about the issue. It seems to me that it is not
possible with IPUV3 (I have not tested myself, so my question) to get
the u-boot splashscreen displayed on the LCD until the kernel has
finished to boot. This could be possible (and it is possible on other
SOC) if the IPU is loaded as module instead of statically linked to the
kernel, and if the kernel does not touch the IPU setup. This means also
that it should not disable the clocks used by U-Boot for the IPU.



I'm not sure I understand. The splash screen comes up as soon as
the call to ipuv3_fb_init() is made (in board_video_skip() in my
implementation for SABRE Lite).

As it stands, if we leave the IPU running, we'll see garbage on
the display as the kernel re-purposes the RAM used by U-Boot's
frame buffer.


Right, if the kernel reuse the same memory. I am aware that it is not
implemented, I am asking if there some reason to make it impossible.

Some customers want to have a picture shown on the LCD until their
application is running. This makes sense, because the application can
take a lot of time before displaying something on the LCD.

If we reserve some memory for this scope, that is not used by the kernel
later (passing the mem= parameter, for example, or using a .reserve
entry in the board initialization code), we can reach the goal. In
U-Boot we have a single display with 16bit, that means that the memory
consumption is not very high.




But I understand from your patch that this way is not possible on
iMX53/MX6, and IPU must be always disabled. Is this correct ?



Sascha responded to a note about this on AKML that the hand-over of
a live FB isn't a supported kernel use case and it's definitely
tricky.


And I agree with him, the handover is tricky and not easy, I mean, it
can work with a SOC (it remains tricky..) but not with another one. What
I am saying is not this, but what happens if the IPU is not touched
until the IPU modules are loaded.



I don't know about the policy, but from a practical matter, the
IPU frame buffer implementation in U-Boot isn't currently up to
that task, since:
 it only supports a single display (i.MX6 can handle 4)
 it only supports 16bpp

Additional functionality would be helpful here.


Agree with you. And this is the reason I am not supposing that the
kernel takes the IPU setup made by U-Boot. It could be a nightmare.



I would like to see a handoff of display settings from U-Boot to
the kernel, but that's also a tricky thing as long as we're supporting
different mechanisms (DT in main-line and kernel parameters in
older kernels).


Yes, and a lot of other things. I know Anatolji implemented this
behavior for a PPC5121, but we cannot generalize. I agree that the
handoff is difficult and not maintainable. My question is different: if
the IPU drivers in kernel are compiled as modules, and I will load them
only after booting, and the framebuffer's memory is reserved so that the
kernel does not touch it, is there still a known reason because the IPU
should not run when we boot the kernel? I know this issue with USB,
maybe we have now the same with the IPU.

i

Note: this has nothing to do with this patch ;-). I will merge it into
the current release when you push V2.



I agree with all of your goals but have a more mundane set for U-Boot
and i.MX6:

-- HDMI support
-- Better strategy for storing display setup. The implementation
of a compiled-in list of supported displays doesn't scale.
-- Hand-off of display setup to DT-enabled kernel (Sascha's drivers)
-- Multiple displays
-- Hand-off of display setup to older kernels

My thought is to take things in more or less this order, although
a couple of things can make the last one trivial to do in a boot
script and it's a pain point for me. (My blog post on setting up
bootargs doesn't seem to be doing the trick)

My thinking is that:
HDMI support can and should support EDID and flexible choice
of resolution, and

We'll need 

Re: [U-Boot] [PATCH v2 2/6] pxa25x: Add support for USB ethernet gadget

2012-09-23 Thread Łukasz Dałek

On 23.09.2012 17:44, Marek Vasut wrote:

Dear Lukasz Dalek,


Add to pxa25x based devices support for USB ethernet gadget. This is a
port of pxa25x UDC driver from Linux kernel.

Signed-off-by: Lukasz Dalekluk0...@gmail.com
---
  drivers/usb/gadget/Makefile |1 +
  drivers/usb/gadget/pxa25x_udc.c | 2059
+++ drivers/usb/gadget/pxa25x_udc.h |
162 +++
  3 files changed,  insertions(+), 0 deletions(-)
  create mode 100644 drivers/usb/gadget/pxa25x_udc.c
  create mode 100644 drivers/usb/gadget/pxa25x_udc.h

[...]

So what's the change here? Or is it a repost?

Best regards,
Marek Vasut


Everything was fine except DEBUG_NOISY defintions. I fixed them and
I have resend patch.

Can I ask what about patches 3,4,5,6?

Łukasz Dałek
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/2] i.MX: mxc_ipuv3_fb: add ipuv3_fb_shutdown() routine to stop IPU before bootm

2012-09-23 Thread Sascha Hauer
On Sun, Sep 23, 2012 at 07:27:41PM +0200, Stefano Babic wrote:
 
  
  I would like to see a handoff of display settings from U-Boot to
  the kernel, but that's also a tricky thing as long as we're supporting
  different mechanisms (DT in main-line and kernel parameters in
  older kernels).
 
 Yes, and a lot of other things. I know Anatolji implemented this
 behavior for a PPC5121, but we cannot generalize. I agree that the
 handoff is difficult and not maintainable. My question is different: if
 the IPU drivers in kernel are compiled as modules, and I will load them
 only after booting, and the framebuffer's memory is reserved so that the
 kernel does not touch it, is there still a known reason because the IPU
 should not run when we boot the kernel? I know this issue with USB,
 maybe we have now the same with the IPU.

The clock framework disables all unused clocks in a late_initcall. when
the IPU is compiled as a module, the IPU clock will be one of those.

Sascha


-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 2/6] pxa25x: Add support for USB ethernet gadget

2012-09-23 Thread Marek Vasut
Dear Łukasz Dałek,

 On 23.09.2012 17:44, Marek Vasut wrote:
  Dear Lukasz Dalek,
  
  Add to pxa25x based devices support for USB ethernet gadget. This is a
  port of pxa25x UDC driver from Linux kernel.
  
  Signed-off-by: Lukasz Dalekluk0...@gmail.com
  ---
  
drivers/usb/gadget/Makefile |1 +
drivers/usb/gadget/pxa25x_udc.c | 2059
  
  +++ drivers/usb/gadget/pxa25x_udc.h
  | 162 +++
  
3 files changed,  insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/gadget/pxa25x_udc.c
create mode 100644 drivers/usb/gadget/pxa25x_udc.h
  
  [...]
  
  So what's the change here? Or is it a repost?
  
  Best regards,
  Marek Vasut
 
 Everything was fine except DEBUG_NOISY defintions. I fixed them and
 I have resend patch.

http://www.denx.de/wiki/U-Boot/Patches did you read this? Worth reading so I 
don't have to repeat myself ;-)

 Can I ask what about patches 3,4,5,6?

I think they're fine ... did you do any changes to them ?

 Łukasz Dałek

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 1/4] COMMON: Add __stringify() function

2012-09-23 Thread Marek Vasut
Dear Albert ARIBAUD,

 Hi Marek,
 
 On Sun, 23 Sep 2012 17:41:22 +0200, Marek Vasut ma...@denx.de wrote:
  Copied from Linux kernel:
  commit 8f7c2c37319a81ef4c2bfdec67b1ccd5744d97e4
  Date:   Wed Apr 8 16:58:57 2009 +0800
  
  This function converts static number to string in preprocessor.
  This is useful as it allows higher usage of puts() in favour of printf()
 
 Fix commit message: this fonction is not limited to numbers.

WFM, can you review the series please ?

  Signed-off-by: Marek Vasut ma...@denx.de
  Cc: Wolfgang Denk w...@denx.de
  ---
  
   include/common.h  |1 +
   include/linux/stringify.h |   12 
   2 files changed, 13 insertions(+), 0 deletions(-)
   create mode 100644 include/linux/stringify.h
  
  diff --git a/include/common.h b/include/common.h
  index 55025c0..9937a57 100644
  --- a/include/common.h
  +++ b/include/common.h
  @@ -39,6 +39,7 @@ typedef volatile unsigned charvu_char;
  
   #include linux/bitops.h
   #include linux/types.h
   #include linux/string.h
  
  +#include linux/stringify.h
  
   #include asm/ptrace.h
   #include stdarg.h
   #if defined(CONFIG_PCI)  (defined(CONFIG_4xx) 
   !defined(CONFIG_AP1000))
  
  diff --git a/include/linux/stringify.h b/include/linux/stringify.h
  new file mode 100644
  index 000..841cec8
  --- /dev/null
  +++ b/include/linux/stringify.h
  @@ -0,0 +1,12 @@
  +#ifndef __LINUX_STRINGIFY_H
  +#define __LINUX_STRINGIFY_H
  +
  +/* Indirect stringification.  Doing two levels allows the parameter to
  be a + * macro itself.  For example, compile with -DFOO=bar,
  __stringify(FOO) + * converts to bar.
  + */
  +
  +#define __stringify_1(x...)#x
  +#define __stringify(x...)  __stringify_1(x)
  +
  +#endif /* !__LINUX_STRINGIFY_H */
 
 Amicalement,

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 2/6] pxa25x: Add support for USB ethernet gadget

2012-09-23 Thread Łukasz Dałek

On 23.09.2012 20:24, Marek Vasut wrote:

Dear Łukasz Dałek,


On 23.09.2012 17:44, Marek Vasut wrote:

Dear Lukasz Dalek,


Add to pxa25x based devices support for USB ethernet gadget. This is a
port of pxa25x UDC driver from Linux kernel.

Signed-off-by: Lukasz Dalekluk0...@gmail.com
---

   drivers/usb/gadget/Makefile |1 +
   drivers/usb/gadget/pxa25x_udc.c | 2059

+++ drivers/usb/gadget/pxa25x_udc.h
| 162 +++

   3 files changed,  insertions(+), 0 deletions(-)
   create mode 100644 drivers/usb/gadget/pxa25x_udc.c
   create mode 100644 drivers/usb/gadget/pxa25x_udc.h

[...]

So what's the change here? Or is it a repost?

Best regards,
Marek Vasut

Everything was fine except DEBUG_NOISY defintions. I fixed them and
I have resend patch.

http://www.denx.de/wiki/U-Boot/Patches did you read this? Worth reading so I
don't have to repeat myself ;-)

Yes.




Can I ask what about patches 3,4,5,6?

I think they're fine ... did you do any changes to them ?



If they are ok then my job is done :-)

Łukasz Dałek
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 1/6] h2200: Add support for iPAQ h2200 palmtop

2012-09-23 Thread Łukasz Dałek

On 23.09.2012 17:43, Marek Vasut wrote:

+   gd-ram_size = CONFIG_SYS_SDRAM_SIZE;
+   return 0;
+}
diff --git a/board/h2200/h2200.h b/board/h2200/h2200.h
new file mode 100644

Do you need this file at all? Can the udc_disconnect() not be put somewhere into
usb.h ?


Can I just move this declaration into h2200.c?

Łukasz Dałek
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 2/2] add Eukrea's CPUIMX25

2012-09-23 Thread Eric Bénard
Hi Vikram,

Le Sun, 23 Sep 2012 23:02:18 +0530,
Vikram Narayanan vikram...@gmail.com a écrit :
 Why the clock init is in two places?
 imximage.cfg and this file. Am I missing something?
 
imximage.cfg for internal boot, lowlevel_init.S for external boot.

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


Re: [U-Boot] [NEXT PATCH v1 4/7] MX35: Add soc_boot_mode and soc_boot_device to MX35

2012-09-23 Thread Eric Bénard
Hi Stefano,

Le Thu,  6 Sep 2012 10:04:57 +0200,
Stefano Babic sba...@denx.de a écrit :
 +#define RCSR_MEM_CTL_WEIM0
 +#define RCSR_MEM_CTL_NAND1
 +#define RCSR_MEM_CTL_SD  2
 +#define RCSR_MEM_TYPE_NOR0
 +#define RCSR_MEM_TYPE_ONENAND2
 +#define RCSR_MEM_TYPE_SD 0
 +#define RCSR_MEM_TYPE_I2C2
 +#define RCSR_MEM_TYPE_SPI3
 +
 +u32 spl_boot_device(void)
 +{
 + puts(spl_boot_device\n);
 + struct ccm_regs *ccm =
 + (struct ccm_regs *)IMX_CCM_BASE;
 +
 +#if 1
 + return BOOT_DEVICE_MMC1;
 +#endif

thisseems not clean and seems caused by the fact that the define
RCSR_MEM_CTL_SD should be 3 and not 2 so in your tests the function
spl_boot_device was not detecting the right boot mode. Also IMHO this
define should be named RCSR_MEM_CTL_EXPANSION as in the app note AN3996
at end of page 3 (there is a typo in the reference manual which seems
to be a copy'n paste from i.MX25 as it doesn't take in acount the ATA
HDD case) :
http://cache.freescale.com/files/dsp/doc/app_note/AN3996.pdf

 +
 + u32 rcsr = readl(ccm-rcsr);
 + u32 mem_type, mem_ctl;
 +
 + /* In external mode, no boot device is returned */
 + if ((rcsr  10)  0x03)
 + return BOOT_DEVICE_NONE;
 +
 + mem_ctl = (rcsr  25)  0x03;
 + mem_type = (rcsr  23)  0x03;
 +
 + switch (mem_ctl) {
 + case RCSR_MEM_CTL_WEIM:
 + switch (mem_type) {
 + case RCSR_MEM_TYPE_NOR:
 + return BOOT_DEVICE_NOR;
 + case RCSR_MEM_TYPE_ONENAND:
 + return BOOT_DEVICE_ONE_NAND;
 + default:
 + return BOOT_DEVICE_NONE;
 + }
 + case RCSR_MEM_CTL_NAND:
 + return BOOT_DEVICE_NAND;
 + case RCSR_MEM_CTL_SD:
 + switch (mem_type) {
 + case RCSR_MEM_TYPE_SD:
 + return BOOT_DEVICE_MMC1;
 + case RCSR_MEM_TYPE_I2C:
 + return BOOT_DEVICE_I2C;
 + case RCSR_MEM_TYPE_SPI:
 + return BOOT_DEVICE_SPI;
 + default:
 + return BOOT_DEVICE_NONE;
 + }
 + }
 +
 + return BOOT_DEVICE_NONE;
 +}
 +

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


Re: [U-Boot] [PATCH v2 1/6] h2200: Add support for iPAQ h2200 palmtop

2012-09-23 Thread Marek Vasut
Dear Łukasz Dałek,

 On 23.09.2012 17:43, Marek Vasut wrote:
  +  gd-ram_size = CONFIG_SYS_SDRAM_SIZE;
  +  return 0;
  +}
  diff --git a/board/h2200/h2200.h b/board/h2200/h2200.h
  new file mode 100644
  
  Do you need this file at all? Can the udc_disconnect() not be put
  somewhere into usb.h ?
 
 Can I just move this declaration into h2200.c?

extern ... ? No, checkpatch will scream and extern is prohibited for a good 
reason.

 Łukasz Dałek

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 2/6] pxa25x: Add support for USB ethernet gadget

2012-09-23 Thread Marek Vasut
Dear Łukasz Dałek,

 On 23.09.2012 20:24, Marek Vasut wrote:
  Dear Łukasz Dałek,
  
  On 23.09.2012 17:44, Marek Vasut wrote:
  Dear Lukasz Dalek,
  
  Add to pxa25x based devices support for USB ethernet gadget. This is a
  port of pxa25x UDC driver from Linux kernel.
  
  Signed-off-by: Lukasz Dalekluk0...@gmail.com
  ---
  
 drivers/usb/gadget/Makefile |1 +
 drivers/usb/gadget/pxa25x_udc.c | 2059
  
  +++
  drivers/usb/gadget/pxa25x_udc.h
  
  | 162 +++
  | 
 3 files changed,  insertions(+), 0 deletions(-)
 create mode 100644 drivers/usb/gadget/pxa25x_udc.c
 create mode 100644 drivers/usb/gadget/pxa25x_udc.h
  
  [...]
  
  So what's the change here? Or is it a repost?
  
  Best regards,
  Marek Vasut
  
  Everything was fine except DEBUG_NOISY defintions. I fixed them and
  I have resend patch.
  
  http://www.denx.de/wiki/U-Boot/Patches did you read this? Worth reading
  so I don't have to repeat myself ;-)
 
 Yes.
 
  Can I ask what about patches 3,4,5,6?
  
  I think they're fine ... did you do any changes to them ?
 
 If they are ok then my job is done :-)

You did not answer my question ... and no, your job isn't done ... once your 
code is mainline, you're the maintainer, every change to common code will also 
be your responsibility to at least review/test on your hardware etc ... you 
know 
the drill.

Even though PXA is semi-dead, so I don't expect much happening there.

 Łukasz Dałek

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/6] h2200: Add support for iPAQ h2200 palmtop

2012-09-23 Thread Łukasz Dałek

On 23.09.2012 21:31, Marek Vasut wrote:

Dear Łukasz Dałek,


On 23.09.2012 17:43, Marek Vasut wrote:

+   gd-ram_size = CONFIG_SYS_SDRAM_SIZE;
+   return 0;
+}
diff --git a/board/h2200/h2200.h b/board/h2200/h2200.h
new file mode 100644

Do you need this file at all? Can the udc_disconnect() not be put
somewhere into usb.h ?

Can I just move this declaration into h2200.c?

extern ... ? No, checkpatch will scream and extern is prohibited for a good
reason.


So where should I put it?

Łukasz Dałek
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 2/6] pxa25x: Add support for USB ethernet gadget

2012-09-23 Thread Łukasz Dałek

On 23.09.2012 21:32, Marek Vasut wrote:

Dear Łukasz Dałek,


On 23.09.2012 20:24, Marek Vasut wrote:

Dear Łukasz Dałek,


On 23.09.2012 17:44, Marek Vasut wrote:

Dear Lukasz Dalek,


Add to pxa25x based devices support for USB ethernet gadget. This is a
port of pxa25x UDC driver from Linux kernel.

Signed-off-by: Lukasz Dalekluk0...@gmail.com
---

drivers/usb/gadget/Makefile |1 +
drivers/usb/gadget/pxa25x_udc.c | 2059

+++
drivers/usb/gadget/pxa25x_udc.h

| 162 +++
|
3 files changed,  insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/gadget/pxa25x_udc.c
create mode 100644 drivers/usb/gadget/pxa25x_udc.h

[...]

So what's the change here? Or is it a repost?

Best regards,
Marek Vasut

Everything was fine except DEBUG_NOISY defintions. I fixed them and
I have resend patch.

http://www.denx.de/wiki/U-Boot/Patches did you read this? Worth reading
so I don't have to repeat myself ;-)

Yes.


Can I ask what about patches 3,4,5,6?

I think they're fine ... did you do any changes to them ?

If they are ok then my job is done :-)

You did not answer my question ... and no, your job isn't done ... once your
code is mainline, you're the maintainer, every change to common code will also
be your responsibility to at least review/test on your hardware etc ... you know
the drill.

Even though PXA is semi-dead, so I don't expect much happening there.


No, since last email I didn't change anything.

But for now you have said that they're fine, so all I have to wait. Am I 
wrong?


Łukasz Dałek
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 1/6] h2200: Add support for iPAQ h2200 palmtop

2012-09-23 Thread Marek Vasut
Dear Łukasz Dałek,

 On 23.09.2012 21:31, Marek Vasut wrote:
  Dear Łukasz Dałek,
  
  On 23.09.2012 17:43, Marek Vasut wrote:
  +gd-ram_size = CONFIG_SYS_SDRAM_SIZE;
  +return 0;
  +}
  diff --git a/board/h2200/h2200.h b/board/h2200/h2200.h
  new file mode 100644
  
  Do you need this file at all? Can the udc_disconnect() not be put
  somewhere into usb.h ?
  
  Can I just move this declaration into h2200.c?
  
  extern ... ? No, checkpatch will scream and extern is prohibited for a
  good reason.
 
 So where should I put it?

Isn't it a general call? some include/usb.h ?

 Łukasz Dałek

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 2/6] pxa25x: Add support for USB ethernet gadget

2012-09-23 Thread Marek Vasut
Dear Łukasz Dałek,

 On 23.09.2012 21:32, Marek Vasut wrote:
  Dear Łukasz Dałek,
  
  On 23.09.2012 20:24, Marek Vasut wrote:
  Dear Łukasz Dałek,
  
  On 23.09.2012 17:44, Marek Vasut wrote:
  Dear Lukasz Dalek,
  
  Add to pxa25x based devices support for USB ethernet gadget. This is
  a port of pxa25x UDC driver from Linux kernel.
  
  Signed-off-by: Lukasz Dalekluk0...@gmail.com
  ---
  
  drivers/usb/gadget/Makefile |1 +
  drivers/usb/gadget/pxa25x_udc.c | 2059
  
  +++
  drivers/usb/gadget/pxa25x_udc.h
  
  | 162 +++
  | 
  3 files changed,  insertions(+), 0 deletions(-)
  create mode 100644 drivers/usb/gadget/pxa25x_udc.c
  create mode 100644 drivers/usb/gadget/pxa25x_udc.h
  
  [...]
  
  So what's the change here? Or is it a repost?
  
  Best regards,
  Marek Vasut
  
  Everything was fine except DEBUG_NOISY defintions. I fixed them and
  I have resend patch.
  
  http://www.denx.de/wiki/U-Boot/Patches did you read this? Worth reading
  so I don't have to repeat myself ;-)
  
  Yes.
  
  Can I ask what about patches 3,4,5,6?
  
  I think they're fine ... did you do any changes to them ?
  
  If they are ok then my job is done :-)
  
  You did not answer my question ... and no, your job isn't done ... once
  your code is mainline, you're the maintainer, every change to common
  code will also be your responsibility to at least review/test on your
  hardware etc ... you know the drill.
  
  Even though PXA is semi-dead, so I don't expect much happening there.
 
 No, since last email I didn't change anything.
 
 But for now you have said that they're fine, so all I have to wait. Am I
 wrong?

You're right.

 Łukasz Dałek

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


Re: [U-Boot] Performance of the ARM's PL310 L2 cache.

2012-09-23 Thread Marek Vasut
Dear Tom Rini,

 On Fri, Aug 17, 2012 at 05:49:53PM +0200, Lukasz Majewski wrote:
  Hi Aneesh,
  
  I've enabled the L2 cache for Trats board. Please find results from
  performance tests.
  The test function as well as my way for enabling L2 are attached to
  this e-mail.
 
 [snip]
 
  Have you had similar results with OMAP?
  Do you do more configuration when enabling the L2 at OMAP?
 
 At least on some parts, it's similar here.  The normal sequence of
 operations is loading a relatively small payload (kernel, maybe device
 tree) from storage and then booting it (which turns off L2 anyways).
 This is why I was willing to disable DCACHE as a USB workaround, the
 common use-case doesn't see a great deal of help from dcache being on.

I saw some pretty significant perf. boost with L1, I was planning to check L2 
on 
mx6q, but I'm not sure if it's worth it anymore.

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


[U-Boot] [PATCH] i2c_probe: update for use in scripting

2012-09-23 Thread Eric Nelson
Allow the use of an I2C address to test and return success
if one or more devices is found.

This allows device presence to alter the flow of a script.
e.g.
   if i2c probe 0x04 ; then
echo found Hannstar touch ;
   fi

Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
---
 common/cmd_i2c.c |   20 
 1 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/common/cmd_i2c.c b/common/cmd_i2c.c
index 795814d..b64b975 100644
--- a/common/cmd_i2c.c
+++ b/common/cmd_i2c.c
@@ -557,18 +557,28 @@ mod_i2c_mem(cmd_tbl_t *cmdtp, int incrflag, int flag, int 
argc, char * const arg
 
 /*
  * Syntax:
- * i2c probe {addr}{.0, .1, .2}
+ * i2c probe {addr}
+ *
+ * Returns zero (success) if one or more I2C devices was found
  */
 static int do_i2c_probe (cmd_tbl_t *cmdtp, int flag, int argc, char * const 
argv[])
 {
int j;
+   int addr = -1;
+   int found = 0;
 #if defined(CONFIG_SYS_I2C_NOPROBES)
int k, skip;
uchar bus = GET_BUS_NUM;
 #endif /* NOPROBES */
 
+   if (argc == 2)
+   addr = simple_strtol(argv[1], 0, 16);
+
puts (Valid chip addresses:);
for (j = 0; j  128; j++) {
+   if ((0 = addr)  (j != addr))
+   continue;
+
 #if defined(CONFIG_SYS_I2C_NOPROBES)
skip = 0;
for (k=0; k  NUM_ELEMENTS_NOPROBE; k++) {
@@ -580,8 +590,10 @@ static int do_i2c_probe (cmd_tbl_t *cmdtp, int flag, int 
argc, char * const argv
if (skip)
continue;
 #endif
-   if (i2c_probe(j) == 0)
+   if (i2c_probe(j) == 0) {
printf( %02X, j);
+   found++;
+   }
}
putc ('\n');
 
@@ -594,7 +606,7 @@ static int do_i2c_probe (cmd_tbl_t *cmdtp, int flag, int 
argc, char * const argv
putc ('\n');
 #endif
 
-   return 0;
+   return (0 == found);
 }
 
 /*
@@ -1331,7 +1343,7 @@ U_BOOT_CMD(
i2c mm chip address[.0, .1, .2] - write to I2C device 
(auto-incrementing)\n
i2c mw chip address[.0, .1, .2] value [count] - write to I2C device 
(fill)\n
i2c nm chip address[.0, .1, .2] - write to I2C device (constant 
address)\n
-   i2c probe - show devices on the I2C bus\n
+   i2c probe [address] - test for and show device(s) on the I2C bus\n
i2c read chip address[.0, .1, .2] length memaddress - read to memory 
\n
i2c reset - re-init the I2C Controller\n
 #if defined(CONFIG_CMD_SDRAM)
-- 
1.7.9

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


Re: [U-Boot] [PATCH v2 1/6] h2200: Add support for iPAQ h2200 palmtop

2012-09-23 Thread Łukasz Dałek

On 23.09.2012 22:05, Marek Vasut wrote:

Dear Łukasz Dałek,


On 23.09.2012 21:31, Marek Vasut wrote:

Dear Łukasz Dałek,


On 23.09.2012 17:43, Marek Vasut wrote:

+   gd-ram_size = CONFIG_SYS_SDRAM_SIZE;
+   return 0;
+}
diff --git a/board/h2200/h2200.h b/board/h2200/h2200.h
new file mode 100644

Do you need this file at all? Can the udc_disconnect() not be put
somewhere into usb.h ?

Can I just move this declaration into h2200.c?

extern ... ? No, checkpatch will scream and extern is prohibited for a
good reason.

So where should I put it?

Isn't it a general call? some include/usb.h ?


For old layer maybe it is.

I'm not sure but include/usb.h is for device implementing usb host but
pxa can only be device. Including usb.h generate error.

I'm going to add sd card support and other functions, maybe leaving it
would be better idea?

Łukasz Dałek
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 2/2] add Eukrea's CPUIMX25

2012-09-23 Thread Eric Bénard
Hi Stefano,

Le Sun, 23 Sep 2012 19:46:50 +0200,
Stefano Babic sba...@denx.de a écrit :
   nand_spl/board/eukrea/cpuimx25/Makefile   |   79 
   nand_spl/board/eukrea/cpuimx25/config.mk  |1 +
   nand_spl/board/eukrea/cpuimx25/u-boot.lds |   83 
 
 There is a main issue with these patches. According to some discussion
 in previous threads and hopefully I do not misinterprete Wolfgang's will
 about the direction that U-Boot will have in future, the nand_spl code
 is obsolete and it remains for the already supported boards.
 
 However, new boards must implement SPL using the SPL framework. New
 boards using nand_spl will not be integrated in mainline.
 
else that would have been to easy ;-)
OK I'll look at this SPL framework based on your serie introducing
woorburn board,

Thanks !
Eric

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


Re: [U-Boot] [PATCH v2 1/6] h2200: Add support for iPAQ h2200 palmtop

2012-09-23 Thread Marek Vasut
Dear Łukasz Dałek,

 On 23.09.2012 22:05, Marek Vasut wrote:
  Dear Łukasz Dałek,
  
  On 23.09.2012 21:31, Marek Vasut wrote:
  Dear Łukasz Dałek,
  
  On 23.09.2012 17:43, Marek Vasut wrote:
  +  gd-ram_size = CONFIG_SYS_SDRAM_SIZE;
  +  return 0;
  +}
  diff --git a/board/h2200/h2200.h b/board/h2200/h2200.h
  new file mode 100644
  
  Do you need this file at all? Can the udc_disconnect() not be put
  somewhere into usb.h ?
  
  Can I just move this declaration into h2200.c?
  
  extern ... ? No, checkpatch will scream and extern is prohibited for a
  good reason.
  
  So where should I put it?
  
  Isn't it a general call? some include/usb.h ?
 
 For old layer maybe it is.
 
 I'm not sure but include/usb.h is for device implementing usb host but
 pxa can only be device.

PXA can be both, actually u-boot is mostly about host. Just put it there.

 Including usb.h generate error.
 
 I'm going to add sd card support and other functions, maybe leaving it
 would be better idea?

Why do you think usb.h is not a good place ?

 Łukasz Dałek

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/6] h2200: Add support for iPAQ h2200 palmtop

2012-09-23 Thread Łukasz Dałek

On 23.09.2012 22:52, Marek Vasut wrote:

Dear Łukasz Dałek,


On 23.09.2012 22:05, Marek Vasut wrote:

Dear Łukasz Dałek,


On 23.09.2012 21:31, Marek Vasut wrote:

Dear Łukasz Dałek,


On 23.09.2012 17:43, Marek Vasut wrote:

+   gd-ram_size = CONFIG_SYS_SDRAM_SIZE;
+   return 0;
+}
diff --git a/board/h2200/h2200.h b/board/h2200/h2200.h
new file mode 100644

Do you need this file at all? Can the udc_disconnect() not be put
somewhere into usb.h ?

Can I just move this declaration into h2200.c?

extern ... ? No, checkpatch will scream and extern is prohibited for a
good reason.

So where should I put it?

Isn't it a general call? some include/usb.h ?

For old layer maybe it is.

I'm not sure but include/usb.h is for device implementing usb host but
pxa can only be device.

PXA can be both, actually u-boot is mostly about host. Just put it there.


Including usb.h generate error.

I'm going to add sd card support and other functions, maybe leaving it
would be better idea?

Why do you think usb.h is not a good place ?

Because:
#if defined(CONFIG_USB_UHCI) || defined(CONFIG_USB_OHCI) || \
defined(CONFIG_USB_EHCI) || defined(CONFIG_USB_OHCI_NEW) || \
defined(CONFIG_USB_SL811HS) || defined(CONFIG_USB_ISP116X_HCD) || \
defined(CONFIG_USB_R8A66597_HCD) || defined(CONFIG_USB_DAVINCI) || \
defined(CONFIG_USB_OMAP3) || defined(CONFIG_USB_DA8XX) || \
defined(CONFIG_USB_BLACKFIN) || defined(CONFIG_USB_AM35X)
...
#else
#error USB Lowlevel not defined
#endif

All of these definitions are usb host implementation (maybe OTG too) but pxa
cannot be host.

Łukasz Dałek
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 1/6] h2200: Add support for iPAQ h2200 palmtop

2012-09-23 Thread Marek Vasut
Dear Łukasz Dałek,

 On 23.09.2012 22:52, Marek Vasut wrote:
  Dear Łukasz Dałek,
  
  On 23.09.2012 22:05, Marek Vasut wrote:
  Dear Łukasz Dałek,
  
  On 23.09.2012 21:31, Marek Vasut wrote:
  Dear Łukasz Dałek,
  
  On 23.09.2012 17:43, Marek Vasut wrote:
  +gd-ram_size = CONFIG_SYS_SDRAM_SIZE;
  +return 0;
  +}
  diff --git a/board/h2200/h2200.h b/board/h2200/h2200.h
  new file mode 100644
  
  Do you need this file at all? Can the udc_disconnect() not be put
  somewhere into usb.h ?
  
  Can I just move this declaration into h2200.c?
  
  extern ... ? No, checkpatch will scream and extern is prohibited for
  a good reason.
  
  So where should I put it?
  
  Isn't it a general call? some include/usb.h ?
  
  For old layer maybe it is.
  
  I'm not sure but include/usb.h is for device implementing usb host but
  pxa can only be device.
  
  PXA can be both, actually u-boot is mostly about host. Just put it there.
  
  Including usb.h generate error.
  
  I'm going to add sd card support and other functions, maybe leaving it
  would be better idea?
  
  Why do you think usb.h is not a good place ?
 
 Because:
 #if defined(CONFIG_USB_UHCI) || defined(CONFIG_USB_OHCI) || \
  defined(CONFIG_USB_EHCI) || defined(CONFIG_USB_OHCI_NEW) || \
  defined(CONFIG_USB_SL811HS) || defined(CONFIG_USB_ISP116X_HCD) || \
  defined(CONFIG_USB_R8A66597_HCD) || defined(CONFIG_USB_DAVINCI) || \
  defined(CONFIG_USB_OMAP3) || defined(CONFIG_USB_DA8XX) || \
  defined(CONFIG_USB_BLACKFIN) || defined(CONFIG_USB_AM35X)
 ...
 #else
 #error USB Lowlevel not defined
 #endif
 
 All of these definitions are usb host implementation (maybe OTG too) but
 pxa cannot be host.

PXA2xx is OHCI host with one OTG port.

what about include/usb/pxa27x_udc.h ... btw can't pxa27x and pxa25x UDC use the 
same driver?

 Łukasz Dałek

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/6] h2200: Add support for iPAQ h2200 palmtop

2012-09-23 Thread Łukasz Dałek

On 23.09.2012 23:04, Marek Vasut wrote:

Dear Łukasz Dałek,


On 23.09.2012 22:52, Marek Vasut wrote:

Dear Łukasz Dałek,


On 23.09.2012 22:05, Marek Vasut wrote:

Dear Łukasz Dałek,


On 23.09.2012 21:31, Marek Vasut wrote:

Dear Łukasz Dałek,


On 23.09.2012 17:43, Marek Vasut wrote:

+   gd-ram_size = CONFIG_SYS_SDRAM_SIZE;
+   return 0;
+}
diff --git a/board/h2200/h2200.h b/board/h2200/h2200.h
new file mode 100644

Do you need this file at all? Can the udc_disconnect() not be put
somewhere into usb.h ?

Can I just move this declaration into h2200.c?

extern ... ? No, checkpatch will scream and extern is prohibited for
a good reason.

So where should I put it?

Isn't it a general call? some include/usb.h ?

For old layer maybe it is.

I'm not sure but include/usb.h is for device implementing usb host but
pxa can only be device.

PXA can be both, actually u-boot is mostly about host. Just put it there.


Including usb.h generate error.

I'm going to add sd card support and other functions, maybe leaving it
would be better idea?

Why do you think usb.h is not a good place ?

Because:
#if defined(CONFIG_USB_UHCI) || defined(CONFIG_USB_OHCI) || \
  defined(CONFIG_USB_EHCI) || defined(CONFIG_USB_OHCI_NEW) || \
  defined(CONFIG_USB_SL811HS) || defined(CONFIG_USB_ISP116X_HCD) || \
  defined(CONFIG_USB_R8A66597_HCD) || defined(CONFIG_USB_DAVINCI) || \
  defined(CONFIG_USB_OMAP3) || defined(CONFIG_USB_DA8XX) || \
  defined(CONFIG_USB_BLACKFIN) || defined(CONFIG_USB_AM35X)
...
#else
#error USB Lowlevel not defined
#endif

All of these definitions are usb host implementation (maybe OTG too) but
pxa cannot be host.

PXA2xx is OHCI host with one OTG port.


From pxa255 documentation:
The UDC supports 16 endpoints and can operate half-duplex at a rate of 
12 Mbps (as a slave only,

not as a host or hub controller).


what about include/usb/pxa27x_udc.h ... btw can't pxa27x and pxa25x UDC use the
same driver?


pxa27x_udc driver is using older layer which doesn't work with usb 
ethernet driver.


Btw. pxa27x can be host, pxa25x can't.

Łukasz Dałek
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 1/6] h2200: Add support for iPAQ h2200 palmtop

2012-09-23 Thread Marek Vasut
Dear Łukasz Dałek,

 On 23.09.2012 23:04, Marek Vasut wrote:
  Dear Łukasz Dałek,
  
  On 23.09.2012 22:52, Marek Vasut wrote:
  Dear Łukasz Dałek,
  
  On 23.09.2012 22:05, Marek Vasut wrote:
  Dear Łukasz Dałek,
  
  On 23.09.2012 21:31, Marek Vasut wrote:
  Dear Łukasz Dałek,
  
  On 23.09.2012 17:43, Marek Vasut wrote:
  +  gd-ram_size = CONFIG_SYS_SDRAM_SIZE;
  +  return 0;
  +}
  diff --git a/board/h2200/h2200.h b/board/h2200/h2200.h
  new file mode 100644
  
  Do you need this file at all? Can the udc_disconnect() not be put
  somewhere into usb.h ?
  
  Can I just move this declaration into h2200.c?
  
  extern ... ? No, checkpatch will scream and extern is prohibited
  for a good reason.
  
  So where should I put it?
  
  Isn't it a general call? some include/usb.h ?
  
  For old layer maybe it is.
  
  I'm not sure but include/usb.h is for device implementing usb host but
  pxa can only be device.
  
  PXA can be both, actually u-boot is mostly about host. Just put it
  there.
  
  Including usb.h generate error.
  
  I'm going to add sd card support and other functions, maybe leaving it
  would be better idea?
  
  Why do you think usb.h is not a good place ?
  
  Because:
  #if defined(CONFIG_USB_UHCI) || defined(CONFIG_USB_OHCI) || \
  
defined(CONFIG_USB_EHCI) || defined(CONFIG_USB_OHCI_NEW) || \
defined(CONFIG_USB_SL811HS) || defined(CONFIG_USB_ISP116X_HCD) ||
\ defined(CONFIG_USB_R8A66597_HCD) || defined(CONFIG_USB_DAVINCI)
|| \ defined(CONFIG_USB_OMAP3) || defined(CONFIG_USB_DA8XX) || \
defined(CONFIG_USB_BLACKFIN) || defined(CONFIG_USB_AM35X)
  
  ...
  #else
  #error USB Lowlevel not defined
  #endif
  
  All of these definitions are usb host implementation (maybe OTG too) but
  pxa cannot be host.
  
  PXA2xx is OHCI host with one OTG port.
 
  From pxa255 documentation:
 The UDC supports 16 endpoints and can operate half-duplex at a rate of
 12 Mbps (as a slave only,
 not as a host or hub controller).
 
  what about include/usb/pxa27x_udc.h ... btw can't pxa27x and pxa25x UDC
  use the same driver?
 
 pxa27x_udc driver is using older layer which doesn't work with usb
 ethernet driver.
 
 Btw. pxa27x can be host, pxa25x can't.

Can you update the new gadget driver to be compatible with pxa27x then ?

 Łukasz Dałek

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 1/4] COMMON: Add __stringify() function

2012-09-23 Thread Albert ARIBAUD
Hi Marek,

On Sun, 23 Sep 2012 20:21:54 +0200, Marek Vasut ma...@denx.de wrote:

 Dear Albert ARIBAUD,
 
  Hi Marek,
  
  On Sun, 23 Sep 2012 17:41:22 +0200, Marek Vasut ma...@denx.de wrote:
   Copied from Linux kernel:
   commit 8f7c2c37319a81ef4c2bfdec67b1ccd5744d97e4
   Date:   Wed Apr 8 16:58:57 2009 +0800
   
   This function converts static number to string in preprocessor.
   This is useful as it allows higher usage of puts() in favour of printf()
  
  Fix commit message: this fonction is not limited to numbers.
 
 WFM, can you review the series please ?

Sorry, should have mentioned that apart from this, the series looks
fine to me. FWIW:

Acked-by: Albert ARIBAUD albert.u.b...@aribaud.net

   Signed-off-by: Marek Vasut ma...@denx.de
   Cc: Wolfgang Denk w...@denx.de
   ---
   
include/common.h  |1 +
include/linux/stringify.h |   12 
2 files changed, 13 insertions(+), 0 deletions(-)
create mode 100644 include/linux/stringify.h
   
   diff --git a/include/common.h b/include/common.h
   index 55025c0..9937a57 100644
   --- a/include/common.h
   +++ b/include/common.h
   @@ -39,6 +39,7 @@ typedef volatile unsigned char  vu_char;
   
#include linux/bitops.h
#include linux/types.h
#include linux/string.h
   
   +#include linux/stringify.h
   
#include asm/ptrace.h
#include stdarg.h
#if defined(CONFIG_PCI)  (defined(CONFIG_4xx) 
!defined(CONFIG_AP1000))
   
   diff --git a/include/linux/stringify.h b/include/linux/stringify.h
   new file mode 100644
   index 000..841cec8
   --- /dev/null
   +++ b/include/linux/stringify.h
   @@ -0,0 +1,12 @@
   +#ifndef __LINUX_STRINGIFY_H
   +#define __LINUX_STRINGIFY_H
   +
   +/* Indirect stringification.  Doing two levels allows the parameter to
   be a + * macro itself.  For example, compile with -DFOO=bar,
   __stringify(FOO) + * converts to bar.
   + */
   +
   +#define __stringify_1(x...)  #x
   +#define __stringify(x...)__stringify_1(x)
   +
   +#endif   /* !__LINUX_STRINGIFY_H */
  
  Amicalement,
 
 Best regards,
 Marek Vasut

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


Re: [U-Boot] [PATCH v2 1/6] h2200: Add support for iPAQ h2200 palmtop

2012-09-23 Thread Łukasz Dałek

On 23.09.2012 23:31, Marek Vasut wrote:

Dear Łukasz Dałek,


On 23.09.2012 23:04, Marek Vasut wrote:


PXA2xx is OHCI host with one OTG port.

   From pxa255 documentation:
The UDC supports 16 endpoints and can operate half-duplex at a rate of
12 Mbps (as a slave only,
not as a host or hub controller).


what about include/usb/pxa27x_udc.h ... btw can't pxa27x and pxa25x UDC
use the same driver?

pxa27x_udc driver is using older layer which doesn't work with usb
ethernet driver.

Btw. pxa27x can be host, pxa25x can't.

Can you update the new gadget driver to be compatible with pxa27x then ?

I don't have any board with pxa27x processor. And I'm quite sure that
differences between pxa25x and pxa27x usb are too big. Even in
Linux kernel are two separate drivers for 25x and 27x chips.

Łukasz Dałek
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/4] COMMON: Add __stringify() function

2012-09-23 Thread Marek Vasut
Dear Albert ARIBAUD,

 Hi Marek,
 
 On Sun, 23 Sep 2012 20:21:54 +0200, Marek Vasut ma...@denx.de wrote:
  Dear Albert ARIBAUD,
  
   Hi Marek,
   
   On Sun, 23 Sep 2012 17:41:22 +0200, Marek Vasut ma...@denx.de wrote:
Copied from Linux kernel:
commit 8f7c2c37319a81ef4c2bfdec67b1ccd5744d97e4
Date:   Wed Apr 8 16:58:57 2009 +0800

This function converts static number to string in preprocessor.
This is useful as it allows higher usage of puts() in favour of
printf()
   
   Fix commit message: this fonction is not limited to numbers.
  
  WFM, can you review the series please ?
 
 Sorry, should have mentioned that apart from this, the series looks
 fine to me. FWIW:
 
 Acked-by: Albert ARIBAUD albert.u.b...@aribaud.net

Ok, and it's now build-tested properly on arm and PPC.

What would you expect in the commit message, lemme take a stab:

Pull in the __stringify() macro from Linux kernel. This macro is usually used 
to 
convert numbers to strings at preprocessor level, yet it is not limited only to 
that.

Seriously, I'm out of creative ideas here, please help :-(

Signed-off-by: Marek Vasut ma...@denx.de
Cc: Wolfgang Denk w...@denx.de
---

 include/common.h  |1 +
 include/linux/stringify.h |   12 
 2 files changed, 13 insertions(+), 0 deletions(-)
 create mode 100644 include/linux/stringify.h

diff --git a/include/common.h b/include/common.h
index 55025c0..9937a57 100644
--- a/include/common.h
+++ b/include/common.h
@@ -39,6 +39,7 @@ typedef volatile unsigned charvu_char;

 #include linux/bitops.h
 #include linux/types.h
 #include linux/string.h

+#include linux/stringify.h

 #include asm/ptrace.h
 #include stdarg.h
 #if defined(CONFIG_PCI)  (defined(CONFIG_4xx) 
 !defined(CONFIG_AP1000))

diff --git a/include/linux/stringify.h b/include/linux/stringify.h
new file mode 100644
index 000..841cec8
--- /dev/null
+++ b/include/linux/stringify.h
@@ -0,0 +1,12 @@
+#ifndef __LINUX_STRINGIFY_H
+#define __LINUX_STRINGIFY_H
+
+/* Indirect stringification.  Doing two levels allows the parameter
to be a + * macro itself.  For example, compile with -DFOO=bar,
__stringify(FOO) + * converts to bar.
+ */
+
+#define __stringify_1(x...)#x
+#define __stringify(x...)  __stringify_1(x)
+
+#endif /* !__LINUX_STRINGIFY_H */
   
   Amicalement,
  
  Best regards,
  Marek Vasut
 
 Amicalement,

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


Re: [U-Boot] [NEXT PATCH v1 2/7] NAND: added NAND type to nand_ids

2012-09-23 Thread Eric Bénard
Hi Stefano,

Le Mon, 10 Sep 2012 14:09:21 +0200,
Stefano Babic sba...@denx.de a écrit :
 The chip supports ONFI, but it seems the i.MX driver does not. Quite as
 described in http://patchwork.ozlabs.org/patch/60042/. READ-ID is always
 sent with address 0, I do not know if we can convince the driver to send
 the address.

to add ONFI support to i.MX's driver, you can check this patch (in
barebox, a similar patch for Linux is cooking, actually tested on
i.MX53 and i.MX25) :
http://git.pengutronix.de/?p=barebox.git;a=commit;h=632c45795065e6a7471ab82be38e808eb6204341

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


Re: [U-Boot] [PATCH V4] i.MX6: mx6qsabrelite: Add splash screen support

2012-09-23 Thread Eric Nelson

On 09/22/2012 10:19 AM, Eric Nelson wrote:

On 09/22/2012 10:02 AM, Fabio Estevam wrote:

Hi Eric,

On Sat, Sep 22, 2012 at 1:51 PM, Eric Nelson
eric.nel...@boundarydevices.com wrote:


Interestingly, I saw U-Boot display on HDMI during my testing,
so I'm pretty certain that all we need is the HDMI transmitter
initialization sequence.


Excellent, could you please share the HDMI transmitter init sequence?



Hi Fabio,

I haven't worked through the details, but I'm sure they're in here ;)

https://github.com/boundarydevices/linux-imx6/blob/boundary-L3.0.35_MX6DQ_ER_1208-Beta/drivers/video/mxc_hdmi.c



This may be easier than I thought (a set of writes to a single register).

I did a little digging, and it seems that the power-on defaults for the
HDMI transmitter work pretty well with my display (many thanks to the
chip designers!).

Without some more digging, I'm not very confident that the clocks
are all getting set up properly, but the attached patch allows me
to get 1080P video over HDMI.

It also highlights some issues in the I2C detection structure
(two parallel arrays that I hacked), but it gives me a lot more
confidence that HDMI is achievable in the short term for at least
one display.

Regards,


Eric
diff --git a/board/freescale/mx6qsabrelite/mx6qsabrelite.c b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
index ed60c6d..d274bad 100644
--- a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
+++ b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
@@ -39,6 +39,7 @@
 #include linux/fb.h
 #include ipu_pixfmt.h
 #include asm/arch/crm_regs.h
+#include asm/arch/mxc_hdmi.h
 #include i2c.h
 
 DECLARE_GLOBAL_DATA_PTR;
@@ -379,6 +380,20 @@ int setup_sata(void)
 
 #if defined(CONFIG_VIDEO_IPUV3)
 static struct fb_videomode videomodes[] = {{
+		.name   = HDMI,
+		.refresh= 60,
+		.xres   = 1920,
+		.yres   = 1080,
+		.pixclock   = 7692,
+		.left_margin= 100,
+		.right_margin   = 40,
+		.upper_margin   = 30,
+		.lower_margin   = 3,
+		.hsync_len  = 10,
+		.vsync_len  = 2,
+		.sync   = FB_SYNC_EXT, /* a.k.a. LVDS or HDMI */
+		.vmode  = FB_VMODE_NONINTERLACED
+	}, {
 		.name   = Hannstar-XGA,
 		.refresh= 60,
 		.xres   = 1024,
@@ -427,22 +442,33 @@ static struct fb_videomode videomodes[] = {{
 struct i2c_display {
 	int bus;
 	int addr;
+	int pixfmt;
 	char const *name;
 };
 
+#define IS_HDMI(d) (0  (d).bus)
+
 static struct i2c_display const i2c_displays[] = {
 {
+	.bus		= -1,
+	.addr		= -1,
+	.name   = HDMI,
+	.pixfmt		= IPU_PIX_FMT_RGB24,
+}, {
 	.bus		= 2,
 	.addr		= 0x4,
 	.name   = Hannstar-XGA,
+	.pixfmt		= IPU_PIX_FMT_LVDS666,
 }, {
 	.bus		= 2,
 	.addr		= 0x38,
 	.name   = wsvga-lvds,
+	.pixfmt		= IPU_PIX_FMT_LVDS666,
 }, {
 	.bus		= 2,
 	.addr		= 0x48,
 	.name   = wvga-rgb,
+	.pixfmt		= IPU_PIX_FMT_RGB666,
 } };
 
 static iomux_v3_cfg_t rgb_pads[] = {
@@ -495,12 +521,20 @@ int board_video_skip(void)
 	if (!panel) {
 		for (i = 0; i  ARRAY_SIZE(i2c_displays); i++) {
 			struct i2c_display const *dev = i2c_displays+i;
-			if ((0 == i2c_set_bus_num(dev-bus))
+			if ((0  dev-bus)
+			 
+			(0 == i2c_set_bus_num(dev-bus))
 			 
 			(0 == i2c_probe(dev-addr))) {
 panel = dev-name;
 printf(auto-detected panel %s\n, panel);
 break;
+			} else if (0  dev-bus) {
+u8 reg = __raw_readb(HDMI_ARB_BASE_ADDR+HDMI_PHY_STAT0);
+if (regHDMI_PHY_HPD) {
+	panel = dev-name;
+	printf(detected HDMI monitor\n);
+}
 			}
 		}
 		if (!panel) {
@@ -513,9 +547,26 @@ int board_video_skip(void)
 			break;
 	}
 	if (i  ARRAY_SIZE(videomodes)) {
-		ret = ipuv3_fb_init(videomodes+i, 0, IPU_PIX_FMT_RGB666);
+		ret = ipuv3_fb_init(videomodes+i, 0, i2c_displays[i].pixfmt);
 		if (!ret) {
-			if (IS_LVDS(videomodes[i]))
+			if IS_HDMI(i2c_displays[i]) {
+u8 reg;
+reg = __raw_readb(
+		HDMI_ARB_BASE_ADDR
+		+HDMI_PHY_CONF0);
+reg |= HDMI_PHY_CONF0_PDZ_MASK;
+__raw_writeb(reg,
+	 HDMI_ARB_BASE_ADDR
+		+HDMI_PHY_CONF0);
+reg |= HDMI_PHY_CONF0_ENTMDS_MASK;
+__raw_writeb(reg,
+	 HDMI_ARB_BASE_ADDR
+		+HDMI_PHY_CONF0);
+reg |= HDMI_PHY_CONF0_GEN2_TXPWRON_MASK;
+__raw_writeb(reg,
+	 HDMI_ARB_BASE_ADDR
+		+HDMI_PHY_CONF0);
+			} else if (IS_LVDS(videomodes[i]))
 gpio_direction_output(LVDS_BACKLIGHT_GP, 1);
 			else {
 imx_iomux_v3_setup_multiple_pads(
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] How to manage RMOBILE patches?

2012-09-23 Thread Nobuhiro Iwamatsu
Hi,

ping

Best regards,
  Nobuhiro

On Mon, Sep 10, 2012 at 9:41 AM, Nobuhiro Iwamatsu iwama...@nigauri.org wrote:
 Hi,

 On Sat, Sep 8, 2012 at 2:09 AM, Albert ARIBAUD
 albert.u.b...@aribaud.net wrote:
 Hi Tom,

 On Thu, 6 Sep 2012 13:58:57 -0700, Tom Rini tr...@ti.com wrote:

 On 09/06/2012 12:28 PM, Albert ARIBAUD wrote:
  Hi Nobuhiro,
 
  On Thu, 6 Sep 2012 08:20:59 +0900, Nobuhiro Iwamatsu
  iwama...@nigauri.org wrote:
 
  Hi, Tom.
 
  On Wed, Sep 5, 2012 at 11:17 PM, Tom Rini tr...@ti.com wrote:
  On 09/05/2012 04:18 AM, Albert ARIBAUD wrote:
  Hi Nobuhiro,
 
  On Wed, 5 Sep 2012 11:26:37 +0900, Nobuhiro Iwamatsu
  iwama...@nigauri.org wrote:
 
  Hi,
 
  On Wed, Sep 5, 2012 at 2:36 AM, Tom Rini tr...@ti.com wrote:
  On Mon, Sep 03, 2012 at 09:15:56PM +0200, Wolfgang Denk wrote:
  Dear Nobuhiro Iwamatsu,
 
  In message
  CABMQnVLBEEjcEtfTzdeThHfTLp=b24qsognfjbzr-8ywytj...@mail.gmail.com
  you wrote:
 
  I am working supporting  Renesas RMOBILE to U-Boot.
  Renesas's RMOBILE SoC family contains an ARM Cortex-A9, and
  this uses the same IP as SH.
  (For example, timer, ether, serial, etc.)
  I already sent to patches of rmobile, I got review from some
  developers. And the patch is managed by the arm/rmobile
  branch of u-boot-sh[0] which I have maintained, now.
  Since I had you take the patch of rmobile into an ARM
  repository, I consulted with Albert about the
  future development approach.
 
  We thought two methods are considered.
  One is Albert picks up a patch from ML to ARM repository,
 
  As this is ARM code, this appears the most natural approach to
  me
 
  Another is whether to have pull from the repository by
  having a repository for rmobile made.
 
  If this is an ARM SoC, then it should go through the ARM repo
  - even if we should later decide that there is so much traffic
  that a separate rmobile repo would be sustified, thi would
  still be a sub-repo, which Albert would pull from.
 
  Another option, which Mike is using for, iirc, sf and blackfin,
  is just to add rmobile-master / rmobile-next as branches to the
  u-boot-sh repository.
 
  Yes, this is one of easy way. But Albert won't  pull form
  u-boot-sh, if If my understanding is not wrong.
 
  This just means that they'll end up on u-boot/master from
  u-boot.sh (and from there into u-boot-arm later on).
 
  To be clear, what I'm saying is just add a few more branches to
  u-boot-sh that Albert will pull (since they're ARM stuff).  Say
  u-boot-sh/rmobile/master and u-boot-sh/rmobile/next.  Then not get
  too hung up on which repository a merge message comes from. :)
 
 
  I was going to do by how to explain you.
  However, I think that Albert mistook by my shortage of explanation.
  Thank you for following up.
 
  Nobuhiro
 
  I understand that some ARM patches would be stored in some branch
  (say rmobile/master) of the u-boot-sh repo and pull-requested to me
  from there.
 
  What I still don't understand is *why* this should be done. Before
  they get on this branch, the patches would still have to go through
  the mailing list for review, just like the ARM patches that end up
  applied to u-boot-arm/master, except they'd have to do through an
  intermediate branch. If there are benefits in this, someone will
  have to lay them out for me, because right now I don't see them.

 I think the answer is, given how you wish to work, there's not.  It's
 a workflow problem only.  If it's no easier for you to get a pull
 request from Nobuhiro once the patches have been reviewed than for
 you to pull them out of patchwork once they have been reviewed, then
 since your preference is for patchwork, via patchwork and into
 u-boot-arm is how they'll work.

 Thanks for this answer. I personally prefer applying patches from
 patchwork directly into u-boot-arm/master.

 OK, could you pickup rmobile patches from patchwork, please?
 But I already archived rmobile patches in patchwork..

 Best regards,
   Nobuhiro

 --
 Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6



-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 0/3] i.MX6: implement hdmidet command

2012-09-23 Thread Eric Nelson
This series implements an HDMI detection command for i.MX6 boards
and configures mx6qsabrelite to use it as discussed in this
thread on the ML:
 http://lists.denx.de/pipermail/u-boot/2012-September/135037.html

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


[U-Boot] [PATCH 2/3] i.MX6: Add hdmidet command to detect attached HDMI monitor

2012-09-23 Thread Eric Nelson
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
---
 arch/arm/imx-common/Makefile  |1 +
 arch/arm/imx-common/cmd_hdmidet.c |   37 +
 2 files changed, 38 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/imx-common/cmd_hdmidet.c

diff --git a/arch/arm/imx-common/Makefile b/arch/arm/imx-common/Makefile
index 31dc52e..7c1e34c 100644
--- a/arch/arm/imx-common/Makefile
+++ b/arch/arm/imx-common/Makefile
@@ -33,6 +33,7 @@ COBJS-$(CONFIG_I2C_MXC) += i2c-mxv7.o
 endif
 COBJS-$(CONFIG_CMD_BMODE) += cmd_bmode.o
 COBJS-y += preboot_os.o
+COBJS-$(CONFIG_CMD_HDMIDETECT) += cmd_hdmidet.o
 COBJS  := $(sort $(COBJS-y))
 
 SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
diff --git a/arch/arm/imx-common/cmd_hdmidet.c 
b/arch/arm/imx-common/cmd_hdmidet.c
new file mode 100644
index 000..ede5d88
--- /dev/null
+++ b/arch/arm/imx-common/cmd_hdmidet.c
@@ -0,0 +1,37 @@
+/*
+ * Copyright (C) 2012 Boundary Devices Inc.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that 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., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+#include common.h
+#include asm/arch/imx-regs.h
+#include asm/arch/mxc_hdmi.h
+#include asm/io.h
+
+int do_hdmidet(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
+{
+   u8 reg = __raw_readb(HDMI_ARB_BASE_ADDR+HDMI_PHY_STAT0);
+   return (regHDMI_PHY_HPD)
+   ? 0 : 1;
+}
+
+U_BOOT_CMD(hdmidet, 1, 1, do_hdmidet,
+   detect HDMI monitor,
+   
+);
-- 
1.7.9

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


[U-Boot] [PATCH 1/3] i.MX6: add HDMI transmitter register declarations from kernel WIP.

2012-09-23 Thread Eric Nelson
Original source from Pengutronix HDMI driver work:


http://git.pengutronix.de/?p=imx/linux-2.6.git;a=commitdiff;h=72c31cd67ac880bd90785af86f8e46f8ea7b3bb0

Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
---
 arch/arm/include/asm/arch-mx6/mxc_hdmi.h | 1053 ++
 1 files changed, 1053 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-mx6/mxc_hdmi.h

diff --git a/arch/arm/include/asm/arch-mx6/mxc_hdmi.h 
b/arch/arm/include/asm/arch-mx6/mxc_hdmi.h
new file mode 100644
index 000..02a413f
--- /dev/null
+++ b/arch/arm/include/asm/arch-mx6/mxc_hdmi.h
@@ -0,0 +1,1053 @@
+/*
+ * Copyright (C) 2011 Freescale Semiconductor, Inc.
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that 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 Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+#ifndef __MXC_HDMI_H__
+#define __MXC_HDMI_H__
+
+/*
+ * Hdmi controller registers
+ */
+
+/* Identification Registers */
+#define HDMI_DESIGN_ID  0x
+#define HDMI_REVISION_ID0x0001
+#define HDMI_PRODUCT_ID00x0002
+#define HDMI_PRODUCT_ID10x0003
+#define HDMI_CONFIG0_ID 0x0004
+#define HDMI_CONFIG1_ID 0x0005
+#define HDMI_CONFIG2_ID 0x0006
+#define HDMI_CONFIG3_ID 0x0007
+
+/* Interrupt Registers */
+#define HDMI_IH_FC_STAT00x0100
+#define HDMI_IH_FC_STAT10x0101
+#define HDMI_IH_FC_STAT20x0102
+#define HDMI_IH_AS_STAT00x0103
+#define HDMI_IH_PHY_STAT0   0x0104
+#define HDMI_IH_I2CM_STAT0  0x0105
+#define HDMI_IH_CEC_STAT0   0x0106
+#define HDMI_IH_VP_STAT00x0107
+#define HDMI_IH_I2CMPHY_STAT0   0x0108
+#define HDMI_IH_AHBDMAAUD_STAT0 0x0109
+
+#define HDMI_IH_MUTE_FC_STAT0   0x0180
+#define HDMI_IH_MUTE_FC_STAT1   0x0181
+#define HDMI_IH_MUTE_FC_STAT2   0x0182
+#define HDMI_IH_MUTE_AS_STAT0   0x0183
+#define HDMI_IH_MUTE_PHY_STAT0  0x0184
+#define HDMI_IH_MUTE_I2CM_STAT0 0x0185
+#define HDMI_IH_MUTE_CEC_STAT0  0x0186
+#define HDMI_IH_MUTE_VP_STAT0   0x0187
+#define HDMI_IH_MUTE_I2CMPHY_STAT0  0x0188
+#define HDMI_IH_MUTE_AHBDMAAUD_STAT00x0189
+#define HDMI_IH_MUTE0x01FF
+
+/* Video Sample Registers */
+#define HDMI_TX_INVID0  0x0200
+#define HDMI_TX_INSTUFFING  0x0201
+#define HDMI_TX_GYDATA0 0x0202
+#define HDMI_TX_GYDATA1 0x0203
+#define HDMI_TX_RCRDATA00x0204
+#define HDMI_TX_RCRDATA10x0205
+#define HDMI_TX_BCBDATA00x0206
+#define HDMI_TX_BCBDATA10x0207
+
+/* Video Packetizer Registers */
+#define HDMI_VP_STATUS  0x0800
+#define HDMI_VP_PR_CD   0x0801
+#define HDMI_VP_STUFF   0x0802
+#define HDMI_VP_REMAP   0x0803
+#define HDMI_VP_CONF0x0804
+#define HDMI_VP_STAT0x0805
+#define HDMI_VP_INT 0x0806
+#define HDMI_VP_MASK0x0807
+#define HDMI_VP_POL 0x0808
+
+/* Frame Composer Registers */
+#define HDMI_FC_INVIDCONF   0x1000
+#define HDMI_FC_INHACTV00x1001
+#define HDMI_FC_INHACTV10x1002
+#define HDMI_FC_INHBLANK0   0x1003
+#define HDMI_FC_INHBLANK1   0x1004
+#define HDMI_FC_INVACTV00x1005
+#define HDMI_FC_INVACTV10x1006
+#define HDMI_FC_INVBLANK0x1007
+#define HDMI_FC_HSYNCINDELAY0   0x1008
+#define HDMI_FC_HSYNCINDELAY1   0x1009
+#define HDMI_FC_HSYNCINWIDTH0   0x100A
+#define HDMI_FC_HSYNCINWIDTH1   0x100B
+#define HDMI_FC_VSYNCINDELAY

[U-Boot] [PATCH 3/3] i.MX6: mx6qsabrelite: Include hdmidet command.

2012-09-23 Thread Eric Nelson
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
---
 board/freescale/mx6qsabrelite/mx6qsabrelite.c |6 ++
 include/configs/mx6qsabrelite.h   |1 +
 2 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/board/freescale/mx6qsabrelite/mx6qsabrelite.c 
b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
index d274d8c..ed60c6d 100644
--- a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
+++ b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
@@ -551,6 +551,12 @@ void lcd_iomux(void)
|MXC_CCM_CCGR3_LDB_DI0_MASK;
writel(reg, mxc_ccm-CCGR3);
 
+   /* Turn on HDMI PHY clock */
+   reg = __raw_readl(mxc_ccm-CCGR2);
+   reg |=  MXC_CCM_CCGR2_HDMI_TX_IAHBCLK_MASK
+  |MXC_CCM_CCGR2_HDMI_TX_ISFRCLK_MASK;
+   writel(reg, mxc_ccm-CCGR2);
+
/* set PFD1_FRAC to 0x13 == 455 MHz (480*18)/0x13 */
writel(ANATOP_PFD_480_PFD1_FRAC_MASK, anatop-pfd_480_clr);
writel(0x13ANATOP_PFD_480_PFD1_FRAC_SHIFT, anatop-pfd_480_set);
diff --git a/include/configs/mx6qsabrelite.h b/include/configs/mx6qsabrelite.h
index 8601685..80707d0 100644
--- a/include/configs/mx6qsabrelite.h
+++ b/include/configs/mx6qsabrelite.h
@@ -144,6 +144,7 @@
 #define CONFIG_BMP_16BPP
 #define CONFIG_VIDEO_LOGO
 #define CONFIG_IPUV3_CLK 26000
+#define CONFIG_CMD_HDMIDETECT
 
 /* allow to overwrite serial and ethaddr */
 #define CONFIG_ENV_OVERWRITE
-- 
1.7.9

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


Re: [U-Boot] [PATCH v2 1/6] h2200: Add support for iPAQ h2200 palmtop

2012-09-23 Thread Marek Vasut
Dear Łukasz Dałek,

 On 23.09.2012 23:31, Marek Vasut wrote:
  Dear Łukasz Dałek,
  
  On 23.09.2012 23:04, Marek Vasut wrote:
  PXA2xx is OHCI host with one OTG port.
  
 From pxa255 documentation:
  The UDC supports 16 endpoints and can operate half-duplex at a rate of
  12 Mbps (as a slave only,
  not as a host or hub controller).
  
  what about include/usb/pxa27x_udc.h ... btw can't pxa27x and pxa25x UDC
  use the same driver?
  
  pxa27x_udc driver is using older layer which doesn't work with usb
  ethernet driver.
  
  Btw. pxa27x can be host, pxa25x can't.
  
  Can you update the new gadget driver to be compatible with pxa27x then ?
 
 I don't have any board with pxa27x processor. And I'm quite sure that
 differences between pxa25x and pxa27x usb are too big. Even in
 Linux kernel are two separate drivers for 25x and 27x chips.

Isn't the 25x only a subset of the 27x ?

 Łukasz Dałek

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 6/6] fdt: Add a Linux tool for reading values from FDT files

2012-09-23 Thread Marek Vasut
Dear Mike Frysinger,

 On Monday 20 August 2012 20:51:32 Joe Hershberger wrote:
  On Mon, Aug 20, 2012 at 7:24 PM, Mike Frysinger wrote:
   On Monday 20 August 2012 19:40:45 Joe Hershberger wrote:
   On Fri, Aug 17, 2012 at 6:35 PM, Mike Frysinger wrote:
On Friday 17 August 2012 16:34:40 Joe Hershberger wrote:
Designed to be able to access itb files on a filesystem or an mtd
partition.

Supports print and list (like the fdt command) and also offset for
finding the offset and size of a given property in an FDT file.

This is especially helpful when reading properties from an ITB
file.

doesn't the ftdump utility from the dtc package cover your needs ?
   
   No.  The purpose is to use this utility e.g. in a Linux shell script
   to retrieve a property from the ITB.  The two places I use it are to
   retrieve a version number from the ITB and to identify the offset and
   size of a data block (image) in the ITB.
   
   From what I can see the ftdump utility in the dtc component just dumps
   the ITB as a single blob with no options.  I'm looking at the dtc
   1.2.0 source.
   
   ... so wouldn't the logical thing be to extend ftdump to support your
   needs and send a patch to the DTC authors rather than to write an
   entire tool from scratch and commit it to a tree that is merely a user
   of device trees ?
  
  Yes it probably would have been, if I had noticed that the ftdump
  utility existed, then that is the approach I would have taken.  I
  think it is of specific use to u-boot users, but if you think it's
  better to extend ftdump, I guess I could take that approach.
 
 i think it has a better chance of being maintained and other people using
 it if it were merged into the canonical DTC project.  i can see a more
 swiss army type tool being useful to people rather than having to pipe it
 all through awk.
 
 git: git://git.jdl.com/software/dtc.git
 e-mail: devicetree-disc...@lists.ozlabs.org
 
 they're friendly people :)

Mostly :-)

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 v8] [RFC] early_malloc for DM added.

2012-09-23 Thread Marek Vasut
Dear Tomas Hlavacek,

[..]
 +
 + if (early_malloc_active()) {
 + addr = early_malloc(size);
 + for (i=0; isize; i++)
 + addr[i] = 0;

memset() ?

 +
 + return addr;
 + }
 +#endif /* CONFIG_SYS_EARLY_MALLOC */
 + return calloc(n, elem_size);
 +}
 +
 +static inline void *dmrealloc(void *oldmem, size_t bytes)
 +{
 +#ifdef CONFIG_SYS_EARLY_MALLOC
 + if (early_malloc_active())
 + return NULL;

I wonder how should this be implemented ... maybe early_malloc + standard 
memcpy()

 +#endif /* CONFIG_SYS_EARLY_MALLOC */
 + return dmrealloc(oldmem, bytes);
 +}
 +
 +#endif /* CONFIG_DM */
 +#endif /* __INCLUDE_DMMALLOC_H */
 +

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/6] h2200: Add support for iPAQ h2200 palmtop

2012-09-23 Thread Łukasz Dałek

On 24.09.2012 01:05, Marek Vasut wrote:

Dear Łukasz Dałek,


On 23.09.2012 23:31, Marek Vasut wrote:

Dear Łukasz Dałek,


On 23.09.2012 23:04, Marek Vasut wrote:

PXA2xx is OHCI host with one OTG port.


 From pxa255 documentation:
The UDC supports 16 endpoints and can operate half-duplex at a rate of
12 Mbps (as a slave only,
not as a host or hub controller).


what about include/usb/pxa27x_udc.h ... btw can't pxa27x and pxa25x UDC
use the same driver?

pxa27x_udc driver is using older layer which doesn't work with usb
ethernet driver.

Btw. pxa27x can be host, pxa25x can't.

Can you update the new gadget driver to be compatible with pxa27x then ?

I don't have any board with pxa27x processor. And I'm quite sure that
differences between pxa25x and pxa27x usb are too big. Even in
Linux kernel are two separate drivers for 25x and 27x chips.

Isn't the 25x only a subset of the 27x ?


Maybe it is.

You've asked me if I could update driver to compatible with pxa27x and my
answer is no. Maybe someone with pxa27x chip could.

I will left that h2200.h header. I'm sure that it will be helpful some day.

Łukasz Dałek
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 1/6] h2200: Add support for iPAQ h2200 palmtop

2012-09-23 Thread Marek Vasut
Dear Łukasz Dałek,

 On 24.09.2012 01:05, Marek Vasut wrote:
  Dear Łukasz Dałek,
  
  On 23.09.2012 23:31, Marek Vasut wrote:
  Dear Łukasz Dałek,
  
  On 23.09.2012 23:04, Marek Vasut wrote:
  PXA2xx is OHCI host with one OTG port.
  
   From pxa255 documentation:
  The UDC supports 16 endpoints and can operate half-duplex at a rate
  of 12 Mbps (as a slave only,
  not as a host or hub controller).
  
  what about include/usb/pxa27x_udc.h ... btw can't pxa27x and pxa25x
  UDC use the same driver?
  
  pxa27x_udc driver is using older layer which doesn't work with usb
  ethernet driver.
  
  Btw. pxa27x can be host, pxa25x can't.
  
  Can you update the new gadget driver to be compatible with pxa27x then
  ?
  
  I don't have any board with pxa27x processor. And I'm quite sure that
  differences between pxa25x and pxa27x usb are too big. Even in
  Linux kernel are two separate drivers for 25x and 27x chips.
  
  Isn't the 25x only a subset of the 27x ?
 
 Maybe it is.
 
 You've asked me if I could update driver to compatible with pxa27x and my
 answer is no. Maybe someone with pxa27x chip could.

I can test it. It'd be good to have only one driver and get rid of the old one 
seems to be the way to go.

 I will left that h2200.h header. I'm sure that it will be helpful some day.

For what exactly? Just put it into include/usb.h .

 Łukasz Dałek

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 08/21] mx6: add plugin file for use with imximage.cfg

2012-09-23 Thread Eric Nelson

On 09/23/2012 10:08 AM, Stefano Babic wrote:

On 23/09/2012 18:23, Eric Nelson wrote:

On 09/23/2012 03:17 AM, Stefano Babic wrote:

On 22/09/2012 04:39, Troy Kisky wrote:

The plugin command of mkimage can take this
file as an argument.

Signed-off-by: Troy Kiskytroy.ki...@boundarydevices.com
---


Hi Troy,

I agree with Vikram that a better explanation of what a plugin is can
help to understand without reading deeply into the i.MX6 manual.

So a plugin is a chunk of code that can be called directly by the
BootROM of i.MX processors supporting V2 version of the i.MX header.
In my understanding, this is supported by i.MX53, too. After the plugin
run, the control is returned to the BootROM.


Hi Stefano,

It seems that there's some general confusion on the list, so I think
a little more background and commentary is in order.


Well, it is - thanks for explanation.



The primary rationale for plugins is to allow separate link maps in
a single image loaded by the BootROM.

The idea is to allow first-level code to initialize resources (usually
DDR) while running in internal RAM, then return to the boot rom for
further image loading (typically into DDR). This prevents the need
for the first-level code to support all boot sources (SPI-NOR,
NAND, SD card, etc) and allows it to focus on machine setup.

The feature is normally needed to allow the first level to access
a PMIC. I'm surprised that the 51evk and 53Loco boards aren't
using it.


The mx51 uses a V1 header and the plugin feature is not supported at
all. So, it can't, simply. The mx53 can, but it is not needed.
Both boards boot without plugin. So it seem we have a misunderstanding,
and thanks to raise this issue ;-)

The setup is done by the SOC interpreting the DCD data into the iMX
header. After this setup, that in any case cannot be very long, the
control is still taken by the bootROM, that copies data from the media
device to the DDR according to the values set into the iMX header. Still
without plugin. After the copy, the bootROM gives the control to U-Boot
for the rest that starts with the usual initialization.

There is no need to setup the pMIC on mx51evk and mx53qsb to get the DDR
running. However, even if we need it, we can do it in another way, as I
will explain now.



Troy's rationale for using it now is to enable a single image on
i.MX6Quad, Dual lite and Solo processors, which have very slight
initialization differences. The 6Solo processor has 32-bit DDR
bus, so it would otherwise require a separate binary.

By doing this in code (plugin), we can introduce a conditional
based on processor type and have a single image that will boot
on any of the three.


Ok - but why cannot this check be done directly by U-Boot ?

My understanding is that you want to add a plugin written in assembly to
allow different setup of the DDR controller. Let's see how we can do
with standard U-Boot code.

Core of the startup is that the SOC copies itself some code into the
internal RAM and started. This is done by bootROM, running is own code
and running the plugin.

We have already this mechanism with the SPL framework. The big advantage
for this approach is that the same mechanism can be used on SOC of
different vendors, while the one in this series is a solution strictly
bound with (some) Freescale's SOC.

The imx header can be still adapted to copy the SPL code into the
internal RAM. When SPL is running, you have all freedom to check which
is the CPU running and to adjust your DDR setting, and everything is C
code. Both MX5 and MX6 have plenty of internal RAM to do this, because
SPL requires ~30KB.



This is the part that gets interesting.

You're right that SPL **can** do the job, but only if it supports
the boot media. For the most part, it's reasonable to expect the
code to be written in U-Boot for that, since the boot media may
also be used to load kernels, RAM disks and the like.

But what about the serial boot modes (especially USB)? We likely
wouldn't implement them (we haven't yet pulled in USB slave support)
and to paraphrase US bumper stickers:

You can take imx_usb away from me when you pry it
from my cold dead hands ;)

If you're not aware of imx_usb, it's a utility that Troy wrote
to allow download over the boot ROM's USB protocol.

Some commentary is here:
http://boundarydevices.com/unbricking-nitrogen6x-sabre-lite-i-mx6-board/

The sources are here (requires libusb):
https://github.com/boundarydevices/imx_usb_loader


I think the goal to have the same U-Boot binary can be reached using the
SPL framework. As you are running U-Boot code, you have the possibility
to do whatever you want.

So my question is: if the main reason is to have a single image for all
your iMX6 boards, why cannot we do it in a standard way using SPL ?



The related question is whether or not the benefits of a single
image is worth the carrying cost.

This is probably more useful for those who boot directly to
SD card, where the cost of 

Re: [U-Boot] [PATCH v2 1/6] h2200: Add support for iPAQ h2200 palmtop

2012-09-23 Thread Łukasz Dałek

On 24.09.2012 01:25, Marek Vasut wrote:

Dear Łukasz Dałek,


On 24.09.2012 01:05, Marek Vasut wrote:

Dear Łukasz Dałek,


On 23.09.2012 23:31, Marek Vasut wrote:

Dear Łukasz Dałek,


On 23.09.2012 23:04, Marek Vasut wrote:

PXA2xx is OHCI host with one OTG port.


   From pxa255 documentation:
The UDC supports 16 endpoints and can operate half-duplex at a rate
of 12 Mbps (as a slave only,
not as a host or hub controller).


what about include/usb/pxa27x_udc.h ... btw can't pxa27x and pxa25x
UDC use the same driver?

pxa27x_udc driver is using older layer which doesn't work with usb
ethernet driver.

Btw. pxa27x can be host, pxa25x can't.

Can you update the new gadget driver to be compatible with pxa27x then
?

I don't have any board with pxa27x processor. And I'm quite sure that
differences between pxa25x and pxa27x usb are too big. Even in
Linux kernel are two separate drivers for 25x and 27x chips.

Isn't the 25x only a subset of the 27x ?

Maybe it is.

You've asked me if I could update driver to compatible with pxa27x and my
answer is no. Maybe someone with pxa27x chip could.

I can test it. It'd be good to have only one driver and get rid of the old one
seems to be the way to go.


Does this driver work with usb ethernet gadget?




I will left that h2200.h header. I'm sure that it will be helpful some day.

For what exactly? Just put it into include/usb.h .

I can't. It doesn't compile because of #error at 170 line.

Łukasz Dałek
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v8] [RFC] early_malloc for DM added.

2012-09-23 Thread Graeme Russ
Hi Tomas,

On Mon, Sep 24, 2012 at 2:15 AM, Tomas Hlavacek tmshl...@gmail.com wrote:
 early_malloc for DM with support for more heaps and lightweight
 first heap in the same memory as an early stack.

 Adaptation layer for seamless calling of early_malloc or dlmalloc from
 DM based on init stage added (dmmalloc() and related functions).

 Signed-off-by: Tomas Hlavacek tmshl...@gmail.com
 ---
 Changelog since v5:
 dmmalloc() and all dm* functions has been moved to header, made static
 inline and preprocessor-dependent blocks are reworked.
 early_malloc_active() corrected and made not static.
 s/CONFIG_SYS_DM/CONFIG_DM/ applied.

 Changelog sice v6:
 Check of first heap emptyness in early_brk() has been simplified.

 Changelog since v7:
 dmcalloc() implmentation added.
 Comments added to header.

  arch/arm/include/asm/global_data.h|3 +
  arch/arm/lib/board.c  |8 ++
  arch/avr32/include/asm/global_data.h  |3 +
  arch/avr32/lib/board.c|9 +++
  arch/blackfin/include/asm/global_data.h   |3 +
  arch/blackfin/lib/board.c |8 ++
  arch/m68k/include/asm/global_data.h   |3 +
  arch/m68k/lib/board.c |8 ++
  arch/microblaze/include/asm/global_data.h |3 +
  arch/microblaze/lib/board.c   |9 +++
  arch/mips/include/asm/global_data.h   |3 +
  arch/mips/lib/board.c |8 ++
  arch/nds32/include/asm/global_data.h  |3 +
  arch/nds32/lib/board.c|8 ++
  arch/nios2/include/asm/global_data.h  |3 +
  arch/nios2/lib/board.c|8 ++
  arch/openrisc/include/asm/global_data.h   |3 +
  arch/openrisc/lib/board.c |8 ++
  arch/powerpc/include/asm/global_data.h|3 +
  arch/powerpc/lib/board.c  |8 ++
  arch/sandbox/include/asm/global_data.h|3 +
  arch/sandbox/lib/board.c  |8 ++
  arch/sh/include/asm/global_data.h |3 +
  arch/sh/lib/board.c   |8 ++
  arch/sparc/include/asm/global_data.h  |3 +
  arch/sparc/lib/board.c|8 ++
  arch/x86/include/asm/global_data.h|3 +
  arch/x86/lib/board.c  |   18 +
  common/Makefile   |1 +
  common/dmmalloc.c |   88 ++
  include/dmmalloc.h|  117 
 +
  31 files changed, 372 insertions(+)
  create mode 100644 common/dmmalloc.c
  create mode 100644 include/dmmalloc.h

 diff --git a/arch/arm/include/asm/global_data.h 
 b/arch/arm/include/asm/global_data.h
 index f8088fe..ef727b0 100644
 --- a/arch/arm/include/asm/global_data.h
 +++ b/arch/arm/include/asm/global_data.h
 @@ -82,6 +82,9 @@ typedef   struct  global_data {
 unsigned long   post_log_res; /* success of POST test */
 unsigned long   post_init_f_time; /* When post_init_f started */
  #endif
 +#ifdef CONFIG_SYS_EARLY_MALLOC
 +   void*early_heap_first;  /* heap for early_malloc */
 +#endif
  } gd_t;

  #include asm-generic/global_data_flags.h
 diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
 index f1951e8..f73d8b2 100644
 --- a/arch/arm/lib/board.c
 +++ b/arch/arm/lib/board.c
 @@ -53,6 +53,10 @@
  #include post.h
  #include logbuff.h

 +#ifdef CONFIG_DM
 +#include dmmalloc.h
 +#endif
 +
  #ifdef CONFIG_BITBANGMII
  #include miiphy.h
  #endif
 @@ -281,6 +285,10 @@ void board_init_f(ulong bootflag)

 memset((void *)gd, 0, sizeof(gd_t));

 +#ifdef CONFIG_SYS_EARLY_MALLOC
 +   gd-early_heap_first = early_brk(CONFIG_SYS_EARLY_HEAP_SIZE);
 +#endif /* CONFIG_SYS_EARLY_MALLOC */
 +

I just realised that all these initialisers can be dumped - early_brk()
will be called when early_malloc() is first called

[snip]

 diff --git a/arch/x86/lib/board.c b/arch/x86/lib/board.c
 index 90cf7fc..a670f9e 100644
 --- a/arch/x86/lib/board.c
 +++ b/arch/x86/lib/board.c
 @@ -40,6 +40,10 @@
  #include asm/init_helpers.h
  #include asm/init_wrappers.h

 +#ifdef CONFIG_DM
 +#include dmmalloc.h
 +#endif
 +
  /*
   * Breath some life into the board...
   *
 @@ -85,6 +89,17 @@
  typedef int (init_fnc_t) (void);

  /*
 + * Initialize early heap (when enabled by config).
 + */
 +#ifdef CONFIG_SYS_EARLY_MALLOC
 +static void early_malloc_init(void)
 +{
 +   gd-early_heap_first = early_brk(CONFIG_SYS_EARLY_HEAP_SIZE);
 +}
 +#endif /* CONFIG_SYS_EARLY_MALLOC */

So this uglyness goes

 +
 +
 +/*
   * init_sequence_f is the list of init functions which are run when U-Boot
   * is executing from Flash with a limited 'C' environment. The following
   * limitations must be considered when implementing an '_f' function:
 @@ -99,6 +114,9 @@ init_fnc_t *init_sequence_f[] = {
 cpu_init_f,
 board_early_init_f,
 env_init,
 +#ifdef CONFIG_SYS_EARLY_MALLOC
 +   early_malloc_init,
 +#endif /* 

Re: [U-Boot] [PATCH v8] [RFC] early_malloc for DM added.

2012-09-23 Thread Tomas Hlavacek
Hi Graeme!

On Mon, Sep 24, 2012 at 2:00 AM, Graeme Russ graeme.r...@gmail.com wrote:
 Hi Tomas,

 On Mon, Sep 24, 2012 at 2:15 AM, Tomas Hlavacek tmshl...@gmail.com wrote:
 early_malloc for DM with support for more heaps and lightweight
 first heap in the same memory as an early stack.

 Adaptation layer for seamless calling of early_malloc or dlmalloc from
 DM based on init stage added (dmmalloc() and related functions).

 Signed-off-by: Tomas Hlavacek tmshl...@gmail.com
 ---
 Changelog since v5:
 dmmalloc() and all dm* functions has been moved to header, made static
 inline and preprocessor-dependent blocks are reworked.
 early_malloc_active() corrected and made not static.
 s/CONFIG_SYS_DM/CONFIG_DM/ applied.

 Changelog sice v6:
 Check of first heap emptyness in early_brk() has been simplified.

 Changelog since v7:
 dmcalloc() implmentation added.
 Comments added to header.

  arch/arm/include/asm/global_data.h|3 +
  arch/arm/lib/board.c  |8 ++
  arch/avr32/include/asm/global_data.h  |3 +
  arch/avr32/lib/board.c|9 +++
  arch/blackfin/include/asm/global_data.h   |3 +
  arch/blackfin/lib/board.c |8 ++
  arch/m68k/include/asm/global_data.h   |3 +
  arch/m68k/lib/board.c |8 ++
  arch/microblaze/include/asm/global_data.h |3 +
  arch/microblaze/lib/board.c   |9 +++
  arch/mips/include/asm/global_data.h   |3 +
  arch/mips/lib/board.c |8 ++
  arch/nds32/include/asm/global_data.h  |3 +
  arch/nds32/lib/board.c|8 ++
  arch/nios2/include/asm/global_data.h  |3 +
  arch/nios2/lib/board.c|8 ++
  arch/openrisc/include/asm/global_data.h   |3 +
  arch/openrisc/lib/board.c |8 ++
  arch/powerpc/include/asm/global_data.h|3 +
  arch/powerpc/lib/board.c  |8 ++
  arch/sandbox/include/asm/global_data.h|3 +
  arch/sandbox/lib/board.c  |8 ++
  arch/sh/include/asm/global_data.h |3 +
  arch/sh/lib/board.c   |8 ++
  arch/sparc/include/asm/global_data.h  |3 +
  arch/sparc/lib/board.c|8 ++
  arch/x86/include/asm/global_data.h|3 +
  arch/x86/lib/board.c  |   18 +
  common/Makefile   |1 +
  common/dmmalloc.c |   88 ++
  include/dmmalloc.h|  117 
 +
  31 files changed, 372 insertions(+)
  create mode 100644 common/dmmalloc.c
  create mode 100644 include/dmmalloc.h

 diff --git a/arch/arm/include/asm/global_data.h 
 b/arch/arm/include/asm/global_data.h
 index f8088fe..ef727b0 100644
 --- a/arch/arm/include/asm/global_data.h
 +++ b/arch/arm/include/asm/global_data.h
 @@ -82,6 +82,9 @@ typedef   struct  global_data {
 unsigned long   post_log_res; /* success of POST test */
 unsigned long   post_init_f_time; /* When post_init_f started */
  #endif
 +#ifdef CONFIG_SYS_EARLY_MALLOC
 +   void*early_heap_first;  /* heap for early_malloc */
 +#endif
  } gd_t;

  #include asm-generic/global_data_flags.h
 diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
 index f1951e8..f73d8b2 100644
 --- a/arch/arm/lib/board.c
 +++ b/arch/arm/lib/board.c
 @@ -53,6 +53,10 @@
  #include post.h
  #include logbuff.h

 +#ifdef CONFIG_DM
 +#include dmmalloc.h
 +#endif
 +
  #ifdef CONFIG_BITBANGMII
  #include miiphy.h
  #endif
 @@ -281,6 +285,10 @@ void board_init_f(ulong bootflag)

 memset((void *)gd, 0, sizeof(gd_t));

 +#ifdef CONFIG_SYS_EARLY_MALLOC
 +   gd-early_heap_first = early_brk(CONFIG_SYS_EARLY_HEAP_SIZE);
 +#endif /* CONFIG_SYS_EARLY_MALLOC */
 +

 I just realised that all these initialisers can be dumped - early_brk()
 will be called when early_malloc() is first called


Yes, but how can I determine the size of the new heap which the
early_brk gives out? When I have CONFIG_SYS_EARLY_HEAP_SIZE macro in
board configuration I can ignore the size passed to the default
early_brk and return the full-sized heap as configuration says (when
the requested size is lower than configured heap size and NULL
otherwise). But what if somebody implements at some point a dynamic
early_brk capable of returning multiple heaps? Should I safely assume
that the future dynamic early_brk would give out multiples of page
size or so?

All other comments understood and agreed.

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


Re: [U-Boot] [PATCH v8] [RFC] early_malloc for DM added.

2012-09-23 Thread Graeme Russ
Hi Thomas,

On Mon, Sep 24, 2012 at 10:35 AM, Tomas Hlavacek tmshl...@gmail.com wrote:
 Hi Graeme!

 On Mon, Sep 24, 2012 at 2:00 AM, Graeme Russ graeme.r...@gmail.com wrote:
 Hi Tomas,

 On Mon, Sep 24, 2012 at 2:15 AM, Tomas Hlavacek tmshl...@gmail.com wrote:
 early_malloc for DM with support for more heaps and lightweight
 first heap in the same memory as an early stack.

 Adaptation layer for seamless calling of early_malloc or dlmalloc from
 DM based on init stage added (dmmalloc() and related functions).

 Signed-off-by: Tomas Hlavacek tmshl...@gmail.com
 ---
 Changelog since v5:
 dmmalloc() and all dm* functions has been moved to header, made static
 inline and preprocessor-dependent blocks are reworked.
 early_malloc_active() corrected and made not static.
 s/CONFIG_SYS_DM/CONFIG_DM/ applied.

 Changelog sice v6:
 Check of first heap emptyness in early_brk() has been simplified.

 Changelog since v7:
 dmcalloc() implmentation added.
 Comments added to header.

  arch/arm/include/asm/global_data.h|3 +
  arch/arm/lib/board.c  |8 ++
  arch/avr32/include/asm/global_data.h  |3 +
  arch/avr32/lib/board.c|9 +++
  arch/blackfin/include/asm/global_data.h   |3 +
  arch/blackfin/lib/board.c |8 ++
  arch/m68k/include/asm/global_data.h   |3 +
  arch/m68k/lib/board.c |8 ++
  arch/microblaze/include/asm/global_data.h |3 +
  arch/microblaze/lib/board.c   |9 +++
  arch/mips/include/asm/global_data.h   |3 +
  arch/mips/lib/board.c |8 ++
  arch/nds32/include/asm/global_data.h  |3 +
  arch/nds32/lib/board.c|8 ++
  arch/nios2/include/asm/global_data.h  |3 +
  arch/nios2/lib/board.c|8 ++
  arch/openrisc/include/asm/global_data.h   |3 +
  arch/openrisc/lib/board.c |8 ++
  arch/powerpc/include/asm/global_data.h|3 +
  arch/powerpc/lib/board.c  |8 ++
  arch/sandbox/include/asm/global_data.h|3 +
  arch/sandbox/lib/board.c  |8 ++
  arch/sh/include/asm/global_data.h |3 +
  arch/sh/lib/board.c   |8 ++
  arch/sparc/include/asm/global_data.h  |3 +
  arch/sparc/lib/board.c|8 ++
  arch/x86/include/asm/global_data.h|3 +
  arch/x86/lib/board.c  |   18 +
  common/Makefile   |1 +
  common/dmmalloc.c |   88 ++
  include/dmmalloc.h|  117 
 +
  31 files changed, 372 insertions(+)
  create mode 100644 common/dmmalloc.c
  create mode 100644 include/dmmalloc.h

 diff --git a/arch/arm/include/asm/global_data.h 
 b/arch/arm/include/asm/global_data.h
 index f8088fe..ef727b0 100644
 --- a/arch/arm/include/asm/global_data.h
 +++ b/arch/arm/include/asm/global_data.h
 @@ -82,6 +82,9 @@ typedef   struct  global_data {
 unsigned long   post_log_res; /* success of POST test */
 unsigned long   post_init_f_time; /* When post_init_f started */
  #endif
 +#ifdef CONFIG_SYS_EARLY_MALLOC
 +   void*early_heap_first;  /* heap for early_malloc */
 +#endif
  } gd_t;

  #include asm-generic/global_data_flags.h
 diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
 index f1951e8..f73d8b2 100644
 --- a/arch/arm/lib/board.c
 +++ b/arch/arm/lib/board.c
 @@ -53,6 +53,10 @@
  #include post.h
  #include logbuff.h

 +#ifdef CONFIG_DM
 +#include dmmalloc.h
 +#endif
 +
  #ifdef CONFIG_BITBANGMII
  #include miiphy.h
  #endif
 @@ -281,6 +285,10 @@ void board_init_f(ulong bootflag)

 memset((void *)gd, 0, sizeof(gd_t));

 +#ifdef CONFIG_SYS_EARLY_MALLOC
 +   gd-early_heap_first = early_brk(CONFIG_SYS_EARLY_HEAP_SIZE);
 +#endif /* CONFIG_SYS_EARLY_MALLOC */
 +

 I just realised that all these initialisers can be dumped - early_brk()
 will be called when early_malloc() is first called


 Yes, but how can I determine the size of the new heap which the
 early_brk gives out? When I have CONFIG_SYS_EARLY_HEAP_SIZE macro in
 board configuration I can ignore the size passed to the default
 early_brk and return the full-sized heap as configuration says (when
 the requested size is lower than configured heap size and NULL

default early_brk() should always use CONFIG_SYS_EARLY_HEAP_SIZE

 otherwise). But what if somebody implements at some point a dynamic
 early_brk capable of returning multiple heaps? Should I safely assume
 that the future dynamic early_brk would give out multiples of page
 size or so?

Very good point. I would assume early_brk() will always return the
largest possible chunk of memory it can. These sizes might be
specified as multiple #defines in the board config or may be
dynamically determined via hardware probing. Either way, that is a
problem for the implementer to deal with 

[U-Boot] [RFC] [PATCH 0/3] Linker-generated arrays

2012-09-23 Thread Marek Vasut
This is a first stab at the linker-generated array. Basically, this
concept is a generic abstraction of how u_boot_cmd works today. The
patch 2/3 contains a huge pile of documentation which should clarify
most of the questions.

NOTE: Compile-testing in progress, but it works with m28evk and sandbox
  for now.

Marek Vasut (3):
  common: Add symbol handling for generic lists into Makefile
  common: Implement support for linker-generated arrays
  common: Add .u_boot_list into all linker files

 Makefile |   21 +++-
 arch/arm/cpu/arm920t/ep93xx/u-boot.lds   |5 +
 arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds|4 +
 arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds  |4 +
 arch/arm/cpu/armv7/omap-common/u-boot-spl.lds|5 +
 arch/arm/cpu/ixp/u-boot.lds  |5 +
 arch/arm/cpu/u-boot.lds  |5 +
 arch/avr32/cpu/u-boot.lds|5 +
 arch/blackfin/cpu/u-boot.lds |4 +
 arch/microblaze/cpu/u-boot.lds   |5 +
 arch/nds32/cpu/n1213/u-boot.lds  |5 +
 arch/nios2/cpu/u-boot.lds|5 +
 arch/powerpc/cpu/74xx_7xx/u-boot.lds |5 +
 arch/powerpc/cpu/mpc512x/u-boot.lds  |5 +
 arch/powerpc/cpu/mpc5xx/u-boot.lds   |5 +
 arch/powerpc/cpu/mpc5xxx/u-boot-customlayout.lds |3 +
 arch/powerpc/cpu/mpc5xxx/u-boot.lds  |5 +
 arch/powerpc/cpu/mpc8220/u-boot.lds  |5 +
 arch/powerpc/cpu/mpc824x/u-boot.lds  |5 +
 arch/powerpc/cpu/mpc8260/u-boot.lds  |5 +
 arch/powerpc/cpu/mpc83xx/u-boot.lds  |5 +
 arch/powerpc/cpu/mpc85xx/u-boot-nand.lds |4 +
 arch/powerpc/cpu/mpc85xx/u-boot-nand_spl.lds |4 +
 arch/powerpc/cpu/mpc85xx/u-boot.lds  |5 +
 arch/powerpc/cpu/mpc86xx/u-boot.lds  |5 +
 arch/powerpc/cpu/ppc4xx/u-boot.lds   |5 +
 arch/sandbox/cpu/u-boot.lds  |5 +
 arch/sh/cpu/sh2/u-boot.lds   |4 +
 arch/sh/cpu/sh3/u-boot.lds   |4 +
 arch/sh/cpu/sh4/u-boot.lds   |4 +
 arch/x86/cpu/u-boot.lds  |5 +
 board/BuS/eb_cpu5282/u-boot.lds  |5 +
 board/LEOX/elpt860/u-boot.lds|5 +
 board/RPXClassic/u-boot.lds  |5 +
 board/RPXlite/u-boot.lds |5 +
 board/RPXlite_dw/u-boot.lds  |5 +
 board/RRvision/u-boot.lds|5 +
 board/actux1/u-boot.lds  |5 +
 board/actux2/u-boot.lds  |5 +
 board/actux3/u-boot.lds  |5 +
 board/adder/u-boot.lds   |5 +
 board/ait/cam_enc_4xx/u-boot-spl.lds |4 +
 board/altera/nios2-generic/u-boot.lds|5 +
 board/amcc/acadia/u-boot-nand.lds|3 +
 board/amcc/bamboo/u-boot-nand.lds|3 +
 board/amcc/canyonlands/u-boot-nand.lds   |3 +
 board/amcc/kilauea/u-boot-nand.lds   |3 +
 board/amcc/sequoia/u-boot-nand.lds   |3 +
 board/amcc/sequoia/u-boot-ram.lds|3 +
 board/amirix/ap1000/u-boot.lds   |5 +
 board/astro/mcf5373l/u-boot.lds  |5 +
 board/c2mon/u-boot.lds   |5 +
 board/cobra5272/u-boot.lds   |5 +
 board/cogent/u-boot.lds  |5 +
 board/dave/PPChameleonEVB/u-boot.lds |5 +
 board/davinci/da8xxevm/u-boot-spl-da850evm.lds   |6 ++
 board/davinci/da8xxevm/u-boot-spl-hawk.lds   |5 +
 board/dbau1x00/u-boot.lds|5 +
 board/dvlhost/u-boot.lds |5 +
 board/eltec/mhpc/u-boot.lds  |5 +
 board/emk/top860/u-boot.lds  |5 +
 board/ep88x/u-boot.lds   |5 +
 board/esd/dasa_sim/u-boot.lds|5 +
 board/esd/pmc440/u-boot-nand.lds |3 +
 board/esd/tasreg/u-boot.lds  |5 +
 board/esteem192e/u-boot.lds  |5 +
 board/etx094/u-boot.lds  |5 +
 board/evb64260/u-boot.lds|5 +
 board/fads/u-boot.lds|5 +
 board/flagadm/u-boot.lds |5 +
 board/freescale/m5208evbe/u-boot.lds |5 +
 board/freescale/m52277evb/u-boot.lds |5 +
 board/freescale/m5235evb/u-boot.lds  |5 +
 board/freescale/m5249evb/u-boot.lds  |5 +
 board/freescale/m5253demo/u-boot.lds |5 +
 board/freescale/m5253evbe/u-boot.lds |5 +
 

[U-Boot] [PATCH 1/3] common: Add symbol handling for generic lists into Makefile

2012-09-23 Thread Marek Vasut
This patch adds essential components for generation of the contents of
the linker section that is used by the linker-generated array. All of
the contents is held in a separate file, u-boot.lst, which is generated
at runtime just before U-Boot is linked.

The purpose of this code is to especially generate the appropriate
boundary symbols around each subsection in the section carrying the
linker-generated arrays. Obviously, the interim linker code for actual
placement of the variables into the section is generated too. The
generated file, u-boot.lst, is included into u-boot.lds via the linker
INCLUDE directive in u-boot.lds .

Adjustments are made in the Makefile and spl/Makefile so that the
u-boot.lds and u-boot-spl.lds depend on their respective .lst files.

Signed-off-by: Marek Vasut ma...@denx.de
Cc: Joe Hershberger joe.hershber...@gmail.com
Cc: Mike Frysinger vap...@gentoo.org
---
 Makefile |   21 ++---
 spl/Makefile |   14 +-
 2 files changed, 31 insertions(+), 4 deletions(-)

diff --git a/Makefile b/Makefile
index e3a27c6..592987a 100644
--- a/Makefile
+++ b/Makefile
@@ -510,7 +510,10 @@ else
 GEN_UBOOT = \
UNDEF_SYM=`$(OBJDUMP) -x $(LIBBOARD) $(LIBS) | \
sed  -n -e 
's/.*\($(SYM_PREFIX)__u_boot_cmd_.*\)/-u\1/p'|sort|uniq`;\
-   cd $(LNDIR)  $(LD) $(LDFLAGS) $(LDFLAGS_$(@F)) $$UNDEF_SYM 
$(__OBJS) \
+   UNDEF_LST=`$(OBJDUMP) -x $(LIBBOARD) $(LIBS) | \
+   sed  -n -e 
's/.*\($(SYM_PREFIX)__u_boot_list_.*\)/-u\1/p'|sort|uniq`;\
+   cd $(LNDIR)  $(LD) $(LDFLAGS) $(LDFLAGS_$(@F)) \
+   $$UNDEF_SYM $$UNDEF_LST $(__OBJS) \
--start-group $(__LIBS) --end-group $(PLATFORM_LIBS) \
-Map u-boot.map -o u-boot
 endif
@@ -543,8 +546,20 @@ $(SUBDIR_EXAMPLES): $(obj)u-boot
 $(LDSCRIPT):   depend
$(MAKE) -C $(dir $@) $(notdir $@)
 
-$(obj)u-boot.lds: $(LDSCRIPT)
-   $(CPP) $(CPPFLAGS) $(LDPPFLAGS) -ansi -D__ASSEMBLY__ -P - $^ 
$@
+$(obj)u-boot.lst: $(LIBBOARD) $(LIBS)
+   $(OBJDUMP) -h $(LIBBOARD) $(LIBS) | \
+   sed -n -e 's/.*\(\.u_boot_list[^ ]\+\).*$$/\1/p' | \
+   sed 's/\.[^\.]\+$$//' | \
+   sed -n ':s /^.\+$$/ { p;s/^\(.*\)\.[^\.]*$$/\1/;b s }' | \
+   sed -n 's/\./.#/g;h;s/$$/\a/p;g;s/$$/@/p;g;s/$$/~/p;' | \
+   LC_COLLATE=C sort -u | \
+   sed 's/#//g' | \
+   sed -n -e '/\a$$/ { s/\./_/g;s/\a$$/__start = .;/p; }'\
+   -e '/~$$/ { s/\./_/g;s/~$$/__end = .;/p; }'\
+   -e '/@$$/ { s/\(.*\)@$$/*(SORT(\1.*));/p }' $@
+
+$(obj)u-boot.lds: $(LDSCRIPT) $(obj)u-boot.lst
+   $(CPP) $(CPPFLAGS) $(LDPPFLAGS) -ansi -D__ASSEMBLY__ -P - $ 
$@
 
 nand_spl:  $(TIMESTAMP_FILE) $(VERSION_FILE) depend
$(MAKE) -C nand_spl/board/$(BOARDDIR) all
diff --git a/spl/Makefile b/spl/Makefile
index d4cb668..545adfe 100644
--- a/spl/Makefile
+++ b/spl/Makefile
@@ -148,7 +148,19 @@ $(START):  depend
 $(LIBS):   depend
$(MAKE) -C $(SRCTREE)$(dir $(subst $(SPLTREE),,$@))
 
-$(obj)u-boot-spl.lds: $(LDSCRIPT) depend
+$(obj)u-boot-spl.lst: $(LIBS)
+   $(OBJDUMP) -h $(LIBS) | \
+   sed -n -e 's/.*\(\.u_boot_list[^ ]\+\).*$$/\1/p' | \
+   sed 's/\.[^\.]\+$$//' | \
+   sed -n ':s /^.\+$$/ { p;s/^\(.*\)\.[^\.]*$$/\1/;b s }' | \
+   sed -n 's/\./.#/g;h;s/$$/\a/p;g;s/$$/@/p;g;s/$$/~/p;' | \
+   LC_COLLATE=C sort -u | \
+   sed 's/#//g' | \
+   sed -n -e '/\a$$/ { s/\./_/g;s/\a$$/__start = .;/p; }'\
+   -e '/~$$/ { s/\./_/g;s/~$$/__end = .;/p; }'\
+   -e '/@$$/ { s/\(.*\)@$$/*(SORT(\1.*));/p }' $@
+
+$(obj)u-boot-spl.lds: $(LDSCRIPT) $(obj)u-boot-spl.lst depend
$(CPP) $(CPPFLAGS) $(LDPPFLAGS) -ansi -D__ASSEMBLY__ -P -  $  $@
 
 depend:$(obj).depend
-- 
1.7.10.4

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


  1   2   >