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

2009-08-03 Thread Wolfgang Denk
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?


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
[Doctors and Bartenders], We both get the same two kinds of customers
-- the living and the dying.
-- Dr. Boyce, "The Menagerie" ("The Cage"), stardate unknown
___
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 pci_setup_indirect into fsl_pci_init

2009-08-03 Thread Wolfgang Denk
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?

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 world is no nursery.  - Sigmund Freud
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] stxamc8548: initial commit

2009-08-03 Thread Peter Tyser
Hi Alex,

Alex Dubov wrote:
>> When you say its an "old" board, hopefully its still being used.  ie
>> adding support for an "old" board still has some value? :)
> 
> The board is still for sale, even though it's not recommended for new
> designs.
> 
> http://www.silicontkx.com/AMC8548.htm
> 
> But then, there are not that many boards for RapidIO development, so the
> board is still very much in use by people who do this style of work.
> 
> As to the most of the other issues: I mostly used copy/paste from other board
> configs to do fix up my board's setup. Can you recommend a particular board
> config which can serve a style reference? Freescale's MPC8548CDS is even
> less prettier than my stuff.

I don't think any board is "perfect".  As time goes on standards seem 
to keep getting higher, which is a good thing.  Most of the boards you'd 
base your patches off were accepted when the bar was a bit lower, so 
they have some of the same issues pointed out in your patch.

Your patch seems relatively close to being accepted though, so I'd 
recommend just fixing up the issues Wolfgang and I pointed out and 
resubmitting.  It might take an iteration or 2 to get it accepted, but 
it shouldn't take too much more work hopefully.

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


Re: [U-Boot] [PATCH] stxamc8548: initial commit

2009-08-03 Thread Alex Dubov

> When you say its an "old" board, hopefully its still being used.  ie
> adding support for an "old" board still has some value? :)

The board is still for sale, even though it's not recommended for new
designs.

http://www.silicontkx.com/AMC8548.htm

But then, there are not that many boards for RapidIO development, so the
board is still very much in use by people who do this style of work.

As to the most of the other issues: I mostly used copy/paste from other board
configs to do fix up my board's setup. Can you recommend a particular board
config which can serve a style reference? Freescale's MPC8548CDS is even
less prettier than my stuff.



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


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

2009-08-03 Thread Kumar Gala
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.

Signed-off-by: Kumar Gala 
---
 board/atum8548/atum8548.c |8 
 board/freescale/mpc8536ds/mpc8536ds.c |   12 
 board/freescale/mpc8544ds/mpc8544ds.c |   12 
 board/freescale/mpc8548cds/mpc8548cds.c   |7 ---
 board/freescale/mpc8568mds/mpc8568mds.c   |6 --
 board/freescale/mpc8569mds/mpc8569mds.c   |3 ---
 board/freescale/mpc8572ds/mpc8572ds.c |9 -
 board/freescale/mpc8610hpcd/mpc8610hpcd.c |9 -
 board/freescale/mpc8641hpcn/mpc8641hpcn.c |6 --
 board/freescale/p2020ds/p2020ds.c |9 -
 board/sbc8548/sbc8548.c   |   11 ---
 board/sbc8641d/sbc8641d.c |7 ---
 board/tqc/tqm85xx/tqm85xx.c   |7 ---
 board/xes/common/fsl_8xxx_pci.c   |   12 
 drivers/pci/fsl_pci_init.c|8 +++-
 include/asm-ppc/fsl_pci.h |1 -
 16 files changed, 7 insertions(+), 120 deletions(-)

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,
@@ -282,9 +279,6 @@ pci_init_board(void)
(uint)pci
);
 
-   /* inbound */
-   r += fsl_pci_setup_inbound_windows(r);
-
/* outbound memory */
pci_set_region(r++,
   CONFIG_SYS_PCI1_MEM_BASE,
@@ -320,8 +314,6 @@ pci_init_board(void)
struct pci_region *r = hose->regions;
 
if (!(devdisr & MPC85xx_DEVDISR_PCI2)) {
-   r += fsl_pci_setup_inbound_windows(r);
-
pci_set_region(r++,
   CONFIG_SYS_PCI2_MEM_BASE,
   CONFIG_SYS_PCI2_MEM_PHYS,
diff --git a/board/freescale/mpc8536ds/mpc8536ds.c 
b/board/freescale/mpc8536ds/mpc8536ds.c
index 9d2753e..5bd20ce 100644
--- a/board/freescale/mpc8536ds/mpc8536ds.c
+++ b/board/freescale/mpc8536ds/mpc8536ds.c
@@ -230,9 +230,6 @@ pci_init_board(void)
}
printf ("\n");
 
-   /* inbound */
-   r += fsl_pci_setup_inbound_windows(r);
-
/* outbound memory */
pci_set_region(r++,
   CONFIG_SYS_PCIE3_MEM_BUS,
@@ -284,9 +281,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_BUS,
@@ -345,9 +339,6 @@ pci_init_board(void)
}
printf ("\n");
 
-   /* inbound */
-   r += fsl_pci_setup_inbound_windows(r);
-
/* outbound memory */
pci_set_region(r++,
   CONFIG_SYS_PCIE2_MEM_BUS,
@@ -412,9 +403,6 @@ pci_init_board(void)
(uint)pci
);
 
-   /* inbound */
-   r += fsl_pci_setup_inbound_windows(r);
-
/* outbound memory */
pci_set_region(r++,
   CONFIG_SYS_PCI1_MEM_BUS,
diff --git a/board/freescale/mpc8544ds/mpc8544ds.c 
b/board/freescale/mpc8544ds/mpc8544ds.c
index 60bde68..5a47d0a 100644
--- a/board/freescale/mpc8544ds/mpc8544ds.c
+++ b/board/freescale/mpc8544ds/mpc8544ds.c
@@ -139,9 +139,6 @@ pci_init_board(void)
}
printf ("\n");
 
-   /* inbound */
-   r += fsl_pci_setup_inbound_windows(r);
-
/* outbound memory */
pci_set_region(r++,
   CONFIG_SYS_PCIE3_MEM_BUS,
@@ -205,9 +202,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_BUS,
@@ -266,9 +260,6 @@ pci_init_board(void)
}
printf ("\n");
 
-   /* inbound */
-   r += fsl_pci_setup_inbound_windows(r);
-
/* outbound memory */
pci_set_region(r++,
   CONFIG_SYS_PCIE2_MEM_BUS,
@@ -333,9 +324,6 @@ pci_init_board(void)

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

2009-08-03 Thread Kumar Gala
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.

Signed-off-by: Kumar Gala 
---
 board/atum8548/atum8548.c |   10 +++---
 board/freescale/mpc8536ds/mpc8536ds.c |   13 -
 board/freescale/mpc8544ds/mpc8544ds.c |   13 -
 board/freescale/mpc8548cds/mpc8548cds.c   |6 ++
 board/freescale/mpc8568mds/mpc8568mds.c   |6 ++
 board/freescale/mpc8569mds/mpc8569mds.c   |4 +---
 board/freescale/mpc8572ds/mpc8572ds.c |   10 +++---
 board/freescale/mpc8610hpcd/mpc8610hpcd.c |   12 +++-
 board/freescale/mpc8641hpcn/mpc8641hpcn.c |6 ++
 board/freescale/p2020ds/p2020ds.c |   13 +++--
 board/sbc8548/sbc8548.c   |6 ++
 board/sbc8641d/sbc8641d.c |6 ++
 board/tqc/tqm85xx/tqm85xx.c   |8 ++--
 board/xes/common/fsl_8xxx_pci.c   |   16 
 drivers/pci/fsl_pci_init.c|6 --
 include/asm-ppc/fsl_pci.h |2 +-
 16 files changed, 42 insertions(+), 95 deletions(-)

diff --git a/board/atum8548/atum8548.c b/board/atum8548/atum8548.c
index c8085c7..7a02cdc 100644
--- a/board/atum8548/atum8548.c
+++ b/board/atum8548/atum8548.c
@@ -244,9 +244,7 @@ pci_init_board(void)
hose->region_count = r - hose->regions;
hose->first_busno=first_free_busno;
 
-   pci_setup_indirect(hose, (int) &pci->cfg_addr, (int) 
&pci->cfg_data);
-
-   fsl_pci_init(hose);
+   fsl_pci_init(hose, (u32)&pci->cfg_addr, (u32)&pci->cfg_data);
 
first_free_busno=hose->last_busno+1;
printf("PCIE1 on bus %02x - %02x\n",
@@ -302,9 +300,8 @@ pci_init_board(void)
   PCI_REGION_IO);
hose->region_count = r - hose->regions;
hose->first_busno=first_free_busno;
-   pci_setup_indirect(hose, (int) &pci->cfg_addr, (int) 
&pci->cfg_data);
 
-   fsl_pci_init(hose);
+   fsl_pci_init(hose, (u32)&pci->cfg_addr, (u32)&pci->cfg_data);
first_free_busno=hose->last_busno+1;
printf ("PCI1 on bus %02x - %02x\n",
hose->first_busno,hose->last_busno);
@@ -338,9 +335,8 @@ pci_init_board(void)
   PCI_REGION_IO);
hose->region_count = r - hose->regions;
hose->first_busno=first_free_busno;
-   pci_setup_indirect(hose, (int) &pci->cfg_addr, (int) 
&pci->cfg_data);
 
-   fsl_pci_init(hose);
+   fsl_pci_init(hose, (u32)&pci->cfg_addr, (u32)&pci->cfg_data);
first_free_busno=hose->last_busno+1;
printf ("PCI2 on bus %02x - %02x\n",
hose->first_busno,hose->last_busno);
diff --git a/board/freescale/mpc8536ds/mpc8536ds.c 
b/board/freescale/mpc8536ds/mpc8536ds.c
index 8c5984b..9d2753e 100644
--- a/board/freescale/mpc8536ds/mpc8536ds.c
+++ b/board/freescale/mpc8536ds/mpc8536ds.c
@@ -250,9 +250,8 @@ pci_init_board(void)
hose->region_count = r - hose->regions;
 
hose->first_busno=first_free_busno;
-   pci_setup_indirect(hose, (int) &pci->cfg_addr, (int) 
&pci->cfg_data);
 
-   fsl_pci_init(hose);
+   fsl_pci_init(hose, (u32)&pci->cfg_addr, (u32)&pci->cfg_data);
 
first_free_busno=hose->last_busno+1;
printf ("PCIE3 on bus %02x - %02x\n",
@@ -313,9 +312,7 @@ pci_init_board(void)
hose->region_count = r - hose->regions;
hose->first_busno=first_free_busno;
 
-   pci_setup_indirect(hose, (int) &pci->cfg_addr, (int) 
&pci->cfg_data);
-
-   fsl_pci_init(hose);
+   fsl_pci_init(hose, (u32)&pci->cfg_addr, (u32)&pci->cfg_data);
 
first_free_busno=hose->last_busno+1;
printf("PCIE1 on bus %02x - %02x\n",
@@ -375,9 +372,8 @@ pci_init_board(void)
 #endif
hose->region_count = r - hose->regions;
hose->first_busno=first_free_busno;
-   pci_setup_indirect(hose, (int) &pci->cfg_addr, (int) 
&pci->cfg_data);
 
-   fsl_pci_init(hose);
+   fsl_pci_init(hose, (u32)&pci->cfg_addr, (u32)&pci->cfg_data);
first_free_busno=hose->last_busno+1;
printf ("PCIE2 on bus %02x - %02x\n",
hose->first_busno,hose->last_busno);
@@ -443,9 +439,8 @@ pci_init_board(void)
 #endif
hose->region_count = r - hose->regions;
hose->first_busno=first_free_busno;
-   pci_setup_indirect(hose, (int) &pci->cfg_addr, (int) 
&pci->cfg_data);
 
-   fsl_pci_init(hose);
+   fsl_pci_init(hose, (u32)&pci->cfg_addr, (u32)&pci

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

2009-08-03 Thread Wolfgang Denk
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.
> 
> 
> 
> 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


[U-Boot] u-boot Flash problem

2009-08-03 Thread Pranay Malik - Mclean
Hi,

 

I am having problem with my intel (p33) 64 Mb flash.

For some reason only 32 Mg gets initialized, though before putting uboot
on board I could access my whole 64 mb through debugger.

My board is mpc8377erdb ( powerpc )

Port width and chip width seem to be 16 bit.

 

Any help would be appreciated as this is becoming a major show stopper
for me.

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


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

2009-08-03 Thread Jerry Van Baren
J.C. Wren wrote:
> I notice that when I hit return at a U-Boot > prompt, it executes the last
> command again.  CONFIG_SYS_HUSH_PARSER is defined, from U-Boot
> 2009.08-rc1-00030-g56bdfa9-dirty.
> 
> It this is expected, it seems like a *really* bad idea.  It's cost me having
> to reload 6M images at 115200 twice now.
> 
> --jc

Hi JC,

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.



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.

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.

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


Re: [U-Boot] [PATCH v2] P2020RDB Platform suppport added

2009-08-03 Thread Wolfgang Denk
Dear Poonam,

in message 
<1bd5cfc378ed0946b688e0c9ba2ef095192...@zin33exm24.fsl.freescale.net> you wrote:
> 
> > Please explain why - we've been using this on PowerPC (where 
> > it has been implemented right in the beginning) for more than 
> > 9 years now, without ever finding it difficult.
> Could you please point me to some Freescale platform which is using this
> API so that I can use the implementation as a reference. I searched but
> could not find. 

What do you mean by "Freescale platform'? Freescale board,m or board
based on Freescale processors? I'm not responsible for the former, so
I cannot comment. As for boards using Freescale processors, see for
example:

board/tqc/tqm5200/tqm5200.c:test2 = get_ram_size((long 
*)(CONFIG_SYS_SDRAM_BASE + dramsize), 0x2000);
board/tqc/tqm5200/tqm5200.c:test1 = get_ram_size((long 
*)CONFIG_SYS_SDRAM_BASE, 0x2000);
board/tqc/tqm5200/tqm5200.c:test2 = get_ram_size((long 
*)CONFIG_SYS_SDRAM_BASE, 0x2000);
board/tqc/tqm5200/tqm5200.c:test2 = test1 = get_ram_size((long 
*)(CONFIG_SYS_SDRAM_BASE + dramsize), 0x2000);
board/tqc/tqm8260/tqm8260.c:size = get_ram_size((long *)base, maxsize);
board/tqc/tqm8272/tqm8272.c:size = get_ram_size((long *)base, maxsize);
board/tqc/tqm834x/tqm834x.c:size = get_ram_size(base, 
DDR_MAX_SIZE_PER_CS);
board/tqc/tqm85xx/sdram.c:  if (get_ram_size (0, 
ddr_cs_conf[i].size) ==
board/tqc/tqm8xx/tqm8xx.c:  return (get_ram_size(base, maxsize));

...just to give you a small slection.

> > > > 534 MHz? Not 533.333 = 4 x 133.333 ? 
> > 
> > You did not comment this one.
> The settings were suggested by board designer,might be just to take care
> of the infinite series boundary condition.

I recommend to ask him again. This looks wrong to me.

> > > A very good suggestion!, This will save us from maintaining the 
> > > redundant stuff at many places.
> > > May be this change would not be possible immediately, as we 
> > need the 
> > > P2020RDB board support in mainline quickly at the moment.
> > 
> > Well, it will not got in before the next merge window opens, 
> > which means not before September. Which leaves you with at 
> > least 4 weeks of time for such a cleanup.
> Okay, but I need to work on other patches also for P2020RDB :( 

Hey, all the better - then you can integrate this for P2020RDB, too,
while you are at 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
When the bosses talk about improving  productivity,  they  are  never
talking about themselves.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] stxamc8548: initial commit

2009-08-03 Thread Wolfgang Denk
Dear Alex Dubov,

In message <123712.99670...@web37606.mail.mud.yahoo.com> you wrote:
> 
> 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.

I will not repeat the comments already made by Peter Tyser.

>  board/stxamc8548/Makefile |   54 ++
>  board/stxamc8548/config.mk|   32 
>  board/stxamc8548/ddr.c|   87 +
>  board/stxamc8548/law.c|   54 ++
>  board/stxamc8548/stxamc8548.c |  260 +++
>  board/stxamc8548/tlb.c|   91 ++
>  board/stxamc8548/u-boot.lds   |  143 +++
>  include/configs/stxamc8548.h  |  396 
> +
>  8 files changed, 1117 insertions(+), 0 deletions(-)
>  create mode 100644 board/stxamc8548/Makefile
>  create mode 100644 board/stxamc8548/config.mk
>  create mode 100644 board/stxamc8548/ddr.c
>  create mode 100644 board/stxamc8548/law.c
>  create mode 100644 board/stxamc8548/stxamc8548.c
>  create mode 100644 board/stxamc8548/tlb.c
>  create mode 100644 board/stxamc8548/u-boot.lds
>  create mode 100644 include/configs/stxamc8548.h

So this is the 4th STX board we're adding (after stxgp3, stxssa, and
stxxtc). I think it's time to

- create a board/stx/ vendor directory and move the existing and the
  new code there
- factor out common code. For example, files board/stxgp3/ddr.c and
  board/stxssa/ddr.c are absolutely identical, and your new ddr.c
  seems not to be too different; same is true for the law.c files,
  etc.

...
> + /*
> +  * Setup SDRAM Base and Option Registers
> +  */
> + lbc->or2 = CONFIG_SYS_OR2_PRELIM;
> + asm("msync");
> +
> + lbc->br2 = CONFIG_SYS_BR2_PRELIM;
> + asm("msync");
> +
> + lbc->lbcr = CONFIG_SYS_LBC_LBCR;
> + asm("msync");

As already menatione by Peter: use I/O accessors.

...
> +struct fsl_e_tlb_entry tlb_table[] = {
> + /* TLB 0 - for temp stack in cache */
> + 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,
> +   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,
> +   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,

These lines are _way_ too long. Check globally!

...
> +/* The mac addresses for all ethernet interface */
> +#if defined(CONFIG_TSEC_ENET)
> +#define CONFIG_HAS_ETH0
> +#define CONFIG_ETHADDR   02:E0:0C:BA:D0:33
> +#define CONFIG_HAS_ETH1
> +#define CONFIG_ETH1ADDR  02:E0:0C:BA:D1:33
> +#define CONFIG_HAS_ETH2
> +#define CONFIG_ETH2ADDR  02:E0:0C:BA:D2:33
> +#define CONFIG_HAS_ETH3
> +#define CONFIG_ETH3ADDR  02:E0:0C:BA:D3:33
> +#endif
> +
> +#define CONFIG_IPADDR 192.168.1.201
...
> +#define CONFIG_SERVERIP  192.168.1.14
> +#define CONFIG_GATEWAYIP 192.168.1.254
> +#define CONFIG_NETMASK   255.255.255.0

This gives you a full NAK.

> +#define  CONFIG_EXTRA_ENV_SETTINGS   \
> + "netdev=eth0\0" \
> + "uboot=" MK_STR(CONFIG_UBOOTPATH) "\0"  \
> + "tftpflash=tftpboot $loadaddr $uboot; " \
> + "protect off " MK_STR(TEXT_BASE) " +$filesize; "\
> + "erase " MK_STR(TEXT_BASE) " +$filesize; "  \
> + "cp.b $loadaddr " MK_STR(TEXT_BASE) " $filesize; "  \
> + "protect on " MK_STR(TEXT_BASE) " +$filesize; " \
> + "cmp.b $loadaddr " MK_STR(TEXT_BASE) " $filesize\0" \

Indentation by TAB only, please (fix globally).

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 have phasers, I vote we blast 'em!
-- Bailey, "The Corbomite Maneuver", stardate 1514.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] Normal command line behavior?

2009-08-03 Thread J.C. Wren
I notice that when I hit return at a U-Boot > prompt, it executes the last
command again.  CONFIG_SYS_HUSH_PARSER is defined, from U-Boot
2009.08-rc1-00030-g56bdfa9-dirty.

It this is expected, it seems like a *really* bad idea.  It's cost me having
to reload 6M images at 115200 twice now.

--jc
___
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

2009-08-03 Thread Scott Wood
On Mon, Aug 03, 2009 at 06:01:03AM +0400, Ilya Yanok wrote:
> >> +  return;
> >> +  }
> >> +
> >> +  if (chip == -1) {
> >> +  writew(readw(&host->regs->nfc_config1) & ~NFC_CE,
> >> +  &host->regs->nfc_config1);
> >> +  return;
> >> +  }
> >> +
> >> +  writew(readw(&host->regs->nfc_config1) | NFC_CE,
> >> +  &host->regs->nfc_config1);
> >> +#endif
> >> 
> >
> > #else?
> >   
> 
> For me it just works (I've never defined CONFIG_MTD_NAND_MXC_FORCE_CE).

If you've never defined it, how do you know it "just works"? :-)

Under what circumstances would one define it?  Should we take it out, to be
added later by someone who can test it, and understands it better?

> >> +  if (column >= mtd->writesize) {
> >> +  /*
> >> +   * before sending SEQIN command for partial write,
> >> +   * we need read one page out. FSL NFC does not support
> >> +   * partial write. It alway send out 512+ecc+512+ecc ...
> >> +   * for large page nand flash. But for small page nand
> >> +   * flash, it does support SPARE ONLY operation.
> >> +   */
> >> +  if (host->pagesize_2k) {
> >> +  /* call ourself to read a page */
> >> +  mxc_nand_command(mtd, NAND_CMD_READ0, 0,
> >> +  page_addr);
> >> +  }
> >> 
> >
> > #ifdef CONFIG_MXC_NAND_HWECC?
> >   
> 
> Uh... I have to admit I don't really have clear understanding of this
> problem and I can't find it's description in i.MX27 Reference Manual...
> Maybe you can point me in some direction? For now I'm not sure if
> putting this under #ifdef won't break something...

It was my understanding that the whole reason for using soft ecc on this
controller was to avoid the weird OOB layout.  If you're only testing with
hard ecc, though, then I'd leave it as is -- I don't want to make untested
changes.

-Scott
___
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

2009-08-03 Thread Darius Augulis
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.

>> 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
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 9379c7e..ade43ed 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -671,6 +671,10 @@ Sergey Lapin
>>
>>  afeb9260ARM926EJS (AT91SAM9260 SoC)
>>
>> +Darius Augulis
>> +
>> +nas4220 CS3516
>> +
> 

fixed alphabetical order.

>> diff --git a/board/nas4220/config.mk b/board/nas4220/config.mk
>> new file mode 100644
>> index 000..5b418ba
>> --- /dev/null
>> +++ b/board/nas4220/config.mk
>> @@ -0,0 +1,14 @@
>> +#
>> +# (c) Copyright 2009
>> +# Linkodas, Inc.
>> +# http://www.linkodas.com
>> +#
>> +# Author: Darius Augulis  
>> +#
>> +# 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.
>> +
>> +TEXT_BASE = 0x1040
>> +LDSCRIPT := $(SRCTREE)/board/$(BOARDDIR)/u-boot.lds
>> diff --git a/board/nas4220/lowlevel_init.S b/board/nas4220/lowlevel_init.S
>> new file mode 100644
>> index 000..d51a5a2
>> --- /dev/null
>> +++ b/board/nas4220/lowlevel_init.S
>> @@ -0,0 +1,96 @@
>> +/*
>> + * (c) Copyright 2009
>> + * Linkodas, Inc.
>> + * http://www.linkodas.com
>> + *
>> + * Author: Darius Augulis  
>> + *
>> + * 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.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +
>> +#define DRAM_SET_MODE   GEMINI_SET_MODE | GEMINI_MODE_DDRAM | \
>> +GEMINI_CAS_3 | GEMINI_BL_4
>> +#define DRAM_SET_TYPE   GEMINI_BUS_32b | GEMINI_RAM_15x10_16x10
>> +
>> +#define DRAM_IOCAP  GEMINI_IOCAP_DRAM_CLOCK | GEMINI_IOCAP_DRAM_DATA | \
>> +GEMINI_IOCAP_DRAM_CTRL
>> +#define DRAM_TIMING GEMINI_RRATE_AREF8 | GEMINI_RTIMER(195) | \
>> +GEMINI_TRFC(11) | GEMINI_TRAS(6) | GEMINI_TWR(3) | \
>> +GEMINI_TRP(3) | GEMINI_TRCD(3) | GEMINI_TCAS(3)
>> +#define DRAM_READ_DLL   GEMINI_RDLL_BYTE3(8) | GEMINI_RDLL_BYTE2(8) | \
>> +GEMINI_RDLL_BYTE1(8) | GEMINI_RDLL_BYTE0(8)
>> +#define DRAM_WRITE_DLL  GEMINI_WDLL(26)
>> +#define DRAM_MEM_CTRL   GEMINI_TRAINING_MODE | GEMINI_DQS_N_FALLING | \
>> +GEMINI_BUF_IN_4rd | (1<<  6)
> please move this to config header and add CONFIG_SYS_ in the name

ok.

>> +
>> +.globl lowlevel_init
>> +lowlevel_init:
>> +
>> +/* DRAM init */
>> +ldr r0, =GEMINI_DRAM_TYPE   /* DRAM set type */
>> +ldr r1, =DRAM_SET_TYPE  /* 32bit, 64 Mbytes total */
>> +str r1, [r0]
> please use write32

ok.

>> +
>> +ldr r0, =GEMINI_DRAM_MODE   /* DRAM set mode */
>> +ldr r1, =DRAM_SET_MODE  /* DDRAM, CAS 3, Burst 4 */
>> +str r1, [r0]
> 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 

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

2009-08-03 Thread Ron Madrid

> "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


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

2009-08-03 Thread Scott Wood
On Mon, Aug 03, 2009 at 08:20:41PM +0530, Rupesh Kumar wrote:
> Hi, 
> I used latest version of u-boot (U-Boot 2009.08-rc1) for NAND booting of 
> my board. Still, it didn't work. 
> Board starts booting and then says read failed and hangs there.  It prints 
> following message on console 
> 
> "NAND boot... read failed (ltesr)"

You most likely got an uncorrectable ECC error reading the data; did you
also program the image from current u-boot, or are you trying to boot an
image written by the old u-boot?  There could be a mismatch on ECC
layout.

Is your board file overriding FMR with CONFIG_FSL_ELBC_FMR (it should
not)?

> I am using 2.1 silicon MPC8313 based custom board with large page NAND.
> 
> Can any one tell how shall i proceed for booting successfully from large 
> page NAND ?

Debugging. :-)

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


Re: [U-Boot] [PATCH v2 2/3] Fix 2k page size NAND for iMX27

2009-08-03 Thread Scott Wood
On Sat, Aug 01, 2009 at 08:28:30AM +0200, Eric Bénard wrote:
> Scott Wood a écrit :
> >On Wed, Jul 15, 2009 at 05:18:40PM +0200, Eric Benard wrote:
> >>Signed-off-by: Eric Benard 
> >>---
> >> drivers/nand/nand_imx.c |   20 +---
> >> include/asm-arm/arch-imx/imx-nand.h |3 ++-
> >> 2 files changed, 19 insertions(+), 4 deletions(-)
> >
> >What tree is this against?  There is no "drivers/nand" in current u-boot,
> >it is in drivers/mtd/nand.  And there is no nand_imx.c.
> >
> sorry this was for u-boot v2.

Ah.  I interpreted the v2 as "this is the second version of this patch".

Can we come up with a less ambiguous way to mark u-boot v2 patches?

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


Re: [U-Boot] Make 'nand write.yaffs' mainline?

2009-08-03 Thread Wolfgang Denk
Dear "J.C. Wren",

In message <17434f2e0908030757t4069c978r1ea8b42330b68...@mail.gmail.com> you 
wrote:
> 
> Being still unfamiliar with u-boot standards and practices for submitting
> patches, etc, what can I do to make this happen?  I can diff it against the
> sources I have and submit a patch to the mailing list, if that's
> acceptable.  I'm building for ARM, and I've proved it works (needing only a
> one change because of the lack of __udivid3 for ARM).

See http://www.denx.de/wiki/U-Boot/Patches for details.

In this case, please make sure especially to include all previous
Signed-off-by: messages.

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 consultant is a person who borrows your watch, tells you what  time
it is, pockets the watch, and sends you a bill for it.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] Make 'nand write.yaffs' mainline?

2009-08-03 Thread J.C. Wren
Being still unfamiliar with u-boot standards and practices for submitting
patches, etc, what can I do to make this happen?  I can diff it against the
sources I have and submit a patch to the mailing list, if that's
acceptable.  I'm building for ARM, and I've proved it works (needing only a
one change because of the lack of __udivid3 for ARM).

--jc

On Mon, Aug 3, 2009 at 10:39 AM, Wolfgang Denk  wrote:

> Dear "J.C. Wren",
>
> In message <17434f2e0908030603t74e23a37ob201fcfb0bf46...@mail.gmail.com>
> you wrote:
> >
> > Scott pointed me at this patch (
> >
> http://git.denx.de/?p=u-boot/u-boot-blackfin.git;a=commitdiff;h=44f07de8cc94836cd3b0fd2fb0cf8b8651461087
> )
> > that's in the Blackfin branch.
> >
> > Would it be possible to make this mainline?
>
> I don't think this patch has ever been submitted on the mailing list,
> at least I cannot find a posting with this subject.
>
> Without postingit on the ML it cannot go into mainline. Actually if
> should not have been added to the BF custoidian repository, either.
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] stxamc8548: initial commit

2009-08-03 Thread Peter Tyser
Hi Alex,
I made a few comments below:

On Sun, 2009-08-02 at 22:24 -0700, Alex Dubov wrote:
> 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.

When you say its an "old" board, hopefully its still being used.  ie
adding support for an "old" board still has some value? :)

> Signed-off-by: Alex Dubov 
> ---
>  board/stxamc8548/Makefile |   54 ++
>  board/stxamc8548/config.mk|   32 
>  board/stxamc8548/ddr.c|   87 +
>  board/stxamc8548/law.c|   54 ++
>  board/stxamc8548/stxamc8548.c |  260 +++
>  board/stxamc8548/tlb.c|   91 ++
>  board/stxamc8548/u-boot.lds   |  143 +++
>  include/configs/stxamc8548.h  |  396 
> +
>  8 files changed, 1117 insertions(+), 0 deletions(-)
>  create mode 100644 board/stxamc8548/Makefile
>  create mode 100644 board/stxamc8548/config.mk
>  create mode 100644 board/stxamc8548/ddr.c
>  create mode 100644 board/stxamc8548/law.c
>  create mode 100644 board/stxamc8548/stxamc8548.c
>  create mode 100644 board/stxamc8548/tlb.c
>  create mode 100644 board/stxamc8548/u-boot.lds
>  create mode 100644 include/configs/stxamc8548.h

You'll need to add entries to MAINTAINERS and MAKEALL.

> diff --git a/board/stxamc8548/Makefile b/board/stxamc8548/Makefile
> new file mode 100644
> index 000..c19a527
> --- /dev/null
> +++ b/board/stxamc8548/Makefile
> @@ -0,0 +1,54 @@
> +#
> +# 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
> +COBJS-y  += ddr.o
> +COBJS-y  += law.o
> +COBJS-y  += tlb.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/stxamc8548/config.mk b/board/stxamc8548/config.mk
> new file mode 100644
> index 000..923828b
> --- /dev/null
> +++ b/board/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/stxamc8548/ddr.c b/board/stxamc8548/ddr.c
> new file mode 100644
> index 000..1fd04d7
> --- /dev/null
> +++ b/board/stxamc8548/ddr.c
> @@ -0,0 +1,87 @@
> +/*
> + * Copyright 2008 Freescale Semiconductor, Inc.
> + * Copyright 2009 Alex Dubov 
>

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

2009-08-03 Thread Rupesh Kumar
Hi, 
I used latest version of u-boot (U-Boot 2009.08-rc1) for NAND booting of 
my board. Still, it didn't work. 
Board starts booting and then says read failed and hangs there.  It prints 
following message on console 

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

I am using 2.1 silicon MPC8313 based custom board with large page NAND.

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

Thanks in advance
Rupesh


 



Scott Wood  
07/29/2009 11:26 PM

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






On Wed, Jul 29, 2009 at 10:05:45PM +0530, Rupesh Kumar wrote:
> I am using u-boot version 1.3.0 included in freescale LTIB released for 
> MPC8313ERDB custom board. 
> I tried NAND booting of MPC8313ERDB board using this u-boot and it 
worked 
> fine.
> 
> Using similar procedure i tried NAND boot on my custom board but it dint 

> work :(
> 
> My board has large page NAND where as MPC8313ERDB has small page NAND. I 

> have modified all the parameters required for Large page NAND.
> It prints initail debug message as shown below and then while copying 
> u-boot code from NAND to DDR it detects NAND blocks as bad block and 
> continuously prints 'B' on Console.
> 
> NAND SPL - U-Boot 1.3.0 (Jul 30 2009 - 06:33:05) MPC83XX
> Loading from NAND : 
> 
B
> 

> 
> 
> Can any one please tell what could be going wrong? Am i missing 
something 
> in large page NAND initialization?

Please try the current upstream u-boot rather than the BSP version.  Large
page support in the mpc8313erdb BSP is likely broken.

-Scott


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


Re: [U-Boot] Make 'nand write.yaffs' mainline?

2009-08-03 Thread Wolfgang Denk
Dear "J.C. Wren",

In message <17434f2e0908030603t74e23a37ob201fcfb0bf46...@mail.gmail.com> you 
wrote:
>
> Scott pointed me at this patch (
> http://git.denx.de/?p=u-boot/u-boot-blackfin.git;a=commitdiff;h=44f07de8cc94836cd3b0fd2fb0cf8b8651461087)
> that's in the Blackfin branch.
> 
> Would it be possible to make this mainline?

I don't think this patch has ever been submitted on the mailing list,
at least I cannot find a posting with this subject.

Without postingit on the ML it cannot go into mainline. Actually if
should not have been added to the BF custoidian repository, either.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] imx27lite: add support for imx27lite board from LogicPD

2009-08-03 Thread Wolfgang Denk
Dear Jean-Christophe PLAGNIOL-VILLARD,

In message <20090803121748.gg15...@game.jcrosoft.org> you wrote:
>
> > > > +#define CONFIG_SYS_MALLOC_LEN  (0x1 + 256 * 1024)
> > > please do not mix hexa and decimal
> I've as there is other think to fix otherwise I'll not have ask
> > 
> > Please be reasonable. This is a perfectly valid and easy to read
> > notation. I see no reason to change this - anything else would
> > probably be much harder to read.

Please do not insist in changing this. No matter how you wrote it,
"0x1 + 0x100 * 0x400" or "0x1 + 0x4" or "65536 + 256 *
1024" or "65536 + 262144" - all thesde forms are more difficult to
parse and give less insight into what is intended.

I say: there is no reason to change this.

> > > > +#define CONFIG_LOADADDR0xa080  /* loadaddr env 
> > > > var */
> > > > +#define CONFIG_SYS_LOAD_ADDR   CONFIG_LOADADDR
> > > why 2?
> > 
> > Because they do different things.
> I've take a look they do nearly the same think it will be better to avoid have
> 2 configs specialy when there are the same

Please feel free to submit a patch if you do not like the current
design. But this has nothing to do with the current patch in
question, i. e. it is not a reason to reject it or ask for changes.

> btw I've found nothing about it in the README

Indeed, documentation is not exactly perfect.  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
Heavier than air flying machines are impossible.
-- Lord Kelvin, President, Royal Society, c. 1895
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] BMP display.

2009-08-03 Thread Tuma
Hello, all!
Detlev, thank for oyur reply.
So I don't need environment file parser any more.

But now I have new question - how can I display a Bitmap picture on the 
board's LCD? I know there is the "bmp" command, but how should I configure 
and build U-Boot to have this command in prompt? My board is OMAP3EVM.

Thank you.


On Thursday 30 July 2009 19:29:27 you wrote:
> Hi Tuma,
>
> > Hello All!
>
> Hiya.
>
> > I develop some "upgrade" tool based on the U-Boot booted from SD card.
> > I want to boot from SD card, and execute some simple script which is
> > stored in bootcmd environment variable:
> > "echo Hello! ; mmcinit ; sleep 10 ; reset; " etc...
> > So I need to generate some environment file.
>
> Sorry, but I do not understand why you need to generate an environment
> image if you only eant to run some scripts.  Can we please step back
> again and talk about what you want to achieve?  Pretty likely there is a
> different and cleaner solution to your problem.
>
> > I find source from tools/env very
> > useful (I try to get variables from correct file I already have), but I
> > can't find any description of environment file (or flash partition) at
> > all (which I need to write tool for generating environment file).
> > Can someone explain me the structure of the file, please.
> > Something like:
> > 0-4 - CRC
>
> Well the problem is that environment can be in a different format,
> depending on configuration options.  If for example you enable redundand
> environments, you will have another byte after the crc signalling which
> of the two copies is the active one.
>
> > 5-... - (Environment)\0(Environment)\0...
> > ... Environment End Mark...
> > and so on.
> >
> > Or tell me in what file should I see from U-Boot source.
>
> A good start would be to read /include/environment.h - but only after
> you are really sure that you want to generate an environment after all
>
> :)
> :
> > And is there any difference between content of OneNAND flash
> > environment-partition and file on SD card?
>
> I can parse the sentence syntactically, but I have no clue what you are
> asking here...
>
> Cheers
>   Detlev



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


[U-Boot] Make 'nand write.yaffs' mainline?

2009-08-03 Thread J.C. Wren
Scott pointed me at this patch (
http://git.denx.de/?p=u-boot/u-boot-blackfin.git;a=commitdiff;h=44f07de8cc94836cd3b0fd2fb0cf8b8651461087)
that's in the Blackfin branch.

Would it be possible to make this mainline?

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


Re: [U-Boot] [PATCH] imx27lite: add support for imx27lite board from LogicPD

2009-08-03 Thread Jean-Christophe PLAGNIOL-VILLARD
On 10:19 Mon 03 Aug , Wolfgang Denk wrote:
> Dear Jean-Christophe PLAGNIOL-VILLARD,
> 
> In message <20090803053218.ga15...@game.jcrosoft.org> you wrote:
> >
> ...
> > > +/* malloc() len */
> > > +#define CONFIG_SYS_MALLOC_LEN(0x1 + 256 * 1024)
> > please do not mix hexa and decimal
I've as there is other think to fix otherwise I'll not have ask
> 
> Please be reasonable. This is a perfectly valid and easy to read
> notation. I see no reason to change this - anything else would
> probably be much harder to read.
> 
> > > +#define CONFIG_LOADADDR  0xa080  /* loadaddr env var */
> > > +#define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR
> > why 2?
> 
> Because they do different things.
I've take a look they do nearly the same think it will be better to avoid have
2 configs specialy when there are the same

btw I've found nothing about it in the README

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


Re: [U-Boot] ARM Pull Request

2009-08-03 Thread Wolfgang Denk
Dear Jean-Christophe PLAGNIOL-VILLARD,

In message <20090803072945.gc15...@game.jcrosoft.org> you wrote:
> Hi,
> 
> Please pull
> The following changes since commit 56bdfa961242fc6acaeebc800640a12b28db3899:
>   Dirk Eibach (1):
> ppc4xx: Remove check for PPC460EX from CompactCenter
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-arm.git master
> 
> David Brownell (1):
>   rm9200 lowevel_init: don't touch reserved/readonly registers
> 
> David Hunter (1):
>   pxa: Fix typo in GCDR(x)
> 
> Eric Benard (1):
>   Add AT91SAM9260 to at91's lowlevel_init.S
> 
>  cpu/arm920t/at91rm9200/lowlevel_init.S |   14 ++
>  cpu/arm926ejs/at91/lowlevel_init.S |2 +-
>  include/asm-arm/arch-pxa/pxa-regs.h|2 +-
>  include/configs/at91rm9200dk.h |5 -
>  include/configs/at91rm9200ek.h |5 -
>  include/configs/cmc_pu2.h  |5 -
>  include/configs/csb637.h   |5 -
>  include/configs/m501sk.h   |5 -
>  include/configs/mp2usb.h   |5 -
>  9 files changed, 4 insertions(+), 44 deletions(-)

Applied, thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
... The things love can drive a man to -- the  ecstasies,  the  mise-
ries,  the broken rules, the desperate chances, the glorious failures
and the glorious victories.
-- McCoy, "Requiem for Methuselah", stardate 5843.7
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2] P2020RDB Platform suppport added

2009-08-03 Thread Aggrwal Poonam-B10812
 

> -Original Message-
> From: u-boot-boun...@lists.denx.de 
> [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Wolfgang Denk
> Sent: Monday, August 03, 2009 1:55 PM
> To: Aggrwal Poonam-B10812
> Cc: u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH v2] P2020RDB Platform suppport added
> 
> Dear Poonam,
> 
> In message 
> <1bd5cfc378ed0946b688e0c9ba2ef095192...@zin33exm24.fsl.freesca
> le.net> you wrote:
> > 
> > > So I always recomment to enable the feature - unless you 
> really have 
> > > to save a few milliseconds on boot time.
> > In that case the API can be really useful. May be I can send the 
> > modifucation to use this API later.
> > Because using it is not quite straight formward on PowerPC. Since I 
> > need
> 
> Please explain why - we've been using this on PowerPC (where 
> it has been implemented right in the beginning) for more than 
> 9 years now, without ever finding it difficult.
Could you please point me to some Freescale platform which is using this
API so that I can use the implementation as a reference. I searched but
could not find. 
> 
> > > > +P2020RDB_config:   unconfig
> > > > +   @mkdir -p $(obj)include
> > > > +   @echo "#define CONFIG_MP" >>$(obj)include/config.h ;
> > > > +   @$(XECHO) "... setting CONFIG_MP." ;
> > > 
> > > Is this really needed? I'd like to keep such stuff out of the 
> > > Makefile.
> > This  would be useful in our case, because the file 
> > include/configgs/P1_P2_RDB.h is intended to be used for 
> more than one 
> > platforms, viz P2020RDB, P1020RDB, P1010RDB , etc. Of them some are 
> > dual core and some are single core. CONFIG_MP would be required for 
> > dual core ones.
> 
> We agree about the purpose, but not about the implementation. 
> Please move this logic intot he board config file. I don't 
> want to see so many lines of "scripting" in the top level Makefile.
> 
Okay I will move it to configs.h
> > > 
> > > > +#define DATARATE_400MHZ 4 #define DATARATE_534MHZ 
> > > > +53400
> > > 
> > > 534 MHz? Not 533.333 = 4 x 133.333 ? 
> 
> 
> You did not comment this one.
The settings were suggested by board designer,might be just to take care
of the infinite series boundary condition.

> 
> ...
> > > Maybe Freescale should come up with a common set of 
> setting for all 
> > > (or at least many) boards, similar to what we have in 
> > > include/configs/amcc-common.h ?
> > A very good suggestion!, This will save us from maintaining the 
> > redundant stuff at many places.
> > May be this change would not be possible immediately, as we 
> need the 
> > P2020RDB board support in mainline quickly at the moment.
> 
> Well, it will not got in before the next merge window opens, 
> which means not before September. Which leaves you with at 
> least 4 weeks of time for such a cleanup.
Okay, but I need to work on other patches also for P2020RDB :( 
> 
> Best regards,
> 
> Wolfgang Denk
Kind Regards
Poonam
> 
> -- 
> 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 greatest threat towards future is indifference.
> ___
> 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 v2] P2020RDB Platform suppport added

2009-08-03 Thread Wolfgang Denk
Dear Poonam,

In message 
<1bd5cfc378ed0946b688e0c9ba2ef095192...@zin33exm24.fsl.freescale.net> you wrote:
> 
> > So I always recomment to enable the feature - unless you 
> > really have to save a few milliseconds on boot time.
> In that case the API can be really useful. May be I can send the
> modifucation to use this API later.
> Because using it is not quite straight formward on PowerPC. Since I need

Please explain why - we've been using this on PowerPC (where it has
been implemented right in the beginning) for more than 9 years now,
without ever finding it difficult.

> > > +P2020RDB_config: unconfig
> > > + @mkdir -p $(obj)include
> > > + @echo "#define CONFIG_MP" >>$(obj)include/config.h ;
> > > + @$(XECHO) "... setting CONFIG_MP." ;
> > 
> > Is this really needed? I'd like to keep such stuff out of the 
> > Makefile.
> This  would be useful in our case, because the file
> include/configgs/P1_P2_RDB.h is intended to be used for more than one
> platforms, viz P2020RDB, P1020RDB, P1010RDB , etc. Of them some are dual
> core and some are single core. CONFIG_MP would be required for dual core
> ones.

We agree about the purpose, but not about the implementation. Please
move this logic intot he board config file. I don't want to see so
many lines of "scripting" in the top level Makefile.

> > 
> > > +#define DATARATE_400MHZ 4
> > > +#define DATARATE_534MHZ 53400
> > 
> > 534 MHz? Not 533.333 = 4 x 133.333 ? 


You did not comment this one.

...
> > Maybe Freescale should come up with a common set of setting 
> > for all (or at least many) boards, similar to what we have in 
> > include/configs/amcc-common.h ?
> A very good suggestion!, This will save us from maintaining the
> redundant stuff at many places.
> May be this change would not be possible immediately, as we need the
> P2020RDB board support in mainline quickly at the moment.

Well, it will not got in before the next merge window opens, which
means not before September. Which leaves you with at least 4 weeks of
time for such a cleanup.

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 greatest threat towards future is indifference.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] ARM Pull Request

2009-08-03 Thread Dirk Behme
Dear Jean-Christophe,

Jean-Christophe PLAGNIOL-VILLARD wrote:
> Hi,
> 
> Please pull
> The following changes since commit 56bdfa961242fc6acaeebc800640a12b28db3899:
>   Dirk Eibach (1):
> ppc4xx: Remove check for PPC460EX from CompactCenter
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-arm.git master
> 
> David Brownell (1):
>   rm9200 lowevel_init: don't touch reserved/readonly registers
> 
> David Hunter (1):
>   pxa: Fix typo in GCDR(x)
> 
> Eric Benard (1):
>   Add AT91SAM9260 to at91's lowlevel_init.S

What's about

1. [PATCHv3 2-5/5] clean up omap3 configuration structs
http://lists.denx.de/pipermail/u-boot/2009-May/052943.html
http://lists.denx.de/pipermail/u-boot/2009-May/052945.html
http://lists.denx.de/pipermail/u-boot/2009-May/052944.html
http://lists.denx.de/pipermail/u-boot/2009-May/052946.html

-> Please see http://lists.denx.de/pipermail/u-boot/2009-July/057615.html

2. [PATCH 1-2/2] V2 remove omap3 compiler warning wrt v7_flush_dcache_all
http://lists.denx.de/pipermail/u-boot/2009-July/055543.html
http://lists.denx.de/pipermail/u-boot/2009-July/055544.html

-> Older patch applied, this is still expected to be applied:

http://lists.denx.de/pipermail/u-boot/2009-July/056859.html

3. PATCH: (Updated) Fix examples for OMAP3 boards...
http://lists.denx.de/pipermail/u-boot/2009-July/056270.html

4. [PATCH]omap3: bug fix for NOR boot support
http://lists.denx.de/pipermail/u-boot/2009-July/057819.html

?

Best regards

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


Re: [U-Boot] [PATCH] imx27lite: add support for imx27lite board from LogicPD

2009-08-03 Thread Wolfgang Denk
Dear Jean-Christophe PLAGNIOL-VILLARD,

In message <20090803053218.ga15...@game.jcrosoft.org> you wrote:
>
...
> > +/* malloc() len */
> > +#define CONFIG_SYS_MALLOC_LEN  (0x1 + 256 * 1024)
> please do not mix hexa and decimal

Please be reasonable. This is a perfectly valid and easy to read
notation. I see no reason to change this - anything else would
probably be much harder to read.

> > +#define CONFIG_LOADADDR0xa080  /* loadaddr env var */
> > +#define CONFIG_SYS_LOAD_ADDR   CONFIG_LOADADDR
> why 2?

Because they do different things.

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
"Where humor is concerned there are no standards -- no  one  can  say
what is good or bad, although you can be sure that everyone will.
- John Kenneth Galbraith
___
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

2009-08-03 Thread Darius Augulis
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.

>> 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
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 9379c7e..ade43ed 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -671,6 +671,10 @@ Sergey Lapin
>>
>>  afeb9260ARM926EJS (AT91SAM9260 SoC)
>>
>> +Darius Augulis
>> +
>> +nas4220 CS3516
>> +
> 

fixed alphabetical order.

