Re: [U-Boot] [PATCH v2 0/2] OMAP/GPMC: speed up NAND read access

2014-06-26 Thread Gupta, Pekon
Hi Daniel,

From: Daniel Mack [mailto:zon...@gmail.com]

Resending this since I got no replies on the first version.
I also fixed up the commit log of #1.

I plan to test this, but there is still a long pending list of patches which
for me to test in kernel and u-boot. So it might take bit time.
But really thanks much for this feature addition.

Just a minor feedback, if you like it...
GPMC controller support various transfer modes
- POLLED: default mode
- PREFETCH_POLLED : as added in this patch
- PREFETCH_IRQ: not implemented/required
- PREFETCH_DMA: not implemented/required

(1) Will it be okay to use following config names, this would be synonymous
to the xfer-modes DT binding used in kernel ?
CONFIG_NAND_OMAP_XFER_MODE_POLLED
CONFIG_NAND_OMAP_XFER_MODE_PREFETCH_POLLED

(2) It would be good if you can make PREFETCH_POLLED mode as default
And instead make POLLED mode selectable.
#ifdef CONFIG_NAND_OMAP_XFER_MODE_POLLED
/* old behavior */
#else  /* 
/* default PREFETCH_POLLED mode */
#endif

However, let me first test your patch, and these minor nit-picks
(if required) can be done later.

Thanks..
with regards, pekon


I spent some time looking into boot times of AM335x platforms. One big
improvement I made came with adding support for GPMC prefetch mode,
which gave a speed-up of NAND reads of roughly factor 2.
This is what patch #1 does.

Note that this is currently limited to read operations in 8-bit mode, but
I believe it could be easily extended to 16-bit operations if anyone has
hardware to test it on. Using the engine for write mode speed
improvements should also be doable, but I didn't spend time on it yet.
That can be added as a separate patch later.

Patch #2 decreases the GPMC memory map window size from 256MiB to 16MiB.
Admittedly, I'm not quite sure about the reason, but a read from
offset 0 in this memory area will freeze U-Boot instantly if the size
is configured to 256MiB. As contents of the FIFO are accessed in a
pseudo-mode from offset 0 anyway, it doesn't really matter.

What I also did to further speed up my boot was to tweak the GPMC
parameters for the NAND chip on our boards, but that's not part of this
patch set, and probably deserves a little more cleanup.

Test results and feedback very welcome.

Thanks,
Daniel


Daniel Mack (2):
  mtd: OMAP: Enable GPMC prefetch mode
  ARM: omap-common: gpmp: decrease memory region size to 16MiB

 arch/arm/cpu/armv7/omap-common/mem-common.c |   2 +-
 doc/README.nand |   5 ++
 drivers/mtd/nand/omap_gpmc.c| 115 +++-
 include/linux/mtd/omap_gpmc.h   |   6 +-
 4 files changed, 124 insertions(+), 4 deletions(-)

--
1.9.3

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


Re: [U-Boot] DCache in designware.c brakes bf609-ezkit board build

2014-06-26 Thread Alexey Brodkin
Hi Vasili,

On Wed, 2014-06-25 at 15:38 +0300, Vasili Galka wrote:
 Hi Alexey,
 
 Your commit 50b0df814b0f75c08a3d45a017016a75af3edb5d caused
 drivers/net/designware.c to be dependent on dcache functionality, e.g.
 invalidate_dcache_range(). This brakes build for configurations that
 don't
 have this implemented. For example the blackfin based bf609-ezkit
 board does
 not build now since it uses designware.c but there is no dcache
 related stuff
 for the blackfin arch.
 
 What do you see as the right solution for this? Implement some stub
 functions
 for dcache on blackfin? #ifdef the dcache calls in designware.c? If
 the
 later, what CONFIG conditions are the best to use?

When I added dcache invalidation/flush functions in DW GMAC driver I
expected that all arches have real or stub functions for cache
operations.

So IMHO the simplest solution is to implement stub functions for
blackfin.

But then maybe it's time to look a bit broader and implement generic
stub functions for cache operations and declare them weak. This will
immediately obsolete requirement of per-arch stubs... well and hopefully
all existing stubs for arches will be removed  - this would also benefit
entire U-Boot project making sources a bit more tiny.

Let me know if either option above works for you and if you need any
help from my side.

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


Re: [U-Boot] [PATCH v2 0/2] OMAP/GPMC: speed up NAND read access

2014-06-26 Thread Daniel Mack
Hi,

On 06/26/2014 08:08 AM, Gupta, Pekon wrote:
 From: Daniel Mack [mailto:zon...@gmail.com]

 Resending this since I got no replies on the first version.
 I also fixed up the commit log of #1.

 I plan to test this, but there is still a long pending list of patches which
 for me to test in kernel and u-boot. So it might take bit time.
 But really thanks much for this feature addition.
 
 Just a minor feedback, if you like it...
 GPMC controller support various transfer modes
 - POLLED: default mode
 - PREFETCH_POLLED : as added in this patch
 - PREFETCH_IRQ: not implemented/required
 - PREFETCH_DMA: not implemented/required
 
 (1) Will it be okay to use following config names, this would be synonymous
 to the xfer-modes DT binding used in kernel ?
 CONFIG_NAND_OMAP_XFER_MODE_POLLED
 CONFIG_NAND_OMAP_XFER_MODE_PREFETCH_POLLED

Yes, I've seen that, but decided for shorter names as we will never
support DMA or IRQ modes from U-Boot. But I can of course change that,
I'd ultimately leave such decisions up to you :)

 (2) It would be good if you can make PREFETCH_POLLED mode as default
 And instead make POLLED mode selectable.
 #ifdef CONFIG_NAND_OMAP_XFER_MODE_POLLED
   /* old behavior */
 #else  /* 
   /* default PREFETCH_POLLED mode */
 #endif

Ok, but then we'd need something that selects PREFETCH_POLLED
automatically if nothing else is selected in the config. I wanted to
avoid yet another mandatory config symbol that have to be patched into
all existing configs. Could you lay out how that would be done?

 However, let me first test your patch, and these minor nit-picks
 (if required) can be done later.

Alright. I'm in no hurry with this. Good to know it's on your list.


Thanks,
Daniel

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


Re: [U-Boot] [PATCH v3 00/10] sunxi: Bug fixes, sun4i and sun5i support and network improvements

2014-06-26 Thread Ian Campbell
(re-adding Hans whose CC I seem to have dropped somehow, sorry)

On Wed, 2014-06-25 at 20:57 +0100, Ian Campbell wrote:
 Hi Albert,
 
 Any comments on these sunxi series from Hans and myself?

I wonder if Hans and I should be applying for a u-boot-sunxi.git
custodian tree[0]?

Ian.

[0] http://www.denx.de/wiki/U-Boot/CustodianGitTrees

 
 Thanks,
 Ian.
 
 On Mon, 2014-06-09 at 11:36 +0200, Hans de Goede wrote:
  Hi All,
  
  Here is v2 of my patch series to be applied on top of Ian's recently merged
  basic sun7i support.
  
  This patch series begins with a few bug fixes found while working on 
  preparing
  the rest of the series, adds sun4i and sun5i support and rounds things of 
  with
  some networking fixes / additions.
  
  Changes since v1:
  -Improved various commit messages
  -Various small typo fixes
  -Cleaned up the axp209 and axp152 drivers
  -Added Acked-by: Ian Campbell ... to the patches which got acked by Ian
  
  Changes since v2:
  -Dropped the i2c + pmic support patches as they need more work
  -Split out the boards.cfg Cubietruck maintainer field changes from the 
  axp209
   support patch into its own patch
  -Added Acked-by: Ian Campbell ... to the patches which got acked by Ian
  
  Regards,
  
  Hans
  ___
  U-Boot mailing list
  U-Boot@lists.denx.de
  http://lists.denx.de/mailman/listinfo/u-boot
  
 
 
 ___
 U-Boot mailing list
 U-Boot@lists.denx.de
 http://lists.denx.de/mailman/listinfo/u-boot
 


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


[U-Boot] [PATCH] powerpc/ifc: fix invalid CSn FTIM2.TCH setting

2014-06-26 Thread shh.xie
From: Shaohui Xie shaohui@freescale.com

On some platforms, CSn FTIM2.TCH is set to zero which is invalid,
an invalid hold time makes DUT timing variances, whether it works
or not on luck.

Signed-off-by: Shaohui Xie shaohui@freescale.com
---
based on 'next' of git://git.denx.de/u-boot-mpc85xx.git.

 include/configs/B4860QDS.h   | 2 +-
 include/configs/BSC9132QDS.h | 2 +-
 include/configs/C29XPCIE.h   | 2 +-
 include/configs/P1010RDB.h   | 2 +-
 include/configs/T104xRDB.h   | 2 +-
 include/configs/T208xRDB.h   | 2 +-
 include/configs/T4240QDS.h   | 2 +-
 7 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/include/configs/B4860QDS.h b/include/configs/B4860QDS.h
index 1af9ba6..43c9df0 100644
--- a/include/configs/B4860QDS.h
+++ b/include/configs/B4860QDS.h
@@ -340,7 +340,7 @@ unsigned long get_board_ddr_clk(void);
 #define CONFIG_SYS_CS3_FTIM1   (FTIM1_GPCM_TACO(0x0e) | \
FTIM1_GPCM_TRAD(0x1f))
 #define CONFIG_SYS_CS3_FTIM2   (FTIM2_GPCM_TCS(0x0e) | \
-   FTIM2_GPCM_TCH(0x0) | \
+   FTIM2_GPCM_TCH(0x8) | \
FTIM2_GPCM_TWP(0x1f))
 #define CONFIG_SYS_CS3_FTIM3   0x0
 
diff --git a/include/configs/BSC9132QDS.h b/include/configs/BSC9132QDS.h
index 7bb5d33..49c16af 100644
--- a/include/configs/BSC9132QDS.h
+++ b/include/configs/BSC9132QDS.h
@@ -354,7 +354,7 @@ combinations. this should be removed later
 #define CONFIG_SYS_CS2_FTIM1   (FTIM1_GPCM_TACO(0x0e) | \
FTIM1_GPCM_TRAD(0x1f))
 #define CONFIG_SYS_CS2_FTIM2   (FTIM2_GPCM_TCS(0x0e) | \
-   FTIM2_GPCM_TCH(0x0) | \
+   FTIM2_GPCM_TCH(0x8) | \
FTIM2_GPCM_TWP(0x1f))
 #define CONFIG_SYS_CS2_FTIM3   0x0
 #endif
diff --git a/include/configs/C29XPCIE.h b/include/configs/C29XPCIE.h
index 9e12fac..0dd1560 100644
--- a/include/configs/C29XPCIE.h
+++ b/include/configs/C29XPCIE.h
@@ -319,7 +319,7 @@
 #define CONFIG_SYS_CS2_FTIM1   (FTIM1_GPCM_TACO(0x0e) | \
FTIM1_GPCM_TRAD(0x1f))
 #define CONFIG_SYS_CS2_FTIM2   (FTIM2_GPCM_TCS(0x0e) | \
-   FTIM2_GPCM_TCH(0x0) | \
+   FTIM2_GPCM_TCH(0x8) | \
FTIM2_GPCM_TWP(0x1f))
 #define CONFIG_SYS_CS2_FTIM3   0x0
 
diff --git a/include/configs/P1010RDB.h b/include/configs/P1010RDB.h
index d612a8b..50529bf 100644
--- a/include/configs/P1010RDB.h
+++ b/include/configs/P1010RDB.h
@@ -537,7 +537,7 @@ extern unsigned long get_sdram_size(void);
 #define CONFIG_SYS_CS3_FTIM1   (FTIM1_GPCM_TACO(0x0e) | \
FTIM1_GPCM_TRAD(0x1f))
 #define CONFIG_SYS_CS3_FTIM2   (FTIM2_GPCM_TCS(0x0e) | \
-   FTIM2_GPCM_TCH(0x0) | \
+   FTIM2_GPCM_TCH(0x8) | \
FTIM2_GPCM_TWP(0x1f))
 #define CONFIG_SYS_CS3_FTIM3   0x0
 
diff --git a/include/configs/T104xRDB.h b/include/configs/T104xRDB.h
index 8d6c51b..40bfc60 100644
--- a/include/configs/T104xRDB.h
+++ b/include/configs/T104xRDB.h
@@ -286,7 +286,7 @@
 #define CONFIG_SYS_CS2_FTIM1   (FTIM1_GPCM_TACO(0x0e) | \
FTIM1_GPCM_TRAD(0x1f))
 #define CONFIG_SYS_CS2_FTIM2   (FTIM2_GPCM_TCS(0x0e) | \
-   FTIM2_GPCM_TCH(0x0) | \
+   FTIM2_GPCM_TCH(0x8) | \
FTIM2_GPCM_TWP(0x1f))
 #define CONFIG_SYS_CS2_FTIM3   0x0
 
diff --git a/include/configs/T208xRDB.h b/include/configs/T208xRDB.h
index 3a1c49c..5d10ad2 100644
--- a/include/configs/T208xRDB.h
+++ b/include/configs/T208xRDB.h
@@ -283,7 +283,7 @@ unsigned long get_board_ddr_clk(void);
 #define CONFIG_SYS_CS2_FTIM1   (FTIM1_GPCM_TACO(0x0e) | \
FTIM1_GPCM_TRAD(0x1f))
 #define CONFIG_SYS_CS2_FTIM2   (FTIM2_GPCM_TCS(0x0e) | \
-   FTIM2_GPCM_TCH(0x0) | \
+   FTIM2_GPCM_TCH(0x8) | \
FTIM2_GPCM_TWP(0x1f))
 #define CONFIG_SYS_CS2_FTIM3   0x0
 
diff --git a/include/configs/T4240QDS.h b/include/configs/T4240QDS.h
index a770dd0..efdb68b 100644
--- a/include/configs/T4240QDS.h
+++ b/include/configs/T4240QDS.h
@@ -237,7 +237,7 @@ unsigned long get_board_ddr_clk(void);
 #define CONFIG_SYS_CS3_FTIM1   (FTIM1_GPCM_TACO(0xff) | \
FTIM1_GPCM_TRAD(0x3f))
 #define CONFIG_SYS_CS3_FTIM2   (FTIM2_GPCM_TCS(0x0e) | \
-   FTIM2_GPCM_TCH(0x0) | \
+   FTIM2_GPCM_TCH(0x8) | \

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

2014-06-26 Thread Wolfgang Denk
Dear Scott,

In message 1403637570.26908.38.ca...@snotra.buserror.net you wrote:

 I still disagree with #ifndef __UBOOT__ as it will hurt more than it
 helps with future merges.

I agree that #ifdef's should be avoided, but then here they also serve
a documentation purpose as they clearly mark areas of code that are
specific to U-Boot, or that are not used in U-Boot.

Do you think just of a removal, so there will be no trace left of
which code was added for U-Boot, and which was removed? Or should
these be turned into comments, something like

/* BEGIN U-Boot specific code */
...
/* END U-Boot specific code */

[but that would not handle code removal well].

So what exactly is your proposal how the #fdef's should be removed?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
It's not what you do, it's how you do what you do!  - Jordan D. Ulmer
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] Add Epson RX8581 RTC support

2014-06-26 Thread Thumshirn, Johannes Tobias
 Von: Tom Rini [mailto:tom.r...@gmail.com] Im Auftrag von Tom Rini
 Gesendet: Mittwoch, 25. Juni 2014 15:07
 An: Thumshirn, Johannes Tobias
 Cc: u-boot@lists.denx.de; Schnürer, Thomas
 Betreff: Re: [U-Boot] [PATCH] Add Epson RX8581 RTC support
 
 * PGP Signed by an unknown key
 
 On Wed, Jun 25, 2014 at 02:31:28PM +0200, Johannes Thumshirn wrote:
 
  Signed-off-by: Johannes Thumshirn johannes.thumsh...@men.de
 
 Seems reasonable.  I'm going to defer this however until we have Kconfig
 and can easily enable various drivers for build coverage unless you're
 going to submit a board that makes use of this.  Thanks!
 
 --
 Tom
 
 * Unknown Key
 * 0x94391D56

Ok, fair enough. Hopefully I can get the board implementation in a submitable 
state soon.

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


[U-Boot] [PATCH V2 00/10] peach_pit: Add support for FIMD, DP and parade chip

2014-06-26 Thread Ajay Kumar
Patchset V1:
https://www.mail-archive.com/u-boot@lists.denx.de/msg140596.html

Patch 6 is TEST_ONLY since Simon will be sending it as a part of
device model changes.

Patch 10 is TEST_ONLY and it adds support for cros-ec on peach_pit.
Simon will be sending a proper patchset for the same.

Changes from V1:
[PATCH V2 3/10] : Don't mix cpu_is and proid_isas per Minkyu's suggestion.
  Also, incorporate Simon's suggestion of not using else.
[PATCH V2 4/10] : For FIMD SYSMMU DT, use same compatible string as kernel.
[TEST_ONLY V2 6/10]: Make this patch TEST_ONLY

Ajay Kumar (9):
  [PATCH V2 1/10] exynos_fb: Remove usage of static defines
  [PATCH V2 2/10] arm: exynos: Add RPLL for Exynos5420
  [PATCH V2 3/10] arm: exynos: Add get_lcd_clk and set_lcd_clk callbacks for 
Exynos5420
  [PATCH V2 4/10] video: exynos_fimd: Add framework to disable FIMD sysmmu
  [TEST_ONLY V2 6/10] ARM: exynos: Add missing declaration for 
gpio_direction_input
  [PATCH V2 7/10] exynos5420: add callbacks needed for exynos_fb driver
  [PATCH V2 8/10] ARM: exynos: peach_pit: Add DT nodes for fimd and parade 
bridge chip
  [PATCH V2 9/10] CONFIGS: peach_pit: Enable display for peach_pit board
  [TEST_ONLY V2 10/10] Pit WIP

Vadim Bendebury (1):
  [PATCH V2 5/10] video: Add driver for Parade PS8625 dP to LVDS bridge


 arch/arm/cpu/armv7/exynos/clock.c  |  83 +-
 arch/arm/cpu/armv7/exynos/clock_init.h |   3 +
 arch/arm/cpu/armv7/exynos/clock_init_exynos5.c |  13 ++
 arch/arm/cpu/armv7/exynos/exynos5_setup.h  |   2 +-
 arch/arm/dts/exynos5420-peach-pit.dts  |  30 
 arch/arm/dts/exynos54xx.dtsi   |  10 ++
 arch/arm/include/asm/arch-exynos/clk.h |   1 +
 arch/arm/include/asm/arch-exynos/gpio.h|   1 +
 arch/arm/include/asm/arch-exynos/system.h  |   4 +
 board/samsung/common/board.c   |  15 ++
 board/samsung/smdk5420/smdk5420.c  | 129 ++-
 doc/device-tree-bindings/video/exynos-fb.txt   |   6 +
 drivers/misc/cros_ec_spi.c |   4 +-
 drivers/power/pmic/Makefile|   3 +-
 drivers/power/pmic/pmic_tps65090_ec.c  | 212 
 drivers/spi/exynos_spi.c   |   9 +-
 drivers/spi/spi.c  |   2 +
 drivers/video/Makefile |   1 +
 drivers/video/exynos_fb.c  |  17 +-
 drivers/video/exynos_fimd.c|  43 +
 drivers/video/parade.c | 220 +
 include/configs/exynos5-dt.h   |   2 +-
 include/configs/exynos5250-dt.h|   2 -
 include/configs/peach-pit.h|  12 ++
 include/configs/s5pc210_universal.h|   3 -
 include/configs/trats.h|   3 -
 include/configs/trats2.h   |   3 -
 include/fdtdec.h   |   2 +
 include/power/tps65090_pmic.h  |   6 +
 lib/fdtdec.c   |   2 +
 30 files changed, 724 insertions(+), 119 deletions(-)
 create mode 100644 drivers/power/pmic/pmic_tps65090_ec.c
 create mode 100644 drivers/video/parade.c

-- 
1.8.1.2

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


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

2014-06-26 Thread Ajay Kumar
This patch adds missing declaration for gpio_direction_input
function, thereby helps in resolving compilation warnings.

Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
 arch/arm/include/asm/arch-exynos/gpio.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/include/asm/arch-exynos/gpio.h 
b/arch/arm/include/asm/arch-exynos/gpio.h
index be5113f..8fb5c23 100644
--- a/arch/arm/include/asm/arch-exynos/gpio.h
+++ b/arch/arm/include/asm/arch-exynos/gpio.h
@@ -1504,6 +1504,7 @@ static const struct gpio_name_num_table 
exynos5420_gpio_table[] = {
 void gpio_cfg_pin(int gpio, int cfg);
 void gpio_set_pull(int gpio, int mode);
 void gpio_set_drv(int gpio, int mode);
+int gpio_direction_input(unsigned gpio);
 int gpio_direction_output(unsigned gpio, int value);
 int gpio_set_value(unsigned gpio, int value);
 int gpio_get_value(unsigned gpio);
-- 
1.8.1.2

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


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

2014-06-26 Thread Ajay Kumar
Enable drivers for FIMD, DP and parade bridge chip.

Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
 include/configs/peach-pit.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/include/configs/peach-pit.h b/include/configs/peach-pit.h
index 76b8d7a..88c093f 100644
--- a/include/configs/peach-pit.h
+++ b/include/configs/peach-pit.h
@@ -22,4 +22,14 @@
 #define CONFIG_SYS_PROMPT  Peach # 
 #define CONFIG_IDENT_STRING for Peach
 
+#define CONFIG_VIDEO_PARADE
+
+/* Display */
+#define CONFIG_LCD
+#ifdef CONFIG_LCD
+#define CONFIG_EXYNOS_FB
+#define CONFIG_EXYNOS_DP
+#define LCD_BPPLCD_COLOR16
+#endif
+
 #endif /* __CONFIG_PEACH_PIT_H */
-- 
1.8.1.2

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


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

2014-06-26 Thread Ajay Kumar
RPLL is needed to drive the LCD panel on Exynos5420 based boards.

Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
Acked-by: Simon Glass s...@chromium.org
Tested-by: Simon Glass s...@chromium.org
---
 arch/arm/cpu/armv7/exynos/clock_init.h |  3 +++
 arch/arm/cpu/armv7/exynos/clock_init_exynos5.c | 13 +
 2 files changed, 16 insertions(+)

diff --git a/arch/arm/cpu/armv7/exynos/clock_init.h 
b/arch/arm/cpu/armv7/exynos/clock_init.h
index a875d0b..fce502f 100644
--- a/arch/arm/cpu/armv7/exynos/clock_init.h
+++ b/arch/arm/cpu/armv7/exynos/clock_init.h
@@ -75,6 +75,9 @@ struct mem_timings {
unsigned spll_mdiv;
unsigned spll_pdiv;
unsigned spll_sdiv;
+   unsigned rpll_mdiv;
+   unsigned rpll_pdiv;
+   unsigned rpll_sdiv;
unsigned pclk_cdrex_ratio;
unsigned direct_cmd_msr[MEM_TIMINGS_MSR_COUNT];
 
diff --git a/arch/arm/cpu/armv7/exynos/clock_init_exynos5.c 
b/arch/arm/cpu/armv7/exynos/clock_init_exynos5.c
index 1d6977f..b6a9bc1 100644
--- a/arch/arm/cpu/armv7/exynos/clock_init_exynos5.c
+++ b/arch/arm/cpu/armv7/exynos/clock_init_exynos5.c
@@ -179,6 +179,10 @@ struct mem_timings mem_timings[] = {
.spll_mdiv = 0xc8,
.spll_pdiv = 0x3,
.spll_sdiv = 0x2,
+   /* RPLL @70.5Mhz */
+   .rpll_mdiv = 0x5E,
+   .rpll_pdiv = 0x2,
+   .rpll_sdiv = 0x4,
 
.direct_cmd_msr = {
0x00020018, 0x0003, 0x00010046, 0x0d70,
@@ -800,6 +804,7 @@ static void exynos5420_system_clock_init(void)
writel(mem-ipll_pdiv * PLL_LOCK_FACTOR, clk-ipll_lock);
writel(mem-spll_pdiv * PLL_LOCK_FACTOR, clk-spll_lock);
writel(mem-kpll_pdiv * PLL_LOCK_FACTOR, clk-kpll_lock);
+   writel(mem-rpll_pdiv * PLL_X_LOCK_FACTOR, clk-rpll_lock);
 
setbits_le32(clk-src_cpu, MUX_HPM_SEL_MASK);
 
@@ -898,6 +903,14 @@ static void exynos5420_system_clock_init(void)
while ((readl(clk-spll_con0)  PLL_LOCKED) == 0)
;
 
+   /* Set RPLL */
+   writel(RPLL_CON2_VAL, clk-rpll_con2);
+   writel(RPLL_CON1_VAL, clk-rpll_con1);
+   val = set_pll(mem-rpll_mdiv, mem-rpll_pdiv, mem-rpll_sdiv);
+   writel(val, clk-rpll_con0);
+   while ((readl(clk-rpll_con0)  PLL_LOCKED) == 0)
+   ;
+
writel(CLK_DIV_CDREX0_VAL, clk-div_cdrex0);
writel(CLK_DIV_CDREX1_VAL, clk-div_cdrex1);
 
-- 
1.8.1.2

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


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

2014-06-26 Thread Ajay Kumar
From: Vadim Bendebury vben...@chromium.org

The initialization table comes from the Illustration of I2C command
for initialing PS8625 document supplied by Parade.

Signed-off-by: Vadim Bendebury vben...@chromium.org
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
Acked-by: Simon Glass s...@chromium.org
Tested-by: Simon Glass s...@chromium.org
---
 drivers/video/Makefile |   1 +
 drivers/video/parade.c | 220 +
 include/fdtdec.h   |   1 +
 lib/fdtdec.c   |   1 +
 4 files changed, 223 insertions(+)
 create mode 100644 drivers/video/parade.c

diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 945f35d..8618590 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -41,3 +41,4 @@ obj-$(CONFIG_VIDEO_SMI_LYNXEM) += smiLynxEM.o videomodes.o
 obj-$(CONFIG_VIDEO_TEGRA) += tegra.o
 obj-$(CONFIG_VIDEO_VCXK) += bus_vcxk.o
 obj-$(CONFIG_FORMIKE) += formike.o
+obj-$(CONFIG_VIDEO_PARADE) += parade.o
diff --git a/drivers/video/parade.c b/drivers/video/parade.c
new file mode 100644
index 000..36e5d80
--- /dev/null
+++ b/drivers/video/parade.c
@@ -0,0 +1,220 @@
+/*
+ * Copyright (c) 2014 The Chromium OS Authors. All rights reserved.
+ * Use of this source code is governed by a BSD-style license that can be
+ * found in the LICENSE file.
+ */
+
+/*
+ * This file is a driver for Parade dP-LVDS bridges. The original submission
+ * is for the ps8625 chip.
+ */
+#include config.h
+#include common.h
+#include i2c.h
+#include fdtdec.h
+
+/*
+ * Initialization of the chip is a process of writing certaing values into
+ * certain registers over i2c bus. The chip in fact responds to a range of
+ * addresses on the i2c bus, so for each written value three parameters are
+ * required: i2c address, register address and the actual value.
+ *
+ * The base address is derived from the device tree, only address offset is
+ * stored in the table below.
+ */
+/**
+ * struct reg_data() - data for a parade register write
+ *
+ * @addr_offoffset from the i2c base address for parade
+ * @reg_addrregister address to write
+ * @value   value to be written
+ */
+struct reg_data {
+   uint8_t addr_off;
+   uint8_t reg;
+   uint8_t value;
+} _packed;
+
+#define END_OF_TABLE 0xff /* Ficticious offset */
+
+static const struct reg_data parade_values[] = {
+   {0x02, 0xa1, 0x01},  /* HPD low */
+/*
+ * SW setting
+ * [1:0] SW output 1.2V voltage is lower to 96%
+ */
+   {0x04, 0x14, 0x01},
+/*
+ * RCO SS setting
+ * [5:4] = b01 0.5%, b10 1%, b11 1.5%
+ */
+   {0x04, 0xe3, 0x20},
+   {0x04, 0xe2, 0x80}, /* [7] RCO SS enable */
+/*
+ *  RPHY Setting
+ * [3:2] CDR tune wait cycle before
+ * measure for fine tune b00: 1us,
+ * 01: 0.5us, 10:2us, 11:4us.
+ */
+   {0x04, 0x8a, 0x0c},
+   {0x04, 0x89, 0x08}, /* [3] RFD always on */
+/*
+ * CTN lock in/out:
+ * 2ppm/8ppm. Lock out 2
+ * times.
+ */
+   {0x04, 0x71, 0x2d},
+/*
+ * 2.7G CDR settings
+ * NOF=40LSB for HBR CDR setting
+ */
+   {0x04, 0x7d, 0x07},
+   {0x04, 0x7b, 0x00},  /* [1:0] Fmin=+4bands */
+   {0x04, 0x7a, 0xfd},  /* [7:5] DCO_FTRNG=+-40% */
+/*
+ * 1.62G CDR settings
+ * [5:2]NOF=64LSB [1:0]DCO scale is 2/5
+ */
+   {0x04, 0xc0, 0x12},
+   {0x04, 0xc1, 0x92},  /* Gitune=-37% */
+   {0x04, 0xc2, 0x1c},  /* Fbstep=100% */
+   {0x04, 0x32, 0x80},  /* [7] LOS signal disable */
+/*
+ * RPIO Setting
+ * [7:4] LVDS driver bias current :
+ * 75% (250mV swing)
+ */
+   {0x04, 0x00, 0xb0},
+/*
+ * [7:6] Right-bar GPIO output strength is 8mA
+ */
+   {0x04, 0x15, 0x40},
+/* EQ Training State Machine Setting */
+   {0x04, 0x54, 0x10},  /* RCO calibration start */
+/* [4:0] MAX_LANE_COUNT set to one lane */
+   {0x01, 0x02, 0x81},
+/* [4:0] LANE_COUNT_SET set to one lane */
+   {0x01, 0x21, 0x81},
+   {0x00, 0x52, 0x20},
+   {0x00, 0xf1, 0x03},  /* HPD CP toggle enable */
+   {0x00, 0x62, 0x41},
+/* Counter number, add 1ms counter delay */
+   {0x00, 0xf6, 0x01},
+/*
+ * [6]PWM function control by
+ * DPCD0040f[7], default is PWM
+ * block always works.
+ */
+   {0x00, 0x77, 0x06},
+/*
+ * 04h Adjust VTotal tolerance to
+ * fix the 30Hz no display issue
+ */
+   {0x00, 0x4c, 0x04},
+/* DPCD00400='h00, Parade OUI = 'h001cf8 */
+   {0x01, 0xc0, 0x00},
+   {0x01, 0xc1, 0x1c},  /* DPCD00401='h1c */
+   {0x01, 0xc2, 0xf8},  /* DPCD00402='hf8 */
+/*
+ * DPCD403~408 = ASCII code
+ * D2SLV5='h4432534c5635
+ */
+   {0x01, 0xc3, 0x44},
+   {0x01, 

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

2014-06-26 Thread Ajay Kumar
This patch adds DT properties for fimd and the parade bridge chip
present on peach_pit. The panel supports 1366x768 resolution.

Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
Acked-by: Simon Glass s...@chromium.org
Tested-by: Simon Glass s...@chromium.org
---
 arch/arm/dts/exynos5420-peach-pit.dts | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm/dts/exynos5420-peach-pit.dts 
b/arch/arm/dts/exynos5420-peach-pit.dts
index 8d148af..3ed70a8 100644
--- a/arch/arm/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/dts/exynos5420-peach-pit.dts
@@ -63,6 +63,11 @@
  reg = 0x20;
  compatible = maxim,max98090-codec;
   };
+
+   edp-lvds-bridge@48 {
+   compatible = parade,ps8625;
+   reg = 0x48;
+   };
};
 
 sound@383 {
@@ -124,4 +129,29 @@
xhci@1240 {
samsung,vbus-gpio = gpio 0x41 0; /* H01 */
};
+
+   fimd@1440 {
+   samsung,vl-freq = 60;
+   samsung,vl-col = 1366;
+   samsung,vl-row = 768;
+   samsung,vl-width = 1366;
+   samsung,vl-height = 768;
+
+   samsung,vl-clkp;
+   samsung,vl-dp;
+   samsung,vl-bpix = 4;
+
+   samsung,vl-hspw = 32;
+   samsung,vl-hbpd = 40;
+   samsung,vl-hfpd = 40;
+   samsung,vl-vspw = 6;
+   samsung,vl-vbpd = 10;
+   samsung,vl-vfpd = 12;
+   samsung,vl-cmd-allow-len = 0xf;
+
+   samsung,winid = 3;
+   samsung,interface-mode = 1;
+   samsung,dp-enabled = 1;
+   samsung,dual-lcd-enabled = 0;
+   };
 };
-- 
1.8.1.2

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


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

2014-06-26 Thread Ajay Kumar
Previously, we used to statically assign values for vl_col, vl_row and
vl_bpix using #defines like LCD_XRES, LCD_YRES and LCD_COLOR16.

Introducing the function exynos_lcd_early_init() would take care of this
assignment on the fly by parsing FIMD DT properties, thereby allowing us
to remove LCD_XRES and LCD_YRES from the main config file.

Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
Acked-by: Simon Glass s...@chromium.org
Tested-by: Simon Glass s...@chromium.org
---
 arch/arm/include/asm/arch-exynos/system.h |  1 +
 board/samsung/common/board.c  | 15 +++
 drivers/video/exynos_fb.c | 17 +
 include/configs/exynos5250-dt.h   |  2 --
 include/configs/s5pc210_universal.h   |  3 ---
 include/configs/trats.h   |  3 ---
 include/configs/trats2.h  |  3 ---
 7 files changed, 21 insertions(+), 23 deletions(-)

diff --git a/arch/arm/include/asm/arch-exynos/system.h 
b/arch/arm/include/asm/arch-exynos/system.h
index 7e2057c..4968d3d 100644
--- a/arch/arm/include/asm/arch-exynos/system.h
+++ b/arch/arm/include/asm/arch-exynos/system.h
@@ -39,5 +39,6 @@ struct exynos5_sysreg {
 
 void set_usbhost_mode(unsigned int mode);
 void set_system_display_ctrl(void);
+int exynos_lcd_early_init(const void *blob);
 
 #endif /* _EXYNOS4_SYSTEM_H */
diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
index 9dc7c83..1f6f0a0 100644
--- a/board/samsung/common/board.c
+++ b/board/samsung/common/board.c
@@ -20,6 +20,7 @@
 #include asm/arch/mmc.h
 #include asm/arch/pinmux.h
 #include asm/arch/power.h
+#include asm/arch/system.h
 #include power/pmic.h
 #include asm/arch/sromc.h
 #include lcd.h
@@ -148,6 +149,20 @@ int board_early_init_f(void)
board_i2c_init(gd-fdt_blob);
 #endif
 
+#if defined(CONFIG_OF_CONTROL)  defined(CONFIG_EXYNOS_FB)
+/*
+ * board_init_f(arch/arm/lib/board.c) calls lcd_setmem() which needs
+ * panel_info.vl_col, panel_info.vl_row and panel_info.vl_bpix, to reserve
+ * FB memory at a very early stage. So, we need to fill panel_info.vl_col,
+ * panel_info.vl_row and panel_info.vl_bpix before lcd_setmem() is called.
+ */
+   err = exynos_lcd_early_init(gd-fdt_blob);
+   if (err) {
+   debug(LCD early init failed\n);
+   return err;
+   }
+#endif
+
return exynos_early_init_f();
 }
 #endif
diff --git a/drivers/video/exynos_fb.c b/drivers/video/exynos_fb.c
index e1e0d80..bc478a9 100644
--- a/drivers/video/exynos_fb.c
+++ b/drivers/video/exynos_fb.c
@@ -27,17 +27,12 @@ DECLARE_GLOBAL_DATA_PTR;
 
 static unsigned int panel_width, panel_height;
 
-/*
- * board_init_f(arch/arm/lib/board.c) calls lcd_setmem() which needs
- * panel_info.vl_col, panel_info.vl_row and panel_info.vl_bpix to reserve
- * FB memory at a very early stage, i.e even before exynos_fimd_parse_dt()
- * is called. So, we are forced to statically assign it.
- */
 #ifdef CONFIG_OF_CONTROL
 vidinfo_t panel_info  = {
-   .vl_col = LCD_XRES,
-   .vl_row = LCD_YRES,
-   .vl_bpix = LCD_COLOR16,
+   /* Insert a value here so that we don't end up in the BSS
+* Reference: drivers/video/tegra.c
+*/
+   .vl_col = -1,
 };
 #endif
 
@@ -141,7 +136,7 @@ static void lcd_panel_on(vidinfo_t *vid)
 }
 
 #ifdef CONFIG_OF_CONTROL
-int exynos_fimd_parse_dt(const void *blob)
+int exynos_lcd_early_init(const void *blob)
 {
unsigned int node;
node = fdtdec_next_compatible(blob, 0, COMPAT_SAMSUNG_EXYNOS_FIMD);
@@ -286,8 +281,6 @@ void lcd_ctrl_init(void *lcdbase)
set_lcd_clk();
 
 #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
diff --git a/include/configs/exynos5250-dt.h b/include/configs/exynos5250-dt.h
index 74e72a5..c24984b 100644
--- a/include/configs/exynos5250-dt.h
+++ b/include/configs/exynos5250-dt.h
@@ -61,8 +61,6 @@
 #ifdef CONFIG_LCD
 #define CONFIG_EXYNOS_FB
 #define CONFIG_EXYNOS_DP
-#define LCD_XRES   2560
-#define LCD_YRES   1600
 #define LCD_BPPLCD_COLOR16
 #endif
 
diff --git a/include/configs/s5pc210_universal.h 
b/include/configs/s5pc210_universal.h
index eb046cd..20985da 100644
--- a/include/configs/s5pc210_universal.h
+++ b/include/configs/s5pc210_universal.h
@@ -247,7 +247,4 @@ int universal_spi_read(void);
 #define CONFIG_VIDEO_BMP_GZIP
 #define CONFIG_SYS_VIDEO_LOGO_MAX_SIZE ((500 * 160 * 4) + 54)
 
-#define LCD_XRES   480
-#define LCD_YRES   800
-
 #endif /* __CONFIG_H */
diff --git a/include/configs/trats.h b/include/configs/trats.h
index 90f1962..35c1feb 100644
--- a/include/configs/trats.h
+++ b/include/configs/trats.h
@@ -261,7 +261,4 @@
 #define CONFIG_VIDEO_BMP_GZIP
 #define CONFIG_SYS_VIDEO_LOGO_MAX_SIZE  ((500 * 160 * 4) + 54)
 
-#define LCD_XRES   720
-#define LCD_YRES   

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

2014-06-26 Thread Ajay Kumar
Add get_lcd_clk and set_lcd_clk callbacks for Exynos5420 needed by
exynos video driver.
Also, configure ACLK_400_DISP1 as the parent for MUX_ACLK_400_DISP1_SUB_SEL.

Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
Acked-by: Simon Glass s...@chromium.org
Tested-by: Simon Glass s...@chromium.org
---
 arch/arm/cpu/armv7/exynos/clock.c | 83 +--
 arch/arm/cpu/armv7/exynos/exynos5_setup.h |  2 +-
 arch/arm/include/asm/arch-exynos/clk.h|  1 +
 3 files changed, 80 insertions(+), 6 deletions(-)

diff --git a/arch/arm/cpu/armv7/exynos/clock.c 
b/arch/arm/cpu/armv7/exynos/clock.c
index 400d134..7558eff 100644
--- a/arch/arm/cpu/armv7/exynos/clock.c
+++ b/arch/arm/cpu/armv7/exynos/clock.c
@@ -82,7 +82,8 @@ static int exynos_get_pll_clk(int pllreg, unsigned int r, 
unsigned int k)
 * VPLL_CON: MIDV [24:16]
 * BPLL_CON: MIDV [25:16]: Exynos5
 */
-   if (pllreg == APLL || pllreg == MPLL || pllreg == BPLL)
+   if (pllreg == APLL || pllreg == MPLL || pllreg == BPLL ||
+   pllreg == SPLL)
mask = 0x3ff;
else
mask = 0x1ff;
@@ -391,6 +392,9 @@ static unsigned long exynos5420_get_pll_clk(int pllreg)
r = readl(clk-rpll_con0);
k = readl(clk-rpll_con1);
break;
+   case SPLL:
+   r = readl(clk-spll_con0);
+   break;
default:
printf(Unsupported PLL (%d)\n, pllreg);
return 0;
@@ -1027,6 +1031,40 @@ static unsigned long exynos5_get_lcd_clk(void)
return pclk;
 }
 
+static unsigned long exynos5420_get_lcd_clk(void)
+{
+   struct exynos5420_clock *clk =
+   (struct exynos5420_clock *)samsung_get_base_clock();
+   unsigned long pclk, sclk;
+   unsigned int sel;
+   unsigned int ratio;
+
+   /*
+* CLK_SRC_DISP10
+* FIMD1_SEL [4]
+* 0: SCLK_RPLL
+* 1: SCLK_SPLL
+*/
+   sel = readl(clk-src_disp10);
+   sel = (1  4);
+
+   if (sel)
+   sclk = get_pll_clk(SPLL);
+   else
+   sclk = get_pll_clk(RPLL);
+
+   /*
+* CLK_DIV_DISP10
+* FIMD1_RATIO [3:0]
+*/
+   ratio = readl(clk-div_disp10);
+   ratio = ratio  0xf;
+
+   pclk = sclk / (ratio + 1);
+
+   return pclk;
+}
+
 void exynos4_set_lcd_clk(void)
 {
struct exynos4_clock *clk =
@@ -1131,6 +1169,33 @@ void exynos5_set_lcd_clk(void)
clrsetbits_le32(clk-div_disp1_0, 0xf, 0x0);
 }
 
+void exynos5420_set_lcd_clk(void)
+{
+   struct exynos5420_clock *clk =
+   (struct exynos5420_clock *)samsung_get_base_clock();
+   unsigned int cfg;
+
+   /*
+* CLK_SRC_DISP10
+* FIMD1_SEL [4]
+* 0: SCLK_RPLL
+* 1: SCLK_SPLL
+*/
+   cfg = readl(clk-src_disp10);
+   cfg = ~(0x1  4);
+   cfg |= (0  4);
+   writel(cfg, clk-src_disp10);
+
+   /*
+* CLK_DIV_DISP10
+* FIMD1_RATIO  [3:0]
+*/
+   cfg = readl(clk-div_disp10);
+   cfg = ~(0xf  0);
+   cfg |= (0  0);
+   writel(cfg, clk-div_disp10);
+}
+
 void exynos4_set_mipi_clk(void)
 {
struct exynos4_clock *clk =
@@ -1602,16 +1667,24 @@ unsigned long get_lcd_clk(void)
 {
if (cpu_is_exynos4())
return exynos4_get_lcd_clk();
-   else
-   return exynos5_get_lcd_clk();
+   else {
+   if (proid_is_exynos5420())
+   return exynos5420_get_lcd_clk();
+   else
+   return exynos5_get_lcd_clk();
+   }
 }
 
 void set_lcd_clk(void)
 {
if (cpu_is_exynos4())
exynos4_set_lcd_clk();
-   else
-   exynos5_set_lcd_clk();
+   else {
+   if (proid_is_exynos5250())
+   exynos5_set_lcd_clk();
+   if (proid_is_exynos5420())
+   exynos5420_set_lcd_clk();
+   }
 }
 
 void set_mipi_clk(void)
diff --git a/arch/arm/cpu/armv7/exynos/exynos5_setup.h 
b/arch/arm/cpu/armv7/exynos/exynos5_setup.h
index 3242093..2eea48a 100644
--- a/arch/arm/cpu/armv7/exynos/exynos5_setup.h
+++ b/arch/arm/cpu/armv7/exynos/exynos5_setup.h
@@ -783,7 +783,7 @@
 #define CLK_SRC_TOP2_VAL   0x11101000
 #define CLK_SRC_TOP3_VAL   0x
 #define CLK_SRC_TOP4_VAL   0x0111
-#define CLK_SRC_TOP5_VAL   0x1100
+#define CLK_SRC_TOP5_VAL   0x1101
 #define CLK_SRC_TOP6_VAL   0x0111
 #define CLK_SRC_TOP7_VAL   0x00022200
 
diff --git a/arch/arm/include/asm/arch-exynos/clk.h 
b/arch/arm/include/asm/arch-exynos/clk.h
index ffbc07e..db24dc0 100644
--- a/arch/arm/include/asm/arch-exynos/clk.h
+++ b/arch/arm/include/asm/arch-exynos/clk.h
@@ -15,6 +15,7 @@
 #define VPLL   4
 #define BPLL   5
 #define RPLL   6
+#define SPLL   7
 
 #define MASK_PRE_RATIO(x)  (0xff  ((x  4) + 8))
 #define MASK_RATIO(x)  (0xf  (x  4))
-- 

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

2014-06-26 Thread Ajay Kumar
On Exynos5420 and newer versions, the FIMD sysmmus are in
on state by default.
We have to disable them in order to make FIMD DMA work.
This patch adds the required framework to exynos_fimd driver,
and disables FIMD sysmmu on Exynos5420.

Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
 arch/arm/dts/exynos54xx.dtsi | 10 +++
 doc/device-tree-bindings/video/exynos-fb.txt |  6 
 drivers/video/exynos_fimd.c  | 43 
 include/fdtdec.h |  1 +
 lib/fdtdec.c |  1 +
 5 files changed, 61 insertions(+)

diff --git a/arch/arm/dts/exynos54xx.dtsi b/arch/arm/dts/exynos54xx.dtsi
index b9f8e0b..c21d798 100644
--- a/arch/arm/dts/exynos54xx.dtsi
+++ b/arch/arm/dts/exynos54xx.dtsi
@@ -113,6 +113,16 @@
status = disabled;
};
 
+   fimdm0_sysmmu@0x1464 {
+   compatible = samsung,sysmmu-v3.3;
+   reg = 0x1464 0x100;
+   };
+
+   fimdm1_sysmmu@0x1468 {
+   compatible = samsung,sysmmu-v3.3;
+   reg = 0x1468 0x100;
+   };
+
fimd@1440 {
/* sysmmu is not used in U-Boot */
samsung,disable-sysmmu;
diff --git a/doc/device-tree-bindings/video/exynos-fb.txt 
b/doc/device-tree-bindings/video/exynos-fb.txt
index bb7441c..dc4e44f 100644
--- a/doc/device-tree-bindings/video/exynos-fb.txt
+++ b/doc/device-tree-bindings/video/exynos-fb.txt
@@ -55,6 +55,12 @@ Board(panel specific):
samsung,pclk-name: parent clock identifier: 1(MPLL), 2(EPLL), 3(VPLL)
samsung,sclk-div: parent_clock/source_clock ratio
samsung,dual-lcd-enabled: 1 if you support two LCD, else 0
+   samsung,disable-sysmmu: Define this if you want to disable FIMD sysmmu.
+   (needed for Exynos5420 and newer versions)
+   Add the required FIMD sysmmu nodes to be
+   disabled with compatible string
+   samsung,sysmmu-v3.3, with a reg property
+   holding the register address of FIMD sysmmu.
 
 Example:
 SOC specific part:
diff --git a/drivers/video/exynos_fimd.c b/drivers/video/exynos_fimd.c
index cebbba7..f67fa81 100644
--- a/drivers/video/exynos_fimd.c
+++ b/drivers/video/exynos_fimd.c
@@ -251,6 +251,45 @@ void exynos_fimd_window_off(unsigned int win_id)
writel(cfg, fimd_ctrl-winshmap);
 }
 
+#ifdef CONFIG_OF_CONTROL
+/*
+* The reset value for FIMD SYSMMU register MMU_CTRL is 3
+* on Exynos5420 and newer versions.
+* This means FIMD SYSMMU is on by default on Exynos5420
+* and newer versions.
+* Since in u-boot we don't use SYSMMU, we should disable
+* those FIMD SYSMMU.
+* Note that there are 2 SYSMMU for FIMD: m0 and m1.
+* m0 handles windows 0 and 4, and m1 handles windows 1, 2 and 3.
+* We disable both of them here.
+*/
+void exynos_fimd_disable_sysmmu(void)
+{
+   u32 *sysmmufimd;
+   unsigned int node;
+   int node_list[2];
+   int count;
+   int i;
+
+   count = fdtdec_find_aliases_for_id(gd-fdt_blob, fimd,
+   COMPAT_SAMSUNG_EXYNOS_SYSMMU, node_list, 2);
+   for (i = 0; i  count; i++) {
+   node = node_list[i];
+   if (node = 0) {
+   debug(Can't get device node for fimd sysmmu\n);
+   return;
+   }
+
+   sysmmufimd = (u32 *)fdtdec_get_addr(gd-fdt_blob, node, reg);
+   if (!sysmmufimd) {
+   debug(Can't get base address for sysmmu fimdm0);
+   return;
+   }
+
+   writel(0x0, sysmmufimd);
+   }
+}
+#endif
 
 void exynos_fimd_lcd_init(vidinfo_t *vid)
 {
@@ -268,6 +307,10 @@ void exynos_fimd_lcd_init(vidinfo_t *vid)
node, reg);
if (fimd_ctrl == NULL)
debug(Can't get the FIMD base address\n);
+
+   if (fdtdec_get_bool(gd-fdt_blob, node, samsung,disable-sysmmu))
+   exynos_fimd_disable_sysmmu();
+
 #else
fimd_ctrl = (struct exynos_fb *)samsung_get_base_fimd();
 #endif
diff --git a/include/fdtdec.h b/include/fdtdec.h
index a7e6ee7..a583d68 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -94,6 +94,7 @@ enum fdt_compat_id {
COMPAT_SANDBOX_LCD_SDL, /* Sandbox LCD emulation with SDL */
COMPAT_TI_TPS65090, /* Texas Instrument TPS65090 */
COMPAT_NXP_PTN3460, /* NXP PTN3460 DP/LVDS bridge */
+   COMPAT_SAMSUNG_EXYNOS_SYSMMU,   /* Exynos sysmmu */
 
COMPAT_COUNT,
 };
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 13d3d2f..1ccfb39 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -68,6 +68,7 @@ static const char * const compat_names[COMPAT_COUNT] = {
COMPAT(SANDBOX_LCD_SDL, sandbox,lcd-sdl),
COMPAT(TI_TPS65090, ti,tps65090),
 

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

2014-06-26 Thread Ajay Kumar
Add initialization code for peach_pit panel, parade bridge chip,
and backlight.

Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
Acked-by: Simon Glass s...@chromium.org
Tested-by: Simon Glass s...@chromium.org
---
 arch/arm/include/asm/arch-exynos/system.h |   3 +
 board/samsung/smdk5420/smdk5420.c | 129 +++---
 2 files changed, 50 insertions(+), 82 deletions(-)

diff --git a/arch/arm/include/asm/arch-exynos/system.h 
b/arch/arm/include/asm/arch-exynos/system.h
index 4968d3d..320763f 100644
--- a/arch/arm/include/asm/arch-exynos/system.h
+++ b/arch/arm/include/asm/arch-exynos/system.h
@@ -41,4 +41,7 @@ void set_usbhost_mode(unsigned int mode);
 void set_system_display_ctrl(void);
 int exynos_lcd_early_init(const void *blob);
 
+/* Initialize the Parade dP-LVDS bridge if present */
+int parade_init(const void *blob);
+
 #endif /* _EXYNOS4_SYSTEM_H */
diff --git a/board/samsung/smdk5420/smdk5420.c 
b/board/samsung/smdk5420/smdk5420.c
index 183c522..270ee83 100644
--- a/board/samsung/smdk5420/smdk5420.c
+++ b/board/samsung/smdk5420/smdk5420.c
@@ -10,11 +10,14 @@
 #include i2c.h
 #include lcd.h
 #include spi.h
+#include errno.h
 #include asm/arch/board.h
 #include asm/arch/cpu.h
 #include asm/arch/gpio.h
 #include asm/arch/pinmux.h
+#include asm/arch/system.h
 #include asm/arch/dp_info.h
+#include power/tps65090_pmic.h
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -40,95 +43,57 @@ int exynos_init(void)
 }
 
 #ifdef CONFIG_LCD
-void cfg_lcd_gpio(void)
+static int has_edp_bridge(void)
 {
-   /* For Backlight */
-   gpio_cfg_pin(EXYNOS5420_GPIO_B20, S5P_GPIO_OUTPUT);
-   gpio_set_value(EXYNOS5420_GPIO_B20, 1);
+   int node;
+
+   node = fdtdec_next_compatible(gd-fdt_blob, 0, COMPAT_PARADE_PS8625);
 
-   /* LCD power on */
-   gpio_cfg_pin(EXYNOS5420_GPIO_X15, S5P_GPIO_OUTPUT);
-   gpio_set_value(EXYNOS5420_GPIO_X15, 1);
+   /* No node for bridge in device tree. */
+   if (node = 0)
+   return 0;
 
-   /* Set Hotplug detect for DP */
-   gpio_cfg_pin(EXYNOS5420_GPIO_X07, S5P_GPIO_FUNC(0x3));
+   /* Default is with bridge ic */
+   return 1;
 }
 
-vidinfo_t panel_info = {
-   .vl_freq= 60,
-   .vl_col = 2560,
-   .vl_row = 1600,
-   .vl_width   = 2560,
-   .vl_height  = 1600,
-   .vl_clkp= CONFIG_SYS_LOW,
-   .vl_hsp = CONFIG_SYS_LOW,
-   .vl_vsp = CONFIG_SYS_LOW,
-   .vl_dp  = CONFIG_SYS_LOW,
-   .vl_bpix= 4,/* LCD_BPP = 2^4, for output conosle on LCD */
-
-   /* wDP panel timing infomation */
-   .vl_hspw= 32,
-   .vl_hbpd= 80,
-   .vl_hfpd= 48,
-
-   .vl_vspw= 6,
-   .vl_vbpd= 37,
-   .vl_vfpd= 3,
-   .vl_cmd_allow_len = 0xf,
-
-   .win_id = 3,
-   .cfg_gpio   = cfg_lcd_gpio,
-   .backlight_on   = NULL,
-   .lcd_power_on   = NULL,
-   .reset_lcd  = NULL,
-   .dual_lcd_enabled = 0,
-
-   .init_delay = 0,
-   .power_on_delay = 0,
-   .reset_delay= 0,
-   .interface_mode = FIMD_RGB_INTERFACE,
-   .dp_enabled = 1,
-};
-
-static struct edp_device_info edp_info = {
-   .disp_info = {
-   .h_res = 2560,
-   .h_sync_width = 32,
-   .h_back_porch = 80,
-   .h_front_porch = 48,
-   .v_res = 1600,
-   .v_sync_width  = 6,
-   .v_back_porch = 37,
-   .v_front_porch = 3,
-   .v_sync_rate = 60,
-   },
-   .lt_info = {
-   .lt_status = DP_LT_NONE,
-   },
-   .video_info = {
-   .master_mode = 0,
-   .bist_mode = DP_DISABLE,
-   .bist_pattern = NO_PATTERN,
-   .h_sync_polarity = 0,
-   .v_sync_polarity = 0,
-   .interlaced = 0,
-   .color_space = COLOR_RGB,
-   .dynamic_range = VESA,
-   .ycbcr_coeff = COLOR_YCBCR601,
-   .color_depth = COLOR_8,
-   },
-};
-
-static struct exynos_dp_platform_data dp_platform_data = {
-   .phy_enable = set_dp_phy_ctrl,
-   .edp_dev_info   = edp_info,
-};
-
-void init_panel_info(vidinfo_t *vid)
+void exynos_lcd_power_on(void)
 {
-   vid-rgb_mode   = MODE_RGB_P;
+   int ret;
+
+#ifdef CONFIG_POWER_TPS65090
+   ret = tps65090_init();
+   if (ret  0) {
+   printf(%s: tps65090_init() failed\n, __func__);
+   return;
+   }
+
+   tps65090_fet_enable(6);
+#endif
+
+   mdelay(5);
+
+   /* TODO(ajaykumar...@samsung.com): Use device tree */
+   gpio_direction_output(EXYNOS5420_GPIO_X35, 1);  /* EDP_SLP# */
+   mdelay(10);
+   gpio_direction_output(EXYNOS5420_GPIO_Y77, 1);  /* EDP_RST# */
+   gpio_direction_input(EXYNOS5420_GPIO_X26);  /* EDP_HPD */
+   gpio_set_pull(EXYNOS5420_GPIO_X26, 

[U-Boot] [TEST_ONLY V2 10/10] Pit WIP

2014-06-26 Thread Ajay Kumar
WIP patch to enable cros-ec on peach_pit.

Signed-off-by: Simon Glass s...@chromium.org
---
 drivers/misc/cros_ec_spi.c|   4 +-
 drivers/power/pmic/Makefile   |   3 +-
 drivers/power/pmic/pmic_tps65090_ec.c | 212 ++
 drivers/spi/exynos_spi.c  |   9 +-
 drivers/spi/spi.c |   2 +
 include/configs/exynos5-dt.h  |   2 +-
 include/configs/peach-pit.h   |   2 +
 include/power/tps65090_pmic.h |   6 +
 8 files changed, 232 insertions(+), 8 deletions(-)
 create mode 100644 drivers/power/pmic/pmic_tps65090_ec.c

diff --git a/drivers/misc/cros_ec_spi.c b/drivers/misc/cros_ec_spi.c
index 7df709c..015333f 100644
--- a/drivers/misc/cros_ec_spi.c
+++ b/drivers/misc/cros_ec_spi.c
@@ -98,7 +98,7 @@ int cros_ec_spi_command(struct cros_ec_dev *dev, uint8_t cmd, 
int cmd_version,
}
 
out = dev-dout;
-   out[0] = cmd_version;
+   out[0] = EC_CMD_VERSION0 + cmd_version;
out[1] = cmd;
out[2] = (uint8_t)dout_len;
memcpy(out + 3, dout, dout_len);
@@ -165,7 +165,7 @@ int cros_ec_spi_decode_fdt(struct cros_ec_dev *dev, const 
void *blob)
  */
 int cros_ec_spi_init(struct cros_ec_dev *dev, const void *blob)
 {
-   dev-spi = spi_setup_slave_fdt(blob, dev-parent_node, dev-node);
+   dev-spi = spi_setup_slave_fdt(blob, dev-node, dev-parent_node);
if (!dev-spi) {
debug(%s: Could not setup SPI slave\n, __func__);
return -1;
diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
index a472f61..e7b07eb 100644
--- a/drivers/power/pmic/Makefile
+++ b/drivers/power/pmic/Makefile
@@ -11,7 +11,8 @@ obj-$(CONFIG_POWER_MAX8997) += pmic_max8997.o
 obj-$(CONFIG_POWER_MUIC_MAX8997) += muic_max8997.o
 obj-$(CONFIG_POWER_MAX77686) += pmic_max77686.o
 obj-$(CONFIG_POWER_PFUZE100) += pmic_pfuze100.o
-obj-$(CONFIG_POWER_TPS65090) += pmic_tps65090.o
+obj-$(CONFIG_POWER_TPS65090_I2C) += pmic_tps65090.o
+obj-$(CONFIG_POWER_TPS65090_EC) += pmic_tps65090_ec.o
 obj-$(CONFIG_POWER_TPS65217) += pmic_tps65217.o
 obj-$(CONFIG_POWER_TPS65218) += pmic_tps65218.o
 obj-$(CONFIG_POWER_TPS65910) += pmic_tps65910.o
diff --git a/drivers/power/pmic/pmic_tps65090_ec.c 
b/drivers/power/pmic/pmic_tps65090_ec.c
new file mode 100644
index 000..93b7923
--- /dev/null
+++ b/drivers/power/pmic/pmic_tps65090_ec.c
@@ -0,0 +1,212 @@
+/*
+ * Copyright (c) 2013 The Chromium OS Authors. All rights reserved.
+ * Use of this source code is governed by a BSD-style license that can be
+ * found in the LICENSE file.
+ *
+ * Alternatively, this software may be distributed under the terms of the
+ * GNU General Public License (GPL) version 2 as published by the Free
+ * Software Foundation.
+ */
+
+#include common.h
+#include cros_ec.h
+#include errno.h
+#include power/tps65090_pmic.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define TPS65090_ADDR  0x48
+
+static struct tps65090 {
+   struct cros_ec_dev *dev;/* The CROS_EC device */
+} config;
+
+/* TPS65090 register addresses */
+enum {
+   REG_FET1_CTRL = 0x0f,
+   REG_FET2_CTRL,
+   REG_FET3_CTRL,
+   REG_FET4_CTRL,
+   REG_FET5_CTRL,
+   REG_FET6_CTRL,
+   REG_FET7_CTRL,
+   TPS65090_NUM_REGS,
+};
+
+enum {
+   MAX_FET_NUM = 7,
+   MAX_CTRL_READ_TRIES = 5,
+
+   /* TPS65090 FET_CTRL register values */
+   FET_CTRL_TOFET  = 1  7,  /* Timeout, startup, overload */
+   FET_CTRL_PGFET  = 1  4,  /* Power good for FET status */
+   FET_CTRL_WAIT   = 3  2,  /* Overcurrent timeout max */
+   FET_CTRL_ADENFET= 1  1,  /* Enable output auto discharge */
+   FET_CTRL_ENFET  = 1  0,  /* Enable FET */
+};
+
+/**
+ * tps65090_read - read a byte from tps6090
+ *
+ * @param reg  The register address to read from.
+ * @param val  We'll return value value read here.
+ * @return 0 if ok; error if EC returns failure.
+ */
+static int tps65090_read(u32 reg, u8 *val)
+{
+   return cros_ec_i2c_xfer(config.dev, TPS65090_ADDR, reg, 1,
+   val, 1, true);
+}
+
+/**
+ * tps65090_write - write a byte to tps6090
+ *
+ * @param reg  The register address to write to.
+ * @param val  The value to write.
+ * @return 0 if ok; error if EC returns failure.
+ */
+static int tps65090_write(u32 reg, u8 val)
+{
+   return cros_ec_i2c_xfer(config.dev, TPS65090_ADDR, reg, 1,
+   val, 1, false);
+}
+
+/**
+ * Checks for a valid FET number
+ *
+ * @param fet_id   FET number to check
+ * @return 0 if ok, -1 if FET value is out of range
+ */
+static int tps65090_check_fet(unsigned int fet_id)
+{
+   if (fet_id == 0 || fet_id  MAX_FET_NUM) {
+   debug(parameter fet_id is out of range, %u not in 1 ~ %u\n,
+ fet_id, MAX_FET_NUM);
+   return -1;
+   }
+
+   return 0;
+}
+
+/**
+ * Set the power 

Re: [U-Boot] [PATCH] mx25pdk: Remove CONFIG_SYS_GENERIC_BOARD

2014-06-26 Thread Stefano Babic
Hi Fabio,

On 25/06/2014 19:45, Fabio Estevam wrote:
 From: Fabio Estevam fabio.este...@freescale.com
 
 With CONFIG_SYS_GENERIC_BOARD the board hangs after issuing a 'save' command.
 
 Remove CONFIG_SYS_GENERIC_BOARD until this issue can be fixed properly.
 
 Signed-off-by: Fabio Estevam fabio.este...@freescale.com
 ---
 Stefano,
 
 I will not have time to debug this prior to 2014.07 version.
 
 It would be better if this patch could be applied so that mx25pdk keeps 
 working
 in 2014.07. I can then investigate and provide a proper fix after 2014.07 is 
 out.

Ok, understood - applied to u-boot-imx, thanks !

Best regards,
Stefano Babic

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


Re: [U-Boot] [PATCH 1/3] i2c: tegra: use repeated start for reads

2014-06-26 Thread Joakim Tjernlund
 From: Stephen Warren swar...@wwwdotorg.org
 To: u-boot@lists.denx.de, Heiko Schocher h...@denx.de, 
 Cc: Stephen Warren swar...@nvidia.com, Tom Warren twar...@nvidia.com
 Date: 2014/06/25 19:05
 Subject: [U-Boot] [PATCH 1/3] i2c: tegra: use repeated start for reads
 Sent by: u-boot-boun...@lists.denx.de
 
 From: Stephen Warren swar...@nvidia.com
 
 I2C read transactions are typically implemented as follows:
 
 START(write) address REPEATED_START(read) data... STOP
 
 However, Tegra's I2C driver currently implements reads as follows:
 
 START(write) address STOP START(read) data... STOP
 
 This sequence confuses at least the AS3722 PMIC on the Jetson TK1 board,
 leading to corrupted read data in some cases. Fix the driver to chain
 the transactions together using repeated starts to solve this.

While I agree to use Repeated START I just wanted to share this:
A common reason for STOP START(read) sequence not working sometimes is 
that
the driver initializes STOP but does not wait for the STOP to complete
before issuing a START.

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


[U-Boot] [PULL] : Please pull u-boot-imx

2014-06-26 Thread Stefano Babic
Hi Albert,

please pull from u-boot-imx, thanks !

The following changes since commit 49692c5f517d8e44ed9db0de778728fe7d2a300c:

  net/designware: Make DMA burst length configurable and reduce by
default (2014-05-25 17:23:58 +0200)

are available in the git repository at:

  git://www.denx.de/git/u-boot-imx.git master

for you to fetch changes up to 3f4c01d9f9d38e383f004dcd06c0d5661f2a57e0:

  mx25pdk: Remove CONFIG_SYS_GENERIC_BOARD (2014-06-26 10:17:19 +0200)


Eric Nelson (1):
  serial_mxc: disable new features of autobaud detection

Fabio Estevam (10):
  mx6sabreauto: Add the mx6dual-lite variant
  mx6sabred: Add PFUZE100 PMIC support
  mx25pdk: Add generic board support
  mx6: Fix definition of IOMUXC_GPR12_DEVICE_TYPE_RC
  embestmx6boards: Fix CONFIG_CONSOLE_DEV
  embestmx6boards: Fix the dtb file name for riotboard
  mx28evk: Fix warning when CONFIG_ENV_IS_IN_SPI_FLASH is selected
  mx28evk: Add a target for SPI NOR boot
  mx28evk: Add documentation on how to boot from SPI NOR
  mx25pdk: Remove CONFIG_SYS_GENERIC_BOARD

Marek Vasut (1):
  arm: mx5: Enable CONFIG_SYS_GENERIC_BOARD on M53EVK

Masahiro Yamada (1):
  spl: consolidate arch/arm/include/asm/arch-*/spl.h

Shawn Guo (1):
  mx6: drop ARM errata 742230

Stefano Babic (3):
  MX25: fix build due to missing sys_proto.h
  imx: correct HAB status for new chip TO
  vf610: fix build due to missing sys_proto.h

Tim Harvey (12):
  spl: nand: add support for mxs nand
  mx6: add common SPL configuration
  mx6: add boot device support for SPL
  imx: add comments and remove unused struct fields
  mx6: add structs for mmdc and ddr iomux registers
  mx6: add mmdc configuration for MX6Q/MX6DL
  imx: iomux: add macros to setup iomux for multiple SoC types
  imx: ventana: split read_eeprom into standalone file
  imx: ventana: auto-configure for IMX6Q vs IMX6DL
  imx: ventana: switch to SPL
  dwc_ahsata: return failure for MX6 if not IMX6Q/IMX6D
  imx: sata: return failure if not IMX6Q/IMX6D

 arch/arm/cpu/arm720t/tegra-common/spl.c |   2 +-
 arch/arm/cpu/armv7/mx6/Makefile |   1 +
 arch/arm/cpu/armv7/mx6/ddr.c| 490 +++
 arch/arm/cpu/armv7/mx6/hab.c|  73 +++-
 arch/arm/imx-common/Makefile|   1 +
 arch/arm/imx-common/cpu.c   |  16 +-
 arch/arm/imx-common/iomux-v3.c  |  18 +-
 arch/arm/imx-common/sata.c  |   7 +-
 arch/arm/imx-common/spl.c   |  81 
 arch/arm/include/asm/arch-at91/spl.h|  24 --
 arch/arm/include/asm/arch-davinci/spl.h |  16 -
 arch/arm/include/asm/arch-mx35/spl.h|  22 -
 arch/arm/include/asm/arch-mx5/spl.h |  13 -
 arch/arm/include/asm/arch-mx6/hab.h |  17 +-
 arch/arm/include/asm/arch-mx6/imx-regs.h|   2 +
 arch/arm/include/asm/arch-mx6/iomux.h   |   2 +-
 arch/arm/include/asm/arch-mx6/mx6-ddr.h | 231 +++
 arch/arm/include/asm/arch-mx6/sys_proto.h   |   4 +-
 arch/arm/include/asm/arch-tegra114/spl.h|  22 -
 arch/arm/include/asm/arch-tegra124/spl.h|  13 -
 arch/arm/include/asm/arch-tegra20/spl.h |  12 -
 arch/arm/include/asm/arch-tegra30/spl.h |  12 -
 arch/arm/include/asm/imx-common/iomux-v3.h  |  25 ++
 arch/arm/include/asm/spl.h  |  20 +
 board/denx/m53evk/m53evk.c  |   2 +-
 board/freescale/mx28evk/README  |  22 +-
 board/freescale/mx6qsabreauto/mx6dl.cfg | 130 ++
 board/freescale/mx6sabresd/mx6sabresd.c |  84 
 board/gateworks/gw_ventana/Makefile |   3 +-
 board/gateworks/gw_ventana/README   |  92 +++--
 board/gateworks/gw_ventana/eeprom.c |  89 +
 board/gateworks/gw_ventana/gw_ventana.c | 597
+++-
 board/gateworks/gw_ventana/gw_ventana.cfg   |  15 -
 board/gateworks/gw_ventana/gw_ventana_spl.c | 419 +++
 board/gateworks/gw_ventana/ventana_eeprom.h |  11 +
 boards.cfg  |   8 +-
 doc/README.mxs  |  26 ++
 drivers/block/dwc_ahsata.c  |   5 +
 drivers/mtd/nand/Makefile   |   1 +
 drivers/mtd/nand/mxs_nand_spl.c | 231 +++
 drivers/serial/serial_mxc.c |   4 +-
 include/configs/embestmx6boards.h   |   4 +-
 include/configs/gw_ventana.h|  11 +
 include/configs/imx6_spl.h  |  71 
 include/configs/m53evk.h|   1 +
 include/configs/mx28evk.h   |   5 +-
 include/configs/mx6_common.h|   1 -
 include/configs/mx6qsabreauto.h |   4 +
 include/configs/mx6sabresd.h|  12 +
 include/power/pfuze100_pmic.h   |   4 +
 50 files changed, 2473 insertions(+), 503 deletions(-)
 create mode 

Re: [U-Boot] [TEST_ONLY V2 10/10] Pit WIP

2014-06-26 Thread Wolfgang Denk
Dear Ajay Kumar,

In message 1403769668-2026-11-git-send-email-ajaykumar...@samsung.com you 
wrote:
 WIP patch to enable cros-ec on peach_pit.

Do you think anybody would be able to figure out what this is supposed
to mean?  I can't...

 @@ -0,0 +1,212 @@
 +/*
 + * Copyright (c) 2013 The Chromium OS Authors. All rights reserved.
 + * Use of this source code is governed by a BSD-style license that can be
 + * found in the LICENSE file.
 + *
 + * Alternatively, this software may be distributed under the terms of the
 + * GNU General Public License (GPL) version 2 as published by the Free
 + * Software Foundation.
 + */

Please use SPDX license tags, and make sure to use GPL-2.0+ rather
than GPL-2.0

 diff --git a/drivers/spi/exynos_spi.c b/drivers/spi/exynos_spi.c
 index c92276f..2969184 100644
 --- a/drivers/spi/exynos_spi.c
 +++ b/drivers/spi/exynos_spi.c
 @@ -428,10 +428,6 @@ void spi_cs_activate(struct spi_slave *slave)
   clrbits_le32(spi_slave-regs-cs_reg, SPI_SLAVE_SIG_INACT);
   debug(Activate CS, bus %d\n, spi_slave-slave.bus);
   spi_slave-skip_preamble = spi_slave-mode  SPI_PREAMBLE;
 -
 - /* Remember time of this transaction so we can honour the bus delay */
 - if (spi_slave-bus-deactivate_delay_us)
 - spi_slave-last_transaction_us = timer_get_us();
  }
  
  /**
 @@ -445,6 +441,11 @@ void spi_cs_deactivate(struct spi_slave *slave)
   struct exynos_spi_slave *spi_slave = to_exynos_spi(slave);
  
   setbits_le32(spi_slave-regs-cs_reg, SPI_SLAVE_SIG_INACT);
 +
 + /* Remember time of this transaction so we can honour the bus delay */
 + if (spi_slave-bus-deactivate_delay_us)
 + spi_slave-last_transaction_us = timer_get_us();
 +
   debug(Deactivate CS, bus %d\n, spi_slave-slave.bus);
  }

Is this really a related change, or shoudl that go into a separate
commit?

 diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
 index 7ddea9b..7d81fbd 100644
 --- a/drivers/spi/spi.c
 +++ b/drivers/spi/spi.c
 @@ -53,6 +53,8 @@ struct spi_slave *spi_base_setup_slave_fdt(const void 
 *blob, int busnum,
   mode |= SPI_CPHA;
   if (fdtdec_get_bool(blob, node, spi-cs-high))
   mode |= SPI_CS_HIGH;
 + if (fdtdec_get_bool(blob, node, spi-half-duplex))
 + mode |= SPI_PREAMBLE;
   return spi_setup_slave(busnum, cs, max_hz, mode);

Ditto?

 diff --git a/include/configs/exynos5-dt.h b/include/configs/exynos5-dt.h
 index e36a031..4e316b9 100644
 --- a/include/configs/exynos5-dt.h
 +++ b/include/configs/exynos5-dt.h
 @@ -37,8 +37,8 @@
  #define CONFIG_TRACE_EARLY_ADDR  0x5000
  
  /* Keep L2 Cache Disabled */
 -#define CONFIG_SYS_DCACHE_OFF
  #define CONFIG_SYS_CACHELINE_SIZE64
 +#define CONFIG_CMD_CACHE

Ditto?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Politics:  A  strife  of  interests  masquerading  as  a  contest  of
principles. The conduct of public affairs for private advantage.
- Ambrose Bierce
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


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

2014-06-26 Thread Wolfgang Denk
Dear Ajay Kumar,

In message 1403769668-2026-6-git-send-email-ajaykumar...@samsung.com you 
wrote:
...
 + * Use of this source code is governed by a BSD-style license that can be
 + * found in the LICENSE file.

NAK.  We need precise licnese terms; just mentioning some LICENSE
file without even telling us where to find it is definitely
insufficient.

Please also make sure to use SPDX tags instead.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Engineering without management is art.   - Jeff Johnson
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 1/6] ARM: m28evk: add needed commands and options

2014-06-26 Thread Marek Vasut
- env ask, env grep and setexpr are needed for commissioning
- add support for ext4 file systems
- adjust default environment to use ext4 commands
- add write support for (V)FAT and EXT4
- add bitmap and splashscreen support
- print timestamp information for images

Signed-off-by: Marek Vasut ma...@denx.de
Cc: Stefano Babic sba...@denx.de
---
 include/configs/m28evk.h | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/include/configs/m28evk.h b/include/configs/m28evk.h
index 3e387c4..c3bdd4b 100644
--- a/include/configs/m28evk.h
+++ b/include/configs/m28evk.h
@@ -12,17 +12,25 @@
 #define MACH_TYPE_M28EVK   3613
 #define CONFIG_MACH_TYPE   MACH_TYPE_M28EVK
 
+#define CONFIG_FIT
+
+#define CONFIG_TIMESTAMP   /* Print image info with timestamp */
+
 /* U-Boot Commands */
 #define CONFIG_SYS_NO_FLASH
 #include config_cmd_default.h
 #define CONFIG_DISPLAY_CPUINFO
 #define CONFIG_DOS_PARTITION
+#define CONFIG_FAT_WRITE
 
+#define CONFIG_CMD_ASKENV
+#define CONFIG_CMD_BMP
 #define CONFIG_CMD_CACHE
 #define CONFIG_CMD_DATE
 #define CONFIG_CMD_DHCP
 #define CONFIG_CMD_EEPROM
-#define CONFIG_CMD_EXT2
+#define CONFIG_CMD_EXT4
+#define CONFIG_CMD_EXT4_WRITE
 #define CONFIG_CMD_FAT
 #define CONFIG_CMD_GPIO
 #define CONFIG_CMD_GREPENV
@@ -145,7 +153,7 @@
 #defineCONFIG_BMP_16BPP
 #defineCONFIG_VIDEO_BMP_RLE8
 #defineCONFIG_VIDEO_BMP_GZIP
-#defineCONFIG_SYS_VIDEO_LOGO_MAX_SIZE  (512  10)
+#defineCONFIG_SYS_VIDEO_LOGO_MAX_SIZE  (2  20)
 #endif
 
 /* Booting Linux */
-- 
2.0.0.rc2

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


[U-Boot] [PATCH 3/6] ARM: m28evk: Update default environment

2014-06-26 Thread Marek Vasut
From: Lothar Rubusch lot...@denx.de

Signed-off-by: Marek Vasut ma...@denx.de
Signed-off-by: Lothar Rubusch lot...@denx.de
---
 include/configs/m28evk.h | 87 ++--
 1 file changed, 84 insertions(+), 3 deletions(-)

diff --git a/include/configs/m28evk.h b/include/configs/m28evk.h
index 89f9785..fccd29d 100644
--- a/include/configs/m28evk.h
+++ b/include/configs/m28evk.h
@@ -157,14 +157,28 @@
 
 /* Booting Linux */
 #define CONFIG_BOOTDELAY   3
-#define CONFIG_BOOTFILEuImage
+#define CONFIG_BOOTFILEfitImage
 #define CONFIG_BOOTARGSconsole=ttyAMA0,115200n8 
-#define CONFIG_BOOTCOMMAND run bootcmd_net
+#define CONFIG_BOOTCOMMAND run mmc_mmc
 #define CONFIG_LOADADDR0x4200
 #define CONFIG_SYS_LOAD_ADDR   CONFIG_LOADADDR
 
 /* Extra Environment */
+#define CONFIG_PREBOOT run try_bootscript
+#define CONFIG_HOSTNAMEm28evk
+
 #define CONFIG_EXTRA_ENV_SETTINGS  \
+   consdev=ttyAMA0\0 \
+   baudrate=115200\0 \
+   bootdev=/dev/mmcblk0p2\0  \
+   rootdev=/dev/mmcblk0p3\0  \
+   netdev=eth0\0 \
+   hostname=m28evk\0 \
+   rootpath=/opt/eldk-5.5/armv5te/rootfs-qte-sdk\0   \
+   kernel_addr_r=0x4200\0\
+   videomode=video=ctfb:x:800,y:480,depth:18,mode:0,pclk:30066,  \
+   le:0,ri:256,up:0,lo:45,hs:1,vs:1,sync:100663296,  \
+   vmode:0\0 \
update_nand_full_filename=u-boot.nand\0   \
update_nand_firmware_filename=u-boot.sb\0 \
update_sd_firmware_filename=u-boot.sd\0   \
@@ -180,7 +194,7 @@
if tftp ${update_nand_full_filename} ; then   \
run update_nand_get_fcb_size ;\
nand scrub -y 0x0 ${filesize} ;   \
-   nand write.raw ${loadaddr} 0x0 ${fcb_sz} ;\
+   nand write.raw ${loadaddr} 0x0 ${fcb_sz} ;\
setexpr update_off ${loadaddr} + ${update_nand_fcb} ;  \
setexpr update_sz ${filesize} - ${update_nand_fcb} ;  \
nand write ${update_off} ${update_nand_fcb} ${update_sz} ;  \
@@ -202,6 +216,73 @@
setexpr fw_sz ${fw_sz} + 1 ;  \
mmc write ${loadaddr} 0x800 ${fw_sz} ;\
fi ;  \
+   fi\0  \
+   addcons=  \
+   setenv bootargs ${bootargs}   \
+   console=${consdev},${baudrate}\0  \
+   addip=\
+   setenv bootargs ${bootargs}   \
+   ip=${ipaddr}:${serverip}:${gatewayip}:\
+   ${netmask}:${hostname}:${netdev}:off\0\
+   addmisc=  \
+   setenv bootargs ${bootargs} ${miscargs}\0 \
+   adddfltmtd=   \
+   if test \x${mtdparts}\ == \x\ ; then  \
+   mtdparts default ;\
+   fi\0  \
+   addmtd=   \
+   run adddfltmtd ;  \
+   setenv bootargs ${bootargs} ${mtdparts}\0 \
+   addargs=run addcons addmtd addmisc\0  \
+   mmcload=  \
+   mmc rescan ;  \
+   ext4load mmc 0:2 ${kernel_addr_r} ${bootfile}\0   \
+   ubiload=  \
+   ubi part UBI ; ubifsmount ubi0:rootfs ;   \
+   ubifsload ${kernel_addr_r} /boot/${bootfile}\0\
+   netload=  \
+   tftp ${kernel_addr_r} ${hostname}/${bootfile}\0   \
+   miscargs=nohlt panic=1\0  \
+   mmcargs=setenv bootargs root=${rootdev} rw rootwait\0 \
+   ubiargs=  \
+   setenv 

[U-Boot] [PATCH 2/6] ARM: m28evk: Adjust mtdparts

2014-06-26 Thread Marek Vasut
Adjust the mtdparts to also consider factory-programmed config block.

Signed-off-by: Marek Vasut ma...@denx.de
---
 include/configs/m28evk.h | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/include/configs/m28evk.h b/include/configs/m28evk.h
index c3bdd4b..89f9785 100644
--- a/include/configs/m28evk.h
+++ b/include/configs/m28evk.h
@@ -64,8 +64,8 @@
 #if defined(CONFIG_CMD_NAND)  defined(CONFIG_ENV_IS_IN_NAND)
 #define CONFIG_ENV_SIZE_REDUND CONFIG_ENV_SIZE
 #define CONFIG_ENV_SECT_SIZE   (128 * 1024)
-#define CONFIG_ENV_RANGE   (512 * 1024)
-#define CONFIG_ENV_OFFSET  0x30
+#define CONFIG_ENV_RANGE   (4 * CONFIG_ENV_SECT_SIZE)
+#define CONFIG_ENV_OFFSET  (24 * CONFIG_ENV_SECT_SIZE) /* 3 MiB */
 #define CONFIG_ENV_OFFSET_REDUND   \
(CONFIG_ENV_OFFSET + CONFIG_ENV_RANGE)
 
@@ -79,13 +79,12 @@
 #define MTDIDS_DEFAULT nand0=gpmi-nand
 #define MTDPARTS_DEFAULT   \
mtdparts=gpmi-nand:   \
-   3m(bootloader)ro, \
-   512k(environment),\
-   512k(redundant-environment),  \
-   4m(kernel),   \
-   128k(fdt),\
-   8m(ramdisk),  \
-   -(filesystem)
+   3m(u-boot),   \
+   512k(env1),   \
+   512k(env2),   \
+   14m(boot),\
+   238m(data),   \
+   -@4096k(UBI)
 #else
 #define CONFIG_ENV_IS_NOWHERE
 #endif
-- 
2.0.0.rc2

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


[U-Boot] [PATCH 4/6] ARM: m53evk: add needed commands and options

2014-06-26 Thread Marek Vasut
- env ask, env grep and setexpr are needed for commissioning
- add support for ext4 file systems
- adjust default environment to use ext4 commands
- add write support for (V)FAT and EXT4
- add bitmap and splashscreen support
- print timestamp information for images

Signed-off-by: Marek Vasut ma...@denx.de
Signed-off-by: Wolfgang Denk w...@denx.de
Cc: Stefano Babic sba...@denx.de
---
 include/configs/m53evk.h | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/include/configs/m53evk.h b/include/configs/m53evk.h
index f401470..e8eb521 100644
--- a/include/configs/m53evk.h
+++ b/include/configs/m53evk.h
@@ -18,17 +18,26 @@
 #define CONFIG_REVISION_TAG
 #define CONFIG_SYS_NO_FLASH
 
+#define CONFIG_FIT
+
+#define CONFIG_TIMESTAMP   /* Print image info with timestamp */
+
 /*
  * U-Boot Commands
  */
 #include config_cmd_default.h
 #define CONFIG_DISPLAY_BOARDINFO
 #define CONFIG_DOS_PARTITION
+#define CONFIG_FAT_WRITE
 
+#define CONFIG_CMD_ASKENV
+#define CONFIG_CMD_BMP
 #define CONFIG_CMD_DATE
 #define CONFIG_CMD_DHCP
-#define CONFIG_CMD_EXT2
+#define CONFIG_CMD_EXT4
+#define CONFIG_CMD_EXT4_WRITE
 #define CONFIG_CMD_FAT
+#define CONFIG_CMD_GREPENV
 #define CONFIG_CMD_I2C
 #define CONFIG_CMD_MII
 #define CONFIG_CMD_MMC
@@ -36,6 +45,7 @@
 #define CONFIG_CMD_NET
 #define CONFIG_CMD_PING
 #define CONFIG_CMD_SATA
+#define CONFIG_CMD_SETEXPR
 #define CONFIG_CMD_USB
 #define CONFIG_VIDEO
 
@@ -213,10 +223,14 @@
 #define CONFIG_VGA_AS_SINGLE_DEVICE
 #define CONFIG_SYS_CONSOLE_IS_IN_ENV
 #define CONFIG_VIDEO_BMP_RLE8
+#define CONFIG_VIDEO_BMP_GZIP
 #define CONFIG_SPLASH_SCREEN
+#define CONFIG_SPLASHIMAGE_GUARD
+#define CONFIG_SPLASH_SCREEN_ALIGN
 #define CONFIG_BMP_16BPP
 #define CONFIG_VIDEO_LOGO
-#define CONFIG_IPUV3_CLK   2
+#define CONFIG_SYS_VIDEO_LOGO_MAX_SIZE (2  20)
+#define CONFIG_IPUV3_CLK   2
 #endif
 
 /*
-- 
2.0.0.rc2

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


[U-Boot] [PATCH 5/6] ARM: m53evk: Adjust mtdparts settings

2014-06-26 Thread Marek Vasut
Adjust the mtdparts settings to allow for alternative boot images and
for using UBI.

Signed-off-by: Marek Vasut ma...@denx.de
Signed-off-by: Wolfgang Denk w...@denx.de
Cc: Stefano Babic sba...@denx.de
---
 include/configs/m53evk.h | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/include/configs/m53evk.h b/include/configs/m53evk.h
index e8eb521..e0e7aa5 100644
--- a/include/configs/m53evk.h
+++ b/include/configs/m53evk.h
@@ -128,8 +128,8 @@
 #define CONFIG_ENV_IS_IN_NAND
 #define CONFIG_ENV_SIZE_REDUND CONFIG_ENV_SIZE
 #define CONFIG_ENV_SECT_SIZE   (128 * 1024)
-#define CONFIG_ENV_RANGE   (512 * 1024)
-#define CONFIG_ENV_OFFSET  0x10
+#define CONFIG_ENV_RANGE   (4 * CONFIG_ENV_SECT_SIZE)
+#define CONFIG_ENV_OFFSET  (8 * CONFIG_ENV_SECT_SIZE) /* 1 MiB */
 #define CONFIG_ENV_OFFSET_REDUND   \
(CONFIG_ENV_OFFSET + CONFIG_ENV_RANGE)
 
@@ -143,13 +143,12 @@
 #define MTDIDS_DEFAULT nand0=mxc_nand
 #define MTDPARTS_DEFAULT   \
mtdparts=mxc_nand:\
-   1m(bootloader)ro, \
-   512k(environment),\
-   512k(redundant-environment),  \
-   4m(kernel),   \
-   128k(fdt),\
-   8m(ramdisk),  \
-   -(filesystem)
+   1024k(u-boot),\
+   512k(env1),   \
+   512k(env2),   \
+   14m(boot),\
+   240m(data),   \
+   -@2048k(UBI)
 #else
 #define CONFIG_ENV_IS_NOWHERE
 #endif
-- 
2.0.0.rc2

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


[U-Boot] [PATCH 6/6] ARM: m53evk: Update default environment

2014-06-26 Thread Marek Vasut
From: Lothar Rubusch lot...@denx.de

Signed-off-by: Marek Vasut ma...@denx.de
Signed-off-by: Lothar Rubusch lot...@denx.de
Signed-off-by: Wolfgang Denk w...@denx.de
---
 include/configs/m53evk.h | 87 +++-
 1 file changed, 86 insertions(+), 1 deletion(-)

diff --git a/include/configs/m53evk.h b/include/configs/m53evk.h
index e0e7aa5..b0edb08 100644
--- a/include/configs/m53evk.h
+++ b/include/configs/m53evk.h
@@ -165,6 +165,7 @@
 #define CONFIG_FEC_XCV_TYPERMII
 #define CONFIG_PHYLIB
 #define CONFIG_PHY_MICREL
+#define CONFIG_ETHPRIMEFEC0
 #endif
 
 /*
@@ -240,9 +241,10 @@
 #define CONFIG_REVISION_TAG
 #define CONFIG_SETUP_MEMORY_TAGS
 #define CONFIG_BOOTDELAY   3
-#define CONFIG_BOOTFILEm53evk/uImage
+#define CONFIG_BOOTFILEfitImage
 #define CONFIG_BOOTARGSconsole=ttymxc1,115200
 #define CONFIG_LOADADDR0x7080
+#define CONFIG_BOOTCOMMAND run mmc_mmc
 #define CONFIG_SYS_LOAD_ADDR   CONFIG_LOADADDR
 #define CONFIG_OF_LIBFDT
 
@@ -269,4 +271,87 @@
 #define CONFIG_SYS_NAND_SIZE   (256 * 1024 * 1024)
 #define CONFIG_SYS_NAND_BAD_BLOCK_POS  0
 
+/*
+ * Extra Environments
+ */
+#define CONFIG_PREBOOT run try_bootscript
+#define CONFIG_HOSTNAMEm53evk
+
+#define CONFIG_EXTRA_ENV_SETTINGS  \
+   consdev=ttymxc1\0 \
+   baudrate=115200\0 \
+   bootscript=boot.scr\0 \
+   bootdev=/dev/mmcblk0p1\0  \
+   rootdev=/dev/mmcblk0p2\0  \
+   netdev=eth0\0 \
+   rootpath=/opt/eldk-5.5/armv7a-hf/rootfs-qte-sdk\0 \
+   kernel_addr_r=0x7200\0\
+   addcons=  \
+   setenv bootargs ${bootargs}   \
+   console=${consdev},${baudrate}\0  \
+   addip=\
+   setenv bootargs ${bootargs}   \
+   ip=${ipaddr}:${serverip}:${gatewayip}:\
+   ${netmask}:${hostname}:${netdev}:off\0\
+   addmisc=  \
+   setenv bootargs ${bootargs} ${miscargs}\0 \
+   adddfltmtd=   \
+   if test \x${mtdparts}\ == \x\ ; then  \
+   mtdparts default ;\
+   fi\0  \
+   addmtd=   \
+   run adddfltmtd ;  \
+   setenv bootargs ${bootargs} ${mtdparts}\0 \
+   addargs=run addcons addmtd addmisc\0  \
+   mmcload=  \
+   mmc rescan ;  \
+   ext4load mmc 0:1 ${kernel_addr_r} ${bootfile}\0   \
+   ubiload=  \
+   ubi part UBI ; ubifsmount ubi0:rootfs ;   \
+   ubifsload ${kernel_addr_r} /boot/${bootfile}\0\
+   netload=  \
+   tftp ${kernel_addr_r} ${hostname}/${bootfile}\0   \
+   miscargs=nohlt panic=1\0  \
+   mmcargs=setenv bootargs root=${rootdev} rw rootwait\0 \
+   ubiargs=  \
+   setenv bootargs ubi.mtd=5 \
+   root=ubi0:rootfs rootfstype=ubifs\0   \
+   nfsargs=  \
+   setenv bootargs root=/dev/nfs rw  \
+   nfsroot=${serverip}:${rootpath},v3,tcp\0  \
+   mmc_mmc=  \
+   run mmcload mmcargs addargs ; \
+   bootm ${kernel_addr_r}\0  \
+   mmc_ubi=  \
+   run mmcload ubiargs addargs ; \
+   bootm ${kernel_addr_r}\0  \
+   mmc_nfs=  \
+   run mmcload nfsargs addip addargs ;   \
+   bootm ${kernel_addr_r}\0   

Re: [U-Boot] [TEST_ONLY V2 10/10] Pit WIP

2014-06-26 Thread Ajay kumar
Hi Denk,


On Thu, Jun 26, 2014 at 2:16 PM, Wolfgang Denk w...@denx.de wrote:
 Dear Ajay Kumar,

 In message 1403769668-2026-11-git-send-email-ajaykumar...@samsung.com you 
 wrote:
 WIP patch to enable cros-ec on peach_pit.
This Entire patch is a TEST_ONLY since it is still WIP(Work In Progress).
That would mean somebody else is already working on it, but he/she hasn't sent
that patchset yet, and till that comes up in the mailing list, this WIP patch
can be used for testing the dependent patches.
So, this would not be merged into the tree, but I thought its better to send
it with a TEST_ONLY tag, so that maintainers can test this patchset.

Regards,
Ajay Kumar

 Do you think anybody would be able to figure out what this is supposed
 to mean?  I can't...

 @@ -0,0 +1,212 @@
 +/*
 + * Copyright (c) 2013 The Chromium OS Authors. All rights reserved.
 + * Use of this source code is governed by a BSD-style license that can be
 + * found in the LICENSE file.
 + *
 + * Alternatively, this software may be distributed under the terms of the
 + * GNU General Public License (GPL) version 2 as published by the Free
 + * Software Foundation.
 + */

 Please use SPDX license tags, and make sure to use GPL-2.0+ rather
 than GPL-2.0

 diff --git a/drivers/spi/exynos_spi.c b/drivers/spi/exynos_spi.c
 index c92276f..2969184 100644
 --- a/drivers/spi/exynos_spi.c
 +++ b/drivers/spi/exynos_spi.c
 @@ -428,10 +428,6 @@ void spi_cs_activate(struct spi_slave *slave)
   clrbits_le32(spi_slave-regs-cs_reg, SPI_SLAVE_SIG_INACT);
   debug(Activate CS, bus %d\n, spi_slave-slave.bus);
   spi_slave-skip_preamble = spi_slave-mode  SPI_PREAMBLE;
 -
 - /* Remember time of this transaction so we can honour the bus delay */
 - if (spi_slave-bus-deactivate_delay_us)
 - spi_slave-last_transaction_us = timer_get_us();
  }

  /**
 @@ -445,6 +441,11 @@ void spi_cs_deactivate(struct spi_slave *slave)
   struct exynos_spi_slave *spi_slave = to_exynos_spi(slave);

   setbits_le32(spi_slave-regs-cs_reg, SPI_SLAVE_SIG_INACT);
 +
 + /* Remember time of this transaction so we can honour the bus delay */
 + if (spi_slave-bus-deactivate_delay_us)
 + spi_slave-last_transaction_us = timer_get_us();
 +
   debug(Deactivate CS, bus %d\n, spi_slave-slave.bus);
  }

 Is this really a related change, or shoudl that go into a separate
 commit?

 diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
 index 7ddea9b..7d81fbd 100644
 --- a/drivers/spi/spi.c
 +++ b/drivers/spi/spi.c
 @@ -53,6 +53,8 @@ struct spi_slave *spi_base_setup_slave_fdt(const void 
 *blob, int busnum,
   mode |= SPI_CPHA;
   if (fdtdec_get_bool(blob, node, spi-cs-high))
   mode |= SPI_CS_HIGH;
 + if (fdtdec_get_bool(blob, node, spi-half-duplex))
 + mode |= SPI_PREAMBLE;
   return spi_setup_slave(busnum, cs, max_hz, mode);

 Ditto?

 diff --git a/include/configs/exynos5-dt.h b/include/configs/exynos5-dt.h
 index e36a031..4e316b9 100644
 --- a/include/configs/exynos5-dt.h
 +++ b/include/configs/exynos5-dt.h
 @@ -37,8 +37,8 @@
  #define CONFIG_TRACE_EARLY_ADDR  0x5000

  /* Keep L2 Cache Disabled */
 -#define CONFIG_SYS_DCACHE_OFF
  #define CONFIG_SYS_CACHELINE_SIZE64
 +#define CONFIG_CMD_CACHE

 Ditto?

 Best regards,

 Wolfgang Denk

 --
 DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
 HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
 Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
 Politics:  A  strife  of  interests  masquerading  as  a  contest  of
 principles. The conduct of public affairs for private advantage.
 - Ambrose Bierce
 ___
 U-Boot mailing list
 U-Boot@lists.denx.de
 http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH RFC 0/2] usb: host: Add a wrapper layer for mutiple host support

2014-06-26 Thread Marek Vasut
On Thursday, June 26, 2014 at 06:46:11 AM, Vivek Gautam wrote:
 Hi Simon, Marek,
 
 
 On Thu, Jun 26, 2014 at 10:04 AM, Vivek Gautam gautam.vi...@samsung.com
 wrote:
 
 sorry for spamming, the earlier message got sent by mistake.
 
  On Thu, Jun 26, 2014 at 8:00 AM, Simon Glass s...@chromium.org wrote:
  Hi Marek,
  
  On 25 June 2014 02:33, Marek Vasut ma...@denx.de wrote:
  On Wednesday, June 25, 2014 at 08:27:39 AM, Simon Glass wrote:
  [...]
  
 model. Instead, I'd love to see a mean to instantiate each *HCI
 controller and have a USB core which would track those
 instances. The USB core would then be able to call whatever
 generic ops on those instances as needed. Does that make sense
 please ?

True, i understand your point here. I think the second approach i
was talking of, goes in this direction.
I think i could not put it well in words there.

I will prepare an RFC patch for that, and post it as soon as its
ready, so that you can have
a look.
   
   Ah, this would be so very appreciated! Thank you!
  
  Should we consider just going straight for driver model?
  
  I was thinking about that, but I'm worried it might break USB support
  on some platforms. Also, the size of U-Boot will grow on many
  platforms, right?
  
  What do you think ?
  
  If you add CONFIG_DM_USB as an option, you can then pull in either
  usb-uclass.c or the old usb code. Since USB is often tied to a board
  then you can move just that board (or group of boards) to dm.
  
  I am keeping a working tree in u-boot-dm.git which does this for
  serial, SPI, SPI flash and GPIO. It seems to work fairly well as a
  technique for keeping both things in the tree in the interim..
 
 Ok, so i am having a look at the u-boot-dm tree, and also going through the
 documentation for driver-model.
 The driver-model looks a promising choice at the moment keeping in mind
 that later we would need to move to it anyways.
 
 I will try understanding the things and raise a flag in case something
 is not clear.

Even better, if I don't have to do this myself :) I'm really glad to see how 
many people put effort into the USB and how things are coming together nicely. 
Thank you guys!

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


Re: [U-Boot] [TEST_ONLY V2 10/10] Pit WIP

2014-06-26 Thread Wolfgang Denk
Dear Ajay kumar,

In message caec9eqna9dkkhg9cgobawtprkmsn32jorq9uw2wgrdkedpr...@mail.gmail.com 
you wrote:
 
  In message 1403769668-2026-11-git-send-email-ajaykumar...@samsung.com you 
  wrote:
  WIP patch to enable cros-ec on peach_pit.
 This Entire patch is a TEST_ONLY since it is still WIP(Work In Progress).
 That would mean somebody else is already working on it, but he/she hasn't sent
 that patchset yet, and till that comes up in the mailing list, this WIP patch
 can be used for testing the dependent patches.
 So, this would not be merged into the tree, but I thought its better to send
 it with a TEST_ONLY tag, so that maintainers can test this patchset.

I don't think this is an excuse for cryptic or missing description of
what this is about.

If you post something on the mailing list, then please make sure
everybody can understand it.  If the message is not intended to public
audience, then don't post it here and use some other, more private
form of communication.

Thanks.


Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
There you go man, Keep as cool as you can. It riles them  to  believe
that you perceive the web they weave. Keep on being free!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [TEST_ONLY V2 10/10] Pit WIP

2014-06-26 Thread Ajay kumar
On Thu, Jun 26, 2014 at 4:19 PM, Wolfgang Denk w...@denx.de wrote:
 Dear Ajay kumar,

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

  In message 1403769668-2026-11-git-send-email-ajaykumar...@samsung.com 
  you wrote:
  WIP patch to enable cros-ec on peach_pit.
 This Entire patch is a TEST_ONLY since it is still WIP(Work In Progress).
 That would mean somebody else is already working on it, but he/she hasn't 
 sent
 that patchset yet, and till that comes up in the mailing list, this WIP patch
 can be used for testing the dependent patches.
 So, this would not be merged into the tree, but I thought its better to send
 it with a TEST_ONLY tag, so that maintainers can test this patchset.

 I don't think this is an excuse for cryptic or missing description of
 what this is about.

 If you post something on the mailing list, then please make sure
 everybody can understand it.  If the message is not intended to public
 audience, then don't post it here and use some other, more private
 form of communication.
I did mention about this in the cover letter.
Still, I will make sure I elaborate more from the next time.

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


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

2014-06-26 Thread Rob Herring
On Wed, Jun 25, 2014 at 7:16 PM, Steve Rae s...@broadcom.com wrote:
 Rob,


 On 14-06-25 06:59 AM, Rob Herring wrote:

 On Mon, Jun 23, 2014 at 1:37 PM, Steve Rae s...@broadcom.com wrote:

 Rob  Sebastian

 I would appreciate your comments on this issue; I suspect that you had
 some
 ideas regarding the implementation of the fastboot flash and erase
 commands


 I agree with Lukasz's and Marek's comments unless there are good
 reasons not to use it which can't be fixed. Curiously, USB mass
 storage does not use the DFU backend, but I don't know why. Perhaps
 there are incompatibilities or converting it is on the todo list. Are
 your performance concerns measurable or it's just the fact you are
 adding another layer?


 The concern is not performance related -- just the amount of (overhead) code
 required to implement the DFU backend versus calling
 mmc_dev-block_write()
(maybe someone can tell me where to interface into DFU: is it at
 dfu_write() or )

Yes, I believe it is dfu_write.

 I'd really like to see the eMMC backend be a generic block device
 backend. There's no good reason for it to be eMMC/SD specific.


 As I understand it, the block_write callback function is in the
 block_dev_desc_t. Isn't this the part of the generic block device
 interface? Please explain...

There are commands for SATA, SCSI (also SATA), eMMC, IDE, etc. They
are all pretty much the same set of sub-commands and duplicate the
same functionality. Those could all be combined to a single
implementation and/or command for block devices. That part is not DFU
related, but this problem then proliferates to other areas as it has
for DFU. The file drivers/dfu/dfu_mmc.c is mostly generic, but has
some eMMC dependencies with find_mmc_device and mmc_switch_part. So
read and write are already pretty much generic, but there's still some
work to do around device addressing/selection.

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


[U-Boot] [PATCH v3 02/11] board:samsung: add function boot_device() for checking boot medium

2014-06-26 Thread Przemyslaw Marczak
It is possible to boot from a few media devices, especially
using a micro SD or eMMC slots. In this situation depends on
a boot device - some setup can be changeg.

This change adds function:
boot_device() - which returns an OM[1:5] bits value

This allows checking if boot device is SD(0x2).

Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com

---
Changes v3:
- new commit after separate one into two
---
 board/samsung/common/board.c | 10 +-
 include/samsung/misc.h   |  7 +++
 2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
index 9dc7c83..ecf3f76 100644
--- a/board/samsung/common/board.c
+++ b/board/samsung/common/board.c
@@ -41,6 +41,13 @@ int __exynos_power_init(void)
 int exynos_power_init(void)
__attribute__((weak, alias(__exynos_power_init)));
 
+unsigned int boot_device(void)
+{
+   unsigned int om_stat = samsung_get_base_power();
+
+   return BOOT_DEVICE(readl(om_stat));
+}
+
 #if defined CONFIG_EXYNOS_TMU
 /* Boot Time Thermal Analysis for SoC temperature threshold breach */
 static void boot_temp_check(void)
@@ -243,19 +250,20 @@ int board_eth_init(bd_t *bis)
 int board_mmc_init(bd_t *bis)
 {
int ret;
+
 #ifdef CONFIG_DWMMC
/* dwmmc initializattion for available channels */
ret = exynos_dwmmc_init(gd-fdt_blob);
if (ret)
debug(dwmmc init failed\n);
 #endif
-
 #ifdef CONFIG_SDHCI
/* mmc initializattion for available channels */
ret = exynos_mmc_init(gd-fdt_blob);
if (ret)
debug(mmc init failed\n);
 #endif
+
return ret;
 }
 #endif
diff --git a/include/samsung/misc.h b/include/samsung/misc.h
index 10653a1..57bac7d 100644
--- a/include/samsung/misc.h
+++ b/include/samsung/misc.h
@@ -28,4 +28,11 @@ void check_boot_mode(void);
 void draw_logo(void);
 #endif
 
+#define BOOT_DEVICE_SDMMC  0x2
+#define BOOT_DEVICE_MASK   0x1f
+#define BOOT_DEVICE_SHIFT  0x1
+#define BOOT_DEVICE(x) (((x)  BOOT_DEVICE_SHIFT)  BOOT_DEVICE_MASK)
+
+unsigned int boot_device(void);
+
 #endif /* __SAMSUNG_MISC_COMMON_H__ */
-- 
1.9.1

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


[U-Boot] [PATCH v3 05/11] samsung:board: misc_init_r: call set_dfu_alt_info()

2014-06-26 Thread Przemyslaw Marczak
This change enable automatic setting of dfu alt info
on every boot. This is useful in case of booting one
u-boot binary from multiple media.

Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
---
 board/samsung/common/board.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
index f07a900..fd5f21f 100644
--- a/board/samsung/common/board.c
+++ b/board/samsung/common/board.c
@@ -325,6 +325,9 @@ int arch_early_init_r(void)
 #ifdef CONFIG_MISC_INIT_R
 int misc_init_r(void)
 {
+#ifdef CONFIG_SET_DFU_ALT_INFO
+   set_dfu_alt_info();
+#endif
 #ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
set_board_info();
 #endif
-- 
1.9.1

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


[U-Boot] [PATCH v3 08/11] samsung: misc: use board specific functions to set env board info

2014-06-26 Thread Przemyslaw Marczak
This change adds setup of environmental board info using
get_board_name() and get_board_type() functions for config
CONFIG_BOARD_TYPES.

This is useful in case of running many boards with just one config.

Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Cc: Piotr Wilczek p.wilc...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com

---
Changes v2:
- set_board_info: move the bdtype pointer to avoid unused pointer
  compilation warning

Changes v3:
- samsung: misc: change get_board_type_fdt() to get_board_type()
- samsung: misc: set env $boardname using get_board_* functions
  for CONFIG_BOARD_TYPES
- update commit msg
---
 board/samsung/common/misc.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/board/samsung/common/misc.c b/board/samsung/common/misc.c
index 166ea83..fca1fed 100644
--- a/board/samsung/common/misc.c
+++ b/board/samsung/common/misc.c
@@ -74,8 +74,17 @@ void set_board_info(void)
setenv(board_rev, info);
 #endif
 #ifdef CONFIG_OF_LIBFDT
-   snprintf(info, ARRAY_SIZE(info),  %s%x-%s.dtb,
-CONFIG_SYS_SOC, s5p_cpu_id, CONFIG_SYS_BOARD);
+   const char *bdtype = ;
+   const char *bdname = CONFIG_SYS_BOARD;
+
+#ifdef CONFIG_BOARD_TYPES
+   bdtype = get_board_type();
+   bdname = get_board_name();
+   sprintf(info, %s%s, bdname, bdtype);
+   setenv(boardname, info);
+#endif
+   snprintf(info, ARRAY_SIZE(info),  %s%x-%s%s.dtb,
+CONFIG_SYS_SOC, s5p_cpu_id, bdname, bdtype);
setenv(fdtfile, info);
 #endif
 }
-- 
1.9.1

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


[U-Boot] [PATCH v3 01/11] exynos: pinmux: fix the gpio names for exynos4x12 mmc

2014-06-26 Thread Przemyslaw Marczak
This change fixes the bad gpio configuration for the exynos dwmmc.

Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Cc: Beomho Seo beomho@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
Cc: Jaehoon Chung jh80.ch...@samsung.com
---
 arch/arm/cpu/armv7/exynos/pinmux.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/armv7/exynos/pinmux.c 
b/arch/arm/cpu/armv7/exynos/pinmux.c
index 86a0c75..b929486 100644
--- a/arch/arm/cpu/armv7/exynos/pinmux.c
+++ b/arch/arm/cpu/armv7/exynos/pinmux.c
@@ -704,8 +704,8 @@ static int exynos4x12_mmc_config(int peripheral, int flags)
ext_func = S5P_GPIO_FUNC(0x3);
break;
case PERIPH_ID_SDMMC4:
-   start = EXYNOS4_GPIO_K00;
-   start_ext = EXYNOS4_GPIO_K13;
+   start = EXYNOS4X12_GPIO_K00;
+   start_ext = EXYNOS4X12_GPIO_K13;
func = S5P_GPIO_FUNC(0x3);
ext_func = S5P_GPIO_FUNC(0x4);
break;
-- 
1.9.1

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


[U-Boot] [PATCH v3 00/11] Add support to Odroid U3/X2

2014-06-26 Thread Przemyslaw Marczak
This patch set introduces:
- boot device check
- automatic init order of mmc proper driver
- automatic setting of dfu entities which depends on boot device
- pre reset function for board own implementation
- setting board info environment for multi board support
- Odroid U3/X2 support

Przemyslaw Marczak (11):
  exynos: pinmux: fix the gpio names for exynos4x12 mmc
  board:samsung: add function boot_device() for checking boot medium
  board:samsung: check the boot device and init the right mmc driver.
  samsung: misc: add function for setting $dfu_alt_info
  samsung:board: misc_init_r: call set_dfu_alt_info()
  arm:reset: call the reset_misc() before the cpu reset
  samsung: board: enable support of multiple board types
  samsung: misc: use board specific functions to set env board info
  odroid: add board file for Odroid X2/U3 based on Samsung Exynos4412
  odroid: add odroid U3/X2 device tree description
  odroid: add odroid_config

 arch/arm/cpu/armv7/exynos/pinmux.c |   4 +-
 arch/arm/dts/Makefile  |   3 +-
 arch/arm/dts/exynos4412-odroid.dts |  70 ++
 arch/arm/lib/reset.c   |   7 +
 board/samsung/common/board.c   |  44 +++-
 board/samsung/common/misc.c|  49 +++-
 board/samsung/odroid/Makefile  |   8 +
 board/samsung/odroid/odroid.c  | 466 +
 board/samsung/odroid/setup.h   | 227 ++
 boards.cfg |   1 +
 doc/README.odroid  | 144 
 include/common.h   |   1 +
 include/configs/odroid.h   | 232 ++
 include/samsung/misc.h |  18 ++
 14 files changed, 1261 insertions(+), 13 deletions(-)
 create mode 100644 arch/arm/dts/exynos4412-odroid.dts
 create mode 100644 board/samsung/odroid/Makefile
 create mode 100644 board/samsung/odroid/odroid.c
 create mode 100644 board/samsung/odroid/setup.h
 create mode 100644 doc/README.odroid
 create mode 100644 include/configs/odroid.h

-- 
1.9.1

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


[U-Boot] [PATCH v3 04/11] samsung: misc: add function for setting $dfu_alt_info

2014-06-26 Thread Przemyslaw Marczak
This change introduces new common function:
- set_dfu_alt_info() - put dfu system and bootloader setting
   into $dfu_alt_info.
functions declaration:
- char *get_dfu_alt_system(void)
- char *get_dfu_alt_boot(void)
- void set_dfu_alt_info(void)
and new config:
- CONFIG_SET_DFU_ALT_INFO

This function can be used for auto setting dfu configuration on boot.
Such feature is useful for multi board support by one u-boot binary.
Each board should define two functions:
- get_dfu_alt_system()
- get_dfu_alt_boot()

Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Cc: Piotr Wilczek p.wilc...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com

---
Changes v2:
- change config names:
  CONFIG_SET_DFU_BOOT_ALT to CONFIG_DFU_ALT_BOOTLOADER and
  CONFIG_DFU_BOOT_ALT_* to CONFIG_DFU_ALT_BOOT_*
- change function name: set_dfu_boot_alt() to set_dfu_alt_boot()
- remove superfluous ifdefs

Changes v3:
- set $dfu_alt_info at every boot
- new config: CONFIG_SET_DFU_ALT_INFO
- update commit msg
---
 board/samsung/common/misc.c | 36 
 include/samsung/misc.h  |  6 ++
 2 files changed, 42 insertions(+)

diff --git a/board/samsung/common/misc.c b/board/samsung/common/misc.c
index a453a82..166ea83 100644
--- a/board/samsung/common/misc.c
+++ b/board/samsung/common/misc.c
@@ -11,6 +11,7 @@
 #include samsung/misc.h
 #include errno.h
 #include version.h
+#include malloc.h
 #include linux/sizes.h
 #include asm/arch/cpu.h
 #include asm/arch/gpio.h
@@ -21,6 +22,41 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+#ifdef CONFIG_SET_DFU_ALT_INFO
+void set_dfu_alt_info(void)
+{
+   char *alt_boot = NULL;
+   char *alt_system = NULL;
+   char *buf = NULL;
+   int buf_len;
+
+   puts(DFU alt info setting: );
+
+   alt_boot = get_dfu_alt_boot();
+   if (!alt_boot)
+   goto error;
+
+   alt_system = get_dfu_alt_system();
+   if (!alt_system)
+   goto error;
+
+   buf_len = strlen(alt_boot) + strlen(alt_system) + 2;
+   buf = malloc(buf_len);
+
+   sprintf(buf, %s;%s, alt_boot, alt_system);
+   setenv(dfu_alt_info, buf);
+
+   free(buf);
+
+   puts(done\n);
+
+   return;
+error:
+   puts(error\n);
+   setenv(dfu_alt_info, Settings not found!);
+}
+#endif
+
 #ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
 void set_board_info(void)
 {
diff --git a/include/samsung/misc.h b/include/samsung/misc.h
index 57bac7d..c3fcc29 100644
--- a/include/samsung/misc.h
+++ b/include/samsung/misc.h
@@ -35,4 +35,10 @@ void draw_logo(void);
 
 unsigned int boot_device(void);
 
+#ifdef CONFIG_SET_DFU_ALT_INFO
+char *get_dfu_alt_system(void);
+char *get_dfu_alt_boot(void);
+void set_dfu_alt_info(void);
+#endif
+
 #endif /* __SAMSUNG_MISC_COMMON_H__ */
-- 
1.9.1

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


[U-Boot] [PATCH v3 09/11] odroid: add board file for Odroid X2/U3 based on Samsung Exynos4412

2014-06-26 Thread Przemyslaw Marczak
This board file supports standard features of Odroid X2 and U3 boards:
- Exynos4412 core clock set to 1000MHz and MPLL peripherial clock set to 800MHz,
- MAX77686 power regulator,
- USB PHY,
- enable XCL205 - power for board peripherials
- check board type: U3 or X2.
- enable Odroid U3 FAN cooler

Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
Cc: Tom Rini tr...@ti.com

---
Changes v2:
- enable fan on odroid U3

Changes v3:
- odroid.c: clean up board name related code
- odroid.c: remove static from set_board_type()
- odroid.c: add implementation of functions: get_dfu_alt_*
- odroid.c: include misc.h
---
 board/samsung/odroid/Makefile |   8 +
 board/samsung/odroid/odroid.c | 466 ++
 board/samsung/odroid/setup.h  | 227 
 3 files changed, 701 insertions(+)
 create mode 100644 board/samsung/odroid/Makefile
 create mode 100644 board/samsung/odroid/odroid.c
 create mode 100644 board/samsung/odroid/setup.h

diff --git a/board/samsung/odroid/Makefile b/board/samsung/odroid/Makefile
new file mode 100644
index 000..b98aaeb
--- /dev/null
+++ b/board/samsung/odroid/Makefile
@@ -0,0 +1,8 @@
+#
+# Copyright (c) 2014 Samsung Electronics Co., Ltd. All rights reserved.
+# Przemyslaw Marczak p.marc...@samsung.com
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y  := odroid.o
diff --git a/board/samsung/odroid/odroid.c b/board/samsung/odroid/odroid.c
new file mode 100644
index 000..a85f2f6
--- /dev/null
+++ b/board/samsung/odroid/odroid.c
@@ -0,0 +1,466 @@
+/*
+ * Copyright (C) 2014 Samsung Electronics
+ * Przemyslaw Marczak p.marc...@samsung.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include asm/arch/pinmux.h
+#include asm/arch/power.h
+#include asm/arch/clock.h
+#include asm/arch/gpio.h
+#include asm/gpio.h
+#include asm/arch/cpu.h
+#include power/pmic.h
+#include power/max77686_pmic.h
+#include errno.h
+#include usb.h
+#include usb/s3c_udc.h
+#include samsung/misc.h
+#include setup.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#ifdef CONFIG_BOARD_TYPES
+/* Odroid board types */
+enum {
+   ODROID_TYPE_U3,
+   ODROID_TYPE_X2,
+};
+
+void set_board_type(void)
+{
+   int val;
+
+   /* Check GPC1 pin 2 */
+   gpio_set_pull(EXYNOS4X12_GPIO_C12, S5P_GPIO_PULL_NONE);
+   gpio_set_drv(EXYNOS4X12_GPIO_C12, S5P_GPIO_DRV_4X);
+   gpio_direction_input(EXYNOS4X12_GPIO_C12);
+
+   /* XCL205 - needs some latch time */
+   mdelay(10);
+
+   /* Check GPC1 pin2 - LED supplied by XCL205 - X2 only */
+   val = gpio_get_value(EXYNOS4X12_GPIO_C12);
+   if (val)
+   gd-board_type = ODROID_TYPE_X2;
+   else
+   gd-board_type = ODROID_TYPE_U3;
+}
+
+const char *get_board_name(void)
+{
+   const char *board_name = odroid;
+
+   return board_name;
+}
+
+const char *get_board_type(void)
+{
+   const char *board_type[] = {u3, x2};
+
+   return board_type[gd-board_type];
+}
+#endif
+
+#ifdef CONFIG_SET_DFU_ALT_INFO
+char *get_dfu_alt_system(void)
+{
+   return getenv(dfu_alt_system);
+}
+
+char *get_dfu_alt_boot(void)
+{
+   char *alt_boot = NULL;
+
+   switch (boot_device()) {
+   case BOOT_DEVICE_SDMMC:
+   alt_boot = CONFIG_DFU_ALT_BOOT_SD;
+   break;
+   default:
+   alt_boot = CONFIG_DFU_ALT_BOOT_EMMC;
+   break;
+   }
+
+   if (!alt_boot)
+   return NULL;
+
+   setenv(dfu_alt_boot, alt_boot);
+
+   return alt_boot;
+}
+#endif
+
+static void board_clock_init(void)
+{
+   unsigned int set, clr, clr_src_cpu, clr_pll_con0, clr_src_dmc;
+   struct exynos4x12_clock *clk = (struct exynos4x12_clock *)
+   samsung_get_base_clock();
+
+   /*
+* CMU_CPU clocks src to MPLL
+* Bit values: 0  ; 1
+* MUX_APLL_SEL:FIN_PLL   ; FOUT_APLL
+* MUX_CORE_SEL:MOUT_APLL ; SCLK_MPLL
+* MUX_HPM_SEL: MOUT_APLL ; SCLK_MPLL_USER_C
+* MUX_MPLL_USER_SEL_C: FIN_PLL   ; SCLK_MPLL
+   */
+   clr_src_cpu = MUX_APLL_SEL(0x1) | MUX_CORE_SEL(0x1) |
+ MUX_HPM_SEL(0x1) | MUX_MPLL_USER_SEL_C(0x1);
+   set = MUX_APLL_SEL(0) | MUX_CORE_SEL(1) | MUX_HPM_SEL(1) |
+ MUX_MPLL_USER_SEL_C(1);
+
+   clrsetbits_le32(clk-src_cpu, clr_src_cpu, set);
+
+   /* Wait for mux change */
+   while (readl(clk-mux_stat_cpu)  MUX_STAT_CPU_CHANGING)
+   continue;
+
+   /* Set APLL to 1000MHz */
+   clr_pll_con0 = SDIV(0x7) | PDIV(0x3f) | MDIV(0x3ff) | FSEL(0x1);
+   set = SDIV(0) | PDIV(3) | MDIV(125) | FSEL(1);
+
+   clrsetbits_le32(clk-apll_con0, clr_pll_con0, set);
+
+   /* Wait for PLL to be locked */
+   while (!(readl(clk-apll_con0)  PLL_LOCKED_BIT))
+   continue;
+
+   /* Set CMU_CPU clocks src to APLL */
+   set = 

[U-Boot] [PATCH v3 10/11] odroid: add odroid U3/X2 device tree description

2014-06-26 Thread Przemyslaw Marczak
This is a standard description for Odroid boards.

Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
Cc: Tom Rini tr...@ti.com
---
 arch/arm/dts/Makefile  |  3 +-
 arch/arm/dts/exynos4412-odroid.dts | 70 ++
 2 files changed, 72 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/exynos4412-odroid.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 933a464..ff95ad9 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1,7 +1,8 @@
 dtb-$(CONFIG_EXYNOS4) += exynos4210-origen.dtb \
exynos4210-universal_c210.dtb \
exynos4210-trats.dtb \
-   exynos4412-trats2.dtb
+   exynos4412-trats2.dtb \
+   exynos4412-odroid.dtb
 
 dtb-$(CONFIG_EXYNOS5) += exynos5250-arndale.dtb \
exynos5250-snow.dtb \
diff --git a/arch/arm/dts/exynos4412-odroid.dts 
b/arch/arm/dts/exynos4412-odroid.dts
new file mode 100644
index 000..24d0bf1
--- /dev/null
+++ b/arch/arm/dts/exynos4412-odroid.dts
@@ -0,0 +1,70 @@
+/*
+ * Odroid-U3/X2 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 = Odroid based on Exynos4412;
+   compatible = samsung,odroid, samsung,exynos4412;
+
+   aliases {
+   i2c0 = /i2c@1386;
+   serial0 = /serial@1380;
+   console = /serial@1381;
+   mmc2 = sdhci@1253;
+   mmc4 = dwmmc@1255;
+   };
+
+   i2c@1386 {
+   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;
+   };
+   };
+
+   serial@1381 {
+   status = okay;
+   };
+
+   sdhci@1251 {
+   status = disabled;
+   };
+
+   sdhci@1252 {
+   status = disabled;
+   };
+
+   sdhci@1253 {
+   samsung,bus-width = 4;
+   samsung,timing = 1 2 3;
+   cd-gpios = gpio 0xC2 0;
+   };
+
+   sdhci@1254 {
+   status = disabled;
+   };
+
+   dwmmc@1255 {
+   samsung,bus-width = 8;
+   samsung,timing = 2 1 0;
+   samsung,removable = 0;
+   fifoth_val = 0x203f0040;
+   bus_hz = 4;
+   div = 0x3;
+   index = 4;
+   };
+};
-- 
1.9.1

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


[U-Boot] [PATCH v3 06/11] arm:reset: call the reset_misc() before the cpu reset

2014-06-26 Thread Przemyslaw Marczak
On an Odroid U3 board, the SOC is unable to reset the eMMC card
in the DWMMC mode by the cpu software reset. Manual reset of the card
by switching proper gpio pin - fixes this issue.

Such solution needs to add a call to pre reset function.
This is done by the reset_misc() function, which is called before reset_cpu().
The function reset_misc() is a weak function.

Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
Cc: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
Cc: Albert ARIBAUD albert.u.b...@aribaud.net
Cc: Tom Rini tr...@ti.com
---
 arch/arm/lib/reset.c | 7 +++
 include/common.h | 1 +
 2 files changed, 8 insertions(+)

diff --git a/arch/arm/lib/reset.c b/arch/arm/lib/reset.c
index 7a03580..3b39466 100644
--- a/arch/arm/lib/reset.c
+++ b/arch/arm/lib/reset.c
@@ -23,6 +23,11 @@
 
 #include common.h
 
+void __reset_misc(void) {}
+
+void reset_misc(void)
+   __attribute((weak, alias(__reset_misc)));
+
 int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 {
puts (resetting ...\n);
@@ -30,6 +35,8 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[])
udelay (5); /* wait 50 ms */
 
disable_interrupts();
+
+   reset_misc();
reset_cpu(0);
 
/*NOTREACHED*/
diff --git a/include/common.h b/include/common.h
index 232136c..04bab78 100644
--- a/include/common.h
+++ b/include/common.h
@@ -629,6 +629,7 @@ int checkicache   (void);
 intcheckdcache   (void);
 void   upmconfig (unsigned int, unsigned int *, unsigned int);
 ulong  get_tbclk (void);
+void   reset_misc(void);
 void   reset_cpu (ulong addr);
 #if defined (CONFIG_OF_LIBFDT)  defined (CONFIG_OF_BOARD_SETUP)
 void ft_cpu_setup(void *blob, bd_t *bd);
-- 
1.9.1

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


[U-Boot] [PATCH v3 03/11] board:samsung: check the boot device and init the right mmc driver.

2014-06-26 Thread Przemyslaw Marczak
It is possible to boot device using a micro SD or eMMC slots.
In this situation, boot device should be registered as a block
device 0 in the MMC framework, because CONFIG_SYS_MMC_ENV_DEV
is usually set to 0 in the most config cases.

Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
---
Changes V3:
- separate two changes into two commits
---
 board/samsung/common/board.c | 24 +---
 1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
index ecf3f76..f07a900 100644
--- a/board/samsung/common/board.c
+++ b/board/samsung/common/board.c
@@ -251,18 +251,28 @@ int board_mmc_init(bd_t *bis)
 {
int ret;
 
+   if (boot_device() == BOOT_DEVICE_SDMMC) {
+#ifdef CONFIG_SDHCI
+   /* mmc initializattion for available channels */
+   ret = exynos_mmc_init(gd-fdt_blob);
+#endif
 #ifdef CONFIG_DWMMC
-   /* dwmmc initializattion for available channels */
-   ret = exynos_dwmmc_init(gd-fdt_blob);
-   if (ret)
-   debug(dwmmc init failed\n);
+   /* dwmmc initializattion for available channels */
+   ret = exynos_dwmmc_init(gd-fdt_blob);
+#endif
+   } else {
+#ifdef CONFIG_DWMMC
+   /* dwmmc initializattion for available channels */
+   ret = exynos_dwmmc_init(gd-fdt_blob);
 #endif
 #ifdef CONFIG_SDHCI
-   /* mmc initializattion for available channels */
-   ret = exynos_mmc_init(gd-fdt_blob);
+   /* mmc initializattion for available channels */
+   ret = exynos_mmc_init(gd-fdt_blob);
+#endif
+   }
+
if (ret)
debug(mmc init failed\n);
-#endif
 
return ret;
 }
-- 
1.9.1

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


[U-Boot] [PATCH v3 07/11] samsung: board: enable support of multiple board types

2014-06-26 Thread Przemyslaw Marczak
This change adds declaration of functions:
- set_board_type() - called at checkboard()
- get_board_type() - called at checkboard()
- get_board_name()

For supporting multiple board types in a one config - it is welcome
to display the current board model. This is what get_board_type()
should return.

Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Cc: Piotr Wilczek p.wilc...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com

---
Changes v3:
- change the commit order
- include/samsung/misc.h: add new functions declaration
- update a commit message
---
 board/samsung/common/board.c | 7 +++
 include/samsung/misc.h   | 5 +
 2 files changed, 12 insertions(+)

diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
index fd5f21f..f2dbfa0 100644
--- a/board/samsung/common/board.c
+++ b/board/samsung/common/board.c
@@ -96,6 +96,7 @@ int board_init(void)
 #ifdef CONFIG_EXYNOS_SPI
spi_init();
 #endif
+
return exynos_init();
 }
 
@@ -285,7 +286,13 @@ int checkboard(void)
 
board_name = fdt_getprop(gd-fdt_blob, 0, model, NULL);
printf(Board: %s\n, board_name ? board_name : unknown);
+#ifdef CONFIG_BOARD_TYPES
+   set_board_type();
+
+   const char *board_type = get_board_type();
 
+   printf(Model: %s\n, board_type ? board_type : unknown);
+#endif
return 0;
 }
 #endif
diff --git a/include/samsung/misc.h b/include/samsung/misc.h
index c3fcc29..fcec5ea 100644
--- a/include/samsung/misc.h
+++ b/include/samsung/misc.h
@@ -40,5 +40,10 @@ char *get_dfu_alt_system(void);
 char *get_dfu_alt_boot(void);
 void set_dfu_alt_info(void);
 #endif
+#ifdef CONFIG_BOARD_TYPES
+void set_board_type(void);
+const char *get_board_type(void);
+const char *get_board_name(void);
+#endif
 
 #endif /* __SAMSUNG_MISC_COMMON_H__ */
-- 
1.9.1

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


[U-Boot] [PATCH v3 11/11] odroid: add odroid_config

2014-06-26 Thread Przemyslaw Marczak
This config is valid for two devices:
- Odroid X2,
- Odroid U3.

Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
Cc: Tom Rini tr...@ti.com

---
Changes v2:
- odroid config: add CONFIG_DFU_ALT_BOOTLOADER
- odroid config: change name of CONFIG_DFU_BOOT_ALT_* to CONFIG_DFU_ALT_BOOT_*

Changes v3:
- odroid.h: update CONFIG_DFU_ALT_BOOT_** with required bootloader binaries
- odroid.h: add multi image support (CONFIG_FIT)
- odroid.h: add autoboot script for multi boot options
- odroid.h: change env name: dfu_alt_info - dfu_alt_system
- odroid.h: update config name: CONFIG_SET_DFU_ALT_INFO
- odroid.h: reduce boot delay to 0 seconds
- update: doc/README.odroid
---
 boards.cfg   |   1 +
 doc/README.odroid| 144 +
 include/configs/odroid.h | 232 +++
 3 files changed, 377 insertions(+)
 create mode 100644 doc/README.odroid
 create mode 100644 include/configs/odroid.h

diff --git a/boards.cfg b/boards.cfg
index 1527ebe..8e8bcb3 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -297,6 +297,7 @@ Active  arm armv7  exynos  samsung  
   smdk5420
 Active  arm armv7  exynos  samsung smdkv310
smdkv310  - 

Chander Kashyap k.chan...@samsung.com
 Active  arm armv7  exynos  samsung trats   
trats - 

Lukasz Majewski l.majew...@samsung.com
 Active  arm armv7  exynos  samsung trats2  
trats2- 

Piotr Wilczek p.wilc...@samsung.com
+Active  arm armv7  exynos  samsung odroid  
odroid- 

Przemyslaw Marczak p.marc...@samsung.com
 Active  arm armv7  exynos  samsung universal_c210  
s5pc210_universal - 

Przemyslaw Marczak p.marc...@samsung.com
 Active  arm armv7  highbank-   highbank
highbank  - 

Rob Herring r...@kernel.org
 Active  arm armv7  keystoneti  k2hk_evm
k2hk_evm  - 

Vitaly Andrianov vita...@ti.com
diff --git a/doc/README.odroid b/doc/README.odroid
new file mode 100644
index 000..15aba10
--- /dev/null
+++ b/doc/README.odroid
@@ -0,0 +1,144 @@
+ U-boot for Odroid X2/U3
+
+
+1. Summary
+==
+This is a quick instruction for setup Odroid boards based on Exynos4412.
+Board config: odroid_config
+
+2. Supported devices
+
+This U-BOOT config can be used on two boards:
+- Odroid U3
+- Odroid X2
+with CPU Exynos 4412 rev 2.0 and 2GB of RAM
+
+3. Boot sequence
+
+iROM-BL1-(BL2 + TrustZone)-U-BOOT
+
+This version of U-BOOT doesn't implement SPL but it is required(BL2)
+and can be found in boot.tar.gz from here:
+http://dev.odroid.com/projects/4412boot/wiki/FrontPage?action=downloadvalue=boot.tar.gz
+
+4. Boot media layout
+
+The table below shows SD/eMMC cards layout for U-boot.
+The block offset is starting from 0 and the block size is 512B.
+ -
+|  Binary   | Block offset| part type |
+|   name| SD   | eMMC |(eMMC only)|
+ -
+| Bl1   | 1| 0|  1 (boot) |
+| Bl2   | 31   | 30   |  1 (boot) |
+| U-boot| 63   | 62   |  1 (boot) |
+| Tzsw  | 2111 | 2110 |  1 (boot) |
+| Uboot Env | 2500 | 2500 |  0 (user) |
+ -
+
+5. Prepare the SD boot card - with SD card reader
+=
+To prepare bootable media you need boot binaries provided by hardkernel.
+File boot.tar.gz (link in point 3.) contains:
+- E4412_S.bl1.HardKernel.bin
+- E4412_S.tzsw.signed.bin
+- bl2.signed.bin
+- sd_fusing.sh
+- u-boot.bin
+
+This is all you need to boot this board. But if you want to use your custom

[U-Boot] Why spi flash probe runs twice ?

2014-06-26 Thread Heshsham Abdul Basit
Hi,

This is a section of the log from u-boot running on Avnet Microzed board:


[Thu Jun 26 17:40:53.656 2014]

[Thu Jun 26 17:40:53.656 2014]

[Thu Jun 26 17:40:53.656 2014] U-Boot 2013.07 (Jun 26 2014 - 17:34:41)

[Thu Jun 26 17:40:53.656 2014]

[Thu Jun 26 17:40:53.656 2014] 1 GiB

[Thu Jun 26 17:40:53.671 2014] SF: Detected
S25FL129P_64K/S25FL128S_64K with page size 64 KiB, total 16 MiB

[Thu Jun 26 17:40:53.703 2014] *** Warning - bad CRC, using default environment

[Thu Jun 26 17:40:53.703 2014]

[Thu Jun 26 17:40:53.703 2014] In:serial

[Thu Jun 26 17:40:53.703 2014] Out:   serial

[Thu Jun 26 17:40:53.703 2014] Err:   serial

[Thu Jun 26 17:40:53.703 2014] U-BOOT for suheb_24

[Thu Jun 26 17:40:53.703 2014]

[Thu Jun 26 17:40:53.703 2014]

[Thu Jun 26 17:40:53.703 2014] SF: Detected
S25FL129P_64K/S25FL128S_64K with page size 64 KiB, total 16 MiB

[Thu Jun 26 17:40:54.453 2014] SF: 5242880 bytes @ 0x52 Read: OK

[Thu Jun 26 17:40:54.453 2014]  Description:  PetaLinux Kernel

[Thu Jun 26 17:40:54.453 2014] 0x01f0

[Thu Jun 26 17:40:54.453 2014] 4620145 Bytes = 4.4 MiB

[Thu Jun 26 17:40:54.453 2014]  Description:  Flattened Device Tree blob

[Thu Jun 26 17:40:54.453 2014] 0x01468114

[Thu Jun 26 17:40:54.453 2014] 9766 Bytes = 9.5 KiB

[Thu Jun 26 17:40:54.453 2014]  Hash algo:crc32

[Thu Jun 26 17:40:54.453 2014]  Hash value:   9a94aca8

[Thu Jun 26 17:40:54.453 2014]  Hash algo:sha1

[Thu Jun 26 17:40:54.453 2014]  Hash value:
97b81e3014decb706ff19e61e1227dace97d4232

[Thu Jun 26 17:40:54.453 2014] crc32+ sha1+  Uncompressing Kernel Image ... OK

.
.
.


I noticed that the following lines are coming twice:

SF: Detected S25FL129P_64K/S25FL128S_64K with page size 64 KiB, total 16 MiB

This corresponds to the function spi_flash_probe from
drivers/mtd/spi/spi_flash.c


I need to know:

1- Why it is probed twice?
2- The name and location of the file from where it is called (twice).
3- The second time it is being probed it is conciderably slow, why it is so?


Thanks and regards,

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


Re: [U-Boot] [PATCH 1/3] i2c: tegra: use repeated start for reads

2014-06-26 Thread Stephen Warren
On 06/26/2014 02:11 AM, Joakim Tjernlund wrote:
 From: Stephen Warren swar...@wwwdotorg.org
 To: u-boot@lists.denx.de, Heiko Schocher h...@denx.de, 
 Cc: Stephen Warren swar...@nvidia.com, Tom Warren twar...@nvidia.com
 Date: 2014/06/25 19:05
 Subject: [U-Boot] [PATCH 1/3] i2c: tegra: use repeated start for reads
 Sent by: u-boot-boun...@lists.denx.de

 From: Stephen Warren swar...@nvidia.com

 I2C read transactions are typically implemented as follows:

 START(write) address REPEATED_START(read) data... STOP

 However, Tegra's I2C driver currently implements reads as follows:

 START(write) address STOP START(read) data... STOP

 This sequence confuses at least the AS3722 PMIC on the Jetson TK1 board,
 leading to corrupted read data in some cases. Fix the driver to chain
 the transactions together using repeated starts to solve this.
 
 While I agree to use Repeated START I just wanted to share this:
 A common reason for STOP START(read) sequence not working sometimes is 
 that
 the driver initializes STOP but does not wait for the STOP to complete
 before issuing a START.

I don't believe that's the case here, since all this patch does is set a
flag to indicate whether the write transaction (to set the intra-chip
register address) generates STOP or REPEATED_START at the end. If the
code or HW wasn't waiting for the STOP to complete, I see no reason it
would wait for the REPEATED_START to complete either, so I think the
subsequent register read transaction would be corrupted in either case.

There's certainly code in tegra_i2c.c:wait_for_transfer_complete() to
poll until each transaction completes before starting the next, and
there's even error handling to detect any problems there:-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


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

2014-06-26 Thread Steve Rae



On 14-06-26 06:20 AM, Rob Herring wrote:

On Wed, Jun 25, 2014 at 7:16 PM, Steve Rae s...@broadcom.com wrote:

Rob,


On 14-06-25 06:59 AM, Rob Herring wrote:


On Mon, Jun 23, 2014 at 1:37 PM, Steve Rae s...@broadcom.com wrote:


Rob  Sebastian

I would appreciate your comments on this issue; I suspect that you had
some
ideas regarding the implementation of the fastboot flash and erase
commands



I agree with Lukasz's and Marek's comments unless there are good
reasons not to use it which can't be fixed. Curiously, USB mass
storage does not use the DFU backend, but I don't know why. Perhaps
there are incompatibilities or converting it is on the todo list. Are
your performance concerns measurable or it's just the fact you are
adding another layer?



The concern is not performance related -- just the amount of (overhead) code
required to implement the DFU backend versus calling
mmc_dev-block_write()
(maybe someone can tell me where to interface into DFU: is it at
dfu_write() or )


Yes, I believe it is dfu_write.


I'd really like to see the eMMC backend be a generic block device
backend. There's no good reason for it to be eMMC/SD specific.



As I understand it, the block_write callback function is in the
block_dev_desc_t. Isn't this the part of the generic block device
interface? Please explain...


There are commands for SATA, SCSI (also SATA), eMMC, IDE, etc. They
are all pretty much the same set of sub-commands and duplicate the
same functionality. Those could all be combined to a single
implementation and/or command for block devices. That part is not DFU
related, but this problem then proliferates to other areas as it has
for DFU. The file drivers/dfu/dfu_mmc.c is mostly generic, but has
some eMMC dependencies with find_mmc_device and mmc_switch_part. So
read and write are already pretty much generic, but there's still some
work to do around device addressing/selection.

Rob

While I agree in general that to make everything generic is ideal, IMO, 
I don't think that there is a design or a roadmap to get us there yet

I would suggest that any generic interface would also need to support:
- handling of multiple HW partitions (0=USER 1-BOOT1 2=BOOT2 etc.)
which I already attempted to implement (and abandoned):
   http://lists.denx.de/pipermail/u-boot/2014-May/180468.html
- handling of partition names
for EFI Partitions, this did get accepted:
   http://lists.denx.de/pipermail/u-boot/2014-May/180292.html
So now I would propose two phases:
(1) short term - get fastboot flash working (and erase, and oem 
format, etc.)

I have code that works for eMMC device (and potentially for NAMD...)
(2) longer term - define the generic block device (probably enhance
block_dev_desc_t ?!?!?) and move the short term solution into this 
new design.


I will submit a v2 to see if it will get accepted as part of the 
short term solution.


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


[U-Boot] [PATCH] common:splash: use __weak

2014-06-26 Thread Jeroen Hofstee
This not only looks a bit better it also prevents a
warning with W=1 (no previous prototype).

cc: ag...@denx.de
Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl
---
 common/splash.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/common/splash.c b/common/splash.c
index 18885f1..144fb10 100644
--- a/common/splash.c
+++ b/common/splash.c
@@ -23,15 +23,11 @@
 #include common.h
 #include splash.h
 
-int __splash_screen_prepare(void)
+__weak int splash_screen_prepare(void)
 {
return 0;
 }
 
-int splash_screen_prepare(void)
-   __attribute__ ((weak, alias(__splash_screen_prepare)));
-
-
 #ifdef CONFIG_SPLASH_SCREEN_ALIGN
 void splash_get_pos(int *x, int *y)
 {
-- 
1.8.3.2

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


[U-Boot] [PATCH] lib:lmb: use __weak

2014-06-26 Thread Jeroen Hofstee
This not only looks a bit better it also prevents a
warning with W=1 (no previous prototype).

Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl
---
 lib/lmb.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/lib/lmb.c b/lib/lmb.c
index 081e418..49a3c9e 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -332,14 +332,12 @@ int lmb_is_reserved(struct lmb *lmb, phys_addr_t addr)
return 0;
 }
 
-void __board_lmb_reserve(struct lmb *lmb)
+__weak void board_lmb_reserve(struct lmb *lmb)
 {
/* please define platform specific board_lmb_reserve() */
 }
-void board_lmb_reserve(struct lmb *lmb) __attribute__((weak, 
alias(__board_lmb_reserve)));
 
-void __arch_lmb_reserve(struct lmb *lmb)
+__weak void arch_lmb_reserve(struct lmb *lmb)
 {
/* please define platform specific arch_lmb_reserve() */
 }
-void arch_lmb_reserve(struct lmb *lmb) __attribute__((weak, 
alias(__arch_lmb_reserve)));
-- 
1.8.3.2

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


[U-Boot] [PATCH] driver/ddr: Fix DDR register timing_cfg_8

2014-06-26 Thread York Sun
The field wrtord_bg should add 2 clocks if on the fly chop is enabled,
according to DDR controller manual for DDR4.

Signed-off-by: York Sun york...@freescale.com
---
 drivers/ddr/fsl/ctrl_regs.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/ddr/fsl/ctrl_regs.c b/drivers/ddr/fsl/ctrl_regs.c
index dcf6287..04e4178 100644
--- a/drivers/ddr/fsl/ctrl_regs.c
+++ b/drivers/ddr/fsl/ctrl_regs.c
@@ -1857,6 +1857,9 @@ static void set_timing_cfg_8(fsl_ddr_cfg_regs_t *ddr,
 
acttoact_bg = picos_to_mclk(common_dimm-trrdl_ps);
wrtord_bg = max(4, picos_to_mclk(7500));
+   if (popts-otf_burst_chop_en)
+   wrtord_bg += 2;
+
pre_all_rec = 0;
 
ddr-timing_cfg_8 = (0
-- 
1.7.9.5

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


[U-Boot] [PATCH] common: main.c: make show_boot_progress __weak

2014-06-26 Thread Jeroen Hofstee
This not only looks a bit better it also prevents a
warning with W=1 (no previous prototype).

Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl
---
 common/main.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/common/main.c b/common/main.c
index 32618f1..2979fbe 100644
--- a/common/main.c
+++ b/common/main.c
@@ -17,8 +17,7 @@ DECLARE_GLOBAL_DATA_PTR;
 /*
  * Board-specific Platform code can reimplement show_boot_progress () if needed
  */
-void inline __show_boot_progress (int val) {}
-void show_boot_progress (int val) __attribute__((weak, 
alias(__show_boot_progress)));
+__weak void show_boot_progress(int val) {}
 
 static void modem_init(void)
 {
-- 
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 0/4] Implement fastboot flash for eMMC

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

NOTES:
- the support for the fastboot flash command is enabled with 
CONFIG_FASTBOOT_FLASH
- the support for eMMC is enabled with CONFIG_FASTBOOT_FLASH_MMC_DEV
- (future) the support for NAND would be enabled with 
CONFIG_FASTBOOT_FLASH_NAND(???)

This has been tested on ARMv7.

Changes in v2:
- split large function into three
- improved handling of response messages
- additional partition size checking when writing sparse image
- update README.android-fastboot file
- new in v2

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

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

-- 
1.8.5

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


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

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

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

Changes in v2: None

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

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

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


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

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

Signed-off-by: Steve Rae s...@broadcom.com
---

Changes in v2:
- update README.android-fastboot file

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

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

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


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

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

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

Changes in v2:
- split large function into three
- improved handling of response messages
- additional partition size checking when writing sparse image

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

diff --git a/common/Makefile b/common/Makefile
index de5cce8..daebe39 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -266,4 +266,9 @@ obj-$(CONFIG_IO_TRACE) += iotrace.o
 obj-y += memsize.o
 obj-y += stdio.o
 
+# This option is not just y/n - it can have a numeric value
+ifdef CONFIG_FASTBOOT_FLASH_MMC_DEV
+obj-y += fb_mmc.o
+endif
+
 CFLAGS_env_embedded.o := -Wa,--no-warn -DENV_CRC=$(shell tools/envcrc 
2/dev/null)
diff --git a/common/fb_mmc.c b/common/fb_mmc.c
new file mode 100644
index 000..4143070
--- /dev/null
+++ b/common/fb_mmc.c
@@ -0,0 +1,189 @@
+/*
+ * Copyright TODO
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include fb_mmc.h
+#include mmc.h
+#include sparse_format.h
+
+/* The 64 defined bytes plus \0 */
+#define RESPONSE_LEN   (64 + 1)
+
+static char *response_str;
+
+static void fastboot_resp(const char *s)
+{
+   strncpy(response_str, s, RESPONSE_LEN);
+   response_str[RESPONSE_LEN - 1] = '\0';
+}
+
+static int is_sparse_image(void *buf)
+{
+   sparse_header_t *s_header = (sparse_header_t *)buf;
+
+   if ((le32_to_cpu(s_header-magic) == SPARSE_HEADER_MAGIC) 
+   (le16_to_cpu(s_header-major_version) == 1))
+   return 1;
+
+   return 0;
+}
+
+static void write_sparse_image(block_dev_desc_t *mmc_dev,
+   disk_partition_t *info, const char *part_name,
+   void *buffer, unsigned int download_bytes)
+{
+   lbaint_t blk;
+   lbaint_t blkcnt;
+   lbaint_t blks;
+   sparse_header_t *s_header = (sparse_header_t *)buffer;
+   chunk_header_t *c_header;
+   void *buf;
+   uint32_t blk_sz;
+   uint32_t remaining_chunks;
+   uint32_t bytes_written = 0;
+
+   blk_sz = le32_to_cpu(s_header-blk_sz);
+
+   /* verify s_header-blk_sz is exact multiple of info-blksz */
+   if (blk_sz != (blk_sz  ~(info-blksz - 1))) {
+   printf(%s: Sparse image block size issue [%u]\n,
+  __func__, blk_sz);
+   fastboot_resp(FAILsparse image block size issue);
+   return;
+   }
+
+   if ((le32_to_cpu(s_header-total_blks) * blk_sz) 
+   (info-size * info-blksz)) {
+   printf(%s: Sparse image is too large for the partition\n,
+  __func__);
+   fastboot_resp(FAILsparse image is too large);
+   return;
+   }
+
+   printf(Flashing Sparse Image\n);
+
+   remaining_chunks = le32_to_cpu(s_header-total_chunks);
+   c_header = (chunk_header_t *)(buffer +
+   le16_to_cpu(s_header-file_hdr_sz));
+   blk = info-start;
+   while (remaining_chunks) {
+   blkcnt =
+   (le32_to_cpu(c_header-chunk_sz) * blk_sz) / info-blksz;
+
+   switch (le16_to_cpu(c_header-chunk_type)) {
+   case CHUNK_TYPE_RAW:
+   buf = (void *)c_header +
+   le16_to_cpu(s_header-chunk_hdr_sz);
+
+   if (blk + blkcnt  info-start + info-size) {
+   printf(
+   %s: Request would exceed partition 
size!\n,
+   __func__);
+   fastboot_resp(
+   FAILRequest would exceed partition size!);
+   return;
+   }
+
+   blks = mmc_dev-block_write(mmc_dev-dev, blk, blkcnt,
+   buf);
+   if (blks != blkcnt) {
+   printf(%s: Write failed  LBAFU \n,
+  __func__, blks);
+   fastboot_resp(FAILmmc write failure);
+   return;
+   }
+
+   bytes_written += blkcnt * info-blksz;
+   break;
+
+   case CHUNK_TYPE_FILL:
+   case CHUNK_TYPE_DONT_CARE:
+   case CHUNK_TYPE_CRC32:
+   /* do nothing */
+   break;
+
+   default:
+   /* error */
+   printf(%s: Unknown chunk type\n, __func__);
+ 

[U-Boot] [PATCH v2 4/4] usb/gadget: fastboot: minor cleanup

2014-06-26 Thread Steve Rae
- update static function
- additional debugging statements

Signed-off-by: Steve Rae s...@broadcom.com
---

Changes in v2:
- new in v2

 drivers/usb/gadget/f_fastboot.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c
index 89c2d3e..3e6e47f 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -293,7 +293,7 @@ static int fastboot_add(struct usb_configuration *c)
 }
 DECLARE_GADGET_BIND_CALLBACK(usb_dnl_fastboot, fastboot_add);
 
-int fastboot_tx_write(const char *buffer, unsigned int buffer_size)
+static int fastboot_tx_write(const char *buffer, unsigned int buffer_size)
 {
struct usb_request *in_req = fastboot_func-in_req;
int ret;
@@ -338,6 +338,7 @@ static void cb_getvar(struct usb_ep *ep, struct usb_request 
*req)
strcpy(response, OKAY);
strsep(cmd, :);
if (!cmd) {
+   printf(%s: missing var\n, __func__);
fastboot_tx_write_str(FAILmissing var);
return;
}
@@ -358,6 +359,7 @@ static void cb_getvar(struct usb_ep *ep, struct usb_request 
*req)
else
strcpy(response, FAILValue not set);
} else {
+   printf(%s: unknown variable: %s\n, __func__, cmd);
strcpy(response, FAILVariable not implemented);
}
fastboot_tx_write_str(response);
@@ -531,10 +533,12 @@ static void rx_handler_command(struct usb_ep *ep, struct 
usb_request *req)
}
}
 
-   if (!func_cb)
+   if (!func_cb) {
+   printf(%s: unknown command: %s\n, __func__, cmdbuf);
fastboot_tx_write_str(FAILunknown command);
-   else
+   } else {
func_cb(ep, req);
+   }
 
if (req-status == 0) {
*cmdbuf = '\0';
-- 
1.8.5

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


Re: [U-Boot] [PATCH 1/3] i2c: tegra: use repeated start for reads

2014-06-26 Thread Joakim Tjernlund
Stephen Warren swar...@wwwdotorg.org wrote on 2014/06/26 18:47:55:
 
 On 06/26/2014 02:11 AM, Joakim Tjernlund wrote:
  From: Stephen Warren swar...@wwwdotorg.org
  To: u-boot@lists.denx.de, Heiko Schocher h...@denx.de, 
  Cc: Stephen Warren swar...@nvidia.com, Tom Warren 
twar...@nvidia.com
  Date: 2014/06/25 19:05
  Subject: [U-Boot] [PATCH 1/3] i2c: tegra: use repeated start for 
reads
  Sent by: u-boot-boun...@lists.denx.de
 
  From: Stephen Warren swar...@nvidia.com
 
  I2C read transactions are typically implemented as follows:
 
  START(write) address REPEATED_START(read) data... STOP
 
  However, Tegra's I2C driver currently implements reads as follows:
 
  START(write) address STOP START(read) data... STOP
 
  This sequence confuses at least the AS3722 PMIC on the Jetson TK1 
board,
  leading to corrupted read data in some cases. Fix the driver to chain
  the transactions together using repeated starts to solve this.
  
  While I agree to use Repeated START I just wanted to share this:
  A common reason for STOP START(read) sequence not working sometimes is 

  that
  the driver initializes STOP but does not wait for the STOP to complete
  before issuing a START.
 
 I don't believe that's the case here, since all this patch does is set a
 flag to indicate whether the write transaction (to set the intra-chip
 register address) generates STOP or REPEATED_START at the end. If the
 code or HW wasn't waiting for the STOP to complete, I see no reason it
 would wait for the REPEATED_START to complete either, so I think the
 subsequent register read transaction would be corrupted in either case.

But there is, you have STOP + START vs. ReSTART only and if the code only 
flips
a flag to change I think there is a chance in this case.
You could easily test by adding a udelay(5) after STOP is initiated. 

 
 There's certainly code in tegra_i2c.c:wait_for_transfer_complete() to
 poll until each transaction completes before starting the next, and
 there's even error handling to detect any problems there:-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/3] i2c: tegra: use repeated start for reads

2014-06-26 Thread Stephen Warren
On 06/26/2014 01:11 PM, Joakim Tjernlund wrote:
 Stephen Warren swar...@wwwdotorg.org wrote on 2014/06/26 18:47:55:

 On 06/26/2014 02:11 AM, Joakim Tjernlund wrote:
 From: Stephen Warren swar...@wwwdotorg.org
 To: u-boot@lists.denx.de, Heiko Schocher h...@denx.de, 
 Cc: Stephen Warren swar...@nvidia.com, Tom Warren 
 twar...@nvidia.com
 Date: 2014/06/25 19:05
 Subject: [U-Boot] [PATCH 1/3] i2c: tegra: use repeated start for 
 reads
 Sent by: u-boot-boun...@lists.denx.de

 From: Stephen Warren swar...@nvidia.com

 I2C read transactions are typically implemented as follows:

 START(write) address REPEATED_START(read) data... STOP

 However, Tegra's I2C driver currently implements reads as follows:

 START(write) address STOP START(read) data... STOP

 This sequence confuses at least the AS3722 PMIC on the Jetson TK1 
 board,
 leading to corrupted read data in some cases. Fix the driver to chain
 the transactions together using repeated starts to solve this.

 While I agree to use Repeated START I just wanted to share this:
 A common reason for STOP START(read) sequence not working sometimes is 
 
 that
 the driver initializes STOP but does not wait for the STOP to complete
 before issuing a START.

 I don't believe that's the case here, since all this patch does is set a
 flag to indicate whether the write transaction (to set the intra-chip
 register address) generates STOP or REPEATED_START at the end. If the
 code or HW wasn't waiting for the STOP to complete, I see no reason it
 would wait for the REPEATED_START to complete either, so I think the
 subsequent register read transaction would be corrupted in either case.
 
 But there is, you have STOP + START vs. ReSTART only and if the code only 
 flips a flag to change I think there is a chance in this case.
 You could easily test by adding a udelay(5) after STOP is initiated. 

If the code doesn't wait for the STOP/REPEATED_START to complete, then
whatever comes after will trample it, whether it's a START, or the data
transfer for the next transaction.

Anyway, as I note below, the code is waiting:

 There's certainly code in tegra_i2c.c:wait_for_transfer_complete() to
 poll until each transaction completes before starting the next, and
 there's even error handling to detect any problems there:-)

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


Re: [U-Boot] [PATCH 1/3] i2c: tegra: use repeated start for reads

2014-06-26 Thread Stephen Warren
On 06/26/2014 01:18 PM, Stephen Warren wrote:
 On 06/26/2014 01:11 PM, Joakim Tjernlund wrote:
 Stephen Warren swar...@wwwdotorg.org wrote on 2014/06/26 18:47:55:

 On 06/26/2014 02:11 AM, Joakim Tjernlund wrote:
 From: Stephen Warren swar...@wwwdotorg.org
 To: u-boot@lists.denx.de, Heiko Schocher h...@denx.de, 
 Cc: Stephen Warren swar...@nvidia.com, Tom Warren 
 twar...@nvidia.com
 Date: 2014/06/25 19:05
 Subject: [U-Boot] [PATCH 1/3] i2c: tegra: use repeated start for 
 reads
 Sent by: u-boot-boun...@lists.denx.de

 From: Stephen Warren swar...@nvidia.com

 I2C read transactions are typically implemented as follows:

 START(write) address REPEATED_START(read) data... STOP

 However, Tegra's I2C driver currently implements reads as follows:

 START(write) address STOP START(read) data... STOP

 This sequence confuses at least the AS3722 PMIC on the Jetson TK1 
 board,
 leading to corrupted read data in some cases. Fix the driver to chain
 the transactions together using repeated starts to solve this.

 While I agree to use Repeated START I just wanted to share this:
 A common reason for STOP START(read) sequence not working sometimes is 

 that
 the driver initializes STOP but does not wait for the STOP to complete
 before issuing a START.

 I don't believe that's the case here, since all this patch does is set a
 flag to indicate whether the write transaction (to set the intra-chip
 register address) generates STOP or REPEATED_START at the end. If the
 code or HW wasn't waiting for the STOP to complete, I see no reason it
 would wait for the REPEATED_START to complete either, so I think the
 subsequent register read transaction would be corrupted in either case.

 But there is, you have STOP + START vs. ReSTART only and if the code only 
 flips a flag to change I think there is a chance in this case.
 You could easily test by adding a udelay(5) after STOP is initiated. 

The delay makes no difference. (I delayed 1ms).
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/3] i2c: tegra: use repeated start for reads

2014-06-26 Thread Joakim Tjernlund
Stephen Warren swar...@wwwdotorg.org wrote on 2014/06/26 21:18:50:

 
 On 06/26/2014 01:11 PM, Joakim Tjernlund wrote:
  Stephen Warren swar...@wwwdotorg.org wrote on 2014/06/26 18:47:55:
 
  On 06/26/2014 02:11 AM, Joakim Tjernlund wrote:
  From: Stephen Warren swar...@wwwdotorg.org
  To: u-boot@lists.denx.de, Heiko Schocher h...@denx.de, 
  Cc: Stephen Warren swar...@nvidia.com, Tom Warren 
  twar...@nvidia.com
  Date: 2014/06/25 19:05
  Subject: [U-Boot] [PATCH 1/3] i2c: tegra: use repeated start for 
  reads
  Sent by: u-boot-boun...@lists.denx.de
 
  From: Stephen Warren swar...@nvidia.com
 
  I2C read transactions are typically implemented as follows:
 
  START(write) address REPEATED_START(read) data... STOP
 
  However, Tegra's I2C driver currently implements reads as follows:
 
  START(write) address STOP START(read) data... STOP
 
  This sequence confuses at least the AS3722 PMIC on the Jetson TK1 
  board,
  leading to corrupted read data in some cases. Fix the driver to 
chain
  the transactions together using repeated starts to solve this.
 
  While I agree to use Repeated START I just wanted to share this:
  A common reason for STOP START(read) sequence not working sometimes 
is 
  
  that
  the driver initializes STOP but does not wait for the STOP to 
complete
  before issuing a START.
 
  I don't believe that's the case here, since all this patch does is 
set a
  flag to indicate whether the write transaction (to set the intra-chip
  register address) generates STOP or REPEATED_START at the end. If the
  code or HW wasn't waiting for the STOP to complete, I see no reason 
it
  would wait for the REPEATED_START to complete either, so I think the
  subsequent register read transaction would be corrupted in either 
case.
  
  But there is, you have STOP + START vs. ReSTART only and if the code 
only 
  flips a flag to change I think there is a chance in this case.
  You could easily test by adding a udelay(5) after STOP is initiated. 
 
 If the code doesn't wait for the STOP/REPEATED_START to complete, then
 whatever comes after will trample it, whether it's a START, or the data
 transfer for the next transaction.

You misunderstand, there has to be an extra STOP complete time between the 
STOP
and START. When replacing this with only one ReSTART that STOP complete 
time is gone.
So by changing to ReSTART you fixed this error and got much better 
behaviour too.
I am just saying that there might be other places which lacks STOP 
completion as well
For reference you can look at 
  
http://git.denx.de/?p=u-boot.git;a=commitdiff;h=21f4cbb77299788e2b06c9b0f48cf20a5ab00d4a
and
 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/i2c/busses/i2c-mpc.c?id=45da790ebe746bb29f7e4adf806c020db6ff7755
That took a while for me to figure out :)

 
 Anyway, as I note below, the code is waiting:
 
  There's certainly code in tegra_i2c.c:wait_for_transfer_complete() to
  poll until each transaction completes before starting the next, and
  there's even error handling to detect any problems there:-)
 

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


Re: [U-Boot] [PATCH 1/3] i2c: tegra: use repeated start for reads

2014-06-26 Thread Joakim Tjernlund
Stephen Warren swar...@wwwdotorg.org wrote on 2014/06/26 21:24:05:
 On 06/26/2014 01:18 PM, Stephen Warren wrote:
  On 06/26/2014 01:11 PM, Joakim Tjernlund wrote:
  Stephen Warren swar...@wwwdotorg.org wrote on 2014/06/26 18:47:55:
 
  On 06/26/2014 02:11 AM, Joakim Tjernlund wrote:
  From: Stephen Warren swar...@wwwdotorg.org
  To: u-boot@lists.denx.de, Heiko Schocher h...@denx.de, 
  Cc: Stephen Warren swar...@nvidia.com, Tom Warren 
  twar...@nvidia.com
  Date: 2014/06/25 19:05
  Subject: [U-Boot] [PATCH 1/3] i2c: tegra: use repeated start for 
  reads
  Sent by: u-boot-boun...@lists.denx.de
 
  From: Stephen Warren swar...@nvidia.com
 
  I2C read transactions are typically implemented as follows:
 
  START(write) address REPEATED_START(read) data... STOP
 
  However, Tegra's I2C driver currently implements reads as follows:
 
  START(write) address STOP START(read) data... STOP
 
  This sequence confuses at least the AS3722 PMIC on the Jetson TK1 
  board,
  leading to corrupted read data in some cases. Fix the driver to 
chain
  the transactions together using repeated starts to solve this.
 
  While I agree to use Repeated START I just wanted to share this:
  A common reason for STOP START(read) sequence not working sometimes 
is 
 
  that
  the driver initializes STOP but does not wait for the STOP to 
complete
  before issuing a START.
 
  I don't believe that's the case here, since all this patch does is 
set a
  flag to indicate whether the write transaction (to set the 
intra-chip
  register address) generates STOP or REPEATED_START at the end. If 
the
  code or HW wasn't waiting for the STOP to complete, I see no reason 
it
  would wait for the REPEATED_START to complete either, so I think the
  subsequent register read transaction would be corrupted in either 
case.
 
  But there is, you have STOP + START vs. ReSTART only and if the code 
only 
  flips a flag to change I think there is a chance in this case.
  You could easily test by adding a udelay(5) after STOP is initiated. 
 
 The delay makes no difference. (I delayed 1ms).

Strange, I had a look at the driver and I have a hard time figuring out 
how/when START/STOP
is generated. However I don't think the current driver's 
wait_for_transfer_complete() waits for
the START/STOP. I guess it waits until all data bytes are finished so STOP 
completion time
isn't accounted for.

Where is STOP initiated and where did you add the delay?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


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

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

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

Changes in v3: None
Changes in v2: None

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

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

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


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

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

Signed-off-by: Steve Rae s...@broadcom.com
---

Changes in v3: None
Changes in v2:
- update README.android-fastboot file

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

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

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


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

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

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

Changes in v3:
- remove most references to 'mmc',
  which leaves only one mmc specific function: mmc_get_dev()

Changes in v2:
- split large function into three
- improved handling of response messages
- additional partition size checking when writing sparse image

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

diff --git a/common/Makefile b/common/Makefile
index de5cce8..daebe39 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -266,4 +266,9 @@ obj-$(CONFIG_IO_TRACE) += iotrace.o
 obj-y += memsize.o
 obj-y += stdio.o
 
+# This option is not just y/n - it can have a numeric value
+ifdef CONFIG_FASTBOOT_FLASH_MMC_DEV
+obj-y += fb_mmc.o
+endif
+
 CFLAGS_env_embedded.o := -Wa,--no-warn -DENV_CRC=$(shell tools/envcrc 
2/dev/null)
diff --git a/common/fb_mmc.c b/common/fb_mmc.c
new file mode 100644
index 000..9163d8c
--- /dev/null
+++ b/common/fb_mmc.c
@@ -0,0 +1,190 @@
+/*
+ * Copyright TODO
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include fb_mmc.h
+#include part.h
+#include sparse_format.h
+
+/* The 64 defined bytes plus \0 */
+#define RESPONSE_LEN   (64 + 1)
+
+static char *response_str;
+
+static void fastboot_resp(const char *s)
+{
+   strncpy(response_str, s, RESPONSE_LEN);
+   response_str[RESPONSE_LEN - 1] = '\0';
+}
+
+static int is_sparse_image(void *buf)
+{
+   sparse_header_t *s_header = (sparse_header_t *)buf;
+
+   if ((le32_to_cpu(s_header-magic) == SPARSE_HEADER_MAGIC) 
+   (le16_to_cpu(s_header-major_version) == 1))
+   return 1;
+
+   return 0;
+}
+
+static void write_sparse_image(block_dev_desc_t *dev_desc,
+   disk_partition_t *info, const char *part_name,
+   void *buffer, unsigned int download_bytes)
+{
+   lbaint_t blk;
+   lbaint_t blkcnt;
+   lbaint_t blks;
+   sparse_header_t *s_header = (sparse_header_t *)buffer;
+   chunk_header_t *c_header;
+   void *buf;
+   uint32_t blk_sz;
+   uint32_t remaining_chunks;
+   uint32_t bytes_written = 0;
+
+   blk_sz = le32_to_cpu(s_header-blk_sz);
+
+   /* verify s_header-blk_sz is exact multiple of info-blksz */
+   if (blk_sz != (blk_sz  ~(info-blksz - 1))) {
+   printf(%s: Sparse image block size issue [%u]\n,
+  __func__, blk_sz);
+   fastboot_resp(FAILsparse image block size issue);
+   return;
+   }
+
+   if ((le32_to_cpu(s_header-total_blks) * blk_sz) 
+   (info-size * info-blksz)) {
+   printf(%s: Sparse image is too large for the partition\n,
+  __func__);
+   fastboot_resp(FAILsparse image is too large);
+   return;
+   }
+
+   printf(Flashing Sparse Image\n);
+
+   remaining_chunks = le32_to_cpu(s_header-total_chunks);
+   c_header = (chunk_header_t *)(buffer +
+   le16_to_cpu(s_header-file_hdr_sz));
+   blk = info-start;
+   while (remaining_chunks) {
+   blkcnt =
+   (le32_to_cpu(c_header-chunk_sz) * blk_sz) / info-blksz;
+
+   switch (le16_to_cpu(c_header-chunk_type)) {
+   case CHUNK_TYPE_RAW:
+   buf = (void *)c_header +
+   le16_to_cpu(s_header-chunk_hdr_sz);
+
+   if (blk + blkcnt  info-start + info-size) {
+   printf(
+   %s: Request would exceed partition 
size!\n,
+   __func__);
+   fastboot_resp(
+   FAILRequest would exceed partition size!);
+   return;
+   }
+
+   blks = dev_desc-block_write(dev_desc-dev, blk, blkcnt,
+   buf);
+   if (blks != blkcnt) {
+   printf(%s: Write failed  LBAFU \n,
+  __func__, blks);
+   fastboot_resp(FAILwrite failure);
+   return;
+   }
+
+   bytes_written += blkcnt * info-blksz;
+   break;
+
+   case CHUNK_TYPE_FILL:
+   case CHUNK_TYPE_DONT_CARE:
+   case CHUNK_TYPE_CRC32:
+   /* do nothing */
+   break;
+
+   default:
+ 

[U-Boot] [PATCH v3 0/4] Implement fastboot flash for eMMC

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

NOTES:
- the support for the fastboot flash command is enabled with 
CONFIG_FASTBOOT_FLASH
- the support for eMMC is enabled with CONFIG_FASTBOOT_FLASH_MMC_DEV
- (future) the support for NAND would be enabled with 
CONFIG_FASTBOOT_FLASH_NAND(???)

This has been tested on ARMv7.

Changes in v3:
- remove most references to 'mmc',
  which leaves only one mmc specific function: mmc_get_dev()

Changes in v2:
- split large function into three
- improved handling of response messages
- additional partition size checking when writing sparse image
- update README.android-fastboot file
- new in v2

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

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

-- 
1.8.5

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


[U-Boot] [PATCH v3 4/4] usb/gadget: fastboot: minor cleanup

2014-06-26 Thread Steve Rae
- update static function
- additional debugging statements

Signed-off-by: Steve Rae s...@broadcom.com
---

Changes in v3: None
Changes in v2:
- new in v2

 drivers/usb/gadget/f_fastboot.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c
index 89c2d3e..3e6e47f 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -293,7 +293,7 @@ static int fastboot_add(struct usb_configuration *c)
 }
 DECLARE_GADGET_BIND_CALLBACK(usb_dnl_fastboot, fastboot_add);
 
-int fastboot_tx_write(const char *buffer, unsigned int buffer_size)
+static int fastboot_tx_write(const char *buffer, unsigned int buffer_size)
 {
struct usb_request *in_req = fastboot_func-in_req;
int ret;
@@ -338,6 +338,7 @@ static void cb_getvar(struct usb_ep *ep, struct usb_request 
*req)
strcpy(response, OKAY);
strsep(cmd, :);
if (!cmd) {
+   printf(%s: missing var\n, __func__);
fastboot_tx_write_str(FAILmissing var);
return;
}
@@ -358,6 +359,7 @@ static void cb_getvar(struct usb_ep *ep, struct usb_request 
*req)
else
strcpy(response, FAILValue not set);
} else {
+   printf(%s: unknown variable: %s\n, __func__, cmd);
strcpy(response, FAILVariable not implemented);
}
fastboot_tx_write_str(response);
@@ -531,10 +533,12 @@ static void rx_handler_command(struct usb_ep *ep, struct 
usb_request *req)
}
}
 
-   if (!func_cb)
+   if (!func_cb) {
+   printf(%s: unknown command: %s\n, __func__, cmdbuf);
fastboot_tx_write_str(FAILunknown command);
-   else
+   } else {
func_cb(ep, req);
+   }
 
if (req-status == 0) {
*cmdbuf = '\0';
-- 
1.8.5

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


[U-Boot] [PATCH] board: ti: dra7xx: add mux data for UART3

2014-06-26 Thread Felipe Balbi
J6 EVM can be built with UART3 as console, but currently
there's nothing muxing UART3 correctly. Likely this only
works because, based on commit log, author was only testing
with UART3 boot and - I assume - ROM code leave UART3 correctly
muxed in that case.

If we want to boot from MMC and still use UART3 as console,
then we need to mux those signals correctly.

Signed-off-by: Felipe Balbi ba...@ti.com
---
 board/ti/dra7xx/mux_data.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/board/ti/dra7xx/mux_data.h b/board/ti/dra7xx/mux_data.h
index 38de9d5..c9e202a 100644
--- a/board/ti/dra7xx/mux_data.h
+++ b/board/ti/dra7xx/mux_data.h
@@ -31,10 +31,15 @@ const struct pad_conf_entry core_padconf_array_essential[] 
= {
{GPMC_A26, (IEN | PTU | PDIS | M1)},/* mmc2_dat2 */
{GPMC_A27, (IEN | PTU | PDIS | M1)},/* mmc2_dat3 */
{GPMC_CS1, (IEN | PTU | PDIS | M1)},/* mmm2_cmd */
+#if (CONFIG_CONS_INDEX == 1)
{UART1_RXD, (FSC | IEN | PTU | PDIS | M0)}, /* UART1_RXD */
{UART1_TXD, (FSC | IEN | PTU | PDIS | M0)}, /* UART1_TXD */
{UART1_CTSN, (IEN | PTU | PDIS | M3)},  /* UART1_CTSN */
{UART1_RTSN, (IEN | PTU | PDIS | M3)},  /* UART1_RTSN */
+#elif (CONFIG_CONS_INDEX == 3)
+   {UART3_RXD, (FSC | IEN | PTU | PDIS | M0)}, /* UART3_RXD */
+   {UART3_TXD, (FSC | IEN | PTU | PDIS | M0)}, /* UART3_TXD */
+#endif
{I2C1_SDA, (IEN | PTU | PDIS | M0)},/* I2C1_SDA */
{I2C1_SCL, (IEN | PTU | PDIS | M0)},/* I2C1_SCL */
{MDIO_MCLK, (PTU | PEN | M0)},  /* MDIO_MCLK  */
-- 
2.0.0.390.gcb682f8

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


Re: [U-Boot] [PATCH 1/3] i2c: tegra: use repeated start for reads

2014-06-26 Thread Stephen Warren
On 06/26/2014 02:01 PM, Joakim Tjernlund wrote:
...
 Strange, I had a look at the driver and I have a hard time figuring out 
 how/when START/STOP
 is generated. However I don't think the current driver's 
 wait_for_transfer_complete() waits for
 the START/STOP. I guess it waits until all data bytes are finished so STOP 
 completion time
 isn't accounted for.
 
 Where is STOP initiated and where did you add the delay?

STOP (or REPEATED_START) happen automatically in HW once it's finished
transferring all the bytes in the TX FIFO, and before the transaction
complete interrupt is asserted. I added the delay immediately after the
loop that spins waiting for transaction complete IRQ status to be set.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot