Re: [U-Boot] [PATCH] tools: gen_eth_addr: remove getpid() operation for the random seed

[Josh Wu]

Hi, Wolfgang, Andreas

Thanks for the testing and point out the wrongness in my patch.

On 9/16/2015 5:15 PM, Wolfgang Denk wrote:

Dear Josh,

In message <55f91588.3040...@atmel.com> you wrote:

In above commands, I have two duplicated eth addr:
92:33:16:3f:0a:56
d2:41:66:54:64:aa

Agreed. Randomness is really poor; for a sequence of 1000 invocations
of gen_eth_addr in a shell loop I would only gt 124 different MAC
addresses:

-> for i in {1..1000} ; do ./gen_eth_addr ; done >/tmp/0
-> sort -u /tmp/0 >/tmp/1 ; wc -l /tmp/[01]
  1000 /tmp/0
   124 /tmp/1

In a second run, even only 41 :-(

But without the getpid() part, it gets even worse - the same loop
would produce only 15 different addresses!


Changing the '|' into a '+' would reliably generate 1000 different MAC
addresses.


I understand your concern. My intention is make it harder to generate
the duplicated result.

I understand this, and agree that we should implement such a fix.


Maybe we can ORing the MSB of time(0)?
I'll investigate it little more.

The following patch appears to work fine for me.  Maybe you can test
it?


yes, this one works well. if you don't mind I want to sent v2 patch, 
which is like:


-srand(time(0) | getpid());
+srand(time(0) + (getpid() << 8));




diff --git a/tools/gen_eth_addr.c b/tools/gen_eth_addr.c
index bf9d935..834163a 100644
--- a/tools/gen_eth_addr.c
+++ b/tools/gen_eth_addr.c
@@ -15,7 +15,7 @@ main(int argc, char *argv[])
  {
  unsigned long ethaddr_low, ethaddr_high;
  
-srand(time(0) | getpid());

+srand(time(0) + getpid());
  
  /*

   * setting the 2nd LSB in the most significant byte of


Thanks.

Best regards,

Wolfgang Denk



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

Re: [U-Boot] [PATCH] tools: gen_eth_addr: remove getpid() operation for the random seed

[Andreas Bießmann]

Hi Josh,

On 09/16/2015 05:18 AM, Josh Wu wrote:
> As 'time(0) | getpid()' sometimes get same value. That depends on the
> value of getpid().
> So that is not a expected behavior. We expect different value for the
> seed when when run it in many times.

I don't think your change made it better. Here is a snippet from a run
of time(NULL) and getpid():

---8<---
time: 1442389450; pid: 11632; time | pid: 1442397690;
time: 1442389450; pid: 11633; time | pid: 1442397691;
time: 1442389450; pid: 11634; time | pid: 1442397690;
time: 1442389450; pid: 11635; time | pid: 1442397691;
time: 1442389450; pid: 11636; time | pid: 1442397694;
time: 1442389450; pid: 11637; time | pid: 1442397695;
time: 1442389450; pid: 11638; time | pid: 1442397694;
time: 1442389450; pid: 11639; time | pid: 1442397695;
time: 1442389450; pid: 11640; time | pid: 1442397690;
time: 1442389450; pid: 11641; time | pid: 1442397691;
time: 1442389450; pid: 11642; time | pid: 1442397690;
time: 1442389450; pid: 11643; time | pid: 1442397691;
--->8---

While time(NULL) is stable, getpid() is incrementing by one. As you may
expect the OR'ed value is oscillating and the values almost the same. So
calling gen_eth_addr three times within the same second you will get two
time the same MAC.

> So this patch remove the getpid(), just use the time(0) as the seed.

So let's see the effect of your change ...

The output of gen_eth_addr at the current ToT:

% RUN=0; while [ $RUN -lt 1 ]; do
/tmp/build-uboot-test/tools/gen_eth_addr; RUN=$(($RUN+1)); done | sort |
uniq | wc -l
254

With your change applied:

% RUN=0; while [ $RUN -lt 1 ]; do
/tmp/build-uboot-test/tools/gen_eth_addr; RUN=$(($RUN+1)); done | sort |
uniq | wc -l
10

Another approach would be to change the algorithm (OR the values) here.
A short test showed that using XOR could be a solution:

---8<---
time: 1442389450; pid: 11632; time ^ pid: 1442394298;
time: 1442389450; pid: 11633; time ^ pid: 1442394299;
time: 1442389450; pid: 11634; time ^ pid: 1442394296;
time: 1442389450; pid: 11635; time ^ pid: 1442394297;
time: 1442389450; pid: 11636; time ^ pid: 1442394302;
time: 1442389450; pid: 11637; time ^ pid: 1442394303;
time: 1442389450; pid: 11638; time ^ pid: 1442394300;
time: 1442389450; pid: 11639; time ^ pid: 1442394301;
time: 1442389450; pid: 11640; time ^ pid: 1442394290;
time: 1442389450; pid: 11641; time ^ pid: 1442394291;
time: 1442389450; pid: 11642; time ^ pid: 1442394288;
time: 1442389450; pid: 11643; time ^ pid: 1442394289;
--->8---

It is the same input but none of the outputs is the same value.

The XOR approach applied to gen_eth_addr:

% RUN=0; while [ $RUN -lt 1 ]; do
/tmp/build-uboot-test/tools/gen_eth_addr; RUN=$(($RUN+1)); done | sort |
uniq | wc -l
9988

Andreas

> Signed-off-by: Josh Wu 
> ---
> 
>  tools/gen_eth_addr.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/gen_eth_addr.c b/tools/gen_eth_addr.c
> index bf9d935..53b023a 100644
> --- a/tools/gen_eth_addr.c
> +++ b/tools/gen_eth_addr.c
> @@ -15,7 +15,7 @@ main(int argc, char *argv[])
>  {
>  unsigned long ethaddr_low, ethaddr_high;
>  
> -srand(time(0) | getpid());
> +srand(time(0));
>  
>  /*
>   * setting the 2nd LSB in the most significant byte of
> 

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

[U-Boot] [PATCH] mmc: sdhci: Fix the SD clock stop sequence

[Wenyou Yang]

According to the SDHC specification, stopping the SD Clock is by setting
the SD Clock Enable bit in the Clock Control register at 0, instead of
setting all bits at 0.

Before stopping the SD clock, we need to make sure all SD transactions
to complete, so add checking the CMD and DAT bits in the Presen State
register, before stopping the SD clock.

Signed-off-by: Wenyou Yang 
---

 drivers/mmc/sdhci.c |   10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index d89e302..f02db4e 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -286,9 +286,15 @@ static int sdhci_send_command(struct mmc *mmc, struct 
mmc_cmd *cmd,
 static int sdhci_set_clock(struct mmc *mmc, unsigned int clock)
 {
struct sdhci_host *host = mmc->priv;
-   unsigned int div, clk, timeout;
+   unsigned int div, clk, timeout, reg;
 
-   sdhci_writew(host, 0, SDHCI_CLOCK_CONTROL);
+   while (sdhci_readl(host, SDHCI_PRESENT_STATE) &
+  (SDHCI_CMD_INHIBIT | SDHCI_DATA_INHIBIT))
+   ;
+
+   reg = sdhci_readw(host, SDHCI_CLOCK_CONTROL);
+   reg &= ~SDHCI_CLOCK_CARD_EN;
+   sdhci_writew(host, reg, SDHCI_CLOCK_CONTROL);
 
if (clock == 0)
return 0;
-- 
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 v2 1/4] dm: tpm: Move tpm_tis_i2c to tpm_i2c_infineon

[Tom Rini]

On Wed, Sep 16, 2015 at 12:33:48AM +0200, Christophe Ricard wrote:

> As there is no TCG specification or recommendation for i2c TPM 1.2,
> move tpm_tis_i2c driver to tpm_i2c_infineon. Other tpm vendors like Atmel
> or STMicroelectronics may have a different transport protocol for i2c.
> 
> Signed-off-by: Christophe Ricard 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH v2] tools: gen_eth_addr: add getpid() to time(0) to avoid duplicated seed

[Wolfgang Denk]

Dear Josh Wu,

In message <1442398864-1312-1-git-send-email-josh...@atmel.com> you wrote:
> As 'time(0) | getpid()' will have a lot of duplicated value. It is not a
> expected behavior. We expect different value for the seed when when run
> it in many times.
> 
> So this patch will left shift the getpid() and add to time(0). That
> avoid duplicated value.
> 
> Test command is like:
>   % RUN=0; while [ $RUN -lt 1 ]; do
>   tools/gen_eth_addr; RUN=$(($RUN+1)); done | sort | uniq | wc -l
>   1
> 
> This patch is incorporated with suggestions made by Wolfgang Denk and Andreas
> Bießmann. Thanks them a lot.
> 
> Signed-off-by: Josh Wu 
> ---
> 
> Changes in v2:
> - left shift and add the getpid() value instead of removing it.
> 
>  tools/gen_eth_addr.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

I ran this version through a total of 80,000 runs ; there were no
duplicated addresses found in this test.

Acked-by: Wolfgang Denk 
Tested-by: Wolfgang Denk 


Thanks!


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"Oh dear, I think you'll find reality's on the blink again."
- Marvin The Paranoid Android
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] kbuild: fixdep: drop meaningless hash table initialization

[Tom Rini]

On Tue, Sep 15, 2015 at 12:54:38PM +0900, Masahiro Yamada wrote:

> The clear_config() is called just once at the beginning of this
> program, but the global variable hashtab[] is already zero-filled
> at the start-up.
> 
> [ Linux commit: d179e22762fd38414c4108acedd5feca4cf7e0d8 ]
> 
> Signed-off-by: Masahiro Yamada 
> Signed-off-by: Michal Marek 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] tools: gen_eth_addr: remove getpid() operation for the random seed

[Wolfgang Denk]

Dear Josh Wu,

In message <1442373526-842-1-git-send-email-josh...@atmel.com> you wrote:
> As 'time(0) | getpid()' sometimes get same value. That depends on the
> value of getpid().

I think removing some "random input" from the way how we compute the
seed is a bad idea.

> So that is not a expected behavior. We expect different value for the
> seed when when run it in many times.

What is your execution environment? In any sane OS it is higly
unlikely that you will see the same or even similar PIDs for
successive runs of the program - each run will start a new process,
which will get a new PID.

[On a mostly idle Linux system (4.1.6 kernel) I see zero dupes in a
set of 30,000 invocations of getpid().]

One can argue if ORing the values is the most clever idea, or if for
example ADDing them would result in more "randomness".  But completely
removing the pid() is bad - any parallel runs of the program on any
machines with synchronized times would predictably result in the same
seeds which is definitely worse behaviour than what we have now.

> So this patch remove the getpid(), just use the time(0) as the seed.

NAK.  This is a bad idea.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
I program, therefore I am.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2 0/4] cm-fx6 updates for Utilite

[Nikita Kiryanov]

On Wed, Sep 16, 2015 at 01:10:45PM +0300, Igor Grinberg wrote:
> Hi Stefano,
> 
> On 09/13/15 11:36, Stefano Babic wrote:
> > 
> > 
> > On 06/09/2015 10:48, Nikita Kiryanov wrote:
> >> This series provides a fix necessary for early models of Utilite, a 
> >> miniature
> >> desktop based on CM-FX6. It implements a dynamic modification to the 
> >> device tree
> >> that is necessary for mmc boot.
> >>
> >> Cc: Stefano Babic 
> >> Cc: Igor Grinberg 
> >>
> >> Changes in V2:
> >>- New patch: compulab: eeprom: propagate error value in read_mac_addr()
> >>- s/BOARD_PRODUCT_NAME_*/PRODUCT_NAME_*
> >>- rewrote cl_eeprom_get_product_name() to take a buffer parameter and
> >>  added documentation
> >>- #define USDHC3_PATH instead of const variable usdhc3_path
> >>- Do not update device tree on eeprom read failures in a more explicit
> >>  way
> >>
> >> Nikita Kiryanov (4):
> >>   compulab: eeprom: select i2c bus when querying for board rev
> >>   compulab: eeprom: propagate error value in read_mac_addr()
> >>   compulab: eeprom: add support for obtaining product name
> >>   arm: mx6: cm-fx6: modify device tree for old revisions of utilite
> >>
> >>  board/compulab/cm_fx6/cm_fx6.c | 22 +-
> >>  board/compulab/cm_t35/cm_t35.c |  2 +-
> >>  board/compulab/common/eeprom.c | 40 
> >> 
> >>  board/compulab/common/eeprom.h | 10 --
> >>  4 files changed, 66 insertions(+), 8 deletions(-)
> >>
> > 
> > 
> > Applied to u-boot-imx, thanks !
> 
> IMO, this was a bit early...
> We haven't received any answer from Nikita yet.
> I tend to think that he is preparing a newer version.
> Nikita?

Yes, I was planning to submit a new version. Since V2 is already in
mainline though, I guess I'll submit a followup patch.

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

Re: [U-Boot] [PATCH] tools: gen_eth_addr: remove getpid() operation for the random seed

[Josh Wu]

On 9/16/2015 3:08 PM, Josh Wu wrote:

Hi, Wolfgang

Thanks for the reply.

On 9/16/2015 2:37 PM, Wolfgang Denk wrote:

Dear Josh Wu,

In message <1442373526-842-1-git-send-email-josh...@atmel.com> you 
wrote:

As 'time(0) | getpid()' sometimes get same value. That depends on the
value of getpid().

I think removing some "random input" from the way how we compute the
seed is a bad idea.


So that is not a expected behavior. We expect different value for the
seed when when run it in many times.

What is your execution environment? In any sane OS it is higly
unlikely that you will see the same or even similar PIDs for
successive runs of the program - each run will start a new process,
which will get a new PID.

my system is Ubuntu 14.04

#uname -a
Linux melon 3.13.0-45-generic #74-Ubuntu SMP Tue Jan 13 19:36:28 UTC 
2015 x86_64 x86_64 x86_64 GNU/Linux


Following is my test history:

➜  tools  date && ./gen_eth_addr
Wed Sep 16 14:48:53 CST 2015
4a:c3:21:45:17:b2
➜  tools  date && ./gen_eth_addr
Wed Sep 16 14:48:56 CST 2015
a6:29:4b:0b:e6:d0
➜  tools  date && ./gen_eth_addr
Wed Sep 16 14:49:02 CST 2015
d2:41:66:54:64:aa
➜  tools  date && ./gen_eth_addr
Wed Sep 16 14:49:06 CST 2015
2a:58:1d:b0:f0:c5
➜  tools  date && ./gen_eth_addr
Wed Sep 16 14:49:13 CST 2015
1e:8e:6f:0e:16:b8
➜  tools  date && ./gen_eth_addr
Wed Sep 16 14:49:19 CST 2015
56:4f:58:67:ad:30
➜  tools  date && ./gen_eth_addr
Wed Sep 16 14:49:21 CST 2015
2e:53:29:97:6a:8a
➜  tools  date && ./gen_eth_addr
Wed Sep 16 14:49:26 CST 2015
d2:41:66:54:64:aa
➜  tools  date && ./gen_eth_addr
Wed Sep 16 14:49:35 CST 2015
d2:41:66:54:64:aa

➜  tools  date && ./gen_eth_addr
Wed Sep 16 14:49:50 CST 2015
92:33:16:3f:0a:56
➜  tools  date && ./gen_eth_addr
Wed Sep 16 14:49:58 CST 2015
92:33:16:3f:0a:56

In above commands, I have two duplicated eth addr:
92:33:16:3f:0a:56
d2:41:66:54:64:aa



[On a mostly idle Linux system (4.1.6 kernel) I see zero dupes in a
set of 30,000 invocations of getpid().]

One can argue if ORing the values is the most clever idea, or if for
example ADDing them would result in more "randomness".

Sure. The ORing seems has big chance to get same result in my machine.



  But completely
removing the pid() is bad - any parallel runs of the program on any
machines with synchronized times would predictably result in the same
seeds which is definitely worse behaviour than what we have now.
I understand your concern. My intention is make it harder to generate 
the duplicated result.


Maybe we can ORing the MSB of time(0)?
I'll investigate it little more.


I test again, here is a duplicated case:

➜  tools  date && ./gen_eth_addr
Wed Sep 16 15:21:30 CST 2015
pid: 0x5aa4, time: 0x55f9187a
86:77:6e:cf:6b:16
➜  tools  date && ./gen_eth_addr
Wed Sep 16 15:21:34 CST 2015
pid: 0x5aa6, time: 0x55f9187e
86:77:6e:cf:6b:16

In above both cases, the random seed is same:  (last 4 bits)
  4 | a = e
  6 | e = e






So this patch remove the getpid(), just use the time(0) as the seed.

NAK.  This is a bad idea.

How about use 'time(0) + (getpid() << 8)'? my reason list in below:
1.  ADD will make the result is more unlikely than OR
2. (<< 8) means larger time difference.

Best Regards,
Josh Wu

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

Re: [U-Boot] [PATCH] tools: gen_eth_addr: remove getpid() operation for the random seed

[Josh Wu]

Hi, Andreas

On 9/16/2015 4:23 PM, Andreas Bießmann wrote:

Hi Josh,

On 09/16/2015 05:18 AM, Josh Wu wrote:

As 'time(0) | getpid()' sometimes get same value. That depends on the
value of getpid().
So that is not a expected behavior. We expect different value for the
seed when when run it in many times.

I don't think your change made it better. Here is a snippet from a run
of time(NULL) and getpid():

---8<---
time: 1442389450; pid: 11632; time | pid: 1442397690;
time: 1442389450; pid: 11633; time | pid: 1442397691;
time: 1442389450; pid: 11634; time | pid: 1442397690;
time: 1442389450; pid: 11635; time | pid: 1442397691;
time: 1442389450; pid: 11636; time | pid: 1442397694;
time: 1442389450; pid: 11637; time | pid: 1442397695;
time: 1442389450; pid: 11638; time | pid: 1442397694;
time: 1442389450; pid: 11639; time | pid: 1442397695;
time: 1442389450; pid: 11640; time | pid: 1442397690;
time: 1442389450; pid: 11641; time | pid: 1442397691;
time: 1442389450; pid: 11642; time | pid: 1442397690;
time: 1442389450; pid: 11643; time | pid: 1442397691;
--->8---

While time(NULL) is stable, getpid() is incrementing by one. As you may
expect the OR'ed value is oscillating and the values almost the same. So
calling gen_eth_addr three times within the same second you will get two
time the same MAC.


So this patch remove the getpid(), just use the time(0) as the seed.

So let's see the effect of your change ...

The output of gen_eth_addr at the current ToT:

% RUN=0; while [ $RUN -lt 1 ]; do
/tmp/build-uboot-test/tools/gen_eth_addr; RUN=$(($RUN+1)); done | sort |
uniq | wc -l
254

With your change applied:

% RUN=0; while [ $RUN -lt 1 ]; do
/tmp/build-uboot-test/tools/gen_eth_addr; RUN=$(($RUN+1)); done | sort |
uniq | wc -l
10

Another approach would be to change the algorithm (OR the values) here.
A short test showed that using XOR could be a solution:

---8<---
time: 1442389450; pid: 11632; time ^ pid: 1442394298;
time: 1442389450; pid: 11633; time ^ pid: 1442394299;
time: 1442389450; pid: 11634; time ^ pid: 1442394296;
time: 1442389450; pid: 11635; time ^ pid: 1442394297;
time: 1442389450; pid: 11636; time ^ pid: 1442394302;
time: 1442389450; pid: 11637; time ^ pid: 1442394303;
time: 1442389450; pid: 11638; time ^ pid: 1442394300;
time: 1442389450; pid: 11639; time ^ pid: 1442394301;
time: 1442389450; pid: 11640; time ^ pid: 1442394290;
time: 1442389450; pid: 11641; time ^ pid: 1442394291;
time: 1442389450; pid: 11642; time ^ pid: 1442394288;
time: 1442389450; pid: 11643; time ^ pid: 1442394289;
--->8---

It is the same input but none of the outputs is the same value.

The XOR approach applied to gen_eth_addr:

% RUN=0; while [ $RUN -lt 1 ]; do
/tmp/build-uboot-test/tools/gen_eth_addr; RUN=$(($RUN+1)); done | sort |
uniq | wc -l
9988


How about using ADD ?
When I change to 'time + (pid << 8)', the result is better. And the pid 
change will has more impact in time range.


➜  tools  time RUN=0; while [ $RUN -lt 1 ]; do
./gen_eth_addr_add_shift 1; RUN=$(($RUN+1)); done | sort | uniq | wc -l
1

The disadvantage is it might cost more time.

Best Regards,
Josh Wu


Andreas


Signed-off-by: Josh Wu 
---

  tools/gen_eth_addr.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/gen_eth_addr.c b/tools/gen_eth_addr.c
index bf9d935..53b023a 100644
--- a/tools/gen_eth_addr.c
+++ b/tools/gen_eth_addr.c
@@ -15,7 +15,7 @@ main(int argc, char *argv[])
  {
  unsigned long ethaddr_low, ethaddr_high;
  
-srand(time(0) | getpid());

+srand(time(0));
  
  /*

   * setting the 2nd LSB in the most significant byte of



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

Re: [U-Boot] [PATCH] tools: gen_eth_addr: remove getpid() operation for the random seed

[Wolfgang Denk]

Dear Josh,

In message <55f91588.3040...@atmel.com> you wrote:
> 
> In above commands, I have two duplicated eth addr:
> 92:33:16:3f:0a:56
> d2:41:66:54:64:aa

Agreed. Randomness is really poor; for a sequence of 1000 invocations
of gen_eth_addr in a shell loop I would only gt 124 different MAC
addresses:

-> for i in {1..1000} ; do ./gen_eth_addr ; done >/tmp/0
-> sort -u /tmp/0 >/tmp/1 ; wc -l /tmp/[01]
 1000 /tmp/0
  124 /tmp/1

In a second run, even only 41 :-(

But without the getpid() part, it gets even worse - the same loop
would produce only 15 different addresses!


Changing the '|' into a '+' would reliably generate 1000 different MAC
addresses.

> I understand your concern. My intention is make it harder to generate 
> the duplicated result.

I understand this, and agree that we should implement such a fix.

> Maybe we can ORing the MSB of time(0)?
> I'll investigate it little more.

The following patch appears to work fine for me.  Maybe you can test
it?

diff --git a/tools/gen_eth_addr.c b/tools/gen_eth_addr.c
index bf9d935..834163a 100644
--- a/tools/gen_eth_addr.c
+++ b/tools/gen_eth_addr.c
@@ -15,7 +15,7 @@ main(int argc, char *argv[])
 {
 unsigned long ethaddr_low, ethaddr_high;
 
-srand(time(0) | getpid());
+srand(time(0) + getpid());
 
 /*
  * setting the 2nd LSB in the most significant byte of


Thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
I think that all right-thinking people in this country are  sick  and
tired  of  being  told that ordinary decent people are fed up in this
country with being sick and tired. I'm certainly not.  But  I'm  sick
and tired of being told that I am. - Monty Python
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] tools: gen_eth_addr: remove getpid() operation for the random seed

[Josh Wu]

Hi, Wolfgang

Thanks for the reply.

On 9/16/2015 2:37 PM, Wolfgang Denk wrote:

Dear Josh Wu,

In message <1442373526-842-1-git-send-email-josh...@atmel.com> you wrote:

As 'time(0) | getpid()' sometimes get same value. That depends on the
value of getpid().

I think removing some "random input" from the way how we compute the
seed is a bad idea.


So that is not a expected behavior. We expect different value for the
seed when when run it in many times.

What is your execution environment? In any sane OS it is higly
unlikely that you will see the same or even similar PIDs for
successive runs of the program - each run will start a new process,
which will get a new PID.

my system is Ubuntu 14.04

#uname -a
Linux melon 3.13.0-45-generic #74-Ubuntu SMP Tue Jan 13 19:36:28 UTC 
2015 x86_64 x86_64 x86_64 GNU/Linux


Following is my test history:

➜  tools  date && ./gen_eth_addr
Wed Sep 16 14:48:53 CST 2015
4a:c3:21:45:17:b2
➜  tools  date && ./gen_eth_addr
Wed Sep 16 14:48:56 CST 2015
a6:29:4b:0b:e6:d0
➜  tools  date && ./gen_eth_addr
Wed Sep 16 14:49:02 CST 2015
d2:41:66:54:64:aa
➜  tools  date && ./gen_eth_addr
Wed Sep 16 14:49:06 CST 2015
2a:58:1d:b0:f0:c5
➜  tools  date && ./gen_eth_addr
Wed Sep 16 14:49:13 CST 2015
1e:8e:6f:0e:16:b8
➜  tools  date && ./gen_eth_addr
Wed Sep 16 14:49:19 CST 2015
56:4f:58:67:ad:30
➜  tools  date && ./gen_eth_addr
Wed Sep 16 14:49:21 CST 2015
2e:53:29:97:6a:8a
➜  tools  date && ./gen_eth_addr
Wed Sep 16 14:49:26 CST 2015
d2:41:66:54:64:aa
➜  tools  date && ./gen_eth_addr
Wed Sep 16 14:49:35 CST 2015
d2:41:66:54:64:aa

➜  tools  date && ./gen_eth_addr
Wed Sep 16 14:49:50 CST 2015
92:33:16:3f:0a:56
➜  tools  date && ./gen_eth_addr
Wed Sep 16 14:49:58 CST 2015
92:33:16:3f:0a:56

In above commands, I have two duplicated eth addr:
92:33:16:3f:0a:56
d2:41:66:54:64:aa



[On a mostly idle Linux system (4.1.6 kernel) I see zero dupes in a
set of 30,000 invocations of getpid().]

One can argue if ORing the values is the most clever idea, or if for
example ADDing them would result in more "randomness".

Sure. The ORing seems has big chance to get same result in my machine.



  But completely
removing the pid() is bad - any parallel runs of the program on any
machines with synchronized times would predictably result in the same
seeds which is definitely worse behaviour than what we have now.
I understand your concern. My intention is make it harder to generate 
the duplicated result.


Maybe we can ORing the MSB of time(0)?
I'll investigate it little more.




So this patch remove the getpid(), just use the time(0) as the seed.

NAK.  This is a bad idea.

Best regards,

Wolfgang Denk


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

Re: [U-Boot] [PATCH] ARM: socfpga: Enable saveenv for SD/MMC

[Pavel Machek]

On Tue 2015-09-15 22:22:33, Marek Vasut wrote:
> On Tuesday, September 15, 2015 at 09:47:23 PM, dingu...@opensource.altera.com 
> wrote:
> > From: Dinh Nguyen 
> > 
> > Enable the able to save the environment variables when SD/MMC is used.
> > 
> > Signed-off-by: Dinh Nguyen 
> 
> Hi,
> 
> this should be done per-board, so I'd suggest the following:

Why? MMC layout is same on all of them...

> >  #define CONFIG_ENV_SIZE4096

While you are changing that, bigger environment size would be
welcome. 32K?
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: socfpga: Enable saveenv for SD/MMC

[Stefan Roese]

On 16.09.2015 08:57, Pavel Machek wrote:

On Tue 2015-09-15 22:22:33, Marek Vasut wrote:

On Tuesday, September 15, 2015 at 09:47:23 PM, dingu...@opensource.altera.com
wrote:

From: Dinh Nguyen 

Enable the able to save the environment variables when SD/MMC is used.

Signed-off-by: Dinh Nguyen 


Hi,

this should be done per-board, so I'd suggest the following:


Why? MMC layout is same on all of them...


It doesn't have to be identical. And other boards might want to use e.g. 
SPI NOR as the environment storage device (I have such a custom board 
here). So this is definitely a board specific thing.



  #define CONFIG_ENV_SIZE   4096


While you are changing that, bigger environment size would be
welcome. 32K?


Yes.

Thanks,
Stefan

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

Re: [U-Boot] Pull-request: u-boot-spi/master

[Jagan Teki]

Hi Michal,

On 15 September 2015 at 18:58, Simon Glass  wrote:
> Hi Jagan,
>
> On 15 September 2015 at 02:13, Jagan Teki  wrote:
>> Hi Tom,
>>
>> Zynq patches has SPL build dependency with Simon changes [1].
>>
>> Simon, Any plan to send a PR for your changes.
>>
>> [1] 
>> http://git.denx.de/?p=u-boot/u-boot-dm.git;a=shortlog;h=refs/heads/zynq-working
>
> These are for the zynq maintainer I think. They are not assigned to me
> in patchwork.

Seems like this patch[1] resolves the SPL build issue, any plan on
pushing this? of-course I will test this and let you know.


[1] 
http://git.denx.de/?p=u-boot/u-boot-dm.git;a=commitdiff;h=7916a8cf902177afd20a09527a9cf307622bb6d2

>>
>> The following changes since commit 850f788709cef8f7d53d571aec3bfb73b14c5531:
>>
>>   Merge branch 'rmobile' of git://git.denx.de/u-boot-sh (2015-09-13 17:25:16 
>> -0400)
>>
>> are available in the git repository at:
>>
>>
>>   git://git.denx.de/u-boot-spi.git master
>>
>> for you to fetch changes up to a63981e1727139c51f05d3fa1cb1b299d2c00a7d:
>>
>>   zynq-common: Add SPL SPI offset, size configs (2015-09-15 13:31:44 +0530)
>>
>> 
>> Jagan Teki (23):
>>   spi: Add zynq qspi controller driver
>>   dts: zynq: Add zynq qspi controller nodes
>>   doc: device-tree-bindings: spi: Add zynq qspi info
>>   dts: microzed: Enable zynq qspi controller node
>>   dts: zc702: Enable zynq qspi controller node
>>   dts: zc706: Enable zynq qspi controller node
>>   dts: zc770-xm010: Enable zynq qspi controller node
>>   dts: zed: Enable zynq qspi controller node
>>   configs: Enable legacy SPI flash interface support
>>   zynq-common: Enable zynq qspi controller support
>>   zynq-common: Enable Bank/Extended address register support
>>   configs: zynq: Enable zynq qspi controller
>>   spi: Kconfig: Add Zynq QSPI controller entry
>>   spi: zynq_spi: Add config reg shift named macros
>>   spi: zynq_spi: Rename baudrate divisor mask name
>>   spi: zynq_spi: Store cs value into private data
>>   sf: params: Add IS25LP032 part support
>>   sf: params: Add IS25LP064 part support
>>   sf: params: Add IS25LP128 part support
>>   zynq-common: Enable ISSI SPI-NOR flash support
>>   spi: xilinx_spi: Fix to configure CPOL, CPHA mask
>>   spi: zynq_spi: Fix to configure CPOL, CPHA mask
>>   spi: zynq_qspi: Fix to configure CPOL, CPHA mask
>>
>> Mirza Krak (1):
>>   spi: tegra20: Add support for mode selection
>>
>> Siva Durga Prasad Paladugu (1):
>>   zynq-common: Add SPL SPI offset, size configs
>>
>>  arch/arm/dts/zynq-7000.dtsi|  12 +
>>  arch/arm/dts/zynq-microzed.dts |   5 +
>>  arch/arm/dts/zynq-zc702.dts|   5 +
>>  arch/arm/dts/zynq-zc706.dts|   5 +
>>  arch/arm/dts/zynq-zc770-xm010.dts  |   7 +-
>>  arch/arm/dts/zynq-zed.dts  |   5 +
>>  configs/zynq_microzed_defconfig|   2 +
>>  configs/zynq_zc702_defconfig   |   2 +
>>  configs/zynq_zc706_defconfig   |   2 +
>>  configs/zynq_zc70x_defconfig   |   2 +
>>  configs/zynq_zc770_xm010_defconfig |   1 +
>>  configs/zynq_zed_defconfig |   2 +
>>  doc/device-tree-bindings/spi/spi-zynq-qspi.txt |  26 ++
>>  drivers/mtd/spi/sf_params.c|   5 +
>>  drivers/spi/Kconfig|   9 +
>>  drivers/spi/Makefile   |   1 +
>>  drivers/spi/tegra20_slink.c|  21 +
>>  drivers/spi/xilinx_spi.c   |  10 +-
>>  drivers/spi/zynq_qspi.c| 623 
>> +
>>  drivers/spi/zynq_spi.c |  27 +-
>>  include/configs/zynq-common.h  |  15 +
>>  21 files changed, 771 insertions(+), 16 deletions(-)
>>  create mode 100644 doc/device-tree-bindings/spi/spi-zynq-qspi.txt
>>  create mode 100644 drivers/spi/zynq_qspi.c

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

[U-Boot] U-boot UBI breaks build with -O0

[Kevin Smith]

Some of the debug functions for UBI are preprocessed out for U-boot 
(ifndef __UBOOT__), but their calls are optimized out at higher 
optimization levels, so this does not cause a problem.  When building 
with -O0, the linker gives an error:

fs/ubifs/io.c:162: undefined reference to `dbg_leb_unmap'

This function is in a #ifndef __UBOOT__ section.

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

Re: [U-Boot] arm: ls1021a: Ensure Generic Timer disabled before jumping into the OS

[Huan Wang]

Hi, Alexander,

> On Tuesday 04 August 2015 09:55:37, Alison Wang wrote:
> > This patch addresses a problem mentioned recently on this mailing
> list:
> > [1].
> >
> > In that posting a LS1021 based system was locking up at about 5
> > minutes after boot,but the problem was mysteriously related to the
> > toolchain used for building u-boot.Debugging the problem reveals a
> > stuck interrupt 29 on the GIC.
> >
> > It appears Freescale's LS1021 support in u-boot erroneously sets the
> > 64-bit ARM generic PL1 physical time CompareValue register to all-
> ones
> > with a 32-bit value.This causes the timer compare to fire 344 seconds
> > after u-boot configures it.Depending on how fast u-boot gets the
> > kernel booted,this amounts to about 5-minutes of Linux uptime before
> > locking up.
> >
> > Apparently the bug is masked by some toolchains. Perhaps this is
> > explained by default compiler options, word sizes, or binutils
> versions.
> >
> > To fix the above issue, the generic physical timer is disabled before
> > jumping to the OS.
> >
> > [1]
> > https://lists.yoctoproject.org/pipermail/meta-freescale/2015-
> June/0144
> > 00.html
> >
> > Signed-off-by: Chris Kilgour 
> > Signed-off-by: Alison Wang 
> > ---
> >  arch/arm/cpu/armv7/ls102xa/cpu.c | 10 ++
> >  1 file changed, 10 insertions(+)
> >
> > diff --git a/arch/arm/cpu/armv7/ls102xa/cpu.c
> > b/arch/arm/cpu/armv7/ls102xa/cpu.c
> > index 75f0d8c..298422f 100644
> > --- a/arch/arm/cpu/armv7/ls102xa/cpu.c
> > +++ b/arch/arm/cpu/armv7/ls102xa/cpu.c
> > @@ -346,3 +346,13 @@ void smp_kick_all_cpus(void)
> > out_be32(>brrl, 0x2);
> >  }
> >  #endif
> > +
> > +void arch_preboot_os(void)
> > +{
> > +   unsigned long ctrl;
> > +
> > +   /* Disable PL1 Physical Timer */
> > +   asm("mrc p15, 0, %0, c14, c2, 1" : "=r" (ctrl));
> > +   ctrl &= ~ARCH_TIMER_CTRL_ENABLE;
> > +   asm("mcr p15, 0, %0, c14, c2, 1" : : "r" (ctrl)); }
> 
> This only disables the timer when booting linux. Does the possibly
> misconfigured timer compare value (only lower 32-bits are set to
> 0x) have any side-effects within u-boot? I don't currently know
> the timer is used there.
> I would prefer that the inline assembly code in timer_init is fixed to
> pass an 64-bit variable to mcrr. Maybe someone will take that code
> snippet as an example and such problems occur again. Opinions?
> 

[Alison Wang] Thanks for your reply. I agree with you that the misconfigured
Timer compare value should be fixed too. So except this patch, the patch on
http://patchwork.ozlabs.org/patch/495476/ need to be applied too.


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

Re: [U-Boot] [PATCH] Revert "env_eeprom: Assign default environment during board_init_f"

[Tom Rini]

On Wed, Sep 16, 2015 at 01:46:34PM +0200, Ludger Dreier wrote:
> Hi Tom,
> 
> Am 2015-09-15 18:54, schrieb Tom Rini:
> > Was there perhaps some sort of init ordering issue in a board which
> > did have EEPROM used as the backing store for env?  I could see a
> > case where perhaps (and Ludger, can you test this as well please?)
> > the problem is that for env_eeprom env_init() needs to just default
> > to the built-in (like it's basically doing today) and
> > env_relocate_spec() needs to do the read, check which is valid, etc,
> > etc, dance which it is _not_ doing today.
> 
> as I understand your idea, the code from both versions of env_init
> (redundant env and non-redunant) which is framed by 
> "#ifdef ENV_IS_EMBEDDED" may potentially be moved to, or called by
> env_relocate_spec. I think this could work. If this ok for you,
> I can come up with a tested proposal. But this would need some days.

Roughly speaking, yes.  env_init() should just be the "use the default
built-in env" code and env_relocate_spec() should do all of the hard
work that env_init() used to do.

-- 
Tom


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

Re: [U-Boot] [PATCH v3 1/2] nios2: map physical address to uncached virtual address

[Thomas Chou]

On 09/15/2015 03:28 PM, Thomas Chou wrote:

Add ioremap() to map physical address to uncached virtual
address. We need this to convert the reg address from the
device tree.

The order of headers inclusion in interrupts.c is changed
because common.h will include board header that contains
IO_REGION_BASE.

In the future, the IO_REGION_BASE should be decided from
the device tree.
tree

Signed-off-by: Thomas Chou 
Acked-by: Marek Vasut 
---
  arch/nios2/cpu/interrupts.c | 4 ++--
  arch/nios2/include/asm/io.h | 5 +
  2 files changed, 7 insertions(+), 2 deletions(-)


This patch should not be bound with the jtag uart driver. Separate this 
from the series.


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

Re: [U-Boot] Please pull u-boot-fdt.git

[Tom Rini]

On Tue, Sep 15, 2015 at 03:30:00PM -0600, Simon Glass wrote:

> Hi Tom,
> 
> The following changes since commit 850f788709cef8f7d53d571aec3bfb73b14c5531:
> 
>   Merge branch 'rmobile' of git://git.denx.de/u-boot-sh (2015-09-13
> 17:25:16 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-fdt.git
> 
> for you to fetch changes up to 02464e386bb5f0a022c121f95ae75cf583759d95:
> 
>   fdt: add new fdt address parsing functions (2015-09-15 07:57:13 -0600)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

[U-Boot] [PATCH v2] tools: gen_eth_addr: add getpid() to time(0) to avoid duplicated seed

[Josh Wu]

As 'time(0) | getpid()' will have a lot of duplicated value. It is not a
expected behavior. We expect different value for the seed when when run
it in many times.

So this patch will left shift the getpid() and add to time(0). That
avoid duplicated value.

Test command is like:
  % RUN=0; while [ $RUN -lt 1 ]; do
  tools/gen_eth_addr; RUN=$(($RUN+1)); done | sort | uniq | wc -l
  1

This patch is incorporated with suggestions made by Wolfgang Denk and Andreas
Bießmann. Thanks them a lot.

Signed-off-by: Josh Wu 
---

Changes in v2:
- left shift and add the getpid() value instead of removing it.

 tools/gen_eth_addr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/gen_eth_addr.c b/tools/gen_eth_addr.c
index bf9d935..5fa3e0c 100644
--- a/tools/gen_eth_addr.c
+++ b/tools/gen_eth_addr.c
@@ -15,7 +15,7 @@ main(int argc, char *argv[])
 {
 unsigned long ethaddr_low, ethaddr_high;
 
-srand(time(0) | getpid());
+srand(time(0) + (getpid() << 8));
 
 /*
  * setting the 2nd LSB in the most significant byte of
-- 
1.9.1

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

Re: [U-Boot] [PATCH V2 0/4] cm-fx6 updates for Utilite

[Igor Grinberg]

Hi Stefano,

On 09/13/15 11:36, Stefano Babic wrote:
> 
> 
> On 06/09/2015 10:48, Nikita Kiryanov wrote:
>> This series provides a fix necessary for early models of Utilite, a miniature
>> desktop based on CM-FX6. It implements a dynamic modification to the device 
>> tree
>> that is necessary for mmc boot.
>>
>> Cc: Stefano Babic 
>> Cc: Igor Grinberg 
>>
>> Changes in V2:
>>  - New patch: compulab: eeprom: propagate error value in read_mac_addr()
>>  - s/BOARD_PRODUCT_NAME_*/PRODUCT_NAME_*
>>  - rewrote cl_eeprom_get_product_name() to take a buffer parameter and
>>added documentation
>>  - #define USDHC3_PATH instead of const variable usdhc3_path
>>  - Do not update device tree on eeprom read failures in a more explicit
>>way
>>
>> Nikita Kiryanov (4):
>>   compulab: eeprom: select i2c bus when querying for board rev
>>   compulab: eeprom: propagate error value in read_mac_addr()
>>   compulab: eeprom: add support for obtaining product name
>>   arm: mx6: cm-fx6: modify device tree for old revisions of utilite
>>
>>  board/compulab/cm_fx6/cm_fx6.c | 22 +-
>>  board/compulab/cm_t35/cm_t35.c |  2 +-
>>  board/compulab/common/eeprom.c | 40 
>>  board/compulab/common/eeprom.h | 10 --
>>  4 files changed, 66 insertions(+), 8 deletions(-)
>>
> 
> 
> Applied to u-boot-imx, thanks !

IMO, this was a bit early...
We haven't received any answer from Nikita yet.
I tend to think that he is preparing a newer version.
Nikita?

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

[U-Boot] [PATCH] mmc: atmel: Add support fo atmel sdhci

[Wenyou Yang]

Signed-off-by: Wenyou Yang 
---

 arch/arm/mach-at91/include/mach/atmel_sdhci.h |   13 +
 drivers/mmc/Makefile  |1 +
 drivers/mmc/atmel_sdhci.c |   35 +
 3 files changed, 49 insertions(+)
 create mode 100644 arch/arm/mach-at91/include/mach/atmel_sdhci.h
 create mode 100644 drivers/mmc/atmel_sdhci.c

diff --git a/arch/arm/mach-at91/include/mach/atmel_sdhci.h 
b/arch/arm/mach-at91/include/mach/atmel_sdhci.h
new file mode 100644
index 000..cf3bf89
--- /dev/null
+++ b/arch/arm/mach-at91/include/mach/atmel_sdhci.h
@@ -0,0 +1,13 @@
+/*
+ * Copyright (c) 2015 Atmel Corporation
+ *   Wenyou.Yang 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef__ATMEL_SDHCI_H
+#define__ATMEL_SDHCI_H
+
+int atmel_sdhci_init(void *regbase, u32 id);
+
+#endif
diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index 99d0295..5d35705 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -8,6 +8,7 @@
 obj-$(CONFIG_DM_MMC) += mmc-uclass.o
 
 obj-$(CONFIG_ARM_PL180_MMCI) += arm_pl180_mmci.o
+obj-$(CONFIG_ATMEL_SDHCI) += atmel_sdhci.o
 obj-$(CONFIG_BCM2835_SDHCI) += bcm2835_sdhci.o
 obj-$(CONFIG_BFIN_SDH) += bfin_sdh.o
 obj-$(CONFIG_DAVINCI_MMC) += davinci_mmc.o
diff --git a/drivers/mmc/atmel_sdhci.c b/drivers/mmc/atmel_sdhci.c
new file mode 100644
index 000..64776a1
--- /dev/null
+++ b/drivers/mmc/atmel_sdhci.c
@@ -0,0 +1,35 @@
+/*
+ * Copyright (C) 2015 Atmel Corporation
+ *   Wenyou.Yang 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#define ATMEL_SDHC_MIN_FRQ 40
+
+int atmel_sdhci_init(void *regbase, u32 id)
+{
+   struct sdhci_host *host = NULL;
+   u32 max_clk, min_clk = ATMEL_SDHC_MIN_FRQ;
+
+   host = (struct sdhci_host *)malloc(sizeof(struct sdhci_host));
+   if (!host) {
+   printf("atmel_sdhci_init: sdhci_host malloc fail\n");
+   return -1;
+   }
+
+   host->name = "atmel_sdhci";
+   host->ioaddr = (void *)regbase;
+   host->quirks = 0;
+   host->version = sdhci_readw(host, SDHCI_HOST_VERSION);
+   max_clk = at91_get_periph_generated_clk(id);
+
+   add_sdhci(host, max_clk, min_clk);
+
+   return 0;
+}
-- 
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] tools: gen_eth_addr: remove getpid() operation for the random seed

[Andreas Bießmann]

Hi Josh,

On 09/16/2015 11:12 AM, Josh Wu wrote:
> On 9/16/2015 4:23 PM, Andreas Bießmann wrote:
>> On 09/16/2015 05:18 AM, Josh Wu wrote:
>>> As 'time(0) | getpid()' sometimes get same value. That depends on the
>>> value of getpid().
>>> So that is not a expected behavior. We expect different value for the
>>> seed when when run it in many times.
>> I don't think your change made it better. Here is a snippet from a run
>> of time(NULL) and getpid():
>>
>> ---8<---
>> time: 1442389450; pid: 11632; time | pid: 1442397690;
>> time: 1442389450; pid: 11633; time | pid: 1442397691;
>> time: 1442389450; pid: 11634; time | pid: 1442397690;
>> time: 1442389450; pid: 11635; time | pid: 1442397691;
>> time: 1442389450; pid: 11636; time | pid: 1442397694;
>> time: 1442389450; pid: 11637; time | pid: 1442397695;
>> time: 1442389450; pid: 11638; time | pid: 1442397694;
>> time: 1442389450; pid: 11639; time | pid: 1442397695;
>> time: 1442389450; pid: 11640; time | pid: 1442397690;
>> time: 1442389450; pid: 11641; time | pid: 1442397691;
>> time: 1442389450; pid: 11642; time | pid: 1442397690;
>> time: 1442389450; pid: 11643; time | pid: 1442397691;
>> --->8---
>>
>> While time(NULL) is stable, getpid() is incrementing by one. As you may
>> expect the OR'ed value is oscillating and the values almost the same. So
>> calling gen_eth_addr three times within the same second you will get two
>> time the same MAC.
>>
>>> So this patch remove the getpid(), just use the time(0) as the seed.
>> So let's see the effect of your change ...
>>
>> The output of gen_eth_addr at the current ToT:
>>
>> % RUN=0; while [ $RUN -lt 1 ]; do
>> /tmp/build-uboot-test/tools/gen_eth_addr; RUN=$(($RUN+1)); done | sort |
>> uniq | wc -l
>> 254
>>
>> With your change applied:
>>
>> % RUN=0; while [ $RUN -lt 1 ]; do
>> /tmp/build-uboot-test/tools/gen_eth_addr; RUN=$(($RUN+1)); done | sort |
>> uniq | wc -l
>> 10
>>
>> Another approach would be to change the algorithm (OR the values) here.
>> A short test showed that using XOR could be a solution:
>>
>> ---8<---
>> time: 1442389450; pid: 11632; time ^ pid: 1442394298;
>> time: 1442389450; pid: 11633; time ^ pid: 1442394299;
>> time: 1442389450; pid: 11634; time ^ pid: 1442394296;
>> time: 1442389450; pid: 11635; time ^ pid: 1442394297;
>> time: 1442389450; pid: 11636; time ^ pid: 1442394302;
>> time: 1442389450; pid: 11637; time ^ pid: 1442394303;
>> time: 1442389450; pid: 11638; time ^ pid: 1442394300;
>> time: 1442389450; pid: 11639; time ^ pid: 1442394301;
>> time: 1442389450; pid: 11640; time ^ pid: 1442394290;
>> time: 1442389450; pid: 11641; time ^ pid: 1442394291;
>> time: 1442389450; pid: 11642; time ^ pid: 1442394288;
>> time: 1442389450; pid: 11643; time ^ pid: 1442394289;
>> --->8---
>>
>> It is the same input but none of the outputs is the same value.
>>
>> The XOR approach applied to gen_eth_addr:
>>
>> % RUN=0; while [ $RUN -lt 1 ]; do
>> /tmp/build-uboot-test/tools/gen_eth_addr; RUN=$(($RUN+1)); done | sort |
>> uniq | wc -l
>> 9988
> 
> How about using ADD ?
> When I change to 'time + (pid << 8)', the result is better. And the pid
> change will has more impact in time range.
> 
> ➜  tools  time RUN=0; while [ $RUN -lt 1 ]; do
> ./gen_eth_addr_add_shift 1; RUN=$(($RUN+1)); done | sort | uniq | wc -l
> 1

I'm fine with that too. All I'd like to say with my answer was that
adding getpid() was for some reason and removing it is worse than having
it OR'ed.

> The disadvantage is it might cost more time.

I don't think this count's here. This tool would be used to generate a
temporary MAC (or more than one) for testing purposes. So getting a
bunch of MAC's can last some time, but should provide unique ones.

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

Re: [U-Boot] [PATCH] Revert "fdt: Fix fdtdec_get_addr_size() for 64-bit"

[Tom Warren]

Simon,

> -Original Message-
> From: Tom Warren
> Sent: Wednesday, September 02, 2015 7:02 PM
> To: 'Stephen Warren'; Simon Glass
> Cc: U-Boot Mailing List; Thierry Reding; Tom Rini
> Subject: RE: [U-Boot] [PATCH] Revert "fdt: Fix fdtdec_get_addr_size() for 64-
> bit"
> 
> > -Original Message-
> > From: Stephen Warren [mailto:swar...@wwwdotorg.org]
> > Sent: Wednesday, September 02, 2015 4:44 PM
> > To: Tom Warren; Simon Glass
> > Cc: U-Boot Mailing List; Thierry Reding; Tom Rini
> > Subject: Re: [U-Boot] [PATCH] Revert "fdt: Fix fdtdec_get_addr_size()
> > for 64- bit"
> >
> > On 09/02/2015 01:54 PM, Stephen Warren wrote:
> > > On 09/02/2015 01:39 PM, Tom Warren wrote:
> > >>
> > >>
> > >>> -Original Message-
> > >>> From: Stephen Warren
> > >>> Sent: Wednesday, September 02, 2015 1:05 PM
> > >>> To: Tom Warren; Simon Glass
> > >>> Cc: Bin Meng; Thierry Reding; Tom Rini; U-Boot Mailing List
> > >>> Subject: Re: [U-Boot] [PATCH] Revert "fdt: Fix
> > >>> fdtdec_get_addr_size() for 64- bit"
> > >>>
> > >>> On 09/02/2015 09:52 AM, Tom Warren wrote:
> >  Simon, et al,
> > 
> > > Simon Glass wrote at Friday, August 14, 2015 3:05 AM:
> > > I plan to apply this revert to u-boot-x86 (where SPI is
> > > currently
> > > broken) and (once it has a bit more testing) also this patch
> > > which I think makes the change in a safer way:
> > >
> > > https://patchwork.ozlabs.org/patch/504918/
> > >
> > > At present that patch breaks at least one x86 board and I have
> > > not dug into it yet.
> > >
> > > The revert should not break tegra, according to Stephen.
> > 
> >  Unfortunately, my testing on P2571 with TOT u-boot-tegra (rebased
> >  against
> > >>> TOT u-boot/master this morning) shows that that is not true.
> > 
> >  The revert of the disputed 'fdtdec_get_addr_size' patch _does_
> >  break Tegra
> > >>> 64-bit (P2571, at least). Nyan-big is OK.  With Simon's revert in
> > >>> place, my board just loops on SPL signon, so I assume it's
> > >>> faulting, etc. in CPU init.  Note that this is the current state of TOT 
> > >>> u-
> boot/master.
> > >>>
> > >>> I'm a bit confused. So far, we don't support SPL on T210 since we
> > >>> assume some other bootloader runs on the boot CPU and starts just
> > >>> the main U-Boot on the main CPU. It sounds like you're testing
> > >>> some local-
> > only SPL support?
> > >>
> > >> Currently there are a couple of ways to get T210 64-bit U-Boot
> > loaded/executed. The first is the way I've always done it (during
> > development and today) - use a 32-bit SPL that I built when I first
> > ported 32-bit U-Boot to T210. I've saved away the SPL portion as a
> > binary, and combine it with the current 64-bit T210 U-Boot proper when
> > building my image.  It's always worked up to now.  What I'm seeing is
> > a failure in the 64-bit CPU U-Boot portion. I just mentioned the
> > looping SPL signon symptom because that's what I see as the indicator of a
> broken 64-bit image.
> > >
> > > Oh I see; the SPL is only looping because the main U-Boot binary
> > > crashes/... and resets the CPU, hence re-executing the SPL. I
> > > thought you were referring to a loop purely within SPL.
> > >
> > > Now it makes more sense.
> > >
> > >> The other way is to use your proprietary NV bootloader for the
> > >> 32-bit
> > portion (this will become the de facto standard when we release said
> > NV bootloader code as open-source, or a binary first-stage loader
> > 'tool').  I haven't tried that, since my way works and is an easy part of my
> workflow.
> > >>
> > >> If you can point me to your boot CPU loader internally, I can try
> > >> your
> > method and see if it makes a difference, but I doubt it will.
> > >
> > > I sent you an internal email message.
> > >
> > > Perhaps you could also try my upstream U-Boot dev branch at:
> > >
> > > repo git://github.com/swarren/u-boot.git branch tegra_dev
> > >
> > > That has the revert of the original patch in, but also has the
> > > following replacement which you'd want to revert (or perhaps best:
> > > try with and without it):
> > >
> > > c1fd5e1d5586 fdt: add new fdt address parsing functions
> > >
> > > I'm sure I tested Simon's revert at the time I said it was OK. I
> > > wonder if the revert used to work fine, but something since then
> > > fails if the revert is in place? I would try testing this now, but
> > > I'm travelling so it's a bit more painful.
> >
> > I worked out how to remote control my device, and tested the current
> > u-boot- tegra/master (which contains the patch revert this email
> > thread is about) with and without "fdt: add new fdt address parsing
> functions"
> > removed, and it works fine for me.
> >
> > When you're concatenating SPL+U-Boot+DTB, are you using the DTB from
> > the same source tree as the main U-Boot (likely by getting U-Boot+DTB
> > from u- boot-dtb.bin in that source tree)?
> Yes
> 

I'm not sure if this was the last 

[U-Boot] [PATCH v4] nios2: convert altera_jtag_uart to driver model

[Thomas Chou]

Convert altera_jtag_uart to driver model.

Signed-off-by: Thomas Chou 
---

v2
  add ioremap.
  make the change to dts compatible with linux.

v3
  use fdt address translation patch from Stefan Roese.
  fix watchdog and loop as Marek suggested.

v4
  add clear AC flag to probe().
  remove polling loops and watchdog reset because they are
done in the serial-uclass.c.

 arch/nios2/dts/3c120_devboard.dts |   5 ++
 configs/nios2-generic_defconfig   |   3 +
 drivers/serial/Kconfig|  13 
 drivers/serial/altera_jtag_uart.c | 137 ++
 include/configs/nios2-generic.h   |   3 -
 5 files changed, 102 insertions(+), 59 deletions(-)

diff --git a/arch/nios2/dts/3c120_devboard.dts 
b/arch/nios2/dts/3c120_devboard.dts
index 02524ab..7f76328 100644
--- a/arch/nios2/dts/3c120_devboard.dts
+++ b/arch/nios2/dts/3c120_devboard.dts
@@ -93,6 +93,7 @@
reg = <0x4d50 0x0008>;
interrupt-parent = <>;
interrupts = <1>;
+   u-boot,dm-pre-reloc;
};
 
tse_mac: ethernet@0x4000 {
@@ -147,6 +148,10 @@
};
};
 
+   aliases {
+   console = _uart;
+   };
+
chosen {
bootargs = "debug console=ttyJ0,115200";
};
diff --git a/configs/nios2-generic_defconfig b/configs/nios2-generic_defconfig
index 9c1bec5..9dc6a72 100644
--- a/configs/nios2-generic_defconfig
+++ b/configs/nios2-generic_defconfig
@@ -1,4 +1,5 @@
 CONFIG_NIOS2=y
+CONFIG_DM_SERIAL=y
 CONFIG_TARGET_NIOS2_GENERIC=y
 CONFIG_DEFAULT_DEVICE_TREE="3c120_devboard"
 CONFIG_HUSH_PARSER=y
@@ -14,3 +15,5 @@ CONFIG_CMD_PING=y
 CONFIG_OF_CONTROL=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_DM=y
+CONFIG_ALTERA_JTAG_UART=y
+CONFIG_ALTERA_JTAG_UART_BYPASS=y
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index ccb80d2..5a8cb3a 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -109,6 +109,19 @@ config DEBUG_UART_SHIFT
  value. Use this value to specify the shift to use, where 0=byte
  registers, 2=32-bit word registers, etc.
 
+config ALTERA_JTAG_UART
+   bool "Altera JTAG UART support"
+   depends on NIOS2 && DM_SERIAL
+   help
+ Select this to enable an JTAG UART for Altera devices.
+
+config ALTERA_JTAG_UART_BYPASS
+   bool "Bypass output when no connection"
+   depends on ALTERA_JTAG_UART
+   help
+ Bypass console output and keep going even if there is no
+ JTAG terminal connection with the host.
+
 config ROCKCHIP_SERIAL
bool "Rockchip on-chip UART support"
depends on ARCH_UNIPHIER && DM_SERIAL
diff --git a/drivers/serial/altera_jtag_uart.c 
b/drivers/serial/altera_jtag_uart.c
index 9a81402..5f7a0f3 100644
--- a/drivers/serial/altera_jtag_uart.c
+++ b/drivers/serial/altera_jtag_uart.c
@@ -6,98 +6,123 @@
  */
 
 #include 
-#include 
+#include 
+#include 
 #include 
 #include 
 #include 
 
-typedef volatile struct {
+struct altera_jtaguart_regs {
unsigneddata;   /* Data register */
unsignedcontrol;/* Control register */
-} nios_jtag_t;
+};
+
+struct altera_jtaguart_platdata {
+   struct altera_jtaguart_regs *reg;
+};
 
 /* data register */
 #define NIOS_JTAG_RVALID   (1<<15) /* Read valid */
-#define NIOS_JTAG_DATA(d)  ((d)&0x0ff) /* Read data */
-#define NIOS_JTAG_RAVAIL(d)((d)>>16)   /* Read space avail */
 
 /* control register */
-#define NIOS_JTAG_RE   (1 << 0)/* read intr enable */
-#define NIOS_JTAG_WE   (1 << 1)/* write intr enable */
-#define NIOS_JTAG_RI   (1 << 8)/* read intr pending */
-#define NIOS_JTAG_WI   (1 << 9)/* write intr pending*/
 #define NIOS_JTAG_AC   (1 << 10)   /* activity indicator */
 #define NIOS_JTAG_RRDY (1 << 12)   /* read available */
 #define NIOS_JTAG_WSPACE(d)((d)>>16)   /* Write space avail */
+/* Write fifo size. FIXME: this should be extracted with sopc2dts */
+#define NIOS_WRITE_DEPTH   64
 
 DECLARE_GLOBAL_DATA_PTR;
 
-/*--
- * JTAG acts as the serial port
- *-*/
-static nios_jtag_t *jtag = (nios_jtag_t *)CONFIG_SYS_NIOS_CONSOLE;
-
-static void altera_jtag_serial_setbrg(void)
-{
-}
-
-static int altera_jtag_serial_init(void)
+static int altera_jtaguart_setbrg(struct udevice *dev, int baudrate)
 {
return 0;
 }
 
-static void altera_jtag_serial_putc(char c)
+static int altera_jtaguart_putc(struct udevice *dev, const char c)
 {
-   while (1) {
-   unsigned st = readl(>control);
-   if (NIOS_JTAG_WSPACE(st))
-   break;
+   struct altera_jtaguart_platdata 

Re: [U-Boot] [PATCH v2 2/4] dm: tpm: Add Driver Model support for tpm_atmel_twi driver

[Tom Rini]

On Wed, Sep 16, 2015 at 12:33:49AM +0200, Christophe Ricard wrote:

> tpm_atmel_twi can fit perfectly to the new UCLASS_TPM class.
> 
> Signed-off-by: Christophe Ricard 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH v2 3/4] dm: tpm: Remove every compilation switch for TPM driver model

[Tom Rini]

On Wed, Sep 16, 2015 at 12:33:50AM +0200, Christophe Ricard wrote:

> As every TPM drivers support UCLASS_TPM, we can only rely on DM_TPM
> functions.
> 
> This simplify a bit the code.
> 
> Signed-off-by: Christophe Ricard 

Reviewed-by: Tom Rini 

-- 
Tom


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

[U-Boot] [PATCH] Allow imxtract to extract part of script image.

[p.aubert]

From: Pierre Aubert 

Scripts are multi-file images, the imxtract command should handle them
in the same manner.

Signed-off-by: Pierre Aubert 
---
 common/cmd_ximg.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/common/cmd_ximg.c b/common/cmd_ximg.c
index 64b9186..abd94ec 100644
--- a/common/cmd_ximg.c
+++ b/common/cmd_ximg.c
@@ -87,7 +87,8 @@ do_imgextract(cmd_tbl_t * cmdtp, int flag, int argc, char * 
const argv[])
image_print_contents(hdr);
 #endif
 
-   if (!image_check_type(hdr, IH_TYPE_MULTI)) {
+   if (!image_check_type(hdr, IH_TYPE_MULTI) &&
+   !image_check_type(hdr, IH_TYPE_SCRIPT)) {
printf("Wrong Image Type for %s command\n",
cmdtp->name);
return 1;
-- 
1.7.6.5

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

Re: [U-Boot] Trying to load old kernel with new u-boot

[DaveKucharczyk]

When I set putty to 38400 I get the first half of the kernel console output
fine and the second half is garbage. 

So that tells me early kernel is outputting at 38400. Even though we don't
set it to that. When I print gd->baudrate in board_late_init() I get 115200.

So what does 2014.07 u-boot do differently than 2009.08 that causes the
early kernel console to get messed up?

That's my trail at the moment. 





--
View this message in context: 
http://u-boot.10912.n7.nabble.com/Trying-to-load-old-kernel-with-new-u-boot-tp228429p228444.html
Sent from the U-Boot mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 4/4] dm: tpm: Every TPM drivers should depends on DM_TPM

[Tom Rini]

On Wed, Sep 16, 2015 at 12:33:51AM +0200, Christophe Ricard wrote:

> Every TPM drivers should now depends on DM_TPM and not only TPM.
> 
> Signed-off-by: Christophe Ricard 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 09/14] armv8/ls1043ardb: Add nand boot support

[Gong Q . Y .]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, September 16, 2015 6:33 AM
> To: Gong Qianyu-B52263
> Cc: u-boot@lists.denx.de; Xie Shaohui-B21989; Hou Zhiqiang-B48286; Hu
> Mingkai-B21284; Song Wenbin-B53747; Sun York-R58495
> Subject: Re: [U-Boot] [PATCH 09/14] armv8/ls1043ardb: Add nand boot
> support
> 
> [Added York Sun -- please CC him on future patches]
> 
> On Tue, 2015-09-15 at 06:47 -0500, Gong Qianyu-B52263 wrote:
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Tuesday, September 15, 2015 7:08 AM
> > > To: Gong Qianyu-B52263
> > > Cc: u-boot@lists.denx.de; Xie Shaohui-B21989; Hou Zhiqiang-B48286;
> > > Hu Mingkai-B21284; Song Wenbin-B53747
> > > Subject: Re: [U-Boot] [PATCH 09/14] armv8/ls1043ardb: Add nand boot
> > > support
> > >
> > > On Fri, 2015-09-11 at 19:07 +0800, Gong Qianyu wrote:
> > > > Signed-off-by: Gong Qianyu 
> > > > Signed-off-by: Hou Zhiqiang 
> > > > Signed-off-by: Shaohui Xie 
> > > > Signed-off-by: Mingkai Hu 
> > > > ---
> > > >  arch/arm/Kconfig   |  1 +
> > > >  arch/arm/cpu/armv8/fsl-lsch2/Makefile  |  1 +
> > > >  arch/arm/cpu/armv8/fsl-lsch2/spl.c | 91
> > > > ++
> > > >  arch/arm/include/asm/arch-fsl-lsch2/config.h   |  2 +
> > > >  board/freescale/ls1043ardb/ls1043ardb_pbi.cfg  | 14 
> > > >  board/freescale/ls1043ardb/ls1043ardb_rcw_nand.cfg |  7 ++
> > > >  configs/ls1043ardb_nand_defconfig  |  4 +
> > > >  include/configs/ls1043a_common.h   | 31 
> > > >  include/configs/ls1043ardb.h   | 40 ++
> > > >  9 files changed, 191 insertions(+)
> > > >
> > > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index
> > > > f935f19..197c72d 100644
> > > > --- a/arch/arm/Kconfig
> > > > +++ b/arch/arm/Kconfig
> > > > @@ -612,6 +612,7 @@ config TARGET_VEXPRESS64_BASE_FVP  config
> > > > TARGET_VEXPRESS64_JUNO
> > > >   bool "Support Versatile Express Juno Development Platform"
> > > >   select ARM64
> > > > + select SUPPORT_SPL
> > >
> > > The subject line says you're adding nand boot support to ls1043ardb,
> > > not Juno.
> > >
> > > Also, the previous patch adds SUPPORT_SPL to ls1043ardb -- was it
> > > supported in that patch (for non-NAND boot) or is that an error?
> > >
> >
> > Sorry, this is really a patching mistake.:(
> >
> > > >
> > > >  config TARGET_LS2085A_EMU
> > > >   bool "Support ls2085a_emu"
> > > > diff --git a/arch/arm/cpu/armv8/fsl-lsch2/Makefile
> > > > b/arch/arm/cpu/armv8/fsl- lsch2/Makefile index 23c5bf9..0573659
> > > > 100644
> > > > --- a/arch/arm/cpu/armv8/fsl-lsch2/Makefile
> > > > +++ b/arch/arm/cpu/armv8/fsl-lsch2/Makefile
> > > > @@ -10,3 +10,4 @@ obj-y += lowlevel.o  obj-y += speed.o
> > > >  obj-$(CONFIG_SYS_HAS_SERDES) += fsl_lsch2_serdes.o
> > > > ls1043a_serdes.o
> > > >  obj-$(CONFIG_OF_LIBFDT) += fdt.o
> > > > +obj-$(CONFIG_SPL) += spl.o
> > > > diff --git a/arch/arm/cpu/armv8/fsl-lsch2/spl.c
> > > > b/arch/arm/cpu/armv8/fsl- lsch2/spl.c new file mode 100644 index
> > > > 000..980901a
> > > > --- /dev/null
> > > > +++ b/arch/arm/cpu/armv8/fsl-lsch2/spl.c
> > > > @@ -0,0 +1,91 @@
> > > > +/*
> > > > + * Copyright 2014 Freescale Semiconductor, Inc.
> > > > + *
> > > > + * SPDX-License-Identifier:  GPL-2.0+  */
> > > > +
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include "../../../../../board/freescale/common/ns_access.h"
> > >
> > > Why is this header in board/freescale/common if code outside that
> > > directory needs it?
> > >
> > > Where did you note the dependency on "ARMv7/ls1021a: move ns_access
> > > to common file" which is not in this patchset?
> > >
> > >
> >
> > The ns_access.h is common and shared by not only LS1043A but also
> > LS1021A boards.
> >
> > The "ARMv7/ls1021a” patch had been sent out much earlier while the
> > ls1043a patches were not ready.
> > Some details are still overlooked, though.
> 
> That doesn't answer my question.  If the header needs to be accessed from
> outside board/freescale/common it should not go in board/freescale/common.
> How about include/fsl-ns-access.h?  What does "ns" stand for here?
> 

OK. Our team discussed and now decide to create a include/fsl_csu.h to include 
the csu common parts.

> >
> > >
> > > > +
> > > > + get_clocks();
> > > > +
> > > > + preloader_console_init();
> > > > +
> > > > +#ifdef CONFIG_SPL_I2C_SUPPORT
> > > > + i2c_init_all();
> > > > +#endif
> > > > + dram_init();
> > > > +
> > > > + /* Clear the BSS */
> > > > + memset(__bss_start, 0, __bss_end - __bss_start);
> > > > +
> > > > +#ifdef CONFIG_LAYERSCAPE_NS_ACCESS
> > > > + enable_layerscape_ns_access(); #endif
> > > > + board_init_r(NULL, 0);
> > > > +}
> > >
> > > Can you 

Re: [U-Boot] [PATCH v2] tools: gen_eth_addr: add getpid() to time(0) to avoid duplicated seed

[Andreas Bießmann]

On 09/16/2015 12:21 PM, Josh Wu wrote:
> As 'time(0) | getpid()' will have a lot of duplicated value. It is not a
> expected behavior. We expect different value for the seed when when run

when when ... could be fixed when applied

> it in many times.
> 
> So this patch will left shift the getpid() and add to time(0). That
> avoid duplicated value.
> 
> Test command is like:
>   % RUN=0; while [ $RUN -lt 1 ]; do
>   tools/gen_eth_addr; RUN=$(($RUN+1)); done | sort | uniq | wc -l
>   1
> 
> This patch is incorporated with suggestions made by Wolfgang Denk and Andreas
> Bießmann. Thanks them a lot.
> 
> Signed-off-by: Josh Wu 

Acked-by: Andreas Bießmann 

> ---
> 
> Changes in v2:
> - left shift and add the getpid() value instead of removing it.
> 
>  tools/gen_eth_addr.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/gen_eth_addr.c b/tools/gen_eth_addr.c
> index bf9d935..5fa3e0c 100644
> --- a/tools/gen_eth_addr.c
> +++ b/tools/gen_eth_addr.c
> @@ -15,7 +15,7 @@ main(int argc, char *argv[])
>  {
>  unsigned long ethaddr_low, ethaddr_high;
>  
> -srand(time(0) | getpid());
> +srand(time(0) + (getpid() << 8));
>  
>  /*
>   * setting the 2nd LSB in the most significant byte of
> 

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

Re: [U-Boot] Trying to load old kernel with new u-boot

[Fabio Estevam]

On Wed, Sep 16, 2015 at 1:17 PM, DaveKucharczyk
 wrote:
> When I set putty to 38400 I get the first half of the kernel console output
> fine and the second half is garbage.
>
> So that tells me early kernel is outputting at 38400. Even though we don't
> set it to that. When I print gd->baudrate in board_late_init() I get 115200.
>
> So what does 2014.07 u-boot do differently than 2009.08 that causes the
> early kernel console to get messed up?

If I recall correctly they have different parents or the uart clock.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Revert "fdt: Fix fdtdec_get_addr_size() for 64-bit"

[Tom Warren]

Simon,

> -Original Message-
> From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
> Sent: Wednesday, September 16, 2015 6:11 PM
> To: Tom Warren
> Cc: U-Boot Mailing List; Thierry Reding; Tom Rini; Stephen Warren
> Subject: Re: [U-Boot] [PATCH] Revert "fdt: Fix fdtdec_get_addr_size() for 64-
> bit"
> 
> Hi Tom,
> 


> > I'm not sure if this was the last thread on this (I was on vacation for a 
> > few
> days), but have you resolved the problem you had with Stephen's new 'fdt:
> Add new fdt address parsing functions" patch? I'd really like to get this 
> resolved
> so I can send a PR to TomR.
> 
> Yes I believe the issues are resolved (not with the patch BTW - the only issue
> with the patch was the #define DEBUG which I removed).
> 
> The patch has just been applied to mainline.
Saw that, and sent a PR to TomR for the pending Tegra stuff. Thanks

> 
> Regards,
> Simon

---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Revert "env_eeprom: Assign default environment during board_init_f"

[Ludger Dreier]

Hi Tom,

Am 2015-09-15 18:54, schrieb Tom Rini:
> Was there perhaps some sort of init ordering issue in a board which
> did have EEPROM used as the backing store for env?  I could see a
> case where perhaps (and Ludger, can you test this as well please?)
> the problem is that for env_eeprom env_init() needs to just default
> to the built-in (like it's basically doing today) and
> env_relocate_spec() needs to do the read, check which is valid, etc,
> etc, dance which it is _not_ doing today.
> 

as I understand your idea, the code from both versions of env_init
(redundant env and non-redunant) which is framed by 
"#ifdef ENV_IS_EMBEDDED" may potentially be moved to, or called by
env_relocate_spec. I think this could work. If this ok for you,
I can come up with a tested proposal. But this would need some days.

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

Re: [U-Boot] [PATCH V2 4/4] test: Add basic tests for remoteproc

[Nishanth Menon]

On 21:46-20150901, Simon Glass wrote:
> On 27 August 2015 at 22:07, Nishanth Menon  wrote:
> > Use the sandbox environment for the basic tests.
> >
> > Signed-off-by: Nishanth Menon 
> > ---
> > New patch.
> >
> >  test/dm/Makefile |  1 +
> >  test/dm/remoteproc.c | 67 
> > 
> >  2 files changed, 68 insertions(+)
> >  create mode 100644 test/dm/remoteproc.c
> 
> Reviewed-by: Simon Glass 
> Tested-by: Simon Glass 
> 
> Nit below.

Thanks. Will fix the same in the next rev.

[...]
> > +
> > +   /* dt device device 2 */
> > +   ut_assertok(rproc_stop(0));
> > +   ut_assertok(rproc_reset(0));
> > +   /* -> invalid attempt tests.. */
> > +   ut_asserteq(-EINVAL, rproc_start(0));
> > +   ut_asserteq(-EINVAL, rproc_ping(0));
> > +   /* Valid tests.. */
> 
> You don't need a period at the end of these comments\

Yep. Will fix.

> 
> > +   ut_assertok(rproc_load(2, 1, 0));
> > +   ut_assertok(rproc_start(2));
> > +   ut_assertok(rproc_is_running(2));
> > +   ut_assertok(rproc_ping(2));
> > +   ut_assertok(rproc_reset(2));
> > +   ut_assertok(rproc_stop(2));
> 
> Would it be worth having a test that goes through things in the wrong
> sequence? It's up to you.

The current tests does attempt to perform basic sanity tests - there
are invalid sequence attempts as well.

> 
> BTW you don't have to put all your tests in one function, e.g. if some
> have a different purpose you can put them in a separate function.

I agree and had started it that way, then as I started putting things
together, considering the tests were simple sequence based, they were
good enough to put them in the test sequence in one shot. We can
definitely evolve as folks find specific needs of improvement in the
future.

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

Re: [U-Boot] Pull request, u-boot-tegra/master

[Tom Rini]

On Wed, Sep 16, 2015 at 04:27:51PM -0700, Tom Warren wrote:

> Tom,
> 
> Please pull u-boot-tegra/master into U-Boot/master. Thanks!
> 
> All tegra builds are OK (32-bit and 64-bit), and P2571 T210 64-bit boots to
> cmd prompt OK.
> 
> The following changes since commit fa43ce842c3026c2abf19d4234d02cd4c62eeec0:
> 
>   Merge git://git.denx.de/u-boot-fdt (2015-09-16 09:53:37 -0400)
> 
> are available in the git repository at:
> 
> 
>   git://git.denx.de/u-boot-tegra.git master
> 
> for you to fetch changes up to 8e1601d994e2fa8b8c7826470c3d923a684492a4:
> 
>   ARM: tegra114: Clear IDDQ when enabling PLLC (2015-09-16 16:11:31 -0700)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

[U-Boot] [PATCH 1/3] qe: add u-qe support to arm board

[Zhao Qiang]

From: Zhao Qiang 

ls1021 is arm-core and support qe which is u-qe.
add u-qe init for arm board.

Signed-off-by: Zhao Qiang 
---
 arch/arm/include/asm/arch-ls102xa/config.h |  4 
 arch/arm/include/asm/global_data.h |  8 
 drivers/Makefile   |  1 +
 drivers/qe/Makefile|  3 ++-
 drivers/qe/fdt.c   |  2 ++
 drivers/qe/qe.c| 15 +++
 drivers/qe/qe.h|  1 +
 7 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/arch-ls102xa/config.h 
b/arch/arm/include/asm/arch-ls102xa/config.h
index a500b5b..9c1b520 100644
--- a/arch/arm/include/asm/arch-ls102xa/config.h
+++ b/arch/arm/include/asm/arch-ls102xa/config.h
@@ -69,6 +69,10 @@
 
 #define DCU_LAYER_MAX_NUM  16
 
+#define QE_MURAM_SIZE  0x6000UL
+#define MAX_QE_RISC1
+#define QE_NUM_OF_SNUM 28
+
 #define CONFIG_SYS_FSL_SRDS_1
 
 #ifdef CONFIG_LS102XA
diff --git a/arch/arm/include/asm/global_data.h 
b/arch/arm/include/asm/global_data.h
index c69d064..438f128 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -17,6 +17,14 @@ struct arch_global_data {
 #if defined(CONFIG_FSL_ESDHC)
u32 sdhc_clk;
 #endif
+
+#if defined(CONFIG_U_QE)
+   u32 qe_clk;
+   u32 brg_clk;
+   uint mp_alloc_base;
+   uint mp_alloc_top;
+#endif /* CONFIG_U_QE */
+
 #ifdef CONFIG_AT91FAMILY
/* "static data" needed by at91's clock.c */
unsigned long   cpu_clk_rate_hz;
diff --git a/drivers/Makefile b/drivers/Makefile
index d8361d9..5ff3943 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -16,6 +16,7 @@ obj-y += twserial/
 obj-y += video/
 obj-y += watchdog/
 obj-$(CONFIG_QE) += qe/
+obj-$(CONFIG_U_QE) += qe/
 obj-y += memory/
 obj-y += pwm/
 obj-y += input/
diff --git a/drivers/qe/Makefile b/drivers/qe/Makefile
index 7f1bd06..8fa4866 100644
--- a/drivers/qe/Makefile
+++ b/drivers/qe/Makefile
@@ -4,5 +4,6 @@
 # SPDX-License-Identifier: GPL-2.0+
 #
 
-obj-y := qe.o uccf.o uec.o uec_phy.o
+obj-$(CONFIG_QE) += qe.o uccf.o uec.o uec_phy.o
+obj-$(CONFIG_U_QE) += qe.o
 obj-$(CONFIG_OF_LIBFDT) += fdt.o
diff --git a/drivers/qe/fdt.c b/drivers/qe/fdt.c
index d9a7d82..dfae4bf 100644
--- a/drivers/qe/fdt.c
+++ b/drivers/qe/fdt.c
@@ -12,6 +12,7 @@
 #include 
 #include "qe.h"
 
+#ifdef CONFIG_QE
 DECLARE_GLOBAL_DATA_PTR;
 
 /*
@@ -72,3 +73,4 @@ void ft_qe_setup(void *blob)
"clock-frequency", gd->arch.qe_clk / 2, 1);
fdt_fixup_qe_firmware(blob);
 }
+#endif
diff --git a/drivers/qe/qe.c b/drivers/qe/qe.c
index 4358a91..b545ec9 100644
--- a/drivers/qe/qe.c
+++ b/drivers/qe/qe.c
@@ -40,6 +40,7 @@ void qe_issue_cmd(uint cmd, uint sbc, u8 mcn, u32 cmd_data)
return;
 }
 
+#ifdef CONFIG_QE
 uint qe_muram_alloc(uint size, uint align)
 {
uintretloc;
@@ -70,6 +71,7 @@ uint qe_muram_alloc(uint size, uint align)
 
return retloc;
 }
+#endif
 
 void *qe_muram_addr(uint offset)
 {
@@ -180,6 +182,17 @@ void qe_init(uint qe_base)
qe_snums_init();
 }
 
+#ifdef CONFIG_U_QE
+void u_qe_init(void)
+{
+   uint qe_base = CONFIG_SYS_IMMR + 0x0140; /* QE immr base */
+   qe_immr = (qe_map_t *)qe_base;
+
+   qe_upload_firmware((const void *)CONFIG_SYS_QE_FW_ADDR);
+   out_be32(_immr->iram.iready, QE_IRAM_READY);
+}
+#endif
+
 void qe_reset(void)
 {
qe_issue_cmd(QE_RESET, QE_CR_SUBBLOCK_INVALID,
@@ -212,6 +225,7 @@ void qe_assign_page(uint snum, uint para_ram_base)
 
 #define BRG_CLK(gd->arch.brg_clk)
 
+#ifdef CONFIG_QE
 int qe_set_brg(uint brg, uint rate)
 {
volatile uint   *bp;
@@ -239,6 +253,7 @@ int qe_set_brg(uint brg, uint rate)
 
return 0;
 }
+#endif
 
 /* Set ethernet MII clock master
 */
diff --git a/drivers/qe/qe.h b/drivers/qe/qe.h
index ebb7c5f..30484b8 100644
--- a/drivers/qe/qe.h
+++ b/drivers/qe/qe.h
@@ -275,6 +275,7 @@ void *qe_muram_addr(uint offset);
 int qe_get_snum(void);
 void qe_put_snum(u8 snum);
 void qe_init(uint qe_base);
+void u_qe_init(void);
 void qe_reset(void);
 void qe_assign_page(uint snum, uint para_ram_base);
 int qe_set_brg(uint brg, uint rate);
-- 
2.1.0.27.g96db324

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

[U-Boot] [PATCH] arm: ls102xa: enable snooping for CAAM transactions

[Horia Geantă]

Enable snooping for CAAM read & write transactions by
programming the SCFG snoop configuration register:
SCFG_SNPCNFGCR[SECRDSNP]
SCFG_SNPCNFGCR[SECWRSNP]

Signed-off-by: Horia Geantă 
Reviewed-by: Zhengxiong Jin 
---
 arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h | 1 +
 board/freescale/ls1021aqds/ls1021aqds.c   | 2 ++
 board/freescale/ls1021atwr/ls1021atwr.c   | 2 ++
 3 files changed, 5 insertions(+)

diff --git a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h 
b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
index 60aa0d3b6f43..fbd06bafce31 100644
--- a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
+++ b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
@@ -144,6 +144,7 @@ struct ccsr_gur {
 };
 
 #define SCFG_ETSECDMAMCR_LE_BD_FR  0x0c00
+#define SCFG_SNPCNFGCR_SEC_RD_WR   0xc000
 #define SCFG_ETSECCMCR_GE2_CLK125  0x0400
 #define SCFG_ETSECCMCR_GE0_CLK125  0x
 #define SCFG_ETSECCMCR_GE1_CLK125  0x0800
diff --git a/board/freescale/ls1021aqds/ls1021aqds.c 
b/board/freescale/ls1021aqds/ls1021aqds.c
index 655fc644fe90..e7c25a5012f0 100644
--- a/board/freescale/ls1021aqds/ls1021aqds.c
+++ b/board/freescale/ls1021aqds/ls1021aqds.c
@@ -281,6 +281,8 @@ int board_early_init_f(void)
struct ccsr_cci400 *cci = (struct ccsr_cci400 *)CONFIG_SYS_CCI400_ADDR;
unsigned int major;
 
+   setbits_be32(>snpcnfgcr, SCFG_SNPCNFGCR_SEC_RD_WR);
+
 #ifdef CONFIG_TSEC_ENET
/* clear BD & FR bits for BE BD's and frame data */
clrbits_be32(>etsecdmamcr, SCFG_ETSECDMAMCR_LE_BD_FR);
diff --git a/board/freescale/ls1021atwr/ls1021atwr.c 
b/board/freescale/ls1021atwr/ls1021atwr.c
index 228dbf81bb25..e15999e42165 100644
--- a/board/freescale/ls1021atwr/ls1021atwr.c
+++ b/board/freescale/ls1021atwr/ls1021atwr.c
@@ -482,6 +482,8 @@ int board_early_init_f(void)
struct ccsr_cci400 *cci = (struct ccsr_cci400 *)CONFIG_SYS_CCI400_ADDR;
unsigned int major;
 
+   setbits_be32(>snpcnfgcr, SCFG_SNPCNFGCR_SEC_RD_WR);
+
 #ifdef CONFIG_TSEC_ENET
/* clear BD & FR bits for BE BD's and frame data */
clrbits_be32(>etsecdmamcr, SCFG_ETSECDMAMCR_LE_BD_FR);
-- 
2.4.4

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

Re: [U-Boot] [PATCH] ARM: at91: sama5: add support for CONFIG_ENV_IS_IN_MMC

[Bo Shen]

Hi Josh

On 09/16/2015 11:34 AM, Josh Wu wrote:

If defined CONFIG_ENV_IS_IN_MMC, then u-boot environment is saved in
mmc's raw sectors. Otherwise, u-boot environment is saved as a file:
uboot.env.

Signed-off-by: Josh Wu 


Reviewed-by: Bo Shen 

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

Re: [U-Boot] Trying to load old kernel with new u-boot

[Fabio Estevam]

On Wed, Sep 16, 2015 at 7:23 PM, Fabio Estevam  wrote:
> On Wed, Sep 16, 2015 at 1:17 PM, DaveKucharczyk
>  wrote:
>> When I set putty to 38400 I get the first half of the kernel console output
>> fine and the second half is garbage.
>>
>> So that tells me early kernel is outputting at 38400. Even though we don't
>> set it to that. When I print gd->baudrate in board_late_init() I get 115200.
>>
>> So what does 2014.07 u-boot do differently than 2009.08 that causes the
>> early kernel console to get messed up?
>
> If I recall correctly they have different parents or the uart clock.

I meant "different parents for the uart clock"
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Pull request, u-boot-tegra/master

[Tom Warren]

Tom,

Please pull u-boot-tegra/master into U-Boot/master. Thanks!

All tegra builds are OK (32-bit and 64-bit), and P2571 T210 64-bit boots to
cmd prompt OK.

The following changes since commit fa43ce842c3026c2abf19d4234d02cd4c62eeec0:

  Merge git://git.denx.de/u-boot-fdt (2015-09-16 09:53:37 -0400)

are available in the git repository at:


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

for you to fetch changes up to 8e1601d994e2fa8b8c7826470c3d923a684492a4:

  ARM: tegra114: Clear IDDQ when enabling PLLC (2015-09-16 16:11:31 -0700)


Axel Lin (1):
  tegra: Remove tegra_spl_gpio_direction_output declaration from header
file

Mirza Krak (1):
  ARM: tegra: Add Tegra20 SPI device nodes

Stephen Warren (4):
  ARM: tegra: Add p2371-2180 board
  ARM: tegra: fix COUNTER_FREQUENCY for T210
  ARM: tegra: fix PLLP frequency calc on T210
  ARM: tegra: replace V_PROMPT define with kconfig

Thierry Reding (8):
  armv8: Make COUNTER_FREQUENCY optional
  ARM: tegra: Implement clk_m
  ARM: tegra: clk_m is the architected timer source clock
  e2220-1170: Remove hard-coded counter frequency
  p2371: Remove hard-coded counter frequency
  p2571: Remove hard-coded counter frequency
  ARM: tegra124: Clear IDDQ when enabling PLLC
  ARM: tegra114: Clear IDDQ when enabling PLLC

 arch/arm/cpu/armv8/start.S |   2 +
 arch/arm/dts/Makefile  |   1 +
 arch/arm/dts/tegra20.dtsi  |  57 +
 arch/arm/dts/tegra210-p2371-2180.dts   |  60 +
 arch/arm/include/asm/arch-tegra/clock.h|   7 +-
 arch/arm/include/asm/arch-tegra/gpio.h |   9 -
 arch/arm/include/asm/arch-tegra114/clock-tables.h  |   1 +
 arch/arm/include/asm/arch-tegra114/clock.h |   3 +
 arch/arm/include/asm/arch-tegra124/clock-tables.h  |   1 +
 arch/arm/include/asm/arch-tegra124/clock.h |   3 +
 arch/arm/include/asm/arch-tegra20/clock-tables.h   |   1 +
 arch/arm/include/asm/arch-tegra210/clock-tables.h  |   1 +
 arch/arm/include/asm/arch-tegra30/clock-tables.h   |   1 +
 arch/arm/mach-tegra/clock.c|  21 +-
 arch/arm/mach-tegra/tegra114/clock.c   |   9 +-
 arch/arm/mach-tegra/tegra124/clock.c   |   9 +-
 arch/arm/mach-tegra/tegra210/Kconfig   |   9 +
 arch/arm/mach-tegra/tegra210/clock.c   |  21 +-
 board/nvidia/p2371-2180/Kconfig|  12 +
 board/nvidia/p2371-2180/MAINTAINERS|   6 +
 board/nvidia/p2371-2180/Makefile   |   8 +
 board/nvidia/p2371-2180/p2371-2180.c   |  51 
 board/nvidia/p2371-2180/pinmux-config-p2371-2180.h | 265
+
 configs/e2220-1170_defconfig   |   1 +
 configs/p2371-_defconfig   |   1 +
 configs/p2371-2180_defconfig   |  18 ++
 configs/p2571_defconfig|   1 +
 include/configs/e2220-1170.h   |   3 -
 include/configs/p2371-.h   |   3 -
 include/configs/p2371-2180.h   |  65 +
 include/configs/p2571.h|   2 -
 31 files changed, 622 insertions(+), 30 deletions(-)
 create mode 100644 arch/arm/dts/tegra210-p2371-2180.dts
 create mode 100644 board/nvidia/p2371-2180/Kconfig
 create mode 100644 board/nvidia/p2371-2180/MAINTAINERS
 create mode 100644 board/nvidia/p2371-2180/Makefile
 create mode 100644 board/nvidia/p2371-2180/p2371-2180.c
 create mode 100644 board/nvidia/p2371-2180/pinmux-config-p2371-2180.h
 create mode 100644 configs/p2371-2180_defconfig
 create mode 100644 include/configs/p2371-2180.h
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2 1/4] drivers: Introduce a simplified remoteproc framework

[Nishanth Menon]

On 21:46-20150901, Simon Glass wrote:
Hi Simon,
   Apologies on a delayed response.

[...]

> > Changes in V2:
> > - review comments incorporated from v1
> 
> Ah yes, but which ones?!

Hopefully all of them - I'd normally list up the details, but the
changes were a little too many in the case of v2..
[...]

> >
> [snip]
> 
> Reviewed-by: Simon Glass 

Thanks. Will post next rev fixing the nits and picking up your
reviewed-by tag.

> 
> A few nits below.

Thanks once again for your patience and review.

> > +
> > +/*
> > + * XXX XXX XXX
> > + * *IMPORTANT* NOTE: THE PLATFORM DATA SUPPORT IS NOT MEANT FOR USE WITH 
> > NEWER
> > + * PLATFORMS. THIS IS MEANT ONLY FOR LEGACY DEVICES. THIS MODE OF
> > + * INITIALIZATION *WILL* BE EVENTUALLY REMOVED ONCE ALL NECESSARY
> > + * PLATFORMS HAVE MOVED TO DM/FDT.
> > + * XXX XXX XXX
> > + */
> 
> This can be lower case and you should remove the  stuff.

Will do so in the next rev.

> > +/* Accessor */
> > +#define rproc_get_ops(dev) ((struct dm_rproc_ops *)(dev)->driver->ops)
> > +
> > +#ifdef CONFIG_REMOTEPROC
> > +int rproc_init(void);
> > +bool rproc_is_initialized(void);
> > +int rproc_load(int id, ulong addr, ulong size);
> > +int rproc_start(int id);
> > +int rproc_stop(int id);
> > +int rproc_reset(int id);
> > +int rproc_ping(int id);
> > +int rproc_is_running(int id);
> 
> Can you move your function comments to here? This where you define
> your API, and it is the file that people will read.

Will do so as well.

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

Re: [U-Boot] [PATCH] mmc: atmel: Add support fo atmel sdhci

[Bo Shen]

Hi Wenyou,

On 09/16/2015 04:23 PM, Wenyou Yang wrote:

I think you should add commit message here.


Signed-off-by: Wenyou Yang 
---

  arch/arm/mach-at91/include/mach/atmel_sdhci.h |   13 +
  drivers/mmc/Makefile  |1 +
  drivers/mmc/atmel_sdhci.c |   35 +
  3 files changed, 49 insertions(+)
  create mode 100644 arch/arm/mach-at91/include/mach/atmel_sdhci.h
  create mode 100644 drivers/mmc/atmel_sdhci.c

diff --git a/arch/arm/mach-at91/include/mach/atmel_sdhci.h 
b/arch/arm/mach-at91/include/mach/atmel_sdhci.h
new file mode 100644
index 000..cf3bf89
--- /dev/null
+++ b/arch/arm/mach-at91/include/mach/atmel_sdhci.h
@@ -0,0 +1,13 @@
+/*
+ * Copyright (c) 2015 Atmel Corporation
+ *   Wenyou.Yang 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef__ATMEL_SDHCI_H
+#define__ATMEL_SDHCI_H
+
+int atmel_sdhci_init(void *regbase, u32 id);
+
+#endif
diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index 99d0295..5d35705 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -8,6 +8,7 @@
  obj-$(CONFIG_DM_MMC) += mmc-uclass.o

  obj-$(CONFIG_ARM_PL180_MMCI) += arm_pl180_mmci.o
+obj-$(CONFIG_ATMEL_SDHCI) += atmel_sdhci.o
  obj-$(CONFIG_BCM2835_SDHCI) += bcm2835_sdhci.o
  obj-$(CONFIG_BFIN_SDH) += bfin_sdh.o
  obj-$(CONFIG_DAVINCI_MMC) += davinci_mmc.o
diff --git a/drivers/mmc/atmel_sdhci.c b/drivers/mmc/atmel_sdhci.c
new file mode 100644
index 000..64776a1
--- /dev/null
+++ b/drivers/mmc/atmel_sdhci.c
@@ -0,0 +1,35 @@
+/*
+ * Copyright (C) 2015 Atmel Corporation
+ *   Wenyou.Yang 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#define ATMEL_SDHC_MIN_FRQ 40


Nit: maybe FREQ is better than FRQ?


+
+int atmel_sdhci_init(void *regbase, u32 id)
+{
+   struct sdhci_host *host = NULL;
+   u32 max_clk, min_clk = ATMEL_SDHC_MIN_FRQ;
+
+   host = (struct sdhci_host *)malloc(sizeof(struct sdhci_host));


How about "host = malloc(sizeof(*host));"?


+   if (!host) {
+   printf("atmel_sdhci_init: sdhci_host malloc fail\n");
+   return -1;


Maybe use -ENOMEM replace -1?


+   }
+
+   host->name = "atmel_sdhci";
+   host->ioaddr = (void *)regbase;
+   host->quirks = 0;
+   host->version = sdhci_readw(host, SDHCI_HOST_VERSION);
+   max_clk = at91_get_periph_generated_clk(id);


As we discussed with your patch for "at91_get_periph_generated_clk", 
this function may failed. So, I think you need add error check here.



+   add_sdhci(host, max_clk, min_clk);
+
+   return 0;
+}



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

Re: [U-Boot] [PATCH] Revert "fdt: Fix fdtdec_get_addr_size() for 64-bit"

[Simon Glass]

Hi Tom,

On 16 September 2015 at 15:46, Tom Warren  wrote:
> Simon,
>
>> -Original Message-
>> From: Tom Warren
>> Sent: Wednesday, September 02, 2015 7:02 PM
>> To: 'Stephen Warren'; Simon Glass
>> Cc: U-Boot Mailing List; Thierry Reding; Tom Rini
>> Subject: RE: [U-Boot] [PATCH] Revert "fdt: Fix fdtdec_get_addr_size() for 64-
>> bit"
>>
>> > -Original Message-
>> > From: Stephen Warren [mailto:swar...@wwwdotorg.org]
>> > Sent: Wednesday, September 02, 2015 4:44 PM
>> > To: Tom Warren; Simon Glass
>> > Cc: U-Boot Mailing List; Thierry Reding; Tom Rini
>> > Subject: Re: [U-Boot] [PATCH] Revert "fdt: Fix fdtdec_get_addr_size()
>> > for 64- bit"
>> >
>> > On 09/02/2015 01:54 PM, Stephen Warren wrote:
>> > > On 09/02/2015 01:39 PM, Tom Warren wrote:
>> > >>
>> > >>
>> > >>> -Original Message-
>> > >>> From: Stephen Warren
>> > >>> Sent: Wednesday, September 02, 2015 1:05 PM
>> > >>> To: Tom Warren; Simon Glass
>> > >>> Cc: Bin Meng; Thierry Reding; Tom Rini; U-Boot Mailing List
>> > >>> Subject: Re: [U-Boot] [PATCH] Revert "fdt: Fix
>> > >>> fdtdec_get_addr_size() for 64- bit"
>> > >>>
>> > >>> On 09/02/2015 09:52 AM, Tom Warren wrote:
>> >  Simon, et al,
>> > 
>> > > Simon Glass wrote at Friday, August 14, 2015 3:05 AM:
>> > > I plan to apply this revert to u-boot-x86 (where SPI is
>> > > currently
>> > > broken) and (once it has a bit more testing) also this patch
>> > > which I think makes the change in a safer way:
>> > >
>> > > https://patchwork.ozlabs.org/patch/504918/
>> > >
>> > > At present that patch breaks at least one x86 board and I have
>> > > not dug into it yet.
>> > >
>> > > The revert should not break tegra, according to Stephen.
>> > 
>> >  Unfortunately, my testing on P2571 with TOT u-boot-tegra (rebased
>> >  against
>> > >>> TOT u-boot/master this morning) shows that that is not true.
>> > 
>> >  The revert of the disputed 'fdtdec_get_addr_size' patch _does_
>> >  break Tegra
>> > >>> 64-bit (P2571, at least). Nyan-big is OK.  With Simon's revert in
>> > >>> place, my board just loops on SPL signon, so I assume it's
>> > >>> faulting, etc. in CPU init.  Note that this is the current state of 
>> > >>> TOT u-
>> boot/master.
>> > >>>
>> > >>> I'm a bit confused. So far, we don't support SPL on T210 since we
>> > >>> assume some other bootloader runs on the boot CPU and starts just
>> > >>> the main U-Boot on the main CPU. It sounds like you're testing
>> > >>> some local-
>> > only SPL support?
>> > >>
>> > >> Currently there are a couple of ways to get T210 64-bit U-Boot
>> > loaded/executed. The first is the way I've always done it (during
>> > development and today) - use a 32-bit SPL that I built when I first
>> > ported 32-bit U-Boot to T210. I've saved away the SPL portion as a
>> > binary, and combine it with the current 64-bit T210 U-Boot proper when
>> > building my image.  It's always worked up to now.  What I'm seeing is
>> > a failure in the 64-bit CPU U-Boot portion. I just mentioned the
>> > looping SPL signon symptom because that's what I see as the indicator of a
>> broken 64-bit image.
>> > >
>> > > Oh I see; the SPL is only looping because the main U-Boot binary
>> > > crashes/... and resets the CPU, hence re-executing the SPL. I
>> > > thought you were referring to a loop purely within SPL.
>> > >
>> > > Now it makes more sense.
>> > >
>> > >> The other way is to use your proprietary NV bootloader for the
>> > >> 32-bit
>> > portion (this will become the de facto standard when we release said
>> > NV bootloader code as open-source, or a binary first-stage loader
>> > 'tool').  I haven't tried that, since my way works and is an easy part of 
>> > my
>> workflow.
>> > >>
>> > >> If you can point me to your boot CPU loader internally, I can try
>> > >> your
>> > method and see if it makes a difference, but I doubt it will.
>> > >
>> > > I sent you an internal email message.
>> > >
>> > > Perhaps you could also try my upstream U-Boot dev branch at:
>> > >
>> > > repo git://github.com/swarren/u-boot.git branch tegra_dev
>> > >
>> > > That has the revert of the original patch in, but also has the
>> > > following replacement which you'd want to revert (or perhaps best:
>> > > try with and without it):
>> > >
>> > > c1fd5e1d5586 fdt: add new fdt address parsing functions
>> > >
>> > > I'm sure I tested Simon's revert at the time I said it was OK. I
>> > > wonder if the revert used to work fine, but something since then
>> > > fails if the revert is in place? I would try testing this now, but
>> > > I'm travelling so it's a bit more painful.
>> >
>> > I worked out how to remote control my device, and tested the current
>> > u-boot- tegra/master (which contains the patch revert this email
>> > thread is about) with and without "fdt: add new fdt address parsing
>> functions"
>> > removed, and it works fine for me.
>> >
>> > When you're concatenating 

[U-Boot] [PATCH] QE: modify the address of qe ucode

[Zhao Qiang]

From: Zhao Qiang 

the address of uboot changed, so change qe ucode

Signed-off-by: Zhao Qiang 
---
 include/configs/ls1021aqds.h | 2 +-
 include/configs/ls1021atwr.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/configs/ls1021aqds.h b/include/configs/ls1021aqds.h
index dfaffa1..adb3cdf 100644
--- a/include/configs/ls1021aqds.h
+++ b/include/configs/ls1021aqds.h
@@ -570,7 +570,7 @@ unsigned long get_board_ddr_clk(void);
 
 #define CONFIG_BOOTDELAY   3
 
-#define CONFIG_SYS_QE_FW_ADDR 0x67f4
+#define CONFIG_SYS_QE_FW_ADDR 0x600c
 
 #ifdef CONFIG_LPUART
 #define CONFIG_EXTRA_ENV_SETTINGS   \
diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h
index 3299a9f..1eb0235 100644
--- a/include/configs/ls1021atwr.h
+++ b/include/configs/ls1021atwr.h
@@ -470,7 +470,7 @@
 #define CONFIG_SYS_MONITOR_BASE CONFIG_SYS_TEXT_BASE/* start of monitor */
 #endif
 
-#define CONFIG_SYS_QE_FW_ADDR 0x67f4
+#define CONFIG_SYS_QE_FW_ADDR 0x600c
 
 /*
  * Environment
-- 
2.1.0.27.g96db324

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

[U-Boot] [PATCH 3/3] qe: add qe support for ls1021a-twr board

[Zhao Qiang]

qe: add qe support MACRO to ls1021a-twr head file

Signed-off-by: Zhao Qiang 
---
 board/freescale/ls1021atwr/ls1021atwr.c | 7 +++
 include/configs/ls1021atwr.h| 6 ++
 2 files changed, 13 insertions(+)

diff --git a/board/freescale/ls1021atwr/ls1021atwr.c 
b/board/freescale/ls1021atwr/ls1021atwr.c
index b522ff2..da09d6e 100644
--- a/board/freescale/ls1021atwr/ls1021atwr.c
+++ b/board/freescale/ls1021atwr/ls1021atwr.c
@@ -16,6 +16,9 @@
 #include 
 #include 
 #include 
+#ifdef CONFIG_U_QE
+#include "../../../drivers/qe/qe.h"
+#endif
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -277,6 +280,10 @@ int board_init(void)
config_serdes_mux();
 #endif
 
+#ifdef CONFIG_U_QE
+   u_qe_init();
+#endif
+
return 0;
 }
 
diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h
index 45b2272..c4408b8 100644
--- a/include/configs/ls1021atwr.h
+++ b/include/configs/ls1021atwr.h
@@ -48,6 +48,10 @@
 
 #define CONFIG_SYS_HAS_SERDES
 
+#if !defined(CONFIG_SDCARD) && !defined(CONFIG_NAND) && !defined(CONFIG_SPI)
+#define CONFIG_U_QE
+#endif
+
 /*
  * IFC Definitions
  */
@@ -274,6 +278,8 @@
 
 #define CONFIG_SYS_MONITOR_BASE CONFIG_SYS_TEXT_BASE/* start of monitor */
 
+#define CONFIG_SYS_QE_FW_ADDR 0x600c
+
 /*
  * Environment
  */
-- 
2.1.0.27.g96db324

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

[U-Boot] [PATCH 2/3] qe: add qe support to ls1021aqds

[Zhao Qiang]

add qe support MACRO to ls1021aqds head file

Signed-off-by: Zhao Qiang 
---
 board/freescale/ls1021aqds/ls1021aqds.c | 8 
 include/configs/ls1021aqds.h| 6 ++
 2 files changed, 14 insertions(+)

diff --git a/board/freescale/ls1021aqds/ls1021aqds.c 
b/board/freescale/ls1021aqds/ls1021aqds.c
index 12e83f7..3bc4a68 100644
--- a/board/freescale/ls1021aqds/ls1021aqds.c
+++ b/board/freescale/ls1021aqds/ls1021aqds.c
@@ -16,6 +16,9 @@
 
 #include "../common/qixis.h"
 #include "ls1021aqds_qixis.h"
+#ifdef CONFIG_U_QE
+#include "../../../drivers/qe/qe.h"
+#endif
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -227,6 +230,11 @@ int board_init(void)
fsl_serdes_init();
config_serdes_mux();
 #endif
+
+#ifdef CONFIG_U_QE
+   u_qe_init();
+#endif
+
return 0;
 }
 
diff --git a/include/configs/ls1021aqds.h b/include/configs/ls1021aqds.h
index bb47813..ee23af4 100644
--- a/include/configs/ls1021aqds.h
+++ b/include/configs/ls1021aqds.h
@@ -69,6 +69,10 @@ unsigned long get_board_ddr_clk(void);
 
 #define CONFIG_SYS_HAS_SERDES
 
+#if !defined(CONFIG_SDCARD) && !defined(CONFIG_NAND) && !defined(CONFIG_SPI)
+#define CONFIG_U_QE
+#endif
+
 /*
  * IFC Definitions
  */
@@ -331,6 +335,8 @@ unsigned long get_board_ddr_clk(void);
 
 #define CONFIG_BOOTDELAY   3
 
+#define CONFIG_SYS_QE_FW_ADDR 0x600c
+
 #define CONFIG_EXTRA_ENV_SETTINGS  \
"bootargs=root=/dev/ram0 rw console=ttyS0,115200\0" \
"fdt_high=0xcfff\0" \
-- 
2.1.0.27.g96db324

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

Re: [U-Boot] [PATCH V2 2/4] remoteproc: Introduce a sandbox dummy driver

[Nishanth Menon]

On 21:46-20150901, Simon Glass wrote:
> On 27 August 2015 at 22:07, Nishanth Menon  wrote:
> 
[...]

> Reviewed-by: Simon Glass 

Thanks. will update and post the next rev with the mentioned changes
incorporated.

> 
> Nit below.
[...]

> > +
> > +/* XXX: THIS MUST GO AWAY ALONG WITH NON-DT support..  */
> 
> /* TODO(y...@email.com): Remove this along with... */

OK. Will add the details.

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

[U-Boot] [PATCH] arm: ls1021a: Add QSPI or IFC support in SD boot

[Alison Wang]

As QSPI and IFC are pin-multiplexed on LS1021A, only IFC is supported in
SD boot now. For the customer's demand, QSPI needs to be supported in SD
boot too.

This patch adds QSPI or IFC support in SD boot according to the
corresponding defconfig. For detail, ls1021atwr_sdcard_ifc_defconfig is
used to support IFC in SD boot and ls1021atwr_sdcard_qspi_defconfig is
used to support QSPI in SD boot.

Signed-off-by: Alison Wang 
---
 Makefile   |  4 
 board/freescale/ls1021atwr/MAINTAINERS |  3 ++-
 board/freescale/ls1021atwr/ls1021atwr.c| 14 +++---
 board/freescale/ls1021atwr/ls102xa_rcw_sd.cfg  | 14 --
 board/freescale/ls1021atwr/ls102xa_rcw_sd_ifc.cfg  |  8 
 board/freescale/ls1021atwr/ls102xa_rcw_sd_qspi.cfg |  8 
 configs/ls1021atwr_sdcard_defconfig|  7 ---
 configs/ls1021atwr_sdcard_ifc_defconfig|  6 ++
 configs/ls1021atwr_sdcard_qspi_defconfig   | 11 +++
 include/configs/ls1021atwr.h   | 17 ++---
 10 files changed, 60 insertions(+), 32 deletions(-)
 delete mode 100644 board/freescale/ls1021atwr/ls102xa_rcw_sd.cfg
 create mode 100644 board/freescale/ls1021atwr/ls102xa_rcw_sd_ifc.cfg
 create mode 100644 board/freescale/ls1021atwr/ls102xa_rcw_sd_qspi.cfg
 delete mode 100644 configs/ls1021atwr_sdcard_defconfig
 create mode 100644 configs/ls1021atwr_sdcard_ifc_defconfig
 create mode 100644 configs/ls1021atwr_sdcard_qspi_defconfig

diff --git a/Makefile b/Makefile
index 86a917f..beadc16 100644
--- a/Makefile
+++ b/Makefile
@@ -1120,7 +1120,11 @@ spl/u-boot-spl.pbl: spl/u-boot-spl.bin FORCE
$(call if_changed,mkimage)
 
 ifeq ($(ARCH),arm)
+ifdef CONFIG_DM
+UBOOT_BINLOAD := u-boot-dtb.img
+else
 UBOOT_BINLOAD := u-boot.img
+endif
 else
 UBOOT_BINLOAD := u-boot.bin
 endif
diff --git a/board/freescale/ls1021atwr/MAINTAINERS 
b/board/freescale/ls1021atwr/MAINTAINERS
index e9f6f0a..b997bb0 100644
--- a/board/freescale/ls1021atwr/MAINTAINERS
+++ b/board/freescale/ls1021atwr/MAINTAINERS
@@ -6,5 +6,6 @@ F:  include/configs/ls1021atwr.h
 F: configs/ls1021atwr_nor_defconfig
 F: configs/ls1021atwr_nor_SECURE_BOOT_defconfig
 F: configs/ls1021atwr_nor_lpuart_defconfig
-F: configs/ls1021atwr_sdcard_defconfig
+F: configs/ls1021atwr_sdcard_ifc_defconfig
+F: configs/ls1021atwr_sdcard_qspi_defconfig
 F: configs/ls1021atwr_qspi_defconfig
diff --git a/board/freescale/ls1021atwr/ls1021atwr.c 
b/board/freescale/ls1021atwr/ls1021atwr.c
index 228dbf8..9d3457b 100644
--- a/board/freescale/ls1021atwr/ls1021atwr.c
+++ b/board/freescale/ls1021atwr/ls1021atwr.c
@@ -175,7 +175,7 @@ struct cpld_data {
u8 rev2;/* Reserved */
 };
 
-#ifndef CONFIG_QSPI_BOOT
+#if !defined(CONFIG_QSPI_BOOT) && !defined(CONFIG_SD_BOOT_QSPI)
 static void convert_serdes_mux(int type, int need_reset);
 
 void cpld_show(void)
@@ -216,7 +216,7 @@ void cpld_show(void)
 int checkboard(void)
 {
puts("Board: LS1021ATWR\n");
-#ifndef CONFIG_QSPI_BOOT
+#if !defined(CONFIG_QSPI_BOOT) && !defined(CONFIG_SD_BOOT_QSPI)
cpld_show();
 #endif
 
@@ -380,7 +380,7 @@ int board_eth_init(bd_t *bis)
 }
 #endif
 
-#ifndef CONFIG_QSPI_BOOT
+#if !defined(CONFIG_QSPI_BOOT) && !defined(CONFIG_SD_BOOT_QSPI)
 int config_serdes_mux(void)
 {
struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
@@ -414,7 +414,7 @@ int config_serdes_mux(void)
 }
 #endif
 
-#ifndef CONFIG_QSPI_BOOT
+#if !defined(CONFIG_QSPI_BOOT) && !defined(CONFIG_SD_BOOT_QSPI)
 int config_board_mux(void)
 {
struct cpld_data *cpld_data = (void *)(CONFIG_SYS_CPLD_BASE);
@@ -627,7 +627,7 @@ int board_init(void)
 {
 #ifndef CONFIG_SYS_FSL_NO_SERDES
fsl_serdes_init();
-#ifndef CONFIG_QSPI_BOOT
+#if !defined(CONFIG_QSPI_BOOT) && !defined(CONFIG_SD_BOOT_QSPI)
config_serdes_mux();
 #endif
 #endif
@@ -657,7 +657,7 @@ int misc_init_r(void)
 #ifdef CONFIG_FSL_DEVICE_DISABLE
device_disable(devdis_tbl, ARRAY_SIZE(devdis_tbl));
 #endif
-#ifndef CONFIG_QSPI_BOOT
+#if !defined(CONFIG_QSPI_BOOT) && !defined(CONFIG_SD_BOOT_QSPI)
config_board_mux();
 #endif
 
@@ -706,7 +706,7 @@ u16 flash_read16(void *addr)
return (((val) >> 8) & 0x00ff) | (((val) << 8) & 0xff00);
 }
 
-#ifndef CONFIG_QSPI_BOOT
+#if !defined(CONFIG_QSPI_BOOT) && !defined(CONFIG_SD_BOOT_QSPI)
 static void convert_flash_bank(char bank)
 {
struct cpld_data *cpld_data = (void *)(CONFIG_SYS_CPLD_BASE);
diff --git a/board/freescale/ls1021atwr/ls102xa_rcw_sd.cfg 
b/board/freescale/ls1021atwr/ls102xa_rcw_sd.cfg
deleted file mode 100644
index 9c3e3b0..000
--- a/board/freescale/ls1021atwr/ls102xa_rcw_sd.cfg
+++ /dev/null
@@ -1,14 +0,0 @@
-#PBL preamble and RCW header
-aa55aa55 01ee0100
-
-#enable IFC, disable QSPI and DSPI
-0608000a   
-2000 00407900 60040a00 21046000
-  

Re: [U-Boot] [PATCH] mmc: atmel: Add support fo atmel sdhci

[Yang, Wenyou]

Hi Shen Bo,

Thanks a lot for your advice.
No problem, They will be added in next version.

Thanks

Best Regards,
Wenyou Yang

> -Original Message-
> From: Bo Shen [mailto:voice.s...@gmail.com]
> Sent: 2015年9月17日 7:02
> To: Yang, Wenyou; U-Boot Mailing List
> Cc: Pantelis Antoniou
> Subject: Re: [U-Boot] [PATCH] mmc: atmel: Add support fo atmel sdhci
> 
> Hi Wenyou,
> 
> On 09/16/2015 04:23 PM, Wenyou Yang wrote:
> 
> I think you should add commit message here.
> 
> > Signed-off-by: Wenyou Yang 
> > ---
> >
> >   arch/arm/mach-at91/include/mach/atmel_sdhci.h |   13 +
> >   drivers/mmc/Makefile  |1 +
> >   drivers/mmc/atmel_sdhci.c |   35
> +
> >   3 files changed, 49 insertions(+)
> >   create mode 100644 arch/arm/mach-at91/include/mach/atmel_sdhci.h
> >   create mode 100644 drivers/mmc/atmel_sdhci.c
> >
> > diff --git a/arch/arm/mach-at91/include/mach/atmel_sdhci.h
> > b/arch/arm/mach-at91/include/mach/atmel_sdhci.h
> > new file mode 100644
> > index 000..cf3bf89
> > --- /dev/null
> > +++ b/arch/arm/mach-at91/include/mach/atmel_sdhci.h
> > @@ -0,0 +1,13 @@
> > +/*
> > + * Copyright (c) 2015 Atmel Corporation
> > + *   Wenyou.Yang 
> > + *
> > + * SPDX-License-Identifier:GPL-2.0+
> > + */
> > +
> > +#ifndef__ATMEL_SDHCI_H
> > +#define__ATMEL_SDHCI_H
> > +
> > +int atmel_sdhci_init(void *regbase, u32 id);
> > +
> > +#endif
> > diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile index
> > 99d0295..5d35705 100644
> > --- a/drivers/mmc/Makefile
> > +++ b/drivers/mmc/Makefile
> > @@ -8,6 +8,7 @@
> >   obj-$(CONFIG_DM_MMC) += mmc-uclass.o
> >
> >   obj-$(CONFIG_ARM_PL180_MMCI) += arm_pl180_mmci.o
> > +obj-$(CONFIG_ATMEL_SDHCI) += atmel_sdhci.o
> >   obj-$(CONFIG_BCM2835_SDHCI) += bcm2835_sdhci.o
> >   obj-$(CONFIG_BFIN_SDH) += bfin_sdh.o
> >   obj-$(CONFIG_DAVINCI_MMC) += davinci_mmc.o diff --git
> > a/drivers/mmc/atmel_sdhci.c b/drivers/mmc/atmel_sdhci.c new file mode
> > 100644 index 000..64776a1
> > --- /dev/null
> > +++ b/drivers/mmc/atmel_sdhci.c
> > @@ -0,0 +1,35 @@
> > +/*
> > + * Copyright (C) 2015 Atmel Corporation
> > + *   Wenyou.Yang 
> > + *
> > + * SPDX-License-Identifier:GPL-2.0+
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define ATMEL_SDHC_MIN_FRQ 40
> 
> Nit: maybe FREQ is better than FRQ?
> 
> > +
> > +int atmel_sdhci_init(void *regbase, u32 id) {
> > +   struct sdhci_host *host = NULL;
> > +   u32 max_clk, min_clk = ATMEL_SDHC_MIN_FRQ;
> > +
> > +   host = (struct sdhci_host *)malloc(sizeof(struct sdhci_host));
> 
> How about "host = malloc(sizeof(*host));"?
> 
> > +   if (!host) {
> > +   printf("atmel_sdhci_init: sdhci_host malloc fail\n");
> > +   return -1;
> 
> Maybe use -ENOMEM replace -1?
> 
> > +   }
> > +
> > +   host->name = "atmel_sdhci";
> > +   host->ioaddr = (void *)regbase;
> > +   host->quirks = 0;
> > +   host->version = sdhci_readw(host, SDHCI_HOST_VERSION);
> > +   max_clk = at91_get_periph_generated_clk(id);
> 
> As we discussed with your patch for "at91_get_periph_generated_clk", this
> function may failed. So, I think you need add error check here.
> 
> > +   add_sdhci(host, max_clk, min_clk);
> > +
> > +   return 0;
> > +}
> >
> 
> Best Regards,
> Bo Shen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot