Re: [U-Boot] IXP425 TEXT_BASE

[Teh Kok How]

Hmmm...I can answer myself now. The flash programmer programs the content
from TEXT_BASE to end of the u-boot image into flash start location
0x5000_. When u-boot boots, it relocates itself from flash to DRAM
location @TEXT_BASE. I still haven't managed to bring up the board. Guess
there are some GPIO pins which I have not initialized properly.

-Original Message-
From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On
Behalf Of Teh Kok How
Sent: Wednesday, August 05, 2009 11:22 AM
To: 'Wolfgang Denk'; 'Darius Augulis'
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] IXP425 TEXT_BASE

Hi;
I understand Wolfgang's argument but setting the TEXT_BASE to this
arbitrary high address (DRAM_end - U-boot_size(_end - _start)) does not make
sense. I am new to ARM arch but in PowerPC and MIPS, the TEXT_BASE is always
set to the reset vector and in ARM, the reset vector is at 0 or 0x.
I have tried both values but still failed to boot u-boot on the board:-(

Regards,
Teh

-Original Message-
From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On
Behalf Of Wolfgang Denk
Sent: Tuesday, August 04, 2009 11:57 PM
To: Darius Augulis
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] IXP425 TEXT_BASE

Dear Darius Augulis,

In message <4a784702.40...@gmail.com> you wrote:
>
> > No. TEXT_BASE is an absolute address.
> 
> yes, but depends on the physical RAM base and size.

Only on ARM (and other architectures that copied it's broken
implementation). TEXT_BASE is an absolute address (in the boot flash)
on PowerPC.

> could you please explain more? why to the end of RAM?

YOu want to have a maximum of contiguous RAM available to load Linux
kernel, ramdisk images etc.

> for example I have 16MB RAM, base is 0x1000. TEXT_BASE = 0x1040.
> Why is better to set this to 0x10F0 ? To have more stack and malloc 
> memory? But U-boot will never exceed such limit? Please explain where I 
> am wrong. Thanks!

With RAM from 0x1000...0x10ff you should probably put
TEXT_BASE at 0x10f8 which then would leave you some 15 MB of
contiguous RAM for your use.

With your setup you jusy have some 3+ MB below U-Boot and some 11+ MB
above it. It makes not much sense to have U-Boot sitting right in the
middle of precious RAM like this.

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 idea of male and female are universal constants.
-- Kirk, "Metamorphosis", stardate 3219.8
___
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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] stx: create common vendor hierarchy for Silicon Turnkey boards

[Alex Dubov]

Just a general observation: if you are not sure that tlb/law files can be
safely factored out and most of the ddr.c files are actually board specific
overrides (common part being less than 10 lines) why had you requested me
to create a common board hierarchy for these STX boards in the first place?

For all I can see, they don't have any common, vendor specific hardware.

I still want my board supported, so I propose you decide how do you want
them arranged (vendor/board/ or just board/) and I'll limit my contribution
to my board's files exclusively.

After all, I don't work for Silicon Turnkey and it starts taking too much
time.







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

Re: [U-Boot] IXP425 TEXT_BASE

[Teh Kok How]

Hi;
I understand Wolfgang's argument but setting the TEXT_BASE to this
arbitrary high address (DRAM_end - U-boot_size(_end - _start)) does not make
sense. I am new to ARM arch but in PowerPC and MIPS, the TEXT_BASE is always
set to the reset vector and in ARM, the reset vector is at 0 or 0x.
I have tried both values but still failed to boot u-boot on the board:-(

Regards,
Teh

-Original Message-
From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On
Behalf Of Wolfgang Denk
Sent: Tuesday, August 04, 2009 11:57 PM
To: Darius Augulis
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] IXP425 TEXT_BASE

Dear Darius Augulis,

In message <4a784702.40...@gmail.com> you wrote:
>
> > No. TEXT_BASE is an absolute address.
> 
> yes, but depends on the physical RAM base and size.

Only on ARM (and other architectures that copied it's broken
implementation). TEXT_BASE is an absolute address (in the boot flash)
on PowerPC.

> could you please explain more? why to the end of RAM?

YOu want to have a maximum of contiguous RAM available to load Linux
kernel, ramdisk images etc.

> for example I have 16MB RAM, base is 0x1000. TEXT_BASE = 0x1040.
> Why is better to set this to 0x10F0 ? To have more stack and malloc 
> memory? But U-boot will never exceed such limit? Please explain where I 
> am wrong. Thanks!

With RAM from 0x1000...0x10ff you should probably put
TEXT_BASE at 0x10f8 which then would leave you some 15 MB of
contiguous RAM for your use.

With your setup you jusy have some 3+ MB below U-Boot and some 11+ MB
above it. It makes not much sense to have U-Boot sitting right in the
middle of precious RAM like this.

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 idea of male and female are universal constants.
-- Kirk, "Metamorphosis", stardate 3219.8
___
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] [PATCH] stx: create common vendor hierarchy for Silicon Turnkey boards

[Alex Dubov]

> > 
> > Move board definition files for STx XTC, GP3 and SSA
> boards into
> > common subdirectory and factor out common code.
> > 
> > "-mno-spe" flag common to all MPC85xx configurations
> does not work
> > so change it to "-mspe=no" which does (GCC bug
> 37759).
> > 
> > Signed-off-by: Alex Dubov 
> ...
> > --- a/board/stxgp3/Makefile
> > +++ b/board/stx/common/Makefile
> > @@ -1,5 +1,5 @@
> >  #
> > -# (C) Copyright 2001-2006
> > +# (C) Copyright 2006
> >  # Wolfgang Denk, DENX Software Engineering, w...@denx.de.
> 
> How comes?

Git is confused somehow.
I don't see this change in my tree.

> 
> > @@ -31,30 +31,34 @@
> >   * LAW(Local Access Window)
> configuration:
> >   *
> >   * 0x_ 
>    0x7fff_ 
>    DDR         
>            2G
> > - * 0x8000_ 
>    0x9fff_     PCI1
> MEM               
> 512M
> > - * 0xa000_ 
>    0xbfff_     PCI2
> MEM               
> 512M
> > + * 0x8000_ 
>    0x9fff_ 
>    PCI1         
>           512M
> > + * 0xa000_ 
>    0xbfff_ 
>    PCI2         
>           512M
> > + * 0xc000_ 
>    0xdfff_ 
>    RapidIO         
>        512M
> >   * 0xe000_ 
>    0xe000_ 
>    CCSR         
>           1M
> >   * 0xe200_ 
>    0xe2ff_     PCI1
> IO             
>    16M
> >   * 0xe300_ 
>    0xe3ff_     PCI2
> IO             
>    16M
> > - * 0xf000_ 
>    0xfaff_     Local
> bus           
>    128M
> > - * 0xfb00_ 
>    0xfb00_     Config
> Latch            64K
> > - * 0xfc00_ 
>    0x_     FLASH
> (boot bank)       64M
> > + * 0xf000_ 
>    0x_     LBC
> options + FLASH     256M
> 
> Are you sure this is correct?

Yes, this will cover all three boards affected by the change.
They all have their address maps set in similar fashion.


> 
> >  struct law_entry law_table[] = {
> > -#ifndef CONFIG_SPD_EEPROM
> > -    SET_LAW(CONFIG_SYS_DDR_SDRAM_BASE,
> LAW_SIZE_128M, LAW_TRGT_IF_DDR),
> > +#ifdef CONFIG_SYS_PCI1_MEM_PHYS
> > +    SET_LAW(CONFIG_SYS_PCI1_MEM_PHYS,
> LAW_SIZE_512M, LAW_TRGT_IF_PCI),
> > +    SET_LAW(CONFIG_SYS_PCI1_IO_PHYS,
> LAW_SIZE_16M, LAW_TRGT_IF_PCI),
> >  #endif
> > -    SET_LAW(CONFIG_SYS_PCI1_MEM_PHYS,
> LAW_SIZE_512M, LAW_TRGT_IF_PCI_1),
> > +#ifdef CONFIG_SYS_PCI2_MEM_PHYS
> >     
> SET_LAW(CONFIG_SYS_PCI2_MEM_PHYS, LAW_SIZE_512M,
> LAW_TRGT_IF_PCI_2),
> > -    SET_LAW(CONFIG_SYS_PCI1_IO_PHYS,
> LAW_SIZE_16M, LAW_TRGT_IF_PCI_1),
> >     
> SET_LAW(CONFIG_SYS_PCI2_IO_PHYS, LAW_SIZE_16M,
> LAW_TRGT_IF_PCI_2),
> > -    /* Map the whole localbus,
> including flash and reset latch. */
> > -   
> SET_LAW(CONFIG_SYS_LBC_OPTION_BASE, LAWAR_SIZE_256M,
> LAW_TRGT_IF_LBC),
> > +#endif
> > +#ifdef CONFIG_SYS_RIO_MEM_PHYS
> > +    SET_LAW(CONFIG_SYS_RIO_MEM_PHYS,
> LAW_SIZE_512M, LAW_TRGT_IF_RIO),
> > +#endif
> > +   
> SET_LAW(CONFIG_SYS_LBC_OPTION_BASE, LAWAR_SIZE_256M,
> LAW_TRGT_IF_LBC)
> >  };
> 
> This looks fishy, too.

Just look at the respective boards' law.c files before the patch.
They all have this entry, either called CONFIG_SYS_LBC_OPTION_BASE or
CONFIG_SYS_LBC_SDRAM_BASE.


> > @@ -31,76 +31,90 @@ struct fsl_e_tlb_entry tlb_table[]
> = {
> >      SET_TLB_ENTRY(0,
> CONFIG_SYS_INIT_RAM_ADDR, CONFIG_SYS_INIT_RAM_ADDR,
> >           
>     MAS3_SX|MAS3_SW|MAS3_SR, 0,
> >           
>     0, 0, BOOKE_PAGESZ_4K, 0),
> > -    SET_TLB_ENTRY(0,
> CONFIG_SYS_INIT_RAM_ADDR + 4 * 1024 ,
> CONFIG_SYS_INIT_RAM_ADDR + 4 * 1024,
> > +    SET_TLB_ENTRY(0,
> CONFIG_SYS_INIT_RAM_ADDR + 4 * 1024,
> > +           
>   CONFIG_SYS_INIT_RAM_ADDR + 4 * 1024,
> >           
>     MAS3_SX|MAS3_SW|MAS3_SR, 0,
> >           
>     0, 0, BOOKE_PAGESZ_4K, 0),
> > -    SET_TLB_ENTRY(0,
> CONFIG_SYS_INIT_RAM_ADDR + 8 * 1024 ,
> CONFIG_SYS_INIT_RAM_ADDR + 8 * 1024,
> > +    SET_TLB_ENTRY(0,
> CONFIG_SYS_INIT_RAM_ADDR + 8 * 1024,
> > +           
>   CONFIG_SYS_INIT_RAM_ADDR + 8 * 1024,
> >           
>     MAS3_SX|MAS3_SW|MAS3_SR, 0,
> >           
>     0, 0, BOOKE_PAGESZ_4K, 0),
> > -    SET_TLB_ENTRY(0,
> CONFIG_SYS_INIT_RAM_ADDR + 12 * 1024 ,
> CONFIG_SYS_INIT_RAM_ADDR + 12 * 1024,
> > +    SET_TLB_ENTRY(0,
> CONFIG_SYS_INIT_RAM_ADDR + 12 * 1024,
> > +           
>   CONFIG_SYS_INIT_RAM_ADDR + 12 * 1024,
> >           
>     MAS3_SX|MAS3_SW|MAS3_SR, 0,
> >           
>     0, 0, BOOKE_PAGESZ_4K, 0),
> 
> Better split code beautifying into separate patch.

I wrote this file from scratch.
Git is confused here.
There's no separate patch.
Same for the other issues here and below.

> 
> 
> Hm... did you actually test these changes on all 4 boards?

There are no real changes. All three boards have nearly identical configs.
stxxtc is only copied around and is not affected by this (no tlbs or law
there).




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

Re: [U-Boot] [PATCH] stx: create common vendor hierarchy for Silicon Turnkey boards

[Kumar Gala]

On Aug 4, 2009, at 6:01 AM, oa...@yahoo.com wrote:

> From: Alex Dubov 
>
> Move board definition files for STx XTC, GP3 and SSA boards into
> common subdirectory and factor out common code.
>
> "-mno-spe" flag common to all MPC85xx configurations does not work
> so change it to "-mspe=no" which does (GCC bug 37759).
>
> Signed-off-by: Alex Dubov 
> ---
> Makefile|6 +-
> board/{stxgp3 => stx/common}/Makefile   |   20 +++--
> board/{stxssa => stx/common}/ddr.c  |   46 ---
> board/{stxssa => stx/common}/law.c  |   30 ---
> board/{stxssa => stx/common}/tlb.c  |   72 ++---
> board/{ => stx}/stxgp3/Makefile |3 -
> board/{ => stx}/stxgp3/config.mk|0
> board/{ => stx}/stxgp3/flash.c  |0
> board/{ => stx}/stxgp3/stxgp3.c |0
> board/{ => stx}/stxgp3/u-boot.lds   |0
> board/{ => stx}/stxssa/Makefile |3 -
> board/{ => stx}/stxssa/config.mk|0
> board/{ => stx}/stxssa/stxssa.c |0
> board/{ => stx}/stxssa/u-boot.lds   |0
> board/{ => stx}/stxxtc/Makefile |0
> board/{ => stx}/stxxtc/config.mk|0
> board/{ => stx}/stxxtc/stxxtc.c |0
> board/{ => stx}/stxxtc/u-boot.lds   |0
> board/{ => stx}/stxxtc/u-boot.lds.debug |0
> board/stxgp3/ddr.c  |   76 --
> board/stxgp3/law.c  |   58 --
> board/stxgp3/tlb.c  |  130  
> ---
> cpu/mpc85xx/config.mk   |2 +-
> include/configs/stxgp3.h|   21 +++--
> include/configs/stxssa.h|   28 ---
> 25 files changed, 135 insertions(+), 360 deletions(-)
> copy board/{stxgp3 => stx/common}/Makefile (82%)
> rename board/{stxssa => stx/common}/ddr.c (57%)
> rename board/{stxssa => stx/common}/law.c (74%)
> rename board/{stxssa => stx/common}/tlb.c (59%)
> rename board/{ => stx}/stxgp3/Makefile (95%)
> rename board/{ => stx}/stxgp3/config.mk (100%)
> rename board/{ => stx}/stxgp3/flash.c (100%)
> rename board/{ => stx}/stxgp3/stxgp3.c (100%)
> rename board/{ => stx}/stxgp3/u-boot.lds (100%)
> rename board/{ => stx}/stxssa/Makefile (95%)
> rename board/{ => stx}/stxssa/config.mk (100%)
> rename board/{ => stx}/stxssa/stxssa.c (100%)
> rename board/{ => stx}/stxssa/u-boot.lds (100%)
> rename board/{ => stx}/stxxtc/Makefile (100%)
> rename board/{ => stx}/stxxtc/config.mk (100%)
> rename board/{ => stx}/stxxtc/stxxtc.c (100%)
> rename board/{ => stx}/stxxtc/u-boot.lds (100%)
> rename board/{ => stx}/stxxtc/u-boot.lds.debug (100%)
> delete mode 100644 board/stxgp3/ddr.c
> delete mode 100644 board/stxgp3/law.c
> delete mode 100644 board/stxgp3/tlb.c

Can you limit the patch that creates board/stx/ to doing just that and  
NOTHING else.  Leave the other clean up and refactoring for other  
patches.

- k

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

Re: [U-Boot] [PATCH] stxamc8548: make environment use one of the smaller "boot" blocks in flash

[Alex Dubov]

> > 
> > Put environment into .ppcenv section aligned on a
> smaller "boot" eraseblock
> > boundary near flash end.
> 
> Hm... if you change to code to using a smaller boot
> sector...
> 
> >  #define CONFIG_ENV_ADDR     
>   (CONFIG_SYS_MONITOR_BASE + 0x38000)
> >  #define
> CONFIG_ENV_SECT_SIZE   0x4000   /*
> 16K(one sector) for env */
> > -#define CONFIG_ENV_SIZE       
> 0x2000
> > +#define CONFIG_ENV_SIZE       
> 0x4000
> 
> ...should then not be CONFIG_ENV_SECT_SIZE changed to some
> smaller
> size, too?
> 

The "large" eraseblock size for this flash config is 128k (2x64k). Small one is 
16k (2x8k).



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

Re: [U-Boot] [PATCH] mxc_nand: add nand driver for MX2/MX3

[Scott Wood]

On Mon, Aug 03, 2009 at 05:45:14AM +0400, Ilya Yanok wrote:
> + if (this->options & NAND_BUSWIDTH_16) {
> + void __iomem *main_buf = host->regs->main_area0;
> + /* compress the ID info */
> + writeb(readb(main_buf + 2), main_buf + 1);
> + writeb(readb(main_buf + 4), main_buf + 2);
> + writeb(readb(main_buf + 6), main_buf + 3);
> + writeb(readb(main_buf + 8), main_buf + 4);
> + writeb(readb(main_buf + 10), main_buf + 5);
> + }

This indicates that read_byte isn't doing what the generic NAND code is
expecting.  It should advance by a word in the buffer for each byte read
-- the implementation of nand_read_byte16 confirms this.

In that case, though, why have separate read_byte and read_word?  Just
to provide an endian-broken alternative, that is only used where
endianness doesn't matter (checking bad block markers)? :-(

> + if (col & 1) {
> + union {
> + uint16_t word;
> + uint8_t bytes[2];
> + } nfc_word;
> +
> + nfc_word.word = readw(p);
> + ret = nfc_word.bytes[1];
> + nfc_word.word = readw(&p[1]);
> + ret |= nfc_word.bytes[0] << 16;

This still has an endian assumption (and shouldn't << 16 be << 8, and
require a cast to avoid shifting beyond the type width?) -- it's moot
given the nature of read_byte and read_word, but if this were necessary
it should be something like:

union {
...
} nfc_word[3];

nfc_word[0] = readw(p);
nfc_word[1] = readw(p + 1);

nfc_word[2].bytes[0] = nfc_word[0].bytes[1];
nfc_word[2].bytes[1] = nfc_word[1].bytes[0];

ret = nfc_word[2].word;

Alternatively, you could apply le16_to_cpu to the result of something
like your version.

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

Re: [U-Boot] [PATCH 1/2] 85xx: CONFIG_MP Boot Page Translation update

[Peter Tyser]

On Fri, 2009-07-24 at 13:18 -0500, Peter Tyser wrote:
> Previously, when CONFIG_MP was defined Boot Page Translation was
> unconditionally enabled and secondary cores were put in a spin loop at
> address 0xf000.  The 0xfxxx address range (ie the Boot Page) was
> being remapped to SDRAM via the BPTR register.
> 
> This change puts secondary cores into spin loops at their 'true' address
> in SDRAM and doesn't require Boot Page Translation to always be enabled.
> The main advantage of this change is that Boot Page Translation can be
> disabled after the secondary cores are brought up which allows the
> memory region at 0xfxxx to be used for other peripherals, etc.
> 
> By default, Boot Page Translation remains enabled while U-Boot executes.
> A new CONFIG_MPC8xxx_DISABLE_BPTR define has been added which causes
> Boot Page Translation to be disabled for those boards which wish to use
> the 0xfxxx address range as part of their normal memory map.

Hi Kumar,
Any chance this patch will get picked up?  Or do you have any requested
changes that need to be made before its accepted?

Thanks,
Peter

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

Re: [U-Boot] [PATCH] tsec: Wait for auto-negotiation to complete without link

[Peter Tyser]

On Sun, 2009-07-19 at 15:14 -0500, Peter Tyser wrote:
> On Wed, 2009-02-04 at 15:14 -0600, Peter Tyser wrote:
> > Previously, waiting for auto-negotiation would only occur if a valid
> > link had been detected.  Problems arose when attempting to use a
> > tsec immediately after bootup but before link was achieved, eg:
> > => dhcp
> > Auto-neg error, defaulting to 10BT/HD
> > eTSEC1: No link.
> > Auto-neg error, defaulting to 10BT/HD
> > eTSEC2: No link.
> > =>
> > 
> > With this patch applied the same operation as above resulted in:
> > => dhcp
> > Waiting for PHY auto negotiation to complete. done
> > Enet starting in 1000BT/FD
> > Speed: 1000, full duplex
> > 
> > Signed-off-by: Peter Tyser 
> 
> This patch originally spawned a lot of discussion but nothing came of
> it.  Could we get it applied?  If not, what do I need to do to get a
> similar change in?
> 
> Right now if you have autoboot enabled that uses network operation, you
> have to add an arbitrary delay to the boot process to give
> autonegotiation time to complete, which is annoying.  The negotiation
> time varies depending on switch too, so the delay can never be exact.

Ping...

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

[U-Boot] [PATCH] xes: Use proper IO access functions

[Peter Tyser]

Also fix some minor whitespace oddities while we're cleaning up

Signed-off-by: Peter Tyser 
---
 board/xes/common/fsl_8xxx_clk.c |6 ++--
 board/xes/common/fsl_8xxx_pci.c |   46 +-
 board/xes/xpedite5200/xpedite5200.c |   17 ++---
 board/xes/xpedite5370/xpedite5370.c |8 +++---
 4 files changed, 38 insertions(+), 39 deletions(-)

diff --git a/board/xes/common/fsl_8xxx_clk.c b/board/xes/common/fsl_8xxx_clk.c
index 0155670..f4a17b7 100644
--- a/board/xes/common/fsl_8xxx_clk.c
+++ b/board/xes/common/fsl_8xxx_clk.c
@@ -21,6 +21,7 @@
  */
 
 #include 
+#include 
 
 /*
  * Return SYSCLK input frequency - 50 MHz or 66 MHz depending on POR config
@@ -33,9 +34,8 @@ unsigned long get_board_sys_clk(ulong dummy)
immap_t *immap = (immap_t *)CONFIG_SYS_IMMR;
volatile ccsr_gur_t *gur = &immap->im_gur;
 #endif
-   u32 gpporcr = gur->gpporcr;
 
-   if (gpporcr & 0x1)
+   if (in_be32(&gur->gpporcr) & 0x1)
return ;
else
return 5000;
@@ -49,7 +49,7 @@ unsigned long get_board_sys_clk(ulong dummy)
 unsigned long get_board_ddr_clk(ulong dummy)
 {
volatile ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
-   u32 ddr_ratio = ((gur->porpllsr) & 0x3e00) >> 9;
+   u32 ddr_ratio = (in_be32(&gur->porpllsr) & 0x3e00) >> 9;
 
if (ddr_ratio == 0x7)
return get_board_sys_clk(dummy);
diff --git a/board/xes/common/fsl_8xxx_pci.c b/board/xes/common/fsl_8xxx_pci.c
index 025cc18..5b281f9 100644
--- a/board/xes/common/fsl_8xxx_pci.c
+++ b/board/xes/common/fsl_8xxx_pci.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -182,18 +183,18 @@ void pci_init_board(void)
immap_t *immap = (immap_t *)CONFIG_SYS_IMMR;
volatile ccsr_gur_t *gur = &immap->im_gur;
 #endif
-   uint devdisr = gur->devdisr;
-   uint io_sel = (gur->pordevsr & MPC8xxx_PORDEVSR_IO_SEL) >>
+   uint devdisr = in_be32(&gur->devdisr);
+   uint io_sel = (in_be32(&gur->pordevsr) & MPC8xxx_PORDEVSR_IO_SEL) >>
MPC8xxx_PORDEVSR_IO_SEL_SHIFT;
-   uint host_agent = (gur->porbmsr & MPC8xxx_PORBMSR_HA) >>
+   uint host_agent = (in_be32(&gur->porbmsr) & MPC8xxx_PORBMSR_HA) >>
MPC8xxx_PORBMSR_HA_SHIFT;
struct pci_region *r;
 
 #ifdef CONFIG_PCI1
-   uint pci_spd_norm = (gur->pordevsr & MPC85xx_PORDEVSR_PCI1_SPD);
-   uint pci_32 = gur->pordevsr & MPC85xx_PORDEVSR_PCI1_PCI32;
-   uint pci_arb = gur->pordevsr & MPC85xx_PORDEVSR_PCI1_ARB;
-   uint pcix = gur->pordevsr & MPC85xx_PORDEVSR_PCI1;
+   uint pci_spd_norm = in_be32(&gur->pordevsr) & MPC85xx_PORDEVSR_PCI1_SPD;
+   uint pci_32 = in_be32(&gur->pordevsr) & MPC85xx_PORDEVSR_PCI1_PCI32;
+   uint pci_arb = in_be32(&gur->pordevsr) & MPC85xx_PORDEVSR_PCI1_ARB;
+   uint pcix = in_be32(&gur->pordevsr) & MPC85xx_PORDEVSR_PCI1;
uint freq = CONFIG_SYS_CLK_FREQ / 1000 / 1000;
 
width = 0; /* Silence compiler warning... */
@@ -203,12 +204,11 @@ void pci_init_board(void)
host = host_agent_cfg[host_agent].pci_host[0];
r = hose->regions;
 
-
if (!(devdisr & MPC85xx_DEVDISR_PCI1)) {
printf("\nPCI1: %d bit %s, %s %d MHz, %s, %s\n",
pci_32 ? 32 : 64,
pcix ? "PCIX" : "PCI",
-   pci_spd_norm ?  ">=" : "<=",
+   pci_spd_norm ? ">=" : "<=",
pcix ? freq * 2 : freq,
host ? "host" : "agent",
pci_arb ? "arbiter" : "external-arbiter");
@@ -250,7 +250,7 @@ void pci_init_board(void)
}
 #elif defined CONFIG_MPC8548
/* PCI1 not present on MPC8572 */
-   gur->devdisr |= MPC85xx_DEVDISR_PCI1; /* disable */
+   out_be32(&gur->devdisr, in_be32(&gur->devdisr) | MPC85xx_DEVDISR_PCI1);
 #endif
 #ifdef CONFIG_PCIE1
pci = (ccsr_fsl_pci_t *) CONFIG_SYS_PCIE1_ADDR;
@@ -262,10 +262,10 @@ void pci_init_board(void)
if (width && !(devdisr & MPC8xxx_DEVDISR_PCIE1)) {
printf("\nPCIE1 connected as %s (x%d)",
host ? "Root Complex" : "End Point", width);
-   if (pci->pme_msg_det) {
-   pci->pme_msg_det = 0x;
+   if (in_be32(&pci->pme_msg_det)) {
+   out_be32(&pci->pme_msg_det, 0x);
debug(" with errors.  Clearing.  Now 0x%08x",
-   pci->pme_msg_det);
+   in_be32(&pci->pme_msg_det));
}
printf("\n");
 
@@ -290,7 +290,7 @@ void pci_init_board(void)
 
hose->first_busno = first_free_busno;
pci_setup_indirect(hose, (int)&pci->cfg_addr,
-   (int) &pci->cfg_data);
+   

[U-Boot] [PATCH] 85xx: Remove unused CONFIG_CLEAR_LAW0 defines

[Peter Tyser]

Signed-off-by: Peter Tyser 
---
 include/configs/ATUM8548.h   |1 -
 include/configs/MPC8548CDS.h |1 -
 include/configs/sbc8548.h|1 -
 3 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/include/configs/ATUM8548.h b/include/configs/ATUM8548.h
index 7ee05e5..91369a7 100644
--- a/include/configs/ATUM8548.h
+++ b/include/configs/ATUM8548.h
@@ -67,7 +67,6 @@
  */
 #define CONFIG_L2_CACHE/* toggle L2 cache */
 #define CONFIG_BTB /* toggle branch predition */
-#define CONFIG_CLEAR_LAW0  /* Clear LAW0 in cpu_init_r */
 
 /*
  * Only possible on E500 Version 2 or newer cores.
diff --git a/include/configs/MPC8548CDS.h b/include/configs/MPC8548CDS.h
index bebb9e9..e69ba90 100644
--- a/include/configs/MPC8548CDS.h
+++ b/include/configs/MPC8548CDS.h
@@ -69,7 +69,6 @@ extern unsigned long get_clock_freq(void);
  */
 #define CONFIG_L2_CACHE/* toggle L2 cache */
 #define CONFIG_BTB /* toggle branch predition */
-#define CONFIG_CLEAR_LAW0  /* Clear LAW0 in cpu_init_r */
 
 /*
  * Only possible on E500 Version 2 or newer cores.
diff --git a/include/configs/sbc8548.h b/include/configs/sbc8548.h
index a2ff955..838b4db 100644
--- a/include/configs/sbc8548.h
+++ b/include/configs/sbc8548.h
@@ -59,7 +59,6 @@
  */
 #define CONFIG_L2_CACHE/* toggle L2 cache */
 #define CONFIG_BTB /* toggle branch predition */
-#define CONFIG_CLEAR_LAW0  /* Clear LAW0 in cpu_init_r */
 
 /*
  * Only possible on E500 Version 2 or newer cores.
-- 
1.6.2.1

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

Re: [U-Boot] [PATCH] NAND boot: fix nand_load overlap issue

[Scott Wood]

On Sun, Jul 19, 2009 at 01:23:43AM +0200, Wolfgang Denk wrote:
> Dear Scott,
> 
> In message <1244170414-4840-1-git-send-email-mingkai...@freescale.com> 
> Mingkai Hu wrote:
> > The code copy data from NAND flash block by block, so when
> > the data length isn't a whole-number multiple of the block
> > size, it will overlap the rest space.
> > 
> > Signed-off-by: Mingkai Hu 
> > ---
> >  nand_spl/nand_boot_fsl_elbc.c |2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> 
> Can you please check the state of this patch? Thanks in advance.

Applied to u-boot-nand-flash.

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

Re: [U-Boot] [PATCH] stxamc8548: make environment use one of the smaller "boot" blocks in flash

[Wolfgang Denk]

Dear oa...@yahoo.com,

In message <1249383697-28141-3-git-send-email-oa...@yahoo.com> you wrote:
> 
> Put environment into .ppcenv section aligned on a smaller "boot" eraseblock
> boundary near flash end.

Hm... if you change to code to using a smaller boot sector...

>  #define CONFIG_ENV_ADDR(CONFIG_SYS_MONITOR_BASE + 0x38000)
>  #define CONFIG_ENV_SECT_SIZE   0x4000   /* 16K(one sector) for env */
> -#define CONFIG_ENV_SIZE0x2000
> +#define CONFIG_ENV_SIZE0x4000

...should then not be CONFIG_ENV_SECT_SIZE changed to some smaller
size, too?

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
How does a project get to be a year late?  ... One day at a time.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] bitbang phy driver

[Wolfgang Denk]

Dear Darius Augulis,

In message <4a789d2f.1050...@gmail.com> you wrote:
> 
> I see that miiphybb.c driver is used only with PPC architecture yet.
> I would like to use it with ARM. Would be it reasonable to make this 
> driver arch independent? I have small patch and it changes defined ports 
> and pins with function calls, which should be provided by each CPU. I 

Hm... I fail to see why such a change is needed.

> attached this patch for RFC. If it is suitable, I may need help with 
> changing all > 20 PPC boards using this driver, because I don't have 
> experience with PPC. Would be there some volunteers willing to help? Or 

Sure. The plan (to make this architecture independent) makes a lot
sense.

...
> - MDIO_ACTIVE;
> - MDIO (1);
> + mii_mdio_active(1);
> + mii_mdio_set(1);
>   for (j = 0; j < 32; j++) {
> - MDC (0);
> + mii_mdc_set(0);
>   MIIDELAY;
> - MDC (1);
> + mii_mdc_set(1);
>   MIIDELAY;

Why are these changes necessary?

Why cannot you simple add this to your board config file:

#define MDIO_ACTIVE mii_mdio_active(1)
#define MDIO(x) mii_mdio_set(x)
#define MDC(x)  mii_mdc_set(x)
...

?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
A year spent in artificial intelligence is enough to make one believe
in God.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] stx: create common vendor hierarchy for Silicon Turnkey boards

[Wolfgang Denk]

Dear oa...@yahoo.com,

In message <1249383697-28141-1-git-send-email-oa...@yahoo.com> you wrote:
> From: Alex Dubov 
> 
> Move board definition files for STx XTC, GP3 and SSA boards into
> common subdirectory and factor out common code.
> 
> "-mno-spe" flag common to all MPC85xx configurations does not work
> so change it to "-mspe=no" which does (GCC bug 37759).
> 
> Signed-off-by: Alex Dubov 
...
> --- a/board/stxgp3/Makefile
> +++ b/board/stx/common/Makefile
> @@ -1,5 +1,5 @@
>  #
> -# (C) Copyright 2001-2006
> +# (C) Copyright 2006
>  # Wolfgang Denk, DENX Software Engineering, w...@denx.de.

How comes?

> --- a/board/stxssa/ddr.c
> +++ b/board/stx/common/ddr.c
> @@ -1,5 +1,6 @@
>  /*
>   * Copyright 2008 Freescale Semiconductor, Inc.
> + * Copyright 2009 Alex Dubov 
>   *
>   * This program is free software; you can redistribute it and/or
>   * modify it under the terms of the GNU General Public License

Please do not add a Copyright for such minor changes. Attribution for
your work by the Signed-off-by: messages in the git repository should
be sufficient here.

...
> +  * Factors to consider for clock adjust:
> +  *  - number of chips on bus
> +  *  - position of slot
> +  *  - DDR1 vs. DDR2?
> +  *  - ???
> +  *
> +  * This needs to be determined on a board-by-board basis.
> +  *  01103/4 cycle late
> +  *  01117/8 cycle late
> +  */
> + popts->clk_adjust = 6;

If this "needs to be determined on a board-by-board basis" i would
expect some CONFIG_SYS_* variable here, which is defined in the
respective board config files?

> +#if defined(CONFIG_FSL_DDR2)
> + popts->cpo_override = 7;
> +#else
>   popts->cpo_override = 0;
> +#endif

Ditto - this should go to the respective board config files.

> diff --git a/board/stxssa/law.c b/board/stx/common/law.c
> similarity index 74%
> rename from board/stxssa/law.c
> rename to board/stx/common/law.c
> index 55dde66..a82c99f 100644
> --- a/board/stxssa/law.c
> +++ b/board/stx/common/law.c
> @@ -1,9 +1,9 @@
>  /*
> - * Copyright 2008 Freescale Semiconductor, Inc.
> - *
>   * (C) Copyright 2000
>   * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
>   *
> + * Copyright 2009 Alex Dubov 
> + *
>   * See file CREDITS for list of people who contributed to this
>   * project.

NAK. Never ever delete any Copyrights. And don't add yoru own just for
minor changes.

> @@ -31,30 +31,34 @@
>   * LAW(Local Access Window) configuration:
>   *
>   * 0x_ 0x7fff_ DDR 2G
> - * 0x8000_ 0x9fff_ PCI1 MEM512M
> - * 0xa000_ 0xbfff_ PCI2 MEM512M
> + * 0x8000_ 0x9fff_ PCI1512M
> + * 0xa000_ 0xbfff_ PCI2512M
> + * 0xc000_ 0xdfff_ RapidIO 512M
>   * 0xe000_ 0xe000_ CCSR1M
>   * 0xe200_ 0xe2ff_ PCI1 IO 16M
>   * 0xe300_ 0xe3ff_ PCI2 IO 16M
> - * 0xf000_ 0xfaff_ Local bus   128M
> - * 0xfb00_ 0xfb00_ Config Latch64K
> - * 0xfc00_ 0x_ FLASH (boot bank)   64M
> + * 0xf000_ 0x_ LBC options + FLASH 256M

Are you sure this is correct?

>  struct law_entry law_table[] = {
> -#ifndef CONFIG_SPD_EEPROM
> - SET_LAW(CONFIG_SYS_DDR_SDRAM_BASE, LAW_SIZE_128M, LAW_TRGT_IF_DDR),
> +#ifdef CONFIG_SYS_PCI1_MEM_PHYS
> + SET_LAW(CONFIG_SYS_PCI1_MEM_PHYS, LAW_SIZE_512M, LAW_TRGT_IF_PCI),
> + SET_LAW(CONFIG_SYS_PCI1_IO_PHYS, LAW_SIZE_16M, LAW_TRGT_IF_PCI),
>  #endif
> - SET_LAW(CONFIG_SYS_PCI1_MEM_PHYS, LAW_SIZE_512M, LAW_TRGT_IF_PCI_1),
> +#ifdef CONFIG_SYS_PCI2_MEM_PHYS
>   SET_LAW(CONFIG_SYS_PCI2_MEM_PHYS, LAW_SIZE_512M, LAW_TRGT_IF_PCI_2),
> - SET_LAW(CONFIG_SYS_PCI1_IO_PHYS, LAW_SIZE_16M, LAW_TRGT_IF_PCI_1),
>   SET_LAW(CONFIG_SYS_PCI2_IO_PHYS, LAW_SIZE_16M, LAW_TRGT_IF_PCI_2),
> - /* Map the whole localbus, including flash and reset latch. */
> - SET_LAW(CONFIG_SYS_LBC_OPTION_BASE, LAWAR_SIZE_256M, LAW_TRGT_IF_LBC),
> +#endif
> +#ifdef CONFIG_SYS_RIO_MEM_PHYS
> + SET_LAW(CONFIG_SYS_RIO_MEM_PHYS, LAW_SIZE_512M, LAW_TRGT_IF_RIO),
> +#endif
> + SET_LAW(CONFIG_SYS_LBC_OPTION_BASE, LAWAR_SIZE_256M, LAW_TRGT_IF_LBC)
>  };

This looks fishy, too.

> --- a/board/stxssa/tlb.c
> +++ b/board/stx/common/tlb.c
> @@ -1,9 +1,9 @@
>  /*
> - * Copyright 2008 Freescale Semiconductor, Inc.
> - *
>   * (C) Copyright 2000
>   * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
>   *
> + * Copyright 2009 Alex Dubov 
> + *
>   * See file CREDITS for list of people who contributed to this
>   * project.

NAK. See above.

> @@ -31,76 +31,90 @@ struct fsl_e_tlb_entry tlb_table[] = {
>   SET_TLB_ENTRY(0, CONFIG_SYS_INIT_RAM_ADDR, CONFIG_SYS_INIT_RAM_ADDR,
> MAS3_SX|

Re: [U-Boot] CFI driver and P33 64M flash

[psdof]

Hi,

I have a similar p30 intel 64M flash.When I try to initialize both banks at
0x2000 and 0x2200, u-boot crashes while initializing second bank at
0x2200, i debugged and found out that u-boot couldn't sucessfully write
to second bank. But when i plug in the debugger to my board i can see and
use the second bank starting at 0x2200.
Though if i initialize only first bank everything runs normal but i am left
with 32Mb of space.

I am going bonkers over this, please help .


Felix Radensky wrote:
> 
> Hi,
> 
> I'm running U-Boot 1.3.4 on custom 460EX based board,
> equipped with 64M P33 flash (similar to Intel P30). See
> http://www.numonyx.com/Documents/Datasheets/314749_P33_Discrete_DS.pdf
> 
> This flash is comprised internally of two 32M flashes.
> I have the following declarations in configuration file:
> 
> #define CFG_FLASH_CFI/* The flash is CFI compatible*/
> #define CFG_FLASH_CFI_DRIVER/* Use common CFI driver*/
> 
> #define CFG_FLASH_BANKS_LIST{CFG_FLASH_BASE}
> #define CFG_MAX_FLASH_BANKS1/* max number of memory banks   
> */
> #define CFG_MAX_FLASH_SECT518/* max number of sectors on one 
> chip*/
> 
> #define CFG_FLASH_USE_BUFFER_WRITE 1/* use buffered writes (20x 
> faster)*/
> #define CFG_FLASH_PROTECTION   1/* use hardware flash 
> protection*/
> #define CFG_FLASH_EMPTY_INFO/* print 'E' for empty sector on 
> flinfo */
> 
> U-Boot identifies this flash as 32M flash. Below is debug output from 
> CFI driver:
> 
> FLASH: flash detect cfi
> fwc addr fc00 cmd f0 f0 8bit x 8 bit
> fwc addr fc00 cmd ff ff 8bit x 8 bit
> fwc addr fc55 cmd 98 98 8bit x 8 bit
> is= cmd 51(Q) addr fc10 is= 0 51
> fwc addr fc000555 cmd 98 98 8bit x 8 bit
> is= cmd 51(Q) addr fc10 is= 0 51
> fwc addr fc00 cmd f0 f0f0 16bit x 8 bit
> fwc addr fc00 cmd ff  16bit x 8 bit
> fwc addr fcaa cmd 98 9898 16bit x 8 bit
> is= cmd 51(Q) addr fc20 is= 0051 5151
> fwc addr fc000aaa cmd 98 9898 16bit x 8 bit
> is= cmd 51(Q) addr fc20 is= 0051 5151
> fwc addr fc00 cmd f0 00f0 16bit x 16 bit
> fwc addr fc00 cmd ff 00ff 16bit x 16 bit
> fwc addr fcaa cmd 98 0098 16bit x 16 bit
> is= cmd 51(Q) addr fc20 is= 0051 0051
> is= cmd 52(R) addr fc22 is= 0052 0052
> is= cmd 59(Y) addr fc24 is= 0059 0059
> device interface is 1
> found port 2 chip 2 port 16 bits chip 16 bits
> 00 : 51 52 59 01 00 0a 01 00 00 00 00 23 36 85 95 08  QRY#6...
> 10 : 09 0a 00 01 01 02 00 19 01 00 06 00 02 03 00 80  
> 20 : 00 fe 00 00 02 00 00 00 00 ff ff ff ff fc 36 a4  ..6.
> fwc addr fc00 cmd ff 00ff 16bit x 16 bit
> fwc addr fc00 cmd 90 0090 16bit x 16 bit
> fwc addr fc00 cmd ff 00ff 16bit x 16 bit
> fwc addr fcaa cmd 98 0098 16bit x 16 bit
> manufacturer is 1
> manufacturer id is 0x89
> device id is 0x22
> device id2 is 0x0
> cfi version is 0x3135
> size_ratio 1 port 16 bits chip 16 bits
> found 2 erase regions
> erase region 0: 0x0083
> erase_region_count = 4 erase_region_size = 32768
> erase region 1: 0x02fe
> erase_region_count = 255 erase_region_size = 131072
> fwc addr fc00 cmd ff 00ff 16bit x 16 bit
> 32 MB
> 
> What should I change in configuration/driver to get
> all 64M of flash detected ?
> 
> Thanks a lot.
> 
> Felix.
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
> 
> 

-- 
View this message in context: 
http://www.nabble.com/-U-Boot--CFI-driver-and-P33-64M-flash-tp19669949p24815971.html
Sent from the Uboot - Users mailing list archive at Nabble.com.

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

[U-Boot] bitbang phy driver

[Darius Augulis]

Hi all,

I see that miiphybb.c driver is used only with PPC architecture yet.
I would like to use it with ARM. Would be it reasonable to make this 
driver arch independent? I have small patch and it changes defined ports 
and pins with function calls, which should be provided by each CPU. I 
attached this patch for RFC. If it is suitable, I may need help with 
changing all > 20 PPC boards using this driver, because I don't have 
experience with PPC. Would be there some volunteers willing to help? Or 
please suggest other solution to make optimize this driver.


Regards,
Darius A.
Make miiphybb gpio interface more flexible

From: Darius Augulis 

Signed-off-by: Darius Augulis 
---

 drivers/net/phy/miiphybb.c |  116 
 drivers/net/phy/miiphybb.h |   22 
 2 files changed, 75 insertions(+), 63 deletions(-)
 create mode 100644 drivers/net/phy/miiphybb.h


diff --git a/drivers/net/phy/miiphybb.c b/drivers/net/phy/miiphybb.c
index b77c917..08d0a80 100644
--- a/drivers/net/phy/miiphybb.c
+++ b/drivers/net/phy/miiphybb.c
@@ -27,8 +27,7 @@
  */
 
 #include 
-#include 
-#include 
+#include "miiphybb.h"
 
 /*
  *
@@ -38,9 +37,6 @@
 static void miiphy_pre (char read, unsigned char addr, unsigned char reg)
 {
int j;  /* counter */
-#if !(defined(CONFIG_EP8248) || defined(CONFIG_EP82XXM))
-   volatile ioport_t *iop = ioport_addr ((immap_t *) CONFIG_SYS_IMMR, 
MDIO_PORT);
-#endif
 
/*
 * Send a 32 bit preamble ('1's) with an extra '1' bit for good measure.
@@ -50,61 +46,61 @@ static void miiphy_pre (char read, unsigned char addr, 
unsigned char reg)
 * but it is safer and will be much more robust.
 */
 
-   MDIO_ACTIVE;
-   MDIO (1);
+   mii_mdio_active(1);
+   mii_mdio_set(1);
for (j = 0; j < 32; j++) {
-   MDC (0);
+   mii_mdc_set(0);
MIIDELAY;
-   MDC (1);
+   mii_mdc_set(1);
MIIDELAY;
}
 
/* send the start bit (01) and the read opcode (10) or write (10) */
-   MDC (0);
-   MDIO (0);
+   mii_mdc_set(0);
+   mii_mdio_set(0);
MIIDELAY;
-   MDC (1);
+   mii_mdc_set(1);
MIIDELAY;
-   MDC (0);
-   MDIO (1);
+   mii_mdc_set(0);
+   mii_mdio_set(1);
MIIDELAY;
-   MDC (1);
+   mii_mdc_set(1);
MIIDELAY;
-   MDC (0);
-   MDIO (read);
+   mii_mdc_set(0);
+   mii_mdio_set(read);
MIIDELAY;
-   MDC (1);
+   mii_mdc_set(1);
MIIDELAY;
-   MDC (0);
-   MDIO (!read);
+   mii_mdc_set(0);
+   mii_mdio_set(!read);
MIIDELAY;
-   MDC (1);
+   mii_mdc_set(1);
MIIDELAY;
 
/* send the PHY address */
for (j = 0; j < 5; j++) {
-   MDC (0);
+   mii_mdc_set(0);
if ((addr & 0x10) == 0) {
-   MDIO (0);
+   mii_mdio_set(0);
} else {
-   MDIO (1);
+   mii_mdio_set(1);
}
MIIDELAY;
-   MDC (1);
+   mii_mdc_set(1);
MIIDELAY;
addr <<= 1;
}
 
/* send the register address */
for (j = 0; j < 5; j++) {
-   MDC (0);
+   mii_mdc_set(0);
if ((reg & 0x10) == 0) {
-   MDIO (0);
+   mii_mdio_set(0);
} else {
-   MDIO (1);
+   mii_mdio_set(1);
}
MIIDELAY;
-   MDC (1);
+   mii_mdc_set(1);
MIIDELAY;
reg <<= 1;
}
@@ -123,31 +119,28 @@ int bb_miiphy_read (char *devname, unsigned char addr,
 {
short rdreg;/* register working value */
int j;  /* counter */
-#if !(defined(CONFIG_EP8248) || defined(CONFIG_EP82XXM))
-   volatile ioport_t *iop = ioport_addr ((immap_t *) CONFIG_SYS_IMMR, 
MDIO_PORT);
-#endif
 
if (value == NULL) {
puts("NULL value pointer\n");
return (-1);
}
 
-   miiphy_pre (1, addr, reg);
+   miiphy_pre(1, addr, reg);
 
/* tri-state our MDIO I/O pin so we can read */
-   MDC (0);
-   MDIO_TRISTATE;
+   mii_mdc_set(0);
+   mii_mdio_active(0);
MIIDELAY;
-   MDC (1);
+   mii_mdc_set(1);
MIIDELAY;
 
/* check the turnaround bit: the PHY should be driving it to zero */
-   if (MDIO_READ != 0) {
+   if (mii_mdio_read() != 0) {
/* puts ("PHY didn't drive TA low\n"); */
for (j = 0; j < 32; j++) {
-   MDC (0);
+   mii_mdc_set(0);
MIIDELAY;
-   

Re: [U-Boot] Normal command line behavior?

[Wolfgang Denk]

Dear "J.C. Wren",

In message <17434f2e0908041305i629aef0dmbf23e620a61fe...@mail.gmail.com> you 
wrote:
>
> Not sure about that part.  I just went back and looked at cmd_i2c.c,
> cmd_yaffs2.c and a few others and I see they all do sub-command processing
> with strncmp(), too.  I had looked at one other file prior to my post, and

Yes, that's the old, deprecated way of doing this. Today we know
better.

> I forgot to mention that all the yaffs commands are top level.  If I were
> me, I'd like to see the yaffs command broken down into a sub-menu.  That's

Please feel free to submit a patch.

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
Any technology distinguishable from magic is insufficiently advanced.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH] Add support for Raidsonic ICYBOX NAS4220 board

[Wolfgang Denk]

Dear Jean-Christophe PLAGNIOL-VILLARD,

In message <20090804194155.ga4...@game.jcrosoft.org> you wrote:
>
...
> > >> +
> > >> +ldr r3, =GEMINI_GLOBAL_ID   /* Global ID reg */
> > >> +ldr r4, [r3]
> > >> +ldr r5, =0xFF   /* Chip revision mask */
> > >> +and r4, r4, r5
> > > please create a function for this and call it
> > 
> > it is used only single time. why do you recommend to create function?
> because it will interesting to have it in the board info and a lot's of time
> you will need it in drivers

Obviously this is not the case - he wrote: "used only single time".

Making it a function makes no sense to me then - especially since
we're just talking about 4 LOC...


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"It is better to have tried and failed than to have  failed  to  try,
but the result's the same."   - Mike Dennison
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH] Add support for Raidsonic ICYBOX NAS4220 board

[Darius Augulis]

On 08/04/2009 10:41 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 19:55 Mon 03 Aug , Darius Augulis wrote:
>> On 07/08/2009 01:29 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>> On 22:03 Tue 30 Jun , Darius Augulis wrote:
 This board is based on Cortina Systems networking processor
 CS3516. It has FA526 core, which is ARMv4 compatible.
 Many SoC specific definitions may be used for similar
 processors CS3512 and dual-core CS3518. This processor
 family has Gemini name.
>>> do you boot linux?
>> yes.
> so why don't you define a machine id?
> on arm you need to pass it to linux

oh yes, I know that. it's only RFC patch, I will finish all similar 
stuff later.

 Signed-off-by: Darius Augulis
 ---

MAINTAINERS  |4 +
MAKEALL  |1
Makefile |3
board/nas4220/Makefile   |   43 +
board/nas4220/config.mk  |   14 ++
board/nas4220/lowlevel_init.S|   96 
board/nas4220/nas4220.c  |   75 +
board/nas4220/u-boot.lds |   48 ++
cpu/arm920t/gemini/Makefile  |   38 +
cpu/arm920t/gemini/timer.c   |   93 
cpu/arm920t/start.S  |   11 +
include/asm-arm/arch-gemini/gemini.h |  271 
 ++
include/configs/nas4220.h|  116 +++
13 files changed, 811 insertions(+), 2 deletions(-)
create mode 100644 board/nas4220/Makefile
create mode 100644 board/nas4220/config.mk
create mode 100644 board/nas4220/lowlevel_init.S
create mode 100644 board/nas4220/nas4220.c
create mode 100644 board/nas4220/u-boot.lds
create mode 100644 cpu/arm920t/gemini/Makefile
create mode 100644 cpu/arm920t/gemini/timer.c
create mode 100644 include/asm-arm/arch-gemini/gemini.h
create mode 100644 include/configs/nas4220.h

>>> ditto etc...
 +
 +  ldr r3, =GEMINI_GLOBAL_ID   /* Global ID reg */
 +  ldr r4, [r3]
 +  ldr r5, =0xFF   /* Chip revision mask */
 +  and r4, r4, r5
>>> please create a function for this and call it
>> it is used only single time. why do you recommend to create function?
> because it will interesting to have it in the board info and a lot's of time
> you will need it in drivers
 +  cmp r4, #0xc0   /* Test if chip rev. is 'c0' */
 +  bne end_prefetch
 +
 +  /* Fix for rev. 'c0' chip */
 +  ldr r0, =GEMINI_DRAM_AHB_CTRL   /* AHB control */
 +  ldr r5, =GEMINI_WRITE_FLUSH_READ
 +  str r5, [r0]
 +
>>> 
 +
 +  ldr r2, =GEMINI_DRAM_BASE
 +  mov r4, #0xa0
 +
 +read_loop:
 +  ldr r3, [r2]/* Read data */
 +  subsr4, r4, #1  /* Decrement loop count */
 +  bge read_loop
 +
 +  bic r1, r1, #GEMINI_TRAINING_MODE   /* Disable train mode */
>>> what is train mode?
>> this is not documented. This piece of code is revers-engineered
>> proprietary Storlink boot loader.
> so please put a comment in the code

ok.

 +  str r1, [r0]
 +
 +  mov pc, lr
>>> please create an api such as at91, davinci and other to manage this kind of
>>> config
>> what api are you talking about? please give some reference.
> take a look an at91 in cpu/arm926ejs/at91/
> for each soc you have hw init

ok, I've already implemented this.

>
 diff --git a/board/nas4220/u-boot.lds b/board/nas4220/u-boot.lds
 new file mode 100644
 index 000..7d249c3
 --- /dev/null
 +++ b/board/nas4220/u-boot.lds
>>> I do not understand why you need a specific lds?
>> because of specific and not software controlled boot procedure of
>> Gemini. Please read my comments below.
> this is steal not clear why you need
> this
 +  {
 +  cpu/arm920t/start.o (.text)
 +  board/nas4220/libnas4220.a  (.text)
 +  lib_arm/libarm.a(.text)
 +  *(.text)
 +  }
> and not
>   {
>   cpu/arm926ejs/start.o   (.text)
>   *(.text)
>   }

Gemini has arm920t (FA526) core.
I need libarm linked above 0x800.

 +
 +  . = ALIGN(4);
 +  .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
 +
> 
 +
 +#endif /* defined (CONFIG_GEMINI) */
 diff --git a/cpu/arm920t/start.S b/cpu/arm920t/start.S
 index 475cdaf..761753e 100644
 --- a/cpu/arm920t/start.S
 +++ b/cpu/arm920t/start.S
 @@ -115,8 +115,10 @@ start_code:
orr r0,r0,#0xd3
msr cpsr,r0

 -  bl coloured_LED_init
 -  bl red_LED_on
 +#ifndef CONFIG_GEMINI
 +  bl  coloured_LED_init
 + 

Re: [U-Boot] [PATCH 3/3 v4] arm: A320: Add support for Faraday A320 evaluation board

[Darius Augulis]

On 08/04/2009 10:48 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 09:42 Mon 03 Aug , Darius Augulis wrote:
>> On 07/08/2009 02:30 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>> On 15:14 Fri 03 Jul , Po-Yu Chuang wrote:
 This patch adds support for A320 development board from Faraday. This board
 uses FA526 processor by default and has 512kB and 32MB NOR flash, 64M RAM.
 FA526 is an ARMv4 processor and uses the ARM920T source in this patch.

>>> as I understand correctly the faraday and the CS3518 share the same core and
>>> IP so it will be better to have the same dir
>> I don't think so. Both A320 and Gemini share the same FA526 core,
>> but different peripheral. There is no reason to create generic dir
>> for A320 and Gemini. Also, no reason to create cpu/fa526 because
>> fa526 is almost arm920t.
> duplicate code is worse
> as example on at91 we do support multiple soc of the family in the same
> generic dir which allow us to factorize common code and ofcourse split
> soc specific code too

Gemini and A320 are not from the same family. There isn't any common 
code *yet*. They share only the same core.
There are more dirs in cpu/arm920t: "imx", "s3c24x0", etc. Perhaps you 
won't suggest to move all these SoC's into single dir?

A320 and Gemini *maybe* have the same timer IP, but there are few 
'small' problems. First: these processors, made in China, have very poor 
documentation. I must do lot of reverse-engineering work to create 
something working. Second, I don't have any A320 hardware to test 
something. It's very difficult to make most optimal release at the very 
beginning. After we have Gemini in main line, somebody interested in 
A320 should feel free to submit patches to optimize support for SoC's, 
based on FA526 core. Now I can't do this job and I guess it shouldn't be 
reason to reject my patches?

>
> Best Regards,
> J.
>

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

Re: [U-Boot] Normal command line behavior?

[J.C. Wren]

On Tue, Aug 4, 2009 at 3:48 PM, Scott Wood  wrote:

> On Tue, Aug 04, 2009 at 12:07:17PM -0400, J.C. Wren wrote:
> > All fair points.
> >
> > It appears that the 'nand' commands don't use the new parser structure.
>
> Do you mean U_BOOT_CMD_MKENT, find_cmd_tbl, etc?


Not sure about that part.  I just went back and looked at cmd_i2c.c,
cmd_yaffs2.c and a few others and I see they all do sub-command processing
with strncmp(), too.  I had looked at one other file prior to my post, and
thought I understood sub-commands were plugged-in with macros.  My mistake.

I forgot to mention that all the yaffs commands are top level.  If I were
me, I'd like to see the yaffs command broken down into a sub-menu.  That's
just a minor nit, as having them all in the top level makes the help a
little more unwieldy.  And they'd be used infrequently enough that having
them under a 'y' sub-menu wouldn't make them much more difficult to use.


>
> >  The 'nand' and 'nboot' commands use the U_BOOT_CMD macro, and have
> > repeatable defined as 1.  The 'nand' command is doing it's own
> > sub-command parsing (via strcnmp()'s), and as a result, all 'nand'
> > commands are repeatable.  That probably isn't a good idea, and I would
> > request the the 'nand' command itself be made non-repeatable.
>
> The one nand command that probably should be repeatable is "nand dump",
> with auto-increment similar to "md".


Makes sense.

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

Re: [U-Boot] [PATCH] Support for the Calao TNY-A9260/TNY-A9G20 boards

[Jean-Christophe PLAGNIOL-VILLARD]

On 09:54 Mon 03 Aug , Albin Tonnerre wrote:
> On Sat, Aug 01, 2009 at 04:15:32PM +0200, Jean-Christophe PLAGNIOL-VILLARD 
> wrote :
> > On 10:32 Fri 24 Jul , Albin Tonnerre wrote:
> > > The Calao TNY-A9260 and TNY-9G20 are boards manufactured and sold by Calao
> > > Systems . Their components are very
> > > similar to the AT91SAM9260EK board, so their configuration is based on
> > > the configuration of this board. There are however some differences:
> > > different clocks, no LCD, no ethernet. They also uses SPI EEPROM to store
> > > the environment.
> > eeprom for the env?
> > why not in the same storage as u-boot
> 
> Storing the environment in the NAND is also an option, as you can see in the
> board configuration.
> 
> > please add
> > @mkdir $(obj)include
> > otherwise the out of tree build will not work
???
all other at91 board do it
> 
> So I guess all the other at91-based boards need fixing too ? They don't seem 
> to
> do that.
> 
> > > + at91_serial_hw_init();
> > > + tny_a9260_nand_hw_init();
> > > + at91_spi0_hw_init(1 << 5 | 1 << 1);
> > you can remove the 1 << 1 as the dataflash driver is deprecated now
> 
> I'm not sure what you mean. There's no dataflash on this board. From what I 
> can
> see, 1 << 1 is required to set the PC5 pin on the B peripheral controller, and
> PC5 happens to be the chip select pin for the on-board SPI EEPROM. Am I 
> missing
> something here ?
this is for hardware chip select which we do not use as we use gpio instead

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

Re: [U-Boot] [RFC PATCH] Add support for Raidsonic ICYBOX NAS4220 board

[Jean-Christophe PLAGNIOL-VILLARD]

On 19:55 Mon 03 Aug , Darius Augulis wrote:
> On 07/08/2009 01:29 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 22:03 Tue 30 Jun , Darius Augulis wrote:
> >> This board is based on Cortina Systems networking processor
> >> CS3516. It has FA526 core, which is ARMv4 compatible.
> >> Many SoC specific definitions may be used for similar
> >> processors CS3512 and dual-core CS3518. This processor
> >> family has Gemini name.
> > do you boot linux?
> 
> yes.
so why don't you define a machine id?
on arm you need to pass it to linux
> 
> >> Signed-off-by: Darius Augulis
> >> ---
> >>
> >>   MAINTAINERS  |4 +
> >>   MAKEALL  |1
> >>   Makefile |3
> >>   board/nas4220/Makefile   |   43 +
> >>   board/nas4220/config.mk  |   14 ++
> >>   board/nas4220/lowlevel_init.S|   96 
> >>   board/nas4220/nas4220.c  |   75 +
> >>   board/nas4220/u-boot.lds |   48 ++
> >>   cpu/arm920t/gemini/Makefile  |   38 +
> >>   cpu/arm920t/gemini/timer.c   |   93 
> >>   cpu/arm920t/start.S  |   11 +
> >>   include/asm-arm/arch-gemini/gemini.h |  271 
> >> ++
> >>   include/configs/nas4220.h|  116 +++
> >>   13 files changed, 811 insertions(+), 2 deletions(-)
> >>   create mode 100644 board/nas4220/Makefile
> >>   create mode 100644 board/nas4220/config.mk
> >>   create mode 100644 board/nas4220/lowlevel_init.S
> >>   create mode 100644 board/nas4220/nas4220.c
> >>   create mode 100644 board/nas4220/u-boot.lds
> >>   create mode 100644 cpu/arm920t/gemini/Makefile
> >>   create mode 100644 cpu/arm920t/gemini/timer.c
> >>   create mode 100644 include/asm-arm/arch-gemini/gemini.h
> >>   create mode 100644 include/configs/nas4220.h
> >>
> > ditto etc...
> >> +
> >> +  ldr r3, =GEMINI_GLOBAL_ID   /* Global ID reg */
> >> +  ldr r4, [r3]
> >> +  ldr r5, =0xFF   /* Chip revision mask */
> >> +  and r4, r4, r5
> > please create a function for this and call it
> 
> it is used only single time. why do you recommend to create function?
because it will interesting to have it in the board info and a lot's of time
you will need it in drivers
> 
> >> +  cmp r4, #0xc0   /* Test if chip rev. is 'c0' */
> >> +  bne end_prefetch
> >> +
> >> +  /* Fix for rev. 'c0' chip */
> >> +  ldr r0, =GEMINI_DRAM_AHB_CTRL   /* AHB control */
> >> +  ldr r5, =GEMINI_WRITE_FLUSH_READ
> >> +  str r5, [r0]
> >> +
> > 
> >> +
> >> +  ldr r2, =GEMINI_DRAM_BASE
> >> +  mov r4, #0xa0
> >> +
> >> +read_loop:
> >> +  ldr r3, [r2]/* Read data */
> >> +  subsr4, r4, #1  /* Decrement loop count */
> >> +  bge read_loop
> >> +
> >> +  bic r1, r1, #GEMINI_TRAINING_MODE   /* Disable train mode */
> > what is train mode?
> 
> this is not documented. This piece of code is revers-engineered 
> proprietary Storlink boot loader.
so please put a comment in the code
> 
> >> +  str r1, [r0]
> >> +
> >> +  mov pc, lr
> 
> >
> > please create an api such as at91, davinci and other to manage this kind of
> > config
> 
> what api are you talking about? please give some reference.
take a look an at91 in cpu/arm926ejs/at91/
for each soc you have hw init
> 

> >> diff --git a/board/nas4220/u-boot.lds b/board/nas4220/u-boot.lds
> >> new file mode 100644
> >> index 000..7d249c3
> >> --- /dev/null
> >> +++ b/board/nas4220/u-boot.lds
> > I do not understand why you need a specific lds?
> 
> because of specific and not software controlled boot procedure of 
> Gemini. Please read my comments below.
this is steal not clear why you need
this
> >> +  {
> >> +  cpu/arm920t/start.o (.text)
> >> +  board/nas4220/libnas4220.a  (.text)
> >> +  lib_arm/libarm.a(.text)
> >> +  *(.text)
> >> +  }
and not
{
cpu/arm926ejs/start.o   (.text)
*(.text)
}
> >> +
> >> +  . = ALIGN(4);
> >> +  .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
> >> +

> 
> >> +
> >> +#endif /* defined (CONFIG_GEMINI) */
> >> diff --git a/cpu/arm920t/start.S b/cpu/arm920t/start.S
> >> index 475cdaf..761753e 100644
> >> --- a/cpu/arm920t/start.S
> >> +++ b/cpu/arm920t/start.S
> >> @@ -115,8 +115,10 @@ start_code:
> >>orr r0,r0,#0xd3
> >>msr cpsr,r0
> >>
> >> -  bl coloured_LED_init
> >> -  bl red_LED_on
> >> +#ifndef CONFIG_GEMINI
> >> +  bl  coloured_LED_init
> >> +  bl  red_LED_on
> >> +#endif
> > no need please remove
> 
> these are linked below (TEXT_BASE + 0x800) address. if called before 
> reallocation, they are not accessible because of Gemini specific boot 
> features.
> 
> >>
> >>   #if  defined(CONFIG_AT91RM9200DK) || defined(CONFIG_AT9

Re: [U-Boot] [PATCH 3/3 v4] arm: A320: Add support for Faraday A320 evaluation board

[Jean-Christophe PLAGNIOL-VILLARD]

On 09:42 Mon 03 Aug , Darius Augulis wrote:
> On 07/08/2009 02:30 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >On 15:14 Fri 03 Jul , Po-Yu Chuang wrote:
> >>This patch adds support for A320 development board from Faraday. This board
> >>uses FA526 processor by default and has 512kB and 32MB NOR flash, 64M RAM.
> >>FA526 is an ARMv4 processor and uses the ARM920T source in this patch.
> >>
> >as I understand correctly the faraday and the CS3518 share the same core and
> >IP so it will be better to have the same dir
> 
> I don't think so. Both A320 and Gemini share the same FA526 core,
> but different peripheral. There is no reason to create generic dir
> for A320 and Gemini. Also, no reason to create cpu/fa526 because
> fa526 is almost arm920t.
duplicate code is worse
as example on at91 we do support multiple soc of the family in the same
generic dir which allow us to factorize common code and ofcourse split
soc specific code too

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

Re: [U-Boot] Normal command line behavior?

[Scott Wood]

On Tue, Aug 04, 2009 at 12:07:17PM -0400, J.C. Wren wrote:
> All fair points.
> 
> It appears that the 'nand' commands don't use the new parser structure.

Do you mean U_BOOT_CMD_MKENT, find_cmd_tbl, etc?

>  The 'nand' and 'nboot' commands use the U_BOOT_CMD macro, and have
> repeatable defined as 1.  The 'nand' command is doing it's own
> sub-command parsing (via strcnmp()'s), and as a result, all 'nand'
> commands are repeatable.  That probably isn't a good idea, and I would
> request the the 'nand' command itself be made non-repeatable.

The one nand command that probably should be repeatable is "nand dump",
with auto-increment similar to "md".

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

[U-Boot] expanding number of pci regions

[Kumar Gala]

I just noticed that we have MAX_PCI_REGIONS set to 7.  On FSL 85xx/ 
86xx parts we can have as many as 9 windows.  Should I just bump the #  
of regions to 9 for everyone or #ifdef based on CONFIG_85xx/CONFIG_86xx?

- k

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

[U-Boot] [PATCH] stxamc8548: make environment use one of the smaller "boot" blocks in flash

[oakad]

From: Alex Dubov 

Put environment into .ppcenv section aligned on a smaller "boot" eraseblock
boundary near flash end.

Signed-off-by: Alex Dubov 
---
 board/stx/stxamc8548/u-boot.lds |   11 ++-
 include/configs/stxamc8548.h|3 ++-
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/board/stx/stxamc8548/u-boot.lds b/board/stx/stxamc8548/u-boot.lds
index 57c4e51..6b46c60 100644
--- a/board/stx/stxamc8548/u-boot.lds
+++ b/board/stx/stxamc8548/u-boot.lds
@@ -109,16 +109,25 @@ SECTIONS
   __ex_table : { *(__ex_table) }
   __stop___ex_table = .;
 
+  .ppcenv ADDR(.text) + 0x38000 :
+  {
+*(.ppcenv)
+  }
+
   . = ALIGN(256);
+
   __init_begin = .;
   .text.init : { *(.text.init) }
   .data.init : { *(.data.init) }
+
+
   . = ALIGN(256);
   __init_end = .;
 
+
   .bootpg ADDR(.text) + 0x3f000 :
   {
-cpu/mpc85xx/start.o(.bootpg)
+cpu/mpc85xx/start.o (.bootpg)
   } :text = 0x
 
   .resetvec ADDR(.text) + 0x3fffc :
diff --git a/include/configs/stxamc8548.h b/include/configs/stxamc8548.h
index c01a4bb..cecd858 100644
--- a/include/configs/stxamc8548.h
+++ b/include/configs/stxamc8548.h
@@ -246,9 +246,10 @@ extern unsigned long get_clock_freq(void);
  * Environment
  */
 #define CONFIG_ENV_IS_IN_FLASH 1
+#define CONFIG_SYS_USE_PPCENV  1
 #define CONFIG_ENV_ADDR(CONFIG_SYS_MONITOR_BASE + 0x38000)
 #define CONFIG_ENV_SECT_SIZE   0x4000   /* 16K(one sector) for env */
-#define CONFIG_ENV_SIZE0x2000
+#define CONFIG_ENV_SIZE0x4000
 
 #define CONFIG_LOADS_ECHO 1 /* echo on for serial download */
 #define CONFIG_SYS_LOADS_BAUD_CHANGE  1 /* allow baudrate change */
-- 
1.5.6.4

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

Re: [U-Boot] Normal command line behavior?

[J.C. Wren]

All fair points.

It appears that the 'nand' commands don't use the new parser structure.  The
'nand' and 'nboot' commands use the U_BOOT_CMD macro, and have repeatable
defined as 1.  The 'nand' command is doing it's own sub-command parsing (via
strcnmp()'s), and as a result, all 'nand' commands are repeatable.  That
probably isn't a good idea, and I would request the the 'nand' command
itself be made non-repeatable.

--jc

On Mon, Aug 3, 2009 at 5:58 PM, Wolfgang Denk  wrote:

> Dear Jerry Van Baren,
>
> In message <4a773c1c.7080...@ge.com> you wrote:
> >
> > It is a configuration/design decision: see include/command.h line 46ff,
> > struct cmd_tbl_s, field "repeatable".  This is configured via the
> > U_BOOT_CMD macro.
> >
> > <
> http://git.denx.de/?p=u-boot.git;a=blob;f=include/command.h;h=55caa6eaf888cdb916d3937a5054ad862ec0e0ab;hb=HEAD#l46
> >
> >
> > Sometimes it is nice (e.g. sequencing through memory dumps), sometimes
> > it bites (you found one of those!).  IMHO, it is enabled in places where
> > it would be better to rely on command line recall rather than the repeat
> > function.
>
> The general rule is that any command that is non-destructive is
> repeatable, i. e. a "tftp" will be repeated, while an "erase" will
> not.
>
> Indeed, today command line history makes it partially dispensable, but
> often at the cost of more typing (think about using the "md" command).
>
> > I think the repeat functionality predated the command line recall
> > functionality, so it use to be more desirable to repeat the command
> > because there wasn't an alternative way to repeat the command.
>
> Correct, this, and because that was exactly what I wanted when I
> implemented it :-)
>
> 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 software required `Windows 95 or better', so I installed Linux.
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] IXP425 TEXT_BASE

[Wolfgang Denk]

Dear Darius Augulis,

In message <4a784702.40...@gmail.com> you wrote:
>
> > No. TEXT_BASE is an absolute address.
> 
> yes, but depends on the physical RAM base and size.

Only on ARM (and other architectures that copied it's broken
implementation). TEXT_BASE is an absolute address (in the boot flash)
on PowerPC.

> could you please explain more? why to the end of RAM?

YOu want to have a maximum of contiguous RAM available to load Linux
kernel, ramdisk images etc.

> for example I have 16MB RAM, base is 0x1000. TEXT_BASE = 0x1040.
> Why is better to set this to 0x10F0 ? To have more stack and malloc 
> memory? But U-boot will never exceed such limit? Please explain where I 
> am wrong. Thanks!

With RAM from 0x1000...0x10ff you should probably put
TEXT_BASE at 0x10f8 which then would leave you some 15 MB of
contiguous RAM for your use.

With your setup you jusy have some 3+ MB below U-Boot and some 11+ MB
above it. It makes not much sense to have U-Boot sitting right in the
middle of precious RAM like this.

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 idea of male and female are universal constants.
-- Kirk, "Metamorphosis", stardate 3219.8
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] suggest on how to convey value of 'CCSRBAR' to user on FSL PPC parts

[Kumar Gala]

On Aug 4, 2009, at 9:43 AM, Peter Tyser wrote:

>
> We'd toyed around with adding a "memmap" command which would display
> chip select mappings, and/or tlb mappings.  I think lots of people
> (especially end-users) would find this info useful as the same issue  
> you
> have with determining the CCSR address applies to other memory  
> regions.
>
> The bd_info structure has some of the same data that the memmap  
> command
> would show, but it doesn't have info such as bank width, cache
> attributes, and only supports mem, NOR flash, CCSR, and SRAM.
>
> Do others think such a command would be useful?

It would be useful, I would suggest possible looking at CMD_REGINFO.

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

Re: [U-Boot] [PATCH] stx: add support for AMC8548 board

[Peter Tyser]

On Tue, 2009-08-04 at 14:27 +0200, Wolfgang Denk wrote:
> Dear oa...@yahoo.com,
> 
> In message <1249383697-28141-2-git-send-email-oa...@yahoo.com> you wrote:
> > From: Alex Dubov 
> > 
> > STx AMC8548 board is an old, AMC form factor, MPC8548 based board intended
> > for RapidIO applications. It features 16MiB NAND flash, one DDR2 soDIMM
> > slot, ethernet on front panel and backplane, RapidIO on backplane, USB
> > controller on local bus (not currently enabled) and no PCI of any kind.
> > 
> > Signed-off-by: Alex Dubov 
> > ---
> >  Makefile  |3 +
> >  board/stx/stxamc8548/Makefile |   51 ++
> >  board/stx/stxamc8548/config.mk|   32 
> >  board/stx/stxamc8548/stxamc8548.c |  168 +++
> >  board/stx/stxamc8548/u-boot.lds   |  143 
> >  include/configs/stxamc8548.h  |  332 
> > +
> >  6 files changed, 729 insertions(+), 0 deletions(-)
> >  create mode 100644 board/stx/stxamc8548/Makefile
> >  create mode 100644 board/stx/stxamc8548/config.mk
> >  create mode 100644 board/stx/stxamc8548/stxamc8548.c
> >  create mode 100644 board/stx/stxamc8548/u-boot.lds
> >  create mode 100644 include/configs/stxamc8548.h
> 
> What's the difference between this patch and the previously submitted
> one:
> 
>   Subject: [U-Boot] [PATCH 2/2] stx: add support for AMC8548 board
>   From: Alex Dubov 
>   Date: Tue, 4 Aug 2009 02:26:49 -0700 (PDT)
> 
> ?

It looks like the MAINTAINERS and MAKEALL entries are still missing for
this board too FWIW.  Hopefully the other feedback has been taken into
consideration in this patch?

It'd be nice when you resubmitted patches to include "v2" in the title,
eg "[PATCH v2]" and also listed what you've changed in the comments
below your signed-off-by.  It makes it easier for others to keep track
of what the most recent patch is and what has changed between
resubmissions.

Best,
Peter

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

Re: [U-Boot] suggest on how to convey value of 'CCSRBAR' to user on FSL PPC parts

[Peter Tyser]

On Tue, 2009-08-04 at 09:27 -0500, Kumar Gala wrote:
> On Aug 4, 2009, at 9:24 AM, Wolfgang Denk wrote:
> 
> > Dear Kumar Gala,
> >
> > In message  
> > <7acc3970-1b73-4828-941c-48c6601a7...@kernel.crashing.org> you wrote:
> >> I had two ideas on simple ways to convey the value of CCSRBAR, IMMR,
> >> etc.. on various Freescale PPC SoCs.  Knowing the value is useful in
> >> debugging if you need to dump the register space.  I wanted to see if
> >> people had a preference or other ideas:
> >>
> >> 1. add it as output when we boot:
> >
> > This would be only acceptable when DEBUG is enabled, and even this
> > it's ugly.
> >
> >> 2. add it as a environment variable
> >>
> >> ccsrbar=fe00
> >
> > Please don't.
> >
> >> I also thought about having it as a command but that seems like a lot
> >> of code w/o any real purpose.
> >
> > I don't understand what exactly you need it for.
> >
> > The information should be part of struct bd_info for all relevant
> > architectures, and struct global_data holds a pointer to bd_info as
> > the first element, and on PowerPC R2 holds a pointer to the global
> > data.
> >
> > So you can easily define a GDB macro to do something like this:
> >
> > (gdb) print/x ((gd_t *)$r2)->bd->bi_immr_base
> 
> I didn't think about it being in the bd.  I can use 'bdinfo' to output  
> its value.

We'd toyed around with adding a "memmap" command which would display
chip select mappings, and/or tlb mappings.  I think lots of people
(especially end-users) would find this info useful as the same issue you
have with determining the CCSR address applies to other memory regions.

The bd_info structure has some of the same data that the memmap command
would show, but it doesn't have info such as bank width, cache
attributes, and only supports mem, NOR flash, CCSR, and SRAM.

Do others think such a command would be useful?

Best,
Peter

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

Re: [U-Boot] IXP425 TEXT_BASE

[Darius Augulis]

On 08/04/2009 04:49 PM, Wolfgang Denk wrote:
> Dear Darius Augulis,
>
> In message<4a78342c.5090...@gmail.com>  you wrote:
>> usually TEXT_BASE is offset, which size depends on your requirements for
>
> No. TEXT_BASE is an absolute address.

yes, but depends on the physical RAM base and size.

>
>> stack size and memory size for malloc. If your DRAM base is 0x0 and
>> TEXT_BASE is 0xf8, you will have almost 16Mb for stack and malloc
>> and your u-boot code will be linked and loaded to 0xf8 address.
>> 16Mb is probably too much, or your DRAM base is not 0x0.
>
> On architectures like ARM (where the implementation is based on a
> broken concept of the system memory map) TEXT_BASE should always be
> chosen to be as high as possible to put the ("relocated") U-Boot code
> as close as possible to the very end of available RAM.  For systems
> with several RAM size options you have to set this according to the
> smallest possible RAM size, of course (which is a major PITA).

could you please explain more? why to the end of RAM?
for example I have 16MB RAM, base is 0x1000. TEXT_BASE = 0x1040.
Why is better to set this to 0x10F0 ? To have more stack and malloc 
memory? But U-boot will never exceed such limit? Please explain where I 
am wrong. Thanks!

Darius A.


>
>
> Best regards,
>
> Wolfgang Denk
>

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

Re: [U-Boot] suggest on how to convey value of 'CCSRBAR' to user on FSL PPC parts

[Kumar Gala]

On Aug 4, 2009, at 9:24 AM, Wolfgang Denk wrote:

> Dear Kumar Gala,
>
> In message  
> <7acc3970-1b73-4828-941c-48c6601a7...@kernel.crashing.org> you wrote:
>> I had two ideas on simple ways to convey the value of CCSRBAR, IMMR,
>> etc.. on various Freescale PPC SoCs.  Knowing the value is useful in
>> debugging if you need to dump the register space.  I wanted to see if
>> people had a preference or other ideas:
>>
>> 1. add it as output when we boot:
>
> This would be only acceptable when DEBUG is enabled, and even this
> it's ugly.
>
>> 2. add it as a environment variable
>>
>> ccsrbar=fe00
>
> Please don't.
>
>> I also thought about having it as a command but that seems like a lot
>> of code w/o any real purpose.
>
> I don't understand what exactly you need it for.
>
> The information should be part of struct bd_info for all relevant
> architectures, and struct global_data holds a pointer to bd_info as
> the first element, and on PowerPC R2 holds a pointer to the global
> data.
>
> So you can easily define a GDB macro to do something like this:
>
> (gdb) print/x ((gd_t *)$r2)->bd->bi_immr_base

I didn't think about it being in the bd.  I can use 'bdinfo' to output  
its value.

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

Re: [U-Boot] suggest on how to convey value of 'CCSRBAR' to user on FSL PPC parts

[Wolfgang Denk]

Dear Kumar Gala,

In message <7acc3970-1b73-4828-941c-48c6601a7...@kernel.crashing.org> you wrote:
> I had two ideas on simple ways to convey the value of CCSRBAR, IMMR,  
> etc.. on various Freescale PPC SoCs.  Knowing the value is useful in  
> debugging if you need to dump the register space.  I wanted to see if  
> people had a preference or other ideas:
> 
> 1. add it as output when we boot:

This would be only acceptable when DEBUG is enabled, and even this
it's ugly.

> 2. add it as a environment variable
> 
> ccsrbar=fe00

Please don't.

> I also thought about having it as a command but that seems like a lot  
> of code w/o any real purpose.

I don't understand what exactly you need it for.

The information should be part of struct bd_info for all relevant
architectures, and struct global_data holds a pointer to bd_info as
the first element, and on PowerPC R2 holds a pointer to the global
data.

So you can easily define a GDB macro to do something like this:

(gdb) print/x ((gd_t *)$r2)->bd->bi_immr_base

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'll excuse me a minute, I'm going to have a cup of coffee."
- broadcast from Apollo 11's LEM, "Eagle", to Johnson  Space  Center,
Houston July 20, 1969, 7:27 P.M.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] NAND booting of MPC8313 based Custom board

[Rupesh Kumar]

Hi
Thanks for reply.
I changed ECCM bit and it fixed "NAND boot... read failed (ltesr)" 
problem. 
However, now it again stuck after printing transferring control.
It lookes like it is able to copy u-boot image to RAM but not able to run 
from there.
What could be problem in this ?

Thanks
Rupesh
 




Ron Madrid  
08/03/2009 09:50 PM

To
Scott Wood , Rupesh Kumar 

cc
u-boot@lists.denx.de
Subject
Re: [U-Boot] NAND booting of MPC8313 based Custom board







> "NAND boot... read failed (ltesr)"

This message is triggered by an uncorrectable ECC error; LTESR[2].

> Can any one tell how shall i proceed for booting
> successfully from large 
> page NAND ?

This sounds very similar to problems I initially had.  Odds are your are
burning you LP NAND with the ECCM (FMR[23]) set incorrectly.  So the NAND
read is failing because it is reading the correct ECC from the wrong
offset, hence making it incorrect and uncorrectable.  Double check that 
and
see if it helps.

Ron


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

[U-Boot] suggest on how to convey value of 'CCSRBAR' to user on FSL PPC parts

[Kumar Gala]

I had two ideas on simple ways to convey the value of CCSRBAR, IMMR,  
etc.. on various Freescale PPC SoCs.  Knowing the value is useful in  
debugging if you need to dump the register space.  I wanted to see if  
people had a preference or other ideas:

1. add it as output when we boot:

U-Boot 2009.08-rc1-00030-g56bdfa9 (Jul 30 2009 - 10:52:13)

CPU:   8536E, Version: 1.1, (0x803f0091)
Core:  E500, Version: 3.0, (0x80210030)
..
CCSRBAR: 0xfe00

2. add it as a environment variable

ccsrbar=fe00

I also thought about having it as a command but that seems like a lot  
of code w/o any real purpose.

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

Re: [U-Boot] IXP425 TEXT_BASE

[Wolfgang Denk]

Dear Darius Augulis,

In message <4a78342c.5090...@gmail.com> you wrote:
>
> usually TEXT_BASE is offset, which size depends on your requirements for 

No. TEXT_BASE is an absolute address.

> stack size and memory size for malloc. If your DRAM base is 0x0 and 
> TEXT_BASE is 0xf8, you will have almost 16Mb for stack and malloc 
> and your u-boot code will be linked and loaded to 0xf8 address.
> 16Mb is probably too much, or your DRAM base is not 0x0.

On architectures like ARM (where the implementation is based on a
broken concept of the system memory map) TEXT_BASE should always be
chosen to be as high as possible to put the ("relocated") U-Boot code
as close as possible to the very end of available RAM.  For systems
with several RAM size options you have to set this according to the
smallest possible RAM size, of course (which is a major PITA).


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
Vulcans worship peace above all.
-- McCoy, "Return to Tomorrow", stardate 4768.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] stx: create common vendor hierarchy for Silicon Turnkey boards

[oakad]

From: Alex Dubov 

Move board definition files for STx XTC, GP3 and SSA boards into
common subdirectory and factor out common code.

"-mno-spe" flag common to all MPC85xx configurations does not work
so change it to "-mspe=no" which does (GCC bug 37759).

Signed-off-by: Alex Dubov 
---
 Makefile|6 +-
 board/{stxgp3 => stx/common}/Makefile   |   20 +++--
 board/{stxssa => stx/common}/ddr.c  |   46 ---
 board/{stxssa => stx/common}/law.c  |   30 ---
 board/{stxssa => stx/common}/tlb.c  |   72 ++---
 board/{ => stx}/stxgp3/Makefile |3 -
 board/{ => stx}/stxgp3/config.mk|0 
 board/{ => stx}/stxgp3/flash.c  |0 
 board/{ => stx}/stxgp3/stxgp3.c |0 
 board/{ => stx}/stxgp3/u-boot.lds   |0 
 board/{ => stx}/stxssa/Makefile |3 -
 board/{ => stx}/stxssa/config.mk|0 
 board/{ => stx}/stxssa/stxssa.c |0 
 board/{ => stx}/stxssa/u-boot.lds   |0 
 board/{ => stx}/stxxtc/Makefile |0 
 board/{ => stx}/stxxtc/config.mk|0 
 board/{ => stx}/stxxtc/stxxtc.c |0 
 board/{ => stx}/stxxtc/u-boot.lds   |0 
 board/{ => stx}/stxxtc/u-boot.lds.debug |0 
 board/stxgp3/ddr.c  |   76 --
 board/stxgp3/law.c  |   58 --
 board/stxgp3/tlb.c  |  130 ---
 cpu/mpc85xx/config.mk   |2 +-
 include/configs/stxgp3.h|   21 +++--
 include/configs/stxssa.h|   28 ---
 25 files changed, 135 insertions(+), 360 deletions(-)
 copy board/{stxgp3 => stx/common}/Makefile (82%)
 rename board/{stxssa => stx/common}/ddr.c (57%)
 rename board/{stxssa => stx/common}/law.c (74%)
 rename board/{stxssa => stx/common}/tlb.c (59%)
 rename board/{ => stx}/stxgp3/Makefile (95%)
 rename board/{ => stx}/stxgp3/config.mk (100%)
 rename board/{ => stx}/stxgp3/flash.c (100%)
 rename board/{ => stx}/stxgp3/stxgp3.c (100%)
 rename board/{ => stx}/stxgp3/u-boot.lds (100%)
 rename board/{ => stx}/stxssa/Makefile (95%)
 rename board/{ => stx}/stxssa/config.mk (100%)
 rename board/{ => stx}/stxssa/stxssa.c (100%)
 rename board/{ => stx}/stxssa/u-boot.lds (100%)
 rename board/{ => stx}/stxxtc/Makefile (100%)
 rename board/{ => stx}/stxxtc/config.mk (100%)
 rename board/{ => stx}/stxxtc/stxxtc.c (100%)
 rename board/{ => stx}/stxxtc/u-boot.lds (100%)
 rename board/{ => stx}/stxxtc/u-boot.lds.debug (100%)
 delete mode 100644 board/stxgp3/ddr.c
 delete mode 100644 board/stxgp3/law.c
 delete mode 100644 board/stxgp3/tlb.c

diff --git a/Makefile b/Makefile
index 8096f91..a445eba 100644
--- a/Makefile
+++ b/Makefile
@@ -1129,7 +1129,7 @@ SPD823TS_config:  unconfig
@$(MKCONFIG) $(@:_config=) ppc mpc8xx spd8xx
 
 stxxtc_config: unconfig
-   @$(MKCONFIG) $(@:_config=) ppc mpc8xx stxxtc
+   @$(MKCONFIG) $(@:_config=) ppc mpc8xx stxxtc stx
 
 svm_sc8xx_config:  unconfig
@$(MKCONFIG) $(@:_config=) ppc mpc8xx svm_sc8xx
@@ -2526,7 +2526,7 @@ socrates_config:  unconfig
@$(MKCONFIG) $(@:_config=) ppc mpc85xx socrates
 
 stxgp3_config: unconfig
-   @$(MKCONFIG) $(@:_config=) ppc mpc85xx stxgp3
+   @$(MKCONFIG) $(@:_config=) ppc mpc85xx stxgp3 stx
 
 stxssa_config  \
 stxssa_4M_config:  unconfig
@@ -2535,7 +2535,7 @@ stxssa_4M_config: unconfig
echo "#define CONFIG_STXSSA_4M" >>$(obj)include/config.h ; \
$(XECHO) "... with 4 MiB flash memory" ; \
fi
-   @$(MKCONFIG) -a stxssa ppc mpc85xx stxssa
+   @$(MKCONFIG) -a stxssa ppc mpc85xx stxssa stx
 
 TQM8540_config \
 TQM8541_config \
diff --git a/board/stxgp3/Makefile b/board/stx/common/Makefile
similarity index 82%
copy from board/stxgp3/Makefile
copy to board/stx/common/Makefile
index 5a68f11..08cc2f9 100644
--- a/board/stxgp3/Makefile
+++ b/board/stx/common/Makefile
@@ -1,5 +1,5 @@
 #
-# (C) Copyright 2001-2006
+# (C) Copyright 2006
 # Wolfgang Denk, DENX Software Engineering, w...@denx.de.
 #
 # See file CREDITS for list of people who contributed to this
@@ -23,23 +23,25 @@
 
 include $(TOPDIR)/config.mk
 
-LIB= $(obj)lib$(BOARD).a
+ifneq ($(OBJTREE),$(SRCTREE))
+$(shell mkdir -p $(obj)board/$(VENDOR)/common)
+endif
 
-COBJS-y+= $(BOARD).o
-COBJS-y+= law.o
-COBJS-y+= tlb.o
-COBJS-y+= flash.o
-COBJS-$(CONFIG_FSL_DDR1) += ddr.o
+LIB= $(obj)lib$(VENDOR).a
+
+COBJS-${CONFIG_MPC85xx} += ddr.o
+COBJS-${CONFIG_MPC85xx} += law.o
+COBJS-${CONFIG_MPC85xx} += tlb.o
 
 SRCS   := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
 OBJS   := $(addprefix $(obj),$(COBJS-y))
 SOBJS  := $(addprefix $(obj),$(SOBJS))
 
-$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+$(LIB):$(obj).depend $(OBJS)
$(AR) $(ARFLAGS) $@ $(OBJS)
 
 clean:
-   rm -f $(OBJS) $(SOBJS)
+   rm -f $(SOBJS) $(OBJS)
 
 distclean: clean
   

Re: [U-Boot] [PATCH] pci/fsl_pci_init: Fold pci_setup_indirect into fsl_pci_init

[Kumar Gala]

On Aug 4, 2009, at 1:07 AM, Wolfgang Denk wrote:

> Dear Kumar Gala,
>
> In message <1249352037-25832-1-git-send-email-ga...@kernel.crashing.org 
> > you wrote:
>> Every platform that calls fsl_pci_init calls pci_setup_indirect  
>> before
>> it calls fsl_pci_init.  There isn't any reason to just call it from
>> fsl_pci_init and simplify things a bit.
> ...
>> --- a/include/asm-ppc/fsl_pci.h
>> +++ b/include/asm-ppc/fsl_pci.h
>> @@ -21,7 +21,7 @@
>> #define __FSL_PCI_H_
>>
>> int fsl_pci_setup_inbound_windows(struct pci_region *r);
>> -void fsl_pci_init(struct pci_controller *hose);
>> +void fsl_pci_init(struct pci_controller *hose, u32 cfg_addr, u32  
>> cfg_data);
>
> There will never be any system where 64 bit addresses may be needed?

I thought about this, pci_setup_indirect() takes u32's at this time.   
I'm not sure what the best option is here.

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

Re: [U-Boot] [PATCH] pci/fsl_pci_init: Fold fsl_pci_setup_inbound_windows into fsl_pci_init

[Kumar Gala]

On Aug 4, 2009, at 1:09 AM, Wolfgang Denk wrote:

> Dear Kumar Gala,
>
> In message <1249352037-25832-2-git-send-email-ga...@kernel.crashing.org 
> > you wrote:
>> Every platform that calls fsl_pci_init calls  
>> fsl_pci_setup_inbound_windows
>> before it calls fsl_pci_init.  There isn't any reason to just call it
>> from fsl_pci_init and simplify things a bit.
> ...
>> diff --git a/board/atum8548/atum8548.c b/board/atum8548/atum8548.c
>> index 7a02cdc..85c0adc 100644
>> --- a/board/atum8548/atum8548.c
>> +++ b/board/atum8548/atum8548.c
>> @@ -216,9 +216,6 @@ pci_init_board(void)
>>  }
>>  printf ("\n");
>>
>> -/* inbound */
>> -r += fsl_pci_setup_inbound_windows(r);
>> -
>>  /* outbound memory */
>>  pci_set_region(r++,
>> CONFIG_SYS_PCIE1_MEM_BASE,
>
> Now pci_set_region() will see a different value of "r". Is this OK?

It is, the order of regions is not important.

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

Re: [U-Boot] IXP425 TEXT_BASE

[Darius Augulis]

On 08/04/2009 02:59 PM, Teh Kok How wrote:
> Hi;
>
>  I am trying to bring up u-boot-2009-08-rc1 on IXP425 board. May
> I know what's the reason that the TEXT_BASE is 0x00f8 instead of 0 or
> 0x5000?
>
>  Thanks.
>

Hi Teh,

usually TEXT_BASE is offset, which size depends on your requirements for 
stack size and memory size for malloc. If your DRAM base is 0x0 and 
TEXT_BASE is 0xf8, you will have almost 16Mb for stack and malloc 
and your u-boot code will be linked and loaded to 0xf8 address.
16Mb is probably too much, or your DRAM base is not 0x0.

It's only my experience with porting u-boot to Gemini arch, and I may be 
wrong.

regards,
Darius A.


>
>
> Regards,
>
> KH
>
>
>
>
> 
>
> ___
> 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] IXP425 TEXT_BASE

[Teh Kok How]

Hi;

I am trying to bring up u-boot-2009-08-rc1 on IXP425 board. May
I know what's the reason that the TEXT_BASE is 0x00f8 instead of 0 or
0x5000?

Thanks.

 

Regards,

KH

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

Re: [U-Boot] LCD Display.

[Wolfgang Denk]

Dear Tuma,

In message <200908041619.12488.chernigovs...@spb.gs.ru> you wrote:
>
> And one more question - how can I outpup some text to the LCD?

I *really* recommend to RTFM.

> I wanna redirect printf/puts functions from Com1 to LCD. Maybe there is some 
> example I can look at?

=> setenv stdout lcd

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
Schshschshchsch.
-- The Gorn, "Arena", stardate 3046.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] stx: add support for AMC8548 board

[Wolfgang Denk]

Dear oa...@yahoo.com,

In message <1249383697-28141-2-git-send-email-oa...@yahoo.com> you wrote:
> From: Alex Dubov 
> 
> STx AMC8548 board is an old, AMC form factor, MPC8548 based board intended
> for RapidIO applications. It features 16MiB NAND flash, one DDR2 soDIMM
> slot, ethernet on front panel and backplane, RapidIO on backplane, USB
> controller on local bus (not currently enabled) and no PCI of any kind.
> 
> Signed-off-by: Alex Dubov 
> ---
>  Makefile  |3 +
>  board/stx/stxamc8548/Makefile |   51 ++
>  board/stx/stxamc8548/config.mk|   32 
>  board/stx/stxamc8548/stxamc8548.c |  168 +++
>  board/stx/stxamc8548/u-boot.lds   |  143 
>  include/configs/stxamc8548.h  |  332 
> +
>  6 files changed, 729 insertions(+), 0 deletions(-)
>  create mode 100644 board/stx/stxamc8548/Makefile
>  create mode 100644 board/stx/stxamc8548/config.mk
>  create mode 100644 board/stx/stxamc8548/stxamc8548.c
>  create mode 100644 board/stx/stxamc8548/u-boot.lds
>  create mode 100644 include/configs/stxamc8548.h

What's the difference between this patch and the previously submitted
one:

Subject: [U-Boot] [PATCH 2/2] stx: add support for AMC8548 board
From: Alex Dubov 
Date: Tue, 4 Aug 2009 02:26:49 -0700 (PDT)

?

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
We want to create puppets that pull their own strings.   - Ann Marion
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] LCD Display.

[Tuma]

Hi, All!
And one more question - how can I outpup some text to the LCD?
I wanna redirect printf/puts functions from Com1 to LCD. Maybe there is some 
example I can look at?


-- 
Software Developer
General Satellite Corp.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] stx: add support for AMC8548 board

[oakad]

From: Alex Dubov 

STx AMC8548 board is an old, AMC form factor, MPC8548 based board intended
for RapidIO applications. It features 16MiB NAND flash, one DDR2 soDIMM
slot, ethernet on front panel and backplane, RapidIO on backplane, USB
controller on local bus (not currently enabled) and no PCI of any kind.

Signed-off-by: Alex Dubov 
---
 Makefile  |3 +
 board/stx/stxamc8548/Makefile |   51 ++
 board/stx/stxamc8548/config.mk|   32 
 board/stx/stxamc8548/stxamc8548.c |  168 +++
 board/stx/stxamc8548/u-boot.lds   |  143 
 include/configs/stxamc8548.h  |  332 +
 6 files changed, 729 insertions(+), 0 deletions(-)
 create mode 100644 board/stx/stxamc8548/Makefile
 create mode 100644 board/stx/stxamc8548/config.mk
 create mode 100644 board/stx/stxamc8548/stxamc8548.c
 create mode 100644 board/stx/stxamc8548/u-boot.lds
 create mode 100644 include/configs/stxamc8548.h

diff --git a/Makefile b/Makefile
index a445eba..909c2ca 100644
--- a/Makefile
+++ b/Makefile
@@ -2525,6 +2525,9 @@ sbc8560_66_config:unconfig
 socrates_config:   unconfig
@$(MKCONFIG) $(@:_config=) ppc mpc85xx socrates
 
+stxamc8548_config: unconfig
+   @$(MKCONFIG) $(@:_config=) ppc mpc85xx stxamc8548 stx
+
 stxgp3_config: unconfig
@$(MKCONFIG) $(@:_config=) ppc mpc85xx stxgp3 stx
 
diff --git a/board/stx/stxamc8548/Makefile b/board/stx/stxamc8548/Makefile
new file mode 100644
index 000..39387d9
--- /dev/null
+++ b/board/stx/stxamc8548/Makefile
@@ -0,0 +1,51 @@
+#
+# Copyright 2004 Freescale Semiconductor.
+# (C) Copyright 2001-2006
+# 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 $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).a
+
+COBJS-y+= $(BOARD).o
+
+SRCS   := $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS-y))
+SOBJS  := $(addprefix $(obj),$(SOBJS-y))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+   $(AR) $(ARFLAGS) $@ $(OBJS)
+
+clean:
+   rm -f $(OBJS) $(SOBJS)
+
+distclean: clean
+   rm -f $(LIB) core *.bak $(obj).depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/stx/stxamc8548/config.mk b/board/stx/stxamc8548/config.mk
new file mode 100644
index 000..923828b
--- /dev/null
+++ b/board/stx/stxamc8548/config.mk
@@ -0,0 +1,32 @@
+#
+# Copyright 2009 Alex Dubov 
+#
+# 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
+#
+
+#
+# STx amc8548 board
+#
+ifndef TEXT_BASE
+TEXT_BASE = 0xfffc
+endif
+
+PLATFORM_CPPFLAGS += -DCONFIG_E500=1
+PLATFORM_CPPFLAGS += -DCONFIG_MPC85xx=1
+PLATFORM_CPPFLAGS += -DCONFIG_MPC8548=1
diff --git a/board/stx/stxamc8548/stxamc8548.c 
b/board/stx/stxamc8548/stxamc8548.c
new file mode 100644
index 000..02ef97b
--- /dev/null
+++ b/board/stx/stxamc8548/stxamc8548.c
@@ -0,0 +1,168 @@
+/*
+ * (C) Copyright 2009 Alex Dubov 
+ *
+ * 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.

[U-Boot] [PATCH 2/2] stx: add support for AMC8548 board

[Alex Dubov]

STx AMC8548 board is an old, AMC form factor, MPC8548 based board intended
for RapidIO applications. It features 16MiB NAND flash, one DDR2 soDIMM
slot, ethernet on front panel and backplane, RapidIO on backplane, USB
controller on local bus (not currently enabled) and no PCI of any kind.

Signed-off-by: Alex Dubov 
---
 Makefile  |3 +
 board/stx/stxamc8548/Makefile |   51 ++
 board/stx/stxamc8548/config.mk|   32 
 board/stx/stxamc8548/stxamc8548.c |  168 +++
 board/stx/stxamc8548/u-boot.lds   |  143 
 include/configs/stxamc8548.h  |  332 +
 6 files changed, 729 insertions(+), 0 deletions(-)
 create mode 100644 board/stx/stxamc8548/Makefile
 create mode 100644 board/stx/stxamc8548/config.mk
 create mode 100644 board/stx/stxamc8548/stxamc8548.c
 create mode 100644 board/stx/stxamc8548/u-boot.lds
 create mode 100644 include/configs/stxamc8548.h

diff --git a/Makefile b/Makefile
index a445eba..909c2ca 100644
--- a/Makefile
+++ b/Makefile
@@ -2525,6 +2525,9 @@ sbc8560_66_config:unconfig
 socrates_config:   unconfig
@$(MKCONFIG) $(@:_config=) ppc mpc85xx socrates
 
+stxamc8548_config: unconfig
+   @$(MKCONFIG) $(@:_config=) ppc mpc85xx stxamc8548 stx
+
 stxgp3_config: unconfig
@$(MKCONFIG) $(@:_config=) ppc mpc85xx stxgp3 stx
 
diff --git a/board/stx/stxamc8548/Makefile b/board/stx/stxamc8548/Makefile
new file mode 100644
index 000..39387d9
--- /dev/null
+++ b/board/stx/stxamc8548/Makefile
@@ -0,0 +1,51 @@
+#
+# Copyright 2004 Freescale Semiconductor.
+# (C) Copyright 2001-2006
+# 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 $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).a
+
+COBJS-y+= $(BOARD).o
+
+SRCS   := $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS-y))
+SOBJS  := $(addprefix $(obj),$(SOBJS-y))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+   $(AR) $(ARFLAGS) $@ $(OBJS)
+
+clean:
+   rm -f $(OBJS) $(SOBJS)
+
+distclean: clean
+   rm -f $(LIB) core *.bak $(obj).depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/stx/stxamc8548/config.mk b/board/stx/stxamc8548/config.mk
new file mode 100644
index 000..923828b
--- /dev/null
+++ b/board/stx/stxamc8548/config.mk
@@ -0,0 +1,32 @@
+#
+# Copyright 2009 Alex Dubov 
+#
+# 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
+#
+
+#
+# STx amc8548 board
+#
+ifndef TEXT_BASE
+TEXT_BASE = 0xfffc
+endif
+
+PLATFORM_CPPFLAGS += -DCONFIG_E500=1
+PLATFORM_CPPFLAGS += -DCONFIG_MPC85xx=1
+PLATFORM_CPPFLAGS += -DCONFIG_MPC8548=1
diff --git a/board/stx/stxamc8548/stxamc8548.c 
b/board/stx/stxamc8548/stxamc8548.c
new file mode 100644
index 000..02ef97b
--- /dev/null
+++ b/board/stx/stxamc8548/stxamc8548.c
@@ -0,0 +1,168 @@
+/*
+ * (C) Copyright 2009 Alex Dubov 
+ *
+ * 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 progr