date:20130520

[U-Boot] [PATCH V2 OMAP-ULPI]: This patch fix the omap access to the transceiver configuration registers using the ulpi bus.

2013-05-20 Thread Michael Trimarchi

This patch fix the omap access to the transceiver configuration registers
using the ulpi bus. As reported by the documentation the bit31 is used
only to check if the transaction is done or still running and the reading
and writing operation have different offset and have different values.
What we need to do at the end of a transaction is leave the bus in done state.
Anyway an error using the ulpi omap register is not recoverable so any error
give out the usage of this interface.

Signed-off-by: Michael Trimarchi 
---

Changes for V2:
- Fix commit message

---
 drivers/usb/ulpi/omap-ulpi-viewport.c |   40 +++--
 1 file changed, 8 insertions(+), 32 deletions(-)

diff --git a/drivers/usb/ulpi/omap-ulpi-viewport.c 
b/drivers/usb/ulpi/omap-ulpi-viewport.c
index 3c1ea1a..2a42033 100644
--- a/drivers/usb/ulpi/omap-ulpi-viewport.c
+++ b/drivers/usb/ulpi/omap-ulpi-viewport.c
@@ -22,18 +22,19 @@
 #include 
 #include 
 
-#define OMAP_ULPI_WR_OPSEL (3 << 21)
-#define OMAP_ULPI_ACCESS   (1 << 31)
+#define OMAP_ULPI_WR_OPSEL (2 << 22)
+#define OMAP_ULPI_RD_OPSEL (3 << 22)
+#define OMAP_ULPI_START(1 << 31)
 
 /*
- * Wait for the ULPI Access to complete
+ * Wait for having ulpi in done state
  */
 static int ulpi_wait(struct ulpi_viewport *ulpi_vp, u32 mask)
 {
int timeout = CONFIG_USB_ULPI_TIMEOUT;
 
while (--timeout) {
-   if ((readl(ulpi_vp->viewport_addr) & mask))
+   if (!(readl(ulpi_vp->viewport_addr) & mask))
return 0;
 
udelay(1);
@@ -43,40 +44,15 @@ static int ulpi_wait(struct ulpi_viewport *ulpi_vp, u32 
mask)
 }
 
 /*
- * Wake the ULPI PHY up for communication
- *
- * returns 0 on success.
- */
-static int ulpi_wakeup(struct ulpi_viewport *ulpi_vp)
-{
-   int err;
-
-   if (readl(ulpi_vp->viewport_addr) & OMAP_ULPI_ACCESS)
-   return 0; /* already awake */
-
-   writel(OMAP_ULPI_ACCESS, ulpi_vp->viewport_addr);
-
-   err = ulpi_wait(ulpi_vp, OMAP_ULPI_ACCESS);
-   if (err)
-   debug("ULPI wakeup timed out\n");
-
-   return err;
-}
-
-/*
  * Issue a ULPI read/write request
  */
 static int ulpi_request(struct ulpi_viewport *ulpi_vp, u32 value)
 {
int err;
 
-   err = ulpi_wakeup(ulpi_vp);
-   if (err)
-   return err;
-
writel(value, ulpi_vp->viewport_addr);
 
-   err = ulpi_wait(ulpi_vp, OMAP_ULPI_ACCESS);
+   err = ulpi_wait(ulpi_vp, OMAP_ULPI_START);
if (err)
debug("ULPI request timed out\n");
 
@@ -85,7 +61,7 @@ static int ulpi_request(struct ulpi_viewport *ulpi_vp, u32 
value)
 
 int ulpi_write(struct ulpi_viewport *ulpi_vp, u8 *reg, u32 value)
 {
-   u32 val = ((ulpi_vp->port_num & 0xf) << 24) |
+   u32 val = (OMAP_ULPI_START | (ulpi_vp->port_num & 0xf) << 24) |
OMAP_ULPI_WR_OPSEL | ((u32)reg << 16) | (value & 0xff);
 
return ulpi_request(ulpi_vp, val);
@@ -95,7 +71,7 @@ u32 ulpi_read(struct ulpi_viewport *ulpi_vp, u8 *reg)
 {
int err;
u32 val = ((ulpi_vp->port_num & 0xf) << 24) |
-OMAP_ULPI_WR_OPSEL | ((u32)reg << 16);
+OMAP_ULPI_RD_OPSEL | ((u32)reg << 16);
 
err = ulpi_request(ulpi_vp, val);
if (err)
-- 
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 0/4] Factorize ARM relocate_code instances

2013-05-20 Thread Albert ARIBAUD

Hi Benoît,

On Sun, 19 May 2013 17:57:59 +0200 (CEST), Benoît Thébaudeau
 wrote:

> Hi Albert,
> 
> On Sunday, May 19, 2013 1:48:11 PM, Albert ARIBAUD wrote:
> > This series replaces all instances of relocate_code in
> > various start.S files from the ARM architecture with a
> > single instance in arch/arm/lib/relocate.S.
> > 
> > This is done in steps, each step keeping the whole of ARM
> > U-Boot buildable and runnable and touching as little code
> > as necessary.
> > 
> > 1. Drop mx31pdk SPL call to relocate_code
> > 
> > In SPL of mx31pdk, board_init_f calls relocate_code to
> > move SPL from the NAND read buffer to SRAM. This move
> > is not a relocation and is thus better implemented as
> > a simple ad hoc copy loop.
> > 
> > 2. Drop tx25 SPL call to relocate_code
> > 
> > Same as mx31pdk.
> > 
> > 3. Prevent all SPLs from assembling relocate_code
> > 
> > Now that no SPL uses relocate_code any more, remove
> > it completely from SPL builds by putting it entirely
> > between #ifndef CONFIG_SPL_BUILD and #endif preprocessor
> > conditional.
> > 
> > 4. Actual factorization of relocate_code
> > 
> > Remove all instances of relocate_code from start.S and
> > create a new file, arch/arm/lib/relocate.S, to provide
> > the new single instance of relocate_code.
> > 
> > The only non-trivial change is that for PXA25X, a call
> > to unlock (actually disable) dcache is moved from before
> > relocating to after relocating. As this cache is either
> > locked-as-RAM or disabled, but never used as actual DDR
> > cache, this move has no performance effect on relocation
> > and no functional impact either.
> > 
> > The relocation routine was step-tested on versatileqemu
> > under gdb. Especially, both relocation offset (from
> > _start to addr_moni and local offsets (from relocate_code
> > to several linker script symbols) have been verified.
> > 
> > Changes in v4:
> > - added blank line after PXA25X conditional code
> > - fixed typos in relocate_code comments
> > - brought back 'mov pc,lr' instead of 'bx lr' for ARMv4
> 
> [...]
> 
> Perfect!
> 
> For this v4 series:
> Reviewed-by: Benoît Thébaudeau 

Thanks Benoît!

Now I need some people to regression-test it on their
HW, both ARM and non-ARM just in case.

> Best regards,
> Benoît

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

Re: [U-Boot] [PATCH V2 OMAP-ULPI]: This patch fix the omap access to the transceiver configuration registers using the ulpi bus.

2013-05-20 Thread Igor Grinberg

Hi Michael,

Sorry for missing the subject last time...
For the subject:
In the square brackets, it should be stated just [PATCH vX]
Afterwards, should come the subsystem/platform
and then short yet meaningful patch description. For example:
[PATCH v2] usb: omap: ulpi: fix ulpi transceiver access

Also, the patch submission rules are available at:
http://www.denx.de/wiki/view/U-Boot/Patches#General_Patch_Submission_Rules
I think it is worth reading.


On 05/20/13 11:53, Michael Trimarchi wrote:
> This patch fix the omap access to the transceiver configuration registers
> using the ulpi bus. As reported by the documentation the bit31 is used
> only to check if the transaction is done or still running and the reading
> and writing operation have different offset and have different values.
> What we need to do at the end of a transaction is leave the bus in done state.
> Anyway an error using the ulpi omap register is not recoverable so any error
> give out the usage of this interface.
> 
> Signed-off-by: Michael Trimarchi 

You can add the below tag to your future submissions of this patch
(if you decide to fix the subject).

Reviewed-by: Igor Grinberg 

> ---
> 
> Changes for V2:
>   - Fix commit message
> 
> ---
>  drivers/usb/ulpi/omap-ulpi-viewport.c |   40 
> +++--
>  1 file changed, 8 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/usb/ulpi/omap-ulpi-viewport.c 
> b/drivers/usb/ulpi/omap-ulpi-viewport.c
> index 3c1ea1a..2a42033 100644
> --- a/drivers/usb/ulpi/omap-ulpi-viewport.c
> +++ b/drivers/usb/ulpi/omap-ulpi-viewport.c
> @@ -22,18 +22,19 @@
>  #include 
>  #include 
>  
> -#define OMAP_ULPI_WR_OPSEL   (3 << 21)
> -#define OMAP_ULPI_ACCESS (1 << 31)
> +#define OMAP_ULPI_WR_OPSEL   (2 << 22)
> +#define OMAP_ULPI_RD_OPSEL   (3 << 22)
> +#define OMAP_ULPI_START  (1 << 31)
>  
>  /*
> - * Wait for the ULPI Access to complete
> + * Wait for having ulpi in done state
>   */
>  static int ulpi_wait(struct ulpi_viewport *ulpi_vp, u32 mask)
>  {
>   int timeout = CONFIG_USB_ULPI_TIMEOUT;
>  
>   while (--timeout) {
> - if ((readl(ulpi_vp->viewport_addr) & mask))
> + if (!(readl(ulpi_vp->viewport_addr) & mask))
>   return 0;
>  
>   udelay(1);
> @@ -43,40 +44,15 @@ static int ulpi_wait(struct ulpi_viewport *ulpi_vp, u32 
> mask)
>  }
>  
>  /*
> - * Wake the ULPI PHY up for communication
> - *
> - * returns 0 on success.
> - */
> -static int ulpi_wakeup(struct ulpi_viewport *ulpi_vp)
> -{
> - int err;
> -
> - if (readl(ulpi_vp->viewport_addr) & OMAP_ULPI_ACCESS)
> - return 0; /* already awake */
> -
> - writel(OMAP_ULPI_ACCESS, ulpi_vp->viewport_addr);
> -
> - err = ulpi_wait(ulpi_vp, OMAP_ULPI_ACCESS);
> - if (err)
> - debug("ULPI wakeup timed out\n");
> -
> - return err;
> -}
> -
> -/*
>   * Issue a ULPI read/write request
>   */
>  static int ulpi_request(struct ulpi_viewport *ulpi_vp, u32 value)
>  {
>   int err;
>  
> - err = ulpi_wakeup(ulpi_vp);
> - if (err)
> - return err;
> -
>   writel(value, ulpi_vp->viewport_addr);
>  
> - err = ulpi_wait(ulpi_vp, OMAP_ULPI_ACCESS);
> + err = ulpi_wait(ulpi_vp, OMAP_ULPI_START);
>   if (err)
>   debug("ULPI request timed out\n");
>  
> @@ -85,7 +61,7 @@ static int ulpi_request(struct ulpi_viewport *ulpi_vp, u32 
> value)
>  
>  int ulpi_write(struct ulpi_viewport *ulpi_vp, u8 *reg, u32 value)
>  {
> - u32 val = ((ulpi_vp->port_num & 0xf) << 24) |
> + u32 val = (OMAP_ULPI_START | (ulpi_vp->port_num & 0xf) << 24) |
>   OMAP_ULPI_WR_OPSEL | ((u32)reg << 16) | (value & 0xff);
>  
>   return ulpi_request(ulpi_vp, val);
> @@ -95,7 +71,7 @@ u32 ulpi_read(struct ulpi_viewport *ulpi_vp, u8 *reg)
>  {
>   int err;
>   u32 val = ((ulpi_vp->port_num & 0xf) << 24) |
> -  OMAP_ULPI_WR_OPSEL | ((u32)reg << 16);
> +  OMAP_ULPI_RD_OPSEL | ((u32)reg << 16);
>  
>   err = ulpi_request(ulpi_vp, val);
>   if (err)
> 

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

Re: [U-Boot] [PATCH V2 OMAP-ULPI]: This patch fix the omap access to the transceiver configuration registers using the ulpi bus.

2013-05-20 Thread Michael Trimarchi

Hi

On 20/05/13 12:05, Igor Grinberg wrote:
> Hi Michael,
> 
> Sorry for missing the subject last time...
> For the subject:
> In the square brackets, it should be stated just [PATCH vX]
> Afterwards, should come the subsystem/platform
> and then short yet meaningful patch description. For example:
> [PATCH v2] usb: omap: ulpi: fix ulpi transceiver access
> 
> Also, the patch submission rules are available at:
> http://www.denx.de/wiki/view/U-Boot/Patches#General_Patch_Submission_Rules
> I think it is worth reading.
> 

Sorry, I know but I'm so busy that I have almost edit the last one. 
I will re-submit :(

Michael

> 
> On 05/20/13 11:53, Michael Trimarchi wrote:
>> This patch fix the omap access to the transceiver configuration registers
>> using the ulpi bus. As reported by the documentation the bit31 is used
>> only to check if the transaction is done or still running and the reading
>> and writing operation have different offset and have different values.
>> What we need to do at the end of a transaction is leave the bus in done 
>> state.
>> Anyway an error using the ulpi omap register is not recoverable so any error
>> give out the usage of this interface.
>>
>> Signed-off-by: Michael Trimarchi 
> 
> You can add the below tag to your future submissions of this patch
> (if you decide to fix the subject).
> 
> Reviewed-by: Igor Grinberg 
> 
>> ---
>>
>> Changes for V2:
>>  - Fix commit message
>>
>> ---
>>  drivers/usb/ulpi/omap-ulpi-viewport.c |   40 
>> +++--
>>  1 file changed, 8 insertions(+), 32 deletions(-)
>>
>> diff --git a/drivers/usb/ulpi/omap-ulpi-viewport.c 
>> b/drivers/usb/ulpi/omap-ulpi-viewport.c
>> index 3c1ea1a..2a42033 100644
>> --- a/drivers/usb/ulpi/omap-ulpi-viewport.c
>> +++ b/drivers/usb/ulpi/omap-ulpi-viewport.c
>> @@ -22,18 +22,19 @@
>>  #include 
>>  #include 
>>  
>> -#define OMAP_ULPI_WR_OPSEL  (3 << 21)
>> -#define OMAP_ULPI_ACCESS(1 << 31)
>> +#define OMAP_ULPI_WR_OPSEL  (2 << 22)
>> +#define OMAP_ULPI_RD_OPSEL  (3 << 22)
>> +#define OMAP_ULPI_START (1 << 31)
>>  
>>  /*
>> - * Wait for the ULPI Access to complete
>> + * Wait for having ulpi in done state
>>   */
>>  static int ulpi_wait(struct ulpi_viewport *ulpi_vp, u32 mask)
>>  {
>>  int timeout = CONFIG_USB_ULPI_TIMEOUT;
>>  
>>  while (--timeout) {
>> -if ((readl(ulpi_vp->viewport_addr) & mask))
>> +if (!(readl(ulpi_vp->viewport_addr) & mask))
>>  return 0;
>>  
>>  udelay(1);
>> @@ -43,40 +44,15 @@ static int ulpi_wait(struct ulpi_viewport *ulpi_vp, u32 
>> mask)
>>  }
>>  
>>  /*
>> - * Wake the ULPI PHY up for communication
>> - *
>> - * returns 0 on success.
>> - */
>> -static int ulpi_wakeup(struct ulpi_viewport *ulpi_vp)
>> -{
>> -int err;
>> -
>> -if (readl(ulpi_vp->viewport_addr) & OMAP_ULPI_ACCESS)
>> -return 0; /* already awake */
>> -
>> -writel(OMAP_ULPI_ACCESS, ulpi_vp->viewport_addr);
>> -
>> -err = ulpi_wait(ulpi_vp, OMAP_ULPI_ACCESS);
>> -if (err)
>> -debug("ULPI wakeup timed out\n");
>> -
>> -return err;
>> -}
>> -
>> -/*
>>   * Issue a ULPI read/write request
>>   */
>>  static int ulpi_request(struct ulpi_viewport *ulpi_vp, u32 value)
>>  {
>>  int err;
>>  
>> -err = ulpi_wakeup(ulpi_vp);
>> -if (err)
>> -return err;
>> -
>>  writel(value, ulpi_vp->viewport_addr);
>>  
>> -err = ulpi_wait(ulpi_vp, OMAP_ULPI_ACCESS);
>> +err = ulpi_wait(ulpi_vp, OMAP_ULPI_START);
>>  if (err)
>>  debug("ULPI request timed out\n");
>>  
>> @@ -85,7 +61,7 @@ static int ulpi_request(struct ulpi_viewport *ulpi_vp, u32 
>> value)
>>  
>>  int ulpi_write(struct ulpi_viewport *ulpi_vp, u8 *reg, u32 value)
>>  {
>> -u32 val = ((ulpi_vp->port_num & 0xf) << 24) |
>> +u32 val = (OMAP_ULPI_START | (ulpi_vp->port_num & 0xf) << 24) |
>>  OMAP_ULPI_WR_OPSEL | ((u32)reg << 16) | (value & 0xff);
>>  
>>  return ulpi_request(ulpi_vp, val);
>> @@ -95,7 +71,7 @@ u32 ulpi_read(struct ulpi_viewport *ulpi_vp, u8 *reg)
>>  {
>>  int err;
>>  u32 val = ((ulpi_vp->port_num & 0xf) << 24) |
>> - OMAP_ULPI_WR_OPSEL | ((u32)reg << 16);
>> + OMAP_ULPI_RD_OPSEL | ((u32)reg << 16);
>>  
>>  err = ulpi_request(ulpi_vp, val);
>>  if (err)
>>
> 


-- 
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO  -  Founder  Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |


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

Re: [U-Boot] [PATCH 0/2 V2] EXYNOS5: Enable Gigabyte device GD25LQ and GD25Q64B

2013-05-20 Thread Minkyu Kang

Dear Rajeshwari,

On 28/03/13 01:42, Simon Glass wrote:
> Hi Minkyu,
> 
> 
> On Tue, Mar 26, 2013 at 11:38 PM, Minkyu Kang  > wrote:
> 
> Dear Rajeshwari and Simon,
> 
> On 12/03/13 15:13, Rajeshwari Birje wrote:
> > Hi Minkyu,
> >
> > Yes it is based on the following patches submitted by Simon Glass and
> > link for the same.
> >
> > "sf: Add spi_flash_alloc() to create a new SPI flash struct"
> > http://patchwork.ozlabs.org/patch/208228/
> >
> > "sf: Use spi_flash_alloc() in each SPI flash driver":
> >  http://patchwork.ozlabs.org/patch/226582/
> >
> 
> Those patches are merged?
> 
> 
> Yes they are in mainline now.
> 
> Regards,
> Simon
> 

applied to u-boot-samsung.

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

Re: [U-Boot] [PATCH v02 1/2] OMAP3+: introduce generic ABB support

2013-05-20 Thread Andrii Tseglytskyi


Hi,

Thank you for review.

On 05/17/2013 04:11 PM, Nishanth Menon wrote:

[snip]

On 19:49-20130513, Andrii Tseglytskyi wrote:
[...]

+   if (fuse && ldovbb) {
+   if (abb_setup_ldovbb(fuse, ldovbb))
+   return;
+   }
+
+   /* configure timings, based on oscillator value */
+   abb_setup_timings(setup);

Still missing txdone clear..
If txdone was set on entry, you'd escape a bit waiting for transition
completion bit in SR2, However, by clearing TXDONE here, you can just wait
for TXDONE.


We touch ABB first time here. I can add check/clear txdone here to 
double check that everything is fine,

but this may be superfluous.


+
+   /* select ABB type */
+   clrsetbits_le32(setup,
+   abb_type_mask | OMAP_ABB_SETUP_SR2EN_MASK,
+   abb_type_mask | OMAP_ABB_SETUP_SR2EN_MASK);

This is no better than set_bits! clearbits (addr, clr, set) -> the clr
bits should clear *all* bits of the field. in this example ABB_TYPE
should both be cleared, same in OPP_SEL.
See the following change on top of this series:

Yep. should be:

clrsetbits_le32(setup,
OMAP_ABB_SETUP_ACTIVE_FBB_SEL_MASK 
|OMAP_ABB_SETUP_ACTIVE_RBB_SEL_MASK | OMAP_ABB_SETUP_SR2EN_MASK,

   abb_type_mask | OMAP_ABB_SETUP_SR2EN_MASK)

But I propose to rework this in the following way:
- at the beginning of setup function clear both ABB registers (setup and 
control),

writel(0, setup);
writel(0, control);

- use setbits_le32 everywhere.

This guarantees that there will be no trash values in ABB registers and 
increases code readability.

Your opinion?


diff --git a/arch/arm/cpu/armv7/omap-common/abb.c 
b/arch/arm/cpu/armv7/omap-common/abb.c
index 73eadb2..31332fb 100644
--- a/arch/arm/cpu/armv7/omap-common/abb.c
+++ b/arch/arm/cpu/armv7/omap-common/abb.c
@@ -115,14 +115,22 @@ void abb_setup(u32 fuse, u32 ldovbb, u32 setup, u32 
control,
/* configure timings, based on oscillator value */
abb_setup_timings(setup);
  
+	/*

+* Clear any pending ABB tranxdones before we wait for txdone.
+* We do not know the mode in which we have been handed over
+* the system (warm/cold reboot), ROM code operations etc..
+* on a cold boot, we do not expect to see this set.
+*/
+   setbits_le32(txdone, OMAP_ABB_MPU_TXDONE_MASK);
+
/* select ABB type */
-   clrsetbits_le32(setup,
-   abb_type_mask | OMAP_ABB_SETUP_SR2EN_MASK,
+   clrsetbits_le32(setup, OMAP_ABB_SETUP_ABB_SEL_MASK |
+   OMAP_ABB_SETUP_SR2EN_MASK,
abb_type_mask | OMAP_ABB_SETUP_SR2EN_MASK);
  
  	/* initiate ABB ldo change */

-   clrsetbits_le32(control,
-   opp_sel_mask | OMAP_ABB_CONTROL_OPP_CHANGE_MASK,
+   clrsetbits_le32(control, OMAP_ABB_CONTROL_OPP_SEL_MASK |
+   OMAP_ABB_CONTROL_OPP_CHANGE_MASK,
opp_sel_mask | OMAP_ABB_CONTROL_OPP_CHANGE_MASK);
  
  	/* wait until transition complete */

diff --git a/arch/arm/include/asm/omap_common.h 
b/arch/arm/include/asm/omap_common.h
index 4892c0a..c2fc180 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -565,13 +565,17 @@ s8 abb_setup_ldovbb(u32 fuse, u32 ldovbb);
  #define OMAP_ABB_NOMINAL_OPP  0
  #define OMAP_ABB_FAST_OPP 1
  #define OMAP_ABB_SLOW_OPP 3
+#define OMAP_ABB_CONTROL_OPP_SEL_MASK  (0x3 << 0)
  #define OMAP_ABB_CONTROL_FAST_OPP_SEL_MASK(0x1 << 0)
-#define OMAP_ABB_CONTROL_SLOW_OPP_SEL_MASK (0x1 << 1)
+#define OMAP_ABB_CONTROL_SLOW_OPP_SEL_MASK (0x3 << 0)
+#define OMAP_ABB_CONTROL_NOMINAL_OPP_SEL_MASK  (0x0 << 0)
  #define OMAP_ABB_CONTROL_OPP_CHANGE_MASK  (0x1 << 2)
  #define OMAP_ABB_CONTROL_SR2_IN_TRANSITION_MASK   (0x1 << 6)
  #define OMAP_ABB_SETUP_SR2EN_MASK (0x1 << 0)
  #define OMAP_ABB_SETUP_ACTIVE_FBB_SEL_MASK(0x1 << 2)
  #define OMAP_ABB_SETUP_ACTIVE_RBB_SEL_MASK(0x1 << 1)
+#define OMAP_ABB_SETUP_ABB_SEL_MASK
(OMAP_ABB_SETUP_ACTIVE_RBB_SEL_MASK | \
+
OMAP_ABB_SETUP_ACTIVE_FBB_SEL_MASK)
  #define OMAP_ABB_SETUP_SR2_WTCNT_VALUE_MASK   (0xff << 8)
  
  static inline u32 omap_revision(void)



+
+   /* initiate ABB ldo change */
+   clrsetbits_le32(control,
+   opp_sel_mask | OMAP_ABB_CONTROL_OPP_CHANGE_MASK,
+   opp_sel_mask | OMAP_ABB_CONTROL_OPP_CHANGE_MASK);
+
+   /* wait until transition complete */
+   if (!wait_on_value(OMAP_ABB_CONTROL_SR2_IN_TRANSITION_MASK, 0,
+  (void *)control, LDELAY))
+   puts("Error: ABB is in transition\n");

superfluous if you wait for txdone.


Agree. Can be removed.

[snip]

+   /* setup LD

[U-Boot] [U-boot]: MMC: add sdhci generic framework

2013-05-20 Thread Jagannadha Sutradharudu Teki

Hi,

On..  drivers/mmc/sdhci.c
+   if (caps & SDHCI_CAN_DO_8BIT)
+   mmc->host_caps |= MMC_MODE_8BIT;

Here we are setting 8BIT bus width, if the sdhci capabilities register 18 bit 
is set.
Does 18-bit is really denoted for 8-bit bus width, I cound't find it on spec,  
https://www.sdcard.org/developers/overview/host_controller/simple_spec/Simplified_SD_Host_Controller_Spec.pdf

Due to this above error even my controller doesn't support 8-bit, it shows a 
8-BIT supported.

Request your help, correct me I am wrong.

Thanks,
Jagan.



This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.


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

Re: [U-Boot] [PATCH v02 1/2] OMAP3+: introduce generic ABB support

2013-05-20 Thread Nishanth Menon

On Mon, May 20, 2013 at 6:06 AM, Andrii Tseglytskyi
 wrote:
> On 05/17/2013 04:11 PM, Nishanth Menon wrote:
>
> [snip]
>>
>> On 19:49-20130513, Andrii Tseglytskyi wrote:
>> [...]
>>>
>>> +   if (fuse && ldovbb) {
>>> +   if (abb_setup_ldovbb(fuse, ldovbb))
>>> +   return;
>>> +   }
>>> +
>>> +   /* configure timings, based on oscillator value */
>>> +   abb_setup_timings(setup);
>>
>> Still missing txdone clear..
>> If txdone was set on entry, you'd escape a bit waiting for transition
>> completion bit in SR2, However, by clearing TXDONE here, you can just wait
>> for TXDONE.
>
>
> We touch ABB first time here. I can add check/clear txdone here to double
> check that everything is fine,
> but this may be superfluous.

PRM register may be reset OR not depending on type of reset and SoC,
Though this might be the first line of code to execute in bootloader
that touches this register, there is no guarentee that there is no
pending TRANXDONE interrupt in the register. if there is TRANXDONE
interrupt, it is not something we desire. Hence the suggestion to
clear.

>>> +
>>> +   /* select ABB type */
>>> +   clrsetbits_le32(setup,
>>> +   abb_type_mask | OMAP_ABB_SETUP_SR2EN_MASK,
>>> +   abb_type_mask | OMAP_ABB_SETUP_SR2EN_MASK);
>>
>> This is no better than set_bits! clearbits (addr, clr, set) -> the clr
>> bits should clear *all* bits of the field. in this example ABB_TYPE
>> should both be cleared, same in OPP_SEL.
>> See the following change on top of this series:
>
> Yep. should be:
>
> clrsetbits_le32(setup,
> OMAP_ABB_SETUP_ACTIVE_FBB_SEL_MASK
> |OMAP_ABB_SETUP_ACTIVE_RBB_SEL_MASK | OMAP_ABB_SETUP_SR2EN_MASK,
>abb_type_mask | OMAP_ABB_SETUP_SR2EN_MASK)
>
> But I propose to rework this in the following way:
> - at the beginning of setup function clear both ABB registers (setup and
> control),
> writel(0, setup);
> writel(0, control);
>
> - use setbits_le32 everywhere.
>
> This guarantees that there will be no trash values in ABB registers and
> increases code readability.
> Your opinion?
>
Case 1) if we have been given control by another bootloader which had
already setup ABB, writing 0 will not impact the current setting as
the transition trigger is OPP_CHANGE
case 2) we are the only bootloader in the system. writing 0 is ok as well.

So, am ok if you reset the registers prior to programming them.
--
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 0/4] Factorize ARM relocate_code instances

2013-05-20 Thread Benoît Thébaudeau

Hi Fabio, Stefano,

On Monday, May 20, 2013 11:26:10 AM, Albert ARIBAUD wrote:
> Hi Benoît,
> 
> On Sun, 19 May 2013 17:57:59 +0200 (CEST), Benoît Thébaudeau
>  wrote:
> 
> > Hi Albert,
> > 
> > On Sunday, May 19, 2013 1:48:11 PM, Albert ARIBAUD wrote:
> > > This series replaces all instances of relocate_code in
> > > various start.S files from the ARM architecture with a
> > > single instance in arch/arm/lib/relocate.S.
> > > 
> > > This is done in steps, each step keeping the whole of ARM
> > > U-Boot buildable and runnable and touching as little code
> > > as necessary.
> > > 
> > > 1. Drop mx31pdk SPL call to relocate_code
> > > 
> > > In SPL of mx31pdk, board_init_f calls relocate_code to
> > > move SPL from the NAND read buffer to SRAM. This move
> > > is not a relocation and is thus better implemented as
> > > a simple ad hoc copy loop.
> > > 
> > > 2. Drop tx25 SPL call to relocate_code
> > > 
> > > Same as mx31pdk.
> > > 
> > > 3. Prevent all SPLs from assembling relocate_code
> > > 
> > > Now that no SPL uses relocate_code any more, remove
> > > it completely from SPL builds by putting it entirely
> > > between #ifndef CONFIG_SPL_BUILD and #endif preprocessor
> > > conditional.
> > > 
> > > 4. Actual factorization of relocate_code
> > > 
> > > Remove all instances of relocate_code from start.S and
> > > create a new file, arch/arm/lib/relocate.S, to provide
> > > the new single instance of relocate_code.
> > > 
> > > The only non-trivial change is that for PXA25X, a call
> > > to unlock (actually disable) dcache is moved from before
> > > relocating to after relocating. As this cache is either
> > > locked-as-RAM or disabled, but never used as actual DDR
> > > cache, this move has no performance effect on relocation
> > > and no functional impact either.
> > > 
> > > The relocation routine was step-tested on versatileqemu
> > > under gdb. Especially, both relocation offset (from
> > > _start to addr_moni and local offsets (from relocate_code
> > > to several linker script symbols) have been verified.
> > > 
> > > Changes in v4:
> > > - added blank line after PXA25X conditional code
> > > - fixed typos in relocate_code comments
> > > - brought back 'mov pc,lr' instead of 'bx lr' for ARMv4
> > 
> > [...]
> > 
> > Perfect!
> > 
> > For this v4 series:
> > Reviewed-by: Benoît Thébaudeau 
> 
> Thanks Benoît!
> 
> Now I need some people to regression-test it on their
> HW, both ARM and non-ARM just in case.

Can you test this series on mx31pdk (directly changed by this series), and some
other i.MX EVK (e.g. ARMv7, so mx51evk or mx53*) board please? That should be
enough for ARM.

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

[U-Boot] [PATCH 1/2] common: Add CCACHE variable to allow use of ccache

2013-05-20 Thread Marek Vasut

Prefix HOSTCC and CC with CCACHE variable to allow easy use of ccache.
In case the user wants to use ccache, exporting CCACHE=ccache will do
the trick. It is of course possible to either make the cross-compiler
name into a shellscript which invokes the ccache and the compiler, but
setting this variable makes use of ccache easier and more convenient.

Using ccache becomes convenient when using MAKEALL for large build
tests, where the speedup after building the cache for the first time
is about 4-6 times.

Signed-off-by: Marek Vasut 
Cc: Tom Rini 
---
 config.mk |8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/config.mk b/config.mk
index 1fd109f..d59ded2 100644
--- a/config.mk
+++ b/config.mk
@@ -98,6 +98,8 @@ else
 HOSTCC = gcc
 endif
 
+HOSTCC := $(CCACHE) $(HOSTCC)
+
 ifeq ($(HOSTOS),cygwin)
 HOSTCFLAGS += -ansi
 endif
@@ -140,13 +142,13 @@ binutils-version = $(shell $(SHELL) 
$(SRCTREE)/tools/binutils-version.sh $(AS))
 #
 # Include the make variables (CC, etc...)
 #
-AS = $(CROSS_COMPILE)as
+AS = $(CCACHE) $(CROSS_COMPILE)as
 
 # Always use GNU ld
 LD = $(shell if $(CROSS_COMPILE)ld.bfd -v > /dev/null 2>&1; \
then echo "$(CROSS_COMPILE)ld.bfd"; else echo 
"$(CROSS_COMPILE)ld"; fi;)
 
-CC = $(CROSS_COMPILE)gcc
+CC = $(CCACHE) $(CROSS_COMPILE)gcc
 CPP= $(CC) -E
 AR = $(CROSS_COMPILE)ar
 NM = $(CROSS_COMPILE)nm
@@ -320,7 +322,7 @@ endif
 
 #
 
-export HOSTCC HOSTCFLAGS HOSTLDFLAGS PEDCFLAGS HOSTSTRIP CROSS_COMPILE \
+export HOSTCC HOSTCFLAGS HOSTLDFLAGS PEDCFLAGS HOSTSTRIP CROSS_COMPILE CCACHE \
AS LD CC CPP AR NM STRIP OBJCOPY OBJDUMP MAKE
 export CONFIG_SYS_TEXT_BASE PLATFORM_CPPFLAGS PLATFORM_RELFLAGS CPPFLAGS 
CFLAGS AFLAGS
 
-- 
1.7.10.4

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

[U-Boot] [PATCH 2/2] common: Use separate dirs for each board for ccache

2013-05-20 Thread Marek Vasut

When using ccache in MAKEALL, use separate directory for the cache
for each board. This way we can avoid rewriting the same files by
building other boards.

Signed-off-by: Marek Vasut 
Cc: Tom Rini 
---
 MAKEALL |7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAKEALL b/MAKEALL
index 2737eab..b945007 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -673,6 +673,13 @@ build_target() {
MAKE=make
fi
 
+   # Use per-board CCACHE directory
+   if [ "x${CCACHE}" != "x" ] ; then
+   export CCACHE_DIR="`${CCACHE} -s | grep "^cache directory" | \
+   tr -s " " | cut -d " " -f 3`/u-boot/${target}" ;
+   mkdir -p "${CCACHE_DIR}"
+   fi
+
${MAKE} distclean >/dev/null
${MAKE} -s ${target}_config
 
-- 
1.7.10.4

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

[U-Boot] [PATCH 0/2] Add ccache support

2013-05-20 Thread Marek Vasut

These two patches make it easy to use ccache with U-Boot to speed up
iterative builds.

The results of building SoC MXS without ccache:
real1m29.286s
user7m1.972s
sys 0m46.668s

The results of building SoC MXS with ccache for the first time:
real1m37.551s
user7m23.632s
sys 0m59.332s

The results of building SoC MXS with ccache again:
real0m41.968s
user1m9.912s
sys 0m20.028s

The speedup is significant.

Marek Vasut (2):
  common: Add CCACHE variable to allow use of ccache
  common: Use separate dirs for each board for ccache

 MAKEALL   |7 +++
 config.mk |8 +---
 2 files changed, 12 insertions(+), 3 deletions(-)

-- 
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 2/2] common: Use separate dirs for each board for ccache

2013-05-20 Thread Marek Vasut

Dear Marek Vasut,

> When using ccache in MAKEALL, use separate directory for the cache
> for each board. This way we can avoid rewriting the same files by
> building other boards.
> 
> Signed-off-by: Marek Vasut 
> Cc: Tom Rini 

This one will need more work, sorry.

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] common/Makefile: Add new symbol CONFIG_SPL_ENV_SUPPORT for environment in SPL

2013-05-20 Thread Scott Wood


On 05/17/2013 07:58:15 PM, Zhang Ying-B40530 wrote:



From: Wood Scott-B07421
Sent: Friday, May 17, 2013 10:41 PM
To: Zhang Ying-B40530
Cc: u-boot@lists.denx.de; aflem...@gmail.com; Xie Xiaobo-R63061;  
Zhang Ying-B40530
Subject: Re: [PATCH] common/Makefile: Add new symbol  
CONFIG_SPL_ENV_SUPPORT for environment in SPL


On 05/16/2013 10:05:17 PM, ying.zh...@freescale.com wrote:
> diff --git a/common/Makefile b/common/Makefile
> index f50bf2e..26b8495 100644
> --- a/common/Makefile
> +++ b/common/Makefile
> @@ -44,13 +44,11 @@ COBJS-$(CONFIG_SYS_GENERIC_BOARD) += board_r.o
>  COBJS-y += cmd_boot.o
>  COBJS-$(CONFIG_CMD_BOOTM) += cmd_bootm.o
>  COBJS-y += cmd_help.o
> -COBJS-y += cmd_nvedit.o
>  COBJS-y += cmd_version.o
>
>  # environment
>  COBJS-y += env_attr.o
>  COBJS-y += env_callback.o
> -COBJS-y += env_common.o
>  COBJS-y += env_flags.o
>  COBJS-$(CONFIG_ENV_IS_IN_DATAFLASH) += env_dataflash.o
>  COBJS-$(CONFIG_ENV_IS_IN_EEPROM) += env_eeprom.o
> @@ -215,18 +213,27 @@ COBJS-$(CONFIG_CMD_GPT) += cmd_gpt.o
>  endif
>
>  ifdef CONFIG_SPL_BUILD
> -COBJS-y += cmd_nvedit.o
> -COBJS-y += env_common.o
>  COBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_flash.o
>  COBJS-$(CONFIG_SPL_YMODEM_SUPPORT) += xyzModem.o
> -COBJS-$(CONFIG_SPL_NET_SUPPORT) += cmd_nvedit.o
> -COBJS-$(CONFIG_SPL_NET_SUPPORT) += env_attr.o
> -COBJS-$(CONFIG_SPL_NET_SUPPORT) += env_callback.o
> -COBJS-$(CONFIG_SPL_NET_SUPPORT) += env_common.o
> -COBJS-$(CONFIG_SPL_NET_SUPPORT) += env_flags.o
> -COBJS-$(CONFIG_SPL_NET_SUPPORT) += env_nowhere.o
>  COBJS-$(CONFIG_SPL_NET_SUPPORT) += miiphyutil.o
> +# environment
> +COBJS-$(CONFIG_SPL_ENV_SUPPORT) += env_attr.o
> +COBJS-$(CONFIG_SPL_ENV_SUPPORT) += env_flags.o
> +COBJS-$(CONFIG_SPL_ENV_SUPPORT) += env_callback.o
> +ifneq ($(CONFIG_SPL_NET_SUPPORT),y)
> +COBJS-$(CONFIG_ENV_IS_NOWHERE) += env_nowhere.o
> +COBJS-$(CONFIG_ENV_IS_IN_MMC) += env_mmc.o
> +COBJS-$(CONFIG_ENV_IS_IN_NAND) += env_nand.o
> +COBJS-$(CONFIG_ENV_IS_IN_SPI_FLASH) += env_sf.o
> +COBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_flash.o
> +else
> +COBJS-y += env_nowhere.o
> +endif

Why do you include these files only if we *don't* have net support?
[Zhang Ying]
This because CONFIG_SPL_NET_SUPPORT is conflict with  SPL ENV. This  
is comments from Tom .


I'm not that familiar with CONFIG_SPL_NET_SUPPORT, but it looks like it  
just enables the net/ directory in an SPL.  How does that conflict with  
env stuff?  Perhaps there's some other symbol that better describes the  
actual conflict.


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

[U-Boot] [PATCH] tools/fw_env: use fsync to ensure that data is physically stored

2013-05-20 Thread Michael Heimpold

Closing a file descriptor does not guarantee that the data has been
successfully saved to disk, as the kernel might defer the write.

Signed-off-by: Michael Heimpold 
---
 tools/env/fw_env.c |   12 
 1 file changed, 12 insertions(+)

diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c
index 428e374..0420495 100644
--- a/tools/env/fw_env.c
+++ b/tools/env/fw_env.c
@@ -1033,7 +1033,19 @@ static int flash_io (int mode)
 
rc = flash_write (fd_current, fd_target, dev_target);
 
+   if (fsync (fd_current)) {
+   fprintf (stderr,
+"fsync failed on %s: %s\n",
+DEVNAME (dev_current), strerror (errno));
+   }
+
if (HaveRedundEnv) {
+   if (fsync (fd_target)) {
+   fprintf (stderr,
+"fsync failed on %s: %s\n",
+DEVNAME (dev_current), strerror 
(errno));
+   }
+
if (close (fd_target)) {
fprintf (stderr,
"I/O error on %s: %s\n",
-- 
1.7.10.4

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

[U-Boot] [PATCH v2] arm: pxa: Add support for ICP DAS LP-8x4x

2013-05-20 Thread Sergey Yanovich

LP-8x4x is a programmable automation controller by ICP DAS. It is
shipped with outdated U-Boot v1.3.0

This patch adds enough supports to boot the board:
 - 128M of 128M SDRAM
 - 32M of 48M NOR Flash memory
 - 1 of 4 Serial consoles (PXA FFUART)
 - 2 of 2 Ethernet controllers (DM9000)

Signed-off-by: Sergey Yanovich 
Series-to: u-boot
Series-cc: marex

---
Changes for v2:
   - use get_ram_size(...) to init ram size
   - fix defines
   - fix formatting
   - fix board GPIO settings
   - initialize eth1 MAC for kernel
   - use proper CONFIG_MACH_TYPE to init r1 in kernel call
   - use proper image format in default boot cmd

 MAINTAINERS  |4 +
 board/icpdas/lp8x4x/Makefile |   41 +++
 board/icpdas/lp8x4x/lp8x4x.c |  147 
 boards.cfg   |1 +
 include/configs/lp8x4x.h |  262 ++
 5 files changed, 455 insertions(+)
 create mode 100644 board/icpdas/lp8x4x/Makefile
 create mode 100644 board/icpdas/lp8x4x/lp8x4x.c
 create mode 100644 include/configs/lp8x4x.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 643a5ac..c696700 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1052,6 +1052,10 @@ Eric Nelson 
nitrogen6s  i.MX6S  512MB
nitrogen6s1gi.MX6S  1GB
 
+Sergey Yanovich 
+
+   lp8x4x  xscale/pxa
+
 -
 
 Unknown / orphaned boards:
diff --git a/board/icpdas/lp8x4x/Makefile b/board/icpdas/lp8x4x/Makefile
new file mode 100644
index 000..cbe6aa9
--- /dev/null
+++ b/board/icpdas/lp8x4x/Makefile
@@ -0,0 +1,41 @@
+#
+# ICPDAS LP-8x4x Support
+#
+# Copyright (C) 2013 Sergey Yanovich 
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS  := lp8x4x.o
+
+SRCS   := $(COBJS:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS))
+
+$(LIB):$(obj).depend $(OBJS)
+   $(call cmd_link_o_target, $(OBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/icpdas/lp8x4x/lp8x4x.c b/board/icpdas/lp8x4x/lp8x4x.c
new file mode 100644
index 000..76f0700
--- /dev/null
+++ b/board/icpdas/lp8x4x/lp8x4x.c
@@ -0,0 +1,147 @@
+/*
+ * ICP DAS LP-8x4x Support
+ *
+ * Copyright (C) 2010 Marek Vasut 
+ * adapted from Voipac PXA270 Support by
+ * Copyright (C) 2013 Sergey Yanovich 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/*
+ * Miscelaneous platform dependent initialisations
+ */
+int board_init(void)
+{
+   /* We have RAM, disable cache */
+   dcache_disable();
+   icache_disable();
+
+   /* memory and cpu-speed are setup before relocation */
+   /* so we do _nothing_ here */
+
+   /* adress of boot parameters */
+   gd->bd->bi_boot_params = 0xa100;
+
+   return 0;
+}
+
+int dram_init(void)
+{
+   pxa2xx_dram_init();
+   gd->ram_size = get_ram_size((long *)PHYS_SDRAM_1, PHYS_SDRAM_1_SIZE);
+   return 0;
+}
+
+void dram_init_banksize(void)
+{
+   gd->bd->bi_dram[0].start = PHYS_SDRAM_1;
+   gd->bd->bi_dram[0].size = PHYS_SDRAM_1_SIZE;
+}
+
+#ifdef CONFIG_CMD_MMC
+int board_mmc_init(bd_t *bis)
+{
+   pxa_mmc_register(0);
+   return 0;
+}
+#endif
+
+#ifdef CONFIG_CMD_USB
+int usb_board_init(void)
+{
+   writel((UHC

[U-Boot] [PATCH] arm: pxa: config option for PXA270 turbo mode

2013-05-20 Thread Sergey Yanovich

PXA270 CPU has turbo mode. The mode is 2.5 times faster than the
default run mode. Activating the mode early significantly speeds
up boot process.

Signed-off-by: Sergey Yanovich 
---
 arch/arm/cpu/pxa/pxa2xx.c |7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm/cpu/pxa/pxa2xx.c b/arch/arm/cpu/pxa/pxa2xx.c
index 09e8177..6c918ac 100644
--- a/arch/arm/cpu/pxa/pxa2xx.c
+++ b/arch/arm/cpu/pxa/pxa2xx.c
@@ -32,6 +32,10 @@
 #include 
 #include 
 
+#ifndef CONFIG_SYS_CLKCFG
+#define CONFIG_SYS_CLKCFG  0x0002
+#endif
+
 /* Flush I/D-cache */
 static void cache_flush(void)
 {
@@ -244,7 +248,8 @@ void pxa_clock_setup(void)
 {
writel(CONFIG_SYS_CKEN, CKEN);
writel(CONFIG_SYS_CCCR, CCCR);
-   asm volatile("mcr   p14, 0, %0, c6, c0, 0" : : "r"(2));
+   asm volatile("mcr   p14, 0, %0, c6, c0, 0" : :
+   "r"(CONFIG_SYS_CLKCFG));
 
/* enable the 32Khz oscillator for RTC and PowerManager */
writel(OSCC_OON, OSCC);
-- 
1.7.10.4

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

[U-Boot] [PATCH] arm: pxa: PXA270 D-Cache as ram

2013-05-20 Thread Sergey Yanovich

2.2.5.2 of Marvell PXA27x Processor Family Developers Manual says:
"The PXA27x processor cache configuration is identical to that of
the PXA255 processor."

As a result, it is perfectly legitimate to use PXA25X
'lock_cache_for_stack' on PXA27X as well.

Signed-off-by: Sergey Yanovich 
---
 arch/arm/cpu/pxa/start.S |   10 --
 include/configs/lp8x4x.h |5 +++--
 2 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/arch/arm/cpu/pxa/start.S b/arch/arm/cpu/pxa/start.S
index ada91a6..5ea512e 100644
--- a/arch/arm/cpu/pxa/start.S
+++ b/arch/arm/cpu/pxa/start.S
@@ -40,6 +40,12 @@
 #include 
 
 #ifdef CONFIG_CPU_PXA25X
+#ifndef CONFIG_PXA2XX_CACHE_AS_RAM
+#define CONFIG_PXA2XX_CACHE_AS_RAM
+#endif
+#endif
+
+#ifdef CONFIG_PXA2XX_CACHE_AS_RAM
 #if ((CONFIG_SYS_INIT_SP_ADDR) != 0xf800)
 #error "Init SP address must be set to 0xf800 for PXA250"
 #endif
@@ -164,7 +170,7 @@ reset:
bl  cpu_init_crit
 #endif
 
-#ifdef CONFIG_CPU_PXA25X
+#ifdef CONFIG_PXA2XX_CACHE_AS_RAM
bl  lock_cache_for_stack
 #endif
 
@@ -482,7 +488,7 @@ fiq:
  * This is useful on PXA25x and PXA26x in early bootstages, where there is no
  * other possible memory available to hold stack.
  */
-#ifdef CONFIG_CPU_PXA25X
+#ifdef CONFIG_PXA2XX_CACHE_AS_RAM
 .macro CPWAIT reg
mrc p15, 0, \reg, c2, c0, 0
mov \reg, \reg
diff --git a/include/configs/lp8x4x.h b/include/configs/lp8x4x.h
index 026f321..27ff2f4 100644
--- a/include/configs/lp8x4x.h
+++ b/include/configs/lp8x4x.h
@@ -149,8 +149,9 @@
 
 #defineCONFIG_SYS_LOAD_ADDR0xa0008000
 #define CONFIG_SYS_SDRAM_BASE  PHYS_SDRAM_1
-/* Use first 64kb bank of the internal SRAM */
-#defineCONFIG_SYS_INIT_SP_ADDR 0x5c01
+/* Use CPU data cache as internal RAM */
+#define CONFIG_PXA2XX_CACHE_AS_RAM
+#defineCONFIG_SYS_INIT_SP_ADDR 0xf800
 
 /*
  * NOR FLASH
-- 
1.7.10.4

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

Re: [U-Boot] [U-boot]: MMC: add sdhci generic framework

2013-05-20 Thread Rommel Custodio


Jagannadha Sutradharudu Teki  xilinx.com> 
writes:

> 
> Hi,
> 
> On..  drivers/mmc/sdhci.c
> +   if (caps & SDHCI_CAN_DO_8BIT)
> +   mmc->host_caps |= MMC_MODE_8BIT;
> 
> Here we are setting 8BIT bus width, if the sdhci capabilities register 18 
bit is set.
> Does 18-bit is really denoted for 8-bit bus width, I cound't find it on 
spec,  
https://www.sdcard.org/developers/overview/host_controller/simple_spec/Simpl
ified_SD_Host_Controller_Spec.pdf

Dear Jagannadha Sutradharudu Teki,

The current u-boot SD/MMC driver supports the latest SD Specification.
You should read version 3.0 of the specification.

> 
> Due to this above error even my controller doesn't support 8-bit, it shows 
a 8-BIT supported.
> 
> Request your help, correct me I am wrong.
> 
> Thanks,
> Jagan.

All the best,
Rommel


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

Re: [U-Boot] [PATCH] common/Makefile: Add new symbol CONFIG_SPL_ENV_SUPPORT for environment in SPL

2013-05-20 Thread Zhang Ying-B40530





-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, May 21, 2013 2:56 AM
To: Zhang Ying-B40530
Cc: Wood Scott-B07421; u-boot@lists.denx.de; aflem...@gmail.com; Xie 
Xiaobo-R63061; Tom Rini
Subject: Re: [PATCH] common/Makefile: Add new symbol CONFIG_SPL_ENV_SUPPORT for 
environment in SPL



On 05/17/2013 07:58:15 PM, Zhang Ying-B40530 wrote:

>

> 

> From: Wood Scott-B07421

> Sent: Friday, May 17, 2013 10:41 PM

> To: Zhang Ying-B40530

> Cc: u-boot@lists.denx.de; 
> aflem...@gmail.com; Xie Xiaobo-R63061;

> Zhang Ying-B40530

> Subject: Re: [PATCH] common/Makefile: Add new symbol

> CONFIG_SPL_ENV_SUPPORT for environment in SPL

>

> On 05/16/2013 10:05:17 PM, 
> ying.zh...@freescale.com wrote:

> > diff --git a/common/Makefile b/common/Makefile

> > index f50bf2e..26b8495 100644

> > --- a/common/Makefile

> > +++ b/common/Makefile

> > @@ -44,13 +44,11 @@ COBJS-$(CONFIG_SYS_GENERIC_BOARD) += board_r.o

> >  COBJS-y += cmd_boot.o

> >  COBJS-$(CONFIG_CMD_BOOTM) += cmd_bootm.o

> >  COBJS-y += cmd_help.o

> > -COBJS-y += cmd_nvedit.o

> >  COBJS-y += cmd_version.o

> >

> >  # environment

> >  COBJS-y += env_attr.o

> >  COBJS-y += env_callback.o

> > -COBJS-y += env_common.o

> >  COBJS-y += env_flags.o

> >  COBJS-$(CONFIG_ENV_IS_IN_DATAFLASH) += env_dataflash.o

> >  COBJS-$(CONFIG_ENV_IS_IN_EEPROM) += env_eeprom.o

> > @@ -215,18 +213,27 @@ COBJS-$(CONFIG_CMD_GPT) += cmd_gpt.o

> >  endif

> >

> >  ifdef CONFIG_SPL_BUILD

> > -COBJS-y += cmd_nvedit.o

> > -COBJS-y += env_common.o

> >  COBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_flash.o

> >  COBJS-$(CONFIG_SPL_YMODEM_SUPPORT) += xyzModem.o

> > -COBJS-$(CONFIG_SPL_NET_SUPPORT) += cmd_nvedit.o

> > -COBJS-$(CONFIG_SPL_NET_SUPPORT) += env_attr.o

> > -COBJS-$(CONFIG_SPL_NET_SUPPORT) += env_callback.o

> > -COBJS-$(CONFIG_SPL_NET_SUPPORT) += env_common.o

> > -COBJS-$(CONFIG_SPL_NET_SUPPORT) += env_flags.o

> > -COBJS-$(CONFIG_SPL_NET_SUPPORT) += env_nowhere.o

> >  COBJS-$(CONFIG_SPL_NET_SUPPORT) += miiphyutil.o

> > +# environment

> > +COBJS-$(CONFIG_SPL_ENV_SUPPORT) += env_attr.o

> > +COBJS-$(CONFIG_SPL_ENV_SUPPORT) += env_flags.o

> > +COBJS-$(CONFIG_SPL_ENV_SUPPORT) += env_callback.o

> > +ifneq ($(CONFIG_SPL_NET_SUPPORT),y)

> > +COBJS-$(CONFIG_ENV_IS_NOWHERE) += env_nowhere.o

> > +COBJS-$(CONFIG_ENV_IS_IN_MMC) += env_mmc.o

> > +COBJS-$(CONFIG_ENV_IS_IN_NAND) += env_nand.o

> > +COBJS-$(CONFIG_ENV_IS_IN_SPI_FLASH) += env_sf.o

> > +COBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_flash.o

> > +else

> > +COBJS-y += env_nowhere.o

> > +endif

>

> Why do you include these files only if we *don't* have net support?

> [Zhang Ying]

> This because CONFIG_SPL_NET_SUPPORT is conflict with  SPL ENV. This

> is comments from Tom .



I'm not that familiar with CONFIG_SPL_NET_SUPPORT, but it looks like it

just enables the net/ directory in an SPL.  How does that conflict with

env stuff?  Perhaps there's some other symbol that better describes the

actual conflict.

[Zhang Ying]
This is Tom's words:
a3m071 relies on SPL always building cmd_nvedit.o and env_common.o and 
duplicated CONFIG_ENV_IS_IN_FLASH in the SPL section.
CONFIG_SPL_NET_SUPPORT relies on the same always-built ins and adds 
env_nowhere.o which works because the regular CONFIG_ENV_IS_IN_...
section is in the non-SPL-only area.
Now, your end-goal is to have env from, I assume, NAND, also exist on SPL?  I 
guess for now, lets go ahead and duplicate a few lines of ENV_IS.. inside the 
SPL area and when you add NAND env, add ifneq 
($(CONFIG_SPL_NET_SUPPORT),y)...endif around it and add to the README that 
CONFIG_SPL_NET_SUPPORT conflicts with SPL env from nand.

My understanding is that there are two kinds of methods:

1. In Tom's opinion: add CONFIG_ENV_IS_IN_... inside the SPL area and add ifneq 
($(CONFIG_SPL_NET_SUPPORT),y)...endif around it.

2. Add new SPL env symbol(for example: CONFIG_SPL_ENV_IS_IN_MMC) for the SPL. 
This need to add excessive symbol for SPL env.


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

Re: [U-Boot] [U-boot]: MMC: add sdhci generic framework

2013-05-20 Thread Jagan Teki

Hi Rommel,

Thanks for your information.

On Tue, May 21, 2013 at 4:20 AM, Rommel Custodio
 wrote:
>
> Jagannadha Sutradharudu Teki  xilinx.com>
> writes:
>
>>
>> Hi,
>>
>> On..  drivers/mmc/sdhci.c
>> +   if (caps & SDHCI_CAN_DO_8BIT)
>> +   mmc->host_caps |= MMC_MODE_8BIT;
>>
>> Here we are setting 8BIT bus width, if the sdhci capabilities register 18
> bit is set.
>> Does 18-bit is really denoted for 8-bit bus width, I cound't find it on
> spec,
> https://www.sdcard.org/developers/overview/host_controller/simple_spec/Simpl
> ified_SD_Host_Controller_Spec.pdf
>
> Dear Jagannadha Sutradharudu Teki,
>
> The current u-boot SD/MMC driver supports the latest SD Specification.
> You should read version 3.0 of the specification.

OK, i saw the spec thanks.
I think we need to add the fix on sdhci, for backward compatibility.
Any concerns.

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

[U-Boot] [PATCH V2 OMAP-ULPI]: This patch fix the omap access to the transceiver configuration registers using the ulpi bus.

Re: [U-Boot] [PATCH v4 0/4] Factorize ARM relocate_code instances

Re: [U-Boot] [PATCH V2 OMAP-ULPI]: This patch fix the omap access to the transceiver configuration registers using the ulpi bus.

Re: [U-Boot] [PATCH V2 OMAP-ULPI]: This patch fix the omap access to the transceiver configuration registers using the ulpi bus.

Re: [U-Boot] [PATCH 0/2 V2] EXYNOS5: Enable Gigabyte device GD25LQ and GD25Q64B

Re: [U-Boot] [PATCH v02 1/2] OMAP3+: introduce generic ABB support

[U-Boot] [U-boot]: MMC: add sdhci generic framework

Re: [U-Boot] [PATCH v02 1/2] OMAP3+: introduce generic ABB support

Re: [U-Boot] [PATCH v4 0/4] Factorize ARM relocate_code instances

[U-Boot] [PATCH 1/2] common: Add CCACHE variable to allow use of ccache

[U-Boot] [PATCH 2/2] common: Use separate dirs for each board for ccache

[U-Boot] [PATCH 0/2] Add ccache support

Re: [U-Boot] [PATCH 2/2] common: Use separate dirs for each board for ccache

Re: [U-Boot] [PATCH] common/Makefile: Add new symbol CONFIG_SPL_ENV_SUPPORT for environment in SPL

[U-Boot] [PATCH] tools/fw_env: use fsync to ensure that data is physically stored

[U-Boot] [PATCH v2] arm: pxa: Add support for ICP DAS LP-8x4x

[U-Boot] [PATCH] arm: pxa: config option for PXA270 turbo mode

[U-Boot] [PATCH] arm: pxa: PXA270 D-Cache as ram

Re: [U-Boot] [U-boot]: MMC: add sdhci generic framework

Re: [U-Boot] [PATCH] common/Makefile: Add new symbol CONFIG_SPL_ENV_SUPPORT for environment in SPL

Re: [U-Boot] [U-boot]: MMC: add sdhci generic framework

21 matches

Site Navigation

Mail list logo

Footer information