date:20140307

Hello Tom, Albert,

   
It is not clear to me when we should change the board status
from Active to Orphan. 
(Could you show me the basic guideline, Tom ? or Albert ?)
There are many boards without maintainers, which are still Active.
   
   This is a known, and so far, open, question. Right now, orphan boards
   are those which were marked so in the former MAINTAINERS file. My
   personal opinion is that Active should mean the board is
   activelymaintained and any maintainer e-mail address associated
   with the board is that of an active maintainer, and Orphan means the
   board is not actively maintained any more but still builds, and any
   address associated with it is that of the last known maintainer(s).
  
  +1 to this definition and yes, oops, I meant Orphan not Inactive.
 
 We should clarify this definition of Active/Orphan in the boards.cfg
 header text.
 
 Also, maybe we could simply mark dead addresses by suffixing the domain
 part with .invalid? For instance, the dead form of my own e-mail
 address would be albert.u.b...@aribaud.net.invalid? That would make
 sure that no mail is ever submitted to a correct domain with a bogus
 recipient.


Definition:
   Active should mean the board is activelymaintained and any
   maintainer e-mail address associated with the board is that of an
   active maintainer, and Orphan means the board is not actively
   maintained any more but still builds, and any address associated
  with it is that of the last known maintainer(s).

If we adopt this definition, adding dead address or .invalid
is redundant, isn't it?

Changing the status to Orphan is enough
because Orphan declares its email address is invalid.

Best Regards
Masahiro Yamada

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

[U-Boot] [PATCH v2 2/2] cosmetic: README: add some entries to Directory Hierarchy

Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---

Changes in v2:
  - Split into 2 patches
  - Add ARC architecture

 README | 5 +
 1 file changed, 5 insertions(+)

diff --git a/README b/README
index 2efba4a..0e04964 100644
--- a/README
+++ b/README
@@ -132,6 +132,10 @@ Directory Hierarchy:
 
 
 /arch  Architecture specific files
+  /arc Files generic to ARC architecture
+/cpu   CPU specific files
+  /arc700  Files specific to ARC 700 CPUs
+/lib   Architecture specific library files
   /arm Files generic to ARM architecture
 /cpu   CPU specific files
   /arm720t Files specific to ARM 720 CPUs
@@ -164,6 +168,7 @@ Directory Hierarchy:
   /mipsFiles generic to MIPS architecture
 /cpu   CPU specific files
   /mips32  Files specific to MIPS32 CPUs
+  /mips64  Files specific to MIPS64 CPUs
 /lib   Architecture specific library files
   /nds32   Files generic to NDS32 architecture
 /cpu   CPU specific files
-- 
1.8.3.2

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

[U-Boot] [PATCH v2 1/2] mips: xburst: remove remainders of dead board

Commit 54e458de deleted qi_lb60 board support
because of the incompatible license issue.

There is no board with XBurst CPU.

Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
Cc: Daniel Schwierzeck daniel.schwierz...@gmail.com
---

Changes in v2:
  - Split into two patches

 README   |   1 -
 arch/mips/cpu/xburst/Makefile|   9 --
 arch/mips/cpu/xburst/config.mk   |  16 ---
 arch/mips/cpu/xburst/cpu.c   | 136 --
 arch/mips/cpu/xburst/jz4740.c| 235 ---
 arch/mips/cpu/xburst/jz_serial.c | 118 
 arch/mips/cpu/xburst/start.S | 179 -
 arch/mips/cpu/xburst/timer.c | 149 -
 8 files changed, 843 deletions(-)
 delete mode 100644 arch/mips/cpu/xburst/Makefile
 delete mode 100644 arch/mips/cpu/xburst/config.mk
 delete mode 100644 arch/mips/cpu/xburst/cpu.c
 delete mode 100644 arch/mips/cpu/xburst/jz4740.c
 delete mode 100644 arch/mips/cpu/xburst/jz_serial.c
 delete mode 100644 arch/mips/cpu/xburst/start.S
 delete mode 100644 arch/mips/cpu/xburst/timer.c

diff --git a/README b/README
index 216f0c7..2efba4a 100644
--- a/README
+++ b/README
@@ -164,7 +164,6 @@ Directory Hierarchy:
   /mipsFiles generic to MIPS architecture
 /cpu   CPU specific files
   /mips32  Files specific to MIPS32 CPUs
-  /xburst  Files specific to Ingenic XBurst CPUs
 /lib   Architecture specific library files
   /nds32   Files generic to NDS32 architecture
 /cpu   CPU specific files
diff --git a/arch/mips/cpu/xburst/Makefile b/arch/mips/cpu/xburst/Makefile
deleted file mode 100644
index 57714d0..000
--- a/arch/mips/cpu/xburst/Makefile
+++ /dev/null
@@ -1,9 +0,0 @@
-#
-# Copyright (C) 2011 Xiangfu Liu xian...@openmobilefree.net
-#
-# SPDX-License-Identifier: GPL-2.0+
-#
-
-extra-y= start.o
-obj-y  = cpu.o timer.o jz_serial.o
-obj-$(CONFIG_JZ4740) += jz4740.o
diff --git a/arch/mips/cpu/xburst/config.mk b/arch/mips/cpu/xburst/config.mk
deleted file mode 100644
index b8e53e5..000
--- a/arch/mips/cpu/xburst/config.mk
+++ /dev/null
@@ -1,16 +0,0 @@
-#
-# Copyright (C) 2011 Xiangfu Liu xian...@openmobilefree.net
-#
-# SPDX-License-Identifier: GPL-2.0+
-#
-
-PLATFORM_CPPFLAGS += -march=mips32
-PLATFORM_CPPFLAGS += -mabi=32 -DCONFIG_32BIT
-ifdef CONFIG_SYS_BIG_ENDIAN
-PLATFORM_LDFLAGS  += -m elf32btsmip
-else
-PLATFORM_LDFLAGS  += -m elf32ltsmip
-endif
-
-CONFIG_STANDALONE_LOAD_ADDR ?= 0x8020 \
-  -T $(srctree)/examples/standalone/mips.lds
diff --git a/arch/mips/cpu/xburst/cpu.c b/arch/mips/cpu/xburst/cpu.c
deleted file mode 100644
index 1fdaa32..000
--- a/arch/mips/cpu/xburst/cpu.c
+++ /dev/null
@@ -1,136 +0,0 @@
-/*
- * (C) Copyright 2003
- * Wolfgang Denk, DENX Software Engineering, w...@denx.de
- * (C) Copyright 2011
- * Xiangfu Liu xian...@openmobilefree.net
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#include common.h
-#include command.h
-#include netdev.h
-#include asm/mipsregs.h
-#include asm/cacheops.h
-#include asm/reboot.h
-#include asm/io.h
-#include asm/jz4740.h
-
-#define cache_op(op, addr) \
-   __asm__ __volatile__(   \
-   .set   push\n \
-   .set   noreorder\n\
-   .set   mips3\n\
-   cache  %0, %1\n   \
-   .set   pop\n  \
-   :   \
-   : i (op), R (*(unsigned char *)(addr)))
-
-void __attribute__((weak)) _machine_restart(void)
-{
-   struct jz4740_wdt *wdt = (struct jz4740_wdt *)JZ4740_WDT_BASE;
-   struct jz4740_tcu *tcu = (struct jz4740_tcu *)JZ4740_TCU_BASE;
-   u16 tmp;
-
-   /* wdt_select_extalclk() */
-   tmp = readw(wdt-tcsr);
-   tmp = ~(WDT_TCSR_EXT_EN | WDT_TCSR_RTC_EN | WDT_TCSR_PCK_EN);
-   tmp |= WDT_TCSR_EXT_EN;
-   writew(tmp, wdt-tcsr);
-
-   /* wdt_select_clk_div64() */
-   tmp = readw(wdt-tcsr);
-   tmp = ~WDT_TCSR_PRESCALE_MASK;
-   tmp |= WDT_TCSR_PRESCALE64,
-   writew(tmp, wdt-tcsr);
-
-   writew(100, wdt-tdr); /* wdt_set_data(100) */
-   writew(0, wdt-tcnt); /* wdt_set_count(0); */
-   writel(TCU_TSSR_WDTSC, tcu-tscr); /* tcu_start_wdt_clock */
-   writeb(readb(wdt-tcer) | WDT_TCER_TCEN, wdt-tcer); /* wdt start */
-
-   while (1)
-   ;
-}
-
-int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
-{
-   _machine_restart();
-
-   fprintf(stderr, *** reset failed ***\n);
-   return 0;
-}
-
-void flush_cache(ulong start_addr, ulong size)
-{
-   unsigned long lsize = CONFIG_SYS_CACHELINE_SIZE;
-   unsigned long addr = start_addr  ~(lsize - 1);
-   unsigned long aend = (start_addr + size - 1)  ~(lsize - 1);
-
-   for (; addr = aend; addr += lsize) {
-

[U-Boot] How to silence the output of U-Boot

2014-03-07 Thread Frank Ihle

Hi everyone,

I searched the Internet but the help I found didn't work. I hope someone here 
may know how to fix it, here's the situation:

I have this ARM9 SAM9G25 which is accessed by its ttyS0. I
 want to disable all of the output, that was made during the U-Boot (v. 
2010.06) 
boot, to decrease the CPU's load. Therefore there is the 


  setenv silent 1



parameter, which i put into the BOOTCMD string like:



  #define CONFIG_BOOTCOMMANDsetenv silent 1; \

bootm 



and there is (as mentioned in the Readme.silent 
http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=doc/README.silent;hb=v2013.10
 ) the
#define CONFIG_SILENT_CONSOLE
#define CONFIG_SYS_DEVICE_NULLDEV
#define CONFIG_SILENT_CONSOLE_UPDATE_ON_SET


command, neither one is working (the lines printed out are still the same and 
the boot time didn't change). Whereas the 
 setenv verify n
is working, just to give an example.

Does somebody see the error ?

BTW
 (I'm not sure if this is related to this) in the referenced link there 
is the information, that u-boot sets the kernel command line to 
console= so that in the end there will be no output for the kernel 
too, but that didn't happen and it doesn't even happen if i force to 
boot Linux with console= in the default Linux command line string
Thanks for your help.
Kind Regards,
Frank
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] video: Add support for TI's AM335x LCD-Controller

Hi Heiko,

Heiko Schocher wrote:
 Hello Hannes,

 Am 06.03.2014 15:24, schrieb Hannes Petermaier:
 On 2014-03-06 14:58, Heiko Schocher wrote:
 Hello Hannes,

 Am 06.03.2014 14:39, schrieb Hannes Petermaier:
 - Adds support for a minimal framebuffer driver of TI's AM335x SoC
 to be compatible with Wolfgang Denk's LCD-Framework (CONFIG_LCD,
 common/lcd.c)

 Signed-off-by: Hannes Petermaieroe5...@oevsv.at
 ---
 drivers/video/Makefile | 1 +
 drivers/video/am335x-fb.c | 169
 +
 drivers/video/am335x-fb.h | 67 ++
 3 files changed, 237 insertions(+)
 create mode 100644 drivers/video/am335x-fb.c
 create mode 100644 drivers/video/am335x-fb.h

 Why you cannot use:

 u-boot:drivers/video/da8xx-fb.c ?

 bye,
 Heiko
 Hi Heiko,

 for my opinion this clone of the linux-driver is very overloaded and
 difficult to use/configure.
 With the words 'small-is-beautiful' and 'keep-it-simple' i've wrote a
 few lines which do the minimum:
 - configure raster-controller
 - setup DMA
 - powerON Display

 maybe we can use the small-version in other projects too.

 Why is it difficult to use/configure the existing driver?

 Look for example into the board/siemens/pxm2/board.c board, which uses
 this driver. You have to define:

 static struct da8xx_panel lcd_panels[]
 static const struct display_panel disp_panel
 static const struct lcd_ctrl_config lcd_cfg

 and call da8xx_video_init(lcd_panels[0], lcd_cfg, lcd_cfg.bpp);

 Thats all ...

i've looked around again for using the da8xx-fb driver and found another
detail which motivated me for writing a new instance.

--
par-vram_virt = malloc(par-vram_size);

par-vram_phys = (dma_addr_t) par-vram_virt;
debug(Requesting 0x%x bytes for framebuffer at 0x%x\n,
(unsigned int)par-vram_size,
(unsigned int)par-vram_virt);
if (!par-vram_virt) {
printf(GLCD: malloc for frame buffer failed\n);
goto err_release_fb;
}
gd-fb_base = (int)par-vram_virt;
--

da8xx-fb.c does allocate a new framebuffer by itself.
But in my case lcd-framework allready has reserved memory (on top of ram)
for framebuffer usage and i want use this memory from lcd-framework for
two reasons:
- don't waste memory
- have this memory really on top of ram to give the following OS (in my
case vxWorks) a pointer where it have to write Video-data.

maybe there are other possibilites to achieve this.
any ideas ?

 bye,
 Heiko

many thanks and best regards,
Hannes


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

[U-Boot] NAND SPL on imx6

2014-03-07 Thread Andy Ng

Dear colleagues,

Has anyone tried to build NAND SPL support on imx6. Does it work?

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

[U-Boot] [PATCH] denali: review feedback

For Chin Liang See

Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---
 drivers/mtd/nand/denali_nand.c | 42 +++---
 drivers/mtd/nand/denali_nand.h |  3 +++
 2 files changed, 22 insertions(+), 23 deletions(-)

diff --git a/drivers/mtd/nand/denali_nand.c b/drivers/mtd/nand/denali_nand.c
index ffa69ad..a713cca 100644
--- a/drivers/mtd/nand/denali_nand.c
+++ b/drivers/mtd/nand/denali_nand.c
@@ -55,8 +55,6 @@ static int onfi_timing_mode = NAND_DEFAULT_TIMINGS;
 #define DENALI_READ0
 #define DENALI_WRITE   0x100
 
-#define DENALI_DATA_OFFSET_ADDRESS 0x10
-
 /* types of device accesses. We can issue commands and get status */
 #define COMMAND_CYCLE  0
 #define ADDR_CYCLE 1
@@ -129,15 +127,15 @@ static uint32_t wait_for_irq(uint32_t irq_mask)
 */
 static void index_addr(uint32_t address, uint32_t data)
 {
-   writel(address, denali.flash_mem);
-   writel(data, denali.flash_mem + DENALI_DATA_OFFSET_ADDRESS);
+   writel(address, denali.flash_mem + INDEX_CTRL_REG);
+   writel(data, denali.flash_mem + INDEX_DATA_REG);
 }
 
 /* Perform an indexed read of the device */
 static void index_addr_read_data(uint32_t address, uint32_t *pdata)
 {
-   writel(address, denali.flash_mem);
-   *pdata = readl(denali.flash_mem + DENALI_DATA_OFFSET_ADDRESS);
+   writel(address, denali.flash_mem + INDEX_CTRL_REG);
+   *pdata = readl(denali.flash_mem + INDEX_DATA_REG);
 }
 
 /* We need to buffer some data for some of the NAND core routines.
@@ -576,7 +574,7 @@ static int denali_send_pipeline_cmd(bool ecc_en, bool 
transfer_spare,
 
if (access_type != SPARE_ACCESS) {
cmd = MODE_01 | addr;
-   writel(cmd, denali.flash_mem);
+   writel(cmd, denali.flash_mem + INDEX_CTRL_REG);
}
return 0;
 }
@@ -593,7 +591,7 @@ static int write_data_to_flash_mem(const void *buf, int len)
/* write the data to the flash memory */
buf32 = (uint32_t *)buf;
for (i = 0; i  len / 4; i++)
-   writel(*buf32++, denali.flash_mem + DENALI_DATA_OFFSET_ADDRESS);
+   writel(*buf32++, denali.flash_mem + INDEX_DATA_REG);
return i * 4; /* intent is to return the number of bytes read */
 }
 
@@ -626,7 +624,7 @@ static int write_oob_data(struct mtd_info *mtd, uint8_t 
*buf, int page)
 
/* We need to write to buffer first through MAP00 command */
cmd = MODE_00 | BANK(denali.flash_bank);
-   writel(cmd, denali.flash_mem);
+   writel(cmd, denali.flash_mem + INDEX_CTRL_REG);
 
/* send the data into flash buffer */
write_data_to_flash_mem(buf, mtd-oobsize);
@@ -664,7 +662,7 @@ static void denali_enable_dma(bool en)
 }
 
 /* setups the HW to perform the data DMA */
-static void denali_setup_dma_sequence(int op)
+static void denali_setup_dma(int op)
 {
const int page_count = 1;
uint32_t mode;
@@ -672,26 +670,24 @@ static void denali_setup_dma_sequence(int op)
 
flush_dcache_range(addr, addr + sizeof(denali.buf.dma_buf));
 
-   mode = MODE_10 | BANK(denali.flash_bank);
-
-   /* DMA is a four step process */
+   mode = MODE_10 | BANK(denali.flash_bank) | denali.page;
 
-   /* 1. setup transfer type and # of pages */
-   index_addr(mode | denali.page, 0x2000 | op | page_count);
+   /* DMA is a three step process */
 
-   /* 2. set memory high address bits 23:8 */
-   index_addr(mode | ((uint32_t)(addr  16)  8), 0x2200);
+   /* 1. setup transfer type and # of pages
+ interrupt when complete, burst len = 64 bytes */
+   index_addr(mode, 0x01002000 | (64  16) | op | page_count);
 
-   /* 3. set memory low address bits 23:8 */
-   index_addr(mode | ((uint32_t)addr  8), 0x2300);
+   /* 2. set memory low address bits 31:0 */
+   index_addr(mode, addr);
 
-   /* 4.  interrupt when complete, burst len = 64 bytes*/
-   index_addr(mode | 0x14000, 0x2400);
+   /* 3. set memory high address bits 64:32 */
+   index_addr(mode, 0);
 }
 
 /* Common DMA function */
 static uint32_t denali_dma_configuration(uint32_t ops, bool raw_xfer,
-   uint32_t irq_mask, int oob_required)
+uint32_t irq_mask, int oob_required)
 {
uint32_t irq_status = 0;
/* setup_ecc_for_xfer(bool ecc_en, bool transfer_spare) */
@@ -704,7 +700,7 @@ static uint32_t denali_dma_configuration(uint32_t ops, bool 
raw_xfer,
denali_enable_dma(true);
 
/* setup the DMA */
-   denali_setup_dma_sequence(ops);
+   denali_setup_dma(ops);
 
/* wait for operation to complete */
irq_status = wait_for_irq(irq_mask);
diff --git a/drivers/mtd/nand/denali_nand.h b/drivers/mtd/nand/denali_nand.h
index 4fd9ffc..c668d8c 100644
--- a/drivers/mtd/nand/denali_nand.h
+++ b/drivers/mtd/nand/denali_nand.h
@@ -413,6 +413,9 @@ typedef int irqreturn_t;
 #ifndef _LLD_NAND_
 #define _LLD_NAND_
 
+#define

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

Hello Chin,


 +/* setups the HW to perform the data DMA */
 +static void denali_setup_dma_sequence(int op)
 +{
 + const int page_count = 1;
 + uint32_t mode;
 + uint32_t addr = (uint32_t)denali.buf.dma_buf;
 +
 + flush_dcache_range(addr, addr + sizeof(denali.buf.dma_buf));
 +
 + mode = MODE_10 | BANK(denali.flash_bank);
 +
 + /* DMA is a four step process */
 +
 + /* 1. setup transfer type and # of pages */
 + index_addr(mode | denali.page, 0x2000 | op | page_count);
 +
 + /* 2. set memory high address bits 23:8 */
 + index_addr(mode | ((uint32_t)(addr  16)  8), 0x2200);
 +
 + /* 3. set memory low address bits 23:8 */
 + index_addr(mode | ((uint32_t)addr  8), 0x2300);
 +
 + /* 4.  interrupt when complete, burst len = 64 bytes*/
 + index_addr(mode | 0x14000, 0x2400);
 +}


This function would not work on my board.
Besides, it is completely different from the description
written in  Chapter 7. Data DMA of 
Denali NAND Flash Memory Controller User's Guide.

It looks really weird to me.
So I asked some questions to Cadence (Denali, before MA).

Accoding to the anwers from Cadence,
in conclusion, I think this function seems wrong.

Please let me confirm once again:
Did this function really work on your board?

I had to re-write this function to run on my board.


 #define DENALI_DATA_OFFSET_ADDRESS0x10

This is a bad name.
I can't understand at all what this macro stands for.
Besides, you only defined data register, not control register.
This is weird.

There exist two registers: control and data
for indexed-addressing of Denali NAND controller.

Denali document shows
Table 8.1
Register  | Offset Address
--
Control|0x0
Data|0x10


How about this?
#define INDEX_CTRL_REG 0x0
#define INDEX_DATA_REG0x10

And move definition from denali_nand.c to denal_nand.h.



 /* setups the HW to perform the data DMA */
 static void denali_setup_dma_sequence(int op)
 {

Please rename denali_setup_dma_sequence
to denali_setup_dma.

Linux uses the latter.
No reason to change it.


/* Common DMA function */
static uint32_t denali_dma_configuration(uint32_t ops, bool raw_xfer,
   uint32_t irq_mask, int oob_required)

Fix indentaion, please.



It's denali.c in Linux -- why denali_nand.c here?
   
   
   
   It seems all the existing U-Boot nand driver is using this naming
   standard where platform_nand.
  
  Not all -- there's omap_gpmc.c, omap_elm.c, nomadik.c, ndfc.c, etc.
  
  A lot of them have the _nand.c suffix in Linux, too.  Personally, I
  think it's redundant.
 
 
 Sure, I can change to denali.c

Agreed.



   Why are you using raw I/O accessors?  The Linux driver doesn't do this.
  
  Add ioread32/iowrite32 to arch/arm/include/asm/io.h
  and use them?
  
 
 
 Changed all to use standard writel and readl.

In my understanding, ioread32/iowrite32 is the same as
readl/writel  at least memory mapped architectures such ARM.

Because Linux Kernel' denali.c uses  ioread32/iowrite32,
I thought using them is helpful for easy diffing.


I've posted my feedback.
I hope it is helpful for you.
http://patchwork.ozlabs.org/patch/327943/



Best Regards
Masahiro Yamada

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

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

On Fri, Mar 07, 2014 at 05:38:40PM +0900, Masahiro Yamada wrote:
 Hello Tom, Albert,
 

 It is not clear to me when we should change the board status
 from Active to Orphan. 
 (Could you show me the basic guideline, Tom ? or Albert ?)
 There are many boards without maintainers, which are still Active.

This is a known, and so far, open, question. Right now, orphan boards
are those which were marked so in the former MAINTAINERS file. My
personal opinion is that Active should mean the board is
activelymaintained and any maintainer e-mail address associated
with the board is that of an active maintainer, and Orphan means the
board is not actively maintained any more but still builds, and any
address associated with it is that of the last known maintainer(s).
   
   +1 to this definition and yes, oops, I meant Orphan not Inactive.
  
  We should clarify this definition of Active/Orphan in the boards.cfg
  header text.
  
  Also, maybe we could simply mark dead addresses by suffixing the domain
  part with .invalid? For instance, the dead form of my own e-mail
  address would be albert.u.b...@aribaud.net.invalid? That would make
  sure that no mail is ever submitted to a correct domain with a bogus
  recipient.
 
 
 Definition:
Active should mean the board is activelymaintained and any
maintainer e-mail address associated with the board is that of an
active maintainer, and Orphan means the board is not actively
maintained any more but still builds, and any address associated
   with it is that of the last known maintainer(s).
 
 If we adopt this definition, adding dead address or .invalid
 is redundant, isn't it?
 
 Changing the status to Orphan is enough
 because Orphan declares its email address is invalid.

Yes.

-- 
Tom


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

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

2014-03-07 Thread Albert ARIBAUD

Hi Tom,

On Thu, 6 Mar 2014 11:22:16 -0500, Tom Rini tr...@ti.com wrote:

 On Thu, Mar 06, 2014 at 10:45:22AM -0500, Tom Rini wrote:
 
  Hey,
  
  The following changes since commit cc07294bc704694ae33db75b25ac557e5917a83f:
  
arm: am335x: DXR2: Reset SMSC LAN9303 switch via GPIO upon bootup 
  (2014-03-04 09:42:07 -0500)
  
  are available in the git repository at:
  
git://git.denx.de/u-boot-ti.git master
  
  for you to fetch changes up to 4b75fd510076f2261c5e21b9b8cf75c9f01ded3c:
  
board/BuR/common: fix phy addresses (2014-03-06 10:43:50 -0500)
  
  
  Hannes Petermaier (1):
board/BuR/common: fix phy addresses
  
   board/BuR/common/common.c |4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)
 
 This has been updated as:
 
 The following changes since commit cc07294bc704694ae33db75b25ac557e5917a83f:
 
   arm: am335x: DXR2: Reset SMSC LAN9303 switch via GPIO upon bootup 
 (2014-03-04 09:42:07 -0500)
 
 are available in the git repository at:
 
   git://git.denx.de/u-boot-ti.git master
 
 for you to fetch changes up to dd1e8583ee533a349c03ed4d75446898fe8dbac6:
 
   OMAP3: igep00x0: Enable required clocks for GPIO that are used. (2014-03-06 
 11:21:37 -0500)
 
 
 Enric Balletbo i Serra (1):
   OMAP3: igep00x0: Enable required clocks for GPIO that are used.
 
 Hannes Petermaier (1):
   board/BuR/common: fix phy addresses
 
  board/BuR/common/common.c|4 ++--
  include/configs/omap3_igep00x0.h |5 +
  2 files changed, 7 insertions(+), 2 deletions(-)
 
 

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

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

[U-Boot] [PATCH V5 00/12] Exynos4: add support for device tree

This patch set enables support for device tree on all Exynos4 based boards.

DT support is enabled on Exynos mipi dsim and sdhci drives.
Common board.c file is reused for all functions common for
Exynos4 boards. Board specific files are implemented in the board files.
Origen, Universal, Trats and Trats2 boards are modifed to support device tree.

This patch series depends on:
[U-Boot] sizes.h - consolidate for all architectures
http://patchwork.ozlabs.org/patch/324427/

Changes for v5:
 - add exynos_mipi_dsi.txt file with documented bindings
 - changed the name of exynos_lcd_panel_init to exynos_lcd_misc_init
 - removed unused panel_info.resolution binding

Changes for v4:
 - define CONFIG_ENV_SIZE, CONFIG_ENV_OFFSET, CONFIG_CMD_I2C at each board
 - use - hypen in DT bindings
 - remove duplicated DT properties at exynos_fb.c file

Changes for v3:
 - moved max77686 init function to smdk5250 board file
 - board DTS files moved to arch/arm/dts
 - rebased on the latest tree

Changes for v2:
 - removed incorrectly implemented check for invalid peripheral id
 - removed unnecesary white space
 - removed panel specific init function 's6e8ax0_init' to the board file
 - removed duplicate DTB node parsing for panel_info.logo_on
 - added (weak) exynos_lcd_panel_init function for panel specific
initialisation from board file
 - fixed checking for SDMMC boundary
 - fiex debug message
 - fixed comment to 'pwr_gpio' struct filed
 - new patch to move checkboard to common file
 - reuse existing common board.c file
 - new patch that removes unused max77686_init function
 - fixed mmc2 addres in DT on Trats2

Piotr Wilczek (12):
  exynos4:pinmux:fdt: decode peripheral id
  video:mipidsim:fdt: Add DT support for mipi dsim driver
  video:exynos_fb:fdt: add additional fdt data
  drivers:mmc:sdhci: enable support for DT
  board:samsung: move checkboard to common file
  arm:exynos: add common DTS file for exynos 4
  board:samsung:common: move max77686 init function
  arm:exynos: enable sdhci and misc_init to common board
  board:origen: Enable device tree on Origen
  board:universal: Enable device tree on Universal
  board:trats: Enable device tree on Trats
  board:trats2: Enable device tree on Trats2

 arch/arm/cpu/armv7/exynos/pinmux.c |  17 +
 arch/arm/dts/Makefile  |   5 +
 arch/arm/dts/exynos4.dtsi  | 138 +++
 arch/arm/dts/exynos4210-origen.dts |  45 +++
 arch/arm/dts/exynos4210-trats.dts  | 120 ++
 arch/arm/dts/exynos4210-universal_c210.dts |  83 
 arch/arm/dts/exynos4412-trats2.dts | 434 +
 arch/arm/include/asm/arch-exynos/board.h   |  12 +
 arch/arm/include/asm/arch-exynos/mipi_dsim.h   |   5 +
 arch/arm/include/asm/arch-exynos/mmc.h |   7 +
 board/samsung/common/board.c   | 180 +++--
 board/samsung/origen/origen.c  | 112 +-
 board/samsung/smdk5250/exynos5-dt.c|  15 -
 board/samsung/smdk5250/smdk5250.c  | 125 ++
 board/samsung/smdk5420/smdk5420.c  |  15 -
 board/samsung/trats/trats.c| 213 +-
 board/samsung/trats2/trats2.c  | 233 +--
 board/samsung/universal_c210/universal.c   | 204 +++---
 doc/device-tree-bindings/video/exynos_mipi_dsi.txt |  82 
 drivers/mmc/s5p_sdhci.c| 129 ++
 drivers/video/exynos_fb.c  |  12 +
 drivers/video/exynos_mipi_dsi.c|  96 +
 include/configs/exynos4-dt.h   | 138 +++
 include/configs/origen.h   | 110 ++
 include/configs/s5pc210_universal.h| 152 +++-
 include/configs/trats.h| 206 +++---
 include/configs/trats2.h   | 204 ++
 include/fdtdec.h   |   2 +
 include/sdhci.h|   5 +
 lib/fdtdec.c   |   2 +
 30 files changed, 1765 insertions(+), 1336 deletions(-)
 create mode 100644 arch/arm/dts/exynos4.dtsi
 create mode 100644 arch/arm/dts/exynos4210-origen.dts
 create mode 100644 arch/arm/dts/exynos4210-trats.dts
 create mode 100644 arch/arm/dts/exynos4210-universal_c210.dts
 create mode 100644 arch/arm/dts/exynos4412-trats2.dts
 create mode 100644 doc/device-tree-bindings/video/exynos_mipi_dsi.txt
 create mode 100644 include/configs/exynos4-dt.h

-- 
1.8.3.2

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

[U-Boot] [PATCH V5 01/12] exynos4:pinmux:fdt: decode peripheral id

This patch adds api to decode peripheral id based on interrupt number.

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

Changes for v4:
 - none

Changes for v3:
 - none

Changes for v2:
 - removed incorrectly implemented check for invalid peripheral id
 - removed unnecesary white space

 arch/arm/cpu/armv7/exynos/pinmux.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/cpu/armv7/exynos/pinmux.c 
b/arch/arm/cpu/armv7/exynos/pinmux.c
index 645c497..8d6e5c1 100644
--- a/arch/arm/cpu/armv7/exynos/pinmux.c
+++ b/arch/arm/cpu/armv7/exynos/pinmux.c
@@ -741,6 +741,21 @@ int exynos_pinmux_config(int peripheral, int flags)
 }
 
 #ifdef CONFIG_OF_CONTROL
+static int exynos4_pinmux_decode_periph_id(const void *blob, int node)
+{
+   int err;
+   u32 cell[3];
+
+   err = fdtdec_get_int_array(blob, node, interrupts, cell,
+   ARRAY_SIZE(cell));
+   if (err) {
+   debug( invalid peripheral id\n);
+   return PERIPH_ID_NONE;
+   }
+
+   return cell[1];
+}
+
 static int exynos5_pinmux_decode_periph_id(const void *blob, int node)
 {
int err;
@@ -758,6 +773,8 @@ int pinmux_decode_periph_id(const void *blob, int node)
 {
if (cpu_is_exynos5())
return  exynos5_pinmux_decode_periph_id(blob, node);
+   else if (cpu_is_exynos4())
+   return  exynos4_pinmux_decode_periph_id(blob, node);
else
return PERIPH_ID_NONE;
 }
-- 
1.8.3.2

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

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

This patch adds the new exynos_lcd_misc_init() function for optional
lcd specific initialisation.

Signed-off-by: Piotr Wilczek p.wilc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
---
Changes for v5:
 - changed the name of exynos_lcd_panel_init to exynos_lcd_misc_init
 - removed unused panel_info.resolution binding

Changes for v4:
 - remove duplicated DT properties at exynos_fb.c file

Changes for v3:
 - none

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

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

diff --git a/drivers/video/exynos_fb.c b/drivers/video/exynos_fb.c
index 00a0a11..e1e0d80 100644
--- a/drivers/video/exynos_fb.c
+++ b/drivers/video/exynos_fb.c
@@ -104,6 +104,13 @@ void __exynos_backlight_reset(void)
 void exynos_backlight_reset(void)
__attribute__((weak, alias(__exynos_backlight_reset)));
 
+int __exynos_lcd_misc_init(vidinfo_t *vid)
+{
+   return 0;
+}
+int exynos_lcd_misc_init(vidinfo_t *vid)
+   __attribute__((weak, alias(__exynos_lcd_misc_init)));
+
 static void lcd_panel_on(vidinfo_t *vid)
 {
udelay(vid-init_delay);
@@ -281,10 +288,15 @@ void lcd_ctrl_init(void *lcdbase)
 #ifdef CONFIG_OF_CONTROL
if (exynos_fimd_parse_dt(gd-fdt_blob))
debug(Can't get proper panel info\n);
+#ifdef CONFIG_EXYNOS_MIPI_DSIM
+   exynos_init_dsim_platform_data(panel_info);
+#endif
+   exynos_lcd_misc_init(panel_info);
 #else
/* initialize parameters which is specific to panel. */
init_panel_info(panel_info);
 #endif
+
panel_width = panel_info.vl_width;
panel_height = panel_info.vl_height;
 
-- 
1.8.3.2

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

[U-Boot] [PATCH V5 02/12] video:mipidsim:fdt: Add DT support for mipi dsim driver

This patch enables parsing mipi data from device tree.
Non device tree case is still supported.

Signed-off-by: Piotr Wilczek p.wilc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
---
Changes for v5:
 - add exynos_mipi_dsi.txt file with documented bindings

Changes for v4:
 - use - hypen for DT bindings

Changes for v3:
 - none

Changes for v2:
 - removed panel specific init function 's6e8ax0_init' to the board file

 arch/arm/include/asm/arch-exynos/mipi_dsim.h   |  5 ++
 doc/device-tree-bindings/video/exynos_mipi_dsi.txt | 82 ++
 drivers/video/exynos_mipi_dsi.c| 96 ++
 include/fdtdec.h   |  1 +
 lib/fdtdec.c   |  1 +
 5 files changed, 185 insertions(+)
 create mode 100644 doc/device-tree-bindings/video/exynos_mipi_dsi.txt

diff --git a/arch/arm/include/asm/arch-exynos/mipi_dsim.h 
b/arch/arm/include/asm/arch-exynos/mipi_dsim.h
index 40aca71..50e5c25 100644
--- a/arch/arm/include/asm/arch-exynos/mipi_dsim.h
+++ b/arch/arm/include/asm/arch-exynos/mipi_dsim.h
@@ -12,6 +12,7 @@
 
 #include linux/list.h
 #include linux/fb.h
+#include lcd.h
 
 #define PANEL_NAME_SIZE(32)
 
@@ -368,8 +369,12 @@ int exynos_mipi_dsi_register_lcd_device(struct 
mipi_dsim_lcd_device
*lcd_dev);
 
 void exynos_set_dsim_platform_data(struct exynos_platform_mipi_dsim *pd);
+void exynos_init_dsim_platform_data(vidinfo_t *vid);
 
 /* panel driver init based on mipi dsi interface */
 void s6e8ax0_init(void);
 
+#ifdef CONFIG_OF_CONTROL
+extern int mipi_power(void);
+#endif
 #endif /* _DSIM_H */
diff --git a/doc/device-tree-bindings/video/exynos_mipi_dsi.txt 
b/doc/device-tree-bindings/video/exynos_mipi_dsi.txt
new file mode 100644
index 000..4938ea0
--- /dev/null
+++ b/doc/device-tree-bindings/video/exynos_mipi_dsi.txt
@@ -0,0 +1,82 @@
+Exynos MIPI-DSIM Controller
+=
+
+Required properties:
+SOC specific:
+   compatible: should be samsung,exynos-mipi-dsi
+   reg: Base address of MIPI-DSIM IP.
+
+Board specific:
+   samsung,dsim-config-e-interface: interface to be used (RGB interface
+   for main display or CPU interface for main or sub display).
+   samsung,dsim-config-e-virtual-ch: virtual channel number that main
+   or sub display uses.
+   samsung,dsim-config-e-pixel-format: pixel stream format for main
+   or sub display.
+   samsung,dsim-config-e-burst-mode: selects Burst mode in Video mode.
+   in Non-burst mode, RGB data area is filled with RGB data and
+   NULL packets, according to input bandwidth of RGB interface.
+   samsung,dsim-config-e-no-data-lane: data lane count used by Master.
+   samsung,dsim-config-e-byte-clk: select byte clock source.
+   It must be DSIM_PLL_OUT_DIV8.
+   DSIM_EXT_CLK_DIV8 and DSIM_EXT_CLK_BYPASSS are not supported.
+   samsung,dsim-config-hfp: HFP disable mode.
+   If set, DSI master ignores HFP area in VIDEO mode.
+   In command mode, this variable is ignored.
+   samsung,dsim-config-p: P value for PMS setting.
+   samsung,dsim-config-m: M value for PMS setting.
+   samsung,dsim-config-s: S value for PMS setting.
+   samsung,dsim-config-pll-stable-time: the PLL Timer for stability
+   of the ganerated clock.
+   samsung,dsim-config-esc-clk: escape clock frequency for getting
+   the escape clock prescaler value.
+   samsung,dsim-config-stop-holding-cnt: the interval value between
+   transmitting read packet (or write set_tear_on command)
+   and BTA request. After transmitting read packet or write
+   set_tear_on command, BTA requests to D-PHY automatically.
+   This counter value specifies the interval between them.
+   samsung,dsim-config-bta-timeout: the timer for BTA. This register
+   specifies time out from BTA request to change the direction
+   with respect to Tx escape clock.
+   samsung,dsim-config-rx-timeout: the timer for LP Rx mode timeout.
+   this register specifies time out on how long RxValid deasserts,
+   after RxLpdt asserts with respect to Tx escape clock.
+   - RxValid specifies Rx data valid indicator.
+   - RxLpdt specifies an indicator that D-PHY is under RxLpdt mode
+   - RxValid and RxLpdt specifies signal from D-PHY.
+   samsung,dsim-device-name: name of the device.
+   samsung,dsim-device-id: unique device id.
+   samsung,dsim-device-bus_id: bus id for identifing connected bus
+   and this bus id should be same as id of mipi_dsim_device.
+
+Optional properties:
+   samsung,dsim-device-reverse-panel: reverse panel.
+
+Example:
+

[U-Boot] [PATCH V5 04/12] drivers:mmc:sdhci: enable support for DT

This patch enables support for device tree for sdhci driver.
Non DT case is still supported.

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

Changes for v4:
 - none

Changes for v3:
 - none

Changes for v2:
 - fixed checking for SDMMC boundary
 - fiex debug message
 - fixed comment to 'pwr_gpio' struct filed

 arch/arm/include/asm/arch-exynos/mmc.h |   7 ++
 drivers/mmc/s5p_sdhci.c| 129 +
 include/fdtdec.h   |   1 +
 include/sdhci.h|   5 ++
 lib/fdtdec.c   |   1 +
 5 files changed, 143 insertions(+)

diff --git a/arch/arm/include/asm/arch-exynos/mmc.h 
b/arch/arm/include/asm/arch-exynos/mmc.h
index 98d6530..0fb6461 100644
--- a/arch/arm/include/asm/arch-exynos/mmc.h
+++ b/arch/arm/include/asm/arch-exynos/mmc.h
@@ -53,6 +53,8 @@
 #define SDHCI_CTRL4_DRIVE_MASK(_x) ((_x)  16)
 #define SDHCI_CTRL4_DRIVE_SHIFT(16)
 
+#define SDHCI_MAX_HOSTS 4
+
 int s5p_sdhci_init(u32 regbase, int index, int bus_width);
 
 static inline int s5p_mmc_init(int index, int bus_width)
@@ -62,4 +64,9 @@ static inline int s5p_mmc_init(int index, int bus_width)
 
return s5p_sdhci_init(base, index, bus_width);
 }
+
+#ifdef CONFIG_OF_CONTROL
+int exynos_mmc_init(const void *blob);
+#endif
+
 #endif
diff --git a/drivers/mmc/s5p_sdhci.c b/drivers/mmc/s5p_sdhci.c
index 40ff873..ccae4cc 100644
--- a/drivers/mmc/s5p_sdhci.c
+++ b/drivers/mmc/s5p_sdhci.c
@@ -8,8 +8,15 @@
 #include common.h
 #include malloc.h
 #include sdhci.h
+#include fdtdec.h
+#include libfdt.h
+#include asm/gpio.h
 #include asm/arch/mmc.h
 #include asm/arch/clk.h
+#include errno.h
+#ifdef CONFIG_OF_CONTROL
+#include asm/arch/pinmux.h
+#endif
 
 static char *S5P_NAME = SAMSUNG SDHCI;
 static void s5p_sdhci_set_control_reg(struct sdhci_host *host)
@@ -86,3 +93,125 @@ int s5p_sdhci_init(u32 regbase, int index, int bus_width)
 
return add_sdhci(host, 5200, 40);
 }
+
+#ifdef CONFIG_OF_CONTROL
+struct sdhci_host sdhci_host[SDHCI_MAX_HOSTS];
+
+static int do_sdhci_init(struct sdhci_host *host)
+{
+   int dev_id, flag;
+   int err = 0;
+
+   flag = host-bus_width == 8 ? PINMUX_FLAG_8BIT_MODE : PINMUX_FLAG_NONE;
+   dev_id = host-index + PERIPH_ID_SDMMC0;
+
+   if (fdt_gpio_isvalid(host-pwr_gpio)) {
+   gpio_direction_output(host-pwr_gpio.gpio, 1);
+   err = exynos_pinmux_config(dev_id, flag);
+   if (err) {
+   debug(MMC not configured\n);
+   return err;
+   }
+   }
+
+   if (fdt_gpio_isvalid(host-cd_gpio)) {
+   gpio_direction_output(host-cd_gpio.gpio, 0xf);
+   if (gpio_get_value(host-cd_gpio.gpio))
+   return -ENODEV;
+
+   err = exynos_pinmux_config(dev_id, flag);
+   if (err) {
+   printf(external SD not configured\n);
+   return err;
+   }
+   }
+
+   host-name = S5P_NAME;
+
+   host-quirks = SDHCI_QUIRK_NO_HISPD_BIT | SDHCI_QUIRK_BROKEN_VOLTAGE |
+   SDHCI_QUIRK_BROKEN_R1B | SDHCI_QUIRK_32BIT_DMA_ADDR |
+   SDHCI_QUIRK_WAIT_SEND_CMD;
+   host-voltages = MMC_VDD_32_33 | MMC_VDD_33_34 | MMC_VDD_165_195;
+   host-version = sdhci_readw(host, SDHCI_HOST_VERSION);
+
+   host-set_control_reg = s5p_sdhci_set_control_reg;
+   host-set_clock = set_mmc_clk;
+
+   host-host_caps = MMC_MODE_HC;
+
+   return add_sdhci(host, 5200, 40);
+}
+
+static int sdhci_get_config(const void *blob, int node, struct sdhci_host 
*host)
+{
+   int bus_width, dev_id;
+   unsigned int base;
+
+   /* Get device id */
+   dev_id = pinmux_decode_periph_id(blob, node);
+   if (dev_id  PERIPH_ID_SDMMC0  dev_id  PERIPH_ID_SDMMC3) {
+   debug(MMC: Can't get device id\n);
+   return -1;
+   }
+   host-index = dev_id - PERIPH_ID_SDMMC0;
+
+   /* Get bus width */
+   bus_width = fdtdec_get_int(blob, node, samsung,bus-width, 0);
+   if (bus_width = 0) {
+   debug(MMC: Can't get bus-width\n);
+   return -1;
+   }
+   host-bus_width = bus_width;
+
+   /* Get the base address from the device node */
+   base = fdtdec_get_addr(blob, node, reg);
+   if (!base) {
+   debug(MMC: Can't get base address\n);
+   return -1;
+   }
+   host-ioaddr = (void *)base;
+
+   fdtdec_decode_gpio(blob, node, pwr-gpios, host-pwr_gpio);
+   fdtdec_decode_gpio(blob, node, cd-gpios, host-cd_gpio);
+
+   return 0;
+}
+
+static int process_nodes(const void *blob, int node_list[], int count)
+{
+   struct sdhci_host *host;
+   int i, node;
+
+   debug(%s: count = %d\n, __func__, count);
+
+   /* build

[U-Boot] [PATCH V5 05/12] board:samsung: move checkboard to common file

The checkboard function's implementation is common for all
DT supporting boards and should be placed in the board common file.

Signed-off-by: Piotr Wilczek p.wilc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Chander Kashyap k.chan...@samsung.com
Cc: Rajeshwari S Shinde rajeshwar...@samsung.com
Cc: Amar amarendra...@samsung.com

Acked-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
Changes for v5:
 - none

Changes for v4:
 - none

Changes for v3:
 - none

Changes for v2:
 - new patch

 board/samsung/common/board.c| 12 
 board/samsung/smdk5250/exynos5-dt.c | 15 ---
 board/samsung/smdk5420/smdk5420.c   | 15 ---
 3 files changed, 12 insertions(+), 30 deletions(-)

diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
index cd873bc..f8562b2 100644
--- a/board/samsung/common/board.c
+++ b/board/samsung/common/board.c
@@ -377,7 +377,19 @@ int board_mmc_init(bd_t *bis)
return ret;
 }
 #endif
+
+#ifdef CONFIG_DISPLAY_BOARDINFO
+int checkboard(void)
+{
+   const char *board_name;
+
+   board_name = fdt_getprop(gd-fdt_blob, 0, model, NULL);
+   printf(Board: %s\n, board_name ? board_name : unknown);
+
+   return 0;
+}
 #endif
+#endif /* CONFIG_OF_CONTROL */
 
 #ifdef CONFIG_BOARD_LATE_INIT
 int board_late_init(void)
diff --git a/board/samsung/smdk5250/exynos5-dt.c 
b/board/samsung/smdk5250/exynos5-dt.c
index 5fb8664..b22fba5 100644
--- a/board/samsung/smdk5250/exynos5-dt.c
+++ b/board/samsung/smdk5250/exynos5-dt.c
@@ -45,21 +45,6 @@ int exynos_init(void)
return 0;
 }
 
-#ifdef CONFIG_DISPLAY_BOARDINFO
-int checkboard(void)
-{
-   const char *board_name;
-
-   board_name = fdt_getprop(gd-fdt_blob, 0, model, NULL);
-   if (board_name == NULL)
-   printf(\nUnknown Board\n);
-   else
-   printf(\nBoard: %s\n, board_name);
-
-   return 0;
-}
-#endif
-
 #ifdef CONFIG_LCD
 void exynos_cfg_lcd_gpio(void)
 {
diff --git a/board/samsung/smdk5420/smdk5420.c 
b/board/samsung/smdk5420/smdk5420.c
index 3ad2ad0..e4606ec 100644
--- a/board/samsung/smdk5420/smdk5420.c
+++ b/board/samsung/smdk5420/smdk5420.c
@@ -142,18 +142,3 @@ int board_get_revision(void)
 {
return 0;
 }
-
-#ifdef CONFIG_DISPLAY_BOARDINFO
-int checkboard(void)
-{
-   const char *board_name;
-
-   board_name = fdt_getprop(gd-fdt_blob, 0, model, NULL);
-   if (board_name == NULL)
-   printf(\nUnknown Board\n);
-   else
-   printf(\nBoard: %s\n, board_name);
-
-   return 0;
-}
-#endif
-- 
1.8.3.2

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

[U-Boot] [PATCH V5 06/12] arm:exynos: add common DTS file for exynos 4

This patch adds common dtsi file and config header for all
Exynos 4 based boards.

Patch additionaly adds board specific (weak) functions for
board_early_init_f and board_power_init functions.

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

Changes for v4:
 - none

Changes for v3:
 - none

Changes for v2:
 - reuse existing common board.c file

 arch/arm/dts/exynos4.dtsi| 138 +++
 arch/arm/include/asm/arch-exynos/board.h |  12 +++
 board/samsung/common/board.c |  18 +++-
 include/configs/exynos4-dt.h | 138 +++
 4 files changed, 304 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/dts/exynos4.dtsi
 create mode 100644 include/configs/exynos4-dt.h

diff --git a/arch/arm/dts/exynos4.dtsi b/arch/arm/dts/exynos4.dtsi
new file mode 100644
index 000..71dc7eb
--- /dev/null
+++ b/arch/arm/dts/exynos4.dtsi
@@ -0,0 +1,138 @@
+/*
+ * Samsung's Exynos4 SoC common device tree source
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/include/ skeleton.dtsi
+
+/ {
+   serial@1380 {
+   compatible = samsung,exynos4210-uart;
+   reg = 0x1380 0x3c;
+   id = 0;
+   };
+
+   serial@1381 {
+   compatible = samsung,exynos4210-uart;
+   reg = 0x1381 0x3c;
+   id = 1;
+   };
+
+   serial@1382 {
+   compatible = samsung,exynos4210-uart;
+   reg = 0x1382 0x3c;
+   id = 2;
+   };
+
+   serial@1383 {
+   compatible = samsung,exynos4210-uart;
+   reg = 0x1383 0x3c;
+   id = 3;
+   };
+
+   serial@1384 {
+   compatible = samsung,exynos4210-uart;
+   reg = 0x1384 0x3c;
+   id = 4;
+   };
+
+   i2c@1386 {
+   #address-cells = 1;
+   #size-cells = 0;
+   compatible = samsung,s3c2440-i2c;
+   interrupts = 0 0 0;
+   };
+
+   i2c@1387 {
+   #address-cells = 1;
+   #size-cells = 0;
+   compatible = samsung,s3c2440-i2c;
+   interrupts = 1 1 0;
+   };
+
+   i2c@1388 {
+   #address-cells = 1;
+   #size-cells = 0;
+   compatible = samsung,s3c2440-i2c;
+   interrupts = 2 2 0;
+   };
+
+   i2c@1389 {
+   #address-cells = 1;
+   #size-cells = 0;
+   compatible = samsung,s3c2440-i2c;
+   interrupts = 3 3 0;
+   };
+
+   i2c@138a {
+   #address-cells = 1;
+   #size-cells = 0;
+   compatible = samsung,s3c2440-i2c;
+   interrupts = 4 4 0;
+   };
+
+   i2c@138b {
+   #address-cells = 1;
+   #size-cells = 0;
+   compatible = samsung,s3c2440-i2c;
+   interrupts = 5 5 0;
+   };
+
+   i2c@138c {
+   #address-cells = 1;
+   #size-cells = 0;
+   compatible = samsung,s3c2440-i2c;
+   interrupts = 6 6 0;
+   };
+
+   i2c@138d {
+   #address-cells = 1;
+   #size-cells = 0;
+   compatible = samsung,s3c2440-i2c;
+   interrupts = 7 7 0;
+   };
+
+   sdhci@1251 {
+   #address-cells = 1;
+   #size-cells = 0;
+   compatible = samsung,exynos-mmc;
+   reg = 0x1251 0x1000;
+   interrupts = 0 75 0;
+   };
+
+   sdhci@1252 {
+   #address-cells = 1;
+   #size-cells = 0;
+   compatible = samsung,exynos-mmc;
+   reg = 0x1252 0x1000;
+   interrupts = 0 76 0;
+   };
+
+   sdhci@1253 {
+   #address-cells = 1;
+   #size-cells = 0;
+   compatible = samsung,exynos-mmc;
+   reg = 0x1253 0x1000;
+   interrupts = 0 77 0;
+   };
+
+   sdhci@1254 {
+   #address-cells = 1;
+   #size-cells = 0;
+   compatible = samsung,exynos-mmc;
+   reg = 0x1254 0x1000;
+   interrupts = 0 78 0;
+   };
+
+   gpio: gpio {
+   gpio-controller;
+   #gpio-cells = 2;
+
+   interrupt-controller;
+   #interrupt-cells = 2;
+   };
+};
diff --git a/arch/arm/include/asm/arch-exynos/board.h 
b/arch/arm/include/asm/arch-exynos/board.h
index 243fb12..1b1cd0d 100644
--- a/arch/arm/include/asm/arch-exynos/board.h
+++ b/arch/arm/include/asm/arch-exynos/board.h
@@ -14,4 +14,16 @@
  */
 int exynos_init(void);
 
+/*
+ *

[U-Boot] [PATCH V5 08/12] arm:exynos: enable sdhci and misc_init to common board

This patch enables sdhci initialisation and misc_init_r in common board
file for all exynos 4 based boards.

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

Changes for v4:
 - none

Changes for v3:
 - none

Changes for v2:
 - new patch

 board/samsung/common/board.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
index a74b044..e95e9c4 100644
--- a/board/samsung/common/board.c
+++ b/board/samsung/common/board.c
@@ -22,6 +22,8 @@
 #include asm/arch/power.h
 #include power/pmic.h
 #include asm/arch/sromc.h
+#include lcd.h
+#include samsung/misc.h
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -183,6 +185,7 @@ int power_init_board(void)
 #endif
 
 #ifdef CONFIG_OF_CONTROL
+#ifdef CONFIG_SMC911X
 static int decode_sromc(const void *blob, struct fdt_sromc *config)
 {
int err;
@@ -206,6 +209,7 @@ static int decode_sromc(const void *blob, struct fdt_sromc 
*config)
}
return 0;
 }
+#endif
 
 int board_eth_init(bd_t *bis)
 {
@@ -263,10 +267,18 @@ int board_mmc_init(bd_t *bis)
 {
int ret;
 
+#ifdef CONFIG_SDHCI
+   /* mmc initializattion for available channels */
+   ret = exynos_mmc_init(gd-fdt_blob);
+   if (ret)
+   debug(mmc init failed\n);
+#endif
+#ifdef CONFIG_DWMMC
/* dwmmc initializattion for available channels */
ret = exynos_dwmmc_init(gd-fdt_blob);
if (ret)
debug(dwmmc init failed\n);
+#endif
 
return ret;
 }
@@ -315,3 +327,21 @@ int arch_early_init_r(void)
 
return 0;
 }
+
+#ifdef CONFIG_MISC_INIT_R
+int misc_init_r(void)
+{
+#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
+   set_board_info();
+#endif
+#ifdef CONFIG_LCD_MENU
+   keys_init();
+   check_boot_mode();
+#endif
+#ifdef CONFIG_CMD_BMP
+   if (panel_info.logo_on)
+   draw_logo();
+#endif
+   return 0;
+}
+#endif
-- 
1.8.3.2

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

[U-Boot] [PATCH V5 07/12] board:samsung:common: move max77686 init function

This patch moves board specific max77686 init function from
common board to smdk5250 board file.

Signed-off-by: Piotr Wilczek p.wilc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Rajeshwari S Shinde rajeshwar...@samsung.com
Cc: Rajeshwari Birje rajeshwari.bi...@gmail.com
Cc: Minkyu Kang mk7.k...@samsung.com
---
Changes for v5:
 - none

Changes for v4:
 - none

Changes for v3:
 - max77686 init function is moved to smdk5250 board file

Changes for v2:
 - new patch

 board/samsung/common/board.c  | 120 
 board/samsung/smdk5250/smdk5250.c | 125 ++
 2 files changed, 125 insertions(+), 120 deletions(-)

diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
index cf78d36..a74b044 100644
--- a/board/samsung/common/board.c
+++ b/board/samsung/common/board.c
@@ -22,7 +22,6 @@
 #include asm/arch/power.h
 #include power/pmic.h
 #include asm/arch/sromc.h
-#include power/max77686_pmic.h
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -175,129 +174,10 @@ static int board_init_cros_ec_devices(const void *blob)
 #endif
 
 #if defined(CONFIG_POWER)
-#ifdef CONFIG_POWER_MAX77686
-static int pmic_reg_update(struct pmic *p, int reg, uint regval)
-{
-   u32 val;
-   int ret = 0;
-
-   ret = pmic_reg_read(p, reg, val);
-   if (ret) {
-   debug(%s: PMIC %d register read failed\n, __func__, reg);
-   return -1;
-   }
-   val |= regval;
-   ret = pmic_reg_write(p, reg, val);
-   if (ret) {
-   debug(%s: PMIC %d register write failed\n, __func__, reg);
-   return -1;
-   }
-   return 0;
-}
-
-static int max77686_init(void)
-{
-   struct pmic *p;
-
-   if (pmic_init(I2C_PMIC))
-   return -1;
-
-   p = pmic_get(MAX77686_PMIC);
-   if (!p)
-   return -ENODEV;
-
-   if (pmic_probe(p))
-   return -1;
-
-   if (pmic_reg_update(p, MAX77686_REG_PMIC_32KHZ, MAX77686_32KHCP_EN))
-   return -1;
-
-   if (pmic_reg_update(p, MAX77686_REG_PMIC_BBAT,
-   MAX77686_BBCHOSTEN | MAX77686_BBCVS_3_5V))
-   return -1;
-
-   /* VDD_MIF */
-   if (pmic_reg_write(p, MAX77686_REG_PMIC_BUCK1OUT,
-  MAX77686_BUCK1OUT_1V)) {
-   debug(%s: PMIC %d register write failed\n, __func__,
- MAX77686_REG_PMIC_BUCK1OUT);
-   return -1;
-   }
-
-   if (pmic_reg_update(p, MAX77686_REG_PMIC_BUCK1CRTL,
-   MAX77686_BUCK1CTRL_EN))
-   return -1;
-
-   /* VDD_ARM */
-   if (pmic_reg_write(p, MAX77686_REG_PMIC_BUCK2DVS1,
-  MAX77686_BUCK2DVS1_1_3V)) {
-   debug(%s: PMIC %d register write failed\n, __func__,
- MAX77686_REG_PMIC_BUCK2DVS1);
-   return -1;
-   }
-
-   if (pmic_reg_update(p, MAX77686_REG_PMIC_BUCK2CTRL1,
-   MAX77686_BUCK2CTRL_ON))
-   return -1;
-
-   /* VDD_INT */
-   if (pmic_reg_write(p, MAX77686_REG_PMIC_BUCK3DVS1,
-  MAX77686_BUCK3DVS1_1_0125V)) {
-   debug(%s: PMIC %d register write failed\n, __func__,
- MAX77686_REG_PMIC_BUCK3DVS1);
-   return -1;
-   }
-
-   if (pmic_reg_update(p, MAX77686_REG_PMIC_BUCK3CTRL,
-   MAX77686_BUCK3CTRL_ON))
-   return -1;
-
-   /* VDD_G3D */
-   if (pmic_reg_write(p, MAX77686_REG_PMIC_BUCK4DVS1,
-  MAX77686_BUCK4DVS1_1_2V)) {
-   debug(%s: PMIC %d register write failed\n, __func__,
- MAX77686_REG_PMIC_BUCK4DVS1);
-   return -1;
-   }
-
-   if (pmic_reg_update(p, MAX77686_REG_PMIC_BUCK4CTRL1,
-   MAX77686_BUCK3CTRL_ON))
-   return -1;
-
-   /* VDD_LDO2 */
-   if (pmic_reg_update(p, MAX77686_REG_PMIC_LDO2CTRL1,
-   MAX77686_LD02CTRL1_1_5V | EN_LDO))
-   return -1;
-
-   /* VDD_LDO3 */
-   if (pmic_reg_update(p, MAX77686_REG_PMIC_LDO3CTRL1,
-   MAX77686_LD03CTRL1_1_8V | EN_LDO))
-   return -1;
-
-   /* VDD_LDO5 */
-   if (pmic_reg_update(p, MAX77686_REG_PMIC_LDO5CTRL1,
-   MAX77686_LD05CTRL1_1_8V | EN_LDO))
-   return -1;
-
-   /* VDD_LDO10 */
-   if (pmic_reg_update(p, MAX77686_REG_PMIC_LDO10CTRL1,
-   MAX77686_LD10CTRL1_1_8V | EN_LDO))
-   return -1;
-
-   return 0;
-}
-#endif
-
 int power_init_board(void)
 {
-   int ret = 0;
-
set_ps_hold_ctrl();
 
-#ifdef CONFIG_POWER_MAX77686
-   ret = max77686_init();
-#endif
-
return exynos_power_init();
 }
 #endif
diff --git a/board/samsung/smdk5250/smdk5250.c 
b/board/samsung/smdk5250/smdk5250.c
index

[U-Boot] [PATCH V5 09/12] board:origen: Enable device tree on Origen

This patch enables to run Origen board on device tree.

Uart, DRAM and MMC init functions are removed as their
generic replacements form the common board file are used.

The config file is modified to contain only board specific options.

Signed-off-by: Piotr Wilczek p.wilc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Chander Kashyap k.chan...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
---
Changes for v5:
 - no changes

Changes for v4:
 - define CONFIG_ENV_SIZE, CONFIG_ENV_OFFSET, CONFIG_CMD_I2C at each board

Changes for v3:
 - dts file moved to arch/arm/dts

Changes for v2:
 - no changes

 arch/arm/dts/Makefile  |   2 +
 arch/arm/dts/exynos4210-origen.dts |  45 +++
 board/samsung/origen/origen.c  | 112 +++--
 include/configs/origen.h   | 110 ++--
 4 files changed, 87 insertions(+), 182 deletions(-)
 create mode 100644 arch/arm/dts/exynos4210-origen.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index e2fcca5..dad03cf 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1,3 +1,5 @@
+dtb-$(CONFIG_EXYNOS4) += exynos4210-origen.dtb
+
 dtb-$(CONFIG_EXYNOS5) += exynos5250-arndale.dtb \
exynos5250-snow.dtb \
exynos5250-smdk5250.dtb \
diff --git a/arch/arm/dts/exynos4210-origen.dts 
b/arch/arm/dts/exynos4210-origen.dts
new file mode 100644
index 000..5c9d2ae
--- /dev/null
+++ b/arch/arm/dts/exynos4210-origen.dts
@@ -0,0 +1,45 @@
+/*
+ * Samsung's Exynos4210 based Origen board device tree source
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/dts-v1/;
+/include/ skeleton.dtsi
+/include/ exynos4.dtsi
+
+/ {
+   model = Insignal Origen evaluation board based on Exynos4210;
+   compatible = insignal,origen, samsung,exynos4210;
+
+   chosen {
+   bootargs =;
+   };
+
+   aliases {
+   serial0 = /serial@1380;
+   console = /serial@1382;
+   mmc2 = sdhci@1253;
+   };
+
+   sdhci@1251 {
+   status = disabled;
+   };
+
+   sdhci@1252 {
+   status = disabled;
+   };
+
+   sdhci@1253 {
+   samsung,bus-width = 4;
+   samsung,timing = 1 2 3;
+   cd-gpios = gpio 0x2008002 0;
+   };
+
+   sdhci@1254 {
+   status = disabled;
+   };
+};
\ No newline at end of file
diff --git a/board/samsung/origen/origen.c b/board/samsung/origen/origen.c
index 15f77ca..d502f02 100644
--- a/board/samsung/origen/origen.c
+++ b/board/samsung/origen/origen.c
@@ -11,129 +11,35 @@
 #include asm/arch/mmc.h
 #include asm/arch/periph.h
 #include asm/arch/pinmux.h
+#include usb.h
 
 DECLARE_GLOBAL_DATA_PTR;
-struct exynos4_gpio_part1 *gpio1;
-struct exynos4_gpio_part2 *gpio2;
 
-int board_init(void)
+u32 get_board_rev(void)
 {
-   gpio1 = (struct exynos4_gpio_part1 *) EXYNOS4_GPIO_PART1_BASE;
-   gpio2 = (struct exynos4_gpio_part2 *) EXYNOS4_GPIO_PART2_BASE;
-
-   gd-bd-bi_boot_params = (PHYS_SDRAM_1 + 0x100UL);
return 0;
 }
 
-static int board_uart_init(void)
+int exynos_init(void)
 {
-   int err;
-
-   err = exynos_pinmux_config(PERIPH_ID_UART0, PINMUX_FLAG_NONE);
-   if (err) {
-   debug(UART0 not configured\n);
-   return err;
-   }
-
-   err = exynos_pinmux_config(PERIPH_ID_UART1, PINMUX_FLAG_NONE);
-   if (err) {
-   debug(UART1 not configured\n);
-   return err;
-   }
-
-   err = exynos_pinmux_config(PERIPH_ID_UART2, PINMUX_FLAG_NONE);
-   if (err) {
-   debug(UART2 not configured\n);
-   return err;
-   }
-
-   err = exynos_pinmux_config(PERIPH_ID_UART3, PINMUX_FLAG_NONE);
-   if (err) {
-   debug(UART3 not configured\n);
-   return err;
-   }
-
return 0;
 }
 
-#ifdef CONFIG_BOARD_EARLY_INIT_F
-int board_early_init_f(void)
-{
-   int err;
-   err = board_uart_init();
-   if (err) {
-   debug(UART init failed\n);
-   return err;
-   }
-   return err;
-}
-#endif
-
-int dram_init(void)
+int board_usb_init(int index, enum usb_init_type init)
 {
-   gd-ram_size= get_ram_size((long *)PHYS_SDRAM_1, PHYS_SDRAM_1_SIZE)
-   + get_ram_size((long *)PHYS_SDRAM_2, PHYS_SDRAM_2_SIZE)
-   + get_ram_size((long *)PHYS_SDRAM_3, PHYS_SDRAM_3_SIZE)
-   + get_ram_size((long *)PHYS_SDRAM_4, PHYS_SDRAM_4_SIZE);
-
return 0;
 }
 
-void dram_init_banksize(void)
-{
-   gd-bd-bi_dram[0].start = PHYS_SDRAM_1;
-   gd-bd-bi_dram[0].size = get_ram_size((long *)PHYS_SDRAM_1, \
-   PHYS_SDRAM_1_SIZE);
-   gd-bd-bi_dram[1].start = PHYS_SDRAM_2;
-

[U-Boot] [PATCH V5 11/12] board:trats: Enable device tree on Trats

This patch enables to run Trats board on device tree.

Signed-off-by: Piotr Wilczek p.wilc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Minkyu Kang mk7.k...@samsung.com
CC: Lukasz Majewski l.majew...@samsung.com
---
Changes for v5:
 - changed the name of exynos_lcd_panel_init to exynos_lcd_misc_init

Changes for v4:
 - use - hypen in DT bindings
 - define CONFIG_ENV_SIZE, CONFIG_ENV_OFFSET, CONFIG_CMD_I2C at each board

Changes for v3:
 - dts file moved to arch/arm/dts

Changes for v2:
 - no changes

 arch/arm/dts/Makefile |   3 +-
 arch/arm/dts/exynos4210-trats.dts | 120 +
 board/samsung/trats/trats.c   | 213 ++
 include/configs/trats.h   | 206 ++--
 4 files changed, 185 insertions(+), 357 deletions(-)
 create mode 100644 arch/arm/dts/exynos4210-trats.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 488aec2..a853ec6 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1,5 +1,6 @@
 dtb-$(CONFIG_EXYNOS4) += exynos4210-origen.dtb \
-   exynos4210-universal_c210.dtb
+   exynos4210-universal_c210.dtb \
+   exynos4210-trats.dtb
 
 dtb-$(CONFIG_EXYNOS5) += exynos5250-arndale.dtb \
exynos5250-snow.dtb \
diff --git a/arch/arm/dts/exynos4210-trats.dts 
b/arch/arm/dts/exynos4210-trats.dts
new file mode 100644
index 000..992e023
--- /dev/null
+++ b/arch/arm/dts/exynos4210-trats.dts
@@ -0,0 +1,120 @@
+/*
+ * Samsung's Exynos4210 based Trats board device tree source
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/dts-v1/;
+/include/ exynos4.dtsi
+
+/ {
+   model = Samsung Trats based on Exynos4210;
+   compatible = samsung,trats, samsung,exynos4210;
+
+   config {
+   samsung,dsim-device-name = s6e8ax0;
+   };
+
+   aliases {
+   i2c0 = /i2c@1386;
+   i2c1 = /i2c@1387;
+   i2c2 = /i2c@1388;
+   i2c3 = /i2c@1389;
+   i2c4 = /i2c@138a;
+   i2c5 = /i2c@138b;
+   i2c6 = /i2c@138c;
+   i2c7 = /i2c@138d;
+   serial0 = /serial@1380;
+   console = /serial@1382;
+   mmc0 = sdhci@1251;
+   mmc2 = sdhci@1253;
+   };
+
+   fimd@11c0 {
+   compatible = samsung,exynos-fimd;
+   reg = 0x11c0 0xa4;
+
+   samsung,vl-freq = 60;
+   samsung,vl-col = 720;
+   samsung,vl-row = 1280;
+   samsung,vl-width = 720;
+   samsung,vl-height = 1280;
+
+   samsung,vl-clkp = 0;
+   samsung,vl-oep = 0;
+   samsung,vl-hsp = 1;
+   samsung,vl-vsp = 1;
+   samsung,vl-dp = 1;
+   samsung,vl-bpix = 4;
+
+   samsung,vl-hspw = 5;
+   samsung,vl-hbpd = 10;
+   samsung,vl-hfpd = 10;
+   samsung,vl-vspw = 2;
+   samsung,vl-vbpd = 1;
+   samsung,vl-vfpd = 13;
+   samsung,vl-cmd-allow-len = 0xf;
+
+   samsung,winid = 3;
+   samsung,power-on-delay = 30;
+   samsung,interface-mode = 1;
+   samsung,mipi-enabled = 1;
+   samsung,dp-enabled;
+   samsung,dual-lcd-enabled;
+
+   samsung,logo-on = 1;
+   samsung,resolution = 0;
+   samsung,rgb-mode = 0;
+   };
+
+   mipidsi@11c8 {
+   compatible = samsung,exynos-mipi-dsi;
+   reg = 0x11c8 0x5c;
+
+   samsung,dsim-config-e-interface = 1;
+   samsung,dsim-config-e-virtual-ch = 0;
+   samsung,dsim-config-e-pixel-format = 7;
+   samsung,dsim-config-e-burst-mode = 1;
+   samsung,dsim-config-e-no-data-lane = 3;
+   samsung,dsim-config-e-byte-clk = 0;
+   samsung,dsim-config-hfp = 1;
+
+   samsung,dsim-config-p = 3;
+   samsung,dsim-config-m = 120;
+   samsung,dsim-config-s = 1;
+
+   samsung,dsim-config-pll-stable-time = 500;
+   samsung,dsim-config-esc-clk = 2000;
+   samsung,dsim-config-stop-holding-cnt = 0x7ff;
+   samsung,dsim-config-bta-timeout = 0xff;
+   samsung,dsim-config-rx-timeout = 0x;
+
+   samsung,dsim-device-id = 0x;
+   samsung,dsim-device-bus-id = 0;
+
+   samsung,dsim-device-reverse-panel = 1;
+   };
+
+   sdhci@1251 {
+   samsung,bus-width = 8;
+   samsung,timing = 1 3 3;
+   pwr-gpios = gpio 0x2008002 0;
+   };
+
+   sdhci@1252 {
+   status = disabled;
+   };
+
+   sdhci@1253 {
+

[U-Boot] [PATCH V5 10/12] board:universal: Enable device tree on Universal

This patch enables to run Universal board on device tree.

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

Acked-by: Przemyslaw Marczak p.marc...@samsung.com
---
Changes for v5:
 - changed the name of exynos_lcd_panel_init to exynos_lcd_misc_init

Changes for v4:
 - define CONFIG_ENV_SIZE, CONFIG_ENV_OFFSET, CONFIG_CMD_I2C at each board

Changes for v3:
 - dts file moved to arch/arm/dts

Changes for v2:
 - no changes

 arch/arm/dts/Makefile  |   3 +-
 arch/arm/dts/exynos4210-universal_c210.dts |  83 
 board/samsung/universal_c210/universal.c   | 204 -
 include/configs/s5pc210_universal.h| 152 +++--
 4 files changed, 185 insertions(+), 257 deletions(-)
 create mode 100644 arch/arm/dts/exynos4210-universal_c210.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index dad03cf..488aec2 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1,4 +1,5 @@
-dtb-$(CONFIG_EXYNOS4) += exynos4210-origen.dtb
+dtb-$(CONFIG_EXYNOS4) += exynos4210-origen.dtb \
+   exynos4210-universal_c210.dtb
 
 dtb-$(CONFIG_EXYNOS5) += exynos5250-arndale.dtb \
exynos5250-snow.dtb \
diff --git a/arch/arm/dts/exynos4210-universal_c210.dts 
b/arch/arm/dts/exynos4210-universal_c210.dts
new file mode 100644
index 000..1cdd981
--- /dev/null
+++ b/arch/arm/dts/exynos4210-universal_c210.dts
@@ -0,0 +1,83 @@
+/*
+ * Samsung's Exynos4210 based Universal C210 board device tree source
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/dts-v1/;
+/include/ exynos4.dtsi
+
+/ {
+   model = Samsung Universal C210 based on Exynos4210 rev0;
+   compatible = samsung,universal_c210, samsung,exynos4210;
+
+   aliases {
+   serial0 = /serial@1380;
+   console = /serial@1382;
+   mmc0 = sdhci@1251;
+   mmc2 = sdhci@1253;
+   };
+
+   sdhci@1251 {
+   samsung,bus-width = 8;
+   samsung,timing = 1 3 3;
+   pwr-gpios = gpio 0x2008002 0;
+   };
+
+   sdhci@1252 {
+   status = disabled;
+   };
+
+   sdhci@1253 {
+   samsung,bus-width = 4;
+   samsung,timing = 1 2 3;
+   cd-gpios = gpio 0x20c6004 0;
+   };
+
+   sdhci@1254 {
+   status = disabled;
+   };
+
+   fimd@11c0 {
+   compatible = samsung,exynos-fimd;
+   reg = 0x11c0 0xa4;
+
+   samsung,vl-freq = 60;
+   samsung,vl-col = 480;
+   samsung,vl-row = 800;
+   samsung,vl-width = 480;
+   samsung,vl-height = 800;
+
+   samsung,vl-clkp = 0;
+   samsung,vl-oep = 0;
+   samsung,vl-hsp = 1;
+   samsung,vl-vsp = 1;
+   samsung,vl-dp = 1;
+   samsung,vl-bpix = 4;
+
+   samsung,vl-hspw = 2;
+   samsung,vl-hbpd = 16;
+   samsung,vl-hfpd = 16;
+   samsung,vl-vspw = 2;
+   samsung,vl-vbpd = 8;
+   samsung,vl-vfpd = 8;
+   samsung,vl-cmd-allow-len = 0xf;
+
+   samsung,pclk_name = 1;
+   samsung,sclk_div = 1;
+
+   samsung,winid = 0;
+   samsung,power-on-delay = 1;
+   samsung,interface-mode = 1;
+   samsung,mipi-enabled = 0;
+   samsung,dp-enabled;
+   samsung,dual-lcd-enabled;
+
+   samsung,logo-on = 1;
+   samsung,resolution = 0;
+   samsung,rgb-mode = 0;
+   };
+};
diff --git a/board/samsung/universal_c210/universal.c 
b/board/samsung/universal_c210/universal.c
index 96da7e0..f9d71b6 100644
--- a/board/samsung/universal_c210/universal.c
+++ b/board/samsung/universal_c210/universal.c
@@ -13,16 +13,17 @@
 #include asm/gpio.h
 #include asm/arch/adc.h
 #include asm/arch/gpio.h
-#include asm/arch/mmc.h
 #include asm/arch/pinmux.h
 #include asm/arch/watchdog.h
-#include libtizen.h
 #include ld9040.h
 #include power/pmic.h
+#include usb.h
 #include usb/s3c_udc.h
 #include asm/arch/cpu.h
 #include power/max8998_pmic.h
+#include libtizen.h
 #include samsung/misc.h
+#include usb_mass_storage.h
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -42,7 +43,7 @@ static int get_hwrev(void)
 
 static void init_pmic_lcd(void);
 
-int power_init_board(void)
+int exynos_power_init(void)
 {
int ret;
 
@@ -59,22 +60,6 @@ int power_init_board(void)
return 0;
 }
 
-int dram_init(void)
-{
-   gd-ram_size = get_ram_size((long *)PHYS_SDRAM_1, PHYS_SDRAM_1_SIZE) +
-   get_ram_size((long *)PHYS_SDRAM_2, PHYS_SDRAM_2_SIZE);
-
-   return 0;
-}
-
-void dram_init_banksize(void)
-{
-   gd-bd-bi_dram[0].start =

[U-Boot] [PATCH V5 12/12] board:trats2: Enable device tree on Trats2

This patch enables to run Trats2 board on device tree.

Signed-off-by: Piotr Wilczek p.wilc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Minkyu Kang mk7.k...@samsung.com
---
Changes for v5:
 - changed the name of exynos_lcd_panel_init to exynos_lcd_misc_init

Changes for v4:
 - use - hypen in DT bindings
 - define CONFIG_ENV_SIZE, CONFIG_ENV_OFFSET, CONFIG_CMD_I2C at each board

Changes for v3:
 - dts file moved to arch/arm/dts

Changes for v2:
 - fixed mmc2 address in DT

 arch/arm/dts/Makefile  |   3 +-
 arch/arm/dts/exynos4412-trats2.dts | 434 +
 board/samsung/trats2/trats2.c  | 233 +---
 include/configs/trats2.h   | 204 -
 4 files changed, 483 insertions(+), 391 deletions(-)
 create mode 100644 arch/arm/dts/exynos4412-trats2.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index a853ec6..631a9be 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1,6 +1,7 @@
 dtb-$(CONFIG_EXYNOS4) += exynos4210-origen.dtb \
exynos4210-universal_c210.dtb \
-   exynos4210-trats.dtb
+   exynos4210-trats.dtb \
+   exynos4412-trats2.dtb
 
 dtb-$(CONFIG_EXYNOS5) += exynos5250-arndale.dtb \
exynos5250-snow.dtb \
diff --git a/arch/arm/dts/exynos4412-trats2.dts 
b/arch/arm/dts/exynos4412-trats2.dts
new file mode 100644
index 000..7d32067
--- /dev/null
+++ b/arch/arm/dts/exynos4412-trats2.dts
@@ -0,0 +1,434 @@
+/*
+ * Samsung's Exynos4412 based Trats2 board device tree source
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/dts-v1/;
+/include/ exynos4.dtsi
+
+/ {
+   model = Samsung Trats2 based on Exynos4412;
+   compatible = samsung,trats2, samsung,exynos4412;
+
+   config {
+   samsung,dsim-device-name = s6e8ax0;
+   };
+
+   aliases {
+   i2c0 = /i2c@1386;
+   i2c1 = /i2c@1387;
+   i2c2 = /i2c@1388;
+   i2c3 = /i2c@1389;
+   i2c4 = /i2c@138a;
+   i2c5 = /i2c@138b;
+   i2c6 = /i2c@138c;
+   i2c7 = /i2c@138d;
+   serial0 = /serial@1380;
+   console = /serial@1382;
+   mmc0 = sdhci@1251;
+   mmc2 = sdhci@1253;
+   };
+
+   i2c@138d {
+   samsung,i2c-sda-delay = 100;
+   samsung,i2c-slave-addr = 0x10;
+   samsung,i2c-max-bus-freq = 10;
+   status = okay;
+
+   max77686_pmic@09 {
+   compatible = maxim,max77686_pmic;
+   interrupts = 7 0;
+   reg = 0x09 0 0;
+   #clock-cells = 1;
+
+   voltage-regulators {
+   ldo1_reg: ldo1 {
+   regulator-compatible = LDO1;
+   regulator-name = VALIVE_1.0V_AP;
+   regulator-min-microvolt = 100;
+   regulator-max-microvolt = 100;
+   regulator-always-on;
+   regulator-mem-on;
+   };
+
+   ldo2_reg: ldo2 {
+   regulator-compatible = LDO2;
+   regulator-name = VM1M2_1.2V_AP;
+   regulator-min-microvolt = 120;
+   regulator-max-microvolt = 120;
+   regulator-always-on;
+   regulator-mem-on;
+   };
+
+   ldo3_reg: ldo3 {
+   regulator-compatible = LDO3;
+   regulator-name = VCC_1.8V_AP;
+   regulator-min-microvolt = 180;
+   regulator-max-microvolt = 180;
+   regulator-always-on;
+   regulator-mem-on;
+   };
+
+   ldo4_reg: ldo4 {
+   regulator-compatible = LDO4;
+   regulator-name = VCC_2.8V_AP;
+   regulator-min-microvolt = 280;
+   regulator-max-microvolt = 280;
+   regulator-always-on;
+   regulator-mem-on;
+   };
+
+   ldo5_reg: ldo5 {
+   regulator-compatible =

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

2014-03-07 Thread Albert ARIBAUD

Hi Tom,

On Thu, 6 Mar 2014 08:39:32 -0700, Tom Warren
twarren.nvi...@gmail.com wrote:

 Albert,
 
 Please pull u-boot-tegra/master into ARM/master. Thanks!
 
 ./MAKEALL -s tegra AOK, checkpatch.pl is clean, and ./MAKEALL -a arm only
 shows failures that were already present in ARM/master.
 
 The following changes since commit cc07294bc704694ae33db75b25ac557e5917a83f:
 
   arm: am335x: DXR2: Reset SMSC LAN9303 switch via GPIO upon bootup
 (2014-03-04 09:42:07 -0500)
 
 are available in the git repository at:
 
   git://git.denx.de/u-boot-tegra master
 
 for you to fetch changes up to f940c72e16f7bdebaaed79b290c1bcb6dc015053:
 
   ARM: tegra: implement bootcmd_pxe (2014-03-05 16:59:08 -0700)
 
 
 Stephen Warren (8):
   ARM: tegra: move CONFIG_TEGRAnn
   ARM: tegra: fix pmc_pwrgate_timer_mult register definition
   ARM: tegra: fix NV_PA_CSITE_BASE for Tegra124
   ARM: tegra: simplify halt_avp()
   ARM: tegra: set CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS
   ARM: tegra: convert tegra to use distro defaults
   ARM: tegra: rework boot scripts
   ARM: tegra: implement bootcmd_pxe
 
  arch/arm/cpu/arm720t/tegra-common/cpu.c|  5 ++-
  arch/arm/cpu/arm720t/tegra124/cpu.c|  4 +--
  arch/arm/include/asm/arch-tegra/pmc.h  | 11 ++
  arch/arm/include/asm/arch-tegra/tegra.h|  5 +++
  arch/arm/include/asm/arch-tegra114/tegra.h |  2 ++
  arch/arm/include/asm/arch-tegra124/tegra.h |  2 ++
  arch/arm/include/asm/arch-tegra20/tegra.h  |  2 ++
  arch/arm/include/asm/arch-tegra30/tegra.h  |  2 ++
  include/configs/tegra-common-post.h| 57
 --
  include/configs/tegra-common.h | 20 +++
  include/configs/tegra114-common.h  | 10 +++---
  include/configs/tegra124-common.h  |  6 +---
  include/configs/tegra20-common.h   | 10 +++---
  include/configs/tegra30-common.h   | 10 +++---
  14 files changed, 95 insertions(+), 51 deletions(-)

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

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

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

2014-03-07 Thread Chin Liang See

Hi Michal,

On Fri, 2014-03-07 at 09:12 +0100, Michal Simek wrote:
 On 03/05/2014 08:00 PM, Chin Liang See wrote:
  On Wed, 2014-03-05 at 19:47 +0100, Michal Simek wrote:
  Hi Pavel,
 
 
  2014-03-05 17:13 GMT+01:00 Pavel Machek pa...@denx.de:
  Hi!
  
   Also I expect that you can change all pins for
  uarts/ethernets/spi/i2c/etc
   that's why there is no golden configuration for socfpga
  that's why
   it is better to keep it empty just to compile it.
  
  
  Well, there are some development boards around... and having
  u-boot
  able to boot on the devel board by default would be very very
  useful.
 
 
  I believe you but the point is somewhere else if you can reach it by
  universal
 
  target.
 
   
  
At same time, these files are located inside board
  folders. If user have
different boards, they will have new set of folders here
  their own
handoff files. From there, there won't the need to
  regenerate everytime.
  
   Please explain me one thing how many users will use this
  configuration?
   Especially these ~600 lines?
  
  
  Pretty much everyone when they test-boot their system...?
 
 
  Really? It means that all development boards/custom boards with
  socfpga
 
  
  I believe you confuse with arch and board. These files are located
  inside board. For board/altera/socfpga, its referring to Altera dev kit.
  When another vendor, example like Xilinx, fabricated a board with
  SOCFPGA chip, then it will have another folder called
  board/xilinx/socfpga.
 
 That explains a lot. Why isn't call devkit then?
 


Examples always nice when I explaining and I love examples.
While the naming, it would be interesting topic which same as giving
baby's name.


 
 
  use the same configuration which seems to me weird.
 
  If yes, then why these files are autogenerated if the same config can
  be use for
  all boards?
 
  Probably an example will clear your doubt. When the board is fabricated,
  the pin mux used will be fixed. You won't need to change it until you
  fabricated a new board. 
 
 I understand that you want to have something which you can just compile
 and boot. But only pins are fixed not internal connection inside chip.
 Also I expect you have connectors on the board which you can use for add-on
 cards.
 My doubts are just based on my experience with zynq that not everything
 what it is generated by tools is really needed to get board boot.
 Also boards have just fixed pins but not internal connections to these pins.
 I believe that this is just the same for your dev kit.
 Also I hardly believe that you need all 600lines just to have something
 to boot.
 


Both SOCFPGA and Zynq are unique due to its programmability. But in this
case, all our configurations here would only support golden system
reference design on Altera dev kit. This would make our lives much
easier.

Thanks
Chin Liang


 Thanks,
 Michal
 


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

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

2014-03-07 Thread Chin Liang See

Hi Masahiro,

On Fri, 2014-03-07 at 21:58 +0900, Masahiro Yamada wrote:
 Hello Chin,
 
 
  +/* setups the HW to perform the data DMA */
  +static void denali_setup_dma_sequence(int op)
  +{
  +   const int page_count = 1;
  +   uint32_t mode;
  +   uint32_t addr = (uint32_t)denali.buf.dma_buf;
  +
  +   flush_dcache_range(addr, addr + sizeof(denali.buf.dma_buf));
  +
  +   mode = MODE_10 | BANK(denali.flash_bank);
  +
  +   /* DMA is a four step process */
  +
  +   /* 1. setup transfer type and # of pages */
  +   index_addr(mode | denali.page, 0x2000 | op | page_count);
  +
  +   /* 2. set memory high address bits 23:8 */
  +   index_addr(mode | ((uint32_t)(addr  16)  8), 0x2200);
  +
  +   /* 3. set memory low address bits 23:8 */
  +   index_addr(mode | ((uint32_t)addr  8), 0x2300);
  +
  +   /* 4.  interrupt when complete, burst len = 64 bytes*/
  +   index_addr(mode | 0x14000, 0x2400);
  +}
 
 
 This function would not work on my board.
 Besides, it is completely different from the description
 written in  Chapter 7. Data DMA of 
 Denali NAND Flash Memory Controller User's Guide.


Hmmm... based on past few email exchange, I am wonder there are few
different version of Denali. For this section, its located at chapter 7:
Data DMA. Wonder you can facilitate which part if not correct. From
there, I can provide what being explain in the datasheet.


 
 It looks really weird to me.
 So I asked some questions to Cadence (Denali, before MA).
 
 Accoding to the anwers from Cadence,
 in conclusion, I think this function seems wrong.
 
 Please let me confirm once again:
 Did this function really work on your board?
 


Yup, if you see this driver, all transaction is being done using DMA
function. Its working as some of SOCFPGA users are using that code.


 I had to re-write this function to run on my board.
 


Can you share your code so we can check the differences. Its really
strange.


 
  #define DENALI_DATA_OFFSET_ADDRESS  0x10
 
 This is a bad name.
 I can't understand at all what this macro stands for.
 Besides, you only defined data register, not control register.
 This is weird.
 
 There exist two registers: control and data
 for indexed-addressing of Denali NAND controller.
 
 Denali document shows
 Table 8.1
 Register  | Offset Address
 --
 Control|0x0
 Data|0x10
 
 
 How about this?
 #define INDEX_CTRL_REG 0x0
 #define INDEX_DATA_REG0x10
 


I have no much objection when come to naming. FYI, I just pluck this
name from datasheet. I will changed that with file name change.


 And move definition from denali_nand.c to denal_nand.h.
 
 


Yup, actually waiting more comments from you before sending out next
revision. :)


 
  /* setups the HW to perform the data DMA */
  static void denali_setup_dma_sequence(int op)
  {
 
 Please rename denali_setup_dma_sequence
 to denali_setup_dma.
 
 Linux uses the latter.
 No reason to change it.
 


I can change that.


 
 /* Common DMA function */
 static uint32_t denali_dma_configuration(uint32_t ops, bool raw_xfer,
  uint32_t irq_mask, int oob_required)
 
 Fix indentaion, please.
 


I can fix that. Hmmm seems checkpatch dun catch this.

 
 
 It's denali.c in Linux -- why denali_nand.c here?



It seems all the existing U-Boot nand driver is using this naming
standard where platform_nand.
   
   Not all -- there's omap_gpmc.c, omap_elm.c, nomadik.c, ndfc.c, etc.
   
   A lot of them have the _nand.c suffix in Linux, too.  Personally, I
   think it's redundant.
  
  
  Sure, I can change to denali.c
 
 Agreed.
 
 
 
Why are you using raw I/O accessors?  The Linux driver doesn't do this.
   
   Add ioread32/iowrite32 to arch/arm/include/asm/io.h
   and use them?
   
  
  
  Changed all to use standard writel and readl.
 
 In my understanding, ioread32/iowrite32 is the same as
 readl/writel  at least memory mapped architectures such ARM.
 
 Because Linux Kernel' denali.c uses  ioread32/iowrite32,
 I thought using them is helpful for easy diffing.
 
 
 I've posted my feedback.
 I hope it is helpful for you.
 http://patchwork.ozlabs.org/patch/327943/
 

Great, I will patch them.
From the patch, I saw your DMA sequence code and the discrepancy. 
For the data portion, I spotted you set the bit 31:16.
But inside my datasheet, its marked as reserved.

Wonder the version of Denali controller I have is older?
Probably we can probe the Cadence then.
At same time, I will send out new patch to capture the fix before
forget.
Thanks

Chin Liang

 
 
 Best Regards
 Masahiro Yamada
 


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

Re: [U-Boot] [U-Boot PATCH v2 08/12] k2hk: add support for k2hk SOC and EVM

2014-03-07 Thread Andrianov, Vitaly

Hi Tom,

[snip]
 
  + fdt_high=0x\0 \
 
  Please don't do this, set it to the top of kernel low mem.
 
 
  The EVM may have up to 8GB of DDR and u-boot can see the first 2GB
  with physical address range 0x8000-0x.
  If we don't use the fdt_high environment variable, u-boot relocates
  the dtb to the end of that memory, which is outside of the lowmem.
 
[snip]

  But K2 lowmem VA starts from 0xc000 and has size ~760MB. That
  corresponds to the physical range 0x8000-0xaf80.
  That is why we have to use the fdt_high=0x environment
 variable.
 
  Have I missed something I u-boot memory configuration?
  Is there a way to tell u-boot to relocate fdt to the end lowmem?
 
 Yes, set fdt_high to 0xaf80 instead :)
 

I think there is a bug in the lmb_alloc_base() and this approach doesn't
work.

else if (lmbbase  max_addr) {
base = min(lmbbase + lmbsize, max_addr);
base = lmb_align_down(base - size, align);
} else

For boards that have DDR at the end of 32 bit address space the
(lmbbase + lmbsize) = 0 which is  max_addr.
So, base becomes 0, and moved to the end of DDR - size on the next line.

I tried a quick fix in the __lmb_alloc_base() and got the fdt relocated 
correctly.
As I'm not sure that is only one buggy place in the lmb.c I don't want to commit
the quick fix. Let's leave the fdt_high=0x in the Keystone2 for 
awhile  
and change it later when we fix the bug.

Thanks,
Vitaly

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

Re: [U-Boot] [U-Boot PATCH v2 08/12] k2hk: add support for k2hk SOC and EVM

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/07/2014 11:41 AM, Andrianov, Vitaly wrote:
 Hi Tom,
 
 [snip]

 + fdt_high=0x\0 \

 Please don't do this, set it to the top of kernel low mem.


 The EVM may have up to 8GB of DDR and u-boot can see the first 2GB
 with physical address range 0x8000-0x.
 If we don't use the fdt_high environment variable, u-boot relocates
 the dtb to the end of that memory, which is outside of the lowmem.

 [snip]
 
 But K2 lowmem VA starts from 0xc000 and has size ~760MB. That
 corresponds to the physical range 0x8000-0xaf80.
 That is why we have to use the fdt_high=0x environment
 variable.

 Have I missed something I u-boot memory configuration?
 Is there a way to tell u-boot to relocate fdt to the end lowmem?

 Yes, set fdt_high to 0xaf80 instead :)

 
 I think there is a bug in the lmb_alloc_base() and this approach doesn't
 work.
 
 else if (lmbbase  max_addr) {
   base = min(lmbbase + lmbsize, max_addr);
   base = lmb_align_down(base - size, align);
 } else
 
 For boards that have DDR at the end of 32 bit address space the
 (lmbbase + lmbsize) = 0 which is  max_addr.
 So, base becomes 0, and moved to the end of DDR - size on the next line.
 
 I tried a quick fix in the __lmb_alloc_base() and got the fdt relocated 
 correctly.
 As I'm not sure that is only one buggy place in the lmb.c I don't want to 
 commit
 the quick fix. Let's leave the fdt_high=0x in the Keystone2 for 
 awhile  
 and change it later when we fix the bug.

If you're committing to look at this later then yes.

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

iQIcBAEBAgAGBQJTGfjRAAoJENk4IS6UOR1WxBYQAKjH1cWlziYl74cR7FhPINWd
WEn7AtPKYLXs47D8dMYvshjrg9kBgjpy3VqDKf23t3yndBUugmznV5MdmSMlx2IQ
TuNg0ICqnXt/2NxclKwxtmznohIwx2t8gJ355UP9XzGrr17lf1+WglOvBolI0R0m
VjP3eBivHDlfwLHF3MWdLjmCjGn1sVDCng2JuZZIjfoqxGto2UsDllh1CQx2O9js
tOeAY+i5cHCag8b5+6jtujZ6GICwQ0vg2qB5XFXeOYAZWY+XTvlGgQCZ27RaspRF
pBHhlOH7iftUnKOTGt/HauEnB62TSfSPjan9ww48VA861fAkrpeANjtPz9uZQKwh
Hd/Ib0XOHrfKkReerF/C+R2vJjlYBfKeEFCvF+SuZApgIMX6am4gdHWiGgZq45/Q
YemR9Exj+KJ4MYZky/a8y2z8cowck+RsnpZozojFiPlNmuvXS+qXZste42nIYTRX
puZx4+xogoaLL4HHjOuKR6QlnCSQDvyxPvLPMNw5HbrZ3Eof0Uwxu2omnJpUvx2+
v/xl6gsqcxOZ07Mz7g3sGwsG5HWZPevFK8CZd8xDFQwj/DZo4pAJO7XFj4MZTgaM
Tg3bpsvQFugK9yU/F96Uoie0EYCpCsgGPu5moOSPYB4sl8OlkHj0Mw1oq3rpWF77
2bFm9XxAOL/awEM/X2l/
=n9Wd
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] lcd: cleanup unused functions

This patch removes following two functions:
- lcd_getbgcolor(...)
  not used somewhere outside lcd.c, internally we use now the global
  variable lcd_color_bg (was return value of function before)
- lcd_getfgcolor(...)
  not used in any place of u-boot

Signed-off-by: Hannes Petermaier oe5...@oevsv.at
---
 common/lcd.c  |   17 +
 include/lcd.h |2 --
 2 files changed, 1 insertion(+), 18 deletions(-)

diff --git a/common/lcd.c b/common/lcd.c
index aa81522..3f73541 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -110,7 +110,6 @@ static int lcd_init(void *lcdbase);
 
 static void *lcd_logo(void);
 
-static int lcd_getbgcolor(void);
 static void lcd_setfgcolor(int color);
 static void lcd_setbgcolor(int color);
 
@@ -454,7 +453,7 @@ void lcd_clear(void)
 #else
/* set framebuffer to background color */
memset((char *)lcd_base,
-   COLOR_MASK(lcd_getbgcolor()),
+   COLOR_MASK(lcd_color_bg),
lcd_line_length * panel_info.vl_row);
 #endif
/* Paint the logo and retrieve LCD base address */
@@ -563,20 +562,6 @@ static void lcd_setbgcolor(int color)
lcd_color_bg = color;
 }
 
-/*--*/
-
-int lcd_getfgcolor(void)
-{
-   return lcd_color_fg;
-}
-
-/*--*/
-
-static int lcd_getbgcolor(void)
-{
-   return lcd_color_bg;
-}
-
 //
 /* ** Chipset depending Bitmap / Logo stuff...  */
 //
diff --git a/include/lcd.h b/include/lcd.h
index d06d6f1..d1cb6b1 100644
--- a/include/lcd.h
+++ b/include/lcd.h
@@ -26,8 +26,6 @@ void lcd_enable(void);
 void lcd_setcolreg(ushort regno, ushort red, ushort green, ushort blue);
 void lcd_initcolregs(void);
 
-int lcd_getfgcolor(void);
-
 /* gunzip_bmp used if CONFIG_VIDEO_BMP_GZIP */
 struct bmp_image *gunzip_bmp(unsigned long addr, unsigned long *lenp,
 void **alloc_addr);
-- 
1.7.10.4

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

[U-Boot] [PATCH v2] Add support for 32-bit organized framebuffers

- Adds support for 32-bit organized framebuffers to the LCD-framework.

Signed-off-by: Hannes Petermaier oe5...@oevsv.at
Cc: ag...@denx.de
---
Changes for v2:
   - separated from 'function-cleanup' changes
---
 common/lcd.c  |   35 ---
 include/lcd.h |   17 -
 2 files changed, 48 insertions(+), 4 deletions(-)

diff --git a/common/lcd.c b/common/lcd.c
index 3f73541..e552340 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -94,7 +94,8 @@
 #if LCD_BPP == LCD_MONOCHROME
 # define COLOR_MASK(c) ((c)  | (c)  1 | (c)  2 | (c)  3 | \
 (c)  4 | (c)  5 | (c)  6 | (c)  7)
-#elif (LCD_BPP == LCD_COLOR8) || (LCD_BPP == LCD_COLOR16)
+#elif (LCD_BPP == LCD_COLOR8) || (LCD_BPP == LCD_COLOR16) || \
+   (LCD_BPP == LCD_COLOR32)
 # define COLOR_MASK(c) (c)
 #else
 # error Unsupported LCD BPP.
@@ -163,10 +164,20 @@ static void console_scrollup(void)
   CONSOLE_SIZE - CONSOLE_ROW_SIZE * rows);
 
/* Clear the last rows */
+#if (LCD_BPP != LCD_COLOR32)
memset(lcd_console_address + CONSOLE_SIZE - CONSOLE_ROW_SIZE * rows,
COLOR_MASK(lcd_color_bg),
CONSOLE_ROW_SIZE * rows);
-
+#else
+   u32 *ppix = lcd_console_address +
+   CONSOLE_SIZE - CONSOLE_ROW_SIZE * rows;
+   u32 i;
+   for (i = 0;
+   i  (CONSOLE_ROW_SIZE * rows) / NBYTES(panel_info.vl_bpix);
+   i++) {
+   *ppix++ = COLOR_MASK(lcd_color_bg);
+   }
+#endif
lcd_sync();
console_row -= rows;
 }
@@ -284,13 +295,15 @@ static void lcd_drawchars(ushort x, ushort y, uchar *str, 
int count)
ushort off  = x * (1  LCD_BPP) % 8;
 #endif
 
-   dest = (uchar *)(lcd_base + y * lcd_line_length + x * (1  LCD_BPP) / 
8);
+   dest = (uchar *)(lcd_base + y * lcd_line_length + x * NBITS(LCD_BPP)/8);
 
for (row = 0; row  VIDEO_FONT_HEIGHT; ++row, dest += lcd_line_length) {
uchar *s = str;
int i;
 #if LCD_BPP == LCD_COLOR16
ushort *d = (ushort *)dest;
+#elif LCD_BPP == LCD_COLOR32
+   u32 *d = (u32 *)dest;
 #else
uchar *d = dest;
 #endif
@@ -323,6 +336,12 @@ static void lcd_drawchars(ushort x, ushort y, uchar *str, 
int count)
lcd_color_fg : lcd_color_bg;
bits = 1;
}
+#elif LCD_BPP == LCD_COLOR32
+   for (c = 0; c  8; ++c) {
+   *d++ = (bits  0x80) ?
+   lcd_color_fg : lcd_color_bg;
+   bits = 1;
+   }
 #endif
}
 #if LCD_BPP == LCD_MONOCHROME
@@ -452,9 +471,19 @@ void lcd_clear(void)
test_pattern();
 #else
/* set framebuffer to background color */
+#if (LCD_BPP != LCD_COLOR32)
memset((char *)lcd_base,
COLOR_MASK(lcd_color_bg),
lcd_line_length * panel_info.vl_row);
+#else
+   u32 *ppix = lcd_base;
+   u32 i;
+   for (i = 0;
+  i  (lcd_line_length * panel_info.vl_row)/NBYTES(panel_info.vl_bpix);
+  i++) {
+   *ppix++ = COLOR_MASK(lcd_color_bg);
+   }
+#endif
 #endif
/* Paint the logo and retrieve LCD base address */
debug([LCD] Drawing the logo...\n);
diff --git a/include/lcd.h b/include/lcd.h
index d1cb6b1..df707f6 100644
--- a/include/lcd.h
+++ b/include/lcd.h
@@ -332,7 +332,7 @@ int lcd_dt_simplefb_enable_existing_node(void *blob);
 #define LCD_COLOR4 2
 #define LCD_COLOR8 3
 #define LCD_COLOR164
-
+#define LCD_COLOR325
 /*--*/
 #if defined(CONFIG_LCD_INFO_BELOW_LOGO)
 # define LCD_INFO_X0
@@ -383,6 +383,21 @@ int lcd_dt_simplefb_enable_existing_node(void *blob);
 # define CONSOLE_COLOR_GREY14
 # define CONSOLE_COLOR_WHITE   15  /* Must remain last / highest   */
 
+#elif LCD_BPP == LCD_COLOR32
+/*
+ * 32bpp color definitions
+ */
+# define CONSOLE_COLOR_RED 0x00ff
+# define CONSOLE_COLOR_GREEN   0xff00
+# define CONSOLE_COLOR_YELLOW  0x0000
+# define CONSOLE_COLOR_BLUE0x00ff
+# define CONSOLE_COLOR_MAGENTA 0x00ff00ff
+# define CONSOLE_COLOR_CYAN0x
+# define CONSOLE_COLOR_GREY0x00aa
+# define CONSOLE_COLOR_BLACK   0x
+# define CONSOLE_COLOR_WHITE   0x00ff  /* Must remain last / highest*/
+# define NBYTES(bit_code)  (NBITS(bit_code)  3)
+
 #else
 
 /*
-- 
1.7.9.5

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

[U-Boot] [PATCH] board/BuR/kwb: fix usage of 'i2c_set_bus_speed'

- fix: return-value of 'i2c_set_bus_speed' was interpreted wrong

Signed-off-by: Hannes Petermaier oe5...@oevsv.at
---
 board/BuR/kwb/board.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/board/BuR/kwb/board.c b/board/BuR/kwb/board.c
index 8aa16bc..8fb5e68 100644
--- a/board/BuR/kwb/board.c
+++ b/board/BuR/kwb/board.c
@@ -120,7 +120,7 @@ void am33xx_spl_board_init(void)
 
/* power-ON  3V3 via Resetcontroller */
oldspeed = i2c_get_bus_speed();
-   if (0 != i2c_set_bus_speed(CONFIG_SYS_OMAP24_I2C_SPEED_PSOC)) {
+   if (0 = i2c_set_bus_speed(CONFIG_SYS_OMAP24_I2C_SPEED_PSOC)) {
buf = RSTCTRL_FORCE_PWR_NEN;
i2c_write(RSTCTRL_ADDR, RSTCTRL_CTRLREG, 1,
  (uint8_t *)buf, sizeof(buf));
@@ -221,7 +221,7 @@ int board_late_init(void)
   TPS65217_WLEDCTRL1, 0x09, 0xFF);
/* write bootinfo into scratchregister of resetcontroller */
oldspeed = i2c_get_bus_speed();
-   if (0 != i2c_set_bus_speed(CONFIG_SYS_OMAP24_I2C_SPEED_PSOC)) {
+   if (0 = i2c_set_bus_speed(CONFIG_SYS_OMAP24_I2C_SPEED_PSOC)) {
i2c_write(RSTCTRL_ADDR, RSTCTRL_SCRATCHREG, 1,
  (uint8_t *)buf, sizeof(buf));
i2c_set_bus_speed(oldspeed);
-- 
1.7.10.4

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

Re: [U-Boot] [linux-sunxi] [PATCH v3 0/4] uboot sata support for sunxi platform

2014-03-07 Thread Ezaul Zillmer

Hi Ian .. 

You would have a repository with these updates where I could play with git, 
compile and test my cubieboard2 using kernel 3.14.rc5 

I'm waiting! to test your boot! 
thank you
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH][v4] powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS

On 03/07/2014 05:23 AM, Aneesh Bansal wrote:
 Changes:
 1. L2 cache is being invalidated by Boot ROM code for e6500 core.
So removing the invalidation from start.S
 2. Clear the LAW and corresponding configuration for CPC. Boot ROM
code uses it as hosekeeping area.
 3. For Secure boot, CPC is configured as SRAM and used as house
keeping area. This configuration is to be disabled once in uboot.
Earlier this disabling of CPC as SRAM was happening in cpu_init_r.
As a result cache invalidation function was getting skipped in
case CPC is configured as SRAM.This was causing random crashes.
 
 Signed-off-by: Aneesh Bansal aneesh.ban...@freescale.com
 ---
  README |  4 
  arch/powerpc/cpu/mpc85xx/cpu_init.c| 27 ++-
  arch/powerpc/cpu/mpc85xx/start.S   |  3 ++-
  arch/powerpc/include/asm/fsl_secure_boot.h |  6 ++
  boards.cfg |  1 +
  5 files changed, 35 insertions(+), 6 deletions(-)
 
 Changes from v3:
 Renamed the macro to indicate CPC configured as SRAM at U-boot entry to
 CONFIG_SYS_CPC_SRAM 

Aneesh,

I understand you are trying to address the comment about when CPC needs to be
disabled before initializing as normal CPC. But introducing CONFIG_SYS_CPC_SRAM
seems even more confusing. Let's take one step back.

CPC as SRAM can be used for many reasons. There is only one reason we should
keep it as SRAM, i.e. u-boot is indeed using SRAM as its final destination. For
all other usages, we can safely reconfigure it as normal CPC after u-boot
relocates itself into DDR. If u-boot's final destination is SRAM, it is a
RAMBOOT. Can we use this condition to deal with CPC?

Do you see the need to disable CPC before relocation? You are doing so in this
patch. Does the temporary LAW or address conflict with u-boot?

York


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

Re: [U-Boot] [PATCH][v4] powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS

On Fri, 2014-03-07 at 18:53 +0530, Aneesh Bansal wrote:
 Changes:
 1. L2 cache is being invalidated by Boot ROM code for e6500 core.
So removing the invalidation from start.S
 2. Clear the LAW and corresponding configuration for CPC. Boot ROM
code uses it as hosekeeping area.
 3. For Secure boot, CPC is configured as SRAM and used as house
keeping area. This configuration is to be disabled once in uboot.
Earlier this disabling of CPC as SRAM was happening in cpu_init_r.
As a result cache invalidation function was getting skipped in
case CPC is configured as SRAM.This was causing random crashes.
 
 Signed-off-by: Aneesh Bansal aneesh.ban...@freescale.com
 ---
  README |  4 
  arch/powerpc/cpu/mpc85xx/cpu_init.c| 27 ++-
  arch/powerpc/cpu/mpc85xx/start.S   |  3 ++-
  arch/powerpc/include/asm/fsl_secure_boot.h |  6 ++
  boards.cfg |  1 +
  5 files changed, 35 insertions(+), 6 deletions(-)
 
 Changes from v3:
 Renamed the macro to indicate CPC configured as SRAM at U-boot entry to
 CONFIG_SYS_CPC_SRAM 
 
 diff --git a/README b/README
 index 216f0c7..e26833d 100644
 --- a/README
 +++ b/README
 @@ -427,6 +427,10 @@ The following options need to be configured:
   In this mode, a single differential clock is used to supply
   clocks to the sysclock, ddrclock and usbclock.
  
 + CONFIG_SYS_CPC_SRAM
 + This CONFIG is defined when the SPC is configured as SRAM at the
 + time of U-boot entry.

SPC?

-Scott


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

Re: [U-Boot] [PATCH][v4] powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS

On Fri, 2014-03-07 at 10:30 -0800, York Sun wrote:
 On 03/07/2014 05:23 AM, Aneesh Bansal wrote:
  Changes:
  1. L2 cache is being invalidated by Boot ROM code for e6500 core.
 So removing the invalidation from start.S
  2. Clear the LAW and corresponding configuration for CPC. Boot ROM
 code uses it as hosekeeping area.
  3. For Secure boot, CPC is configured as SRAM and used as house
 keeping area. This configuration is to be disabled once in uboot.
 Earlier this disabling of CPC as SRAM was happening in cpu_init_r.
 As a result cache invalidation function was getting skipped in
 case CPC is configured as SRAM.This was causing random crashes.
  
  Signed-off-by: Aneesh Bansal aneesh.ban...@freescale.com
  ---
   README |  4 
   arch/powerpc/cpu/mpc85xx/cpu_init.c| 27 ++-
   arch/powerpc/cpu/mpc85xx/start.S   |  3 ++-
   arch/powerpc/include/asm/fsl_secure_boot.h |  6 ++
   boards.cfg |  1 +
   5 files changed, 35 insertions(+), 6 deletions(-)
  
  Changes from v3:
  Renamed the macro to indicate CPC configured as SRAM at U-boot entry to
  CONFIG_SYS_CPC_SRAM 
 
 Aneesh,
 
 I understand you are trying to address the comment about when CPC needs to be
 disabled before initializing as normal CPC. But introducing 
 CONFIG_SYS_CPC_SRAM
 seems even more confusing. Let's take one step back.
 
 CPC as SRAM can be used for many reasons. There is only one reason we should
 keep it as SRAM, i.e. u-boot is indeed using SRAM as its final destination. 
 For
 all other usages, we can safely reconfigure it as normal CPC after u-boot
 relocates itself into DDR. If u-boot's final destination is SRAM, it is a
 RAMBOOT. Can we use this condition to deal with CPC?

Even if CPC is the final destination, shouldn't RAMBOOT imply that DDR
has been initialized?

-Scott


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

Re: [U-Boot] A proposal/hack for an efficient USB DFU for linux based boards

2014-03-07 Thread Krishna Pattabiraman

Hi,

Thanks for your time,

Please find following comments:

1. Current solution (u-boot):
- It is possible to specify your own dfu_alt_info environment
variable when you call dfu command.

2. Speed improvement - section Making it faster from:
http://codelectron.wordpress.com/2014/02/28/flexible-firmware-upgrade/

- I've noticed that you are referring to following dfu-util version:
dfu-util - (C) 2007 by Openmoko Inc.

It seems to be a bit old one.

I just used the content from my old documentation, But im referring to
current implementation.

The newest GIT repo can be found at:
git://gitorious.org/dfu-util/dfu-util.git

I'm referring to following SHA1 (master branch):
bda43a52a6c5e9dcd159236553b0d5c511616e77

The code at dfuload_do_dnload() function is already rewritten to only
wait:
milli_sleep(dst.bwPollTimeout);

which is correct, since non-zero values are explicitly specified in
u-boot (when e.g. target expects that eMMC data will be written).

It seems that the proposed improvement is already implemented.

I dont think its implemented, you can refer here, its the block of code
what I am referring to,

https://gitorious.org/dfu-util/dfu-util/source/bda43a52a6c5e9dcd159236553b0d5c511616e77:src/dfu_load.c#L123
https://gitorious.org/dfu-util/dfu-util/source/bda43a52a6c5e9dcd159236553b0d5c511616e77:src/dfu_load.c#L137

As a side note:
To improve transmission speed we were even trying to increase the EP0
packet size on HOST machine. Unfortunately it has some limitations
(4 KiB if I'm not wrong).

Yes I do think so about the limitation, as a standard EP0 should support
atleast 64 bytes and DFU is based on that.

Anyway, I'm open for potential DFU transmission speed improvements.

3. Flexibility improvement - section Making it flexible

The idea of adding headers seems appealing - but there are as usual
some corner cases:

- Backward compatibility - dfu-util and dfu use number of alt settings
to chose the memory region to be written. That is why you observe a
lot of alt=X when you type dfu-util -l. We would need some extra
switch in the dfu-util to support yours header based approach.

- In u-boot we would like to have some degree of control of where and if
we flash data. I personally like to specify beforehand (in envs) what
parts of memory are available for flashing.

I developed it keeping in mind a situation in field where there can be a
complete change in memory organisation.

- Some more complicated schemes shall be considered as well. I've got
some pending patches to support eMMC's bootparts flashing via DFU.

- Also the header itself only assumes NAND being the backing memory. But
we now also alter content of eMMC and RAM with DFU. This is missing.

- The information provided by headers is already stored at
dfu_alt_info environment variable. It is also used by other gadgets.

It was an example code based on what I had implemented some time back. It
was based on nand flash, but the idea will be the same for any other type.

I just wanted to share the idea of a different type of implementation of
USB DFU.

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

Re: [U-Boot] [PATCH 1/3] powerpc/p1010rdb: SECURE BOOT- define CONFIG_SYS_RAMBOOT for NAND boot

On Thu, 2014-03-06 at 03:24 -0600, Bansal Aneesh-B39320 wrote:
  -Original Message-
  From: Wood Scott-B07421
  Sent: Wednesday, March 05, 2014 11:30 PM
  To: Bansal Aneesh-B39320
  Cc: Sun York-R58495; Wolfgang Denk; u-boot@lists.denx.de; Gupta
  Ruchika-R66431
  Subject: Re: [U-Boot] [PATCH 1/3] powerpc/p1010rdb: SECURE BOOT-
  define CONFIG_SYS_RAMBOOT for NAND boot

  On Tue, 2014-03-04 at 23:30 -0600, Bansal Aneesh-B39320 wrote:
   Yes, in case of secure boot from NAND, the DRAM is initialized by
  the
   BootROM and complete u-boot image is copied from NAND to DRAM by the
  BootROM.
   So, it should be called RAMBOOT.

  DRAM or SRAM?  Having ROM initialize DDR is a bit scary.

  -Scott

 It can be either DDR or SRAM. It is not hardcoded in BootROM to initialize 
 DDR.
 This depends on the config words (CF_WORDS) in the CF_HEADER.
 The Boot ROM code parses the config words and programs the addresses with 
 data values
 accordingly. The user may opt to initialize DDR and get the image copied onto 
 DDR or 
 configure CPC as SRAM and get the Image copied onto SRAM.
 On 1010,

P1010?  LS1010?  Something else?

 the CPC size is not big enough to accommodate the U-boot image.
 So, currently the CF_WORDS are for DDR to be initialized and copy the image 
 on DDR.

Generally if SPD is present, it should be used to init DDR rather than
using hardcoded values.  If U-Boot doesn't fit in SRAM, you can use SPL
instead of hardcoded init.

-Scott

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

Re: [U-Boot] [PATCH][v4] powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS

On 03/07/2014 10:54 AM, Scott Wood wrote:
 On Fri, 2014-03-07 at 10:30 -0800, York Sun wrote:
 On 03/07/2014 05:23 AM, Aneesh Bansal wrote:
 Changes:
 1. L2 cache is being invalidated by Boot ROM code for e6500 core.
So removing the invalidation from start.S
 2. Clear the LAW and corresponding configuration for CPC. Boot ROM
code uses it as hosekeeping area.
 3. For Secure boot, CPC is configured as SRAM and used as house
keeping area. This configuration is to be disabled once in uboot.
Earlier this disabling of CPC as SRAM was happening in cpu_init_r.
As a result cache invalidation function was getting skipped in
case CPC is configured as SRAM.This was causing random crashes.

 Signed-off-by: Aneesh Bansal aneesh.ban...@freescale.com
 ---
  README |  4 
  arch/powerpc/cpu/mpc85xx/cpu_init.c| 27 ++-
  arch/powerpc/cpu/mpc85xx/start.S   |  3 ++-
  arch/powerpc/include/asm/fsl_secure_boot.h |  6 ++
  boards.cfg |  1 +
  5 files changed, 35 insertions(+), 6 deletions(-)

 Changes from v3:
 Renamed the macro to indicate CPC configured as SRAM at U-boot entry to
 CONFIG_SYS_CPC_SRAM 

 Aneesh,

 I understand you are trying to address the comment about when CPC needs to be
 disabled before initializing as normal CPC. But introducing 
 CONFIG_SYS_CPC_SRAM
 seems even more confusing. Let's take one step back.

 CPC as SRAM can be used for many reasons. There is only one reason we should
 keep it as SRAM, i.e. u-boot is indeed using SRAM as its final destination. 
 For
 all other usages, we can safely reconfigure it as normal CPC after u-boot
 relocates itself into DDR. If u-boot's final destination is SRAM, it is a
 RAMBOOT. Can we use this condition to deal with CPC?
 
 Even if CPC is the final destination, shouldn't RAMBOOT imply that DDR
 has been initialized?

No. RAMBOOT implies u-boot shouldn't initialize RAM. There may be cases where
u-boot needs to run in SRAM without DDR. It doesn't matter if the RAM is SRAM or
DRAM.

York

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

Re: [U-Boot] [PATCH][v4] powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS

On Fri, 2014-03-07 at 10:58 -0800, York Sun wrote:
 On 03/07/2014 10:54 AM, Scott Wood wrote:
  On Fri, 2014-03-07 at 10:30 -0800, York Sun wrote:
  On 03/07/2014 05:23 AM, Aneesh Bansal wrote:
  Changes:
  1. L2 cache is being invalidated by Boot ROM code for e6500 core.
 So removing the invalidation from start.S
  2. Clear the LAW and corresponding configuration for CPC. Boot ROM
 code uses it as hosekeeping area.
  3. For Secure boot, CPC is configured as SRAM and used as house
 keeping area. This configuration is to be disabled once in uboot.
 Earlier this disabling of CPC as SRAM was happening in cpu_init_r.
 As a result cache invalidation function was getting skipped in
 case CPC is configured as SRAM.This was causing random crashes.
 
  Signed-off-by: Aneesh Bansal aneesh.ban...@freescale.com
  ---
   README |  4 
   arch/powerpc/cpu/mpc85xx/cpu_init.c| 27 
  ++-
   arch/powerpc/cpu/mpc85xx/start.S   |  3 ++-
   arch/powerpc/include/asm/fsl_secure_boot.h |  6 ++
   boards.cfg |  1 +
   5 files changed, 35 insertions(+), 6 deletions(-)
 
  Changes from v3:
  Renamed the macro to indicate CPC configured as SRAM at U-boot entry to
  CONFIG_SYS_CPC_SRAM 
 
  Aneesh,
 
  I understand you are trying to address the comment about when CPC needs to 
  be
  disabled before initializing as normal CPC. But introducing 
  CONFIG_SYS_CPC_SRAM
  seems even more confusing. Let's take one step back.
 
  CPC as SRAM can be used for many reasons. There is only one reason we 
  should
  keep it as SRAM, i.e. u-boot is indeed using SRAM as its final 
  destination. For
  all other usages, we can safely reconfigure it as normal CPC after u-boot
  relocates itself into DDR. If u-boot's final destination is SRAM, it is a
  RAMBOOT. Can we use this condition to deal with CPC?
  
  Even if CPC is the final destination, shouldn't RAMBOOT imply that DDR
  has been initialized?
 
 No. RAMBOOT implies u-boot shouldn't initialize RAM. There may be cases where
 u-boot needs to run in SRAM without DDR. It doesn't matter if the RAM is SRAM 
 or
 DRAM.

There are some situations where we run U-Boot out of SRAM without
relocating to DDR, but I can't think of a situation where we wouldn't
want to use DDR at all (e.g. for loading an OS to).

-Scott


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

Re: [U-Boot] [PATCH 1/3] powerpc/p1010rdb: SECURE BOOT- define CONFIG_SYS_RAMBOOT for NAND boot

On 03/07/2014 10:57 AM, Scott Wood wrote:
 On Thu, 2014-03-06 at 03:24 -0600, Bansal Aneesh-B39320 wrote:
 -Original Message-
 From: Wood Scott-B07421
 Sent: Wednesday, March 05, 2014 11:30 PM
 To: Bansal Aneesh-B39320
 Cc: Sun York-R58495; Wolfgang Denk; u-boot@lists.denx.de; Gupta
 Ruchika-R66431
 Subject: Re: [U-Boot] [PATCH 1/3] powerpc/p1010rdb: SECURE BOOT-
 define CONFIG_SYS_RAMBOOT for NAND boot

 On Tue, 2014-03-04 at 23:30 -0600, Bansal Aneesh-B39320 wrote:
 Yes, in case of secure boot from NAND, the DRAM is initialized by
 the
 BootROM and complete u-boot image is copied from NAND to DRAM by the
 BootROM.
 So, it should be called RAMBOOT.

 DRAM or SRAM?  Having ROM initialize DDR is a bit scary.

 -Scott

 It can be either DDR or SRAM. It is not hardcoded in BootROM to initialize 
 DDR.
 This depends on the config words (CF_WORDS) in the CF_HEADER.
 The Boot ROM code parses the config words and programs the addresses with 
 data values
 accordingly. The user may opt to initialize DDR and get the image copied 
 onto DDR or 
 configure CPC as SRAM and get the Image copied onto SRAM.
 On 1010,

 P1010?  LS1010?  Something else?

 the CPC size is not big enough to accommodate the U-boot image.
 So, currently the CF_WORDS are for DDR to be initialized and copy the image 
 on DDR.

 Generally if SPD is present, it should be used to init DDR rather than
 using hardcoded values.  If U-Boot doesn't fit in SRAM, you can use SPL
 instead of hardcoded init.

I agree with Scott on this point. Using hardcoded values totally skip DDR
driver. You don't only lose the flexibility of various speeds, you also skip all
workarounds implemented in DDR driver.

York

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

Re: [U-Boot] [PATCH][v4] powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS

On 03/07/2014 11:00 AM, Scott Wood wrote:
 On Fri, 2014-03-07 at 10:58 -0800, York Sun wrote:
 On 03/07/2014 10:54 AM, Scott Wood wrote:
 On Fri, 2014-03-07 at 10:30 -0800, York Sun wrote:
 On 03/07/2014 05:23 AM, Aneesh Bansal wrote:
 Changes:
 1. L2 cache is being invalidated by Boot ROM code for e6500 core.
So removing the invalidation from start.S
 2. Clear the LAW and corresponding configuration for CPC. Boot ROM
code uses it as hosekeeping area.
 3. For Secure boot, CPC is configured as SRAM and used as house
keeping area. This configuration is to be disabled once in uboot.
Earlier this disabling of CPC as SRAM was happening in cpu_init_r.
As a result cache invalidation function was getting skipped in
case CPC is configured as SRAM.This was causing random crashes.

 Signed-off-by: Aneesh Bansal aneesh.ban...@freescale.com
 ---
  README |  4 
  arch/powerpc/cpu/mpc85xx/cpu_init.c| 27 
 ++-
  arch/powerpc/cpu/mpc85xx/start.S   |  3 ++-
  arch/powerpc/include/asm/fsl_secure_boot.h |  6 ++
  boards.cfg |  1 +
  5 files changed, 35 insertions(+), 6 deletions(-)

 Changes from v3:
 Renamed the macro to indicate CPC configured as SRAM at U-boot entry to
 CONFIG_SYS_CPC_SRAM 

 Aneesh,

 I understand you are trying to address the comment about when CPC needs to 
 be
 disabled before initializing as normal CPC. But introducing 
 CONFIG_SYS_CPC_SRAM
 seems even more confusing. Let's take one step back.

 CPC as SRAM can be used for many reasons. There is only one reason we 
 should
 keep it as SRAM, i.e. u-boot is indeed using SRAM as its final 
 destination. For
 all other usages, we can safely reconfigure it as normal CPC after u-boot
 relocates itself into DDR. If u-boot's final destination is SRAM, it is a
 RAMBOOT. Can we use this condition to deal with CPC?

 Even if CPC is the final destination, shouldn't RAMBOOT imply that DDR
 has been initialized?

 No. RAMBOOT implies u-boot shouldn't initialize RAM. There may be cases where
 u-boot needs to run in SRAM without DDR. It doesn't matter if the RAM is 
 SRAM or
 DRAM.
 
 There are some situations where we run U-Boot out of SRAM without
 relocating to DDR, but I can't think of a situation where we wouldn't
 want to use DDR at all (e.g. for loading an OS to).
 

I generally agree with you. Loading OS needs more RAM.

I am trying to simplify the condition to reinitialize CPC. My point is only one
situation requires the CPC to act as SRAM. We can brainstorm how useful it is.
For example, as a recovery method if using JTAG tool to enable CPC as SRAM and
to load u-boot into it, one can skip the steps to initialize DDR to run an
full-feature u-boot and reflash the board.

York


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

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

On 02/28/2014 12:48 AM, Prabhakar Kushwaha wrote:
 With the default value of MDIO_CLK_DIV generatee MDC is too high and It is
 violating the IEEE specs much higher than 2.5Mhz.
 
 Although there is errata(A-006260) for EMI2(MDIO2), but same errata is
 been hit on EMI1(MDIO1). unfortunately this errata never hit on B4 rev1.
 So reduced the MDIO_CLK_DIV value.
 

Please fix the typo and some grammar error in the commit message.
What is about B4 Rev 1? We support rev 2 and later in this u-boot.

York

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

Re: [U-Boot] [PATCH][v3] board/t104xrdb: Add support of CPLD

On 02/27/2014 06:22 PM, Prabhakar Kushwaha wrote:
 T1040RDB and T1042RDB_PI has CPLD. Here CPLD controls board mux/features.
 
 This support of CPLD includes
  - files and register defintion
  - Commands to swtich alternate bank and default bank
 
 Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
 ---
 Changes for v2:
   - Updated the cpld command
 Changes for v3:
   - fix typo 
 
snip

 +U_BOOT_CMD(
 + cpld, CONFIG_SYS_MAXARGS, 1, do_cpld,
 + Reset the board or alternate bank,
 + reset - hard reset to default bank\n
 + cpld_cmd reset altbank - reset to alternate bank\n
 +#ifdef DEBUG
 + cpld_cmd dump - display the CPLD registers\n
 +#endif

More to fix. Please keep the command consistent. I think you want to use cpld,
instead of cpld_cmd.

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

Re: [U-Boot] [PATCH v4 2/2] ventana: Add Gateworks Ventana family support

2014-03-07 Thread Tim Harvey

On Wed, Mar 5, 2014 at 3:22 AM, Stefano Babic sba...@denx.de wrote:
 Hi Tim,

 On 05/03/2014 12:06, Stefano Babic wrote:
 On 13/02/2014 08:48, Tim Harvey wrote:
 Gateworks Ventana is a product family based on the i.MX6.  This
 patch adds support for all boards in the Ventana family. Where
 possible, data from the boards EEPROM is used to determine various
 details about the board at runtime.

 Signed-off-by: Tim Harvey thar...@gateworks.com
 Cc: Stefano Babic sba...@denx.de
 ---

 Applied to u-boot-imx, thanks !

 I merged but not yet pushed to the server. I have found an issue:
 gwventanaq cannot be compiled. In fact, the combination quad + 512MB RAM
 is not covered in /gw_ventana.cfg:

 /home/stefano/Projects/imx/u-boot-imx/board/gateworks/gw_ventana/gw_ventana.cfg:40:4:
 error: #error Unsupported CPU/Memory configuration


 Can you fix and resubmit ? Thanks !

Stefano,

Sorry about that - yes I realized that issue as well a few days back.
I posted a v5 patch yesterday.  Let me know if there is anything else
needed.

Thanks,

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

Re: [U-Boot] [U-Boot PATCH v2 08/12] k2hk: add support for k2hk SOC and EVM

2014-03-07 Thread Murali Karicheri


[snip]

+Build instructions:
+===
+
+To build u-boot.bin
+  make k2hk_evm_config
+  make u-boot-spi.gph
+
+To build u-boot-spi.gph
+  make k2hk_evm_config
+  make u-boot-spi.gph

We need to use CONFIG_SPL_TARGET so that make all just works.


I am assuming we need to do

#define CONFIG_SPL_TARGET  u-boot-spi.gph

and then

./MAKEALL -a arm

 will build this image as well. Is that right?

Murali



+   if (err  0)
+   printf(error deleting 
linux,initrd-start\n);

Here and elsewhere, puts when we aren't using format chars.


diff --git a/boards.cfg b/boards.cfg
index a8336cc..1690315 100644
--- a/boards.cfg
+++ b/boards.cfg

Please make sure that the entry is correctly sorted, see the top of
boards.cfg.


+++ b/include/configs/k2hk_evm.h
@@ -0,0 +1,221 @@
+/*
+ * Configuration header file for TI's k2hk-evm
+ *
+ * (C) Copyright 2012-2014
+ * Texas Instruments Incorporated, www.ti.com
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#ifndef __CONFIG_H

Please use __CONFIG_K2HK_EVM_H


+/* Platform type */
+#define CONFIG_SOC_K2HK
+#define CONFIG_K2HK_EVM

Make sure we use these.


+
+/* U-Boot Build Configuration */
+#define CONFIG_SKIP_LOWLEVEL_INIT  /* U-Boot is a 2nd stage loader */

So there's a level before SPL that is doing a certain amount of init we
don't want to re-do?


+#define CONFIG_SYS_DCACHE_OFF

Really?


+#define CONFIG_SYS_MALLOC_LEN  (1024  10)  /* 1 MiB */

This is pretty small, especially since we care about UBI.


+#define CONFIG_SYS_MEMTEST_START   CONFIG_SYS_SDRAM_BASE
+#define CONFIG_SYS_MEMTEST_END (CONFIG_SYS_SDRAM_BASE + 32  20)

Please see doc/README.memory-test


+/* SPL SPI Loader Configuration */
+#define CONFIG_SPL_TEXT_BASE   0x0c20
+#define CONFIG_SPL_PAD_TO  65536
+#define CONFIG_SPL_MAX_SIZE(CONFIG_SPL_PAD_TO - 8)

Please explain this a bit more, esp since SPL_PAD_TO should take into
account the header size already...


+#define CONFIG_SPL_BSS_START_ADDR  (CONFIG_SPL_TEXT_BASE + \
+CONFIG_SPL_MAX_SIZE)
+#define CONFIG_SPL_BSS_MAX_SIZE(32 * 1024)

Do we really want SPL BSS in early ram (I don't want to get the name of
the type wrong) rather than DDR?


+#define CONFIG_SYS_SPL_MALLOC_START(CONFIG_SPL_BSS_START_ADDR +\
+CONFIG_SPL_BSS_MAX_SIZE)
+#define CONFIG_SYS_SPL_MALLOC_SIZE (32 * 1024)

Same.


+#define CONFIG_SYS_BAUDRATE_TABLE  { 9600, 19200, 38400, 57600, 115200 }

Please use the default table.


+#define PART_BOOT  1024k(bootloader)ro,
+#define PART_PARAMS512k(params)ro,
+#define PART_UBI   -(ubifs)
+#define MTDPARTS_DEFAULT   mtdparts=davinci_nand.0:\
+   PART_BOOT PART_PARAMS PART_UBI

Please just set these outright.


+/* U-Boot command configuration */
+#include config_cmd_default.h
+#undef CONFIG_CMD_BDI

Why?


+#undef CONFIG_CMD_FLASH

Shouldn't be needed.


+#undef CONFIG_CMD_FPGA
+#undef CONFIG_CMD_SETGETDCR

Same.


+#define CONFIG_SYS_PROMPT_HUSH_PS2  

Not needed.


+   fdt_high=0x\0   \

Please don't do this, set it to the top of kernel low mem.


+   mtdparts=mtdparts=davinci_nand.0:   \
+   1024k(bootloader)ro,512k(params)ro,522752k(ubifs)\0

Now you're not using the mtdparts you define, this shouldn't be needed.


+/* Linux interfacing */
+#define CONFIG_CMDLINE_TAG
+#define CONFIG_SETUP_MEMORY_TAGS

OF/FDT things should be down here.


+#define LINUX_BOOT_PARAM_ADDR  (CONFIG_SYS_SDRAM_BASE + 0x100)

Just use this in the code.

Thanks!



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

Re: [U-Boot] [U-Boot PATCH v2 08/12] k2hk: add support for k2hk SOC and EVM

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/07/2014 04:21 PM, Murali Karicheri wrote:
 [snip]
 +Build instructions:
 +===
 +
 +To build u-boot.bin
 +  make k2hk_evm_config
 +  make u-boot-spi.gph
 +
 +To build u-boot-spi.gph
 +  make k2hk_evm_config
 +  make u-boot-spi.gph
 We need to use CONFIG_SPL_TARGET so that make all just works.
 
 I am assuming we need to do
 
 #define CONFIG_SPL_TARGET  u-boot-spi.gph
 
 and then
 
 ./MAKEALL -a arm
 
  will build this image as well. Is that right?

Yes.

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

iQIcBAEBAgAGBQJTGjnAAAoJENk4IS6UOR1WJyIQAK6bDPHLGoVdi2v+1jktrQ/X
H+QTdFvokX9j4gQim7IOIhWvv106N7oeIX7QrCeNieEDPfav1TDMx9vu40DmIiDc
o3REaoCzGJ7Vo8kdNIXKwjV7y4tUOjB1q+2b9iqf/p4gJ/OjmQNcbioG9APCIeme
cfVZeypANQczMzUfXPGTrZX5GkVOYMFbtkK+pXXckD6XuROWc1CITDXKPjOh1qSt
HUQhJA5JtiR72rQvjWXXDsmuGhcYmmSXUQpml/16bBNhb4zxsZxnPB6skv11f0gr
kKevhfYREiqAIUmHR888NYB8+PyGsXWoEScYUmzzrFSrZmNH+aUu0gy0/NRaPidg
o3dUKun654SbzOXic/Gt/VzFt29ioMmFZAXDHtMwXM+V7V//mhfeQdCDnBgC6ty5
cUtSHsaFmWUuOR3E9IKoeP0Orplf6A8U+wy6swIwmKYPzlEHtI7IL0tweHo/KUyV
CYPPBICjJdPconYAN5cV1rQuem+VeBTKTNwtUdXuy9iYk1kwxM3aLi562DVUHBOa
oWBi2Aynar4ofFvRqNMYMynJM/ASjs9/nny5jFcxpcvrdzEDlPhcU61mpqEMyBWW
9iJyVN5UV5gJEWf9pofVGdokXl9yZ1YPwjLQF6+KZQwY6qeZhD614yx0MnE9553X
7VOJdxzoPPRazEx3azaB
=25vk
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] fsl_i2c: Add write-then-read transaction interface for I2C slave

On 03/03/2014 12:58 AM, Shaveta Leekha wrote:
 Most of the I2C slaves support accesses in the typical style
 viz.read/write series of bytes at particular address offset.
 These transactions are currently supportd in the
 i2c driver using i2c_read and i2c_write APIs. I2C EEPROMs,
 RTC, etc fall in this category.
 The transactions look like:
 START:Address:Tx:Offset:RESTART:Address[0..4]:Tx/Rx:data[0..n]:STOP
 
 However there are certain devices which support accesses in
 terms of the transactions as follows:
 START:Address:Tx:Txdata[0..n1]:Clock_stretching:
 RESTART:Address:Rx:data[0..n2]
 
 The Txdata is typically a command and some associated data,
 similarly Rxdata could be command status plus some data received
 as a response to the command sent.
 i2c_write_read() function provides support for such transactions
 (multiple bytes write followed by read)
 
 Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com
 Signed-off-by: Shaveta Leekha shav...@freescale.com
 ---
  drivers/i2c/fsl_i2c.c  |   64 ++-
  drivers/i2c/i2c_core.c |7 +
  include/i2c.h  |   19 ++---
  3 files changed, 78 insertions(+), 12 deletions(-)

snip

 diff --git a/include/i2c.h b/include/i2c.h
 index 1b4078e..7bac20a 100644
 --- a/include/i2c.h
 +++ b/include/i2c.h
 @@ -65,6 +65,9 @@ struct i2c_adapter {
   int (*write)(struct i2c_adapter *adap, uint8_t chip,
   uint addr, int alen, uint8_t *buffer,
   int len);
 + int (*write_read)(struct i2c_adapter *adap, uint8_t chip,
 + uint8_t *wbuffer, int wlength, uint8_t *rbuffer,
 + int rlength);
   uint(*set_bus_speed)(struct i2c_adapter *adap,
   uint speed);
   int speed;
 @@ -75,13 +78,14 @@ struct i2c_adapter {
   char*name;
  };
  
 -#define U_BOOT_I2C_MKENT_COMPLETE(_init, _probe, _read, _write, \
 +#define U_BOOT_I2C_MKENT_COMPLETE(_init, _probe, _read, _write, _write_read, 
 \
   _set_speed, _speed, _slaveaddr, _hwadapnr, _name) \
   { \
   .init   =   _init, \
   .probe  =   _probe, \
   .read   =   _read, \
   .write  =   _write, \
 + .write_read =   _write_read, \
   .set_bus_speed  =   _set_speed, \
   .speed  =   _speed, \
   .slaveaddr  =   _slaveaddr, \
 @@ -90,10 +94,11 @@ struct i2c_adapter {
   .name   =   #_name \
  };
  
 -#define U_BOOT_I2C_ADAP_COMPLETE(_name, _init, _probe, _read, _write, \
 - _set_speed, _speed, _slaveaddr, _hwadapnr) \
 - ll_entry_declare(struct i2c_adapter, _name, i2c) = \
 - U_BOOT_I2C_MKENT_COMPLETE(_init, _probe, _read, _write, \
 +#define U_BOOT_I2C_ADAP_COMPLETE(_name, _init, _probe, _read, _write,
 \
 + _write_read, _set_speed, _speed, _slaveaddr,\
 + _hwadapnr)  \
 + ll_entry_declare(struct i2c_adapter, _name, i2c) =  \
 + U_BOOT_I2C_MKENT_COMPLETE(_init, _probe, _read, _write,  _write_read, \
_set_speed, _speed, _slaveaddr, _hwadapnr, _name);
  
  struct i2c_adapter *i2c_get_adapter(int index);
 @@ -237,6 +242,8 @@ int i2c_read(uint8_t chip, unsigned int addr, int alen,
  
  int i2c_write(uint8_t chip, unsigned int addr, int alen,
   uint8_t *buffer, int len);
 +int i2c_write_read(uint8_t chip, uchar *wbuffer, int wlen, uchar *rbuffer,
 + int rlen);
  
  /*
   * Utility routines to read/write registers.
 @@ -302,6 +309,8 @@ int i2c_probe(uchar chip);
   */
  int i2c_read(uchar chip, uint addr, int alen, uchar *buffer, int len);
  int i2c_write(uchar chip, uint addr, int alen, uchar *buffer, int len);
 +int i2c_write_read(uchar chip, uchar *wbuffer, int wlen, uchar *rbuffer,
 + int rlen);


You need to be careful when changing the header file. If you compile other
platforms, you will see the error. Try ./MAKEALL -a powerpc. I don't know how
bad you broke other architectures.

York

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

Re: [U-Boot] [PATCH v3 1/4] kbuild, blackfin: Add CONFIG_CC_OPTIMIZE_LIBS_FOR_SPEED

Hi Masahiro,

On 5 March 2014 00:59, Masahiro Yamada yamad...@jp.panasonic.com wrote:
 Many (but not all) of Blackfin boards give -O2 option
 to compile under lib/ directory.
 That means lib/ should be speed-optimized,
 whereas other parts should be size-optimized.

 We want to keep the same behavior,
 but do not want to parse board/*/config.mk again and again.
 We've got no choice but to invent a new method.

 CONFIG_CC_OPTIMIZE_LIBS_FOR_SPEED, if it is enabled,
 gives -O2 flag only for building under lib/ directory.

 Dirty codes which I had marked as FIX ME
 in board/${BOARD}/config.mk have been deleted.
 Instead, CONFIG_CC_OPTIMIZE_LIBS_FOR_SPEED has been
 defined in include/configs/${BOARD}.h.

 Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
 Cc: Sonic Zhang sonic.zh...@analog.com

Acked-by: Simon Glass s...@chromium.org

 diff --git a/lib/Makefile b/lib/Makefile
 index dedb97b..8814ff9 100644
 --- a/lib/Makefile
 +++ b/lib/Makefile
 @@ -65,3 +65,5 @@ obj-y += vsprintf.o
  obj-$(CONFIG_RANDOM_MACADDR) += rand.o
  obj-$(CONFIG_BOOTP_RANDOM_DELAY) += rand.o
  obj-$(CONFIG_CMD_LINK_LOCAL) += rand.o
 +
 +subdir-ccflags-$(CONFIG_CC_OPTIMIZE_LIBS_FOR_SPEED) += -O2


I guess this gets added after the -Os so supersedes it. I wonder what
happens if debugging is enabled? Still this is the same as before I
think.

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

Re: [U-Boot] [PATCH v3 2/4] kbuild: add CONFIG_ prefix to USE_PRIVATE_LIBGCC

On 5 March 2014 00:59, Masahiro Yamada yamad...@jp.panasonic.com wrote:
 Before this commit, USE_PRIVATE_LIBGCC was defined in
 arch-specific config.mk and referenced in
 arch/$(ARCH)/lib/Makefile.

 We are not happy about parsing config.mk again and again.
 We have to keep the same behavior with a different way.

 By adding CONFIG_ prefix, this macro appears
 in include/autoconf.mk, include/spl-autoconf.mk.
 (And treating USE_PRIVATE_LIBGCC as CONFIG macro
 is reasonable enough.)

 Tegra SoC family defined USE_PRIVATE_LIBGCC as yes
 in arch/arm/cpu/arm720t/tegra*/config.mk,
 whereas did not define it in arch/arm/cpu/armv7/tegra*/config.mk.

 It means Tegra enables PRIVATE_LIBGCC only for SPL.
 We can describe the same behavior by adding

   #ifdef CONFIG_SPL_BUILD
   # define CONFIG_USE_PRIVATE_LIBGCC
   #endif

 to include/configs/tegra-common.h.

 Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
 Cc: Tom Warren twar...@nvidia.com
 Cc: Simon Glass s...@chromium.org
 Acked-by: Stephen Warren swar...@nvidia.com

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

Re: [U-Boot] [PATCH v3 3/4] config.mk: specify the exact path to standalone linker script

On 5 March 2014 00:59, Masahiro Yamada yamad...@jp.panasonic.com wrote:
 We want to change the build system to include config.mk
 only from ./Makefile and spl/Makefile.
 We must prepare for that in this commit.

 $(src) is a moving target and not handy for our purpose.
 We must replace it with a fixed path.

 Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com

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

Re: [U-Boot] [PATCH 1/2] kbuild: move checkthumb to ARM archprepare

On 5 March 2014 01:49, Masahiro Yamada yamad...@jp.panasonic.com wrote:
 checkthumb makes sense only for ARM architecture.
 Move it to arch/arm/config.mk.

 To make sure gcc supports THUMB mode before beginning build,
 run checkthumb during archprepare.

 Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com

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

Re: [U-Boot] [PATCH 2/2] kbuild: move checkgcc4 to PowerPC archprepare

On 5 March 2014 01:49, Masahiro Yamada yamad...@jp.panasonic.com wrote:
 checkgcc4 is used only for PowerPC.
 Move it to arch/powerpc/config.mk.

 To make sure gcc is new enough before beginning build,
 run checkgcc4 during archprepare.

 Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com

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

Re: [U-Boot] [U-Boot, V3] hush: fix some quoted variable expansion issues

On Sat, Mar 01, 2014 at 10:16:10PM -0700, Stephen Warren wrote:

 The following shell command fails:
 
 if test -z $x; then echo zero; else echo non-zero; fi
 
 (assuming $x does not exist, it prints non-zero rather than zero).
 
 ... since $x expands to nothing, and the argument is completely
 dropped, causing too few to be passed to -z, causing cmd_test() to
 error out early.
 
 This is because when variable expansions are processed by make_string(),
 the expanded results are concatenated back into a new string. However,
 no quoting is applied when doing so, so any empty variables simply don't
 generate any parameter when the combined string is parsed again.
 
 Fix this by explicitly replacing quoting any argument that was originally
 quoted when re-generating a string from the already-parsed argument list.
 
 This also fixes loss of whitespace in commands such as:
 
 setenv space  
 setenv var  1${space}${space} 2 
 echo ${var}
 
 Reported-by: Russell King li...@arm.linux.org.uk
 Acked-by: Simon Glass s...@chromium.org
 Signed-off-by: Stephen Warren swar...@wwwdotorg.org

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v3, 2/4] kbuild: add CONFIG_ prefix to USE_PRIVATE_LIBGCC

On Wed, Mar 05, 2014 at 04:59:38PM +0900, Masahiro Yamada wrote:

 Before this commit, USE_PRIVATE_LIBGCC was defined in
 arch-specific config.mk and referenced in
 arch/$(ARCH)/lib/Makefile.
 
 We are not happy about parsing config.mk again and again.
 We have to keep the same behavior with a different way.
 
 By adding CONFIG_ prefix, this macro appears
 in include/autoconf.mk, include/spl-autoconf.mk.
 (And treating USE_PRIVATE_LIBGCC as CONFIG macro
 is reasonable enough.)
 
 Tegra SoC family defined USE_PRIVATE_LIBGCC as yes
 in arch/arm/cpu/arm720t/tegra*/config.mk,
 whereas did not define it in arch/arm/cpu/armv7/tegra*/config.mk.
 
 It means Tegra enables PRIVATE_LIBGCC only for SPL.
 We can describe the same behavior by adding
 
   #ifdef CONFIG_SPL_BUILD
   # define CONFIG_USE_PRIVATE_LIBGCC
   #endif
 
 to include/configs/tegra-common.h.
 
 Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
 Cc: Tom Warren twar...@nvidia.com
 Cc: Simon Glass s...@chromium.org
 Acked-by: Stephen Warren swar...@nvidia.com

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v3, 3/4] config.mk: specify the exact path to standalone linker script

On Wed, Mar 05, 2014 at 04:59:39PM +0900, Masahiro Yamada wrote:

 We want to change the build system to include config.mk
 only from ./Makefile and spl/Makefile.
 We must prepare for that in this commit.
 
 $(src) is a moving target and not handy for our purpose.
 We must replace it with a fixed path.
 
 Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, 2/2] kbuild: move checkgcc4 to PowerPC archprepare

On Wed, Mar 05, 2014 at 05:49:23PM +0900, Masahiro Yamada wrote:

 checkgcc4 is used only for PowerPC.
 Move it to arch/powerpc/config.mk.
 
 To make sure gcc is new enough before beginning build,
 run checkgcc4 during archprepare.
 
 Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v2] mips: move CONFIG_MIPS{32, 64} definition to config.mk

On Wed, Mar 05, 2014 at 05:25:37PM +0900, Masahiro Yamada wrote:

 All mips32 boards define CONFIG_MIPS32 in config headers
 except malta boards which define it in boards.cfg.
 We can consolidate them by defining it in
 arch/mips/cpu/mips32/config.mk.
 
 CONFIG_MIPS64 definition can be moved to
 arch/mips/cpu/mips64/config.mk as well.
 
 Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
 Cc: Daniel Schwierzeck daniel.schwierz...@gmail.com
 Acked-by: Daniel Schwierzeck daniel.schwierz...@gmail.com

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, 1/2] kbuild: move checkthumb to ARM archprepare

On Wed, Mar 05, 2014 at 05:49:22PM +0900, Masahiro Yamada wrote:

 checkthumb makes sense only for ARM architecture.
 Move it to arch/arm/config.mk.
 
 To make sure gcc supports THUMB mode before beginning build,
 run checkthumb during archprepare.
 
 Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] Cosmetic: Typo fixes

On Tue, Mar 04, 2014 at 05:24:09PM +0200, Vasili Galka wrote:

 From: Vasili Galka vvv...@gmail.com
 
 Signed-off-by: Vasili Galka vas...@visionmap.com

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] powerpc: mpc8260: consolidate CONFIG_MPC8260 and CONFIG_8260

On Wed, Mar 05, 2014 at 05:40:10PM +0900, Masahiro Yamada wrote:

 Before this commit, CONFIG_MPC8260 and CONFIG_8260
 were used mixed-up.
 
 All boards with mpc8260 cpu defined both of them:
   - CONFIG_MPC8260 was defined in board config headers
   and include/common.h
   - CONFIG_8260 was defined arch/powerpc/cpu/mpc8260/config.mk
 
 We do not need to have both of them.
 This commit keeps only CONFIG_MPC8260.
 
 This commit does:
  - Delete CONFIG_8260 and CONFIG_MPC8260 definition
in config headers and include/common.h
  - Rename CONFIG_8260 to CONFIG_MPC8260
 in arch/powerpc/cpu/mpc8260/config.mk.
  - Rename #ifdef CONFIG_8260 to #ifdef CONFIG_MPC8260
 
 Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
 Cc: Wolfgang Denk w...@denx.de

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] net/phy: Correct AR8021 phy_mask

On Tue, Mar 04, 2014 at 03:56:12PM +0800, Haijun.Zhang wrote:

 There was wrong phy_mask for AR8021 device,
 so the AR8021 can't be probed correctly.
 Changed it from 0x4f to 0x40.
 
 Signed-off-by: Haijun Zhang haijun.zh...@freescale.com

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] ppc4xx: Remove 4xx NAND booting support

On Tue, Mar 04, 2014 at 03:34:35PM +0100, Stefan Roese wrote:

 As ppc4xx currently only supports the deprecated nand_spl infrastructure
 and nobody seems to have time / resources to port this over to the newer
 SPL infrastructure, lets remove NAND booting completely.
 
 This should not affect the normal, non NAND-booting ppc4xx platforms
 that are currently supported.
 
 Signed-off-by: Stefan Roese s...@denx.de
 Cc: Wolfgang Denk w...@denx.de
 Cc: Tirumala Marri tma...@apm.com
 Cc: Matthias Fuchs matthias.fu...@esd.eu
 Cc: Masahiro Yamada yamad...@jp.panasonic.com
 Cc: Tom Rini tr...@ti.com
 Tested-by: Matthias Fuchs matthias.fu...@esd.eu

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] cmd_nvedit: Make 'env import -c' require size parameter

On Tue, Mar 04, 2014 at 03:52:35PM -0500, Tom Rini wrote:

 When importing a checksummed area we need to be told how big the area in
 question is so that we know that will match the size of the area which
 the checksum is generated against.
 
 Reported-by: Pierre AUBERT p.aub...@staubli.com
 Signed-off-by: Tom Rini tr...@ti.com

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v3, 1/4] kbuild, blackfin: Add CONFIG_CC_OPTIMIZE_LIBS_FOR_SPEED