>> diff --git a/board/nas4220/config.mk b/board/nas4220/config.mk
>> new file mode 100644
>> index 000..5b418ba
>> --- /dev/null
>> +++ b/board/nas4220/config.mk
>> @@ -0,0 +1,14 @@
>> +#
>> +# (c) Copyright 2009
>> +# Linkodas, Inc.
>> +# http://www.linkodas.com
>> +#
>> +# Author: Darius Augulis  
>> +#
>> +# 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.
>> +
>> +TEXT_BASE = 0x1040
>> +LDSCRIPT := $(SRCTREE)/board/$(BOARDDIR)/u-boot.lds
>> diff --git a/board/nas4220/lowlevel_init.S b/board/nas4220/lowlevel_init.S
>> new file mode 100644
>> index 000..d51a5a2
>> --- /dev/null
>> +++ b/board/nas4220/lowlevel_init.S
>> @@ -0,0 +1,96 @@
>> +/*
>> + * (c) Copyright 2009
>> + * Linkodas, Inc.
>> + * http://www.linkodas.com
>> + *
>> + * Author: Darius Augulis  
>> + *
>> + * 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.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +
>> +#define DRAM_SET_MODE   GEMINI_SET_MODE | GEMINI_MODE_DDRAM | \
>> +GEMINI_CAS_3 | GEMINI_BL_4
>> +#define DRAM_SET_TYPE   GEMINI_BUS_32b | GEMINI_RAM_15x10_16x10
>> +
>> +#define DRAM_IOCAP  GEMINI_IOCAP_DRAM_CLOCK | GEMINI_IOCAP_DRAM_DATA | \
>> +GEMINI_IOCAP_DRAM_CTRL
>> +#define DRAM_TIMING GEMINI_RRATE_AREF8 | GEMINI_RTIMER(195) | \
>> +GEMINI_TRFC(11) | GEMINI_TRAS(6) | GEMINI_TWR(3) | \
>> +GEMINI_TRP(3) | GEMINI_TRCD(3) | GEMINI_TCAS(3)
>> +#define DRAM_READ_DLL   GEMINI_RDLL_BYTE3(8) | GEMINI_RDLL_BYTE2(8) | \
>> +GEMINI_RDLL_BYTE1(8) | GEMINI_RDLL_BYTE0(8)
>> +#define DRAM_WRITE_DLL  GEMINI_WDLL(26)
>> +#define DRAM_MEM_CTRL   GEMINI_TRAINING_MODE | GEMINI_DQS_N_FALLING | \
>> +GEMINI_BUF_IN_4rd | (1<<  6)
> please move this to config header and add CONFIG_SYS_ in the name

ok.

>> +
>> +.globl lowlevel_init
>> +lowlevel_init:
>> +
>> +/* DRAM init */
>> +ldr r0, =GEMINI_DRAM_TYPE   /* DRAM set type */
>> +ldr r1, =DRAM_SET_TYPE  /* 32bit, 64 Mbytes total */
>> +str r1, [r0]
> please use write32

ok.

>> +
>> +ldr r0, =GEMINI_DRAM_MODE   /* DRAM set mode */
>> +ldr r1, =DRAM_SET_MODE  /* DDRAM, CAS 3, Burst 4 */
>> +str r1, [r0]
> 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 

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

2009-08-03 Thread Albin Tonnerre
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

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 ?

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


[U-Boot] ARM Pull Request

2009-08-03 Thread Jean-Christophe PLAGNIOL-VILLARD
Hi,

Please pull
The following changes since commit 56bdfa961242fc6acaeebc800640a12b28db3899:
  Dirk Eibach (1):
ppc4xx: Remove check for PPC460EX from CompactCenter

are available in the git repository at:

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

David Brownell (1):
  rm9200 lowevel_init: don't touch reserved/readonly registers

David Hunter (1):
  pxa: Fix typo in GCDR(x)

Eric Benard (1):
  Add AT91SAM9260 to at91's lowlevel_init.S

 cpu/arm920t/at91rm9200/lowlevel_init.S |   14 ++
 cpu/arm926ejs/at91/lowlevel_init.S |2 +-
 include/asm-arm/arch-pxa/pxa-regs.h|2 +-
 include/configs/at91rm9200dk.h |5 -
 include/configs/at91rm9200ek.h |5 -
 include/configs/cmc_pu2.h  |5 -
 include/configs/csb637.h   |5 -
 include/configs/m501sk.h   |5 -
 include/configs/mp2usb.h   |5 -
 9 files changed, 4 insertions(+), 44 deletions(-)

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


[U-Boot] Changing serial port and sending arbitrary data over serial interface

2009-08-03 Thread Matthias Weisser
Hi

I am currently in the process of reworking my patches to bring my
u-boot port into the official git.
All my work is based on latest head.

Now I came to a point where I don't know how to do it and also didn't
find any board doing the same thing.

My system has six NS16550 serial ports where u-boot only needs to deal
with three of them. So I defined:

#define CONFIG_SYS_NS16550
#define CONFIG_SYS_NS16550_SERIAL
#define CONFIG_SYS_NS16550_REG_SIZE (-4)
#define CONFIG_SYS_NS16550_CLK  CONFIG_JADE_IOCLK
#define
CONFIG_SYS_NS16550_COM1 0xfffe1000  /*
UART 0 */
#define
CONFIG_SYS_NS16550_COM2 0xfffe2000  /*
UART 1 */
#define
CONFIG_SYS_NS16550_COM3 0xfff5  /*
UART 2 (SP) */

#define CONFIG_CONS_INDEX   1

The default is that u-boot uses COM1. Under some circumstances COM2 has
to be used.
So the question is: How to switch (dynamically) between the console
input/output?

I also have to send some arbitrary data to COM3 depending on some
environment variables. These are
commands to a small processor on the same board which will then
switches some devices on which I need
for further booting.


Matthias Weißer

 
Amtsgericht Freiburg HRA 602707
Ust. ID-Nr.: DE232464428

Geschäftsführer: 
Dipl. Ing. (FH) Martin Graf 
Dipl. Ing. (FH) David Graf 
Dipl. Inf. Fabian Graf
 
Komplementärin:
GRAF-SYTECO Verwaltungs-GmbH
Amtsgericht Freiburg HRB 602868 

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


Re: [U-Boot] [patch] rm9200 lowevel_init: don't touch reserved/readonly registers

2009-08-03 Thread Jean-Christophe PLAGNIOL-VILLARD
On 18:40 Thu 16 Jul , David Brownell wrote:
> For some reason the AT91rm9200 lowlevel init writes to a bunch of
> reserved or read-only addresses.  All the boards seem to define the
> value-to-be-written values as zero ... but they shouldn't actually
> be writing *anything* there.
> 
> No documented erratum justifies these accesses.  It looks like maybe
> some pre-release BDI-2000 setup code has been carried along by cargo
> cult programming since at least late 2004 (per GIT history).
> 
> Here's a patch disabling what seems to be bogosity.  Tested on a
> csb337; there were no behavioral changes.
> ---
>  cpu/arm920t/at91rm9200/lowlevel_init.S |   14 ++
>  include/configs/at91rm9200dk.h |5 -
>  include/configs/at91rm9200ek.h |5 -
>  include/configs/cmc_pu2.h  |5 -
>  include/configs/csb637.h   |5 -
>  include/configs/m501sk.h   |5 -
>  include/configs/mp2usb.h   |5 -
>  7 files changed, 2 insertions(+), 42 deletions(-)
> 
Tested on rm9200ek

applied to u-boot-arm

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