Re: [U-Boot] U-Boot load and run via NAND flash - ARM926EJ-S

[N Cheung]

I presume you system will have SDRAM and execution is from SDRAM.  I did a
port to an Atmel 9260 with only NAND flash (for bootstrap, bootloader, RFS).
The only issue with NAND is dealing with bad blocks.  There are many ways to
work this.  One example:
1. bootstrap - I put it in the first block as it guarantees good by
manufacturer.  ATmel's bootstrap will skip to next block when reading u-boot
into SDRAM for execution
2. RFS - Initially I tried read/writeable FS with bad block management like
JFFS2 but performance was bad.  I end up using CRAMFS on top of UBI in a
read only RFS partition and a small JFFS2 for RW.

Hope this helps.
Norman



Thomas Jackson wrote:
> 
> Hi List,
> I understand NOR-based flash memory devices have traditionally been used
> for non-volatile storage for a bootloader and other various advantages
> including support for execute-in-place code, random access to memory, and
> zero error rate, etc.  However, we have a project that we would like to
> have U-Boot bootloader run via NAND Flash memory device on a ARM926EJ-S
> based board.  I searched the mailing list for this and didn't see
> anything.  I only found a question posted in 2006 where it was asked if
> the kernel based on ARM926EJ-S can boot from NAND flash.  Which I know is
> ok.   Does the community know of any existing mechanisms for this type of
> configuration to enable U-Boot load and run via NAND flash?
> 
> Thanks in advance!
> TJ
>
> 

-- 
View this message in context: 
http://www.nabble.com/U-Boot-load-and-run-via-NAND-flash---ARM926EJ-S-tp25484494p25486169.html
Sent from the Uboot - Users 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] [TESTING PATCH] ppc: Relocation test patch

[Joakim Tjernlund]

>
> When preparing the ppc relocation patches I noticed that the gcc
> -mrelocatable compiler flag increases the .reloc section by 3 or 4
> Kbytes.  I did a compile test, and this increase pushes the ALPR board
> back over 256K (it recently had the same size issue, see "ppc4xx: Remove
> some features from ALPR to fit into 256k again").  No other boards
> appear to break size-wise.
>
> So I guess I had 2 questions:
> 1. Is enabling proper relocation worth the 3/4KB that will be added to
> every ppc binary?  I personally think so as the manual relocation fixups
> that currently litter the code can be removed and true relocation is
> much less hokey in the long run.  X-ES's U-Boot binaries also are
> generally much smaller than their allocated 512KB, so this increase
> doesn't affect me much:)

You can get some of this space back by just #ifdef:ing out the manual relocation
code. Removing it completely is OK by me though.

The size can be further decreased by looking over the use of global data:
- Some tables can be replaced by code.
- Combine several global variables into one struct variable.
- reducing string literals

One day we can fit the whole relocation table into built-in CPU memory, 
hopefully
that will make it possible to make u-boot a true PIC exe

 Jocke

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

Re: [U-Boot] [PATCH v4 3/4]: Define ffs/fls for all architectures

[Simon Kagstrom]

On Thu, 17 Sep 2009 08:56:08 +0200

> > Yes, the patch should have contained something like that. Well, we'll
> > have to cook up a fix for this then. Sorry about that again.
> 
> Simon, could you do this please?

Yes, absolutely. I'll try to have it done by this afternoon.

> And btw:
> 
> #ifndef __set_bit
> # define __set_bit generic_set_bit
> #endif
> 
> looks fishy too. Please fix this one as well.

Yes, I know about that issue as well. It will go in the same patch.

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

Re: [U-Boot] [PATCH v4 3/4]: Define ffs/fls for all architectures

[Stefan Roese]

On Thursday 17 September 2009 09:13:48 Simon Kagstrom wrote:
> > > Yes, the patch should have contained something like that. Well, we'll
> > > have to cook up a fix for this then. Sorry about that again.
> >
> > Simon, could you do this please?
> 
> Yes, absolutely. I'll try to have it done by this afternoon.
> 
> > And btw:
> >
> > #ifndef __set_bit
> > # define __set_bit generic_set_bit
> > #endif
> >
> > looks fishy too. Please fix this one as well.
> 
> Yes, I know about that issue as well. It will go in the same patch.

Thanks. :)
 
Cheers,
Stefan

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

[U-Boot] imx27lite stability problems.

[javier Martin]

I have tried u-boot for the imx27lite board from LogicPD which is
currently in u-boot-arm repository and I have experienced some
stability problems:
- Sometimes the system gets stuck in serial_getc() from serial_mxc.c
driver when printing information (ex. mii read ).
- Pings do not work properly, the system gets stuck in fec_send()
function waiting always for a frame to be sent (which actually does
not happen).
- Sometimes the system gets stuck when saving the environment to flash
'saveenv', but other times it does it well.

I would like to help to solve this problems, but I don't know exactly
where to begin from. I have been reviewing clock settings. Could this
be happening because this board is using 32KHz xtal as reference
instead of 26MHz one?

Have you experienced these problems also?

Thank you.

-- 
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] U-Boot load and run via NAND flash - ARM926EJ-S

[Wolfgang Denk]

Dear Thomas Jackson,

In message <25484494.p...@talk.nabble.com> you wrote:
> 
> I understand NOR-based flash memory devices have traditionally been used for
> non-volatile storage for a bootloader and other various advantages including
> support for execute-in-place code, random access to memory, and zero error
> rate, etc.  However, we have a project that we would like to have U-Boot
> bootloader run via NAND Flash memory device on a ARM926EJ-S based board.  I
> searched the mailing list for this and didn't see anything.  I only found a

I have no idea how you performed that search, but it seems you have a
special aptitude to avoid all the obvious hits.

> question posted in 2006 where it was asked if the kernel based on ARM926EJ-S
> can boot from NAND flash.  Which I know is ok.   Does the community know of
> any existing mechanisms for this type of configuration to enable U-Boot load
> and run via NAND flash?

It's a standard feature and available on many (most?) boards that
support booting from NAND. Dunno if this includes AT91 boards.

Jean-Christophe should be able to answer this, but he is currently
off this planet.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Anyone can count the seeds in an apple.
No one can count the apples in a seed.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [TESTING PATCH] ppc: Relocation test patch

[Wolfgang Denk]

Dear Joakim Tjernlund,

In message 
 you 
wrote:
>
> One day we can fit the whole relocation table into built-in CPU memory, 
> hopefully
> that will make it possible to make u-boot a true PIC exe

Why is the former the prerequisite for the latter?

Best regards,

Wolfgang Denk

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

Re: [U-Boot] imx27lite stability problems.

[Wolfgang Denk]

Dear javier Martin,

In message  you 
wrote:
> I have tried u-boot for the imx27lite board from LogicPD which is
> currently in u-boot-arm repository and I have experienced some
> stability problems:
> - Sometimes the system gets stuck in serial_getc() from serial_mxc.c
> driver when printing information (ex. mii read ).
> - Pings do not work properly, the system gets stuck in fec_send()
> function waiting always for a frame to be sent (which actually does
> not happen).
> - Sometimes the system gets stuck when saving the environment to flash
> 'saveenv', but other times it does it well.

We don't see any such issues on the board we have here in the lab.

> I would like to help to solve this problems, but I don't know exactly
> where to begin from. I have been reviewing clock settings. Could this
> be happening because this board is using 32KHz xtal as reference
> instead of 26MHz one?

Yes, of course this could be a problem. Is this an original LogicPD
board?  Did you adapt the code for the different clock speed? What
exactly did you change?

> Have you experienced these problems also?

No, we didn't.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Monday is an awful way to spend one seventh of your life.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] fsl_i2c: Impl. AN2819, rev 5 to calculate FDR/DFSR

[Wolfgang Denk]

Dear Joakim Tjernlund,

In message 
 you 
wrote:
> 
> > > +   u8 dfsr, fdr = 0x31; /* Default if no FDR found */
> > > +   unsigned short A, B, Ga, Gb;
> >
> > Please do not use mixed-case variables, thanks.
> 
> A and B are from the AN2819 spec and I used the same names to ease
> identify with the spec. I rather keep them.

Feel free to add a comment to explain the relation, but please use
only lower-case identifiers.

...
> Like so?
> for(Ga = 0x4, A = 10; A <= 30; Ga++, A += 2) {

Please also here:

for (...)


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
It's certainly  convenient  the  way  the  crime  (or  condition)  of
stupidity   carries   with   it  its  own  punishment,  automatically
admisistered without remorse, pity, or prejudice. :-)
 -- Tom Christiansen in <559seq$ag...@csnews.cs.colorado.edu>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] fsl_i2c: Impl. AN2819, rev 5 to calculate FDR/DFSR

[Heiko Schocher]

Hello Joakim,

Joakim Tjernlund wrote:
> Heiko Schocher  wrote on 17/09/2009 08:00:34:
> 
>> Hello Joakim,
> 
> Hi Heiko
> 
>> Joakim Tjernlund wrote:
>>> The latest AN2819 has changed the way FDR/DFSR should be calculated.
>>> Update the driver according to spec. However, Condition 2
>>> is not accounted for as it is not clear how to do so.
>> Thanks for your work, just some minor Codingstyle comments:
>>
>>> Signed-off-by: Joakim Tjernlund 
>>> ---
>>>  drivers/i2c/fsl_i2c.c |   88 
>>> +---
>>>  1 files changed, 53 insertions(+), 35 deletions(-)
>>>
>>> diff --git a/drivers/i2c/fsl_i2c.c b/drivers/i2c/fsl_i2c.c
>>> index 0c5f6be..0491a69 100644
>>> --- a/drivers/i2c/fsl_i2c.c
>>> +++ b/drivers/i2c/fsl_i2c.c
>>> @@ -100,29 +100,9 @@ static const struct fsl_i2c *i2c_dev[2] = {
> 
>>>  #ifdef __PPC__
>>> - u8 dfsr;
>>> +   u8 dfsr, fdr = 0x31; /* Default if no FDR found */
>>> +   unsigned short A, B, Ga, Gb;
>> Please do not use mixed-case variables, thanks.
> 
> A and B are from the AN2819 spec and I used the same names to ease
> identify with the spec. I rather keep them.

I am fine with that, just please do not mix upper and
lower case in one variable name. So please use "ga" and
"gb" ...

>>> +   unsigned long c_div, est_div;
>>> +
>>>  #ifdef CONFIG_FSL_I2C_CUSTOM_DFSR
>>> - dfsr = CONFIG_FSL_I2C_CUSTOM_DFSR;
>>> +   dfsr = CONFIG_FSL_I2C_CUSTOM_DFSR;
>>>  #else
>>> - dfsr = fsl_i2c_speed_map[i].dfsr;
>>> -#endif
>>> - writeb(dfsr, &dev->dfsrr);   /* set default filter */
>>> +   /* Condition 1: dfsr <= 50/T */
>>> +   dfsr = (5*(i2c_clk/1000))/(10);
>> Please use one space around (on each side of) most binary
>> and ternary operators.
> 
> Like so?
> dfsr = (5 * (i2c_clk / 1000)) / 10);

Yep.

