[U-Boot] [PATCH v3] SATA: do not auto-initialize during boot

2008-12-22 Thread Mike Frysinger 
Rather than have the board code initialize SATA automatically during boot,
make the user manually run "sata init".  This brings the SATA subsystem in
line with common U-Boot policy.

Rather than having a dedicated weak function "is_sata_supported", people
can override sata_initialize() to do their weird board stuff.  Then they
can call the actual __sata_initialize().

Signed-off-by: Mike Frysinger 
---
v3
- redo how the board weak is handled to be less bloated when
  screwing over everyone else

v2
- auto run `sata init` if needed when doing other `sata ...` cmds

 board/freescale/mpc8536ds/mpc8536ds.c |6 +++---
 common/cmd_sata.c |   12 +++-
 include/sata.h|1 +
 lib_ppc/board.c   |   20 
 4 files changed, 15 insertions(+), 24 deletions(-)

diff --git a/board/freescale/mpc8536ds/mpc8536ds.c 
b/board/freescale/mpc8536ds/mpc8536ds.c
index 2b17612..49474d7 100644
--- a/board/freescale/mpc8536ds/mpc8536ds.c
+++ b/board/freescale/mpc8536ds/mpc8536ds.c
@@ -582,15 +582,15 @@ get_board_ddr_clk(ulong dummy)
 }
 #endif
 
-int is_sata_supported(void)
+int sata_initialize(void)
 {
volatile ccsr_gur_t *gur = (void *)(CFG_MPC85xx_GUTS_ADDR);
uint sdrs2_io_sel =
(gur->pordevsr & MPC85xx_PORDEVSR_SRDS2_IO_SEL) >> 27;
if (sdrs2_io_sel & 0x04)
-   return 0;
+   return 1;
 
-   return 1;
+   return __sata_initialize();
 }
 
 #if defined(CONFIG_OF_BOARD_SETUP)
diff --git a/common/cmd_sata.c b/common/cmd_sata.c
index dd6f1d9..c6e0d37 100644
--- a/common/cmd_sata.c
+++ b/common/cmd_sata.c
@@ -31,7 +31,7 @@
 int curr_device = -1;
 block_dev_desc_t sata_dev_desc[CONFIG_SYS_SATA_MAX_DEVICE];
 
-int sata_initialize(void)
+int __sata_initialize(void)
 {
int rc;
int i;
@@ -55,6 +55,7 @@ int sata_initialize(void)
curr_device = 0;
return rc;
 }
+int sata_initialize(void) __attribute__((weak,alias("__sata_initialize")));
 
 block_dev_desc_t *sata_get_dev(int dev)
 {
@@ -65,6 +66,14 @@ int do_sata(cmd_tbl_t *cmdtp, int flag, int argc, char 
*argv[])
 {
int rc = 0;
 
+   if (argc == 2 && strcmp(argv[1], "init") == 0)
+   return sata_initialize();
+
+   /* If the user has not yet run `sata init`, do it now */
+   if (curr_device == -1)
+   if (sata_initialize())
+   return 1;
+
switch (argc) {
case 0:
case 1:
@@ -186,6 +195,7 @@ int do_sata(cmd_tbl_t *cmdtp, int flag, int argc, char 
*argv[])
 U_BOOT_CMD(
sata, 5, 1, do_sata,
"sata   - SATA sub system\n",
+   "init - init SATA sub system\n"
"sata info - show available SATA devices\n"
"sata device [dev] - show or set current device\n"
"sata part [dev] - print partition table\n"
diff --git a/include/sata.h b/include/sata.h
index 57ee9ac..37573cf 100644
--- a/include/sata.h
+++ b/include/sata.h
@@ -7,5 +7,6 @@ ulong sata_read(int dev, ulong blknr, ulong blkcnt, void 
*buffer);
 ulong sata_write(int dev, ulong blknr, ulong blkcnt, const void *buffer);
 
 int sata_initialize(void);
+int __sata_initialize(void);
 
 #endif
diff --git a/lib_ppc/board.c b/lib_ppc/board.c
index 289a32a..3076824 100644
--- a/lib_ppc/board.c
+++ b/lib_ppc/board.c
@@ -38,9 +38,6 @@
 #if defined(CONFIG_CMD_IDE)
 #include 
 #endif
-#if defined(CONFIG_CMD_SATA)
-#include 
-#endif
 #if defined(CONFIG_CMD_SCSI)
 #include 
 #endif
@@ -635,16 +632,6 @@ void board_init_f (ulong bootflag)
/* NOTREACHED - relocate_code() does not return */
 }
 
-int __is_sata_supported(void)
-{
-   /* For some boards, when sata disabled by the switch, and the
-* driver still access the sata registers, the cpu will hangup.
-* please define platform specific is_sata_supported() if your
-* board have such issue.*/
-   return 1;
-}
-int is_sata_supported(void) __attribute__((weak, 
alias("__is_sata_supported")));
-
 /
  *
  * This is the next part if the initialization sequence: we are now
@@ -1144,13 +1131,6 @@ void board_init_r (gd_t *id, ulong dest_addr)
 #endif
 #endif
 
-#if defined(CONFIG_CMD_SATA)
-   if (is_sata_supported()) {
-   puts("SATA:  ");
-   sata_initialize();
-   }
-#endif
-
 #ifdef CONFIG_LAST_STAGE_INIT
WATCHDOG_RESET ();
/*
-- 
1.6.0.4

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

Re: [U-Boot] [PATCH] SATA: do not auto-initialize during boot

2008-12-22 Thread Mike Frysinger 
On Thursday 11 December 2008 18:57:37 Wolfgang Denk wrote:
> In message <200812111624.20543.vap...@gentoo.org> you wrote:
> > it made sense when the init step was automatic.  but you're telling me
> > users
>
> And we still want to have it automatic, just deferred.
>
> > of your board are incapable of looking at it and going "hmm, this has a
> > SATA disk" ?  it isnt like disks are tiny and they have to scan a board
> > for some obscure IC.  disks are friggin huge.
>
> Come on. Have you never seen a system that came in a case, and you
> didn't know if it included a disk, or how many of these?

if it were a system that wasnt mine, sure.  but if i'm expected to actually 
develop on it, then it cant be a black box.  so no, i dont think it's 
unreasonable to have people who actually be using the hardware know what is in 
the system.
-mike


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

Re: [U-Boot] [PATCH] SATA: do not auto-initialize during boot

2008-12-22 Thread Mike Frysinger 
On Thursday 11 December 2008 19:15:06 Scott Wood wrote:
> Mike Frysinger wrote:
> > On Thursday 11 December 2008 18:53:00 Wolfgang Denk wrote:
> >> And if they do, the code should fail gracefully, i. e. print some
> >> friendly error message like that S-ATA is not available.
> >
> > in this case, i think that's up to the controller.  i.e. the controller
> > doesnt find anything and you get a message that nothing was found.
> >
> > i dont have a board to test with to know what will happen exactly, nor
> > does the current code make any statement that i can see.  Scott ?
>
> IIUC, if it's "not available" the driver will still see the controller
> regs, but it will be trying to control pins that are actually routed to
> another device.  That said, it should be the driver calling into
> SoC-specific code to find out, rather than a global SATA-blocker (what
> if a PCIe SATA card were used?).

i agree with that sentiment, but i'm not about to take on that restructure ;)
-mike


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

Re: [U-Boot] [RFC][PATCH] Code Clean-up (weak functions)

2008-12-22 Thread Mike Frysinger 
On Monday 22 December 2008 06:20:27 Graeme Russ wrote:
> On Mon, Dec 22, 2008 at 10:44 PM, Mike Frysinger  wrote:
> > On Monday 22 December 2008 04:16:33 Graeme Russ wrote:
> >> On Mon, Dec 22, 2008 at 8:05 PM, Mike Frysinger wrote:
> >> > On Saturday 13 December 2008 00:26:26 Graeme Russ wrote:
> >> >> This patch makes all definitions, declarations and usages of weak
> >> >> functions consistent.
> >> >
> >> > a quick glance shows that it breaks things (the ELF and Blackfin stuff
> >> > certainly appears to be wrong).  i'm guessing you focused on style for
> >> > the RFC part rather than the result actually being correct ...
> >> > -mike
> >>
> >> Thanks for having a look at this. Would it be possible for you to be a
> >> bit more specific about 'wrong' if for nothing other that me gaining a
> >> better understanding of how it works, and how it breaks
> >
> > you set the aliases to functions that do not exist
>
> Ack  - I can see that for the ELF - the main function needs to be renamed
> __do_bootelf_exec ()
>
> I cannot see the problem with Blackfin - I will freely admit that Blackfin
> has been fundamentally changed (any therefore needs thorough testing), but
> unless the Blackfin toolchain treats weak function linking differently, it
> _should_ "just still work"(tm)
>
> Maybe I am not seeing the obvious?

sorry, you're right, you added the new function.  that said, i dont think 
marking those functions as "inline" is correct or makes sense.
-mike


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

[U-Boot] nand sector size is zero in jffs2 cmds

2008-12-22 Thread Derek Ou 
Hi, all,

When I tested jffs2 command for NAND, I found that jffs2_1pass.c:: 
jffs2_1pass_build_lists() fails at
u32 nr_sectors = part->size/part->sector_size;
because part->sector_size is zero.  And cause the "### ERROR ### Please 
RESET the board ###" error when entering the for loop (i < nr_sectors), 
I think.

It looks like the sector_size was not updated in mtdparts_init().  
According to cmd_jffs2.c, the mtdparts_init in the #ifdef 
CONFIG_JFFS2_CMDLINE section calls the parse_mtdparts() and eventually 
reach the following lines in part_validate_nand():
nand = &nand_info[id->num];
part->sector_size = nand->erasesize;
However, the other mtdparts_init(), which is not in the #ifdef 
CONFIG_JFFS2_CMDLINE section, does not call parse_mtdparts() and it may 
lead to the part->sector_size not initialized.

I am not totally familiar with this jffs2 and nand code.  Can someone 
review this?  Thanks.
Derek
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Please pull u-boot-mpc85xx.git

2008-12-22 Thread Andy Fleming 
On Mon, Dec 22, 2008 at 6:08 PM, Peter Tyser  wrote:
> Hi Andy,
>
> On Mon, 2008-12-22 at 13:36 -0600, Andy Fleming wrote:
>> are available in the git repository at:
>>
>>   git://www.denx.de/git/u-boot-mpc85xx.git master
>
> 
>
>> Peter Tyser (5):
>>   pci/fsl_pci_init: Enable inbound PCI config cycles
>>   Add support for PCA953x I2C gpio devices
>>   XPedite5370 board support
>>   85xx: Enable inbound PCI config cycles for X-ES boards
>>   XPedite5200 board support
>
> Thanks for picking up these patches.  It looks like something got a bit
> messed up in the process however.
>
> 1. The order of application of "85xx: Enable inbound PCI config cycles
> for X-ES boards" and "XPedite5200 board support" should be swapped - the
> "85xx: Enable inbound PCI config cycles for X-ES boards" patch modifies
> some code that "XPedite5200 board support" added.  I'm fine with
> submitting another patch to resolve any issues if that's easier for you.
>
> 2. The "XPedite5200 board support" patch in the 85xx branch only appears
> to change files which exist, it doesn't add a number of necessary, new
> files.  eg diff stat from the patch:
>  MAINTAINERS |1 +
>  MAKEALL |1 +
>  Makefile|3 +
>  board/xes/common/Makefile   |3 +-
>  board/xes/common/actl_nand.c|   65 
>  board/xes/common/fsl_85xx_pci.c |  103 +++-
>  board/xes/xpedite5200/Makefile  |   55 
>  board/xes/xpedite5200/config.mk |   34 +++
>  board/xes/xpedite5200/ddr.c |   91 ++
>  board/xes/xpedite5200/law.c |   51 
>  board/xes/xpedite5200/tlb.c |   85 ++
>  board/xes/xpedite5200/u-boot.lds|  145 +
>  board/xes/xpedite5200/xpedite5200.c |  125 
>  include/configs/XPEDITE5200.h   |  546
> +++
>  14 files changed, 1303 insertions(+), 5 deletions(-)
>  create mode 100644 board/xes/common/actl_nand.c
>  create mode 100644 board/xes/xpedite5200/Makefile
>  create mode 100644 board/xes/xpedite5200/config.mk
>  create mode 100644 board/xes/xpedite5200/ddr.c
>  create mode 100644 board/xes/xpedite5200/law.c
>  create mode 100644 board/xes/xpedite5200/tlb.c
>  create mode 100644 board/xes/xpedite5200/u-boot.lds
>  create mode 100644 board/xes/xpedite5200/xpedite5200.c
>
> vs modified files from what's in 85xx branch:
> MAINTAINERS
> MAKEALL
> Makefile
> board/xes/common/Makefile
> board/xes/common/fsl_85xx_pci.c
>
> Let me know if I should take any action.

Ugh, yeah, if you could submit patches which fix this, I'd appreciate
it.  I had some difficulty getting the patches to apply in the right
order (mailbox issues), and must have lost some things in the merge.

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

Re: [U-Boot] Please pull u-boot-mpc85xx.git

2008-12-22 Thread Peter Tyser 
Hi Andy,

On Mon, 2008-12-22 at 13:36 -0600, Andy Fleming wrote:
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-mpc85xx.git master



> Peter Tyser (5):
>   pci/fsl_pci_init: Enable inbound PCI config cycles
>   Add support for PCA953x I2C gpio devices
>   XPedite5370 board support
>   85xx: Enable inbound PCI config cycles for X-ES boards
>   XPedite5200 board support

Thanks for picking up these patches.  It looks like something got a bit
messed up in the process however.

1. The order of application of "85xx: Enable inbound PCI config cycles
for X-ES boards" and "XPedite5200 board support" should be swapped - the
"85xx: Enable inbound PCI config cycles for X-ES boards" patch modifies
some code that "XPedite5200 board support" added.  I'm fine with
submitting another patch to resolve any issues if that's easier for you.

2. The "XPedite5200 board support" patch in the 85xx branch only appears
to change files which exist, it doesn't add a number of necessary, new
files.  eg diff stat from the patch:
 MAINTAINERS |1 +
 MAKEALL |1 +
 Makefile|3 +
 board/xes/common/Makefile   |3 +-
 board/xes/common/actl_nand.c|   65 
 board/xes/common/fsl_85xx_pci.c |  103 +++-
 board/xes/xpedite5200/Makefile  |   55 
 board/xes/xpedite5200/config.mk |   34 +++
 board/xes/xpedite5200/ddr.c |   91 ++
 board/xes/xpedite5200/law.c |   51 
 board/xes/xpedite5200/tlb.c |   85 ++
 board/xes/xpedite5200/u-boot.lds|  145 +
 board/xes/xpedite5200/xpedite5200.c |  125 
 include/configs/XPEDITE5200.h   |  546
+++
 14 files changed, 1303 insertions(+), 5 deletions(-)
 create mode 100644 board/xes/common/actl_nand.c
 create mode 100644 board/xes/xpedite5200/Makefile
 create mode 100644 board/xes/xpedite5200/config.mk
 create mode 100644 board/xes/xpedite5200/ddr.c
 create mode 100644 board/xes/xpedite5200/law.c
 create mode 100644 board/xes/xpedite5200/tlb.c
 create mode 100644 board/xes/xpedite5200/u-boot.lds
 create mode 100644 board/xes/xpedite5200/xpedite5200.c

vs modified files from what's in 85xx branch:
MAINTAINERS
MAKEALL
Makefile
board/xes/common/Makefile
board/xes/common/fsl_85xx_pci.c

Let me know if I should take any action.

Best,
Peter

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

Re: [U-Boot] ftp area ftp://ftp.denx.de/pub/u-boot/

2008-12-22 Thread Dirk Behme 
Dusek, Richard (Richard)** CTR ** wrote:
>  
> Could you tell me why has the name been changed from the
> u-boot-1.3.4.tar.bz2 type name to u-boot-2008.10.tar.bz2.
> 
> The build uses the root directory to create the version number, in
> version_autogenerated.h, 
> 
> and now it is reported as "U-boot 2008.10"
> 
> instead of the old "U-Boot 1.3.4"
> 
> Where is this documented.  What does it mean.
> 
> I searched through the CHANGELOG and the readme file and didn't find any
> mention of this.

Maybe

http://lists.denx.de/pipermail/u-boot/2008-August/039644.html

and the following thread can help you.

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

Re: [U-Boot] ftp area ftp://ftp.denx.de/pub/u-boot/

2008-12-22 Thread Ben Warren 
Hi Richard,

Dusek, Richard (Richard)** CTR ** wrote:
>  
>
> Could you tell me why has the name been changed from the
> u-boot-1.3.4.tar.bz2 type name to u-boot-2008.10.tar.bz2.
>
>  
>   
To be less arbitrary.  The version number now includes a date, as 
opposed to continually increasing numbers with subjective 
major/minor/trivial numbers.
> The build uses the root directory to create the version number, in
> version_autogenerated.h, 
>
> and now it is reported as "U-boot 2008.10"
>
>  
>
> instead of the old "U-Boot 1.3.4"
>
>  
>
> Where is this documented.  What does it mean.
>
>  
>   
U-boot-2008.10 was released in October, 2008 (hence 2008.10).  The next 
one will be 2009.01, to be released in January 2009.  The last version 
with the old numbering scheme was 1.3.4.
> I searched through the CHANGELOG and the readme file and didn't find any
> mention of this.
>
>  
>
> Thank you.
>
>  
>   
regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] NIOS2: Added DE2 board with SD support

2008-12-22 Thread ivanchuklist ivanchu 
Hi list,
I wrote about my work with u-boot in the thread "[U-Boot] DE2 board with MMC
interface (PIO based) and FAT support enabled" and i decided to post a
patch. I would like to discuss the changes.
I have changed the Makefile to match the binutils provided by Altera and i
added the DE2 board.
I have also made changes to the files cmd_mem.c to add one more command
"dmmc". Because the SD card is not a memory mapped device in the bus like a
flash memory, we can't deduce the direction of data (i mean when copying
data to sd or from sd) with the function mmc2info(). I tried to solve this
trick by using the command dmmc.
I found problems at link level with cmd_mmc.o and cmd_mem.o because both
files includes mmc.h, then i have two copies of the same functions in both
objects files. I solved this problem by declaring extern the function
mmc_init in cmd_mmc.c.
I think i should post the file include/asm-nios2/arch-nios2/mmc.h and the
board related files but i will wait your response.
In include/asm-nios2/arch-nios2/mmc.h i implemented mmc_get_dev() and
mmc_read_block() to provide access to the FAT table.
The code is working with all the examples distributed by Altera in the DE2
board and it should work with any SD socket interfaced by PIO cores.

diff --git a/Makefile b/Makefile
index 4df4812..6501d08 100644
--- a/Makefile
+++ b/Makefile
@@ -163,7 +163,7 @@ ifeq ($(ARCH),nios)
 CROSS_COMPILE = nios-elf-
 endif
 ifeq ($(ARCH),nios2)
-CROSS_COMPILE = nios2-elf-
+CROSS_COMPILE = nios2-linux-
 endif
 ifeq ($(ARCH),m68k)
 CROSS_COMPILE = m68k-elf-
@@ -3137,6 +3137,9 @@ PK1C20_config : unconfig
 PCI5441_config : unconfig
 @$(MKCONFIG)  PCI5441 nios2 nios2 pci5441 psyent

+DE2_config : unconfig
+@$(MKCONFIG)  DE2 nios2 nios2 de2 altera
+
 #
 ## Microblaze
 #
diff --git a/common/cmd_mem.c b/common/cmd_mem.c
index 400cfd7..4585795 100644
--- a/common/cmd_mem.c
+++ b/common/cmd_mem.c
@@ -53,6 +53,7 @@ uintdp_last_length = 0x40;
 uintmm_last_addr, mm_last_size;

 staticulongbase_address = 0;
+staticulongmmc_direction = 0;

 /* Memory Display
  *
@@ -355,6 +356,17 @@ int do_mem_cmp (cmd_tbl_t *cmdtp, int flag, int argc,
char *argv[])
 return rcode;
 }

+int do_dmmc( cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
+{
+if (argc > 1)
+mmc_direction = simple_strtoul(argv[1], NULL, 10);
+if (mmc_direction)
+printf("Mem to mmc\n");
+else
+printf("Mmc to mem\n");
+return 0;
+}
+
 int do_mem_cp ( cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 {
 ulongaddr, dest, count;
@@ -405,7 +417,7 @@ int do_mem_cp ( cmd_tbl_t *cmdtp, int flag, int argc,
char *argv[])
 #endif

 #if defined(CONFIG_CMD_MMC)
-if (mmc2info(dest)) {
+if (mmc_direction) {
 int rc;

 puts ("Copy to MMC... ");
@@ -422,9 +434,7 @@ int do_mem_cp ( cmd_tbl_t *cmdtp, int flag, int argc,
char *argv[])
 }
 puts ("done\n");
 return 0;
-}
-
-if (mmc2info(addr)) {
+} else {
 int rc;

 puts ("Copy from MMC... ");
@@ -1221,6 +1231,14 @@ U_BOOT_CMD(
 "[.b, .w, .l] address value [count]\n- write memory\n"
 );

+#if defined(CONFIG_CMD_MMC)
+U_BOOT_CMD(
+dmmc,2,1,do_dmmc,
+"dmmc- set mmc-memory copy direction\n",
+"direction\n- copy mmc<->mem\n"
+);
+#endif
+
 U_BOOT_CMD(
 cp,4,1,do_mem_cp,
 "cp- memory copy\n",
diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c
index 25c9702..c9a5ac6 100644
--- a/common/cmd_mmc.c
+++ b/common/cmd_mmc.c
@@ -23,7 +23,8 @@

 #include 
 #include 
-#include 
+
+extern int mmc_init(int);

 int do_mmc (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 {
@@ -31,6 +32,7 @@ int do_mmc (cmd_tbl_t *cmdtp, int flag, int argc, char
*argv[])
 printf ("No MMC card found\n");
 return 1;
 }
+printf ("MMC card found\n");
 return 0;
 }
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] ftp area ftp://ftp.denx.de/pub/u-boot/

2008-12-22 Thread Dusek, Richard (Richard)** CTR ** 
 

Could you tell me why has the name been changed from the
u-boot-1.3.4.tar.bz2 type name to u-boot-2008.10.tar.bz2.

 

The build uses the root directory to create the version number, in
version_autogenerated.h, 

and now it is reported as "U-boot 2008.10"

 

instead of the old "U-Boot 1.3.4"

 

Where is this documented.  What does it mean.

 

I searched through the CHANGELOG and the readme file and didn't find any
mention of this.

 

Thank you.

 

 

+

Rick Dusek

1 Robbins Rd. 

Westford Ma 01886

Phone: 978-952-1155

 

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

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

2008-12-22 Thread Andy Fleming 
are available in the git repository at:

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

Dave Liu (1):
  85xx: Fix the boot window issue

Haiying Wang (1):
  Set IVPR to kenrel entry point in second core boot page

Kumar Gala (3):
  85xx: Add support to populate addr map based on TLB settings
  ppc: Use addrmap in virt_to_phys and map_physmem.
  NAND FSL elbc: Use virt_to_phys to determine which bank is in use

Paul Gortmaker (3):
  sbc8548: don't enable the 3rd and 4th eTSEC
  sbc8548: enable command line editing by default.
  sbc8548: use proper PHY address

Peter Tyser (5):
  pci/fsl_pci_init: Enable inbound PCI config cycles
  Add support for PCA953x I2C gpio devices
  XPedite5370 board support
  85xx: Enable inbound PCI config cycles for X-ES boards
  XPedite5200 board support

Trent Piepho (5):
  mpc8[56]xx: Put localbus clock in device tree
  mpc8xxx: LCRR[CLKDIV] is sometimes five bits
  mpc8568: Double local bus clock divider
  mpc86xx: Double local bus clock divider
  mpc8[56]xx: Put localbus clock in sysinfo and gd

 MAINTAINERS |4 +
 MAKEALL |2 +
 Makefile|8 +
 README  |9 +
 board/freescale/mpc8540ads/mpc8540ads.c |2 +-
 board/freescale/mpc8541cds/mpc8541cds.c |2 +-
 board/freescale/mpc8548cds/mpc8548cds.c |2 +-
 board/freescale/mpc8555cds/mpc8555cds.c |2 +-
 board/freescale/mpc8560ads/mpc8560ads.c |2 +-
 board/freescale/mpc8568mds/mpc8568mds.c |2 +-
 board/mpc8540eval/mpc8540eval.c |2 +-
 board/pm854/pm854.c |2 +-
 board/pm856/pm856.c |2 +-
 board/sbc8548/sbc8548.c |2 +-
 board/socrates/socrates.c   |2 +-
 board/tqc/tqm85xx/tqm85xx.c |2 +-
 board/xes/common/Makefile   |   57 +++
 board/xes/common/fsl_8572_clk.c |   51 +++
 board/xes/common/fsl_85xx_ddr.c |   93 +
 board/xes/common/fsl_85xx_pci.c |  375 
 board/xes/xpedite5370/Makefile  |   45 +++
 board/xes/xpedite5370/config.mk |   35 ++
 board/xes/xpedite5370/ddr.c |  270 ++
 board/xes/xpedite5370/law.c |   54 +++
 board/xes/xpedite5370/tlb.c |   94 +
 board/xes/xpedite5370/u-boot.lds|  145 
 board/xes/xpedite5370/xpedite5370.c |  128 +++
 cpu/mpc85xx/cpu.c   |   31 +--
 cpu/mpc85xx/fdt.c   |8 +-
 cpu/mpc85xx/release.S   |1 +
 cpu/mpc85xx/speed.c |   27 ++
 cpu/mpc85xx/start.S |   16 +-
 cpu/mpc85xx/tlb.c   |   34 ++
 cpu/mpc86xx/cpu.c   |   21 +-
 cpu/mpc86xx/fdt.c   |9 +
 cpu/mpc86xx/speed.c |   19 +
 drivers/gpio/Makefile   |   47 +++
 drivers/gpio/pca953x.c  |  227 
 drivers/mtd/nand/fsl_elbc_nand.c|6 +-
 drivers/pci/fsl_pci_init.c  |   29 ++
 include/asm-ppc/fsl_lbc.h   |5 +-
 include/asm-ppc/global_data.h   |3 +
 include/asm-ppc/io.h|   12 +
 include/asm-ppc/mmu.h   |3 +
 include/configs/XPEDITE5370.h   |  589 +++
 include/configs/sbc8548.h   |   20 +-
 include/e500.h  |1 +
 include/mpc86xx.h   |1 +
 include/pca953x.h   |   39 ++
 lib_ppc/board.c |8 +
 50 files changed, 2467 insertions(+), 83 deletions(-)
 create mode 100644 board/xes/common/Makefile
 create mode 100644 board/xes/common/fsl_8572_clk.c
 create mode 100644 board/xes/common/fsl_85xx_ddr.c
 create mode 100644 board/xes/common/fsl_85xx_pci.c
 create mode 100644 board/xes/xpedite5370/Makefile
 create mode 100644 board/xes/xpedite5370/config.mk
 create mode 100644 board/xes/xpedite5370/ddr.c
 create mode 100644 board/xes/xpedite5370/law.c
 create mode 100644 board/xes/xpedite5370/tlb.c
 create mode 100644 board/xes/xpedite5370/u-boot.lds
 create mode 100644 board/xes/xpedite5370/xpedite5370.c
 create mode 100644 drivers/gpio/Makefile
 create mode 100644 drivers/gpio/pca953x.c
 create mode 100644 include/configs/XPEDITE5370.h
 create mode 100644 include/pca953x.h
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] jffs2_1pass and jffs2_nand_1pass

2008-12-22 Thread Derek Ou 
Hi, all,

I am having problem loading jffs2 from NAND with the latest code.  After 
some research, I am getting confused regarding the two files 
jffs2_1pass.c and jffs2_nand_1pass.c.  Some post suggested 
jffs2_nand_1pass.c to replace jffs2_1pass.c for jffs2_NAND.  The git 
history 08ab4e1780fa63c88dd5a5ab52f4ff4ed1ee1878 seems to be moving away 
from using the file jffs2_nand_1pass.c.  Is this commit incomplete or I 
should not use the file jffs2_nand_1pass.c at all?

Also, I am trying to load jffs2 from NAND with latest code on my 
at91sam9263ek-based board.  I run into the "### ERROR ### Please RESET 
the board ###" error.  Is this a memory space issue?  Any suggestion on 
how to debug?

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

Re: [U-Boot] [RFC][PATCH] Code Clean-up (weak functions)

2008-12-22 Thread Graeme Russ 
On Mon, Dec 22, 2008 at 10:44 PM, Mike Frysinger  wrote:
> On Monday 22 December 2008 04:16:33 Graeme Russ wrote:
>> On Mon, Dec 22, 2008 at 8:05 PM, Mike Frysinger wrote:
>> > On Saturday 13 December 2008 00:26:26 Graeme Russ wrote:
>> >> This patch makes all definitions, declarations and usages of weak
>> >> functions consistent.
>> >
>> > a quick glance shows that it breaks things (the ELF and Blackfin stuff
>> > certainly appears to be wrong).  i'm guessing you focused on style for
>> > the RFC part rather than the result actually being correct ...
>> > -mike
>>
>> Thanks for having a look at this. Would it be possible for you to be a bit
>> more specific about 'wrong' if for nothing other that me gaining a better
>> understanding of how it works, and how it breaks
>
> you set the aliases to functions that do not exist
> -mike
>
Ack  - I can see that for the ELF - the main function needs to be renamed
__do_bootelf_exec ()

I cannot see the problem with Blackfin - I will freely admit that Blackfin has
been fundamentally changed (any therefore needs thorough testing), but unless
the Blackfin toolchain treats weak function linking differently, it _should_
"just still work"(tm)

Maybe I am not seeing the obvious?

Regards,

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

Re: [U-Boot] [RFC][PATCH] Code Clean-up (weak functions)

2008-12-22 Thread Mike Frysinger 
On Monday 22 December 2008 04:16:33 Graeme Russ wrote:
> On Mon, Dec 22, 2008 at 8:05 PM, Mike Frysinger wrote:
> > On Saturday 13 December 2008 00:26:26 Graeme Russ wrote:
> >> This patch makes all definitions, declarations and usages of weak
> >> functions consistent.
> >
> > a quick glance shows that it breaks things (the ELF and Blackfin stuff
> > certainly appears to be wrong).  i'm guessing you focused on style for
> > the RFC part rather than the result actually being correct ...
> > -mike
>
> Thanks for having a look at this. Would it be possible for you to be a bit
> more specific about 'wrong' if for nothing other that me gaining a better
> understanding of how it works, and how it breaks

you set the aliases to functions that do not exist
-mike


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

Re: [U-Boot] [RFC][PATCH] Code Clean-up (weak functions)

2008-12-22 Thread Graeme Russ 
Mike,

On Mon, Dec 22, 2008 at 8:05 PM, Mike Frysinger  wrote:
> On Saturday 13 December 2008 00:26:26 Graeme Russ wrote:
>> This patch makes all definitions, declarations and usages of weak functions
>> consistent.
>
> a quick glance shows that it breaks things (the ELF and Blackfin stuff
> certainly appears to be wrong).  i'm guessing you focused on style for the RFC
> part rather than the result actually being correct ...
> -mike
>

Thanks for having a look at this. Would it be possible for you to be a bit more
specific about 'wrong' if for nothing other that me gaining a better
understanding of how it works, and how it breaks

I was, honestly, hoping that the changes would not break things.

Thanks,


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

Re: [U-Boot] [RFC][PATCH] Code Clean-up (weak functions)

2008-12-22 Thread Mike Frysinger 
On Saturday 13 December 2008 00:26:26 Graeme Russ wrote:
> This patch makes all definitions, declarations and usages of weak functions
> consistent.

a quick glance shows that it breaks things (the ELF and Blackfin stuff 
certainly appears to be wrong).  i'm guessing you focused on style for the RFC 
part rather than the result actually being correct ...
-mike


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

Re: [U-Boot] [PATCH] cmd_sf: rename "speed" to "hz"

2008-12-22 Thread Mike Frysinger 
On Friday 12 December 2008 02:22:16 Wolfgang Denk wrote:
> In message <200812112130.02918.vap...@gentoo.org> you wrote:
> > > > -#ifndef CONFIG_SF_DEFAULT_SPEED
> > > > -# define CONFIG_SF_DEFAULT_SPEED   100
> > > > +#ifndef CONFIG_SF_DEFAULT_HZ
> > > > +# define CONFIG_SF_DEFAULT_HZ  100
> > >
> > > I consider "FREQ" (and even "SPEED) a much better name than "HZ".
> > >
> > > "HZ" is the unit of what you are measuring, not a name for what you
> > > are measuring.
> >
> > then they should all be converted.  not 90% using hz and 10% using
> > something
>
> Agreed.
>
> > else.  "speed" is bad as it doesnt convey the unit while "hz" is pretty
> > clear.
>
> You are right, but that could be mentioned in the documentation
> then...

that seems silly to me.  we can either have self-explaining defines, or 
confusing ones which requires people to read the documentation to figure out ?
-mike


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