Re: [U-Boot] at91sam9263_nandflash build issues

[Reinhard Meyer]

Dear Marek Vasut,

> The problem is clear from this IRC log, where "vickylinuxer" described his 
> grief 
> (so I included the log, the board really doesn't build). I also did a quick 
> and 
> dirty patch (follows the log, it might give you an idea where it breaks, but 
> it's a mess -- not all is relevant and it probably breaks it even more).

All ATMEL AT91 boards except for AT91SAM9260ek (which I fixed) boards are 
currently broken.
People are working towards bringing the others in-line again, but that will 
take time.

> diff --git a/drivers/serial/atmel_usart.c b/drivers/serial/atmel_usart.c
> index bfa1f3a..1cc8bc0 100644
> --- a/drivers/serial/atmel_usart.c
> +++ b/drivers/serial/atmel_usart.c
> @@ -23,6 +23,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 

Things like that are fixed at u-boot-atmel.git/rework101228...

> diff --git a/drivers/spi/atmel_dataflash_spi.c 
> b/drivers/spi/atmel_dataflash_spi.c
> index 4a5c4aa..d5215c0 100644
> --- a/drivers/spi/atmel_dataflash_spi.c
> +++ b/drivers/spi/atmel_dataflash_spi.c
> @@ -158,12 +158,12 @@ unsigned int AT91F_SpiWrite(AT91PS_DataflashDesc pDesc)
> }
>  
> /* arm simple, non interrupt dependent timer */
> -   reset_timer_masked();
> +   reset_timer();

NO. reset_timer() is not acceptable anymore. A fix is already in the list, I 
just need
some time to handle it all:)

> diff --git a/include/configs/at91sam9263ek.h b/include/configs/at91sam9263ek.h
> index f6cb406..3db8bd0 100644
> --- a/include/configs/at91sam9263ek.h
> +++ b/include/configs/at91sam9263ek.h
> @@ -27,6 +27,9 @@
>  #ifndef __CONFIG_H
>  #define __CONFIG_H
>  
> +#define CONFIG_AT91_LEGACY

There should be no need for LEGACY anymore.

I have project deadlines I must meet first, then I will handle all accumulated 
AT91 patches.

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

Re: [U-Boot] AT91: dataflash: was at91sam9263_nandflash build issues

[Reinhard Meyer]

Just noticed that the subject was wrong!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] at91sam9263_nandflash build issues

[Marek Vasut]

On Wednesday 02 February 2011 09:16:46 Reinhard Meyer wrote:
> Dear Marek Vasut,
> 

Hi,

> > The problem is clear from this IRC log, where "vickylinuxer" described
> > his grief (so I included the log, the board really doesn't build). I
> > also did a quick and dirty patch (follows the log, it might give you an
> > idea where it breaks, but it's a mess -- not all is relevant and it
> > probably breaks it even more).
> 
> All ATMEL AT91 boards except for AT91SAM9260ek (which I fixed) boards are
> currently broken. People are working towards bringing the others in-line
> again, but that will take time.

All right. No need to worry, we all are busy :)
> 
> > diff --git a/drivers/serial/atmel_usart.c b/drivers/serial/atmel_usart.c
> > index bfa1f3a..1cc8bc0 100644
> > --- a/drivers/serial/atmel_usart.c
> > +++ b/drivers/serial/atmel_usart.c
> > @@ -23,6 +23,7 @@
> > 
> >  #include 
> >  #include 
> > 
> > +#include 
> > 
> >  #include 
> 
> Things like that are fixed at u-boot-atmel.git/rework101228...

Ok, good to know.

> 
> > diff --git a/drivers/spi/atmel_dataflash_spi.c
> > b/drivers/spi/atmel_dataflash_spi.c index 4a5c4aa..d5215c0 100644
> > --- a/drivers/spi/atmel_dataflash_spi.c
> > +++ b/drivers/spi/atmel_dataflash_spi.c
> > @@ -158,12 +158,12 @@ unsigned int AT91F_SpiWrite(AT91PS_DataflashDesc
> > pDesc)
> > 
> > }
> > 
> > /* arm simple, non interrupt dependent timer */
> > 
> > -   reset_timer_masked();
> > +   reset_timer();
> 
> NO. reset_timer() is not acceptable anymore. A fix is already in the list,
> I just need some time to handle it all:)

Ok, it was just a very quick thing with no thinking involved.

> 
> > diff --git a/include/configs/at91sam9263ek.h
> > b/include/configs/at91sam9263ek.h index f6cb406..3db8bd0 100644
> > --- a/include/configs/at91sam9263ek.h
> > +++ b/include/configs/at91sam9263ek.h
> > @@ -27,6 +27,9 @@
> > 
> >  #ifndef __CONFIG_H
> >  #define __CONFIG_H
> > 
> > +#define CONFIG_AT91_LEGACY
> 
> There should be no need for LEGACY anymore.
> 
> I have project deadlines I must meet first, then I will handle all
> accumulated AT91 patches.

Ok, as I don't have any AT91 hardware, I can't help anymore :)

Cheers

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

Re: [U-Boot] spi subystem maintainer?

[Stefano Babic]

On 02/02/2011 08:23 AM, Kumar Gala wrote:
> Wanted to see if anyone had input on how to deal with the SPI
> controller on some of our newer parts.  It expects command & data
> xfer's to happen together.  However our current code does not call
> spi_xfer() that way.

Which is your concrete case ? spi_xfer is responsible to setup the
controller and to start the transfer, and everything could be done
inside this function. What do you mean exactly with command and data ?

Regards,
Stefano

-- 
=
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] spi subystem maintainer?

[Reinhard Meyer]

Dear Stefano Babic:
> On 02/02/2011 08:23 AM, Kumar Gala wrote:
>> Wanted to see if anyone had input on how to deal with the SPI
>> controller on some of our newer parts.  It expects command & data
>> xfer's to happen together.  However our current code does not call
>> spi_xfer() that way.
> 
> Which is your concrete case ? spi_xfer is responsible to setup the
> controller and to start the transfer, and everything could be done
> inside this function. What do you mean exactly with command and data ?
> 
> Regards,
> Stefano
> 

I think he refers to the common "problem" that many SPI devices
require CS to stay low during both "phases" of issuing the
read/write command and transfering the actual data.

Current u-boot code calls spi_xfer() two times.

Hardware controlled CS often go high between both calls, which
requires you to (at least) use GPIO controlled CS, or, even worse,
use bitbang SPI (in cases where the SPI pin assignment is in groups,
not individually).

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

[U-Boot] [PATCH 1/2] MX31: add support for MX31 watchdog

[Stefano Babic]

The patch add CONFIG_HW_WATCHDOG to be used
with the internal watchdog timer of the MX31
processor. Two function are exported for the
board maintainers:
mxc_hw_watchdog_enable
mxc_hw_watchdog_reset

The board maintainer can decide to use mxc_hw_watchdog_reset as
hw_watchdog_reset, or to implement his own function to reset
the watchdog.
The watchdog timer can be configured with CONFIG_SYS_WD_TIMER_SECS
(value in seconds). The MX31 allows values between 0.5
(CONFIG_SYS_WD_TIMER_SECS = 0) and 128 seconds.

Signed-off-by: Stefano Babic 
---
 arch/arm/cpu/arm1136/mx31/timer.c  |   38 +++-
 arch/arm/include/asm/arch-mx31/mx31-regs.h |   10 +++
 2 files changed, 47 insertions(+), 1 deletions(-)

diff --git a/arch/arm/cpu/arm1136/mx31/timer.c 
b/arch/arm/cpu/arm1136/mx31/timer.c
index b8848c4..5191f40 100644
--- a/arch/arm/cpu/arm1136/mx31/timer.c
+++ b/arch/arm/cpu/arm1136/mx31/timer.c
@@ -24,6 +24,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #define TIMER_BASE 0x53f9 /* General purpose timer 1 */
 
@@ -166,5 +168,39 @@ void __udelay (unsigned long usec)
 
 void reset_cpu (ulong addr)
 {
-   __REG16(WDOG_BASE) = 4;
+   struct wdog_regs *wdog = (struct wdog_regs *)WDOG_BASE;
+   wdog->wcr = WDOG_ENABLE;
+   while (1)
+   ;
 }
+
+#ifdef CONFIG_HW_WATCHDOG
+void mxc_hw_watchdog_enable(void)
+{
+   struct wdog_regs *wdog = (struct wdog_regs *)WDOG_BASE;
+   u16 secs;
+
+   /*
+* The timer watchdog can be set between
+* 0.5 and 128 Seconds. If not defined
+* in configuration file, sets 64 Seconds
+*/
+#ifdef CONFIG_SYS_WD_TIMER_SECS
+   secs = (CONFIG_SYS_WD_TIMER_SECS << 1) & 0xFF;
+   if (!secs) secs = 1;
+#else
+   secs = 64;
+#endif
+   writew(readw(&wdog->wcr) | (secs << WDOG_WT_SHIFT) | WDOG_ENABLE,
+   &wdog->wcr);
+}
+
+
+void mxc_hw_watchdog_reset(void)
+{
+   struct wdog_regs *wdog = (struct wdog_regs *)WDOG_BASE;
+
+   writew(0x, &wdog->wsr);
+   writew(0x, &wdog->wsr);
+}
+#endif
diff --git a/arch/arm/include/asm/arch-mx31/mx31-regs.h 
b/arch/arm/include/asm/arch-mx31/mx31-regs.h
index 105f7d8..37337f2 100644
--- a/arch/arm/include/asm/arch-mx31/mx31-regs.h
+++ b/arch/arm/include/asm/arch-mx31/mx31-regs.h
@@ -75,6 +75,16 @@ struct cspi_regs {
u32 test;
 };
 
+/* Watchdog Timer (WDOG) registers */
+#define WDOG_ENABLE(1 << 2)
+#define WDOG_WT_SHIFT  8
+struct wdog_regs {
+   u16 wcr;/* Control */
+   u16 wsr;/* Service */
+   u16 wrsr;   /* Reset Status */
+};
+
+
 #define IOMUX_PADNUM_MASK  0x1ff
 #define IOMUX_PIN(gpionum, padnum) ((padnum) & IOMUX_PADNUM_MASK)
 
-- 
1.7.1

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

[U-Boot] [PATCH 2/2] MX31: qong: add watchdog

[Stefano Babic]

Signed-off-by: Stefano Babic 
---
 board/davedenx/qong/qong.c |   12 
 include/configs/qong.h |1 +
 2 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/board/davedenx/qong/qong.c b/board/davedenx/qong/qong.c
index 8a81cfc..3ace6cd 100644
--- a/board/davedenx/qong/qong.c
+++ b/board/davedenx/qong/qong.c
@@ -30,9 +30,17 @@
 #include 
 #include 
 #include "qong_fpga.h"
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
+#ifdef CONFIG_HW_WATCHDOG
+void hw_watchdog_reset(void)
+{
+   mxc_hw_watchdog_reset();
+}
+#endif
+
 int dram_init (void)
 {
/* dram_init must store complete ramsize in gd->ram_size */
@@ -202,6 +210,10 @@ int board_late_init(void)
pmic_reg_write(REG_POWER_CTL0, val | COINCHEN);
pmic_reg_write(REG_INT_STATUS1, RTCRSTI);
 
+#ifdef CONFIG_HW_WATCHDOG
+   mxc_hw_watchdog_enable();
+#endif
+
return 0;
 }
 
diff --git a/include/configs/qong.h b/include/configs/qong.h
index e2f7a5e..299db5e 100644
--- a/include/configs/qong.h
+++ b/include/configs/qong.h
@@ -52,6 +52,7 @@
 #define CONFIG_SYS_MX31_UART1  1
 
 #define CONFIG_MXC_GPIO
+#define CONFIG_HW_WATCHDOG
 
 #define CONFIG_MXC_SPI
 #define CONFIG_DEFAULT_SPI_BUS 1
-- 
1.7.1

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

Re: [U-Boot] Trouble running hello_world

[Wolfgang Denk]

Dear Alfred Morgan,

In message <30ada4e9-4366-4c21-a901-55d23c87e...@54.org> you wrote:
> 
> I am having trouble executing anything using U-Boot.  I have read the
> U-Boot README and Manual.  I have also tried to following the steps on
> plugcomputer.org's wiki.  I was feeling like I was beginning to get a
> clue but then I couldn't get anything to work.  I figured a good place
> to start is trying to execute the u-boot hello_world standalone program
> but I couldn't even get that to work.
...
> And that is it.  The plug sits there with no further output to the
> serial console.  I've also tried "tftp 0x640 hello_world.bin" and
> "go 0x644" (like the manual says to start 4 bytes from start in
> section 5.12.1) but still, same boring results.  I've also tried
> 0xC14 with the loads method just in case, but still nothing.

Did you read
http://www.denx.de/wiki/view/DULG/MyStandaloneProgramDoesNotWork

?

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
People have one thing in common: they are all different.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] at91sam9263_nandflash build issues

[Wolfgang Denk]

Dear Marek Vasut,

In message <201102020849.36451.marek.va...@gmail.com> you wrote:
> The problem is clear from this IRC log, where "vickylinuxer" described his 
> grief 
> (so I included the log, the board really doesn't build). I also did a quick 
> and 
> dirty patch (follows the log, it might give you an idea where it breaks, but 
> it's a mess -- not all is relevant and it probably breaks it even more).

What exactly is it that you want?

Contact the board maintainer ?  Then why did you not put him on Cc: ?

Contact the responsible custodian ? Then why did you not put him on Cc: ?

Submit a fix ? Then why did you not follow the patch submission rules?

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
Of course there's no reason for it, it's just our policy.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] MPC8xx malloc failing

[saugat mitra]

Hi Wolfgang

The project was started more than a year back and that time 2009.11
was the latest version, so we are still continuing with the same.
On running the back trace I found that functions to be called were from -
malloc
env_relocate
board_init_r
trap_init

To be more precise the code was dying while in the following loop from
the function malloc() in dlmalloc.c. It executes the loop twice before
crashing.

 for (victim = last(bin); victim != bin; victim = victim->bk)
{
  victim_size = chunksize(victim);
  remainder_size = victim_size - nb;
  if (remainder_size >= (long)MINSIZE) /* too big */
  {

  --idx; /* adjust to rescan below after checking last remainder */
  break;
  }

  else if (remainder_size >= 0) /* exact fit */
  {
  unlink(victim, bck, fwd);
  set_inuse_bit_at_offset(victim, victim_size);
  check_malloced_chunk(victim, nb);
  return chunk2mem(victim);
  }

}


Also when I removed a few print(debug) statements the backtrace gave
the first function to be puts instead of malloc, other functions
were the same as earlier.

cpu is mpc8xx.

Thanks & Regards
Saugat.

On Tue, Feb 1, 2011 at 6:59 PM, Wolfgang Denk  wrote:
> Dear saugat mitra,
>
> In message  you 
> wrote:
>>
>> I have moved onto 2009.11, though more new versions are available but still 
>> ..
>
> Stefano wrote:
>
> | > make yourself a favour and upgrade to last U-Boot version...
>
> Can you please explain why you stick again with code that is > 1 year
> old?
>
>
>> I am using a MPC8XX based board( as earlier), but now the code is crashing
>> in env_relocate() function. On applying debug prints I found that the
>> code was failing
>> in malloc with a Bus Fault with the following dump -
>
> It would have been easier if you had just decoded the backtrace:
>
>> Call backtrace:
>> 00FC9988 00FDCD34 00FCCD60 00FC93B8
>> machine check
>
> Which routines are these addresses from?
>
> 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
> In C we had to code our own bugs, in C++ we can inherit them.
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] BSS footprint of FAT very high - SPL issues

[Aneesh V]

Hello Wolfgang, Albert,

On Tuesday 01 February 2011 03:33 PM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<4d47c1c9.1020...@ti.com>  you wrote:
>>
>>> Why would that be necessary?  Just put the BSS segment in SDRAM, and
>>> everything is fine, isn't it?
>>
>> SDRAM is initialized by the SPL. So, bss can not be initialized and
>> used until SDRAM initialization is complete. I would prefer to have
>
> Yes, this is normal.
>
>> rest of the bss in internal RAM so that it's available as soon as we
>> enter C code.
>
> Well, you probably have to decide if you want an easy solution with
> the restictions of the internal RAM size, or a somewhat more complex
> solution with much more powerful resources.

I tried putting bss in SDRAM and it works for me. I just had to put a
couple of variables explicitly in .data section. However, there is one
minor issue that I would like to report.

Making .bss disjoint from the rest of the image may break the
relocation code in start.S. Currently the assumption is that
'__bss_start' indicates the end of .data and hence the image.
That will not be the case when .text and .data are in IRAM and .bss in
SDRAM. I am not affected because our SPL doesn't need relocation.

Best regards,
Aneesh

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

Re: [U-Boot] BSS footprint of FAT very high - SPL issues

[Albert ARIBAUD]

Hi Aneesh,

Le 02/02/2011 14:17, Aneesh V a écrit :
> Hello Wolfgang, Albert,
>
> On Tuesday 01 February 2011 03:33 PM, Wolfgang Denk wrote:
>> Dear Aneesh V,
>>
>> In message<4d47c1c9.1020...@ti.com> you wrote:
>>>
 Why would that be necessary? Just put the BSS segment in SDRAM, and
 everything is fine, isn't it?
>>>
>>> SDRAM is initialized by the SPL. So, bss can not be initialized and
>>> used until SDRAM initialization is complete. I would prefer to have
>>
>> Yes, this is normal.
>>
>>> rest of the bss in internal RAM so that it's available as soon as we
>>> enter C code.
>>
>> Well, you probably have to decide if you want an easy solution with
>> the restictions of the internal RAM size, or a somewhat more complex
>> solution with much more powerful resources.
>
> I tried putting bss in SDRAM and it works for me. I just had to put a
> couple of variables explicitly in .data section.

You mean data that would have ended in BSS but that you moved to .data? Why?

> However, there is one minor issue that I would like to report.
>
> Making .bss disjoint from the rest of the image may break the
> relocation code in start.S. Currently the assumption is that
> '__bss_start' indicates the end of .data and hence the image.
> That will not be the case when .text and .data are in IRAM and .bss in
> SDRAM. I am not affected because our SPL doesn't need relocation.

That's a good remark -- formally, the relocation code should go from 
start of text to end of data, not to start of BSS.

And that's one more reason for me to want bss stay with text and data 
(and your two variables above should stay uninitialized) and external 
RAM get its own memory declaration in the linker file. :)

> Best regards,
> Aneesh

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

Re: [U-Boot] BSS footprint of FAT very high - SPL issues

[Aneesh V]

Hi Albert,

On Wednesday 02 February 2011 07:07 PM, Albert ARIBAUD wrote:
> Hi Aneesh,
>
> Le 02/02/2011 14:17, Aneesh V a écrit :
>> Hello Wolfgang, Albert,
>>
>> On Tuesday 01 February 2011 03:33 PM, Wolfgang Denk wrote:
>>> Dear Aneesh V,
>>>
>>> In message<4d47c1c9.1020...@ti.com> you wrote:

> Why would that be necessary? Just put the BSS segment in SDRAM, and
> everything is fine, isn't it?

 SDRAM is initialized by the SPL. So, bss can not be initialized and
 used until SDRAM initialization is complete. I would prefer to have
>>>
>>> Yes, this is normal.
>>>
 rest of the bss in internal RAM so that it's available as soon as we
 enter C code.
>>>
>>> Well, you probably have to decide if you want an easy solution with
>>> the restictions of the internal RAM size, or a somewhat more complex
>>> solution with much more powerful resources.
>>
>> I tried putting bss in SDRAM and it works for me. I just had to put a
>> couple of variables explicitly in .data section.
>
> You mean data that would have ended in BSS but that you moved to .data?
> Why?

Yes. These are variables that otherwise would go to BSS. I do this
because I need them before SDRAM initialization. One of this is the gd
structure. I allocate gd structure in .data that is in IRAM.
Why I need gd before SDRAM? Because I try to initialize serial console
as early as possible and this code has some reference to gd.


>
>> However, there is one minor issue that I would like to report.
>>
>> Making .bss disjoint from the rest of the image may break the
>> relocation code in start.S. Currently the assumption is that
>> '__bss_start' indicates the end of .data and hence the image.
>> That will not be the case when .text and .data are in IRAM and .bss in
>> SDRAM. I am not affected because our SPL doesn't need relocation.
>
> That's a good remark -- formally, the relocation code should go from
> start of text to end of data, not to start of BSS.
>
> And that's one more reason for me to want bss stay with text and data
> (and your two variables above should stay uninitialized) and external
> RAM get its own memory declaration in the linker file. :)
>

I can try that too. Just one small question.
You want to have the source file changes for putting the buffers in
.ram section only for SPL, right?
We could have done this globally(for both u-boot and SPL) and merge .ram 
with .bss for u-boot. But that would require changes to all linker scripts.

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

[U-Boot] omap3 mux enabling

[jacopo mondi]

Dear folks,
I'm very new to this community, please pardon me if I'm going to ask
something that seems obvious to the majority of you.

As I've seen digging through the list archives in later months there
was some discussions about mux state, and possible decoupling between
u-boot and linux kernel in doing pin multiplexing [1].

Mine is a question related to an end-user problem, since I'm no more
able to do multiplexing for my DM3730 Beagleboard xM platform.
The problem is quite simple, multiplexer configurations are totally
ignored by u-boot (v2010.12), and I'm not able to do what I was used
to do with my previous C4 board (with v2010.06 and v2010.03).

After reading discussion [1] I just wanna know if it is needed to
manually enable MUX for recent  u-boot versions as a consequence to
discussions or decisions which I'm not aware of and I was unable to
find in the list logs or in changelogs (since seraching for that in the
web site returns a 403 error[2])

Again, sorry if I'm missing something obvious for you all.
Just ask for details about how I'm doing multiplexing, I've inserted
none since they are not relevant to my main question.

thanks
jacopo

[1]http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/88443/focus=88451
[2]http://git.denx.de/?p=u-boot.git;a=blob_plain;f=CHANGELOG-before-U-Boot-1.1.5;hb=HEAD
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] atmel nand patch CE don't care NAND

[Michael Trimarchi]

Hi,

this patch fix the support for CE don't care nand

Michael Trimarchi
commit 0cb23ef858407a7a9de6e353e08394637c518c89
Author: Michael Trimarchi 
Date:   Wed Feb 2 14:24:21 2011 +0100

Fix the CE for the NAND don't care

Signed-off-by: Michael Trimarchi 

diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index ab8bbb3..bda117a 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -249,8 +249,13 @@ static void at91_nand_hwcontrol(struct mtd_info *mtd,
 		if (ctrl & NAND_ALE)
 			IO_ADDR_W |= CONFIG_SYS_NAND_MASK_ALE;
 
+		/*
+		 * Nand CS don't care doesn't need the enable pin
+		 */
+#ifdef CONFIG_SYS_NAND_ENABLE_PIN
 		at91_set_gpio_value(CONFIG_SYS_NAND_ENABLE_PIN,
 !(ctrl & NAND_NCE));
+#endif
 		this->IO_ADDR_W = (void *) IO_ADDR_W;
 	}
 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] BSS footprint of FAT very high - SPL issues

[Albert ARIBAUD]

Le 02/02/2011 15:01, Aneesh V a écrit :
> Hi Albert,
>
> On Wednesday 02 February 2011 07:07 PM, Albert ARIBAUD wrote:
>> Hi Aneesh,
>>
>> Le 02/02/2011 14:17, Aneesh V a écrit :
>>> Hello Wolfgang, Albert,
>>>
>>> On Tuesday 01 February 2011 03:33 PM, Wolfgang Denk wrote:
 Dear Aneesh V,

 In message<4d47c1c9.1020...@ti.com> you wrote:
>
>> Why would that be necessary? Just put the BSS segment in SDRAM, and
>> everything is fine, isn't it?
>
> SDRAM is initialized by the SPL. So, bss can not be initialized and
> used until SDRAM initialization is complete. I would prefer to have

 Yes, this is normal.

> rest of the bss in internal RAM so that it's available as soon as we
> enter C code.

 Well, you probably have to decide if you want an easy solution with
 the restictions of the internal RAM size, or a somewhat more complex
 solution with much more powerful resources.
>>>
>>> I tried putting bss in SDRAM and it works for me. I just had to put a
>>> couple of variables explicitly in .data section.
>>
>> You mean data that would have ended in BSS but that you moved to .data?
>> Why?
>
> Yes. These are variables that otherwise would go to BSS. I do this
> because I need them before SDRAM initialization. One of this is the gd
> structure. I allocate gd structure in .data that is in IRAM.
> Why I need gd before SDRAM? Because I try to initialize serial console
> as early as possible and this code has some reference to gd.
>
>
>>
>>> However, there is one minor issue that I would like to report.
>>>
>>> Making .bss disjoint from the rest of the image may break the
>>> relocation code in start.S. Currently the assumption is that
>>> '__bss_start' indicates the end of .data and hence the image.
>>> That will not be the case when .text and .data are in IRAM and .bss in
>>> SDRAM. I am not affected because our SPL doesn't need relocation.
>>
>> That's a good remark -- formally, the relocation code should go from
>> start of text to end of data, not to start of BSS.
>>
>> And that's one more reason for me to want bss stay with text and data
>> (and your two variables above should stay uninitialized) and external
>> RAM get its own memory declaration in the linker file. :)
>>
>
> I can try that too. Just one small question.
> You want to have the source file changes for putting the buffers in
> .ram section only for SPL, right?
> We could have done this globally(for both u-boot and SPL) and merge .ram
> with .bss for u-boot. But that would require changes to all linker scripts.

Correct: the BSS size issue only hits SPL, and only in your case -- 
U-Boot as such does not have strict BSS size issues. So yes, the change 
should affect only the board's SPL linker file if it exists, but if not, 
then the generic SPL linker file should be ok, because the change will 
only have an effect for boards where the code actually maps data to the 
DRAM section.

> Best regards,
> Aneesh

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

Re: [U-Boot] MPC8xx malloc failing

[Wolfgang Denk]

Dear saugat mitra,

In message  you 
wrote:
> 
> The project was started more than a year back and that time 2009.11
> was the latest version, so we are still continuing with the same.

I can imagine that you dislike this, but you are learning a lesson
the hard way now. If you have to maintain your software for more than
a few months (which usually applies only to few fast-living, high
volume consumer devices)  it is usually a good investment to push your
changes upstream so they get included into mainline code, and the
community does most of the maintenance work for you.  You did not, so
now you have to allthe work needed to bring your code back in sync
with mainline yourself.

> On running the back trace I found that functions to be called were from -
> malloc
> env_relocate
> board_init_r
> trap_init
> 
> To be more precise the code was dying while in the following loop from
> the function malloc() in dlmalloc.c. It executes the loop twice before
> crashing.

This is definitely not the place where the problem is.  The problem
happened earlier, and you see only the results of earlier failures
here.

But we don't know your code, nor your configuration...  And digging
down into old code is not exactly interesting either, at least not in
the context of free community work.

I recommend you update, and then you post your patches.  The review
process might catch a problem or two.


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
I can't understand it. I can't even understand  the  people  who  can
understand it.- Queen Juliana of the Netherlands.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] Fix gunzip to work for any gzipped uImage size Signed-off-by: Catalin Radu

[Catalin Radu]

---
 lib/gunzip.c |   16 ++--
 1 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/lib/gunzip.c b/lib/gunzip.c
index 482a476..18cb45b 100644
--- a/lib/gunzip.c
+++ b/lib/gunzip.c
@@ -106,12 +106,16 @@ int zunzip(void *dst, int dstlen, unsigned char *src, 
unsigned long *lenp,
s.avail_in = *lenp - offset;
s.next_out = dst;
s.avail_out = dstlen;
-   r = inflate(&s, Z_FINISH);
-   if ((r != Z_STREAM_END) && (stoponerr==1)) {
-   printf ("Error: inflate() returned %d\n", r);
-   inflateEnd(&s);
-   return (-1);
-   }
+do {
+r = inflate(&s, Z_FINISH);
+if ((r != Z_STREAM_END) && (r != Z_BUF_ERROR) && (stoponerr==1)) {
+printf ("Error: inflate() returned %d\n", r);
+inflateEnd(&s);
+return (-1);
+}
+s.avail_in = *lenp - offset - (int)(s.next_out - (unsigned char*)dst);
+s.avail_out = dstlen;
+} while (r == Z_BUF_ERROR);
*lenp = s.next_out - (unsigned char *) dst;
inflateEnd(&s);
 
-- 
1.6.3.3

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

Re: [U-Boot] [Patch V6 0/4] Add basic NVIDIA Tegra2 SoC support

[Tom Warren]

Mike,

On Wed, Feb 2, 2011 at 12:57 AM, Mike Rapoport  wrote:
> On 02/02/11 02:09, Tom Warren wrote:
>> I haven't seen any new feedback on this version (V6) of the patchset
>> since it was posted.
>>
>> Wolfgang, Mike, Peter, et al - are you happy with the current patch?
>
> I'm Ok with the current patch.
Thanks, Mike. Appreciate your help.
>
>> If so, when can I expect it to be pushed?
Who has to push/accept/apply the patch? Wolfgang, or the ARM custodian?

Thanks.
>>
>> Thanks,
>>
>> Tom
>>
>> On Thu, Jan 27, 2011 at 1:58 PM, Tom Warren  wrote:
>>> This series of patches adds preliminary/baseline support for NVIDIA's
>>> Tegra2 SoC.  Basic CPU (AVP), RAM and UART init are covered so that the
>>> system (Harmony or Seaboard) can boot to the U-Boot serial cmd prompt.
>>>
>>> Further support (for Cortex-A9 CPU(s), USB, SD/MMC, etc.) to follow.
>>>
>>> Changes for V2:
>>>        - Coding style cleanup
>>>        - Remove mach-types.h change; wait for ARM kernel sync-up
>>>        - Move serial driver changes to separate patch
>>>        - Use board/nvidia/ instead of /board/tegra
>>>        - Remove TRUE/FALSE defines
>>>        - Use standard NS16550 register/bit defines in UART init
>>>        - Change nv-common.h config file to tegra2-common.h
>>>
>>> Changes for V3:
>>>        - Use I/O accessors for Tegra2 HW MMIO register access
>>>        - Allow conditional compile of UARTA/UARTD code to save space
>>>
>>> Changes for V4:
>>>        - Use address of HW structs (&pmc, etc.) in readl/writel
>>>        - Remove empty lines, fix mixed case hex #s & comments in header(s)
>>>        - Move board/nvidia/common/board.c UART code & header to
>>>                arch/arm/cpu/armv7/tegra2/
>>>        - Declare internal functions as static in UART code
>>>
>>> Changes for V5:
>>>        - Move arch/arm/cpu/armv7/uart.c & board.h to drivers/serial and
>>>                rename to serial_tegra2.c
>>>        - Remove use of uart_num & UART_A/D in serial_tegra2, simplify code
>>>
>>> Changes for V6:
>>>        - Fix uart.c add & delete in previous patchset
>>>        - Move pinmux & clock init code to common board file as per review
>>>        - Use #if defined() where possible in config files/UART code
>>>        - Drop all typedef and volatile struct declarations in header files
>>>
>>> Tom Warren (4):
>>>  arm: Tegra2: Add basic NVIDIA Tegra2 SoC support
>>>  serial: Add Tegra2 serial port support
>>>  arm: Tegra2: Add support for NVIDIA Harmony board
>>>  arm: Tegra2: Add support for NVIDIA Seaboard board
>>>
>>>  MAINTAINERS                                  |    5 +
>>>  arch/arm/cpu/armv7/tegra2/Makefile           |   48 +++
>>>  arch/arm/cpu/armv7/tegra2/board.c            |   88 
>>>  arch/arm/cpu/armv7/tegra2/config.mk          |   28 
>>>  arch/arm/cpu/armv7/tegra2/lowlevel_init.S    |   65 +
>>>  arch/arm/cpu/armv7/tegra2/sys_info.c         |   35 +
>>>  arch/arm/cpu/armv7/tegra2/timer.c            |  122 
>>>  arch/arm/include/asm/arch-tegra2/clk_rst.h   |  165 ++
>>>  arch/arm/include/asm/arch-tegra2/pinmux.h    |   55 
>>>  arch/arm/include/asm/arch-tegra2/pmc.h       |  124 +
>>>  arch/arm/include/asm/arch-tegra2/sys_proto.h |   35 +
>>>  arch/arm/include/asm/arch-tegra2/tegra2.h    |   49 +++
>>>  arch/arm/include/asm/arch-tegra2/uart.h      |   47 ++
>>>  board/nvidia/common/board.c                  |  193 
>>> ++
>>>  board/nvidia/harmony/Makefile                |   50 +++
>>>  board/nvidia/seaboard/Makefile               |   50 +++
>>>  boards.cfg                                   |    2 +
>>>  common/serial.c                              |    3 +-
>>>  drivers/serial/Makefile                      |    1 +
>>>  drivers/serial/serial_tegra2.c               |   77 ++
>>>  drivers/serial/serial_tegra2.h               |   29 
>>>  include/configs/harmony.h                    |   49 +++
>>>  include/configs/seaboard.h                   |   43 ++
>>>  include/configs/tegra2-common.h              |  160 +
>>>  include/serial.h                             |    3 +-
>>>  25 files changed, 1524 insertions(+), 2 deletions(-)
>>>  create mode 100644 arch/arm/cpu/armv7/tegra2/Makefile
>>>  create mode 100644 arch/arm/cpu/armv7/tegra2/board.c
>>>  create mode 100644 arch/arm/cpu/armv7/tegra2/config.mk
>>>  create mode 100644 arch/arm/cpu/armv7/tegra2/lowlevel_init.S
>>>  create mode 100644 arch/arm/cpu/armv7/tegra2/sys_info.c
>>>  create mode 100644 arch/arm/cpu/armv7/tegra2/timer.c
>>>  create mode 100644 arch/arm/include/asm/arch-tegra2/clk_rst.h
>>>  create mode 100644 arch/arm/include/asm/arch-tegra2/pinmux.h
>>>  create mode 100644 arch/arm/include/asm/arch-tegra2/pmc.h
>>>  create mode 100644 arch/arm/include/asm/arch-tegra2/sys_proto.h
>>>  create mode 100644 arch/arm/include/asm/arch-tegra2/tegra2.h
>>>  create mode 100644 arch/arm

[U-Boot] [PATCH] powerpc: Add cpu_late_init_r to allow for initialization post env setup

[Kumar Gala]

We can simplify some cpu/SoC level initialization by moving it to be
after the environment and non-volatile storage is setup as there might
be dependancies on such things in various boot configurations.

For example for FSL SoC's with QE if we boot from NAND we need it setup
to extra the ucode image to initialize the QE.  If we always do this
after environment & non-volatile storage is working we can have the code
be the same regardless of NOR, NAND, SPI, MMC boot.

Signed-off-by: Kumar Gala 
---
 arch/powerpc/cpu/mpc85xx/cpu_init.c |   15 +--
 arch/powerpc/lib/board.c|7 +++
 2 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c 
b/arch/powerpc/cpu/mpc85xx/cpu_init.c
index 8ece970..fa77857 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
@@ -384,12 +384,6 @@ int cpu_init_r(void)
 
enable_cpc();
 
-#ifdef CONFIG_QE
-   uint qe_base = CONFIG_SYS_IMMR + 0x0008; /* QE immr base */
-   qe_init(qe_base);
-   qe_reset();
-#endif
-
/* needs to be in ram since code uses global static vars */
fsl_serdes_init();
 
@@ -449,3 +443,12 @@ int sata_initialize(void)
return 1;
 }
 #endif
+
+void cpu_late_init_r(void)
+{
+#ifdef CONFIG_QE
+   uint qe_base = CONFIG_SYS_IMMR + 0x0008; /* QE immr base */
+   qe_init(qe_base);
+   qe_reset();
+#endif
+}
diff --git a/arch/powerpc/lib/board.c b/arch/powerpc/lib/board.c
index b88cf6b..525a0d4 100644
--- a/arch/powerpc/lib/board.c
+++ b/arch/powerpc/lib/board.c
@@ -186,6 +186,11 @@ int __board_flash_wp_on(void)
 }
 int board_flash_wp_on(void) __attribute__((weak, 
alias("__board_flash_wp_on")));
 
+void __cpu_late_init_r(void)
+{
+}
+void cpu_late_init_r(void) __attribute__((weak, alias("__cpu_late_init_r")));
+
 static int init_func_ram (void)
 {
 #ifdef CONFIG_BOARD_TYPES
@@ -986,6 +991,8 @@ void board_init_r (gd_t *id, ulong dest_addr)
 #endif
 #endif
 
+   cpu_late_init_r();
+
 #ifdef CONFIG_LAST_STAGE_INIT
WATCHDOG_RESET ();
/*
-- 
1.7.2.3

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

Re: [U-Boot] Trouble running hello_world

[Alfred Morgan]

Wolfgang,

> Did you read
> http://www.denx.de/wiki/view/DULG/MyStandaloneProgramDoesNotWork


I did.  I have not modified hello_world.c so I thought it wouldn't apply.  Here 
is my nm output:

$ nm -n examples/standalone/hello_world
0010 N $d
003c N $d
0c10 t $a
0c10 T hello_world
0c10009c t $d
0c1000bc t $a
0c1000bc T dummy

-alfred

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

Re: [U-Boot] [PATCH] powerpc: Add cpu_late_init_r to allow for initialization post env setup

[Haiying Wang]

On Wed, 2011-02-02 at 11:27 -0600, Kumar Gala wrote:
> +void cpu_late_init_r(void)
> +{
> +#ifdef CONFIG_QE
> + uint qe_base = CONFIG_SYS_IMMR + 0x0008; /* QE immr base */
> + qe_init(qe_base);
> + qe_reset();
> +#endif
> +}
You did not move qe_reset() inside qe_init() as you recommended.:)

For NAND boot case, the microcode needs to be read from nand flash via
nand_read first, so you might add some more code like:
+void cpu_late_init_r(void)
 +{
 +#ifdef CONFIG_QE
 +#ifdef CONFIG_SYS_QE_FW_IN_NAND
 +  int ret;
 +  size_t fw_length = CONFIG_SYS_QE_FW_LENGTH;

 +  /* load QE firmware from NAND flash to DDR first */
 +   ret = nand_read(&nand_info[0],(loff_t)CONFIG_SYS_QE_FW_IN_NAND,
 +   &fw_length, (u_char *)CONFIG_SYS_QE_FW_ADDR);

 +   if (ret && ret == -EUCLEAN) {
 +  printf ("NAND read for QE firmware at offset %x failed %
d\n",
 +   CONFIG_SYS_QE_FW_IN_NAND, ret);
 +   }
 +#endif
 +  uint qe_base = CONFIG_SYS_IMMR + 0x0008; /* QE immr base */
 +  qe_init(qe_base);
 +  qe_reset();
 +#endif
 +}

Haiying



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

Re: [U-Boot] [PATCH] Add support for ASIX's AX88783 ethernet chip

[Stefano Babic]

On 01/31/2011 06:42 PM, Joe Xue wrote:
> for more information about this chip, please check:
> http://www.asix.com.tw/products.php?op=pItemdetail&PItemID=98;65;86&PLine=65
> 
> Signed-off-by: Joe Xue 
> 

Please add a version number to your patch to make easier tracking which
is your last version.

Do not forget to add always the net Maintainer to CC (Wolfgang Denk), I
added him now.

> --- /dev/null
> +++ b/drivers/net/ax88783.c
> @@ -0,0 +1,297 @@
> +/*
> + *

You should drop this line

> +
> +static int ax88183_phy_initial(struct eth_device *dev)

You forget to replace the name of the function. It has still ax88183_

> + /* phy init */
> + tmp = readl(®->pcr);
> + tmp |= PCR_PHY0_RESET_CLEAR;
> +
> + writel(tmp, ®->pcr);
> + udelay(10);

you already explained why you need such a long delay. It is not bad to
add your explanation as comment here, so everyone knows your answer.

> +static void ax88783_halt(struct eth_device *dev)
> +{
> + unsigned int tmp;
> + struct ax88783_reg *reg = (struct ax88783_reg *)dev->iobase;
> + tmp = readl(®->pcr);
> + writel((tmp | PCR_LOOP_BACK), ®->pcr);
> +}

>From the name it seems you set the controller in loopback, instead of
disabling it. Is it correct ?

> +
> + res = eth_getenv_enetaddr("ethaddr", dev->enetaddr);
> + if (!res) {
> + puts("Please set your MAC address!");
> + free(dev);
> + return 0;
> + }

This is wrong. A network driver should not call directly
eth_getenv_enetaddr, and you do not need. If you want to check the mac
addrsss, use is_valid_ether_addr() inside ax88783_init() before copying
the mac to the hardware.

> +
> + res = ax88183_phy_initial(dev);

Name must be changed.

> diff --git a/drivers/net/ax88783.h b/drivers/net/ax88783.h
> new file mode 100644
> index 000..09ac9ed
> --- /dev/null
> +++ b/drivers/net/ax88783.h
> @@ -0,0 +1,100 @@
> +/*
> + *

As explained, all headers start with copyright on the second line. Drop
this line.

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-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] powerpc: Add cpu_late_init_r to allow for initialization post env setup

[Kumar Gala]

On Feb 2, 2011, at 11:53 AM, Haiying Wang wrote:

> On Wed, 2011-02-02 at 11:27 -0600, Kumar Gala wrote:
>> +void cpu_late_init_r(void)
>> +{
>> +#ifdef CONFIG_QE
>> +uint qe_base = CONFIG_SYS_IMMR + 0x0008; /* QE immr base */
>> +qe_init(qe_base);
>> +qe_reset();
>> +#endif
>> +}
> You did not move qe_reset() inside qe_init() as you recommended.:)

Yeah, forgot about that.  Part of this was to see what response the patch got 
(ie is this even acceptable).

> For NAND boot case, the microcode needs to be read from nand flash via
> nand_read first, so you might add some more code like:
> +void cpu_late_init_r(void)
> +{
> +#ifdef CONFIG_QE
> +#ifdef CONFIG_SYS_QE_FW_IN_NAND
> +  int ret;
> +  size_t fw_length = CONFIG_SYS_QE_FW_LENGTH;
> 
> +  /* load QE firmware from NAND flash to DDR first */
> +   ret = nand_read(&nand_info[0],(loff_t)CONFIG_SYS_QE_FW_IN_NAND,
> +   &fw_length, (u_char *)CONFIG_SYS_QE_FW_ADDR);
> 
> +   if (ret && ret == -EUCLEAN) {
> +  printf ("NAND read for QE firmware at offset %x failed %
> d\n",
> +   CONFIG_SYS_QE_FW_IN_NAND, ret);
> +   }
> +#endif
> + uint qe_base = CONFIG_SYS_IMMR + 0x0008; /* QE immr base */
> + qe_init(qe_base);
> + qe_reset();
> +#endif
> +}
> 
> Haiying

I leave that to you when we add a board (like P1021 MDS) that needs boot from 
NAND.

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

[U-Boot] [PATCH] powerpc: Add cpu_secondary_init_r to allow for initialization post env setup

[Kumar Gala]

We can simplify some cpu/SoC level initialization by moving it to be
after the environment and non-volatile storage is setup as there might
be dependancies on such things in various boot configurations.

For example for FSL SoC's with QE if we boot from NAND we need it setup
to extra the ucode image to initialize the QE.  If we always do this
after environment & non-volatile storage is working we can have the code
be the same regardless of NOR, NAND, SPI, MMC boot.

Signed-off-by: Kumar Gala 
---
* This is really second version of the cpu_late_init_r patch
  - changed where we call cpu_secondary_init_r to be right after env_relocate

 arch/powerpc/cpu/mpc85xx/cpu_init.c |   15 +--
 arch/powerpc/lib/board.c|   14 ++
 2 files changed, 23 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c 
b/arch/powerpc/cpu/mpc85xx/cpu_init.c
index 8ece970..215b7b3 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
@@ -384,12 +384,6 @@ int cpu_init_r(void)
 
enable_cpc();
 
-#ifdef CONFIG_QE
-   uint qe_base = CONFIG_SYS_IMMR + 0x0008; /* QE immr base */
-   qe_init(qe_base);
-   qe_reset();
-#endif
-
/* needs to be in ram since code uses global static vars */
fsl_serdes_init();
 
@@ -449,3 +443,12 @@ int sata_initialize(void)
return 1;
 }
 #endif
+
+void cpu_secondary_init_r(void)
+{
+#ifdef CONFIG_QE
+   uint qe_base = CONFIG_SYS_IMMR + 0x0008; /* QE immr base */
+   qe_init(qe_base);
+   qe_reset();
+#endif
+}
diff --git a/arch/powerpc/lib/board.c b/arch/powerpc/lib/board.c
index b88cf6b..38ca1f8 100644
--- a/arch/powerpc/lib/board.c
+++ b/arch/powerpc/lib/board.c
@@ -186,6 +186,12 @@ int __board_flash_wp_on(void)
 }
 int board_flash_wp_on(void) __attribute__((weak, 
alias("__board_flash_wp_on")));
 
+void __cpu_secondary_init_r(void)
+{
+}
+void cpu_secondary_init_r(void)
+__attribute__((weak, alias("__cpu_secondary_init_r")));
+
 static int init_func_ram (void)
 {
 #ifdef CONFIG_BOARD_TYPES
@@ -798,6 +804,14 @@ void board_init_r (gd_t *id, ulong dest_addr)
env_relocate ();
 
/*
+* after non-volatile devices & environment is setup and cpu code have
+* another round to deal with any initialization that might require
+* full access to the environment or loading of some image (firmware)
+* from a non-volatile device
+*/
+   cpu_secondary_init_r();
+
+   /*
 * Fill in missing fields of bd_info.
 * We do this here, where we have "normal" access to the
 * environment; we used to do this still running from ROM,
-- 
1.6.0.6

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

Re: [U-Boot] [Patch V6 0/4] Add basic NVIDIA Tegra2 SoC support

[Albert ARIBAUD]

Le 02/02/2011 18:06, Tom Warren a écrit :
> Mike,
>
> On Wed, Feb 2, 2011 at 12:57 AM, Mike Rapoport  wrote:
>> On 02/02/11 02:09, Tom Warren wrote:
>>> I haven't seen any new feedback on this version (V6) of the patchset
>>> since it was posted.
>>>
>>> Wolfgang, Mike, Peter, et al - are you happy with the current patch?
>>
>> I'm Ok with the current patch.
> Thanks, Mike. Appreciate your help.
>>
>>> If so, when can I expect it to be pushed?
> Who has to push/accept/apply the patch? Wolfgang, or the ARM custodian?

That would be me. Wolfgang, since the V1 patch series predates the merge 
window close and you have not yet pulled in my request, do you accept 
that I take these patches in and re-send a pull request?

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

Re: [U-Boot] at91sam9263_nandflash build issues

[Scott Wood]

On Wed, 2 Feb 2011 08:49:36 +0100
Marek Vasut  wrote:

> diff --git a/config.mk b/config.mk
> index 5147c35..fe1d40c 100644
> --- a/config.mk
> +++ b/config.mk
> @@ -261,7 +261,7 @@ $(obj)%.s:  %.c
>  
>  # If the list of objects to link is empty, just create an empty built-in.o
>  cmd_link_o_target = $(if $(strip $1),\
> - $(LD) $(LDFLAGS) -r -o $@ $1,\
> + $(LD) -r -o $@ $1,\
>   rm -f $@; $(AR) rcs $@ )

LDFLAGS was used here deliberately by commit:
8aba9dceebb14144e07d19593111ee3a999c37fc

I suspect your problem is because you have --gc-sections in
PLATFORM_LDFLAGS.  The above commit changed architectures that set
--gc-sections to use LDFLAGS_u-boot instead, but it missed boards that
set it.

Also note this patch, which if applied would mean that you'd need to
put --gc-sections in LDFLAGS_FINAL instead of LDFLAGS_u-boot:

http://patchwork.ozlabs.org/patch/81206/

-Scott

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

Re: [U-Boot] Trouble running hello_world

[Wolfgang Denk]

Dear Alfred Morgan,

In message <4ea4f7e8-6ea1-44d9-a087-04a4f2774...@54.org> you wrote:
> 
> I did.  I have not modified hello_world.c so I thought it wouldn't =
> apply.  Here is my nm output:
> 
> $ nm -n examples/standalone/hello_world
> 0010 N $d
> 003c N $d
> 0c10 t $a
> 0c10 T hello_world
> 0c10009c t $d
> 0c1000bc t $a
> 0c1000bc T dummy

Well, then your entry point is at 0c10 and you don;t have to try
other addresses.

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
Mirrors should reflect a little before throwing back images.
- Jean Cocteau
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] change email address in MAINTAINERS

[Wolfgang Denk]

Dear Yoshihiro Shimoda,

In message <4d48ade3.4070...@renesas.com> you wrote:
> Signed-off-by: Yoshihiro Shimoda 
> ---
>  This patch depends on "sh: add support for sh7757lcr board".
> 
>  MAINTAINERS |2 +-
>  1 files changed, 1 insertions(+), 1 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
A well-written program is its own heaven; a poorly-written program is
its own hell. -- Geoffrey James, "The Tao of Programming"
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] change email address in MAINTAINERS

[Wolfgang Denk]

Dear Nobuhiro Iwamatsu,

In message <20110202073515.gb8...@chimagu.nigauri.org> you wrote:
> Applied, thanks.
> 
> On Wed, Feb 02, 2011 at 10:05:39AM +0900, Yoshihiro Shimoda wrote:
> > Signed-off-by: Yoshihiro Shimoda 
> > ---
> >  This patch depends on "sh: add support for sh7757lcr board".
> > 
> >  MAINTAINERS |2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)

Thanks, but actually this is my area of responsibility.

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
Dealing with failure is easy: work hard to improve. Success  is  also
easy  to  handle:  you've  solved  the  wrong  problem.  Work hard to
improve.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [U-boot] : TFTP download is getting Failed on MCF5485 Custom Board

[sivakumar borela]

Hi ,

We have a MCF5485 procesoor based custom board. But it's design is derived
from M5485EVB board. 10% of boards are having TFTP download issue. TFTP
donwload is getting failed. It has the boardcom BCM522 as PHY interface. we
are using FEC0 of MCF5485. TFTP dowload is always getting failed while
downloading Linuix kernel image. All the ethernet settings were intact, as
rest of our boards are working good wit the same settings.

Can anyone have any idea ?

Boot log detials:

U-Boot 1.3.3 (Oct  1 2009 - 10:00:03)
CPU:   Freescale MCF5485
   CPU CLK 132 Mhz BUS CLK 66 Mhz
Board: M5485EVB
DRAM:  128 MB
POST: Testing Ram...PASSED.
FLASH: 64 MB
unlocking boot environment sector ..
. done
Un-Protected 1 sectors
. done
Protected 1 sectors
In:serial
Out:   serial
Err:   serial
Net:   FEC0, FEC1
Hit any key to stop autoboot:  5  4  0



-> tftp 0x200 uImage
Using FEC0 device
TFTP from server 172.25.2.14; our IP address is 172.25.2.13
Filename 'uImage'.
Load address: 0x200
Loading: *#
  #



Here is the boot environment varaibles:
->printenv

bootdelay=5

baudrate=9600

ethaddr=00:e0:0c:bc:e5:60

eth1addr=00:e0:0c:bc:e5:61

ipaddr=172.25.2.13

serverip=172.25.2.14

gatewayip=172.25.2.1

netmask=255.255.255.0

hostname=M548xEVB

netdev=eth0

loadaddr=1

u-boot=u-boot.bin

load=tftp ${loadaddr) ${u-boot}

upd=run load; run prog

prog=prot off bank 1:0-3;era e000 e007;cp.b ${loadaddr} e000
${filesize};save

bootargs=root=/dev/mtdblock3 rw rootfstype=jffs2

bootcmd=bootm 0xe00c

tftp 0200 uImage

prot off 1:6-255;era e00c e1ff;cp.b ${fileaddr} 0xe00c
${filesize};save

tftp 0200 rootfs.jffs2

prot off bank 2;era bank 2;cp.b ${fileaddr} 0x3000 ${filesize};save

stdin=serial

stdout=serial

stderr=serial

ethact=FEC0

mem=130560k







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

Re: [U-Boot] [PATCH] Print compiler and linker version with the version command

[Wolfgang Denk]

Dear Alexander Holler,

In message <1295393080-6510-1-git-send-email-hol...@ahsoftware.de> you wrote:
> After years of unsuccessful research I've finally shamelessly stolen other
> peoples intellectual properties to present the all-new and world-changing
> updated version command:
> -
> U-Boot>> version
> 
> U-Boot 2010.12-00014-g7435056-dirty (Jan 18 2011 - 23:19:38)
> MyBoard
> gcc (GCC) 0.42 (Distro foobar)
> GNU ld (GNU Binutils) 0.314159265
> -
> May the toolchain bugs rest in peace.
> 
> Signed-off-by: Alexander Holler 
> ---
>  Makefile |4 
>  common/cmd_version.c |9 -
>  2 files changed, 12 insertions(+), 1 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
Every time history repeats itself the price goes up.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Wolfgang Denk]

Dear Albert ARIBAUD,

In message <4d48a0a0.8040...@free.fr> you wrote:
> Hi Wolfgang,
> 
> Please pull from u-boot-arm/master to go into rc1 of upcoming release.
> 
> The following changes since commit 6f918bd46482f889f4d94623b09daf659a1974bd:
> 
>Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx (2011-01-31 
> 23:20:32 +0100)
> 
> are available in the git repository at:
> 
>git://www.denx.de/git/u-boot-arm.git master
> 
> Alexander Holler (1):
>ARM: Avoid compiler optimization for readb, writeb and friends.
> 
> Anatolij Gustschin (2):
>SPI: mxc_spi: fix swapping bug and add missing swapping in 
> unaligned rx case
>SPI: mxc_spi: add SPI clock calculation and setup to the driver
> 
> Heiko Schocher (2):
>arm1136: timer: Replace bss variable by gd
>arm926ejs: timer: Replace bss variable by gdr
> 
> Jens Scharsig (1):
>remove (double) LED initialization in arm920t start.s
> 
> Liu Hui-R64343 (10):
>MX51EVK: UART does not print out the early information
>MX5: Add initial support for MX53 processor
>fec_mxc: add support for MX53 processor
>serial_mxc: add support for MX53 processor
>mxc_gpio: add support for MX53 processor
>mxc_i2c: add support for MX53 processor
>fsl_pmic: add I2C interface support
>MX5:MX53: add initial support for MX53EVK board
>imximage: Add MX53 boot image support
>ARM: */start.S: code cleanup
> 
> Marek Vasut (4):
>BLOCK: Add freescale IMX51 PATA driver
>MC13892: Add SWx buck switchers definitions
>MX51EVK: Use SWx macros in PMIC init
>iMX5: EfikaMX: Preliminary board support
> 
> Mike Rapoport (1):
>OMAP3: add CM-T35 board
> 
> Minkyu Kang (4):
>armv7: s5pc1xx: don't use function pointer for clock functions
>S5P: serial: Use the inline function instead of static value
>armv7: add support for S5PC210 SoC
>armv7: add support for s5pc210 universal board
> 
> Po-Yu Chuang (1):
>arm: a320evb: fixes for relocation support
> 
> Sandeep Paulraj (12):
>Davinci MMCSD Support
>DaVinci DM355: Adding MMC/SD support for DM355 EVM
>DaVinci DM365: Adding MMC/SD support for DM365 EVM
>DM365: Fix Build Error
>DaVinci EMAC: Fix davinci_eth_gigabit_enable
>DaVinci EMAC: Add name to Ethernet device
>DaVinci DM6467: Added ET1011C (LSI) PHY support
>ARM: Update mach types
>DaVinci DM6467: Enhance board Support
>DaVinci DM6467: Fix Build Error
>DaVinci Sonata: Fix Build Error
>DaVinci: Remove incorrect CONFIG option
> 
> Stefano Babic (13):
>mxc_nand: add support for i.MX35 processor
>Add support for MX35 processor
>serial_mxc: add support for Freescale's i.MX35 processor
>mxc_i2c: Add support for the i.MX35 processor
>I2C: mxc_i2c: get rid of __REG access
>I2C: mxc_i2c: address failure with mx35 processor
>Add basic support for Freescale's mc9sdz60
>SPI: mxc_spi: add support for i.MX35 processor
>SPI: mxc_spi: replace fixed offsets with structures
>Add support for Freescale's mx35pdk board.
>MX5: Reuse the gd->tbl value for timestamp and add gd->lastinc 
> for lastinc bss
>MXC: removed warnings from IMX51 ATA driver
>ARM: fix broken build of ARM
> 
>   MAINTAINERS|   17 +-
>   arch/arm/config.mk |2 +-
>   arch/arm/cpu/arm1136/mx31/timer.c  |   19 +-
>   arch/arm/cpu/arm1136/mx35/Makefile |   63 +
>   arch/arm/cpu/arm1136/mx35/asm-offsets.c|   43 +
>   arch/arm/cpu/arm1136/mx35/generic.c|  463 
>   arch/arm/cpu/arm1136/mx35/iomux.c  |  116 +
>   arch/arm/cpu/arm1136/mx35/timer.c  |  120 +
>   arch/arm/cpu/arm1136/omap24xx/timer.c  |   19 +-
>   arch/arm/cpu/arm1136/start.S   |2 -
>   arch/arm/cpu/arm1176/start.S   |2 -
>   arch/arm/cpu/arm720t/start.S   |2 -
>   arch/arm/cpu/arm920t/start.S   |5 -
>   arch/arm/cpu/arm925t/start.S   |2 -
>   arch/arm/cpu/arm926ejs/davinci/Makefile|2 +-
>   arch/arm/cpu/arm926ejs/davinci/cpu.c   |   14 +-
>   arch/arm/cpu/arm926ejs/davinci/et1011c.c   |   55 +
>   arch/arm/cpu/arm926ejs/kirkwood/timer.c|6 +-
>   arch/arm/cpu/arm926ejs/mb86r0x/timer.c |6 +-
>   arch/arm/cpu/arm926ejs/mx25/timer.c|6 +-
>   arch/arm/cpu/arm926ejs/mx27/timer.c|6 +-
>   arch/arm/cpu/arm926ejs/omap/timer.c|6 +-
>   arch/arm/cpu/arm926ejs/orion5x/timer.c |6 +-
>   arch/arm/cpu/arm926ejs/spear/timer.c   |6 +-
>   arch/arm/cpu/arm92

Re: [U-Boot] BSS footprint of FAT very high - SPL issues

[Graeme Russ]

On Thu, Feb 3, 2011 at 1:01 AM, Aneesh V  wrote:
> Hi Albert,
>
> On Wednesday 02 February 2011 07:07 PM, Albert ARIBAUD wrote:
>> Hi Aneesh,
>>
>> Le 02/02/2011 14:17, Aneesh V a écrit :
>>> Hello Wolfgang, Albert,
>>>
>>> On Tuesday 01 February 2011 03:33 PM, Wolfgang Denk wrote:
 Dear Aneesh V,

 In message<4d47c1c9.1020...@ti.com> you wrote:
>
>> Why would that be necessary? Just put the BSS segment in SDRAM, and
>> everything is fine, isn't it?
>
> SDRAM is initialized by the SPL. So, bss can not be initialized and
> used until SDRAM initialization is complete. I would prefer to have

 Yes, this is normal.

> rest of the bss in internal RAM so that it's available as soon as we
> enter C code.

 Well, you probably have to decide if you want an easy solution with
 the restictions of the internal RAM size, or a somewhat more complex
 solution with much more powerful resources.
>>>
>>> I tried putting bss in SDRAM and it works for me. I just had to put a
>>> couple of variables explicitly in .data section.
>>
>> You mean data that would have ended in BSS but that you moved to .data?
>> Why?
>
> Yes. These are variables that otherwise would go to BSS. I do this
> because I need them before SDRAM initialization. One of this is the gd
> structure. I allocate gd structure in .data that is in IRAM.
> Why I need gd before SDRAM? Because I try to initialize serial console
> as early as possible and this code has some reference to gd.
>

Which is a perfectly normal scenario and the way things have always been.
There should have been no need to shuffle gd around because of console
initialisation.

And as I understand it, gd itself does not get statically 'allocated' in
the u-boot image per-se (i.e. not in .data and not in .bss) - Only the
pointer to it is allocated. In most arches, this pointer is itself not
in .data or .bss but rather in a fixed reserved register. In the new x86
(final patches coming soon), the pointer is allocated in .data with a
preset initialised value pointing into  Cache-As-RAM (i.e. IRAM). Prior to
relocation, the gd pointer variable points to somewhere in IRAM / CAR and
after relocation, gd gets copied into the heap and the gd pointer adjusted
to point to the new permanent copy.

Regards,

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

Re: [U-Boot] change email address in MAINTAINERS

[Nobuhiro Iwamatsu]

Hi,

2011/2/3 Wolfgang Denk :
> Dear Nobuhiro Iwamatsu,
>
> In message <20110202073515.gb8...@chimagu.nigauri.org> you wrote:
>> Applied, thanks.
>>
>> On Wed, Feb 02, 2011 at 10:05:39AM +0900, Yoshihiro Shimoda wrote:
>> > Signed-off-by: Yoshihiro Shimoda 
>> > ---
>> >  This patch depends on "sh: add support for sh7757lcr board".
>> >
>> >  MAINTAINERS |    2 +-
>> >  1 files changed, 1 insertions(+), 1 deletions(-)
>
> Thanks, but actually this is my area of responsibility.
>

I see. I remove this commit from my repository.

Nobuhiro

-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [STATUS] v2011.03-rc1 released

[Wolfgang Denk]

Hello  everybody:

* U-Boot v2011.03-rc1 was released on Wed, 02 Feb 2011.

* Release "v2011.03" is scheduled in 39 days - on March 13, 2011.

Please help testing, and check if all your relevant patches have been
included.


Note that still a large number of ARM boards are broken. I hope many
people join the efforts and fix all the currently broken boards.
Thanks in advance to everybody who lends a helping hand.


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
A committee is a life form with six or more legs and no brain.
  -- Lazarus Long, "Time Enough For Love"
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] change email address in MAINTAINERS

[Wolfgang Denk]

Dear Nobuhiro Iwamatsu,

In message  you 
wrote:
> 
> I see. I remove this commit from my repository.

You don't have to.  git will ignore it automatically.

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
The human mind  ordinarily  operates  at  only  ten  percent  of  its
capacity. The rest is overhead for the operating system.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Pull request: nand flash

[Scott Wood]

The following changes since commit 42d44f631c4e8e5359775bdc098f2fffde4e5c05:

  Prepare v2011.03-rc1 (2011-02-02 22:37:32 +0100)

are available in the git repository at:
  git://git.denx.de/u-boot-nand-flash.git ..BRANCH.NOT.VERIFIED..

Alexander Holler (1):
  NAND: Fix saving of redundand environment

 common/env_nand.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

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

Re: [U-Boot] [PATCH 07/14] tsec: use IO accessories to access the register

[Andy Fleming]

On Jan 26, 2011, at 10:52 PM, Mingkai Hu wrote:

> Signed-off-by: Mingkai Hu 

Acked-by: Andy Fleming 

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

[U-Boot] [PATCH] Fix bad padding of bootp request packet

[Simon Glass]

This seems to pad to one byte longer than required

Change-Id: I86a888a9f5f27356e260c0457d92468d5923a756

Signed-off-by: Simon Glass 
---
 net/bootp.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/net/bootp.c b/net/bootp.c
index 1a71786..87b027e 100644
--- a/net/bootp.c
+++ b/net/bootp.c
@@ -464,7 +464,7 @@ static int DhcpExtended (u8 * e, int message_type, IPaddr_t 
ServerID, IPaddr_t R
 
/* Pad to minimal length */
 #ifdef CONFIG_DHCP_MIN_EXT_LEN
-   while ((e - start) <= CONFIG_DHCP_MIN_EXT_LEN)
+   while ((e - start) < CONFIG_DHCP_MIN_EXT_LEN)
*e++ = 0;
 #endif
 
-- 
1.7.3.1

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

Re: [U-Boot] [PATCH 08/14] tsec: arrange the code to avoid useless function declaration

[Andy Fleming]

On Jan 26, 2011, at 10:52 PM, Mingkai Hu wrote:

> Signed-off-by: Mingkai Hu 

Acked-by: Andy Fleming 

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

Re: [U-Boot] at91sam9263_nandflash build issues

[Marek Vasut]

On Wednesday 02 February 2011 20:43:00 Scott Wood wrote:
> On Wed, 2 Feb 2011 08:49:36 +0100
> 
> Marek Vasut  wrote:
> > diff --git a/config.mk b/config.mk
> > index 5147c35..fe1d40c 100644
> > --- a/config.mk
> > +++ b/config.mk
> > @@ -261,7 +261,7 @@ $(obj)%.s:  %.c
> > 
> >  # If the list of objects to link is empty, just create an empty
> >  built-in.o cmd_link_o_target = $(if $(strip $1),\
> > 
> > - $(LD) $(LDFLAGS) -r -o $@ $1,\
> > + $(LD) -r -o $@ $1,\
> > 
> >   rm -f $@; $(AR) rcs $@ )
> 
> LDFLAGS was used here deliberately by commit:
> 8aba9dceebb14144e07d19593111ee3a999c37fc

Oh my, it's not my platform. Also, you missed the comment where I said the 
patch 
is a mess, not a patch to be merged :) This time I really only forwarded a 
bugreport from irc channel with a bad sketch of a patch.
> 
> I suspect your problem is because you have --gc-sections in
> PLATFORM_LDFLAGS.  The above commit changed architectures that set
> --gc-sections to use LDFLAGS_u-boot instead, but it missed boards that
> set it.
> 
> Also note this patch, which if applied would mean that you'd need to
> put --gc-sections in LDFLAGS_FINAL instead of LDFLAGS_u-boot:
> 
> http://patchwork.ozlabs.org/patch/81206/
> 
> -Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] mach-type #define mismatch for lange51/efikamx

[Loïc Minier]

Hey!

> iMX5: EfikaMX: Preliminary board support

 u-boot-imx has:
#define MACH_TYPE_MX51_LANGE51 2336
#define MACH_TYPE_MX51_LANGE52 2337

 u-boot-arm has:
#define MACH_TYPE_MX51_EFIKAMX 2336
#define MACH_TYPE_MX51_LANGE52 2337

 and linux has:
mx51_efikamxMACH_MX51_EFIKAMX   MX51_EFIKAMX 2336
mx51_lange52MACH_MX51_LANGE52   MX51_LANGE52 2337

 but board/efikamx/efikamx.c uses MACH_TYPE_MX51_LANGE51 (and hence
 fails to build in u-boot-arm.git and u-boot.git).

 So while (Pegatron?) Lange 5.1 and 5.2 might have been more consistent,
 I think we need to switch board/efikamx/efikamx.c to the linux name
 MACH_MX51_EFIKAMX.

   Thanks!
-- 
Loïc Minier
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] PCIE supported networking cards?

[Aaron Williams]

Thanks,

I took the patch but it looks like it's unable to read the eeprom. It's 
possible it may also have something to do with our PCIE implementation since 
I'm trying to bring that up with the updated u-boot. I also need to go through 
the code and make sure that the driver is 64-bit friendly since we load u-boot 
above 4GB when enough memory is loaded (virt_to_phys returns a 64-bit address 
on our platform).

In the Linux e1000e driver I do see some differences between the e1000_82573 
and the e1000_82574.

-Aaron

PCIe: Port 0 is SRIO, skipping. 
  
PCIe: Port 1 link active, 1 lanes, speed gen1   
  
PCI Autoconfig: Bus Memory region: [0xf800-0x], 
  
Physical Memory [f800-x]
  
PCI Autoconfig: Bus I/O region: [0x10-0x1000e], 
  
Physical Memory: [10-1000e] 
  
address=0x10 bus_lower=0x100400PCI:   Bus Dev VenId DevId Class Int 
  
PCI Autoconfig: Bus Memory region: [0xf800-0x], 
  
Physical Memory [f800-x]
  
PCI Autoconfig: Bus I/O region: [0x10-0x1000e], 
  
Physical Memory: [10-1000e] 
  
PCI Scan: Found Bus 0, Device 0, Function 0 
  
PCI Autoconfig: BAR 0, Mem, size=0x2, address=0xf800 
bus_lower=0xf802 
PCI Autoconfig: BAR 1, Mem, size=0x8, address=0xf808 
bus_lower=0xf810 
PCI Autoconfig: BAR 2, I/O, size=0x20, address=0x10 bus_lower=0x100020  
  
PCI Autoconfig: BAR 3, Mem, size=0x4000, address=0xf810 
bus_lower=0xf8104000  
PCIe: port=1, first_bus=0, last_bus=0   
e1000_initialize
   
e1000#0: iobase 0xf800  
  
e1000_set_mac_type  
  
Found 52574, setting mac type to 17 
  
e1000_set_media_type
  
copper interface
  
e1000_reset_hw  
  
Masking off all interrupts  
  
Issuing a global reset to MAC   
  
Masking off all interrupts  
  
e1000_init_eeprom_params
  
e1000_is_onboard_nvm_eeprom 
  
e1000_validate_eeprom_checksum  
  
e1000_read_eeprom   
  
e1000_is_onboard_nvm_eeprom 
  
e1000_read_eeprom   
  
e1000_is_onboard_nvm_eeprom 
  
e1000_read_eeprom   
  
e1000_is_onboard_nvm_eeprom 
  
e1000_read_eeprom   
  
e1000_is_onboard_nvm_eeprom 
  
e1000_read_eeprom   
  
e1000_is_onboard_nvm_eeprom 
  
e1000_read_eeprom   
  
e1000_is_onboard_nvm_eeprom 
  
e1000_read_

[U-Boot] [PATCH] NAND: add more watchdog resets

[Scott Wood]

Poke the watchdog in a variety of looping constructs, which could take
a long time to complete.

Signed-off-by: Scott Wood 
---
Jaap, does this resolve the watchdog problems you were seeing?

 drivers/mtd/nand/nand_base.c |6 ++
 drivers/mtd/nand/nand_util.c |2 ++
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 70c0593..b9bd394 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -1156,6 +1156,8 @@ static int nand_do_read_ops(struct mtd_info *mtd, loff_t 
from,
oob = ops->oobbuf;
 
while(1) {
+   WATCHDOG_RESET();
+
bytes = min(mtd->writesize - col, readlen);
aligned = (bytes == mtd->writesize);
 
@@ -1485,6 +1487,7 @@ static int nand_do_read_oob(struct mtd_info *mtd, loff_t 
from,
page = realpage & chip->pagemask;
 
while(1) {
+   WATCHDOG_RESET();
sndcmd = chip->ecc.read_oob(mtd, chip, page, sndcmd);
 
len = min(len, readlen);
@@ -1884,6 +1887,8 @@ static int nand_do_write_ops(struct mtd_info *mtd, loff_t 
to,
memset(chip->oob_poi, 0xff, mtd->oobsize);
 
while(1) {
+   WATCHDOG_RESET();
+
int bytes = mtd->writesize;
int cached = writelen > bytes && page != blockmask;
uint8_t *wbuf = buf;
@@ -2215,6 +2220,7 @@ int nand_erase_nand(struct mtd_info *mtd, struct 
erase_info *instr,
instr->state = MTD_ERASING;
 
while (len) {
+   WATCHDOG_RESET();
/*
 * heck if we have a bad block, we do not erase bad blocks !
 */
diff --git a/drivers/mtd/nand/nand_util.c b/drivers/mtd/nand/nand_util.c
index 8b4f738..5a6f7ae 100644
--- a/drivers/mtd/nand/nand_util.c
+++ b/drivers/mtd/nand/nand_util.c
@@ -542,6 +542,8 @@ int nand_write_skip_bad(nand_info_t *nand, loff_t offset, 
size_t *length,
 
pages = write_size / pagesize_oob;
for (page = 0; page < pages; page++) {
+   WATCHDOG_RESET();
+
ops.datbuf = p_buffer;
ops.oobbuf = ops.datbuf + pagesize;
 
-- 
1.7.1

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

Re: [U-Boot] [PATCH] Fix to make U-Boot work with more USB sticks

[Aaron Williams]

We have our cache enabled since we're a cache coherent architecture so the 
performance is not due to cache (otherwise FAT would also be slow).

The hub that's failing has a transaction translator built in whereas the ones 
that work do not. For some reason it fails trying to reset this hub.

Granted, this hub is getting a lot of poor reviews, though I suspect the hub 
draws a lot more power than advertized due to all of its insanely bright LEDs. 
At least from within Linux it seems to work fine, both the embedded board and 
my desktop.

http://terminus-tech.com/images/FE2.1%20Product%20Brief%20(Rev.%201.0).pdf

http://www.amazon.com/Hi-Speed-Port-USB-Power-
Adapter/dp/B000Y8EXSS/ref=sr_1_16?s=electronics&ie=UTF8&qid=1296691437&sr=1-16

# lsusb -v -s 1:12

Bus 001 Device 012: ID 1a40:0201 TERMINUS TECHNOLOGY INC. 
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 2 TT per port
  bMaxPacketSize064
  idVendor   0x1a40 TERMINUS TECHNOLOGY INC.
  idProduct  0x0201 
  bcdDevice1.00
  iManufacturer   0 
  iProduct1 USB 2.0 Hub [MTT]
  iSerial 0 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   41
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0xe0
  Self Powered
  Remote Wakeup
MaxPower  100mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 9 Hub
  bInterfaceSubClass  0 Unused
  bInterfaceProtocol  1 Single TT
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0001  1x 1 bytes
bInterval  12
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   1
  bNumEndpoints   1
  bInterfaceClass 9 Hub
  bInterfaceSubClass  0 Unused
  bInterfaceProtocol  2 TT per port
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0001  1x 1 bytes
bInterval  12
Hub Descriptor:
  bLength   9
  bDescriptorType  41
  nNbrPorts 7
  wHubCharacteristic 0x0088
Ganged power switching
Per-port overcurrent protection
TT think time 8 FS bits
Port indicators
  bPwrOn2PwrGood   50 * 2 milli seconds
  bHubContrCurrent100 milli Ampere
  DeviceRemovable0x00
  PortPwrCtrlMask0xff
 Hub Port Status:
   Port 1: .0100 power
   Port 2: .0100 power
   Port 3: .0100 power
   Port 4: .0100 power
   Port 5: .0100 power
   Port 6: .0100 power
   Port 7: .0100 power
Device Qualifier (for other device speed):
  bLength10
  bDescriptorType 6
  bcdUSB   2.00
  bDeviceClass9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 0 Full speed (or root) hub
  bMaxPacketSize064
  bNumConfigurations  1
Device Status: 0x0001
  Self Powered


On Tuesday, February 01, 2011 05:46:51 pm Simon Glass wrote:
> Hi Aaron,
> 
> OK good. Yes I notice ext2 is slow also, but the dcache is still off so I
> assumed that was it.
> 
> I have had no hub problems, but have only tried two types. I do recall a
> LUN patch floating around. I was going to try with an uSD card to see if
> it is needed there.
> 
> Regards,
> Simon
> 
> On Tue, Feb 1, 2011 at 4:03 PM, Aaron Williams <
> 
> aaron.willi...@caviumnetworks.com> wrote:
> > I too am interested in this. I am running EHCI and have had problems with
> > a number of USB storage devices, one of which (the SanDisk Cruzer)
> > causes a crash due to it reporting the maximum LUN as 1.  I'm also
> > seeing some interesting performance issues with ext2 being extremely
> > slow compared to FAT.
> > 
> > Additionally, I have been trying various USB hubs with EHCI and have
> > found that a large percentage fail to work.  Hopefully I'll look into it
> > more soon
> > when I get ahold of our USB analyzer again.
> > 
> > -Aaron
> > 
> > 

Re: [U-Boot] Trouble running hello_world

[Alfred Morgan]

> Well, then your entry point is at 0c10 and you don;t have to try
> other addresses.

At least that narrows my problem down.  If my problem is stdout not being sent 
to serial then how could I easily confirm this happening or not?  Will someone 
code me a blinking LED hello_world.c or, since I have serial working, a serial 
version I can try?

-alfred

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

Re: [U-Boot] [STATUS] v2011.03-rc1 released

[John Rigby]

On Wed, Feb 2, 2011 at 2:55 PM, Wolfgang Denk  wrote:
> Hello  everybody:
>
> * U-Boot v2011.03-rc1 was released on Wed, 02 Feb 2011.
>
> * Release "v2011.03" is scheduled in 39 days - on March 13, 2011.
>
> Please help testing, and check if all your relevant patches have been
> included.
>
>

This omap timer fix never got applied
http://patchwork.ozlabs.org/patch/76803/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [STATUS] v2011.03-rc1 released

[Paulraj, Sandeep]

>This omap timer fix never got applied
>http://patchwork.ozlabs.org/patch/76803/

was on vacation. I missed it. I'll apply it.

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

Re: [U-Boot] PCIE supported networking cards?

[Aaron Williams]

Disregard my previous email. I'm running into some issues trying to get PCIe 
working in u-boot.

-Aaron

On Wednesday, February 02, 2011 03:51:14 pm Aaron Williams wrote:
> Thanks,
> 
> I took the patch but it looks like it's unable to read the eeprom. It's
> possible it may also have something to do with our PCIE implementation
> since I'm trying to bring that up with the updated u-boot. I also need to
> go through the code and make sure that the driver is 64-bit friendly since
> we load u-boot above 4GB when enough memory is loaded (virt_to_phys
> returns a 64-bit address on our platform).
> 
> In the Linux e1000e driver I do see some differences between the
> e1000_82573 and the e1000_82574.
> 
> -Aaron
> 
> PCIe: Port 0 is SRIO, skipping.
> PCIe: Port 1 link active, 1 lanes, speed gen1
> PCI Autoconfig: Bus Memory region: [0xf800-0x],
> Physical Memory [f800-x]
> PCI Autoconfig: Bus I/O region: [0x10-0x1000e],
> Physical Memory: [10-1000e]
> address=0x10 bus_lower=0x100400PCI:   Bus Dev VenId DevId Class Int
> PCI Autoconfig: Bus Memory region: [0xf800-0x],
> Physical Memory [f800-x]
> PCI Autoconfig: Bus I/O region: [0x10-0x1000e],
> Physical Memory: [10-1000e]
> PCI Scan: Found Bus 0, Device 0, Function 0
> PCI Autoconfig: BAR 0, Mem, size=0x2, address=0xf800
> bus_lower=0xf802
> PCI Autoconfig: BAR 1, Mem, size=0x8, address=0xf808
> bus_lower=0xf810
> PCI Autoconfig: BAR 2, I/O, size=0x20, address=0x10 bus_lower=0x100020
> PCI Autoconfig: BAR 3, Mem, size=0x4000, address=0xf810
> bus_lower=0xf8104000
> PCIe: port=1, first_bus=0, last_bus=0
> e1000_initialize
> e1000#0: iobase 0xf800
> e1000_set_mac_type
> Found 52574, setting mac type to 17
> e1000_set_media_type
> copper interface
> e1000_reset_hw
> Masking off all interrupts
> Issuing a global reset to MAC
> Masking off all interrupts
> e1000_init_eeprom_params
> e1000_is_onboard_nvm_eeprom
> e1000_validate_eeprom_checksum
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom

Re: [U-Boot] [Patch V6 0/4] Add basic NVIDIA Tegra2 SoC support

[Mike Rapoport]

On 02/02/11 19:06, Tom Warren wrote:
> Mike,
> 
> On Wed, Feb 2, 2011 at 12:57 AM, Mike Rapoport  wrote:
>> On 02/02/11 02:09, Tom Warren wrote:
>>> I haven't seen any new feedback on this version (V6) of the patchset
>>> since it was posted.
>>>
>>> Wolfgang, Mike, Peter, et al - are you happy with the current patch?
>>
>> I'm Ok with the current patch.
> Thanks, Mike. Appreciate your help.
>>
>>> If so, when can I expect it to be pushed?
> Who has to push/accept/apply the patch? Wolfgang, or the ARM custodian?

AFAIK, the ARM custodian

> Thanks.
>>>
>>> Thanks,
>>>
>>> Tom
>>>
>>> On Thu, Jan 27, 2011 at 1:58 PM, Tom Warren  
>>> wrote:
 This series of patches adds preliminary/baseline support for NVIDIA's
 Tegra2 SoC.  Basic CPU (AVP), RAM and UART init are covered so that the
 system (Harmony or Seaboard) can boot to the U-Boot serial cmd prompt.

 Further support (for Cortex-A9 CPU(s), USB, SD/MMC, etc.) to follow.

 Changes for V2:
- Coding style cleanup
- Remove mach-types.h change; wait for ARM kernel sync-up
- Move serial driver changes to separate patch
- Use board/nvidia/ instead of /board/tegra
- Remove TRUE/FALSE defines
- Use standard NS16550 register/bit defines in UART init
- Change nv-common.h config file to tegra2-common.h

 Changes for V3:
- Use I/O accessors for Tegra2 HW MMIO register access
- Allow conditional compile of UARTA/UARTD code to save space

 Changes for V4:
- Use address of HW structs (&pmc, etc.) in readl/writel
- Remove empty lines, fix mixed case hex #s & comments in header(s)
- Move board/nvidia/common/board.c UART code & header to
arch/arm/cpu/armv7/tegra2/
- Declare internal functions as static in UART code

 Changes for V5:
- Move arch/arm/cpu/armv7/uart.c & board.h to drivers/serial and
rename to serial_tegra2.c
- Remove use of uart_num & UART_A/D in serial_tegra2, simplify code

 Changes for V6:
- Fix uart.c add & delete in previous patchset
- Move pinmux & clock init code to common board file as per review
- Use #if defined() where possible in config files/UART code
- Drop all typedef and volatile struct declarations in header files

 Tom Warren (4):
  arm: Tegra2: Add basic NVIDIA Tegra2 SoC support
  serial: Add Tegra2 serial port support
  arm: Tegra2: Add support for NVIDIA Harmony board
  arm: Tegra2: Add support for NVIDIA Seaboard board

  MAINTAINERS  |5 +
  arch/arm/cpu/armv7/tegra2/Makefile   |   48 +++
  arch/arm/cpu/armv7/tegra2/board.c|   88 
  arch/arm/cpu/armv7/tegra2/config.mk  |   28 
  arch/arm/cpu/armv7/tegra2/lowlevel_init.S|   65 +
  arch/arm/cpu/armv7/tegra2/sys_info.c |   35 +
  arch/arm/cpu/armv7/tegra2/timer.c|  122 
  arch/arm/include/asm/arch-tegra2/clk_rst.h   |  165 ++
  arch/arm/include/asm/arch-tegra2/pinmux.h|   55 
  arch/arm/include/asm/arch-tegra2/pmc.h   |  124 +
  arch/arm/include/asm/arch-tegra2/sys_proto.h |   35 +
  arch/arm/include/asm/arch-tegra2/tegra2.h|   49 +++
  arch/arm/include/asm/arch-tegra2/uart.h  |   47 ++
  board/nvidia/common/board.c  |  193 
 ++
  board/nvidia/harmony/Makefile|   50 +++
  board/nvidia/seaboard/Makefile   |   50 +++
  boards.cfg   |2 +
  common/serial.c  |3 +-
  drivers/serial/Makefile  |1 +
  drivers/serial/serial_tegra2.c   |   77 ++
  drivers/serial/serial_tegra2.h   |   29 
  include/configs/harmony.h|   49 +++
  include/configs/seaboard.h   |   43 ++
  include/configs/tegra2-common.h  |  160 +
  include/serial.h |3 +-
  25 files changed, 1524 insertions(+), 2 deletions(-)
  create mode 100644 arch/arm/cpu/armv7/tegra2/Makefile
  create mode 100644 arch/arm/cpu/armv7/tegra2/board.c
  create mode 100644 arch/arm/cpu/armv7/tegra2/config.mk
  create mode 100644 arch/arm/cpu/armv7/tegra2/lowlevel_init.S
  create mode 100644 arch/arm/cpu/armv7/tegra2/sys_info.c
  create mode 100644 arch/arm/cpu/armv7/tegra2/timer.c
  create mode 100644 arch/arm/include/asm/arch-tegra2/clk_rst.h
  create mode 100644 arch/arm/include/asm/arch-tegra2/pinmux.h
  create mode 100644 arch/arm/include/asm/arch-tegra2

Re: [U-Boot] mach-type #define mismatch for lange51/efikamx

[Stefano Babic]

On 02/03/2011 01:04 AM, Loïc Minier wrote:
> Hey!
> 
>> iMX5: EfikaMX: Preliminary board support
> 
>  u-boot-imx has:
> #define MACH_TYPE_MX51_LANGE51 2336
> #define MACH_TYPE_MX51_LANGE52 2337
> 
>  u-boot-arm has:
> #define MACH_TYPE_MX51_EFIKAMX 2336
> #define MACH_TYPE_MX51_LANGE52 2337
> 
>  and linux has:
> mx51_efikamxMACH_MX51_EFIKAMX   MX51_EFIKAMX 2336
> mx51_lange52MACH_MX51_LANGE52   MX51_LANGE52 2337
> 
>  but board/efikamx/efikamx.c uses MACH_TYPE_MX51_LANGE51 (and hence
>  fails to build in u-boot-arm.git and u-boot.git).
> 
>  So while (Pegatron?) Lange 5.1 and 5.2 might have been more consistent,
>  I think we need to switch board/efikamx/efikamx.c to the linux name
>  MACH_MX51_EFIKAMX.

Marek, what do you think about ? It seems that the machine type for
efikamx is wrong.

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-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] BSS footprint of FAT very high - SPL issues

[sughosh ganu]

hi Aneesh,

On Wed, Feb 2, 2011 at 7:31 PM, Aneesh V  wrote:

> Yes. These are variables that otherwise would go to BSS. I do this
> because I need them before SDRAM initialization. One of this is the gd
> structure. I allocate gd structure in .data that is in IRAM.
> Why I need gd before SDRAM? Because I try to initialize serial console
> as early as possible and this code has some reference to gd.
>

I had added serial console support in my nand_spl code for the hawkboard
port(referring existing FSL boards). I think the serial console can be
initialised using NS16550_init, which does not access any gd variable. This
is assuming that you can use the ns16550 serial driver :)

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

Re: [U-Boot] BSS footprint of FAT very high - SPL issues

[Aneesh V]

Hello Graeme,

On Thursday 03 February 2011 02:31 AM, Graeme Russ wrote:
[snip ..]
>> Yes. These are variables that otherwise would go to BSS. I do this
>> because I need them before SDRAM initialization. One of this is the gd
>> structure. I allocate gd structure in .data that is in IRAM.
>> Why I need gd before SDRAM? Because I try to initialize serial console
>> as early as possible and this code has some reference to gd.
>>
>
> Which is a perfectly normal scenario and the way things have always been.
> There should have been no need to shuffle gd around because of console
> initialisation.
>
> And as I understand it, gd itself does not get statically 'allocated' in
> the u-boot image per-se (i.e. not in .data and not in .bss) - Only the
> pointer to it is allocated. In most arches, this pointer is itself not
> in .data or .bss but rather in a fixed reserved register. In the new x86
> (final patches coming soon), the pointer is allocated in .data with a
> preset initialised value pointing into  Cache-As-RAM (i.e. IRAM). Prior to
> relocation, the gd pointer variable points to somewhere in IRAM / CAR and
> after relocation, gd gets copied into the heap and the gd pointer adjusted
> to point to the new permanent copy.

Please note that SPL starts executing from IRAM and not
FLASH (copied there by ROM code). So we have .data available
immediately. Actually we do not need gd except to reuse some code from
u-boot that uses it. Declaring gd as a static variable was just a
convenience decision.

If I were to allocate it separately I would have to allocate it in the
same IRAM and I may end up reserving more space than needed to allow
for future expansion. IRAM space is at a premium. So, declaring it as a
static variable helps in allocating only as much space as is needed.

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

[U-Boot] Berfore relocation.

[Lakshmi T]

Hai all .

 

I am very new to U-boot and trying to port u-boot onto MPC885 platform.

I have done necessary changes in uboot and burned the Uboot binary in NOR
based FLASH.

The code is executing from FLASH and am able to see console messages.

And no messages are seen after the following

 

U-Boot 1.1.6 (Feb  2 2011 - 18:01:58)

 

CPU:   MPC885ZPnn at 50 MHz: 8 kB I-Cache 8 kB D-Cache FEC present

Board: MPC885ADS

DRAM:  (8 MB SDRAM)  8 MB

BEFORE RELOCATE

 

 

Can any one let me know, why this is happening and where might the problem
be.

 

Thanks.

Ammu.

 

 

 

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

Re: [U-Boot] BSS footprint of FAT very high - SPL issues

[Aneesh V]

Hello Sughosh,

On Thursday 03 February 2011 12:19 PM, sughosh ganu wrote:
> hi Aneesh,
>
> On Wed, Feb 2, 2011 at 7:31 PM, Aneesh V  > wrote:
>
> Yes. These are variables that otherwise would go to BSS. I do this
> because I need them before SDRAM initialization. One of this is the gd
> structure. I allocate gd structure in .data that is in IRAM.
> Why I need gd before SDRAM? Because I try to initialize serial console
> as early as possible and this code has some reference to gd.
>
>
> I had added serial console support in my nand_spl code for the hawkboard
> port(referring existing FSL boards). I think the serial console can be
> initialised using NS16550_init, which does not access any gd variable.
> This is assuming that you can use the ns16550 serial driver :)

Thanks for the input. Yes, we are using ns16550 driver.

However, I would still need gd because it is getting used
in other places like the mmc driver that I have to use in the SPL.

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

[U-Boot] [PATCH] sh: sh7785lcr: Fix out of tree building

[nobuhiro . iwamatsu . yj]

From: Nobuhiro Iwamatsu 

Signed-off-by: Nobuhiro Iwamatsu 
---
 board/renesas/sh7785lcr/Makefile |8 ++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/board/renesas/sh7785lcr/Makefile b/board/renesas/sh7785lcr/Makefile
index b5c496f..e404fa6 100644
--- a/board/renesas/sh7785lcr/Makefile
+++ b/board/renesas/sh7785lcr/Makefile
@@ -23,8 +23,12 @@ LIB  = $(obj)lib$(BOARD).o
 COBJS  := sh7785lcr.o selfcheck.o rtl8169_mac.o
 SOBJS  := lowlevel_init.o
 
-$(LIB):$(obj).depend $(COBJS) $(SOBJS)
-   $(call cmd_link_o_target, $(COBJS) $(SOBJS))
+SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS))
+SOBJS  := $(addprefix $(obj),$(SOBJS))
+
+$(LIB): $(obj).depend $(OBJS) $(SOBJS)
+   $(call cmd_link_o_target, $(OBJS) $(SOBJS))
 
 clean:
rm -f $(SOBJS) $(OBJS)
-- 
1.7.2.3

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

Re: [U-Boot] Berfore relocation.

[Wolfgang Denk]

Dear Lakshmi T,

In message <002b01cbc370$fc2e0920$f48a1b60$@com> you wrote:
> 
> I am very new to U-boot and trying to port u-boot onto MPC885 platform.
> 
> I have done necessary changes in uboot and burned the Uboot binary in NOR
> based FLASH.
> 
> The code is executing from FLASH and am able to see console messages.
> 
> And no messages are seen after the following
> 
>  
> 
> U-Boot 1.1.6 (Feb  2 2011 - 18:01:58)
> 
>  
> 
> CPU:   MPC885ZPnn at 50 MHz: 8 kB I-Cache 8 kB D-Cache FEC present
> 
> Board: MPC885ADS
> 
> DRAM:  (8 MB SDRAM)  8 MB
> 
> BEFORE RELOCATE

Can you please stop adding all these bogus empy lines?  Thanks.

Re your problem: Please see the FAQ at
http://www.denx.de/wiki/view/DULG/UBootCrashAfterRelocation

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
"Plan to throw one away. You will anyway."
  - Fred Brooks, "The Mythical Man Month"
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Trouble running hello_world

[Wolfgang Denk]

Dear Alfred Morgan,

In message <85926fd6-dc95-41c1-9034-64697d1a8...@54.org> you wrote:
>
> At least that narrows my problem down.  If my problem is stdout not
> being sent to serial then how could I easily confirm this happening or
> not?  Will someone code me a blinking LED hello_world.c or, since I have
> serial working, a serial version I can try?

It's probably difficult to come up with something that is simpler than
the hello_world exampe (while stil being useful to debug the problem).

Re debugging: attach your JTAG debugger and fire up GDB...

Re "Will someone code me..." - yes, we can do this. Please contact me
off-list for a quotation.   [Ah, you ment - for free? Sorry, it's not
one of my itches.]

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
If the odds are a million to one against something occuring,  chances
are 50-50 it will.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] mach-type #define mismatch for lange51/efikamx

[Marek Vasut]

On Thursday 03 February 2011 07:32:02 Stefano Babic wrote:
> On 02/03/2011 01:04 AM, Loïc Minier wrote:
> > Hey!
> >> 
> >> iMX5: EfikaMX: Preliminary board support
> >> 
> >  u-boot-imx has:
> > #define MACH_TYPE_MX51_LANGE51 2336
> > #define MACH_TYPE_MX51_LANGE52 2337
> >  
> >  u-boot-arm has:
> > #define MACH_TYPE_MX51_EFIKAMX 2336
> > #define MACH_TYPE_MX51_LANGE52 2337
> >  
> >  and linux has:
> > mx51_efikamxMACH_MX51_EFIKAMX   MX51_EFIKAMX 2336
> > mx51_lange52MACH_MX51_LANGE52   MX51_LANGE52 2337
> >  
> >  but board/efikamx/efikamx.c uses MACH_TYPE_MX51_LANGE51 (and hence
> >  fails to build in u-boot-arm.git and u-boot.git).
> >  
> >  So while (Pegatron?) Lange 5.1 and 5.2 might have been more consistent,
> >  I think we need to switch board/efikamx/efikamx.c to the linux name
> >  MACH_MX51_EFIKAMX.
> 
> Marek, what do you think about ? It seems that the machine type for
> efikamx is wrong.

It used to be lange51, that's the official code-name too. They (genesi I guess) 
seem to have requested an update in linux-arm machine ID database. Obviously, 
needs a change. Thanks
> 
> Best regards,
> Stefano Babic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Trouble running hello_world

[Albert ARIBAUD]

Hi Alfred,

Le 03/02/2011 01:35, Alfred Morgan a écrit :

> Will someone code me a blinking LED hello_world.c or, since I have serial 
> working, a serial version I can try?

What prevents you from coding this? You have the whole source code and 
you build your hello_world from the same tree that produced your u-boot, 
haven't you? So you can modify hello_world.c as you see fit.

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

Re: [U-Boot] [STATUS] v2011.03-rc1 released

[Nobuhiro Iwamatsu]

Hi,

2011/2/3 Wolfgang Denk :
> Hello  everybody:
>
> * U-Boot v2011.03-rc1 was released on Wed, 02 Feb 2011.
>
> * Release "v2011.03" is scheduled in 39 days - on March 13, 2011.
>
> Please help testing, and check if all your relevant patches have been
> included.
>
>
> Note that still a large number of ARM boards are broken. I hope many
> people join the efforts and fix all the currently broken boards.
> Thanks in advance to everybody who lends a helping hand.
>

Please apply
  http://patchwork.ozlabs.org/patch/80297/
and
  http://patchwork.ozlabs.org/patch/71935/

Best regards,
  Nobuhiro

-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot