Re: [U-Boot] [PATCH v3] dfu: Introduction of the "dfu_hash_algo" env variable for checksum method setting

2014-05-08 Thread Lukasz Majewski
Hi Wolfgang,

> Dear Lukasz Majewski,
> 
> In message <1399552067-31208-1-git-send-email-l.majew...@samsung.com>
> you wrote:
> > Up till now the CRC32 of received data was calculated
> > unconditionally. The standard crc32 implementation causes long
> > delay when large images were uploaded.
> > 
> > The "dfu_hash_algo" environment variable gives the opportunity to
> > enable on demand (when e.g. debugging) the hash (crc32) calculation.
> > It can be done without need to recompile the u-boot binary and
> > reuses the generic hash framework.
> > 
> > By default the crc32 is NOT calculated anymore.
> 
> I consider this a VARY BAD idea, as it causes a significant decrease
> of reliability and robustness of the systems.  Please do not do this.

I do understand that reliability is very important, but please
consider following arguments:

1. Now calculated crc32 is only used for debugging. 

For automated tests I use MD5 and compare this value before sending
data to target via DFU and after I read it. This testing is done purely
on HOST machine.

Please refer to the discussion which we had at previous version of this
patch:

http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/183311/focus=183455

Participants have agreed, that we shall optionally enable crc32 (or
other algorithm) calculation. 

2. The current crc32 implementation is painfully slow (although I have
only L1 enabled on my target). 

3. With large files (like rootfs images) we store data (to medium) with
32 MiB chunks, which means that when we calculate complete crc32 the
image is already written to its final destination.

Of course we could store the rootfs to some "free" space on the eMMC,
then calculate crc32 and store it to the final position. This however
would take considerable time and require wrapping our binaries to
special headers (as described below). 

4. This patch also allows some flexibility: by setting the env variable
we can decide which algorithm to use (crc32, sha1, etc). It is
appealing since we use the hash_* code anyway.

> 
> In any case, if you introduce this, the behaviour should be
> documented, and the default setting should be such as to keep the
> previous behaviour, i. e. CRC checking should remain on by default.
> then people who are willing to trade reliability for a little speed

I would not touch the code if the speedup wouldn't be so significant.
Reducing flashing time of 400 MiB file from 65 s to 25 s is worth its
effort.

> can still switch it off, but the unawarerest of the users will not
> suffer.

As I've stated previously the crc32 in the current dfu implementation
is only informative.

To take the full advantage of it, we would need to modify the dfu-util
to wrap the sent file to some kind of header or locally write some
script to do that. However, this is not specified by the standard and
would be u-boot's extension of the DFU. 

Even more important issue is that it would work only for small files
(like uImage).

> 
> 
> Best regards,
> 
> Wolfgang Denk
> 

-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/4] bootm: allow to disable legacy image format

2014-05-08 Thread Heiko Schocher

Hello Mike,

Am 08.05.2014 15:02, schrieb mike:

Hi Heiko,

Did you see my last email? The one that bounced with a mime header and where I 
attached a patch file.


Seems I missed this EMail ...


I just wonder if its not better to switch the define to be

if (CONFIG_SIGNATURE_VERIFICATION_WITH_LEGACY_SIDE_DOOR). It can become 
mutually exclusive with the existing signature verification define.


The define length seems a little long, but this is also an option.
I just prepared my patch after Simons comment, see:

http://lists.denx.de/pipermail/u-boot/2014-May/179139.html


That way the legacy stuff is removed automatically upon requesting verification 
unless defined otherwise. When you fail to boot an unsigned legacy kernel then 
its kind of obvious that you have to solve something but if you implement 
verified boot and
forget this new variable then you leave a security hole.

In my last email I also discussed my confusion regard the 'required' variable. 
Similar argument to the above plus some other thoughts.


Was this EMail on the U-Boot ML? I could not find it...
Can you send a link?

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


Re: [U-Boot] [PATCH 1/4] bootm: allow to disable legacy image format

2014-05-08 Thread Wolfgang Denk
Dear mike,

In message <536b8062.6030...@kaew.be> you wrote:
> Hi Heiko,
> 
> Did you see my last email? The one that bounced with a mime header and 
> where I attached a patch file.
> 
> I just wonder if its not better to switch the define to be
> 
> if (CONFIG_SIGNATURE_VERIFICATION_WITH_LEGACY_SIDE_DOOR). It can become 
> mutually exclusive with the existing signature verification define.

Can we please come up with somewhat longer macro names? :-(

Please try and find some more reasonable (short!) names!

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
Intel's new motto: United we stand. Divided we fall!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v3] dfu: Introduction of the "dfu_hash_algo" env variable for checksum method setting

2014-05-08 Thread Wolfgang Denk
Dear Lukasz Majewski,

In message <1399552067-31208-1-git-send-email-l.majew...@samsung.com> you wrote:
> Up till now the CRC32 of received data was calculated unconditionally.
> The standard crc32 implementation causes long delay when large images
> were uploaded.
> 
> The "dfu_hash_algo" environment variable gives the opportunity to
> enable on demand (when e.g. debugging) the hash (crc32) calculation.
> It can be done without need to recompile the u-boot binary and reuses
> the generic hash framework.
> 
> By default the crc32 is NOT calculated anymore.

I consider this a VARY BAD idea, as it causes a significant decrease
of reliability and robustness of the systems.  Please do not do this.

In any case, if you introduce this, the behaviour should be
documented, and the default setting should be such as to keep the
previous behaviour, i. e. CRC checking should remain on by default.
then people who are willing to trade reliability for a little speed
can still switch it off, but the unawarerest of the users will not
suffer.


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
As far as the laws of mathematics refer  to  reality,  they  are  not
certain;  and  as  far  as  they  are  certain,  they do not refer to
reality.   -- Albert Einstein
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v2 3/3] mx28evk: Add documentation on how to boot from SPI NOR

2014-05-08 Thread Fabio Estevam
From: Fabio Estevam 

Explain the necessary steps in order to boot from SPI NOR.

Based on a earlier submission from Mårten Wikman.

Signed-off-by: Mårten Wikman 
Signed-off-by: Fabio Estevam 
---
Changes since v1:
- Remove accidental hunk:
"-
+n"

 board/freescale/mx28evk/README | 22 +++---
 doc/README.mxs | 26 ++
 2 files changed, 45 insertions(+), 3 deletions(-)

diff --git a/board/freescale/mx28evk/README b/board/freescale/mx28evk/README
index 0389a1d..958ebc6 100644
--- a/board/freescale/mx28evk/README
+++ b/board/freescale/mx28evk/README
@@ -23,11 +23,19 @@ To boot MX28EVK from an SD card, set the boot mode DIP 
switches as:
* VDD 5V: To the left (off)
* Hold Button: Down (off)
 
+To boot MX28EVK from SPI NOR flash, set the boot mode DIP switches as:
+
+   * Boot Mode Select: 0 0 1 0 (Boot from SSP2)
+   * JTAG PSWITCH RESET: To the right (reset disabled)
+   * Battery Source: Down
+   * Wall 5V: Up
+   * VDD 5V: To the left (off)
+   * Hold Button: Down (off)
 
 Environment Storage
 ---
 
-There are two targets for mx28evk:
+There are three targets for mx28evk:
 
 "make mx28evk_config"  - store environment variables into MMC
 
@@ -35,12 +43,20 @@ or
 
 "make mx28evk_nand_config" - store environment variables into NAND flash
 
+or
+
+"make mx28evk_spi_config"   - store enviroment variables into SPI NOR flash
+
 Choose the target accordingly.
 
 Note: The mx28evk board does not come with a NAND flash populated from the
 factory. It comes with an empty slot (U23), which allows the insertion of a
 48-pin TSOP flash device.
 
-Follow the instructions from doc/README.mxs to generate a bootable SD card.
+mx28evk does not come with SPI NOR flash populated from the factory either.
+It is possible to solder a SOIC memory on U49 or use a DIP8 on J89.
+To get SPI communication to work R320, R321,R322 and C178 need to be populated.
+Look in the schematics for the proper component values.
 
-Insert the SD card in slot 0, power up the board and U-boot will boot.
+Follow the instructions from doc/README.mxs to generate a bootable SD card or
+to generate a binary to be flashed into SPI NOR.
diff --git a/doc/README.mxs b/doc/README.mxs
index 0235a5a..ed2e568 100644
--- a/doc/README.mxs
+++ b/doc/README.mxs
@@ -23,6 +23,7 @@ Contents
 2) Compiling U-Boot for a MXS based board
 3) Installation of U-Boot for a MXS based board to SD card
 4) Installation of U-Boot into NAND flash on a MX28 based board
+5) Installation of U-boot into SPI NOR flash on a MX28 based board
 
 1) Prerequisites
 
@@ -262,3 +263,28 @@ There are two possibilities when preparing an image 
writable to NAND flash.
   In case the user needs to boot a firmware image bigger than 1Mb, the
   user has to adjust the "update_nand_firmware_maxsz" variable for the
   update scripts to work properly.
+
+5) Installation of U-Boot into SPI NOR flash on a MX28 based board
+--
+
+The u-boot.sb file can be directly written to SPI NOR from U-boot prompt.
+
+Load u-boot.sb into RAM, this can be done in several ways and one way is to use
+tftp:
+   => tftp u-boot.sb 0x4200
+
+Probe the SPI NOR flash:
+   => sf probe
+
+(SPI NOR should be succesfully detected in this step)
+
+Erase the blocks where U-boot binary will be written to:
+   => sf erase 0x0 0x8
+
+Write u-boot.sb to SPI NOR:
+   => sf write 0x4200 0 0x8
+
+Power off the board and set the boot mode DIP switches to boot from the SPI NOR
+according to MX28 manual section 12.2.1 (Table 12-2)
+
+Last step is to power up the board and U-boot should start from SPI NOR.
-- 
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 2/3] mx28evk: Add a target for SPI NOR boot

2014-05-08 Thread Fabio Estevam
From: Fabio Estevam 

Introduce 'mx28evk_spi' target which will store the environment variables
into SPI NOR, which is useful when booting from SPI NOR.

Signed-off-by: Fabio Estevam 
---
Changes since v1:
- None

 boards.cfg | 1 +
 1 file changed, 1 insertion(+)

diff --git a/boards.cfg b/boards.cfg
index 89ed095..7e24ab8 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -214,6 +214,7 @@ Active  arm arm926ejs  mxs freescale
   mx23evk
 Active  arm arm926ejs  mxs freescale   mx28evk 
mx28evk  mx28evk:ENV_IS_IN_MMC  

   Fabio Estevam 
 Active  arm arm926ejs  mxs freescale   mx28evk 
mx28evk_auart_console
mx28evk:MXS_AUART,MXS_AUART_BASE=MXS_UARTAPP3_BASE,ENV_IS_IN_MMC
  Fabio Estevam 

 Active  arm arm926ejs  mxs freescale   mx28evk 
mx28evk_nand mx28evk:ENV_IS_IN_NAND 

   Fabio Estevam 
+Active  arm arm926ejs  mxs freescale   mx28evk 
mx28evk_spi  mx28evk:ENV_IS_IN_SPI_FLASH

Fabio Estevam 
 Active  arm arm926ejs  mxs olimex  mx23_olinuxino  
mx23_olinuxino   -  

   Marek Vasut 
 Active  arm arm926ejs  mxs ppcag   bg0900  
bg0900   -  

   Marek Vasut 
 Active  arm arm926ejs  mxs sandisk sansa_fuze_plus 
sansa_fuze_plus  -  

   Marek Vasut 
-- 
1.8.3.2

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


[U-Boot] [PATCH v2 1/3] mx28evk: Remove extra CONFIG_ENV_SIZE

2014-05-08 Thread Fabio Estevam
From: Fabio Estevam 

When building a target with CONFIG_ENV_IS_IN_SPI_FLASH the following build
warning is seen:

include/configs/mx28evk.h:73:0: warning: "CONFIG_ENV_SIZE" redefined [enabled 
by default]

Each target has its own CONFIG_ENV_SIZE definition, so remove the one that
does not belong to any target.

While at it, fix a typo.

Signed-off-by: Fabio Estevam 
---
Changes since v1:
- None

 include/configs/mx28evk.h | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h
index 9b9124a..e5370f3 100644
--- a/include/configs/mx28evk.h
+++ b/include/configs/mx28evk.h
@@ -48,7 +48,6 @@
 #define CONFIG_SYS_SDRAM_BASE  PHYS_SDRAM_1
 
 /* Environment */
-#define CONFIG_ENV_SIZE(16 * 1024)
 #define CONFIG_ENV_OVERWRITE
 
 /* Environment is in MMC */
@@ -67,7 +66,7 @@
(CONFIG_ENV_OFFSET + CONFIG_ENV_RANGE)
 #endif
 
-/* Environemnt is in SPI flash */
+/* Environment is in SPI flash */
 #if defined(CONFIG_CMD_SF) && defined(CONFIG_ENV_IS_IN_SPI_FLASH)
 #define CONFIG_SYS_REDUNDAND_ENVIRONMENT
 #define CONFIG_ENV_SIZE0x1000  /* 4KB */
-- 
1.8.3.2

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


[U-Boot] [PATCH 3/3] mx28evk: Add documentation on how to boot from SPI NOR

2014-05-08 Thread Fabio Estevam
From: Fabio Estevam 

Explain the necessary steps in order to boot from SPI NOR.

Based on a early submission from Mårten Wikman.

Signed-off-by: Mårten Wikman 
Signed-off-by: Fabio Estevam 
---
 board/freescale/mx28evk/README | 24 
 doc/README.mxs | 26 ++
 2 files changed, 46 insertions(+), 4 deletions(-)

diff --git a/board/freescale/mx28evk/README b/board/freescale/mx28evk/README
index 0389a1d..7148089 100644
--- a/board/freescale/mx28evk/README
+++ b/board/freescale/mx28evk/README
@@ -23,24 +23,40 @@ To boot MX28EVK from an SD card, set the boot mode DIP 
switches as:
* VDD 5V: To the left (off)
* Hold Button: Down (off)
 
+To boot MX28EVK from SPI NOR flash, set the boot mode DIP switches as:
+
+   * Boot Mode Select: 0 0 1 0 (Boot from SSP2)
+   * JTAG PSWITCH RESET: To the right (reset disabled)
+   * Battery Source: Down
+   * Wall 5V: Up
+   * VDD 5V: To the left (off)
+   * Hold Button: Down (off)
 
 Environment Storage
 ---
 
-There are two targets for mx28evk:
+There are three targets for mx28evk:
 
 "make mx28evk_config"  - store environment variables into MMC
-
+n
 or
 
 "make mx28evk_nand_config" - store environment variables into NAND flash
 
+or
+
+"make mx28evk_spi_config"   - store enviroment variables into SPI NOR flash
+
 Choose the target accordingly.
 
 Note: The mx28evk board does not come with a NAND flash populated from the
 factory. It comes with an empty slot (U23), which allows the insertion of a
 48-pin TSOP flash device.
 
-Follow the instructions from doc/README.mxs to generate a bootable SD card.
+mx28evk does not come with SPI NOR flash populated from the factory either.
+It is possible to solder a SOIC memory on U49 or use a DIP8 on J89.
+To get SPI communication to work R320, R321,R322 and C178 need to be populated.
+Look in the schematics for the proper component values.
 
-Insert the SD card in slot 0, power up the board and U-boot will boot.
+Follow the instructions from doc/README.mxs to generate a bootable SD card or
+to generate a binary to be flashed into SPI NOR.
diff --git a/doc/README.mxs b/doc/README.mxs
index 0235a5a..9d7a9b1 100644
--- a/doc/README.mxs
+++ b/doc/README.mxs
@@ -23,6 +23,7 @@ Contents
 2) Compiling U-Boot for a MXS based board
 3) Installation of U-Boot for a MXS based board to SD card
 4) Installation of U-Boot into NAND flash on a MX28 based board
+5) Installation of U-boot into SPI NOR flash on a MX28 based board
 
 1) Prerequisites
 
@@ -262,3 +263,28 @@ There are two possibilities when preparing an image 
writable to NAND flash.
   In case the user needs to boot a firmware image bigger than 1Mb, the
   user has to adjust the "update_nand_firmware_maxsz" variable for the
   update scripts to work properly.
+
+5) Installation of U-Boot into SPI NOR flash on a MX28 based board
+--
+
+The u-boot.sb file can be directly written to SPI NOR from U-boot prompt.
+
+Load u-boot.sb into RAM, this can be done in several ways and one way is to use
+tftp:
+   => tftp u-boot.sb 0x4200
+
+Probe the SPI NOR flash:
+   => sf probe
+
+(SPI NOR should be succesfully detected in this step)
+
+Erase the blocks where U-boot binary will be written to:
+   => sf erase 0x0 0x8
+
+Write u-boot.sb to SPI NOR:
+   => sf write 0x4200 0 0x8
+
+Power off the board and set the boot mode DIP switches to boot from the SPI NOR
+according to MX28 manual section 12.2.1 (Table 12-2)
+
+Last step is to power up the board and U-boot should start from SPI NOR.
-- 
1.8.3.2

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


[U-Boot] [PATCH 2/3] mx28evk: Add a target for SPI NOR boot

2014-05-08 Thread Fabio Estevam
From: Fabio Estevam 

Introduce 'mx28evk_spi' target which will store the environment variables
into SPI NOR, which is useful when booting from SPI NOR.

Signed-off-by: Fabio Estevam 
---
 boards.cfg | 1 +
 1 file changed, 1 insertion(+)

diff --git a/boards.cfg b/boards.cfg
index 89ed095..7e24ab8 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -214,6 +214,7 @@ Active  arm arm926ejs  mxs freescale
   mx23evk
 Active  arm arm926ejs  mxs freescale   mx28evk 
mx28evk  mx28evk:ENV_IS_IN_MMC  

   Fabio Estevam 
 Active  arm arm926ejs  mxs freescale   mx28evk 
mx28evk_auart_console
mx28evk:MXS_AUART,MXS_AUART_BASE=MXS_UARTAPP3_BASE,ENV_IS_IN_MMC
  Fabio Estevam 

 Active  arm arm926ejs  mxs freescale   mx28evk 
mx28evk_nand mx28evk:ENV_IS_IN_NAND 

   Fabio Estevam 
+Active  arm arm926ejs  mxs freescale   mx28evk 
mx28evk_spi  mx28evk:ENV_IS_IN_SPI_FLASH

Fabio Estevam 
 Active  arm arm926ejs  mxs olimex  mx23_olinuxino  
mx23_olinuxino   -  

   Marek Vasut 
 Active  arm arm926ejs  mxs ppcag   bg0900  
bg0900   -  

   Marek Vasut 
 Active  arm arm926ejs  mxs sandisk sansa_fuze_plus 
sansa_fuze_plus  -  

   Marek Vasut 
-- 
1.8.3.2

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


[U-Boot] [PATCH 1/3] mx28evk: Remove extra CONFIG_ENV_SIZE

2014-05-08 Thread Fabio Estevam
From: Fabio Estevam 

When building a target with CONFIG_ENV_IS_IN_SPI_FLASH the following build
warning is seen:

include/configs/mx28evk.h:73:0: warning: "CONFIG_ENV_SIZE" redefined [enabled 
by default]

Each target has its own CONFIG_ENV_SIZE definition, so remove the one that
does not belong to any target.

While at it, fix a typo.

Signed-off-by: Fabio Estevam 
---
 include/configs/mx28evk.h | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h
index 9b9124a..e5370f3 100644
--- a/include/configs/mx28evk.h
+++ b/include/configs/mx28evk.h
@@ -48,7 +48,6 @@
 #define CONFIG_SYS_SDRAM_BASE  PHYS_SDRAM_1
 
 /* Environment */
-#define CONFIG_ENV_SIZE(16 * 1024)
 #define CONFIG_ENV_OVERWRITE
 
 /* Environment is in MMC */
@@ -67,7 +66,7 @@
(CONFIG_ENV_OFFSET + CONFIG_ENV_RANGE)
 #endif
 
-/* Environemnt is in SPI flash */
+/* Environment is in SPI flash */
 #if defined(CONFIG_CMD_SF) && defined(CONFIG_ENV_IS_IN_SPI_FLASH)
 #define CONFIG_SYS_REDUNDAND_ENVIRONMENT
 #define CONFIG_ENV_SIZE0x1000  /* 4KB */
-- 
1.8.3.2

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


Re: [U-Boot] [PATCH] usb: ci_udc: parse QTD before over-writing it

2014-05-08 Thread Stephen Warren
On 05/08/2014 05:16 PM, Stephen Warren wrote:
> From: Stephen Warren 
> 
> ci_udc only allocates a single QTD structure per EP. All data needs to be
> extracted from the DTD prior to calling handle_ep_complete(), since that

Oh. s/handle_ep_complete/ci_ep_submit_next_request/ there... Let me know
if you want me to repost with that fixed, or whether you can fix it up
when you apply this. Thanks.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH] usb: ci_udc: parse QTD before over-writing it

2014-05-08 Thread Stephen Warren
From: Stephen Warren 

ci_udc only allocates a single QTD structure per EP. All data needs to be
extracted from the DTD prior to calling handle_ep_complete(), since that
fills the QTD with next transaction's parameters. Fix handle_ep_complete()
to extract the transaction (remaining) length before kicking off the next
transaction.

In practice, this only causes writes to UMS devices to fail for me. I may
have tested the final versions of my previous ci_udc patch only with
reads. More recently, I had patches applied locally that allocated a QTD
per USB request rather than per USB EP, although since that doesn't give
any performance benefit, I'm dropping those.

Fixes: 2813006fecda ("usb: ci_udc: allow multiple buffer allocs per ep")
Signed-off-by: Stephen Warren 
---
 drivers/usb/gadget/ci_udc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/ci_udc.c b/drivers/usb/gadget/ci_udc.c
index 290863d61fc9..9cd003636a44 100644
--- a/drivers/usb/gadget/ci_udc.c
+++ b/drivers/usb/gadget/ci_udc.c
@@ -424,6 +424,7 @@ static void handle_ep_complete(struct ci_ep *ep)
item = ci_get_qtd(num, in);
ci_invalidate_qtd(num);
 
+   len = (item->info >> 16) & 0x7fff;
if (item->info & 0xff)
printf("EP%d/%s FAIL info=%x pg0=%x\n",
   num, in ? "in" : "out", item->info, item->page0);
@@ -435,7 +436,6 @@ static void handle_ep_complete(struct ci_ep *ep)
if (!list_empty(&ep->queue))
ci_ep_submit_next_request(ep);
 
-   len = (item->info >> 16) & 0x7fff;
ci_req->req.actual = ci_req->req.length - len;
ci_debounce(ci_req, in);
 
-- 
1.8.1.5

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


Re: [U-Boot] [PATCH 2/4] mpc8313, signed fit: disable legacy image format on ids8313 board

2014-05-08 Thread Kim Phillips
On Thu, 8 May 2014 13:05:16 +0200
Heiko Schocher  wrote:

> Disable legacy image format with CONFIG_DISABLE_IMAGE_FORMAT_LEGACY
> on the ids8313 board, as it uses signed FIT images for booting
> Linux.
> 
> Signed-off-by: Heiko Schocher 
> Cc: Simon Glass 
> Cc: Kim Phillips 
> Cc: Michael Conrad 
> ---

on behalf of mpc83xx:

Acked-by: Kim Phillips 

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


[U-Boot] [PATCH v3 4/5] net/designware: reorder struct dw_eth_dev to pack more efficiently.

2014-05-08 Thread Ian Campbell
The {tx,rx}_mac_descrtable fields are aligned to ARCH_DMA_MINALIGN, which could
be 256 or even larger. That means there is a potentially huge hole in the
struct before those fields, so move them to the front where they are better
packed.

Moving them to the front also helps ensure that so long as dw_eth_dev is
properly aligned (which it is since "net/designware: ensure device private data
is DMA aligned.") the {tx,rx}_mac_descrtable will be too, or at least avoids
having to worry too much about compiler specifics.

The {r,t}xbuffs fields also need to be aligned. Previously this was done
implicitly because they immediately followed the descriptor tables. Make this
explicit and also move to the head of the struct.

Signed-off-by: Ian Campbell 
Cc: Alexey Brodkin 
---
v3: Also align tx and rx bufs
---
 drivers/net/designware.h | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/designware.h b/drivers/net/designware.h
index 382b0c7..eac5e72 100644
--- a/drivers/net/designware.h
+++ b/drivers/net/designware.h
@@ -215,15 +215,15 @@ struct dmamacdescr {
 #endif
 
 struct dw_eth_dev {
+   struct dmamacdescr tx_mac_descrtable[CONFIG_TX_DESCR_NUM];
+   struct dmamacdescr rx_mac_descrtable[CONFIG_RX_DESCR_NUM];
+
u32 interface;
u32 tx_currdescnum;
u32 rx_currdescnum;
 
-   struct dmamacdescr tx_mac_descrtable[CONFIG_TX_DESCR_NUM];
-   struct dmamacdescr rx_mac_descrtable[CONFIG_RX_DESCR_NUM];
-
-   char txbuffs[TX_TOTAL_BUFSIZE];
-   char rxbuffs[RX_TOTAL_BUFSIZE];
+   char txbuffs[TX_TOTAL_BUFSIZE] __aligned(ARCH_DMA_MINALIGN);
+   char rxbuffs[RX_TOTAL_BUFSIZE] __aligned(ARCH_DMA_MINALIGN);
 
struct eth_mac_regs *mac_regs_p;
struct eth_dma_regs *dma_regs_p;
-- 
1.9.0

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


[U-Boot] [PATCH v3 3/5] net/designware: ensure cache invalidations are aligned to ARCH_DMA_MINALIGN

2014-05-08 Thread Ian Campbell
This is required at least on ARM.

When sending instead of simply invalidating the entire descriptor, flush
as little as possible while still respecting ARCH_DMA_MINALIGN, as
requested by Alexey.

Signed-off-by: Ian Campbell 
Cc: Alexey Brodkin 
---
v2: - collapsed "net/designware: align cache invalidation on rx" and
  "net/designware: invalidate entire descriptor in dw_eth_send" into
  one.
- roundup sizeof(txrx_status) to ARCH_DMA_MINALIGN instead of just
  invalidating the entire descriptor.
---
 drivers/net/designware.c | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/net/designware.c b/drivers/net/designware.c
index 41ab3ac..fa816bf 100644
--- a/drivers/net/designware.c
+++ b/drivers/net/designware.c
@@ -280,10 +280,18 @@ static int dw_eth_send(struct eth_device *dev, void 
*packet, int length)
u32 desc_num = priv->tx_currdescnum;
struct dmamacdescr *desc_p = &priv->tx_mac_descrtable[desc_num];
 
-   /* Invalidate only "status" field for the following check */
-   invalidate_dcache_range((unsigned long)&desc_p->txrx_status,
-   (unsigned long)&desc_p->txrx_status +
-   sizeof(desc_p->txrx_status));
+   /*
+* Strictly we only need to invalidate the "txrx_status" field
+* for the following check, but on some platforms we cannot
+* invalidate only 4 bytes, so roundup to
+* ARCH_DMA_MINALIGN. This is safe because the individual
+* descriptors in the array are each aligned to
+* ARCH_DMA_MINALIGN.
+*/
+   invalidate_dcache_range(
+   (unsigned long)desc_p,
+   (unsigned long)desc_p +
+   roundup(sizeof(desc_p->txrx_status), ARCH_DMA_MINALIGN));
 
/* Check if the descriptor is owned by CPU */
if (desc_p->txrx_status & DESC_TXSTS_OWNBYDMA) {
@@ -351,7 +359,7 @@ static int dw_eth_recv(struct eth_device *dev)
/* Invalidate received data */
invalidate_dcache_range((unsigned long)desc_p->dmamac_addr,
(unsigned long)desc_p->dmamac_addr +
-   length);
+   roundup(length, ARCH_DMA_MINALIGN));
 
NetReceive(desc_p->dmamac_addr, length);
 
-- 
1.9.0

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


[U-Boot] [PATCH v3 5/5] net/designware: Make DMA burst length configurable and reduce by default

2014-05-08 Thread Ian Campbell
The correct value for this setting can vary across SoCs and boards, so make it
configurable.

Also reduce the default value to 8, which is the same default as used in the
Linux driver.

Signed-off-by: Ian Campbell 
Cc: Alexey Brodkin 
---
v3: Pulled into this series instead of sunxi series.
---
 drivers/net/designware.c |  2 +-
 drivers/net/designware.h | 12 ++--
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/net/designware.c b/drivers/net/designware.c
index fa816bf..7186e3b 100644
--- a/drivers/net/designware.c
+++ b/drivers/net/designware.c
@@ -249,7 +249,7 @@ static int dw_eth_init(struct eth_device *dev, bd_t *bis)
rx_descs_init(dev);
tx_descs_init(dev);
 
-   writel(FIXEDBURST | PRIORXTX_41 | BURST_16, &dma_p->busmode);
+   writel(FIXEDBURST | PRIORXTX_41 | DMA_PBL, &dma_p->busmode);
 
writel(readl(&dma_p->opmode) | FLUSHTXFIFO | STOREFORWARD,
   &dma_p->opmode);
diff --git a/drivers/net/designware.h b/drivers/net/designware.h
index eac5e72..e5b5e20 100644
--- a/drivers/net/designware.h
+++ b/drivers/net/designware.h
@@ -77,18 +77,18 @@ struct eth_dma_regs {
 
 #define DW_DMA_BASE_OFFSET (0x1000)
 
+/* Default DMA Burst length */
+#ifndef CONFIG_DW_GMAC_DEFAULT_DMA_PBL
+#define CONFIG_DW_GMAC_DEFAULT_DMA_PBL 8
+#endif
+
 /* Bus mode register definitions */
 #define FIXEDBURST (1 << 16)
 #define PRIORXTX_41(3 << 14)
 #define PRIORXTX_31(2 << 14)
 #define PRIORXTX_21(1 << 14)
 #define PRIORXTX_11(0 << 14)
-#define BURST_1(1 << 8)
-#define BURST_2(2 << 8)
-#define BURST_4(4 << 8)
-#define BURST_8(8 << 8)
-#define BURST_16   (16 << 8)
-#define BURST_32   (32 << 8)
+#define DMA_PBL(CONFIG_DW_GMAC_DEFAULT_DMA_PBL<<8)
 #define RXHIGHPRIO (1 << 1)
 #define DMAMAC_SRST(1 << 0)
 
-- 
1.9.0

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


[U-Boot] [PATCH v3 2/5] net/designware: ensure device private data is DMA aligned.

2014-05-08 Thread Ian Campbell
struct dw_eth_dev contains fields which are accessed via DMA, so make sure it
is aligned to a dma boundary. Without this I see:
ERROR: v7_dcache_inval_range - start address is not aligned - 0x7fb677e0

Signed-off-by: Ian Campbell 
Reviewed-by: Alexey Brodkin 
Acked-by: Marek Vasut 
---
v2: Sign of with my own mail not my work mail. I made these changes on my
own time, but a .gitconfig vcsh mismerge caused "git commit -s" to use the
wrong thing. (I wondered why everyone was CCing me at work...)
---
 drivers/net/designware.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/designware.c b/drivers/net/designware.c
index 78751b2..41ab3ac 100644
--- a/drivers/net/designware.c
+++ b/drivers/net/designware.c
@@ -414,7 +414,8 @@ int designware_initialize(ulong base_addr, u32 interface)
 * Since the priv structure contains the descriptors which need a strict
 * buswidth alignment, memalign is used to allocate memory
 */
-   priv = (struct dw_eth_dev *) memalign(16, sizeof(struct dw_eth_dev));
+   priv = (struct dw_eth_dev *) memalign(ARCH_DMA_MINALIGN,
+ sizeof(struct dw_eth_dev));
if (!priv) {
free(dev);
return -ENOMEM;
-- 
1.9.0

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


[U-Boot] [PATCH v3 0/5] net/designware: fixes for data cache, phylib and burst size

2014-05-08 Thread Ian Campbell
Pulling together various fixes for designware into a single series. I'm
calling this v3, although some of these never had a v2.

Most of these have been floating around for a few weeks, the cache line
issues in particular mean that the driver is unlikely to work on any ARM
system. I've been testing these on top of my sunxi mainlining series.

I've also thrown them onto gitorious. Pull-request details are below.

Thanks,
Ian.

The following changes since commit dda0dbfc69f3d560c87f5be85f127ed862ea6721:

  Prepare v2014.04 (2014-04-14 15:19:24 -0400)

are available in the git repository at:

  git://gitorious.org/ijc/u-boot.git designware

for you to fetch changes up to 5e3e5c37bc7a867ca42fa43f69ad764c8942b631:

  net/designware: Make DMA burst length configurable and reduce by default 
(2014-05-08 22:16:33 +0100)


Ian Campbell (5):
  net/designware: call phy_connect_dev() to properly setup phylib device
  net/designware: ensure device private data is DMA aligned.
  net/designware: ensure cache invalidations are aligned to 
ARCH_DMA_MINALIGN
  net/designware: reorder struct dw_eth_dev to pack more efficiently.
  net/designware: Make DMA burst length configurable and reduce by default

 drivers/net/designware.c | 25 ++---
 drivers/net/designware.h | 22 +++---
 2 files changed, 29 insertions(+), 18 deletions(-)


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


[U-Boot] [PATCH v3 1/5] net/designware: call phy_connect_dev() to properly setup phylib device

2014-05-08 Thread Ian Campbell
This sets up the linkage from the phydev back to the ethernet device. This
symptom of not doing this which I noticed was:
 Waiting for PHY auto negotiation to complete
rather than:
dwmac.1c5 Waiting for PHY auto negotiation to complete

Signed-off-by: Ian Campbell 
Cc: Alexey Brodkin 
---
 drivers/net/designware.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/designware.c b/drivers/net/designware.c
index c45593b..78751b2 100644
--- a/drivers/net/designware.c
+++ b/drivers/net/designware.c
@@ -390,6 +390,8 @@ static int dw_phy_init(struct eth_device *dev)
if (!phydev)
return -1;
 
+   phy_connect_dev(phydev, dev);
+
phydev->supported &= PHY_GBIT_FEATURES;
phydev->advertising = phydev->supported;
 
-- 
1.9.0

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


Re: [U-Boot] [PATCH 4/4] mpc8313: add CONFIG_SYS_GENERIC_BOARD to ids8313 board

2014-05-08 Thread Kim Phillips
On Thu, 8 May 2014 13:05:18 +0200
Heiko Schocher  wrote:

> - add CONFIG_SYS_GENERIC_BOARD
> - remove CONFIG_OF_CONTROL to boot again
> 
> Signed-off-by: Heiko Schocher 
> Cc: Simon Glass 
> Cc: Kim Phillips 
> ---

on behalf of mpc83xx:

Acked-by: Kim Phillips 

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


Re: [U-Boot] [PATCH] boards.cfg: fix a configuration error of ep8248 board

2014-05-08 Thread Kim Phillips
On Wed, 30 Apr 2014 07:14:53 +0200
Heiko Schocher  wrote:

> Hello Masahiro,
> 
> Am 30.04.2014 05:55, schrieb Masahiro Yamada:
> > "make ep8248_config" fails with an error like this:
> >
> >  $ make ep8248_config
> >  make: *** [ep8248_config] Error 1
> >
> > Its cause is that there are two entries for "ep8248".
> >
> > The first is around line 652 of boards.cfg. (as Active)
> >
> > The second appears around line 1230. (as Orphan)
> >
> > This bug was accidentally introduced by commit e7e90901.
> > But it is not the author's fault. He just intended to change
> > IDS8247 board.
> >
> > The commiter added ep8248 entry by mistake when he resolved a conflict.
> >
> > Signed-off-by: Masahiro Yamada
> > Cc: Heiko Schocher
> > Cc: Kim Phillips
> 
> Thanks for detecting this!
> 
> Acked-by: Heiko Schocher 

apologies for the damage:

Acked-by: Kim Phillips 

Wolfgang and/or Tom, please feel free to apply directly.

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


[U-Boot] [sparc] Pull request

2014-05-08 Thread Daniel Hellstrom

Hello Tom,

Please pull from u-boot-sparc.git, thanks! One of the fixes enables the 
SPARC platform to build again, sorry for the long delay and thanks for 
informing me about the problem.


The following changes since commit 09865465821fd35eabedcd9f102f1d576c626ad8:
Michal Simek (1):
serial: zynq: Fix typo in suffix function name

are available in the git repository at:

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

Daniel Hellstrom (2):
leon: use CONFIG_SYS_HZ to config timer prescaler
leon: implement missing get_tbclk()

arch/sparc/cpu/leon2/cpu_init.c | 22 ++
arch/sparc/cpu/leon3/cpu_init.c | 22 ++
2 files changed, 28 insertions(+), 16 deletions(-)


Best Regards,

--
Daniel Hellstrom
Software Section Head
Aeroflex Gaisler AB
Aeroflex Microelectronic Solutions – HiRel
Kungsgatan 12
SE-411 19 Gothenburg, Sweden
Phone: +46 31 7758657
dan...@gaisler.com
www.Aeroflex.com/Gaisler

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


Re: [U-Boot] Mainline u-boot on socfpga (SocKit) board

2014-05-08 Thread Wolfgang Denk
Dear Chin Liang See,

In message <1399544922.2064.19.ca...@clsee-virtualbox.altera.com> you wrote:
> 
> But nevertheless, it poses another challenge when come to license. The
> driver is currently licensed under BSD-3 clause. Wonder can we upstream
> BSD-3 clause code? Any advise would be appreciated.

It's your code, so why can't you relicense it under GPL?  Why was it
not licensed under GPL from the beginning when it'sbeen written for
U-Boot?

Technically, the "original BSD license, modified by removal of the
advertising clause" (sometimes referred to as the "3-clause BSD
license") is considered to be compatible with the GNU GPL.

Best regards,
Viele Grüße,

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
"Spock, did you see the looks on their faces?"
"Yes, Captain, a sort of vacant contentment."
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v1 0/3] ARM: omap: add support for GPMC and ELM controllers on OMAP4 and OMAP5 platforms

2014-05-08 Thread Gupta, Pekon
>From: Gupta, Pekon
>
>This patch series intends to:
>- Add support for GPMC and ELM controllers for OMAP4 and OMAP5 platform devices
>  by moving all generic arch specific code shared between
>  arch/AM33xx, arch/OMAP4 and arch/OMAP5 into arch/omap-common/
>- Separate out arch specific header for future scalability
>- Remove redundant code
>
>Pekon Gupta (3):
>  ARM: omap4: add platform specific info for GPMC and ELM controllers
>  ARM: omap5: add platform specific info for GPMC and ELM controllers
>  ARM: omap: merge GPMC initialization code for all platform
>
> arch/arm/cpu/armv7/am33xx/Makefile |   1 -
> arch/arm/cpu/armv7/omap-common/Makefile|   4 -
> .../{am33xx/mem.c => omap-common/mem-common.c} |  39 ++
> arch/arm/cpu/armv7/omap3/Makefile  |   1 -
> arch/arm/cpu/armv7/omap3/mem.c | 139 -
> arch/arm/include/asm/arch-omap4/cpu.h  |   5 +-
> arch/arm/include/asm/arch-omap4/hardware.h |  26 
> arch/arm/include/asm/arch-omap4/mem.h  |  62 +
> arch/arm/include/asm/arch-omap4/omap.h |   3 -
> arch/arm/include/asm/arch-omap5/cpu.h  |   5 +-
> arch/arm/include/asm/arch-omap5/hardware.h |  26 
> arch/arm/include/asm/arch-omap5/mem.h  |  62 +
> arch/arm/include/asm/arch-omap5/omap.h |   3 -
> 13 files changed, 219 insertions(+), 157 deletions(-)
> rename arch/arm/cpu/armv7/{am33xx/mem.c => omap-common/mem-common.c} (68%)
> delete mode 100644 arch/arm/cpu/armv7/omap3/mem.c
> create mode 100644 arch/arm/include/asm/arch-omap4/hardware.h
> create mode 100644 arch/arm/include/asm/arch-omap4/mem.h
> create mode 100644 arch/arm/include/asm/arch-omap5/hardware.h
> create mode 100644 arch/arm/include/asm/arch-omap5/mem.h
>
>--
>1.8.5.1.163.gd7aced9

Missed adding
Reported-by: Gregoire Gentil 


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


[U-Boot] [PATCH] mx6sabreauto: Add the mx6dual-lite variant

2014-05-08 Thread Fabio Estevam
Tested by booting a mainline kernel via TFTP.

Signed-off-by: Fabio Estevam 
---
 board/freescale/mx6qsabreauto/mx6dl.cfg | 130 
 boards.cfg  |   1 +
 include/configs/mx6qsabreauto.h |   4 +
 3 files changed, 135 insertions(+)
 create mode 100644 board/freescale/mx6qsabreauto/mx6dl.cfg

diff --git a/board/freescale/mx6qsabreauto/mx6dl.cfg 
b/board/freescale/mx6qsabreauto/mx6dl.cfg
new file mode 100644
index 000..89078e5
--- /dev/null
+++ b/board/freescale/mx6qsabreauto/mx6dl.cfg
@@ -0,0 +1,130 @@
+/*
+ * Copyright (C) 2013 Freescale Semiconductor, Inc.
+ * Jason Liu 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ *
+ * Refer doc/README.imximage for more details about how-to configure
+ * and create imximage boot image
+ *
+ * The syntax is taken as close as possible with the kwbimage
+ */
+/* image version */
+
+IMAGE_VERSION 2
+
+/*
+ * Boot Device : one of
+ * spi, sd (the board has no nand neither onenand)
+ */
+BOOT_FROM  sd
+
+/*
+ * Device Configuration Data (DCD)
+ *
+ * Each entry must have the format:
+ * Addr-type   AddressValue
+ *
+ * where:
+ * Addr-type register length (1,2 or 4 bytes)
+ * Address   absolute address of the register
+ * value value to be stored in the register
+ */
+DATA 4 0x020e0774 0x000C
+DATA 4 0x020e0754 0x
+DATA 4 0x020e04ac 0x0030
+DATA 4 0x020e04b0 0x0030
+DATA 4 0x020e0464 0x0030
+DATA 4 0x020e0490 0x0030
+DATA 4 0x020e074c 0x0030
+DATA 4 0x020e0494 0x0030
+DATA 4 0x020e04a0 0x
+DATA 4 0x020e04b4 0x0030
+DATA 4 0x020e04b8 0x0030
+DATA 4 0x020e076c 0x0030
+DATA 4 0x020e0750 0x0002
+DATA 4 0x020e04bc 0x0028
+DATA 4 0x020e04c0 0x0028
+DATA 4 0x020e04c4 0x0028
+DATA 4 0x020e04c8 0x0028
+DATA 4 0x020e04cc 0x0028
+DATA 4 0x020e04d0 0x0028
+DATA 4 0x020e04d4 0x0028
+DATA 4 0x020e04d8 0x0028
+DATA 4 0x020e0760 0x0002
+DATA 4 0x020e0764 0x0028
+DATA 4 0x020e0770 0x0028
+DATA 4 0x020e0778 0x0028
+DATA 4 0x020e077c 0x0028
+DATA 4 0x020e0780 0x0028
+DATA 4 0x020e0784 0x0028
+DATA 4 0x020e078c 0x0028
+DATA 4 0x020e0748 0x0028
+DATA 4 0x020e0470 0x0028
+DATA 4 0x020e0474 0x0028
+DATA 4 0x020e0478 0x0028
+DATA 4 0x020e047c 0x0028
+DATA 4 0x020e0480 0x0028
+DATA 4 0x020e0484 0x0028
+DATA 4 0x020e0488 0x0028
+DATA 4 0x020e048c 0x0028
+DATA 4 0x021b0800 0xa1390003
+DATA 4 0x021b080c 0x001F001F
+DATA 4 0x021b0810 0x001F001F
+DATA 4 0x021b480c 0x001F001F
+DATA 4 0x021b4810 0x001F001F
+DATA 4 0x021b083c 0x42190217
+DATA 4 0x021b0840 0x017B017B
+DATA 4 0x021b483c 0x4176017B
+DATA 4 0x021b4840 0x015F016C
+DATA 4 0x021b0848 0x4C4C4D4C
+DATA 4 0x021b4848 0x4A4D4C48
+DATA 4 0x021b0850 0x3F3F3F40
+DATA 4 0x021b4850 0x3538382E
+DATA 4 0x021b081c 0x
+DATA 4 0x021b0820 0x
+DATA 4 0x021b0824 0x
+DATA 4 0x021b0828 0x
+DATA 4 0x021b481c 0x
+DATA 4 0x021b4820 0x
+DATA 4 0x021b4824 0x
+DATA 4 0x021b4828 0x
+DATA 4 0x021b08b8 0x0800
+DATA 4 0x021b48b8 0x0800
+DATA 4 0x021b0004 0x00020025
+DATA 4 0x021b0008 0x00333030
+DATA 4 0x021b000c 0x676B5313
+DATA 4 0x021b0010 0xB66E8B63
+DATA 4 0x021b0014 0x01FF00DB
+DATA 4 0x021b0018 0x1740
+DATA 4 0x021b001c 0x8000
+DATA 4 0x021b002c 0x26d2
+DATA 4 0x021b0030 0x006B1023
+DATA 4 0x021b0040 0x0047
+DATA 4 0x021b 0x841A
+DATA 4 0x021b001c 0x04008032
+DATA 4 0x021b001c 0x8033
+DATA 4 0x021b001c 0x00048031
+DATA 4 0x021b001c 0x05208030
+DATA 4 0x021b001c 0x04008040
+DATA 4 0x021b0020 0x5800
+DATA 4 0x021b0818 0x0007
+DATA 4 0x021b4818 0x0007
+DATA 4 0x021b0004 0x00025565
+DATA 4 0x021b0404 0x00011006
+DATA 4 0x021b001c 0x
+
+/* set the default clock gate to save power */
+DATA 4 0x020c4068 0x00C03F3F
+DATA 4 0x020c406c 0x0030FC03
+DATA 4 0x020c4070 0x0FFFC000
+DATA 4 0x020c4074 0x3FF0
+DATA 4 0x020c4078 0xF300
+DATA 4 0x020c407c 0x0FC3
+DATA 4 0x020c4080 0x0FFF
+
+/* enable AXI cache for VDOA/VPU/IPU */
+DATA 4 0x020e0010 0xF0CF
+/* set IPU AXI-id0 Qos=0xf(bypass) AXI-id1 Qos=0x7 */
+DATA 4 0x020e0018 0x007F007F
+DATA 4 0x020e001c 0x007F007F
diff --git a/boards.cfg b/boards.cfg
index 89ed095..514970e 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -320,6 +320,7 @@ Active  arm armv7  mx6 boundary 
   nitrogen6x
 Active  arm armv7  mx6 congateccgtqmx6eval 
cgtqmx6qeval 
cgtqmx6eval:IMX_CONFIG=board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg,MX6Q
  Leo Sartre 

 Active  arm armv7  mx6 freescale   mx6qarm2
mx6qarm2 
mx6qarm2:IMX_CONFIG=board/freescale/mx6qarm2/imximage.cfg   
  Jason Liu 

 Active  a

[U-Boot] [PATCH v1 2/3] ARM: omap5: add platform specific info for GPMC and ELM controllers

2014-05-08 Thread Pekon Gupta
This patch moves platform specific information for GPMC and ELM controller
into separate header files, so that any derivative devices do not mess other
header files.

Platform specific information added into arch-xx/../hardware.h
 - CPU related platform specific details like base-address of GPMC and ELM

Platform specific information added into arch-xx/../mem.h
 - Generic configs for GPMC and ELM initialization.
 - Hardware parameters or constrains specific to GPMC and ELM IP like;
   number of max number of chip-selects available

Signed-off-by: Pekon Gupta 
---
 arch/arm/include/asm/arch-omap5/cpu.h  |  5 +--
 arch/arm/include/asm/arch-omap5/hardware.h | 26 +
 arch/arm/include/asm/arch-omap5/mem.h  | 62 ++
 arch/arm/include/asm/arch-omap5/omap.h |  3 --
 4 files changed, 90 insertions(+), 6 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-omap5/hardware.h
 create mode 100644 arch/arm/include/asm/arch-omap5/mem.h

diff --git a/arch/arm/include/asm/arch-omap5/cpu.h 
b/arch/arm/include/asm/arch-omap5/cpu.h
index 5f1d745..6109b92 100644
--- a/arch/arm/include/asm/arch-omap5/cpu.h
+++ b/arch/arm/include/asm/arch-omap5/cpu.h
@@ -14,6 +14,8 @@
 #include 
 #endif /* !(__KERNEL_STRICT_NAMES || __ASSEMBLY__) */
 
+#include 
+
 #ifndef __KERNEL_STRICT_NAMES
 #ifndef __ASSEMBLY__
 struct gptimer {
@@ -63,9 +65,6 @@ struct watchdog {
 #define TCLR_AR(0x1 << 1)
 #define TCLR_PRE   (0x1 << 5)
 
-/* GPMC BASE */
-#define GPMC_BASE  (OMAP54XX_GPMC_BASE)
-
 /* I2C base */
 #define I2C_BASE1  (OMAP54XX_L4_PER_BASE + 0x7)
 #define I2C_BASE2  (OMAP54XX_L4_PER_BASE + 0x72000)
diff --git a/arch/arm/include/asm/arch-omap5/hardware.h 
b/arch/arm/include/asm/arch-omap5/hardware.h
new file mode 100644
index 000..f7011b4
--- /dev/null
+++ b/arch/arm/include/asm/arch-omap5/hardware.h
@@ -0,0 +1,26 @@
+/*
+ * hardware.h
+ *
+ * hardware specific header
+ *
+ * Copyright (C) 2013, Texas Instruments, Incorporated - http://www.ti.com/
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __OMAP_HARDWARE_H
+#define __OMAP_HARDWARE_H
+
+#include 
+
+/*
+ * Common hardware definitions
+ */
+
+/* BCH Error Location Module */
+#define ELM_BASE   0x48078000
+
+/* GPMC Base address */
+#define GPMC_BASE  0x5000
+
+#endif
diff --git a/arch/arm/include/asm/arch-omap5/mem.h 
b/arch/arm/include/asm/arch-omap5/mem.h
new file mode 100644
index 000..d2e708b
--- /dev/null
+++ b/arch/arm/include/asm/arch-omap5/mem.h
@@ -0,0 +1,62 @@
+/*
+ * (C) Copyright 2006-2008
+ * Texas Instruments, 
+ *
+ * Author
+ * Mansoor Ahamed 
+ *
+ * Initial Code from:
+ * Richard Woodruff 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _MEM_H_
+#define _MEM_H_
+
+/*
+ * GPMC settings -
+ * Definitions is as per the following format
+ * #define _GPMC_CONFIG 
+ * Where:
+ * PART is the part name e.g. STNOR - Intel Strata Flash
+ * x is GPMC config registers from 1 to 6 (there will be 6 macros)
+ * Value is corresponding value
+ *
+ * For every valid PRCM configuration there should be only one definition of
+ * the same. if values are independent of the board, this definition will be
+ * present in this file if values are dependent on the board, then this should
+ * go into corresponding mem-boardName.h file
+ *
+ * Currently valid part Names are (PART):
+ * M_NAND - Micron NAND
+ * STNOR - STMicrolelctronics M29W128GL
+ */
+#define GPMC_SIZE_256M 0x0
+#define GPMC_SIZE_128M 0x8
+#define GPMC_SIZE_64M  0xC
+#define GPMC_SIZE_32M  0xE
+#define GPMC_SIZE_16M  0xF
+
+#define M_NAND_GPMC_CONFIG10x0800
+#define M_NAND_GPMC_CONFIG20x001e1e00
+#define M_NAND_GPMC_CONFIG30x001e1e00
+#define M_NAND_GPMC_CONFIG40x16051807
+#define M_NAND_GPMC_CONFIG50x00151e1e
+#define M_NAND_GPMC_CONFIG60x16000f80
+#define M_NAND_GPMC_CONFIG70x0008
+
+#define STNOR_GPMC_CONFIG1 0x1200
+#define STNOR_GPMC_CONFIG2 0x00101000
+#define STNOR_GPMC_CONFIG3 0x00030301
+#define STNOR_GPMC_CONFIG4 0x10041004
+#define STNOR_GPMC_CONFIG5 0x000C1010
+#define STNOR_GPMC_CONFIG6 0x08070280
+#define STNOR_GPMC_CONFIG7 0x0F48
+
+/* max number of GPMC Chip Selects */
+#define GPMC_MAX_CS8
+/* max number of GPMC regs */
+#define GPMC_MAX_REG   7
+
+#endif /* endif _MEM_H_ */
diff --git a/arch/arm/include/asm/arch-omap5/omap.h 
b/arch/arm/include/asm/arch-omap5/omap.h
index 19fdece..cf17e2d 100644
--- a/arch/arm/include/asm/arch-omap5/omap.h
+++ b/arch/arm/include/asm/arch-omap5/omap.h
@@ -59,9 +59,6 @@
 /* Watchdog Timer2 - MPU watchdog */
 #define WDT2_BASE  (OMAP54XX_L4_WKUP_BASE + 0x14000)
 
-/* GPMC */
-#define OMAP54XX_GPMC_BASE 0x5000
-
 /* QSPI */
 #define QSPI_BASE  0x4B30
 
-- 
1.8.5.1.163.gd7aced9

__

[U-Boot] [PATCH v1 3/3] ARM: omap: merge GPMC initialization code for all platform

2014-05-08 Thread Pekon Gupta
GPMC controller on TI's OMAP SoC is general purpose controller to interface
with different types of external devices like;
 - parallel NOR flash
 - parallel NAND flash
 - OneNand flash
 - SDR RAM
 - Ethernet Devices like LAN9220

Though GPMC configurations may be different for each platform depending on
clock-frequency and external device interfacing with controller. But
initialization sequence remains common across all platfoms.

Thus this patch merges gpmc_init() scattered in different arch-xx/mem.c
files into single omap-common/mem-common.c

However, actual platforms specific register config values are still sourced
from corresponding platform specific headers like;
 AM33xx: arch/arm/include/asm/arch-am33xx/mem.h
 OMAP3:  arch/arm/include/asm/arch-omap3/mem.h
 OMAP4:  arch/arm/include/asm/arch-omap4/mem.h
 OMAP4:  arch/arm/include/asm/arch-omap5/mem.h

Also, CONFIG_xx passed by board-profile decide config for which set of macros
need to be used for initialization
 CONFIG_NAND:initialize GPMC for NAND device
 CONFIG_NOR: initialize GPMC for NOR device
 CONFIG_ONENAND: initialize GPMC for ONENAND device

Signed-off-by: Pekon Gupta 
---
 arch/arm/cpu/armv7/am33xx/Makefile |   1 -
 arch/arm/cpu/armv7/omap-common/Makefile|   4 -
 .../{am33xx/mem.c => omap-common/mem-common.c} |  39 ++
 arch/arm/cpu/armv7/omap3/Makefile  |   1 -
 arch/arm/cpu/armv7/omap3/mem.c | 139 -
 5 files changed, 39 insertions(+), 145 deletions(-)
 rename arch/arm/cpu/armv7/{am33xx/mem.c => omap-common/mem-common.c} (68%)
 delete mode 100644 arch/arm/cpu/armv7/omap3/mem.c

diff --git a/arch/arm/cpu/armv7/am33xx/Makefile 
b/arch/arm/cpu/armv7/am33xx/Makefile
index 5566310..aae3f09 100644
--- a/arch/arm/cpu/armv7/am33xx/Makefile
+++ b/arch/arm/cpu/armv7/am33xx/Makefile
@@ -14,7 +14,6 @@ endif
 
 obj-$(CONFIG_TI816X)   += clock_ti816x.o
 obj-y  += sys_info.o
-obj-y  += mem.o
 obj-y  += ddr.o
 obj-y  += emif4.o
 obj-y  += board.o
diff --git a/arch/arm/cpu/armv7/omap-common/Makefile 
b/arch/arm/cpu/armv7/omap-common/Makefile
index 59f5352..5f5132f 100644
--- a/arch/arm/cpu/armv7/omap-common/Makefile
+++ b/arch/arm/cpu/armv7/omap-common/Makefile
@@ -27,8 +27,4 @@ obj-y += boot-common.o
 obj-y  += lowlevel_init.o
 endif
 
-ifndef CONFIG_SPL_BUILD
-ifneq ($(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX),)
 obj-y  += mem-common.o
-endif
-endif
diff --git a/arch/arm/cpu/armv7/am33xx/mem.c 
b/arch/arm/cpu/armv7/omap-common/mem-common.c
similarity index 68%
rename from arch/arm/cpu/armv7/am33xx/mem.c
rename to arch/arm/cpu/armv7/omap-common/mem-common.c
index 56c9e7d..944ef84 100644
--- a/arch/arm/cpu/armv7/am33xx/mem.c
+++ b/arch/arm/cpu/armv7/omap-common/mem-common.c
@@ -19,9 +19,36 @@
 #include 
 #include 
 #include 
+#include 
 
 struct gpmc *gpmc_cfg;
 
+#if defined(CONFIG_OMAP34XX)
+/
+ *  mem_ok() - test used to see if timings are correct
+ * for a part. Helps in guessing which part
+ * we are currently using.
+ ***/
+u32 mem_ok(u32 cs)
+{
+   u32 val1, val2, addr;
+   u32 pattern = 0x12345678;
+
+   addr = OMAP34XX_SDRC_CS0 + get_sdr_cs_offset(cs);
+
+   writel(0x0, addr + 0x400);  /* clear pos A */
+   writel(pattern, addr);  /* pattern to pos B */
+   writel(0x0, addr + 4);  /* remove pattern off the bus */
+   val1 = readl(addr + 0x400); /* get pos A value */
+   val2 = readl(addr); /* get val2 */
+   writel(0x0, addr + 0x400);  /* clear pos A */
+
+   if ((val1 != 0) || (val2 != pattern))   /* see if pos A val changed */
+   return 0;
+   else
+   return 1;
+}
+#endif
 
 void enable_gpmc_cs_config(const u32 *gpmc_config, struct gpmc_cs *cs, u32 
base,
u32 size)
@@ -74,6 +101,17 @@ void gpmc_init(void)
};
u32 size = GPMC_SIZE_256M;
u32 base = CONFIG_SYS_NAND_BASE;
+#elif defined(CONFIG_CMD_ONENAND)
+   const u32 gpmc_regs[GPMC_MAX_REG] = {   ONENAND_GPMC_CONFIG1,
+   ONENAND_GPMC_CONFIG2,
+   ONENAND_GPMC_CONFIG3,
+   ONENAND_GPMC_CONFIG4,
+   ONENAND_GPMC_CONFIG5,
+   ONENAND_GPMC_CONFIG6,
+   0
+   };
+   u32 base = PISMO1_ONEN_BASE;
+   u32 size = PISMO1_ONEN_SIZE;
 #else
const u32 gpmc_regs[GPMC_MAX_REG] = { 0, 0, 0, 0, 0, 0, 0 };
u32 size = 0;
@@ -83,6 +121,7 @@ void gpmc_init(void)
writel(0x0008, &gpmc_cfg->sysconfig);
writel(0x, &gpmc_cfg->irqstatus);
writel

[U-Boot] [PATCH v1 0/3] ARM: omap: add support for GPMC and ELM controllers on OMAP4 and OMAP5 platforms

2014-05-08 Thread Pekon Gupta
This patch series intends to:
- Add support for GPMC and ELM controllers for OMAP4 and OMAP5 platform devices
  by moving all generic arch specific code shared between
  arch/AM33xx, arch/OMAP4 and arch/OMAP5 into arch/omap-common/
- Separate out arch specific header for future scalability
- Remove redundant code

Pekon Gupta (3):
  ARM: omap4: add platform specific info for GPMC and ELM controllers
  ARM: omap5: add platform specific info for GPMC and ELM controllers
  ARM: omap: merge GPMC initialization code for all platform

 arch/arm/cpu/armv7/am33xx/Makefile |   1 -
 arch/arm/cpu/armv7/omap-common/Makefile|   4 -
 .../{am33xx/mem.c => omap-common/mem-common.c} |  39 ++
 arch/arm/cpu/armv7/omap3/Makefile  |   1 -
 arch/arm/cpu/armv7/omap3/mem.c | 139 -
 arch/arm/include/asm/arch-omap4/cpu.h  |   5 +-
 arch/arm/include/asm/arch-omap4/hardware.h |  26 
 arch/arm/include/asm/arch-omap4/mem.h  |  62 +
 arch/arm/include/asm/arch-omap4/omap.h |   3 -
 arch/arm/include/asm/arch-omap5/cpu.h  |   5 +-
 arch/arm/include/asm/arch-omap5/hardware.h |  26 
 arch/arm/include/asm/arch-omap5/mem.h  |  62 +
 arch/arm/include/asm/arch-omap5/omap.h |   3 -
 13 files changed, 219 insertions(+), 157 deletions(-)
 rename arch/arm/cpu/armv7/{am33xx/mem.c => omap-common/mem-common.c} (68%)
 delete mode 100644 arch/arm/cpu/armv7/omap3/mem.c
 create mode 100644 arch/arm/include/asm/arch-omap4/hardware.h
 create mode 100644 arch/arm/include/asm/arch-omap4/mem.h
 create mode 100644 arch/arm/include/asm/arch-omap5/hardware.h
 create mode 100644 arch/arm/include/asm/arch-omap5/mem.h

-- 
1.8.5.1.163.gd7aced9

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


[U-Boot] [PATCH v1 1/3] ARM: omap4: add platform specific info for GPMC and ELM controllers

2014-05-08 Thread Pekon Gupta
This patch moves platform specific information for GPMC and ELM controller
into separate header files, so that any derivative devices do not mess other
header files.

Platform specific information added into arch-xx/../hardware.h
 - CPU related platform specific details like base-address of GPMC and ELM

Platform specific information added into arch-xx/../mem.h
 - Generic configs for GPMC and ELM initialization.
 - Hardware parameters or constrains specific to GPMC and ELM IP like;
   number of max number of chip-selects available

Signed-off-by: Pekon Gupta 
---
 arch/arm/include/asm/arch-omap4/cpu.h  |  5 +--
 arch/arm/include/asm/arch-omap4/hardware.h | 26 +
 arch/arm/include/asm/arch-omap4/mem.h  | 62 ++
 arch/arm/include/asm/arch-omap4/omap.h |  3 --
 4 files changed, 90 insertions(+), 6 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-omap4/hardware.h
 create mode 100644 arch/arm/include/asm/arch-omap4/mem.h

diff --git a/arch/arm/include/asm/arch-omap4/cpu.h 
b/arch/arm/include/asm/arch-omap4/cpu.h
index c21fb54..f7595ae 100644
--- a/arch/arm/include/asm/arch-omap4/cpu.h
+++ b/arch/arm/include/asm/arch-omap4/cpu.h
@@ -12,6 +12,8 @@
 #include 
 #endif /* !(__KERNEL_STRICT_NAMES || __ASSEMBLY__) */
 
+#include 
+
 #ifndef __KERNEL_STRICT_NAMES
 #ifndef __ASSEMBLY__
 struct gptimer {
@@ -57,9 +59,6 @@ struct watchdog {
 #define TCLR_AR(0x1 << 1)
 #define TCLR_PRE   (0x1 << 5)
 
-/* GPMC BASE */
-#define GPMC_BASE  (OMAP44XX_GPMC_BASE)
-
 /* I2C base */
 #define I2C_BASE1  (OMAP44XX_L4_PER_BASE + 0x7)
 #define I2C_BASE2  (OMAP44XX_L4_PER_BASE + 0x72000)
diff --git a/arch/arm/include/asm/arch-omap4/hardware.h 
b/arch/arm/include/asm/arch-omap4/hardware.h
new file mode 100644
index 000..f7011b4
--- /dev/null
+++ b/arch/arm/include/asm/arch-omap4/hardware.h
@@ -0,0 +1,26 @@
+/*
+ * hardware.h
+ *
+ * hardware specific header
+ *
+ * Copyright (C) 2013, Texas Instruments, Incorporated - http://www.ti.com/
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __OMAP_HARDWARE_H
+#define __OMAP_HARDWARE_H
+
+#include 
+
+/*
+ * Common hardware definitions
+ */
+
+/* BCH Error Location Module */
+#define ELM_BASE   0x48078000
+
+/* GPMC Base address */
+#define GPMC_BASE  0x5000
+
+#endif
diff --git a/arch/arm/include/asm/arch-omap4/mem.h 
b/arch/arm/include/asm/arch-omap4/mem.h
new file mode 100644
index 000..d2e708b
--- /dev/null
+++ b/arch/arm/include/asm/arch-omap4/mem.h
@@ -0,0 +1,62 @@
+/*
+ * (C) Copyright 2006-2008
+ * Texas Instruments, 
+ *
+ * Author
+ * Mansoor Ahamed 
+ *
+ * Initial Code from:
+ * Richard Woodruff 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _MEM_H_
+#define _MEM_H_
+
+/*
+ * GPMC settings -
+ * Definitions is as per the following format
+ * #define _GPMC_CONFIG 
+ * Where:
+ * PART is the part name e.g. STNOR - Intel Strata Flash
+ * x is GPMC config registers from 1 to 6 (there will be 6 macros)
+ * Value is corresponding value
+ *
+ * For every valid PRCM configuration there should be only one definition of
+ * the same. if values are independent of the board, this definition will be
+ * present in this file if values are dependent on the board, then this should
+ * go into corresponding mem-boardName.h file
+ *
+ * Currently valid part Names are (PART):
+ * M_NAND - Micron NAND
+ * STNOR - STMicrolelctronics M29W128GL
+ */
+#define GPMC_SIZE_256M 0x0
+#define GPMC_SIZE_128M 0x8
+#define GPMC_SIZE_64M  0xC
+#define GPMC_SIZE_32M  0xE
+#define GPMC_SIZE_16M  0xF
+
+#define M_NAND_GPMC_CONFIG10x0800
+#define M_NAND_GPMC_CONFIG20x001e1e00
+#define M_NAND_GPMC_CONFIG30x001e1e00
+#define M_NAND_GPMC_CONFIG40x16051807
+#define M_NAND_GPMC_CONFIG50x00151e1e
+#define M_NAND_GPMC_CONFIG60x16000f80
+#define M_NAND_GPMC_CONFIG70x0008
+
+#define STNOR_GPMC_CONFIG1 0x1200
+#define STNOR_GPMC_CONFIG2 0x00101000
+#define STNOR_GPMC_CONFIG3 0x00030301
+#define STNOR_GPMC_CONFIG4 0x10041004
+#define STNOR_GPMC_CONFIG5 0x000C1010
+#define STNOR_GPMC_CONFIG6 0x08070280
+#define STNOR_GPMC_CONFIG7 0x0F48
+
+/* max number of GPMC Chip Selects */
+#define GPMC_MAX_CS8
+/* max number of GPMC regs */
+#define GPMC_MAX_REG   7
+
+#endif /* endif _MEM_H_ */
diff --git a/arch/arm/include/asm/arch-omap4/omap.h 
b/arch/arm/include/asm/arch-omap4/omap.h
index f66da0d..d43dc26 100644
--- a/arch/arm/include/asm/arch-omap4/omap.h
+++ b/arch/arm/include/asm/arch-omap4/omap.h
@@ -60,9 +60,6 @@
 /* Watchdog Timer2 - MPU watchdog */
 #define WDT2_BASE  (OMAP44XX_L4_WKUP_BASE + 0x14000)
 
-/* GPMC */
-#define OMAP44XX_GPMC_BASE 0x5000
-
 /*
  * Hardware Register Details
  */
-- 
1.8.5.1.163.gd7aced9


[U-Boot] [PATCH V2] ARM: tegra: use a CPU freq that all SKUs can support

2014-05-08 Thread Stephen Warren
From: Stephen Warren 

U-Boot on Tegra30 currently selects a main CPU frequency that cannot be
supported at all on some SKUs, and needs higher VDD_CPU/VDD_CORE values
on some others. This can result in unreliable operation of the main CPUs.

Resolve this by switching to a CPU frequency that can be supported by any
SKU. According to the following link, the maximum supported CPU frequency
of the slowest Tegra30 SKU is 600MHz:

repo http://nv-tegra.nvidia.com/gitweb/?p=linux-2.6.git;a=summary
branch l4t/l4t-r16-r2
path arch/arm/mach-tegra/tegra3_dvfs.c
table cpu_dvfs_table[]

According to that same table, the minimum VDD_CPU required to operate at
that frequency across all SKUs is 1.007V. Given the adjustment resolution
of the TPS65911 PMIC that's used on all Tegra30-based boards we support,
we'll end up using 1.0125V instead.

At that VDD_CPU, tegra3_get_core_floor_mv() in that same file dictates
that VDD_CORE must be at least 1.2V on all SKUs. According to
tegra_core_speedo_mv() (in tegra3_speedo.c in the same source tree),
that voltage is safe for all SKUs.

An alternative would be to port much of the code from tegra3_dvfs.c and
tegra3_speedo.c in the kernel tree mentioned above. That's more work
than I want to take on right now.

While all the currently supported boards use the same regulator chip for
VDD_CPU, different types of regulators are used for VDD_CORE. Hence, we
add some small conditional code to select how VDD_CORE is programmed. If
this becomes more complex in the future as new boards are added, or we
end up adding code to detect the SoC SKU and dynamically determine the
allowed frequency and required voltages, we should probably make this a
runtime call into a function provided by the board file and/or relevant
PMIC driver.

Cc: Alban Bedel 
Cc: Marcel Ziswiler 
Cc: Bard Liao 
Signed-off-by: Stephen Warren 
---
v2:
* Fix 7-vs-8-bit I2C address and register value shifting confusion
  pointed out by Lucas Stach.

Alban, I don't know which regulator is used for VDD_CORE on Tec-NG. If
could you find this out, I can adjust tec-ng.h too. Thanks.
---
 arch/arm/cpu/arm720t/tegra-common/cpu.c | 10 +-
 arch/arm/cpu/arm720t/tegra30/cpu.c  | 23 +--
 include/configs/beaver.h|  3 +++
 include/configs/cardhu.h|  3 +++
 4 files changed, 32 insertions(+), 7 deletions(-)

diff --git a/arch/arm/cpu/arm720t/tegra-common/cpu.c 
b/arch/arm/cpu/arm720t/tegra-common/cpu.c
index 168f525ec7c8..c6f3b029a16e 100644
--- a/arch/arm/cpu/arm720t/tegra-common/cpu.c
+++ b/arch/arm/cpu/arm720t/tegra-common/cpu.c
@@ -82,7 +82,7 @@ struct clk_pll_table 
tegra_pll_x_table[TEGRA_SOC_CNT][CLOCK_OSC_FREQ_COUNT] = {
{ .n = 600, .m = 13, .p = 0, .cpcon = 12 }, /* OSC: 26.0 MHz */
},
/*
-* T30: 1.4 GHz
+* T30: 600 MHz
 *
 * Register   Field  Bits   Width
 * --
@@ -92,10 +92,10 @@ struct clk_pll_table 
tegra_pll_x_table[TEGRA_SOC_CNT][CLOCK_OSC_FREQ_COUNT] = {
 * PLLX_MISC  cpcon  11: 84
 */
{
-   { .n = 862, .m =  8, .p = 0, .cpcon = 8 }, /* OSC: 13.0 MHz */
-   { .n = 583, .m =  8, .p = 0, .cpcon = 4 }, /* OSC: 19.2 MHz */
-   { .n = 700, .m =  6, .p = 0, .cpcon = 8 }, /* OSC: 12.0 MHz */
-   { .n = 700, .m = 13, .p = 0, .cpcon = 8 }, /* OSC: 26.0 MHz */
+   { .n = 600, .m = 13, .p = 0, .cpcon = 8 }, /* OSC: 13.0 MHz */
+   { .n = 500, .m = 16, .p = 0, .cpcon = 8 }, /* OSC: 19.2 MHz */
+   { .n = 600, .m = 12, .p = 0, .cpcon = 8 }, /* OSC: 12.0 MHz */
+   { .n = 600, .m = 26, .p = 0, .cpcon = 8 }, /* OSC: 26.0 MHz */
},
/*
 * T114: 700 MHz
diff --git a/arch/arm/cpu/arm720t/tegra30/cpu.c 
b/arch/arm/cpu/arm720t/tegra30/cpu.c
index 85a945bc7918..9003902e3ff7 100644
--- a/arch/arm/cpu/arm720t/tegra30/cpu.c
+++ b/arch/arm/cpu/arm720t/tegra30/cpu.c
@@ -41,10 +41,18 @@ void tegra_i2c_ll_write_data(uint data, uint config)
writel(config, ®->cnfg);
 }
 
+#define TPS62366A_I2C_ADDR 0xC0
+#define TPS62366A_SET1_REG 0x01
+#define TPS62366A_SET1_DATA(0x4600 | TPS62366A_SET1_REG)
+
+#define TPS62361B_I2C_ADDR 0xC0
+#define TPS62361B_SET3_REG 0x03
+#define TPS62361B_SET3_DATA(0x4600 | TPS62361B_SET3_REG)
+
 #define TPS65911_I2C_ADDR  0x5A
 #define TPS65911_VDDCTRL_OP_REG0x28
 #define TPS65911_VDDCTRL_SR_REG0x27
-#define TPS65911_VDDCTRL_OP_DATA   (0x2300 | TPS65911_VDDCTRL_OP_REG)
+#define TPS65911_VDDCTRL_OP_DATA   (0x2400 | TPS65911_VDDCTRL_OP_REG)
 #define TPS65911_VDDCTRL_SR_DATA   (0x0100 | TPS65911_VDDCTRL_SR_REG)
 #define I2C_SEND_2_BYTES   0x0A02
 
@@ -58,9 +66,20 @@ static void enable_cpu_power_rail(void)
reg |= CPUPWRREQ_OE;
writel(reg, &pmc->pmc_cntrl);
 
+   /* Set V

[U-Boot] [PATCH] ARM: zynq: Enable generic board for Xilinx Zynq

2014-05-08 Thread Michal Simek
Enable CONFIG_SYS_GENERIC_BOARD for all Zynq boards.

Signed-off-by: Michal Simek 
---

 include/configs/zynq-common.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/zynq-common.h b/include/configs/zynq-common.h
index 8e0f93599fc4..153f3fe73d70 100644
--- a/include/configs/zynq-common.h
+++ b/include/configs/zynq-common.h
@@ -334,4 +334,6 @@

 #define CONFIG_SYS_UBOOT_START CONFIG_SYS_TEXT_BASE

+#define CONFIG_SYS_GENERIC_BOARD
+
 #endif /* __CONFIG_ZYNQ_COMMON_H */
--
1.8.2.3



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


Re: [U-Boot] [PATCH] zynq: treat ps7_init.c/h as external files to ignore them

2014-05-08 Thread Michal Simek
On 05/08/2014 02:30 PM, Masahiro Yamada wrote:
> ps7_init.c and ps7_init.h are supposed to be exported by hw project
> and copied to board/xilinx/zynq/ directory.
> 
> We want them to be ignored by git.
> So what we should do is to always treat them as external files
> rather than replacing ps7_init.c
> 
> This commit does:
> 
>  - Move a weak function ps7_init() to arch/arm/cpu/armv7/zynq/spl.c
>and delete board/xilinx/zynq/ps7_init.c
> 
>  - Compile board/xilinx/zynq/ps7_init.c only when it exists
> 
>  - Add .gitignore to ignore ps7_init.c/h
> 
> Signed-off-by: Masahiro Yamada 
> Cc: Michal Simek 
> ---
>  arch/arm/cpu/armv7/zynq/spl.c |  8 
>  board/xilinx/zynq/.gitignore  |  1 +
>  board/xilinx/zynq/Makefile|  5 -
>  board/xilinx/zynq/ps7_init.c  | 12 
>  4 files changed, 13 insertions(+), 13 deletions(-)
>  create mode 100644 board/xilinx/zynq/.gitignore
>  delete mode 100644 board/xilinx/zynq/ps7_init.c
> 

Signed-off-by: Michal Simek 

Masahiro: I have just tried to run this on the top of my zynq branch
with fpga changes I have sent and I can't see any problem in MMC boot mode.

As we discussed earlier - I am doing these changes in zynq-common
not to deal with dts files now.

diff --git a/include/configs/zynq-common.h b/include/configs/zynq-common.h
index 8e0f93599fc4..fb08a978019a 100644
--- a/include/configs/zynq-common.h
+++ b/include/configs/zynq-common.h
@@ -226,15 +226,6 @@
 #define CONFIG_FIT
 #define CONFIG_FIT_VERBOSE 1 /* enable fit_format_{error,warning}() */

-/* FDT support */
-#define CONFIG_OF_CONTROL
-#define CONFIG_OF_SEPARATE
-#define CONFIG_DISPLAY_BOARDINFO_LATE
-
-/* RSA support */
-#define CONFIG_FIT_SIGNATURE
-#define CONFIG_RSA
-

And I get this (I am sending generic board enabling for Zynq in a minute).

U-Boot SPL 2014.04-00236-gb861b285b4e9-dirty (May 08 2014 - 15:08:00)
mmc boot
reading system.dtb
spl_load_image_fat_os: error reading image system.dtb, err - -1
reading u-boot.img
reading u-boot.img


U-Boot 2014.04-00236-gb861b285b4e9-dirty (May 08 2014 - 15:08:00)

I2C:   ready
DRAM:  Memory: ECC disabled
1 GiB
MMC:   zynq_sdhci: 0
Using default environment

In:serial
Out:   serial
Err:   serial
Net:   Gem.e000b000
Warning: failed to set MAC address

Hit any key to stop autoboot:  0
zynq-uboot>


Thanks,
Michal

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




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


Re: [U-Boot] [PATCH 1/4] bootm: allow to disable legacy image format

2014-05-08 Thread mike

Hi Heiko,

Did you see my last email? The one that bounced with a mime header and 
where I attached a patch file.


I just wonder if its not better to switch the define to be

if (CONFIG_SIGNATURE_VERIFICATION_WITH_LEGACY_SIDE_DOOR). It can become 
mutually exclusive with the existing signature verification define.


That way the legacy stuff is removed automatically upon requesting 
verification unless defined otherwise. When you fail to boot an unsigned 
legacy kernel then its kind of obvious that you have to solve something 
but if you implement verified boot and forget this new variable then you 
leave a security hole.


In my last email I also discussed my confusion regard the 'required' 
variable. Similar argument to the above plus some other thoughts.


Thanks,

Mike.

On 05/08/2014 01:05 PM, Heiko Schocher wrote:

Disabling legacy image format is useful when using
signed FIT images with required signature check.
Use CONFIG_DISABLE_IMAGE_FORMAT_LEGACY in the board
config file.

Signed-off-by: Heiko Schocher 
Cc: Simon Glass 
Cc: Lars Steubesand 
Cc: Mike Pearce 
Cc: Wolfgang Denk 
---
  README   |  5 +
  common/cmd_bootm.c   | 14 ++
  common/cmd_disk.c|  4 
  common/cmd_fdc.c |  4 
  common/cmd_fpga.c|  2 ++
  common/cmd_nand.c|  4 
  common/cmd_source.c  |  4 
  common/cmd_ximg.c|  7 ++-
  common/image-fdt.c   | 10 --
  common/image.c   | 23 ---
  doc/uImage.FIT/signature.txt |  3 +++
  include/image.h  |  2 ++
  12 files changed, 72 insertions(+), 10 deletions(-)

diff --git a/README b/README
index b973344..b1f0ea3 100644
--- a/README
+++ b/README
@@ -3152,6 +3152,11 @@ FIT uImage format:
using a hash signed and verified using RSA. See
doc/uImage.FIT/signature.txt for more details.
  
+		CONFIG_DISABLE_IMAGE_FORMAT_LEGACY

+   WARNING: When relying on signed FIT images with required
+   signature check the legacy image format should be disabled by
+   using this define.
+
  - Standalone program support:
CONFIG_STANDALONE_LOAD_ADDR
  
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c

index c243a5b..69b86ee 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -233,6 +233,7 @@ static int bootm_find_os(cmd_tbl_t *cmdtp, int flag, int 
argc,
  
  	/* get image parameters */

switch (genimg_get_format(os_hdr)) {
+#if !defined(CONFIG_DISABLE_IMAGE_FORMAT_LEGACY)
case IMAGE_FORMAT_LEGACY:
images.os.type = image_get_type(os_hdr);
images.os.comp = image_get_comp(os_hdr);
@@ -241,6 +242,7 @@ static int bootm_find_os(cmd_tbl_t *cmdtp, int flag, int 
argc,
images.os.end = image_get_image_end(os_hdr);
images.os.load = image_get_load(os_hdr);
break;
+#endif
  #if defined(CONFIG_FIT)
case IMAGE_FORMAT_FIT:
if (fit_image_get_type(images.fit_hdr_os,
@@ -838,6 +840,7 @@ int bootm_maybe_autostart(cmd_tbl_t *cmdtp, const char *cmd)
return 0;
  }
  
+#if !defined(CONFIG_DISABLE_IMAGE_FORMAT_LEGACY)

  /**
   * image_get_kernel - verify legacy format kernel image
   * @img_addr: in RAM address of the legacy format image to be verified
@@ -888,6 +891,7 @@ static image_header_t *image_get_kernel(ulong img_addr, int 
verify)
}
return hdr;
  }
+#endif
  
  /**

   * boot_get_kernel - find kernel image
@@ -905,7 +909,9 @@ static const void *boot_get_kernel(cmd_tbl_t *cmdtp, int 
flag, int argc,
char * const argv[], bootm_headers_t *images, ulong *os_data,
ulong *os_len)
  {
+#if !defined(CONFIG_DISABLE_IMAGE_FORMAT_LEGACY)
image_header_t  *hdr;
+#endif
ulong   img_addr;
const void *buf;
  #if defined(CONFIG_FIT)
@@ -943,6 +949,7 @@ static const void *boot_get_kernel(cmd_tbl_t *cmdtp, int 
flag, int argc,
*os_data = *os_len = 0;
buf = map_sysmem(img_addr, 0);
switch (genimg_get_format(buf)) {
+#if !defined(CONFIG_DISABLE_IMAGE_FORMAT_LEGACY)
case IMAGE_FORMAT_LEGACY:
printf("## Booting kernel from Legacy Image at %08lx ...\n",
img_addr);
@@ -985,6 +992,7 @@ static const void *boot_get_kernel(cmd_tbl_t *cmdtp, int 
flag, int argc,
images->legacy_hdr_valid = 1;
bootstage_mark(BOOTSTAGE_ID_DECOMP_IMAGE);
break;
+#endif
  #if defined(CONFIG_FIT)
case IMAGE_FORMAT_FIT:
os_noffset = fit_image_load(images, FIT_KERNEL_PROP,
@@ -1114,6 +1122,7 @@ static int image_info(ulong addr)
printf("\n## Checking Image at %08lx ...\n", addr);
  
  	switch (genimg_get_format(hdr)) {

+#if !defined(CONFIG_DISABLE_IMAGE_FORMAT_LEGACY)
case IMAGE_FORMAT_LEGACY:
puts("   Legacy image 

Re: [U-Boot] [PATCH v3] dfu: Introduction of the "dfu_hash_algo" env variable for checksum method setting

2014-05-08 Thread Marek Vasut
On Thursday, May 08, 2014 at 02:27:47 PM, Lukasz Majewski wrote:
> Up till now the CRC32 of received data was calculated unconditionally.
> The standard crc32 implementation causes long delay when large images
> were uploaded.
> 
> The "dfu_hash_algo" environment variable gives the opportunity to
> enable on demand (when e.g. debugging) the hash (crc32) calculation.
> It can be done without need to recompile the u-boot binary and reuses
> the generic hash framework.
> 
> By default the crc32 is NOT calculated anymore.
> 
> Tests results:
> 400 MiB ums.img file
> With  crc32 calculation: 65 sec [avg 6.29 MB/s]
> Without   crc32 calculation: 25 sec [avg 16.17 MB/s]
> 
> Signed-off-by: Lukasz Majewski 
> Cc: Marek Vasut 

Reviewed-by: Marek Vasut 

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


Re: [U-Boot] Pull request: u-boot-dfu

2014-05-08 Thread Marek Vasut
On Thursday, May 08, 2014 at 10:56:37 AM, Lukasz Majewski wrote:
> Dear Marek,
> 
> Please pull following code. In the same occasion I would like to
> apologize for the fuzz with sending the last PR.
> 
> This one is ready to go and (hopefully) clans up all the code floating
> around various USB gadgets and DFU.
> 
> The following changes since commit
> 340ed422d2a58c4858ba8e110c233e8ae92c04e0:
> 
>   usb: ums: remove ci_udc special case (2014-05-07 23:36:58 +0200)
> 
> are available in the git repository at:
> 
>   ssh://gu-...@git.denx.de/u-boot-dfu master
> 
> for you to fetch changes up to fc25fa27e5f439705e9ca42182014e2d75d9f0ae:
> 
>   dfu, nand: add medium specific polltimeout function (2014-05-08
>   10:38:30 +0200)

Pulled, thanks.

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


Re: [U-Boot] [PATCH] zynq: ignore ps7_init.h

2014-05-08 Thread Masahiro Yamada
Hi Michal,


> > obj-y   := board.o
> > obj-$(CONFIG_SPL_BUILD) += $(if $(wildcard 
> > $(srctree)/$(src)/ps7_init.c),ps7_init.o)
> 
> If this is acceptable by others I am quite happy to use it
> because it seems to me like a good way how to handle it.
> 
> In future when everything is ready I expect that these ps7_init.c/h
> files will go away and information will be read directly from DTS
> but we are not there yet.
> 
> Anyway: Can you please prepare that patches? 

Sure.
Please check out
http://patchwork.ozlabs.org/patch/347023/


Best Regards
Masahiro Yamada

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


[U-Boot] [PATCH] zynq: treat ps7_init.c/h as external files to ignore them

2014-05-08 Thread Masahiro Yamada
ps7_init.c and ps7_init.h are supposed to be exported by hw project
and copied to board/xilinx/zynq/ directory.

We want them to be ignored by git.
So what we should do is to always treat them as external files
rather than replacing ps7_init.c

This commit does:

 - Move a weak function ps7_init() to arch/arm/cpu/armv7/zynq/spl.c
   and delete board/xilinx/zynq/ps7_init.c

 - Compile board/xilinx/zynq/ps7_init.c only when it exists

 - Add .gitignore to ignore ps7_init.c/h

Signed-off-by: Masahiro Yamada 
Cc: Michal Simek 
---
 arch/arm/cpu/armv7/zynq/spl.c |  8 
 board/xilinx/zynq/.gitignore  |  1 +
 board/xilinx/zynq/Makefile|  5 -
 board/xilinx/zynq/ps7_init.c  | 12 
 4 files changed, 13 insertions(+), 13 deletions(-)
 create mode 100644 board/xilinx/zynq/.gitignore
 delete mode 100644 board/xilinx/zynq/ps7_init.c

diff --git a/arch/arm/cpu/armv7/zynq/spl.c b/arch/arm/cpu/armv7/zynq/spl.c
index fcad762..e97695e 100644
--- a/arch/arm/cpu/armv7/zynq/spl.c
+++ b/arch/arm/cpu/armv7/zynq/spl.c
@@ -67,3 +67,11 @@ int spl_start_uboot(void)
return 0;
 }
 #endif
+
+__weak void ps7_init(void)
+{
+   /*
+* This function is replaced by the one in
+* board/xilinx/zynq/ps7_init.c, if it exists.
+*/
+}
diff --git a/board/xilinx/zynq/.gitignore b/board/xilinx/zynq/.gitignore
new file mode 100644
index 000..68b8edd
--- /dev/null
+++ b/board/xilinx/zynq/.gitignore
@@ -0,0 +1 @@
+ps7_init.[ch]
diff --git a/board/xilinx/zynq/Makefile b/board/xilinx/zynq/Makefile
index 3f19a1c..f91214c 100644
--- a/board/xilinx/zynq/Makefile
+++ b/board/xilinx/zynq/Makefile
@@ -6,4 +6,7 @@
 #
 
 obj-y  := board.o
-obj-$(CONFIG_SPL_BUILD)+= ps7_init.o
+
+# Please copy ps7_init.c/h from hw project
+obj-$(CONFIG_SPL_BUILD) += \
+   $(if $(wildcard $(srctree)/$(src)/ps7_init.c),ps7_init.o)
diff --git a/board/xilinx/zynq/ps7_init.c b/board/xilinx/zynq/ps7_init.c
deleted file mode 100644
index c47da09..000
--- a/board/xilinx/zynq/ps7_init.c
+++ /dev/null
@@ -1,12 +0,0 @@
-/*
- * (C) Copyright 2014 Xilinx, Inc. Michal Simek
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-#include 
-#include 
-
-__weak void ps7_init(void)
-{
-   puts("Please copy ps7_init.c/h from hw project\n");
-}
-- 
1.8.3.2

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


[U-Boot] [PATCH v3] dfu: Introduction of the "dfu_hash_algo" env variable for checksum method setting

2014-05-08 Thread Lukasz Majewski
Up till now the CRC32 of received data was calculated unconditionally.
The standard crc32 implementation causes long delay when large images
were uploaded.

The "dfu_hash_algo" environment variable gives the opportunity to
enable on demand (when e.g. debugging) the hash (crc32) calculation.
It can be done without need to recompile the u-boot binary and reuses
the generic hash framework.

By default the crc32 is NOT calculated anymore.

Tests results:
400 MiB ums.img file
Withcrc32 calculation: 65 sec [avg 6.29 MB/s]
Without crc32 calculation: 25 sec [avg 16.17 MB/s]

Signed-off-by: Lukasz Majewski 
Cc: Marek Vasut 
---
Changes for v2:
- Utilization of hash_block generic function to calculate CRC32 checksum
Changes for v3:
- Remove dependency on altering the lib/hash.c generic implementation
- Use of hash_update() function to calculate crc32 in the same way as
  it was done with crc32
---
 drivers/dfu/dfu.c |   47 ++-
 1 file changed, 42 insertions(+), 5 deletions(-)

diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 51b1026..c06f4cc 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -20,6 +21,7 @@ static bool dfu_reset_request;
 static LIST_HEAD(dfu_list);
 static int dfu_alt_num;
 static int alt_num_cnt;
+static struct hash_algo *dfu_hash_algo;
 
 bool dfu_reset(void)
 {
@@ -99,6 +101,24 @@ unsigned char *dfu_get_buf(void)
return dfu_buf;
 }
 
+static char *dfu_get_hash_algo(void)
+{
+   char *s;
+
+   s = getenv("dfu_hash_algo");
+   if (!s)
+   return NULL;
+
+   if (!strcmp(s, "crc32")) {
+   debug("%s: DFU hash method: %s\n", __func__, s);
+   return s;
+   }
+
+   error("DFU hash method: %s not supported!\n", s);
+
+   return NULL;
+}
+
 static int dfu_write_buffer_drain(struct dfu_entity *dfu)
 {
long w_size;
@@ -109,8 +129,9 @@ static int dfu_write_buffer_drain(struct dfu_entity *dfu)
if (w_size == 0)
return 0;
 
-   /* update CRC32 */
-   dfu->crc = crc32(dfu->crc, dfu->i_buf_start, w_size);
+   if (dfu_hash_algo)
+   dfu_hash_algo->hash_update(dfu_hash_algo, &dfu->crc,
+  dfu->i_buf_start, w_size, 0);
 
ret = dfu->write_medium(dfu, dfu->offset, dfu->i_buf_start, &w_size);
if (ret)
@@ -134,7 +155,9 @@ int dfu_flush(struct dfu_entity *dfu, void *buf, int size, 
int blk_seq_num)
if (dfu->flush_medium)
ret = dfu->flush_medium(dfu);
 
-   printf("\nDFU complete CRC32: 0x%08x\n", dfu->crc);
+   if (dfu_hash_algo)
+   printf("\nDFU complete %s: 0x%08x\n", dfu_hash_algo->name,
+  dfu->crc);
 
/* clear everything */
dfu_free_buf();
@@ -234,7 +257,11 @@ static int dfu_read_buffer_fill(struct dfu_entity *dfu, 
void *buf, int size)
/* consume */
if (chunk > 0) {
memcpy(buf, dfu->i_buf, chunk);
-   dfu->crc = crc32(dfu->crc, buf, chunk);
+   if (dfu_hash_algo)
+   dfu_hash_algo->hash_update(dfu_hash_algo,
+  &dfu->crc, buf,
+  chunk, 0);
+
dfu->i_buf += chunk;
dfu->b_left -= chunk;
dfu->r_left -= chunk;
@@ -318,7 +345,9 @@ int dfu_read(struct dfu_entity *dfu, void *buf, int size, 
int blk_seq_num)
}
 
if (ret < size) {
-   debug("%s: %s CRC32: 0x%x\n", __func__, dfu->name, dfu->crc);
+   if (dfu_hash_algo)
+   debug("%s: %s %s: 0x%x\n", __func__, dfu->name,
+ dfu_hash_algo->name, dfu->crc);
puts("\nUPLOAD ... done\nCtrl+C to exit ...\n");
 
dfu_free_buf();
@@ -393,6 +422,14 @@ int dfu_config_entities(char *env, char *interface, int 
num)
dfu_alt_num = dfu_find_alt_num(env);
debug("%s: dfu_alt_num=%d\n", __func__, dfu_alt_num);
 
+   dfu_hash_algo = NULL;
+   s = dfu_get_hash_algo();
+   if (s) {
+   ret = hash_lookup_algo(s, &dfu_hash_algo);
+   if (ret)
+   error("Hash algorithm %s not supported\n", s);
+   }
+
dfu = calloc(sizeof(*dfu), dfu_alt_num);
if (!dfu)
return -1;
-- 
1.7.10.4

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


Re: [U-Boot] [PATCH] zynq: ignore ps7_init.h

2014-05-08 Thread Michal Simek
On 05/08/2014 11:21 AM, Masahiro Yamada wrote:
> Hi Michal,
> 
>>
>> Here is just one question if we should also ignore ps7_init.c too.
>> It means move current ps7_init weak function to spl.c in mach-zynq
>> and just compile ps7_init.c in board file if it is available there.
>>
>> Is there any nice hook in Kbuild to compile file if it is available?
>>
>> Something like
>> [ -f ps7_init.c ] && compile it
> 
> Nice suggestion!
> 
> 
>> Then we can just move weak function
>> and ignore ps7_init.c/h files in board file.
>>
> 
> This might not be beautiful very much, but
> we can write board/xilinx/zynq/Makefile like this:
> 
> obj-y := board.o
> obj-$(CONFIG_SPL_BUILD)   += $(if $(wildcard 
> $(srctree)/$(src)/ps7_init.c),ps7_init.o)

If this is acceptable by others I am quite happy to use it
because it seems to me like a good way how to handle it.

In future when everything is ready I expect that these ps7_init.c/h
files will go away and information will be read directly from DTS
but we are not there yet.

Anyway: Can you please prepare that patches? I am quite happy to test them
and adding it to my zynq queue and send it to Albert.

Or do you want me to prepare them?

Thanks,
Michal


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




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


[U-Boot] Building under Cygwin - "-ansi" flag?

2014-05-08 Thread Vasili Galka
Hi,

I'm building u-boot (am335x_evm config) using arm-none-eabi toolchain
under Cygwin. When trying to build unmodified v2014.04 tag I get some
errors. However, if I remove the "-ansi" flag from the Makefile,
everything builds fine:

-ifeq ($(HOSTOS),cygwin)
-HOSTCFLAGS+= -ansi
-endif

I tried tracking down where those lines came from and why building
under Cygwin requires separate treatment. I found our this originates
from the following commit (dated Jan 2008):

  SHA-1: 883e3925d99a8dd69c5b0201cba5b1887f88f95c

  * Fix build problems under Cygwin

  This patch allows u-boot to build without error in a cygwin
  environment.  Cygwin does not define __u64 in it's
  include/asm/types.h file.  The -idirafter flag in the u-boot
  build causes the inclusion of the cygwin types.h file as opposed
  to u-bot/include/asm/types.h file which does define __u64.
  Subsequently, sha1.c compile fails due to unknown symbol.

  Signed-off-by: Brian Miller 

This comment does not really explain why "-ansi" flag is required.
Personally, I don't see any reason for it.

Maybe it should be removed at all?

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


[U-Boot] [PATCH][v2] drivers/usb : Define usb control register mask for w1c bits

2014-05-08 Thread Nikhil Badola
Define and use CONTROL_REGISTER_W1C_MASK to make sure that
w1c bits of usb control register do not get reset while
writing any other bit

Signed-off-by: Nikhil Badola 
Signed-off-by: Ramneek Mehresh 
---
Changes for v2:
- Using clrsetbits_be32() instead of new API

 drivers/usb/host/ehci-fsl.c | 15 ++-
 include/usb/ehci-fsl.h  |  2 ++
 2 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index 6cb4d98..45062e6 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -104,15 +104,20 @@ int ehci_hcd_init(int index, enum usb_init_type init,
 
if (!strncmp(phy_type, "utmi", 4)) {
 #if defined(CONFIG_SYS_FSL_USB_INTERNAL_UTMI_PHY)
-   setbits_be32(&ehci->control, PHY_CLK_SEL_UTMI);
-   setbits_be32(&ehci->control, UTMI_PHY_EN);
+   clrsetbits_be32(&ehci->control, CONTROL_REGISTER_W1C_MASK,
+   PHY_CLK_SEL_UTMI);
+   clrsetbits_be32(&ehci->control, CONTROL_REGISTER_W1C_MASK,
+   UTMI_PHY_EN);
udelay(1000); /* delay required for PHY Clk to appear */
 #endif
out_le32(&(*hcor)->or_portsc[0], PORT_PTS_UTMI);
-   setbits_be32(&ehci->control, USB_EN);
+   clrsetbits_be32(&ehci->control, CONTROL_REGISTER_W1C_MASK,
+   USB_EN);
} else {
-   setbits_be32(&ehci->control, PHY_CLK_SEL_ULPI);
-   clrsetbits_be32(&ehci->control, UTMI_PHY_EN, USB_EN);
+   clrsetbits_be32(&ehci->control, CONTROL_REGISTER_W1C_MASK,
+   PHY_CLK_SEL_ULPI);
+   clrsetbits_be32(&ehci->control, UTMI_PHY_EN |
+   CONTROL_REGISTER_W1C_MASK, USB_EN);
udelay(1000); /* delay required for PHY Clk to appear */
if (!usb_phy_clk_valid(ehci))
return -EINVAL;
diff --git a/include/usb/ehci-fsl.h b/include/usb/ehci-fsl.h
index c9ee1d5..dd77ad6 100644
--- a/include/usb/ehci-fsl.h
+++ b/include/usb/ehci-fsl.h
@@ -11,6 +11,8 @@
 
 #include 
 
+#define CONTROL_REGISTER_W1C_MASK   0x0002  /* W1C: PHY_CLK_VALID */
+
 /* Global offsets */
 #define FSL_SKIP_PCI   0x100
 
-- 
1.7.11.7

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


[U-Boot] [PATCH 1/4] bootm: allow to disable legacy image format

2014-05-08 Thread Heiko Schocher
Disabling legacy image format is useful when using
signed FIT images with required signature check.
Use CONFIG_DISABLE_IMAGE_FORMAT_LEGACY in the board
config file.

Signed-off-by: Heiko Schocher 
Cc: Simon Glass 
Cc: Lars Steubesand 
Cc: Mike Pearce 
Cc: Wolfgang Denk 
---
 README   |  5 +
 common/cmd_bootm.c   | 14 ++
 common/cmd_disk.c|  4 
 common/cmd_fdc.c |  4 
 common/cmd_fpga.c|  2 ++
 common/cmd_nand.c|  4 
 common/cmd_source.c  |  4 
 common/cmd_ximg.c|  7 ++-
 common/image-fdt.c   | 10 --
 common/image.c   | 23 ---
 doc/uImage.FIT/signature.txt |  3 +++
 include/image.h  |  2 ++
 12 files changed, 72 insertions(+), 10 deletions(-)

diff --git a/README b/README
index b973344..b1f0ea3 100644
--- a/README
+++ b/README
@@ -3152,6 +3152,11 @@ FIT uImage format:
using a hash signed and verified using RSA. See
doc/uImage.FIT/signature.txt for more details.
 
+   CONFIG_DISABLE_IMAGE_FORMAT_LEGACY
+   WARNING: When relying on signed FIT images with required
+   signature check the legacy image format should be disabled by
+   using this define.
+
 - Standalone program support:
CONFIG_STANDALONE_LOAD_ADDR
 
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index c243a5b..69b86ee 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -233,6 +233,7 @@ static int bootm_find_os(cmd_tbl_t *cmdtp, int flag, int 
argc,
 
/* get image parameters */
switch (genimg_get_format(os_hdr)) {
+#if !defined(CONFIG_DISABLE_IMAGE_FORMAT_LEGACY)
case IMAGE_FORMAT_LEGACY:
images.os.type = image_get_type(os_hdr);
images.os.comp = image_get_comp(os_hdr);
@@ -241,6 +242,7 @@ static int bootm_find_os(cmd_tbl_t *cmdtp, int flag, int 
argc,
images.os.end = image_get_image_end(os_hdr);
images.os.load = image_get_load(os_hdr);
break;
+#endif
 #if defined(CONFIG_FIT)
case IMAGE_FORMAT_FIT:
if (fit_image_get_type(images.fit_hdr_os,
@@ -838,6 +840,7 @@ int bootm_maybe_autostart(cmd_tbl_t *cmdtp, const char *cmd)
return 0;
 }
 
+#if !defined(CONFIG_DISABLE_IMAGE_FORMAT_LEGACY)
 /**
  * image_get_kernel - verify legacy format kernel image
  * @img_addr: in RAM address of the legacy format image to be verified
@@ -888,6 +891,7 @@ static image_header_t *image_get_kernel(ulong img_addr, int 
verify)
}
return hdr;
 }
+#endif
 
 /**
  * boot_get_kernel - find kernel image
@@ -905,7 +909,9 @@ static const void *boot_get_kernel(cmd_tbl_t *cmdtp, int 
flag, int argc,
char * const argv[], bootm_headers_t *images, ulong *os_data,
ulong *os_len)
 {
+#if !defined(CONFIG_DISABLE_IMAGE_FORMAT_LEGACY)
image_header_t  *hdr;
+#endif
ulong   img_addr;
const void *buf;
 #if defined(CONFIG_FIT)
@@ -943,6 +949,7 @@ static const void *boot_get_kernel(cmd_tbl_t *cmdtp, int 
flag, int argc,
*os_data = *os_len = 0;
buf = map_sysmem(img_addr, 0);
switch (genimg_get_format(buf)) {
+#if !defined(CONFIG_DISABLE_IMAGE_FORMAT_LEGACY)
case IMAGE_FORMAT_LEGACY:
printf("## Booting kernel from Legacy Image at %08lx ...\n",
img_addr);
@@ -985,6 +992,7 @@ static const void *boot_get_kernel(cmd_tbl_t *cmdtp, int 
flag, int argc,
images->legacy_hdr_valid = 1;
bootstage_mark(BOOTSTAGE_ID_DECOMP_IMAGE);
break;
+#endif
 #if defined(CONFIG_FIT)
case IMAGE_FORMAT_FIT:
os_noffset = fit_image_load(images, FIT_KERNEL_PROP,
@@ -1114,6 +1122,7 @@ static int image_info(ulong addr)
printf("\n## Checking Image at %08lx ...\n", addr);
 
switch (genimg_get_format(hdr)) {
+#if !defined(CONFIG_DISABLE_IMAGE_FORMAT_LEGACY)
case IMAGE_FORMAT_LEGACY:
puts("   Legacy image found\n");
if (!image_check_magic(hdr)) {
@@ -1135,6 +1144,7 @@ static int image_info(ulong addr)
}
puts("OK\n");
return 0;
+#endif
 #if defined(CONFIG_FIT)
case IMAGE_FORMAT_FIT:
puts("   FIT image found\n");
@@ -1194,6 +1204,7 @@ static int do_imls_nor(void)
goto next_sector;
 
switch (genimg_get_format(hdr)) {
+#if !defined(CONFIG_DISABLE_IMAGE_FORMAT_LEGACY)
case IMAGE_FORMAT_LEGACY:
if (!image_check_hcrc(hdr))
goto next_sector;
@@ -1208,6 +1219,7 @@ static int do_imls_nor(void)
puts("OK\n");
}
b

[U-Boot] [PATCH 3/4] lib, fdt: move fdtdec_get_int() out of lib/fdtdec.c

2014-05-08 Thread Heiko Schocher
move fdtdec_get_int() out of lib/fdtdec.c into lib/fdtdec_common.c
as this function is also used, if CONFIG_OF_CONTROL is not
used. Poped up on the ids8313 board using signed FIT images,
and activating CONFIG_SYS_GENERIC_BOARD. Without this patch
it shows on boot:

No valid FDT found - please append one to U-Boot binary, use u-boot-dtb.bin or 
define CONFIG_OF_EMBED. For sandbox, use -d 

With this patch, it boots again with CONFIG_SYS_GENERIC_BOARD
enabled.

Signed-off-by: Heiko Schocher 
Cc: Simon Glass 
Cc: Tom Rini 
---
 lib/Makefile|  1 +
 lib/fdtdec.c| 18 --
 lib/fdtdec_common.c | 53 +
 tools/fdtdec.c  |  1 +
 4 files changed, 55 insertions(+), 18 deletions(-)
 create mode 100644 lib/fdtdec_common.c

diff --git a/lib/Makefile b/lib/Makefile
index 27e4f78..a3a237f 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_USB_TTY) += circbuf.o
 obj-y += crc7.o
 obj-y += crc8.o
 obj-y += crc16.o
+obj-y += fdtdec_common.o
 obj-$(CONFIG_OF_CONTROL) += fdtdec.o
 obj-$(CONFIG_TEST_FDTDEC) += fdtdec_test.o
 obj-$(CONFIG_GZIP) += gunzip.o
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 8ecb80f..397bcc2 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -646,22 +646,4 @@ int fdtdec_read_fmap_entry(const void *blob, int node, 
const char *name,
 
return 0;
 }
-#else
-#include "libfdt.h"
-#include "fdt_support.h"
-
-int fdtdec_get_int(const void *blob, int node, const char *prop_name,
-   int default_val)
-{
-   const int *cell;
-   int len;
-
-   cell = fdt_getprop_w((void *)blob, node, prop_name, &len);
-   if (cell && len >= sizeof(int)) {
-   int val = fdt32_to_cpu(cell[0]);
-
-   return val;
-   }
-   return default_val;
-}
 #endif
diff --git a/lib/fdtdec_common.c b/lib/fdtdec_common.c
new file mode 100644
index 000..7123554
--- /dev/null
+++ b/lib/fdtdec_common.c
@@ -0,0 +1,53 @@
+/*
+ * Copyright (c) 2014
+ * Heiko Schocher, DENX Software Engineering, h...@denx.de.
+ *
+ * Based on lib/fdtdec.c:
+ * Copyright (c) 2011 The Chromium OS Authors.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef USE_HOSTCC
+#include 
+#include 
+#include 
+
+s32 fdtdec_get_int(const void *blob, int node, const char *prop_name,
+   s32 default_val)
+{
+   const s32 *cell;
+   int len;
+
+   debug("%s: %s: ", __func__, prop_name);
+   cell = fdt_getprop(blob, node, prop_name, &len);
+   if (cell && len >= sizeof(s32)) {
+   s32 val = fdt32_to_cpu(cell[0]);
+
+   debug("%#x (%d)\n", val, val);
+   return val;
+   }
+   debug("(not found)\n");
+   return default_val;
+}
+
+
+#else
+#include "libfdt.h"
+#include "fdt_support.h"
+
+int fdtdec_get_int(const void *blob, int node, const char *prop_name,
+   int default_val)
+{
+   const int *cell;
+   int len;
+
+   cell = fdt_getprop_w((void *)blob, node, prop_name, &len);
+   if (cell && len >= sizeof(int)) {
+   int val = fdt32_to_cpu(cell[0]);
+
+   return val;
+   }
+   return default_val;
+}
+#endif
diff --git a/tools/fdtdec.c b/tools/fdtdec.c
index f1c2256..9987f83 100644
--- a/tools/fdtdec.c
+++ b/tools/fdtdec.c
@@ -1 +1,2 @@
+#include "../lib/fdtdec_common.c"
 #include "../lib/fdtdec.c"
-- 
1.8.3.1

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


[U-Boot] [PATCH 0/4] mpc8313: ids8313 board updates

2014-05-08 Thread Heiko Schocher
- introduce CONFIG_DISABLE_IMAGE_FORMAT_LEGACY for disabling
  booting legacy image format, as this board use only signed
  FIT images, and activiate it for the ids8313 board.

- add CONFIG_SYS_GENERIC_BOARD to the ids8313 board,
  therefore fdtdec_get_int() is moved out of lib/fdtdec.c
  as lib/fdtdec.c is only compiled if CONFIG_OF_CONTROL
  is defined, but defining this for the ids8313 board
  leads in conjunction with CONFIG_SYS_GENERIC_BOARD
  in booting error:

No valid FDT found - please append one to U-Boot binary, use u-boot-dtb.bin or 
define CONFIG_OF_EMBED. For sandbox, use -d 

  So move the common used function fdtdec_get_int()
  out of lib/fdtdec.c into lib/fdtdec_common.c

Cc: Simon Glass 
Cc: Kim Phillips 
Cc: Wolfgang Denk 

Heiko Schocher (4):
  bootm: allow to disable legacy image format
  mpc8313, signed fit: disable legacy image format on ids8313 board
  lib, fdt: move fdtdec_get_int() out of lib/fdtdec.c
  mpc8313: add CONFIG_SYS_GENERIC_BOARD to ids8313 board

 README   |  5 +
 common/cmd_bootm.c   | 14 
 common/cmd_disk.c|  4 
 common/cmd_fdc.c |  4 
 common/cmd_fpga.c|  2 ++
 common/cmd_nand.c|  4 
 common/cmd_source.c  |  4 
 common/cmd_ximg.c|  7 +-
 common/image-fdt.c   | 10 +++--
 common/image.c   | 23 +--
 doc/uImage.FIT/signature.txt |  3 +++
 include/configs/ids8313.h|  4 +++-
 include/image.h  |  2 ++
 lib/Makefile |  1 +
 lib/fdtdec.c | 18 ---
 lib/fdtdec_common.c  | 53 
 tools/fdtdec.c   |  1 +
 17 files changed, 130 insertions(+), 29 deletions(-)
 create mode 100644 lib/fdtdec_common.c

-- 
1.8.3.1

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


[U-Boot] [PATCH 4/4] mpc8313: add CONFIG_SYS_GENERIC_BOARD to ids8313 board

2014-05-08 Thread Heiko Schocher
- add CONFIG_SYS_GENERIC_BOARD
- remove CONFIG_OF_CONTROL to boot again

Signed-off-by: Heiko Schocher 
Cc: Simon Glass 
Cc: Kim Phillips 
---
 include/configs/ids8313.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/configs/ids8313.h b/include/configs/ids8313.h
index a6b861b..a2d95af 100644
--- a/include/configs/ids8313.h
+++ b/include/configs/ids8313.h
@@ -19,6 +19,8 @@
 #define CONFIG_MPC8313
 #define CONFIG_IDS8313
 
+#define CONFIG_SYS_GENERIC_BOARD
+
 #define CONFIG_FSL_ELBC
 
 #define CONFIG_MISC_INIT_R
@@ -583,6 +585,5 @@
 #define CONFIG_RSA
 #define CONFIG_SHA1
 #define CONFIG_SHA256
-#define CONFIG_OF_CONTROL
 
 #endif /* __CONFIG_H */
-- 
1.8.3.1

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


[U-Boot] [PATCH 2/4] mpc8313, signed fit: disable legacy image format on ids8313 board

2014-05-08 Thread Heiko Schocher
Disable legacy image format with CONFIG_DISABLE_IMAGE_FORMAT_LEGACY
on the ids8313 board, as it uses signed FIT images for booting
Linux.

Signed-off-by: Heiko Schocher 
Cc: Simon Glass 
Cc: Kim Phillips 
Cc: Michael Conrad 
---
 include/configs/ids8313.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/ids8313.h b/include/configs/ids8313.h
index 613f7e1..a6b861b 100644
--- a/include/configs/ids8313.h
+++ b/include/configs/ids8313.h
@@ -577,6 +577,7 @@
 
 #define CONFIG_FIT
 #define CONFIG_FIT_SIGNATURE
+#define CONFIG_DISABLE_IMAGE_FORMAT_LEGACY
 #define CONFIG_CMD_FDT
 #define CONFIG_CMD_HASH
 #define CONFIG_RSA
-- 
1.8.3.1

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


Re: [U-Boot] Mainline u-boot SPL for socfpga

2014-05-08 Thread Chin Liang See
Hi Charles,


On Tue, 2014-05-06 at 12:22 +1200, Charles Manning wrote:
> Hello
> 
> 
> I am trying to understand the state of the socfpga preloader in
> mainline u-boot.
> 
> 
> From what I see, this is broken and perhaps has never worked.
> 
> 
> When I build the code in u-boot-socfpga I get a healthy working
> u-boot-spl.bin of approx 45kbytes.
> 
> 
> When I build the mainline u-boot code I get a broken u-boot-spl.bin of
> approx 3kbytes.
> 
> 
> It seems the mainline u-boot is missing stuff, including the
> all-critical sdram initialisation without which the SPL is useless.
> 
> 
As of now, we have most of the drivers already upstreamed to main line.
The missing piece here are the SDRAM driver. The SDRAM driver poses a
big challenge as its now licensed under BSD-3 clause. I am still working
with legal team to look into potential to make it GPL license.


> So, I have a few related questions:
> 
> 
> 1. The SDRAM init code, like other SocFPGA "hand-off" files is
> generated by the Altera tools. Since it is not hand written, and is
> not compliant with u-boot coding style. Is it more important to
> preserve coding style and have a broken SPL than it is to have a
> working SPL and broken code?
> 

The SDRAM handoff files generated by tools is not compliance as the
original code developer doesn't familiar with open source world. But if
you look into the SDRAM handoff files within rocketboard.org git, the
existing code already updated. I enhanced the code to ensure it meet
with basic coding standard. But further enhancement is needed and
on-going now.

> 
> 2. Is there a practical "half-way" compromise whereby the generated
> code is run through lindent and we just accept that this is as good as
> it gets?
> 
> 
The on-going plan now is to use the enhanced SDRAM handoff file at
rocketboard.org. From there, we want to streamline the driver by
removing unused code. Once its ready, we will upstream this file.


> 3. Can we get some sort of coding style waiver, considering that this
> code is off in a board file and does not impact on anyone working on
> anything other than socfpga (indeed nobody even working on socfpga
> even reads it).
> 
> 
> Clearly significant hand editing generated code makes for a very
> broken workflow, but running it through an automated step like lindent
> is Ok from a workflow point of view.
> 
> 
> Unless this can be resolved we end up with a situation where people
> working on SocFPGA are forced to fork for practical reasons.


I believe it would be tough to get the waiver. Nevertheless, we are
further enhancing the handoff files to a state which is good for
upstreaming. At same time, I am also working with tools team to ensure
all these enhancement is putting back to original code.

Thanks

Chin Liang
> 
> 
> Regards
> 
> 
> Charles
> 
> 
> 


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


Re: [U-Boot] Pull request: u-boot-dfu

2014-05-08 Thread Marek Vasut
On Thursday, May 08, 2014 at 09:08:24 AM, Lukasz Majewski wrote:
> Hi Heiko,
> 
> > Hello Lukasz,
> > 
> > Am 08.05.2014 08:30, schrieb Lukasz Majewski:
> > > Hi Marek,
> > > 
> > >> On Tuesday, May 06, 2014 at 11:29:32 AM, Lukasz Majewski wrote:
> > >>> Hi Marek,
> > >>> 
> > >>> The following changes since commit
> > >>> 
> > >>> af41d6b4cb1602abebaaa9c8774a9b0ece564796:
> > >>>common: fixed linker-list example (2014-05-05 10:24:13 +0200)
> > >>> 
> > >>> are available in the git repository at:
> > >>>ssh://gu-...@git.denx.de/u-boot-dfu master
> > >>> 
> > >>> for you to fetch changes up to
> > >>> 
> > >>> c805776ce7079c7b7dd54c644b499e1b8f6296b1:
> > >>>ums: allow the user to specify the device type (2014-05-06
> > >>> 
> > >>> 11:13:23 +0200)
> > >>> 
> > >>> 
> > >>> 
> > >>> Stephen Warren (9):
> > >>>usb: ums: add error handling for failed registration
> > >>>ums: support block devices not MMC devices
> > >>>ums: remove UMS_{NUM,START}_SECTORS + UMS_START_SECTOR
> > >>>ums: remove error-checking of MMC device size
> > >>>ums: remove ums_disk_init()
> > >>>ums: move IO support code to common location
> > >>>ums: use get_device() not find_mmc_device();
> > >>>ums: move all variable declarations to the start of the
> > >>> 
> > >>> block ums: allow the user to specify the device type
> > >> 
> > >> This doesn't match what's in U-Boot-dfu.git/master [1] it seems. Or
> > >> does it ... ?
> > > 
> > > This PR seems outdated :-).
> > > 
> > > I've also added to u-boot-dfu work done Rob Herring in the meantime.
> > > 
> > > I will prepare new PR with those changes included.
> > > Thanks for pointing out.
> > 
> > Hmm, I have 2 patches pending ...
> > 
> > [U-Boot,1/2] musb-new, dfu: first send request answer then call
> > completions http://patchwork.ozlabs.org/patch/337982/
> > 
> > and
> > 
> > [U-Boot,v2] dfu, nand: add medium specific polltimeout function
> > http://patchwork.ozlabs.org/patch/338369/
> > 
> > Could you (or Marek) add them? Or are there some issues with them?
> 
> I will test them and if no regressions appear I will add them to
> u-boot-dfu tree.

Thanks.

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


Re: [U-Boot] Mainline u-boot on socfpga (SocKit) board

2014-05-08 Thread Chin Liang See
Hi Pavel,

On Wed, 2014-05-07 at 17:48 +0200, ZY - pavel wrote:
> Hi!
> 
> I know that mainline U-Boot SPL is quite far from working on
> socfpga... but would like to ask, what is the status of U-Boot
> proper. That should work on socfpga, right? Or are there some pieces
> missing?
> 
> I tried 
> 
> commit 173d294b94cfec10063a5be40934d6d8fb7981ce
> Merge: 33b0f7b 870e0bd
> Author: Tom Rini 
> Date:   Tue May 6 14:55:45 2014 -0400
> 
> Merge branch 'serial' of git://www.denx.de/git/u-boot-microblaze
> 
> and it just dies with no output.
> 
> I'd really like to get something close to mainline working, so that I
> can generate patches etc.
> 

The missing piece here is the SDRAM driver. This is a big piece as
U-boot require the SDRAM to run. As of now, I am enhancing the existing
SDRAM drivers to ensure its compliance with the coding standard. 

But nevertheless, it poses another challenge when come to license. The
driver is currently licensed under BSD-3 clause. Wonder can we upstream
BSD-3 clause code? Any advise would be appreciated.

Thanks

Chin Liang


> Thanks,
>   Pavel


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


Re: [U-Boot] [PATCH] zynq: ignore ps7_init.h

2014-05-08 Thread Masahiro Yamada
Hi Michal,

> 
> Here is just one question if we should also ignore ps7_init.c too.
> It means move current ps7_init weak function to spl.c in mach-zynq
> and just compile ps7_init.c in board file if it is available there.
> 
> Is there any nice hook in Kbuild to compile file if it is available?
> 
> Something like
> [ -f ps7_init.c ] && compile it

Nice suggestion!


> Then we can just move weak function
> and ignore ps7_init.c/h files in board file.
> 

This might not be beautiful very much, but
we can write board/xilinx/zynq/Makefile like this:

obj-y   := board.o
obj-$(CONFIG_SPL_BUILD) += $(if $(wildcard 
$(srctree)/$(src)/ps7_init.c),ps7_init.o)



Best Regards
Masahiro Yamada

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


Re: [U-Boot] [PATCH v3] lib:crc32:hash: Allow setting of the initial crc32 value

2014-05-08 Thread Lukasz Majewski
Hi Simon,

> Hi Lukasz,
> 
> On 7 May 2014 06:57, Lukasz Majewski  wrote:
> >
> > The current approach set the initial value of crc32 calculation to
> > zero, which is correct for calculating checksum of the whole chunk
> > of data.
> >
> > It however, lacks the flexibility, when one wants to calculate
> > CRC32 of a file comprised of many smaller parts received separately.
> >
> > In the proposed approach the output value is used as a starting
> > condition for the proper crc32 calculation at crc32_wd function.
> > This behavior is identical to the one provided by crc32() method
> > implementation.
> >
> > Additionally comments were appropriately updated.
> 
> Maybe I am missing something, but this doesn't seem necessary. In
> hash.h we have
> 
> hash_init()
> hash_update()
> hash_finish()
> 
> which permits you to pass more data through a hash function. Doesn't
> this already do what you want?

I thought, that I would get away with replacing crc32() function call
with similar one - hash_block(). As it was pointed out it doesn't
itself provide the same functionality.

However, I will try to implement the solution you suggested. Thanks for
tip.


> 
> What is missing is probably command-line access to this API.
> Something like:
> 
> hash init , 
> hash update  , , 
> hash finish , [*]
> 
> or similar.
> 
> Regards,
> Simon


-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] Pull request: u-boot-dfu

2014-05-08 Thread Lukasz Majewski
Dear Marek,

Please pull following code. In the same occasion I would like to
apologize for the fuzz with sending the last PR.

This one is ready to go and (hopefully) clans up all the code floating
around various USB gadgets and DFU.

The following changes since commit
340ed422d2a58c4858ba8e110c233e8ae92c04e0:

  usb: ums: remove ci_udc special case (2014-05-07 23:36:58 +0200)

are available in the git repository at:

  ssh://gu-...@git.denx.de/u-boot-dfu master

for you to fetch changes up to fc25fa27e5f439705e9ca42182014e2d75d9f0ae:

  dfu, nand: add medium specific polltimeout function (2014-05-08
  10:38:30 +0200)


Heiko Schocher (2):
  musb-new, dfu: first send request answer then call completions
  dfu, nand: add medium specific polltimeout function

Rob Herring (1):
  arm: beagle: enable Android fastboot support

Sebastian Siewior (2):
  image: add support for Android's boot image format
  usb/gadget: add the fastboot gadget

Stephen Warren (9):
  usb: ums: add error handling for failed registration
  ums: support block devices not MMC devices
  ums: remove UMS_{NUM,START}_SECTORS + UMS_START_SECTOR
  ums: remove error-checking of MMC device size
  ums: remove ums_disk_init()
  ums: move IO support code to common location
  ums: use get_device() not find_mmc_device();
  ums: move all variable declarations to the start of the block
  ums: allow the user to specify the device type

 README |   22 +++
 board/samsung/common/Makefile  |1 -
 board/samsung/common/ums.c |   74 
 common/Makefile|3 +
 common/cmd_bootm.c |   23 +++-
 common/cmd_fastboot.c  |   36 
 common/cmd_usb_mass_storage.c  |   91
 + common/image-android.c
 |   84 +++
 common/image.c |   20 +--
 doc/README.android-fastboot|   91
 + doc/README.android-fastboot-protocol
 |  170 ++
 drivers/dfu/dfu_nand.c |   13 +
 drivers/usb/gadget/Makefile|1 +
 drivers/usb/gadget/f_dfu.c |   10 +++-
 drivers/usb/gadget/f_fastboot.c|  513
 
+
 drivers/usb/musb-new/musb_gadget_ep0.c |8 +--
 include/android_image.h|   69 ++
 include/configs/omap3_beagle.h |   10 
 include/dfu.h  |1 +
 include/image.h|   13 +
 include/usb_mass_storage.h |   13 + 

21 files changed, 1157 insertions(+), 109 deletions(-) delete mode 100644
 board/samsung/common/ums.c create mode 100644 common/cmd_fastboot.c
 create mode 100644 common/image-android.c create mode 100644
 doc/README.android-fastboot create mode 100644
 doc/README.android-fastboot-protocol create mode 100644
 drivers/usb/gadget/f_fastboot.c create mode 100644
 include/android_image.h


-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] sh: delete an unused source file

2014-05-08 Thread Nobuhiro Iwamatsu
Hi,

Sorry, reply was late.
This was already applied into u-boot/master.

Thanks!

Nobuhiro

2014-04-28 17:00 GMT+09:00 Masahiro Yamada :
> Hi Nobuhiro,
>
> On Mon, 31 Mar 2014 15:02:24 +0900
> Nobuhiro Iwamatsu  wrote:
>
>> Applied to u-boot-sh.git.
>> Thanks!
>>
>> Nobuhiro
>>
>> 2014-03-31 14:46 GMT+09:00 Nobuhiro Iwamatsu 
>> :
>> > 2014-03-31 13:09 GMT+09:00 Masahiro Yamada :
>> >> Signed-off-by: Masahiro Yamada 
>> >> Cc: Nobuhiro Iwamatsu 
>> >
>> > Acked-by: Nobuhiro Iwamatsu 
>
>
> This patch went to u-boot-sh/next but it has not been synced with
> the mainline.
>
> Could you send a pull-request of u-boot-sh/next ?
>
> Best Regards
> Masahiro Yamada
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot



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


Re: [U-Boot] [PATCH 1/2] musb-new, dfu: first send request answer then call completions

2014-05-08 Thread Lukasz Majewski
Hi Heiko,

> comment in ep0_txstate() states:
> 
> "report completions as soon as the fifo's loaded; there's no win
>  in waiting till this last packet gets acked".
> 
> This is wrong for using dfu. In the dfu usecase we must send
> a PollTimeout to the host, so the host can wait until the
> U-Boot Code is ready for answering new usb requests. So the
> answer which contains the PollTimeout must send *before*
> U-Boot calls req->complete.
> 
> The req->complete is used in the dfu case for flushing the
> medium, when entering DFU_STATE_dfuMANIFEST_SYNC state.
> 
> Signed-off-by: Heiko Schocher 
> Cc: Lukasz Majewski 
> Cc: Kyungmin Park 
> Cc: Marek Vasut 
> Cc: Pantelis Antoniou 

Applied to u-boot-dfu. Thanks.

-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2] dfu, nand: add medium specific polltimeout function

2014-05-08 Thread Lukasz Majewski
Hi Heiko,

> add a possibility to add a medium specific polltimeout
> function. So it is possible to define different
> poll timeouts.
> 
> Used on nand medium, for setting the DFU_MANIFEST_POLL_TIMEOUT
> only on nand ubi partitions, which is currently the only
> usecase.
> 
> Signed-off-by: Heiko Schocher 
> Cc: Lukasz Majewski 
> Cc: Kyungmin Park 
> Cc: Marek Vasut 
> Cc: Pantelis Antoniou 

Applied to u-boot-dfu. Thanks.

-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] zynq: add empty xil_io.h to avoid compile error

2014-05-08 Thread Michal Simek
On 05/08/2014 10:13 AM, Masahiro Yamada wrote:
> ps7_init.c exported by hw project has #include "xil_io.h" line
> but U-Boot does not have "xil_io.h".
> 
> So we get an error on SPL build:
>   ps7_init.c:12581:20: fatal error: xil_io.h: No such file or directory
> 
> We can delete the include directive in ps7_init.c to avoid this error.
> But it is painful to do this every time we export ps7_init.c file.
> 
> Instead, we can put an empty xil_io.h in the same directory
> so we can directly copy ps7_init.c as is.
> 
> Signed-off-by: Masahiro Yamada 
> Cc: Michal Simek 
> ---
>  board/xilinx/zynq/xil_io.h | 13 +
>  1 file changed, 13 insertions(+)
>  create mode 100644 board/xilinx/zynq/xil_io.h
> 
> diff --git a/board/xilinx/zynq/xil_io.h b/board/xilinx/zynq/xil_io.h
> new file mode 100644
> index 000..e59a977
> --- /dev/null
> +++ b/board/xilinx/zynq/xil_io.h
> @@ -0,0 +1,13 @@
> +/*
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#ifndef XIL_IO_H   /* prevent circular inclusions */
> +#define XIL_IO_H
> +
> +/*
> + * This empty file is here because ps7_init.c exported by hw project
> + * has #include "xil_io.h" line.
> + */
> +
> +#endif /* XIL_IO_H */
> 

This is good if this is acceptable by others.

Acked-by: Michal Simek 

Thanks,
Michal


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




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


Re: [U-Boot] [PATCH] zynq: ignore ps7_init.h

2014-05-08 Thread Michal Simek
On 05/08/2014 10:13 AM, Masahiro Yamada wrote:
> ps_init.h should be ignored because it is supposed to
> be copied from an external project.
> 
> Signed-off-by: Masahiro Yamada 
> Cc: Michal Simek 
> ---
>  board/xilinx/zynq/.gitignore | 1 +
>  1 file changed, 1 insertion(+)
>  create mode 100644 board/xilinx/zynq/.gitignore
> 
> diff --git a/board/xilinx/zynq/.gitignore b/board/xilinx/zynq/.gitignore
> new file mode 100644
> index 000..5255763
> --- /dev/null
> +++ b/board/xilinx/zynq/.gitignore
> @@ -0,0 +1 @@
> +ps7_init.h
> 

Here is just one question if we should also ignore ps7_init.c too.
It means move current ps7_init weak function to spl.c in mach-zynq
and just compile ps7_init.c in board file if it is available there.

Is there any nice hook in Kbuild to compile file if it is available?

Something like
[ -f ps7_init.c ] && compile it

Then we can just move weak function
and ignore ps7_init.c/h files in board file.

Thanks,
Michal

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




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


[U-Boot] [PATCH 3/3] fs/fat: correct FAT16/12 file finding in root dir

2014-05-08 Thread Josh Wu
When write a file into FAT file system, it will search a match file in
root dir. So the find_directory_entry() will get the first cluster of
root dir content and search the directory item one by one. If the file
is not found, we will call get_fatent_value() to get next cluster of root
dir via lookup the FAT table and continue the search.

The issue is in FAT16/12 system, we cannot get root dir's next clust
from FAT table. The FAT table only be use to find the clust of data
aera in FAT16/12.

In FAT16/12 if the clust is in root dir, the clust number is a negative
number or 0, 1. Since root dir is located in front of the data area.
Data area start clust #2. So the root dir clust number should < 2.

This patch will check above situation before call get_fatenv_value().
If curclust is < 2, include minus number, we just increase one on the
curclust since root dir is in continous cluster.

The patch also add a sanity check for entry in get_fatenv_value().

Signed-off-by: Josh Wu 
---
 fs/fat/fat_write.c |   27 +++
 1 file changed, 27 insertions(+)

diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
index 623d11c..da8902a 100644
--- a/fs/fat/fat_write.c
+++ b/fs/fat/fat_write.c
@@ -139,6 +139,11 @@ static __u32 get_fatent_value(fsdata *mydata, __u32 entry)
__u32 ret = 0x00;
__u16 val1, val2;
 
+   if (CHECK_CLUST(entry, mydata->fatsize)) {
+   printf("Error: Invalid FAT entry: 0x%08x\n", entry);
+   return ret;
+   }
+
switch (mydata->fatsize) {
case 32:
bufnum = entry / FAT32BUFSIZE;
@@ -881,6 +886,28 @@ static dir_entry *find_directory_entry(fsdata *mydata, int 
startsect,
return dentptr;
}
 
+   /*
+* In FAT16/12, the root dir is locate before data area, shows
+* in following:
+* -
+* | Boot | FAT1 & 2 | Root dir | Data (start from cluster #2) |
+* -
+*
+* As a result if curclust is in Root dir, it is a negative
+* number or 0, 1.
+*
+*/
+   if (mydata->fatsize != 32 && (int)curclust <= 1) {
+   /* Current clust is in root dir, set to next clust */
+   curclust++;
+   if ((int)curclust <= 1)
+   continue;   /* continue to find */
+
+   /* Reach the end of root dir */
+   empty_dentptr = dentptr;
+   return NULL;
+   }
+
curclust = get_fatent_value(mydata, dir_curclust);
if (IS_LAST_CLUST(curclust, mydata->fatsize)) {
empty_dentptr = dentptr;
-- 
1.7.9.5

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


[U-Boot] [PATCH 1/3] fs/fat: add fat12 cluster check

2014-05-08 Thread Josh Wu
Signed-off-by: Josh Wu 
---
 include/fat.h |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/fat.h b/include/fat.h
index c8eb7cc..65da733 100644
--- a/include/fat.h
+++ b/include/fat.h
@@ -85,7 +85,9 @@
+ (mydata->fatsize != 32 ? 0 : \
  (FAT2CPU16((dent)->starthi) << 16)))
 #define CHECK_CLUST(x, fatsize) ((x) <= 1 || \
-   (x) >= ((fatsize) != 32 ? 0xfff0 : 0xff0))
+   (x) >= ((fatsize) != 32 ? \
+   ((fatsize) != 16 ? 0xff0 : 0xfff0) : \
+   0xff0))
 
 typedef struct boot_sector {
__u8ignored[3]; /* Bootstrap code */
-- 
1.7.9.5

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


[U-Boot] [PATCH 2/3] fs: fat_write: fix the incorrect last cluster checking

2014-05-08 Thread Josh Wu
In fat_write.c, the last clust condition check is incorrect:

  if ((curclust >= 0xff8) || (curclust >= 0xfff8)) {
... ...
  }

For example, in FAT32 if curclust is 0x11000. It is a valid clust.
But on above condition check, it will be think as a last clust.

So the correct last clust check should be:
  in fat32, curclust >= 0xff8
  in fat16, curclust >= 0xfff8
  in fat12, curclust >= 0xff8

This patch correct the last clust check.

Signed-off-by: Josh Wu 
---
 fs/fat/fat_write.c |2 +-
 include/fat.h  |3 +++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
index 9f5e911..623d11c 100644
--- a/fs/fat/fat_write.c
+++ b/fs/fat/fat_write.c
@@ -882,7 +882,7 @@ static dir_entry *find_directory_entry(fsdata *mydata, int 
startsect,
}
 
curclust = get_fatent_value(mydata, dir_curclust);
-   if ((curclust >= 0xff8) || (curclust >= 0xfff8)) {
+   if (IS_LAST_CLUST(curclust, mydata->fatsize)) {
empty_dentptr = dentptr;
return NULL;
}
diff --git a/include/fat.h b/include/fat.h
index 65da733..81d9790 100644
--- a/include/fat.h
+++ b/include/fat.h
@@ -84,6 +84,9 @@
 #define START(dent)(FAT2CPU16((dent)->start) \
+ (mydata->fatsize != 32 ? 0 : \
  (FAT2CPU16((dent)->starthi) << 16)))
+#define IS_LAST_CLUST(x, fatsize) ((x) >= ((fatsize) != 32 ? \
+   ((fatsize) != 16 ? 0xff8 : 0xfff8) : \
+   0xff8))
 #define CHECK_CLUST(x, fatsize) ((x) <= 1 || \
(x) >= ((fatsize) != 32 ? \
((fatsize) != 16 ? 0xff0 : 0xfff0) : \
-- 
1.7.9.5

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


[U-Boot] [PATCH 0/3] fs: fat: misc fix for FAT16/12

2014-05-08 Thread Josh Wu
This patch series fix the bug when search files in root dir in FAT16/12.

In early time, I've sent a single patch for this:
http://patchwork.ozlabs.org/patch/336585/

This patch series is updated version compare with the early one in above URL.
It not only refined my early fix but also add other misc fixes.

Josh Wu (3):
  fs/fat: add fat12 cluster check
  fs: fat_write: fix the incorrect last cluster checking
  fs/fat: correct FAT16/12 file finding in root dir

 fs/fat/fat_write.c |   29 -
 include/fat.h  |7 ++-
 2 files changed, 34 insertions(+), 2 deletions(-)

-- 
1.7.9.5

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


[U-Boot] [PATCH] zynq: add empty xil_io.h to avoid compile error

2014-05-08 Thread Masahiro Yamada
ps7_init.c exported by hw project has #include "xil_io.h" line
but U-Boot does not have "xil_io.h".

So we get an error on SPL build:
  ps7_init.c:12581:20: fatal error: xil_io.h: No such file or directory

We can delete the include directive in ps7_init.c to avoid this error.
But it is painful to do this every time we export ps7_init.c file.

Instead, we can put an empty xil_io.h in the same directory
so we can directly copy ps7_init.c as is.

Signed-off-by: Masahiro Yamada 
Cc: Michal Simek 
---
 board/xilinx/zynq/xil_io.h | 13 +
 1 file changed, 13 insertions(+)
 create mode 100644 board/xilinx/zynq/xil_io.h

diff --git a/board/xilinx/zynq/xil_io.h b/board/xilinx/zynq/xil_io.h
new file mode 100644
index 000..e59a977
--- /dev/null
+++ b/board/xilinx/zynq/xil_io.h
@@ -0,0 +1,13 @@
+/*
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef XIL_IO_H   /* prevent circular inclusions */
+#define XIL_IO_H
+
+/*
+ * This empty file is here because ps7_init.c exported by hw project
+ * has #include "xil_io.h" line.
+ */
+
+#endif /* XIL_IO_H */
-- 
1.8.3.2

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


[U-Boot] [PATCH] zynq: ignore ps7_init.h

2014-05-08 Thread Masahiro Yamada
ps_init.h should be ignored because it is supposed to
be copied from an external project.

Signed-off-by: Masahiro Yamada 
Cc: Michal Simek 
---
 board/xilinx/zynq/.gitignore | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 board/xilinx/zynq/.gitignore

diff --git a/board/xilinx/zynq/.gitignore b/board/xilinx/zynq/.gitignore
new file mode 100644
index 000..5255763
--- /dev/null
+++ b/board/xilinx/zynq/.gitignore
@@ -0,0 +1 @@
+ps7_init.h
-- 
1.8.3.2

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


Re: [U-Boot] Pull request: u-boot-dfu

2014-05-08 Thread Lukasz Majewski
Hi Heiko,

> Hello Lukasz,
> 
> Am 08.05.2014 08:30, schrieb Lukasz Majewski:
> > Hi Marek,
> >
> >> On Tuesday, May 06, 2014 at 11:29:32 AM, Lukasz Majewski wrote:
> >>> Hi Marek,
> >>>
> >>> The following changes since commit
> >>> af41d6b4cb1602abebaaa9c8774a9b0ece564796:
> >>>
> >>>common: fixed linker-list example (2014-05-05 10:24:13 +0200)
> >>>
> >>> are available in the git repository at:
> >>>
> >>>ssh://gu-...@git.denx.de/u-boot-dfu master
> >>>
> >>> for you to fetch changes up to
> >>> c805776ce7079c7b7dd54c644b499e1b8f6296b1:
> >>>
> >>>ums: allow the user to specify the device type (2014-05-06
> >>> 11:13:23 +0200)
> >>>
> >>> 
> >>> Stephen Warren (9):
> >>>usb: ums: add error handling for failed registration
> >>>ums: support block devices not MMC devices
> >>>ums: remove UMS_{NUM,START}_SECTORS + UMS_START_SECTOR
> >>>ums: remove error-checking of MMC device size
> >>>ums: remove ums_disk_init()
> >>>ums: move IO support code to common location
> >>>ums: use get_device() not find_mmc_device();
> >>>ums: move all variable declarations to the start of the
> >>> block ums: allow the user to specify the device type
> >>
> >> This doesn't match what's in U-Boot-dfu.git/master [1] it seems. Or
> >> does it ... ?
> >
> > This PR seems outdated :-).
> >
> > I've also added to u-boot-dfu work done Rob Herring in the meantime.
> >
> > I will prepare new PR with those changes included.
> > Thanks for pointing out.
> 
> Hmm, I have 2 patches pending ...
> 
> [U-Boot,1/2] musb-new, dfu: first send request answer then call
> completions http://patchwork.ozlabs.org/patch/337982/
> 
> and
> 
> [U-Boot,v2] dfu, nand: add medium specific polltimeout function
> http://patchwork.ozlabs.org/patch/338369/
> 
> Could you (or Marek) add them? Or are there some issues with them?

I will test them and if no regressions appear I will add them to
u-boot-dfu tree.

> 
> Thanks!
> 
> bye,
> Heiko



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v3 10/13] ARM: HYP/non-sec/PSCI: emit DT nodes

2014-05-08 Thread Ian Campbell
On Thu, 2014-05-08 at 07:22 +0100, Marc Zyngier wrote:
> Hi Ian,
> 
> On 2014-05-07 20:24, Ian Campbell wrote:
> > On Sat, 2014-02-15 at 13:36 +, Marc Zyngier wrote:
> >> @@ -32,5 +33,11 @@ int arch_fixup_fdt(void *blob)
> >>size[bank] = bd->bi_dram[bank].size;
> >>}
> >>
> >> -  return fdt_fixup_memory_banks(blob, start, size, 
> >> CONFIG_NR_DRAM_BANKS);
> >> +  ret = fdt_fixup_memory_banks(blob, start, size, 
> >> CONFIG_NR_DRAM_BANKS);
> >> +  if (ret)
> >> +  return ret;
> >> +
> >> +#if defined(CONFIG_ARMV7_NONSEC) || defined(CONFIG_ARMV7_VIRT)
> >> +  return armv7_update_dt(blob);
> >> +#endif
> >
> > For platforms where neither of these CONFIG_* are set this results 
> > in:
> > arch/arm/lib/bootm-fdt.c: In function ‘arch_fixup_fdt’:
> > arch/arm/lib/bootm-fdt.c:43:1: warning: control reaches end of
> > non-void function [-Wreturn-type]
> >  }
> 
> I'm afraid this is old news. ;-)
> 
> This bug has been fixed in v4:
> http://lists.denx.de/pipermail/u-boot/2014-April/178280.html

AH, I thought I had the latest from your tree and I was only ccd on v3
so I missed it.

Ian.

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