>>>  #endif
>>>  #ifdef CONFIG_FSL_I2C_CUSTOM_FDR
>>> - fdr = CONFIG_FSL_I2C_CUSTOM_FDR;
>>> - speed = i2c_clk / divider; /* Fake something */
>>> +   fdr = CONFIG_FSL_I2C_CUSTOM_FDR;
>>> +   speed = i2c_clk / divider; /* Fake something */
>>>  #else
>>> +   debug("Requested speed:%d, i2c_clk:%d\n", speed, i2c_clk);
>>> +   if (!dfsr)
>>> +  dfsr = 1;
>>> +
>>> +   est_div = ~0;
>>> +   for(Ga=0x4, A=10; A<=30; Ga++, A+=2) {
>> spaces her too.
> Like so?
> for(Ga = 0x4, A = 10; A <= 30; Ga++, A += 2) {

for (Ga = 0x4, A = 10; A <= 30; Ga++, A += 2) {

>>> +  for (Gb=0; Gb<8; Gb++) {
>> and here too. Please check the whole patch.
>>
>>> + B = 16 << Gb;
>>> + c_div = B * (A + ((3*dfsr)/B)*2);
>>> + if (c_div > divider && c_div < est_div) {
>> Can we make
>>
>> if ((c_div > divider) && (c_div < est_div)) {
> 
> Sure.

Thanks!

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

Re: [U-Boot] imx27lite stability problems.

[javier Martin]

2009/9/17 Wolfgang Denk :
> Dear javier Martin,
>
> In message  you 
> wrote:
>> I have tried u-boot for the imx27lite board from LogicPD which is
>> currently in u-boot-arm repository and I have experienced some
>> stability problems:
>> - Sometimes the system gets stuck in serial_getc() from serial_mxc.c
>> driver when printing information (ex. mii read ).
>> - Pings do not work properly, the system gets stuck in fec_send()
>> function waiting always for a frame to be sent (which actually does
>> not happen).
>> - Sometimes the system gets stuck when saving the environment to flash
>> 'saveenv', but other times it does it well.
>
> We don't see any such issues on the board we have here in the lab.
>
>> I would like to help to solve this problems, but I don't know exactly
>> where to begin from. I have been reviewing clock settings. Could this
>> be happening because this board is using 32KHz xtal as reference
>> instead of 26MHz one?
>
> Yes, of course this could be a problem. Is this an original LogicPD
> board?  Did you adapt the code for the different clock speed? What
> exactly did you change?

Sorry, I am not trying it on an original LogicPD board. Our board is
based in i.mx27 ipcam. We have a different phy which is in 0x0 address
instead of 0x1F and we have also a different NOR flash model. We have
also the external 32KHz xtal at 32.768 KHz.

- The init code for our sdram is different as we have different model
and memory configuration, however I made a memory test and all seems
fine.
- I adapted NOR flash configuration and PHY_ADDRESS only, and
experienced the previous problems. I could expect issues with NOR
flash but I don't know why I could have any issue with ethernet.


>
>> Have you experienced these problems also?
>
> No, we didn't.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
> Monday is an awful way to spend one seventh of your life.
>



-- 
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [TESTING PATCH] ppc: Relocation test patch

[Joakim Tjernlund]

Wolfgang Denk  wrote on 17/09/2009 09:50:51:
>
> Dear Joakim Tjernlund,
>
> In message  00270...@transmode.se> you wrote:
> >
> > One day we can fit the whole relocation table into built-in CPU memory, 
> > hopefully
> > that will make it possible to make u-boot a true PIC exe
>
> Why is the former the prerequisite for the latter?

Some time ago I looked into making u-boot PIC and I came to the conclusion
that one must be able to modify the GOT table before we have relocated to RAM.
Perhaps there is another way but didn't see it at the time, maybe there is some
"hidden" option to gcc that I missed.
The main problem are all those string literals, these are in the fixup table
and one wants to use printf and friends before relocation to RAM.

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

[U-Boot] [PATCH 2/3] fsl_i2c: Add CONFIG_FSL_I2C_CUSTOM_{DFSR/FDR}

[Joakim Tjernlund]

Some boards need a higher DFSR value than the spec currently
recommends so give these boards the means to define there own.

For completeness, add CONFIG_FSL_I2C_CUSTOM_FDR too.

Signed-off-by: Joakim Tjernlund 
---
 drivers/i2c/fsl_i2c.c |   14 +++---
 1 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/fsl_i2c.c b/drivers/i2c/fsl_i2c.c
index 56f9680..0c5f6be 100644
--- a/drivers/i2c/fsl_i2c.c
+++ b/drivers/i2c/fsl_i2c.c
@@ -172,14 +172,22 @@ static unsigned int set_i2c_bus_speed(const struct 
fsl_i2c *dev,
u8 fdr;
 #ifdef __PPC__
u8 dfsr;
+#ifdef CONFIG_FSL_I2C_CUSTOM_DFSR
+   dfsr = CONFIG_FSL_I2C_CUSTOM_DFSR;
+#else
dfsr = fsl_i2c_speed_map[i].dfsr;
 #endif
+   writeb(dfsr, &dev->dfsrr);  /* set default filter */
+#endif
+#ifdef CONFIG_FSL_I2C_CUSTOM_FDR
+   fdr = CONFIG_FSL_I2C_CUSTOM_FDR;
+   speed = i2c_clk / divider; /* Fake something */
+#else
fdr = fsl_i2c_speed_map[i].fdr;
speed = i2c_clk / fsl_i2c_speed_map[i].divider;
-   writeb(fdr, &dev->fdr); /* set bus speed */
-#ifdef __PPC__
-   writeb(dfsr, &dev->dfsrr);  /* set default filter */
 #endif
+   writeb(fdr, &dev->fdr); /* set bus speed */
+
break;
}
 
-- 
1.6.4.3

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

[U-Boot] [PATCH 3/3] fsl_i2c: Impl. AN2919, rev 5 to calculate FDR/DFSR

[Joakim Tjernlund]

The latest AN2919 has changed the way FDR/DFSR should be calculated.
Update the driver according to spec. However, Condition 2
is not accounted for as it is not clear how to do so.

Signed-off-by: Joakim Tjernlund 
---
 drivers/i2c/fsl_i2c.c |   90 ++---
 1 files changed, 55 insertions(+), 35 deletions(-)

diff --git a/drivers/i2c/fsl_i2c.c b/drivers/i2c/fsl_i2c.c
index 0c5f6be..78f21c7 100644
--- a/drivers/i2c/fsl_i2c.c
+++ b/drivers/i2c/fsl_i2c.c
@@ -100,29 +100,9 @@ static const struct fsl_i2c *i2c_dev[2] = {
  */
 static const struct {
unsigned short divider;
-#ifdef __PPC__
-   u8 dfsr;
-#endif
u8 fdr;
 } fsl_i2c_speed_map[] = {
-#ifdef __PPC__
-   {160, 1, 32}, {192, 1, 33}, {224, 1, 34}, {256, 1, 35},
-   {288, 1, 0}, {320, 1, 1}, {352, 6, 1}, {384, 1, 2}, {416, 6, 2},
-   {448, 1, 38}, {480, 1, 3}, {512, 1, 39}, {544, 11, 3}, {576, 1, 4},
-   {608, 22, 3}, {640, 1, 5}, {672, 32, 3}, {704, 11, 5}, {736, 43, 3},
-   {768, 1, 6}, {800, 54, 3}, {832, 11, 6}, {896, 1, 42}, {960, 1, 7},
-   {1024, 1, 43}, {1088, 22, 7}, {1152, 1, 8}, {1216, 43, 7}, {1280, 1, 9},
-   {1408, 22, 9}, {1536, 1, 10}, {1664, 22, 10}, {1792, 1, 46},
-   {1920, 1, 11}, {2048, 1, 47}, {2176, 43, 11}, {2304, 1, 12},
-   {2560, 1, 13}, {2816, 43, 13}, {3072, 1, 14}, {3328, 43, 14},
-   {3584, 1, 50}, {3840, 1, 15}, {4096, 1, 51}, {4608, 1, 16},
-   {5120, 1, 17}, {6144, 1, 18}, {7168, 1, 54}, {7680, 1, 19},
-   {8192, 1, 55}, {9216, 1, 20}, {10240, 1, 21}, {12288, 1, 22},
-   {14336, 1, 58}, {15360, 1, 23}, {16384, 1, 59}, {18432, 1, 24},
-   {20480, 1, 25}, {24576, 1, 26}, {28672, 1, 62}, {30720, 1, 27},
-   {32768, 1, 63}, {36864, 1, 28}, {40960, 1, 29}, {49152, 1, 30},
-   {61440, 1, 31}, {-1, 1, 31}
-#elif defined(__M68K__)
+#ifdef __M68K__
{20, 32}, {22, 33}, {24, 34}, {26, 35},
{28, 0}, {28, 36}, {30, 1}, {32, 37},
{34, 2}, {36, 38}, {40, 3}, {40, 39},
@@ -158,7 +138,6 @@ static unsigned int set_i2c_bus_speed(const struct fsl_i2c 
*dev,
unsigned int i2c_clk, unsigned int speed)
 {
unsigned short divider = min(i2c_clk / speed, (unsigned short) -1);
-   unsigned int i;
 
/*
 * We want to choose an FDR/DFSR that generates an I2C bus speed that
@@ -166,31 +145,72 @@ static unsigned int set_i2c_bus_speed(const struct 
fsl_i2c *dev,
 * want the first divider that is equal to or greater than the
 * calculated divider.
 */
-
-   for (i = 0; i < ARRAY_SIZE(fsl_i2c_speed_map); i++)
-   if (fsl_i2c_speed_map[i].divider >= divider) {
-   u8 fdr;
 #ifdef __PPC__
-   u8 dfsr;
+   u8 dfsr, fdr = 0x31; /* Default if no FDR found */
+   /* a, b and dfsr matches identifiers A,B and C respectively in AN2919 */
+   unsigned short a, b, ga, gb;
+   unsigned long c_div, est_div;
+
 #ifdef CONFIG_FSL_I2C_CUSTOM_DFSR
-   dfsr = CONFIG_FSL_I2C_CUSTOM_DFSR;
+   dfsr = CONFIG_FSL_I2C_CUSTOM_DFSR;
 #else
-   dfsr = fsl_i2c_speed_map[i].dfsr;
-#endif
-   writeb(dfsr, &dev->dfsrr);  /* set default filter */
+   /* Condition 1: dfsr <= 50/T */
+   dfsr = (5 * (i2c_clk / 1000)) / 10;
 #endif
 #ifdef CONFIG_FSL_I2C_CUSTOM_FDR
-   fdr = CONFIG_FSL_I2C_CUSTOM_FDR;
-   speed = i2c_clk / divider; /* Fake something */
+   fdr = CONFIG_FSL_I2C_CUSTOM_FDR;
+   speed = i2c_clk / divider; /* Fake something */
 #else
+   debug("Requested speed:%d, i2c_clk:%d\n", speed, i2c_clk);
+   if (!dfsr)
+   dfsr = 1;
+
+   est_div = ~0;
+   for (ga = 0x4, a = 10; a <= 30; ga++, a += 2) {
+   for (gb = 0; gb < 8; gb++) {
+   b = 16 << gb;
+   c_div = b * (a + ((3*dfsr)/b)*2);
+   if ((c_div > divider) && (c_div < est_div)) {
+   unsigned short bin_gb, bin_ga;
+
+   est_div = c_div;
+   bin_gb = gb << 2;
+   bin_ga = (ga & 0x3) | ((ga & 0x4) << 3);
+   fdr = bin_gb | bin_ga;
+   speed = i2c_clk / est_div;
+   debug("FDR:0x%.2x, div:%ld, ga:0x%x, gb:0x%x, "
+ "a:%d, b:%d, speed:%d\n",
+ fdr, est_div, ga, gb, a, b, speed);
+   /* Condition 2 not accounted for */
+   debug("Tr <= %d ns\n", 
+ (b - 3 * dfsr) * 100 /
+ (i2c_clk / 1000));
+   }
+   }
+   if (a == 20)
+   a += 2;
+   if (a == 24)
+

[U-Boot] [PATCH 1/3] fsl_i2c: Wait for STOP condition to propagate

[Joakim Tjernlund]

After issuing a STOP one must wait until the STOP has completed
on the bus before doing something new to the controller.

Also add an extra read of SR as the manual mentions doing that
is a good idea.

Remove surplus write of CR just before a write, isn't required and
could potentially disturb the I2C bus.

Signed-off-by: Joakim Tjernlund 
---
 drivers/i2c/fsl_i2c.c |   12 
 1 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/i2c/fsl_i2c.c b/drivers/i2c/fsl_i2c.c
index 47bbf79..56f9680 100644
--- a/drivers/i2c/fsl_i2c.c
+++ b/drivers/i2c/fsl_i2c.c
@@ -223,7 +223,7 @@ i2c_init(int speed, int slaveadd)
 #endif
 }
 
-static __inline__ int
+static int
 i2c_wait4bus(void)
 {
unsigned long long timeval = get_ticks();
@@ -248,6 +248,8 @@ i2c_wait(int write)
csr = readb(&i2c_dev[i2c_bus_num]->sr);
if (!(csr & I2C_SR_MIF))
continue;
+   /* Read again to allow register to stabilise */
+   csr = readb(&i2c_dev[i2c_bus_num]->sr);
 
writeb(0x0, &i2c_dev[i2c_bus_num]->sr);
 
@@ -293,9 +295,6 @@ __i2c_write(u8 *data, int length)
 {
int i;
 
-   writeb(I2C_CR_MEN | I2C_CR_MSTA | I2C_CR_MTX,
-  &i2c_dev[i2c_bus_num]->cr);
-
for (i = 0; i < length; i++) {
writeb(data[i], &i2c_dev[i2c_bus_num]->dr);
 
@@ -351,6 +350,9 @@ i2c_read(u8 dev, uint addr, int alen, u8 *data, int length)
&& i2c_write_addr(dev, I2C_READ_BIT, 1) != 0)
i = __i2c_read(data, length);
 
+   if (length && i2c_wait4bus()) /* Wait until STOP */
+   debug("i2c_read: wait4bus timed out\n");
+
writeb(I2C_CR_MEN, &i2c_dev[i2c_bus_num]->cr);
 
if (i == length)
@@ -372,6 +374,8 @@ i2c_write(u8 dev, uint addr, int alen, u8 *data, int length)
}
 
writeb(I2C_CR_MEN, &i2c_dev[i2c_bus_num]->cr);
+   if (i2c_wait4bus()) /* Wait until STOP */
+   debug("i2c_write: wait4bus timed out\n");
 
if (i == length)
return 0;
-- 
1.6.4.3

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

Re: [U-Boot] lowlevel_init.s for ARM920t/S3C2410

[kevin.morf...@fearnside-systems.co.uk]

J.Hwan.Kim wrote:
> Hi, everyone
> 
> I'm running u-boot (2009.03) in S3C2410 board now.
> But I have a problem.
> 
> It seems that "bl lowlevel_init" routine in ARM920t/start.s is not working.
> The label, lowlevel_init, is  defined as global label in 
> /board/samsung/s3c2410/lowlevel_init.s
> and is seen system.map file.
> 
> I think the code does not jump to lowlevel_init in 
> /board/samsung/s3c2410/lowlevel_init.S from start.S
> When I copy lowlevel_init subroutine into ARM920t/start.S instead of "bl 
> lowlevel_init",
> it does work.
> 
> Why does the "bl lowlevel_init" not work?
> 
> How can  I solve this problem ?
> 
> Thanks in advance.
> 
> Regards,
> J.Hwan Kim
> 
> 
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
> 

Hi

I wonder if your board is booting from NAND flash? If it is, then at start-up
the s3c2410's Steppingstone feature will read a 4Kb block of data from the base
of NAND flash to the base of RAM bank 0 then jump to the base of that RAM bank.
The idea is that the first 4Kb of the code in NAND flash should contain a small
code loader that initialises the NAND flash controller, reads the rest of the
code from NAND flash into RAM, and then executes it. This will only work if the
whole of this code loader is forced into the first 4Kb at link time.

Unfortunately u-boot for s3c2410 doesn't support this at the moment, it only
really supports booting from NOR flash. I've just done a build for the s3c2410x
board and looking at the link map the start.S code is located at the linker base
address of 0x33f8, but lowlevel_init.S is linked at 0x33f91610, so
lowlevel_init.S isn't in the first 4Kb of the u-boot image and it won't get
loaded into RAM at start-up. When the Steppingstone function loads the first
4Kb of NAND flash into RAM at start-up it will have loaded start.S but not
lowlevel_init.S, so when start.S branches to the RAM address where lowlevel_init
should be lowlevel_init won't be there and it will crash.

When you copied lowlevel_init into start.S the "bl lowlevel_init" worked because
this forced it to be linked into the bottom 4Kb of code, but I'm guessing that
u-boot still didn't work because u-boot for s3c2410 doesn't contain any code
that reads the rest of u-boot from NAND flash to RAM

The simplest way around this would be to load u-boot into NOR flash and
configure the board jumpers to boot from NOR flash, not NAND flash. Then u-boot
would just copy itself from NOR flash to RAM at start-up and would boot 
normally.

Alternatively, I have seen some unofficial u-boot ports for s3c24x0 cpu's that
do support u-boot booting from NAND flash but I don't have the source code for 
them.

Regards
Kevin Morfitt


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

[U-Boot] Compilation error for fw_printenv

[Rahanesh]

Hi All,

While trying to compile fw_printenv under tools/env directory of u-boot 
i am getting the following error:

fw_env.c:34:27: error: linux/mtd/mtd.h: No such file or directory
fw_env.c: In function fw_printenv:
fw_env.c: In function flash_io:
fw_env.c:390: error: erase_info_t undeclared (first use in this function)
fw_env.c:390: error: (Each undeclared identifier is reported only once
fw_env.c:390: error: for each function it appears in.)
fw_env.c:390: error: expected  before erase
fw_env.c:421: error: erase undeclared (first use in this function)
fw_env.c:423: error: MEMUNLOCK undeclared (first use in this function)
fw_env.c:462: error: MEMERASE undeclared (first use in this function)
fw_env.c:519: error: MEMLOCK undeclared (first use in this function)
make: *** [fw_printenv] Error 1

How can i solve this? I a very new to Linux Environment.

Thanks
Rahanesh



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

Re: [U-Boot] error in fw_printenv

[Rahanesh]

Hi Wolfgang,

> Well, that most certainly means that your /dev/mtd0 is not a NOR or
> NAND flash device.
>
>   
   Now used the fw_printenv under tools/env directory of uboot. It 
does not have IOCTL error.
 
On issuing a fw_printenv it showd following messages
 
 Bad data CRC, Using default environment and printed only few 
environment variables.

  Then i did a fw_setenv bootdelay 6. It showed some messgaes of 
erasing flash. But it actually erased my uboot itself.

  What might be the issue? config file?

   MTD device name   Device offset   Env. sizeFlash 
sector size   Number of sectors
/dev/mtd00x   
0x1000   0x1


What does Device Offset mean?

/dev/mtd0 has both uboot as well as  environment variables. Environment 
variables lie at bottom of /dev/mtd0. Is that the meaning of device offset?

   #define CFG_ENV_ADDR0xAD03F000   (Flash starts at 0xAD00)
   #define CFG_ENV_SIZE0x1000
   #define CFG_ENV_SECT_SIZE   0x1


These are the macro that i found in include/configs/board.h

Please help

Thanks
Rahanesh




 
   

  
  
 


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

Re: [U-Boot] I found an error

[Minkyu Kang]

Dear Sun, Peng

2009/9/16 Sun, Peng 2 :
> Hi,
> I use ubuntu 9.04 system.
> The shell is bash version is : GNU bash, version 3.2.48(1)-release 
> (i486-pc-linux-gnu)
> The make version is: GNU Make 3.81
> The step I take to compile the u-boot is :
>        make smdk6400_config
>        make all
> below is the some message from compiling:
>        arm-linux-objcopy --gap-fill=0xff -O binary 
> /root/u-boot-2009.06/nand_spl/u-boot-spl 
> /root/u-boot-2009.06/nand_spl/u-boot-spl.bin
>        arm-linux-objcopy --gap-fill=0xff --pad-to= -O binary 
> /root/u-boot-2009.06/nand_spl/u-boot-spl 
> /root/u-boot-2009.06/nand_spl/u-boot-spl-16k.bin
>        make[1]: Leaving directory 
> `/root/u-boot-2009.06/nand_spl/board/samsung/smdk6400'
>        cat nand_spl/u-boot-spl-16k.bin u-boot.bin > u-boot-nand.bin
>
> list the files give out the result below:
> -rwxr-xr-x 1 root root  2884 2009-09-16 23:32 u-boot-spl-16k.bin
> -rwxr-xr-x 1 root root  2884 2009-09-16 23:32 u-boot-spl.bin
>
>
> You can notice that the PAD_TO is empty during build, and the final size of 
> the two file is the same.
> Do you think that is the difference of bash or make between yours and mine 
> cause the issue ?
> -Original Message-
> From: Minkyu Kang [mailto:proms...@gmail.com]
> Sent: Wednesday, September 16, 2009 9:44 AM
> To: Wolfgang Denk
> Cc: Minkyu Kang; u-boot@lists.denx.de; sun peng
> Subject: Re: [U-Boot] I found an error
>
> Dear sun peng
>
> 2009/9/16 Wolfgang Denk :
>> Dear Minkyu Kang,
>>
>> In message <3fa5fd300909100724x18b2a8bdve0bd6e9fb7194...@mail.gmail.com> Sun 
>> Peng wrote:
>>>
>>> Recently I'm playing with u-boot and want it be able to boot from nand.
>>> When I config u-boot to smdk6400, I found I can't  get nand_spl with proper
>>> size. It need to be pad to 4k to fit into the steping stone.
>>> The final size of nand_spl is  depend on the variable "PAD_TO":
>>>
>>>              # PAD_TO used to generate a 4kByte binary needed for the
>>> combined image
>>>              # -> PAD_TO = TEXT_BASE + 4096
>>>              PAD_TO  := $(shell expr $$[$(TEXT_BASE) + 4096])
>>> The lines above is in file:
>>>             u-boot-xxx/nand_spl//board/samsung/smdk6400/config.mk
>>> Unfortunately the PAD_TO can not evaluate to the proper value when I run the
>>> makefile.
>>> I change the the line to below:
>>>    PAD_TO    := $(shell expr $(TEXT_BASE) + 4096)
>>> then the whole build works OK.
>>>
>>> Is there any body think this is an issue ?
>>
>> Could you please be so kind and have a look at this?
>>
>> Thanks in advance.
>>
>> Best regards,
>>
>> Wolfgang Denk
>>
>> --
>> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
>> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
>> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
>> "IBM uses what I like to call the 'hole-in-the-ground  technique'  to
>> destroy  the  competition.  IBM digs a big HOLE in the ground and
>> covers it with leaves. It then puts a big POT OF GOLD nearby. Then it
>> gives the call, 'Hey, look at all this gold, get over here fast.'  As
>> soon  as  the competitor approaches the pot, he falls into the pit"
>>                                                     - John C. Dvorak
>> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>>
>
> I saw correct PAD_TO value without modification.
>
> ccache /opt/toolchains/arm-2008q3/bin/arm-none-linux-gnueabi-objcopy
> --gap-fill=0xff --pad-to=4096 -O binary
> /home/share/Work/u-boot-work/nand_spl/u-boot-spl
> /home/share/Work/u-boot-work/nand_spl/u-boot-spl-16k.bin
>
> and I've got 4Kbyte binary also.
>
> -rwxr-xr-x  1 prom prom  4096 2009-09-16 10:21 u-boot-spl-16k.bin
>
> I think there have no problem.
> If it's not your problem, please explain in more detail.
>
> Thanks.
> Minkyu Kang
> --
> from. prom.
> www.promsoft.net
>

I think we use similar system.
And I saw same problem at my co-worker's system.
but I don't know the cause.

This problem is seems to be occurred at particular system.
and If your modification have no problem, then we can fix it.
so, please send the patch.
and then many people will test it.

+
please do not top-post.

Thanks
Minkyu Kang
-- 
from. prom.
www.promsoft.net
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [TESTING PATCH] ppc: Relocation test patch

[Wolfgang Denk]

Dear Joakim Tjernlund,

In message 
 you 
wrote:
>
> > > One day we can fit the whole relocation table into built-in CPU memory, 
> > > hopefully
> > > that will make it possible to make u-boot a true PIC exe
> >
> > Why is the former the prerequisite for the latter?
> 
> Some time ago I looked into making u-boot PIC and I came to the conclusion
> that one must be able to modify the GOT table before we have relocated to RAM.
> Perhaps there is another way but didn't see it at the time, maybe there is 
> some
> "hidden" option to gcc that I missed.

But why has the GOT table to fit "into built-in CPU memory"? When we
are about to relocate U-Boot to RAM, we already have RAM working. So
we should also be able to copy the GOT table to RAM and modify it
there as needed before we use it?

> The main problem are all those string literals, these are in the fixup table
> and one wants to use printf and friends before relocation to RAM.

Maybe a similar approach is usable here?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Unsichtbar macht sich die Dummheit, indem sie immer  größere  Ausmaße
annimmt. -- Bertold Brecht: Der Tui-Roman
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] mx27ads: add support for iMX27ADS board from Freescale

[javier Martin]

Has anyone tested ethernet connection in this board?

Thank you.

-- 
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] error in fw_printenv

[Detlev Zundel]

Hi Rahanesh,

>> Well, that most certainly means that your /dev/mtd0 is not a NOR or
>> NAND flash device.
>>
>>   
>Now used the fw_printenv under tools/env directory of uboot. It 
> does not have IOCTL error.
>  
> On issuing a fw_printenv it showd following messages
>  
>  Bad data CRC, Using default environment and printed only few 
> environment variables.

This should have made big warning signs flash up - if data crc was not
correct, it was 99% sure that your configuration wasn't ok.

>   Then i did a fw_setenv bootdelay 6. It showed some messgaes of 
> erasing flash. But it actually erased my uboot itself.

No big wonder here.

>   What might be the issue? config file?

Of course.

>MTD device name   Device offset   Env. sizeFlash 
> sector size   Number of sectors
> /dev/mtd00x   
> 0x1000   0x1
>
>
> What does Device Offset mean?

Offset is the offset into the area mapped by the device file.

> /dev/mtd0 has both uboot as well as  environment variables. Environment 
> variables lie at bottom of /dev/mtd0. Is that the meaning of device offset?

That would be the meaning.  You can always test by reading /dev/mtd0
directly from linux and inspect its contents, i.e. try

dd if=/dev/mtd0 bs=64k count=1 | hexdump -C | less

(or something comparable) and look for your environment.

>#define CFG_ENV_ADDR0xAD03F000   (Flash starts at 0xAD00)
>#define CFG_ENV_SIZE0x1000
>#define CFG_ENV_SECT_SIZE   0x1
>
>
> These are the macro that i found in include/configs/board.h

This looks completly weird to me.  Can you tell me exactly what board
you are working with?  It looks like this cannot be a NOR flash..

Cheers
  Detlev

-- 
In God we trust.  All others we monitor
   -- NSA motto
--
DENX Software Engineering GmbH,  MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] fls definition issue

[Hu Mingkai-B21284]

Hi all,
 
I run across an issue when startup the MPC8536DS board by using
the latest git tree. The system hanged when initialized the DDR.
 
U-Boot 2009.08-00197-g15fba32 (Sep 17 2009 - 18:15:50)
 
CPU:   8536E, Version: 1.1, (0x803f0091)
Core:  E500, Version: 3.0, (0x80210030)
Clock Configuration:
   CPU0:1499.985 MHz,
   CCB:499.995 MHz,
   DDR:333.330 MHz (666.660 MT/s data rate) (Asynchronous),
LBC:31.250 MHz
L1:D-cache 32 kB enabled
   I-cache 32 kB enabled
Board: MPC8536DS Sys ID: 0x15, Sys Ver: 0x10, FPGA Ver: 0x13, vBank: 0
I2C:   ready
DRAM:  InitializingERROR
 2 GB left unmapped
DDR:
 
I traced the code and found the variable law_sz_enc got an
error value when call __ilog2_u64 in the function set_ddr_laws.
 
The inline function __ilog2_u64 will call fls inline function
finally, but the fls is defined as a variable by the commit
52d61227b66d4099b39c8309ab37cb67ee09a405 in the platform specific
bitops.h file.
 
include/asm-ppc/bitops.h:
static __inline__ int fls(unsigned int x)
{
return __ilog2(x) + 1;
}
#define fls

So when called fls, which one will be used?
>From the experiments, I got the latter called, but I don't find
the root reason, any clues?
 
Thanks,
Mingkai
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] fls definition issue

[Stefan Roese]

On Thursday 17 September 2009 13:47:58 Hu Mingkai-B21284 wrote:
> I traced the code and found the variable law_sz_enc got an
> error value when call __ilog2_u64 in the function set_ddr_laws.
> 
> The inline function __ilog2_u64 will call fls inline function
> finally, but the fls is defined as a variable by the commit
> 52d61227b66d4099b39c8309ab37cb67ee09a405 in the platform specific
> bitops.h file.
> 
> include/asm-ppc/bitops.h:
> static __inline__ int fls(unsigned int x)
> {
> return __ilog2(x) + 1;
> }
> #define fls
> 
> So when called fls, which one will be used?
> From the experiments, I got the latter called, but I don't find
> the root reason, any clues?

This problem is already known, and Simon (on Cc) is currently working on a 
patch to fix it. Should be ready this afternoon...
 
Cheers,
Stefan

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

Re: [U-Boot] [PATCH 1/3] fsl_i2c: Wait for STOP condition to propagate

[Heiko Schocher]

Hello Joakim,

Joakim Tjernlund wrote:
> After issuing a STOP one must wait until the STOP has completed
> on the bus before doing something new to the controller.
> 
> Also add an extra read of SR as the manual mentions doing that
> is a good idea.
> 
> Remove surplus write of CR just before a write, isn't required and
> could potentially disturb the I2C bus.
> 
> Signed-off-by: Joakim Tjernlund 
> ---
>  drivers/i2c/fsl_i2c.c |   12 
>  1 files changed, 8 insertions(+), 4 deletions(-)

Applied to u-boot-i2c testing

I applied your 3 patches at the moment to the u-boot-i2c testing branch,
in the hope to see some "Tested-by" ;-)

Thanks.

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

Re: [U-Boot] [PATCH 2/3] fsl_i2c: Add CONFIG_FSL_I2C_CUSTOM_{DFSR/FDR}

[Heiko Schocher]

Hello Joakim,

Joakim Tjernlund wrote:
> Some boards need a higher DFSR value than the spec currently
> recommends so give these boards the means to define there own.
> 
> For completeness, add CONFIG_FSL_I2C_CUSTOM_FDR too.
> 
> Signed-off-by: Joakim Tjernlund 
> ---
>  drivers/i2c/fsl_i2c.c |   14 +++---
>  1 files changed, 11 insertions(+), 3 deletions(-)

Applied to u-boot-i2c testing

Thanks.

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

Re: [U-Boot] [PATCH 3/3] fsl_i2c: Impl. AN2919, rev 5 to calculate FDR/DFSR

[Heiko Schocher]

Hello Joakim,

Joakim Tjernlund wrote:
> The latest AN2919 has changed the way FDR/DFSR should be calculated.
> Update the driver according to spec. However, Condition 2
> is not accounted for as it is not clear how to do so.
> 
> Signed-off-by: Joakim Tjernlund 
> ---
>  drivers/i2c/fsl_i2c.c |   90 
> ++---
>  1 files changed, 55 insertions(+), 35 deletions(-)

Applied to u-boot-i2c testing with one fix:

Applying: fsl_i2c: Impl. AN2919, rev 5 to calculate FDR/DFSR
/home/hs/i2c/u-boot-i2c/.git/rebase-apply/patch:100: trailing whitespace.
debug("Tr <= %d ns\n",
warning: 1 line applied after fixing whitespace errors.

Thanks.

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

Re: [U-Boot] [PATCH] ppc4xx: Fix 405EZ uart base baud calculation

[Stefan Roese]

On Friday 11 September 2009 17:21:38 Stefan Roese wrote:
> With this fix, Linux correctly configures the baudrate when booting
> with FDT passed from U-Boot to Linux.
> 
> Signed-off-by: Stefan Roese 

Applied to ppc4xx/master. Thanks.

Cheers,
Stefan

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

Re: [U-Boot] [PATCH] ppc4xx: Enable commands for FDT enabled Linux booting on AMCC Acadia

[Stefan Roese]

On Friday 11 September 2009 17:22:27 Stefan Roese wrote:
> Acadia still used the "old" arch/ppc bootm commands for booting
> Linux images without FDT. This patch now enables these fdt-aware
> boot commands for Acadia as well.
> 
> Signed-off-by: Stefan Roese 

Applied to ppc4xx/master. Thanks.

Cheers,
Stefan

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

Re: [U-Boot] Compilation error for fw_printenv

[Wolfgang Denk]

Dear Rahanesh,

In message <4ab20222.3050...@tataelxsi.co.in> you wrote:
> Hi All,
> 
> While trying to compile fw_printenv under tools/env directory of u-boot 
> i am getting the following error:
> 
> fw_env.c:34:27: error: linux/mtd/mtd.h: No such file or directory
> fw_env.c: In function fw_printenv:
> fw_env.c: In function flash_io:
> fw_env.c:390: error: erase_info_t undeclared (first use in this function)
> fw_env.c:390: error: (Each undeclared identifier is reported only once
> fw_env.c:390: error: for each function it appears in.)
> fw_env.c:390: error: expected  before erase
> fw_env.c:421: error: erase undeclared (first use in this function)
> fw_env.c:423: error: MEMUNLOCK undeclared (first use in this function)
> fw_env.c:462: error: MEMERASE undeclared (first use in this function)
> fw_env.c:519: error: MEMLOCK undeclared (first use in this function)
> make: *** [fw_printenv] Error 1
> 
> How can i solve this? I a very new to Linux Environment.

Obviously your cross tool chain does not provide the (needed)
linux/mtd/mtd.h header file.  Either use a more complete tool chain
(we use the ELDK), or manually add this file to your cross tool
chain's headers.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"355/113 -- Not the famous irrational number PI,  but  an  incredible
simulation!"
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ppc4xx: Consolidate get_OPB_freq()

[Stefan Roese]

On Monday 14 September 2009 11:39:53 Stefan Roese wrote:
> All 4xx variants had their own, mostly identical get_OPB_freq()
> function. Some variants even only had the OPB frequency calculated
> in this routine and not supplied the sys_info.freqOPB variable
> correctly (e.g. 405EZ). This resulted in incorrect OPB values passed
> via the FDT to Linux.
> 
> This patch now removes all those copies and only uses one function
> for all 4xx variants (except for IOP480 which doesn't have an OPB).
> 
> Signed-off-by: Stefan Roese 

Applied to ppc4xx/master. Thanks.

Cheers,
Stefan

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

[U-Boot] Please pull u-boot-ppc4xx

[Stefan Roese]

Hi Wolfgang,

please pull the following changes:

The following changes since commit 15fba3279b56333bdb65ead366f82c945ed320d1:
  Kumar Gala (1):
ppc/85xx: Disable all async interrupt sources when we boot

are available in the git repository at:

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

Stefan Roese (3):
  ppc4xx: Fix 405EZ uart base baud calculation
  ppc4xx: Enable commands for FDT enabled Linux booting on AMCC Acadia
  ppc4xx: Consolidate get_OPB_freq()

 cpu/ppc4xx/speed.c   |   96 ++
 include/configs/acadia.h |3 +-
 2 files changed, 22 insertions(+), 77 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Compile for SPARC Leon3 fails with *** No rule to make target ... ***

[Jerry Van Baren]

Kraitschy, Tobias wrote:
> Hi all,
> 
> I`ve implemented Gaisler Research`s Leon3 SPARC core to a FPGA
> evaluation board of Actel. Now I`m about to get U-Boot running. So I
> made up my own board directory, added header files with my
> configuration-parameters etc. just as discribed in the u-boot README.
> The "make myboard_config" goes well, but "make all" fails with the
> following message.
> 
> make[1]: *** No rule to make target 
> `/u-boot-2009.08_build/cpu/leon3/start.S', needed by 
> `/u-boot-2009.08_build/cpu/leon3/start.o'.  Stop.

The source has a cpu/leon3/start.S file.  The Makefile in that directory has
   $(START): $(START:.o=.S)
so that is where the dependency is coming from.  Is the file's location 
correct?  Does the file really exist there:
   ls /u-boot-2009.08_build/cpu/leon3/start.S

> I´d like to add that I set "BUILD_DIR=`/u-boot-2009.08_build" and I
> am using Gaisler`s Bare Cross Compiler with GCC 3.4.4. Searching the
> mailing-list-archives brought no advice to me. I also tried to study
> the Makefiles for half a week now, but I´m not familiar enought with
> it.

Setting BUILD_DIR to be an absolute path (leading "/") seems odd.

 says...
"By default the build is performed locally and the objects are saved in 
the source directory. One of the two methods can be used to change this 
behaviour and build U-Boot to some external directory:"

Try building it in the source directory rather than putting the output 
in a separate directory.  There are perennial problems with building 
into a separate directory (e.g. the $(OBJ) prefix is not prepended to 
the destination).  This is an easy thing to miss or mess up (also easy 
to fix).  Since leon3 is not a heavily used target, I would suspect that 
is the problem.

I would suggest not using BUILD_DIR and see if it works.  If it does, 
update the cpu/leon3/Makefile to look like a more heavily used target 
CPU, e.g. a PowerPC like the 83xx:


> 
> Thanks for your help!
> 
> Best regards,
> 
> Tobias Kraitschy

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

Re: [U-Boot] [PATCH 1/3] fsl_i2c: Wait for STOP condition to propagate

[Joakim Tjernlund]

>
> Hello Joakim,
>
> Joakim Tjernlund wrote:
> > After issuing a STOP one must wait until the STOP has completed
> > on the bus before doing something new to the controller.
> >
> > Also add an extra read of SR as the manual mentions doing that
> > is a good idea.
> >
> > Remove surplus write of CR just before a write, isn't required and
> > could potentially disturb the I2C bus.
> >
> > Signed-off-by: Joakim Tjernlund 
> > ---
> >  drivers/i2c/fsl_i2c.c |   12 
> >  1 files changed, 8 insertions(+), 4 deletions(-)
>
> Applied to u-boot-i2c testing
>
> I applied your 3 patches at the moment to the u-boot-i2c testing branch,
> in the hope to see some "Tested-by" ;-)

Great, hopefully you will get some Tested-by from Wolfgang G. and Timur

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

Re: [U-Boot] [TESTING PATCH] ppc: Relocation test patch

[Joakim Tjernlund]

Wolfgang Denk  wrote on 17/09/2009 12:15:42:
>
> Dear Joakim Tjernlund,
>
> In message  002f9...@transmode.se> you wrote:
> >
> > > > One day we can fit the whole relocation table into built-in CPU memory, 
> > > > hopefully
> > > > that will make it possible to make u-boot a true PIC exe
> > >
> > > Why is the former the prerequisite for the latter?
> >
> > Some time ago I looked into making u-boot PIC and I came to the conclusion
> > that one must be able to modify the GOT table before we have relocated to 
> > RAM.
> > Perhaps there is another way but didn't see it at the time, maybe there is 
> > some
> > "hidden" option to gcc that I missed.
>
> But why has the GOT table to fit "into built-in CPU memory"? When we
> are about to relocate U-Boot to RAM, we already have RAM working. So
> we should also be able to copy the GOT table to RAM and modify it
> there as needed before we use it?

Before you get RAM working there are lots of references to global data and
string literals. These point to their link address so if you have loaded
u-boot at a different address than you link address you have to adjust for
the offset. Hard to do that when GOT is in flash :(

>
> > The main problem are all those string literals, these are in the fixup table
> > and one wants to use printf and friends before relocation to RAM.
>
> Maybe a similar approach is usable here?

Yes, fixups and GOT are the same in this regard.

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

[U-Boot] [PATCH] Correct ffs/fls regression for PowerPC etc

[Simon Kagstrom]

Correct ffs/fls regression for PowerPC etc

Commits

  02f99901ed1c9d828e3ea117f94ce2264bf8389e
  52d61227b66d4099b39c8309ab37cb67ee09a405

introduced a regression where platform-specific ffs/fls implementations
were defined away. This patch corrects that by using PLATFORM_xxx
instead of the name itself.

Signed-off-by: Simon Kagstrom 
---
I've runtime tested on ARM (OpenRD base) and build-tested on MPC8536DS,
where __ilog2_u64 now at least is non-empty. It would be nice if (at
least!) some PowerPC people could test the patch.

 include/asm-arm/bitops.h|8 
 include/asm-blackfin/bitops.h   |   10 +-
 include/asm-i386/bitops.h   |2 +-
 include/asm-m68k/bitops.h   |2 +-
 include/asm-microblaze/bitops.h |3 ++-
 include/asm-mips/bitops.h   |   13 +
 include/asm-nios/bitops.h   |2 +-
 include/asm-nios2/bitops.h  |2 +-
 include/asm-ppc/bitops.h|4 ++--
 include/asm-sh/bitops.h |2 +-
 include/linux/bitops.h  |8 
 11 files changed, 15 insertions(+), 41 deletions(-)

diff --git a/include/asm-arm/bitops.h b/include/asm-arm/bitops.h
index 3c7b00c..270f163 100644
--- a/include/asm-arm/bitops.h
+++ b/include/asm-arm/bitops.h
@@ -125,14 +125,6 @@ static inline unsigned long ffz(unsigned long word)
 }
 
 /*
- * ffs: find first bit set. This is defined the same way as
- * the libc and compiler builtin ffs routines, therefore
- * differs in spirit from the above ffz (man ffs).
- */
-
-#define ffs(x) generic_ffs(x)
-
-/*
  * hweightN: returns the hamming weight (i.e. the number
  * of bits set) of a N-bit word
  */
diff --git a/include/asm-blackfin/bitops.h b/include/asm-blackfin/bitops.h
index cc3685d..f469f1c 100644
--- a/include/asm-blackfin/bitops.h
+++ b/include/asm-blackfin/bitops.h
@@ -79,7 +79,7 @@ static __inline__ void __set_bit(int nr, volatile void *addr)
mask = 1 << (nr & 0x1f);
*a |= mask;
 }
-#define __set_bit
+#define PLATFORM__set_bit
 
 /*
  * clear_bit() doesn't provide any barrier for the compiler.
@@ -270,14 +270,6 @@ static __inline__ int find_next_zero_bit(void *addr, int 
size, int offset)
 }
 
 /*
- * ffs: find first bit set. This is defined the same way as
- * the libc and compiler builtin ffs routines, therefore
- * differs in spirit from the above ffz (man ffs).
- */
-
-#define ffs(x) generic_ffs(x)
-
-/*
  * hweightN: returns the hamming weight (i.e. the number
  * of bits set) of a N-bit word
  */
diff --git a/include/asm-i386/bitops.h b/include/asm-i386/bitops.h
index ac6285a..c7a38f2 100644
--- a/include/asm-i386/bitops.h
+++ b/include/asm-i386/bitops.h
@@ -349,7 +349,7 @@ static __inline__ int ffs(int x)
"1:" : "=r" (r) : "g" (x));
return r+1;
 }
-#define ffs
+#define PLATFORM_FFS
 
 /**
  * hweightN - returns the hamming weight of a N-bit word
diff --git a/include/asm-m68k/bitops.h b/include/asm-m68k/bitops.h
index e0c35fa..ad971b4 100644
--- a/include/asm-m68k/bitops.h
+++ b/include/asm-m68k/bitops.h
@@ -51,7 +51,7 @@ extern __inline__ int ffs(int x)
return r;
 }
 #define __ffs(x) (ffs(x) - 1)
-#define ffs
+#define PLATFORM_FFS
 
 #endif /* __KERNEL__ */
 
diff --git a/include/asm-microblaze/bitops.h b/include/asm-microblaze/bitops.h
index aac9061..3b39e16 100644
--- a/include/asm-microblaze/bitops.h
+++ b/include/asm-microblaze/bitops.h
@@ -23,6 +23,7 @@ extern void __set_bit(int nr, volatile void * addr);
 
 extern void clear_bit(int nr, volatile void * addr);
 #define __clear_bit(nr, addr) clear_bit(nr, addr)
+#define PLATFORM__clear_bit
 
 extern void change_bit(int nr, volatile void * addr);
 extern void __change_bit(int nr, volatile void * addr);
@@ -75,7 +76,7 @@ extern __inline__ void __set_bit(int nr, volatile void * addr)
mask = 1 << (nr & 0x1f);
*a |= mask;
 }
-#define __set_bit
+#define PLATFORM__set_bit
 
 /*
  * clear_bit() doesn't provide any barrier for the compiler.
diff --git a/include/asm-mips/bitops.h b/include/asm-mips/bitops.h
index 0c07b68..18dee51 100644
--- a/include/asm-mips/bitops.h
+++ b/include/asm-mips/bitops.h
@@ -90,7 +90,7 @@ static __inline__ void __set_bit(int nr, volatile void * addr)
 
*m |= 1UL << (nr & 31);
 }
-#define __set_bit
+#define PLATFORM__set_bit
 
 /*
  * clear_bit - Clears a bit in memory
@@ -706,17 +706,6 @@ static __inline__ unsigned long ffz(unsigned long word)
 
 #ifdef __KERNEL__
 
-/**
- * ffs - find first bit set
- * @x: the word to search
- *
- * This is defined the same way as
- * the libc and compiler builtin ffs routines, therefore
- * differs in spirit from the above ffz (man ffs).
- */
-
-#define ffs(x) generic_ffs(x)
-
 /*
  * hweightN - returns the hamming weight of a N-bit word
  * @x: the word to weigh
diff --git a/include/asm-nios/bitops.h b/include/asm-nios/bitops.h
index 8315fb7..2047b7c 100644
--- a/include/asm-nios/bitops.h
+++ b/include/asm-nios/bitops.h
@@ -33,6 +33,6 @@ extern int test_and_set_bit(int nr, volatile voi

[U-Boot] [PATCH] arm: Correct build with CONFIG_SYS_HUSH_PARSER set

[Simon Kagstrom]

arm: Correct build with CONFIG_SYS_HUSH_PARSER set

FLAG_PARSE_SEMICOLON is not defined without hush.h, so include that.

Signed-off-by: Simon Kagstrom 
---
 cpu/arm926ejs/kirkwood/cpu.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/cpu/arm926ejs/kirkwood/cpu.c b/cpu/arm926ejs/kirkwood/cpu.c
index d0cdaf6..fbe754c 100644
--- a/cpu/arm926ejs/kirkwood/cpu.c
+++ b/cpu/arm926ejs/kirkwood/cpu.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define BUFLEN 16
 
-- 
1.6.0.4

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

Re: [U-Boot] Compilation error for fw_printenv

[Rahanesh]

Dear Wolfgang.
>
> Obviously your cross tool chain does not provide the (needed)
> linux/mtd/mtd.h header file.  Either use a more complete tool chain
> (we use the ELDK), or manually add this file to your cross tool
> chain's headers.
>
>
>   
After cross compiling now i get the following behaviour.
After issuing a fw_printenv it said
* Bad data CRC, Using default environment... *and printed out  
few environment variables.*
*
 Then i did a *fw_setenv bootdelay 6*. It showed some messgaes 
of erasing flash. But it actually erased my uboot itself.

 What might be the issue? Any issue with the config file?

  MTD device name   Device offset   Env. sizeFlash 
sector size   Number of sectors
   /dev/mtd00x   
0x1000   0x1


What does Device Offset mean?

/dev/mtd0 has both uboot as well as  environment variables. Environment 
variables lie at bottom of /dev/mtd0. Is that the meaning of device offset?

  #define CFG_ENV_ADDR0xAD03F000   (Flash starts at 0xAD00)
  #define CFG_ENV_SIZE0x1000
  #define CFG_ENV_SECT_SIZE   0x1


These are the macros that i found in include/configs/board.h

Please help

Thanks
Rahanesh



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

Re: [U-Boot] [TESTING PATCH] ppc: Relocation test patch

[Wolfgang Denk]

Dear Joakim Tjernlund,

In message 
 you 
wrote:
>
> > But why has the GOT table to fit "into built-in CPU memory"? When we
> > are about to relocate U-Boot to RAM, we already have RAM working. So
> > we should also be able to copy the GOT table to RAM and modify it
> > there as needed before we use it?
> 
> Before you get RAM working there are lots of references to global data and
> string literals. These point to their link address so if you have loaded
> u-boot at a different address than you link address you have to adjust for
> the offset. Hard to do that when GOT is in flash :(

Ah, I finally GOT you :-)

Hm... but being able to load (and start) U-Boot from an arbitrary RAM
location would be a big benefit, too, even if we still have to copy it
to the correct (linked) address when storing it in flash.

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

Re: [U-Boot] [PATCH] Correct ffs/fls regression for PowerPC etc

[Stefan Roese]

Hi Simon,

On Thursday 17 September 2009 14:39:40 Simon Kagstrom wrote:
> Correct ffs/fls regression for PowerPC etc
> 
> Commits
> 
>   02f99901ed1c9d828e3ea117f94ce2264bf8389e
>   52d61227b66d4099b39c8309ab37cb67ee09a405
> 
> introduced a regression where platform-specific ffs/fls implementations
> were defined away. This patch corrects that by using PLATFORM_xxx
> instead of the name itself.

Thanks. I tested it on my faulting ppc4xx platform (sequoia). And the problem 
is gone now, so thanks.

But I've spotted a problem with other platforms in this patch. See below...
 
> Signed-off-by: Simon Kagstrom 
> ---
> I've runtime tested on ARM (OpenRD base) and build-tested on MPC8536DS,
> where __ilog2_u64 now at least is non-empty. It would be nice if (at
> least!) some PowerPC people could test the patch.
> 
>  include/asm-arm/bitops.h|8 
>  include/asm-blackfin/bitops.h   |   10 +-
>  include/asm-i386/bitops.h   |2 +-
>  include/asm-m68k/bitops.h   |2 +-
>  include/asm-microblaze/bitops.h |3 ++-
>  include/asm-mips/bitops.h   |   13 +
>  include/asm-nios/bitops.h   |2 +-
>  include/asm-nios2/bitops.h  |2 +-
>  include/asm-ppc/bitops.h|4 ++--
>  include/asm-sh/bitops.h |2 +-
>  include/linux/bitops.h  |8 
>  11 files changed, 15 insertions(+), 41 deletions(-)
> 
> diff --git a/include/asm-arm/bitops.h b/include/asm-arm/bitops.h
> index 3c7b00c..270f163 100644
> --- a/include/asm-arm/bitops.h
> +++ b/include/asm-arm/bitops.h
> @@ -125,14 +125,6 @@ static inline unsigned long ffz(unsigned long word)
>  }
> 
>  /*
> - * ffs: find first bit set. This is defined the same way as
> - * the libc and compiler builtin ffs routines, therefore
> - * differs in spirit from the above ffz (man ffs).
> - */
> -
> -#define ffs(x) generic_ffs(x)
> -
> -/*
>   * hweightN: returns the hamming weight (i.e. the number
>   * of bits set) of a N-bit word
>   */
> diff --git a/include/asm-blackfin/bitops.h b/include/asm-blackfin/bitops.h
> index cc3685d..f469f1c 100644
> --- a/include/asm-blackfin/bitops.h
> +++ b/include/asm-blackfin/bitops.h
> @@ -79,7 +79,7 @@ static __inline__ void __set_bit(int nr, volatile void
>  *addr) mask = 1 << (nr & 0x1f);
>   *a |= mask;
>  }
> -#define __set_bit
> +#define PLATFORM__set_bit
> 
>  /*
>   * clear_bit() doesn't provide any barrier for the compiler.
> @@ -270,14 +270,6 @@ static __inline__ int find_next_zero_bit(void *addr,
>  int size, int offset) }
> 
>  /*
> - * ffs: find first bit set. This is defined the same way as
> - * the libc and compiler builtin ffs routines, therefore
> - * differs in spirit from the above ffz (man ffs).
> - */
> -
> -#define ffs(x)   generic_ffs(x)
> -
> -/*
>   * hweightN: returns the hamming weight (i.e. the number
>   * of bits set) of a N-bit word
>   */
> diff --git a/include/asm-i386/bitops.h b/include/asm-i386/bitops.h
> index ac6285a..c7a38f2 100644
> --- a/include/asm-i386/bitops.h
> +++ b/include/asm-i386/bitops.h
> @@ -349,7 +349,7 @@ static __inline__ int ffs(int x)
>   "1:" : "=r" (r) : "g" (x));
>   return r+1;
>  }
> -#define ffs
> +#define PLATFORM_FFS

Here you define "FFS" in upper case.

>  /**
>   * hweightN - returns the hamming weight of a N-bit word
> diff --git a/include/asm-m68k/bitops.h b/include/asm-m68k/bitops.h
> index e0c35fa..ad971b4 100644
> --- a/include/asm-m68k/bitops.h
> +++ b/include/asm-m68k/bitops.h
> @@ -51,7 +51,7 @@ extern __inline__ int ffs(int x)
>   return r;
>  }
>  #define __ffs(x) (ffs(x) - 1)
> -#define ffs
> +#define PLATFORM_FFS

And here again.

>  #endif /* __KERNEL__ */
> 
> diff --git a/include/asm-microblaze/bitops.h
>  b/include/asm-microblaze/bitops.h index aac9061..3b39e16 100644
> --- a/include/asm-microblaze/bitops.h
> +++ b/include/asm-microblaze/bitops.h
> @@ -23,6 +23,7 @@ extern void __set_bit(int nr, volatile void * addr);
> 
>  extern void clear_bit(int nr, volatile void * addr);
>  #define __clear_bit(nr, addr) clear_bit(nr, addr)
> +#define PLATFORM__clear_bit
> 
>  extern void change_bit(int nr, volatile void * addr);
>  extern void __change_bit(int nr, volatile void * addr);
> @@ -75,7 +76,7 @@ extern __inline__ void __set_bit(int nr, volatile void *
>  addr) mask = 1 << (nr & 0x1f);
>   *a |= mask;
>  }
> -#define __set_bit
> +#define PLATFORM__set_bit
> 
>  /*
>   * clear_bit() doesn't provide any barrier for the compiler.
> diff --git a/include/asm-mips/bitops.h b/include/asm-mips/bitops.h
> index 0c07b68..18dee51 100644
> --- a/include/asm-mips/bitops.h
> +++ b/include/asm-mips/bitops.h
> @@ -90,7 +90,7 @@ static __inline__ void __set_bit(int nr, volatile void *
>  addr)
> 
>   *m |= 1UL << (nr & 31);
>  }
> -#define __set_bit
> +#define PLATFORM__set_bit
> 
>  /*
>   * clear_bit - Clears a bit in memory
> @@ -706,17 +706,6 @@ static __inline__ unsigned long ffz(unsigned long
>  word)
> 
>  #ifdef __KERNEL__
> 
> -/**
>

Re: [U-Boot] [PATCH] Correct ffs/fls regression for PowerPC etc

[Wolfgang Denk]

Dear Stefan Roese,

In message <200909171456.33234...@denx.de> you wrote:
> 
> Thanks. I tested it on my faulting ppc4xx platform (sequoia). And the problem 
> is gone now, so thanks.

Thanks for testing.

> But I've spotted a problem with other platforms in this patch. See below...
...
> > -#define ffs
> > +#define PLATFORM_FFS
> 
> Here you define "FFS" in upper case.

... which is acctually correct, as macro names _shall_ use upper case
letters.

...
> > -#define __set_bit
> > +#define PLATFORM__set_bit

This is not a legal macro name.

> > -#define ffs
> > +#define PLATFORM_ffs
> 
> Here it's lower case.

Yeah, the patch is not clean.

> > -#ifndef ffs
> > +#ifndef PLATFORM_ffs
> >  # define ffs generic_ffs
> >  #endif
> 
> And here you check against lower case "_ffs". So the platforms with upper 
> case 
> "_FFS" are still broken. Please fix and resubmit.


Simon, this needs to be cleaned up. Please make sure to use upper case
macro names only.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
You humans have that emotional need  to  express  gratitude.  "You're
welcome," I believe, is the correct response.
-- Spock, "Bread and Circuses", stardate 4041.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2] Correct ffs/fls regression for PowerPC etc

[Simon Kagstrom]

Correct ffs/fls regression for PowerPC etc

Commits

  02f99901ed1c9d828e3ea117f94ce2264bf8389e
  52d61227b66d4099b39c8309ab37cb67ee09a405

introduced a regression where platform-specific ffs/fls implementations
were defined away. This patch corrects that by using PLATFORM_xxx
instead of the name itself.

Signed-off-by: Simon Kagstrom 
---
I've runtime tested on ARM (OpenRD base) and build-tested on MPC8536DS,
where __ilog2_u64 now at least is non-empty. It would be nice if (at
least!) some PowerPC people could test the patch.


ChangeLog:

v2 - Make _all_ macros upper case (Stefan, Wolfgang)


 include/asm-arm/bitops.h|8 
 include/asm-blackfin/bitops.h   |   10 +-
 include/asm-i386/bitops.h   |2 +-
 include/asm-m68k/bitops.h   |2 +-
 include/asm-microblaze/bitops.h |3 ++-
 include/asm-mips/bitops.h   |   13 +
 include/asm-nios/bitops.h   |2 +-
 include/asm-nios2/bitops.h  |2 +-
 include/asm-ppc/bitops.h|4 ++--
 include/asm-sh/bitops.h |2 +-
 include/linux/bitops.h  |8 
 11 files changed, 15 insertions(+), 41 deletions(-)

diff --git a/include/asm-arm/bitops.h b/include/asm-arm/bitops.h
index 3c7b00c..270f163 100644
--- a/include/asm-arm/bitops.h
+++ b/include/asm-arm/bitops.h
@@ -125,14 +125,6 @@ static inline unsigned long ffz(unsigned long word)
 }
 
 /*
- * ffs: find first bit set. This is defined the same way as
- * the libc and compiler builtin ffs routines, therefore
- * differs in spirit from the above ffz (man ffs).
- */
-
-#define ffs(x) generic_ffs(x)
-
-/*
  * hweightN: returns the hamming weight (i.e. the number
  * of bits set) of a N-bit word
  */
diff --git a/include/asm-blackfin/bitops.h b/include/asm-blackfin/bitops.h
index cc3685d..ab1fea5 100644
--- a/include/asm-blackfin/bitops.h
+++ b/include/asm-blackfin/bitops.h
@@ -79,7 +79,7 @@ static __inline__ void __set_bit(int nr, volatile void *addr)
mask = 1 << (nr & 0x1f);
*a |= mask;
 }
-#define __set_bit
+#define PLATFORM__SET_BIT
 
 /*
  * clear_bit() doesn't provide any barrier for the compiler.
@@ -270,14 +270,6 @@ static __inline__ int find_next_zero_bit(void *addr, int 
size, int offset)
 }
 
 /*
- * ffs: find first bit set. This is defined the same way as
- * the libc and compiler builtin ffs routines, therefore
- * differs in spirit from the above ffz (man ffs).
- */
-
-#define ffs(x) generic_ffs(x)
-
-/*
  * hweightN: returns the hamming weight (i.e. the number
  * of bits set) of a N-bit word
  */
diff --git a/include/asm-i386/bitops.h b/include/asm-i386/bitops.h
index ac6285a..c7a38f2 100644
--- a/include/asm-i386/bitops.h
+++ b/include/asm-i386/bitops.h
@@ -349,7 +349,7 @@ static __inline__ int ffs(int x)
"1:" : "=r" (r) : "g" (x));
return r+1;
 }
-#define ffs
+#define PLATFORM_FFS
 
 /**
  * hweightN - returns the hamming weight of a N-bit word
diff --git a/include/asm-m68k/bitops.h b/include/asm-m68k/bitops.h
index e0c35fa..ad971b4 100644
--- a/include/asm-m68k/bitops.h
+++ b/include/asm-m68k/bitops.h
@@ -51,7 +51,7 @@ extern __inline__ int ffs(int x)
return r;
 }
 #define __ffs(x) (ffs(x) - 1)
-#define ffs
+#define PLATFORM_FFS
 
 #endif /* __KERNEL__ */
 
diff --git a/include/asm-microblaze/bitops.h b/include/asm-microblaze/bitops.h
index aac9061..5d814f0 100644
--- a/include/asm-microblaze/bitops.h
+++ b/include/asm-microblaze/bitops.h
@@ -23,6 +23,7 @@ extern void __set_bit(int nr, volatile void * addr);
 
 extern void clear_bit(int nr, volatile void * addr);
 #define __clear_bit(nr, addr) clear_bit(nr, addr)
+#define PLATFORM__CLEAR_BIT
 
 extern void change_bit(int nr, volatile void * addr);
 extern void __change_bit(int nr, volatile void * addr);
@@ -75,7 +76,7 @@ extern __inline__ void __set_bit(int nr, volatile void * addr)
mask = 1 << (nr & 0x1f);
*a |= mask;
 }
-#define __set_bit
+#define PLATFORM__SET_BIT
 
 /*
  * clear_bit() doesn't provide any barrier for the compiler.
diff --git a/include/asm-mips/bitops.h b/include/asm-mips/bitops.h
index 0c07b68..1c8f4c0 100644
--- a/include/asm-mips/bitops.h
+++ b/include/asm-mips/bitops.h
@@ -90,7 +90,7 @@ static __inline__ void __set_bit(int nr, volatile void * addr)
 
*m |= 1UL << (nr & 31);
 }
-#define __set_bit
+#define PLATFORM__SET_BIT
 
 /*
  * clear_bit - Clears a bit in memory
@@ -706,17 +706,6 @@ static __inline__ unsigned long ffz(unsigned long word)
 
 #ifdef __KERNEL__
 
-/**
- * ffs - find first bit set
- * @x: the word to search
- *
- * This is defined the same way as
- * the libc and compiler builtin ffs routines, therefore
- * differs in spirit from the above ffz (man ffs).
- */
-
-#define ffs(x) generic_ffs(x)
-
 /*
  * hweightN - returns the hamming weight of a N-bit word
  * @x: the word to weigh
diff --git a/include/asm-nios/bitops.h b/include/asm-nios/bitops.h
index 8315fb7..0be74f4 100644
--- a/include/asm-nios/bitops.h
+++ b/include/asm-nios/bitops.

Re: [U-Boot] [TESTING PATCH] ppc: Relocation test patch

[Joakim Tjernlund]

Wolfgang Denk  wrote on 17/09/2009 14:53:59:
>
> Dear Joakim Tjernlund,

Dear me :)

>
> In message  00451...@transmode.se> you wrote:
> >
> > > But why has the GOT table to fit "into built-in CPU memory"? When we
> > > are about to relocate U-Boot to RAM, we already have RAM working. So
> > > we should also be able to copy the GOT table to RAM and modify it
> > > there as needed before we use it?
> >
> > Before you get RAM working there are lots of references to global data and
> > string literals. These point to their link address so if you have loaded
> > u-boot at a different address than you link address you have to adjust for
> > the offset. Hard to do that when GOT is in flash :(
>
> Ah, I finally GOT you :-)

*LOL*

>
> Hm... but being able to load (and start) U-Boot from an arbitrary RAM
> location would be a big benefit, too, even if we still have to copy it
> to the correct (linked) address when storing it in flash.

Naa, true PIC is what I want.
What is really missing is an option to gcc telling it to use a register
as GOT base. Something like *assume* GOT is r30 instead of calculating it
from __GLOBAL_OFFSET_TABLE__ in every function.

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

Re: [U-Boot] Compile for SPARC Leon3 fails with *** No rule to make target ... ***

[Kraitschy, Tobias]

Hi,

Unsetting BUILD_DIR solved the problem.

Of course /u-boot-2009.08_build/cpu/leon3/start.S does not exist here. I´ll try 
to figure out what´s wrong in the Makefile.

Thanks.

Best regards,

Tobias Kraitschy

-Original Message-
From: Jerry Van Baren [mailto:gerald.vanba...@ge.com] 
Date: Thursday, 17. September 2009 14:19
To: Kraitschy, Tobias
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] Compile for SPARC Leon3 fails with *** No rule to make 
target ... ***

Kraitschy, Tobias wrote:
> Hi all,
> 
> I`ve implemented Gaisler Research`s Leon3 SPARC core to a FPGA
> evaluation board of Actel. Now I`m about to get U-Boot running. So I
> made up my own board directory, added header files with my
> configuration-parameters etc. just as discribed in the u-boot README.
> The "make myboard_config" goes well, but "make all" fails with the
> following message.
> 
> make[1]: *** No rule to make target 
> `/u-boot-2009.08_build/cpu/leon3/start.S', needed by 
> `/u-boot-2009.08_build/cpu/leon3/start.o'.  Stop.

The source has a cpu/leon3/start.S file.  The Makefile in that directory has
   $(START): $(START:.o=.S)
so that is where the dependency is coming from.  Is the file's location 
correct?  Does the file really exist there:
   ls /u-boot-2009.08_build/cpu/leon3/start.S

> I´d like to add that I set "BUILD_DIR=`/u-boot-2009.08_build" and I
> am using Gaisler`s Bare Cross Compiler with GCC 3.4.4. Searching the
> mailing-list-archives brought no advice to me. I also tried to study
> the Makefiles for half a week now, but I´m not familiar enought with
> it.

Setting BUILD_DIR to be an absolute path (leading "/") seems odd.

 says...
"By default the build is performed locally and the objects are saved in 
the source directory. One of the two methods can be used to change this 
behaviour and build U-Boot to some external directory:"

Try building it in the source directory rather than putting the output 
in a separate directory.  There are perennial problems with building 
into a separate directory (e.g. the $(OBJ) prefix is not prepended to 
the destination).  This is an easy thing to miss or mess up (also easy 
to fix).  Since leon3 is not a heavily used target, I would suspect that 
is the problem.

I would suggest not using BUILD_DIR and see if it works.  If it does, 
update the cpu/leon3/Makefile to look like a more heavily used target 
CPU, e.g. a PowerPC like the 83xx:


> 
> Thanks for your help!
> 
> Best regards,
> 
> Tobias Kraitschy

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

Re: [U-Boot] [PATCH v2] Correct ffs/fls regression for PowerPC etc

[Kumar Gala]

On Sep 17, 2009, at 8:15 AM, Simon Kagstrom wrote:

> Correct ffs/fls regression for PowerPC etc
>
> Commits
>
>  02f99901ed1c9d828e3ea117f94ce2264bf8389e
>  52d61227b66d4099b39c8309ab37cb67ee09a405
>
> introduced a regression where platform-specific ffs/fls  
> implementations
> were defined away. This patch corrects that by using PLATFORM_xxx
> instead of the name itself.
>
> Signed-off-by: Simon Kagstrom 
> ---
> I've runtime tested on ARM (OpenRD base) and build-tested on  
> MPC8536DS,
> where __ilog2_u64 now at least is non-empty. It would be nice if (at
> least!) some PowerPC people could test the patch.
>
>
> ChangeLog:
>
> v2 - Make _all_ macros upper case (Stefan, Wolfgang)
>

Acked-by: Kumar Gala 

This fixes the issue I was seeing.

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

Re: [U-Boot] [PATCH v2] Correct ffs/fls regression for PowerPC etc

[Stefan Roese]

On Thursday 17 September 2009 15:15:52 Simon Kagstrom wrote:
> Correct ffs/fls regression for PowerPC etc
> 
> Commits
> 
>   02f99901ed1c9d828e3ea117f94ce2264bf8389e
>   52d61227b66d4099b39c8309ab37cb67ee09a405
> 
> introduced a regression where platform-specific ffs/fls implementations
> were defined away. This patch corrects that by using PLATFORM_xxx
> instead of the name itself.
> 
> Signed-off-by: Simon Kagstrom 

You have the subject "Correct ffs/fls regression for PowerPC etc" twice in the 
commit message, once in the email subject and once at the beginning of the 
mail body.

Other than this:

Acked-by: Stefan Roese 

Thanks.

Cheers,
Stefan

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

Re: [U-Boot] [PATCH v2] Correct ffs/fls regression for PowerPC etc

[Simon Kagstrom]

On Thu, 17 Sep 2009 16:13:26 +0200
Stefan Roese  wrote:

> You have the subject "Correct ffs/fls regression for PowerPC etc" twice in 
> the 
> commit message, once in the email subject and once at the beginning of the 
> mail body.

Well, I'll admit that I haven't setup git to send emails yet, so I
simply paste them into my regular mail program. I'll submit with the
first line only in the subject from now on.

Or setup git-send-email one day :-)

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

Re: [U-Boot] [PATCH v2] Correct ffs/fls regression for PowerPC etc

[Stefan Roese]

On Thursday 17 September 2009 16:22:12 Simon Kagstrom wrote:
> > You have the subject "Correct ffs/fls regression for PowerPC etc" twice
> > in the commit message, once in the email subject and once at the
> > beginning of the mail body.
> 
> Well, I'll admit that I haven't setup git to send emails yet, so I
> simply paste them into my regular mail program. I'll submit with the
> first line only in the subject from now on.
> 
> Or setup git-send-email one day :-)

Yes, git send-email really saves time and trouble from my experience. :)
 
Cheers,
Stefan

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

Re: [U-Boot] [PATCH 2/3] fsl_i2c: Add CONFIG_FSL_I2C_CUSTOM_{DFSR/FDR}

[Timur Tabi]

Joakim Tjernlund wrote:

> +#ifdef CONFIG_FSL_I2C_CUSTOM_FDR
> + fdr = CONFIG_FSL_I2C_CUSTOM_FDR;
> + speed = i2c_clk / divider; /* Fake something */

How about setting 'speed' to CONFIG_SYS_I2C_SPEED?

-- 
Timur Tabi
Linux kernel developer at Freescale
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] I am maintainer of Freescale i.MX

[Fred Fan]

Dear Wolfgang Denk & Magnus Lilja:
 I am u-boot maintainer of Freescale i.MX team.
 I have two mail accounts:
fanyef...@gmail.com and r01...@freescale.com.
 I will use both of them.
Best Regards
Fred.Fan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] imx27lite stability problems.

[javier Martin]

I've found some problems because the cache is enabled, I don't see any
place where you disable it.

Are you sure you have this controlled properly?

-- 
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] RAM burst mode problem

[Mikhail Zaturenskiy]

We finally solved our DRAM timing problem so I wanted to follow up on
my question.

On Fri, Sep 4, 2009 at 1:41 AM, Frank Svendsbøe
 wrote:
> Hi Mikhail,
> Burst mode UPM setup is not trivial, and it is quite amount of work to
> go through your table, so
> I'm not surprised nobody has replied.

I know, I'm not too surprised either :)


> I assume you've verified the generated waveforms using a logic
> analyzer/scope, and compared
> them to the DRAMs datasheet (?).

Unfortunately we do not have access to a decent scope nor a logic
analyzer, that would certainly have been helpful.


> If you have access to a Windows
> machine, you could try an
> ancient Motorola tool called UPM860. It might be helpful when
> verifying your UPM program.

Did take a look at that, though it did not appear to be as helpful as I hoped.


> Good luck!
> - Frank

Thanks for your suggestions Frank, They did provide me with some food
for thought.

What the issue ended up being was us incorrectly setting the amx0/amx1
bits of the "Exception" RAM word. After we fixed that we also found a
nice document from Micron on DRAM timings which had slightly more
efficient read/write section values than what we came up with, for
those interested here is the link
http://download.micron.com/pdf/technotes/TN4812.pdf . Now RAM burst
reads/writes are finally working properly :)

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

[U-Boot] [PATCH 1/3] ppc/85xx: Cleanup p1_p2_rdb PCI setup

[Kumar Gala]

General code cleanup to use in/out IO accessors as well as making
the code that prints out info sane between board and generic fsl pci
code.

Signed-off-by: Kumar Gala 
---
 board/freescale/p1_p2_rdb/pci.c |   38 --
 drivers/pci/fsl_pci_init.c  |2 +-
 2 files changed, 21 insertions(+), 19 deletions(-)

diff --git a/board/freescale/p1_p2_rdb/pci.c b/board/freescale/p1_p2_rdb/pci.c
index a3617d5..1193362 100644
--- a/board/freescale/p1_p2_rdb/pci.c
+++ b/board/freescale/p1_p2_rdb/pci.c
@@ -41,58 +41,60 @@ static struct pci_controller pcie2_hose;
 
 void pci_init_board(void)
 {
-   struct fsl_pci_info pci_info[2];
volatile ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
-   uint devdisr = in_be32(&gur->devdisr);
-   uint io_sel = (in_be32(&gur->pordevsr) & MPC85xx_PORDEVSR_IO_SEL) >> 19;
-   uint host_agent = (in_be32(&gur->porbmsr) & MPC85xx_PORBMSR_HA) >> 16;
-   int num = 0;
+   struct fsl_pci_info pci_info[2];
+   u32 devdisr, pordevsr, io_sel, host_agent;
int first_free_busno = 0;
+   int num = 0;
 
int pcie_ep, pcie_configured;
 
+   devdisr = in_be32(&gur->devdisr);
+   pordevsr = in_be32(&gur->pordevsr);
+   io_sel = (pordevsr & MPC85xx_PORDEVSR_IO_SEL) >> 19;
+   host_agent = (in_be32(&gur->porbmsr) & MPC85xx_PORBMSR_HA) >> 16;
+
debug ("   pci_init_board: devdisr=%x, io_sel=%x, host_agent=%x\n",
devdisr, io_sel, host_agent);
 
-   if (!(gur->pordevsr & MPC85xx_PORDEVSR_SGMII2_DIS))
+   if (!(pordevsr & MPC85xx_PORDEVSR_SGMII2_DIS))
printf ("eTSEC2 is in sgmii mode.\n");
 
+   puts("\n");
 #ifdef CONFIG_PCIE2
-   SET_STD_PCIE_INFO(pci_info[num], 2);
pcie_ep = is_fsl_pci_agent(LAW_TRGT_IF_PCIE_2, host_agent);
pcie_configured = is_fsl_pci_cfg(LAW_TRGT_IF_PCIE_2, io_sel);
 
if (pcie_configured && !(devdisr & MPC85xx_DEVDISR_PCIE)){
-   puts ("\nPCIE2 connected to Slot 1 as ");
-   printf ("%s (base address %lx)",
-   pcie_ep ? "End Point": "Root Complex", 
pci_info[num].regs);
-   first_free_busno = fsl_pci_init_port(&pci_info[num],
+   SET_STD_PCIE_INFO(pci_info[num], 2);
+   printf("PCIE2 connected to Slot 1 as %s (base addr %lx)\n",
+   pcie_ep ? "End Point" : "Root Complex",
+   pci_info[num].regs);
+   first_free_busno = fsl_pci_init_port(&pci_info[num++],
&pcie2_hose, first_free_busno);
-   num++;
} else {
printf ("PCIE2: disabled\n");
}
+   puts("\n");
 #else
set_bits32(&gur->devdisr, MPC85xx_DEVDISR_PCIE2); /* disable */
 #endif
 
 #ifdef CONFIG_PCIE1
-   SET_STD_PCIE_INFO(pci_info[num], 1);
-
pcie_ep = is_fsl_pci_agent(LAW_TRGT_IF_PCIE_1, host_agent);
pcie_configured = is_fsl_pci_cfg(LAW_TRGT_IF_PCIE_1, io_sel);
 
if (pcie_configured && !(devdisr & MPC85xx_DEVDISR_PCIE)){
-   puts ("\nPCIE1 connected to Slot 2 as ");
-   printf ("%s (base address %lx)",
+   SET_STD_PCIE_INFO(pci_info[num], 1);
+   printf("PCIE1 connected to Slot 2 as %s (base addr %lx)\n",
pcie_ep ? "End Point" : "Root Complex",
pci_info[num].regs);
-   first_free_busno = fsl_pci_init_port(&pci_info[num],
+   first_free_busno = fsl_pci_init_port(&pci_info[num++],
&pcie1_hose, first_free_busno);
-   num++;
} else {
printf ("PCIE1: disabled\n");
}
+   puts("\n");
 #else
set_bits32(&gur->devdisr, MPC85xx_DEVDISR_PCIE); /* disable */
 #endif
diff --git a/drivers/pci/fsl_pci_init.c b/drivers/pci/fsl_pci_init.c
index 885542c..87944bf 100644
--- a/drivers/pci/fsl_pci_init.c
+++ b/drivers/pci/fsl_pci_init.c
@@ -450,7 +450,7 @@ int fsl_pci_init_port(struct fsl_pci_info *pci_info,
 
fsl_pci_init(hose, (u32)&pci->cfg_addr, (u32)&pci->cfg_data);
 
-   printf("\nPCIE%x on bus %02x - %02x\n", pci_info->pci_num,
+   printf("PCIE%x on bus %02x - %02x\n", pci_info->pci_num,
hose->first_busno, hose->last_busno);
 
return(hose->last_busno + 1);
-- 
1.6.0.6

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

[U-Boot] [PATCH 2/3] ppc/85xx: Clean up p2020ds PCI setup code

[Kumar Gala]

Use new fsl_pci_init_port() that reduces amount of duplicated code in the
board ports, use IO accessors and clean up printing of status info.

Signed-off-by: Kumar Gala 
---
 board/freescale/p2020ds/p2020ds.c |  150 -
 1 files changed, 33 insertions(+), 117 deletions(-)

diff --git a/board/freescale/p2020ds/p2020ds.c 
b/board/freescale/p2020ds/p2020ds.c
index 7ad9be8..0832fe1 100644
--- a/board/freescale/p2020ds/p2020ds.c
+++ b/board/freescale/p2020ds/p2020ds.c
@@ -192,69 +192,42 @@ static struct pci_controller pcie2_hose;
 static struct pci_controller pcie3_hose;
 #endif
 
-int first_free_busno = 0;
-
 #ifdef CONFIG_PCI
 void pci_init_board(void)
 {
volatile ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
-   uint devdisr = gur->devdisr;
-   uint io_sel = (gur->pordevsr & MPC85xx_PORDEVSR_IO_SEL) >> 19;
-   uint host_agent = (gur->porbmsr & MPC85xx_PORBMSR_HA) >> 16;
+   struct fsl_pci_info pci_info[3];
+   u32 devdisr, pordevsr, io_sel, host_agent;
+   int first_free_busno = 0;
+   int num = 0;
 
-   volatile ccsr_fsl_pci_t *pci;
-   struct pci_controller *hose;
int pcie_ep, pcie_configured;
-   struct pci_region *r;
-/* u32 temp32; */
+
+   devdisr = in_be32(&gur->devdisr);
+   pordevsr = in_be32(&gur->pordevsr);
+   io_sel = (pordevsr & MPC85xx_PORDEVSR_IO_SEL) >> 19;
+   host_agent = (in_be32(&gur->porbmsr) & MPC85xx_PORBMSR_HA) >> 16;
 
debug("   pci_init_board: devdisr=%x, io_sel=%x, host_agent=%x\n",
devdisr, io_sel, host_agent);
 
-   if (!(gur->pordevsr & MPC85xx_PORDEVSR_SGMII2_DIS))
+   if (!(pordevsr & MPC85xx_PORDEVSR_SGMII2_DIS))
printf("eTSEC2 is in sgmii mode.\n");
-   if (!(gur->pordevsr & MPC85xx_PORDEVSR_SGMII3_DIS))
+   if (!(pordevsr & MPC85xx_PORDEVSR_SGMII3_DIS))
printf("eTSEC3 is in sgmii mode.\n");
 
+   puts("\n");
 #ifdef CONFIG_PCIE2
-   pci = (ccsr_fsl_pci_t *) CONFIG_SYS_PCIE2_ADDR;
-   hose = &pcie2_hose;
pcie_ep = is_fsl_pci_agent(LAW_TRGT_IF_PCIE_2, host_agent);
pcie_configured = is_fsl_pci_cfg(LAW_TRGT_IF_PCIE_2, io_sel);
-   r = hose->regions;
 
if (pcie_configured && !(devdisr & MPC85xx_DEVDISR_PCIE2)) {
-   printf("\nPCIE2 connected to ULI as %s (base addr %x)",
+   SET_STD_PCIE_INFO(pci_info[num], 2);
+   printf("PCIE2 connected to ULI as %s (base addr %lx)\n",
pcie_ep ? "End Point" : "Root Complex",
-   (uint)pci);
-   if (pci->pme_msg_det) {
-   pci->pme_msg_det = 0x;
-   debug(" with errors.  Clearing.  Now 0x%08x",
-   pci->pme_msg_det);
-   }
-   printf("\n");
-
-   /* outbound memory */
-   pci_set_region(r++,
-   CONFIG_SYS_PCIE2_MEM_BUS,
-   CONFIG_SYS_PCIE2_MEM_PHYS,
-   CONFIG_SYS_PCIE2_MEM_SIZE,
-   PCI_REGION_MEM);
-
-   /* outbound io */
-   pci_set_region(r++,
-   CONFIG_SYS_PCIE2_IO_BUS,
-   CONFIG_SYS_PCIE2_IO_PHYS,
-   CONFIG_SYS_PCIE2_IO_SIZE,
-   PCI_REGION_IO);
-
-   hose->region_count = r - hose->regions;
-   hose->first_busno = first_free_busno;
-
-   fsl_pci_init(hose, (u32)&pci->cfg_addr, (u32)&pci->cfg_data);
-   first_free_busno = hose->last_busno+1;
-   printf("PCIE2 on bus %02x - %02x\n",
-   hose->first_busno, hose->last_busno);
+   pci_info[num].regs);
+   first_free_busno = fsl_pci_init_port(&pci_info[num++],
+   &pcie2_hose, first_free_busno);
 
/*
 * The workaround doesn't work on p2020 because the location
@@ -279,104 +252,47 @@ void pci_init_board(void)
} else {
printf("PCIE2: disabled\n");
}
+   puts("\n");
 #else
-   gur->devdisr |= MPC85xx_DEVDISR_PCIE2; /* disable */
+   set_bits32(&gur->devdisr, MPC85xx_DEVDISR_PCIE2); /* disable */
 #endif
 
 #ifdef CONFIG_PCIE3
-   pci = (ccsr_fsl_pci_t *) CONFIG_SYS_PCIE3_ADDR;
-   hose = &pcie3_hose;
pcie_ep = is_fsl_pci_agent(LAW_TRGT_IF_PCIE_3, host_agent);
pcie_configured = is_fsl_pci_cfg(LAW_TRGT_IF_PCIE_3, io_sel);
-   r = hose->regions;
 
if (pcie_configured && !(devdisr & MPC85xx_DEVDISR_PCIE3)) {
-   printf("\nPCIE3 connected to Slot 1 as %s (base addr %x)",
+   SET_STD_PCIE_INFO(pci_info[num], 3);
+   printf("PCIE3 connected to Slot 1 as

[U-Boot] [PATCH 3/3] ppc/85xx: Clean up mpc8572DS PCI setup code

[Kumar Gala]

Use new fsl_pci_init_port() that reduces amount of duplicated code in the
board ports, use IO accessors and clean up printing of status info.

Signed-off-by: Kumar Gala 
---
 board/freescale/mpc8572ds/mpc8572ds.c |  226 ++--
 1 files changed, 71 insertions(+), 155 deletions(-)

diff --git a/board/freescale/mpc8572ds/mpc8572ds.c 
b/board/freescale/mpc8572ds/mpc8572ds.c
index c69934c..f8d9713 100644
--- a/board/freescale/mpc8572ds/mpc8572ds.c
+++ b/board/freescale/mpc8572ds/mpc8572ds.c
@@ -160,189 +160,105 @@ static struct pci_controller pcie2_hose;
 static struct pci_controller pcie3_hose;
 #endif
 
-int first_free_busno=0;
 #ifdef CONFIG_PCI
 void pci_init_board(void)
 {
volatile ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
-   uint devdisr = gur->devdisr;
-   uint io_sel = (gur->pordevsr & MPC85xx_PORDEVSR_IO_SEL) >> 19;
-   uint host_agent = (gur->porbmsr & MPC85xx_PORBMSR_HA) >> 16;
+   struct fsl_pci_info pci_info[3];
+   u32 devdisr, pordevsr, io_sel, host_agent, temp32;
+   int first_free_busno = 0;
+   int num = 0;
+
+   int pcie_ep, pcie_configured;
+
+   devdisr = in_be32(&gur->devdisr);
+   pordevsr = in_be32(&gur->pordevsr);
+   io_sel = (pordevsr & MPC85xx_PORDEVSR_IO_SEL) >> 19;
+   host_agent = (in_be32(&gur->porbmsr) & MPC85xx_PORBMSR_HA) >> 16;
 
debug ("   pci_init_board: devdisr=%x, io_sel=%x, host_agent=%x\n",
devdisr, io_sel, host_agent);
 
-   if (!(gur->pordevsr & MPC85xx_PORDEVSR_SGMII1_DIS))
+   if (!(pordevsr & MPC85xx_PORDEVSR_SGMII1_DIS))
printf ("eTSEC1 is in sgmii mode.\n");
-   if (!(gur->pordevsr & MPC85xx_PORDEVSR_SGMII2_DIS))
+   if (!(pordevsr & MPC85xx_PORDEVSR_SGMII2_DIS))
printf ("eTSEC2 is in sgmii mode.\n");
-   if (!(gur->pordevsr & MPC85xx_PORDEVSR_SGMII3_DIS))
+   if (!(pordevsr & MPC85xx_PORDEVSR_SGMII3_DIS))
printf ("eTSEC3 is in sgmii mode.\n");
-   if (!(gur->pordevsr & MPC85xx_PORDEVSR_SGMII4_DIS))
+   if (!(pordevsr & MPC85xx_PORDEVSR_SGMII4_DIS))
printf ("eTSEC4 is in sgmii mode.\n");
 
-
+   puts("\n");
 #ifdef CONFIG_PCIE3
-   {
-   volatile ccsr_fsl_pci_t *pci = (ccsr_fsl_pci_t *) 
CONFIG_SYS_PCIE3_ADDR;
-   struct pci_controller *hose = &pcie3_hose;
-   int pcie_ep = is_fsl_pci_agent(LAW_TRGT_IF_PCIE_3, host_agent);
-   int pcie_configured = is_fsl_pci_cfg(LAW_TRGT_IF_PCIE_3, 
io_sel);
-   struct pci_region *r = hose->regions;
-   u32 temp32;
-
-   if (pcie_configured && !(devdisr & MPC85xx_DEVDISR_PCIE3)){
-   printf ("\nPCIE3 connected to ULI as %s (base 
address %x)",
-   pcie_ep ? "End Point" : "Root Complex",
-   (uint)pci);
-   if (pci->pme_msg_det) {
-   pci->pme_msg_det = 0x;
-   debug (" with errors.  Clearing.  Now 
0x%08x",pci->pme_msg_det);
-   }
-   printf ("\n");
-
-   /* outbound memory */
-   pci_set_region(r++,
-   CONFIG_SYS_PCIE3_MEM_BUS,
-   CONFIG_SYS_PCIE3_MEM_PHYS,
-   CONFIG_SYS_PCIE3_MEM_SIZE,
-   PCI_REGION_MEM);
-
-   /* outbound io */
-   pci_set_region(r++,
-   CONFIG_SYS_PCIE3_IO_BUS,
-   CONFIG_SYS_PCIE3_IO_PHYS,
-   CONFIG_SYS_PCIE3_IO_SIZE,
-   PCI_REGION_IO);
-
-   hose->region_count = r - hose->regions;
-   hose->first_busno=first_free_busno;
-
-   fsl_pci_init(hose, (u32)&pci->cfg_addr, 
(u32)&pci->cfg_data);
-
-   first_free_busno=hose->last_busno+1;
-   printf ("PCIE3 on bus %02x - %02x\n",
-   hose->first_busno,hose->last_busno);
-
-   /*
-* Activate ULI1575 legacy chip by performing a fake
-* memory access.  Needed to make ULI RTC work.
-* Device 1d has the first on-board memory BAR.
-*/
-
-   pci_hose_read_config_dword(hose, PCI_BDF(2, 0x1d, 0 ),
-   PCI_BASE_ADDRESS_1, &temp32);
-   if (temp32 >= CONFIG_SYS_PCIE3_MEM_BUS) {
-   void *p = pci_mem_to_virt(PCI_BDF(2, 0x1d, 0),
-   temp32, 4, 0);
-

Re: [U-Boot] imx27lite stability problems.

[Fred Fan]

Dear Javier Martin:

2009/9/17, javier Martin :
>
> I've found some problems because the cache is enabled, I don't see any
> place where you disable it.
> [Fred] Do you means D-cache is enabled? There are no mmu enabled, D-cache
> should be disabled as default setting.

IAre you sure you have this controlled properly?

--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Configuring BRGs and BRG input clock on an MPC875

[Mikhail Zaturenskiy]

Hello, I thought I'd ask here before I go and make a mess of my code:
what's the easiest way to configure my board to have SMC1 use BRG1,
SCC4 use BRG2, and make my BRG1 and BRG2 use CLK2 as an input clock?

I looked over the code and it looked like most of this is hard-coded
in the "serial.c" file to use BRG1 for everything and I think to use
BRGCLK as the BRG clock source ("serial_setdivisor" function).

My board is similar to the EP88xc by the way.

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

Re: [U-Boot] [TESTING PATCH] ppc: Relocation test patch

[Peter Tyser]

On Thu, 2009-09-17 at 09:06 +0200, Joakim Tjernlund wrote:
> >
> > When preparing the ppc relocation patches I noticed that the gcc
> > -mrelocatable compiler flag increases the .reloc section by 3 or 4
> > Kbytes.  I did a compile test, and this increase pushes the ALPR board
> > back over 256K (it recently had the same size issue, see "ppc4xx: Remove
> > some features from ALPR to fit into 256k again").  No other boards
> > appear to break size-wise.
> >
> > So I guess I had 2 questions:
> > 1. Is enabling proper relocation worth the 3/4KB that will be added to
> > every ppc binary?  I personally think so as the manual relocation fixups
> > that currently litter the code can be removed and true relocation is
> > much less hokey in the long run.  X-ES's U-Boot binaries also are
> > generally much smaller than their allocated 512KB, so this increase
> > doesn't affect me much:)
> 
> You can get some of this space back by just #ifdef:ing out the manual 
> relocation
> code. Removing it completely is OK by me though.

The original patchset I had planned on submitting completely removed all
PPC-specific manual relocation fixups, but didn't do anything with the
references to gd->reloc_off in common files.  The thought was that we
could get other architectures to properly relocate, then get rid of
gd->reloc_off globally.  Otherwise there's going to be a fair number of
#ifdef CONFIG_RELOC_FIXUP_WORKS littering the code until all arches
support proper relocation which is a bit ugly.

With all PPC-specific relocation manual fixups removed, the ALPR still
didn't fit.  However, I just removed all relocation fixups in the common
fpga code as well as added some #ifdef CONFIG_RELOC_FIXUP_WORKS in
common code, and now the ALPR fits in its designated 256KB.  It looks to
be 1.8KB larger than the original, non-relocatable code.

I'll submit this patch for review shortly.  I'm assuming people are OK
with the 1.8KB image size increase?  Perhaps some of Jocke's suggestions
below can decrease the size as well.

Best,
Peter

> The size can be further decreased by looking over the use of global data:
> - Some tables can be replaced by code.
> - Combine several global variables into one struct variable.
> - reducing string literals
> 
> One day we can fit the whole relocation table into built-in CPU memory, 
> hopefully
> that will make it possible to make u-boot a true PIC exe
> 
>  Jocke
> 

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

[U-Boot] AMCC 405EX - EMAC0 + EMAC1 Problems

[Jonathan Haws]

All,

I am having issues getting EMAC1 working alongside EMAC0.  We need 
both EMACs running at the same time in U-Boot (U-Boot handles the PHY 
configuration, since the VxWorks implementation of PHY initialization 
is buggy).

What I have done is this:

In net/eth.c I have modified the eth_init(bd_t *bis) function to 
simply initialize both EMACs (line 443).  We use EMAC0 by default, so 
I set eth_current back to EMAC0 when I am finished and return 0 on 
success.  Here is what the function looks like right now:  (I know I 
can clean this up better, but I am looking for a first cut solution 
that works.  When I have it working, I will clean up the code.)

int eth_init(bd_t *bis)
{
struct eth_device* old_current;

if (!eth_current) {
puts ("No ethernet found.\n");
return -1;
}

old_current = eth_current;
do {
debug ("Trying %s\n", eth_current->name);

if (eth_current->init(eth_current,bis) < 0) {
debug  ("FAIL\n");
eth_try_another(0);
return -1;
}
eth_current->state = ETH_STATE_ACTIVE;
eth_try_another(0);

debug ("Trying %s\n", eth_current->name);
if (eth_current->init(eth_current,bis) < 0) {
debug  ("FAIL\n");
eth_try_another(0);
return -1;
}
eth_current->state = ETH_STATE_ACTIVE;

eth_current = old_current;
return 0;
} while (old_current != eth_current);

return -1;
}

What happens is this, when I boot via TFTP, both EMACs and PHYs get
initialized, but the system hangs as soon as it starts the protocol's 
request (ping, tftp, etc.).

It seems that I am missing something somewhere - I am overwriting some
configuration that I should not be or something of that sort.  But 
shouldn't the EMAC data structure be separated to the point where I 
should be able to initialize them individually without causing 
problems?

Thanks for any insight!

Jonathan


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

Re: [U-Boot] [PATCH 2/3] fsl_i2c: Add CONFIG_FSL_I2C_CUSTOM_{DFSR/FDR}

[Joakim Tjernlund]

>
> Joakim Tjernlund wrote:
>
> > +#ifdef CONFIG_FSL_I2C_CUSTOM_FDR
> > + fdr = CONFIG_FSL_I2C_CUSTOM_FDR;
> > + speed = i2c_clk / divider; /* Fake something */
>
> How about setting 'speed' to CONFIG_SYS_I2C_SPEED?

Naa, if you want that you just pass CONFIG_SYS_I2C_SPEED to
i2c_init(), which is the default.

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

Re: [U-Boot] AMCC 405EX - EMAC0 + EMAC1 Problems

[Ben Warren]

Hi Jonathan ,

Jonathan Haws wrote:
> All,
>
> I am having issues getting EMAC1 working alongside EMAC0.  We need 
> both EMACs running at the same time in U-Boot (U-Boot handles the PHY 
> configuration, since the VxWorks implementation of PHY initialization 
> is buggy).
>
> What I have done is this:
>
> In net/eth.c I have modified the eth_init(bd_t *bis) function to 
> simply initialize both EMACs (line 443).  We use EMAC0 by default, so 
> I set eth_current back to EMAC0 when I am finished and return 0 on 
> success.  Here is what the function looks like right now:  (I know I 
> can clean this up better, but I am looking for a first cut solution 
> that works.  When I have it working, I will clean up the code.)
>
>   
Instead of modifying net/eth.c, I recommend creating a board_eth_init() 
function. Something like this should do:

int board_eth_init(bd_t *bis)
{
struct eth_device *dev;
cpu_eth_init(bis);/* Initialize both EMACs */
dev = eth_get_dev_by_index(1);
dev->init(dev, bis); /* Initialize EMAC1 */
return 0;
}

This way you don't have to monkey around with any of the current/prime 
stuff.
Of course, we would never allow this sort of thing to be submitted to 
mainline because you're not allowed to touch hardware that doesn't get 
used, but what you do in your private code is your business.

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

[U-Boot] SD Card in Spi mode boot mpc8315

[Marcos Cunha]

Dears,

It is possible booting Linux from SD Card or USB mass storage device?

I am using U-boot 1.3.2.

Thanks in advance,

Marcos Cunha
Instituto Atlântico
Electrical Engineer
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] SD Card in Spi mode boot mpc8315

[Konrad Mattheis]

Hi,

SD boot is possible. I already got it working on at91sam9g20.

But just first chance your release.
First go to 2009.08 and try to get it working.

Then you have to check if an sd driver for your CPU already implemented.

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

Re: [U-Boot] AMCC 405EX - EMAC0 + EMAC1 Problems

[Wolfgang Denk]

Dear Jonathan Haws,

In message  you 
wrote:
> 
> I am having issues getting EMAC1 working alongside EMAC0.  We need 
> both EMACs running at the same time in U-Boot (U-Boot handles the PHY 
> configuration, since the VxWorks implementation of PHY initialization 
> is buggy).

Hm... Note that such code will probably not go into mainline. The
principle in U-Boot is not to initialize any devices that are not
used by U-Boot itself, so unless you use a network related command in
U-Boot, none of the Ethenret interfaces shall be initialized; and
U-Boot never uses more than one at a time in any case.

> What I have done is this:
> 
> In net/eth.c I have modified the eth_init(bd_t *bis) function to 
> simply initialize both EMACs (line 443).  We use EMAC0 by default, so 
> I set eth_current back to EMAC0 when I am finished and return 0 on 
> success.  Here is what the function looks like right now:  (I know I 
> can clean this up better, but I am looking for a first cut solution 
> that works.  When I have it working, I will clean up the code.)

NAK. This will not go into mainline.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
There are three ways to get something done:
(1) Do it yourself.
(2) Hire someone to do it for you.
(3) Forbid your kids to do it.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] Correct ffs/fls regression for PowerPC etc

[Wolfgang Denk]

Dear Simon Kagstrom,

In message <20090917151552.013d4...@marrow.netinsight.se> you wrote:
> Correct ffs/fls regression for PowerPC etc
> 
> Commits
> 
>   02f99901ed1c9d828e3ea117f94ce2264bf8389e
>   52d61227b66d4099b39c8309ab37cb67ee09a405
> 
> introduced a regression where platform-specific ffs/fls implementations
> were defined away. This patch corrects that by using PLATFORM_xxx
> instead of the name itself.
> 
> Signed-off-by: Simon Kagstrom 
> ---
> I've runtime tested on ARM (OpenRD base) and build-tested on MPC8536DS,
> where __ilog2_u64 now at least is non-empty. It would be nice if (at
> least!) some PowerPC people could test the patch.
> 
> 
> ChangeLog:
> 
> v2 - Make _all_ macros upper case (Stefan, Wolfgang)
> 
> 
>  include/asm-arm/bitops.h|8 
>  include/asm-blackfin/bitops.h   |   10 +-
>  include/asm-i386/bitops.h   |2 +-
>  include/asm-m68k/bitops.h   |2 +-
>  include/asm-microblaze/bitops.h |3 ++-
>  include/asm-mips/bitops.h   |   13 +
>  include/asm-nios/bitops.h   |2 +-
>  include/asm-nios2/bitops.h  |2 +-
>  include/asm-ppc/bitops.h|4 ++--
>  include/asm-sh/bitops.h |2 +-
>  include/linux/bitops.h  |8 
>  11 files changed, 15 insertions(+), 41 deletions(-)

Applied, thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
It may be bad manners to talk with your mouth full, but it isn't  too
good either if you speak when your head is empty.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Uboot 1.1.3 and USB

[Stephen Banville]

Hello,

I would like to post a problem I am encountering regarding Uboot
1.1.3 and USB.

My processor is  an AMD 1550. In short I am seeing the following error
when I execute

The "usb start" command. I also noticed that a CTL:Timeout occurs. It
appears the Uboot

can see the device, but for some reason the device does not respond to
requests. 

 

 I have browsed through Some mail threads from other folks encountering
the same issue, and the resolution for them resulted

In an upgrade to Uboot 1.1.4. I would like to know if anyone has worked
around / fixed such an issue

without upgrading U-Boot.

 

DEBUG: RET(ctlr) URB:[   0] dev: 0,ep: 0-I,type:CTRL,len:0/8 stat:0x20

DEBUG: usb_new_device() usb_get_descriptor RETURN err: ,
act_len/status;

 8/20

DEBUG: usb_new_device() device_descriptor: 00 00 00 00 00 00 00 08

 

  USB device not responding, giving up (status=20)

 

 

-- ENTIRE DEBUG
OUTPUT 

 

BOOT>usb start

(Re)start USB...

USB:   INFO: aligned ghcca afffe800

DEBUG: USB HC reset_hc usb-au1550: ctrl = 0x0 ;

DEBUG: OHCI controller usb-au1550 state

DEBUG: control: 0x008f HCFS=operational IE PLE CBSR=3

DEBUG: cmdstatus: 0x SOC=0

DEBUG: intrstatus: 0x0004 SF

DEBUG: intrenable: 0x0053 RHSC UE WDH SO

DEBUG: hcca frame #

DEBUG: roothub.a: 02001202 POTPGT=2 NOCP NPS NDP=2

DEBUG: roothub.b:  PPCM= DR=

DEBUG: roothub.status: 

DEBUG: roothub.portstatus [0] = 0x00010101 CSC PPS CCS

DEBUG: roothub.portstatus [1] = 0x0100 PPS

scanning bus for devices... New Device 0

usb_control_msg: request: 0x6, requesttype: 0x80

value 0x100 index 0x0 length 0x8

INFO: submit_control_msg

DEBUG: SUB URB:[   0] dev: 0,ep: 0-I,type:CTRL,len:0/8 stat:0x8000

DEBUG: SUB(rh) URB:[   0] dev: 0,ep: 0-I,type:CTRL,len:0/8
stat:0x8000

INFO: Root-Hub: adr:  0 cmd(8): 0680 0100  0008

DEBUG: roothub.a: 02001202 POTPGT=2 NOCP NPS NDP=2

DEBUG: roothub.b:  PPCM= DR=

DEBUG: roothub.status: 

DEBUG: roothub.portstatus [0] = 0x00010101 CSC PPS CCS

DEBUG: roothub.portstatus [1] = 0x0100 PPS

DEBUG: RET(rh) URB:[   0] dev: 0,ep: 0-I,type:CTRL,len:8/8 stat:0x0

DEBUG: usb_new_device() usb_get_descriptor RETURN err: 8,
act_len/status; 8/0

DEBUG: usb_new_device() device_descriptor: 12 01 10 01 09 00 00 08

set address 1

usb_control_msg: request: 0x5, requesttype: 0x0

value 0x1 index 0x0 length 0x0

INFO: submit_control_msg

DEBUG: SUB URB:[   0] dev: 0,ep: 0-O,type:CTRL,len:0/0 stat:0x8000

DEBUG: SUB(rh) URB:[   0] dev: 0,ep: 0-O,type:CTRL,len:0/0
stat:0x8000

INFO: Root-Hub: adr:  1 cmd(8): 0500 0001  

DEBUG: roothub.a: 02001202 POTPGT=2 NOCP NPS NDP=2

DEBUG: roothub.b:  PPCM= DR=

DEBUG: roothub.status: 

DEBUG: roothub.portstatus [0] = 0x00010101 CSC PPS CCS

DEBUG: roothub.portstatus [1] = 0x0100 PPS

DEBUG: RET(rh) URB:[   0] dev: 0,ep: 0-O,type:CTRL,len:0/0 stat:0x0

usb_control_msg: request: 0x6, requesttype: 0x80

value 0x100 index 0x0 length 0x12

INFO: submit_control_msg

DEBUG: SUB URB:[   0] dev: 1,ep: 0-I,type:CTRL,len:0/18 stat:0x8000

DEBUG: SUB(rh) URB:[   0] dev: 1,ep: 0-I,type:CTRL,len:0/18
stat:0x8000

INFO: Root-Hub: adr:  1 cmd(8): 0680 0100  0012

DEBUG: roothub.a: 02001202 POTPGT=2 NOCP NPS NDP=2

DEBUG: roothub.b:  PPCM= DR=

DEBUG: roothub.status: 

DEBUG: roothub.portstatus [0] = 0x00010101 CSC PPS CCS

DEBUG: roothub.portstatus [1] = 0x0100 PPS

DEBUG: RET(rh) URB:[   0] dev: 1,ep: 0-I,type:CTRL,len:18/18 stat:0x0

DEBUG: usb_new_device() device_descriptor: 12 01 10 01 09 00 00 08 00 00
00 00 00 00 00 01 00 01

usb_control_msg: request: 0x6, requesttype: 0x80

value 0x200 index 0x0 length 0x8

INFO: submit_control_msg

DEBUG: SUB URB:[   0] dev: 1,ep: 0-I,type:CTRL,len:0/8 stat:0x8000

DEBUG: SUB(rh) URB:[   0] dev: 1,ep: 0-I,type:CTRL,len:0/8
stat:0x8000

INFO: Root-Hub: adr:  1 cmd(8): 0680 0200  0008

DEBUG: roothub.a: 02001202 POTPGT=2 NOCP NPS NDP=2

DEBUG: roothub.b:  PPCM= DR=

DEBUG: roothub.status: 

DEBUG: roothub.portstatus [0] = 0x00010101 CSC PPS CCS

DEBUG: roothub.portstatus [1] = 0x0100 PPS

DEBUG: RET(rh) URB:[   0] dev: 1,ep: 0-I,type:CTRL,len:8/8 stat:0x0

usb_control_msg: request: 0x6, requesttype: 0x80

value 0x200 index 0x0 length 0x19

INFO: submit_control_msg

DEBUG: SUB URB:[   0] dev: 1,ep: 0-I,type:CTRL,len:0/25 stat:0x8000

DEBUG: SUB(rh) URB:[   0] dev: 1,ep: 0-I,type:CTRL,len:0/25
stat:0x8000

INFO: Root-Hub: adr:  1 cmd(8): 0680 0200  0019

DEBUG: roothub.a: 02001202 POTPGT=2 NOCP NPS NDP=2

DEBUG: roothub.b:  PPCM= DR=

DEBUG: roothub.status: 

DEBUG: roothub.portstatus [0] = 0x00010101 CSC PPS CCS

DEBUG: roothub.portstatus [1] = 0x0100 PPS

DEBUG: RET(rh) URB:[   0] dev: 1,ep

Re: [U-Boot] Please pull u-boot-ppc4xx

[Wolfgang Denk]

Dear Stefan Roese,

In message <200909171411.29825...@denx.de> you wrote:
> Hi Wolfgang,
> 
> please pull the following changes:
> 
> The following changes since commit 15fba3279b56333bdb65ead366f82c945ed320d1:
>   Kumar Gala (1):
> ppc/85xx: Disable all async interrupt sources when we boot
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-ppc4xx.git master
> 
> Stefan Roese (3):
>   ppc4xx: Fix 405EZ uart base baud calculation
>   ppc4xx: Enable commands for FDT enabled Linux booting on AMCC Acadia
>   ppc4xx: Consolidate get_OPB_freq()
> 
>  cpu/ppc4xx/speed.c   |   96 
> ++
>  include/configs/acadia.h |3 +-
>  2 files changed, 22 insertions(+), 77 deletions(-)

Done, thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
At the source of every error which is blamed on the computer you will
find at least two human errors, including the error of blaming it  on
the computer.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Uboot 1.1.3 and USB

[Wolfgang Denk]

Dear Stephen Banville,

In message <54ac63178735ed46bac5f5e668a9f224de8...@alfalfa.fortresstech.com> 
you wrote:
>
> I would like to post a problem I am encountering regarding Uboot
> 1.1.3 and USB.

U-Boot 1.1.3 is more trhan 4 years old. Guess what? A *lot* of things
have changed since.

> In an upgrade to Uboot 1.1.4. I would like to know if anyone has worked
> around / fixed such an issue

Heh. And you call this "upgrade"? U-Boot 1.1.4 is still more than 3
years old.

Do yourself a favour and really _update_ your code, i. e. use v2009.08
or top of tree from the git repository.



Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"Ada is PL/I trying to be Smalltalk. - Codoso diBlini
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [TESTING PATCH] ppc: Relocation test patch

[Graeme Russ]

On Thu, Sep 17, 2009 at 10:53 PM, Wolfgang Denk  wrote:
> Dear Joakim Tjernlund,
>
> In message 
>  you 
> wrote:
>>
>> > But why has the GOT table to fit "into built-in CPU memory"? When we
>> > are about to relocate U-Boot to RAM, we already have RAM working. So
>> > we should also be able to copy the GOT table to RAM and modify it
>> > there as needed before we use it?
>>
>> Before you get RAM working there are lots of references to global data and
>> string literals. These point to their link address so if you have loaded
>> u-boot at a different address than you link address you have to adjust for
>> the offset. Hard to do that when GOT is in flash :(
>
> Ah, I finally GOT you :-)
>
> Hm... but being able to load (and start) U-Boot from an arbitrary RAM
> location would be a big benefit, too, even if we still have to copy it
> to the correct (linked) address when storing it in flash.

Things are starting to make a lot of sense to me now - I thought all this
relocation work on PPC was full relocation, but I see now that it only
relates to relocation of code segments.

The biggest problem (for me anyway) in not relocating data segments
(particularly .rodata) is that any time you attempt to lock or erase the
flash, U-Boot can crash. This prevents (again, for me) updating the U-Boot
image in flash on-board from within U-Boot itself.

I am working on full relocation on the x86 port (about 85% done) - It is
a real pita because not only do you need to update the GOT, you also need
to worry about any other references not known to the linker - Jumping to
C interupt handlers from inline asm is my big headache at the moment

I hope to have a patch out in the next few weeks for x86 which will
illustrate the concepts of full relocation.

Regards,

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

[U-Boot] [PATCH v3 2/3] On-chip ROM boot: MPC8536DS support

[Mingkai Hu]

The MPC8536E is capable of booting from the on-chip ROM - boot from
eSDHC and boot from eSPI. When power on, the porcessor excutes the
ROM code to initialize the eSPI/eSDHC controller, and loads the mian
U-Boot image from the memory device that interfaced to the controller,
such as the SDCard or SPI EEPROM, to the target memory, e.g. SDRAM or
L2SRAM, then boot from it.

The memory device should contain a specific data structure with control
word and config word at the fixed address. The config word direct the
process how to config the memory device, and the control word direct
the processor where to find the image on the memory device, or where
copy the main image to. The user can use any method to store the data
structure to the memory device, only if store it on the assigned address.

The on-chip ROM code will map the whole 4GB address space by setting
entry0 in the TLB1, so the main image need to switch to Address space 1
to disable this mapping and map the address space again.

This patch implements loading the mian U-Boot image into L2SRAM, so
the image can configure the system memory by using SPD EEPROM.

Signed-off-by: Mingkai Hu 
---

Change over v2:
 - Intergrated Kumar's comments.
 - Aligned to the leatest git tree

 MAKEALL |2 ++
 Makefile|2 ++
 board/freescale/mpc8536ds/config.mk |   12 
 include/configs/MPC8536DS.h |   17 -
 4 files changed, 32 insertions(+), 1 deletions(-)

diff --git a/MAKEALL b/MAKEALL
index 283add0..97600f2 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -379,6 +379,8 @@ LIST_85xx=" \
ATUM8548\
MPC8536DS   \
MPC8536DS_NAND  \
+   MPC8536DS_SDCARD\
+   MPC8536DS_SPIFLASH  \
MPC8540ADS  \
MPC8540EVAL \
MPC8541CDS  \
diff --git a/Makefile b/Makefile
index 4d18a9f..8f7f7c3 100644
--- a/Makefile
+++ b/Makefile
@@ -2447,6 +2447,8 @@ ATUM8548_config:  unconfig
@$(MKCONFIG) $(@:_config=) ppc mpc85xx atum8548
 
 MPC8536DS_NAND_config \
+MPC8536DS_SDCARD_config \
+MPC8536DS_SPIFLASH_config \
 MPC8536DS_36BIT_config \
 MPC8536DS_config:   unconfig
@$(MKCONFIG) -t $(@:_config=) MPC8536DS ppc mpc85xx mpc8536ds freescale
diff --git a/board/freescale/mpc8536ds/config.mk 
b/board/freescale/mpc8536ds/config.mk
index d6490b5..e38af73 100644
--- a/board/freescale/mpc8536ds/config.mk
+++ b/board/freescale/mpc8536ds/config.mk
@@ -30,8 +30,20 @@ LDSCRIPT := $(TOPDIR)/cpu/$(CPU)/u-boot-nand.lds
 endif
 endif
 
+ifeq ($(CONFIG_MK_SDCARD), y)
+TEXT_BASE = $(CONFIG_RAMBOOT_TEXT_BASE)
+RESET_VECTOR_ADDRESS = 0xf8fc
+endif
+
+ifeq ($(CONFIG_MK_SPIFLASH), y)
+TEXT_BASE = $(CONFIG_RAMBOOT_TEXT_BASE)
+RESET_VECTOR_ADDRESS = 0xf8fc
+endif
+
 ifndef TEXT_BASE
 TEXT_BASE = 0xeff8
 endif
 
+ifndef RESET_VECTOR_ADDRESS
 RESET_VECTOR_ADDRESS = 0xeffc
+endif
diff --git a/include/configs/MPC8536DS.h b/include/configs/MPC8536DS.h
index b6f1e60..97091d4 100644
--- a/include/configs/MPC8536DS.h
+++ b/include/configs/MPC8536DS.h
@@ -37,6 +37,16 @@
 #define CONFIG_RAMBOOT_TEXT_BASE   0xf8f82000
 #endif
 
+#ifdef CONFIG_MK_SDCARD
+#define CONFIG_RAMBOOT_SDCARD  1
+#define CONFIG_RAMBOOT_TEXT_BASE   0xf8f8
+#endif
+
+#ifdef CONFIG_MK_SPIFLASH
+#define CONFIG_RAMBOOT_SPIFLASH1
+#define CONFIG_RAMBOOT_TEXT_BASE   0xf8f8
+#endif
+
 /* High Level Configuration Options */
 #define CONFIG_BOOKE   1   /* BOOKE */
 #define CONFIG_E5001   /* BOOKE e500 family */
@@ -231,7 +241,8 @@ extern unsigned long get_board_ddr_clk(unsigned long dummy);
 
 #define CONFIG_SYS_MONITOR_BASETEXT_BASE   /* start of monitor */
 
-#if defined(CONFIG_SYS_SPL) || defined(CONFIG_RAMBOOT_NAND)
+#if defined(CONFIG_SYS_SPL) || defined(CONFIG_RAMBOOT_NAND) \
+   || defined(CONFIG_RAMBOOT_SDCARD) || defined(CONFIG_RAMBOOT_SPIFLASH)
 #define CONFIG_SYS_RAMBOOT
 #else
 #undef CONFIG_SYS_RAMBOOT
@@ -622,6 +633,10 @@ extern unsigned long get_board_ddr_clk(unsigned long 
dummy);
#define CONFIG_ENV_IS_IN_NAND   1
#define CONFIG_ENV_SIZE CONFIG_SYS_NAND_BLOCK_SIZE
#define CONFIG_ENV_OFFSET   ((512 * 1024) + 
CONFIG_SYS_NAND_BLOCK_SIZE)
+#elif defined(CONFIG_RAMBOOT_SDCARD) || defined(CONFIG_RAMBOOT_SPIFLASH)
+   #define CONFIG_ENV_IS_NOWHERE   1   /* Store ENV in memory only */
+   #define CONFIG_ENV_ADDR (CONFIG_SYS_MONITOR_BASE - 0x1000)
+   #define CONFIG_ENV_SIZE 0x2000
 #endif
 #else
#define CONFIG_ENV_IS_IN_FLASH  1
-- 
1.6.4

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

[U-Boot] [PATCH v3 1/3] NAND boot: MPC8536DS support

[Mingkai Hu]

MPC8536E can support booting from NAND flash which uses the
image u-boot-nand.bin. This image contains two parts: a 4K
NAND loader and a main U-Boot image. The former is appended
to the latter to produce u-boot-nand.bin. The 4K NAND loader
includes the corresponding nand_spl directory, along with the
code twisted by CONFIG_NAND_SPL. The main U-Boot image just
like a general U-Boot image except the parts that included by
CONFIG_SYS_RAMBOOT.

When power on, eLBC will automatically load from bank 0 the
4K NAND loader into the FCM buffer RAM where CPU can execute
the boot code directly. In the first stage, the NAND loader
copies itself to RAM or L2SRAM to free up the FCM buffer RAM,
then loads the main image from NAND flash to RAM or L2SRAM
and boot from it.

This patch implements the NAND loader to load the main image
into L2SRAM, so the main image can configure the RAM by using
SPD EEPROM. In the first stage, the NAND loader copies itself
to the second to last 4K address space, and uses the last 4K
address space as the initial RAM for stack.

Obviously, the size of L2SRAM shouldn't be less than the size
of the image used. If so, the workaround is to generate another
image that includes the code to configure the RAM by SPD and
load it to L2SRAM first, then relocate the main image to RAM
to boot up.

Signed-off-by: Mingkai Hu 
---

Change over v2:
 - Intergrated Kumar's comments.
 - Aligned to the leatest git tree

 MAKEALL|1 +
 Makefile   |1 +
 board/freescale/mpc8536ds/config.mk|7 ++
 board/freescale/mpc8536ds/tlb.c|   11 ++
 cpu/mpc85xx/cpu_init_nand.c|   69 +
 include/configs/MPC8536DS.h|   96 +++
 nand_spl/board/freescale/mpc8536ds/Makefile|  123 
 nand_spl/board/freescale/mpc8536ds/nand_boot.c |   99 +++
 nand_spl/board/freescale/mpc8536ds/u-boot.lds  |   67 +
 9 files changed, 454 insertions(+), 20 deletions(-)
 create mode 100644 cpu/mpc85xx/cpu_init_nand.c
 create mode 100644 nand_spl/board/freescale/mpc8536ds/Makefile
 create mode 100644 nand_spl/board/freescale/mpc8536ds/nand_boot.c
 create mode 100644 nand_spl/board/freescale/mpc8536ds/u-boot.lds

diff --git a/MAKEALL b/MAKEALL
index 1d50c34..283add0 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -378,6 +378,7 @@ LIST_83xx=" \
 LIST_85xx="\
ATUM8548\
MPC8536DS   \
+   MPC8536DS_NAND  \
MPC8540ADS  \
MPC8540EVAL \
MPC8541CDS  \
diff --git a/Makefile b/Makefile
index 99837a3..4d18a9f 100644
--- a/Makefile
+++ b/Makefile
@@ -2446,6 +2446,7 @@ vme8349_config:   unconfig
 ATUM8548_config:   unconfig
@$(MKCONFIG) $(@:_config=) ppc mpc85xx atum8548
 
+MPC8536DS_NAND_config \
 MPC8536DS_36BIT_config \
 MPC8536DS_config:   unconfig
@$(MKCONFIG) -t $(@:_config=) MPC8536DS ppc mpc85xx mpc8536ds freescale
diff --git a/board/freescale/mpc8536ds/config.mk 
b/board/freescale/mpc8536ds/config.mk
index c1d0525..d6490b5 100644
--- a/board/freescale/mpc8536ds/config.mk
+++ b/board/freescale/mpc8536ds/config.mk
@@ -23,6 +23,13 @@
 #
 # mpc8536ds board
 #
+ifndef NAND_SPL
+ifeq ($(CONFIG_MK_NAND), y)
+TEXT_BASE = $(CONFIG_RAMBOOT_TEXT_BASE)
+LDSCRIPT := $(TOPDIR)/cpu/$(CPU)/u-boot-nand.lds
+endif
+endif
+
 ifndef TEXT_BASE
 TEXT_BASE = 0xeff8
 endif
diff --git a/board/freescale/mpc8536ds/tlb.c b/board/freescale/mpc8536ds/tlb.c
index 35a13d4..dc52d7f 100644
--- a/board/freescale/mpc8536ds/tlb.c
+++ b/board/freescale/mpc8536ds/tlb.c
@@ -71,6 +71,17 @@ struct fsl_e_tlb_entry tlb_table[] = {
SET_TLB_ENTRY(1, CONFIG_SYS_NAND_BASE, CONFIG_SYS_NAND_BASE_PHYS,
  MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
  0, 4, BOOKE_PAGESZ_1M, 1),
+
+#if defined(CONFIG_SYS_RAMBOOT) && defined(CONFIG_SYS_INIT_L2_ADDR)
+   /* *I*G - L2SRAM */
+   SET_TLB_ENTRY(1, CONFIG_SYS_INIT_L2_ADDR, CONFIG_SYS_INIT_L2_ADDR_PHYS,
+ MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
+ 0, 5, BOOKE_PAGESZ_256K, 1),
+   SET_TLB_ENTRY(1, CONFIG_SYS_INIT_L2_ADDR + 0x4,
+ CONFIG_SYS_INIT_L2_ADDR_PHYS + 0x4,
+ MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
+ 0, 6, BOOKE_PAGESZ_256K, 1),
+#endif
 };
 
 int num_tlb_entries = ARRAY_SIZE(tlb_table);
diff --git a/cpu/mpc85xx/cpu_init_nand.c b/cpu/mpc85xx/cpu_init_nand.c
new file mode 100644
index 000..e62f8d3
--- /dev/null
+++ b/cpu/mpc85xx/cpu_init_nand.c
@@ -0,0 +1,69 @@
+/*
+ * Copyright 2009 Freescale Semiconductor, Inc.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software

[U-Boot] [PATCH v3 3/3] Add README.mpc8536ds

[Mingkai Hu]

Add boot from NAND/eSDHC/eSPI description

Signed-off-by: Mingkai Hu 
---

No change over v2, it comes here for the pick up convience.

 doc/README.mpc8536ds |  127 ++
 1 files changed, 127 insertions(+), 0 deletions(-)
 create mode 100644 doc/README.mpc8536ds

diff --git a/doc/README.mpc8536ds b/doc/README.mpc8536ds
new file mode 100644
index 000..4d0bee0
--- /dev/null
+++ b/doc/README.mpc8536ds
@@ -0,0 +1,127 @@
+Overview:
+=
+
+The MPC8536E integrates a PowerPC processor core with system logic
+required for imaging, networking, and communications applications.
+
+Boot from NAND:
+===
+
+The MPC8536E is capable of booting from NAND flash which uses the image
+u-boot-nand.bin. This image contains two parts: a first stage image(also
+call 4K NAND loader and a second stage image. The former is appended to
+the latter to produce u-boot-nand.bin.
+
+The bootup process can be divided into two stages: the first stage will
+configure the L2SRAM, then copy the second stage image to L2SRAM and jump
+to it. The second stage image is to configure all the hardware and boot up
+to U-Boot command line.
+
+The 4K NAND loader's code comes from the corresponding nand_spl directory,
+along with the code twisted by CONFIG_NAND_SPL. The macro CONFIG_NAND_SPL
+is mainly used to shrink the code size to the 4K size limitation.
+
+The macro CONFIG_SYS_RAMBOOT is used to control the code to produce the
+second stage image. It's set in the board config file when boot from NAND
+is selected.
+
+Build and boot steps
+
+
+1. Building image
+   make MPC8536DS_NAND_config
+   make CROSS_COMPILE=powerpc-none-linux-gnuspe- all
+
+2. Change dip-switch
+   SW2[5-8] = 1011
+   SW9[1-3] = 101
+   Note: 1 stands for 'on', 0 stands for 'off'
+
+3. Flash image
+   tftp 100 u-boot-nand.bin
+   nand erase 0 a
+   nand write 100 0 a
+
+Boot from On-chip ROM:
+==
+
+The MPC8536E is capable of booting from the on-chip ROM - boot from eSDHC
+and boot from eSPI. When power on, the porcessor excutes the ROM code to
+initialize the eSPI/eSDHC controller, and loads the mian U-Boot image from
+the memory device that interfaced to the controller, such as the SDCard or
+SPI EEPROM, to the target memory, e.g. SDRAM or L2SRAM, then boot from it.
+
+The memory device should contain a specific data structure with control word
+and config word at the fixed address. The config word direct the process how
+to config the memory device, and the control word direct the processor where
+to find the image on the memory device, or where copy the main image to. The
+user can use any method to store the data structure to the memory device, only
+if store it on the assigned address.
+
+Build and boot steps
+
+
+For boot from eSDHC:
+1. Build image
+   make MPC8536DS_SDCARD_config
+   make CROSS_COMPILE=powerpc-none-linux-gnuspe- all
+
+2. Change dip-switch
+   SW2[5-8] = 0111
+   SW3[1]   = 0
+   SW8[7]   = 0 - The on-board SD/MMC slot is active
+   SW8[7]   = 1 - The externel SD/MMC slot is active
+
+3. Put image to SDCard
+   Put the follwing info at the assigned address on the SDCard:
+
+  Offset   |   Data | Description
+   
+   | 0x40-0x43 | 0x424F4F54 | BOOT signature  |
+   
+   | 0x48-0x4B | 0x0008 | u-boot.bin's size   |
+   
+   | 0x50-0x53 | 0x | u-boot.bin's Addr on SDCard |
+   
+   | 0x58-0x5B | 0xF8F8 | Target Address  |
+   ---
+   | 0x60-0x63 | 0xF8FFF000 | Execution Starting Address  |
+   
+   | 0x68-0x6B | 0x6| Number of Config Addr/Data  |
+   
+   | 0x80-0x83 | 0xFF720100 | Config Addr 1   |
+   | 0x84-0x87 | 0xF8F8 | Config Data 1   |
+   
+   | 0x88-0x8b | 0xFF720e44 | Config Addr 2   |
+   | 0x8c-0x8f | 0x000C | Config Data 2   |
+   
+   | 0x90-0x93 | 0xFF72 | Config Addr 3   |
+   | 0x94-0x97 | 0x8001 | Config Data 3   |
+   
+   | 0x98-0x9b | 0xFF72e40e | Config Addr 4   |
+   | 0x9c-0x9f | 0x0040 | Config Data 4   |
+   
+   | 0xa0-0xa3 | 0x4001 | Config

[U-Boot] [PATCH] mpc8536: simplify the top makefile for 36-bit config

[Mingkai Hu]

Signed-off-by: Mingkai Hu 
---
 Makefile|4 +---
 include/configs/MPC8536DS.h |2 +-
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/Makefile b/Makefile
index 0b61d05..99837a3 100644
--- a/Makefile
+++ b/Makefile
@@ -2448,9 +2448,7 @@ ATUM8548_config:  unconfig
 
 MPC8536DS_36BIT_config \
 MPC8536DS_config:   unconfig
-   @mkdir -p $(obj)include
-   @echo "#define CONFIG_$(@:_config=) 1"  >$(obj)include/config.h
-   @$(MKCONFIG) -a MPC8536DS ppc mpc85xx mpc8536ds freescale
+   @$(MKCONFIG) -t $(@:_config=) MPC8536DS ppc mpc85xx mpc8536ds freescale
 
 MPC8540ADS_config: unconfig
@$(MKCONFIG) $(@:_config=) ppc mpc85xx mpc8540ads freescale
diff --git a/include/configs/MPC8536DS.h b/include/configs/MPC8536DS.h
index 4746e2e..faca805 100644
--- a/include/configs/MPC8536DS.h
+++ b/include/configs/MPC8536DS.h
@@ -27,7 +27,7 @@
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
-#ifdef CONFIG_MPC8536DS_36BIT
+#ifdef CONFIG_MK_36BIT
 #define CONFIG_PHYS_64BIT  1
 #endif
 
-- 
1.6.4

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

[U-Boot] [PATCH] ppc/85xx: simplify the top makefile for 36-bit config for mpc8536ds

[Mingkai Hu]

Signed-off-by: Mingkai Hu 
---

Sorry for the spam, ingnor the [PATCH] mpc8536: simplify the top makefile for 
36-bit config,
this is the new version.

 Makefile|4 +---
 include/configs/MPC8536DS.h |2 +-
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/Makefile b/Makefile
index 0b61d05..99837a3 100644
--- a/Makefile
+++ b/Makefile
@@ -2448,9 +2448,7 @@ ATUM8548_config:  unconfig
 
 MPC8536DS_36BIT_config \
 MPC8536DS_config:   unconfig
-   @mkdir -p $(obj)include
-   @echo "#define CONFIG_$(@:_config=) 1"  >$(obj)include/config.h
-   @$(MKCONFIG) -a MPC8536DS ppc mpc85xx mpc8536ds freescale
+   @$(MKCONFIG) -t $(@:_config=) MPC8536DS ppc mpc85xx mpc8536ds freescale
 
 MPC8540ADS_config: unconfig
@$(MKCONFIG) $(@:_config=) ppc mpc85xx mpc8540ads freescale
diff --git a/include/configs/MPC8536DS.h b/include/configs/MPC8536DS.h
index 4746e2e..faca805 100644
--- a/include/configs/MPC8536DS.h
+++ b/include/configs/MPC8536DS.h
@@ -27,7 +27,7 @@
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
-#ifdef CONFIG_MPC8536DS_36BIT
+#ifdef CONFIG_MK_36BIT
 #define CONFIG_PHYS_64BIT  1
 #endif
 
-- 
1.6.4

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

[U-Boot] Hanging in kmalloc of nand_scan_tail() function

[J.Hwan.Kim]

Hi, everyone

I'm using U-boot 2009-03.
U-boot hangs in nand_init() function.
I found the routine kmalloc in nand_scan_tail() cause U-boot reset.


int nand_scan_tail(struct mtd_info *mtd)
{
int i;
struct nand_chip *chip = mtd->priv;

if (!(chip->options & NAND_OWN_BUFFERS)) {
chip->buffers = kmalloc(sizeof(*chip->buffers), GFP_KERNEL);   
}

if (!chip->buffers)
return -ENOMEM;
  


U-boot displays message as follows :

NAND:  data abort
pc : [<31f902b4>]\0x09   lr : [<31fa084c>]
sp : 31f5bee0  ip : 0076\0x09 fp : 
r10: 1188  r9 : 0002\0x09 r8 : 31f5bfdc
r7 : 0001  r6 : \0x09 r5 : 31fa42b8  r4 : 31fa4364
r3 : 31fa052c  r2 : 0064\0x09 r1 : 0063  r0 : 
Flags: NzCv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...


Where the malloc function is defined?
Why the kmalloc() hangs the u-boot?
Is there any configuation definition needed?

Thanks in advance.

Regards,
J.Hwan Kim


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

[U-Boot] Details of fw_env.config file

[Rahanesh]

Hi All,.

I wanted to know the meaning of Device Offset in the config file 
(fw_env.config).

I used it as

  MTD device name   Device offset   Env. size   Flash sector size   
Number of sectors
   /dev/mtd0   0x0x1000  0x1

The partition mtd0 contains uboot as well as Environment variables.
when i used fw_setenv command to set the boot delay to 6, it actually 
erased my u-boot itself.

Should i Keep Environment variables in separate mtd partition say mtd1.?

Is it enough to change the device offset to point the environment 
variables within mtd1 itself?

Please help


Thanks
Rahanesh


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

Re: [U-Boot] AMCC 405EX - EMAC0 + EMAC1 Problems

[Stefan Roese]

Hi Jonathan,

On Thursday 17 September 2009 20:00:42 Jonathan Haws wrote:
> I am having issues getting EMAC1 working alongside EMAC0.  We need
> both EMACs running at the same time in U-Boot (U-Boot handles the PHY
> configuration, since the VxWorks implementation of PHY initialization
> is buggy).

If the VxWorks PHY init is "buggy", then you should probably fix this VxWorks 
code.

Cheers,
Stefan

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

Re: [U-Boot] [TESTING PATCH] ppc: Relocation test patch

[Joakim Tjernlund]

Graeme Russ  wrote on 17/09/2009 23:57:56:
>
> On Thu, Sep 17, 2009 at 10:53 PM, Wolfgang Denk  wrote:
> > Dear Joakim Tjernlund,
> >
> > In message  00451...@transmode.se> you wrote:
> >>
> >> > But why has the GOT table to fit "into built-in CPU memory"? When we
> >> > are about to relocate U-Boot to RAM, we already have RAM working. So
> >> > we should also be able to copy the GOT table to RAM and modify it
> >> > there as needed before we use it?
> >>
> >> Before you get RAM working there are lots of references to global data and
> >> string literals. These point to their link address so if you have loaded
> >> u-boot at a different address than you link address you have to adjust for
> >> the offset. Hard to do that when GOT is in flash :(
> >
> > Ah, I finally GOT you :-)
> >
> > Hm... but being able to load (and start) U-Boot from an arbitrary RAM
> > location would be a big benefit, too, even if we still have to copy it
> > to the correct (linked) address when storing it in flash.
>
> Things are starting to make a lot of sense to me now - I thought all this
> relocation work on PPC was full relocation, but I see now that it only
> relates to relocation of code segments.

Nope, this patch does full relocation but must start from flash at its
linked address. Then it relocates to RAM and bring everything into RAM.
PCC has a "fixup" (-mrelocate) option that emits relocation entries for
strings and global function pointers etc.

>
> The biggest problem (for me anyway) in not relocating data segments
> (particularly .rodata) is that any time you attempt to lock or erase the
> flash, U-Boot can crash. This prevents (again, for me) updating the U-Boot
> image in flash on-board from within U-Boot itself.

yes, although it does not seem to happen often.

>
> I am working on full relocation on the x86 port (about 85% done) - It is
> a real pita because not only do you need to update the GOT, you also need
> to worry about any other references not known to the linker - Jumping to
> C interupt handlers from inline asm is my big headache at the moment

yeah, you will need to emit relocation info for those function pointers
I guess. As I remember PPC has something similar, look in start.S

  Jocke

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

Re: [U-Boot] imx27lite stability problems.

[javier Martin]

2009/9/17 Fred Fan :
> Dear Javier Martin:
>
> 2009/9/17, javier Martin :
>>
>> I've found some problems because the cache is enabled, I don't see any
>> place where you disable it.
>> [Fred] Do you means D-cache is enabled? There are no mmu enabled, D-cache
>> should be disabled as default setting.

This is what I also though but I found it making some debugging
through JTAG + GDB.

As I stated in my first mail, FEC driver was getting stuck after
transmitting a frame in a while() loop. However, using wireshark the
frame had actually been sent. And using GDB I found that in the SDRAM
the while() condition was true, nevertheless the microprocessor was
evaluating it as false. That seemed to cache issues to me, so I put a
"dcache_disable()" just before that while() loop and saw that these
problems were not happening anymore.

What is your opinion?
Thanks.

-- 
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot