[U-Boot] Please pull u-boot-mmc.git

2010-04-23 Thread Andy Fleming
There are still a few pending patches that I'm waiting to hear back about,
and you or Kumar have applied most of the others, but this one has been
cleaned up and applied to my tree.

The following changes since commit a47a12becf66f02a56da91c161e2edb625e9f20c:
  Stefan Roese (1):
Move arch/ppc to arch/powerpc

are available in the git repository at:

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

Dipen Dudhat (1):
  ppc/85xx: PIO Support for FSL eSDHC Controller Driver

 drivers/mmc/fsl_esdhc.c |   87 +-
 include/fsl_esdhc.h |2 +
 2 files changed, 87 insertions(+), 2 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH][RFC] SD/MMC: multiple block read support

2010-04-23 Thread Andy Fleming
On Wed, Apr 7, 2010 at 10:31 AM, Kumar Gala  wrote:
> From: Jerry Huang 
>
> Multiple block read support to improve performance (time it takes) to read
> larger amounts of data.
>
> Signed-off-by: Jerry Huang 
> Signed-off-by: Roy Zang 


How well has this been tested?  I recall that there was some reason I
did this, like the DMA wouldn't work to unaligned addresses.  Or would
show up in the middle of the buffer if you read from an unaligned
address.

So has this been tested by trying to read a partial block?  By trying
to read multiple blocks that start and/or end at non-block-aligned
addresses?  I can't test this tonight, but will this weekend.  I hope
this didn't break it.  :)

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


Re: [U-Boot] da850/L138 SPI flash transfer speed

2010-04-23 Thread Delio Brignoli
On 24/04/2010, at 11:42 AM, Wolfgang Denk wrote:
> In message  you wrote:
>> 
>> OK, so reducing the number of reads from registers and writes to RAM
>> should improve performance. To you knowledge, would enabling the
>> cache for davinci da850 break anything in U-Boot?
> 
> No, except that it should be done consistently for all ARM processors.

Thank you Wolfgang. I will give the source a closer look to see
how similar per-CPU setups are handled in U-Boot.

Kind regards
--
Delio

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


Re: [U-Boot] [PATCH] PXAMMC: Drop different delays for PXA27X

2010-04-23 Thread Andy Fleming
On Fri, Apr 23, 2010 at 8:29 PM, Marek Vasut  wrote:
> Dne So 24. dubna 2010 03:13:07 Andy Fleming napsal(a):
>> On Sun, Apr 4, 2010 at 7:32 PM, Marek Vasut  wrote:
>> > In case the delays were set to 1, the MMC card on PXA27X boards (and
>> > PXA3xx boards) didn't initialize on first try. Increasing the delays and
>> > leaving just those for PXA25x and 26x (that is 20) fixes this
>> > problem.
>>
>> In general, I object to board-specific #ifdefs in drivers.
>
> This is not a board specific ifdef.

I'm sorry, I misread the patch completely.  I assumed you were adding
the #ifdefs, instead of removing them, as that is the usual pattern,
and I had misunderstood your patch description.  20us is a long
time.  Are you sure it's necessary (would 10 work)?  Let me know,
and I'll apply this patch.

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


Re: [U-Boot] [PATCH 2/2] PXAMCI Monahans support

2010-04-23 Thread Marek Vasut
Dne So 24. dubna 2010 03:22:08 Andy Fleming napsal(a):
> On Fri, Mar 26, 2010 at 12:57 AM, Marek Vasut  wrote:
> > ---
> >  drivers/mmc/pxa_mmc.c |   13 -
> >  1 files changed, 8 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/mmc/pxa_mmc.c b/drivers/mmc/pxa_mmc.c
> > index 8225235..18d5df9 100644
> > --- a/drivers/mmc/pxa_mmc.c
> > +++ b/drivers/mmc/pxa_mmc.c
> > @@ -126,7 +126,7 @@ mmc_block_read(uchar * dst, ulong src, ulong len)
> >MMC_I_MASK = ~MMC_I_MASK_RXFIFO_RD_REQ;
> >while (len) {
> >if (MMC_I_REG & MMC_I_REG_RXFIFO_RD_REQ) {
> > -#ifdef CONFIG_PXA27X
> > +#if defined(CONFIG_PXA27X) || defined(CONFIG_CPU_MONAHANS)
> >int i;
> >for (i = min(len, 32); i; i--) {
> >*dst++ = *((volatile uchar *)&MMC_RXFIFO);
> > @@ -558,8 +558,11 @@ mmc_legacy_init(int verbose)
> >set_GPIO_mode(GPIO6_MMCCLK_MD);
> >set_GPIO_mode(GPIO8_MMCCS0_MD);
> >  #endif
> > +#ifdef CONFIG_CPU_MONAHANS /* pxa3xx */
> > +   CKENA |= CKENA_12_MMC0 | CKENA_13_MMC1;
> > +#else  /* pxa2xx */
> 
> Let's try to find a solution to this that doesn't require filling this
> driver with more #ifdefs.

That won't make too much sense. You won't run the same binary on both pxa2xx 
and 
pxa3xx ... ever. Increasing the bootloader size only because you want to avoid 
ifdef makes no sense either.

There are other ifdefs in that driver that need to go away (will in further 
patches), this one is the least harmful one.
> 
> Andy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] PXAMMC: Drop different delays for PXA27X

2010-04-23 Thread Marek Vasut
Dne So 24. dubna 2010 03:13:07 Andy Fleming napsal(a):
> On Sun, Apr 4, 2010 at 7:32 PM, Marek Vasut  wrote:
> > In case the delays were set to 1, the MMC card on PXA27X boards (and
> > PXA3xx boards) didn't initialize on first try. Increasing the delays and
> > leaving just those for PXA25x and 26x (that is 20) fixes this
> > problem.
> 
> In general, I object to board-specific #ifdefs in drivers.

This is not a board specific ifdef.

> At the
> very least, change this so that the value
> is specified like so:
> 
> #ifndef PXA_TIMEOUT_DELAY
> #define PXA_TIMEOUT_DELAY 1
> #endif
> 
> And then override the value in the PXA27X config file.

No need to override anything.
> 
> That way, when the next board comes along, and someone objects to
> waiting a fifth of a second between each try, but they need more than
> 10,000us, they can override it to a different value without doing
> cascading #ifdefs.

There won't be any ifdefs or board specific goo.
> 
> Andy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] at91sam9g45ekes SDHC/MMC

2010-04-23 Thread Andy Fleming
On Fri, Apr 23, 2010 at 6:21 PM, Albin Tonnerre
 wrote:
> On Fri, 23 Apr 2010 16:58 -0500, Andy Fleming wrote :
>> On Thu, Apr 22, 2010 at 7:51 PM, Rob Emanuele  wrote:
>> > Hi Henry & U-Boot Community,
>> >
>> > I've been experiencing the same errors and frustration you have.
>> >
>> > So I've been looking at this code and these patch sets for a day or
>> > two now.  I've done that in conjunction with reading the SD card spec:
>> > http://www.sdcard.org/developers/tech/sdcard/pls/
>> >
>> > I've come to the conclusion that this code as it stands will not work
>> > with any card that conforms to the SD Physical Layer Simplified
>> > Specification Version 2.0.  This includes all SDHC cards and some
>> > non-HC cards that conform to version 2.0.  I have a few 1GB cards that
>> > work just fine with the atmel_mci.c code on a 'G45 as it was in rev
>> > 95c44ec485b46ffb43dbdaa299f1491a500fdadf .
>> >
>> > If your SD card is newer, you'll see in the for loop in "sd_init_card"
>> > in atmel_mci.c time out.  In the 2.0 spec, you need to perform a CMD8
>> > (SEND_IF_COND) first to see if your card is a 2.0 card.  In CMD8 you
>> > tell the card the voltages you support and if you support HC cards.
>> > Once you send it the right data there, then ACMD41 will not have its
>> > BUSY bit set.  That's all well and good, but additionally the CSD
>> > register is in a new format and that needs updating before any of this
>> > will work.
>>
>>
>> The best solution is to use the MMC framework, which *does* do all of
>> these things that you suggest.  It should be fairly straightforward to
>> port the atmel_mci driver to this framework.  If you see something
>> lacking, feel free to mention it, or modify the framework.  :)
>
> I did port the atmel_mci driver to the MMC framework and posted the results on
> this mailing list a few months back. However, some people apparently 
> experienced
> issues I have never been able to reproduce, and got few review.
> I recently adapted the AT91 SD/MMC support patch and the atmel_mci port to use
> the new C structures access, I'll repost it in a couple days in case anyone's
> interested.
>


Yeah, I see that now.  I'm catching up from being in various other
project quagmires.  Sadly,
I can't apply your patch if people are running into problems with it,
but I'd far prefer it.

I also don't have such a board, though.  If someone could apply
Albin's patches, and try to identify why it's not working, I'd be very
appreciative.  :)

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


Re: [U-Boot] [PATCH 2/2] PXAMCI Monahans support

2010-04-23 Thread Andy Fleming
On Fri, Mar 26, 2010 at 12:57 AM, Marek Vasut  wrote:
> ---
>  drivers/mmc/pxa_mmc.c |   13 -
>  1 files changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mmc/pxa_mmc.c b/drivers/mmc/pxa_mmc.c
> index 8225235..18d5df9 100644
> --- a/drivers/mmc/pxa_mmc.c
> +++ b/drivers/mmc/pxa_mmc.c
> @@ -126,7 +126,7 @@ mmc_block_read(uchar * dst, ulong src, ulong len)
>        MMC_I_MASK = ~MMC_I_MASK_RXFIFO_RD_REQ;
>        while (len) {
>                if (MMC_I_REG & MMC_I_REG_RXFIFO_RD_REQ) {
> -#ifdef CONFIG_PXA27X
> +#if defined(CONFIG_PXA27X) || defined(CONFIG_CPU_MONAHANS)
>                        int i;
>                        for (i = min(len, 32); i; i--) {
>                                *dst++ = *((volatile uchar *)&MMC_RXFIFO);
> @@ -558,8 +558,11 @@ mmc_legacy_init(int verbose)
>        set_GPIO_mode(GPIO6_MMCCLK_MD);
>        set_GPIO_mode(GPIO8_MMCCS0_MD);
>  #endif
> +#ifdef CONFIG_CPU_MONAHANS     /* pxa3xx */
> +       CKENA |= CKENA_12_MMC0 | CKENA_13_MMC1;
> +#else  /* pxa2xx */


Let's try to find a solution to this that doesn't require filling this
driver with more #ifdefs.

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


Re: [U-Boot] [PATCH] PXAMMC: Drop different delays for PXA27X

2010-04-23 Thread Andy Fleming
On Sun, Apr 4, 2010 at 7:32 PM, Marek Vasut  wrote:
> In case the delays were set to 1, the MMC card on PXA27X boards (and 
> PXA3xx
> boards) didn't initialize on first try. Increasing the delays and leaving just
> those for PXA25x and 26x (that is 20) fixes this problem.


In general, I object to board-specific #ifdefs in drivers.  At the
very least, change this so that the value
is specified like so:

#ifndef PXA_TIMEOUT_DELAY
#define PXA_TIMEOUT_DELAY 1
#endif

And then override the value in the PXA27X config file.

That way, when the next board comes along, and someone objects to
waiting a fifth of a second between each try, but they need more than
10,000us, they can override it to a different value without doing
cascading #ifdefs.

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


Re: [U-Boot] da850/L138 SPI flash transfer speed

2010-04-23 Thread Wolfgang Denk
Dear Delio Brignoli,

In message  you wrote:
> 
> OK, so reducing the number of reads from registers and writes to RAM
> should improve performance. To you knowledge, would enabling the
> cache for davinci da850 break anything in U-Boot?

No, except that it should be done consistently for all ARM processors.

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
Disobedience:  The silver lining to the cloud of servitude.
- Ambrose Bierce
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] da850/L138 SPI flash transfer speed

2010-04-23 Thread Delio Brignoli
Hello Wolfgang,

On 24/04/2010, at 10:29 AM, Wolfgang Denk wrote:
> please mind the NetiQuette and restrict your line length to some 70
> charatcers or so.  Thanks.

Will do, thanks.

> Everything is slow as caches are not enabled.

OK, so reducing the number of reads from registers and writes to RAM
should improve performance. To you knowledge, would enabling the
cache for davinci da850 break anything in U-Boot?

Best regards
--
Delio

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


Re: [U-Boot] at91sam9g45ekes SDHC/MMC

2010-04-23 Thread Albin Tonnerre
On Fri, 23 Apr 2010 16:58 -0500, Andy Fleming wrote :
> On Thu, Apr 22, 2010 at 7:51 PM, Rob Emanuele  wrote:
> > Hi Henry & U-Boot Community,
> >
> > I've been experiencing the same errors and frustration you have.
> >
> > So I've been looking at this code and these patch sets for a day or
> > two now.  I've done that in conjunction with reading the SD card spec:
> > http://www.sdcard.org/developers/tech/sdcard/pls/
> >
> > I've come to the conclusion that this code as it stands will not work
> > with any card that conforms to the SD Physical Layer Simplified
> > Specification Version 2.0.  This includes all SDHC cards and some
> > non-HC cards that conform to version 2.0.  I have a few 1GB cards that
> > work just fine with the atmel_mci.c code on a 'G45 as it was in rev
> > 95c44ec485b46ffb43dbdaa299f1491a500fdadf .
> >
> > If your SD card is newer, you'll see in the for loop in "sd_init_card"
> > in atmel_mci.c time out.  In the 2.0 spec, you need to perform a CMD8
> > (SEND_IF_COND) first to see if your card is a 2.0 card.  In CMD8 you
> > tell the card the voltages you support and if you support HC cards.
> > Once you send it the right data there, then ACMD41 will not have its
> > BUSY bit set.  That's all well and good, but additionally the CSD
> > register is in a new format and that needs updating before any of this
> > will work.
> 
> 
> The best solution is to use the MMC framework, which *does* do all of
> these things that you suggest.  It should be fairly straightforward to
> port the atmel_mci driver to this framework.  If you see something
> lacking, feel free to mention it, or modify the framework.  :)

I did port the atmel_mci driver to the MMC framework and posted the results on
this mailing list a few months back. However, some people apparently experienced
issues I have never been able to reproduce, and got few review.
I recently adapted the AT91 SD/MMC support patch and the atmel_mci port to use
the new C structures access, I'll repost it in a couple days in case anyone's
interested.

Cheers,
-- 
Albin Tonnerre, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] da850/L138 SPI flash transfer speed

2010-04-23 Thread Wolfgang Denk
Dear Delio Brignoli,

please mind the NetiQuette and restrict your line length to some 70
charatcers or so.  Thanks.

In message <4d573595-069a-4490-af2d-38ed3aad7...@audioscience.com> you wrote:
> 
> I am working on reducing boot time on an L138 EVM and SPI flash transfer 
> speed is currently the worst offender. U-Boot transfers from the SPI flash at 
> 0.6Mbytes/s, this a lot slower than I would expect for a 50MHz SPI clock. 
> Using a scope we found that 
> the chip select is active throughout the transfer (as expected), we see 
> ~160ns bursts of activity on the clock line for each byte transferred (8 bits 
> @ 50MHz) with 1us idle periods in between. Where does the 1us delay between 
> byte transfers come from? I
> s reading data bytes from the SPI registers very slow or is writing to RAM 
> one byte at a time slowing the transfer?

Everything is slow as caches are not enabled.


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
Our missions are peaceful -- not for conquest.  When we do battle, it
is only because we have no choice.
-- Kirk, "The Squire of Gothos", stardate 2124.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH RFC v3] add CONFIG_BOOTCOUNT_LIMIT for MCF5445x

2010-04-23 Thread Wolfgang Denk
Dear Wolfgang Wegner,

In message <20100423205938.gu20...@leila.ping.de> you wrote:
> This patch adds bootcount for Freescale MCF5445x. Two registers of
> eDMA transfer control descriptors (TCD[1]) are used because these
> are unused by linux kernel (freescale LTIB linux-2.6.25) and were
> tested to keep their contents across resets.
> TCD[1] is currently unused by the linux drivers, so using its registers
> should be safe as long as no non-standard driver is loaded.
> 
> Signed-off-by: Wolfgang Wegner 
> ---
> I implemented and tested this bootcount on a custom MCF54455 board.
> According to the data sheet, the internal SRAM is not supposed to be
> useful for data storage across resets. There is no explicit statement
> concerning the TCD registers, but in tests on our board the values
> did always survive reset.
> v2: updated comment
> v3: moved updated comment to the right place :-)

Did you???

>  arch/m68k/cpu/mcf5445x/cpu.c|   29 +
>  arch/m68k/include/asm/immap_5445x.h |1 +
>  2 files changed, 30 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/m68k/cpu/mcf5445x/cpu.c b/arch/m68k/cpu/mcf5445x/cpu.c
> index 6238bc0..70007c1 100644
> --- a/arch/m68k/cpu/mcf5445x/cpu.c
> +++ b/arch/m68k/cpu/mcf5445x/cpu.c
> @@ -110,3 +110,32 @@ int cpu_eth_init(bd_t *bis)
>   return mcffec_initialize(bis);
>  }
>  #endif
> +
> +#ifdef CONFIG_BOOTCOUNT_LIMIT
> +/*
> + * We use transfer descriptor registers as a persistent storage
> + * across resets. This was tested on a MCF54455.
> + * Neither U-Boot nor the stock LTIB kernel seem to use
> + * TCD[1], so it should be safe at least until application
> + * start.
> + */

This still reads the same...

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 biggest difference between time and space is that you can't reuse
time. - Merrick Furst
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] da850/L138 SPI flash transfer speed

2010-04-23 Thread Delio Brignoli
Hello Sekhar,

I am working on reducing boot time on an L138 EVM and SPI flash transfer speed 
is currently the worst offender. U-Boot transfers from the SPI flash at 
0.6Mbytes/s, this a lot slower than I would expect for a 50MHz SPI clock. Using 
a scope we found that the chip select is active throughout the transfer (as 
expected), we see ~160ns bursts of activity on the clock line for each byte 
transferred (8 bits @ 50MHz) with 1us idle periods in between. Where does the 
1us delay between byte transfers come from? Is reading data bytes from the SPI 
registers very slow or is writing to RAM one byte at a time slowing the 
transfer?

Reading the source I can see that FAST_READ is being issued to the SPI flash 
and, unless I am missing something, there shouldn't be a delay between byte 
transfers. Looking at the spi_xfer() function in drivers/spi/davinci_spi.c and 
the L138 SPI module documentation I can think of making the following 
improvements: call spi_readl(ds, BUF) only once per byte transfer; take 
advantage of the tx/rx buffers for pipelining; write received data to RAM 32bit 
at a time, instead of 1 byte at a time. Does any one of these improvements go 
in the right direction?

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


Re: [U-Boot] at91sam9g45ekes SDHC/MMC

2010-04-23 Thread Andy Fleming
On Thu, Apr 22, 2010 at 7:51 PM, Rob Emanuele  wrote:
> Hi Henry & U-Boot Community,
>
> I've been experiencing the same errors and frustration you have.
>
> So I've been looking at this code and these patch sets for a day or
> two now.  I've done that in conjunction with reading the SD card spec:
> http://www.sdcard.org/developers/tech/sdcard/pls/
>
> I've come to the conclusion that this code as it stands will not work
> with any card that conforms to the SD Physical Layer Simplified
> Specification Version 2.0.  This includes all SDHC cards and some
> non-HC cards that conform to version 2.0.  I have a few 1GB cards that
> work just fine with the atmel_mci.c code on a 'G45 as it was in rev
> 95c44ec485b46ffb43dbdaa299f1491a500fdadf .
>
> If your SD card is newer, you'll see in the for loop in "sd_init_card"
> in atmel_mci.c time out.  In the 2.0 spec, you need to perform a CMD8
> (SEND_IF_COND) first to see if your card is a 2.0 card.  In CMD8 you
> tell the card the voltages you support and if you support HC cards.
> Once you send it the right data there, then ACMD41 will not have its
> BUSY bit set.  That's all well and good, but additionally the CSD
> register is in a new format and that needs updating before any of this
> will work.


The best solution is to use the MMC framework, which *does* do all of
these things that you suggest.  It should be fairly straightforward to
port the atmel_mci driver to this framework.  If you see something
lacking, feel free to mention it, or modify the framework.  :)

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


Re: [U-Boot] [PATCH RFC v3] add CONFIG_BOOTCOUNT_LIMIT for MCF5445x

2010-04-23 Thread Wolfgang Wegner
This patch adds bootcount for Freescale MCF5445x. Two registers of
eDMA transfer control descriptors (TCD[1]) are used because these
are unused by linux kernel (freescale LTIB linux-2.6.25) and were
tested to keep their contents across resets.
TCD[1] is currently unused by the linux drivers, so using its registers
should be safe as long as no non-standard driver is loaded.

Signed-off-by: Wolfgang Wegner 
---
I implemented and tested this bootcount on a custom MCF54455 board.
According to the data sheet, the internal SRAM is not supposed to be
useful for data storage across resets. There is no explicit statement
concerning the TCD registers, but in tests on our board the values
did always survive reset.
v2: updated comment
v3: moved updated comment to the right place :-)

 arch/m68k/cpu/mcf5445x/cpu.c|   29 +
 arch/m68k/include/asm/immap_5445x.h |1 +
 2 files changed, 30 insertions(+), 0 deletions(-)

diff --git a/arch/m68k/cpu/mcf5445x/cpu.c b/arch/m68k/cpu/mcf5445x/cpu.c
index 6238bc0..70007c1 100644
--- a/arch/m68k/cpu/mcf5445x/cpu.c
+++ b/arch/m68k/cpu/mcf5445x/cpu.c
@@ -110,3 +110,32 @@ int cpu_eth_init(bd_t *bis)
return mcffec_initialize(bis);
 }
 #endif
+
+#ifdef CONFIG_BOOTCOUNT_LIMIT
+/*
+ * We use transfer descriptor registers as a persistent storage
+ * across resets. This was tested on a MCF54455.
+ * Neither U-Boot nor the stock LTIB kernel seem to use
+ * TCD[1], so it should be safe at least until application
+ * start.
+ */
+#include 
+
+void bootcount_store(ulong a)
+{
+   tcd_st *tcd = (tcd_st *)MMAP_TCD;
+
+   __raw_writel(a, &(tcd[1].saddr));
+   __raw_writel(BOOTCOUNT_MAGIC, &(tcd[1].daddr));
+}
+
+ulong bootcount_load(void)
+{
+   tcd_st *tcd = (tcd_st *)MMAP_TCD;
+
+   if (__raw_readl(&(tcd[1].daddr)) != BOOTCOUNT_MAGIC)
+   return 0;
+   else
+   return __raw_readl(&(tcd[1].saddr));
+}
+#endif /* CONFIG_BOOTCOUNT_LIMIT */
diff --git a/arch/m68k/include/asm/immap_5445x.h 
b/arch/m68k/include/asm/immap_5445x.h
index 57cf3ec..d6e416a 100644
--- a/arch/m68k/include/asm/immap_5445x.h
+++ b/arch/m68k/include/asm/immap_5445x.h
@@ -37,6 +37,7 @@
 #define MMAP_EDMA  0xFC044000
 #define MMAP_INTC0 0xFC048000
 #define MMAP_INTC1 0xFC04C000
+#define MMAP_TCD   0xFC045000
 #define MMAP_IACK  0xFC054000
 #define MMAP_I2C   0xFC058000
 #define MMAP_DSPI  0xFC05C000
-- 
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 RFC v2] add CONFIG_BOOTCOUNT_LIMIT for MCF5445x

2010-04-23 Thread Wolfgang Wegner
Dear Wolfgang Denk,

On Fri, Apr 23, 2010 at 10:47:53PM +0200, Wolfgang Denk wrote:
[...]
> Um... I think this was a misunderstanding. This comment here is lost
> in the git repository.

only half misunderstanding and half too late for me today... Sorry!

Best regards,
Wolfgang

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


Re: [U-Boot] [PATCH RFC v2] add CONFIG_BOOTCOUNT_LIMIT for MCF5445x

2010-04-23 Thread Wolfgang Denk
Dear Wolfgang Wegner,

In message <20100423202642.gt20...@leila.ping.de> you wrote:
> This patch adds bootcount for Freescale MCF5445x. Two registers of
> eDMA transfer control descriptors (TCD[1]) are used because these
> are unused by linux kernel (freescale LTIB linux-2.6.25) and were
> tested to keep their contents across resets.
> 
> Signed-off-by: Wolfgang Wegner 
> ---
> I implemented and tested this bootcount on a custom MCF54455 board.
> According to the data sheet, the internal SRAM is not supposed to be
> useful for data storage across resets. There is no explicit statement
> concerning the TCD registers, but in tests on our board the values
> did always survive reset. TCD[1] is currently unused by the linux
> drivers, so using its registers should be safe as long as no non-
> standard driver is loaded.
> v2: fixed comment

Um... I think this was a misunderstanding. This comment here is lost
in the git repository.

>  arch/m68k/cpu/mcf5445x/cpu.c|   29 +
>  arch/m68k/include/asm/immap_5445x.h |1 +
>  2 files changed, 30 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/m68k/cpu/mcf5445x/cpu.c b/arch/m68k/cpu/mcf5445x/cpu.c
> index 6238bc0..70007c1 100644
> --- a/arch/m68k/cpu/mcf5445x/cpu.c
> +++ b/arch/m68k/cpu/mcf5445x/cpu.c
> @@ -110,3 +110,32 @@ int cpu_eth_init(bd_t *bis)
>   return mcffec_initialize(bis);
>  }
>  #endif
> +
> +#ifdef CONFIG_BOOTCOUNT_LIMIT
> +/*
> + * We use transfer descriptor registers as a persistent storage
> + * across resets. This was tested on a MCF54455.
> + * Neither U-Boot nor the stock LTIB kernel seem to use
> + * TCD[1], so it should be safe at least until application
> + * start.
> + */

It was this comment here that IMHO should be changed as the "until
application start" is misleading.

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
All your people must learn before you can reach for the stars.
-- Kirk, "The Gamesters of Triskelion", stardate 3259.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH RFC v2] add CONFIG_BOOTCOUNT_LIMIT for MCF5445x

2010-04-23 Thread Wolfgang Wegner
This patch adds bootcount for Freescale MCF5445x. Two registers of
eDMA transfer control descriptors (TCD[1]) are used because these
are unused by linux kernel (freescale LTIB linux-2.6.25) and were
tested to keep their contents across resets.

Signed-off-by: Wolfgang Wegner 
---
I implemented and tested this bootcount on a custom MCF54455 board.
According to the data sheet, the internal SRAM is not supposed to be
useful for data storage across resets. There is no explicit statement
concerning the TCD registers, but in tests on our board the values
did always survive reset. TCD[1] is currently unused by the linux
drivers, so using its registers should be safe as long as no non-
standard driver is loaded.
v2: fixed comment

 arch/m68k/cpu/mcf5445x/cpu.c|   29 +
 arch/m68k/include/asm/immap_5445x.h |1 +
 2 files changed, 30 insertions(+), 0 deletions(-)

diff --git a/arch/m68k/cpu/mcf5445x/cpu.c b/arch/m68k/cpu/mcf5445x/cpu.c
index 6238bc0..70007c1 100644
--- a/arch/m68k/cpu/mcf5445x/cpu.c
+++ b/arch/m68k/cpu/mcf5445x/cpu.c
@@ -110,3 +110,32 @@ int cpu_eth_init(bd_t *bis)
return mcffec_initialize(bis);
 }
 #endif
+
+#ifdef CONFIG_BOOTCOUNT_LIMIT
+/*
+ * We use transfer descriptor registers as a persistent storage
+ * across resets. This was tested on a MCF54455.
+ * Neither U-Boot nor the stock LTIB kernel seem to use
+ * TCD[1], so it should be safe at least until application
+ * start.
+ */
+#include 
+
+void bootcount_store(ulong a)
+{
+   tcd_st *tcd = (tcd_st *)MMAP_TCD;
+
+   __raw_writel(a, &(tcd[1].saddr));
+   __raw_writel(BOOTCOUNT_MAGIC, &(tcd[1].daddr));
+}
+
+ulong bootcount_load(void)
+{
+   tcd_st *tcd = (tcd_st *)MMAP_TCD;
+
+   if (__raw_readl(&(tcd[1].daddr)) != BOOTCOUNT_MAGIC)
+   return 0;
+   else
+   return __raw_readl(&(tcd[1].saddr));
+}
+#endif /* CONFIG_BOOTCOUNT_LIMIT */
diff --git a/arch/m68k/include/asm/immap_5445x.h 
b/arch/m68k/include/asm/immap_5445x.h
index 57cf3ec..d6e416a 100644
--- a/arch/m68k/include/asm/immap_5445x.h
+++ b/arch/m68k/include/asm/immap_5445x.h
@@ -37,6 +37,7 @@
 #define MMAP_EDMA  0xFC044000
 #define MMAP_INTC0 0xFC048000
 #define MMAP_INTC1 0xFC04C000
+#define MMAP_TCD   0xFC045000
 #define MMAP_IACK  0xFC054000
 #define MMAP_I2C   0xFC058000
 #define MMAP_DSPI  0xFC05C000
-- 
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 0/2] POST cleanup

2010-04-23 Thread Anatolij Gustschin
Hello Michael,

On Fri, 23 Apr 2010 22:06:09 +0300
Michael Zaidman  wrote:

> The patches implement first 2 steps of POST framework cleanup 
> suggested by Wolfgang Denk in the
> http://lists.denx.de/pipermail/u-boot/2010-April/070400.html

Are you working on a patch addressing the 3rd step?
I need to add post_word_load/store for mpc5121 based
board and re-submit board support patches, but if these
functions are going to be eliminated, I have to drop
post_word_load/store extension patch from my series
and base my patches on your patch.

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


[U-Boot] Possible uboot crashes

2010-04-23 Thread John Tobias
Hello Guys,

I would like to know what are the possible chances that u-boot/ubl crashes?.
I am looking for some theory/scenario that I can possibly connect/apply the
scenario to what happened to my device based on dm6446.

The device has been running for a year now and for some reason it never come
back anymore. I connect through the serial port of the device and check if
there's something different. The device was in the state where the
bootloader is missing. I re-program the u-boot and the device boot it again
as I expected.
The /dev/mtd0 and /dev/mtd1 are not writable on linux space in order to
screwed up the uboot.

Thanks,

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


Re: [U-Boot] [PATCH RFC] add CONFIG_BOOTCOUNT_LIMIT for MCF5445x

2010-04-23 Thread Wolfgang Denk
Dear Wolfgang Wegner,

In message <20100423194341.gs20...@leila.ping.de> you wrote:
> 
> > > + * We use transfer descriptor registers as a persistent storage
> > > + * across resets. This was tested on a MCF54455.
> > > + * Neither U-Boot nor the stock LTIB kernel seem to use
> > > + * TCD[1], so it should be safe at least until application
> > > + * start.
> > 
> > This is not sufficent, then. The bootcounter requires to be reset from
> > User Space, i. e. _after_ the application has been succesfully
> > started. If application start messes with the value, this fails to
> > work.
> 
> sorry, my wording was not correct.
> What I meant was that no device driver in stock kernel uses these
> registers, so the only possibility for them to get used is if the
> init system or application loads some non-standard drivers.

I see. I guess the comment should be updated, then.

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 I can have honesty, it's easier to overlook mistakes.
-- Kirk, "Space Seed", stardate 3141.9
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH RFC] add CONFIG_BOOTCOUNT_LIMIT for MCF5445x

2010-04-23 Thread Wolfgang Wegner
Dear Wolfgang Denk,

On Fri, Apr 23, 2010 at 09:25:35PM +0200, Wolfgang Denk wrote:
> Dear Wolfgang Wegner,
> 
> In message <1272026324-18566-1-git-send-email-w.weg...@astro-kom.de> you 
> wrote:
> > This patch adds bootcount for Freescale MCF5445x. Two registers of
> > eDMA transfer control descriptors (TCD[1]) are used because these
> > are unused by linux kernel (freescale LTIB linux-2.6.25) and were
> > tested to keep their contents across resets.
> ...
> > +#ifdef CONFIG_BOOTCOUNT_LIMIT
> > +/*
> > + * We use transfer descriptor registers as a persistent storage
> > + * across resets. This was tested on a MCF54455.
> > + * Neither U-Boot nor the stock LTIB kernel seem to use
> > + * TCD[1], so it should be safe at least until application
> > + * start.
> 
> This is not sufficent, then. The bootcounter requires to be reset from
> User Space, i. e. _after_ the application has been succesfully
> started. If application start messes with the value, this fails to
> work.

sorry, my wording was not correct.
What I meant was that no device driver in stock kernel uses these
registers, so the only possibility for them to get used is if the
init system or application loads some non-standard drivers.

Regards,
Wolfgang

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


Re: [U-Boot] bf537-stamp board compilation problem

2010-04-23 Thread Wolfgang Denk
Dear Mike Frysinger,

In message <201004231533.58136.vap...@gentoo.org> you wrote:
>
> it.  i could just as easily say "i'd rather the code didnt assume powerpc 
> everywhere", but it isnt like that gets us from point a to point b.

I would have preferred an architecture neutral implementation as well,
but you know how it works: you start with just one specific processor
in mind, then another CPU of the same architecture gets added, and
when you try to add support for another architecture some rework and
cleanup is needed.  Same story here: first came MPC823E, then PPC440EX.
Both happened to be PPC...

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 more data I punch in this card,  the lighter it becomes, and the
lower the mailing cost."
 - Stan Kelly-Bootle, "The Devil's DP Dictionary"
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] Call Now:+234 5288 1740

2010-04-23 Thread W U
Confirm the receipt of $50,000:Send your information to 
(westernafricau...@w.cn) Name,Age,Address,Phone,Occupation,Country.etc

-
Find the home of your dreams with eircom net property
Sign up for email alerts now http://www.eircom.net/propertyalerts


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


Re: [U-Boot] bf537-stamp board compilation problem

2010-04-23 Thread Mike Frysinger
On Friday 23 April 2010 15:30:09 Wolfgang Denk wrote:
> Mike Frysinger wrote:
> > because the post/ dir has historically been ppc-only (literally sprinkled
> > with code that would not compile for any other arch), we were filtering
> > post/ out in the top level Makefile for Blackfin targets.
> > ifneq ($(ARCH),blackfin)
> > LIBS += post/libpost.a
> > endif
> 
> I'd rather have seen fixes for any such problems.

like i already said, we had plans to de-suckify post/, but never got around to 
it.  what you're asking for isnt trivial, nor were we seeing the demand for 
it.  i could just as easily say "i'd rather the code didnt assume powerpc 
everywhere", but it isnt like that gets us from point a to point b.
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] bf537-stamp board compilation problem

2010-04-23 Thread Wolfgang Denk
Dear Mike Frysinger,

In message <201004231137.16732.vap...@gentoo.org> you wrote:
>
> because the post/ dir has historically been ppc-only (literally sprinkled 
> with 
> code that would not compile for any other arch), we were filtering post/ out 
> in the top level Makefile for Blackfin targets.
> ifneq ($(ARCH),blackfin)
> LIBS += post/libpost.a
> endif

I'd rather have seen fixes for any such problems.

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 matters of principle, stand like a rock;  in  matters  of  taste,
swim with the current."- Thomas Jefferson
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH RFC] add CONFIG_BOOTCOUNT_LIMIT for MCF5445x

2010-04-23 Thread Wolfgang Denk
Dear Wolfgang Wegner,

In message <1272026324-18566-1-git-send-email-w.weg...@astro-kom.de> you wrote:
> This patch adds bootcount for Freescale MCF5445x. Two registers of
> eDMA transfer control descriptors (TCD[1]) are used because these
> are unused by linux kernel (freescale LTIB linux-2.6.25) and were
> tested to keep their contents across resets.
...
> +#ifdef CONFIG_BOOTCOUNT_LIMIT
> +/*
> + * We use transfer descriptor registers as a persistent storage
> + * across resets. This was tested on a MCF54455.
> + * Neither U-Boot nor the stock LTIB kernel seem to use
> + * TCD[1], so it should be safe at least until application
> + * start.

This is not sufficent, then. The bootcounter requires to be reset from
User Space, i. e. _after_ the application has been succesfully
started. If application start messes with the value, this fails to
work.

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 combination of a number of things to make existence worthwhile."
"Yes, the philosophy of 'none,' meaning 'all.'"
-- Spock and Lincoln, "The Savage Curtain", stardate 5906.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 2/2] Blackfin: POST: revive, sync to main stream, cleanup.

2010-04-23 Thread Michael Zaidman
1) post/post.c instead of arch/blackfin/lib/post.c
2) Alternative post_list support.

Suggested-by: Wolfgang Denk 
Signed-off-by: Michael Zaidman 
---
 arch/blackfin/lib/Makefile|2 +-
 arch/blackfin/lib/board.c |1 -
 arch/blackfin/lib/post.c  |  421 -
 board/bf537-stamp/Makefile|2 +-
 include/common.h  |3 +
 include/configs/bfin_adi_common.h |1 +
 post/Makefile |3 +-
 7 files changed, 8 insertions(+), 425 deletions(-)
 delete mode 100644 arch/blackfin/lib/post.c

diff --git a/arch/blackfin/lib/Makefile b/arch/blackfin/lib/Makefile
index 3bdba75..a18bbd6 100644
--- a/arch/blackfin/lib/Makefile
+++ b/arch/blackfin/lib/Makefile
@@ -46,7 +46,7 @@ COBJS-y   += clocks.o
 COBJS-$(CONFIG_CMD_CACHE_DUMP) += cmd_cache_dump.o
 COBJS-$(CONFIG_CMD_KGDB) += kgdb.o
 COBJS-y+= muldi3.o
-COBJS-$(CONFIG_POST) += post.o tests.o
+COBJS-$(CONFIG_POST_ALT_LIST) += tests.o
 COBJS-y+= string.o
 
 SRCS   := $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
diff --git a/arch/blackfin/lib/board.c b/arch/blackfin/lib/board.c
index 4e9bb19..00a2041 100644
--- a/arch/blackfin/lib/board.c
+++ b/arch/blackfin/lib/board.c
@@ -321,7 +321,6 @@ void board_init_r(gd_t * id, ulong dest_addr)
 
 #if defined(CONFIG_POST)
post_output_backlog();
-   post_reloc();
 #endif
 
/* initialize malloc() area */
diff --git a/arch/blackfin/lib/post.c b/arch/blackfin/lib/post.c
deleted file mode 100644
index faf6b96..000
--- a/arch/blackfin/lib/post.c
+++ /dev/null
@@ -1,421 +0,0 @@
-/*
- * (C) Copyright 2002
- * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
- *
- * See file CREDITS for list of people who contributed to this
- * project.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of
- * the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- * MA 02111-1307 USA
- */
-
-#include 
-#include 
-#include 
-#include 
-
-#ifdef CONFIG_LOGBUFFER
-#include 
-#endif
-
-DECLARE_GLOBAL_DATA_PTR;
-
-#define POST_MAX_NUMBER32
-
-#define BOOTMODE_MAGIC 0xDEAD
-
-int post_init_f(void)
-{
-   int res = 0;
-   unsigned int i;
-
-   for (i = 0; i < post_list_size; i++) {
-   struct post_test *test = post_list + i;
-
-   if (test->init_f && test->init_f()) {
-   res = -1;
-   }
-   }
-
-   gd->post_init_f_time = post_time_ms(0);
-   if (!gd->post_init_f_time) {
-   printf
-   ("post/post.c: post_time_ms seems not to be implemented\n");
-   }
-
-   return res;
-}
-
-void post_bootmode_init(void)
-{
-   int bootmode = post_bootmode_get(0);
-   int newword;
-
-   if (post_hotkeys_pressed() && !(bootmode & POST_POWERTEST)) {
-   newword = BOOTMODE_MAGIC | POST_SLOWTEST;
-   } else if (bootmode == 0) {
-   newword = BOOTMODE_MAGIC | POST_POWERON;
-   } else if (bootmode == POST_POWERON || bootmode == POST_SLOWTEST) {
-   newword = BOOTMODE_MAGIC | POST_NORMAL;
-   } else {
-   /* Use old value */
-   newword = post_word_load() & ~POST_COLDBOOT;
-   }
-
-   if (bootmode == 0) {
-   /* We are booting after power-on */
-   newword |= POST_COLDBOOT;
-   }
-
-   post_word_store(newword);
-
-   /* Reset activity record */
-   gd->post_log_word = 0;
-}
-
-int post_bootmode_get(unsigned int *last_test)
-{
-   unsigned long word = post_word_load();
-   int bootmode;
-
-   if ((word & 0x) != BOOTMODE_MAGIC) {
-   return 0;
-   }
-
-   bootmode = word & 0x7F;
-
-   if (last_test && (bootmode & POST_POWERTEST)) {
-   *last_test = (word >> 8) & 0xFF;
-   }
-
-   return bootmode;
-}
-
-/* POST tests run before relocation only mark status bits  */
-static void post_log_mark_start(unsigned long testid)
-{
-   gd->post_log_word |= (testid) << 16;
-}
-
-static void post_log_mark_succ(unsigned long testid)
-{
-   gd->post_log_word |= testid;
-}
-
-/* ... and the messages are output once we are relocated */
-void post_output_backlog(void)
-{
-   int j;
-
-   for (j = 0; j < post_list_size; j++) {
-   if (gd->post_log_word & (post_list[j].testid << 16)) {
-   post_log("

[U-Boot] [PATCH 1/2] The bootcount_{store|load} moved to arch specific generic locations.

2010-04-23 Thread Michael Zaidman
Signed-off-by: Michael Zaidman 
Suggested-by: Wolfgang Denk 
---
 arch/powerpc/cpu/mpc8260/commproc.c |   24 
 arch/powerpc/cpu/mpc8260/cpu.c  |   24 
 arch/powerpc/cpu/mpc8xx/commproc.c  |   26 --
 arch/powerpc/cpu/mpc8xx/cpu.c   |   26 ++
 arch/powerpc/cpu/ppc4xx/commproc.c  |   24 
 arch/powerpc/cpu/ppc4xx/cpu.c   |   24 
 6 files changed, 74 insertions(+), 74 deletions(-)

diff --git a/arch/powerpc/cpu/mpc8260/commproc.c 
b/arch/powerpc/cpu/mpc8260/commproc.c
index 111a67c..c522bc5 100644
--- a/arch/powerpc/cpu/mpc8260/commproc.c
+++ b/arch/powerpc/cpu/mpc8260/commproc.c
@@ -195,27 +195,3 @@ ulong post_word_load (void)
 }
 
 #endif /* CONFIG_POST || CONFIG_LOGBUFFER*/
-
-#ifdef CONFIG_BOOTCOUNT_LIMIT
-
-void bootcount_store (ulong a)
-{
-   volatile ulong *save_addr =
-   (volatile ulong *)(CONFIG_SYS_IMMR + CPM_BOOTCOUNT_ADDR);
-
-   save_addr[0] = a;
-   save_addr[1] = BOOTCOUNT_MAGIC;
-}
-
-ulong bootcount_load (void)
-{
-   volatile ulong *save_addr =
-   (volatile ulong *)(CONFIG_SYS_IMMR + CPM_BOOTCOUNT_ADDR);
-
-   if (save_addr[1] != BOOTCOUNT_MAGIC)
-   return 0;
-   else
-   return save_addr[0];
-}
-
-#endif /* CONFIG_BOOTCOUNT_LIMIT */
diff --git a/arch/powerpc/cpu/mpc8260/cpu.c b/arch/powerpc/cpu/mpc8260/cpu.c
index aedbf29..0beebb0 100644
--- a/arch/powerpc/cpu/mpc8260/cpu.c
+++ b/arch/powerpc/cpu/mpc8260/cpu.c
@@ -336,3 +336,27 @@ int cpu_eth_init(bd_t *bis)
 #endif
return 0;
 }
+
+#ifdef CONFIG_BOOTCOUNT_LIMIT
+
+void bootcount_store (ulong a)
+{
+   volatile ulong *save_addr =
+   (volatile ulong *)(CONFIG_SYS_IMMR + CPM_BOOTCOUNT_ADDR);
+
+   save_addr[0] = a;
+   save_addr[1] = BOOTCOUNT_MAGIC;
+}
+
+ulong bootcount_load (void)
+{
+   volatile ulong *save_addr =
+   (volatile ulong *)(CONFIG_SYS_IMMR + CPM_BOOTCOUNT_ADDR);
+
+   if (save_addr[1] != BOOTCOUNT_MAGIC)
+   return 0;
+   else
+   return save_addr[0];
+}
+
+#endif /* CONFIG_BOOTCOUNT_LIMIT */
diff --git a/arch/powerpc/cpu/mpc8xx/commproc.c 
b/arch/powerpc/cpu/mpc8xx/commproc.c
index a87a0dc..2c85377 100644
--- a/arch/powerpc/cpu/mpc8xx/commproc.c
+++ b/arch/powerpc/cpu/mpc8xx/commproc.c
@@ -103,29 +103,3 @@ ulong post_word_load (void)
 }
 
 #endif /* CONFIG_POST || CONFIG_LOGBUFFER*/
-
-#ifdef CONFIG_BOOTCOUNT_LIMIT
-
-void bootcount_store (ulong a)
-{
-   volatile ulong *save_addr =
-   (volatile ulong *)( ((immap_t *) 
CONFIG_SYS_IMMR)->im_cpm.cp_dpmem +
-   CPM_BOOTCOUNT_ADDR );
-
-   save_addr[0] = a;
-   save_addr[1] = BOOTCOUNT_MAGIC;
-}
-
-ulong bootcount_load (void)
-{
-   volatile ulong *save_addr =
-   (volatile ulong *)( ((immap_t *) 
CONFIG_SYS_IMMR)->im_cpm.cp_dpmem +
-   CPM_BOOTCOUNT_ADDR );
-
-   if (save_addr[1] != BOOTCOUNT_MAGIC)
-   return 0;
-   else
-   return save_addr[0];
-}
-
-#endif /* CONFIG_BOOTCOUNT_LIMIT */
diff --git a/arch/powerpc/cpu/mpc8xx/cpu.c b/arch/powerpc/cpu/mpc8xx/cpu.c
index 2eb848b..70d2e86 100644
--- a/arch/powerpc/cpu/mpc8xx/cpu.c
+++ b/arch/powerpc/cpu/mpc8xx/cpu.c
@@ -652,3 +652,29 @@ int cpu_eth_init(bd_t *bis)
 #endif
return 0;
 }
+
+#ifdef CONFIG_BOOTCOUNT_LIMIT
+
+void bootcount_store (ulong a)
+{
+   volatile ulong *save_addr =
+   (volatile ulong *)( ((immap_t *) 
CONFIG_SYS_IMMR)->im_cpm.cp_dpmem +
+   CPM_BOOTCOUNT_ADDR );
+
+   save_addr[0] = a;
+   save_addr[1] = BOOTCOUNT_MAGIC;
+}
+
+ulong bootcount_load (void)
+{
+   volatile ulong *save_addr =
+   (volatile ulong *)( ((immap_t *) 
CONFIG_SYS_IMMR)->im_cpm.cp_dpmem +
+   CPM_BOOTCOUNT_ADDR );
+
+   if (save_addr[1] != BOOTCOUNT_MAGIC)
+   return 0;
+   else
+   return save_addr[0];
+}
+
+#endif /* CONFIG_BOOTCOUNT_LIMIT */
diff --git a/arch/powerpc/cpu/ppc4xx/commproc.c 
b/arch/powerpc/cpu/ppc4xx/commproc.c
index a1696d3..6bf95e6 100644
--- a/arch/powerpc/cpu/ppc4xx/commproc.c
+++ b/arch/powerpc/cpu/ppc4xx/commproc.c
@@ -51,27 +51,3 @@ ulong post_word_load (void)
 }
 
 #endif /* CONFIG_POST || CONFIG_LOGBUFFER*/
-
-#ifdef CONFIG_BOOTCOUNT_LIMIT
-
-void bootcount_store (ulong a)
-{
-   volatile ulong *save_addr =
-   (volatile ulong *)(CONFIG_SYS_OCM_DATA_ADDR + 
CONFIG_SYS_BOOTCOUNT_ADDR);
-
-   save_addr[0] = a;
-   save_addr[1] = BOOTCOUNT_MAGIC;
-}
-
-ulong bootcount_load (void)
-{
-   volatile ulong *save_addr =
-   (volatile ulong *)(CONFIG_SYS_OCM_DATA_ADDR + 
CONFIG_SYS_BOOTCOUNT_ADDR);
-
-   if (save_addr[1] != BOOTCOUNT_MAGIC)
-   return 0;
-   else
-   retur

[U-Boot] [PATCH 0/2] POST cleanup

2010-04-23 Thread Michael Zaidman
The patches implement first 2 steps of POST framework cleanup 
suggested by Wolfgang Denk in the
http://lists.denx.de/pipermail/u-boot/2010-April/070400.html

Michael Zaidman (2):
  The bootcount_{store|load} moved to arch specific generic locations.
  Blackfin: POST: revive, sync to main stream, cleanup.

 arch/blackfin/lib/Makefile  |2 +-
 arch/blackfin/lib/board.c   |1 -
 arch/blackfin/lib/post.c|  421 ---
 arch/powerpc/cpu/mpc8260/commproc.c |   24 --
 arch/powerpc/cpu/mpc8260/cpu.c  |   24 ++
 arch/powerpc/cpu/mpc8xx/commproc.c  |   26 ---
 arch/powerpc/cpu/mpc8xx/cpu.c   |   26 +++
 arch/powerpc/cpu/ppc4xx/commproc.c  |   24 --
 arch/powerpc/cpu/ppc4xx/cpu.c   |   24 ++
 board/bf537-stamp/Makefile  |2 +-
 include/common.h|3 +
 include/configs/bfin_adi_common.h   |1 +
 post/Makefile   |3 +-
 13 files changed, 82 insertions(+), 499 deletions(-)
 delete mode 100644 arch/blackfin/lib/post.c

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


[U-Boot] [PATCH] i.MX31: Activate NAND support for i.MX31 Litekit board.

2010-04-23 Thread Magnus Lilja
Signed-off-by: Magnus Lilja 
---
 include/configs/imx31_litekit.h |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/include/configs/imx31_litekit.h b/include/configs/imx31_litekit.h
index 6131008..d58ca8a 100644
--- a/include/configs/imx31_litekit.h
+++ b/include/configs/imx31_litekit.h
@@ -89,6 +89,7 @@
 #define CONFIG_CMD_PING
 #define CONFIG_CMD_SPI
 #define CONFIG_CMD_DATE
+#define CONFIG_CMD_NAND
 
 #define CONFIG_BOOTDELAY   3
 
@@ -174,4 +175,13 @@
 #undef CONFIG_CMD_MTDPARTS
 #define CONFIG_JFFS2_DEV   "nor0"
 
+/*
+ * NAND flash
+ */
+#define CONFIG_NAND_MXC
+#define CONFIG_MXC_NAND_REGS_BASE  NFC_BASE_ADDR
+#define CONFIG_SYS_MAX_NAND_DEVICE 1
+#define CONFIG_SYS_NAND_BASE   NFC_BASE_ADDR
+#define CONFIG_MXC_NAND_HWECC
+
 #endif /* __CONFIG_H */
-- 
1.6.4.2

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


[U-Boot] [PATCH] fdt_support: add entry for sec3.1 and remove tls_ssl_stream descriptor type capability for sec3.3

2010-04-23 Thread Kim Phillips
Add sec3.1 h/w geometry for fdt node fixups.

Also, technically, whilst SEC v3.3 h/w honours the tls_ssl_stream descriptor
type, it lacks the ARC4 algorithm execution unit required to be able
to execute anything meaningful with it.  Change the node to agree with
the documentation that declares that the sec3.3 really doesn't have such
a descriptor type.

Reported-by: Haiying Wang 
Signed-off-by: Kim Phillips 
---
 common/fdt_support.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/common/fdt_support.c b/common/fdt_support.c
index b6f252a..a8ac617 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -534,7 +534,8 @@ void fdt_fixup_crypto_node(void *blob, int sec_rev)
{ 0x0202, 1, 24, 0x04c, 0x0122003f }, /* SEC 2.2 */
{ 0x0204, 4, 24, 0x07e, 0x012b0ebf }, /* SEC 2.4 */
{ 0x0300, 4, 24, 0x9fe, 0x03ab0ebf }, /* SEC 3.0 */
-   { 0x0303, 4, 24, 0x97c, 0x03ab0abf }, /* SEC 3.3 */
+   { 0x0301, 4, 24, 0xbfe, 0x03ab0ebf }, /* SEC 3.1 */
+   { 0x0303, 4, 24, 0x97c, 0x03a30abf }, /* SEC 3.3 */
};
char compat_strlist[ARRAY_SIZE(sec_rev_prop_list) *
sizeof("fsl,secX.Y")];
-- 
1.7.0.5

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


Re: [U-Boot] [PATCH v2] smc911x driver frame alignment patch

2010-04-23 Thread Valentin Yakovenkov

23.04.2010 19:11, Mike Frysinger wrote:


for future reference, you shouldnt put "patch" in the subject name ... i'm not
referring to the leading [PATCH], but the trailing "patch".

ok, thanx


also, i'm not sure if you're using `git send-email` because the trail of your
patch is missing the "---" marker:
I don't use git at all. We have mercurial "master repo" which is pulled 
from local "SVN synced repo" which is synchronized via svn with 
blackfin.uclinux.org.


This patch is a result of the "hg diff smc911.x" command with manually 
added signed-off-by line.


Is it so critical to make this patch via git?

--
  WBR, Valentin
  CJSC "NII STT", Russia, Smolensk
  http://www.niistt.ru



smime.p7s
Description: S/MIME Cryptographic Signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2] smc911x driver frame alignment patch

2010-04-23 Thread Mike Frysinger
On Friday 23 April 2010 12:48:55 Valentin Yakovenkov wrote:
> I don't use git at all. We have mercurial "master repo" which is pulled
> from local "SVN synced repo" which is synchronized via svn with
> blackfin.uclinux.org.

b.u.o offers git as well if that makes things easier to sync:
http://blackfin.uclinux.org/git/

> Is it so critical to make this patch via git?

no, but it is important the patch format matches what git expects.  so if you 
add the --- marker yourself after the s-o-b tag, that's fine.
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] bf537-stamp board compilation problem

2010-04-23 Thread Mike Frysinger
On Friday 23 April 2010 12:31:21 Michael Zaidman wrote:
> Will you fix the CONFIG_{MMC,SPI_MMC} in the bf537-stamp.h header by
> yourself or you want me to do it it this patch set?

i'll take care of it
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] bf537-stamp board compilation problem

2010-04-23 Thread Michael Zaidman
On Fri, Apr 23, 2010 at 6:37 PM, Mike Frysinger  wrote:
> On Friday 23 April 2010 11:21:28 Michael Zaidman wrote:
>> BTW, looking on the blackfin POST implementation I wonder if it was
>> used recently. Enabling POST on the bf537-stamp board caused the
>> post_list array of post/tests.c to be linked instead of
>> arch/blackfin/cpu/lib/tests.c as was expected...
>
> because the post/ dir has historically been ppc-only (literally sprinkled with
> code that would not compile for any other arch), we were filtering post/ out
> in the top level Makefile for Blackfin targets.
> ifneq ($(ARCH),blackfin)
> LIBS += post/libpost.a
> endif
> -mike
>
Ok, I am going to send the patches that bring the blackfin POST into
the main stream...
Will you fix the CONFIG_{MMC,SPI_MMC} in the bf537-stamp.h header by
yourself or you want me to do it it this patch set?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] convention for SPI dummy data?

2010-04-23 Thread Wolfgang Wegner
On Fri, Apr 23, 2010 at 11:34:53AM -0400, Mike Frysinger wrote:
[...]
> > the problem exists in the (coldfire) SPI driver, not in the MMC/SD code.
> 
> sorry, i thought you were proposing to fix it in the SPI/MMC driver

no, as far as I can see it is always set to 0xFF there if set explicitly,
i.e. except for the read-only transfers.

> what i've seen so far is that the idle val doesnt matter to most spi devices. 
>  
> so on the Blackfin side, we've been defaulting to 0xff so that things do work 
> "out of the box" for everyone (at least so far).

Sounds good - however I had just sent a patch implementing CONFIG_SPI_IDLE_VAL.

(I am quite hesitating to simply change such a basic default value because
I fear there might be other devices around relying on current behaviour.
On the other hand, my implementation adds 7 lines of preprocessor stuff,
which also does not look really good.)

Regards,
Wolfgang

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


[U-Boot] [PATCH RFC] add CONFIG_SPI_IDLE_VAL for cf_spi.c to allow use of spi_mmc

2010-04-23 Thread Wolfgang Wegner
This patch adds CONFIG_SPI_IDLE_VAL to cf_spi.c
The default setting is 0x0 to behave same as current version, in case
CONFIG_SPI_MMC is set, the value is set to 0x (all ones). In either
case, the value can be overwritten by board configuration.

Signed-off-by: Wolfgang Wegner 
---
 drivers/spi/cf_spi.c |   14 +++---
 1 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/spi/cf_spi.c b/drivers/spi/cf_spi.c
index 8cc1d03..7b26f2a 100644
--- a/drivers/spi/cf_spi.c
+++ b/drivers/spi/cf_spi.c
@@ -49,6 +49,14 @@ extern void cfspi_release_bus(uint bus, uint cs);
 
 DECLARE_GLOBAL_DATA_PTR;
 
+#ifndef CONFIG_SPI_IDLE_VAL
+#if defined(CONFIG_SPI_MMC)
+#define CONFIG_SPI_IDLE_VAL0x
+#else
+#define CONFIG_SPI_IDLE_VAL0x0
+#endif
+#endif
+
 #if defined(CONFIG_CF_DSPI)
 /* DSPI specific mode */
 #define SPI_MODE_MOD   0x0020
@@ -145,7 +153,7 @@ int cfspi_xfer(struct spi_slave *slave, uint bitlen, const 
void *dout,
}
 
if (din != NULL) {
-   cfspi_tx(ctrl, 0);
+   cfspi_tx(ctrl, CONFIG_SPI_IDLE_VAL);
if (cfslave->charbit == 16)
*spi_rd16++ = cfspi_rx();
else
@@ -169,7 +177,7 @@ int cfspi_xfer(struct spi_slave *slave, uint bitlen, const 
void *dout,
}
 
if (din != NULL) {
-   cfspi_tx(ctrl, 0);
+   cfspi_tx(ctrl, CONFIG_SPI_IDLE_VAL);
if (cfslave->charbit == 16)
*spi_rd16 = cfspi_rx();
else
@@ -177,7 +185,7 @@ int cfspi_xfer(struct spi_slave *slave, uint bitlen, const 
void *dout,
}
} else {
/* dummy read */
-   cfspi_tx(ctrl, 0);
+   cfspi_tx(ctrl, CONFIG_SPI_IDLE_VAL);
cfspi_rx();
}
 
-- 
1.5.6.5

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


Re: [U-Boot] convention for SPI dummy data?

2010-04-23 Thread Wolfgang Wegner
On Fri, Apr 23, 2010 at 05:18:29PM +0200, Wolfgang Wegner wrote:
> (Only pitfall is that the current 0x0 is used for 8- as well as 16-bit
> transfers...)

forget about that, the register is alway written as 16 bits.

Regards,
Wolfgang

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


Re: [U-Boot] bf537-stamp board compilation problem

2010-04-23 Thread Mike Frysinger
On Friday 23 April 2010 11:21:28 Michael Zaidman wrote:
> BTW, looking on the blackfin POST implementation I wonder if it was
> used recently. Enabling POST on the bf537-stamp board caused the
> post_list array of post/tests.c to be linked instead of
> arch/blackfin/cpu/lib/tests.c as was expected...

because the post/ dir has historically been ppc-only (literally sprinkled with 
code that would not compile for any other arch), we were filtering post/ out 
in the top level Makefile for Blackfin targets.
ifneq ($(ARCH),blackfin)
LIBS += post/libpost.a
endif
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] convention for SPI dummy data?

2010-04-23 Thread Mike Frysinger
On Friday 23 April 2010 11:18:29 Wolfgang Wegner wrote:
> On Fri, Apr 23, 2010 at 11:08:10AM -0400, Mike Frysinger wrote:
> > On Friday 23 April 2010 04:43:07 Wolfgang Wegner wrote:
> > > However, one of the things I had to change was the dummy data sent
> > > out by SPI for read-only transactions. The original driver had all
> > > zeros, for SD/MMC all ones (0xFF) is needed.
> > > 
> > > Is such a change acceptable, or is there any configuration option/flag
> > > I could use?
> > 
> > if it isnt part of the SPI/MMC spec, use a config option named like
> > IDLE_VAL.
> 
> the problem exists in the (coldfire) SPI driver, not in the MMC/SD code.

sorry, i thought you were proposing to fix it in the SPI/MMC driver

> (For SD, the spec IMHO clearly states 0xFF for all idle transfers.)

thanks, wasnt aware

> > changing the default to 0xff is OK i think.
> 
> I could add CONFIG_SPI_IDLE_VAL and default it to 0x0 in the coldfire
> SPI driver. In case one wants to use MMC/SD with this driver, one could
> then add CONFIG_SPI_IDLE_VAL as 0xFF in the board to override it.
> (Only pitfall is that the current 0x0 is used for 8- as well as 16-bit
> transfers...)

what i've seen so far is that the idle val doesnt matter to most spi devices.  
so on the Blackfin side, we've been defaulting to 0xff so that things do work 
"out of the box" for everyone (at least so far).
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH RFC v2] add redundant environment for env_sf.c

2010-04-23 Thread Wolfgang Wegner
This patch adds redundant environment for environment in SPI flash.
I took env_flash.c as an example and slightly modified it. Apart
from adapting things to SF, I also slightly changed the decision
logic to use area 2 as a default in case the flags are wrong because
not having a default path worried me.

I did not add a section for CONFIG_ENV_IS_IN_SPI_FLASH in environment.h
because I did not understand if this is desired and/or needed.
So to use the feature, one has to set CONFIG_ENV_OFFSET_REDUND _and_
CONFIG_SYS_REDUNDAND_ENVIRONMENT.

I checked it by powering off my board several times during flash
erase or write, because I do not know if there are other stress
test scenarios.

Signed-off-by: Wolfgang Wegner 
---
 common/env_sf.c |  232 +++
 1 files changed, 232 insertions(+), 0 deletions(-)

diff --git a/common/env_sf.c b/common/env_sf.c
index 6575b6d..4391d61 100644
--- a/common/env_sf.c
+++ b/common/env_sf.c
@@ -43,6 +43,14 @@
 # define CONFIG_ENV_SPI_MODE   SPI_MODE_3
 #endif
 
+#ifdef CONFIG_ENV_OFFSET_REDUND
+static ulong env_offset = CONFIG_ENV_OFFSET;
+static ulong env_new_offset = CONFIG_ENV_OFFSET_REDUND;
+
+#define ACTIVE_FLAG   1
+#define OBSOLETE_FLAG 0
+#endif /* CONFIG_ENV_ADDR_REDUND */
+
 DECLARE_GLOBAL_DATA_PTR;
 
 /* references to names in env_common.c */
@@ -58,6 +66,229 @@ uchar env_get_char_spec(int index)
return *((uchar *)(gd->env_addr + index));
 }
 
+#if defined(CONFIG_ENV_OFFSET_REDUND)
+void swap_env(void)
+{
+   ulong tmp_offset = env_offset;
+
+   env_offset = env_new_offset;
+   env_new_offset = tmp_offset;
+}
+
+int saveenv(void)
+{
+   u32 saved_size, saved_offset;
+   char *saved_buffer = NULL;
+   u32 sector = 1;
+   int ret;
+   char flag = OBSOLETE_FLAG, new_flag = ACTIVE_FLAG;
+
+   if (!env_flash) {
+   puts("Environment SPI flash not initialized\n");
+   return 1;
+   }
+
+   /* Is the sector larger than the env (i.e. embedded) */
+   if (CONFIG_ENV_SECT_SIZE > CONFIG_ENV_SIZE) {
+   saved_size = CONFIG_ENV_SECT_SIZE - CONFIG_ENV_SIZE;
+   saved_offset = env_new_offset + CONFIG_ENV_SIZE;
+   saved_buffer = malloc(saved_size);
+   if (!saved_buffer) {
+   ret = 1;
+   goto done;
+   }
+   ret = spi_flash_read(env_flash, saved_offset,
+   saved_size, saved_buffer);
+   if (ret)
+   goto done;
+   }
+
+   if (CONFIG_ENV_SIZE > CONFIG_ENV_SECT_SIZE) {
+   sector = CONFIG_ENV_SIZE / CONFIG_ENV_SECT_SIZE;
+   if (CONFIG_ENV_SIZE % CONFIG_ENV_SECT_SIZE)
+   sector++;
+   }
+
+   puts("Erasing SPI flash...");
+   ret = spi_flash_erase(env_flash, env_new_offset,
+   sector * CONFIG_ENV_SECT_SIZE);
+   if (ret)
+   goto done;
+
+   puts("Writing to SPI flash...");
+   ret = spi_flash_write(env_flash,
+   env_new_offset + offsetof(env_t, data),
+   sizeof(env_ptr->data), env_ptr->data);
+   if (ret)
+   goto done;
+
+   ret = spi_flash_write(env_flash,
+   env_new_offset + offsetof(env_t, crc),
+   sizeof(env_ptr->crc), &env_ptr->crc);
+   if (ret)
+   goto done;
+
+   ret = spi_flash_write(env_flash,
+   env_offset + offsetof(env_t, flags),
+   sizeof(env_ptr->flags), &flag);
+   if (ret)
+   goto done;
+
+   ret = spi_flash_write(env_flash,
+   env_new_offset + offsetof(env_t, flags),
+   sizeof(env_ptr->flags), &new_flag);
+   if (ret)
+   goto done;
+
+   if (CONFIG_ENV_SECT_SIZE > CONFIG_ENV_SIZE) {
+   ret = spi_flash_write(env_flash, saved_offset,
+   saved_size, saved_buffer);
+   if (ret)
+   goto done;
+   }
+
+   swap_env();
+
+   ret = 0;
+   puts("done\n");
+
+ done:
+   if (saved_buffer)
+   free(saved_buffer);
+   return ret;
+}
+
+void env_relocate_spec(void)
+{
+   int ret;
+   int crc1_ok = 0, crc2_ok = 0;
+   env_t *tmp_env1 = NULL;
+   env_t *tmp_env2 = NULL;
+   uchar flag1, flag2;
+   /* current_env is set only in case both areas are valid! */
+   int current_env = 0;
+
+   tmp_env1 = (env_t *)malloc(CONFIG_ENV_SIZE);
+   if (!tmp_env1) {
+   puts("*** Warning: could not init environment,"
+   " using defaults\n\n");
+   goto out;
+   }
+
+   tmp_env2 = (env_t *)malloc(CONFIG_ENV_SIZE);
+   if (!tmp_env2) {
+   puts("*** Warning: could not init environment,"
+   " using defaults\n\n");
+   goto out;
+   }
+
+

Re: [U-Boot] convention for SPI dummy data?

2010-04-23 Thread Wolfgang Wegner
Hi Mike,

On Fri, Apr 23, 2010 at 11:08:10AM -0400, Mike Frysinger wrote:
> On Friday 23 April 2010 04:43:07 Wolfgang Wegner wrote:
> > However, one of the things I had to change was the dummy data sent
> > out by SPI for read-only transactions. The original driver had all
> > zeros, for SD/MMC all ones (0xFF) is needed.
> > 
> > Is such a change acceptable, or is there any configuration option/flag
> > I could use?
> 
> if it isnt part of the SPI/MMC spec, use a config option named like IDLE_VAL. 
>  

the problem exists in the (coldfire) SPI driver, not in the MMC/SD code.
(For SD, the spec IMHO clearly states 0xFF for all idle transfers.)

> changing the default to 0xff is OK i think.

I could add CONFIG_SPI_IDLE_VAL and default it to 0x0 in the coldfire
SPI driver. In case one wants to use MMC/SD with this driver, one could
then add CONFIG_SPI_IDLE_VAL as 0xFF in the board to override it.
(Only pitfall is that the current 0x0 is used for 8- as well as 16-bit
transfers...)

ok?

> -mike

Regards,
Wolfgang

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


Re: [U-Boot] bf537-stamp board compilation problem

2010-04-23 Thread Michael Zaidman
On Fri, Apr 23, 2010 at 5:56 PM, Mike Frysinger  wrote:
> On Friday 23 April 2010 10:10:16 Michael Zaidman wrote:
>> Compiling the bf537-stamp board I got the following linker error:
>> /home/mike/develop/u-boot/u-boot-patch/common/cmd_mmc.c:53: undefined
>> reference to `mmc_legacy_init'
>> /home/mike/develop/u-boot/u-boot-patch/common/cmd_mmc.c:53: relocation
>> truncated to fit: R_pcrel24 against undefined symbol `mmc_legacy_init'
>> disk/libdisk.a(part.o):(.rodata.block_drvr+0x4): undefined reference
>> to `mmc_get_dev'
>> make: *** [u-boot] Error 1
>
> remove CONFIG_{MMC,SPI_MMC} from the bf537-stamp.h config header
> -mike
>
Ok, thanks, I just added CONFIG_GENERIC_MMC with the same effect :-)

BTW, looking on the blackfin POST implementation I wonder if it was
used recently. Enabling POST on the bf537-stamp board caused the
post_list array of post/tests.c to be linked instead of
arch/blackfin/cpu/lib/tests.c as was expected...

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


Re: [U-Boot] [PATCH v2] smc911x driver frame alignment patch

2010-04-23 Thread Mike Frysinger
for future reference, you shouldnt put "patch" in the subject name ... i'm not 
referring to the leading [PATCH], but the trailing "patch".

also, i'm not sure if you're using `git send-email` because the trail of your 
patch is missing the "---" marker:
=
It seems that fifo underflow occurs only when using byte packing on
32-bit blackfin bus (may be because of very small delay between reads).



Signed-off-by: Valentin Yakovenkov 
diff -r 7dc8ff189175 a/drivers/net/smc911x.c
--- a/drivers/net/smc911x.c Mon Mar 29 11:08:55 2010 +0400
=

it should have been like:
=
It seems that fifo underflow occurs only when using byte packing on
32-bit blackfin bus (may be because of very small delay between reads).

Signed-off-by: Valentin Yakovenkov 
---
diff -r 7dc8ff189175 a/drivers/net/smc911x.c
--- a/drivers/net/smc911x.c Mon Mar 29 11:08:55 2010 +0400
=
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] convention for SPI dummy data?

2010-04-23 Thread Mike Frysinger
On Friday 23 April 2010 04:43:07 Wolfgang Wegner wrote:
> However, one of the things I had to change was the dummy data sent
> out by SPI for read-only transactions. The original driver had all
> zeros, for SD/MMC all ones (0xFF) is needed.
> 
> Is such a change acceptable, or is there any configuration option/flag
> I could use?

if it isnt part of the SPI/MMC spec, use a config option named like IDLE_VAL.  
changing the default to 0xff is OK i think.
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH RFC] add redundant environment for env_sf.c

2010-04-23 Thread Mike Frysinger
On Friday 23 April 2010 05:22:16 Wolfgang Wegner wrote:
> Signed-off-by: Wolfgang Wegner 
> ---
> This patch adds redundant environment for environment in SPI flash.
> I took env_flash.c as an example and slightly modified it. Apart
> from adapting things to SF, I also slightly changed the decision
> logic to use area 2 as a default in case the flags are wrong.
> 
> I did not add a section for CONFIG_ENV_IS_IN_SPI_FLASH in environment.h
> because I did not understand if this is desired and/or needed.
> So to use the feature, one has to set CONFIG_ENV_OFFSET_REDUND _and_
> CONFIG_SYS_REDUNDAND_ENVIRONMENT.
> 
> I checked it by powering off my board several times during flash
> erase or write, because I do not know if there are other stress
> test scenarios.

this is a change log and belongs above your Signed-off-by tag, not after the 
--- marker.  please resend your patch.
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] Adding new architecture (nds32) support to u-boot

2010-04-23 Thread Mike Frysinger
On Thursday 22 April 2010 23:42:13 macp...@andestech.com wrote:
> Since our toolchain haven’t been commit to GNU, could we commit code to
> u-boot before GNU accept our toolchain support?

yes, you can

> Is there anything special that we must provide to you?

the patches :p
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH-V2 3/4] AM35x: Add support for AM3517EVM

2010-04-23 Thread hvaibhav
From: Vaibhav Hiremath 

This patch adds basic support for the AM3517EVM.
It includes:
- Board int file (.c and .h)
- Default configuration file
- Updates for Makefile

Signed-off-by: Vaibhav Hiremath 
Signed-off-by: Sanjeev Premi 
---
 Makefile  |3 +
 arch/arm/include/asm/arch-omap3/mux.h |   36 +++
 board/logicpd/am3517evm/Makefile  |   47 
 board/logicpd/am3517evm/am3517evm.c   |   76 ++
 board/logicpd/am3517evm/am3517evm.h   |  405 +
 board/logicpd/am3517evm/config.mk |   30 +++
 include/configs/am3517_evm.h  |  297 
 7 files changed, 894 insertions(+), 0 deletions(-)
 create mode 100644 board/logicpd/am3517evm/Makefile
 create mode 100644 board/logicpd/am3517evm/am3517evm.c
 create mode 100644 board/logicpd/am3517evm/am3517evm.h
 create mode 100644 board/logicpd/am3517evm/config.mk
 create mode 100644 include/configs/am3517_evm.h

diff --git a/Makefile b/Makefile
index 34f10ce..487ae73 100644
--- a/Makefile
+++ b/Makefile
@@ -3169,6 +3169,9 @@ omap3_zoom1_config :  unconfig
 omap3_zoom2_config :   unconfig
@$(MKCONFIG) $(@:_config=) arm arm_cortexa8 zoom2 logicpd omap3

+am3517_evm_config :unconfig
+   @$(MKCONFIG) $(@:_config=) arm arm_cortexa8 am3517evm logicpd omap3
+
 smdkc100_config:   unconfig
@$(MKCONFIG) $(@:_config=) arm arm_cortexa8 smdkc100 samsung s5pc1xx

diff --git a/arch/arm/include/asm/arch-omap3/mux.h 
b/arch/arm/include/asm/arch-omap3/mux.h
index 0c01c73..8ea47b6 100644
--- a/arch/arm/include/asm/arch-omap3/mux.h
+++ b/arch/arm/include/asm/arch-omap3/mux.h
@@ -283,6 +283,7 @@
 /*Control and debug */
 #define CONTROL_PADCONF_SYS_32K0x0A04
 #define CONTROL_PADCONF_SYS_CLKREQ 0x0A06
+#define CONTROL_PADCONF_SYS_NRESWARM   0x0A08
 #define CONTROL_PADCONF_SYS_NIRQ   0x01E0
 #define CONTROL_PADCONF_SYS_BOOT0  0x0A0A
 #define CONTROL_PADCONF_SYS_BOOT1  0x0A0C
@@ -403,6 +404,41 @@
 #define CONTROL_PADCONF_D2D_SBUSFLAG   0x0260
 #define CONTROL_PADCONF_SDRC_CKE0  0x0262
 #define CONTROL_PADCONF_SDRC_CKE1  0x0264
+/* AM3517 specific */
+#define CONTROL_PADCONF_CCDC_PCLK  0x01E4
+#define CONTROL_PADCONF_CCDC_FIELD 0x01E6
+#define CONTROL_PADCONF_CCDC_HD0x01E8
+#define CONTROL_PADCONF_CCDC_VD0x01EA
+#define CONTROL_PADCONF_CCDC_WEN   0x01EC
+#define CONTROL_PADCONF_CCDC_DATA0 0x01EE
+#define CONTROL_PADCONF_CCDC_DATA1 0x01F0
+#define CONTROL_PADCONF_CCDC_DATA2 0x01F2
+#define CONTROL_PADCONF_CCDC_DATA3 0x01F4
+#define CONTROL_PADCONF_CCDC_DATA4 0x01F6
+#define CONTROL_PADCONF_CCDC_DATA5 0x01F8
+#define CONTROL_PADCONF_CCDC_DATA6 0x01FA
+#define CONTROL_PADCONF_CCDC_DATA7 0x01FC
+#define CONTROL_PADCONF_RMII_MDIO_DATA 0x01FE
+#define CONTROL_PADCONF_RMII_MDIO_CLK  0x0200
+#define CONTROL_PADCONF_RMII_RXD0  0x0202
+#define CONTROL_PADCONF_RMII_RXD1  0x0204
+#define CONTROL_PADCONF_RMII_CRS_DV0x0206
+#define CONTROL_PADCONF_RMII_RXER  0x0208
+#define CONTROL_PADCONF_RMII_TXD0  0x020A
+#define CONTROL_PADCONF_RMII_TXD1  0x020C
+#define CONTROL_PADCONF_RMII_TXEN  0x020E
+#define CONTROL_PADCONF_RMII_50MHZ_CLK 0x0210
+#define CONTROL_PADCONF_USB0_DRVBUS0x0212
+#define CONTROL_PADCONF_HECC1_TXD  0x0214
+#define CONTROL_PADCONF_HECC1_RXD  0x0216
+#define CONTROL_PADCONF_SYS_BOOT7  0x0218
+#define CONTROL_PADCONF_SDRC_DQS0N 0x021A
+#define CONTROL_PADCONF_SDRC_DQS1N 0x021C
+#define CONTROL_PADCONF_SDRC_DQS2N 0x021E
+#define CONTROL_PADCONF_SDRC_DQS3N 0x0220
+#define CONTROL_PADCONF_STRBEN_DLY00x0222
+#define CONTROL_PADCONF_STRBEN_DLY10x0224
+#define CONTROL_PADCONF_SYS_BOOT8  0x0226

 #define MUX_VAL(OFFSET,VALUE)\
writew((VALUE), OMAP34XX_CTRL_BASE + (OFFSET));
diff --git a/board/logicpd/am3517evm/Makefile b/board/logicpd/am3517evm/Makefile
new file mode 100644
index 000..3c71fef
--- /dev/null
+++ b/board/logicpd/am3517evm/Makefile
@@ -0,0 +1,47 @@
+#
+# Author: Vaibhav Hiremath 
+#
+# Based on ti/evm/Makefile
+#
+# Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).a
+
+C

[U-Boot] [PATCH-V2 2/4] omap3: Consolidate SDRC related operations

2010-04-23 Thread hvaibhav
From: Vaibhav Hiremath 

Consolidated SDRC related functions into one file - sdrc.c

And also replaced sdrc_init with generic memory init
function (mem_init), this generalization of omap memory setup
is necessary to support the new emif4 interface introduced in AM3517.

Signed-off-by: Vaibhav Hiremath 
Signed-off-by: Sanjeev Premi 
---
 arch/arm/cpu/arm_cortexa8/omap3/Makefile|3 +
 arch/arm/cpu/arm_cortexa8/omap3/board.c |   35 +-
 arch/arm/cpu/arm_cortexa8/omap3/mem.c   |   90 
 arch/arm/cpu/arm_cortexa8/omap3/sdrc.c  |  202 +++
 arch/arm/cpu/arm_cortexa8/omap3/sys_info.c  |   41 --
 arch/arm/include/asm/arch-omap3/cpu.h   |3 +
 arch/arm/include/asm/arch-omap3/mem.h   |   13 ++
 arch/arm/include/asm/arch-omap3/sys_proto.h |4 +-
 include/configs/devkit8000.h|2 +
 include/configs/omap3_beagle.h  |2 +
 include/configs/omap3_evm.h |2 +
 include/configs/omap3_overo.h   |2 +
 include/configs/omap3_pandora.h |2 +
 include/configs/omap3_sdp3430.h |2 +
 include/configs/omap3_zoom1.h   |2 +
 include/configs/omap3_zoom2.h   |2 +
 16 files changed, 240 insertions(+), 167 deletions(-)
 create mode 100644 arch/arm/cpu/arm_cortexa8/omap3/sdrc.c

diff --git a/arch/arm/cpu/arm_cortexa8/omap3/Makefile 
b/arch/arm/cpu/arm_cortexa8/omap3/Makefile
index 136b163..8cc7802 100644
--- a/arch/arm/cpu/arm_cortexa8/omap3/Makefile
+++ b/arch/arm/cpu/arm_cortexa8/omap3/Makefile
@@ -33,6 +33,9 @@ COBJS += board.o
 COBJS  += clock.o
 COBJS  += gpio.o
 COBJS  += mem.o
+ifdef  CONFIG_SDRC
+COBJS  += sdrc.o
+endif
 COBJS  += syslib.o
 COBJS  += sys_info.o
 COBJS  += timer.o
diff --git a/arch/arm/cpu/arm_cortexa8/omap3/board.c 
b/arch/arm/cpu/arm_cortexa8/omap3/board.c
index 69a08fd..d2500ca 100644
--- a/arch/arm/cpu/arm_cortexa8/omap3/board.c
+++ b/arch/arm/cpu/arm_cortexa8/omap3/board.c
@@ -40,8 +40,6 @@

 extern omap3_sysinfo sysinfo;

-extern u32 is_mem_sdr(void);
-
 /**
  * Routine: delay
  * Description: spinning delay to use before udelay works
@@ -233,7 +231,7 @@ void s_init(void)
per_clocks_enable();

if (!in_sdram)
-   sdrc_init();
+   mem_init();
 }

 /**
@@ -274,37 +272,6 @@ void watchdog_init(void)
 }

 /**
- * Routine: dram_init
- * Description: sets uboots idea of sdram size
- */
-int dram_init(void)
-{
-   DECLARE_GLOBAL_DATA_PTR;
-   unsigned int size0 = 0, size1 = 0;
-
-   size0 = get_sdr_cs_size(CS0);
-
-   /*
-* If a second bank of DDR is attached to CS1 this is
-* where it can be started.  Early init code will init
-* memory on CS0.
-*/
-   if ((sysinfo.mtype == DDR_COMBO) || (sysinfo.mtype == DDR_STACKED)) {
-   do_sdrc_init(CS1, NOT_EARLY);
-   make_cs1_contiguous();
-
-   size1 = get_sdr_cs_size(CS1);
-   }
-
-   gd->bd->bi_dram[0].start = PHYS_SDRAM_1;
-   gd->bd->bi_dram[0].size = size0;
-   gd->bd->bi_dram[1].start = PHYS_SDRAM_1 + get_sdr_cs_offset(CS1);
-   gd->bd->bi_dram[1].size = size1;
-
-   return 0;
-}
-
-/**
  * Dummy function to handle errors for EABI incompatibility
  */
 void abort(void)
diff --git a/arch/arm/cpu/arm_cortexa8/omap3/mem.c 
b/arch/arm/cpu/arm_cortexa8/omap3/mem.c
index dfb7e4c..bd914b0 100644
--- a/arch/arm/cpu/arm_cortexa8/omap3/mem.c
+++ b/arch/arm/cpu/arm_cortexa8/omap3/mem.c
@@ -79,26 +79,6 @@ static const u32 gpmc_onenand[GPMC_MAX_REG] = {

 #endif

-static struct sdrc *sdrc_base = (struct sdrc *)OMAP34XX_SDRC_BASE;
-
-/**
- * make_cs1_contiguous() - for es2 and above remap cs1 behind cs0 to allow
- *  command line mem=xyz use all memory with out discontinuous support
- *  compiled in.  Could do it at the ATAG, but there really is two banks...
- * Called as part of 2nd phase DDR init.
- **/
-void make_cs1_contiguous(void)
-{
-   u32 size, a_add_low, a_add_high;
-
-   size = get_sdr_cs_size(CS0);
-   size >>= 25;/* divide by 32 MiB to find size to offset CS1 */
-   a_add_high = (size & 3) << 8;   /* set up low field */
-   a_add_low = (size & 0x3C) >> 2; /* set up high field */
-   writel((a_add_high | a_add_low), &sdrc_base->cs_cfg);
-
-}
-
 /
  *  me

[U-Boot] [PATCH-V2 4/4] AM35x: Add support for EMIF4

2010-04-23 Thread hvaibhav
From: Vaibhav Hiremath 

This patch adds support for the EMIF4 interface
available in the AM35x processors.

Signed-off-by: Vaibhav Hiremath 
Signed-off-by: Sanjeev Premi 
---
 arch/arm/cpu/arm_cortexa8/omap3/Makefile|3 +
 arch/arm/cpu/arm_cortexa8/omap3/emif4.c |  168 +++
 arch/arm/include/asm/arch-omap3/cpu.h   |   24 
 arch/arm/include/asm/arch-omap3/emif4.h |   79 +
 arch/arm/include/asm/arch-omap3/sys_proto.h |3 +
 5 files changed, 277 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/cpu/arm_cortexa8/omap3/emif4.c
 create mode 100644 arch/arm/include/asm/arch-omap3/emif4.h

diff --git a/arch/arm/cpu/arm_cortexa8/omap3/Makefile 
b/arch/arm/cpu/arm_cortexa8/omap3/Makefile
index 8cc7802..0a23fa5 100644
--- a/arch/arm/cpu/arm_cortexa8/omap3/Makefile
+++ b/arch/arm/cpu/arm_cortexa8/omap3/Makefile
@@ -36,6 +36,9 @@ COBJS += mem.o
 ifdef  CONFIG_SDRC
 COBJS  += sdrc.o
 endif
+ifdef  CONFIG_EMIF4
+COBJS  += emif4.o
+endif
 COBJS  += syslib.o
 COBJS  += sys_info.o
 COBJS  += timer.o
diff --git a/arch/arm/cpu/arm_cortexa8/omap3/emif4.c 
b/arch/arm/cpu/arm_cortexa8/omap3/emif4.c
new file mode 100644
index 000..749a394
--- /dev/null
+++ b/arch/arm/cpu/arm_cortexa8/omap3/emif4.c
@@ -0,0 +1,168 @@
+/*
+ * Author :
+ * Vaibhav Hiremath 
+ *
+ * Based on mem.c and sdrc.c
+ *
+ * Copyright (C) 2010
+ * Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+extern omap3_sysinfo sysinfo;
+
+static emif4_t *emif4_base = (emif4_t *)OMAP34XX_SDRC_BASE;
+
+/*
+ * is_mem_sdr -
+ *  - Return 1 if mem type in use is SDR
+ */
+u32 is_mem_sdr(void)
+{
+   return 0;
+}
+
+/*
+ * get_sdr_cs_size -
+ *  - Get size of chip select 0/1
+ */
+u32 get_sdr_cs_size(u32 cs)
+{
+   u32 size;
+
+   /* TODO: Calculate the size based on EMIF4 configuration */
+   size = CONFIG_SYS_CS0_SIZE;
+
+   return size;
+}
+
+/*
+ * get_sdr_cs_offset -
+ *  - Get offset of cs from cs0 start
+ */
+u32 get_sdr_cs_offset(u32 cs)
+{
+   u32 offset = 0;
+
+   return offset;
+}
+
+/*
+ * do_emif4_init -
+ *  - Init the emif4 module for DDR access
+ *  - Early init routines, called from flash or SRAM.
+ */
+void do_emif4_init(void)
+{
+   unsigned int regval;
+   /* Set the DDR PHY parameters in PHY ctrl registers */
+   regval = (EMIF4_DDR1_READ_LAT | EMIF4_DDR1_PWRDN_DIS |
+   EMIF4_DDR1_EXT_STRB_DIS);
+   writel(regval, &emif4_base->ddr_phyctrl1);
+   writel(regval, &emif4_base->ddr_phyctrl1_shdw);
+   writel(0, &emif4_base->ddr_phyctrl2);
+
+   /* Reset the DDR PHY and wait till completed */
+   regval = readl(&emif4_base->sdram_iodft_tlgc);
+   regval |= (1<<10);
+   writel(regval, &emif4_base->sdram_iodft_tlgc);
+   /*Wait till that bit clears*/
+   while ((readl(&emif4_base->sdram_iodft_tlgc) & (1<<10)) == 0x1);
+   /*Re-verify the DDR PHY status*/
+   while ((readl(&emif4_base->sdram_sts) & (1<<2)) == 0x0);
+
+   regval |= (1<<0);
+   writel(regval, &emif4_base->sdram_iodft_tlgc);
+   /* Set SDR timing registers */
+   regval = (EMIF4_TIM1_T_WTR | EMIF4_TIM1_T_RRD |
+   EMIF4_TIM1_T_RC | EMIF4_TIM1_T_RAS |
+   EMIF4_TIM1_T_WR | EMIF4_TIM1_T_RCD |
+   EMIF4_TIM1_T_RP);
+   writel(regval, &emif4_base->sdram_time1);
+   writel(regval, &emif4_base->sdram_time1_shdw);
+
+   regval = (EMIF4_TIM2_T_CKE | EMIF4_TIM2_T_RTP |
+   EMIF4_TIM2_T_XSRD | EMIF4_TIM2_T_XSNR |
+   EMIF4_TIM2_T_ODT | EMIF4_TIM2_T_XP);
+   writel(regval, &emif4_base->sdram_time2);
+   writel(regval, &emif4_base->sdram_time2_shdw);
+
+   regval = (EMIF4_TIM3_T_RAS_MAX | EMIF4_TIM3_T_RFC);
+   writel(regval, &emif4_base->sdram_time3);
+   writel(regval, &emif4_base->sdram_time3_shdw);
+
+   /* Set the PWR control register */
+   regval = (EMIF4_PWR_PM_TIM | EMIF4_PWR_LP_MODE |
+   EMIF4_PWR_DPD_DIS | EMIF4_PWR_IDLE_MODE);
+   writel(regval, &emif4_base->sdram_pwr_mgmt);
+   writel(regval, &emif4_base->sdram_pwr_mgmt_shdw);
+
+   /* Set the DDR refresh rate control register */
+   regval = (EMIF4_R

[U-Boot] [RESEND:PATCH-V4] OMAP3EVM: Added NAND support

2010-04-23 Thread hvaibhav
From: Vaibhav Hiremath 

The EVMS have been shipping with NAND (instead of OneNAND) as default.
So, this patch sets NAND as default.

To choose OneNAND, define CMD_ONENAND instead of CMD_NAND in the
config file omap3_evm.h,

Changes from V3 :-
- Added undef statement for CMD_ONENAND.

Signed-off-by: Vaibhav Hiremath 
---
 include/configs/omap3_evm.h |9 -
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h
index 0d99f7d..1d31731 100644
--- a/include/configs/omap3_evm.h
+++ b/include/configs/omap3_evm.h
@@ -151,7 +151,8 @@

 #define CONFIG_CMD_I2C /* I2C serial bus support   */
 #define CONFIG_CMD_MMC /* MMC support  */
-#define CONFIG_CMD_ONENAND /* ONENAND support  */
+#undef CONFIG_CMD_ONENAND  /* ONENAND support  */
+#define CONFIG_CMD_NAND/* NAND support */
 #define CONFIG_CMD_DHCP
 #define CONFIG_CMD_PING

@@ -306,7 +307,13 @@
 #define CONFIG_SYS_MONITOR_BASECONFIG_SYS_FLASH_BASE
 #define CONFIG_SYS_ONENAND_BASEONENAND_MAP

+#if defined(CONFIG_CMD_NAND)
+#define CONFIG_NAND_OMAP_GPMC
+#define GPMC_NAND_ECC_LP_x16_LAYOUT1
+#define CONFIG_ENV_IS_IN_NAND
+#elif defined(CONFIG_CMD_ONENAND)
 #define CONFIG_ENV_IS_IN_ONENAND   1
+#endif
 #define ONENAND_ENV_OFFSET 0x26 /* environment starts here */
 #define SMNAND_ENV_OFFSET  0x26 /* environment starts here */

--
1.6.2.4

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


[U-Boot] [PATCH-V2 1/4] omap3: Calculate CS1 size only when SDRC is initialized for CS1

2010-04-23 Thread hvaibhav
From: Vaibhav Hiremath 

The patch makes sure that size for SDRC CS1 gets calculated
only when the CS1 SDRC is initialized.

Signed-off-by: Vaibhav Hiremath 
Signed-off-by: Sanjeev Premi 
---
 arch/arm/cpu/arm_cortexa8/omap3/board.c |7 ---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm/cpu/arm_cortexa8/omap3/board.c 
b/arch/arm/cpu/arm_cortexa8/omap3/board.c
index 7b78fa4..69a08fd 100644
--- a/arch/arm/cpu/arm_cortexa8/omap3/board.c
+++ b/arch/arm/cpu/arm_cortexa8/omap3/board.c
@@ -282,6 +282,8 @@ int dram_init(void)
DECLARE_GLOBAL_DATA_PTR;
unsigned int size0 = 0, size1 = 0;

+   size0 = get_sdr_cs_size(CS0);
+
/*
 * If a second bank of DDR is attached to CS1 this is
 * where it can be started.  Early init code will init
@@ -290,10 +292,9 @@ int dram_init(void)
if ((sysinfo.mtype == DDR_COMBO) || (sysinfo.mtype == DDR_STACKED)) {
do_sdrc_init(CS1, NOT_EARLY);
make_cs1_contiguous();
-   }

-   size0 = get_sdr_cs_size(CS0);
-   size1 = get_sdr_cs_size(CS1);
+   size1 = get_sdr_cs_size(CS1);
+   }

gd->bd->bi_dram[0].start = PHYS_SDRAM_1;
gd->bd->bi_dram[0].size = size0;
--
1.6.2.4

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


[U-Boot] [PATCH-V2 0/4] Add Support for AM3517EVM with EMIF4

2010-04-23 Thread hvaibhav
From: Vaibhav Hiremath 

Changes from V1 (comments provided by Tom Rix):
- Refreshed against latest denx/master.
- Further split SDRC consolidated patch, since it was
  fixing up one issue in dram_init in addition to code
  moment.
- Retained copyright for sdrc.c file, since it is
  barely a code moment.

AM3517 device is high-performance, industrial applications
processor designed and developed keeping Software Compatible
with OMAP3 Processors.

Differances :-
===
- The SDRC controller has been replaced with EMIF4.
- Some new IP's got added like, CAN, VPFE, etc...
- Removed ISP completely

This patch series adds support for AM3517EVM along with EMIF4 configuration.

Tested :-
===
- OMAP3 EVM (both NAND and MMC boot mode)
- AM3517 EVM (both NAND and MMC boot mode)

Build tested on all OMAP3 platforms.

Below are some of the useful links :-
===
AM3517 device is high-performance, industrial applications processor designed
and developed keeping Software Compatible with OMAP3 Processors.

Below are some of the useful links -

Migration from OMAP35x to AM35x :-
http://focus.ti.com/lit/an/sprab91/sprab91.pdf

Specs/TRM :-
http://focus.ti.com/docs/prod/folders/print/am3517.html

EVM Link -:
http://www.logicpd.com/products/development-kits/zoom-am3517-experimenter-kit


Vaibhav Hiremath (4):
  omap3: Calculate CS1 size only when SDRC is initialized for CS1
  omap3: Consolidate SDRC related operations
  AM35x: Add support for AM3517EVM
  AM35x: Add support for EMIF4

 Makefile|3 +
 arch/arm/cpu/arm_cortexa8/omap3/Makefile|6 +
 arch/arm/cpu/arm_cortexa8/omap3/board.c |   34 +---
 arch/arm/cpu/arm_cortexa8/omap3/emif4.c |  168 +++
 arch/arm/cpu/arm_cortexa8/omap3/mem.c   |   90 --
 arch/arm/cpu/arm_cortexa8/omap3/sdrc.c  |  202 +
 arch/arm/cpu/arm_cortexa8/omap3/sys_info.c  |   41 ---
 arch/arm/include/asm/arch-omap3/cpu.h   |   27 ++
 arch/arm/include/asm/arch-omap3/emif4.h |   79 ++
 arch/arm/include/asm/arch-omap3/mem.h   |   13 +
 arch/arm/include/asm/arch-omap3/mux.h   |   36 +++
 arch/arm/include/asm/arch-omap3/sys_proto.h |7 +-
 board/logicpd/am3517evm/Makefile|   47 +++
 board/logicpd/am3517evm/am3517evm.c |   76 +
 board/logicpd/am3517evm/am3517evm.h |  405 +++
 board/logicpd/am3517evm/config.mk   |   30 ++
 include/configs/am3517_evm.h|  297 
 include/configs/devkit8000.h|2 +
 include/configs/omap3_beagle.h  |2 +
 include/configs/omap3_evm.h |2 +
 include/configs/omap3_overo.h   |2 +
 include/configs/omap3_pandora.h |2 +
 include/configs/omap3_sdp3430.h |2 +
 include/configs/omap3_zoom1.h   |2 +
 include/configs/omap3_zoom2.h   |2 +
 25 files changed, 1411 insertions(+), 166 deletions(-)
 create mode 100644 arch/arm/cpu/arm_cortexa8/omap3/emif4.c
 create mode 100644 arch/arm/cpu/arm_cortexa8/omap3/sdrc.c
 create mode 100644 arch/arm/include/asm/arch-omap3/emif4.h
 create mode 100644 board/logicpd/am3517evm/Makefile
 create mode 100644 board/logicpd/am3517evm/am3517evm.c
 create mode 100644 board/logicpd/am3517evm/am3517evm.h
 create mode 100644 board/logicpd/am3517evm/config.mk
 create mode 100644 include/configs/am3517_evm.h

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


Re: [U-Boot] bf537-stamp board compilation problem

2010-04-23 Thread Mike Frysinger
On Friday 23 April 2010 10:10:16 Michael Zaidman wrote:
> Compiling the bf537-stamp board I got the following linker error:
> /home/mike/develop/u-boot/u-boot-patch/common/cmd_mmc.c:53: undefined
> reference to `mmc_legacy_init'
> /home/mike/develop/u-boot/u-boot-patch/common/cmd_mmc.c:53: relocation
> truncated to fit: R_pcrel24 against undefined symbol `mmc_legacy_init'
> disk/libdisk.a(part.o):(.rodata.block_drvr+0x4): undefined reference
> to `mmc_get_dev'
> make: *** [u-boot] Error 1

remove CONFIG_{MMC,SPI_MMC} from the bf537-stamp.h config header
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] mmc: new legacy MMC/SPI driver

2010-04-23 Thread Mike Frysinger
On Friday 23 April 2010 04:20:34 Wolfgang Wegner wrote:
> On Thu, Apr 22, 2010 at 11:28:27PM -0400, Mike Frysinger wrote:
> > +static short mmc_spi_init_card(struct mmc_spi_dev *pdev)
> > +{
> > +   unsigned short cntr = 0;
> > +
> > +   /* for making init process beeing silent */
> > +   init_mode = 1;
> > +   /* save length of log for external usage */
> > +   pdev->log_len = LOG_LEN;
> > +
> > +   /* 10 bytes(80 cycles) with CS de-asserted */
> > +   mmc_spi_dummy_clocks(pdev, 10);
> > +   pdev->doassert();
> > +   if (send_cmd_and_wait(pdev, GO_IDLE_STATE, 0, R1_IDLE_STATE,
> > MMC_INIT_TIMEOUT)) +return 1;
> > +   pdev->deassert();
> > +   /* Send One Byte Delay */
> > +   if (pdev->write(Null_Word, 1, pdev->priv_data) < 0)
> > +   return 1;
> > +   pdev->doassert();
> 
> [...]
> 
> Is there any reason to use doassert() and deassert() except to generate
> the "dummy" cycles needed to initialize the card? Which driver does
> _need_ an explicit cs_activate() and cs_deactivate() outside the
> write() and read() functions?

i have no idea.  i didnt write the driver.
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] Facing problems in Porting U-boot to MIPS32 (Au1350)

2010-04-23 Thread Andrew Dyer
2010/4/23 Gurumurthy G M :
>
>
> let me know if anyone have ported u-boot to MIPS32.

I did a couple of ports for Au1550 boards back when it was still owned by AMD.

On Au1550 if the boot pins are set up for NOR flash, the CS0 line is
mapped with a base physical address 0x0_1fc0_ (36 bit physical
address) and a chip select mask of 0xf_fffc_ (range of 256K).
Without using the TLB (ie staying in KSEG1 virtual range), the top
physical address you can select is 0x0_1fff_, so this is
effectively 4Mb down from the top of memory at boot time.

In lowlevel_init.S the base and range of the chip select can get
adjusted so that more of the flash is accessible by adjusting the base
address and mask.  As an example we had a board that adjusted to the
registers for a larger NOR mapped at 0x0_1f00_ with a size of
0x0_0100_.  Look in the dbau1550 port for more info.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v3 01/26] [x86] Add unaligned.h

2010-04-23 Thread Graeme Russ
Signed-off-by: Graeme Russ 
---
 arch/i386/include/asm/unaligned.h |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 arch/i386/include/asm/unaligned.h

diff --git a/arch/i386/include/asm/unaligned.h 
b/arch/i386/include/asm/unaligned.h
new file mode 100644
index 000..6cecbbb
--- /dev/null
+++ b/arch/i386/include/asm/unaligned.h
@@ -0,0 +1 @@
+#include 
-- 
1.7.1.rc1.12.ga601

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


[U-Boot] [PATCH v3 04/26] [x86] Add register dump to crash handlers

2010-04-23 Thread Graeme Russ
Shamelessly steal the Linux x86 crash handling code and shove it into
U-Boot (cool - it fits). Be sure to include suitable attribution to
Linus

Signed-off-by: Graeme Russ 
---
 arch/i386/cpu/interrupts.c |  310 
 1 files changed, 228 insertions(+), 82 deletions(-)

diff --git a/arch/i386/cpu/interrupts.c b/arch/i386/cpu/interrupts.c
index 4b57437..2eae5be 100644
--- a/arch/i386/cpu/interrupts.c
+++ b/arch/i386/cpu/interrupts.c
@@ -5,6 +5,9 @@
  * (C) Copyright 2002
  * Daniel Engström, Omicron Ceti AB, dan...@omicron.se.
  *
+ * Portions of this file are derived from the Linux kernel source
+ *  Copyright (C) 1991, 1992  Linus Torvalds
+ *
  * See file CREDITS for list of people who contributed to this
  * project.
  *
@@ -32,12 +35,112 @@
".hidden irq_"#x"\n" \
".type irq_"#x", @function\n" \
"irq_"#x":\n" \
-   "pushl %ebp\n" \
-   "movl %esp,%ebp\n" \
-   "pusha\n" \
"pushl $"#x"\n" \
"jmp irq_common_entry\n"
 
+/*
+ * Volatile isn't enough to prevent the compiler from reordering the
+ * read/write functions for the control registers and messing everything up.
+ * A memory clobber would solve the problem, but would prevent reordering of
+ * all loads stores around it, which can hurt performance. Solution is to
+ * use a variable and mimic reads and writes to it to enforce serialization
+ */
+static unsigned long __force_order;
+
+static inline unsigned long read_cr0(void)
+{
+   unsigned long val;
+   asm volatile("mov %%cr0,%0\n\t" : "=r" (val), "=m" (__force_order));
+   return val;
+}
+
+static inline unsigned long read_cr2(void)
+{
+   unsigned long val;
+   asm volatile("mov %%cr2,%0\n\t" : "=r" (val), "=m" (__force_order));
+   return val;
+}
+
+static inline unsigned long read_cr3(void)
+{
+   unsigned long val;
+   asm volatile("mov %%cr3,%0\n\t" : "=r" (val), "=m" (__force_order));
+   return val;
+}
+
+static inline unsigned long read_cr4(void)
+{
+   unsigned long val;
+   asm volatile("mov %%cr4,%0\n\t" : "=r" (val), "=m" (__force_order));
+   return val;
+}
+
+static inline unsigned long get_debugreg(int regno)
+{
+   unsigned long val = 0;  /* Damn you, gcc! */
+
+   switch (regno) {
+   case 0:
+   asm("mov %%db0, %0" :"=r" (val));
+   break;
+   case 1:
+   asm("mov %%db1, %0" :"=r" (val));
+   break;
+   case 2:
+   asm("mov %%db2, %0" :"=r" (val));
+   break;
+   case 3:
+   asm("mov %%db3, %0" :"=r" (val));
+   break;
+   case 6:
+   asm("mov %%db6, %0" :"=r" (val));
+   break;
+   case 7:
+   asm("mov %%db7, %0" :"=r" (val));
+   break;
+   default:
+   val = 0;
+   }
+   return val;
+}
+
+void dump_regs(struct pt_regs *regs)
+{
+   unsigned long cr0 = 0L, cr2 = 0L, cr3 = 0L, cr4 = 0L;
+   unsigned long d0, d1, d2, d3, d6, d7;
+
+   printf("EIP: %04x:[<%08lx>] EFLAGS: %08lx\n",
+   (u16)regs->xcs, regs->eip, regs->eflags);
+
+   printf("EAX: %08lx EBX: %08lx ECX: %08lx EDX: %08lx\n",
+   regs->eax, regs->ebx, regs->ecx, regs->edx);
+   printf("ESI: %08lx EDI: %08lx EBP: %08lx ESP: %08lx\n",
+   regs->esi, regs->edi, regs->ebp, regs->esp);
+   printf(" DS: %04x ES: %04x FS: %04x GS: %04x SS: %04x\n",
+  (u16)regs->xds, (u16)regs->xes, (u16)regs->xfs, (u16)regs->xgs, 
(u16)regs->xss);
+
+   cr0 = read_cr0();
+   cr2 = read_cr2();
+   cr3 = read_cr3();
+   cr4 = read_cr4();
+
+   printf("CR0: %08lx CR2: %08lx CR3: %08lx CR4: %08lx\n",
+   cr0, cr2, cr3, cr4);
+
+   d0 = get_debugreg(0);
+   d1 = get_debugreg(1);
+   d2 = get_debugreg(2);
+   d3 = get_debugreg(3);
+
+   printf("DR0: %08lx DR1: %08lx DR2: %08lx DR3: %08lx\n",
+   d0, d1, d2, d3);
+
+   d6 = get_debugreg(6);
+   d7 = get_debugreg(7);
+   printf("DR6: %08lx DR7: %08lx\n",
+   d6, d7);
+}
+
 struct idt_entry {
u16 base_low;
u16 selector;
@@ -122,7 +225,7 @@ int disable_interrupts(void)
 }
 
 /* IRQ Low-Level Service Routine */