On Wed, Mar 05, 2014 at 04:59:37PM +0900, Masahiro Yamada wrote:

 Many (but not all) of Blackfin boards give -O2 option
 to compile under lib/ directory.
 That means lib/ should be speed-optimized,
 whereas other parts should be size-optimized.
 
 We want to keep the same behavior,
 but do not want to parse board/*/config.mk again and again.
 We've got no choice but to invent a new method.
 
 CONFIG_CC_OPTIMIZE_LIBS_FOR_SPEED, if it is enabled,
 gives -O2 flag only for building under lib/ directory.
 
 Dirty codes which I had marked as FIX ME
 in board/${BOARD}/config.mk have been deleted.
 Instead, CONFIG_CC_OPTIMIZE_LIBS_FOR_SPEED has been
 defined in include/configs/${BOARD}.h.
 
 Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
 Cc: Sonic Zhang sonic.zh...@analog.com

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,v3,4/4] kbuild: improve Kbuild speed

On Wed, Mar 05, 2014 at 04:59:40PM +0900, Masahiro Yamada wrote:

 Kbuild brought about many advantages for us but a significant
 performance regression was reported by Simon Glass.
 
 After some discussions and analysis, it turned out
 its main cause is in $(call cc-option,...).
 
 Historically, U-Boot parses all config.mk
 (arch/*/config.mk and board/*/config.mk)
 every time descending into subdirectories.
 That means cc-options are evaluated over and over again.
 
 $(call cc-option,...) is useful but costly.
 So we want to evaluate them only in ./Makefile
 and spl/Makefile and export compiler flags.
 
 This commit changes the build system as follows:
 
   - Modify scripts/Makefile.build to not include config.mk
 Instead, add $(PLATFORM_CPPFLAGS) to asflags-y, ccflags-y,
 cppflags-y.
 
   - Export many variables
 Going forward, Kbuild will not parse config.mk files
 when it descends into subdirectories.
 If we want to set variables in config.mk and use them
 in subdirectories, they must be exported.
 
 This is the list of variables to get exported:
   PLATFORM_CPPFLAGS
   CPUDIR
   BOARDDIR
   OBJCOPYFLAGS
   LDFLAGS
   LDFLAGS_FINAL
 (used in nand_spl/board/*/*/Makefile)
   CONFIG_STANDALONE_LOAD_ADDR
 (used in examples/standalone/Makefile)
   SYM_PREFIX
 (used in examples/standalone/Makefile)
   RELFLAGS
 (used in examples/standalone/Makefile)
 
   - Delete CPPFLAGS
 This variable has been replaced with PLATFORM_CPPFLAGS
 
   - Copy gcclibdir from example/standalone/Makefile
 to arch/sparc/config.mk
 The reference in CONFIG_STANDALONE_LOAD_ADDR must be
 resolved before it is exported.
 
 Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
 Reported-by: Simon Glass s...@chromium.org
 Acked-by: Simon Glass s...@chromium.org
 Tested-by: Simon Glass s...@chromium.org [on Sandbox]
 Tested-by: Stephen Warren swar...@nvidia.com [on Tegra]

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] xilinx: delete meaningless .gitignore files

On Tue, Mar 04, 2014 at 11:36:51AM +0900, Masahiro Yamada wrote:

 config.tmp is never generated
 
 Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
 Cc: Michal Simek michal.si...@xilinx.com
 Acked-by: Michal Simek michal.si...@xilinx.com

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] unit-test: clean up evironment after Hush tests

On Thu, Feb 27, 2014 at 10:01:28PM -0700, Stephen Warren wrote:

 Delete the temporary variables that are used to save unit-test results
 from the environment after running the test. This prevents polluting
 the environment, or growing it too much.
 
 Signed-off-by: Stephen Warren swar...@wwwdotorg.org
 Acked-by: Simon Glass s...@chromium.org

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] unit-test: make test -e test independent of $CWD

On Sat, Mar 01, 2014 at 10:18:00PM -0700, Stephen Warren wrote:

 The unit-test for hush's test -e currently relies upon being run in
 the U-Boot build directory, because it tests for the existence of a file
 that exists in that directory.
 
 Fix this by explicitly creating the file we use for the existence test,
 and deleting it afterwards so that multiple successive unit-test
 invocations succeed. This required adding an os.c function to erase
 files.
 
 Reported-by: Simon Glass s...@chromium.org
 Signed-off-by: Stephen Warren swar...@wwwdotorg.org

Applied to u-boot/master, thanks!

-- 
Tom


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

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

On Thu, Feb 27, 2014 at 01:27:02PM -0700, Stephen Warren wrote:

 From: Stephen Warren swar...@nvidia.com
 
 For Ethernet/USB RX packets, the ASIX HW pads odd-sized packets so that
 they have an even size. Currently, asix_recv() does remove this padding,
 and asic_send() adds equivalent padding in the TX path. However, the HW
 does not appear to need this packing for TX packets in practical testing
 with ASIX Elec. Corp. AX88x72A 01 Vendor: 0x0b95 Product 0x7720
 Version 0.1. The Linux kernel does no such padding for the TX path.
 
 Remove the padding from the TX path:
 
 * For consistency with the Linux kernel.
 * NVIDIA has a Tegra simulator which validates that the length of USB
   packets sent to an ASIX device matches the packet length value inside
   the packet data. Having U-Boot and the kernel do the same thing when
   creating the TX packets simplifies the simulator's validation.
 
 Cc: Lucas Stach d...@lynxeye.de
 Cc: Marek Vasut ma...@denx.de
 Cc: Simon Glass s...@chromium.org
 Signed-off-by: Stephen Warren swar...@nvidia.com
 Acked-by: Simon Glass s...@chromium.org
 Acked-by: Marek Vasut ma...@denx.de
 Tested-by: Marek Vasut ma...@denx.de
 Tested-by: Gerhard Sittig g...@denx.de

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v4 1/2] QE/FMAN: modify CONFIG_SYS_QE_FMAN_FW_ADDR to CONFIG_SYS_FMAN_FW_ADDR and CONFIG_SYS_QE_FW_ADDR

On 02/17/2014 07:28 PM, Zhao Qiang wrote:
 CONFIG_SYS_QE_FMAN_FW_ADDR is used to both Fman and QE for microcode address.
 Now using CONFIG_SYS_FMAN_FW_ADDR for Fman microcode address,
 and CONFIG_SYS_QE_FW_ADDR for QE microcode address.
 
 Signed-off-by: Zhao Qiang b45...@freescale.com
 ---
 Changes for v2:
   - no 
 Changes for v3:
   - no 
 Changes for v4:
   - no 
 
  README  |  9 +++--
  arch/powerpc/cpu/mpc85xx/cpu_init.c |  2 +-
  drivers/net/fm/fm.c | 12 ++--
  drivers/qe/qe.c |  2 +-
  include/configs/B4860QDS.h  | 10 +-
  include/configs/MPC8569MDS.h|  2 +-
  include/configs/P1023RDB.h  |  2 +-
  include/configs/P1023RDS.h  |  4 ++--
  include/configs/P2041RDB.h  | 10 +-
  include/configs/T1040QDS.h  |  8 
  include/configs/T1040RDB.h  |  8 
  include/configs/T1042RDB_PI.h   |  8 
  include/configs/T2080QDS.h  | 10 +-
  include/configs/T4240EMU.h  |  2 +-
  include/configs/T4240QDS.h  | 10 +-
  include/configs/corenet_ds.h| 10 +-
  include/configs/km/km8309-common.h  |  2 +-
  include/configs/km/kmp204x-common.h |  2 +-

Please double check the change for km. It has compiling error. It seems to use
FMAN but you changed it to QE.

York


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

Re: [U-Boot] [PATCH] board/b4860qds: Add support to make PCIe SATA work on B4860QDS

On 02/26/2014 02:36 AM, Shaveta Leekha wrote:
   1) SerDes2 Refclks have been set properly to make
  PCIe SATA to work as it work on SerDes refclk of 100MHz
   2) Mask the SerDes's device reset request before changing
  the Refclks for SerDes1 and SerDes2 for PLL locks to
  happen properly, device reset request bit unmasked
  after SerDes refclks configuration
 
 Signed-off-by: Shaveta Leekha shav...@freescale.com
 ---


Applied to u-boot-mpc85xx/master. Thanks.

York

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

Re: [U-Boot] [PATCH] board/b4860qds: Add support to make Aurora work on B4860QDS

On 02/26/2014 02:36 AM, Shaveta Leekha wrote:
 1) Add new SerDes1 protocols having Aurora in them
 2) Add VSC cross point connections for Aurora to work with
CPRI and SGMIIs
 3) Configure VSC crossbar switch to connect SerDes1
lanes to aurora on board, by checking SerDes1 protocols
 4) SerDes1 Refclks have been set properly to make
Aurora, CPRI and SGMIIs to work together properly
 
 Signed-off-by: Shaveta Leekha shav...@freescale.com
 ---

Applied to u-boot-mpc85xx/master. Thanks.

York


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

Re: [U-Boot] [PATCH] 85xx/b4860: Alternate serdes protocols for B4860/B4420

On 02/16/2014 07:08 PM, Poonam Aggrwal wrote:
 On B4860 and B4420, some serdes protocols can be used with LC VCO as
 well as Ring VCO options.
 
 Addded Alternate options with LC VCO for such protocols.
 For example protocol 0x2a on srds 1 becomes 0x29 if it is LC VCO.
 
 The alternate option has the same functionality as the original option;
 the only difference being LC VCO rather than Ring VCO.
 
 Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com
 Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
 ---


Applied to u-boot-mpc85xx/master. Thanks.

York

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

Re: [U-Boot] [PATCH 1/2] B4860/B4420: Add PLL_NUM define for B4420/B4860 to use SerDes2 Refclks re-configuration

On 02/26/2014 02:37 AM, Shaveta Leekha wrote:
 - B4860 has two PLL per SerDes whereas B4420 has one PLL
   per SerDes, add their defines in
   arch/powerpc/include/asm/config_mpc85xx.h
 
 Signed-off-by: Shaveta Leekha shav...@freescale.com
 ---


Applied to u-boot-mpc85xx/master. Thanks.

York

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

Re: [U-Boot] [PATCH 2/2] B4860qds: Set SerDes2 refclk2 at to 156.25MHz for XFI to work

On 02/26/2014 02:37 AM, Shaveta Leekha wrote:
- Change setting of SerDes2 refclk2 to have the default value
  as it is coming on board that is 156.25MHz, for XFI to work
- Also change PLL_NUM variable to the one defined in
  config_mpc85xx.h for B4860 and B4420
 
 Signed-off-by: Shaveta Leekha shav...@freescale.com
 ---


Applied to u-boot-mpc85xx/master. Thanks.

York

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

Re: [U-Boot] [PATCH] powerpc/b4860: Add workaround for errata A006384 and A006475

On 02/26/2014 02:38 AM, Shaveta Leekha wrote:
 SerDes PLLs may not lock reliably at 5 G VCO configuration(A006384)
 and at cold temperatures(A006475), workaround recalibrate the
 PLLs with some SerDes configuration
 
 Both these errata are only applicable for b4 rev1.
 So, make workaround for these errata conditional,
 depending upon soc version.
 
 Signed-off-by: Shaveta Leekha shav...@freescale.com


Applied to u-boot-mpc85xx/master. Thanks.

York

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

Re: [U-Boot] [PATCH v2] powerpc/usb: Workaround for erratum-A006261

On 02/26/2014 12:59 AM, Suresh Gupta wrote:
   USB spec says that the minimum disconnect threshold should be
   over 525 mV. However, internal USB PHY threshold value is below
   this specified value. Due to this some devices disconnect at
   run-time. Hence, phy settings are tweaked to increased disconnect
   threshold to be above 525mV by using this workaround.
 
 Signed-off-by: Suresh Gupta suresh.gu...@freescale.com
 ---
  Changes for v2:
   - Incorporated missing SOC's affected by errata
 


Applied to u-boot-mpc85xx/master. Thanks.

York

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

Re: [U-Boot] [PATCH] powerpc/t208xqds: fixup for t208xqds

On 03/05/2014 11:07 PM, Shengzhou Liu wrote:
 - change QIXIS timing parameter CONFIG_SYS_CS3_FTIM2 to 8 from 0.
 - fix EMI2 for t2080qds, which was caused by adding t2081qds.
 
 Signed-off-by: Shengzhou Liu shengzhou@freescale.com
 ---

Applied to u-boot-mpc85xx/master. Thanks.

York


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

Re: [U-Boot] [PATCH V2 2/2] bootstage: powerpc: support fdt stash and reporting

On 02/19/2014 07:16 AM, Rommel G Custodio wrote:
 This implements stashing of bootstage timing data to FDT and automatic
 timing reporting. To enable define CONFIG_BOOTSTAGE_FDT and
 CONFIG_BOOTSTAGE_REPORT respectively.
 
 Signed-off-by: Rommel G Custodio sessyargc+u-b...@gmail.com
 ---


Applied to u-boot-mpc85xx/master. Thanks.

York

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

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

On 03/04/2014 11:04 PM, Shengzhou Liu wrote:
 T2080PCIe-RDB is a Freescale Reference Design Board that hosts the T2080 SoC.
 It works in two mode: standalone mode and PCIe endpoint mode.
 
 T2080PCIe-RDB Feature Overview
 --
 Processor:
  - T2080 SoC integrating four 64-bit dual-threads e6500 cores up to 1.8GHz
 DDR Memory:
  - Single memory controller capable of supporting DDR3 and DDR3-LP devices
  - 72bit 4GB DDR3-LP SODIMM in slot
 Ethernet interfaces:
  - Two 10M/100M/1G RGMII ports on-board
  - Two 10Gbps SFP+ ports on-board
  - Two 10Gbps Base-T ports on-board
 Accelerator:
  - DPAA components consist of FMan, BMan, QMan, PME, DCE and SEC
 SerDes 16 lanes configuration:
  - SerDes-1 Lane A-B: to two 10G XFI fiber (MAC9  MAC10)
  - SerDes-1 Lane C-D: to two 10G Base-T (MAC1  MAC2)
  - SerDes-1 Lane E-H: to PCIe Goldfinger (PCIe4 x4, Gen3)
  - SerDes-2 Lane A-D: to PCIe Slot (PCIe1 x4, Gen2)
  - SerDes-2 Lane E-F: to C293 secure co-processor (PCIe2 x2)
  - SerDes-2 Lane G-H: to SATA1  SATA2
 IFC/Local Bus:
  - NOR:  128MB 16-bit NOR flash
  - NAND: 512MB 8-bit NAND flash
  - CPLD: for system controlling with programable header on-board
 eSPI:
  - 64MB N25Q512 SPI flash
 USB:
  - Two USB2.0 ports with internal PHY (both Type-A)
 PCIe:
  - One PCIe x4 gold-finger
  - One PCIe x4 connector
  - One PCIe x2 end-point device (C293 Crypto co-processor)
 SATA:
  - Two SATA 2.0 ports on-board
 SDHC:
  - support a TF-card on-board
 I2C:
  - Four I2C controllers.
 UART:
  - Dual 4-pins UART serial ports
 
 Signed-off-by: Shengzhou Liu shengzhou@freescale.com
 ---
 v3: rename PHY address to match Cortina PHY driver.
 v2: updated readme.


Applied to u-boot-mpc85xx/master. Thanks.

York


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

Re: [U-Boot] [PATCH 1/2] powerpc/mpc85xx: Add SCFG_PIXCLKCR register support for T1040

On 01/30/2014 02:09 AM, Priyanka Jain wrote:
 T1040 SoC has SCFG (Supplement Configuration) Block which provides
 chip specific configuration and status support. The base address of
 SCFG block in T1040 is 0xfc000.
 SCFG contains SCFG_PIXCLKCR (DIU pixel clock control register)
 at offset 0x28.
 
 Add definition of
 -SCFG block
 -SCFG_PIXCLKCR register
 -Bits definition of SCFG_PIXCLK register
 
 Signed-off-by: Priyanka Jain priyanka.j...@freescale.com
 ---

Applied to u-boot-mpc85xx/master. Thanks.

York


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

Re: [U-Boot] [PATCH][v2] powerpc/t1040qds: Add Video - HDMI support

On 02/26/2014 02:41 AM, Priyanka Jain wrote:
 T1040 has internal display interface unit (DIU) for driving video.
 T1040QDS supports video mode via
 -LCD using TI enconder
 -HDMI type interface via HDMI encoder
 
 Chrontel, CH7301C encoder which is I2C programmable is used as
 HDMI connector on T1040QDS.
 This patch add support to
 -enable Video interface for T1040QDS
 -route qixis multiplexing to enable DIU-HDMI interface on board
 -program DIU pixel clock gerenartor for T1040
 -program HDMI encoder via I2C on board
 
 Signed-off-by: Priyanka Jain priyanka.j...@freescale.com
 ---
  Changes for v2: Fix compilation warnings
  Depends on http://patchwork.ozlabs.org/patch/315294/

Applied to u-boot-mpc85xx/master. Thanks.

York


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

Re: [U-Boot] [PATCH][v2] powerpc/t104xrdb: Update DDR initialization related settings

On 02/25/2014 08:08 PM, Priyanka Jain wrote:
 Update following DDR related settings for T1040RDB, T1042RDB_PI
 -Correct number of chip selects to two as t1040 supports
  two Chip selects.
 -Update board_specific_parameters udimm structure with settings
  derived via calibration.
 -Update ddr_raw_timing sructure corresponding to DIMM.
 -Set ODT to off. Typically on FSL board, ODT is set to 75 ohm,
  but on T104xRDB, on setting this , DDR instability is observed.
  Board-level debugging is in progress.
 
 Verified the updated settings to be working fine with dual-ranked
 Micron, MT18KSF51272AZ-1G6 DIMM at data rate 1600MT/s.
 
 Signed-off-by: Priyanka Jain priyanka.j...@freescale.com
 Signed-off-by: York Sun york...@freescale.com
 ---
  Changes for v2:
   Udpated description related to ODT off, Removed
   cpo, write_data_delay, force_2t parameters as they
   are not longer used.

Applied to u-boot-mpc85xx/master. Thanks.

York


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

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

Tom,

The following changes since commit e4b87e5b1d026bd010e2ba3abbf89561e8320287:

  Merge branch 'master' of git://git.denx.de/u-boot-nand-flash (2014-03-04
21:23:42 -0500)

are available in the git repository at:


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

for you to fetch changes up to 96ac18c9ccc77c7f57dff5651b34a3cc914c8abd:

  powerpc/t104xrdb: Update DDR initialization related settings (2014-03-07
14:53:48 -0800)


Mela Custodio (1):
  bootstage: powerpc: support fdt stash and reporting

Priyanka Jain (3):
  powerpc/mpc85xx: Add SCFG_PIXCLKCR register support for T1040
  powerpc/t1040qds: Add Video - HDMI support
  powerpc/t104xrdb: Update DDR initialization related settings

Shaveta Leekha (5):
  board/b4860qds: Add support to make Aurora work on B4860QDS
  board/b4860qds: Add support to make PCIe SATA work on B4860QDS
  B4860/B4420: Add PLL_NUM define for B4420/B4860 to use SerDes2 Refclks
re-configuration
  B4860qds: Set SerDes2 refclk2 at to 156.25MHz for XFI to work
  powerpc/b4860: Add workaround for errata A006384 and A006475

Shengzhou Liu (2):
  powerpc/t208xqds: fixup for t208xqds
  powerpc/t2080rdb: Add T2080PCIe-RDB board support

Suresh Gupta (1):
  powerpc/usb: Workaround for erratum-A006261

poonam aggrwal (1):
  85xx/b4860: Alternate serdes protocols for B4860/B4420

 arch/powerpc/cpu/mpc85xx/b4860_serdes.c  |   61 ++
 arch/powerpc/cpu/mpc85xx/cmd_errata.c|   12 +
 arch/powerpc/cpu/mpc85xx/cpu_init.c  |   62 ++
 arch/powerpc/include/asm/config_mpc85xx.h|   11 +
 arch/powerpc/include/asm/fsl_errata.h|   34 +
 arch/powerpc/include/asm/immap_85xx.h|   31 +-
 arch/powerpc/lib/bootm.c |7 +
 board/freescale/b4860qds/b4860qds.c  |  392 ++-
 board/freescale/b4860qds/b4860qds_crossbar_con.h |8 +
 board/freescale/b4860qds/eth_b4860qds.c  |5 +
 board/freescale/t1040qds/Makefile|1 +
 board/freescale/t1040qds/diu.c   |  215 ++
 board/freescale/t1040qds/t1040qds.h  |1 +
 board/freescale/t1040qds/t1040qds_qixis.h|   12 +
 board/freescale/t104xrdb/ddr.c   |   13 +-
 board/freescale/t104xrdb/ddr.h   |   38 +-
 board/freescale/t208xqds/eth_t208xqds.c  |3 +-
 board/freescale/t208xrdb/Makefile|   13 +
 board/freescale/t208xrdb/README  |  208 ++
 board/freescale/t208xrdb/cpld.c  |   71 ++
 board/freescale/t208xrdb/cpld.h  |   42 ++
 board/freescale/t208xrdb/ddr.c   |  112 
 board/freescale/t208xrdb/ddr.h   |   47 ++
 board/freescale/t208xrdb/eth_t208xrdb.c  |  106 +++
 board/freescale/t208xrdb/law.c   |   34 +
 board/freescale/t208xrdb/pci.c   |   23 +
 board/freescale/t208xrdb/t2080_pbi.cfg   |   41 ++
 board/freescale/t208xrdb/t2080_rcw.cfg   |8 +
 board/freescale/t208xrdb/t208xrdb.c  |  124 
 board/freescale/t208xrdb/t208xrdb.h  |   13 +
 board/freescale/t208xrdb/tlb.c   |  151 +
 boards.cfg   |5 +
 include/configs/T1040QDS.h   |   27 +-
 include/configs/T1040RDB.h   |2 +-
 include/configs/T1042RDB_PI.h|2 +-
 include/configs/T208xQDS.h   |2 +-
 include/configs/T208xRDB.h   |  779 ++
 include/fsl_usb.h|   23 +-
 38 files changed, 2687 insertions(+), 52 deletions(-)
 create mode 100644 board/freescale/t1040qds/diu.c
 create mode 100644 board/freescale/t208xrdb/Makefile
 create mode 100644 board/freescale/t208xrdb/README
 create mode 100644 board/freescale/t208xrdb/cpld.c
 create mode 100644 board/freescale/t208xrdb/cpld.h
 create mode 100644 board/freescale/t208xrdb/ddr.c
 create mode 100644 board/freescale/t208xrdb/ddr.h
 create mode 100644 board/freescale/t208xrdb/eth_t208xrdb.c
 create mode 100644 board/freescale/t208xrdb/law.c
 create mode 100644 board/freescale/t208xrdb/pci.c
 create mode 100644 board/freescale/t208xrdb/t2080_pbi.cfg
 create mode 100644 board/freescale/t208xrdb/t2080_rcw.cfg
 create mode 100644 board/freescale/t208xrdb/t208xrdb.c
 create mode 100644 board/freescale/t208xrdb/t208xrdb.h
 create mode 100644 board/freescale/t208xrdb/tlb.c
 create mode 100644 include/configs/T208xRDB.h

Thanks,

York
___
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/master