-__isr__ irq_llsr(int ip, int seg, int irq)
+__isr__ irq_llsr(struct pt_regs *regs)
 {
/*
 * For detailed description of each exception, refer to:
@@ -131,74 +234,93 @@ __isr__ irq_llsr(int ip, int seg, int irq)
 * Order Number: 253665-029US, November 2008
 * Table 6-1. Exceptions and Interrupts
 */
-   switch (irq) {
-   case 0x00:
-   printf("Divide Error (Division by zero) at %04x:%08x\n", seg, 
ip);
-   while(1);
-   break;
-   case 0x01:
-   printf("Debug Interrupt (Single step) at %04x:%08x\n", seg, ip);
-   break;
-   case 0x02:
- 

[U-Boot] [PATCH v3 06/26] [x86] Fix sc520 memory size reporting

2010-04-23 Thread Graeme Russ
There is an error in how the assembler version of the sc520 memory size
reporting code works. As a result, it will only ever report at most the
size of one bank of RAM

Signed-off-by: Graeme Russ 
---
 arch/i386/cpu/sc520/sc520_asm.S |   35 +--
 1 files changed, 17 insertions(+), 18 deletions(-)

diff --git a/arch/i386/cpu/sc520/sc520_asm.S b/arch/i386/cpu/sc520/sc520_asm.S
index 2042d9b..135f7b4 100644
--- a/arch/i386/cpu/sc520/sc520_asm.S
+++ b/arch/i386/cpu/sc520/sc520_asm.S
@@ -503,38 +503,37 @@ dram_done:
 
movl$DRCBENDADR, %edi/* DRAM ending address register  */
 
-   movl(%edi), %eax
-   movl%eax, %ecx
-   andl$0x8000, %ecx
-   jz  bank2
-   andl$0x7f00, %eax
-   shrl$2, %eax
-   movl%eax, %ebx
-
-bank2: movl(%edi), %eax
+bank0: movl(%edi), %eax
movl%eax, %ecx
-   andl$0x0080, %ecx
+   andl$0x0080, %ecx
jz  bank1
-   andl$0x007f, %eax
-   shll$6, %eax
+   andl$0x007f, %eax
+   shll$22, %eax
movl%eax, %ebx
 
 bank1: movl(%edi), %eax
movl%eax, %ecx
andl$0x8000, %ecx
-   jz  bank0
+   jz  bank2
andl$0x7f00, %eax
shll$14, %eax
movl%eax, %ebx
 
-bank0: movl(%edi), %eax
+bank2: movl(%edi), %eax
movl%eax, %ecx
-   andl$0x0080, %ecx
-   jz  done
-   andl$0x007f, %eax
-   shll$22, %eax
+   andl$0x0080, %ecx
+   jz  bank3
+   andl$0x007f, %eax
+   shll$6, %eax
movl%eax, %ebx
 
+bank3: movl(%edi), %eax
+   movl%eax, %ecx
+   andl$0x8000, %ecx
+   jz  done
+   andl$0x7f00, %eax
+   shrl$2, %eax
+   movl%eax, %ebx
 
 done:
movl%ebx, %eax
-- 
1.7.1.rc1.12.ga601

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


[U-Boot] bf537-stamp board compilation problem

2010-04-23 Thread Michael Zaidman
Hi,
Compiling the bf537-stamp board I got the following linker error:
/home/mike/develop/u-boot/u-boot-patch/common/cmd_mmc.c:53: undefined
reference to `mmc_legacy_init'
/home/mike/develop/u-boot/u-boot-patch/common/cmd_mmc.c:53: relocation
truncated to fit: R_pcrel24 against undefined symbol `mmc_legacy_init'
disk/libdisk.a(part.o):(.rodata.block_drvr+0x4): undefined reference
to `mmc_get_dev'
make: *** [u-boot] Error 1

While another blackfin board bf548-ezkit passes the compilation. The
only difference that makes sense to me is CONFIG_GENERIC_MMC that
presents in the bf548-ezkit.h and absents in the bf537-stamp.h

I am trying to cleanup POST issues and have no idea what MMC config
should be in blackfin particular board.
Am I observing a real problem or just missing something?

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


[U-Boot] [PATCH v3 26/26] [sc520] Fix minor DRAM Controller Setup bug

2010-04-23 Thread Graeme Russ
Signed-off-by: Graeme Russ 
---
 arch/i386/cpu/sc520/sc520_asm.S |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/i386/cpu/sc520/sc520_asm.S b/arch/i386/cpu/sc520/sc520_asm.S
index 3407254..c8f74b3 100644
--- a/arch/i386/cpu/sc520/sc520_asm.S
+++ b/arch/i386/cpu/sc520/sc520_asm.S
@@ -500,7 +500,7 @@ emptybank:
/* just have your hardware desinger _GIVE_ you what you need here! */
movl$DRCTMCTL, %edi
movb$CONFIG_SYS_SDRAM_DRCTMCTL,%al
-   movb(%edi), %al
+   movb%al, (%edi)
 #else
 #if defined(CONFIG_SYS_SDRAM_CAS_LATENCY_2T) || 
defined(CONFIG_SYS_SDRAM_CAS_LATENCY_3T)
/* set the CAS latency now since it is hard to do
-- 
1.7.1.rc1.12.ga601

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


[U-Boot] [PATCH v3 25/26] [sc520] Update to new AMD Copyright

2010-04-23 Thread Graeme Russ
AMD recently changed the licensing of the RAM sizing code to the
GPLv2 (or at you option any later version)

Signed-off-by: Graeme Russ 
---
 arch/i386/cpu/sc520/sc520_asm.S |  117 +-
 1 files changed, 77 insertions(+), 40 deletions(-)

diff --git a/arch/i386/cpu/sc520/sc520_asm.S b/arch/i386/cpu/sc520/sc520_asm.S
index c745454..3407254 100644
--- a/arch/i386/cpu/sc520/sc520_asm.S
+++ b/arch/i386/cpu/sc520/sc520_asm.S
@@ -25,48 +25,85 @@
  * copyright is included below
  */
 
-/*
- *  
=
- *
- *   Copyright 1999 Advanced Micro Devices, Inc.
- *
- *  This software is the property of Advanced Micro Devices, Inc  (AMD)  which
- *  specifically grants the user the right to modify, use and distribute this
- *  software provided this COPYRIGHT NOTICE is not removed or altered.  All
- *  other rights are reserved by AMD.
- *
- *  THE MATERIALS ARE PROVIDED "AS IS" WITHOUT ANY EXPRESS OR IMPLIED WARRANTY
- *  OF ANY KIND INCLUDING WARRANTIES OF MERCHANTABILITY, NONINFRINGEMENT OF
- *  THIRD-PARTY INTELLECTUAL PROPERTY, OR FITNESS FOR ANY PARTICULAR PURPOSE.
- *  IN NO EVENT SHALL AMD OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER
- *  (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS, BUSINESS
- *  INTERRUPTION, LOSS OF INFORMAITON) ARISING OUT OF THE USE OF OR INABILITY
- *  TO USE THE MATERIALS, EVEN IF AMD HAS BEEN ADVISED OF THE POSSIBILITY OF
- *  SUCH DAMAGES.  BECAUSE SOME JURSIDICTIONS PROHIBIT THE EXCLUSION OR
- *  LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES, THE ABOVE
- *  LIMITATION MAY NOT APPLY TO YOU.
- *
- *  AMD does not assume any responsibility for any errors that may appear in
- *  the Materials nor any responsibility to support or update the Materials.
- *  AMD retains the right to make changes to its test specifications at any
- *  time, without notice.
- *
- *  So that all may benefit from your experience, please report  any  problems
- *  or suggestions about this software back to AMD.  Please include your name,
- *  company,  telephone number,  AMD product requiring support and question or
- *  problem encountered.
- *
- *  Advanced Micro Devices, Inc. Worldwide support and contact
- *  Embedded Processor Divisioninformation available at:
- *  Systems Engineering   epd.supp...@amd.com
- *  5204 E. Ben White Blvd.  -or-
- *  Austin, TX 78741
http://www.amd.com/html/support/techsup.html
- *  

+/* TITLE   SIZER - Aspen DRAM Sizing Routine.
+ * 
=
+ *
+ *  Copyright 1999 Advanced Micro Devices, Inc.
+ * You may redistribute this program and/or modify this program under the terms
+ * of the GNU General Public License as published by the Free Software 
Foundation;
+ * either version 2 of the License, or (at your option) any later version.
+ *
+ *  This program is distributed WITHOUT ANY WARRANTY; WITHOUT EVEN THE IMPLIED
+ * WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; if not, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *
+ * THE MATERIALS ARE PROVIDED "AS IS" WITHOUT ANY EXPRESS OR IMPLIED WARRANTY
+ * OF ANY KIND INCLUDING WARRANTIES OF MERCHANTABILITY, NONINFRINGEMENT OF
+ * THIRD-PARTY INTELLECTUAL PROPERTY, OR FITNESS FOR ANY PARTICULAR PURPOSE.
+ * IN NO EVENT SHALL AMD OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER
+ * (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS, BUSINESS
+ * INTERRUPTION, LOSS OF INFORMATION) ARISING OUT OF THE USE OF OR INABILITY
+ * TO USE THE MATERIALS, EVEN IF AMD HAS BEEN ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGES.  BECAUSE SOME JURSIDICTIONS PROHIBIT THE EXCLUSION OR
+ * LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES, THE ABOVE
+ * LIMITATION MAY NOT APPLY TO YOU.
+ *
+ * AMD does not assume any responsibility for any errors that may appear in
+ * the Materials nor any responsibility to support or update the Materials.
+ * AMD retains the right to make changes to its test specifications at any
+ * time, without notice.
+ * 
==
  */
 
-
-/***
- *  AUTHOR  : Buddy Fey - Original.
+/*
+ **
+ *
+ *  FILE: sizer.asm - SDRAM DIMM Sizing Algorithm
+ *
+ *
+ *
+ *  FUNCTIONS   : sizemem() - jumped to, not called.  To be executed after
+ *reset to deter

[U-Boot] [PATCH v3 24/26] Implement eNET Watchdog

2010-04-23 Thread Graeme Russ
Signed-off-by: Graeme Russ 
---
 board/eNET/eNET.c  |   46 ++
 board/eNET/hardware.h  |1 +
 include/configs/eNET.h |   10 +-
 3 files changed, 48 insertions(+), 9 deletions(-)

diff --git a/board/eNET/eNET.c b/board/eNET/eNET.c
index ad71f7e..56e1a22 100644
--- a/board/eNET/eNET.c
+++ b/board/eNET/eNET.c
@@ -45,6 +45,9 @@ DECLARE_GLOBAL_DATA_PTR;
 
 unsigned long monitor_flash_len = CONFIG_SYS_MONITOR_LEN;
 
+static void enet_timer_isr(void);
+static void enet_toggle_run_led(void);
+
 void init_sc520_enet (void)
 {
/* Set CPU Speed to 100MHz */
@@ -160,6 +163,10 @@ int last_stage_init(void)
 
major = minor = 0;
 
+   outb(0x00, LED_LATCH_ADDRESS);
+
+   register_timer_isr (enet_timer_isr);
+
printf("Serck Controls eNET\n");
 
return 0;
@@ -218,3 +225,42 @@ void setup_pcat_compatibility()
writeb(SC520_IRQ_DISABLED, &sc520_mmcr->wpvmap);
writeb(SC520_IRQ_DISABLED, &sc520_mmcr->icemap);
 }
+
+void enet_timer_isr(void)
+{
+   static long enet_ticks = 0;
+
+   enet_ticks++;
+
+   /* Toggle Watchdog every 100ms */
+   if ((enet_ticks % 100) == 0)
+   hw_watchdog_reset();
+
+   /* Toggle Run LED every 500ms */
+   if ((enet_ticks % 500) == 0)
+   enet_toggle_run_led();
+}
+
+void hw_watchdog_reset(void)
+{
+   /* Watchdog Reset must be atomic */
+   long flag = disable_interrupts();
+
+   if (sc520_mmcr->piodata15_0 & WATCHDOG_PIO_BIT)
+   sc520_mmcr->pioclr15_0 = WATCHDOG_PIO_BIT;
+   else
+   sc520_mmcr->pioset15_0 = WATCHDOG_PIO_BIT;
+
+   if (flag)
+   enable_interrupts();
+}
+
+void enet_toggle_run_led(void)
+{
+   unsigned char leds_state= inb(LED_LATCH_ADDRESS);
+   if (leds_state & LED_RUN_BITMASK)
+   outb(leds_state &~ LED_RUN_BITMASK, LED_LATCH_ADDRESS);
+   else
+   outb(leds_state | LED_RUN_BITMASK, LED_LATCH_ADDRESS);
+}
+
diff --git a/board/eNET/hardware.h b/board/eNET/hardware.h
index 42474a6..dec2cd8 100644
--- a/board/eNET/hardware.h
+++ b/board/eNET/hardware.h
@@ -31,5 +31,6 @@
 #define LED_RX_BITMASK 0x08
 #define LED_TX_BITMASK 0x10
 #define LED_ERR_BITMASK0x20
+#define WATCHDOG_PIO_BIT   0x8000
 
 #endif /* HARDWARE_H_ */
diff --git a/include/configs/eNET.h b/include/configs/eNET.h
index 6189794..361fe61 100644
--- a/include/configs/eNET.h
+++ b/include/configs/eNET.h
@@ -53,7 +53,7 @@
  * bottom (processor) board MUST be removed!
  */
 #undef CONFIG_WATCHDOG
-#undef CONFIG_HW_WATCHDOG
+#define CONFIG_HW_WATCHDOG
 
  /*---
   * Serial Configuration
@@ -234,14 +234,6 @@
 #define CONFIG_RTL8139
 
 /*---
- * Hardware watchdog configuration
- */
-#define CONFIG_SYS_WATCHDOG_PIO_BIT0x8000
-#define CONFIG_SYS_WATCHDIG_PIO_DATA   SC520_PIODATA15_0
-#define CONFIG_SYS_WATCHDIG_PIO_CLRSC520_PIOCLR15_0
-#define CONFIG_SYS_WATCHDIG_PIO_SETSC520_PIOSET15_0
-
-/*---
  * FPGA configuration
  */
 #define CONFIG_SYS_FPGA_PROGRAM_PIO_BIT0x2000
-- 
1.7.1.rc1.12.ga601

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


[U-Boot] [PATCH v3 23/26] Use SC520 MMCR to reset eNET board

2010-04-23 Thread Graeme Russ
Signed-off-by: Graeme Russ 
---
 include/configs/eNET.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/configs/eNET.h b/include/configs/eNET.h
index dac3ede..6189794 100644
--- a/include/configs/eNET.h
+++ b/include/configs/eNET.h
@@ -160,7 +160,7 @@
  * CPU Features
  */
 #define CONFIG_SYS_SC520_HIGH_SPEED0   /* 100 or 133MHz */
-#undef  CONFIG_SYS_SC520_RESET /* use SC520 MMCR's to reset 
cpu */
+#define CONFIG_SYS_SC520_RESET /* use SC520 MMCR's to reset 
cpu */
 #define CONFIG_SYS_SC520_TIMER /* use SC520 swtimers */
 #undef  CONFIG_SYS_GENERIC_TIMER   /* use the i8254 PIT timers */
 #undef  CONFIG_SYS_TSC_TIMER   /* use the Pentium TSC timers */
-- 
1.7.1.rc1.12.ga601

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


[U-Boot] [PATCH v3 22/26] [eNET] Add PC/AT compatibility setup function

2010-04-23 Thread Graeme Russ
The eNET uses the sc520 software timers rather than the PC/AT clones

Set all interrupts and timers up to be PC/AT compatible

Signed-off-by: Graeme Russ 
---
 board/eNET/eNET.c |   38 ++
 1 files changed, 38 insertions(+), 0 deletions(-)

diff --git a/board/eNET/eNET.c b/board/eNET/eNET.c
index 62f99ce..ad71f7e 100644
--- a/board/eNET/eNET.c
+++ b/board/eNET/eNET.c
@@ -180,3 +180,41 @@ int board_eth_init(bd_t *bis)
 {
return pci_eth_init(bis);
 }
+
+void setup_pcat_compatibility()
+{
+   /* disable global interrupt mode */
+   writeb(0x40, &sc520_mmcr->picicr);
+
+   /* set all irqs to edge */
+   writeb(0x00, &sc520_mmcr->pic_mode[0]);
+   writeb(0x00, &sc520_mmcr->pic_mode[1]);
+   writeb(0x00, &sc520_mmcr->pic_mode[2]);
+
+   /*
+*  active low polarity on PIC interrupt pins,
+*  active high polarity on all other irq pins
+*/
+   writew(0x,&sc520_mmcr->intpinpol);
+
+   /* Set PIT 0 -> IRQ0, RTC -> IRQ8, FP error -> IRQ13 */
+   writeb(SC520_IRQ0, &sc520_mmcr->pit_int_map[0]);
+   writeb(SC520_IRQ8, &sc520_mmcr->rtcmap);
+   writeb(SC520_IRQ13, &sc520_mmcr->ferrmap);
+
+   /* Disable all other interrupt sources */
+   writeb(SC520_IRQ_DISABLED, &sc520_mmcr->gp_tmr_int_map[0]);
+   writeb(SC520_IRQ_DISABLED, &sc520_mmcr->gp_tmr_int_map[1]);
+   writeb(SC520_IRQ_DISABLED, &sc520_mmcr->gp_tmr_int_map[2]);
+   writeb(SC520_IRQ_DISABLED, &sc520_mmcr->pit_int_map[1]);
+   writeb(SC520_IRQ_DISABLED, &sc520_mmcr->pit_int_map[2]);
+   writeb(SC520_IRQ_DISABLED, &sc520_mmcr->pci_int_map[0]);/* 
disable PCI INT A */
+   writeb(SC520_IRQ_DISABLED, &sc520_mmcr->pci_int_map[1]);/* 
disable PCI INT B */
+   writeb(SC520_IRQ_DISABLED, &sc520_mmcr->pci_int_map[2]);/* 
disable PCI INT C */
+   writeb(SC520_IRQ_DISABLED, &sc520_mmcr->pci_int_map[3]);/* 
disable PCI INT D */
+   writeb(SC520_IRQ_DISABLED, &sc520_mmcr->dmabcintmap);   /* 
disable DMA INT */
+   writeb(SC520_IRQ_DISABLED, &sc520_mmcr->ssimap);
+   writeb(SC520_IRQ_DISABLED, &sc520_mmcr->wdtmap);
+   writeb(SC520_IRQ_DISABLED, &sc520_mmcr->wpvmap);
+   writeb(SC520_IRQ_DISABLED, &sc520_mmcr->icemap);
+}
-- 
1.7.1.rc1.12.ga601

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


[U-Boot] [PATCH v3 21/26] [eNET] Add support for onboard RTL8100B (RTL8139) chips

2010-04-23 Thread Graeme Russ
Signed-off-by: Graeme Russ 
---
 board/eNET/eNET.c  |7 +++
 include/configs/eNET.h |9 -
 2 files changed, 15 insertions(+), 1 deletions(-)

diff --git a/board/eNET/eNET.c b/board/eNET/eNET.c
index 52ea140..62f99ce 100644
--- a/board/eNET/eNET.c
+++ b/board/eNET/eNET.c
@@ -24,6 +24,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #ifdef CONFIG_HW_WATCHDOG
 #include 
@@ -173,3 +175,8 @@ ulong board_flash_get_legacy (ulong base, int banknum, 
flash_info_t * info)
} else
return 0;
 }
+
+int board_eth_init(bd_t *bis)
+{
+   return pci_eth_init(bis);
+}
diff --git a/include/configs/eNET.h b/include/configs/eNET.h
index 0bfbd08..dac3ede 100644
--- a/include/configs/eNET.h
+++ b/include/configs/eNET.h
@@ -105,9 +105,10 @@
 #define CONFIG_CMD_LOADS   /* loads*/
 #define CONFIG_CMD_MEMORY  /* md mm nm mw cp cmp crc base loop mtest */
 #define CONFIG_CMD_MISC/* Misc functions like sleep etc*/
-#undef CONFIG_CMD_NET  /* bootp, tftpboot, rarpboot*/
+#define CONFIG_CMD_NET /* bootp, tftpboot, rarpboot*/
 #undef CONFIG_CMD_NFS  /* NFS support  */
 #define CONFIG_CMD_PCI /* PCI support  */
+#define CONFIG_CMD_PING/* ICMP echo support*/
 #define CONFIG_CMD_RUN /* run command in env variable  */
 #define CONFIG_CMD_SAVEENV /* saveenv  */
 #define CONFIG_CMD_SETGETDCR   /* DCR support on 4xx   */
@@ -226,6 +227,12 @@
 #define CONFIG_SYS_THIRD_PCI_IRQ   11
 #define CONFIG_SYS_FORTH_PCI_IRQ   15
 
+ /*
+ * Network device (TRL8100B) support
+ */
+#define CONFIG_NET_MULTI
+#define CONFIG_RTL8139
+
 /*---
  * Hardware watchdog configuration
  */
-- 
1.7.1.rc1.12.ga601

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


[U-Boot] [PATCH v3 18/26] [eNET] Fix CONFIG_SYS_HZ to be 1000

2010-04-23 Thread Graeme Russ
The clock interupt has always been 1kHz as per timer_init() in
/arch/i386/cpu/sc520/sc520_timer.c

Signed-off-by: Graeme Russ 
---
 include/configs/eNET.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/configs/eNET.h b/include/configs/eNET.h
index f643f7f..0bfbd08 100644
--- a/include/configs/eNET.h
+++ b/include/configs/eNET.h
@@ -140,7 +140,7 @@
 
 #defineCONFIG_SYS_LOAD_ADDR0x10/* default load 
address */
 
-#defineCONFIG_SYS_HZ   1024/* incrementer 
freq: 1kHz */
+#defineCONFIG_SYS_HZ   1000/* incrementer 
freq: 1kHz */
 
 /*---
  * SDRAM Configuration
-- 
1.7.1.rc1.12.ga601

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


[U-Boot] [PATCH v3 19/26] [sc520] Move PCI defines to PCI include file

2010-04-23 Thread Graeme Russ
Signed-off-by: Graeme Russ 
---
 arch/i386/include/asm/ic/pci.h   |   29 +
 arch/i386/include/asm/ic/sc520.h |   29 -
 2 files changed, 29 insertions(+), 29 deletions(-)

diff --git a/arch/i386/include/asm/ic/pci.h b/arch/i386/include/asm/ic/pci.h
index bcccdbe..1a35f34 100644
--- a/arch/i386/include/asm/ic/pci.h
+++ b/arch/i386/include/asm/ic/pci.h
@@ -24,6 +24,35 @@
 #ifndef _ASM_IC_SC520_PCI_H_
 #define _ASM_IC_SC520_PCI_H_ 1
 
+/* bus mapping constants (used for PCI core initialization) */ 




 /* bus mapping constants */
+#define SC520_REG_ADDR 0x0cf8
+#define SC520_REG_DATA 0x0cfc
+
+#define SC520_ISA_MEM_PHYS 0x
+#define SC520_ISA_MEM_BUS  0x
+#define SC520_ISA_MEM_SIZE 0x0100
+
+#define SC520_ISA_IO_PHYS  0x
+#define SC520_ISA_IO_BUS   0x
+#define SC520_ISA_IO_SIZE  0x1000
+
+/* PCI I/O space from 0x1000 to 0xdfff
+ * (make 0xe000-0xfdff available for stuff like PCCard boot) */
+#define SC520_PCI_IO_PHYS  0x1000
+#define SC520_PCI_IO_BUS   0x1000
+#define SC520_PCI_IO_SIZE  0xd000
+
+/* system memory from 0x to 0x0fff */
+#defineSC520_PCI_MEMORY_PHYS   0x
+#defineSC520_PCI_MEMORY_BUS0x
+#define SC520_PCI_MEMORY_SIZE  0x1000
+
+/* PCI bus memory from 0x1000 to 0x26ff
+ * (make 0x2700 - 0x27ff available for stuff like PCCard boot) */
+#define SC520_PCI_MEM_PHYS 0x1000
+#define SC520_PCI_MEM_BUS  0x1000
+#define SC520_PCI_MEM_SIZE 0x1700
+
 /* pin number used for PCI interrupt mappings */
 #define SC520_PCI_INTA 0
 #define SC520_PCI_INTB 1
diff --git a/arch/i386/include/asm/ic/sc520.h b/arch/i386/include/asm/ic/sc520.h
index 20384a4..053d9c6 100644
--- a/arch/i386/include/asm/ic/sc520.h
+++ b/arch/i386/include/asm/ic/sc520.h
@@ -293,35 +293,6 @@ extern volatile sc520_mmcr_t *sc520_mmcr;
 #define UART2_DIS  0x02/* UART2 Disable */
 #define UART1_DIS  0x01/* UART1 Disable */
 
-/* bus mapping constants (used for PCI core initialization) */ 




 /* bus mapping constants */
-#define SC520_REG_ADDR 0x0cf8
-#define SC520_REG_DATA 0x0cfc
-
-#define SC520_ISA_MEM_PHYS 0x
-#define SC520_ISA_MEM_BUS  0x
-#define SC520_ISA_MEM_SIZE 0x0100
-
-#define SC520_ISA_IO_PHYS  0x
-#define SC520_ISA_IO_BUS   0x
-#define SC520_ISA_IO_SIZE  0x1000
-
-/* PCI I/O space from 0x1000 to 0xdfff
- * (make 0xe000-0xfdff available for stuff like PCCard boot) */
-#define SC520_PCI_IO_PHYS  0x1000
-#define SC520_PCI_IO_BUS   0x1000
-#define SC520_PCI_IO_SIZE  0xd000
-
-/* system memory from 0x to 0x0fff */
-#defineSC520_PCI_MEMORY_PHYS   0x
-#defineSC520_PCI_MEMORY_BUS0x
-#define SC520_PCI_MEMORY_SIZE  0x1000
-
-/* PCI bus memory from 0x1000 to 0x26ff
- * (make 0x2700 - 0x27ff available for stuff like PCCard boot) */
-#define SC520_PCI_MEM_PHYS 0x1000
-#define SC520_PCI_MEM_BUS  0x1000
-#define SC520_PCI_MEM_SIZE 0x1700
-
 /* 0x2800 - 0x3fff is used by the flash banks */
 
 /* 0x4000 - 0x is not adressable by the SC520 */
-- 
1.7.1.rc1.12.ga601

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


[U-Boot] [PATCH v3 20/26] [sc520] Board Specific PCI Init

2010-04-23 Thread Graeme Russ
Signed-off-by: Graeme Russ 
---
 arch/i386/cpu/sc520/sc520_pci.c |   39 ++-
 arch/i386/include/asm/ic/pci.h  |1 +
 board/eNET/eNET_pci.c   |   34 ++
 3 files changed, 37 insertions(+), 37 deletions(-)

diff --git a/arch/i386/cpu/sc520/sc520_pci.c b/arch/i386/cpu/sc520/sc520_pci.c
index ee7e720..b917734 100644
--- a/arch/i386/cpu/sc520/sc520_pci.c
+++ b/arch/i386/cpu/sc520/sc520_pci.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 static struct {
@@ -124,43 +125,7 @@ void pci_sc520_init(struct pci_controller *hose)
 {
hose->first_busno = 0;
hose->last_busno = 0xff;
-
-   /* System memory space */
-   pci_set_region(hose->regions + 0,
-  SC520_PCI_MEMORY_BUS,
-  SC520_PCI_MEMORY_PHYS,
-  SC520_PCI_MEMORY_SIZE,
-  PCI_REGION_MEM | PCI_REGION_SYS_MEMORY);
-
-   /* PCI memory space */
-   pci_set_region(hose->regions + 1,
-  SC520_PCI_MEM_BUS,
-  SC520_PCI_MEM_PHYS,
-  SC520_PCI_MEM_SIZE,
-  PCI_REGION_MEM);
-
-   /* ISA/PCI memory space */
-   pci_set_region(hose->regions + 2,
-  SC520_ISA_MEM_BUS,
-  SC520_ISA_MEM_PHYS,
-  SC520_ISA_MEM_SIZE,
-  PCI_REGION_MEM);
-
-   /* PCI I/O space */
-   pci_set_region(hose->regions + 3,
-  SC520_PCI_IO_BUS,
-  SC520_PCI_IO_PHYS,
-  SC520_PCI_IO_SIZE,
-  PCI_REGION_IO);
-
-   /* ISA/PCI I/O space */
-   pci_set_region(hose->regions + 4,
-  SC520_ISA_IO_BUS,
-  SC520_ISA_IO_PHYS,
-  SC520_ISA_IO_SIZE,
-  PCI_REGION_IO);
-
-   hose->region_count = 5;
+   hose->region_count = pci_set_regions(hose);
 
pci_setup_type1(hose,
SC520_REG_ADDR,
diff --git a/arch/i386/include/asm/ic/pci.h b/arch/i386/include/asm/ic/pci.h
index 1a35f34..2e4376b 100644
--- a/arch/i386/include/asm/ic/pci.h
+++ b/arch/i386/include/asm/ic/pci.h
@@ -73,6 +73,7 @@
 extern int sc520_pci_ints[];
 
 void pci_sc520_init(struct pci_controller *hose);
+int pci_set_regions(struct pci_controller *hose);
 int pci_sc520_set_irq(int pci_pin, int irq);
 
 #endif
diff --git a/board/eNET/eNET_pci.c b/board/eNET/eNET_pci.c
index e80a8fe..e105e4a 100644
--- a/board/eNET/eNET_pci.c
+++ b/board/eNET/eNET_pci.c
@@ -93,3 +93,37 @@ void pci_init_board(void)
 {
pci_sc520_init(&enet_hose);
 }
+
+int pci_set_regions(struct pci_controller *hose)
+{
+   /* System memory space */
+   pci_set_region(hose->regions + 0,
+  SC520_PCI_MEMORY_BUS,
+  SC520_PCI_MEMORY_PHYS,
+  SC520_PCI_MEMORY_SIZE,
+  PCI_REGION_MEM | PCI_REGION_SYS_MEMORY);
+
+   /* ISA/PCI memory space */
+   pci_set_region(hose->regions + 1,
+  SC520_ISA_MEM_BUS,
+  SC520_ISA_MEM_PHYS,
+  SC520_ISA_MEM_SIZE,
+  PCI_REGION_MEM);
+
+   /* PCI I/O space */
+   pci_set_region(hose->regions + 2,
+  SC520_PCI_IO_BUS,
+  SC520_PCI_IO_PHYS,
+  SC520_PCI_IO_SIZE,
+  PCI_REGION_IO);
+
+   /* ISA/PCI I/O space */
+   pci_set_region(hose->regions + 3,
+  SC520_ISA_IO_BUS,
+  SC520_ISA_IO_PHYS,
+  SC520_ISA_IO_SIZE,
+  PCI_REGION_IO);
+
+   return 4;
+}
+
-- 
1.7.1.rc1.12.ga601

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


[U-Boot] [PATCH v3 17/26] [eNET] Fix Flash Write

2010-04-23 Thread Graeme Russ
Onboard AMD Flash chip does not support buffered writes

Signed-off-by: Graeme Russ 
---
 include/configs/eNET.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/configs/eNET.h b/include/configs/eNET.h
index 05d7db8..f643f7f 100644
--- a/include/configs/eNET.h
+++ b/include/configs/eNET.h
@@ -198,7 +198,7 @@
 CONFIG_SYS_FLASH_BASE_1, \
 CONFIG_SYS_FLASH_BASE_2}
 #define CONFIG_SYS_FLASH_EMPTY_INFO
-#define CONFIG_SYS_FLASH_USE_BUFFER_WRITE
+#undef CONFIG_SYS_FLASH_USE_BUFFER_WRITE
 #define CONFIG_SYS_MAX_FLASH_SECT  128 /* max number of sectors on one 
chip */
 #define CONFIG_SYS_FLASH_CFI_WIDTH FLASH_CFI_8BIT
 #define CONFIG_SYS_FLASH_LEGACY_512Kx8
-- 
1.7.1.rc1.12.ga601

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


[U-Boot] [PATCH v3 16/26] [sc520] Allow boards to override udelay

2010-04-23 Thread Graeme Russ
If the board has a high precision mico-second timer, it maked sense to use
it instead of the on-chip one

Signed-off-by: Graeme Russ 
---
 arch/i386/cpu/sc520/sc520_timer.c |4 
 arch/i386/include/asm/ic/sc520.h  |1 +
 2 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/arch/i386/cpu/sc520/sc520_timer.c 
b/arch/i386/cpu/sc520/sc520_timer.c
index eca48e0..d5617e9 100644
--- a/arch/i386/cpu/sc520/sc520_timer.c
+++ b/arch/i386/cpu/sc520/sc520_timer.c
@@ -69,7 +69,11 @@ int timer_init(void)
return 0;
 }
 
+/* Allow boards to override udelay implementation */
 void __udelay(unsigned long usec)
+   __attribute__((weak, alias("sc520_udelay")));
+
+void sc520_udelay(unsigned long usec)
 {
int m = 0;
long u;
diff --git a/arch/i386/include/asm/ic/sc520.h b/arch/i386/include/asm/ic/sc520.h
index 57c9904..20384a4 100644
--- a/arch/i386/include/asm/ic/sc520.h
+++ b/arch/i386/include/asm/ic/sc520.h
@@ -28,6 +28,7 @@
 
 void init_sc520(void);
 unsigned long init_sc520_dram(void);
+void sc520_udelay(unsigned long usec);
 
 /* Memory mapped configuration registers */
 typedef struct sc520_mmcr {
-- 
1.7.1.rc1.12.ga601

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


[U-Boot] [PATCH v3 13/26] [x86] Use CONFIG_SERIAL_MULTI

2010-04-23 Thread Graeme Russ
Signed-off-by: Graeme Russ 
---
 arch/i386/cpu/Makefile |2 +-
 arch/i386/cpu/serial.c |  506 
 arch/i386/lib/board.c  |5 +-
 board/eNET/eNET.c  |3 +-
 common/serial.c|3 +-
 include/configs/eNET.h |   26 ++-
 include/serial.h   |3 +-
 7 files changed, 32 insertions(+), 516 deletions(-)
 delete mode 100644 arch/i386/cpu/serial.c

diff --git a/arch/i386/cpu/Makefile b/arch/i386/cpu/Makefile
index c658c6e..bb0a48f 100644
--- a/arch/i386/cpu/Makefile
+++ b/arch/i386/cpu/Makefile
@@ -29,7 +29,7 @@ include $(TOPDIR)/config.mk
 LIB= $(obj)lib$(CPU).a
 
 START  = start.o start16.o resetvec.o
-COBJS  = serial.o interrupts.o cpu.o
+COBJS  = interrupts.o cpu.o
 
 SRCS   := $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c)
 OBJS   := $(addprefix $(obj),$(SOBJS) $(COBJS))
diff --git a/arch/i386/cpu/serial.c b/arch/i386/cpu/serial.c
deleted file mode 100644
index e7025a3..000
--- a/arch/i386/cpu/serial.c
+++ /dev/null
@@ -1,506 +0,0 @@
-/*
- * (C) Copyright 2002
- * Daniel Engström, Omicron Ceti AB, dan...@omicron.se
- *
- * (C) Copyright 2000
- * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
- *
- * See file CREDITS for list of people who contributed to this
- * project.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of
- * the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- * MA 02111-1307 USA
- */
-/*--+
 */
-
-/*
- * This source code is dual-licensed.  You may use it under the terms of the
- * GNU General Public License version 2, or under the license below.
- *
- * This source code has been made available to you by IBM on an AS-IS
- * basis.  Anyone receiving this source is licensed under IBM
- * copyrights to use it in any way he or she deems fit, including
- * copying it, modifying it, compiling it, and redistributing it either
- * with or without modifications.  No license under IBM patents or
- * patent applications is to be implied by the copyright license.
- *
- * Any user of this software should understand that IBM cannot provide
- * technical support for this software and will not be responsible for
- * any consequences resulting from the use of this software.
- *
- * Any person who transfers this source code or any derivative work
- * must include the IBM copyright notice, this paragraph, and the
- * preceding two paragraphs in the transferred software.
- *
- * COPYRIGHT   I B M   CORPORATION 1995
- * LICENSED MATERIAL  -  PROGRAM PROPERTY OF I B M
- */
-/*---
 */
-
-#include 
-#include 
-#include 
-#include 
-
-#ifdef CONFIG_SERIAL_SOFTWARE_FIFO
-#include 
-#endif
-
-DECLARE_GLOBAL_DATA_PTR;
-
-#define UART_RBR0x00
-#define UART_THR0x00
-#define UART_IER0x01
-#define UART_IIR0x02
-#define UART_FCR0x02
-#define UART_LCR0x03
-#define UART_MCR0x04
-#define UART_LSR0x05
-#define UART_MSR0x06
-#define UART_SCR0x07
-#define UART_DLL0x00
-#define UART_DLM0x01
-
-/*-+
-  | Line Status Register.
-  
+-*/
-#define asyncLSRDataReady10x01
-#define asyncLSROverrunError1 0x02
-#define asyncLSRParityError1  0x04
-#define asyncLSRFramingError1 0x08
-#define asyncLSRBreakInterrupt1   0x10
-#define asyncLSRTxHoldEmpty1  0x20
-#define asyncLSRTxShiftEmpty1 0x40
-#define asyncLSRRxFifoError1  0x80
-
-
-#ifdef CONFIG_SERIAL_SOFTWARE_FIFO
-/*-+
-  | Fifo
-  
+-*/
-typedef struct {
-   char *rx_buffer;
-   ulong rx_put;
-   ulong rx_get;
-   int cts;
-} serial_buffer_t;
-
-volatile serial_buffer_t buf_info;
-static int serial_buffer_active=0;
-#endif
-
-
-static int serial_div(int baudrate)
-{
-
-   switch (baudrate) {
-   case 1200:
-   return 96;
-   case 9600:
-   return 12;
-   case 19200:
-   return 6;
-   case 38400:
-   return 3;
-   case 57600:
-   return 2;
-   case 11520

[U-Boot] [PATCH v3 14/26] [x86] Provide weak PC/AT compatibility setup function

2010-04-23 Thread Graeme Russ
It is possibly to setup x86 boards to use non-PC/AT configurations. For
example, the sc520 is an x86 CPU with PC/AT and non-PC/AT peripherals.
This function allows the board to set itself up for maximum PC/AT
compatibility just before booting the Linux kernel (the Linux kernel
'just works' if everything is PC/AT compliant)

Signed-off-by: Graeme Russ 
---
 arch/i386/include/asm/u-boot-i386.h |2 ++
 arch/i386/lib/board.c   |8 
 2 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/i386/include/asm/u-boot-i386.h 
b/arch/i386/include/asm/u-boot-i386.h
index 521fd35..ce097a3 100644
--- a/arch/i386/include/asm/u-boot-i386.h
+++ b/arch/i386/include/asm/u-boot-i386.h
@@ -43,6 +43,8 @@ int cpu_init_interrupts(void);
 int board_init(void);
 int dram_init(void);
 
+void setup_pcat_compatibility(void);
+
 void isa_unmap_rom(u32 addr);
 u32 isa_map_rom(u32 bus_addr, int size);
 
diff --git a/arch/i386/lib/board.c b/arch/i386/lib/board.c
index 7115a2f..b852ed1 100644
--- a/arch/i386/lib/board.c
+++ b/arch/i386/lib/board.c
@@ -441,3 +441,11 @@ unsigned long do_go_exec (ulong (*entry)(int, char *[]), 
int argc, char *argv[])
 
return (entry) (argc, argv);
 }
+
+void setup_pcat_compatibility(void)
+   __attribute__((weak, alias("__setup_pcat_compatibility")));
+
+void __setup_pcat_compatibility(void)
+{
+}
+
-- 
1.7.1.rc1.12.ga601

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


[U-Boot] [PATCH v3 12/26] [ns16550] Enable port-mapped access

2010-04-23 Thread Graeme Russ
The x86 architecture exclusively uses Port-Mapped I/O (inb/outb) to access
the 16550 UARTs. This patch mimics how Linux selects between Memory-Mapped
and Port-Mapped I/O. This allows x86 boards to use CONFIG_SERIAL_MUTLI and
drop the custom serial port driver

Signed-off-by: Graeme Russ 
---
 drivers/serial/ns16550.c |   69 ++
 1 files changed, 39 insertions(+), 30 deletions(-)

diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index 23c0f76..7e833fd 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -7,6 +7,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #define UART_LCRVAL UART_LCR_8N1   /* 8 data, 1 stop, no parity */
 #define UART_MCRVAL (UART_MCR_DTR | \
@@ -14,28 +16,35 @@
 #define UART_FCRVAL (UART_FCR_FIFO_EN |\
 UART_FCR_RXSR |\
 UART_FCR_TXSR) /* Clear & enable FIFOs */
+#ifdef CONFIG_SYS_NS16550_PORT_MAPPED
+#define serial_out(x,y)outb(x,(ulong)y)
+#define serial_in(y)   inb((ulong)y)
+#else
+#define serial_out(x,y) writeb(x,y)
+#define serial_in(y)   readb(y)
+#endif
 
 void NS16550_init (NS16550_t com_port, int baud_divisor)
 {
-   com_port->ier = 0x00;
+   serial_out(0x00, &com_port->ier);
 #if defined(CONFIG_OMAP) && !defined(CONFIG_OMAP3_ZOOM2)
-   com_port->mdr1 = 0x7;   /* mode select reset TL16C750*/
+   serial_out(0x7, &com_port->mdr1);   /* mode select reset TL16C750*/
 #endif
-   com_port->lcr = UART_LCR_BKSE | UART_LCRVAL;
-   com_port->dll = 0;
-   com_port->dlm = 0;
-   com_port->lcr = UART_LCRVAL;
-   com_port->mcr = UART_MCRVAL;
-   com_port->fcr = UART_FCRVAL;
-   com_port->lcr = UART_LCR_BKSE | UART_LCRVAL;
-   com_port->dll = baud_divisor & 0xff;
-   com_port->dlm = (baud_divisor >> 8) & 0xff;
-   com_port->lcr = UART_LCRVAL;
+   serial_out(UART_LCR_BKSE | UART_LCRVAL, (ulong)&com_port->lcr);
+   serial_out(0, &com_port->dll);
+   serial_out(0, &com_port->dlm);
+   serial_out(UART_LCRVAL, &com_port->lcr);
+   serial_out(UART_MCRVAL, &com_port->mcr);
+   serial_out(UART_FCRVAL, &com_port->fcr);
+   serial_out(UART_LCR_BKSE | UART_LCRVAL, &com_port->lcr);
+   serial_out(baud_divisor & 0xff, &com_port->dll);
+   serial_out((baud_divisor >> 8) & 0xff, &com_port->dlm);
+   serial_out(UART_LCRVAL, &com_port->lcr);
 #if defined(CONFIG_OMAP) && !defined(CONFIG_OMAP3_ZOOM2)
 #if defined(CONFIG_APTIX)
-   com_port->mdr1 = 3; /* /13 mode so Aptix 6MHz can hit 115200 */
+   serial_out(3, &com_port->mdr1); /* /13 mode so Aptix 6MHz can hit 
115200 */
 #else
-   com_port->mdr1 = 0; /* /16 is proper to hit 115200 with 48MHz */
+   serial_out(0, &com_port->mdr1); /* /16 is proper to hit 115200 with 
48MHz */
 #endif
 #endif /* CONFIG_OMAP */
 }
@@ -43,42 +52,42 @@ void NS16550_init (NS16550_t com_port, int baud_divisor)
 #ifndef CONFIG_NS16550_MIN_FUNCTIONS
 void NS16550_reinit (NS16550_t com_port, int baud_divisor)
 {
-   com_port->ier = 0x00;
-   com_port->lcr = UART_LCR_BKSE | UART_LCRVAL;
-   com_port->dll = 0;
-   com_port->dlm = 0;
-   com_port->lcr = UART_LCRVAL;
-   com_port->mcr = UART_MCRVAL;
-   com_port->fcr = UART_FCRVAL;
-   com_port->lcr = UART_LCR_BKSE;
-   com_port->dll = baud_divisor & 0xff;
-   com_port->dlm = (baud_divisor >> 8) & 0xff;
-   com_port->lcr = UART_LCRVAL;
+   serial_out(0x00, &com_port->ier);
+   serial_out(UART_LCR_BKSE | UART_LCRVAL, &com_port->lcr);
+   serial_out(0, &com_port->dll);
+   serial_out(0, &com_port->dlm);
+   serial_out(UART_LCRVAL, &com_port->lcr);
+   serial_out(UART_MCRVAL, &com_port->mcr);
+   serial_out(UART_FCRVAL, &com_port->fcr);
+   serial_out(UART_LCR_BKSE, &com_port->lcr);
+   serial_out(baud_divisor & 0xff, &com_port->dll);
+   serial_out((baud_divisor >> 8) & 0xff, &com_port->dlm);
+   serial_out(UART_LCRVAL, &com_port->lcr);
 }
 #endif /* CONFIG_NS16550_MIN_FUNCTIONS */
 
 void NS16550_putc (NS16550_t com_port, char c)
 {
-   while ((com_port->lsr & UART_LSR_THRE) == 0);
-   com_port->thr = c;
+   while ((serial_in(&com_port->lsr) & UART_LSR_THRE) == 0);
+   serial_out(c, &com_port->thr);
 }
 
 #ifndef CONFIG_NS16550_MIN_FUNCTIONS
 char NS16550_getc (NS16550_t com_port)
 {
-   while ((com_port->lsr & UART_LSR_DR) == 0) {
+   while ((serial_in(&com_port->lsr) & UART_LSR_DR) == 0) {
 #ifdef CONFIG_USB_TTY
extern void usbtty_poll(void);
usbtty_poll();
 #endif
WATCHDOG_RESET();
}
-   return (com_port->rbr);
+   return serial_in(&com_port->rbr);
 }
 
 int NS16550_tstc (NS16550_t com_port)
 {
-   return ((com_port->lsr & UART_LSR_DR) != 0);
+   return ((serial_in(&com_port->lsr) & UART_LSR_DR) != 0);
 }
 
 #endif /* CONFIG_NS16550_MIN_FUNCTIONS */
-- 
1.7.1.

[U-Boot] [PATCH v3 11/26] [x86] Fix copying of Real-Mode code into RAM

2010-04-23 Thread Graeme Russ
Signed-off-by: Graeme Russ 
---
 arch/i386/lib/bios_setup.c |2 +-
 arch/i386/lib/realmode.c   |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/i386/lib/bios_setup.c b/arch/i386/lib/bios_setup.c
index 6491e52..a92b77e 100644
--- a/arch/i386/lib/bios_setup.c
+++ b/arch/i386/lib/bios_setup.c
@@ -141,7 +141,7 @@ static void setvector(int vector, u16 segment, void 
*handler)
 
 int bios_setup(void)
 {
-   ulong i386boot_bios  = (ulong)&_i386boot_bios;
+   ulong i386boot_bios  = (ulong)&_i386boot_bios + gd->reloc_off;
ulong i386boot_bios_size = (ulong)&_i386boot_bios_size;
 
static int done=0;
diff --git a/arch/i386/lib/realmode.c b/arch/i386/lib/realmode.c
index 3c3c1fc..b3f5123 100644
--- a/arch/i386/lib/realmode.c
+++ b/arch/i386/lib/realmode.c
@@ -37,7 +37,7 @@ extern char realmode_enter;
 
 int realmode_setup(void)
 {
-   ulong i386boot_realmode  = (ulong)&_i386boot_realmode;
+   ulong i386boot_realmode  = (ulong)&_i386boot_realmode + 
gd->reloc_off;
ulong i386boot_realmode_size = (ulong)&_i386boot_realmode_size;
 
/* copy the realmode switch code */
-- 
1.7.1.rc1.12.ga601

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


[U-Boot] [PATCH v3 10/26] [x86] Pass relocation offset into Global Data

2010-04-23 Thread Graeme Russ
In order to locate the 16-bit BIOS code, we need to know the reloaction
offset.

Signed-off-by: Graeme Russ 
---
 arch/i386/lib/board.c |   63 -
 1 files changed, 36 insertions(+), 27 deletions(-)

diff --git a/arch/i386/lib/board.c b/arch/i386/lib/board.c
index 5e28c6f..947a8ec 100644
--- a/arch/i386/lib/board.c
+++ b/arch/i386/lib/board.c
@@ -52,7 +52,9 @@ extern ulong _i386boot_rel_dyn_start;
 extern ulong _i386boot_rel_dyn_end;
 extern ulong _i386boot_bss_start;
 extern ulong _i386boot_bss_size;
-void ram_bootstrap (void *);
+
+void ram_bootstrap (void *, ulong);
+
 const char version_string[] =
U_BOOT_VERSION" (" U_BOOT_DATE " - " U_BOOT_TIME ")";
 
@@ -162,6 +164,7 @@ init_fnc_t *init_sequence[] = {
NULL,
 };
 
+static gd_t gd_data;
 gd_t *gd;
 
 /*
@@ -174,21 +177,18 @@ void board_init_f (ulong stack_limit)
Elf32_Rel *rel_dyn_start = (Elf32_Rel *)&_i386boot_rel_dyn_start;
Elf32_Rel *rel_dyn_end = (Elf32_Rel *)&_i386boot_rel_dyn_end;
void *bss_start = &_i386boot_bss_start;
-   void *bss_size = &_i386boot_bss_size;
+   ulong bss_size = (ulong)&_i386boot_bss_size;
 
-   size_t uboot_size;
-   void *ram_start;
+   ulong uboot_size;
+   void *dest_addr;
ulong rel_offset;
Elf32_Rel *re;
 
-   void (*start_func)(void *);
-
-   /* compiler optimization barrier needed for GCC >= 3.4 */
-   __asm__ __volatile__("": : :"memory");
+   void (*start_func)(void *, ulong);
 
-   uboot_size = (size_t)u_boot_cmd_end - (size_t)text_start;
-   ram_start  = (void *)stack_limit - (uboot_size + (ulong)bss_size);
-   rel_offset = text_start - ram_start;
+   uboot_size = (ulong)u_boot_cmd_end - (ulong)text_start;
+   dest_addr  = (void *)stack_limit - (uboot_size + (ulong)bss_size);
+   rel_offset = text_start - dest_addr;
start_func = ram_bootstrap - rel_offset;
 
/* First stage CPU initialization */
@@ -200,10 +200,10 @@ void board_init_f (ulong stack_limit)
hang();
 
/* Copy U-Boot into RAM */
-   memcpy(ram_start, text_start, (size_t)uboot_size);
+   memcpy(dest_addr, text_start, uboot_size);
 
/* Clear BSS */
-   memset(bss_start - rel_offset,  0, (size_t)bss_size);
+   memset(bss_start - rel_offset,  0, bss_size);
 
/* Perform relocation adjustments */
for (re = rel_dyn_start; re < rel_dyn_end; re++)
@@ -213,27 +213,39 @@ void board_init_f (ulong stack_limit)
*(ulong *)(re->r_offset - rel_offset) -= 
(Elf32_Addr)rel_offset;
}
 
-   start_func(ram_start);
-
-   /* NOTREACHED - relocate_code() does not return */
+   /* Enter the relocated U-Boot! */
+   start_func(dest_addr, rel_offset);
+   /* NOTREACHED - board_init_f() does not return */
while(1);
 }
 
 /*
- * All attempts to jump straight from board_init_f() to board_init_r()
- * have failed, hence this special 'bootstrap' function.
+ * We cannot initialize gd_data in board_init_f() because we would be
+ * attempting to write to flash (I have even tried using manual relocation
+ * adjustments on pointers but it just won't work) and board_init_r() does
+ * not have enough arguments to allow us to pass the relocation offset
+ * straight up. This bootstrap function (which runs in RAM) is used to
+ * setup gd_data in order to pass the relocation offset to the rest of
+ * U-Boot.
+ *
+ * TODO: The compiler optimization barrier is intended to stop GCC from
+ * optimizing this function into board_init_f(). It seems to work without
+ * it, but I've left it in to be sure. I think also that the barrier in
+ * board_init_r() is no longer needed, but left it in 'just in case'
  */
-void ram_bootstrap (void *ram_start)
+void ram_bootstrap (void *dest_addr, ulong rel_offset)
 {
-   static gd_t gd_data;
-
/* compiler optimization barrier needed for GCC >= 3.4 */
__asm__ __volatile__("": : :"memory");
 
-   board_init_r(&gd_data, (ulong)ram_start);
+   /* tell others: relocation done */
+   gd_data.reloc_off = rel_offset;
+   gd_data.flags |= GD_FLG_RELOC;
+
+   board_init_r(&gd_data, (ulong)dest_addr);
 }
 
-void board_init_r(gd_t *id, ulong ram_start)
+void board_init_r(gd_t *id, ulong dest_addr)
 {
char *s;
int i;
@@ -247,16 +259,13 @@ void board_init_r(gd_t *id, ulong ram_start)
/* compiler optimization barrier needed for GCC >= 3.4 */
__asm__ __volatile__("": : :"memory");
 
-   memset (gd, 0, sizeof (gd_t));
gd->bd = &bd_data;
memset (gd->bd, 0, sizeof (bd_t));
show_boot_progress(0x22);
 
gd->baudrate =  CONFIG_BAUDRATE;
 
-   gd->flags |= GD_FLG_RELOC;  /* tell others: relocation done */
-
-   mem_malloc_initulong)ram_start - CONFIG_SYS_MALLOC_LEN)+3)&~3,
+   mem_malloc_initulong)dest_addr - CONFIG_SYS_MALLOC_LEN)+3)&~3,
  

[U-Boot] [PATCH v3 09/26] [x86] Move GDT to a safe location in RAM

2010-04-23 Thread Graeme Russ
Currently, the GDT is either located in FLASH or in the non-relocated
U-Boot image in RAM. Both of these locations are unsafe as those
locations can be erased during a U-Boot update. Move the GDT into the
highest available memory location and relocate U-Boot to just below it

Signed-off-by: Graeme Russ 
---
 arch/i386/cpu/start.S   |   96 +++
 arch/i386/cpu/start16.S |   21 +++---
 2 files changed, 103 insertions(+), 14 deletions(-)

diff --git a/arch/i386/cpu/start.S b/arch/i386/cpu/start.S
index 3cea04b..7def8de 100644
--- a/arch/i386/cpu/start.S
+++ b/arch/i386/cpu/start.S
@@ -100,6 +100,53 @@ mem_init_ret:
jmp get_mem_size
 get_mem_size_ret:
 
+   /*
+* We are now in 'Flat Protected Mode' and we know how much memory
+* the board has. The (temporary) Global Descriptor Table is not
+* in a 'Safe' place (it is either in Flash which can be erased or
+* reprogrammed or in a fail-safe boot-strap image which could be
+* over-written).
+*
+* Move the final gdt to a safe place (top of RAM) and load it.
+* This is not a trivial excercise - the lgdt instruction does not
+* have a register operand (memory only) and we may well be
+* running from Flash, so self modifying code will not work here.
+* To overcome this, we copy a stub into upper memory along with
+* the GDT.
+*/
+
+   /* Reduce upper memory limit by (Stub + GDT Pointer + GDT) */
+   subl$(end_gdt_setup - start_gdt_setup), %eax
+
+   /* Copy the GDT and Stub */
+   movl$start_gdt_setup, %esi
+   movl%eax, %edi
+   movl$(end_gdt_setup - start_gdt_setup), %ecx
+   shrl$2, %ecx
+   cld
+   rep movsl
+
+   /* write the lgdt 'parameter' */
+   subl$(jmp_instr - start_gdt_setup - 4), %ebp
+   addl%eax, %ebp
+   movl$(gdt_ptr - start_gdt_setup), %ebx
+   addl%eax, %ebx
+   movl%ebx, (%ebp)
+
+   /* write the gdt address into the pointer */
+   movl$(gdt_addr - start_gdt_setup), %ebp
+   addl%eax, %ebp
+   movl$(gdt - start_gdt_setup), %ebx
+   addl%eax, %ebx
+   movl%ebx, (%ebp)
+
+   /* Save the return address */
+   movl$load_gdt_ret, %ebp
+
+   /* Load the new (safe) Global Descriptor Table */
+   jmp *%eax
+
+load_gdt_ret:
/* Check we have enough memory for stack */
movl$CONFIG_SYS_STACK_SIZE, %ecx
cmpl%ecx, %eax
@@ -174,3 +221,52 @@ die:   hlt
 blank_idt_ptr:
.word   0   /* limit */
.long   0   /* base */
+
+.align 4
+start_gdt_setup:
+   lgdtgdt_ptr
+jmp_instr:
+   jmp *%ebp
+
+.align 4
+gdt_ptr:
+   .word   0x30/* limit (48 bytes = 6 GDT entries) */
+gdt_addr:
+   .long   gdt /* base */
+
+   /* The GDT table ...
+*
+*   Selector   Type
+*   0x00   NULL
+*   0x08   Unused
+*   0x10   32bit code
+*   0x18   32bit data/stack
+*   0x20   16bit code
+*   0x28   16bit data/stack
+*/
+
+.align 4
+gdt:
+   .word   0, 0, 0, 0  /* NULL  */
+   .word   0, 0, 0, 0  /* unused */
+
+   .word   0x  /* 4Gb - (0x10*0x1000 = 4Gb) */
+   .word   0   /* base address = 0 */
+   .word   0x9B00  /* code read/exec */
+   .word   0x00CF  /* granularity = 4096, 386 (+5th nibble of 
limit) */
+
+   .word   0x  /* 4Gb - (0x10*0x1000 = 4Gb) */
+   .word   0x0 /* base address = 0 */
+   .word   0x9300  /* data read/write */
+   .word   0x00CF  /* granularity = 4096, 386 (+5th nibble of 
limit) */
+
+   .word   0x  /* 64kb */
+   .word   0   /* base address = 0 */
+   .word   0x9b00  /* data read/write */
+   .word   0x0010  /* granularity = 1  (+5th nibble of limit) */
+
+   .word   0x  /* 64kb */
+   .word   0   /* base address = 0 */
+   .word   0x9300  /* data read/write */
+   .word   0x0010  /* granularity = 1 (+5th nibble of limit) */
+end_gdt_setup:
diff --git a/arch/i386/cpu/start16.S b/arch/i386/cpu/start16.S
index 5e33aa1..3e8b2cc 100644
--- a/arch/i386/cpu/start16.S
+++ b/arch/i386/cpu/start16.S
@@ -44,7 +44,7 @@ board_init16_ret:
movl%eax, %cr0
wbinvd
 
-   /* load the descriptor tables */
+   /* load the temporary Global Descriptor Table */
 o32 cs lgdtgdt_ptr
 
/* Now, we enter protected mode */
@@ -68,8 +68,13 @@ code32start:
.long   _start  /* offset */
.word   0x10/* segment */
 
+/*
+ * The following Global Descriptor Table is just enough

[U-Boot] [PATCH v3 08/26] [x86] Add RAM bootstrap functionality

2010-04-23 Thread Graeme Russ
Add a parameter to the 32-bit entry to indicate if entry is from Real
Mode or not. If entry is from Real Mode, execute the destructive 'sizer'
routine to determine memory size as we are booting cold and running in
Flash. If not entering from Real Mode, we are executing a U-Boot image
from RAM and therefore the memory size is already known (and running
'sizer' will destroy the running image)

There are now two 32-bit entry points. The first is the 'in RAM' entry
point which exists at the start of the U-Boot binary image. As such,
you can load u-boot.bin in RAM and jump directly to the load address
without needing to calculate any offsets. The second entry point is
used by the real-to-protected mode switch

This patch also changes TEXT_BASE to 0x600 (in RAM). You can load
the resulting image at 0x600 and simple go 0x600 from the u-boot
prompt

Hopefully a later patch will completely elliminate any dependency on
TEXT_BASE like a relocatable linux kernel (perfect world)

Signed-off-by: Graeme Russ 
---
 arch/i386/cpu/start.S   |   36 
 arch/i386/cpu/start16.S |8 ++--
 board/eNET/config.mk|2 +-
 board/eNET/u-boot.lds   |9 -
 4 files changed, 43 insertions(+), 12 deletions(-)

diff --git a/arch/i386/cpu/start.S b/arch/i386/cpu/start.S
index 1980f1a..3cea04b 100644
--- a/arch/i386/cpu/start.S
+++ b/arch/i386/cpu/start.S
@@ -33,7 +33,27 @@
 .type _start, @function
 .globl _i386boot_start
 _i386boot_start:
+   /*
+* This is the fail safe 32-bit bootstrap entry point. The
+* following code is not executed from a cold-reset (actually, a
+* lot of it is, but from real-mode after cold reset. It is
+* repeated here to put the board into a state as close to cold
+* reset as necessary)
+*/
+   cli
+   cld
+
+   /* Turn of cache (this might require a 486-class CPU) */
+   movl%cr0, %eax
+   orl $0x6000,%eax
+   movl%eax, %cr0
+   wbinvd
+
+   /* Tell 32-bit code it is being entered from an in-RAM copy */
+   movw$0x, %bx
 _start:
+   /* This is the 32-bit cold-reset entry point */
+
movl$0x18,%eax  /* Load our segement registes, the
 * gdt have already been loaded by start16.S */
movw%ax,%fs
@@ -42,6 +62,18 @@ _start:
movw%ax,%es
movw%ax,%ss
 
+   /* Clear the interupt vectors */
+   lidtblank_idt_ptr
+
+   /*
+* Skip low-level board and memory initialization if not starting
+* from cold-reset. This allows us to do a fail safe boot-strap
+* into a new build of U-Boot from a known-good boot flash
+*/
+   movw$0x0001, %ax
+   cmpw%ax, %bx
+   jne mem_init_ret
+
/* We call a few functions in the board support package
 * since we have no stack yet we'll have to use %ebp
 * to store the return address */
@@ -138,3 +170,7 @@ stack_ok:
 die:   hlt
jmp die
hlt
+
+blank_idt_ptr:
+   .word   0   /* limit */
+   .long   0   /* base */
diff --git a/arch/i386/cpu/start16.S b/arch/i386/cpu/start16.S
index 1ebb6bc..5e33aa1 100644
--- a/arch/i386/cpu/start16.S
+++ b/arch/i386/cpu/start16.S
@@ -45,10 +45,8 @@ board_init16_ret:
wbinvd
 
/* load the descriptor tables */
-o32 cs lidtidt_ptr
 o32 cs lgdtgdt_ptr
 
-
/* Now, we enter protected mode */
movl%cr0, %eax
orl $1,%eax
@@ -57,6 +55,8 @@ o32 cslgdtgdt_ptr
/* Flush the prefetch queue */
jmp ff
 ff:
+   /* Tell 32-bit code it is being entered from hard-reset */
+   movw$0x0001, %bx
 
/* Finally jump to the 32bit initialization code */
movw$code32start, %ax
@@ -68,10 +68,6 @@ code32start:
.long   _start  /* offset */
.word   0x10/* segment */
 
-idt_ptr:
-   .word   0   /* limit */
-   .long   0   /* base */
-
 gdt_ptr:
.word   0x30/* limit (48 bytes = 6 GDT entries) */
.long   BOOT_SEG + gdt  /* base */
diff --git a/board/eNET/config.mk b/board/eNET/config.mk
index dcde7fc..63a58fd 100644
--- a/board/eNET/config.mk
+++ b/board/eNET/config.mk
@@ -21,7 +21,7 @@
 # MA 02111-1307 USA
 #
 
-TEXT_BASE = 0x3804
+TEXT_BASE = 0x0600
 CFLAGS_common/dlmalloc.o += -Wa,--no-warn -fno-strict-aliasing
 PLATFORM_RELFLAGS += -fvisibility=hidden
 PLATFORM_CPPFLAGS += -fno-dwarf2-cfi-asm
diff --git a/board/eNET/u-boot.lds b/board/eNET/u-boot.lds
index 0d74021..7b0ffaa 100644
--- a/board/eNET/u-boot.lds
+++ b/board/eNET/u-boot.lds
@@ -27,7 +27,7 @@ ENTRY(_start)
 
 SECTIONS
 {
-   . = 0x3804; /* Location of bootcode in flash */
+   . = 0x0600; /* Location of bootcode in flash */
_i386boot_text_start = .;
.text  : { *(.text); }

[U-Boot] [PATCH v3 07/26] [x86] Split sc520 memory sizing versus reporting

2010-04-23 Thread Graeme Russ
This patch allows the low-level assembler boot-strap to obtain the RAM
size without calling the destructive 'sizer' routine. This allows
boot-strapping from a U-Boot image loaded in RAM

Signed-off-by: Graeme Russ 
---
 arch/i386/cpu/sc520/sc520_asm.S |   95 +++---
 arch/i386/cpu/start.S   |5 ++
 2 files changed, 62 insertions(+), 38 deletions(-)

diff --git a/arch/i386/cpu/sc520/sc520_asm.S b/arch/i386/cpu/sc520/sc520_asm.S
index 135f7b4..c745454 100644
--- a/arch/i386/cpu/sc520/sc520_asm.S
+++ b/arch/i386/cpu/sc520/sc520_asm.S
@@ -498,47 +498,21 @@ bad_ram:
 
 dram_done:
 
-   /* readback DRCBENDADR and return the number
-* of available ram bytes in %eax */
-
-   movl$DRCBENDADR, %edi/* DRAM ending address register  */
-
-bank0: movl(%edi), %eax
-   movl%eax, %ecx
-   andl$0x0080, %ecx
-   jz  bank1
-   andl$0x007f, %eax
-   shll$22, %eax
-   movl%eax, %ebx
-
-bank1: movl(%edi), %eax
-   movl%eax, %ecx
-   andl$0x8000, %ecx
-   jz  bank2
-   andl$0x7f00, %eax
-   shll$14, %eax
-   movl%eax, %ebx
-
-bank2: movl(%edi), %eax
-   movl%eax, %ecx
-   andl$0x0080, %ecx
-   jz  bank3
-   andl$0x007f, %eax
-   shll$6, %eax
-   movl%eax, %ebx
+#if CONFIG_SYS_SDRAM_ECC_ENABLE
+   /*
+* We are in the middle of an existing 'call' - Need to store the
+* existing return address before making another 'call'
+*/
+   movl%ebp, %ebx
 
-bank3: movl(%edi), %eax
-   movl%eax, %ecx
-   andl$0x8000, %ecx
-   jz  done
-   andl$0x7f00, %eax
-   shrl$2, %eax
-   movl%eax, %ebx
+   /* Get the memory size */
+   movl$init_ecc, %ebp
+   jmplget_mem_size
 
-done:
-   movl%ebx, %eax
+init_ecc:
+   /* Restore the orignal return address */
+   movl%ebx, %ebp
 
-#if CONFIG_SYS_SDRAM_ECC_ENABLE
/* A nominal memory test: just a byte at each address line */
movl%eax, %ecx
shrl$0x1, %ecx
@@ -575,6 +549,51 @@ set_ecc:
mov $0x05, %al
movb%al, (%edi)
 #endif
+
 out:
+   jmp *%ebp
+
+/*
+ * Read and decode the sc520 DRCBENDADR MMCR and return the number of
+ * available ram bytes in %eax
+ */
+.globl get_mem_size
+get_mem_size:
+   movl$DRCBENDADR, %edi/* DRAM ending address register  */
+
+bank0: movl(%edi), %eax
+   movl%eax, %ecx
+   andl$0x0080, %ecx
+   jz  bank1
+   andl$0x007f, %eax
+   shll$22, %eax
+   movl%eax, %ebx
+
+bank1: movl(%edi), %eax
+   movl%eax, %ecx
+   andl$0x8000, %ecx
+   jz  bank2
+   andl$0x7f00, %eax
+   shll$14, %eax
+   movl%eax, %ebx
+
+bank2: movl(%edi), %eax
+   movl%eax, %ecx
+   andl$0x0080, %ecx
+   jz  bank3
+   andl$0x007f, %eax
+   shll$6, %eax
+   movl%eax, %ebx
+
+bank3: movl(%edi), %eax
+   movl%eax, %ecx
+   andl$0x8000, %ecx
+   jz  done
+   andl$0x7f00, %eax
+   shrl$2, %eax
+   movl%eax, %ebx
+
+done:
movl%ebx, %eax
jmp *%ebp
+
diff --git a/arch/i386/cpu/start.S b/arch/i386/cpu/start.S
index 25d32e6..1980f1a 100644
--- a/arch/i386/cpu/start.S
+++ b/arch/i386/cpu/start.S
@@ -63,6 +63,11 @@ early_board_init_ret:
jmp mem_init
 mem_init_ret:
 
+   /* fetch memory size (into %eax) */
+   mov $get_mem_size_ret, %ebp
+   jmp get_mem_size
+get_mem_size_ret:
+
/* Check we have enough memory for stack */
movl$CONFIG_SYS_STACK_SIZE, %ecx
cmpl%ecx, %eax
-- 
1.7.1.rc1.12.ga601

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


[U-Boot] [PATCH v3 05/26] [x86] Fix do_go_exec()

2010-04-23 Thread Graeme Russ
This was broken a long time ago by a49864593e083a5d0779fb9ca98e5a0f2053183d
which munged the NIOS and x86 do_go_exec()

Signed-off-by: Graeme Russ 
---
 arch/i386/lib/board.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/i386/lib/board.c b/arch/i386/lib/board.c
index af81cd5..5e28c6f 100644
--- a/arch/i386/lib/board.c
+++ b/arch/i386/lib/board.c
@@ -422,10 +422,10 @@ void hang (void)
 unsigned long do_go_exec (ulong (*entry)(int, char *[]), int argc, char 
*argv[])
 {
/*
-* TODO: Test this function - changed to fix compiler error.
-* Original code was:
-*   return (entry >> 1) (argc, argv);
-* with a comment about Nios function pointers are address >> 1
+* x86 does not use a dedicated register to pass the pointer
+* to the global_data
 */
+   argv[-1] = (char *)gd;
+
return (entry) (argc, argv);
 }
-- 
1.7.1.rc1.12.ga601

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


[U-Boot] [PATCH v3 03/26] [x86] Fix MMCR Access

2010-04-23 Thread Graeme Russ
Change sc520 MMCR Access to use memory accessor functions

Signed-off-by: Graeme Russ 
---
 arch/i386/cpu/sc520/sc520.c   |   33 --
 arch/i386/cpu/sc520/sc520_pci.c   |   24 ++
 arch/i386/cpu/sc520/sc520_ssi.c   |   27 ++--
 arch/i386/cpu/sc520/sc520_timer.c |   31 +++--
 board/eNET/eNET.c |   86 ++--
 5 files changed, 106 insertions(+), 95 deletions(-)

diff --git a/arch/i386/cpu/sc520/sc520.c b/arch/i386/cpu/sc520/sc520.c
index 4b566a7..519bfd8 100644
--- a/arch/i386/cpu/sc520/sc520.c
+++ b/arch/i386/cpu/sc520/sc520.c
@@ -44,24 +44,24 @@ void init_sc520(void)
/* Set the UARTxCTL register at it's slower,
 * baud clock giving us a 1.8432 MHz reference
 */
-   sc520_mmcr->uart1ctl = 0x07;
-   sc520_mmcr->uart2ctl = 0x07;
+   writeb(0x07, &sc520_mmcr->uart1ctl);
+   writeb(0x07, &sc520_mmcr->uart2ctl);
 
/* first set the timer pin mapping */
-   sc520_mmcr->clksel = 0x72;  /* no clock frequency selected, use 
1.1892MHz */
+   writeb(0x72, &sc520_mmcr->clksel);  /* no clock frequency selected, 
use 1.1892MHz */
 
/* enable PCI bus arbitrer */
-   sc520_mmcr->sysarbctl = 0x02;   /* enable concurrent mode */
+   writeb(0x02, &sc520_mmcr->sysarbctl);   /* enable concurrent mode */
 
-   sc520_mmcr->sysarbmenb = 0x1f;  /* enable external grants */
-   sc520_mmcr->hbctl = 0x04;   /* enable posted-writes */
+   writeb(0x1f, &sc520_mmcr->sysarbmenb);  /* enable external grants */
+   writeb(0x04, &sc520_mmcr->hbctl);   /* enable posted-writes */
 
if (CONFIG_SYS_SC520_HIGH_SPEED) {
-   sc520_mmcr->cpuctl = 0x02;  /* set it to 133 MHz and write 
back */
+   writeb(0x02, &sc520_mmcr->cpuctl);  /* set it to 133 MHz 
and write back */
gd->cpu_clk = 13300;
printf("## CPU Speed set to 133MHz\n");
} else {
-   sc520_mmcr->cpuctl = 0x01;  /* set it to 100 MHz and write 
back */
+   writeb(0x01, &sc520_mmcr->cpuctl);  /* set it to 100 MHz 
and write back */
printf("## CPU Speed set to 100MHz\n");
gd->cpu_clk = 1;
}
@@ -74,7 +74,7 @@ void init_sc520(void)
"loop 0b\n": : : "ecx");
 
/* turn on the SDRAM write buffer */
-   sc520_mmcr->dbctl = 0x11;
+   writeb(0x11, &sc520_mmcr->dbctl);
 
/* turn on the cache and disable write through */
asm("movl   %%cr0, %%eax\n"
@@ -88,6 +88,7 @@ unsigned long init_sc520_dram(void)
 
u32 dram_present=0;
u32 dram_ctrl;
+
 #ifdef CONFIG_SYS_SDRAM_DRCTMCTL
/* these memory control registers are set up in the assember part,
 * in sc520_asm.S, during 'mem_init'.  If we muck with them here,
@@ -97,7 +98,8 @@ unsigned long init_sc520_dram(void)
 * simply dictates it.
 */
 #else
-   int val;
+   u8 tmp;
+   u8 val;
 
int cas_precharge_delay = CONFIG_SYS_SDRAM_PRECHARGE_DELAY;
int refresh_rate= CONFIG_SYS_SDRAM_REFRESH_RATE;
@@ -116,9 +118,10 @@ unsigned long init_sc520_dram(void)
val = 3;  /* 62.4us */
}
 
-   sc520_mmcr->drcctl = (sc520_mmcr->drcctl & 0xcf) | (val<<4);
+   tmp = (readb(&sc520_mmcr->drcctl) & 0xcf) | (val<<4);
+   writeb(tmp, &sc520_mmcr->drcctl);
 
-   val = sc520_mmcr->drctmctl & 0xf0;
+   val = readb(&sc520_mmcr->drctmctl) & 0xf0;
 
if (cas_precharge_delay==3) {
val |= 0x04;   /* 3T */
@@ -133,12 +136,12 @@ unsigned long init_sc520_dram(void)
} else {
val |= 1;
}
-   sc520_mmcr->drctmctl = val;
+   writeb(val, &c520_mmcr->drctmctl);
 #endif
 
/* We read-back the configuration of the dram
 * controller that the assembly code wrote */
-   dram_ctrl = sc520_mmcr->drcbendadr;
+   dram_ctrl = readl(&sc520_mmcr->drcbendadr);
 
bd->bi_dram[0].start = 0;
if (dram_ctrl & 0x80) {
@@ -191,7 +194,7 @@ void reset_cpu(ulong addr)
 {
printf("Resetting using SC520 MMCR\n");
/* Write a '1' to the SYS_RST of the RESCFG MMCR */
-   sc520_mmcr->rescfg = 0x01;
+   writeb(0x01, &sc520_mmcr->rescfg);
 
/* NOTREACHED */
 }
diff --git a/arch/i386/cpu/sc520/sc520_pci.c b/arch/i386/cpu/sc520/sc520_pci.c
index f446c6d..ee7e720 100644
--- a/arch/i386/cpu/sc520/sc520_pci.c
+++ b/arch/i386/cpu/sc520/sc520_pci.c
@@ -25,6 +25,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -63,6 +64,8 @@ int sc520_pci_ints[15] = {
 int pci_sc520_set_irq(int pci_pin, int irq)
 {
int i;
+   u8 tmpb;
+   u16 tmpw;
 
 # if 1
printf("set_irq(): map INT%c to IRQ%d\n", pci_pin + 'A', irq);
@@ -80,31 +83,34 @@ int pci_sc520_set_irq(int pci_pin, int irq)
 
/* PCI interrupt mapping (A through D)*/
for (i=0; i<=3 ;i++) {
- 

[U-Boot] [PATCH v3 02/26] [x86] #ifdef out getenv_IPaddr()

2010-04-23 Thread Graeme Russ
Signed-off-by: Graeme Russ 
---
 arch/i386/lib/board.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/i386/lib/board.c b/arch/i386/lib/board.c
index f3b6348..af81cd5 100644
--- a/arch/i386/lib/board.c
+++ b/arch/i386/lib/board.c
@@ -280,8 +280,10 @@ void board_init_r(gd_t *id, ulong ram_start)
show_boot_progress(0x26);
 
 
+#ifdef CONFIG_CMD_NET
/* IP Address */
bd_data.bi_ip_addr = getenv_IPaddr ("ipaddr");
+#endif
 
 #if defined(CONFIG_PCI)
/*
-- 
1.7.1.rc1.12.ga601

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


[U-Boot] [PATCH v3 00/26] [x86] 'Comming of Age'

2010-04-23 Thread Graeme Russ

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


[U-Boot] [PATCH v3 00/26] [x86] 'Comming of Age'

2010-04-23 Thread Graeme Russ
Hello Everyone

Respin of a previous patch set addressing a few minor issues
including:

Version 2:
 - Resolved the PCI_BASE_ADDRESS_1 --> PCI_BASE_ADDRESS_0 modification.
  It turned out to be a PCI region definition issue where the existing
  code was making non-generic assumptions about the allocation of the
  PCI address space. The code which defines PCI regions has been made
  board specific
 - Use asm-generic/unaligned.h
 - Added GPLv2 copyright notice to the RAM sizer code - I contacted AMD
  and asked them to modify the license on thier Code Kit containing
  this code and they have happily obliged
 - Fixed bug in the RAM sizer code which I noticed when comparing the
  now Code Kit code to the existing code
  
Version 3:
 - Added CONFIG_SYS_NS16550_PORT_MAPPED instead of using CONFIG_X86 as
   suggested by Nishanth Menon

This patch series can be examined as several distinct functional changes
 - Patches 1-3 are x86 specific build and core fixups
 - Patches 4-11 are x86 specific functional improvements
 - Patches 12-13 (*) switch the x86 port to CONFIG_SERIAL_MULTI
 - Patches 14-15 provide Linux boot support
 - Patch 16 is an sc520 specific patch (this one can be delayed)
 - Patches 17-18 are various eNET specific patches
 - Patches 19-20 make PCI region initialisation board specific
 - Patch 21 enables the eNET Ethernet chips (requires patched 19-20)
 - Patch 22 sets up the eNET for maximum PC/AT compatibilty to boot Linux
 - Patches 23-24 are eNET 'nice to haves'
 - Patch 25 updates the AMD license to GPL (I have supporting emails)
 - Patch 26 fixes a minor sc520 bug

(*) Patches 12 and 13 are the only patches which touch files outside the
x86 tree.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH] MX51: Fix MX51 CPU detect message

2010-04-23 Thread Fabio Estevam
Fix MX51 CPU detect message.

Original string was: 
CPU:   Freescale i.MX51 family 3.0V at 800 MHz

which can be misinterpreted as  3.0 Volts instead of the silicon revision.

,change it to:
CPU:   Freescale i.MX51 family rev3.0 at 800 MHz

Signed-off-by: Fabio Estevam 

---
 arch/arm/cpu/arm_cortexa8/mx51/soc.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/cpu/arm_cortexa8/mx51/soc.c 
b/arch/arm/cpu/arm_cortexa8/mx51/soc.c
index 2a139b2..f22ebe9 100644
--- a/arch/arm/cpu/arm_cortexa8/mx51/soc.c
+++ b/arch/arm/cpu/arm_cortexa8/mx51/soc.c
@@ -67,7 +67,7 @@ int print_cpuinfo(void)
u32 cpurev;
 
cpurev = get_cpu_rev();
-   printf("CPU:   Freescale i.MX51 family %d.%dV at %d MHz\n",
+   printf("CPU:   Freescale i.MX51 family rev%d.%d at %d MHz\n",
(cpurev & 0xF0) >> 4,
(cpurev & 0x0F) >> 4,
mxc_get_clock(MXC_ARM_CLK) / 100);
-- 
1.6.0.4


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


Re: [U-Boot] Pull request u-boot-marvell.git

2010-04-23 Thread Prafulla Wadaskar
 

> -Original Message-
> From: Tom Rix [mailto:t...@bumblecow.com] 
> Sent: Thursday, April 22, 2010 5:17 AM
> To: Prafulla Wadaskar
> Cc: u-boot@lists.denx.de; Siddarth Gore; Tom Rix
> Subject: Re: [U-Boot] Pull request u-boot-marvell.git
> 
> Prafulla Wadaskar wrote:
> > Hi Tom
> > 
> > Pls pull the following
> > 
> > The following changes since commit 
> 07739bcef5da07cc4a4edef8b91014ccc332eda3:
> >   Stefano Babic (1):
> > Moved board specific values in config file
> > 
> > are available in the git repository at:
> > 
> >   http://git.denx.de/u-boot/u-boot-marvell.git master branch
> > 
> > Frans Meulenbroeks (2):
> >   configs/sheevaplug: added a few additional commands
> >   configs/openrd_base.h: reordered macros
> > 
> > Siddarth Gore (1):
> >   Marvell GuruPlug Board Support
> > 
> >  MAINTAINERS |4 +
> >  MAKEALL |1 +
> >  Makefile|3 +
> >  board/Marvell/guruplug/Makefile |   51 +
> >  board/Marvell/guruplug/config.mk|   27 +
> >  board/Marvell/guruplug/guruplug.c   |  167 
> +
> >  board/Marvell/guruplug/guruplug.h   |   39 +++
> >  board/Marvell/guruplug/kwbimage.cfg |  162 
> 
> >  include/configs/guruplug.h  |  198 
> +++
> >  include/configs/openrd_base.h   |4 +-
> >  include/configs/sheevaplug.h|   27 -
> >  11 files changed, 676 insertions(+), 7 deletions(-)
> >  create mode 100644 board/Marvell/guruplug/Makefile
> >  create mode 100644 board/Marvell/guruplug/config.mk
> >  create mode 100644 board/Marvell/guruplug/guruplug.c
> >  create mode 100644 board/Marvell/guruplug/guruplug.h
> >  create mode 100644 board/Marvell/guruplug/kwbimage.cfg
> >  create mode 100644 include/configs/guruplug.h
> > 
> > Regards..
> > Prafulla . .
> 
> Prafulla,
> These have been applied to arm/master.
> 
> There were some compiler warnings for the new guruplug board.
> kirkwood_egiga.c: In function 'kwgbe_init':
> kirkwood_egiga.c:448: warning: dereferencing type-punned 
> pointer will break 
> strict-aliasing rules
> kirkwood_egiga.c: In function 'kwgbe_recv':
> kirkwood_egiga.c:609: warning: dereferencing type-punned 
> pointer will break 
> strict-aliasing rules
> These should be fixed.

Hi Tom

I have already provided patch for this long back.
I hope this will be pushed up through u-boot-net.git by Ben.

Ref: http://lists.denx.de/pipermail/u-boot/2010-April/069464.html

Hi Ben,
Any comments on this?

Regards..
Prafulla . .

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


[U-Boot] [PATCH RFC] add CONFIG_BOOTCOUNT_LIMIT for MCF5445x

2010-04-23 Thread Wolfgang Wegner
This patch adds bootcount for Freescale MCF5445x. Two registers of
eDMA transfer control descriptors (TCD[1]) are used because these
are unused by linux kernel (freescale LTIB linux-2.6.25) and were
tested to keep their contents across resets.

Signed-off-by: Wolfgang Wegner 
---
I implemented and tested this bootcount on a custom MCF54455 board.
According to the data sheet, the internal SRAM is not supposed to be
useful for data storage across resets. There is no explicit statement
concerning the TCD registers, but in tests on our board the values
did always survive reset. TCD[1] is currently unused by the linux
drivers, so using its registers should be safe up to application start,
where re-setting the bootcount would probably be done anyways.

 arch/m68k/cpu/mcf5445x/cpu.c|   29 +
 arch/m68k/include/asm/immap_5445x.h |1 +
 2 files changed, 30 insertions(+), 0 deletions(-)

diff --git a/arch/m68k/cpu/mcf5445x/cpu.c b/arch/m68k/cpu/mcf5445x/cpu.c
index 6238bc0..70007c1 100644
--- a/arch/m68k/cpu/mcf5445x/cpu.c
+++ b/arch/m68k/cpu/mcf5445x/cpu.c
@@ -110,3 +110,32 @@ int cpu_eth_init(bd_t *bis)
return mcffec_initialize(bis);
 }
 #endif
+
+#ifdef CONFIG_BOOTCOUNT_LIMIT
+/*
+ * We use transfer descriptor registers as a persistent storage
+ * across resets. This was tested on a MCF54455.
+ * Neither U-Boot nor the stock LTIB kernel seem to use
+ * TCD[1], so it should be safe at least until application
+ * start.
+ */
+#include 
+
+void bootcount_store(ulong a)
+{
+   tcd_st *tcd = (tcd_st *)MMAP_TCD;
+
+   __raw_writel(a, &(tcd[1].saddr));
+   __raw_writel(BOOTCOUNT_MAGIC, &(tcd[1].daddr));
+}
+
+ulong bootcount_load(void)
+{
+   tcd_st *tcd = (tcd_st *)MMAP_TCD;
+
+   if (__raw_readl(&(tcd[1].daddr)) != BOOTCOUNT_MAGIC)
+   return 0;
+   else
+   return __raw_readl(&(tcd[1].saddr));
+}
+#endif /* CONFIG_BOOTCOUNT_LIMIT */
diff --git a/arch/m68k/include/asm/immap_5445x.h 
b/arch/m68k/include/asm/immap_5445x.h
index 57cf3ec..d6e416a 100644
--- a/arch/m68k/include/asm/immap_5445x.h
+++ b/arch/m68k/include/asm/immap_5445x.h
@@ -37,6 +37,7 @@
 #define MMAP_EDMA  0xFC044000
 #define MMAP_INTC0 0xFC048000
 #define MMAP_INTC1 0xFC04C000
+#define MMAP_TCD   0xFC045000
 #define MMAP_IACK  0xFC054000
 #define MMAP_I2C   0xFC058000
 #define MMAP_DSPI  0xFC05C000
-- 
1.5.6.5

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


Re: [U-Boot] [PATCH V2] Moved board specific values in config file

2010-04-23 Thread Stefano Babic
Liu Hui-R64343 wrote:
> Stefano ,
> 
Hi Jason,

>>  
>> +#define CONFIG_SYS_DDR_CLKSEL   0
>> +#define CONFIG_SYS_CLKTL_CBCDR  0x59E35100
> 
> It's nice to have some comments about the value selected.

This patch is more as one month old and was already merged into the
mainline, so we need a new patch to for setting a comment.
As your comment regards only the description to a configuration value, I
will not do it now. However, I write down your comment for the next time
this file will be changed ;)

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] Adding new architecture (nds32) support to u-boot

2010-04-23 Thread Marek Vasut
Dne Pá 23. dubna 2010 05:42:13 macp...@andestech.com napsal(a):
> Hi Wolfgang,
> 
> 
> 
> I’m working for Andestech, which is a RISC IP (NDS32) company in Taiwan.
> 
> This company has been started for 5 years.
> 
> In recent , we are planning to release source code such as Linux Kernel and
> GNU toolchain back to communities.
> 
> We also plan to commit code to u-boot.
> 
> 
> 
> I’ve read some materials on u-boot wiki.
> 
> It seems other architectures will maintain their own u-boot git, and you
> will merge their code into your mainline trunk.
> 
> If we want to init a new u-boot git repository for our architecture, should
> we just follow the instructions wrote in
> http://www.denx.de/wiki/U-Boot/CustodianGitTrees “?

Should be OK.
> 
> Since our toolchain haven’t been commit to GNU, could we commit code to
> u-boot before GNU accept our toolchain support?
> 
> Is there anything special that we must provide to you?
> 
> 
> 
> Thanks for your replying.
> 
> 
> 
> Best regards,
> 
> Macpaul Lin
> Mobile: +886-919380156
> 
> Software Engineer
> (Andes Tech.)
> 
> 
> 2F, No.1, Li-Hsin First Road, Science-Based Industrial Park,
> Hsinchu 300, Taiwan, R.O.C.
> Tel: +886-3-6668300 #379
> Fax: +886-3-6668322
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 2/4] mpc832x: add support for the mpc8321 based suvd3 board

2010-04-23 Thread Heiko Schocher
Hello Wolfgang,

Wolfgang Denk wrote:
> In message <4bc2ccbe.6060...@denx.de> you wrote:
>> - serial console on UART1
>> - Ethernet RMII over UCC4
>> - PHY SMSC LAN8700
>> - 64MB Flash
>> - 128 MB DDR2 RAM
>> - I2C
>> - bootcount
>>
>> This board is similiar to the kmeter1 (8360) board,
>> so common config options are extracted into the
>> include/configs/km83xx-common.h file.
> 
>> --- a/board/keymile/kmeter1/kmeter1.c
>> +++ b/board/keymile/km83xx/km83xx.c
>> @@ -11,6 +11,9 @@
>>   * (C) Copyright 2008
>>   * Heiko Schocher, DENX Software Engineering, h...@denx.de.
>>   *
>> + * (C) Copyright 2009
>> + * Heiko Schocher, DENX Software Engineering, h...@denx.de.
>> + *
> 
> Please use a single entry and use "2008-2009" instead. Please fix
> globally.
> 
> Or is this 2010 actually?

It is 2008-2010, fixed.

>> +#if defined(CONFIG_SUVD3)
>> +const uint upma_table[] =
>> +{ 0x1ffedc00, 0x0ffcdc80, 0x0ffcdc80, 0x0ffcdc04, //Words 0 to 3
>> +  0x0ffcdc00, 0xcc00, 0xcc01, 0xfc01, //Words 4 to 7
>> +  0xfc01, 0xfc01, 0xfc01, 0xfc01, //Words 8 to 11
>> +  0xfc01, 0xfc01, 0xfc01, 0xfc01, //Words 12 to 15
>> +  0xfc01, 0xfc01, 0xfc01, 0xfc01, //Words 16 to 19
>> +  0xfc01, 0xfc01, 0xfc01, 0xfc01, //Words 20 to 23
>> +  0x9cfffc00, 0x00fffc80, 0x00fffc80, 0x00fffc00, //Words 24 to 27
>> +  0xec04, 0xec01, 0xfc01, 0xfc01, //Words 28 to 31
>> +  0xfc01, 0xfc01, 0xfc01, 0xfc01, //Words 32 to 35
>> +  0xfc01, 0xfc01, 0xfc01, 0xfc01, //Words 36 to 39
>> +  0xfc01, 0xfc01, 0xfc01, 0xfc01, //Words 40 to 43
>> +  0xfc01, 0xfc01, 0xfc01, 0xfc01, //Words 44 to 47
>> +  0xfc01, 0xfc01, 0xfc01, 0xfc01, //Words 48 to 51
>> +  0xfc01, 0xfc01, 0xfc01, 0xfc01, //Words 52 to 55
>> +  0xfc01, 0xfc01, 0xfc01, 0xfc01, //Words 56 to 59
>> +  0xfc01, 0xfc01, 0xfc01, 0xfc01  //Words 60 to 63
>> +};
>> +#endif
> 
> No C++ comments, please. Please fix globally.

fixed.

>>  int checkboard (void)
>>  {
>> -puts ("Board: Keymile kmeter1");
>> +puts ("Board: Keymile ");
>> +puts(CONFIG_KM_BOARD_NAME);
> 
> Please write:
> 
>   puts("Board: Keymile " CONFIG_KM_BOARD_NAME);

fixed.

>> --- a/cpu/mpc83xx/cpu.c
>> +++ b/cpu/mpc83xx/cpu.c
>> @@ -305,7 +305,7 @@ int cpu_mmc_init(bd_t *bis)
>>
>>  #ifdef CONFIG_BOOTCOUNT_LIMIT
>>
>> -#if !defined(CONFIG_MPC8360)
>> +#if !defined(CONFIG_MPC8360) && !defined(CONFIG_MPC832x)
>>  #error "CONFIG_BOOTCOUNT_LIMIT only for MPC8360 implemented"
> 
> Code and comments don't agree.
> 
> And please keep list sorted (832x < 8360). Please fix globally.

fixed.

> ...
>> +#undef CONFIG_DDR_ECC
>> +
>> +/*
>> + * DDRCDR - DDR Control Driver Register
>> + */
>> +
>> +#undef CONFIG_SPD_EEPROM/* Do not use SPD EEPROM for DDR setup */
> 
> No need to undefine what is not defined anyway.

Yep.

>> +/*
>> + * Manually set up DDR parameters
>> + */
>> +#define CONFIG_DDR_II
>> +#define CONFIG_SYS_DDR_SIZE 2048 /* MB */
> 
> Do you use get_ram_size() for auto-sizing?

Yes, this is the maximum size ...

>> +#if (CONFIG_SYS_MONITOR_BASE < CONFIG_SYS_FLASH_BASE)
>> +#define CONFIG_SYS_RAMBOOT
>> +#else
>> +#undef  CONFIG_SYS_RAMBOOT
>> +#endif
> 
> Please do not #undef what is not defined - please fix globally.

OK, fixed.

>> +/*
>> + * Initial RAM Base Address Setup
>> + */
>> +#define CONFIG_SYS_INIT_RAM_LOCK1
>> +#define CONFIG_SYS_INIT_RAM_ADDR0xE600 /* Initial RAM address */
>> +#define CONFIG_SYS_INIT_RAM_END 0x1000 /* End of used area in RAM */
>> +#define CONFIG_SYS_GBL_DATA_SIZE0x100 /* num bytes initial data */
>> +#define CONFIG_SYS_GBL_DATA_OFFSET  (CONFIG_SYS_INIT_RAM_END - 
>> CONFIG_SYS_GBL_DATA_SIZE)
> 
> Line too long. please fix globally.

Ok.

> ...
>> +#ifndef CONFIG_SYS_RAMBOOT
> ...
>> +#else /* CFG_RAMBOOT */
> ...
>> +#endif /* CFG_RAMBOOT */
> 
> CFG_RAMBOOT ??? Seems this needs cleanup.

Yep.

>> +#if defined(CFG_RAMBOOT)
>> +#undef CONFIG_CMD_SAVEENV
>> +#undef CONFIG_CMD_LOADS
> 
> Why?

Good question ... I delete this.

>> +#define CONFIG_EXTRA_ENV_SETTINGS \
>> +   CONFIG_KM_DEF_ENV\
>> +   CONFIG_KM_DEF_ROOTPATH   
>> \
>> +"dtt_bus=pca9547:70:a\0"\
>> +"EEprom_ivm=pca9547:70:9\0" \
>> +"newenv="   \
>> +"prot off 0xF00C +0x4 && "  \
>> +"era 0xF00C +0x4\0" \
>> +"unlock=yes\0"  \
>> +""
> 
> Indentation by TAB only. Please fix globally.

fixed.

Thanks for the review.

bye
Heiko
-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 

Re: [U-Boot] [PATCH 07/17] SPEAr : Network driver support added

2010-04-23 Thread Armando VISCONTI
Ben,

I have a specific question on the way we handle phy address
in SPEAr.
>> +
>> +static u8 find_phy(struct eth_device *dev)
>> +{
>> +u8 phy_addr = 0;
>> +u16 ctrl, oldctrl;
>> +
>> +do {
>> +eth_mdio_read(dev, phy_addr, PHY_BMCR,&ctrl);
>> +oldctrl = ctrl&  PHY_BMCR_AUTON;
>> +
>> +ctrl ^= PHY_BMCR_AUTON;
>> +eth_mdio_write(dev, phy_addr, PHY_BMCR, ctrl);
>> +eth_mdio_read(dev, phy_addr, PHY_BMCR,&ctrl);
>> +ctrl&= PHY_BMCR_AUTON;
>> +
>> +if (ctrl == oldctrl) {
>> +phy_addr++;
>> +} else {
>> +ctrl ^= PHY_BMCR_AUTON;
>> +eth_mdio_write(dev, phy_addr, PHY_BMCR, ctrl);
>> +break;
>> +}
>> +} while (phy_addr<  32);
>> +
>> +return phy_addr;
>> +}
>> +
>> 
As you can see we use an auto-probing mechanism implemented as find_phy()
routine. This auto-probing is also used in other cases, like the
drivers/net/mcfmii.c (mii_discover_phy()).

Actually I'm not sure this auto-probing mechanism is correct, as it 
works only
in case (very used) in which the MAC-PHY are in 1:1 relationship.

Instead, the MDIO bus nature implies that there might be N MACs and M 
PHYs connected
to the bus, so the auto-probing would not work.

See here some comments on the same:
http://lists.ozlabs.org/pipermail/devicetree-discuss/2010-February/001670.html


In our PCB we have the 1:1 relationship, but since the dw_eth.c driver 
is generic, it
might be used on differently designed pcb.

What is your general opinion in that?
Should we implement it differently?

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


Re: [U-Boot] UBI partigion in u-boot

2010-04-23 Thread Ewer, Edward E
Excuse me, I forgot to paste in the u-boot output:
=> nand info
 
Device 0: nand0, sector size 128 KiB
=> nand erase
 
NAND erase: device 0 whole chip
Bad block table found at page 524224, version 0x01
Bad block table found at page 524160, version 0x01
nand_read_bbt: Bad block at 0x006c
nand_read_bbt: Bad block at 0x0ab4
nand_read_bbt: Bad block at 0x0d02
nand_read_bbt: Bad block at 0x0d60
nand_read_bbt: Bad block at 0x135a
nand_read_bbt: Bad block at 0x1d50
nand_read_bbt: Bad block at 0x1d52
nand_read_bbt: Bad block at 0x1d60
nand_read_bbt: Bad block at 0x1d62
nand_read_bbt: Bad block at 0x1dea
nand_read_bbt: Bad block at 0x299e
nand_read_bbt: Bad block at 0x2b8e
nand_read_bbt: Bad block at 0x2cc4
nand_read_bbt: Bad block at 0x3b78
nand_read_bbt: Bad block at 0x3fb4
nand_read_bbt: Bad block at 0x3fbc
Skipping bad block at  0x006c
Skipping bad block at  0x0ab4
Skipping bad block at  0x0d02
Skipping bad block at  0x0d60
Skipping bad block at  0x135a
Skipping bad block at  0x1d50
Skipping bad block at  0x1d52
Skipping bad block at  0x1d60
Skipping bad block at  0x1d62
Skipping bad block at  0x1dea
Skipping bad block at  0x299e
Skipping bad block at  0x2b8e
Skipping bad block at  0x2cc4
Skipping bad block at  0x3b78
Skipping bad block at  0x3fb4
Skipping bad block at  0x3fbc
Skipping bad block at  0x3ff8
Skipping bad block at  0x3ffa
Skipping bad block at  0x3ffc
Skipping bad block at  0x3ffe
 
OK
=> mtdparts
 
device nand0 , # parts = 1
 #: namesizeoffset  mask_flags
 0: rootfs  0x0400  0x  0
 
active partition: nand0,0 - (rootfs) 0x0400 @ 0x
 
defaults:
mtdids  : nand0=nand
mtdparts: mtdparts=nand:64m(rootfs)
=> ubi part rootfs
Creating 1 MTD partitions on "nand0":
0x-0x0400 : "mtd=0"
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:129024 bytes
UBI: smallest flash I/O unit:2048
UBI: sub-page size:  512
UBI: VID header offset:  512 (aligned 512)
UBI: data offset:2048
UBI: empty MTD device detected
UBI: create volume table (copy #1)
UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB 0:512,
written 0 bytes
UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB 1:512,
written 0 bytes
UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB 2:512,
written 0 bytes
UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB 3:512,
written 0 bytes
UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB 4:512,
written 0 bytes
UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB 5:512,
written 0 bytes
UBI error: ubi_init: cannot attach mtd1
UBI error: ubi_init: UBI error: cannot initialize UBI, error -5
UBI init error -5
exit not allowed from main input shell.
=> nand info
 
Device 0: nand0, sector size 128 KiB
=> ver
 
U-Boot 2010.03-00150-ga47a12b-dirty (Apr 23 2010 - 06:22:06)
=>
 
Thanks,
Edward



From: Ewer, Edward E 
Sent: Friday, April 23, 2010 6:39 AM
To: 'u-boot@lists.denx.de'
Subject: UBI partigion in u-boot


I'm using a MPC8572DS evaluation system and attempting to set up a UBI
file system from u-boot.  I've seen a similar thread with similar errors
but my error isn't being caused by the define CONFIG_SYS_MALLOC_LEN
being too small (it's set for 1M).
 
I'm just starting with UBI/UBIFS and hoping someone could give me some
insight into what may be causing these errors.
 
Here is my u-boot output:
 
 
 
Thanks,
Edward
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] UBI partigion in u-boot

2010-04-23 Thread Ewer, Edward E
I'm using a MPC8572DS evaluation system and attempting to set up a UBI
file system from u-boot.  I've seen a similar thread with similar errors
but my error isn't being caused by the define CONFIG_SYS_MALLOC_LEN
being too small (it's set for 1M).
 
I'm just starting with UBI/UBIFS and hoping someone could give me some
insight into what may be causing these errors.
 
Here is my u-boot output:
 
 
 
Thanks,
Edward
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] Layout of OOB data in NAND flash

2010-04-23 Thread Gaer, A.
Hi!

It seems like the layout of OOB/4-Bit-ECC data in NAND flash differs from 
RBL/UBL to u-boot/linux (at least on a DM365 device). Is there any good reason 
for this?

As far as I understand, the RBL/UBL uses this layout (2048 byte pages):

(E = ECC byte, X = other oob)

XXEE

XXEE

XXEE

XXEE


The u-boot/linux drivers seems to use this instead:









 
The ECC bytes seem to be packed in the same way, though.

The different layout means that it is impossible to update UBL/u-boot from 
u-boot or linux.

I would really like to add a config option to u-boot/linux that enables the 
RBL/UBL layout also in u-boot/linux. Any objections to this?

Another question: 512 byte pages in linux seem to have a really funny oob layout

EXEE
XEEE

Does anybody know the reason for that? (I know the 6th byte is the manufacturer 
bad-block marker. But why not just put the ECC data into the last 10 byte of 
oob like RBL/UBL do it?)

Regards,
 Andreas.

___

Andreas Gäer, Senior Software Engineer

Basler Vision Technologies
An der Strusbek 60-62
22926 Ahrensburg
Germany

Tel. +49 (0) 4102 - 463 517
Fax +49 (0) 4102 - 463 46 517 

mailto:andreas.g...@baslerweb.com
http://www.baslerweb.com

Vorstand: Dr.-Ing. Dietmar Ley (Vorsitzender) · John P. Jennings · 
Aufsichtsratsvorsitzender: Norbert Basler Basler AG · Amtsgericht Ahrensburg 
HRB 4090 · Ust-IdNr.: DE 135 098 121 · Steuer-Nr.: 30 292 04497 · WEEE-Reg.-Nr. 
DE 83888045

___


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


Re: [U-Boot] [PATCH V2] Moved board specific values in config file

2010-04-23 Thread Liu Hui-R64343
Stefano ,

> -Original Message-
> From: u-boot-boun...@lists.denx.de 
> [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Stefano Babic
> Sent: 2010年3月28日 19:43
> To: u-boot@lists.denx.de
> Subject: [U-Boot] [PATCH V2] Moved board specific values in 
> config file
> 
> The lowlevel_init file contained some hard-coded values to 
> setup the RAM. These board related values are moved into the 
> board configuration file.
> 
> Signed-off-by: Stefano Babic 
> ---
>  cpu/arm_cortexa8/mx51/lowlevel_init.S |5 -
>  include/configs/mx51evk.h |3 +++
>  2 files changed, 7 insertions(+), 1 deletions(-)
> 
> diff --git a/cpu/arm_cortexa8/mx51/lowlevel_init.S 
> b/cpu/arm_cortexa8/mx51/lowlevel_init.S
> index 31af9e2..783c81f 100644
> --- a/cpu/arm_cortexa8/mx51/lowlevel_init.S
> +++ b/cpu/arm_cortexa8/mx51/lowlevel_init.S
> @@ -158,6 +158,7 @@
>   /* Switch peripheral to PLL 3 */
>   ldr r0, =CCM_BASE_ADDR
>   ldr r1, =0x10C0
> + orr r1,r1,#CONFIG_SYS_DDR_CLKSEL
>   str r1, [r0, #CLKCTL_CBCMR]
>   ldr r1, =0x13239145
>   str r1, [r0, #CLKCTL_CBCDR]
> @@ -171,6 +172,7 @@
>   ldr r1, =0x19239145
>   str r1, [r0, #CLKCTL_CBCDR]
>   ldr r1, =0x20C0
> + orr r1,r1,#CONFIG_SYS_DDR_CLKSEL
>   str r1, [r0, #CLKCTL_CBCMR]
>  
>   mov r3, #DP_OP_216
> @@ -201,9 +203,10 @@
>   /* setup the rest */
>   /* Use lp_apm (24MHz) source for perclk */
>   ldr r1, =0x20C2
> + orr r1,r1,#CONFIG_SYS_DDR_CLKSEL
>   str r1, [r0, #CLKCTL_CBCMR]
>   /* ddr clock from PLL 1, all perclk dividers are 1 
> since using 24MHz */
> - ldr r1, =0x59E35100
> + ldr r1, =CONFIG_SYS_CLKTL_CBCDR
>   str r1, [r0, #CLKCTL_CBCDR]
>  
>   /* Restore the default values in the Gate registers */ 
> diff --git a/include/configs/mx51evk.h 
> b/include/configs/mx51evk.h index e2daeca..5096ab7 100644
> --- a/include/configs/mx51evk.h
> +++ b/include/configs/mx51evk.h
> @@ -177,6 +177,9 @@
>  #define PHYS_SDRAM_1 CSD0_BASE_ADDR
>  #define PHYS_SDRAM_1_SIZE(512 * 1024 * 1024)
>  
> +#define CONFIG_SYS_DDR_CLKSEL0
> +#define CONFIG_SYS_CLKTL_CBCDR   0x59E35100

It's nice to have some comments about the value selected.

> +
>  
> /*
> ---
>   * FLASH and environment organization
>   */
> --
> 1.6.3.3
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
> 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] Facing problems in Porting U-boot to MIPS32 (Au1350)

2010-04-23 Thread Wolfgang Denk
Dear Gurumurthy G M,

please do not top post / full quote.

And do not ask questions you have just asked a few hours before.

In message <5858de952c53a441bda3408a0524130104cce...@mkegmal01> you wrote:
> 
> 
> let me know if anyone have ported u-boot to MIPS32.

Why don't you have a look yourself at the existing code? There are a
number of MIPS32 based boards supported by U-Boot.


I have to admit that I don;t remember the situation in the historic
1.2.0 version you seem to be using - don't expect much help for this
old stuff.  For recent work, you really should use recent code (i. e.
topof tree from git repository, or at least v2010.03).

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 you're not part of the solution, you're part of the problem.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] PULL REQUEST (for "next"): please pull u-boot-mpc5xxx

2010-04-23 Thread Wolfgang Denk
Dear Anatolij,

In message <20100423102809.5afa8...@wker> you wrote:
> 
> > [I'll leave this code as is in the u-boot-mpc5xxx repo for now, but I
> > will rebase this as soon as you submit a fix.]
> 
> What would be the best way to proceed here? I submitted separate
> patch to fix this, "serial: fix struct serial_device initialisation".
> It is based on u-boot-mpc5xxx repo. But since the directory structure
> has been changed now I think that better would be to revert these
> four patches in the u-boot-mpc5xxx repo. I can submit rebased
> patches which also address this breakage. I also noticed that
> adding post_word_load/store to cpu/mpc512x/commproc.c as one patch
> does, is actually wrong. So I need to address this, too.

I would appreciate if you could submit rebased (against current master
branch) patches. Thanks in advance.

Best regards,

Wolfgang Denk

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


  1   2   >